The previous lesson built the function-level AI risk register, the owned, evidenced inventory of every way AI can fail your function. But a register without a governance structure is a document waiting for a meeting that never happens. Who decides whether a residual hallucination risk on a flagship NDA is acceptable? Who approves a new AI use case before it goes live? When a drift breach is detected on a Friday afternoon, who has the authority to halt production, and who do they call? When the AI use disclosure in a cover letter needs sign-off and the medical writing lead, the RA director, and Quality disagree, who breaks the tie? These are not questions about technology; they are questions about decision rights, and a function-level AI program that cannot answer them on a single page does not have a governance structure, it has a set of well-intentioned people who will improvise under pressure and produce an inconsistent, undefendable record. This lesson builds the governance structure that owns the register and the strategy: the two- and three-tier committee models, the integration with the existing Quality Council and IT Governance so you do not create a parallel bureaucracy, and the decision rights and escalation paths that turn good intentions into a functioning, inspectable system of accountability.

Why Governance Is the Load-Bearing Layer, Not the Bureaucratic One

The word "governance" makes practitioners flinch because it conjures committees that meet monthly, produce minutes nobody reads, and slow everything down without deciding anything. That reflex is the enemy of good AI governance, because the structure this lesson builds is the opposite: it exists to make decisions faster and more defensibly, by deciding in advance who decides what, so that the people doing the work are not paralyzed and the people accountable are not blindsided. Governance is the layer that converts the strategy, the metrics, and the risk register from artifacts into a running system, because a strategy nobody is empowered to enforce is a wish, a metric nobody is obligated to act on is a number, and a risk register nobody is required to review is a snapshot. The committee structure is what gives each of those artifacts a heartbeat, a recurring forum where they are reviewed, decisions are made on the record, and accountability is assigned to a name.

Governance is also the single thing an inspector and a board most reliably probe, because it is the proxy for everything else. The 14 January 2026 FDA-EMA Guiding Principles named governance and documentation as an explicit principle and accountability as another, and an inspector who wants to assess whether a sponsor is in a state of control over its AI use will ask to see the governance structure first, because a sound governance structure implies that risks are reviewed, decisions are owned, and the program is steered rather than drifting. A board exercising its Caremark duty of oversight is asking the same question from the other direction: is there a reporting system, a forum where AI risk reaches the people accountable for it. The governance structure is the answer to both, which is why the strategist must build it as a load-bearing structural element of the program, not as a compliance afterthought bolted on to satisfy a checklist.

The deepest reason governance matters is that AI decisions in a regulated function are cross-functional by nature, and cross-functional decisions made without a structure default to whoever is loudest, most senior, or most available, which is the worst possible basis for a decision that will be inspected. Whether to accept a residual risk touches Quality, RA, and the function head; whether a tool is validated touches IT, Quality, and the function; whether an AI disclosure is adequate touches RA, Legal, and the function. None of these decisions has a natural single owner, and in the absence of a structure they are made informally, inconsistently, and without a defensible record of who decided and why. The governance structure exists precisely to give cross-functional decisions a defined home, a defined decider, and a defined record, which is the difference between a program that can explain its decisions to an inspector and one that cannot.

The Two-Tier Model for a Single Function

For a single function standing up its AI program, the two-tier model is usually the right starting structure, because it separates the operational from the strategic without creating more layers than the work justifies. The lower tier is an operational AI working group: the people who actually run the workflows, the power-users, a validation representative, a quality representative, and the function's AI lead, meeting frequently enough to handle the live decisions, new use-case intake, control execution issues, incident triage, and the routine maintenance of the risk register. This tier owns the day-to-day and escalates only what exceeds its authority. The upper tier is a governance or steering committee: the function head, a senior Quality representative, a senior RA or regulatory representative, an IT or validation lead, and as needed Legal and Privacy, meeting less frequently to own the strategic decisions, use-case prioritization, residual-risk acceptance above a threshold, vendor decisions, the board narrative, and the policy that the working group operates under.

The critical design choice in the two-tier model is the boundary between the tiers, expressed as a decision-rights threshold, because a boundary that is vague recreates the improvisation the structure was meant to eliminate. The working group must know exactly what it can decide and what it must escalate: it can accept a low residual risk on a routine artifact, but it must escalate a high residual risk, any risk on a flagship asset, any new vendor, any decision that sets a precedent, or any incident with regulatory exposure. Writing this threshold down, and keeping it current, is the single highest-value act in building the model, because it is what lets the working group move fast on the ninety percent of decisions that are routine while ensuring the ten percent that are consequential reach the people accountable for them. A two-tier model with an unwritten boundary is a one-tier model pretending, and it fails the first time a consequential decision is made at the wrong altitude.

The two-tier model also has to define how the tiers connect, because two committees that do not talk are two silos. The connection is the AI lead, who sits in both, carries the working group's escalations up and the steering committee's decisions down, and owns the risk register that both tiers act on. This single human linkage is what keeps the model coherent, and it is also its vulnerability, because an AI lead who becomes a bottleneck or who filters what the steering committee sees can quietly break the whole structure. The mitigation is a standing escalation path that does not depend solely on the AI lead, any working group member can escalate directly on a defined set of triggers, and a standing register review at the steering tier that does not rely on the AI lead to surface what matters, so that the structure has redundancy in its information flow.

The Three-Tier Model for an Enterprise or Multi-Function Scope

When AI use spans multiple functions, regulatory, medical writing, clinical operations, pharmacovigilance, medical affairs, the two-tier model strains, because a single steering committee cannot own the strategic decisions of five functions and the working groups have no peer forum to share controls and incidents. The three-tier model adds an enterprise AI council above the function-level structures: each function retains its operational working group and a function-level governance forum, and above them sits a cross-functional AI council that owns enterprise policy, the shared validation framework, vendor strategy across functions, the consolidated risk view, and the relationship to the board. This tier is where the company decides things that must be consistent across functions, what disclosure language is used, what validation rigor a Category 4 tool requires, what the enterprise stance is on a given vendor, so that the medical writing function and the PV function are not separately inventing incompatible answers to the same question.

The three-tier model's failure mode is the opposite of the two-tier model's: where the two-tier risks under-structuring, the three-tier risks over-structuring into a bureaucracy where every decision climbs three levels and nothing moves. The defense is the same discipline, ruthless decision-rights clarity, applied across three tiers instead of two: the council owns only what must be enterprise-consistent, the function governance owns what is function-specific, and the working group owns the operational, with each tier holding the smallest set of decisions that genuinely require its altitude. A three-tier model where the council reviews routine use cases is a failed three-tier model, because it has pulled operational decisions up to a strategic forum and guaranteed that the forum is too busy with the routine to attend to the strategic. The art is to push every decision to the lowest tier that can own it defensibly, and to reserve the higher tiers for genuinely cross-cutting or high-consequence decisions.

Integration, Not Proliferation: The Quality Council and IT Governance

The most common and most expensive mistake in AI governance is to build it as a freestanding parallel structure alongside the company's existing governance, producing a new committee that duplicates the Quality Council's remit, competes with IT Governance for the same decisions, and confuses everyone about who actually owns a given call. A regulated company already has a Quality Council that owns quality risk and the GxP system, an IT Governance body that owns software validation and the technology estate, and often a Privacy or Data Governance council, and AI governance must integrate with these rather than replace or shadow them, because AI risk is not a new kind of risk that needs a new kind of governance, it is quality risk, validation risk, and data risk wearing a new technology, and it belongs inside the structures that already own those risk types. The strategist who builds a shiny new AI committee that floats free of the Quality Council has built a structure that an inspector will immediately question, because it implies AI is being governed outside the quality system rather than inside it.

The integration is mechanical and specific, not aspirational. AI validation decisions route into IT Governance and the existing validation process, because an AI tool is software and validating it is the same discipline as validating any GxP software under GAMP 5 and Computer Software Assurance, not a separate one. AI quality risk, the residual-risk acceptances, the incident reviews, the register oversight, routes into the Quality Council, because it is quality risk and the Quality Council already owns the authority to accept it. AI data and confidentiality decisions route into the Privacy or Data Governance body. The AI-specific governance forum, whether the two-tier steering committee or the three-tier council, exists to own only what is genuinely AI-specific and cross-cutting, the AI strategy, the AI use-case portfolio, the AI-specific risk taxonomy, the board narrative, and to feed the appropriate decisions into the existing councils rather than to duplicate them. This makes the AI governance structure lean, defensible, and inspectable, because every decision lands in the body that already has the standing and the documentation discipline to own it.

Integration also solves the documentation problem that a parallel structure creates. The Quality Council's decisions are already captured in a GxP-compliant minute-and-record system that an inspector knows how to read; routing AI quality decisions through it means they inherit that documentation discipline automatically, rather than living in a new committee's ad-hoc notes that may not survive scrutiny. The same is true for validation decisions in IT Governance. The AI-specific forum, by owning less, generates less novel documentation and relies more on the established records of the councils it feeds, which is exactly the lean, defensible posture the strategist wants, because every record an inspector requests is one the existing system was already built to produce. The principle is integration over proliferation: the fewer new structures and records you create, the fewer new ways the program can fail an inspection.

Decision Rights: The RACI That Prevents the Friday-Afternoon Crisis

A governance structure is only as good as its decision rights, and decision rights are best made concrete through a simple discipline borrowed from program management: for every consequential AI decision, name who is Responsible for doing the work, who is Accountable as the single owner of the decision, who must be Consulted, and who must be Informed. This RACI is not bureaucratic decoration; it is the artifact that answers the Friday-afternoon question, when a drift breach is detected and someone has to decide, right now, whether to halt the PV narrative tool, and the difference between a calm, defensible response and a chaotic one is whether the decision right was assigned before the crisis or is being invented during it. The decisions that most need explicit rights are the high-stakes, time-pressured, cross-functional ones: residual-risk acceptance, new use-case approval, tool validation sign-off, incident response and production halt authority, AI disclosure approval, and vendor selection and termination.

The accountable role is the one the structure must get exactly right, because there can be only one accountable owner per decision, and diffusing accountability across a committee is how decisions become unattributable. A committee can be consulted and a committee can ratify, but a committee cannot be accountable in the sense the FDA-EMA principles require, because accountability that belongs to everyone belongs to no one, and an inspector asking "who decided this AI tool was fit to produce submission content" needs a name, not a committee. So the decision-rights design assigns each consequential decision to a single accountable human, the function head for use-case approval, the Quality Council chair or a delegate for high residual-risk acceptance, the validation owner for tool sign-off, the QPPV for PV-specific AI decisions, and uses the committees as the forums where those accountable individuals are consulted, supported, and held to account, not as a way to dissolve accountability into a vote.

Escalation is the dynamic counterpart to decision rights, the defined path a decision travels when it exceeds the authority of the tier that encountered it, and it must be specified for both the routine and the emergency case. The routine escalation is the threshold-based one already described: the working group escalates to the steering committee on defined triggers, and the steering committee escalates to the council or the board on others. The emergency escalation is the one most programs neglect and most need: when an incident with regulatory or patient-safety exposure is detected outside a scheduled meeting, who has standing emergency authority to act, who must be notified within what window, and how is the action documented after the fact. A program that can only make decisions in scheduled meetings cannot respond to a Friday-afternoon drift breach or a near-miss confidentiality incident, so the escalation design must include a named emergency authority, a notification chain, and a retrospective documentation requirement, so that fast action under pressure is still a governed, recorded action rather than an undefendable improvisation.

Making the Structure Real: Charter, Cadence, and the Living Link to the Register

A governance structure that exists only in a slide is not a structure; it becomes real through a charter, a cadence, and a living operational link to the register and the rest of the program. The charter is the document that names the tiers, the membership, the decision rights, the escalation paths, the meeting cadence, and the integration points with the Quality Council and IT Governance, and it is the artifact a board approves and an inspector reads to understand how AI is governed. A charter that is specific about decision rights and escalation is worth more than any number of well-attended meetings, because it is what makes the structure inspectable and what lets a new member or a covering deputy understand their authority without improvising. The charter must be version-controlled and maintained like any GxP document, because a governance structure that has evolved while its charter has not is a structure that no longer matches its own description, which is itself a finding.

The cadence must match the decision velocity of each tier rather than a calendar habit, the working group meeting often enough to keep use-case intake and incident triage current, the steering or governance tier meeting on a rhythm that keeps strategic decisions and register review timely without becoming a standing tax, and the council, where it exists, meeting on the slowest rhythm appropriate to enterprise policy. The connective tissue across all of this is the risk register from the previous lesson, which is the standing input to every governance forum: the working group maintains it, the steering tier reviews its high-residual entries and makes the accept-or-treat decisions, and the council sees the consolidated view. This is the synthesis the whole chapter has been building toward, the register is the what, the governance structure is the who and the how, and together they convert the function-level AI strategy from a set of documents into a running, owned, inspectable system of accountability. The next lesson takes that system into the inspection itself, examining what FDA and EMA inspectors are actually asking in 2026 about AI tools, AI-generated content, vendors, PCCPs, and audit trails, and how the governance and register you have built hold up when the inspector is in the room.

Key Takeaways

• Governance is the load-bearing layer that converts the strategy, metrics, and risk register from artifacts into a running system by deciding in advance who decides what. It is the first thing an inspector probes and the Caremark reporting system a board looks for, because cross-functional AI decisions made without a structure default to whoever is loudest, which is the worst basis for a decision that will be inspected.
• The two-tier model suits a single function: an operational working group for live decisions and a steering committee for strategic ones, joined by the AI lead and separated by a written decision-rights threshold. The boundary between the tiers, what the working group may decide versus must escalate, is the highest-value design choice, because a two-tier model with an unwritten boundary is a one-tier model pretending.
• The three-tier model adds an enterprise AI council for multi-function scope, owning only what must be enterprise-consistent. Its failure mode is over-structuring into a bureaucracy where every decision climbs three levels, so push every decision to the lowest tier that can own it defensibly and reserve higher tiers for genuinely cross-cutting or high-consequence calls.
• Integrate with the existing Quality Council, IT Governance, and Privacy bodies rather than building a parallel structure. AI risk is quality, validation, and data risk in new technology, so route validation into IT Governance, quality risk and residual-risk acceptance into the Quality Council, and data decisions into Privacy, leaving the AI-specific forum to own only the genuinely AI-specific and cross-cutting, which keeps the program lean, defensible, and documented in records an inspector already knows how to read.
• Make decision rights concrete with a RACI in which each consequential decision has exactly one accountable human, because accountability diffused across a committee is unattributable and fails the FDA-EMA principle and the inspector's "who decided" question. Specify both routine threshold-based escalation and a named emergency authority with a notification chain and retrospective documentation, so a Friday-afternoon drift breach is a governed, recorded action rather than an improvisation, and bind the whole structure with a version-controlled charter, a cadence matched to decision velocity, and a standing link to the risk register.