A cell biologist I spoke with this week described how his research team uses AI in drug discovery. In silico — inside the machine — AI is fast, broad, and genuinely useful. It processes literature at scale, generates hypotheses, runs models. What it doesn’t do is take the next step alone. Before any hypothesis moves into a living organism, a researcher decides whether it holds. That gate is explicit, designed, and non-negotiable.
That image stayed with me. Because it captures exactly the question most leadership teams avoid when they deploy AI: not what can the model do, but where does the human decide.
The Same Question, Five Different Rooms
This week, across workshops, conversations, and posts, I kept running into the same fault line. Teams that are stuck with AI aren’t stuck because the technology is wrong. They’re stuck because the handoff between AI output and human judgment is undefined.
In one room, the problem was automation creep: a team wanted to wire their CRM into an AI pipeline before anyone had verified a single output by hand. In another, a department head described it as an “AI knowledge problem” — but when I pressed, it turned out that nobody on the team owned the domain well enough to recognise when the AI was quietly getting it wrong.
The question underneath was always the same: Where does the human decide?
Most AI strategies never answer it. They decide what to automate. They don’t design the gates.
Gate One: Can You Verify It?
The fastest, most reliable AI wins come from transformation — taking something that already exists and summarising, reformatting, or extracting from it. Not because transformation is technically simpler than generation, but because you can check the result against a real source.
When you ask AI to summarise a document you wrote, or extract data from a file you control, you have something to verify against. That ability to check is what makes the output trustworthy — and what makes it safe to eventually automate.
The maturity ladder I run with teams follows a clear sequence: upload a document and verify the output yourself first. Copy-paste a few records. Understand where the model fails before you connect any system. Connectors and automated pipelines come last — only after you’ve mapped the failure modes by hand.
The rule is blunt: don’t automate what you haven’t verified.
Gate Two: Can You Switch?
This week’s debate around European AI sovereignty — specifically around whether a model’s geographic origin is what matters — surfaced a principle I’ve come to hold firmly: you are only sovereign when you can switch.
It doesn’t matter whether the model runs on servers in Heidelberg or California if you haven’t built the internal capability to evaluate it, benchmark it against your actual work, and replace it if something better arrives. Sovereignty isn’t about provenance. It’s about portability — your ability to judge performance on your own terms.
The teams I respect in this space don’t wait for independent benchmarks. They keep their own test cases. When a new model launches, they run it through their specific workflows the same night. They’ve built the evaluation muscle themselves.
That’s Gate Two: Do we have our own benchmark tasks — or are we dependent on the vendor’s claims?
Gate Three: Who Owns the Domain?
Here is the insight that sharpens everything else. When a team struggles with AI, the first diagnosis is almost always “we need more AI knowledge.” My experience is that this is rarely the real problem.
What’s usually missing is domain expertise. AI in sales fails because nobody on the team can tell whether the output is commercially accurate. AI in procurement fails because nobody can verify the sourcing logic. AI in finance flags anomalies that a junior analyst would have caught — but nobody senior is in the review loop.
A CEO doesn’t need to play every instrument. But a conductor who can’t hear a wrong note can’t run a rehearsal. And the check cannot come from the same musician who played the part.
Gate Three is the one teams most often skip: Who on this team has the domain expertise to know when the AI is wrong — and are they explicitly in the review loop before the output is acted on?
The Operator’s Gate Check
Before any AI workflow goes live — or before you expand one that’s already running — I run three questions. I call this the Operator’s Gate Check.
Gate 1 — Verification Can someone on the team check this output against a known source, without technical help? If no: don’t automate yet. Start by hand, on real cases.
Gate 2 — Portability Do we have our own test tasks for this workflow — tasks we could use to evaluate a different model tomorrow? If no: you don’t have sovereignty. You have vendor dependency.
Gate 3 — Domain Who owns the expert judgment here, and are they in the loop before this output is acted on? If no: the AI isn’t the risk. The missing human is.
You don’t need all three gates perfect before moving forward. But you need to know which gates are open, and to have made a conscious decision about why.
The Capability Shift Most Leaders Miss
There’s a related leadership move that I think is even harder than setting the three gates — and it came up directly in a conversation I had this week about how a technology team was structured.
The old brief was: build me an onboarding flow. Deliver it, sign it off, move on. The new brief is: build me a team that can keep building onboarding flows — a team of people and agents that compounds with each iteration. The language change is small. The outcome difference is enormous.
A team that delivers a finished product learns nothing transferable to the next request. A team that builds a repeatable capability — with humans setting the gates and agents doing the repetitive work — gets better every cycle.
For me, this is the leadership question behind all the others: Are you building a capability, or are you buying an output?
The answer determines whether your AI investment produces a one-time result or a structural edge.
Three Things You Can Do Next Week
-
Run one transformation, not a creation. Take a document you already trust — a report, a contract, a set of meeting notes — and run it through an AI tool for summarisation or extraction. Verify every output line against the source. That’s your first verified workflow.
-
Write down two internal test cases. For any AI tool you’re currently evaluating or using, write two specific tasks from your actual business that you’ll run against any new model. These are your benchmarks — not the vendor’s.
-
Name the domain owner. For each AI workflow currently running in your organisation, name one person who has the expertise to identify a wrong answer. If you can’t name them, Gate Three is open.
-
Reframe one AI project brief. Before you approve the next AI project, ask: are we commissioning a deliverable or building a capability? If it’s a deliverable, who inherits the ability to build the next one?
-
Investigate one AI complaint. If a team tells you “we need more AI knowledge,” spend an hour asking what the AI gets wrong in their specific domain. The answer will tell you whether the real gap is technical — or whether it’s domain expertise that’s missing.
Where in your organisation is Gate Three currently open — and who would you put in that role?