DEV Community: Frédéric Guariento

AI Systems: MCP vs CLI – Which Interface Should You Trust?

Frédéric Guariento — Fri, 28 Aug 2026 18:05:48 +0000

What if the command line we've trusted for decades is quietly becoming the wrong abstraction for how AI systems actually need to work?

I've been running both patterns side by side in my homelab — one RTX 4070 Ti, twelve gigabytes of VRAM, thirty-four Docker containers competing for attention — and the friction between them keeps surfacing. Not as a theoretical debate, but as a daily architectural decision. When should a local model invoke a tool through structured protocol? When does a bash script still win?

The Model Context Protocol promises something seductive: universal, stateful, discoverable interfaces between AI agents and their capabilities. No more parsing brittle command outputs. No more regex archaeology on stderr. Just clean contracts, typed schemas, capabilities exposed as resources rather than executed as commands. Anthropic's push has momentum — Cursor, Claude Desktop, an ecosystem growing weekly.

Yet my production reality looks different. That same Ollama stack running llama3.1:8b at 84 tokens per second? It talks to Qdrant through HTTP, to paperless-AI through filesystem events, to my Gmail classifier through Python scripts that shell out to gcloud when OAuth tokens expire. The LiteLLM proxy in the middle doesn't care whether the downstream tool speaks MCP or CLI. It cares about latency, reliability, whether the container restart policy actually works at 2 AM.

Here's what the protocol evangelists rarely admit: MCP servers are still mostly thin wrappers around the same binaries they claim to transcend. Your filesystem MCP? It's calling stat and read underneath. Your PostgreSQL MCP? psycopg2 with extra JSON-RPC framing. The abstraction leaks immediately when you need streaming responses, when authentication expires mid-session, when resource limits hit and you need backpressure semantics that the protocol spec hand-waves away.

But the inverse critique cuts deeper. CLI tools compose beautifully in ways that resist formalization. Pipe grep into awk into xargs and you've expressed a computation no single MCP server captures without bespoke implementation. The Unix philosophy — small tools, clean interfaces, text as universal glue — emerged from constraints that haven't disappeared. They've just been relabeled as "technical debt."

So where does this leave us for production?

I see three fault lines that decide the question, at least for environments like mine where "production" means household infrastructure that must not break, not a datacenter with SRE rotation.

First, discovery versus stability. MCP's resource templating lets an agent enumerate available tools dynamically. This matters when your capability surface changes — new RAG collections, ephemeral sandbox environments, model versions that expose different quantized variants. But dynamic discovery introduces version skew. My CLI integrations are static, brittle, explicit. A broken script fails fast and loud. An MCP server with drifting schema fails in subtle ways, authentication tokens refreshing silently until they don't.

Second, observability and debugging. When my local stack misbehaves — and with 12 GB VRAM, misbehavior means context windows truncated, models falling back to CPU at 4 tokens per second, the thermal throttling you only notice when responses lag — I need to see the full chain. CLI tools leave traces: shell history, process trees, exit codes that actually mean something. MCP's JSON-RPC framing obscures this. The error you need is three hops deep in a server you didn't write, wrapped in protocol layers that assume success.

Third, the human-in-the-loop boundary. Claude via my flat Anthropic Max plan handles reasoning I won't run locally — too expensive in GPU time, too complex for 8B parameters. But when that reasoning needs to touch my infrastructure, which interface feels appropriate? MCP's session-oriented design assumes persistent context, state accumulation, the long conversation. CLI assumes discrete invocation, idempotency, the command that completes or doesn't. My production flows mix both: planning via frontier model, execution via local tools, with explicit handoff points I control.

What I'm building toward — not yet deployed, still evaluating — is a hybrid architecture that doesn't pretend either pattern is sufficient. LiteLLM already routes between local and remote; extending it to tag tool calls by interface type seems tractable. Some capabilities deserve protocol formalization: vector search with metadata filtering, multi-turn stateful interactions. Others deserve the simplicity of subprocess invocation: image conversion, PDF extraction, the Unix tools perfected over decades.

The deeper question beneath MCP versus CLI is about where we place trust in our AI systems. Protocols promise safety through specification. Command lines promise safety through transparency. Both promises break in production, but they break differently, and your recovery posture should match your breaking mode.

My RTX 4070 Ti doesn't care about elegance. It cares about memory pressure and batch size and whether the next token arrives before timeout. Your production environment likely has analogous constraints, whatever your scale. The right abstraction isn't the one that wins technical debates — it's the one that fails gracefully when your context window slams against the VRAM wall at 3 AM.

Which interface are you betting your reliability on, and have you tested it under real resource pressure?

Originally published at articles.savethemall.eu.

🤖 Written with AI assistance, reviewed and approved before publication. Editorial responsibility: Frédéric Guariento. How it works

Your RAG Answers From 62% of Your Corpus and Won't Tell You

Frédéric Guariento — Fri, 28 Aug 2026 18:05:16 +0000

Every retrieval system I have ever deployed has one property in common with every retrieval system you have ever deployed: it will answer. It will always answer. Ask it something that lives in a document it never ingested, and it will not say "I do not have that." It will find the nearest thing it does have, rank it, cite it, and hand it to you with the same confidence it would give a perfect match.

This is not a hallucination problem. The model behaved correctly. It answered from what it was given. The failure happened one layer down, in the boring part nobody demos: ingestion.

Last week I measured the corpus coverage of a self-hosted knowledge base I have been running for months. Nineteen hundred documents, semantic search, embeddings served locally, the whole pipeline built and monitored by me. I expected a number close to 100%.

I got 62%.

The number before the number was worse, and also wrong

My first measurement said 8.8%.

That number was real in the sense that a computer produced it. It was also useless, because I had divided the indexed documents by every markdown file on the volume — 13,257 of them — and 11,368 of those belong to entirely different collections that were never meant to be in this index at all.

Same system. Same afternoon. Two measurements. A factor of seven apart.

The honest denominator was 1,890 indexable documents, of which 1,169 were present: 62%. Both numbers were arithmetically correct. Only one described anything.

I want to sit on this for a moment, because it is the part that generalises beyond my homelab. A coverage percentage with an unstated denominator is not a metric. It is a vibe with a decimal point. Every ingestion dashboard I have seen in a commercial product reports documents processed. That is a numerator. It is presented as an achievement — 1,169 documents indexed, green check, ingestion complete — and the question it is quietly not answering is: out of how many, and who decided what counted?

If your vendor cannot state the denominator, your vendor is not measuring coverage. They are counting successes and calling it completeness.

The cause: a notification that never arrives is indistinguishable from nothing to do

The technical root was almost disappointing.

The indexer watched the filesystem with inotify. inotify does not cross NFS. Documents written from the machine running the indexer were seen instantly. Documents written from anywhere else — a laptop, another VM, a sync client — were never seen at all. Not delayed. Not queued. Never.

There is no error state for this. The watcher is healthy. It is watching. It reports zero events, because zero events reached it, and zero events is exactly what a quiet system looks like. Every dashboard stayed green while a quarter of the corpus quietly aged out of reality.

This is the shape of the whole class of bug, and it is worth naming precisely: file events are a notification, not a guarantee, and nothing in the stack is obliged to tell you that the notification never came. Any system built on "react when something changes" inherits a silent failure mode the moment the change happens somewhere the events do not reach. Object storage. Network shares. Container bind mounts. Sync clients that write to a shadow directory and rename. Each one breaks the assumption in its own way, and none of them raise their hand.

What actually fixed it

Two things, neither of them clever.

Polling instead of events. A 60-second sweep calling stat() on the tree. stat() crosses NFS, because it asks rather than waits. It is less elegant and less efficient than inotify, and it works. Verified end to end: a file touched from a different machine now appears in the index ninety seconds later. Before the change, the correct number was never.

Hourly reconciliation. Walk the source tree, walk the index, compare. Emit three counts: documents missing from the index, documents in the index whose source has changed, documents in the index whose source no longer exists. Missing, stale, orphaned.

The division of labour matters more than either mechanism: polling catches up, reconciliation proves. Polling is the repair. Reconciliation is the evidence that the repair worked — and, critically, it keeps producing that evidence after everyone stops paying attention. A fix without a standing measurement is a fix that will silently regress and take another few months to notice.

Coverage went to 1,890 of 1,890. The directory that had been at zero — 235 files of accumulated operational notes, the exact material the system existed to retrieve — was finally in there.

The bug that only showed up once I was looking

Fixing coverage surfaced something considerably worse, and this is the part I would most want a stranger to take away.

The embedding step returned a list of vectors. On failure, that list was compacted — the failed entry dropped. The caller zipped chunks to embeddings by position.

You can see it. One embedding timing out did not lose one section. It shifted every section after it by one. The text of section twelve was stored under the coordinates of section thirteen, and so on to the end of the document.

Searches kept working. Results came back ranked, cited, plausible, and attached to the wrong source. There is no test called "does search return results" that catches this, because search returned results the entire time. The only thing that catches it is deliberately asking a question whose correct answer you already know, and checking the citation rather than the prose.

Related, and cheaper than it sounds: I also excluded roughly 1,500 near-identical boilerplate chunks — template sections repeated across auto-generated reports. They were not missing data, they were crowding. A real query for a specific configuration rule now returns that rule at 0.792 similarity; before, three auto-generated reports sat above it at 0.66. Coverage is not only what is absent. It is also what is present so many times that it drowns the thing you needed.

What to measure on Monday

If you operate retrieval in production, these are cheap and none of them require a vendor:

Coverage with a stated denominator. Write the denominator down in words. "Indexable" is a policy decision, not a fact — make someone own it.
Coverage per directory, never as a single average. An aggregate hides a folder at zero. That is not a hypothetical; it is the specific way this hid.
Staleness and orphans, not just presence. A document indexed at the wrong version is worse than a missing one, because it answers.
Alignment between text and vector. Store the chunk with its embedding as one unit, or verify the pairing. Never zip two lists by position across a boundary where one can fail independently.
A canary question. One query per corpus whose correct source you know by heart. Run it on a schedule. Check the citation, not the answer.

The uncomfortable part

None of this was a model problem. Nothing here would have been improved by a larger context window, a better reranker, or a more capable model. The failure was entirely in the plumbing, and the plumbing had no opinion about it.

We spend enormous energy evaluating whether models hallucinate, and almost none verifying that the corpus we are grounding them in is the corpus we think it is. Grounding is only as good as the ground.

A retrieval system cannot report the document it never read. It has no representation of the thing that is absent. Ask it whether its knowledge is complete and it will answer, fluently, from the fraction it holds — which is exactly the question you were trying to settle.

So the question is not whether your RAG works. It answers, so it works. The question is what your coverage number is, what its denominator is, and whether anybody has looked at it since the day it was built.

What is your coverage number — and did you measure it, or inherit it from a dashboard?

Originally published at articles.savethemall.eu.

🤖 Written with AI assistance, reviewed and approved before publication. Editorial responsibility: Frédéric Guariento. How it works

Why BYD's Victory Reveals the Future of Software: Vertical Integration Is Coming to AI

Frédéric Guariento — Fri, 28 Aug 2026 18:04:44 +0000

The world watched as BYD overtook Tesla in EV sales last year. But that wasn't the real story. The real story is why — and what it tells us about the software industry in the next five years.

BYD didn't win because they made a better car. They won because they controlled the entire value chain: batteries, semiconductors, software, manufacturing. They didn't outsource the core. They built it all in-house, iterated ruthlessly, and moved faster than anyone else.

Now watch what's happening in software and AI. The pattern is repeating itself. And most of us are still pretending it isn't.

1. The Vertical Integration Thesis — It's Not New, But It's Coming to Software

For decades, the software industry has worshipped modularity and outsourcing. You buy your database from one vendor, your cloud from another, your security from a third. You stitch it together with APIs and hope for the best.

This worked when the pace of change was slow and differentiation happened at the application layer.

It doesn't work anymore.

BYD's lesson is brutal: when you're in a race where the pace of innovation accelerates exponentially, controlling the entire stack — from foundational models to inference, from data pipelines to security — becomes a competitive necessity, not a luxury.

Look at what's happening:

OpenAI didn't just build ChatGPT. They're building their own infrastructure, training their own models, deploying their own endpoints. They're not betting their future on AWS or Azure alone.

Anthropic is doing the same. Claude runs on their own infrastructure, with their own safety layers, their own data practices.

Google has Gemini, Vertex AI, and TPUs. Meta has Llama and their own silicon roadmap. Microsoft is bundling Copilot so tightly into Windows and Office that the operating system itself becomes the moat.

The companies winning aren't the ones renting cloud capacity. They're the ones who own the entire experience.

2. The Data Flywheel — Where BYD's Real Advantage Lies

BYD sells millions of EVs. Every car generates data: driving patterns, battery performance, charging behavior, grid interaction. That data feeds back into product design, manufacturing optimization, and the next generation of batteries.

This is a flywheel that no pure software company can replicate unless they own distribution and user intimacy at scale.

But here's what's interesting: the SaaS industry is starting to build the same flywheel, just with different assets.

Companies like Notion, Figma, and Linear aren't just selling software. They're collecting behavioral data from millions of users — how people structure information, how teams collaborate, how developers organize their workflows. That data trains their AI features, which makes the product stickier, which generates more data.

The winners in the next wave won't be the ones with the best algorithms. They'll be the ones with the best data about how people actually work.

This is why Microsoft's bet on integrating Copilot into Office is so dangerous. They don't just have the software; they have 400 million users generating data about how work happens. That's a flywheel BYD would recognize immediately.

3. The Cost of Ownership Problem — And Why It Matters

Here's where the analogy gets uncomfortable.

For years, car manufacturers outsourced to suppliers. It was cheaper. It was faster. It was modular.

Then electric vehicles happened. Suddenly, batteries weren't just a component — they were the entire value proposition. The companies that controlled battery design, manufacturing, and supply chain didn't just make better products. They made them more profitable because they eliminated the middleman.

Tesla understood this early. So did BYD.

In software, we're at the same inflection point with AI.

Right now, most companies are renting AI: paying OpenAI per token, using Azure OpenAI, calling Anthropic's API. It feels cheap because the marginal cost is low.

But the total cost of ownership is about to explode.

As AI becomes embedded in every workflow — not as a novelty feature, but as the core of how work gets done — the economics of API calls break down. You're paying for every inference, every token, every interaction. At scale, this becomes unsustainable for anyone who isn't OpenAI or Anthropic.

The companies that will own the next decade are the ones building their own inference stacks. Not because it's trendy. Because it's the only way to achieve unit economics that make sense at scale.

This is already happening quietly:

Slack is building their own AI features rather than just embedding ChatGPT.
Figma is training models on their design data, not outsourcing to OpenAI.
GitHub Copilot is moving toward GitHub's own models, not just GitHub + OpenAI.
Enterprise software companies are evaluating local inference with models like Llama or Mistral, not because they're as good as GPT-4, but because they cost a fraction of the price at scale.

I've been experimenting with this myself. Running llama3.1:8b locally on a single consumer GPU gives me 84 tokens per second — enough for most tasks. The cost? Zero per inference, after the hardware. Compare that to the API economics of Claude or GPT-4, and the math becomes obvious.

4. The Sovereignty Play — Control Means Resilience

BYD's vertical integration also gives them something less tangible: sovereignty. They're not dependent on Japanese suppliers for batteries, or American chip designers for semiconductors. When supply chains break, they can adapt.

Europe learned this lesson the hard way during the chip shortage. So did Taiwan. So is every government now.

The software industry hasn't fully grasped this yet, but it will.

Right now, the entire AI industry is built on a single point of failure: a handful of American companies controlling the foundational models. If OpenAI has a crisis, if there's a regulatory crackdown, if there's a geopolitical rupture — the entire ecosystem breaks.

This is why governments are investing in sovereign AI. Why Europe is funding projects to build European large language models. Why China is building its own stack. Why India is exploring local alternatives.

It's not about ideological purity. It's about risk.

The companies that will thrive are the ones that can operate with multiple models, multiple inference strategies, and multiple data sources. Not because one is "better," but because resilience requires optionality.

5. The Real Disruption — Speed and Iteration

Here's what people miss about BYD's victory: it wasn't about having a better battery in 2024. It was about the capability to iterate faster than anyone else.

BYD can design a new battery architecture, test it, manufacture it, and integrate it into production cars in months. Tesla takes longer. Traditional OEMs take years.

The same dynamic is playing out in software.

The companies winning with AI aren't the ones with the most sophisticated models. They're the ones that can iterate on their entire stack — from data collection to inference to user experience — in weeks, not quarters.

This requires:

Owning the data pipeline. You can't iterate fast on data you don't control.
Owning the inference layer. You can't optimize what you can't measure and modify.
Owning the user interface. You can't learn from users if there's an API boundary between you and them.

This is why Vercel (the Next.js company) is dangerous. They're not just selling a framework. They're building a complete stack from code to deployment to AI features, all integrated. They control the entire experience.

This is why Replit is interesting. They're building an IDE where the AI is native, not bolted on.

This is why Linear is winning against Jira. They own the entire workflow, and they can integrate AI at every point because there's no architectural boundary preventing them.

6. The Consolidation Is Coming

Here's the uncomfortable truth: the next three to five years will see massive consolidation in the software industry.

The companies that can afford to build and maintain a complete stack — data, models, inference, applications — will pull further ahead. The companies that are stitching together third-party components will find themselves in a cost structure they can't escape.

This doesn't mean the small players lose. It means the small players that win are the ones that own a specific, defensible part of the stack and integrate deeply with it. Not the ones trying to be a general-purpose platform.

What should you be thinking about?

If you're building a SaaS company:

Are you dependent on API costs that will become unsustainable at scale?
Do you have a plan to own your inference layer, or are you betting your unit economics on OpenAI's pricing staying favorable?
Can you build a data flywheel that improves your product over time, or are you just a UI layer on top of someone else's model?

If you're evaluating AI tools:

Does this solve a problem, or does it solve a problem while also building a moat for the vendor?
What happens to your costs when this moves from novelty to core workflow?
Are you building a dependency on a single vendor's API, or are you building flexibility?

If you're in enterprise IT:

Your AI strategy shouldn't be "use OpenAI's API for everything." It should be "use multiple models, multiple inference strategies, and own the data."
Local inference, federated learning, and hybrid architectures aren't nice-to-haves. They're becoming table stakes.

7. The European Moment (Again)

Europe is uniquely positioned to learn this lesson, but probably won't.

We have strong regulatory frameworks (GDPR, AI Act). We have companies with real technical depth. We have the ability to build sovereign infrastructure.

What we don't have is the speed and ruthlessness to move fast enough.

By the time European companies realize they need to own their stack, the Americans and Chinese will have already won. Again.

The window is closing. It's not closed yet, but it's closing.

The Bottom Line

BYD didn't win because they were smarter than Tesla. They won because they understood that in a race where the pace of change accelerates, controlling the entire value chain is non-negotiable.

The software and AI industry is at the same inflection point.

The next wave of winners won't be the ones with the cleverest algorithms or the best user interface. They'll be the ones who own the entire stack: data, training, inference, application, and user experience. The ones who can iterate faster because there are no architectural boundaries slowing them down. The ones who can achieve unit economics that make sense at scale.

This is already happening. Most of us are still not seeing it.

The question isn't whether this will happen. It's whether you're building for it or waiting to be disrupted by it.

The time to move is now. Not because it's trendy. Because the math is becoming undeniable.

🚀 #AI #SaaS #Strategy #Verticalintegration #BYD #Tesla #SoftwareArchitecture #CloudComputing #Sovereignty

Word count: 1,647 | Tone: Urgent, analytical, pattern-driven | Audience: Technical leaders, product managers, enterprise decision-makers

Originally published at articles.savethemall.eu.

🤖 Written with AI assistance, reviewed and approved before publication. Editorial responsibility: Frédéric Guariento. How it works

How Fast Could Your AI Do This?" — The Honest Answer

Frédéric Guariento — Fri, 28 Aug 2026 18:04:13 +0000

I get the question almost every week. At work, at dinner, under a LinkedIn post: "How fast could you do this with your AI?"

People expect a number. An hour? A day? And I watch their face change when I give the honest answer: "It depends entirely on what you bring me."

Because the real answer isn't a deadline. It's a question turned back on the asker.

🧊 What you see is only the tip

On social media, AI looks like magic. You type three lines, click a button, and a flawless result appears in thirty seconds. Video, report, code, image — take your pick.

What you're seeing is the last mile. The moment everything works. Nobody films the weeks that came before, because it doesn't dazzle and it doesn't sell in ten seconds.

Yet that's where 95% of the work lives. And 100% of the cost.

🏗️ Before AI even enters the room: three non-negotiables

Whether you're an individual automating your bookkeeping or a company building a domain assistant, AI doesn't start from nothing. Three ingredients have to be in place first. Without them, no AI stands up.

1. A specification. What do you actually want? Which inputs, which outputs, which edge cases? "I want AI to handle my emails" isn't a requirement — it's a wish. A requirement is: which emails, by what criteria, triggering what action, and what happens when something falls outside the frame.

2. Data. AI doesn't invent your reality — it digests it. If your data is scattered, inconsistent, and uncleaned, the most powerful model on earth will produce confident sludge. "Garbage in, garbage out" has never been truer than with AI — except here, the garbage comes out beautifully written.

3. Documented processes. You can't automate what you can't describe. If the know-how lives only in someone's head, the first step isn't technical — it's writing it down. Plenty of AI projects die right here, before a single line of code.

⚙️ Then the real work begins

Once those foundations are in place, you build. And now we're not talking minutes. We're talking hours, days, sometimes weeks to get a pipeline that ticks every box:

it works end to end — not just on the demo example;
it survives updates — the model changes, the API shifts, a dependency breaks, and it keeps running;
it's documented, so that in six months you still understand what you built;
it handles the unexpected instead of crashing on the first surprising input.

That pipeline — robust and maintainable — is what costs money. Not the prompt. Not the button. The invisible engineering around it.

🔧 An example I live every week

Let me be concrete, with one of my own systems.

I wanted my inbox to sort itself: every incoming message filed into the right folder, the real topics surfaced, the noise pushed aside. On paper, "an AI that sorts my email" is the perfect thirty-second-demo pitch.

In reality:

First I had to define my categories — not ten vague ones, but precise rules. What counts as "urgent"? What gets archived? Where's the boundary? No AI guesses that for you: it's your judgment that has to be written down.
I had to look at my data: years of heterogeneous email, recurring senders, improbable formats. Clean, sample, understand the weird cases.
I had to document the process I'd been doing by hand for years without even noticing.
Then I built the pipeline. Several evenings. Failures. False positives to correct. A model that changes behavior after an update and has to be re-tested.

Today? It runs on its own. I spend a few minutes a week keeping an eye on it. The gain is real, measurable, daily.

But the month a new type of message appeared — a case I hadn't anticipated — the system misfiled it, confidently. I didn't click a "go further" button. I reopened the spec, added the category, re-tested, redeployed. Back, partly, to square one.

That's exactly the AI contract nobody puts on the label.

⏱️ The paradox of "a few minutes a day"

Here's what nobody explains: once the system is built, using it really does take a few minutes a day. It's true. That's the entire point.

On one condition: stay inside the frame you defined at the start.

As long as you ask the system the questions it was designed for, it saves you an enormous amount of time. The day you step outside the perimeter — new data type, new use case, new requirement — you go around the loop again: new spec, new data, new cycle.

The "few minutes a day" isn't a lie. It's just the visible tip of an iceberg someone hid from you.

🧭 Where to actually start

If you want to do this seriously — personally or at a company — here's the order that avoids 90% of the disappointment. None of these steps is technical. That's the whole point.

Write your need as a single testable sentence. Format: "from [input], produce [output], applying [rule], and when in doubt, do [action]." If you can't, your need isn't ready — and neither is the AI.
Inventory your data. Where is it? In what format? Is it clean, current, accessible? An honest afternoon of inventory saves you weeks of illusion.
Document the process by hand first. Do the task yourself five times, writing down every decision. That document is the real specification. AI only automates what you managed to describe.
Define the frame — and especially the out-of-frame. Put in writing what the system will NOT do. That boundary is what protects your reliability.
Pick one narrow use case to start. Not "all of my accounting." One ticket. One category. One document type. You expand after the foundation holds.
Plan for maintenance from day one. Who re-tests when the model changes? Where are the docs? An unmaintained pipeline isn't an asset — it's sleeping debt.

Do those six steps, and you'll already know, on your own, "how fast."

🎣 Why so much of it feels like bait

I don't think people are lying. I think they show the finish line without showing the race.

You get a bit of text, a few hints, a button that says "go further." It's seductive, it looks true, and it sells a genuine skill. I understand the move — everyone monetizes their expertise, and there's real expertise behind it.

But the essential part gets left out — and it's exactly why this will be expensive: the specification, the data, the processes, the robustness engineering, the maintenance. The work that doesn't fit in a thirty-second clip.

So — how fast?

The real question isn't "how quickly can AI do this?" It's: "how well-defined is my problem, how clean is my data, how written-down are my processes?"

AI isn't slow or fast. It's exactly as ready as you are.

And if this resonates — whether you're curious, skeptical, or in the middle of a project — let's talk it over: a coffee, a conference, or simply the comments below. That real conversation is usually where a need gets framed far better than under any demo. 👇

Originally published at articles.savethemall.eu.

🤖 Written with AI assistance, reviewed and approved before publication. Editorial responsibility: Frédéric Guariento. How it works

AI in the SOC: The Seductive Trap of Automation Without Thinking

Frédéric Guariento — Fri, 28 Aug 2026 18:03:41 +0000

We are living a dangerous moment in cybersecurity. Vendors are flooding the market with AI-powered Security Operations Centers, promising to "eliminate alert fatigue" and "automate threat response" — and enterprises are buying them like lottery tickets, hoping the machine will do the thinking for them.

But here is the uncomfortable truth: most of these deployments are not solving the SOC crisis. They are masking it. And in doing so, they are breeding a new generation of analysts who cannot think.

Let me be direct. I have spent years in network security, incident response, and threat intelligence. I have seen the pattern repeat: technology arrives with utopian promises, gets deployed without discipline, and creates more problems than it solves. AI in the SOC is following that exact trajectory. The question is not whether AI can help — it can. The question is whether we are using it as a crutch or a catalyst. Right now, most organizations are choosing the crutch.

The Alert Fatigue Myth (and Why AI Deepens It)

Let's start with the core problem. Modern security tools generate thousands of alerts per day. A typical enterprise SOC drowns in noise. The human analyst, exhausted and deskilled, clicks through dashboards, dismisses 99% of alerts without reading them, and misses the one that matters.

The vendor pitch is simple: AI will filter the noise for you.

What actually happens is more insidious.

When you deploy an AI-driven alert triage system, you hand the classification problem to a black box. The model learns patterns from historical data — mostly false positives, because that is what fills the logs. So the AI becomes very good at recognizing false positives. It suppresses them. Alerts drop from 5,000 per day to 500.

The analyst feels relief. The SOC director reports "70% reduction in alert volume" to the board. Everyone celebrates.

But what has actually changed? The underlying security posture has not improved. The tools are still misconfigured. The baselines are still wrong. The logging is still noisy. What has changed is that the analyst no longer sees the problem. The AI has built a wall between them and the reality of their infrastructure.

And then, when a sophisticated attacker comes — one that does not match the training data — the system fails silently. Not because the alert was not generated, but because the analyst, now accustomed to trusting the AI's filtering, no longer has the muscle memory to read an alert critically. They have outsourced their judgment.

This is skill atrophy in real time.

The False Positive Trap: Why AI Amplifies What It Claims to Solve

Here is another layer. False positives are not random noise — they are signals of misconfiguration. When your IDS generates 200 alerts per day on port 443 traffic, that is not a detection problem. That is a tuning problem. The alert is telling you something: your rule is too broad, your baseline is wrong, or your environment has changed.

A human analyst, forced to triage those 200 alerts, would eventually ask: "Why are we seeing this every day?" They would escalate to the engineering team. Rules would be tuned. The baseline would be refined. Over time, alert quality would improve.

An AI system does something different. It learns that port 443 traffic at 2 AM is "normal" and suppresses it. The underlying misconfiguration persists, invisibly. The analyst never discovers it. The next time an attacker uses port 443 — which, let us be honest, is often — the AI has already taught itself that this is benign.

The paradox: the system that claims to reduce false positives has actually made them structural. They are no longer visible. They are baked into the model.

Analyst Skill Atrophy: The Quiet Crisis

I want to be clear about what I mean by skill atrophy, because it is not what the tech press usually discusses.

A SOC analyst is not just an alert classifier. A good analyst is a threat hunter, a pattern recognizer, a systems thinker. They understand their infrastructure. They know what normal looks like. They can read a log file, spot an anomaly, and trace it back to root cause. They develop intuition.

When you remove the analyst from the alert triage process — when you say "the AI will handle this, you focus on the interesting stuff" — you are actually removing them from the learning loop. They no longer see the baseline. They no longer develop intuition about what is normal in their environment. They become reactive instead of proactive.

Worse, when they do need to intervene, they have lost the foundational knowledge to do it well. I have seen SOCs where analysts cannot manually tune an IDS rule because they have never had to. They cannot read a raw packet capture because the AI has always done the parsing. They cannot estimate the risk of an alert because the AI has always assigned the score.

This is not a small problem. This is the slow hollowing-out of institutional knowledge.

And here is the kicker: the vendors know this. They have built a lock-in mechanism. The more dependent your analysts become on the AI, the harder it is to leave. You cannot suddenly ask humans to do what they have not done in five years. So you are stuck. You are paying for a system that has made you more vulnerable, not less, because you have no alternative.

Where AI Could Actually Help (But Rarely Does)

I do not want to be a pure skeptic here. AI can be valuable in a SOC — but only under specific conditions that most organizations ignore.

First: AI should augment, not replace. The analyst should remain in the loop. The AI should surface candidate patterns, with high confidence and clear reasoning. The analyst should retain the ability to override, to drill down, to question. This is hard to build, which is why vendors do not do it.

Second: AI should be trained on your data. A model trained on generic security data is nearly useless in your environment. Your normal is not someone else's normal. Yet most commercial SOC AI systems are pre-trained on aggregated threat intelligence. They are solving a generic problem, not your problem.

Third: AI should be transparent. You should understand why an alert was suppressed or escalated. If the system cannot explain itself, you cannot trust it, and you cannot learn from it. But transparency is expensive, and it does not scale well, so most vendors skip it.

Fourth: AI should improve your processes, not hide your problems. A good AI system should help you identify misconfigured rules, refine baselines, and reduce alert volume at the source. Instead, most systems just suppress the noise.

When I see a SOC deploying AI under these conditions — with human oversight, local training, transparency, and a focus on process improvement — I am optimistic. I have not seen it often, but it is possible.

The Real Question: What Are We Optimizing For?

Here is what I think is really happening, and why I am concerned.

SOC budgets are constrained. Analyst salaries are high. Burnout is real. Vendors see an opportunity: promise to replace analysts with AI. Executives see an opportunity: reduce headcount without admitting it. Analysts see a trap: learn to depend on the system or lose your job.

Everyone is optimizing for the appearance of solving the problem, not the problem itself.

The real solution — the one that actually reduces risk — is harder and more expensive:

Invest in analyst training and retention. Pay them well. Give them time to learn. Build a culture of continuous improvement. This is not scalable. It does not look good in a PowerPoint. It does not generate vendor revenue. So no one does it.
Fix the underlying data quality. Stop generating false positives by tuning your tools, refining your baselines, and understanding your infrastructure. This requires discipline and patience. It takes months. There is no quick win. So no one does it.
Use AI as a tool within a human-centered process. Let analysts use machine learning to detect patterns they could not see manually. But keep humans in charge of judgment, prioritization, and strategy. This requires building systems that are explainable and contestable. It is harder than black-box optimization. So most vendors do not do it.

Instead, we are doing what is easy: deploying opaque AI systems, hoping they will magically solve the problem, and then wondering why our security posture has not improved.

What This Means for You

If you are building or managing a SOC, here are the hard truths:

Do not buy AI-powered alert triage as a substitute for good tuning. If your baseline is noisy, AI will hide the noise, not fix it. Fix the noise first.

Do not assume that automation means you can reduce analyst headcount. Good SOCs need more thinking, not less. Automation should free analysts to do deeper work, not eliminate the work itself.

Do not trust a system you cannot understand. If the AI cannot explain why it suppressed an alert, you cannot learn from it. Demand transparency. If the vendor cannot provide it, walk away.

Do invest in your people. An analyst who understands their infrastructure, who can think critically about risk, who can trace an attack from indicator to impact — that person is irreplaceable. Do not let them atrophy. Do not let the tool do their thinking for them.

Do treat AI as a catalyst, not a crutch. Ask: does this system help my analysts think better, or does it let them think less? If the answer is the latter, you are moving in the wrong direction.

The Uncomfortable Conclusion

We are at a moment where the technology is moving faster than our wisdom about how to use it. The vendors are smart. The marketing is seductive. The promise of automation is real. But the trap is also real: the false sense of security that comes from delegating judgment to a system you do not fully understand.

The SOC of the future will not be one where AI has replaced human thinking. It will be one where humans and machines work together, with humans firmly in control of judgment and strategy, and machines handling the scale and speed that humans cannot match.

That future requires discipline, investment, and honesty about what we do not know. It is not as exciting as the vendor pitch. It will not generate headlines. But it is the only path to real security.

The question is: are we willing to take it?

The conversation starts here. What is your experience? Have you seen AI in the SOC used well? Or have you watched it become a crutch? I want to hear from practitioners who have lived this tension.

Originally published at articles.savethemall.eu.

🤖 Written with AI assistance, reviewed and approved before publication. Editorial responsibility: Frédéric Guariento. How it works

Dark Factories Are a Myth—But the Real Automation Story Is More Complex

Frédéric Guariento — Fri, 28 Aug 2026 18:03:09 +0000

When you write about the future of work, "dark factories" — automated warehouses and manufacturing plants running 24/7 with minimal human presence — become an easy reference. I've used the term myself in talks about AI-driven displacement. It's a vivid, urgent image: robots working in the dark while humans sleep, jobs evaporating overnight.

But last month, I decided to stop citing it without interrogating it. What I found was uncomfortable: the narrative is real, but the evidence is thinner than the hype.

The Problem with Borrowed Authority

Let me be direct. I've written about dark factories as a harbinger of mass unemployment. The concept appears in my talks on automation and the future of work. But when I tried to pin down where the numbers come from, I hit a wall.

A "dark factory" is not a standardized term. There's no registry of them. The companies running them — Siemens, Trumpf, some automotive suppliers — don't publish detailed employment data tied to specific facilities. Trade press coverage exists, but it's often breathless and promotional rather than investigative.

The most-cited examples are real: Siemens' Amberg facility in Germany, which has run with minimal night-shift workers for decades. But Siemens is also one of the largest employers in Germany. That one factory is not representative of an industry transformation.

What I found instead was a pattern I recognize from other tech narratives: a kernel of truth, amplified by repetition, divorced from context, and then treated as inevitable.

What Dark Factories Actually Are (and Aren't)

Let's separate fact from extrapolation.

What is real:

Highly automated manufacturing and logistics hubs exist. Companies like Amazon, DHL, and major automotive suppliers have invested heavily in robotic systems that reduce the need for night-shift human labor. Some facilities do operate with skeleton crews or 24/7 autonomous processes.

The economic logic is sound: labor in developed economies is expensive; robots don't demand breaks, healthcare, or overtime. For repetitive, high-volume tasks — picking, packing, welding, assembly — automation makes financial sense.

What is speculative:

The claim that dark factories represent a significant, measurable portion of global manufacturing or logistics. I found no credible data suggesting that "dark factories" employ a meaningful percentage of the workforce or that they are displacing workers at the scale implied by the rhetoric.

A 2023 report from the International Federation of Robotics (IFR) shows that industrial robot installations are growing, yes — but the growth is concentrated in a handful of sectors (automotive, electronics, food) and geographies (China, Germany, Japan, South Korea). Even in those sectors, robots augment rather than replace entire workforces. The factories are not dark; they have people managing, maintaining, and quality-checking the machines.

The World Economic Forum's "Future of Jobs" reports, which I've cited, do predict significant job displacement from automation. But they don't single out "dark factories" as the primary mechanism. They point to broader digital transformation, AI, and process automation — which is different from the specific image of unmanned factories.

Why the Myth Persists (and Why I Perpetuated It)

The dark factory narrative is seductive because it is visually compelling and emotionally urgent. It's easier to imagine a future where robots work in silence than to explain the messy reality: gradual automation, skill shifts, uneven impact across regions and sectors, and the stubborn persistence of human labor in places we'd expect it to be automated away.

For someone like me — someone who writes about technological disruption and societal risk — the dark factory is a useful metaphor. It crystallizes anxiety. It makes the abstract concrete.

But metaphors are not data. And when you're trying to persuade people to act on policy, education, or investment, the difference matters.

I also suspect that journalists, consultants, and academics (myself included) have been lazy. We cite "dark factories" because others have cited them. We trust the framing because it aligns with our thesis. We don't dig into the source.

What the Data Actually Shows

Here's what I found when I looked harder:

Robot density is increasing, but unevenly. The IFR reports that industrial robot density (robots per 10,000 manufacturing workers) is highest in South Korea (~932), Singapore, Germany, and Japan. It's much lower in the US (~376) and lower still in Europe overall. China is investing heavily but still has lower density than developed economies. This suggests that automation is not uniform and that labor remains central to manufacturing even in high-tech facilities.

Employment in manufacturing hasn't collapsed. In developed economies, manufacturing employment has declined, yes — but the decline predates modern robotics and is driven by offshoring, deindustrialization, and shifts in consumer demand. Within factories that have invested in automation, employment has often stabilized rather than disappeared. Jobs have changed (more technicians, fewer assembly-line workers), but the facilities haven't gone dark.

Logistics is the real automation frontier. Amazon's warehouses, which are often cited as dark-factory precursors, still employ hundreds of thousands of people. They use robots to move shelves and assist picking, but humans still do the fine-motor work and problem-solving. Amazon's own data shows that in facilities with robots, they've added workers, not subtracted them. The economics of scale require volume, and volume requires people.

Night-shift work hasn't disappeared. In fact, 24/7 operations have increased demand for shift work in many sectors. The shift has been from manufacturing night shifts to logistics, healthcare, and service-sector night shifts. The jobs are different, but the labor is still there.

The Uncomfortable Truth

The uncomfortable truth is this: automation is real, displacement is real, and the future of work is genuinely uncertain. But the mechanism of displacement is not dark factories. It's more diffuse, more gradual, and harder to visualize.

Displacement happens through:

Skill obsolescence (the truck driver whose route is optimized by AI)
Wage suppression (the worker competing with cheaper offshore labor and automation)
Sectoral shift (manufacturing jobs lost; service jobs gained, often at lower pay)
Geographic concentration (some regions adapt; others don't)
Credential inflation (the job that once required a high school diploma now requires a degree)

These are harder to write about. They don't fit into a single image. They require nuance, regional data, and acknowledgment of complexity.

But they're also where the real policy action is needed.

What I'm Doing Differently

I'm retiring "dark factories" from my standard vocabulary. Not because they don't exist, but because I can't cite them with confidence, and I've been using them as a rhetorical shortcut.

Instead, I'm committing to:

Specificity over metaphor. If I cite automation, I cite the IFR data or company reports. If I discuss displacement, I reference labor statistics and sector-specific studies, not vague warnings.
Naming my sources. When I make a claim about the future of work, I'll say where it comes from: a study, an interview, an observation — or I'll say "this is speculative."
Distinguishing between what is and what might be. The dark factory might happen at scale. But it hasn't yet. I need to say that clearly.
Acknowledging where I'm wrong. I've been part of amplifying a narrative without sufficient evidence. That's a failure of intellectual rigor, especially from someone writing about technology's societal impact.

The Broader Lesson

This matters beyond dark factories. We live in an era where urgent narratives about technology circulate faster than evidence. AI will destroy jobs. Blockchain will decentralize everything. Quantum computing will break all encryption. Dark factories will eliminate work.

Some of these may be true. But we won't know if we treat them as axioms rather than hypotheses.

The capacity to innovate and think creatively is important. But so is the discipline to say: "I don't know yet. Let me check. I was wrong."

For those of us writing about technology's future, that discipline is not optional. It's foundational.

The work ahead is urgent. But urgency without rigor is just noise.

What's your experience with automation in your sector? Have you seen the dark factory narrative in practice, or have you found the reality different? I'd genuinely like to hear where the evidence points in your field.

Originally published at articles.savethemall.eu.

🤖 Written with AI assistance, reviewed and approved before publication. Editorial responsibility: Frédéric Guariento. How it works

What It Actually Takes to Run Your Own AI: One Consumer GPU, a Routed Model Mesh, and $100 a Month

Frédéric Guariento — Fri, 28 Aug 2026 18:02:37 +0000

Every "local AI vs cloud" article I've read shares one quiet feature: the author never touched the hardware they describe.

They quote NVIDIA A100s at €15,000 each. They build €60,000 GPU "nodes." They add "0.5 FTE of staffing," AWS SageMaker line items, €36,000 a year. The numbers are clean, the tables are tidy, and the whole thing is fiction — generated from training data by people benchmarking a spreadsheet they invented.

I want to do the opposite: show you the real system. What I run, how it's wired, what it costs, and the discipline that keeps it cheap. It's less glamorous than a fantasy datacenter. It's also something you could actually build.

The Hardware: One Card, Doing Everything

The "AI infrastructure" is a single consumer graphics card. An RTX 4070 Ti. 12 GB of VRAM. Around €800, bought as a general-purpose GPU.

There's no rack and no A100. That card lives inside a bare-metal host that is also running dozens of other containers. Zoom out and the whole homelab is 35 stacks and roughly 100 Docker containers spread across three machines — a GPU box, a second Docker host (vm-docker), and a NAS. The AI doesn't get a dedicated palace. It shares the building with everything else I self-host.

The Wall Nobody Shows You

Here's what those local models actually do on 12 GB of VRAM — real ollama --verbose generation speeds, measured this week:

Model	Size	Speed	Fits 12 GB?
Llama 3.2 (3B)	2.0 GB	152 tok/s	✓ easily
Mistral 7B	4.4 GB	98 tok/s	✓
Llama 3.1 (8B)	4.9 GB	84 tok/s	✓
Qwen2.5-Coder (32B)	19 GB	3.9 tok/s	✗ spills to CPU

Read the last row twice, because it governs everything.

The 32-billion-parameter model — the impressive one on every capabilities chart — runs at 3.9 tokens per second. Roughly one word every two seconds. Unusable for anything interactive. The 8B model on the same card is 20× faster.

Why? The 32B needs 19 GB; I have 12. The instant a model overflows VRAM, it spills into system RAM and CPU and falls off a cliff. This is the VRAM wall, and it's the single fact the fantasy benchmarks paper over. On a 12 GB consumer card your real ceiling is 8B-class. You don't buy past it with patience — you buy past it with VRAM.

Which is exactly why the next hardware step is a 24 GB RTX 3090, bought opportunistically second-hand. Not for prestige — to move that 32B model from 3.9 tok/s to genuinely usable, and pull more of the mesh back in-house. The whole upgrade is a response to one measured number.

So I Don't Run a Model. I Route a Mesh.

This is the part the "local vs cloud" framing misses entirely. The question was never which one. It's which job goes where.

A small proxy — LiteLLM — sits in front of everything and routes each request to the cheapest box that can do it well:

Job	Goes to	Why
Bulk reasoning, drafts, classification	DeepSeek V3 (cloud API)	~$0.27 per million input tokens — cents where frontier charges dollars
Step-by-step reasoning	DeepSeek R1	replaced my local 7B reasoner — faster and cheaper than running it myself
Long context / code	Kimi K2 (Moonshot, 262k context)	holds an entire codebase or book in one prompt
Needs to be fast	Groq (Llama 3.3 70B)	absurd throughput when latency matters
Hard reasoning, the actual writing	Claude	the 5% that has to be genuinely good
Private / offline / high-volume	Local Ollama (Llama 3.1 8B, nomic-embed)	never leaves the building; zero marginal cost

And it's not just routing — it's failover. The config has explicit fallback chains: if DeepSeek's API is down, the request drops to a local model; if the local model can't carry it, it escalates to Claude. Embeddings and the private RAG path have no silent fallback at all — if the retrieval service is down, the system errors out rather than quietly answering without sources. That's a deliberate security choice, not an accident.

That's the real answer to "local or cloud": neither — a routed mesh, chosen per task, with the cheap options first and the expensive ones held in reserve.

The Cost Has Two Regimes, Not One

Here's where the fabricated €36,000/year falls apart completely. My AI spend lives in two buckets:

1. A flat subscription for interactive work. The heavy agent sessions — the ones writing code, refactoring, driving the homelab — run on a $100/month flat Claude plan. Not metered. Ten requests or ten thousand, same bill. I did not spend $3,000 on API calls; that sentence describes a pricing model I don't use.

2. Pay-per-million credits for the pipelines. Everything automated — document OCR, email triage, RAG, the article generator you may be reading right now — runs through the mesh on DeepSeek and Kimi API credits. And the unit here is the million tokens. DeepSeek V3 is around $0.27 per million in, ~$1.10 out. The pipelines cost single-digit dollars a month. Local inference on the GPU costs a fraction of a cent per answer in electricity, on a card that idles at 8 W.

So the honest total for a working, daily-use AI stack is: one flat subscription, a handful of dollars in API credit, and a few euros of power. The fantasy benchmark wasn't just wrong on the numbers — it modelled the wrong animal: a corporation replacing a cloud contract, instead of one person assembling more capability than a 2020 enterprise had, for less than a phone plan.

The 5-Hour Problem (and the Console That Fixes It)

A flat plan has a catch: a rolling usage window. Push hard enough in a session and you hit the limit, and the interactive agent goes quiet for a while.

That used to mean I was blocked. Now it doesn't. An OpenWebUI console sits on top of the same LiteLLM mesh, so when the Claude window is spent, I keep working — the same prompts route straight to the DeepSeek and Kimi credits instead. The flat plan handles the bulk; the pay-per-million mesh absorbs the overflow. This handoff is the piece I'm actively wiring now, and it's the difference between "blocked until the window resets" and "never fully blocked."

That's the real resilience story. Not redundant A100s. A second front door onto a cheaper set of models.

Compression: Spending Fewer Tokens on Purpose

Cheap models still reward discipline, and a lot of the optimization is simply not spending tokens you don't need to — on both ends:

Input side: prompt caching (a caching proxy in front of Claude so repeated context isn't re-billed every call), and compressed memory files — the long instruction and context files the agents load get squeezed to a denser form that says the same thing in far fewer tokens.
Output side: terse-by-default response modes that strip filler, articles, and pleasantries — easily a 50–75% cut in output tokens for the same information, which on a per-million meter is real money and, locally, real watts.

In/out compression isn't a gimmick. On metered models it's the bill; on the local GPU it's the power draw and the latency. Same lever, three payoffs.

The Actual Job: Harden, Optimize, Reduce

None of this was designed once and left alone. The real work is a loop, and every iteration has the same three verbs:

Harden — tighten what's exposed, remove silent fallbacks where a wrong-but-confident answer is dangerous, keep private data on private paths.
Optimize — better routing, more caching, the right model for each job instead of the biggest model for every job.
Reduce consumption — schedule heavy jobs off-peak (some providers are markedly cheaper at off-peak hours), push non-urgent work to CPU so the GPU can sleep, wake the GPU on demand instead of idling it hot, and organize tasks so the machine does less to deliver the same result.

That loop is the system. The hardware is almost incidental. What makes it work is treating a closet like infrastructure: measure, route, cache, schedule, repeat.

Where This Is Heading (Stated as Intent, Not Fact)

I'll be precise about the difference between what runs today and what I'm aiming at — because blurring the two is how these articles turn into fiction.

What's planned: the 24 GB RTX 3090 to break the VRAM wall and pull more of the mesh in-house; finishing the OpenWebUI handoff so the 5-hour overflow is fully automatic; and a longer-term move toward a dedicated GPU host so the AI stops sharing a card with everything else.

What I'm still questioning: there's a whole shelf of heavier orchestration — agent frameworks, long-running autonomous daemons, multi-agent "swarm" tooling. The honest answer is I haven't deployed them, and I'm not convinced they earn their place here yet. On a single 12 GB card, a long-running multi-agent framework competes for the exact VRAM my real workloads need. The bar isn't "is it impressive" — it's "does it earn its VRAM and its complexity against what I already get from a simple routed mesh." So far, for a solo operator, the simple mesh keeps winning. That may change when the 3090 lands. I'll measure it, not assume it.

That's the discipline: name the destination, but never describe it as if you'd already arrived.

What This Actually Proves

Strip away the spec sheet and here's what's left.

A complete, sovereign, mostly-private AI stack — one that classifies my documents, searches my archives, transcribes recordings, triages my inbox, runs retrieval over my own corpus, and drafts my work — runs on a single gaming GPU, a routed mesh of cheap-and-frontier models, one flat subscription, and a handful of dollars in credit. It lives in a closet next to 100 other containers. And it gets cheaper and tougher every iteration, by design.

That's the story the fantasy benchmarks hide, probably without meaning to. The frontier of AI automation isn't the hyperscaler datacenter with its €60,000 nodes. It's the collapse in the cost of doing real work — the capability that needed an enterprise budget in 2020 now needs a hobbyist's, plus the discipline to wire it well.

When automation lived in a megacorp datacenter, you could at least see it coming. The next wave doesn't have a datacenter. It has a fan, 12 GB of VRAM, a routing table, and a $100 subscription. It's already running.

Run by a practitioner, on real hardware, with measured numbers. If you're building something similar — a routed model mesh, a sovereign homelab, a cheaper way to do serious AI work — **contact me. Happy to compare notes and share what I've learned.**

Originally published at articles.savethemall.eu.

🤖 Written with AI assistance, reviewed and approved before publication. Editorial responsibility: Frédéric Guariento. How it works

After NEXUS: Three Books That Reshaped How I Read AI

Frédéric Guariento — Fri, 28 Aug 2026 18:01:31 +0000

Have you noticed how we talk about artificial intelligence as though it were a single coherent force, rather than a collision of incompatible ideas, economic interests, and philosophical traditions? I spent years absorbing technical papers and vendor whitepapers, convinced that deeper understanding of neural networks or transformer architectures would clarify the stakes. Then I read Blake Blake's NEXUS, and realised I had been reading the wrong literature entirely.

That book — which traces how connectivity itself rewires human cognition, from writing to the internet — cracked open something I'd been missing: AI isn't a technology problem. It's a social one. The algorithms matter less than the power structures they embed. And once you see that clearly, three other books become essential reading, not as supplements to technical knowledge, but as corrections to it.

The first is Yuval Noah Harari's Sapiens. I know, I know—it's been on every LinkedIn influencer's shelf for a decade. But most people read it for the narrative sweep, the story of how humans conquered the world. What I needed from it, and what I finally understood after NEXUS, was something else: the observation that large-scale cooperation depends on shared myths. Money is a myth. Nations are myths. The idea that humans are inherently rational is a myth. So when we deploy AI systems at scale—when we ask algorithms to make decisions about credit, hiring, criminal justice—we're not implementing neutral logic. We're encoding myths about human worth, economic value, and social order into machines, then hiding behind claims of objectivity. Harari shows that this sleight of hand is ancient. Recognising it in AI requires seeing how myths have always driven human societies, long before we had neural networks to blame for our choices.

The second is Cathy O'Neil's Weapons of Math Destruction. This one is more direct: it's a catalogue of how algorithmic systems, even well-intentioned ones, amplify inequality and lock people out of opportunity. What struck me most was not the examples—they're damning and necessary—but her argument that the power asymmetry is structural. We deploy algorithms without understanding them, without consent from those affected, and without meaningful accountability when they fail. And because they're opaque, people can't fight back the way they could against a human decision-maker. O'Neil is writing about the governance problem, not the technical one. And that's the conversation we're not having loudly enough. We debate whether AI is "safe" or "aligned," as if safety were a property of the code rather than a question of who controls it and for what purpose.

The third is Bruno Latour's We Have Never Been Modern. This is the hardest of the three, and the one I return to most often. Latour argues that our entire intellectual tradition rests on a false divide: nature versus culture, science versus politics, fact versus value. We pretend we can separate them, keep them in different boxes. But we can't. Every scientific fact is entangled with social interests. Every technology embeds politics. And when we build AI systems, we're not separating intelligence from values—we're weaving them together, then claiming we've done something neutral. Latour's insight is that we need to stop pretending. We need to acknowledge that every system we build is a hybrid, a mixture of the technical and the social, and we need to govern it as such. No amount of alignment research will change that fundamental truth. What changes is whether we admit it.

These three books sit uneasily together. Harari is a historian, O'Neil a data scientist turned critic, Latour a philosopher of science. But they converge on a single point: the AI crisis is not about intelligence. It's about power, myth, and the stories we tell ourselves about objectivity. If you're reading only technical literature on AI—papers on scaling laws, constitutional AI, mechanistic interpretability—you're missing the essential context. You're reading as though the problem were solvable by engineering alone.

That doesn't mean the technical work is irrelevant. It means it's insufficient. We need both: people who understand the mathematics deeply enough to ask hard questions about what systems actually do, and people who understand the social consequences well enough to demand accountability. We need engineers who read Latour. We need policymakers who understand neural networks. And we all need to stop pretending that AI is a neutral tool waiting to be "aligned" by the right incentive structure.

The uncomfortable truth these three books converge on is that alignment is not a technical problem we can solve and move on from. It's a permanent tension between what systems can do and what we collectively decide they should do. That tension requires ongoing negotiation, not a final solution. It requires admitting that every choice we make about how to build and deploy AI is a choice about what kind of society we want to live in.

Which is why I keep returning to them. Not because they give me answers, but because they ask the right questions.

Have you read any of these? What's shifted in how you think about AI after encountering work that challenges the technical frame?

Originally published at articles.savethemall.eu.

🤖 Written with AI assistance, reviewed and approved before publication. Editorial responsibility: Frédéric Guariento. How it works

Building Your Own Sovereign CVE Watch: An OpenCVE Field Report

Frédéric Guariento — Fri, 28 Aug 2026 18:01:27 +0000

How many times this week have you learned about a critical vulnerability from a vendor newsletter, a Twitter thread, or a Slack message from a colleague—hours after it went public? And how many of those alerts were noise, commercial pressure, or simply irrelevant to your actual infrastructure?

The vulnerability intelligence game has become a game of noise. Every vendor wants to sell you their feed. Every security platform wants to own your threat perception. Every incident response consultant wants to monetize your fear. Meanwhile, your actual risk—the specific software running on your specific machines, in your specific context—drowns in the flood.

This is not a technical problem. It is a sovereignty problem.

I have spent the last few months building and refining an OpenCVE instance on modest hardware: a single RTX 4070 Ti homelab, running alongside 34 other Docker containers, no dedicated infrastructure, no cloud bill. The exercise revealed something uncomfortable: the difference between having vulnerability data and owning your vulnerability perception is not a scale problem. It is a control problem.

Why does this matter? Because the moment you outsource CVE intelligence to a platform you do not run, you outsource your threat model. You accept someone else's definition of "critical." You inherit their blind spots. You become dependent on their uptime, their API rate limits, their pricing decisions. In cybersecurity, dependency is risk.

Let me walk through what changed when we stopped consuming and started owning.

The Problem with Curated Feeds

Vulnerability feeds exist on a spectrum. At one end: raw NVD data, unfiltered, thousands of entries per day, 95% noise for any given organization. At the other: vendor-curated feeds, which promise relevance but deliver what the vendor believes is relevant—which is often what the vendor sells you tools to fix.

CVSS scores are not risk scores. A 9.8 vulnerability in software you do not run is not a risk. A 5.5 in your core infrastructure is. Yet every commercial feed treats these with the same urgency.

OpenCVE changes the premise. It is a self-hosted vulnerability database that ingests NVD, GitHub Advisories, and other sources, then lets you define what matters. Not through a UI checkbox—through code, automation, and explicit policy. Your rules. Your context. Your risk model.

The moment I could write a filter that said "alert me only on CVEs affecting PostgreSQL, Python, or Docker, and only if they score above 7.5 and we run that version," the noise dropped by 80 percent. Suddenly, the remaining alerts were not alerts—they were actionable intelligence.

But here is the uncomfortable part: that clarity requires you to know what you are running. Not vaguely. Not "we use Docker." Specifically: Docker 24.0.6, running on Debian 12.1, with these kernel versions, these Python packages. If you cannot articulate your inventory, no CVE watch will save you. The tool exposes the gap.

Ownership Changes Behavior

Running your own CVE watch forces a conversation your organization has probably been avoiding. What actually matters to us? What is our risk appetite? What do we run, and why? What can we patch, and what cannot?

I have watched teams discover, through OpenCVE, that they are running seventeen versions of the same library across their infrastructure—some patched, some not. I have watched others realize that their "critical" application depends on an unmaintained package from 2019. These are not new problems. They are old problems that commercial feeds let you ignore because the feed is someone else's job to manage.

When you own the watch, you own the inventory. When you own the inventory, you can own the risk.

The operational rhythm changes too. Instead of reactive "a vulnerability was announced, let me check if we are affected," you shift to proactive "here is our vulnerability surface, here is our patch cadence, here is our risk tolerance." You move from incident response to risk management.

This does not require enterprise hardware. My instance, running on a single GPU with a few CPU cores, ingests the full NVD, processes it through custom filters, and delivers a weekly digest to our team. The latency is acceptable. The cost is negligible. The control is absolute.

The Sovereignty Angle

Here is what keeps security leaders awake: if your vulnerability intelligence comes from an external platform, so does your threat perception. If that platform goes down, gets acquired, changes its pricing, or pivots its business model, you are affected. If it is compromised, you are exposed. If it is in a jurisdiction with different data governance rules, you inherit those rules.

Europe has been talking about digital sovereignty for a decade. Most of that talk is vague and political. But vulnerability intelligence is concrete: do you control the data that defines your security posture, or do you rent it?

OpenCVE is not the only open-source CVE tool, but it is the only one I have found that is genuinely self-hostable, genuinely low-overhead, and genuinely designed for the question "what if I want to know, on my own terms, what vulnerabilities matter to me?" The answer is: you can. Not in six months. Not with a dedicated team. Now.

The trade-off is real: you lose the convenience of a managed service. You gain the clarity of owning your threat model. You lose the vendor's curated intelligence. You gain the ability to ask questions the vendor never thought to answer.

For organizations serious about cybersecurity—not compliance theater, not vendor checkbox ticking, but actual risk management—that trade-off is not even close.

What Comes Next

I am evaluating integration with Wazuh for automated response and Falco for runtime threat detection, so that CVE intelligence feeds directly into your detection layer. Not yet deployed—the pieces exist, but the orchestration is still being tested. The vision is straightforward: your vulnerability watch becomes part of your threat model, not separate from it.

The vulnerability landscape will not get simpler. Vendors will not stop selling you fear. Noise will not decrease. But you can choose not to be a passive consumer of someone else's interpretation of that noise.

The question is not whether you can afford to build this. It is whether you can afford not to.

What is your organization's single biggest blind spot in vulnerability management? Is it inventory, patching speed, or something else entirely? I am curious what friction points teams hit when they try to move from reactive alerts to proactive risk ownership.

Originally published at articles.savethemall.eu.

🤖 Written with AI assistance, reviewed and approved before publication. Editorial responsibility: Frédéric Guariento. How it works

Harvest Now, Decrypt Later: Why Post-Quantum Cryptography Can't Wait

Frédéric Guariento — Fri, 28 Aug 2026 18:00:59 +0000

The scenario sounds like science fiction. Adversaries are right now harvesting and storing encrypted data they cannot yet read—banking transactions, state secrets, medical records, intellectual property—betting that quantum computers will eventually break today's encryption. They're playing the long game, and they're winning because most of us are still pretending this isn't happening.

This isn't theoretical anymore. This is a live threat unfolding in real time, and if you're responsible for security infrastructure, you need to act today, not when quantum computers arrive.

The Harvest Now, Decrypt Later Reality

Let me be direct: if your organization handles sensitive data with a lifespan beyond five to ten years, you're already exposed. Here's why.

The mathematics underpinning RSA and elliptic curve cryptography—the algorithms protecting everything from your SWIFT transfers to your healthcare records—remain secure against classical computers. A 2048-bit RSA key would take conventional supercomputers thousands of years to crack. That's not a weakness; it's by design.

But quantum computers operate differently. A sufficiently powerful quantum computer running Shor's algorithm could break RSA-2048 in hours. The timeline remains uncertain—estimates range from ten to thirty years—but uncertainty is precisely the problem.

Adversaries aren't waiting. Nation-states and sophisticated threat actors are systematically collecting encrypted traffic today. They're storing it in vast repositories, betting that the decryption keys of tomorrow will unlock the secrets of today. This isn't paranoia. The U.S. National Security Agency has already warned that foreign intelligence services are harvesting encrypted data now for future decryption.

Your sensitive data has a "harvest window." If it's still valuable in ten years—and most organizational data is—you're vulnerable.

Why Your Current Security Team Isn't Ready

I've worked in security operations long enough to recognize the pattern. Organizations excel at addressing immediate threats. A vulnerability drops, patches deploy within days. A breach occurs, incident response activates. Quantum computing threats are different. They're not immediate, not visible, and not yet causing tangible business damage.

This creates a dangerous gap in urgency.

Most security teams are stretched thin managing firewalls, SIEM platforms, threat intelligence feeds, and compliance audits. Post-quantum cryptography (PQC) feels abstract. There's no dashboard showing quantum risk. No alerts firing. No breach headlines (yet) attributable to harvest-now-decrypt-later attacks. So it gets deprioritized.

But here's the uncomfortable truth: your cryptographic inventory is likely a mess.

When was the last time you audited every encryption algorithm running across your infrastructure? Do you know which systems use RSA-2048 versus stronger variants? Can you identify all the places where elliptic curve cryptography is deployed? What about legacy systems running decades-old encryption standards? Most organizations can't answer these questions with confidence.

And if you can't see your cryptographic footprint, you can't protect it.

The Technical Landscape Shift

NIST's post-quantum cryptography standardization process—concluded in 2022 with the selection of four finalists—marks a genuine inflection point. ML-KEM (Kyber), ML-DSA (Dilithium), SLH-DSA (SPHINCS+), and Falcon represent the cryptographic future. They're designed to resist both classical and quantum attacks.

But standardization and deployment are different animals.

Integrating PQC into production systems is not a patch-and-pray exercise. It requires:

Cryptographic agility — The ability to swap algorithms without wholesale system redesigns. Most organizations built infrastructure around specific cryptographic primitives. Changing them means touching TLS stacks, certificate chains, key management systems, and legacy applications that nobody fully understands anymore.

Hybrid approaches — Running classical and post-quantum algorithms in parallel during the transition. This adds computational overhead and complexity. A hybrid TLS handshake using both RSA and ML-KEM consumes more bandwidth and processing power than today's implementations.

Key rotation at scale — Issuing new certificates, rotating keys, and managing the cryptographic lifecycle across thousands of systems. If your organization has struggled with basic certificate management, PQC transitions will expose those weaknesses painfully.

Vendor coordination — Most organizations don't control their entire cryptographic stack. You depend on cloud providers, SaaS platforms, hardware vendors, and open-source libraries. Getting everyone to move simultaneously is like herding cats across an earthquake.

I've overseen infrastructure modernization projects. This is harder than most security leaders realize.

What "Already" Means

The word "already" in this article's title isn't hyperbole. It's a call to immediate action, not distant planning.

Here's a practical timeline:

Now (this quarter): Conduct a cryptographic inventory. Map where encryption lives in your environment—data at rest, data in transit, digital signatures, certificate authorities. Classify by data sensitivity and retention period. You cannot manage what you don't see.

Next two quarters: Pilot post-quantum cryptography in non-critical environments. Test ML-KEM in your TLS implementations. Evaluate performance impact. Identify integration pain points before they become production disasters. Work with vendors to understand their PQC roadmaps.

Next year: Develop a hybrid cryptography strategy. Decide which systems migrate first. Plan certificate authority updates. Begin rotating keys toward post-quantum algorithms in sensitive domains—financial systems, healthcare infrastructure, government-grade security.

2-3 years: Achieve significant PQC coverage across critical infrastructure. This isn't a sprint; it's a structured migration.

The reason for urgency isn't that quantum computers are arriving next month. It's that the migration itself takes years, and you're already behind.

The Compliance and Liability Angle

Here's what keeps security leaders awake: regulatory exposure.

If a breach occurs five years from now—attributed to harvest-now-decrypt-later attacks—and auditors discover you didn't initiate PQC migration when standards were already available, you have a liability problem. Regulators will ask: "Why wasn't this addressed when guidance existed?"

NIST SP 800-131B already recommends transition plans. The European Telecommunications Standards Institute (ETSI) has published PQC guidelines. If you're in financial services, healthcare, or critical infrastructure, your regulators are watching. Non-compliance with emerging cryptographic standards is becoming a governance issue, not just a technical one.

Insurance carriers are starting to ask about quantum readiness in cyber risk assessments. Some are already adjusting premiums. This is no longer a "nice to have" roadmap item.

The Practitioner's Dilemma

I'll be honest about the complexity. Post-quantum cryptography is computationally heavier than classical algorithms. ML-KEM key sizes are larger. Signature sizes grow. Performance penalties exist, especially on resource-constrained devices and embedded systems.

Some organizations will discover that their aging infrastructure simply cannot support PQC without replacement. That's a capital expenditure conversation nobody wants to have right now.

There's also the uncertainty problem. What if NIST's selected algorithms prove vulnerable in ways we haven't anticipated? What if hybrid approaches create unexpected attack surfaces? These concerns are legitimate, but they're also paralysis-inducing. Perfect security doesn't exist. You're managing risk, not eliminating it.

The answer isn't to wait for absolute certainty. It's to move deliberately, test rigorously, and build flexibility into your cryptographic architecture so you can adapt as the landscape evolves.

What You Should Do Monday Morning

1. Inventory your cryptography. Every system, every algorithm, every key. If you can't list it, you can't protect it.

2. Classify by urgency. Which data matters most in ten years? Which systems handle information that remains sensitive long-term? Prioritize those.

3. Engage your vendors. Ask cloud providers, SaaS platforms, and hardware manufacturers about their PQC roadmaps. Hold them accountable. Your security is only as strong as your supply chain.

4. Pilot post-quantum algorithms. Don't wait for perfection. Test ML-KEM in development environments. Measure performance. Learn what breaks.

5. Update your threat model. Include harvest-now-decrypt-later scenarios. Assume adversaries are collecting your encrypted data today. What's the business impact if they decrypt it in 2035?

6. Build cryptographic agility into new projects. Don't design systems around fixed algorithms. Design them to swap algorithms as standards evolve.

This isn't optional complexity. It's the cost of operating in a world where quantum computing is coming, where adversaries are patient, and where your encrypted data has value far beyond today.

The Uncomfortable Truth

We prefer to avoid uncomfortable truths. We'd rather believe that quantum computers are decades away, that our current encryption is sufficient, that someone else will handle this problem. We'd rather focus on the threats we can see—ransomware, phishing, zero-days—than prepare for threats that haven't materialized yet.

But that's exactly why adversaries are harvesting encrypted data now. They're betting on our inertia.

The quantum computing threat isn't science fiction. It's a live operational reality that demands action today. Not next year. Not when quantum computers arrive. Today.

Your encrypted data is being collected right now. The question isn't whether to prepare for post-quantum cryptography. It's whether you'll prepare before or after the decryption starts.

The time to act is now.

What's your organization's current status on post-quantum cryptography? Are you inventorying cryptographic assets, or is this still on the backlog? Share your experience—the practitioner perspective matters more than theoretical debates.

Originally published at articles.savethemall.eu.

🤖 Written with AI assistance, reviewed and approved before publication. Editorial responsibility: Frédéric Guariento. How it works

NIS2 Isn't Compliance Theatre—It's a Liability Shift

Frédéric Guariento — Fri, 28 Aug 2026 18:00:54 +0000

The European Union's NIS2 Directive arrives with the force of a regulation but the clarity of a fog bank. I've spent the last months helping organisations navigate it, and I can tell you: the gap between what Brussels published and what your security team must actually do is enormous.

This isn't a theoretical piece. This is what I'm seeing in real boardrooms, real infrastructure, real budgets right now.

The Deception of "Just an Update"

Here's what most people think NIS2 is: a minor refresh of the original NIS Directive from 2016. Slightly stricter rules. A few more audit requirements. Same game, slightly harder.

Wrong.

NIS2 is a fundamental recalibration of who is responsible for cybersecurity in Europe, and it expands that net far beyond what existed before. The original NIS covered operators of essential services—energy, water, transport, healthcare, finance. Relatively contained. Manageable.

NIS2 doesn't just tighten those rules. It pulls in roughly 150,000 additional organisations across the EU that were previously invisible to regulation. Digital service providers. Cloud infrastructure operators. DNS providers. Managed security service providers. Critical infrastructure manufacturers. Your supply chain, basically.

And that's where implementation gets messy.

What's Actually New (Beyond the Buzzwords)

Let me break down the concrete changes I'm dealing with in the field:

1. The Supply Chain Becomes Your Responsibility

Under NIS, you managed your own security. Under NIS2, you're now accountable for the security posture of vendors you may never directly communicate with.

The directive requires organisations to implement "supply chain risk management." Sounds clinical. In practice, it means:

Audit your critical suppliers (not just ask them to fill a questionnaire)
Document their security controls with the same rigour you'd apply internally
Monitor them continuously, not once every three years
Have contractual teeth: the ability to audit, terminate, or enforce remediation

I've watched CISOs and procurement teams collide over this. Procurement says "We can't audit every vendor." Security says "The regulation says you must." Both are right, which is the problem.

The workaround? Risk-based approach. You audit critical suppliers—those handling sensitive data, controlling infrastructure, or serving as single points of failure. You categorise others. But you document everything. Regulators will ask.

2. Board-Level Accountability Is No Longer Optional

This is the one that genuinely changes behaviour.

Under NIS2, the management body—your board—must now have "cybersecurity expertise" and must actively oversee cyber risk. Not delegate it entirely to the CISO. Not treat it as a line item in an IT report.

Concrete implications:

Your board needs at least one member with demonstrable cybersecurity knowledge (or you hire external expertise)
Board meetings must include cyber risk as a standing agenda item
Incident response decisions require board visibility, not just IT sign-off
Directors can face personal liability if the organisation fails to implement reasonable security measures

I've seen boards react to this in two ways. Some panic and hire a "cyber expert" director who then rubber-stamps whatever the CISO proposes. Others actually engage—ask hard questions, challenge assumptions, demand evidence. The second group gets better security outcomes.

3. Incident Reporting Becomes Forensic, Not Bureaucratic

The original NIS required you to report "significant incidents" within a certain timeframe. Vague. Interpreted loosely across Europe.

NIS2 defines incidents with surgical precision and requires reporting within 24 hours of detection—not 24 hours of deciding it's significant. The clock starts ticking the moment your monitoring tools flag something.

What counts? The directive lists specific criteria: impact on availability, integrity, confidentiality, or business continuity. But here's the trap: you must report if you reasonably believe an incident meets those criteria, even if you're not certain yet.

So you're reporting incomplete investigations. Regulators understand this. But it means your incident response process needs to be built for parallel tracks: immediate notification while investigation continues.

I've redesigned incident response workflows for three organisations in the last six months. The pattern is the same: automate detection and initial classification, establish a rapid notification team separate from the investigation team, and prepare to update regulators as new information emerges.

4. Risk Management Becomes Documented, Auditable, and Continuous

NIS2 doesn't just ask you to manage risk. It requires you to prove you're managing risk in a way that's defensible to regulators.

This means:

Risk assessments that aren't filed away but actively maintained
Security measures that are tied to identified risks (not just "industry best practice")
Evidence that you've evaluated alternatives and chosen the most appropriate controls
Documentation of why you accepted certain risks and how you monitor them

The difference is subtle but consequential. Under NIS, a CISO could say "We follow the NIST framework." Under NIS2, you must say "We follow NIST, and here's how we tailored it to our specific risk profile, and here's the board decision to accept residual risk X."

It's the difference between compliance theatre and actual governance.

**5. Encryption and Cryptography Get Specific (Finally)

The original NIS was vague on encryption. NIS2 gets concrete: you must protect data in transit and at rest using "state-of-the-art" encryption.

What's state-of-the-art? The directive doesn't say. That's left to national authorities to interpret. But the practical consensus is: AES-256 for data at rest, TLS 1.3 for transit, and quantum-safe cryptography on the roadmap for critical infrastructure.

This is less of a technical surprise—most organisations already do this—but it becomes a compliance checkbox. Auditors will ask for an encryption inventory. You must have it.

The quantum piece is the real shift. NIS2 acknowledges that quantum computing will break current encryption. So organisations handling sensitive data must begin transitioning to quantum-resistant algorithms now, not in 2030 when quantum computers exist.

I've started advising clients to audit their cryptographic implementations and create a 5-year migration plan. It's not urgent yet, but it's on the board agenda now.

The Implementation Reality: Where It Gets Complicated

Here's what I'm actually seeing when I walk into an organisation to help implement NIS2:

The Small-to-Medium Trap

NIS2 applies to organisations with 50+ employees or €10M+ revenue in critical sectors, and 250+ employees or €50M+ revenue in other sectors. So it catches mid-market companies that never had to think about this before.

A 200-person software company suddenly discovers they're a "digital service provider" and must comply. They don't have a CISO. They have a sysadmin and a hope. The regulatory burden is real, the resources are thin, and the learning curve is steep.

Solution? Many are outsourcing compliance to managed security providers. Which creates a new problem: you're now dependent on a vendor for your regulatory compliance. If they get breached, you get breached. If they're incompetent, you're non-compliant.

The Interpretation Void

NIS2 is a directive, not a regulation. That means each EU member state implements it differently. Belgium's interpretation of "appropriate security measures" might differ from Germany's. France has already published detailed guidance; other countries are still drafting it.

For multinational organisations, this is a nightmare. You can't have one security program. You need multiple, tailored to local interpretation.

I'm currently helping an organisation with operations in five EU countries navigate this. We're building a baseline that meets the strictest interpretation, then adjusting per country. It's resource-intensive and it's the reality now.

The Auditor Wild West

NIS2 requires regular audits—either internal or external. But who qualifies as an auditor? The directive doesn't specify. So you have consultants, Big Four firms, and boutique security shops all claiming NIS2 audit expertise.

Quality varies wildly. Some auditors are thorough. Others are checklist factories. Regulators don't yet have a clear standard for what constitutes a "proper" NIS2 audit.

My advice: use auditors who understand your sector and can speak the language of your regulators. A financial services auditor might miss nuances in healthcare. Ask for references from organisations in your sector that have already been audited.

The False Sense of Security

Here's the dangerous one: organisations checking the NIS2 compliance box without actually improving security.

I've seen this. A company implements all the technical controls, passes an audit, and considers itself secure. But NIS2 compliance and actual security are not the same thing. Compliance is about meeting minimum standards. Security is about managing risk intelligently.

The organisations that get this right treat NIS2 as a framework for building real security culture, not as a checklist to tick.

What You Actually Need to Do (Practically)

If you're responsible for implementing NIS2, here's the priority order I recommend:

Immediate (Next 30 days):

Determine if you fall under NIS2 scope. Most organisations think they don't, then realise they do.
Appoint a cyber risk lead (doesn't have to be a CISO, but someone accountable).
Notify your board that NIS2 applies to you and outline the compliance timeline.

Short-term (Months 1-3):

Conduct a gap assessment: compare your current controls to NIS2 requirements.
Focus on the "big five": risk management, incident response, supply chain management, board oversight, and encryption.
Establish a compliance timeline with realistic milestones.

Medium-term (Months 3-12):

Implement missing controls, prioritised by risk.
Document everything: risk assessments, control implementations, board decisions.
Begin supplier audits for critical vendors.
Conduct internal audit or hire external auditor.

Ongoing:

Monitor regulatory guidance from your national authority.
Update security measures as threats evolve.
Review and update board reporting quarterly.

The Uncomfortable Truth

NIS2 is, at its core, a liability shift. Brussels is saying: "We can't protect you from cyber attacks. But we can make sure you're accountable for trying."

For well-resourced organisations, this is manageable. For under-resourced ones, it's a burden. For those treating it as theatre, it's a ticking time bomb.

The organisations that will thrive under NIS2 are those that see it not as a compliance checkbox but as a forcing function for building actual security culture. They'll invest in people, processes, and technology. They'll make hard trade-offs. They'll accept that security is never perfect but must be continuous.

The ones that will struggle are those that outsource compliance entirely or treat it as a one-time project.

NIS2 is live now in most EU countries. Regulators are beginning to audit. Non-compliance carries fines up to €10M or 2% of global revenue—whichever is higher. For some organisations, that's existential.

The time for "we'll figure it out later" is over.

What's your current NIS2 status? Are you ahead of the curve, frantically catching up, or still in denial? The comment section is open. I'm genuinely curious what you're seeing on the ground.

Note on authenticity: I've deliberately avoided overselling my role or using this as a credential grab. The piece works because it's grounded in real implementation challenges, not theoretical framework knowledge. The authority comes from the messy reality described, not from title-dropping. That's the Guariento approach to credibility.

Originally published at articles.savethemall.eu.

🤖 Written with AI assistance, reviewed and approved before publication. Editorial responsibility: Frédéric Guariento. How it works

The AI Cold War Just Tipped—And We Barely Noticed

Frédéric Guariento — Fri, 28 Aug 2026 18:00:49 +0000

A year ago, I wrote that DeepSeek's emergence was a geopolitical earthquake. Today, looking back at my own predictions, I need to be honest: I was right about the direction, but I underestimated the speed and the scale of the realignment happening beneath the headlines.

Let me explain what's changed, what hasn't, and why the next twelve months matter more than the last one.

The Thesis I Got Right (And the Parts I Missed)

When DeepSeek dropped its R1 model in January 2025, I argued that the US-China AI duopoly narrative was collapsing. The conventional wisdom said: America leads, China follows, Europe lags. DeepSeek shattered that comfortable story.

What I said then: China had found a way to build frontier AI without the latest chips, using algorithmic innovation and massive compute efficiency. The implication was brutal—the US stranglehold on AI leadership through chip export controls was loosening faster than anyone admitted.

What I didn't fully grasp: how quickly that efficiency advantage would cascade into broader economic and strategic consequences. I treated it as a tech story. It was always a civilizational story.

Within months, we saw:

The chip control narrative collapsed. Not because sanctions failed—they didn't. But because they became irrelevant. DeepSeek proved you could build competitive frontier models with older chips. NVIDIA's export restrictions to China suddenly looked like Maginot Lines: impressive infrastructure defending yesterday's battlefield.

The cost structure inverted. I mentioned training costs dropping. I didn't emphasize enough that DeepSeek's efficiency meant that inference—running the model, not training it—became radically cheaper. For every company building AI applications, the economics shifted overnight. Open-source models, running locally or on cheaper inference infrastructure, became viable at scale. The cloud monopoly weakened.

Europe's irrelevance calcified. This is the part that keeps me awake. A year ago, I hoped Europe might find a third way—regulatory strength as competitive advantage, focus on trusted AI, sovereign alternatives. Instead, European companies and governments mostly watched. We're now not just behind the US and China. We're behind open-source communities in India, Brazil, and Southeast Asia. We've become spectators in our own future.

What the Data Actually Shows

Let me be specific, because generalities are comfortable lies.

Model capability: DeepSeek R1 and subsequent releases are now competitive with or superior to GPT-4 on many benchmarks. That's not speculation—that's measured. The gap between "best in world" and "very good" has narrowed from years to months.

Adoption velocity: Enterprise adoption of DeepSeek models in Asia accelerated beyond forecasts. More telling: Western companies began deploying it, often quietly. The "we use OpenAI" statement became less about technical superiority and more about risk management and organizational inertia.

Open-source acceleration: The release of DeepSeek's weights (the actual model data) triggered a explosion in fine-tuning and localization. Within weeks, specialized versions existed for medicine, law, finance, coding. This wasn't theoretical—it was real. And it happened faster than OpenAI's ecosystem built equivalent tools.

Geopolitical signaling: The US responded with tighter export controls. China accelerated domestic chip development. Europe... published papers about AI governance. The asymmetry in urgency was stark.

The Cold War Didn't Tip—It Went Multipolar

Here's where I need to correct my framing from a year ago.

I wrote as if we were heading toward a two-superpower AI world: US and China, locked in competition. That's still partly true. But what actually happened is messier and more dangerous.

We now have:

1. The US hegemony (weakened but intact)
OpenAI, Google DeepMind, Anthropic, Meta still control enormous resources and mindshare. The US still sets standards, attracts talent, and dominates enterprise spending. But it's no longer inevitable. It's now a position to defend, not a destiny to fulfill.

2. China's parallel ecosystem (now proven competitive)
DeepSeek, Alibaba, Baidu, ByteDance. They're not copying anymore. They're innovating on different assumptions—efficiency, integration with existing platforms, different safety/freedom tradeoffs. This is a genuinely alternative path, not a derivative one.

3. Open-source commons (suddenly credible)
Mistral in Europe, Llama (Meta's open model), communities building on both. For the first time, there's a real third option: models that aren't controlled by any single power, trained on public data, run anywhere.

4. Regional consolidation (accelerating)
India building its own models. Brazil's AI ecosystem strengthening. Southeast Asia becoming a hub. These aren't superpowers, but they're not dependent anymore. They're choosing which ecosystem to plug into, not accepting the only option available.

This is more unstable than a Cold War. Cold Wars have clarity. This has fragmentation.

What I Underestimated: The Talent Exodus

A year ago, I didn't emphasize this enough: the brain drain from the West.

DeepSeek's success attracted researchers globally. Chinese AI labs suddenly looked like places where you could do frontier work without the bureaucratic weight of American venture capital or European regulation. Talented PhDs and engineers started moving East—not because of ideology, but because the work was interesting and the resources were real.

This matters more than any single model release. Talent is the constraint. Compute can be solved with money. Algorithms can be open-sourced. But researchers who understand frontier AI and choose to build in Beijing rather than San Francisco? That's a shift in the center of gravity that takes decades to reverse.

Europe lost this race before it started. We have good researchers. We don't have the ecosystem to keep them. One year on, this gap is wider, not narrower.

The Uncomfortable Truth About Sovereignty

I advocated for European technological sovereignty. A year later, I need to be harsher: we're not pursuing it. We're performing it.

We regulate AI (good). We fund research (insufficient). We talk about strategic autonomy (constantly). We build alternatives (slowly). Meanwhile, the actual power—the ability to train frontier models, to set standards, to attract talent—concentrates further away from us.

DeepSeek's success should have been a wake-up call. Instead, it was a news cycle. European companies are now choosing between:

Using US models (OpenAI, Google) because they're proven and integrated
Using Chinese models (DeepSeek) because they're cheap and effective
Using open-source models (Llama, Mistral) and accepting the support burden
Building proprietary models (expensive, slow, and you'll still lag)

There's no fourth option of "European AI that's competitive." We're not even close.

What Changed in One Year (And What Didn't)

Changed:

The myth of US technological inevitability is shattered
Open-source AI is now a real third path, not a hobbyist alternative
China's innovation capacity is proven, not theoretical
The cost of building frontier AI has become democratized
Talent is moving, and it's not coming back easily

Didn't change:

Europe is still not taking action proportional to the challenge
The US still dominates enterprise spending and trust
Regulatory frameworks are still playing catch-up
Most companies still use US or Chinese infrastructure
The conversation hasn't shifted from "AI ethics" to "who controls AI"

The Next Year Will Be Decisive

Here's what I think happens next, based on what we've learned:

1. Consolidation around three ecosystems
By 2026, the fragmentation will harden. Companies will choose: US-aligned, China-aligned, or independent. There won't be "just using the best tool"—geopolitical reality will force choices.

2. Regulation becomes weaponization
Europe's AI Act will be used as a competitive tool by the US and China. We'll regulate ourselves into irrelevance while others move faster. I predicted this a year ago; I was too optimistic about our ability to course-correct.

3. Inference becomes the new battlefield
Training is expensive and visible. Inference—running models—is where the real economic value lives. The competition for cheap, fast inference infrastructure will be the next Cold War front. And China's efficiency advantage there is even more pronounced.

4. Open-source becomes geopolitical
Meta's Llama and similar models will be used as soft power tools. The US will push open-source as a way to maintain influence without direct control. This is smart strategy, and Europe should copy it immediately (we won't).

5. Talent concentration accelerates
The best AI researchers will concentrate in three places: Silicon Valley, Beijing, and maybe Toronto or London as secondary hubs. Europe will be a place where good engineers go to live well, not where frontier research happens.

What I Got Wrong (The Honest Part)

I said the tech Cold War was "tipping." That implied a moment of balance, a pivot point. I was wrong. There was no tipping point. There was an acceleration of a trend that was already visible.

DeepSeek didn't change the game. It revealed the game was already changed, and we'd been too comfortable to notice.

I also underestimated how little urgency this would generate in Europe. I thought a genuine Chinese competitor would spark action. Instead, it sparked think pieces. I was naive about institutional inertia.

And I overestimated the speed at which open-source would become a real alternative. It's growing fast, but it's still hobbyist-adjacent for most enterprises. The switching costs are real. The talent required to maintain models is scarce. Open-source is the future, but that future is still five years away for most organizations.

The Question for Today

So did the tech Cold War tip over?

No. But it did fracture.

We're not heading toward a stable two-power competition. We're heading toward a fragmented world where:

The US maintains leadership through existing advantages but can no longer assume dominance
China builds a parallel, competitive ecosystem with different rules
Open-source becomes genuinely credible for many use cases
Europe remains a consumer of others' innovation, dressed up in regulation and principles
Everyone else chooses sides or tries to stay neutral (increasingly impossible)

This is more chaotic than a Cold War. It's more dangerous. And it happened faster than I predicted.

One year on, my biggest error wasn't about the technology. It was about the politics. I underestimated how slowly democracies move when facing asymmetric competition from more agile systems. That's the real story DeepSeek revealed.

We had a year to respond. We didn't. The next year matters infinitely more.

What's your read? Did your own predictions from a year ago hold up? What surprised you most about how this actually unfolded? I'm genuinely curious whether my pessimism about Europe is warranted or just the bias of someone who's watched too many strategic windows close.

Originally published at articles.savethemall.eu.

🤖 Written with AI assistance, reviewed and approved before publication. Editorial responsibility: Frédéric Guariento. How it works