TL;DR: Most AI governance reviews fire on intake, and AI work doesn't arrive through intake. A large manufacturer's security review board worked exactly as designed in September 2026 and still only saw software that was already running in production. Moving the trigger earlier, so people register intent before code exists, fixes more than adding reviewers ever will.
The review board wasn't broken. That's the part worth sitting with.
On a September 10, 2026 call, a security team at a large manufacturer described a review process that does its job. Apps get looked at. Risk gets written down. Somebody signs. None of that was the complaint.
The complaint was what the board sees. It sees production. Something lands, somebody notices, and the review starts after the thing is already running and already load-bearing. Their word for it was whack-a-mole.
I've heard that word on a lot of calls this year. It usually means the process is fine and the trigger is wrong.
Why does a working review board still miss AI projects?
Because review boards fire on intake, and intake is a form that somebody has to choose to fill out. That choice made sense when starting a software project meant asking for a budget, a repo, a server, and somebody's sign-off. Every one of those asks passed a desk. AI work skips all of them.
So the board never gets a chance to be early. It only gets called after discovery, which means after something is live.
Think about what used to force the conversation. You needed infrastructure, and infrastructure had an owner. You needed a developer, and developers sat in a group that had a manager who knew what the group was building. Each of those was an accidental checkpoint. Nobody designed them as governance and they worked as governance anyway.
Those checkpoints are gone now. A person with a laptop and a coding assistant produces working software without asking anyone for anything. There's no budget line and no moment where the work becomes visible to a process.
What actually changed about who writes software?
The population of people writing code got several times larger, and most of the new ones never went through your developer onboarding. One security team in 2026 put the change at three to five times the previous developer count, with the new arrivals working inside coding assistants rather than in the old toolchain.
Stop thinking of this as a tooling change. It's a population change, and populations are governed differently than tools.
Here's what that means in practice. Your secure development training was written for people who'd already decided to be developers. Your code review culture assumes a team with shared norms. Your pipeline gates assume the code goes through the pipeline. A marketing analyst building a working internal tool in an afternoon triggers none of that, and won't think to, because from where that person sits the work isn't software. It's a spreadsheet that got ambitious.
None of those people are doing anything wrong. That's what makes this hard to fix by memo.
What does intake before code exists look like?
It looks like registering an intent, not submitting a project. The unit of registration is "I'm about to build something that touches customer data," filed in under two minutes, before a single line gets written. That's the guidance that keeps landing on calls where citizen development is the presenting problem.
Make the registration cheap enough that skipping it saves nobody any time. If your form takes fifteen minutes, you've built an incentive to not file it.
The short version of the form asks five things. What are you trying to do. What data will it touch. What can it change on its own. Who owns it by name. When do you expect it to be real. That's it. You're not approving anything at this stage and you should say so on the form, because "register" and "request permission" feel very different to the person typing.
What you get back is a queue of intent instead of an archaeology project. Some of those entries will never become anything, and that's fine. The ones that do become something arrive on your radar while they're still cheap to shape.
Why doesn't adding a security gate solve this?
Because a gate with one person behind it becomes a line, and lines get walked around. A security team that stood up an AI gate in 2024 described the result plainly two years later: demand outran the single person staffing it, and tons of work was going around the gate.
The named gap wasn't capacity. It was triage. Nobody had decided what actually needs the gate and what doesn't.
That distinction is the whole game. If every AI use case gets the same review, the review has to be short enough for the trivial cases, which makes it useless for the dangerous ones. Or it's thorough enough for the dangerous ones, which makes the queue long enough that the trivial ones route around it. Pick either failure and you get the same outcome.
The way out is a triage step that's faster than the review. Sort on two questions. What can this reach, and what can it change without a person saying yes. A tool that reads public docs and drafts text is not the same object as a tool with write access to a customer record, and treating them as one object is what created the queue.
What do you do about champions who are already ahead of you?
Assume they're ahead of you, because on most of these calls they are. Innovation teams and internal AI champions get funded to move fast, which means they're building outside the managed environment by design, not by accident. Two separate September 2026 calls described exactly that shape.
Don't start by slowing them down. Start by making their work visible on terms they'll accept.
Champions are usually the easiest group to bring into a registry, and people get this backwards. They're proud of what they built. They want it adopted. They're not hiding, they're just not on any list. A conversation that starts with "I want to help you get this to more people, so let's write down what it touches" gets a yes. A conversation that starts with a policy violation gets a workaround.
The harder group is the quiet one. End users building small tools outside the managed environment aren't looking for adoption and won't self-identify for any reason you can offer. That's the population where discovery still has to do the work, which is why the technical side of this carries so much weight.
How do you make discovery a real control instead of an accident?
Treat discovery as a scheduled job with an owner, not as something that happens when an incident forces it. Right now, in most organizations, "discovery" means somebody tripped over something. That's not a control. That's luck with a governance label on it.
Point it at the places the work actually shows up. Identity systems know about new service principals and new tokens. Your network exit knows which destinations got new traffic this month. Endpoint telemetry knows which machines started running an interpreter they never ran before. Software repositories know about new projects with one contributor and recent first commits. None of those require a new platform.
Then close the loop, which is the part everyone skips. Every discovery finding goes back into the registry with an owner's name on it, and that owner gets the two-minute form, retroactively. Otherwise you rediscover the same thing next quarter and call it a new finding.
What should you do in the next two weeks?
Find out what your review board saw last quarter and when. Count how many items were already in production on the day of review. That number is your argument for changing the trigger.
Cut your intake form down to five questions and rename it. Registration, not approval. The name change does more than you'd expect.
Write the triage rule on one page. What can it reach, what can it change. Two tiers, not five. Publish it so people can self-sort before they get to you.
Pick two discovery sources you already own and schedule them monthly. Identity and network exit are the usual first pair, because both have owners and neither needs new spend.
Take one AI champion to coffee and register their project with them at their own desk. You'll learn more about your real intake problem in twenty minutes than a quarter of policy drafting gives you.
Set a turnaround number for registration responses and publish it. Two business days is defensible. Silence is not, and silence is what teaches people to skip the form.
Key takeaways:
Review boards fire on intake, but AI work skips the budget, infrastructure, staffing, and sign-off asks that used to force intake to happen.
A large manufacturer's review board worked as designed in September 2026 and still only reviewed software that was already in production.
The developer population grew three to five times at one organization in 2026, and the new builders never passed through developer onboarding.
Registration should record intent before code exists and take under two minutes, and it has to be explicitly separate from approval.
A single-person security gate fails on triage before it fails on capacity, so sort AI use cases by reach and by change authority before reviewing them.
Discovery has to be a scheduled job pointed at identity, network exit, endpoint telemetry, and code repositories, with findings routed back into the registry under a named owner.
Frequently asked questions
Isn't registration before code exists just intake with a new name?
The trigger is different and so is the promise. Intake asks permission for a project that already has shape, and the answer gates the work. Registration records an intent and returns nothing but a receipt and a turnaround date. People file the second one because it costs them nothing and buys them cover if the thing they built gets noticed later.
What if people still don't register?
Then discovery catches them, and that's the design. Registration isn't a substitute for discovery, it's a way to keep discovery from being your only channel. A healthy program sees most work arrive by registration and uses discovery to find the rest, plus to measure how well registration is working.
How do we register something an employee built in a personal account?
You register the use, not the code. If somebody built a useful tool outside the managed environment, the fastest safe path is usually to register what it does and what it touches, then migrate it to a sanctioned platform on a schedule. Demanding deletion on day one teaches everyone else to stay quiet.
Does this apply to agents or just to AI-assisted code?
Both, and agents make it more urgent. Agent work is harder to spot after the fact because it often runs under an existing identity and leaves behavior that looks like normal application traffic. Registering the intent gives you a record that exists whether or not you can find the runtime later.
Who should own the discovery job?
Whoever already owns the data source, with one named person accountable for the merged result. Splitting discovery across identity, network, and endpoint teams without a single owner produces four partial lists and no registry. The merge is the job, and it needs a name on it.
Where does Zero Trust fit here?
Zero Trust is the foundation this sits on. Verify every request and grant the least access needed. Assume something inside is already compromised. Registration and discovery tell you which agents exist and what they're allowed to reach, which is what makes those access decisions enforceable instead of theoretical. Agents need one more check on top of that foundation, which is a judgment about how much autonomy each one has earned.
Your board isn't failing. It's answering a question nobody asked it early enough to matter, and that's a scheduling problem dressed up as a governance problem.