Building an AI Governance Committee That Approves Use Cases in Weeks, Not Quarters

Where the Time Goes When AI Approvals Take a Quarter

Ask a business team how long it took to get an AI use case approved and you will often hear “about three months.” Ask the reviewers how much time they spent on it and the answer is usually a few hours. The gap between those two numbers is the problem this article addresses. Review effort is rarely what slows approval. Queue time is.

The formal structures are now common. In the IAPP and Credo AI survey behind the AI Governance Profession Report 2025, 39% of organizations said they had an AI governance committee, and respondents at organizations with a committee were less likely to report challenges in AI governance reporting, including the lack of a clear mandate¹. A committee is a start. What it does with each request decides whether the business sees it as help or as an obstacle.

The Five Waits

When we trace a slow approval in a life-sciences company, the elapsed time almost always breaks down into the same five waits:

• Waiting for the meeting. The committee meets monthly. A request that arrives the day after a meeting waits four weeks before anyone looks at it, and another four if a question comes up that cannot be answered in the room.
• Waiting for a complete submission. The requester sends a two-line email. Quality asks what data it touches, IT asks which tool, privacy asks whether personal data is involved, and each question takes a week to answer because each one goes back separately.
• Waiting for someone to own the decision. Nobody is sure whether a moderate-risk use needs the full committee, so it goes to the full committee to be safe. The agenda fills with small items and the large items slip.
• Waiting for a debate that already happened. A second department wants to use the same approved tool for the same kind of work. The committee has no record it can point to, so it reviews the request from scratch.
• Waiting with no deadline. No one has promised the requester a date. Reviews expand to fill the time available, and a request can stay in “under review” for months without anyone noticing.

Each wait has a specific fix, and the fixes are the five mechanics in this article. Tiers with their own approval paths remove the third wait. Pre-approved patterns remove the fourth. The evidence packet removes the second. A fixed review cycle with response times removes the first and fifth. Decision records make the patterns possible and keep the whole system consistent over time.

What a Faster Process Looks Like in Practice

The most useful public numbers on AI review cycle time come from outside pharma, from health system and technology company programs that have measured their own process. They show both what is achievable and how the fast programs get there.

Duke Health described its governance framework for algorithm-based clinical decision support in a 2022 paper in the Journal of the American Medical Informatics Association. The program registers every algorithm used in patient care, then triages each one using a risk-based approach to one of three routes: full committee review, a fast-track review, or no further review. The team recorded date stamps at each step so it could measure its own operations. As of October 2021 it was managing 52 models. The average time from registration to triage was one week, checkpoint presentations before the oversight committee occurred on average in one month, and the decision came less than a week after the presentation². A health system is not a drug manufacturer, and clinical decision support is a different regulatory setting, but the mechanics are the ones this article recommends: registration first, risk-based routing, a short list of routes, and timestamps on every step.

Microsoft’s 2025 Responsible AI Transparency Report describes a different scale. More than 1,300 generative AI cases were submitted to its Responsible AI experts for guidance in 2024. To handle that volume while keeping a consistent bar for release, Microsoft built shared tools and instructions, and set up a wider network of employees, including Responsible AI Champs, to help product teams prepare before their pre-deployment review. It also launched an internal workflow tool to bring its responsible AI requirements into one place³. The lesson for a pharma committee is direct: at volume, the work that keeps review fast happens before the review, in preparation and in standard formats.

Match the Approval Effort to the Risk, Not to the Meeting Calendar

Pharma does not need a new principle to justify a faster approval path for low-risk AI. It already has one, and quality leaders know it well. ICH Q9(R1), the quality risk management guideline adopted in January 2023, states as one of its two primary principles: “The level of effort, formality and documentation of the quality risk management process should be commensurate with the level of risk.”⁴ Q9(R1) also describes formality as a continuum rather than a choice between formal and informal, and lists characteristics of lower formality, such as handling risk within other parts of the quality system and not always needing a cross-functional team⁴.

That principle carries straight into AI governance. A committee that sends every AI request through the same full review is not being more careful. It is applying high formality to low-risk decisions, which Q9(R1) does not ask for, and it is spending the committee’s limited attention on items that do not need it.

Regulators Say the Same Thing About AI

The AI-specific guidance from regulators points the same way. In January 2026, FDA and EMA jointly published ten guiding principles of good AI practice in drug development. The second principle reads: “The development and use of AI technologies follow a risk-based approach with proportionate validation, risk mitigation, and oversight based on the context of use and determined model risk.”⁵ The fourth asks that AI technologies have a well-defined context of use, which the document explains as the role and scope for why the AI is being used⁵. Both points shape the approval design below: oversight should be proportionate, and the context of use is what determines the proportion.

EMA’s reflection paper on AI in the medicinal product lifecycle, dated September 2024, uses the terms “high patient risk” and “high regulatory impact” to mark where scrutiny should be greatest, and states plainly that “The level of scrutiny depends on the level of risk and regulatory impact posed by the system.”⁶ NIST’s AI Risk Management Framework makes the same point in governance terms. Its GOVERN 1.3 subcategory calls for processes, procedures, and practices “to determine the needed level of risk management activities based on the organization’s risk tolerance,” and GOVERN 1.5 asks organizations to plan periodic review and decide how often it happens⁷.

A Public Example of Streamlined Approval

The clearest written instruction to streamline AI approvals comes from US federal policy rather than drug regulation. OMB Memorandum M-25-21, issued April 3, 2025, governs AI use by federal agencies. It does not apply to pharma companies, but its approval design is worth reading. It directs agencies to enable “trained and accountable agency officials at the lowest appropriate level” to identify, assess, mitigate, and accept risk for AI use cases. For high-impact uses, it says that where possible, agencies “should streamline approvals for intended use cases that are closely related in their deployment context and have substantially similar risk profiles.”⁸ That sentence is a good one-line description of a pre-approved pattern, which we return to below.

Risk Tiers With Their Own Approval Paths

Most AI governance programs already assign a risk tier to each use case. Our earlier article on the AI use case register sets out triage criteria (GxP impact, data sensitivity, decision role, and model type) and four tiers that quality and IT can agree on. This article does not repeat those criteria. It addresses what many programs leave out: once a use has a tier, the tier should decide who approves it, how, with what evidence, and by when. A tier that changes the controls but not the approval path does nothing for speed.

A Sample Tier Table With Approval Paths

The table below is a starting design. Adjust the names and the response targets to your volume and staffing, but keep the structure: one row per route, one named decision maker per route, and a response target for every row.

Three features of this table do most of the work. First, only one route goes to the full committee. Everything else is decided by a named person or a small panel. Second, the Tier 3 response target covers the go-ahead decision, not the validation. Validation takes as long as validation takes, and pretending otherwise creates pressure to cut it short. What the committee can promise is that a GxP-critical proposal will get a clear yes, no, or “yes with conditions” within one cycle, so the project team can plan the validation work. Third, the “not eligible as designed” route is a real outcome with its own target. A fast, clear “no, but here is what would work” is far more useful to a business team than a slow “maybe.”

Delegated Approvers Can Approve or Escalate, Not Reject

Delegating approval raises a fair concern: what if one person makes a poor call? Human research protection in the US has dealt with this question for decades, and its answer is worth copying. Under 21 CFR 56.110, an institutional review board may use an expedited procedure for research on a published list of minimal-risk categories, and for minor changes to research it has already approved. The review can be carried out by the IRB chairperson or by experienced reviewers the chair designates. Those reviewers may exercise all of the IRB’s authorities except one: they may not disapprove the research. Disapproval can only come from the full board. The regulation also requires the IRB to keep all members informed of what was approved under the expedited procedure⁹.

Apply the same two rules to delegated AI approvals:

• A delegated approver can approve, approve with conditions, or escalate. They cannot reject on their own. If they believe a use should not go ahead, they send it up to the review panel or the committee with their reasoning. This protects requesters from one person’s caution and protects the company from one person’s enthusiasm, because anything contested reaches a group.
• The full committee sees everything that was approved below it. A one-page digest at each committee meeting lists every delegated and pattern approval since the last meeting, with the tier and the approver. Committee members can pull any item for discussion. Most never are, but the visibility keeps delegated approvers consistent and gives the committee an early view of where demand is growing.

Name the Approvers, Not Just the Roles

A charter that says “Tier 1 uses are approved by a delegated approver from the relevant function” will not speed anything up until someone writes down who those people are. Keep a short list: one or two approvers per function, each with a named backup, each trained on the tier rules and the evidence packet. When an approver leaves or changes role, updating the list is a governance coordinator task, not a committee agenda item. Our article on AI steering committee charters includes a decision authority matrix that sets out which body holds which decision. The list of named approvers is what makes that matrix usable day to day.

Pre-Approved Patterns: Decide Once, Reuse Many Times

A large share of AI requests are not new. They are a second, third, or tenth team asking to do something the company has already approved somewhere else. The second team in regulatory operations that wants to use the approved enterprise assistant to summarize non-GxP meeting notes is asking the same question the first team asked. If the committee reviews it again from the start, the answer will be the same and the requester will have waited a month for it.

A pre-approved pattern is a written approval for a kind of use, with the conditions that make it safe stated in advance. A request that meets every condition inherits the approval and its controls. A request that fails any condition goes through the normal route for its tier.

Pharma Already Uses This Approach for Manufacturing Changes

The idea is familiar from post-approval change management. ICH Q12 describes the post-approval change management protocol (PACMP) as a regulatory tool that provides predictability about what is needed to implement a CMC change, because the approved protocol is an agreement between the marketing authorization holder and the regulator. The protocol describes the change, how it will be prepared and verified, and a suggested reporting category, which can be a lower reporting category or a shorter review period than the same change would get without an approved protocol. The protocol also sets specific conditions and acceptance criteria that must be met¹⁰. FDA’s guidance on comparability protocols, finalized in October 2022, works the same way in the US: an approved protocol is an agreed plan, and if the activities are not performed or the predefined acceptance criteria are not met, a reduced reporting category is not justified¹¹.

ICH Q12 adds a point that every AI pattern should copy. If new information appears after the protocol is approved, the risk assessment should be reviewed before the change is made, and if that review shows increased risk, the previously approved reporting category should no longer be considered appropriate¹⁰. In other words, a pre-approval is conditional on the facts it was based on. When the facts change, the faster route no longer applies.

An internal AI pattern is not a regulatory filing, and nothing here suggests a regulator has approved anything. The point is narrower. Pharma quality and regulatory teams already trust the structure of “agree the conditions in advance, then confirm each instance meets them.” Presenting AI patterns in those terms usually wins quality’s support faster than any argument about efficiency.

What a Pattern Card Contains

Each pattern should fit on one page. A longer pattern is usually two patterns, or a pattern trying to cover a GxP use that needs its own review. A workable pattern card has these fields:

The Fit Check

The fit check is what makes a pattern safe to use without a full review. It should be a short list of yes or no questions, written so that a business user can answer them honestly without help, and so that any “no” or “not sure” sends the request to its normal route. For the summarization pattern above, a fit check might read:

1. Will you use only the approved enterprise assistant, with no other plug-ins or connectors?
2. Is all content you will put into it internal or public, with no GxP records, no patient or study subject data, and no personal data beyond names in meeting notes?
3. Will a person on your team read and correct every summary before it is shared or stored?
4. Will the summaries stay out of any GxP process, record, or decision?
5. Has everyone who will use it completed the acceptable use training?
6. Is there a named owner on your team who will answer the annual attestation?

The governance coordinator confirms the answers, checks the request against the pattern’s exclusions, and records a decision that cites the pattern ID. The pattern owner is informed, not asked. The request is closed within the response target, and the committee sees it in the next digest.

Starter Patterns Worth Writing First

Write patterns where you already see repeat demand. In most pharma and biotech companies the first four are similar:

When a Pattern Does Not Apply

Patterns are for repeat uses below the GxP-critical line. A direct GxP use does not become routine because a similar one was approved elsewhere. Even so, the same structure helps at Tier 3 in a narrower way. When a validated AI tool is being extended to a second site or a second product, the committee can agree in advance what evidence the extension needs (for example, which tests are repeated and which are covered by the original validation), much as a PACMP agrees the studies in advance. The extension still goes through change control and quality approval. What the pattern removes is the argument about what to provide.

The Standard Evidence Packet

Incomplete submissions are the most common cause of slow review, and the easiest to fix. If the requester does not know what the reviewers will ask for, the review becomes a series of questions sent one at a time. A standard evidence packet changes the order of work: the requester gathers everything first, a coordinator checks completeness, and only then does the review start.

The packet also gives reviewers a shared format. When every request arrives with the same sections in the same order, a reviewer who handles ten a month gets faster at each one. NIST’s Generative AI Profile points in the same direction when it suggests setting minimum thresholds for performance or assurance criteria and reviewing them as part of go/no-go deployment approval processes¹². A packet makes those thresholds visible to the requester before they submit, instead of discovered during review.

A Sample Evidence Packet

The sample below covers sections A to L. Tier 1 requests complete sections A to G. Tier 2 and Tier 3 requests complete all sections. Most sections take a few sentences, not a few pages.

Section A deserves the most care. The FDA and EMA principles put context of use at the center of AI oversight⁵, and in practice most disagreements between reviewers trace back to a vague use summary. “Use AI to help with deviations” could mean anything from drafting an email about a deviation to deciding its root cause. “Generate a first-draft summary of the deviation record for the assigned investigator, who edits and approves it in the eQMS” tells every reviewer what they need to know.

Section G is what connects the packet to the rest of the system. Asking the requester to name the closest pattern or precedent does two things: it routes pattern matches to the fast path immediately, and it makes the requester explain how their use differs from an approved one, which is often the only question the reviewer needs answered.

The Completeness Check

A governance coordinator checks each packet for completeness within two business days. The check is about whether the sections are filled in, not whether the answers are good. Incomplete packets go back with a single consolidated list of what is missing, never one question at a time. The review clock does not start until the packet is complete, and the requester is told that plainly, so they know the fastest route to a decision is a complete submission.

Help Requesters Get It Right the First Time

A packet only speeds things up if requesters can complete it. Three supports make the difference:

• A completed example for each tier, using a realistic but fictional use case, kept next to the blank form.
• Prepared answers for approved tools. Sections C and D for the enterprise assistant should be written once by IT and copied into every packet that uses it. Requesters should never have to research the hosting arrangements of a tool the company already licenses.
• A small network of trained helpers. Microsoft’s network of Responsible AI Champs helps product teams prepare before their reviews³. In a pharma company, one or two people in each major function who know the packet well can do the same, and their help is the reason most packets arrive complete.

A Fixed Review Cycle and Published Response Times

A process with no deadlines will be slow even if every other part is well designed. The fix has two parts: a fixed calendar of review slots that do not depend on the committee’s monthly meeting, and response times that are published to requesters and measured.

Separate the Review Calendar From the Committee Calendar

Our earlier article on cross-functional AI steering committees recommends a monthly committee meeting with a quarterly portfolio review. That rhythm suits strategy, portfolio, and GxP-critical decisions. It is far too slow for individual Tier 1 and Tier 2 requests. Those need their own, faster cycle:

• Daily or continuous: intake, completeness checks, Tier 0 and pattern decisions by the governance coordinator.
• Weekly: a short standing slot where delegated approvers and the coordinator clear Tier 1 items and agree which Tier 2 items need a panel call.
• Every two weeks: a Tier 2 panel call, held only if there are items where reviewers disagree. If there are none, the call is canceled.
• Monthly: the committee meeting, which takes Tier 3 go-ahead decisions, escalations, new or changed patterns, and the digest of decisions made below it.

The effect is that no request below Tier 3 ever waits for the monthly meeting. A Tier 3 request still does, but it arrives with a complete packet and a coordinator’s summary, so the committee can decide it in one session.

A Sample Service-Level Table

Response times only work if everyone agrees when the clock starts, when it pauses, and when it stops. Write those rules down.

What Happens When a Target Is Missed

Some programs make a missed deadline count as approval. In a regulated company that is the wrong default, because it rewards reviewers for ignoring hard requests. The better rule is that a missed target escalates. If a Tier 1 approver has not decided within five business days, the request moves automatically to their backup, and then to the panel. If the panel misses its target, the item goes to the committee chair. Every missed target appears in the monthly digest with the reason. Nobody wants their name on that list twice, and the visibility does more for response times than any reminder email.

The Life of a Request

Measure the Process and Publish the Numbers

Duke Health recorded date stamps at every step of its process so it could report its own cycle times². Do the same. The governance coordinator should report a small set of numbers to the committee each month and share them with the business:

• Median days from complete packet to decision, by route
• Share of decisions made within the target, by route
• Share of packets returned as incomplete at first submission
• Share of all requests closed through a pattern
• Number of escalations, and how many were decided differently from the delegated approver’s recommendation
• Oldest open request and its current step

Publishing the numbers to requesters matters. Teams that can see a Tier 1 request is decided in a median of four days stop building workarounds, and teams that work around governance are the main source of shadow AI.

Decision Records Built for Reuse

Every committee keeps minutes. Few keep decision records that a reviewer can find and apply six months later. The difference is the difference between a committee that reaches the same conclusion ten times and one that reaches it once.

A Format Borrowed From Software Architecture

Software teams faced this problem years ago. In a widely used 2011 post, Michael Nygard proposed recording each significant architecture decision as a short, separate document with five parts: title, context, decision, status, and consequences. He suggested keeping each record to one or two pages, and when a decision is reversed, keeping the old record and marking it as superseded rather than deleting it¹³. Those three habits (short, separate, and never deleted) are exactly what an AI decision log needs.

Adapted for AI governance in a regulated company, a decision record should contain:

The reasoning and scope fields are the ones that make reuse possible. A record that says only “Approved, Tier 2” tells the next reviewer nothing. A record that says “Approved for first-draft summaries of closed non-GxP complaints in the approved assistant; not approved for open complaints or for any summary used in trending, because those feed a GxP process” lets the next reviewer decide a similar request in minutes.

Search Before You Review

The decision log is only useful if someone looks at it. Make the precedent search a formal step, done by the coordinator before the request reaches a reviewer (step 3 in the life of a request above). The reviewer then starts with the closest earlier decisions in front of them. If the new request is the same in every way that matters, the reviewer can cite the precedent and decide. If it differs, the reviewer knows exactly which difference to examine.

Promote Clusters of Decisions Into Patterns

Patterns should come from decisions, not from a blank page. When the log shows two or three approvals of substantially the same use with the same conditions, the coordinator drafts a pattern card from them, lists those records as its source decisions, and takes it to the committee. This keeps patterns grounded in real requests and real reasoning, and it gives the committee a regular, useful agenda item: approving the patterns that will remove future requests from its agenda.

Track Exceptions the Way M-25-21 Tracks Waivers

Sometimes the committee approves a use that does not meet a standard requirement, for good reason. Those exceptions need more care than ordinary decisions, not less. M-25-21 sets a useful model for federal agencies: waivers from the minimum practices for high-impact AI must be tracked centrally, reassessed if there are significant changes to the conditions or context of use, certified annually, and summarized publicly with their justification⁸. A pharma committee does not need to publish anything externally, but the internal version is sound: keep exceptions in their own list, give each one an expiry date, reassess it when its context changes, and show the full list to the committee every quarter.

Where Fast Approval Goes Wrong

A fast approval process can drift back to a slow one, or worse, become fast for the wrong reasons. These are the failure points we see most often, with the signal that shows each one and the fix.

The GxP-Critical Path Needs Its Own Protection

Most of this article is about removing routine decisions from the committee. The point of doing so is to give Tier 3 decisions the time they need. Two practices protect that. First, Tier 3 items get a fixed share of each committee meeting, so they are never squeezed out by escalations. Second, the committee never accepts a Tier 3 response target that covers validation. The go-ahead decision can be fast. Validation under the company’s computerized system validation approach, quality approval before use, and change control proceed on their own plan, with the evidence the use requires. The FDA and EMA principles call for proportionate validation and oversight⁵, and proportionate means both things: lighter oversight for low-risk uses and full oversight for GxP-critical ones.

Getting Started Without a Big Program

None of this needs new software or a long rollout. A practical order of work:

1. Measure first. Pull the dates on your last ten requests and find the longest wait.
2. Write the tier table with approval paths and get the committee to approve the delegation, including named approvers and backups.
3. Publish the evidence packet with a completed example per tier, and prepared sections C and D for the tools you already license.
4. Start the weekly slot and the monthly digest, and announce the response targets to the business.
5. Convert existing approvals into decision records for anything still in use, starting with the most common tools.
6. Draft the first two or three patterns from the clusters you find in those records.

Conclusion

A slow AI governance committee is rarely a careless one. Usually it is a careful committee using one route for every decision, with no standard submission, no deadline, and no memory of what it decided last time. The fix is not to review less. It is to decide each request at the level its risk calls for, with the evidence collected before review starts, on a calendar the requester can see, and with a record the next reviewer can use. Pharma already works this way in quality risk management and post-approval change, and regulators have said the same about AI: oversight should be proportionate to the context of use and the risk. Approval in weeks is what proportionate oversight looks like when it is designed on purpose.

Sakara Digital works with pharma and biotech organizations building AI governance that the business will use rather than work around. If your committee is spending its time on repeat requests, or your teams are waiting a quarter for answers on low-risk uses, we are happy to talk through where the time is going and what to change first.

For Further Reading