Overview

Tomas Reyes spent three years as the AI lead at a Manila-based consumer bank before being asked to lead the group's full AI transformation as Chief AI Officer. His first decision - before hiring a team, before choosing platforms, before building a roadmap - was to spend four weeks drawing boxes on whiteboards with the CEO, the COO, the Chief Risk Officer, and the Chief People Officer. They were not drawing org charts in the usual sense. They were answering one question: when something goes wrong with an AI system - and something eventually will - who is responsible, who is informed, and what happens next? "We had the technology conversation later," Tomas told me. "The governance conversation had to come first. Because without that, we'd build something that nobody owned, and when it broke, everyone would point at someone else."

Why Governance Must Precede Deployment

Organizations often approach AI governance as a retrospective activity: they build AI systems, deploy them, and then put governance structures in place when a problem emerges. This sequence is backwards and expensive. Governance established after deployment is governance designed around the systems that already exist, rather than governance that shapes what systems get built and how.

Governance-first organizations answer three questions before any AI system enters production. Who has the authority to approve this system for deployment? Who is accountable for its performance and compliance after it goes live? What happens - specifically and procedurally - if the system fails?

Without answers to these questions, organizations face a cascade of predictable problems: systems deployed without adequate review, unclear ownership when performance degrades, slow incident response because escalation paths were not defined, and regulatory exposure because the documentation of governance decisions does not exist.

The Governance Structure

Effective AI governance has four structural components. Each serves a distinct function. Most organizations have one or two of these components. Organizations with mature AI programs have all four, well-connected.

Executive oversight

Executive oversight is the mechanism by which the board and senior leadership maintain visibility and authority over the organization's AI portfolio. This typically takes the form of a standing board-level or executive committee review of AI risk and performance on a quarterly basis, and immediate escalation for material incidents or regulatory developments.

Executive oversight does not mean executives review individual AI systems. It means they receive aggregated reporting on the AI portfolio's performance, compliance posture, and strategic alignment, and have a clear path to request more detail or direct a response when needed. Without executive oversight, governance decisions get made at lower levels than their organizational significance warrants.

AI governance committee

The AI governance committee is the core decision-making body for AI policy, standards, and risk management. It typically includes representation from legal, risk, compliance, technology, and a rotating business unit representative. It meets monthly or biweekly and makes decisions that cannot be resolved at the operational level: approving new policy, adjudicating governance disputes, authorizing exceptions to policy requirements, and reviewing significant incidents.

The committee needs genuine authority - the ability to block deployment of an AI system that does not meet governance requirements, regardless of business pressure to proceed. A governance committee with advisory-only authority is not a governance committee. It is a review body that will be ignored when its recommendations are inconvenient.

The model risk or AI review function

This is the operational review function that assesses individual AI systems against governance requirements before deployment. It reviews model documentation, evaluates technical quality, assesses regulatory compliance, and issues deployment authorization. In financial services, model risk management is often a well-established function with regulatory mandate. In other sectors, it may need to be built from scratch.

The review function needs technical depth - reviewers who understand enough about how models work to evaluate their documentation meaningfully, not just confirm that a model card exists. A review function staffed entirely by compliance generalists will produce sign-offs that do not actually assess technical risk. A review function staffed entirely by data scientists will assess technical risk but miss policy and regulatory compliance gaps. The most effective functions combine both.

System-level owners

Every AI system in production needs a named owner - a specific individual who is accountable for that system's performance and compliance. This is not the data scientist who built the model. It is the business leader who has authority over the business process the model supports and will be held accountable for its outcomes. System owners are responsible for monitoring their system's performance, escalating concerns, responding to incidents, and ensuring the system's documentation remains current.

Tomas implemented a system ownership requirement as one of his first governance decisions. Before any AI system could be deployed, a system owner had to be named and had to sign a deployment authorization acknowledging their accountability. The first time a system owner declined to sign because they did not feel they understood the system well enough to be accountable for it, Tomas knew the requirement was working. "That's the behavior you want," he said. "An owner who takes the accountability seriously enough to ask questions before signing."

Designing for Responsible Innovation

A common fear about governance is that it will slow innovation - that requirements and review processes will make it too difficult or too slow to build new AI capabilities. This fear reflects bad governance design, not the nature of governance itself.

Good AI governance is risk-proportionate. Low-risk applications - an AI tool that helps employees draft internal communications, a recommendation engine for internal knowledge search - should face lightweight governance: a brief documentation requirement, a self-certification process, periodic check-ins. High-risk applications - systems that affect customer credit, employment decisions, healthcare triage, or critical infrastructure - should face rigorous governance: full documentation, independent technical review, legal and compliance sign-off, executive authorization.

Risk tiers are the key design lever. An organization that applies the same governance burden to a low-stakes internal productivity tool and a customer-facing credit model is creating friction without commensurate benefit. An organization that stratifies systems into three or four risk tiers and calibrates governance to each tier moves quickly on low-risk applications while maintaining appropriate rigor on high-risk ones.

>
Governance that treats all AI systems the same is governance that has not been designed. Risk-proportionate governance enables innovation by making the path clear for low-risk applications while protecting against the harms where they matter most.

Governance in Practice: The First Ninety Days

For organizations building governance from a weak starting point, a sequenced approach over the first ninety days creates a foundation without requiring everything to be perfect before anything can proceed.

Days 1 to 30. Inventory existing AI systems. Identify which are in production, who built them, who uses them, and what business decisions they influence. Identify the highest-risk systems - the ones whose failure would cause the most harm to customers, the organization, or regulatory standing. Assign a system owner to each.

Days 31 to 60. Establish the governance committee. Define its authority, membership, and decision-making process. Draft the organization's risk tier framework - the criteria that determine whether a system is low, medium, or high risk. Publish the draft for comment from legal, risk, and technical teams.

Days 61 to 90. Develop minimum documentation requirements for each risk tier. Begin applying them to the inventory. Identify the three to five highest-risk existing systems and conduct a retroactive governance review. For new systems entering development, apply the risk tier framework and appropriate governance pathway from the start.

Key Takeaways

• Governance-first is not governance-only. Establishing who is accountable, what authority exists, and what happens in failure before deployment is more efficient than retrofitting governance after problems emerge.
  - Four structural components are all required. Executive oversight, an AI governance committee with real authority, a technical review function, and named system owners together constitute a complete governance structure. Missing any one creates a gap that incidents will find.
  - Governance committees need real authority to block deployment. Advisory-only committees are ignored when business pressure is high. The authority to say no - and have it stick - is what makes governance meaningful.
  - Technical depth in the review function is essential. Governance review staffed only by compliance generalists cannot assess technical risk. A combination of technical and policy expertise is necessary.
  - Risk-proportionate governance enables innovation. Applying the same burden to a low-stakes internal tool and a high-stakes customer model creates unnecessary friction. Calibrating requirements to risk tiers moves low-risk applications quickly while protecting where it matters.
  - Named system owners create accountability that diffuses otherwise. A named individual who signs a deployment authorization takes accountability seriously. Shared or implicit ownership is no ownership.
  - The first ninety days are about inventory, authority, and risk tiering. A complete governance structure takes time to build. A sequenced approach over ninety days creates a foundation from which the rest can develop.