Overview

When Rodrigo Castillo joined a 12,000-person financial services company as its first Head of AI, he inherited 23 active AI projects - each governed differently. One team required sign-off from legal before every prompt change. Another had never talked to legal at all. A model deployed in collections had no owner. Three months in, Rodrigo told me: "We didn't have a governance problem. We had an absence-of-governance problem." The two look similar from the outside but require completely different fixes.

Governance is how an organization makes decisions about AI - who decides, who is accountable, and what constraints apply. Get it wrong in either direction and you lose. Too centralized, and innovation slows to a crawl as every idea waits in a queue. Too distributed, and you get the Rodrigo problem: duplication, inconsistency, and no one accountable when something breaks.

This lesson gives you the mental model and practical tools to design governance that fits your organization's size, risk profile, and maturity - and to evolve it as all three change.

The Three Operating Models

Most enterprise AI governance falls into one of three structural patterns. None is universally right. Understanding the trade-offs is what lets you choose and adapt.

The Centralized Model: One AI Team Runs Everything

In a centralized model, a single AI team - often called a Center of Excellence, or CoE - owns all significant AI work. Business units bring requests. The CoE evaluates, builds, and deploys. Governance decisions live in one place.

The benefits are real: consistent standards, no duplicate work, clearer accountability. A company running sensitive financial models or health-related AI often needs this level of control.

The costs are also real. The CoE becomes a bottleneck. Business unit teams feel ownership is taken from them, which reduces adoption. Ideas that do not fit the CoE's priorities languish. In a fast-moving environment, the queue problem can be fatal to momentum.

Centralization works best in: highly regulated industries; early-stage AI programs where standards have not yet been established; organizations with serious prior incidents that require tighter control.

The Distributed Model: Business Units Lead Their Own AI

In a distributed model, each business unit builds and governs its own AI capabilities. A central function might exist for platform infrastructure or compliance review, but strategic and operational decisions belong to the teams closest to the work.

The benefits: speed, ownership, and relevance. Teams who live with the problem build solutions that fit it. Innovation can happen in parallel across the organization.

The costs: duplication of effort, inconsistent quality standards, risk that one team's poor practices expose the whole organization. In Rodrigo's company, the collections model with no owner was a distributed-model legacy - a team had built it, the team had disbanded, and no one knew they owned the risk.

Distribution works best in: large organizations where business unit contexts are genuinely different; mature AI programs where teams have demonstrated capability; organizations where innovation speed is the primary competitive concern.

The Hybrid Model: Federated with Central Guardrails

Most organizations that have worked through both extremes end up here. The hybrid or "federated" model separates what must be centralized from what should be distributed.

Rodrigo's eventual design was a useful example. He centralized four things: risk classification (which projects are high-risk vs. low-risk), data governance standards (who can access what data for AI training), the vendor approval process, and incident response. Everything else - building, deploying, iterating - stayed with business units. "I'm not here to build things for people," he told his leadership team. "I'm here to make sure things don't go wrong and that people have what they need."

This structure let the 23 projects continue operating while bringing the highest-risk ones under review without stalling the others.

Establishing Decision Rights

Whatever model you choose, you need explicit answers to six questions. Leaving any of them implicit means they will be answered by whoever acts first - which may not be who should act.

• Who approves new AI projects? Define the threshold. A pilot with no customer data might need only team-lead sign-off. A model that affects customer credit decisions needs a different process.
  - Who controls data access? This is often the source of the most contentious governance disputes. Assign a clear data steward per domain with authority to grant and revoke access.
  - Who owns a deployed model? This is the collections-model problem. Every production AI system needs a named owner who is accountable for its performance and for responding when something goes wrong.
  - Who decides when to retire or replace an AI system? Without a defined process, systems persist long after they should be replaced, accumulating technical debt and risk.
  - Who handles governance violations? When a team bypasses the process, what happens? The answer shapes whether the governance is real or decorative.
  - Who changes the governance itself? Governance that cannot evolve calcifies. Build in a review cycle - annually at minimum - and assign someone to own it.

Governing External AI Systems

Most organizations now use AI capabilities they did not build - commercial large language models, vendor platforms, embedded AI in SaaS tools. These require a different kind of governance because you do not control the model, the training data, or the update schedule.

Rodrigo found that his company was using seven different external AI platforms, two of which processed customer data under terms that did not meet their data protection standards. No one had caught this because vendor selection had been ad hoc.

A minimal vendor governance process for AI includes: a defined approval path before any team can use a new AI vendor; a standard set of contract requirements covering data handling, model change notification, and liability; and a periodic review - at least annually - of all active vendor relationships.

The contract requirements matter more than they used to. AI vendors update their underlying models. A model that passed your evaluation in January may behave differently in October. Require notification of material model changes as a contractual term. Some vendors will resist this; how they respond tells you something useful about the relationship.

Guardrails That Enable Rather Than Block

A guardrail is a constraint that defines the space within which teams can move freely. The goal is not to prevent innovation - it is to prevent the kinds of failure that would shut down innovation entirely.

Effective guardrails are proportionate to risk. A model that generates internal meeting summaries warrants light oversight: perhaps a review of the prompt design and a note in the project registry. A model that determines employee performance scores warrants heavy oversight: human review at every consequential decision, documented appeal process, demographic fairness testing before deployment.

Common guardrail categories in enterprise AI programs:

• Data guardrails: Which data can be used to train or fine-tune models, and which cannot. Sensitive personal data and customer data typically have the most restrictions.
  - Transparency guardrails: Requirements that AI-generated outputs be labeled as such, and that decision-makers understand when AI is influencing a recommendation.
  - Human oversight guardrails: Specific decision types that require human review regardless of AI confidence. Define these explicitly - "high-stakes" is not specific enough.
  - Performance guardrails: Minimum accuracy or reliability thresholds before a model can be deployed to production, and ongoing monitoring standards after deployment.

Governance as a Living System

Rodrigo's governance framework looked very different after 18 months than it did at launch. Three projects that started as low-risk had grown in scope and required reclassification. The vendor approval process had been simplified after teams found the original version too slow. Two guardrails had been tightened after near-misses, and one had been relaxed after proving unnecessarily restrictive.

This is what healthy governance looks like. It learns. The review cycle is not ceremonial - it is how you find out which parts of the framework create friction without corresponding risk reduction, and which parts are not being followed because they were unrealistic to begin with.

The people operating under governance are your best source of signal on both. Build in a feedback mechanism: a short quarterly survey, a governance office-hours session, or simply a standing agenda item at your AI working group. What you hear will tell you where to tighten and where to loosen - and making those adjustments visibly signals that the governance is responsive, not just bureaucratic.

Key Takeaways

• Absent governance is not the same as light governance. When there are no explicit rules, the rules are whatever each team decides - which produces inconsistency, duplication, and unowned risk.
  - The three models - centralized, distributed, hybrid - have real trade-offs. Most mature organizations land on a federated hybrid: centralize risk classification, data standards, vendor approval, and incident response; distribute everything else.
  - Decision rights must be explicit. Every AI program needs clear answers to six questions: who approves projects, who controls data, who owns deployed models, who retires them, who handles violations, and who changes the governance itself.
  - External AI vendors require their own governance layer. Require notification of material model changes, enforce data handling standards in contracts, and review all active vendor relationships at least annually.
  - Guardrails should be proportionate to risk. Treat a meeting summary tool differently from a model that affects compensation. The goal is to protect against consequential failure, not to constrain every experiment.
  - Good governance learns and adapts. Build in a formal review cycle. The teams operating under the governance will tell you what works and what creates unnecessary friction - if you make it easy for them to do so.