If your governance team tells me their AI reviews take six weeks, I won’t ask about their enterprise risk tolerance or decision-making speed. I’ve learned that decision-making itself – governance personnel determining their review outcome or a business leader deciding to accept the risk and proceed – is seldom what consumes six weeks.
What consumed the six weeks was a week of calendar Tetris to get five people into a single room, after which the privacy attorney quietly wondered why she'd been called at all when the use case didn’t touch a byte of personal data. It was your business-segment security questionnaire that overlapped almost entirely with the enterprise security questionnaire, which overlapped in turn with the enterprise legal questionnaire, so three teams asked three flavors of the same question and everyone waited on three flavors of the same answer. So it drags on intake.
In 2026, the majority of the enterprise AI registry is procured AI. So more likely than not, now you enter rounds of risk mitigation discussions with a vendor point of contact. Your governance team’s attorney reps hedge on issuing their sign off because the liability language, the prior-notice provisions, and the controls they'd recommend all have to be implemented by the business – not by legal – and the governance team that wrote those recommendations has neither the bandwidth nor the mandate to stay and enforce them. The governance team has got the next use case waiting. Nobody is quite sure who owns what happens after the word "approved."
When a company calls me, they usually need help with the wiring. That wiring comes down to four pipes: how a request gets defined, where it routes, what it gets measured against, and who owns turning the policy at the top into a real control at the bottom. These pipes like getting clogged. Organizations who make these four decisions never have to relitigate it on a Tuesday afternoon with six people and a shared calendar.
Pipe 1: Unit of inventory and review
Before you can route a request, you have to agree on the thing you're routing. This decision sets the shape of your entire intake and review process.
Imagine you receive a request for AI in advertising production. Is the use case the system, Photoshop's generative fill on its own? Or is it the business workflow, advertisement development for a single campaign, where Photoshop and Autodesk Maya's AI features get approved together but only for that team on that one social media campaign?
You say yes. What exactly did you bless? AI used in that way for that campaign, or that campaign plus every one after it? For this product line, or every product line you sell? Does your yes stretch to the People team running the same tools for recruiting promotions?
Every one of those answers is defensible. I've watched dozens of companies land in slightly different places over the years. I find that the ones that run smoothly aren't the ones who found the "right" boundary (I’m not convinced there is one). They're the ones who chose a boundary deliberately and got every reviewer to agree to it.
Your use case definition dictates how you word your questionnaires and how you wire your routing. Leave it vague and your inventory turns into a mish-mash of different things, with redundant submissions piling up faster than anyone can clear them, a separate ticket for hundreds of agents embedded in Oracle Fusion or thousands of Claude connectors and skills.
Pipe 2: Reviewer routing logic
Most of the six weeks typically hides here, and it is the most fixable thing on this list. What you want is routing that fires the instant a request lands: it goes straight to the handful of reviewers it needs and bothers no one else. That is only possible if Privacy, IP, Security, Procurement, and Technology have agreed on the logic in advance, instead of pushing to the cross-functional committee on every ticket and discovering halfway through that two of them never needed to be in the thread.
Perhaps InfoSec reviews an Anthropic-hosted Claude connector and signs off. Treat that as an approved pattern, not a single closed ticket. When the next Anthropic-hosted connector comes through, it should not reopen the infrastructure question that's already been answered; what's left is narrow and specific, namely which data sources this particular use case will reach. So it routes to IP Law alone, at the use-case level, on that one question, and the rest of the committee never sees it.
I can think of hundreds of patterns like that inside a single enterprise. It’s not easy to codify them all, but in my experience it is worth the effort to try. Your committee stops rubber-stamping the requests that already match a known-good pattern, which is routinely half the queue, and spends its attention on the novel ones that have earned it.
The catch is that none of this works until the reviewers sit down together and agree on the logic. Everyone wants to buy the automation, but there can be no automation until you’ve done the sit-down.
Pipe 3: Enterprise AI dashboard data
Leadership often asks for an AI risk dashboard before the data underneath it can support one. No one ever has perfectly clean data, and stalling until you do just means no insight at all, so you start with what you have.
That said, you do need trust in the fields that matter. If you can't believe your own Low/Medium/High risk classification, the chart built on it is a very expensive mood light, and the danger is that people steer by it anyway. A common example I see is use case return-on-investment (ROI). I’ve not yet come across an organization with a standardized enterprise-wide framework for ROI-sizing and known data sources for cost information mapped to use cases. The value is especially hard to measure in the age of agentic AI. Yet many AI registry owners are expected to show use case distribution by ROI.
You unclog this pipe by getting the first two right. Define what a submission is and what metadata it carries, pull that into your governance tooling, and you have a foundation an inventory can actually stand on. Solve routing and you also know who's meant to review each use case – now you also have throughput and cycle-time data. A dashboard should be what you can finally see once the plumbing underneath is robust.
Pipe 4: Ownership for risk mitigation and acceptance
A security board asks a product owner to "implement appropriate content filtering". The owner doesn’t know what the engineer needs to build. The fix seems clear: write up a definition of done, "we need outputs A, B, and C, evidenced this way," an artifact one team can build to and another can verify.
This isn’t difficult to write, but it stalls due to ownership: it’s undecided who produces the definition, or who checks the work against it once the use case goes live. The control gets recommended at the policy level and then falls into a gap, too operational for the governance team that named it, not specified enough for the people who are supposed to implement it.
More likely, this is vendor-provided AI, where this problem sits outside of engineering. Governance says the vendor contract needs a clause requiring prior notice if the vendor swaps out the backend model. This is reasonable. Now, can Legal sign off as soon as they’ve informed the business owner they’ll need the clause? Or does legal hold their approval until the clause actually shows up in the draft contract? Does the governance team get into the specific language and stay looped into contract iterations?
That's the pipe. Ownership around who turns a policy requirement into a specific control, and who confirms it got done well. Leave it undefined and "approved" carries no real weight, because no one is clearly on the hook for what comes after it.
The payoff
These four pipes are organization-level definitions and agreements, made once, by the right people. Governance programs should periodically revisit them as new patterns emerge in what AI employees are requesting and the risks they carry.
In my experience the teams that move fastest don't have looser standards or smaller risk appetites. They have just fixed the plumbing, so the standard runs at the speed of the business, instead of the speed of an inbox.
Looking for support with your AI governance plumbing? My Credo AI Advisory colleagues and I would love to learn how we can assist.
DISCLAIMER. The information we provide here is for informational purposes only and is not intended in any way to represent legal advice or a legal opinion that you can rely on. It is your sole responsibility to consult an attorney to resolve any legal issues related to this information.
