Ask a validation team what data integrity means and you'll get the same answer everywhere: ALCOA+. Attributable, legible, contemporaneous, original, accurate, complete, consistent, enduring, available. It's a clean framework, built for a world of validated instruments, controlled forms, and audit trails that record exactly who touched a record and when.
Then someone drops a large language model into the batch record review process, or plugs a predictive model into deviation triage, and half of those nine letters get complicated fast. Not broken, exactly. Stretched in ways the original framework wasn't built to handle.
I work with pharma and medical device companies building AI governance programs on top of existing quality systems, and data integrity is where I see the most confusion. Not because teams don't understand ALCOA+, but because they're trying to apply a framework designed for deterministic, human-operated systems to something that's probabilistic, learns from its inputs, and can produce a different answer to the same question twice. This guide walks through where AI actually strains data integrity controls, what the current regulatory expectations are, and how to build a program that holds up under FDA scrutiny.
What Data Integrity Means in GxP, and Where AI Breaks It
ALCOA+ was formalized in FDA's April 2018 guidance, Data Integrity and Compliance With Drug CGMP, which extended the original five-letter ALCOA acronym (attributable, legible, contemporaneous, original, accurate) to nine attributes by adding complete, consistent, enduring, and available. The guidance ties directly back to existing predicate rules: 21 CFR 211.68(b) requires that backup data be exact, complete, and secure from alteration, and 21 CFR 11.10(e) requires a secure, computer-generated, time-stamped audit trail that independently records the date, time, and content of operator entries and actions that create, modify, or delete electronic records.
Those requirements assume a record has a stable origin and a traceable chain of custody. AI systems complicate several of the nine attributes at once.
Attributable gets murky when a model, not a person, generates or transforms a value. If an AI tool flags a deviation as low-risk, who is the record attributable to? The model version, the training run, the human who accepted the recommendation, or all three?
Original is difficult when a model's output is itself a derived artifact of thousands of training examples, none of which are individually traceable to the final answer. There's no single "original" the way there is for a chromatogram or a weighed sample.
Accurate and consistent run into the reality that many AI models, particularly generative ones, are non-deterministic. The same input can produce a different output on a different run, which is a direct conflict with the assumption baked into most computerized system validation: that a validated system behaves the same way every time given the same inputs.
Enduring raises a version-control problem. If a model is retrained, fine-tuned, or has its underlying weights updated, the system that produced last quarter's output may no longer exist in the form it existed in when it produced that output. Reproducing the basis for a decision six months later isn't guaranteed the way it is with a locked SOP and a validated spreadsheet.
None of this means AI can't be used on GxP data. It means the controls need to be designed for how AI actually behaves, not retrofitted from controls written for static, rule-based systems.
The Regulatory Landscape
There's no single AI-specific data integrity regulation for pharma yet, but the framework isn't a vacuum either. Several pieces already apply, and more are arriving.
21 CFR Part 11 still governs electronic records and signatures regardless of whether the system generating them is rule-based or AI-based. If an AI tool creates, modifies, or is used to make a decision about a GxP record, that interaction falls under the same audit trail and validation expectations as any other computerized system.
FDA's January 2025 draft guidance, Considerations for the Use of Artificial Intelligence to Support Regulatory Decision-Making for Drug and Biological Products, is the agency's first dedicated attempt to lay out a risk-based framework for AI used in drug development and regulatory submissions. It proposes a credibility assessment framework scaled to the AI model's risk to patients and to the reliability of the regulatory decision it supports, and it explicitly calls out data quality and provenance as a determinant of model credibility.
Article 10 of the EU AI Act requires that training, validation, and testing datasets for high-risk AI systems be relevant, representative, and, to the best extent possible, free of errors, with documented data governance practices covering collection, labeling, and any data preparation steps. Pharma AI use cases involving clinical decision support or manufacturing process control are likely to fall into the high-risk category under the Act's classification rules.
ISO/IEC 42001:2023, the AI management system standard, addresses this directly in Annex A control A.7, "Data for AI systems," which requires organizations to document data provenance, quality criteria, and preparation processes across the AI system life cycle. Clause 6.1.2 requires a documented AI risk assessment process, which is the natural home for evaluating where a given AI use case threatens data integrity before it goes live. I've written a longer breakdown of how ISO 42001's Annex A controls map to regulated industry requirements for teams building this out.
GAMP 5 (Second Edition, 2022), the ISPE guide most quality teams already use for computerized system validation, doesn't have an AI-specific category, but its risk-based approach to novel and complex applications is the model most validation teams are adapting for AI/ML systems, treating them closer to a custom application than an off-the-shelf configured system.
The common thread across all of these: none of them let you skip data integrity controls because the system is AI. They all raise the documentation bar, particularly around where the data came from and how the model's behavior can be reconstructed after the fact.
Where AI-Specific Risk Actually Shows Up
In practice, the gap between traditional data integrity controls and what AI needs shows up in five places.
Training data provenance. A validated computerized system's behavior is defined by its code and configuration. An AI model's behavior is defined by its training data, and if you can't trace where that data came from, what was excluded, and how it was labeled, you can't defend the model's outputs the way you'd defend a validated calculation. This is the single most common gap I see in early-stage AI governance programs: teams can tell you what the model does, but not what it learned from.
Model versioning and drift. Traditional systems change through a documented change control process with a defined before-and-after state. AI models can drift continuously, especially if they're retrained on new data or fine-tuned in production. Without a model version log tied to the outputs it produced, you lose the ability to answer "what did the system know when it made this decision" months later.
Non-deterministic outputs. A generative AI tool answering the same query twice and getting two different, both-reasonable answers isn't a bug in the way a validated calculation returning two different results would be. But it breaks the "consistent" attribute in ALCOA+ as written, and it requires a different control: documenting the acceptable range of variation and how a human reviewer is expected to evaluate outputs that fall outside it.
Black-box audit trails. 21 CFR 11.10(e) audit trail requirements assume a system can log what it did and why. Many AI models, particularly deep learning systems, can log what output they produced but not a human-readable rationale for how they got there. Where full explainability isn't achievable, the control shifts to documenting the human review step that sits on top of the model's output, rather than the model's internal reasoning.
Third-party and vendor data. AI tools embedded in vendor software often train on data the pharma company never sees, using processes it doesn't control. Vendor oversight has always mattered for GxP systems, but it becomes the primary control, not a secondary one, when the vendor's AI is making judgment calls inside your quality system.
Traditional vs. AI-Specific Data Integrity Controls
| ALCOA+ Attribute | Traditional Computerized System Control | AI System Challenge and Adapted Control |
|---|---|---|
| Attributable | User login tied to every record action | Requires logging model version, training data version, and the human who accepted or overrode the output |
| Original | Source record preserved unaltered | No single "original"; control shifts to documenting the training dataset and preprocessing pipeline as the system of record |
| Accurate | Validated calculation produces one correct result | Model output is a prediction, not a calculation; control is a documented accuracy/performance threshold plus human review |
| Consistent | Same input produces same output every time | Non-deterministic outputs are expected; control is a documented acceptable variation range, not identical repeatability |
| Complete | All data captured in the validated workflow | Requires documenting excluded or filtered training data and why it was excluded |
| Enduring | Locked record, unchangeable after approval | Requires model version control so a past output can be reconstructed even after retraining |
| Available | Record retrievable for the required retention period | Requires retaining the model version and training data snapshot, not just the output, for the retention period |
Building an AI Data Integrity Program
The teams that get this right treat AI data integrity as an extension of existing computerized system validation, not a parallel program. A few things that matter most in that build-out:
Start with data lineage, not model performance. Before evaluating whether a model is accurate enough, document where its training and operational data comes from, what preprocessing it went through, and who's accountable for that data's quality. This is the foundation everything else sits on, and it's the piece most teams skip because it's less visible than the model itself.
Design the audit trail around the decision, not just the output. If a model recommendation feeds into a GxP decision, the audit trail needs to capture the model version, the input data, the output, the human reviewer, and the final decision as one linked record. A log of model outputs with no link to what a human did with them doesn't satisfy 21 CFR 11.10(e) in any meaningful sense.
Treat model changes as change control events. Every retrain, fine-tune, or prompt change that affects a GxP-relevant AI system should go through the same change control discipline as a code change to a validated system: documented rationale, testing against a defined baseline, and an approval record before it goes live.
Set a human-in-the-loop standard proportional to risk. Not every AI use case needs the same level of human review. A model that drafts a first pass at a deviation summary for a human to edit carries different risk than a model that autonomously classifies a batch as pass or fail. Scale the review requirement to the decision's consequence, and document that scaling logic so an auditor can see the reasoning, not just the outcome.
Put vendor AI under the same scrutiny as vendor software. If a validated system you're licensing has an AI feature bolted on, ask the vendor directly: what data trains it, how often does it retrain, and what audit trail does it expose. If they can't answer, that's the finding, not a footnote.
I go deeper on structuring this kind of assessment in a pharma-specific AI risk assessment framework, and for teams weighing where AI fits inside an existing validated environment, the GxP-compliant AI governance approach walks through the validation lifecycle question in more detail.
Common Pitfalls
The most common mistake I see is treating an AI pilot as low-risk simply because it's not customer-facing. An internal model helping a quality reviewer triage deviations is still touching GxP data, and its outputs are still subject to the same integrity expectations as any other input into a regulated decision, even if no one outside the company ever sees it.
The second is documenting the model but not the data. Teams will produce a thorough model validation package, complete with performance metrics and a risk assessment, and then have nothing on where the training data came from or how it was curated. An FDA investigator asking "how do you know this data was complete and accurate" deserves a better answer than "the vendor told us."
The third is assuming a locked model is a static one. Vendors update models more often than most quality teams expect, sometimes without a formal notification. Building a monitoring process to catch silent model updates, and revalidating when they happen, closes a gap that most current change control processes don't cover.
FAQ
Does 21 CFR Part 11 apply to AI systems used in pharma manufacturing? Yes. Part 11's audit trail, validation, and electronic signature requirements apply to any computerized system used to create, modify, or approve GxP records, regardless of whether the system is rule-based or AI-based. There's no carve-out for AI in the regulation.
Can a non-deterministic AI model ever satisfy ALCOA+ data integrity requirements? It can, but the "consistent" attribute has to be reinterpreted. Instead of expecting identical outputs from identical inputs, the control becomes a documented acceptable variation range and a defined human review step for outputs that fall outside it, backed by version-controlled logging of the model that produced each output.
What's the difference between validating a traditional computerized system and validating an AI/ML model for GxP use? Traditional validation confirms a system performs its intended function consistently against a fixed specification. AI/ML validation has to additionally address training data provenance, ongoing performance monitoring against drift, and a defined process for revalidating after retraining, since the model's behavior isn't fixed the way a rule-based system's is.
Is ISO 42001 certification required for pharma companies using AI? No regulation currently mandates ISO/IEC 42001:2023 certification for pharma AI use. It's a voluntary AI management system standard, but its Annex A control A.7 on data for AI systems maps closely to the data provenance documentation that FDA's data integrity expectations already require, which is why it's become a common framework for structuring AI governance programs.
What should a company do if it discovers a vendor updated an embedded AI model without notice? Treat it as an unplanned change to a validated system. Document what changed, assess the impact on any GxP decisions the model informed since the update, and formalize a monitoring or contractual requirement with the vendor for advance notification of future model updates.
Data integrity was never really about the nine letters in ALCOA+. It was always about being able to answer, with evidence, "how do you know this is true." AI doesn't remove that obligation. It just changes what the evidence has to look like. If your program can trace a decision back through the model version, the training data, and the human who reviewed it, you're in solid shape regardless of what's generating the output. If you can only point to the output itself, you have a gap worth closing before an investigator finds it for you.
For companies building or auditing an AI governance program that touches GxP data, our healthcare and pharma AI governance practice works through exactly this kind of data integrity mapping as part of standing up a defensible program.
Last updated: 2026-08-18
Jared Clark
Principal Consultant, Certify Consulting
Jared Clark is the founder of Certify Consulting, helping organizations achieve and maintain compliance with international standards and regulatory requirements.