The question isn’t whether copyright lawsuits involving AI will reshape enterprise liability. They already are. What’s shifting now is that enterprises are building large-scale AI systems without clarity on what they’re legally exposed to—and that gap is widening, not closing.

Three major litigation tracks are running simultaneously. The first involves generative AI companies and the datasets they used to train large language models. Several high-profile cases allege that training on copyrighted material without permission or compensation violates copyright law. The second track involves enterprise use of foundation models—if you’re using foundation models to generate content that replaces work that would have been licensed, you may be moving risk. The third, less visible but arguably most dangerous for enterprises, involves the training data you’re collecting and using internally.

Most enterprises aren’t thinking about the third category. They should be.

The Data You Control, Not the Models

When a foundation model company faces copyright liability, they shoulder it. They built the model; they made the decisions about what data to include. But when you build an internal AI system—a customer service chatbot trained on your internal documentation, a code-generation tool trained on your private repositories, a content classifier trained on labeled examples—you’re making the same decisions. And you’re controlling the dataset.

If your training data includes copyrighted material, you’ve made a choice. If it includes customer personal data that you’ve used for model training without explicit consent or legal basis, you’ve created another liability. If it includes third-party data that you licensed for one purpose but then used for model training without renegotiating the terms, you’ve created a third.

This isn’t hypothetical. Enterprises are building on top of open-source code that has licensing restrictions. They’re fine-tuning models on customer data without revisiting their data governance policies. They’re using datasets that were collected before large-scale AI was a consideration, and the original privacy or usage terms never contemplated model training.

Where Most Organizations Have a Blind Spot

The typical audit process asks: “Are we using a licensed model or an open-source model?” If it’s licensed, they assume the vendor handled copyright. If it’s open-source, they check the license (GPL, MIT, Apache, etc.) and call it secure. What they miss is the training data itself.

You may have a fully licensed foundation model deployment, but if you’re feeding it proprietary customer data that you’re then using to fine-tune another model, or if you’re processing it through the API and storing the results in a way that violates your customer’s original consent, the licensing status of the base model becomes secondary.

Similarly, open-source models have become attractive precisely because they seem to sidestep the copyright questions that plague foundation models. But if you’re training an open-source model on a dataset you don’t have clean rights to, the licensing of the model is not your primary risk.

What’s Changing Now

Up until recently, enterprises could move reasonably fast because copyright enforcement was theoretically the problem of the model builders, not the model users. That assumption is breaking down. Courts are beginning to articulate theories of liability that flow backward—from end users toward the data sources and the choices made about what data to use.

The litigation landscape is also clarifying that “we didn’t know it was copyrighted” is not a defense if you had reason to know. A Fortune 500 company has more reason to know than a startup. If you’re building internal AI systems, courts will likely assume you had the capacity to verify your data sources.

There’s also a subtle but important shift in how regulators and advocates are framing the issue. It’s moving from “did you train on copyrighted material” to “did you have a process for knowing what you were training on.” Process failures are easier to prosecute than content mistakes.

What You Need to Start Doing

First, document the provenance of every dataset used for training. Not in aggregate (“we used publicly available data”), but specifically: where did this data come from, who originally created it, what license or terms govern its use, was it collected with consent for this purpose, and did we verify any of that.

Second, revisit your vendor contracts for any data you’re licensing or procuring. The boilerplate language you signed three years ago probably doesn’t address foundation model training. It should. If you’re licensing customer data or third-party data, the terms should explicitly cover (or explicitly prohibit) use for AI model training.

Third, audit your internal datasets. If you’re using customer service transcripts, product documentation, customer feedback, code repositories, or any other internal source as training data, verify the original consent and licensing basis. If it doesn’t exist, you have a choice to make: get the consent retroactively, limit what you do with the model, or don’t use that data.

Fourth, establish a practice where anyone proposing a new AI system documents the data sources upfront, not as an afterthought. Make the data liability question as visible as the technical question.

The Cost of Waiting

The earliest enterprises to address this will have a practical advantage: they’ll know what they can and can’t do. More importantly, they’ll have a documented process that demonstrates reasonable care. That matters in litigation. The enterprises that move slowly will face a much harder conversation when they discover, in the middle of a deployment, that their training data has clean-title problems.

The copyright landscape around AI is clarifying month by month. The visibility enterprises have into their own data governance is not. That gap is where the liability sits.

Most organizations make one mistake about AI governance: they treat all decisions as if they belong at the same level.

They create a governance board. The board makes decisions about which models to deploy, what risk thresholds are acceptable, how to manage fairness, what data to use. Everything flows through the same decision-making structure.

This works until it doesn’t. Suddenly the board is making decisions about whether a particular model should log timestamps in a particular format. Or whether a team should run a quick model experiment. Or what documentation a data scientist should write. And now the board is a bottleneck, because the board is making decisions that should be made much closer to the work.

The mistake is not that the board is doing anything wrong. The mistake is that the decision belongs at a different level.

The Three Levels

Most enterprise AI governance needs three levels of decision-making, with different questions at each level.

Enterprise level. These are decisions about strategy, architecture, and constraints that affect the whole organization.

Questions at this level: What’s our overall risk appetite for AI? What vendors do we work with? What data can be used for AI? What governance structures do we require? How much are we spending on AI? These are decisions that affect multiple lines of business, that have strategic implications, that set constraints others work within.

These decisions should move slowly. They should be made carefully. They should be made by people who can see across the whole organization. They should be made infrequently. If you’re revisiting your enterprise AI strategy every month, something is wrong.

Line-of-business level. These are decisions about which AI initiatives to pursue within a line of business, how to implement them, and how to measure success.

Questions at this level: Should we build a demand forecast model? Should we use this vendor’s AI platform or build our own? How do we resource the AI team? What’s the model refresh schedule? These are decisions that affect one business area but don’t affect strategy organization-wide. They’re guided by enterprise-level decisions (we will spend this much, we will use this vendor, we will follow this risk appetite) but they’re made locally.

These decisions should move faster. A line-of-business leader should be able to make the call on whether to pursue an initiative without going back to the enterprise board. If the enterprise board has set clear constraints, the local decisions are within those constraints. Move on.

Team level. These are decisions about how to build, test, and deploy models within an initiative.

Questions at this level: What features should we engineer? How many samples do we need for training? What’s the right batch size? Should we use this algorithm or that one? How should we handle missing data? These are implementation details. They’re guided by the line-of-business decision (we’re building a demand forecast) but they’re decided by the team that’s doing the work.

These decisions should move very fast. A data scientist should be able to choose an algorithm without asking permission. The team should be able to run experiments without a governance board vote.

The Common Mistakes

Organizations usually get this wrong in one of two ways:

First, they push decisions up. A team wants to run an experiment. They go to the board. The board approves it. This happens for every decision, so the board becomes a bottleneck. The organization moves slowly. Teams get frustrated.

This usually happens because the team isn’t confident in the constraints set at the higher level. They don’t know what they’re allowed to do, so they ask. Which means the enterprise level hasn’t been clear about what the rules are. Or the line-of-business level hasn’t been clear about the initiative. The failure is higher up, but it manifests as slowness lower down.

Second, they push decisions down. Teams start making decisions about architecture. Teams choose vendors. Teams set risk thresholds. And now you have no consistency across the organization. One line of business is using Vendor A, another is using Vendor B. One team is comfortable with 3% bias, another requires 0.5%. One team runs models without any governance, another has heavy governance.

This usually happens because the higher levels haven’t set clear constraints. Or haven’t been clear about which decisions they’re responsible for. The teams are making reasonable decisions locally, but those decisions don’t add up to a coherent strategy.

How to Tell If You Have It Right

You have the right decision hierarchy if:

Enterprise decisions feel weighty. When the enterprise board meets, they’re making decisions that feel consequential. Not “should we tune this hyperparameter?” Decisions like “what’s our risk tolerance?” or “should we use this vendor?” These should feel substantial because they’re the decisions that matter most.

Line-of-business decisions move fast. Business leaders can make the call on which initiatives to pursue without spending six months getting approval. They know the constraints (spend budget X, follow risk appetite Y, use vendor Z). They decide: we’re building a demand forecast, we’re building a churn prediction model, etc. They make those decisions independently.

Team decisions happen in hours or days. Data scientists run experiments. They try algorithms. They refine features. They don’t ask for permission. They work within the constraints set by the business leader. They make technical choices rapidly.

If enterprise decisions feel trivial, you’ve pushed decisions up. If team decisions require approval, you’ve not pushed decisions down. If different lines of business are making inconsistent choices about vendors or risk appetite, you haven’t set enterprise constraints clearly.

How to Implement It

If you don’t have this structure, start by answering one question: What decisions have to be made at the enterprise level to set clear constraints for everyone below?

For most organizations, the answer looks like: – Risk appetite (what are we willing to accept?) – Vendor strategy (what infrastructure do we use?) – Data governance (what data can be used for AI?) – Budget (how much do we spend on AI?) – Required processes (what governance do we require?)

Make those decisions carefully and clearly. Document them. Make them known. Then say: “Within these constraints, you can make your own decisions.”

The line-of-business level then works within those constraints: we have $X budget, we have to use vendor Z, we have to follow risk appetite Y. Now: what initiatives should we pursue?

The team level then works within the initiative: we’ve decided to build a demand forecast. Now: how do we build the best forecast possible?

Three levels. Three sets of questions. Three speeds.

The Conversation That Matters

The conversation worth having is: “Are we making this decision at the right level?”

If you’re at the board, and you’re deciding whether a team should use algorithm A or algorithm B, you’re at the wrong level. Or the team doesn’t have good constraints, and that’s a higher-level problem.

If you’re a business leader, and you don’t know whether you can pursue an initiative without asking the enterprise board, you need higher-level clarity about what the constraints are.

If you’re a data scientist, and you can’t run an experiment without approval, either the governance is too heavy, or your manager hasn’t given you clear guidance about what you can do.

The organization that gets this right doesn’t move faster in every dimension. It moves faster where it should (team decisions), and slower where it should (enterprise decisions). But because every level is moving at its appropriate speed, the overall system is faster and more coherent than an organization where everything goes through one decision-making structure.

Most organizations can implement this in a month. The hard part isn’t the structure. The hard part is being clear about what belongs at each level, and then having the discipline to stick to it.

You’ve built a good governance structure for AI. Clear decision rights. Good documentation. Regular review cycles. Smart people involved. It works for about six months.

Then someone on the board asks a question that matters. “Why did we turn off that model?” or “Why didn’t we deploy this system?” And the answer from your governance structure doesn’t align with what someone powerful wanted.

Now your governance structure is a problem.

This is when governance gets political. Not in the sense of backroom dealing, though sometimes that happens. But in the sense of power. Governance is a set of rules. Rules constrain power. And when a rule gets in the way of someone who has actual authority, that rule either gets changed or gets ignored.

Most organizations don’t think about this when they design governance. They design for a world where the governance structure is neutral and everyone respects it. That world doesn’t exist.

How This Manifests

The pattern is usually one of these:

The override. Someone with authority needs something from an AI system. The governance structure says “not yet, you need to wait for approval.” But they override it. They say “this is important, we’re proceeding.” The governance structure becomes advisory.

The reinterpretation. The governance structure says “we don’t deploy models without fairness audits.” Someone argues that “fairness audit” is ambiguous. What counts? Who decides? Their model is fair by their definition. The governance structure becomes interpretable.

The work-around. The governance structure applies to production models but not to “pilots.” So everything becomes a pilot. The governance structure becomes inapplicable.

The evolution. You design a governance structure. It works. Then the business changes. Now the structure is seen as too slow, or too strict, or misaligned with strategy. It gets relaxed. Then something goes wrong and it gets tightened. It becomes reactive instead of stable.

In each of these cases, the governance structure didn’t fail because it was badly designed. It failed because it wasn’t designed to survive political pressure.

What Stable Governance Looks Like

Governance structures that survive political pressure have three things in common:

First, they align incentives. If the governance structure creates friction for someone without creating benefits for them, they’ll find a way around it. But if the governance structure creates benefits for them, they’ll defend it.

This means: if your governance structure makes decisions slower but safer, you need to be clear that “safer” creates value for the person waiting. If it creates compliance benefit but not business benefit, it’s vulnerable.

The strongest governance structures are ones where following the rules creates obvious good outcomes for the people following them. A good example: “We do fairness audits before deployment. This prevents lawsuits. This saves us money.” That’s a governance structure with aligned incentives.

Second, they create accountability that matters. If following the governance structure comes with visibility and credit, people follow it. If ignoring it comes with no consequences, people ignore it.

Most organizations create governance structures where following them is invisible and ignoring them has no immediate consequences. That’s a structure designed to fail.

A strong governance structure is one where the people in the governance process have skin in the game. If a model is deployed without proper review and it causes harm, everyone knows who approved it. The risk is shared. The accountability is real.

Third, they’re clear about which decisions are reversible and which aren’t. Some decisions can be undone (deploy a model, see how it performs, roll it back if needed). Some decisions are hard to undo (choose a vendor, build integration, hire for a skill). Some decisions are nearly impossible to undo (deploy a model that’s trained on proprietary data, build a regulatory precedent).

Governance can be lighter for reversible decisions and heavier for irreversible ones. If you make everything high-governance, it’s seen as overly cautious. If you make everything low-governance, nothing prevents bad irreversible decisions.

The structures that survive political pressure are ones that match the governance weight to the reversibility of the decision.

The Conversation That Reveals What You Need

When you design governance, ask this question: “If someone with authority disagrees with what this governance structure says, what happens?”

If the honest answer is “they override it,” then your governance structure is advisory. That might be fine. But you should know that’s what you have. Don’t pretend you have authority when you don’t.

If the honest answer is “we discuss it, and we follow the structure,” then ask: why? What makes them accept the constraint? Usually it’s because (1) they understand why the rule exists, (2) they see benefit from the rule, or (3) they have accountability if the rule is ignored.

The organizations with the strongest governance are the ones that have designed it explicitly to survive politics. They’ve made sure the stakeholders with power understand the benefit of following the rules. They’ve created accountability for not following them. They’ve matched the governance rigor to the actual risk.

How to Design Governance That Lasts

Start by identifying the most powerful people in your organization and asking: “What does this governance structure require of them?” Then ask: “Do they see benefit in following it? If not, why would they?”

If the answer is “I don’t know” or “not really,” you’ve found your political vulnerability.

Then, either (1) redesign the governance to create benefit for them, or (2) accept that the governance won’t hold under pressure and design something lighter that can hold.

Most organizations do neither. They design governance that looks good in a document, and then are surprised when it falls apart when someone with power tests it.

The second thing: link accountability to outcomes. If a model is deployed against governance recommendations and it fails, that failure should be visible. The people who approved it, the people who were overridden, the leadership that allowed the override—all of it should be part of the story. This doesn’t mean blame. It means learning. It means next time, people think twice before overriding governance because they know it matters.

The third thing: be honest about reversibility. Some decisions should go through heavy governance. Some shouldn’t. If everything is heavily governed, you’re not making trade-offs—you’re just slowing down decision-making. The governance structures that last are the ones that people see as proportional.

The Fundamental Problem

The fundamental problem is that governance is a constraint on power. And power doesn’t like constraints. So either governance is weak enough that power doesn’t feel constrained (in which case it’s not doing much), or it’s strong enough that power notices (in which case power pushes back).

The organizations that solve this well don’t try to make governance neutral or invisible. They make it aligned. They make sure the people with power see governance as something that protects them, not something that limits them. “We don’t deploy models without fairness audits, because the cost of a fairness issue is enormous.” That’s governance that makes sense to power.

Governance that says “we have policies and you have to follow them” is governance that will eventually lose to someone who doesn’t want to.

Governance that says “here’s why this structure protects you and creates value for you” is governance that lasts.

Most organizations are asking the wrong question about AI costs.

They ask: “How much will this AI initiative cost?”

They should be asking: “How do we prevent AI costs from spiraling?”

The difference is the difference between a forecast and a control mechanism. Forecasts are almost always wrong. Control mechanisms work.

The problem is that AI costs don’t behave like traditional IT costs. With traditional infrastructure, you pay for capacity: servers, storage, network. The cost is relatively predictable. You plan for growth. You scale. It’s understood.

With AI, you pay for inference. And inference costs scale with usage. As your model gets more popular, as you integrate it into more applications, as more people use it, costs go up. And because models are often inexpensive to run at scale, the incentive to optimize the cost is low. So organizations deploy models, they get popular, usage grows, and suddenly you’re spending millions on inference that you didn’t budget for.

This happens because most organizations don’t have a cost governance structure for AI. They have a cost tracking structure. They measure what they spent. They don’t control how much they spend.

Why This Happens

The typical progression looks like this:

Someone builds a successful AI model. It works. It saves money or makes money. It’s popular. Usage grows. Inference cost is $0.02 per request, but requests go from 10,000 a day to 1 million a day. Now you’re spending $20,000 a day on that model. Nobody planned for that. It just happened.

So you have a choice: shut down the model, or keep paying. And because the model is popular and it works, you keep paying. But now you’re subsidizing that usage, because nobody allocated budget for it. That budget has to come from somewhere—probably from planned AI spending on new models, or from other projects.

This pattern repeats. By the end of the year, you’ve deployed seven models. Three of them are wildly popular and they’re costing you 60% of your AI inference budget. The other four are barely used, but you’re still paying to run them. You have $5M that you didn’t budget for. And you have to figure out where it came from.

Most organizations handle this by saying “we need to be more careful about which models we deploy” or “we need better forecasting.” Neither of those works. The problem is not selection or forecasting. The problem is that you don’t have a cost governance structure.

What Cost Governance Actually Means

Cost governance for AI doesn’t mean “spend less money.” It means “make spending decisions consciously.” This framework draws on common enterprise cost modeling principles.

Here’s what it looks like:

Every model has a cost budget. Not a forecast. A budget. When you deploy a model, you specify: “This model can spend up to $50,000 per month.” That’s the budget. If inference costs exceed that, the model hits the budget cap and either (a) you optimize the model to reduce costs, or (b) you explicitly decide to increase the budget.

Every model has an owner who cares about the cost. This is not the data scientist who built it. The data scientist cares about accuracy. You need someone who cares about cost. In many organizations, this is the product manager for the AI initiative or the business owner of the process it affects.

You review model costs regularly. Monthly, at minimum. Who’s spending what? Are costs going up or down? Why? If a model is consuming 40% of your inference budget but it’s not producing 40% of the value, why are we running it? These are real conversations.

You have a retirement process for models. When a model’s cost exceeds its value, or when it’s no longer needed, you shut it down. This sounds obvious, but most organizations never retire models. They accumulate. You end up with a graveyard of low-value models that nobody wants to turn off because “someone might need it.”

You look for economies of scale. Once you have multiple models, you can start optimizing. Can you batch inferences? Can you use a smaller model? Can you run models in a cheaper region? Can you use caching to reduce redundant inferences? These optimizations only matter if you have cost visibility and cost ownership.

The Uncomfortable Bit

Cost governance requires making trade-offs that are uncomfortable.

If you have limited inference budget, you have to make a choice: run a very accurate model infrequently, or run a less accurate model frequently. You have to make that choice consciously. That requires business input. It requires someone to say “yes, we’re okay with 85% accuracy if it costs half as much.”

Most organizations don’t want to have that conversation. It’s easier to say “let’s try to optimize both” or “we’ll figure it out later.” But that avoidance is what creates runaway costs.

How To Start

If you have AI systems in production and you don’t have cost governance, start here:

1. Get an accurate measure of your actual AI inference costs. Not an estimate. Actual. What are you spending on model serving, on inference APIs, on GPU capacity?

2. Allocate that cost to the models that are driving it. Which models are expensive? Why?

3. For the expensive models, identify the owner. Product manager, business leader, operations director. Someone who cares about the cost.

4. Have a conversation with that owner: “This model is costing $X per month. What value is it producing? Is that cost justified?” If the answer is “I don’t know,” you’ve found a problem.

5. Set a cost budget for the coming quarter. Not a forecast. A budget. “This model can spend up to $Y per month.”

6. Monitor it monthly. If the model hits the budget, deal with it. Optimize, or request a budget increase, or retire the model. Don’t let it exceed the budget silently.

That’s cost governance. It’s not complicated. It’s just intentional.

The Payoff

Organizations that do this end up with 20-30% lower inference costs than organizations that don’t, because they’re constantly asking “do we need to keep running this?” and “can we run this more cheaply?” instead of just assuming that usage and cost will work out.

And more importantly, they don’t have the experience of looking at their bill at the end of the quarter and being surprised. They know what they’re spending. They chose to spend it. That’s control.

The question isn’t “how much will AI cost?” It’s “how much do we want to spend, and what do we get for that?” Answer that question first, and the costs take care of themselves.

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.