The Complete AI Record Does Not Exist in One System

A GMP record can stay approved, signed and readable in the QMS for years while the evidence that explains how it was produced runs on infrastructure with no obligation to retain anything for that long. A record is only ever as complete as its shortest-lived necessary relationship.

Consider a representative case, grounded in architecture that is publicly documented rather than invented for effect. Five years after approval, an inspector selects an AI-assisted manufacturing-change assessment for review. The QMS holds everything it should: the final assessment, the workflow history, the electronic signature, a readable audit trail. The source documents it references are still archived.

Nothing looks missing.

The organisation then tries to answer a narrower question. Which AI execution produced the adopted draft. Which source versions fed it. Which model version was active at the time. Whether the output a reviewer actually saw was the one later approved.

Vault AI Agents run their inference on large language models hosted on Amazon Bedrock; custom agents can use Veeva-hosted models or a customer-provided Bedrock or Azure AI Foundry environment. Vault continues to govern application access, workflow and the resulting business record. The inference computation itself runs on that external infrastructure. Bedrock's own model-invocation logging, the feature that actually captures what was sent to the model and what it returned, is disabled by default. Where it's enabled, records are written to CloudWatch Logs or S3 and survive according to the retention and lifecycle policies configured for those services, separate from, and not necessarily aligned to, the GMP record's own retention schedule. Whether a given deployment has this turned on, and what governs how long it lasts, is a question worth putting to the platform team directly.

The GMP record survived. The evidence needed to interpret it may never have been captured in a form built to last as long as the record does.

The organisation hasn't lost the approved record. It has lost the ability to explain how that record came to exist.

One record, three clocks

A retention assessment often starts with the designated system of record. That boundary may be insufficient for an AI-assisted process, because the evidence splits across the QMS, the agent or orchestration layer, the model provider, and the integration layer connecting them, each on its own schedule.

I separate three things. Business-record retention: how long the approved output stays available. Execution-evidence retention: how long the underlying AI events and configuration stay available. Relationship retention: how long the identifiers proving those two belong to the same transaction stay available. The third is the one nobody assigns an owner to.

This is a Navata architecture observation, not a quoted regulatory requirement: the complete AI record survives only as long as its shortest-lived necessary relationship.

The QMS can remain complete after the evidence chain has failed

A document-presence check confirms the record exists, the signature is intact, the audit trail reads cleanly, and says nothing about whether the AI-assisted authorship behind it is still reconstructible, because that failure happens entirely outside the QMS: a supplier rotates its logs, a model version is deprecated, a tenant migrates, an integration account is deleted, none of which touches the GMP record while quietly removing the evidence that explains it.

An AI-assisted record can become incomplete without any change to the record itself.

When telemetry becomes evidence

During implementation, an integration team typically builds a transaction identifier for troubleshooting failed calls. Its intended purpose is operational support, nothing more. Over time, that same identifier can become the only reliable link between the QMS record, the agent execution and the model-provider transaction.

At that point it has acquired an evidentiary function, whatever its retention policy still calls it.

I'd classify it by what the data does, not by the label an engineer gave it. That doesn't mean every technical log becomes a GxP record: ask whether the item is necessary to establish which execution produced the approved content, whether it's the only link to the applicable source or configuration state, and whether the decision could be reconstructed without it. Where the answer points one way, it has crossed into the evidence boundary, whatever folder it happens to sit in.

Most of this gets decided during delivery, long before anyone discusses retention: whether the QMS identifier propagates into every AI component, whether the model-provider reference gets written back into a client-controlled record, whether retrieval references point to durable locations or temporary ones, whether a failed evidence export stops the transaction, raises a controlled exception, or just logs a support ticket nobody reads. These read as integration details at build time. Together, they decide whether Quality's retention requirement can ever be met.

The AI Audit-Trail Illusion examined the event by which machine output becomes a human-owned GMP record. This piece asks a narrower question: whether the evidence for that event survives as long as the record does. More on how Navata approaches AI governance and validation.

What has to survive, not just what has to exist

I use the term evidence-retention envelope for the minimum set of records, metadata and relationships that have to stay accessible and intelligible for as long as the underlying AI-assisted record needs defending. It isn't a regulatory term, and no framework requires an organisation to name it this way.

The envelope holds the retained business record, the execution identity, the evidence references and their versions, the relationships connecting all of it, the disposition evidence showing which human action moved the output into the record, and the interpretive context needed once the live platform has moved on.

I'd document it as a matrix before build, not just a list: for each necessary item, the system that creates it, its authoritative identifier, the relationship it proves, the required retention period, the supplier's actual retention period, the client-controlled export or archive, and the owner. Any row where the required period exceeds the available one isn't a future operational risk. It's an unresolved architecture decision, today.

I hold two rules here: no necessary relationship should exist only inside a live supplier console, and no supplier should be the only party capable of explaining the client's own regulated record.

I'd ask, before go-live: what is the minimum evidence package that would let the client defend this record after the live supplier environment no longer exists?

A supplier's retention default is a Quality decision

A cloud supplier's default retention for audit logs, telemetry and diagnostic caches can be entirely reasonable for its own operational purpose and still inadequate for the client's evidentiary one. A NIST report published in March 2026 names the underlying condition, if not in GxP terms: it lists fragmented logging across distributed infrastructure as a documented monitoring barrier, and separately describes an information asymmetry in which developers, hosts and providers each hold only partial information about how a system was used. Real, independent support for the problem, though it stops well short of a GxP retention standard.

Quality approves the business-record retention period. Digital accepts the platform's logging and archival model. Procurement signs off the service tier without necessarily seeing either. The partner configures to whatever it was asked to build. Each decision can be reasonable on its own terms while the resulting evidence chain expires years before the regulated record it supports, which is exactly when a supplier's retention setting becomes a Quality decision rather than an IT one.

I'd expect one objection here: isn't this just data governance, already owned by IT? Infrastructure retention is normally sized against operational load and storage cost, which answers how long a log is needed for its own purposes, not how long Quality needs it to defend a decision already approved. The two match only by coincidence unless someone has deliberately lined them up.

Archived is not the same as explainable

The draft revision of EU GMP Annex 11 states that when a regulated user relies on outsourced activities, it remains fully responsible for maintaining the evidence for GMP requirements and for producing it on regulatory review, that documentation must be accessible and explainable from the regulated user's own facility, and that supplier contracts should define an exit strategy by which the regulated user retains control of system data. Its archiving section requires GMP data and metadata, including audit trails, protected from deletion throughout the retention period, and says this doesn't remove the need to validate the archival and retrieval process itself. These are consultation proposals, not yet in force, written for computerised systems generally rather than AI specifically, which is exactly why they already reach an AI-assisted QMS record: it's a computerised system's output like any other.

Moving a QMS record to read-only storage protects the final document. The expired provider transaction, the deleted retrieval event, and the meaning of an undocumented model alias behind it stay lost regardless.

I hold three things together here: archival integrity (the item hasn't been altered or lost), historical intelligibility (it can still be interpreted in the context it was created in), and chain retrievability (every necessary item can still be connected into one execution history).

Test what survives, not just what connects

A validation approach that stops at a runtime check, create a transaction, confirm every component logged it, confirm the identifiers line up, is a real baseline. It's a useful baseline, and it only proves the chain holds while every supplier console is still live and every log is still fresh, which is the easiest condition this evidence will ever face.

Before ageing anything, the runtime baseline itself has to survive a few failure modes: one correlation identifier missing, two executions receiving the same identifier, a retry producing two provider transactions for one business action, system clocks disagreeing on sequence, a supplier export quietly omitting a relationship the live console still shows.

Run the same reconstruction after the shortest supplier retention period has passed (a configured test window, not an actual months-long wait), then again after console access is removed, after a tenant migration, after an identity is deactivated, and after contractual service termination, using only the export the client controls.

A supplier retrieving the record on request demonstrates supplier capability. A partner explaining the design demonstrates implementation knowledge. Only the client reconstructing it, unaided, demonstrates operational control, and that is the one the test should actually measure.

A test has not proved retention where it depends on the same live supplier access whose future absence is the risk being tested.

The FDA and EMA's Guiding Principles of Good AI Practice in Drug Development call for data source provenance, processing steps and analytical decisions to be documented in a detailed, traceable and verifiable manner in line with GxP requirements. They do not prescribe this test. The aged-record scenario is a proposed way of making that principle operational rather than aspirational.

One retention decision, not five unrelated ones

Quality defines what must remain defensible, and for how long. Architecture decides where the necessary records and relationships are created, stored, exported and retired. Partner delivery configures whether the integration preserves durable identifiers and fails visibly when evidence can't be retained. Validation proves whether the client can reconstruct the chain after ageing, migration and supplier exit. Operational ownership tracks retention changes and evidence approaching expiry.

The control is complete only when that intent survives every handover and remains demonstrable without the original supplier or delivery team in the room.

The last day of retention

Pick one AI-assisted GMP record whose formal retention period runs longer than the supplier's default log retention. Find the shortest-lived necessary item, the shortest-lived necessary relationship, and who controls each. Confirm what client-controlled evidence would remain if both expired tomorrow.

Then ask a single question: who on the client side owns proving this record will still be explainable on the last day it is required to be retained?

The complete AI record not existing in one system is a straightforward architecture condition to design around. What turns it into a control failure is retention left to emerge from unrelated settings chosen independently by Quality, Digital, suppliers and delivery partners, none of whom were ever asked to solve for the same date. Where the approved record outlives the evidence needed to explain it, the final answer is all that's left to inspect.

For more on where Quality-owned controls stop matching Digital-owned systems, see the Navata Insights archive.