When something goes wrong with an AI system, the first serious conversation is always the same.

Someone from compliance or legal asks: “Why was this decision made?”

And here’s what usually happens: nobody knows. There’s no record. Someone on the team vaguely remembers discussing it. There are emails somewhere, but they’re scattered. There’s a Slack channel that got archived. The person who made the decision left six months ago.

And now you’re in a room having a retroactive argument about whether the decision was reasonable, when nobody can actually remember what the reasoning was.

This happens because organizations don’t build decision audit trails. They build decision-making processes—governance boards, approval workflows, documentation templates—but they don’t track what was actually decided and why.

The difference matters.

Why This Matters

A decision audit trail is a record that says: “On this date, we decided to deploy this model. Here’s why we thought it was a good idea. Here’s what we were concerned about. Here’s what we decided to do about those concerns. Here’s who signed off. Here’s when we said we’d review this decision.”

That record is valuable for three reasons:

First, it’s legally defensive. If the model causes harm and someone asks “did you make a reasonable decision to deploy this,” you can point to the record and say “yes, here’s the reasoning, here’s the concerns we identified, here’s what we did about them.” That’s the beginning of a credible story. Without it, you’re arguing retroactively, and you’re at a disadvantage.

Second, it’s organizationally honest. A decision audit trail forces you to be explicit about trade-offs. You can’t just say “we decided to go ahead.” You have to say “we decided to go ahead because X was more important than Y, and here’s why.” That conversation is uncomfortable, which is why most organizations avoid it. But it’s where the real thinking happens.

Third, it’s operationally useful. When you’re reviewing a model six months later and something’s not working, a decision audit trail tells you what you were thinking about at the time. Maybe you were concerned about data drift—and you should have been, because now you’re seeing it. That tells you that your monitoring should have caught this, and it didn’t. That’s valuable information about what went wrong operationally.

What It Looks Like

A decision audit trail doesn’t need to be complicated. For a model deployment, it might look like this:

Decision: Deploy the demand forecast model to production for the northeast region.

Date: November 2024

Who: VP of Operations, Chief Data Officer, Finance Director

Rationale: The model improves forecast accuracy by 12% vs. the manual process, reducing inventory carrying costs. We project ROI of $2.3M annually with a payback period of 8 months. Production deployment is justified.

Key concerns raised: – Accuracy is good, but it’s not perfect. What if the model fails and we stock the wrong inventory? – We haven’t seen this model perform in all seasons. We have 18 months of data.

How we addressed concerns: – We’re deploying to one region first. If accuracy degrades, we can roll back without major impact. – We’re monitoring forecast accuracy weekly and will escalate if it drops below 85%. – We’re running a manual review process for orders above $1M, at least for the first 90 days.

Decision: Proceed with phased deployment.

Review schedule: 90 days (go/no-go decision), 6 months (full rollout decision)

That’s it. It’s specific. It shows that real thinking happened. It shows that someone considered the downside. It shows what you’re actually monitoring. If something goes wrong, it’s not “we made a reckless decision.” It’s “we made a decision with these safeguards and the safeguards didn’t work as expected.”

The second one is a defensible story. The first one is not.

The Missing Piece

Most organizations have governance processes that feel like they’re creating decision records. They have approval workflows. They have sign-off sheets. Someone’s responsible for documentation. But none of that actually creates a decision audit trail.

A decision audit trail requires capturing:

1. What decision was being made
2. Why it was a good idea (the business case)
3. What could go wrong (the risks)
4. How you’re going to detect if it’s going wrong (the monitoring)
5. What you’ll do if it is going wrong (the contingency)
6. Who owned the decision

Most organizations capture maybe two of these. Number 3 and 4 are usually missing.

And because they’re missing, you end up with a situation where you thought you were monitoring something, but you weren’t. Or you thought you had a contingency plan, but the plan depended on someone who’s no longer here.

How To Build It

If you don’t have decision audit trails, start with the consequential decisions.

Not every decision. You don’t need a decision audit trail for “which hyperparameter value should we use for this test.” You do need one for “should we deploy this model to production” and “should we increase our confidence threshold on this model” and “should we change the fairness criteria we’re using.”

The template can be simple. One page. Five minutes to fill out. The point is not to create bureaucracy. The point is to answer the question: “Why did we make that choice?”

And to answer it not retroactively, but at the time, when the thinking is fresh and the reasoning is real.

The Conversation You Need To Have

When you ask “do we have a decision audit trail for this,” and the answer is no, that’s information. It means you don’t actually know why you made the decision you made. You can construct a story now, but you’re probably wrong about some of it.

That’s worth fixing. Not because regulators will ask, though they might. But because when something goes wrong, the first thing you should be able to do is point to the decision record and say, “Here’s what we were thinking about. Here’s what we got wrong. Here’s what we should have been monitoring. Here’s what we’re doing about it now.”

That’s the conversation that leads to change. The conversation where you don’t know what you were thinking, and you’re constructing stories now—that’s the conversation that leads to friction and defensiveness.

Build the audit trail while the decision is fresh. It takes five minutes. And when something goes wrong, it’s the most valuable document you have.

You have a great AI idea.

It’s technically sound. Your team built something that works. It solves a real problem. Everyone who uses it agrees it’s better than the alternative. The ROI is clear.

And six months after you deploy it, adoption is 20% of what you predicted. People aren’t using it. Or they’re using it in ways you didn’t expect. Or they’re using it for a week and then going back to their old tools.

Most organizations blame the idea. The idea wasn’t as good as they thought. Or the team didn’t build it right. Or the users weren’t ready.

Sometimes those explanations are right. Most of the time, they’re wrong. The problem is not the idea. The problem is implementation.

The Paradox

Here’s the paradox that most technical organizations miss: the better your idea, the more adoption risk you have.

The reason is that good ideas usually require people to change how they work. Great ideas require change. If your AI system cuts the manual work out of a process by 80%, that’s a great idea. It’s also a great change management challenge, because someone’s job, or a big part of their job, just got easier. They used to spend four hours a day on that work. Now they spend forty minutes.

How are they supposed to feel about that?

The answer, usually, is ambivalent at best. Some people are thrilled. Some are worried about whether they’ll still be needed. Some actually liked the routine of that work and are now bored. Some were using that time to procrastinate on harder work and now they have to actually do the hard work.

You built a great solution to a technical problem. You didn’t build a great solution to an organizational problem.

Organizations that struggle with AI adoption usually solve this wrong. They assume the problem is education. So they build training. They assume the problem is visibility. So they build dashboards. They assume the problem is trust. So they add more explanation to the model. None of these actually solve the adoption problem.

The adoption problem is solved by implementation.

What Implementation Means

Implementation is not deployment. Deployment is “we built it and we turned it on.” Implementation is “we worked with the teams affected by this change to understand what they need to do differently, helped them do it, monitored whether they did it, and adjusted.”

It’s work. It’s not automated.

Here’s what it looks like:

Identify whose work is changing. Not in the abstract—specifically. “This AI system will change the work of claims adjusters,” okay. Now identify which claims adjusters, what their current process looks like, what their incentives are, what they care about.

Understand what they lose. This is the step organizations usually skip. They focus on what people gain (they spend less time on manual work, they’re more accurate). They don’t focus on what people lose. Maybe they lose autonomy. Maybe they lose the feeling that they’re doing a skilled job. Maybe they lose the informal decision-making power they had. Understanding what people lose is where you find the real adoption barriers.

Design the new process with them. Not for them—with them. If your AI system takes a claims adjuster from manual review of claims to validating AI decisions, what does that role actually look like? Do they trust the AI immediately, or do they need time? How much validation do they need to do? What happens if they disagree with the model? Where do they escalate? You can’t answer these questions in a conference room. You answer them with the people who are going to do the work.

Implement in phases. Don’t turn the model on for all claims. Turn it on for 10%. Let the claims adjusters work with it. Let them get confused, ask questions, figure out what works. After a month, turn it on for 25%. Now they have some experience. After three months, wider rollout. This is slow. It’s also how you avoid the six-month “adoption is 20%” problem.

Monitor what actually happens. You probably have metrics on whether the model is being used. You probably don’t have metrics on whether people are adopting it. Are they trusting it more over time, or less? Are they using it as you intended, or in workarounds? Are they starting to rely on it, or are they going back to manual review? You should be able to see these signals. If you’re not, you’re missing where adoption is actually failing.

The Uncomfortable Conversation

The reason this doesn’t happen more is that implementation requires something most technical organizations aren’t good at: change management people.

I don’t mean change management theory. I mean people who can spend a week with a team of claims adjusters and understand, deeply, what their concern is. Not fix it remotely. Sit with them. Understand it. Build solutions together. That’s expensive, and it requires interpersonal skill that some technical teams find uncomfortable.

Most organizations underinvest in this part. They hire a change management consultant, who writes a 50-page change management plan. That’s not implementation. That’s theater. Implementation is the hard work of actually helping people change.

If You Want Better Adoption

Start before deployment. Figure out whose work is changing and spend time understanding what they care about. Not what you think they should care about. What they actually care about.

Then, when you deploy, do it with them. Not to them. With them. They should be the experts on whether this is actually working. You’re the expert on the technology. Together, you’re building something that works.

And don’t measure success by “is the model being used.” Measure success by “are people’s jobs better, and are they choosing to use this because it makes their life easier, not because we told them to?”

Most AI projects fail not because the technology is bad. They fail because implementation is an afterthought. You built the machine. The machine works. But you forgot to teach people how to work with machines.

That’s the kind of problem that no amount of technical excellence can fix.

There is a quiet, significant problem emerging in global AI governance that most enterprise leaders haven’t fully reckoned with yet.

It’s this: different jurisdictions are making different rules, and those rules are creating incentives that don’t align with good AI governance. These are emerging patterns and observations, not predictions—regulatory landscapes remain highly uncertain.

This is not new. We’ve seen it in data privacy (GDPR vs. state-by-state US regulation vs. no regulation in some jurisdictions), in financial services (different countries have different capital requirements, different lending regulations), in environmental compliance. But in each of those domains, organizations eventually learned to operate or consolidated around the strictest requirements.

With AI, the governance picture is different. It’s more fragmented, the rules are less settled, and the cost of compliance in different jurisdictions is much higher. The result is regulatory arbitrage—situations where global enterprises can choose which rules they want to follow, based on which jurisdiction they operate in, and that choice has material impact on their risk profile and their competitive position.

What This Looks Like

The EU is implementing the AI Act. It has risk tiers, requirements for high-risk systems, documentation mandates, audit trails. It’s comprehensive and it’s coming.

The US has sector-specific guidance (from the SEC on AI risk disclosure, from OCC on model risk management, from FTC on bias) but no unified framework. It’s fragmented, and the rules are softer.

The UK is taking a “principles-based” approach—you should follow these principles, but we’re not going to prescribe how. Even softer.

China is taking a content-control approach, focused on the model’s outputs rather than its governance. Different problem entirely.

For a global enterprise, this creates an obvious problem: you can’t have one governance framework if different jurisdictions require different things. But you can make architectural choices about where systems run, where data is processed, and which governance structures you invest in.

Here’s the incentive that emerges: invest heavily in EU-grade governance if you’re primarily serving EU customers, because you have to. Invest lightly in US governance, because you don’t have to and the rules are unclear. Operate the same systems differently in different regions, or operate systems in less-regulated jurisdictions with lower governance standards.

This is regulatory arbitrage. And it creates real problems.

The Three Kinds of Problems This Creates

First, it creates governance inconsistency. A multinational enterprise might have two identical AI systems doing identical jobs in two different regions, governed completely differently. One has quarterly bias audits and explicit decision appeals processes. The other doesn’t. Why? Because it can. This isn’t sustainable as an ethical matter, and it’s not sustainable as a legal matter. Eventually, one of the looser regions will have an incident, and the question will be “why didn’t you use the governance structure you were using elsewhere?”

Second, it creates incentive misalignment. If the cost of operating a high-risk AI system is significantly lower in Region A than Region B, organizations will route decisions through Region A. Not explicitly—nobody makes that decision consciously. But the incentives point that way. If your customer base is split between regions, and your finance team says “governing this system for the EU costs 40% more,” your product team will find reasons to process more decisions in less-regulated regions.

Third, it creates a coordination problem. Imagine you’re a financial services company operating globally. The GDPR required privacy-by-design, and you built that into your systems. The EU AI Act requires transparency and explainability. You’re building that in. But a competitor in a less-regulated market is not. They’re shipping faster, with lower compliance costs. They have an advantage. The only way to level the field is if everyone plays by the same rules. But that’s not happening.

Why This Matters

The stable outcome is likely to be that global enterprises operating in multiple jurisdictions consolidate around the strictest requirements. This happened with privacy. It’s happening with financial regulation. It may happen with AI, eventually.

But not before there’s a transition period—maybe a long one—where different organizations make different governance choices based on where they operate. And not before the looser jurisdictions either tighten their rules (expensive, usually late), or the strict jurisdictions’ rules leak out to everyone (through litigation, customer pressure, reputational risk).

The other stable outcome is fragmentation: different enterprises follow different rules, and the market becomes harder to coordinate. This is expensive and it’s unstable.

What To Do

If you’re a global enterprise, this is not something you can solve unilaterally. But you can do some things:

First, assume that looser rules now become stricter rules later. Build for the strictest jurisdiction you operate in, globally. This is the bet that the EU rules will eventually become standard. You might lose near-term speed. You won’t have to rebuild later.

Second, don’t create policy gaps. If you have different governance structures in different regions, document why. Make the decision explicitly. “We’re using lighter governance in Region A because regulation is lighter” is a defensible decision. “We accidentally built different systems” is not.

Third, participate in governance conversations. If you operate globally, you have influence in these conversations. You have standing to say “here’s what companies need to operate effectively” or “here’s what we’ve learned works well.” Use it. The alternative is waking up in five years with incompatible rules that cost you more than they would have cost now.

Fourth, watch the frontier. The organizations that will win are the ones that see regulatory change coming and adjust before they have to. The ones that will struggle are the ones that optimize for today’s rules and then have to retrofit.

The Conversation Worth Having

If you operate globally, your risk and compliance teams should be having regular conversations about regulatory divergence. Not “what are the minimum rules we need to follow?” but “what rules are converging and what rules are diverging, and what does that mean for our architecture?”

The organizations that are ahead right now are the ones that made governance choices years ago, before the rules were clear, and those choices happen to align with what regulators are now requiring. That’s luck. The ones that will be ahead in five years are the ones that assume luck won’t last, and are building accordingly.

Regulatory arbitrage is a real phenomenon. The question is whether you’re going to let it shape your strategy, or whether you’re going to choose your governance standard and stick with it globally.

You have metrics. Good ones, probably. Your recommendation model has a 94% NDCG. Your classification model has an F1 of 0.87. You’re tracking precision, recall, AUC. You’re measuring fairness. You have dashboards.

Your CFO does not care about any of this.

It’s not that your metrics are wrong. It’s that your CFO cares about different metrics, and most technical organizations have missed the gap. When you show someone “our model improved precision by 3 percentage points,” what they hear is “we spent six months optimizing something abstract.” When they ask how much money that’s worth, you don’t have a good answer. And that disconnect—between model performance and business performance—is where most AI projects end up trapped.

What Your CFO Cares About

Your CFO cares about:

Conversion: Did the AI initiative result in more revenue, or cut costs?

Risk avoidance: Did it prevent something bad from happening? How much?

Velocity: Did it let us do something faster, so we could do more volume?

Margin: Did it improve the margin on existing business?

Each of these is measurable. None of them are “model F1.”

Consider a recommendation model. Your metric might be “NDCG improved from 0.72 to 0.75.” Your CFO’s metric is “users who saw the new recommendations bought 6% more than users who saw the old ones.” Different thing entirely. The F1 improvement was necessary to get there, but it’s not what matters to the business.

Or a fraud model. Your metric is “we improved true positive rate from 87% to 91%.” Your CFO’s metric is “we caught $2.3 million in fraud last quarter, compared to $1.8 million the quarter before.” Or better: “the cost of the false positives we generate (customer friction, manual review) is lower than the cost of fraud we miss.”

The pattern is the same: your metrics are leading indicators. His are lagging indicators. And lagging indicators are what determine whether you keep funding the project.

Why Most Organizations Have This Wrong

There are a few reasons technical teams and business teams measure different things.

First, your metrics are available. You have access to model performance data. You’re logging predictions. You’re measuring holdout accuracy. You’re not necessarily inside the business system where you can see whether recommendations turned into purchases or whether avoided fraud created margin.

Second, your metrics are crisp. “F1 of 0.87” is unambiguous. “The model prevented fraud” is less so. You have to create attribution models, control groups, have arguments about whether the model or the sales team or the pricing change drove the improvement.

Third, most data teams assume that model performance maps to business performance. If the model is better, the business outcome will follow. This is usually true. But not always. And the gap—between a technically excellent model and a model that actually moves the needle for the business—is where most projects stall.

Fourth, measurement is political. If you own the model, you want to measure things that show the model in a good light. If you’re part of the business, you want to measure things that show you created value. If those measurements are different, there’s room for disagreement. It’s safer to stick to model metrics.

How to Translate

This is not actually that hard to fix. It requires being intentional about what you measure.

Start by defining the business question clearly: What would success look like? Not “the model is accurate.” What does accurate actually deliver? Is it more revenue? Less risk? Faster processing? Happier customers?

Then translate that into a measurable outcome.

If the business question is “should we use this model for recommendations,” the success metric is not “NDCG > 0.75.” It’s “users who see AI-recommended products have 15% higher conversion rate than users who see non-AI recommendations, measured over 30 days.” Now you have something testable and something that connects to revenue.

If the business question is “should we use this model for loan approvals,” the success metric is not “F1 > 0.85.” It’s “loan defaults decrease by 5% and loan volume increases by 10% when we use the model vs. traditional underwriting.” Now you have something that matters to the CFO.

The way to get there is via A/B test. Take your model. Put it in production for a subset of users or transactions. Measure what actually happens. Not “does the model work,” but “does deploying the model change behavior in the direction we want?”

The Conversation That Actually Matters

Here’s what this looks like as a conversation:

You come to the CFO and say: “I want to build a demand forecast model. Here’s what we’ll measure: does it reduce inventory carrying cost by more than the cost of the model?”

That’s a conversation. The CFO can engage with “well, what’s the cost of the model, and what’s the typical carrying cost?” and “do we have confidence those numbers are right?” and “how would we validate this?” Now you’re talking the same language.

You come with “the model has RMSE of 12.3%,” and the CFO does not know how to respond. She doesn’t know if that’s good. She doesn’t know if it’s worth investing in. She ends up saying “sounds nice, let’s see if it works,” and six months later you’re having a frustrated conversation about why the demand forecast project never got follow-up investment.

Most technical AI projects stall because nobody defined the business metric first. Everyone agreed the model should be accurate. Nobody agreed what accuracy delivers or how to measure whether it delivered.

The Fix

If you have AI projects that feel stuck, this is a diagnostic question: Can you answer this quickly and concretely: “If we deploy this model, what business outcome will improve, and by how much?”

If you can’t, that’s not a technical problem. That’s why it’s stuck.

If you can, but your CFO is still skeptical, that’s different. That’s a risk conversation. But at least you’re having a conversation about something real.

Your model metrics are important. But they’re not what determines whether your organization keeps funding AI. The business metrics are. Measure those first.

Production AI systems fail. They fail more often than most organizations expect, and usually in ways that don’t fit standard operational risk frameworks.

The problem is that most enterprises have built operational disciplines around traditional software failures: crashes, latency spikes, data corruption, security breaches. These are discrete, observable, alarming. When they happen, everyone knows immediately. Your pager goes off. You have a post-mortem. You fix it.

AI systems fail differently. And most organizations are only built to catch one of the three types.

Type One: The Model Fails You Already Monitor For

This is the one you’re probably already built to catch. The system goes down. The API returns errors. Inference latency spikes to ten seconds. The model crashes under load.

These are traditional operational failures, and you have patterns for them. Your monitoring catches them within minutes. Your escalation process kicks in. You know something is wrong.

The example is straightforward: A recommendation model’s serving infrastructure runs out of memory. The API returns 500 errors. Your monitoring alerts. You page the team. You either restart the service or roll back the model version. Problem solved.

This is the easy case. Most organizations have something like this covered.

Type Two: The Model Works, But Silently Produces Bad Results

This is the one that keeps security and compliance people awake.

The system is up. It’s returning predictions. It’s not throwing errors. But the predictions are wrong, or biased, or systematically misleading. And you don’t know for hours, or days, or sometimes longer.

The example: A loan approval model systematically rejects applications from a particular geographic area, not because of the features you fed it, but because of a proxy correlation in your training data. The model is working exactly as trained. It’s not crashing. Your monitoring shows normal latency, normal throughput. But it’s making unfair decisions at scale.

You don’t find this out when it happens. You find it out when someone does a statistical audit, or when a complaint comes in, or when a regulator asks. By then, you’ve approved three thousand loans with the bias baked in.

Most organizations don’t have good monitoring for this. Why? Because it requires something different from traditional observability. You need a baseline understanding of what “correct” looks like, and continuous measurement of whether your model’s outputs are staying within that baseline.

For some models, this is hard. A recommendation system’s “correct” is fuzzy. A language model’s “correct” is even fuzzier. But for consequential models—loan decisions, hiring, resource allocation—you should know immediately if the distribution of predictions is shifting, if certain cohorts are being treated systematically differently, if accuracy is drifting.

Most don’t.

Type Three: The Model Fails In Production But Passed Testing

This is the rare, terrifying one. It’s what happens when your model behaves well in the test environment and completely differently in production.

Why does this happen? The training data distribution doesn’t match production data distribution. A feature that was engineered correctly in the test pipeline is calculated differently in production. The feature store returns different values in different environments. The model is exposed to input patterns it never saw in training—because training was on historical data, and the world has changed.

The example: A fraud detection model is trained on six months of historical transactions. It works great in testing: 94% accuracy. Then you deploy it to production, and it catches a different type of fraud that wasn’t prevalent in your training data. You miss fraud from the new pattern because your model was never exposed to it. Or worse: the real world is different enough that your accuracy drops from 94% to 68%, and you don’t realize it for weeks.

Type Three failures are the hardest to defend against, because they require admitting that your test environment and your production environment are fundamentally different. Most organizations assume they’re the same until they’re proven wrong.

How to Guard Against All Three

Type One requires what you probably already have: infrastructure monitoring. Uptime, latency, errors. Standard DevOps. Keep doing that.

Type Two requires model monitoring. This is not the same as infrastructure monitoring. You need:

• Baseline distributions. What should your model’s predictions look like? For a loan approval model, what’s the expected approval rate, and what’s the expected distribution across geographies, income levels, and credit score ranges?
• Continuous measurement. Every hour, measure whether the actual distribution matches the baseline. If approval rate shifts from 42% to 48%, that’s an alert. If approval rate for one geographic region shifts while others stay stable, that’s an alert.
• Cohort monitoring. Slice the data by sensitive attributes and measure whether accuracy or fairness is stable across cohorts. This is especially important for models that touch protected classes.

This requires investment, but it’s not exotic. It’s measurable and defensible.

Type Three requires something harder: honesty about the difference between test and production. You need:

• Production validation. After deployment, validate the model against a hold-out test set from production data. Don’t wait a month. Do it after a week. If accuracy drops materially, you have a problem.
• Feature validation. Measure the distributions of features in production vs. training. If a feature that was normally distributed in training is bimodal in production, you’re in a different world than you thought.
• A rollback plan. If production accuracy is materially worse than test accuracy, you should be able to roll back quickly. Most organizations don’t build this. They assume it won’t happen.

Why This Matters

Most operational incidents in AI aren’t the dramatic failures. They’re the silent ones—the ones where the system is working perfectly, by the metrics you’re monitoring, but producing wrong answers for real people.

If you’re only guarding against Type One failures, you’re vulnerable to the other two. And the other two are more common than you think.

Start with Type Two monitoring. It’s the one you can implement immediately, and it’s the one that will catch the most common failures. Type Three requires more organizational change, and it requires admitting that your test and production environments might not be as similar as you assumed.

But if you’re running a model that touches loan decisions, hiring, benefits eligibility, or any other decision that affects people’s lives, Type Three monitoring is not optional. It’s just a matter of when you’ll wish you had built it.

There is a moment, early in AI adoption, when a decision gets made that looks small at the time.

It’s not a decision about which model to use. It’s not about governance structure or hiring. It’s about architecture. Usually it gets made by a technical team, noted in a meeting, maybe documented somewhere. The decision is: Where do we put this model? Do we build it ourselves, or do we use the vendor’s platform?

This decision will cost you millions.

Most organizations make it wrong, without realizing it’s the decision they’re making at all. They start using a vendor’s AI platform—whether it’s a CRM provider’s AI features, a data platform’s ML tools, or cloud AI services from a hyperscaler. It’s the easy path. The vendor handles the infrastructure. The model gets deployed in weeks instead of months. You’re running. You look like you’re moving fast.

Then, five years later, something changes. You’ve built your business around that vendor’s model serving layer. Your data pipelines feed into their architecture. Your applications are integrated with their APIs. Your teams know their tools. And you realize you’re locked in. You want to move to a different model, or a different vendor. It’s technically possible. It’s just expensive. Maybe hundreds of millions expensive, depending on your scale.

You’ve created technical debt so deep that switching isn’t a business decision anymore—it’s a strategic bet.

How This Happens (Without Anyone Meaning For It To)

The reason this happens is not malice. It’s not even vendor lock-in in the traditional sense. It’s compounding convenience.

Day one, you adopt a vendor’s platform because they have the best model for your use case. Smart decision. Day 30, you wire your data into their infrastructure because that’s where the model lives. Makes sense. Day 60, you build a second model on the same platform because you’re already there, and moving the first one would be chaos. Still reasonable.

By month eighteen, you have seventeen models running on that vendor’s infrastructure. Your data team knows the vendor’s APIs. Your DevOps team understands their monitoring. Your compliance team understands their audit trail. You’ve solved all the hard problems using their tools. The cost of moving is not the cost of migrating one model. It’s the cost of rebuilding your entire AI operating system on new infrastructure.

And the vendor knows this. Not because they’re sinister. Because they’ve seen it a hundred times. They don’t need to lock you in. They just need to be the default until it costs too much to change.

What This Costs

The most visible cost is money. If you’ve built on your data platform’s vector search and you want to switch to a different vector store, or if you’ve built on your CRM vendor’s prediction serving and you want to move to open-source, you’re rewriting years of integration. You’re retraining your team. You’re building new monitoring, new audit systems, new deployment pipelines.

At enterprise scale, this is eight figures. Sometimes nine.

The less obvious cost is velocity. During the transition—which takes a year or more—you can’t update your AI infrastructure confidently. You can’t adopt new techniques because you don’t know if they’ll work in both the old and new systems. You’re operating in a carefully managed state of semi-paralysis. Your competitors, who made different architecture decisions, are moving faster.

The strategic cost is control. If a fundamental shift in the AI landscape happens—if there’s a new model family that’s meaningfully better, or a new architecture pattern that changes the economics of AI, or a regulatory requirement that changes how you need to serve predictions—you have to evaluate whether it’s worth moving. And you usually conclude it’s not, because the switching cost is too high. So you stay on a legacy architecture longer than you should.

The Decision That Matters

Here’s what this looks like as a decision: Do you build an abstraction layer between your applications and the model serving infrastructure?

If you do, switching vendors costs the same as switching databases. Annoying, but doable. Your applications talk to your abstraction layer. Your abstraction layer talks to any inference infrastructure. You can swap the infrastructure underneath without touching application code.

If you don’t, your applications talk directly to the vendor’s serving layer. Switching costs much more, because now application teams have to learn new APIs, integrate new authentication, handle new failure modes.

The abstraction layer costs more up front. You’re not using the vendor’s native optimization. You’re solving problems twice. The vendor does most of the work for you in their platform; with an abstraction layer, you’re doing that work yourself.

Most teams skip it because of this cost. It’s the wrong calculation.

What To Do About It

If you’re starting your AI program now, here’s the straightforward version:

Build your own model serving layer, even if it’s thin. Or use an open-source serving platform (vLLM, Ray Serve, BentoML, TensorFlow Serving) and commit to it. Wire your applications to talk to your serving layer, not the vendor’s. Use the vendor’s platform for fine-tuning, for training, for data preparation. Don’t use it for serving.

The cost is real—maybe 15% slower inference, maybe more engineering overhead. But the switching cost if you need to move drops from nine figures to one. Your ability to adopt new models without a five-year migration project improves dramatically.

If you’re already locked in—if you’ve already built seventeen models on one vendor’s infrastructure—here’s the harder conversation: Accept that you’re going to stay there for a while, but start building an abstraction layer for new models. Don’t migrate the old ones. But new models go into the abstraction layer first. In five years, you’re a hybrid. In ten, you could switch.

Why This Matters To You

Most boards don’t think about architecture. Architecture is a technical detail. But architecture creates lock-in, and lock-in creates cost, and cost constrains strategy.

When you’re evaluating AI spending in five years, and it looks higher than you expected, and someone asks why you can’t just switch to a cheaper model serving platform, the answer is going to be “because of a decision we made in 2026 and never revisited.”

This decision doesn’t need to be made by a board. But it should be made consciously, by someone who understands that convenience today is strategy tomorrow.

Most boards have risk appetite statements. Most are useless.

They sit in governance documents, drafted by compliance and risk teams, worded so generically that any outcome could be called compliant. “We maintain a balanced approach to risk while pursuing innovation.” “We accept calculated risks that support strategic objectives.” When the problem arrives—a model fails, a bias issue goes public, a regulatory question gets serious—nobody points to that statement and says, “Ah, yes, this is exactly what we authorized.”

That’s not a risk appetite statement. That’s security theater.

A useful risk appetite statement for AI does something specific: it describes, in operational language, what kinds of failures the organization is willing to experience and what it isn’t. Not failure in general. Specific failure modes. Specific thresholds. Specific trade-offs.

The usual failure is that risk appetite statements are written as aspirations rather than constraints. They describe what the organization hopes to achieve, not what it’s willing to tolerate. A real risk appetite statement for AI should feel, on first read, uncomfortably concrete.

What You’re Actually Deciding

When you set a risk appetite for AI, you’re answering a smaller, sharper question than most boards realize: Under what conditions will we accept outcomes that we wouldn’t accept from traditional systems?

Because AI will produce outcomes that rule-based systems wouldn’t. It will make decisions that are accurate on average but wrong for specific people. It will fail in ways that are hard to predict. It will sometimes work better than legacy alternatives, sometimes worse. You have to decide, in advance, whether you’re okay with that trade-off.

That’s not a philosophical question. It’s an operational one.

Consider hiring. A traditional hiring system is a rubric: minimum GPA, degree from certain schools, years of experience. It’s crude. It misses talented people. But it’s consistent, and when it fails, you know why. An AI hiring system can be more accurate across the population, but for individual candidates, the reasons for decisions are opaque. And it will sometimes make mistakes that a human would catch.

What’s your appetite for that? Not in principle. In practice.

Do you accept a model that’s 5% more effective on average but makes occasional decisions you can’t explain to a candidate? Ten percent more effective? Twenty? And at what accuracy threshold do you switch back to rules? These aren’t theoretical questions. They’re the ones that will matter when the litigation starts.

A risk appetite statement that’s worth something says: “We accept hiring models that outperform our traditional rubric by at least 8% on overall placement success. We do not accept opaque rejections for protected class candidates. We conduct quarterly bias audits and halt model use if disparate impact on any protected class exceeds 3 percentage points.”

That’s specific. It’s defensible. It’s something your board is actually committing to.

The Categories That Matter

Most boards conflate risk appetite across different failure modes. They shouldn’t. An acceptable failure for a recommendation system (wrong suggestion, user ignores it) is not acceptable for a compliance system (false positive, audit cost explodes). An acceptable accuracy threshold for a back-office process (efficiency gains outweigh occasional rework) might be criminal negligence in a loan decisions system.

Your risk appetite statement should separate failure modes by consequence:

Direct customer/citizen impact. Model predictions affect someone directly. Loan decisions, hiring, benefits eligibility, medical triage. The failure mode is accuracy and bias. The question is: what accuracy level is required before we use this, and what disparities across populations do we tolerate? You need a numerical answer.

Operational efficiency. The model improves internal processes—contract review, log analysis, pattern detection. The failure mode is missed problems or rework. The question is: what percentage of errors will we tolerate before we switch back to human review? Not “we’ll monitor it.” What’s the actual threshold?

Strategic/regulatory exposure. The model touches compliance, audit, or regulatory reporting. The failure mode is misclassification with enforcement consequences. The question is: will we accept any error rate, or do we require 99.9% accuracy with human review of all flagged items? Do we get regulatory pre-approval before deploy?

Speed/convenience. The model is faster than the alternative but less certain. Chatbots instead of agents, automated triage instead of manual. The failure mode is a bad experience or escalation. The question is: what escalation rate is acceptable? How much productivity gain justifies how much friction?

Each of these has a different risk appetite. The mistake boards make is writing one statement and applying it to all four.

What Changes When You Do This

Setting a real risk appetite statement for AI changes three things:

First, it forces alignment before deployment, not after. Your board has said what trade-off they’re accepting. When the question comes later—“Should we keep using this despite the bias issue?”—you have a reference point.

Second, it creates clarity on what monitoring you actually need. If your appetite statement says “5% error rate is acceptable,” you build monitoring to catch when you hit 4.5%. You don’t build monitoring for perfection.

Third, it makes decisions delegatable. Once your board has set the appetite, your operations and compliance teams can evaluate models against it without coming back for every decision. You’ve moved from review-based governance to criteria-based governance.

The hard part isn’t writing the statement. The hard part is defending the numbers. Why 5% and not 3%? Why 99%? When someone on your board asks that question and you don’t have an answer, you’ve found where the real decision-making needs to happen.

That conversation should happen before you deploy the model. Not after something breaks.

The Conversation Worth Having

The best risk appetite statements come out of actual tension, not consensus. Someone in the room says, “I’m not comfortable deploying a model with an error rate above 2%.” Someone else says, “Then we can’t compete; the best model we can build is 3%.” That’s a real conversation. The number you land on—2.5%, maybe, with more aggressive monitoring—is worth something because it’s actually contested.

A risk appetite statement that arrived through consensus and compromise is the useless kind. The kind that sits in documents and means nothing when you need it.

Your board should sign off on risk appetite for AI. But make them sign off on something real—specific failure modes, specific thresholds, specific monitoring regimes. Not aspirations. Not hedging language that fits any outcome.

If they won’t commit to specific numbers, that’s information too. It means the organization isn’t actually ready to deploy the model yet. And that’s a decision worth making before you’ve already deployed it.

Your company is probably spending more on AI talent than you think.

Not in salary — though that’s part of it. In what you’re giving up while they’re maintaining the system you built.

This is the cost that doesn’t appear in budgets, but it explains why so many organizations that invested heavily in AI still feel like they’re not getting return on investment.

The context-switching tax

Here’s what usually happens: You hire a strong AI/ML engineer. They join at a critical moment. You have models to build, systems to set up. They dive in.

Six months in, the initial projects are done. The models are built. Things are working.

Now they’re managing the models. They’re monitoring. They’re updating. They’re responding when something breaks.

They’re also doing all the governance work that the previous ten sections have described:

• Maintaining data provenance
• Setting up behavioral monitoring
• Documenting decisions
• Mapping vendor dependencies
• Updating governance when something breaks

This isn’t one job. This is about five jobs. And you probably have one person trying to do it.

The best AI talent doesn’t want to be the everything person. They want to be building.

But they’re not building. They’re in maintenance mode. They’re reading dashboards. They’re writing retrospectives after incidents. They’re answering “why did the model do that” questions for business teams.

If they had capacity to build, they’d be building. They don’t have capacity because the infrastructure around the model requires constant care.

Why traditional staffing doesn’t work

Here’s where most organizations get the math wrong: They think “we need data scientists to build models, and we need one person to maintain them.”

What they don’t realize is that building an AI system that actually works — that is explainable, monitored, governed, accountable — requires way more than one person maintaining it.

You need:

• Someone understanding data provenance and maintaining lineage
• Someone building and maintaining behavioral monitoring
• Someone tracking governance (decisions, escalations, updates)
• Someone managing vendor dependencies and integration
• Someone responding when something goes wrong

These could be one person in a small organization. But they’re usually at least three people in any organization with more than a few models.

And you probably have them all under “one ML engineer” in your budget.

The reason AI projects feel understaffed is usually because they are.

But the reason they’re understaffed isn’t because AI is hard. It’s because organizations don’t realize what “AI working properly” requires in terms of infrastructure.

The burnout pattern

This is where talent costs become really high.

Your AI engineer is doing five jobs. They’re good at maybe three of them. The other two are just work that needs to get done. They’re smart, so they can do it, but it’s not what they want to do.

They’re smart enough to realize they could be doing something else. Something more interesting. Something that builds on their strengths.

So they look. And they find another opportunity. A company that will let them specialize. That will build proper infrastructure so they don’t have to be everything.

You lose the person. You hire someone new. You spend three months ramping them up. They’re immediately in context-switching mode because nobody invested in infrastructure while you had the first person.

The real cost of your AI talent isn’t their salary. It’s the turnover rate. It’s rebuilding the context every time someone leaves.

What you’re actually paying for

When you hire AI talent, you’re not just paying for the code they write. You’re paying for:

Understanding

This is usually 40% of someone’s time — understanding what the models do, what data they train on, what constraints they operate under.

If you don’t invest in explainability and data provenance, understanding becomes a constant burden. If you do, it becomes manageable and new hires can ramp faster.

Maintenance

This is usually 30% of someone’s time — keeping systems running, responding to failures, updating models when something goes wrong.

If you don’t invest in monitoring and governance structures, maintenance is reactive and constant. If you do, it’s more predictable and new people can take on pieces of it.

Context switching

This is usually 20% of someone’s time — explaining to other teams what the model does, answering questions, serving as the expert on call.

If you have documentation, explainability, and governance structures, context switching is reduced. If you don’t, every model decision flows through the person who understands it.

Building new things

This is usually 10% of someone’s time.

This is the part people think their AI talent should be doing. And it’s the part they’re doing least.

The companies that manage this well

The organizations that don’t have this problem usually have made investments that seem excessive for the number of models they have:

Data infrastructure

They’ve invested in versioning, lineage, provenance. It seems like a lot of infrastructure for what looks like it could be manual.

But it means new people understand what data trained models. It means understanding builds on itself.

Monitoring infrastructure

They’ve invested in behavioral dashboards, automated alerting, clear definitions of what “healthy” means.

It seems like overhead. But it means when something goes wrong, it’s detected automatically. It’s not “call the person who understands the model and ask them to look.”

Decision documentation

They maintain decision memoranda. Why was this model deployed? What were the constraints? What would change the decision?

This seems like busywork. But it means when something breaks, the diagnosis is much faster. And it means new people can understand the decisions without having to ask the original decision-maker.

Governance procedures

They have escalation paths, decision authority, update procedures.

These seem like bureaucracy. But they mean that governance doesn’t depend on one person’s understanding. It becomes embedded in how the organization operates.

Organizations that make these investments pay a premium for infrastructure. But they reduce the context-switching tax dramatically.

The AI engineer doesn’t have to be everything. They can specialize. They can focus on what they’re good at. They have space to build.

What this means for budgeting

If you’re budgeting for AI, budget for infrastructure as much as you budget for talent.

The traditional model: One data scientist builds the model. One engineer maintains it.

The realistic model: One person builds the model (or the team builds it). Three to five people work on the infrastructure that makes the model actually work: provenance, monitoring, governance, integration, incident response.

If you underinvest in infrastructure, you will pay for it in talent turnover. The people you hire will be doing five jobs poorly, and they’ll leave.

If you invest properly in infrastructure, you’ll spend more upfront, but your talent will last longer and be more productive.

The long-term math

Let’s say you have one AI person doing everything: building models, maintaining provenance, setting up monitoring, managing governance, responding to incidents.

Their salary is $200k. But you turn them over every 18 months. Onboarding costs $80k (including lost productivity). You actually spend $320k per year per person.

If you invest in infrastructure (engineering for provenance, monitoring, governance), you might spend $400k upfront. But now your AI person can focus on modeling. Their job is more interesting. They stay. You keep the same person for 4 years.

Total cost for 4 years: One person at $200k/year + infrastructure investment ($400k upfront spread over 4 years = $100k/year) = $300k/year.

With turnover: Three people * $320k/year (salary + turnover) = $960k.

The upfront infrastructure investment actually costs less.

Where to start

If you have AI engineers and they seem overstretched, the answer isn’t to hire more AI engineers.

The answer is to invest in the infrastructure that would let the people you have actually focus on their core work:

1. Invest in data provenance systems so understanding is documented
2. Invest in monitoring so maintenance is predictable
3. Invest in decision documentation so context doesn’t live in someone’s head
4. Invest in governance so the same decisions don’t have to be made again

This will cost money. But it will be less than what you’re spending on turnover of good people who got burned out doing five jobs.

The talent cost of AI isn’t the salary. It’s what you’re losing while they’re maintaining a system you didn’t invest in properly.

Most vendor relationships in enterprise AI are built backwards.

The company doing the evaluation has a gap. They need a model. They look at the available options, pick one, and then manage the dependency.

That’s backwards from how it should work. The question isn’t “which model should we buy.” It’s “if we depend on this vendor, what are the constraints that creates, and can we live with them?”

This matters because vendor dependency is actually a governance issue, not a procurement issue.

The hidden constraints of vendor dependency

Here’s a scenario that plays out regularly: A company licenses a foundation model from a vendor. They build applications on top of it. The model works well. Everything’s good for two years.

Then the vendor updates the model. It’s a better model. Stronger performance. But it has different behavior characteristics. It generates outputs that are slightly different. The applications that were built on top of the old model have to be updated.

Or the vendor changes their terms. They used to allow you to run the model internally. Now they want you to use their API. You have to redesign your applications.

Or the vendor stops supporting the version you’re using. They want you to upgrade. The upgrade comes with changes you’re not prepared for.

In each case, the company that built the dependency is now constrained. The vendor changed something. The company has to adapt.

This is fine if you have one model. This is a serious problem if you’ve built dozens of applications on top of the model and that model is embedded in your decision-making processes.

Why this becomes a governance problem

Most companies don’t think about vendor dependency until it’s a problem.

They’re focused on the model’s performance right now. Does it do what you need? Does it have good accuracy? Is it cost-effective?

They’re not focused on the second-order question: What happens if this vendor changes?

By the time that question becomes urgent, the dependency is already deep.

I watched a company build a suite of applications on top of an open-source model. They contributed improvements. They optimized for their use case. Six months in, they had 12 applications in production, all depending on that model.

Then the model’s maintainers made a change. Not a breaking change, exactly, but a change that affected how the model handled certain types of input.

The company had to choose: Spend weeks updating all 12 applications, or fork the model and maintain their own version.

They forked. Now they’re maintaining their own version of a model that’s being actively developed by a community. Their fork diverges. Updates from the community have to be manually merged. New bugs come out of the original model. Do they apply those fixes to the fork?

Within two years, maintaining the fork cost more than building their own model would have.

The company wasn’t paying attention to the governance implications of the vendor dependency. They were paying attention to whether the model worked.

What questions actually matter

The evaluation criteria for any AI platform partner aren’t the ones most companies focus on.

Most companies ask: What’s the model’s accuracy? How much does it cost? What’s the API latency?

These questions aren’t aimed at any specific category of provider. They apply to every AI platform relationship—cloud services, open-source deployments, and proprietary APIs alike. You should also ask:

1) How often does this model change?

And importantly: How do you define a change? Is it just updates to the weights? Does it include changes to architecture? Changes to inputs or outputs?

If you’ve built applications that depend on specific model outputs, and the model changes behavior, your applications might break.

You need to understand the cadence. Is the model updated quarterly? Whenever the vendor feels like it? When there’s a major improvement?

2) What’s your path if the vendor stops supporting this?

Not “if they go out of business,” but if they decide to deprecate this model or change their business model.

Can you download the model and run it yourself? Are there licensing restrictions? If you needed to migrate to a different model, how long would that take?

If the answer is “you’d have to rewrite everything,” you should factor that into your decision.

3) What changes are backwards compatible?

If the vendor updates the model, will your applications still work? Or will you have to retest and redeploy?

Some vendors are thoughtful about backwards compatibility. Others aren’t. If you depend on them, you need to know.

4) What’s the data retention policy?

If you’re using their API, are they storing your data? For how long? What are they using it for?

If they’re using your data to improve their models, that’s fine — but you should know it and be comfortable with it.

5) What happens to my applications if you change your terms?

If they say “we’re discontinuing the API and you have to use our cloud service,” what options do you have?

If they change pricing dramatically, what’s your recourse?

Most vendors won’t want to answer this question directly. But you should ask it anyway.

The vendor as governance decision

Here’s why this matters at the governance level: When you decide to use a vendor’s model, you’re not just deciding on that model’s performance. You’re deciding to accept a set of constraints on your system.

You’re deciding to accept that this vendor can change how your model behaves, and you’ll have to keep up.

You’re deciding to accept that if the vendor’s business changes, you might have to change yours.

You’re deciding to accept that you’re dependent on someone else’s roadmap.

All of these are fine — dependencies are inevitable. But they should be explicit decisions, not accidental ones.

Organizations that handle this well usually:

Map the dependencies

They know exactly which applications depend on which models, and what would happen if those dependencies changed.

Diversify where sensible

If they have applications that could work with multiple models, they build for flexibility. They’re not locked into one vendor.

Maintain fallback options

They have a plan if the vendor changes. Maybe it’s “we’ll migrate to this alternative,” or “we’ll build our own version,” or “we’ll redesign the application.” But they have a plan.

Make it a deliberate choice

When they decide to depend on a vendor, they’re making an explicit decision about the constraints that dependency creates.

What to do if you’re already dependent

If you’ve already built applications on vendor models and you’re realizing the dependency is deep, you can’t undo it quickly.

But you can start:

1. Map the dependencies. Which applications use which models? What would it cost to migrate?

2. Start reducing dependency where sensible. Can you build flexibility into your architecture so you’re not locked into one model?

3. Ask the hard questions. Especially the ones about what happens if the vendor changes.

4. Make explicit decisions about where to accept dependency and where to avoid it.

The companies that end up in bad situations usually didn’t plan for vendor risk. They just picked a model that worked and kept building on it.

The companies that manage vendor relationships well ask the governance questions upfront. They know what constraints they’re accepting. And when things change, they’re not surprised because they planned for the possibility.

I’m going to say something that will sound heretical: The best governance frameworks are the ones most organizations won’t recognize as governance frameworks.

They don’t look like frameworks. They look like a decision. Someone with authority decides whether to use a model. They document why. They monitor it. Something changes, they update the decision.

No committee sign-offs. No tiered approval processes. No model risk assessment templates. Just conscious choice.

The reason most governance frameworks don’t look like that is because they’re designed for the wrong problem.

What frameworks are actually designed for

Most organizations build AI governance frameworks for two reasons:

Reason 1: Audit readiness

They want to be able to show regulators that they have a system. They want processes. They want documentation. They want to demonstrate that they’re taking this seriously.

Reason 2: Risk distribution

They want to distribute risk across multiple people and functions so that nobody bears sole responsibility if something goes wrong. If something fails, there’s a paper trail showing that the model was reviewed, validated, and approved by multiple parties.

Both of these reasons are understandable. Neither of them produces governance that actually prevents problems.

You can tell because most frameworks look the same: A model is proposed. It goes through a validation process (multiple teams review it). It gets approved (often by committee). It’s deployed with monitoring. If something goes wrong, the organization can show the process and say “we did what we were supposed to do.”

The problem is that this process doesn’t actually prevent bad decisions. It just documents that a process existed.

The framework that doesn’t prevent problems

Here’s a concrete example: A company built an AI governance framework with five layers of review:

1. Data quality review (is the training data sound)
2. Model validation review (does the model perform as expected)
3. Fairness assessment (does the model produce disparate impact)
4. Business impact review (does deploying this make sense)
5. Executive approval (final sign-off)

On paper, this looks comprehensive. In practice, it was almost useless.

Here’s what happened: A model came through for approval. The data quality team reviewed it and approved it. The validation team checked the metrics and approved it. The fairness team looked at aggregate statistics and approved it. The business team saw revenue potential and approved it. The executive signed off.

The model got deployed. Within months, it was producing outcomes that everyone could see were problematic. The model was systematically making worse decisions for a specific population segment.

Then the conversation went:

• “The fairness team reviewed this.”
• “Yes, we looked at the aggregate statistics.”
• “Did you notice the disparate outcomes?”
• “No, the aggregate statistics looked fine.”
• “The model is producing disparate outcomes.”
• “Then the environment changed, or we made a wrong assumption.”
• “Your approval was supposed to prevent this.”
• “Our approval was that we followed the process.”

In the end, the governance structure had done exactly what it was designed to do: document that a process existed and distribute responsibility across multiple parties.

What it hadn’t done: actually prevent a bad outcome.

Why the framework didn’t work

The framework failed for a specific reason: Nobody at any step had the authority or responsibility to say “I’m uncomfortable with this, and we’re not deploying it until I understand why.”

Each reviewer had a specific domain: – Data quality: “Is the data clean?” Yes. Approve. – Validation: “Does the model perform?” Yes. Approve. – Fairness: “Do the aggregate statistics look ok?” Yes. Approve. – Business: “Is there business value?” Yes. Approve. – Executive: “Has everything been approved?” Yes. Approve.

At no point did anyone have to say: “I understand all the reviews and I’m choosing to take the risk of deploying this model given these constraints.”

It was a process without a decision. Everyone followed their part. The system reached approval. Nobody decided.

What actually works

The governance structures that actually prevent problems have a different pattern. Usually there’s a person (maybe a small group, but not a committee) with clear authority. Their job is to decide: Should we use this model?

When they decide, they’re deciding based on: – Understanding what the model does – Understanding the environment where it will be used – Understanding the constraints and risks – Deciding that deployment is acceptable given those constraints

This person doesn’t validate every detail. They rely on expert input. But they’re the one who synthesizes that input and makes the choice.

Then they document: “We are deploying this model. Here’s why I’m comfortable with that decision. Here are the constraints I’m putting around it. Here’s what would make me reverse this decision.”

Then when the environment changes or something unexpected happens, this person (or their successor) reviews and updates the decision.

This structure looks less “governance-like” than a matrix of committees and approval workflows. But it actually prevents problems.

Here’s why: The decision-maker has to be able to defend the decision. If the model fails in an unexpected way, the question isn’t “did we follow the process” but “would this decision still be defensible given what happened.”

This creates a different incentive structure. The decision-maker actually thinks about what could go wrong, not just whether the checklist is complete.

The problem with frameworks

Here’s the uncomfortable truth: Comprehensive frameworks usually create false confidence without creating better outcomes.

They create the appearance of control. The appearance matters for audits and regulatory meetings. But it doesn’t actually prevent bad decisions.

What prevents bad decisions is: – Someone with authority and accountability deciding whether to deploy – Enough expertise available to inform that decision – The decision-maker understanding and accepting the risks – Clear monitoring so that if something unexpected happens, it gets escalated back to the decision-maker

You could write this on a page. You don’t need a framework.

But the reason organizations build frameworks is because nobody believes that would survive an audit. If something goes wrong and your governance is “we had a thoughtful person decide,” that feels insufficient.

The regulatory environment hasn’t clarified that this is actually better than “we had a five-layer review process.” So organizations build the five-layer review process.

Starting over

If you were building AI governance from scratch — not trying to be audit-ready, just trying to prevent bad outcomes — here’s what you’d do:

Identify the person or small group with authority to make deployment decisions.

Make sure they have access to expert input: data scientists, compliance officers, business leads, whoever informs the decision.

Have them document the decision: “We’re deploying this model. Here’s why. Here are the constraints. Here’s what would change the decision.”

Set up monitoring. When something diverges from expectations, it escalates back to the decision-maker.

When the decision-maker would revert the decision if something unexpected happened, that’s governance.

When the framework is designed so that the decision-maker can never reverse course because they’re locked in by the approval process, that’s theater.

What to do if you already have a framework

If your organization already has a comprehensive governance framework (you probably do), you can’t just throw it out. But you can add a layer to it.

Add a decision layer. Someone with authority needs to actively decide “we deploy this given these constraints.” They’re not just approving at the end of the process. They’re deciding.

And they need to know that their job is to make a defensible decision, not to validate that everyone did their part.

The organizations that end up with the best outcomes usually have a framework (for audit readiness) and a decision (for actual risk management).

Most organizations have the framework and call it governance. They’re surprised later when the framework didn’t prevent a problem.