When an integrated biopharma's general counsel asked the new Head of AI to "send me the AI policy," the honest answer was that the company had eleven of them. Legal had a generative-AI acceptable-use memo. IT had a sanctioned-tools list. Quality had a draft computer-system-validation appendix that mentioned AI in a footnote. R&D had a discovery-AI guideline written by a data-science team that had never spoken to regulatory. Privacy had a data-handling standard that predated large language models entirely. Each was reasonable in isolation, and together they were incoherent: a discovery scientist and a Module 2.5 medical writer were governed by different documents with different definitions of "high-risk," different approval paths, and no shared vocabulary, so the same model could be freely used in one corner of the company and effectively banned in another for no principled reason. An enterprise AI policy is not the eleventh document; it is the single instrument that makes the other ten cohere, scoped from discovery to commercial, categorized by risk, and aligned to the regulatory frameworks that actually bind the company, including the EU AI Act's high-risk-system requirements where they apply. This lesson is about how a Level 5 leader designs that instrument so that it governs without paralyzing, so that it survives an inspection and a board review, and so that it is specific enough to tell a writer on Monday what they may and may not do.

Why an Enterprise Policy and Not a Collection of Memos

The eleven-memo problem is not a failure of effort; it is the predictable result of AI governance growing up function by function, each function writing the document it needed without a shared frame, and the cost of that incoherence is real and regulatory. When a discovery scientist and a medical writer operate under different definitions of "high-risk," the company cannot make a consistent risk-based decision about any AI use, which is precisely what the FDA-EMA "risk-based" and "governance and documentation" principles require it to do. An inspector who finds two parts of the same company governing the same model under contradictory rules does not see eleven thoughtful documents; they see the absence of a quality system, because a quality system is by definition a single coherent set of controls, not a federation of local conventions. The enterprise policy exists to supply the missing frame: one definition of the risk categories, one approval architecture, one set of vendor-management requirements, and one documentation standard, under which every function's specific procedures become consistent local applications rather than independent inventions.

The policy also exists to solve a problem the memos cannot, which is the cross-functional workflow that the previous chapters built: a pilot or a scaled workflow that threads from discovery through translational, clinical, and regulatory crosses the jurisdiction of four different memos and falls into the gaps between them. The mechanism-of-action narrative that flows from a discovery hypothesis into a Module 2.5 introduction is governed, under the memo regime, by the discovery guideline at one end and the regulatory standard at the other, with no document owning the handoff in between, which is exactly where accountability evaporated in the cross-functional pilot. A single enterprise policy with one risk taxonomy and one handoff standard closes that gap by governing the workflow as a whole rather than governing each function's slice of it. The Level 5 leader's first design decision is therefore structural: the policy is the apex document, the functions write procedures beneath it, and nothing about AI is governed outside its frame.

Scope: From Discovery to Commercial, Deliberately

The scope of an enterprise AI policy is the whole drug-development lifecycle, from target discovery through commercial promotion, and the deliberate breadth is the point, because the failure mode of a narrow policy is the ungoverned corner. A policy scoped only to "regulated submissions" leaves discovery AI, which generates the hypotheses and molecules that everything downstream depends on, entirely ungoverned, and discovery AI is not low-risk simply because it is early; a biased generative-chemistry model or a flawed target-identification model propagates its errors through every subsequent phase. A policy scoped only to "GxP systems" leaves commercial and medical-affairs AI ungoverned, where the risks are promotional compliance, off-label exposure, and the handling of KOL and patient data, which are different risks but not smaller ones. The enterprise policy therefore covers discovery (generative chemistry, target identification, biomarker discovery), translational and nonclinical, clinical development and operations, regulatory affairs and submissions, pharmacovigilance, CMC and manufacturing, medical affairs, and commercial, with the explicit recognition that the risk profile changes across the lifecycle but the governance frame does not.

Scoping broadly does not mean governing uniformly, and the art of the policy is calibrating the weight of governance to the risk of the use, which is where the risk categories do their work. The policy's scope statement makes clear that everything is in frame while the risk categories ensure that an internal brainstorming use of a model and a Module 2.5 drafting use are not subjected to the same controls, because identical controls on unequal risks are both wasteful and, worse, training the organization to treat governance as bureaucracy to be evaded. The leader who scopes broadly and governs proportionately builds a policy that the organization experiences as sensible rather than obstructive, which is the only kind of policy that is actually followed, and a policy that is not followed is worse than no policy because it creates a documented standard the company is visibly failing to meet. Breadth of scope with proportionality of control is the design principle that makes an enterprise policy both comprehensive and livable.

The Three Risk Categories That Organize Everything

The spine of the policy is a risk taxonomy, and the cleanest taxonomy for a biopharma sorts every AI use into three categories: internal-use, regulated, and high-risk, defined by what the AI output touches rather than by which function produces it. An internal-use case is one whose output never enters a GxP artifact, a regulatory record, or a patient-affecting decision: summarizing internal meeting notes, drafting a non-promotional internal email, brainstorming a research direction that a human will independently validate. A regulated case is one whose output becomes part of a record an inspector or assessor may read: a Module 2.5 paragraph, an ICSR narrative, a CSR section, a monitoring visit report, a CMC comparability narrative. A high-risk case is one whose output influences an irreducible scientific or safety judgment, a benefit-risk conclusion, a causality assessment, a comparability conclusion, a dosing decision, or one that falls under an external high-risk-system regime such as the EU AI Act. The category, not the function, determines the controls, which is what gives a discovery scientist and a medical writer a shared vocabulary at last.

The power of defining categories by output rather than by function is that it correctly captures the cases where a nominally low-stakes function produces a high-stakes output and the reverse. A medical-affairs use that drafts an internal congress-debrief note is internal-use even though medical affairs is a regulated function; a discovery use whose generated structure-activity claim will be cited in an IND-enabling toxicology rationale is regulated even though discovery feels upstream and informal. The taxonomy also makes the high-risk category do specific regulatory work: where the EU AI Act applies, certain AI systems are designated high-risk and carry obligations for risk management, data governance, technical documentation, human oversight, transparency, and post-market monitoring, and the policy's high-risk category is the hook that pulls those obligations into the company's own controls rather than treating the AI Act as a separate compliance silo. By defining its high-risk category to encompass and align with the EU AI Act high-risk-system requirements where applicable, the policy ensures that a single internal classification triggers both the company's GxP controls and the external regulatory obligations, which is far more defensible than running two parallel and possibly contradictory classification schemes.

Approval Workflows That Match the Risk

A policy that classifies risk but does not route each category through a proportionate approval workflow is a taxonomy without teeth, and the design of the approval architecture is where the policy either enables work or strangles it. The proportionate design routes internal-use cases through a light path, often self-attestation against a published acceptable-use standard with no pre-approval, because subjecting a meeting-notes summary to a validation committee teaches the organization that governance is theater. Regulated cases route through a defined approval that requires a fit-for-purpose statement, a validation appropriate to the artifact, the human-accountability gate, and registration in the AI inventory, which is the same reference-pattern-and-variant discipline the scaling lesson established, now mandated by policy. High-risk cases route through the heaviest path: a formal impact assessment, model-card and data-card documentation, explicit human-oversight design, alignment to the EU AI Act high-risk obligations where applicable, and approval by the cross-functional governance body that the next lesson describes. The three paths share a structure but differ in weight, and the difference in weight is exactly proportional to the difference in risk.

The approval architecture must also specify what happens at the boundaries between categories, because the most contentious cases are the reclassifications, where a use that was approved as internal-use is found to be feeding a regulated artifact, or a regulated use is discovered to be influencing a high-risk judgment. The policy needs an explicit re-classification trigger and path, so that when a discovery scientist's "internal" structure-activity exploration starts being cited in an IND rationale, there is a defined mechanism to re-route it through the regulated approval before its outputs reach the submission, rather than the silent category-drift that produces ungoverned regulated use. This is the policy-level expression of the kill-and-scale-criteria discipline from the pilot lesson: the policy must make category boundaries observable and crossable through a controlled path, so that the organization cannot accidentally operate a high-risk use under internal-use controls. A leader who designs the approval workflows without the reclassification path has built a policy that governs the initial decision but not the drift, and drift is where the inspection findings live.

Vendor Management the Policy Cannot Skip

Most AI in a biopharma is bought, not built, which makes vendor-management requirements a load-bearing section of the policy rather than an appendix, and the requirements must be specific enough that a procurement team can apply them without re-litigating the policy for every contract. The policy mandates, for any vendor AI touching a regulated or high-risk use, a defined floor: a Business Associate Agreement or equivalent data-protection contract where personal or patient data is involved, zero-data-retention or contractually bounded data handling so that confidential submission content and trade secrets are not absorbed into a vendor's training corpus, model-version control so that the validated configuration does not change underneath the company without notice, captured-run metadata sufficient for a 21 CFR Part 11 audit trail, and sponsor audit rights over the AI workflow. These are not aspirational preferences; they are the conditions under which a vendor tool can be part of a defensible regulated workflow at all, and a vendor that cannot meet them cannot be used for regulated or high-risk cases regardless of how capable its model is.

The vendor-management section must also address the model-card and data-card standards that the policy adopts as a documentation requirement, because these are the artifacts that make a third-party AI system's intended use, training-data provenance, performance characteristics, and limitations legible to the company's own governance and to a regulator. A model card documents what the model is, what it was designed to do, how it performs, and where it should not be used; a data card documents the provenance, composition, and known biases of the data the model was trained or tuned on. For a high-risk use under the EU AI Act, technical documentation of exactly this kind is an obligation, and for any regulated use it is the evidence that lets the company make a fit-for-purpose determination rather than trusting a vendor's marketing. The policy requires that every regulated and high-risk vendor AI come with a model card and a data card, or that the company generate the equivalent documentation through its own qualification, so that no AI enters a regulated workflow as an undocumented black box. The leader who writes a vendor-management section without the model-card and data-card requirement has left the company unable to answer the regulator's most basic question about a third-party tool: what is it, and how do you know it is fit for this purpose.

Aligning to the EU AI Act Without Building a Parallel System

The EU AI Act introduces a risk-tiered regime in which certain AI systems are classified as high-risk and subjected to obligations for risk management, data governance, technical documentation, record-keeping, transparency, human oversight, accuracy and robustness, and post-market monitoring, and the temptation for a biopharma is to treat this as a separate compliance program run by a separate team. The Level 5 design insight is that this is a mistake, because the AI Act's high-risk obligations overlap heavily with the GxP and FDA-EMA controls the company already needs, and running them as parallel systems produces duplicated effort, contradictory classifications, and the inspection-grade incoherence the whole policy was meant to eliminate. The defensible design folds the AI Act's high-risk obligations into the policy's high-risk category, so that a use classified high-risk internally automatically inherits both the GxP controls and the AI Act obligations, and a single risk-management file, a single technical-documentation set, and a single human-oversight design satisfy both regimes rather than two divergent ones.

This integration requires the leader to map the obligations carefully, because the regimes are aligned in spirit but not identical in detail, and the policy must name where they diverge. The AI Act's data-governance obligation and the FDA-EMA data-quality principle are close cousins; the AI Act's human-oversight requirement maps to the human-accountability gate the program has taught throughout; the AI Act's post-market monitoring obligation maps to the lifecycle-monitoring principle and to the PCCP-style change control for any learning system. Where the AI Act adds a specific obligation that GxP does not, such as certain transparency and registration requirements for high-risk systems, the policy names that obligation explicitly and assigns it an owner rather than assuming the GxP controls cover it. The result is a policy that a European inspector and an FDA investigator can both read as a single coherent governance system that happens to satisfy both their frameworks, which is the strongest possible position, and which is achievable only if the leader resists the organizational pressure to build the AI Act compliance as a bolt-on. The integration is the design, and it is the difference between a policy that scales internationally and one that fragments at every border.

What This Means for the Leader on Monday

The leader tasked with the enterprise AI policy should resist the instinct to start drafting clauses and instead start with the three structural decisions that everything else follows from: the scope is the whole lifecycle, the spine is the three output-defined risk categories, and the high-risk category is designed to encompass the EU AI Act high-risk obligations so that one classification drives both internal and external requirements. With those three decisions made, the policy almost writes itself, because the approval workflows follow from the categories, the vendor-management floor follows from the regulated and high-risk requirements, and the model-card and data-card standards follow from the documentation obligations of both GxP and the AI Act. The first Monday action is to inventory the eleven existing memos and map each to the new frame, identifying which become procedures beneath the policy, which are superseded, and which contain a local definition that contradicts the enterprise taxonomy and must be reconciled.

The deeper discipline is to write the policy for the person who has to follow it on Monday, not for the lawyer who has to defend it in a deposition, because a policy that is unreadable to the medical writer and the discovery scientist will be ignored by them, and an ignored policy is a documented standard the company is failing to meet. The test of a good enterprise AI policy is that a medical writer can read the relevant section and know, without consulting anyone, that drafting a Module 2.5 paragraph is a regulated use that requires a fit-for-purpose statement, source-linked citations, a claim-reconciliation log, and registration in the AI inventory, while summarizing their own meeting notes is an internal-use case they may simply do. A policy that achieves that clarity governs without paralyzing, satisfies the inspector and the board, and gives every function a shared vocabulary for AI risk, which is the foundation the cross-functional governance councils of the next lesson are built to operate. The policy is the constitution; the councils are the government; and the leader who designs the constitution well makes the government possible.

Key Takeaways

• An enterprise AI policy is the single instrument that makes the function-by-function memos cohere, not the eleventh memo. Contradictory local definitions of "high-risk" mean the company cannot make a consistent risk-based decision, and an inspector reads two parts of the company governing the same model under contradictory rules as the absence of a quality system rather than as thoughtful local governance.
• Scope the policy across the whole lifecycle, from discovery to commercial, but govern proportionately. A narrow policy leaves ungoverned corners (discovery AI is not low-risk because it is early; commercial AI carries promotional and data risks), and breadth of scope with proportionality of control is the only design the organization experiences as sensible rather than as bureaucracy to be evaded.
• The three output-defined risk categories, internal-use, regulated, and high-risk, are the spine that gives every function a shared vocabulary. Defining categories by what the output touches, not by which function produces it, correctly captures low-stakes functions producing high-stakes outputs, and designing the high-risk category to encompass the EU AI Act high-risk-system requirements makes one classification trigger both GxP and external obligations.
• Approval workflows must be proportionate and must include a reclassification path. Internal-use self-attests, regulated cases require a fit-for-purpose statement and AI-inventory registration, and high-risk cases require an impact assessment, model and data cards, and governance-body approval, while an explicit reclassification trigger prevents the silent category-drift where an "internal" use quietly starts feeding a regulated artifact.
• Vendor management with mandatory model-card and data-card standards is load-bearing, and the EU AI Act folds into the high-risk category rather than running as a parallel system. The vendor floor (BAA, zero-data-retention, model-version control, captured-run metadata, audit rights) is the condition for a defensible regulated workflow, and integrating the AI Act's high-risk obligations into the policy lets a single risk-management file and human-oversight design satisfy both the European and FDA frameworks as one coherent system.