The AI Use Case Register: Triage Criteria Quality and IT Can Agree On

Why AI Registers Fail Before Anyone Reads Them

An AI use case register is a simple idea. You write down every place the company uses AI, you say how risky each one is, and you apply controls in proportion. The difficulty is not the idea. The difficulty is that two functions with different questions are asked to share one list, and each ends up building its own.

Quality asks: does this use affect a GxP decision, a GxP record, or a patient? If so, what validation and oversight does it need? IT asks: what software is this, who supplies it, what data flows into it, and is it approved under our security and architecture standards? Both questions are fair. The trouble starts when quality’s list is organized by process and IT’s list is organized by application. A single vendor platform can hold six AI features used in four processes. A single process can draw on three AI tools from three suppliers. Neither list maps cleanly onto the other, so reconciliation becomes a quarterly argument rather than a routine check.

What Public Inventories Have Already Taught Us

The U.S. federal government has run AI use case inventories for several years, and the results are a useful warning. In December 2023 the Government Accountability Office reviewed the inventories of 20 agencies that reported AI use. It found that only five gave complete information for each reported use case. The other 15 had incomplete or inaccurate entries, such as missing life cycle stage fields, and two inventories listed uses that the agencies later decided were not AI at all¹.

The federal program has since matured. The 2025 consolidated inventory, compiled by the Office of Management and Budget (OMB) from agency submissions, lists 3,611 individually reported use cases, of which 445 were identified as high-impact². OMB also created a separate “consolidated” reporting format for common tasks that run on commercial off-the-shelf products, so that the individual inventory stays focused on the uses that matter most. A use case that is high-impact cannot be reported in the consolidated format². That design choice, a light entry for routine embedded AI and a full entry for anything consequential, is one of the most useful ideas a pharma register can borrow.

The third figure explains why a register built only from procurement records will always be short. In Microsoft and LinkedIn’s 2024 Work Trend Index, which surveyed 31,000 knowledge workers across 31 countries, 75% of respondents said they use generative AI at work, and 78% of those AI users said they bring their own tools³. The survey was not specific to life sciences, but there is no reason to assume regulated companies are immune. A register has to be fed from more than one channel, and it has to make registering a use easier than hiding it.

A Register Is Not a Model Registry or a System Inventory

Much of the friction between quality and IT comes from using one word for three different lists. It helps to separate them before building anything.

The register links to the other three but does not replace them. An entry points to the system inventory record for the platform it runs on and to the model registry record for the model version it uses, where one exists. It does not copy their contents. Keeping the register thin in this way is what makes it maintainable.

What Counts as One Use Case

Before any triage can happen, both teams need the same answer to a basic question: what is one entry? If quality registers “the deviation management system” and IT registers “the LLM feature in the deviation management system” and the business registers “AI-drafted investigation summaries,” you have three entries for one thing and no agreement on which one carries the risk rating.

The Unit of Entry

We recommend a simple rule: one entry equals one AI capability, applied to one process step, for one purpose. The same model used for two purposes becomes two entries, because the risk comes from the use, not the model. A classifier that flags possible adverse events in customer emails is a different use from the same classifier sorting product complaints by category, even if the code is identical. The first can affect a safety reporting clock. The second probably cannot.

This matches the federal approach. OMB memorandum M-25-21 tells agencies to evaluate the AI’s specific output and its potential risks when deciding whether a use is high-impact, which only works if each entry describes one use with one output⁵. It also matches how regulators frame AI risk. FDA’s draft guidance on AI to support regulatory decision-making asks sponsors to define a “context of use” and assesses risk for that context, not for the model in the abstract⁷. The draft guidance has not been finalized, but its logic is sound for internal governance whether or not a use will ever reach a submission.

Embedded Vendor AI and the Consolidated Entry

The fastest-growing source of AI in most companies is not an AI project at all. It is an AI feature switched on inside software the company already licenses: a summarization button in the eQMS, a drafting assistant in the document management system, a meeting transcription feature in the collaboration suite. Registering each one as a full entry buries the register in noise. Ignoring them leaves a gap that an inspector will find.

The federal approach offers a workable middle path. OMB allows agencies to report a limited set of common tasks that run on commercial off-the-shelf products in a consolidated format, while any high-impact use must be reported individually². For a pharma register, that becomes a consolidated entry: one record per approved general-purpose AI capability (for example, “enterprise chat assistant for general drafting”), with the permitted uses and prohibited uses listed. The moment someone applies that capability to a GxP process step or a restricted data set, it needs its own entry and its own triage. The consolidated entry covers the routine case. It never covers the consequential one.

Is It AI? A Working Test

GAO’s finding that two federal inventories contained uses later judged not to be AI is a reminder that the first triage question is whether the thing belongs in the register at all¹. Vendors label rule engines, statistical process control, and keyword search as AI. Internal teams sometimes do the same to attract funding.

A practical test comes from the draft EU GMP Annex 22, which applies to machine learning models that “have obtained their functionality through training with data, rather than being explicitly programmed”⁶. That wording gives quality and IT a shared, checkable question: was the behavior learned from data or written as rules? If it was written as rules, it belongs in the ordinary computerized system inventory and the ordinary validation approach. If it was learned, it goes in the register. Record the answer either way, including for the items you exclude, so the next reviewer does not reopen the same question.

The Fields to Capture, and Who Owns Each One

Registers fail in two opposite ways. Some ask for so little that the entry cannot support a decision. Others ask for so much at intake that people stop submitting. The fix is to split the fields into three groups: what the requester provides at intake, what the triage team adds, and what keeps the entry current afterward.

The NIST AI Risk Management Framework makes the same point in its Playbook. Its GOVERN 1.6 outcome reads: “Mechanisms are in place to inventory AI systems and are resourced according to organizational risk priorities.” The Playbook’s suggested actions include naming a specific person or team responsible for the inventory, deciding which systems are covered (preferably all, at minimum the high-risk ones), and defining which attributes to record, such as documentation, links to source code, incident response plans, data dictionaries, and contacts⁴. The phrase “resourced according to organizational risk priorities” is the useful part. It means the depth of each entry should follow its risk tier, not a single template applied to everything.

Intake Fields: What the Requester Provides

Intake should take a business user about fifteen minutes. If it takes longer, the form is asking for triage work the requester is not equipped to do. Twelve fields are enough.

Two of these fields deserve emphasis. The first is the ID rule. OMB instructs agencies that use cases keep the same ID from year to year, and that retired use cases must still be reported as retired in the following year’s inventory, with the ID never reused². The same discipline matters in GxP work, where an audit trail entry or a deviation report from three years ago may refer to a use case by its ID. The second is field 6. “What the output is used for” is the field that most often changes the triage result, and it is the one requesters most often leave vague.

Fields Added at Triage

The triage team adds the four criterion scores, the resulting tier, and the reasoning. It also adds cross-references: the system inventory record, the model registry record if there is one, the supplier assessment, the applicable procedures, and any regulatory flags (for example, “EU AI Act Annex III category” or “output may support a regulatory submission”). The reasoning field is the one to protect. A tier without a written reason cannot be defended to an inspector and cannot be challenged sensibly at the next review.

Fields That Keep the Entry Current

After triage, an entry needs a small set of lifecycle fields: date of last review, date of next review, open actions, linked change controls, linked incidents or deviations, and the current status of required evidence (risk assessment, validation or fit-for-use testing, training records). These fields are what turn a one-time survey into a working control. The NIST Playbook suggests reviewing the inventory’s completeness, usability, and efficacy on a set schedule⁴, and these fields are what that review checks.

The Four Triage Criteria

Triage is where quality and IT most often disagree, usually because each team scores against a different mental model of risk. The answer is not a longer questionnaire. It is a short list of criteria where each criterion has a clear owner, a small answer scale, and a factual basis both teams can check. We use four.

These four map closely to how others classify AI. The OECD Framework for the Classification of AI Systems uses five dimensions: People and Planet, Economic Context, Data and Input, AI Model, and Task and Output¹². Our GxP impact criterion covers the regulated slice of People and Planet and Economic Context. Data sensitivity matches Data and Input. Decision role matches Task and Output. Model type matches AI Model. Nothing here is novel in structure. What is specific to pharma is the content of each scale.

Criterion 1: GxP Impact

The draft EU GMP Annex 22 applies to AI models “used in critical applications with direct impact on patient safety, product quality or data integrity”⁶. That phrase is the best available anchor for this criterion, even though Annex 22 remains a draft: the consultation closed in October 2025 and no final text or implementation date has been published. Annex 22 is also a GMP document. For clinical, pharmacovigilance, and laboratory uses we apply the same three-level test by choice, because it is the clearest test available, not because Annex 22 requires it outside manufacturing.

• Direct. The AI output decides or determines a GxP outcome, or creates or changes a GxP record, without an independent check that would catch an error. Examples: an inspection model that rejects units, a model that excludes literature articles from case processing, a model whose prediction is recorded as a batch parameter.
• Indirect. The output supports GxP work, but a qualified person reviews each output before it affects a GxP decision or record. Example: a first draft of a deviation summary that a QA investigator edits and approves.
• None. The output does not feed a GxP process. Examples: drafting internal communications, summarizing public literature for strategy work, scheduling meetings.

FDA’s draft guidance draws a similar line from the other side. It states that it does not address AI used in drug discovery, or AI used for operational efficiencies, such as internal workflows, resource allocation, or drafting a regulatory submission, that do not affect patient safety, drug quality, or the reliability of results from a nonclinical or clinical study⁷. That is a helpful statement of what “None” looks like in regulatory terms. Note the example: drafting a submission is out of scope for that guidance because a person remains responsible for the content. The data inside the submission is a different matter.

Criterion 2: Data Sensitivity

Data sensitivity is the criterion IT and privacy usually care about most, and it is often the one quality overlooks. Score it by the most sensitive data the use touches, in either direction: what goes into the model (prompts, files, training data) and what comes out (outputs stored in a system of record).

• Restricted. Patient-level or study subject data, personal data of employees or candidates, and GxP records where the AI can create or change the record.
• Confidential. Unpublished product, process, or regulatory information: CMC data, draft submissions, supplier contracts, pricing.
• Internal. Ordinary business information with no special handling rules.
• Public. Published literature, public regulatory documents, marketing copy after approval.

Use the company’s existing data classification scheme rather than inventing a new one. If the scheme does not yet say what may be sent to an external AI service, that gap should be closed in the classification policy, not worked around in the register.

One data question also carries a legal flag outside GxP. The EU AI Act lists, in Annex III, AI systems intended for recruitment or selection of people (for example, to filter job applications or evaluate candidates) and AI used to make decisions about promotion, termination, task allocation, or performance monitoring⁸. These are high-risk uses under the Act regardless of whether anything GxP is involved. Under the Digital Omnibus amendment, Regulation (EU) 2026/1744, the obligations for Annex III systems now apply from December 2, 2027 rather than August 2026⁹. A pharma company screening candidates for QC analyst roles with an AI tool in the EU has a high-risk AI use in HR, and the register is where that should become visible, well before the deadline.

Criterion 3: Decision Role

Decision role asks how much the AI output drives the decision it feeds. This is where the most important judgment in the whole register happens, and where the most common mistake is made.

FDA’s draft guidance calls the matching idea “model influence”: the contribution of the evidence derived from the AI model relative to other evidence used to answer the question. It pairs model influence with “decision consequence,” the significance of an adverse outcome from an incorrect decision, and treats the combination as model risk⁷. In the guidance’s clinical example, a model that is the sole determinant of which trial participants go to outpatient monitoring has high influence and high consequence, so high risk. In its manufacturing example, a model that predicts fill volume has high decision consequence, but because release testing also measures fill volume on a sample from each batch, the model’s influence is judged low and the overall model risk medium⁷.

We use a four-level scale:

• Informational. The output provides background. No specific decision depends on it.
• Assists. The output is one input to a decision, and a qualified person reviews each output and has other evidence to decide with.
• Principal basis. The output is the main basis for the decision, even though a person formally signs off.
• Acts automatically. The output triggers an action or record with no human step in between.

OMB’s definition of high-impact AI turns on exactly this criterion: AI whose output “serves as a principal basis for decisions or actions” with a legal, material, binding, or significant effect on, among other things, human health and safety⁵. Pharma can use the same line. If the AI output is the principal basis for a decision that matters, the use is consequential no matter how the sign-off step is designed.

ISPE’s AI maturity model for GxP applications offers a related view. It rates systems on two dimensions: control design, which runs from the AI operating in parallel with the existing process up to systems that correct themselves, and autonomy, which runs from fixed algorithms with no learning up to systems that update themselves¹⁰. Its control design dimension is close to our decision role scale. Its autonomy dimension feeds our next criterion.

Criterion 4: Model Type

Model type covers how the model behaves and where it comes from. IT owns this criterion because it requires technical facts that business users rarely have. Four attributes matter:

• Static or dynamic. Does the model change its behavior during use by learning from new data, or is it fixed between controlled releases?
• Deterministic or probabilistic. Given identical inputs, does it always give identical outputs?
• Generative or not. Does it produce new text, images, or code (large language models and similar), or does it classify, predict, or score?
• Built, configured, or bought. Did the company train it, adapt a supplier’s model, or switch on a feature inside a licensed product? This drives what evidence the company can obtain and who can change the model without notice.

Model type matters most for GxP-critical uses because the draft Annex 22 is explicit. It applies only to static models with deterministic output. It states that dynamic models that continuously learn during use, models with probabilistic output, and generative AI and large language models should not be used in critical GMP applications. Where generative models are used in non-critical GMP applications, it expects qualified and trained personnel to be responsible for checking that outputs are suitable, which it describes as human-in-the-loop⁶. EMA held a multistakeholder expert workshop on June 30 and July 1, 2026, noting that its 2025 consultation suggested support for possibly enabling generative AI and large language models in medicines manufacturing, so the final position may change¹⁵. Until a final text is published, the draft is the most specific statement regulators have made, and a register should record model type in a way that lets you re-sort every entry quickly when the final text arrives.

From Criteria to Risk Tiers

Four criteria with three or four levels each produce dozens of combinations. Nobody wants a lookup table with dozens of rows, and nobody will use one. Tiers exist to reduce those combinations to a small number of control sets that people can remember. We use four.

Rules That Keep Tiering Consistent

Four rules make the tiering repeatable from one triage meeting to the next.

1. The highest criterion sets the floor. A use with no GxP impact but restricted data is at least Tier 2. Criteria never average out.
2. GxP impact alone decides Tier 3. Any use with direct GxP impact goes on the GxP-critical route. Within that route, decision role and model type set the depth of testing, in line with FDA’s point that credibility activities should be proportionate to model risk⁷. The fill volume model from FDA’s example would still be Tier 3, but with lighter testing than a model that is the sole basis for release.
3. Model type can make a use ineligible. If a use scores GxP impact Direct and the model is dynamic, probabilistic, or generative, the register does not assign Tier 3. It marks the use “not eligible as designed,” consistent with the draft Annex 22 position, and sends it back for redesign. The two usual redesigns are to lock the model and retrain it only under change control, or to move the AI to an assisting role where a qualified person makes the GxP decision.
4. Mitigations must be real to count. An independent check, such as release testing, can lower decision role, as it does in FDA’s fill volume example. A procedural sign-off that no one has time to perform does not.

Worked Examples

The following examples show how the rules play out. They are illustrations of the method, not rulings on any specific product. Your facts may produce a different answer, and the written reasoning matters more than the tier label.

Two of these deserve comment. The deviation summary use is Tier 2, not Tier 3, only as long as the investigator can and does check each summary against the evidence. If the volume of summaries grows until review becomes a formality, the decision role moves to principal basis, the GxP impact becomes direct, and the use should be re-triaged. The predictive maintenance use is Tier 2 because its alerts concern GMP equipment; if its alerts were used to extend qualified maintenance intervals, that would be a different use with a different entry.

Making Quality and IT Agree: Ownership and the Triage Meeting

Criteria and tiers are the easy part to write down. The harder part is the working agreement that decides who scores what, who breaks ties, and how entries reach the register in the first place.

Split the Scoring by Who Holds the Facts

Each criterion should be owned by the function that holds the facts, with the other function able to challenge. Quality owns GxP impact because it knows which process steps are GxP and which records are GxP records. IT owns model type because it can find out how the model behaves and who can change it. IT and privacy jointly own data sensitivity, because IT knows where data flows and privacy knows what the flows mean legally. The business owner proposes the decision role, because only the people doing the work know how the output is used day to day, and quality confirms it.

The draft Annex 22 expects this kind of cooperation. It calls for close cooperation between process subject matter experts, QA, data scientists, IT, and consultants during algorithm selection, training, validation, testing, and operation⁶. The register’s triage meeting is the practical place where that cooperation happens.

The Tie-Breaking Rule

When quality and IT disagree on a score, the higher score stands until someone produces evidence for the lower one. This rule does two things. It removes the incentive to argue a use down to a lighter tier without facts. It also puts the burden of proof on the person closest to the evidence. If IT believes a supplier’s model is static and quality is unsure, IT asks the supplier for its model change notification terms, and the score changes when the document arrives.

Detect Uses at the Process Level, Not Only at the System Level

Most registers are organized around systems: a new application arrives, it is assessed, and its AI features are recorded. That approach tends to miss AI features, or find them late, because they often appear inside systems that were assessed long before the feature was switched on. A register that watches process steps and data flows catches them earlier, at the moment an AI capability starts automating a step or reading regulated data.

In practice, this means the register should be fed from several channels at once:

• Procurement and contract review for new AI products and AI clauses in renewals.
• Change control, with a mandatory question on every change request: does this change add or modify an AI capability?
• Supplier release notes for licensed platforms, reviewed by system owners for newly enabled AI features.
• IT discovery through single sign-on logs, network traffic to known AI services, and browser extension inventories.
• Periodic review of computerized systems, with a standing question about AI features.
• Self-registration by business users, kept short so that registering is easier than working around the process.

The Triage Workflow

Approve Patterns, Not Just Instances

Triage volume can overwhelm a small team. M-25-21 addresses this directly: it tells agencies that, where possible, they should streamline approvals for intended use cases that are closely related in their deployment context and have substantially similar risk profiles⁵. A pharma register can do the same with pattern entries. Once the triage team has approved “generative drafting of internal SOP first drafts, reviewed by the document owner, in the approved enterprise assistant” as a Tier 2 pattern, the next department that wants to do the same thing registers against the pattern and inherits its controls. The triage meeting then only needs to confirm that the new use fits the pattern.

Review Cadence and Re-Triage Triggers

A register that is accurate on the day it is built and wrong six months later is a liability, because it gives false comfort. Two mechanisms keep it current: a scheduled review cadence tied to tier, and a set of events that force re-triage regardless of the schedule.

Cadence by Tier

For Tier 3 entries, the register review should not duplicate the formal periodic review of the validated system. It should confirm that the periodic review has happened, point to its record, and check the few items the system review might miss, mainly whether the use itself has drifted from what was validated.

Events That Force Re-Triage

M-25-21 defines a “significant modification” as an update to an AI application, or to the conditions or context in which it is used, that “meaningfully alters the AI’s impact,” including a significant change to the context, scope, or intended purpose of the use⁵. That is a good general test. In pharma terms, re-triage should be triggered by any of the following:

• A new model version from the supplier, or a notice that the supplier’s model will be retired or replaced.
• A change in the process step the output feeds, or in what users do with the output.
• A new data source, especially one that moves the data sensitivity score up.
• A new user group, a new site, or a new geography.
• Growth in volume that changes whether human review is realistic.
• An incident, deviation, complaint, or audit finding that involves the use.
• A change in regulation or guidance that affects a criterion, such as the final text of Annex 22.

For EU uses that fall into an Annex III category, the Act’s deployer obligations add their own review points once they apply. Article 26 requires deployers of high-risk AI systems to use them in line with the provider’s instructions, to assign human oversight to people with the necessary competence, training, and authority, to monitor operation and inform the provider of risks, and to keep automatically generated logs under their control for at least six months¹¹. A register entry for such a use should record who holds each of those responsibilities.

Measure the Register Itself

A register needs its own health measures, reviewed by the governance committee that owns AI policy. Keep them few and factual:

• Share of entries with a named, current business owner.
• Number of reviews overdue, by tier.
• Number of uses found through discovery channels rather than self-registration in the period. A high number means intake is too hard or too little known.
• Number of re-triages triggered by events, and how many changed the tier.
• Number of entries retired in the period, with IDs preserved.

A Sample Register Layout

The register does not need a new tool to start. A controlled spreadsheet with access control and version history, or a module in an existing GRC or QMS platform, is enough for the first year. What matters is that the columns are consistent and that the reasoning is written down. The layout below shows the summary view that a governance committee would review. Each row links to a detail record holding the full intake fields, the evidence, and the review history.

The Detail Record Behind Each Row

Behind the summary, each entry’s detail record should hold, at minimum:

• The twelve intake fields, with the date and the person who submitted them.
• The four criterion scores, each with a one-line reason, the scorer’s name, and a link to evidence.
• The tier, the tier rule applied, and the triage meeting date.
• Cross-references: system inventory ID, model registry ID, supplier assessment, applicable procedures, change control numbers.
• Regulatory flags: EU AI Act category, regulatory reliance, privacy impact assessment reference.
• The control plan: required controls, owners, due dates, and status.
• The review history: dates, outcomes, re-triage events, and tier changes with reasons.

Connecting the Register to Your Management System

Companies that plan to align with ISO/IEC 42001, the international standard that specifies requirements for establishing, implementing, maintaining, and continually improving an AI management system¹³, will find the register a natural backbone for it. The register tells the management system what exists and how much control each item needs. For Tier 2 and Tier 3 entries that affect people, ISO/IEC 42005:2025, published in May 2025, gives guidance on performing and documenting AI system impact assessments for individuals and societies, and on integrating those assessments into AI risk management¹⁴. Linking each elevated entry to its impact assessment closes the loop between the register and the risk process.

For companies already running a GxP quality system, the simpler path is often better: treat the register as a controlled record under an AI governance procedure, give it a system owner, and include it in the scope of internal audit. What an inspector wants to see is not a particular tool. It is a complete list, consistent reasoning, and evidence that the list is kept current.

Conclusion

An AI register fails when it tries to answer quality’s question and IT’s question in two separate lists, or when it asks one team to rate risks it cannot see. It works when the unit of entry is the use, not the model or the application, when each triage criterion is owned by the function that holds the facts, and when four plain criteria (GxP impact, data sensitivity, decision role, and model type) lead to a small number of tiers with known controls. The public inventories that came before this one show where the traps are: incomplete entries, uses that were never AI, embedded features that swamp the list, and human sign-offs that look like oversight on paper and are not. Each of those has a design answer, and none of them needs an expensive platform.

Sakara Digital works with pharma and biotech organizations building AI governance that quality, IT, and the business can all operate. If you are setting up an AI use case register, or trying to reconcile two lists that have grown apart, and want an independent view on where to draw the lines, we are happy to have that conversation.

For Further Reading