Huginn

The Advisor on the Factory Floor: Everyone Works Better with a Defined Role, Even AI

By Ydun Research

I am the founder of Ydun.io and a senior software engineer at CrabNebula. I first gave this talk at the Nordic Software Security Summit in spring 2026, representing CrabNebula, and I am giving it again at Øredev in Malmö. What follows is the argument, adapted for reading.

Who I am, and why that matters

I use AI more than almost anyone in the room. My daily workflow is built around it. I maintain open source tooling at CrabNebula inside the Tauri ecosystem. I run security audits using AI-assisted pipelines. I have a multi-agent research system running in my home lab right now, named after MI6 characters, that I talk to more than most humans.

And every single agent in that system has a defined role.

Moneypenny controls access and filters what gets through. Beast runs the heavy compute: embeddings, vector search, the work that needs raw power. Q handles research and development. Guardian watches the perimeter.

Nobody crosses into someone else's lane. The system works because the roles are explicit, bounded, and enforced. The moment an agent tries to do something outside its defined function, the system flags it.

I didn't design it that way because I read a paper about multi-agent architecture. I designed it that way because I grew up on a factory floor. And everyone on a factory floor knows: you work better when you know your role.

That principle is the entire talk.

My number one rule is to be forward looking. Always. At CrabNebula we are actively researching hybrid quantum cryptography, zero knowledge proofs, the cryptographic primitives that do not exist yet in production but will have to before 2030.

I believe in AI completely.

And I am telling you that your production line has to be code. Not because I am a skeptic. Because being forward looking is exactly how we know this. And because everyone, including AI, works better with a defined role.

The factory floor: a hundred years of manufacturing wisdom

Let's go back a hundred years. Actually, let's go back further than that, and closer to home for some of you.

  1. The Göta Canal opens. And in Motala, a small town on the eastern shore of Lake Vättern, Motala Verkstad is building the locomotives, the steam engines, and the mechanical infrastructure that will industrialise Sweden's interior. That workshop didn't just build machines. It built the engineering culture of Östergötland, the region that today is home to Väderstad, Toyota Material Handling, the SAAB legacy, and some of the most serious manufacturing DNA in Europe.

I know this because I live there. I am based in Motala.

I grew up on a factory floor in Western Sydney, a third-generation manufacturing family. And I ended up in arguably the town where Swedish manufacturing began. I have been surrounded by production lines my entire life. I know what one looks like. And I know what happens when you try to replace the line with an advisor.

So when I talk about a hundred years of manufacturing wisdom, I am not reading from a business school textbook. This is the air I grew up breathing, in two different countries.

Henry Ford did not invent the car. He invented the process. The moving assembly line. Each station deterministic. Each component tested before it reached the next stage. The output of one module was the verified input to the next. You could point at any moment in the line and say: this is what happened, this is what produced it, this is who is accountable.

That was a revolution. Not because it was fast, though it was. Because it was auditable.

Then Japan looked at Ford's line and asked a different question. Not how do we build more, but how do we build right. Toyota didn't just build cars. They built a philosophy. Kaizen. Continuous improvement. Quality is not inspected in at the end. Quality is built in at every single step.

And critically, the human on the floor had authority to stop the line. If something was wrong, you halted production. The cost of stopping was always less than the cost of a defect reaching the next stage.

The outside expert, the sensei, the quality consultant, the advisor from the other factory, stood beside the line. Watched. Challenged. Suggested. Was invaluable.

Was never the conveyor belt.

A hundred years of manufacturing knowledge distilled to a single principle: the line is deterministic, modular, and human-accountable. The advisor makes it better. The advisor does not replace it.

The CRA called you a manufacturer, and that wasn't an accident

The EU did not accidentally use the word manufacturer.

The Cyber Resilience Act extends the CE mark, the same mark on your washing machine, your child's toy, your medical device, to your software. That is not a metaphor. It is a precise legal statement that brings a hundred years of product liability, conformity assessment, and manufacturing accountability to your codebase.

There are two distinct groups affected, and the CRA lands differently for each.

Some are digital-native. SaaS companies, open source maintainers, software houses. The CRA calling you a manufacturer is a conceptual shift. You have never thought of yourself that way. You ship code, not products. You deploy, you patch, you iterate. The factory floor metaphor is new territory.

And some were already manufacturers before the CRA existed. Industrial companies. Medical device makers. Defence suppliers. You already had CE marks. You already had production lines, quality management systems, ISO 9001, notified body relationships. You know exactly what a declaration of conformity means because you have been signing them for years.

For the first group, welcome to manufacturing. The discipline that kept physical products safe for decades is coming to your codebase. The metaphor is the message.

For the second group, the message is different, and arguably more urgent. Your software department is now subject to the same obligations your factory floor has operated under for decades. The question is whether your software team knows that. Because your legal exposure just extended into a domain your quality management system probably wasn't designed to cover.

The industrial manufacturers already understand what it means when your name is on a product and something goes wrong. That accountability is now explicitly yours in software too.

Both groups end up in the same place. The line must be deterministic. The accountability must be human. But the journey there looks different depending on where you are starting from.

Daniel Thompson-Yvetot, who has written the two most important practical books on this legislation, Manufacturing European Software and Modular Compliance, puts it plainly in his opening chapter: for the first time, software is formally treated as a product under EU law.

A product. With a manufacturer. With a responsible person. With documentation requirements, lifecycle obligations, and a declaration of conformity that a human being signs.

The conformity assessment modules, A, B+C, H, are the quality assurance stages of a software manufacturing process. Module A is internal production control. You assess, document, sign. Module H is full quality assurance, a functioning QMS with ongoing surveillance. These are not abstract compliance checkboxes. They are the regulatory encoding of the Toyota production system applied to software.

The CRA asks one fundamental question at every stage: who signed this, and can you prove it?

You cannot point at a model. The liability does not attach to weights. The declaration of conformity requires a human manufacturer.

And the clock is not abstract. September 11, 2026 is the first hard deadline, when mandatory incident reporting to ENISA becomes enforceable, a 24-hour early warning and a 72-hour notification through a single reporting platform. That is not the full compliance horizon, that is the first moment of truth. If your pipeline is not deterministic and auditable before that date, you will find out the hard way what the CRA actually means by manufacturer.

The CRA already knew what Ford and Toyota knew. The line must be deterministic. The accountability must be human. Compliance is not the ceiling. It is the floor.

The adversary already knows this

Red teams exist for one reason: to think like the attacker before the attacker thinks for you. That is not a threat exercise. That is the most disciplined form of defensive engineering there is. You cannot build a resilient pipeline without first asking how you would break it.

That is how we approach compliance work at CrabNebula. We don't ask "does this pass?" We ask "how would this fail, and who would exploit it?" Stress-test your own posture before the notified body or the threat actor does. If you survive that exercise, you build accordingly.

So let's think like the attacker for a moment.

A Trellix Advanced Research Center report published in March 2026 documents something worth sitting with. MuddyWater, an Iranian state-aligned APT group that has been running espionage campaigns since 2017, rewrote their primary implant in Rust. They called it RustyWater.

Think about that. A nation state threat actor red-teamed their own attack toolchain and made a deliberate engineering decision: the payload needs to be memory safe, performant, and hard to inspect. They did the exercise. They built accordingly. They chose Rust for their production pipeline.

The adversary already knows what your pipeline needs to be built in.

The same report documents CyberAv3ngers, IRGC-linked operators, deploying IOCONTROL, a custom malware platform purpose-built for industrial IoT and operational technology environments. Fuel management systems. Water treatment infrastructure. They didn't attack software. They attacked the physical world through software. That is what "products with digital elements" actually means in practice: a connected sensor on your factory floor is now a potential weapons delivery system.

And RedKitten, a newly identified actor, incorporated AI into the attack lifecycle itself. AI-assisted malware development. The attacker is already using AI as an accelerant in their pipeline. As an advisor that makes their attacks better.

They figured it out. The AI advises. The pipeline is code.

So here is the question worth sitting with. If the adversary is writing Rust, using AI as an advisor to build better attacks, and targeting the physical infrastructure we depend on, what does our response pipeline look like? Is it deterministic? Is it modular? Is it auditable? Can every step be signed by a human who owns the outcome? Or are we building compliance on a foundation we cannot inspect?

AI as advisor: the correct mental model

I want to be precise about what I am arguing.

I am not arguing against AI. I am arguing for the correct placement of AI in your architecture.

At CrabNebula, we use AI every day in security work. In our QA pipeline. In compliance research. In threat analysis. The way we use it is deliberate: AI reads the landscape, surfaces gaps, challenges our assumptions, spots what we missed. Then a human practitioner makes the call and owns the finding.

AI advises. The engineer decides. The engineer signs.

That is not a limitation on AI. That is the more sophisticated use of it. It requires understanding what AI is genuinely good at, pattern recognition, synthesis across large information spaces, pressure-testing reasoning, versus what it structurally cannot do, which is carry legal liability or produce a verifiable audit trail of its internal reasoning.

This is also where the EU AI Act intersects directly with your CRA compliance posture. An AI system making conformity decisions autonomously is potentially a high-risk AI system under the AI Act, with its own separate compliance obligations. The moment you remove the human from the signature loop, you may have just created two compliance problems where you thought you were solving one. Human-in-the-loop is not a limitation. It is a deliberate architectural choice that keeps your legal exposure manageable across two regulatory frameworks simultaneously.

Here is the deeper technical problem.

The conformity assessment process requires you to be able to swap components, test them in isolation, verify their behaviour, and prove that a change between version A and version B did not break your compliance posture. That is the modularity requirement. SWHID, the Software Hash Identifier, now ISO/IEC 18670:2025, exists precisely to give you a cryptographic fingerprint for every component in your supply chain. SBOM exists to enumerate what you have. You swap in a new cryptographic module, you test it against your pipeline, you get a deterministic result.

You cannot do this with an AI model in your compliance pipeline.

You can gate the inputs. You can constrain the outputs. You can wrap it in a deterministic shell. But you cannot open the model, inspect it, and prove what changed between version A and version B of the weights. The weights are not source code. There is no SWHID for a model that tells you what it thinks. The SBOM for an LLM is an open and unresolved problem in this industry.

And the CRA is going to require an answer.

Every organisation currently using an LLM inside its conformity assessment process has an undeclared component in its compliance pipeline that it cannot fully audit. That is not a position. That is a structural fact.

The advisor stands beside the line. Invaluable. Essential. Not the conveyor belt.

Now, I want to be honest about where this goes, because we are not closing the door.

I can see a future where this changes. Not AI as a generic assistant dropped into a compliance workflow, but purpose-built compliance AI. An agent that knows your product. Your regulatory classification. Your dependency graph, your risk posture, your team's decision history. A genuine member of your compliance function with a defined role, bounded authority, and a track record your notified body can actually inspect.

Not a tool you prompt. A teammate with a job title.

That future is closer than most people think. And when it arrives, the conversation about what AI can own, what it can sign for, and how its role gets defined under the CRA and the AI Act will need to be had seriously.

But we are not there yet. Today we cannot open the model and inspect what changed between version A and version B. Today the weights are not source code. Today the SBOM for an LLM is an unresolved problem in this industry.

So for now, the advisor stays beside the line. Not because AI isn't capable enough. Because the role isn't defined well enough yet.

And everyone works better with a defined role.

The pipeline has to be code

So what does a correct pipeline look like? It looks like what good engineers have always built.

One thing first. When I gave this in Stockholm, I stood in front of a room full of Swedish engineers and told them their pipeline should be written in Rust and not .NET. I understand this is borderline heresy in that postcode. I have seen the Ericsson campus. I know what runs in there.

But here is the thing. MuddyWater already made the switch. If Iranian state-sponsored threat actors can migrate off PowerShell, we can have a conversation about memory safety.

Rust, or a language with equivalent memory safety guarantees, at the base layer. Not because it is fashionable. Because memory safety is a CRA essential requirement and because the adversary already chose Rust for their payloads. You should at minimum match their engineering discipline.

Modular architecture. Every component independently testable. Inputs and outputs defined, versioned, and signed. The ability to swap in a new cryptography module, and we will need to, as post-quantum standards land, without breaking your audit trail. Cryptographic agility built in from the start, not bolted on later.

Deterministic build pipelines. Reproducible builds. SWHID identifiers on every component. SBOM generated automatically as an output of your build process, not assembled manually after the fact. One detail worth flagging: SWHID currently uses SHA-1 as its hashing algorithm, and the ISO standard accounts for a SHA-256 migration path. The compliance tooling we build at CrabNebula handles this today via supplementary hashing, SHA-256 and SHA3-256 alongside the current identifier, so the identity layer is already ready for the transition when it lands. If you are building this infrastructure today, build for the transition. Cryptographic agility applies to your compliance tooling as much as it applies to your product.

Human sign-off at every conformity stage. Not as a bureaucratic gesture, but as a genuine engineering checkpoint. The person who signs Module A owns what they are signing.

And AI operating exactly where it belongs: reading threat intelligence, surfacing gaps in your risk assessment, auditing your documentation for consistency, challenging your assumptions before the notified body does.

The best factories in the world had brilliant advisors. The Kaizen sensei did not replace the production line. He made it better.

This is not conservatism. We are researching hybrid quantum infrastructure and ZK proof systems at CrabNebula right now. The more forward you look, the more you understand why the base layer has to be solid. You cannot build quantum-resilient infrastructure on a pipeline you cannot inspect.

This is not abstract, either. The pipeline I have described is the one I help build, deterministic, modular, auditable, with SBOM generation as a build output and continuous vulnerability monitoring against the dependency graph. The point is not the product. The point is the principle: deterministic core, modular architecture, human accountability at every sign-off point, AI advising at every stage. We looked as far forward as we could, hybrid quantum, ZK proofs, the threat landscape in March 2026. We came back and wrote Rust.

Close

Ford proved that deterministic modular production at scale was possible.

Toyota proved that quality has to be built in at every step, and was very precise about what the outside expert was: an advisor, not the conveyor belt.

The EU extended the CE mark to your code and called you a manufacturer.

The adversary already wrote Rust.

The CRA doesn't care how smart your advisor is. It cares who signed the document.

Compliance should not be a burden on European software. It should be the engineering discipline that makes European software the most trustworthy in the world.

The future is extraordinary. The base layer is code.

References

  • Thompson-Yvetot, D. (2025). Manufacturing European Software v1.3.0
  • Thompson-Yvetot, D. (2026). Modular Compliance v1.0.5
  • Trellix Advanced Research Center (2026). The Iranian Cyber Capability 2026
  • EU Cyber Resilience Act (2024). Regulation (EU) 2024/2847
  • ISO/IEC 18670:2025, Software Hash Identifier (SWHID)
  • NTIA and ENISA SBOM frameworks