AI writes the code. Who reviews the risk?

For fifteen years I worked on the defensive side of security, most recently as Head of Group IT Security. In that time I watched the same pattern repeat in almost every team: ship fast, then bolt security on at the end.

Two things just made that pattern far more dangerous. One is AI. The other is NIS2.

The most expensive bugs were never typos

The failures that cost the most were rarely bad lines of code. They were design decisions: a trust boundary drawn in the wrong place, an authentication model decided too late, a service that trusted another for no reason. By the time there's code, most of the security is already locked in. You can't test your way out of a broken design.

That's why the cheapest fix is usually a 20-minute conversation at a whiteboard ("if I wanted to break this, where would I push?"), not a three-week rewrite after the pentest.

AI is a confident junior who read the whole internet

Here's the uncomfortable part about AI-assisted development. Your copilot ships faster than any human, and it reproduces, with total confidence, the exact vulnerability classes it learned from a decade of public code that was never secure in the first place. Injection, weak auth, leaked secrets: the patterns it absorbed are now the patterns it suggests.

And because the output looks right (clean, idiomatic, plausible), it sails straight through review.

AI didn't remove the need to review code for security. It made it more urgent, and it changed what you're looking for. The teams that win won't be the ones who ban AI. They'll be the ones whose engineers know exactly how it fails.

NIS2 moved the bar from the binder to the codebase

At the same time, NIS2 raised the bar on how software is actually built, not just how it's documented the week before an audit. Most of that conversation has been legal and governance. The engineering side, what a dev team needs to do differently, gets skipped.

The good news: you're probably closer than you think. Done right, compliance isn't a binder you assemble under pressure. It's a by-product of how you already ship.

Every pull-request review, every scan result, every gated release is an audit-ready artifact: proof that a control ran and a decision was made, with a timestamp and an owner. The teams that struggle at audit aren't missing controls. They're missing the trail that proves the controls ran.

Security is a habit at the start, not a phase at the end

Put the three forces together (design decisions that lock in early, AI accelerating insecure patterns and NIS2 raising the bar) and the conclusion is the one I've believed for years:

Security isn't a gate you add at the end. It's a series of decisions made while the code is written. Move those decisions upstream, into the hands of the engineers who make them, and most of the "security problem" quietly disappears.

The habit fits on a sticky note: think like an adversary, act like a white hat.

Where to start

A few of the checks I run with teams:

• Threat-model new features at design time, before the code exists.
• Review AI-generated code through the same gates as hand-written code.
• Know what you ship: SCA and an SBOM, not guesswork.
• Treat your pipeline as your audit evidence: who, when, why.

I put the full version (14 practical checks, no legal fluff) on one page. Free, no wall: cyberment.ee/nis2

I'm Barnabás. After years on the defensive side, I started CyberMentee to teach engineering teams to build security in, hands-on, on their own code and pipeline. If any of this resonates, I'm always up for comparing notes.