In the last lesson, the containment slide was the one that won the board room. This lesson builds the artifact that sits underneath it and makes that slide true rather than rhetorical: the function-level AI risk register. A risk register is not a compliance ornament, and it is not the generic enterprise risk-management spreadsheet with "AI" pasted into one row. It is the living, owned, version-controlled inventory of every way your function's use of AI can produce a regulatory, quality, legal, or commercial failure, paired with the control that bounds each one, the owner who is accountable, and the evidence that the control is working. When an FDA inspector at a Pre-Approval Inspection asks "show me how you manage the risk that AI fabricated content in this Module 2.5," the register is the document that decides whether the answer is two minutes of calm evidence or two hours of improvised defense. This lesson builds the functional risk taxonomy, hallucination, drift, vendor failure, IP exposure, regulator non-acceptance, inspection finding, and post-market risk, and then builds the register that turns that taxonomy into a managed system rather than a list of fears.

Why a Function-Level Register and Not the Enterprise One

Most large pharma companies already have an enterprise risk register, an IT risk register, and a quality risk-management system under ICH Q9(R1), and the instinct of a tidy organization is to add a single "generative AI" line to one of them and consider the risk managed. That instinct fails for a specific reason: AI risk in a regulated function is not one risk, it is a taxonomy of materially different failure modes that live at the altitude of the workflow, not the enterprise. The enterprise register can say "AI may produce errors," but it cannot say that a hallucinated TLF cross-reference in a Module 2.5.4 propagates into Module 2.7.3 and surfaces as a Day 74 Information Request, because the enterprise register does not know what a 2.5.4 is. The function-level register is the only artifact at the right resolution to name the failure mode against the specific artifact it threatens and to assign a control a writer can actually execute.

The function-level register also solves an ownership problem that the enterprise register structurally cannot. Enterprise risks are owned by enterprise functions, and "AI risk" parked there ends up owned by everyone and therefore no one, usually by an IT or innovation team that does not own the submission and cannot be accountable for its content. A function-level register assigns each risk to the person in the function who actually controls the workflow step where the risk lives: the head of medical writing owns hallucination risk in Module 2 drafting, the QPPV owns AI-assisted causality risk in ICSR narratives, the RA-CMC lead owns AI risk in the comparability protocol. This alignment between where the risk occurs and who owns it is the entire point, because the 14 January 2026 FDA-EMA accountability principle is explicit that sponsor accountability does not transfer to a vendor and cannot be diffused into a committee; it lands on a named human, and the register is where that name is written down.

Finally, the function-level register is what makes the board's containment slide and the inspector's audit defensible at the same time, with one artifact serving two very different audiences. The board sees the top five risks and their controls aggregated to one line each; the inspector sees the full register with evidence behind every control. Building one register that serves both is more disciplined than maintaining two narratives, and it removes the single most dangerous gap in a regulated AI program, the gap between what you told the board and what you can show the FDA. When those two come from the same living document, the strategist never has to reconcile a board promise against an inspection reality under pressure, because they were never allowed to diverge.

The Functional Risk Taxonomy: Naming the Seven Failure Modes

A register is only as good as its taxonomy, and a vague taxonomy ("AI errors," "data issues") produces a useless register because controls cannot attach to vague risks. The function-level taxonomy that holds up across regulatory, medical writing, clinical operations, and pharmacovigilance functions has seven distinct entries, each of which fails differently, is detected differently, and is controlled differently. The first is hallucination: the model generating fluent, confident, factually wrong content, the fabricated TLF table, the invented dose, the plausible-but-wrong hazard ratio, the citation to a study that does not exist. This is the most familiar risk and the one most likely to be under-controlled precisely because it is familiar, and its control is structural, source-reconciliation gates and named-author sign-off, not behavioral reminders, because hallucination is emergent from next-token sampling and cannot be trained away by telling writers to be careful.

The second is drift: the silent degradation or change in model behavior over time as a vendor updates the underlying model, retrains it, or changes the system prompt or retrieval layer, so that a tool validated in March behaves measurably differently in September without anyone deciding it should. Drift is the risk the PCCP framework was built to manage, and its control is ongoing performance monitoring against acceptance criteria with defined re-validation triggers, because a tool that drifts below its qualified performance is no longer the tool you validated, and content produced after the drift is content produced by an unvalidated system. The third is vendor failure: the AI vendor going insolvent, being acquired and sunset, suffering a security breach, changing terms in a way that breaks your data-protection posture, or simply failing to deliver during an in-flight submission. Its control is concentration management, an exit plan with data portability, and contractual protections, and the register must name what happens to a live submission if the vendor disappears on Day 60.

The fourth is IP and confidentiality exposure: trade secrets in CMC sections, commercial confidential information in a 483 response, PHI in a case narrative, or KOL personal data flowing into a model that retains or trains on it. Its control is the vendor BAA, zero-data-retention configuration, and the de-identification and data-classification discipline that decides what may touch which tool. The fifth is regulator non-acceptance: the risk that the way AI was used, or disclosed, or documented is itself found unacceptable by a health authority, independent of whether the content was correct, because the process did not meet the FDA-EMA principles' expectations on transparency, documentation, or human accountability. Its control is the AI use log, the cover-letter disclosure discipline, and alignment to the principles by design. The sixth is the inspection finding: the risk that a PAI or GCP/GMP inspection cites the AI program itself, a missing audit trail, an unvalidated tool, an undocumented run, producing a 483 observation that triggers the EIR cycle. The seventh is post-market risk: the distinct, often-underweighted risk that AI used in pharmacovigilance, signal detection, or post-approval content misses a safety signal, mis-codes an ADR, or produces a defective PSUR section, where the failure mode is not an embarrassing submission but a patient-safety and regulatory-reporting failure with its own legal weight.

Anatomy of a Register Entry: The Columns That Matter

A risk register that is just a list of risks is a worry diary, not a management system, and the difference is in the columns. A defensible function-level entry carries, at minimum: the risk statement written as a specific failure against a named artifact, not a category; the inherent risk rating before controls, scored on likelihood and impact using the same scale as the function's existing ICH Q9(R1) quality risk management so the AI register speaks the company's native risk language; the control or controls that bound the risk; the residual risk rating after controls; the named owner accountable for the control's effectiveness; the evidence that the control is operating, which is the column most registers omit and the one an inspector goes to first; the monitoring or detection mechanism and its cadence; and the trigger and escalation path for when the residual risk is breached. An entry missing the evidence column or the owner column is not a managed risk; it is a documented intention, and an inspector knows the difference instantly.

The single most important discipline in scoring is to rate inherent risk honestly and high. A register that scores hallucination as low-inherent-risk because "our writers are careful" has already failed, because it has conflated the control (careful writers, which is weak) with the inherent risk (the model fabricates by architecture, which is high). Inherent risk is the risk before any control, and for most AI failure modes in a regulated function it is high precisely because the failure is fluent, plausible, and survives a casual reviewer. The honesty of the inherent rating is what justifies the rigor of the control, and a board or inspector who sees inherent risk rated low for hallucination concludes, correctly, that the program does not understand its own exposure. The residual rating, after the structural controls, is where the program earns its low number, and the gap between inherent-high and residual-low, fully evidenced, is the story the containment slide actually tells.

The evidence column deserves its own discipline because it is where registers most often turn out to be theater. "Source-reconciliation gate" as a control is a claim; the evidence is the claim-reconciliation log showing it was executed on a specific artifact, the audit trail showing the run was captured, the sign-off record showing a named author certified. A control with no evidence is indistinguishable, to an inspector, from a control that does not exist, and worse, asserting a control you cannot evidence is itself a finding, because it means the quality system describes a state of control that is not demonstrated. The strategist building the register must therefore refuse to enter any control whose operation cannot be evidenced, which has the salutary effect of forcing the program to build real controls rather than aspirational ones, because the register will not let an unevidenced control hide.

Rating, Prioritizing, and the Residual-Risk Decision

Once the seven failure modes are decomposed into specific entries against named artifacts, the register has to be prioritized, because a function may have forty entries and a board can see five and a quarter has limited remediation capacity. Prioritization runs on residual risk, not inherent risk, because inherent risk tells you where the danger is and residual risk tells you where the danger still is after you have done your work, which is where attention belongs. The entries with high residual risk are the ones where the control is weak, missing, or unevidenced, and they are the register's to-do list and the honest content of any board escalation. A program that escalates only its successes has misunderstood the register's purpose; the register exists to surface the residual risks that are not yet adequately controlled, so that resources flow to them before an inspector finds them.

The residual-risk decision also forces an explicit accept-or-treat choice that immature programs leave implicit, and leaving it implicit is itself a risk. For each entry, the function must decide whether the residual risk, after available controls, is acceptable, and if so, who has the authority to accept it, because accepting a residual risk is a decision that must be made by someone with the standing to own its consequences. A residual hallucination risk on a flagship NDA's benefit-risk section is not a risk a junior writer may accept; it is a risk the head of the function, or the Quality Council, accepts explicitly and on the record, or treats with additional controls. The register makes this decision visible and attributable, which is precisely what the FDA-EMA accountability principle and the duty of oversight both require, and it prevents the most common governance failure, the risk that everyone assumed someone else had accepted.

Maintaining the Register: The Living-Document Discipline

A risk register's value decays the moment it stops being maintained, and a stale register is worse than no register, because it asserts a state of control that no longer exists and converts an inspection from a conversation into a finding. The register must be a living document with a defined review cadence, an owner of the register itself distinct from the owners of individual risks, and version control under the same change-management discipline as any GxP record, so that an inspector can see not just the current state but the history of how risks were identified, rated, controlled, and re-rated over time. That history is itself evidence of a functioning risk-management process, which is often what the inspector is actually assessing, more than the current snapshot, because a process that demonstrably learns and updates is the hallmark the FDA-EMA principles' ongoing-lifecycle-monitoring expectation is looking for.

Maintenance has specific triggers beyond the periodic review, and naming them is part of building the register. A new AI use case in the function triggers a register entry before the use case goes live, not after, because a risk identified after deployment is a risk that ran uncontrolled in production. A vendor model update or system-prompt change triggers a drift re-assessment of every entry that depends on that tool. An incident, a caught hallucination that nearly reached a submission, a drift breach, a near-miss on confidentiality, triggers an entry update and, often, a control strengthening, and the incident itself is logged so the register reflects what actually happened rather than what was supposed to. A regulatory development, a new guidance, an inspection trend, a peer-company enforcement action, triggers a review of the regulator-non-acceptance and inspection-finding entries. The register that updates on these triggers is alive; the register that updates only annually is a snapshot that is wrong for eleven months of the year.

The deepest maintenance discipline is the feedback loop from the rest of the program into the register. The metrics from the measurement chapter feed the register: a rising query rate or IR volume on AI-assisted content is a leading indicator that a control is weakening and a residual rating should rise. The drift monitoring from the validation chapter feeds the register directly. The board reporting from the previous lesson draws from the register and, in turn, the questions the board asks feed back as new entries or re-ratings. A register wired into the program this way is not a document the strategist maintains as a chore; it is the nervous system of the function's AI risk posture, the place where every signal from operations, validation, measurement, and governance is integrated into a single, owned, evidenced view of where the function stands and what it must fix next.

What the Inspector Actually Tests, and Why the Register Answers It

When an FDA or EMA inspector engages with a function's AI use in 2026, they are not testing whether the company uses AI, which is now unremarkable; they are testing whether the company is in a state of control over its AI use, which is the GxP question that has always been asked of every production system. The register is the artifact that answers the state-of-control question directly, because state of control is exactly what a complete, owned, evidenced, maintained register demonstrates: that the function has identified its risks, rated them honestly, controlled them with evidenced controls, assigned them to accountable owners, and maintained the whole through a living process. An inspector who asks "how do you know AI did not fabricate content in this submission" is asking to see the hallucination entry, its control, its evidence, and its owner, and a function that can produce all four in two minutes has demonstrated control, while a function that improvises has demonstrated its absence.

The register's final value is that it converts AI risk from an existential, unbounded fear, the thing that keeps the CRO awake, into a bounded, managed, attributable system that behaves like every other GxP risk the company already knows how to manage. That conversion is the actual deliverable of this lesson, and it is what the AI Function Strategist is for: not to eliminate AI risk, which is impossible, but to render it managed, evidenced, and owned, so that the board can fund it, the inspector can accept it, and the function can use AI at scale without the program living one fabricated table away from a Warning Letter. The next lesson builds the governance structure that owns this register, the committee, the decision rights, and the escalation paths that turn a well-built register into a functioning system of accountability.

Key Takeaways

• A function-level register exists because AI risk is a taxonomy of distinct failure modes at workflow altitude, not one line in the enterprise register. Only the function-level artifact can name a hallucinated TLF cross-reference against a specific Module 2.5.4 and assign the control to the person who owns that workflow step, which is what the FDA-EMA accountability principle requires.
• The taxonomy has seven distinct entries, each failing, detected, and controlled differently: hallucination (structural reconciliation gates), drift (PCCP-style monitoring with re-validation triggers), vendor failure (concentration management and exit plan), IP and confidentiality exposure (BAA, zero-data-retention, de-identification), regulator non-acceptance (use log and disclosure discipline), inspection finding (audit trail and validation), and post-market risk (the patient-safety failure mode in PV and signal detection).
• The columns that turn a worry diary into a management system are the inherent rating, the control, the residual rating, the named owner, the evidence the control operates, the detection mechanism, and the escalation trigger. Rate inherent risk honestly high, because conflating "careful writers" with low inherent risk hides the architecture-driven exposure, and refuse any control you cannot evidence, because an unevidenced control is indistinguishable from a missing one to an inspector.
• Prioritize on residual risk, and make the accept-or-treat decision explicit and attributable. Residual risk is where danger still lives after the work, so it drives the to-do list and the honest board escalation, and a residual risk on a flagship benefit-risk section is accepted on the record by someone with standing, not assumed away by everyone.
• The register must be a living document with version control, a register owner, defined review cadence, and named update triggers, new use case, vendor change, incident, regulatory development. Its history is itself the evidence of a functioning, lifecycle-monitoring risk process that answers the inspector's real question, which is whether the function is in a state of control over its AI use.