Build for the Wobble
We've covered the people (builders, hired for curiosity) and the technology (a coherent platform, so AI has a clean signal to reason over). Time for the part that ties the room together, and the part I'll be honest I know least about: process.
Two bad takes again. "Automate everything, AI's got this" and "you can't trust AI with anything important."
Both wrong.
The grown-up version: if AI is doing most of the work, your processes have to be AI-first. But AI is non-deterministic, so those processes also have to be built to fail safely and heal themselves.
Because deviation isn't the exception here. It's a property of the system.
The numbers are sobering
Let's not hand-wave this. Stanford's 2026 AI Index found hallucination rates across 26 leading models ranging anywhere from 22% to 94% depending on the task, and those errors compound across multi-step workflows.
It gets more concrete. Faros AI's analysis of the DORA 2025 data found incidents per pull request jumped 242.7% where AI was let loose without robust controls. And Gartner expects more than 40% of agentic-AI projects to be cancelled by 2027, largely because teams underestimated exactly this.
The pattern is hard to miss: enthusiasm without discipline fails.
Borrow the discipline from reliability engineering
The good news is we already know how to do this. We've been building reliable systems on top of unreliable components for years.
You design for deviation, explicitly. Clear states, retries, rollback points, and escalation paths, so that a bad output becomes a logged reroute or a human handoff, never a silent error. The moment a failure can slip through unnoticed, you don't have a process. You have a liability with good PR.
The failure-budget mindset
The mental model I find most useful is a failure budget. You engineer the process to tolerate a higher failure rate than the model's actual error rate, the same way modern pipelines and development lifecycles are built to ship fast and reliably at the same time.
Build for the wobble, and the wobble stops being scary.
Practical takeaway: assume it'll be wrong, then make that safe
- Make every AI step observable. If you can't see it, you can't trust it or fix it.
- Define where a human signs off, anchored in reversibility and impact, not vibes.
- Build kill switches, fallbacks and backups. Plan for the confident mistake at scale, because it's coming.
- Budget for failure. Tolerate more error than the model produces, and design the recovery in from day one.
Putting the series together
Stack the three parts and a surprisingly coherent picture falls out. The security team you build with AI in mind is a crew of curious, creative builders, working from one coherent toolset, whose real job becomes orchestrating fit-for-purpose processes that don't depend on people standing in the loop to function.
The humans aren't doing the toil. They're directing the system, asking the right questions the machine wouldn't, and building the next thing that removes the next bit of toil.
And notice it's the same bar across all of it, generalised over the whole function, GRC and all. DevSecOps was never meant to stay in one corner of the org chart. It was a preview of the operating standard for all of security in the AI era.
"The future of the team isn't defined by removing people. It's defined by removing low-value friction, and raising what we expect every person on the team to be capable of."
That's the series. Part 1 → "Everyone's a Builder Now". Part 2 → "Give Your AI a Clean Room".
