The Problem Nobody Has Solved Yet

When software changes information in a regulated system, who is accountable? What gets recorded? Can an auditor tell a change made by a person from one initiated by AI? These questions sit right at the heart of 21 CFR Part 11 audit trail compliance for AI — and the honest answer is that the industry has not fully worked it out.

The FDA has not published specific guidance on AI-initiated actions within Part 11 systems. Neither has the EMA or PMDA. DnXT is building ahead of regulation, based on the existing Part 11 framework. This is an interpretation, and the landscape will change.

What we can share is how we have designed our audit trail to handle AI actions today, and why we made the choices we did.

Built In, Not Bolted On

Most enterprise software treats audit logging as a feature: a developer adds a line of code to record each action after performing it. That creates two problems. Developers sometimes forget. And the record is created separately from the action itself, so the two can drift apart.

DnXT works the other way round. The part of the platform through which all regulated information passes creates the audit record itself, every time something is created, changed or removed. Nobody decides whether to record it — it happens because of how the platform is built.

This matters especially for AI, which may carry out dozens of actions in quick succession. If recording depends on each one remembering, gaps are inevitable. When recording is part of writing, everything is captured regardless of what set it off.

What Every Record Captures

Our audit trail is treated as a component critical to GxP compliance and validated accordingly. Every record captures four things:

  • Who — the person and where they connected from, taken from their authenticated session. For AI-initiated actions, this is the account associated with the customer’s credential, tagged distinctly so it is visibly an AI action.
  • What — what was affected and what was done. Create, change, delete, view, export, sign, approve, reject, sign in and sign out.
  • When — the time according to the platform, never according to whatever asked. A deliberate choice: where software may be running anywhere in the world, there has to be one authority on what time it is.
  • Why — the detail: which fields changed, from what to what, in what context, and for what stated reason.

ALCOA+ in Practice

ALCOA+ is the FDA’s data integrity framework. Here is how each principle maps to what we built:

  • Attributable — every record names a person and where they connected from. AI actions are attributable to the account behind the customer’s credential, which is itself linked to a named administrator.
  • Legible — a consistent, structured format throughout. No free-text dumps that only the author can interpret.
  • Contemporaneous — the time is recorded as the action happens, never added afterwards.
  • Original — the audit record is the original record of the event. It is not a copy or summary of something held elsewhere.
  • Accurate — values are checked for validity before they are stored.
  • Complete — a daily check looks for any gap in the audit trail longer than an hour. If records were missed because something was unavailable, we know.
  • Consistent — every part of the platform records audit entries the same way. There are no local variations that might diverge over time.
  • Enduring — records are held with the same backup and retention arrangements as all other regulated information.
  • Available — the audit trail can be searched and produced on request.

Detecting Tampering

Every audit record carries a cryptographic fingerprint calculated from its own contents — what happened, to what, by whom, and when. Each record also stores the fingerprint of the record before it, and its position in the sequence.

That forms a chain. If any record is altered after the fact, its fingerprint no longer matches the copy held by the record that follows it, and the chain visibly breaks. Any auditor able to read the audit trail can check this.

This is not blockchain. It is simpler and more practical — a chain of fingerprints that makes tampering detectable without any of the machinery blockchain would require.

Telling AI and Human Actions Apart

When the audit trail records an AI-initiated action, it is tagged distinctly from a human one:

  • Actions from the Publisher are tagged as coming from a person there
  • Actions from the Reviewer are tagged separately
  • Actions initiated by AI are tagged as such
  • Actions from the platform’s own internal processes are tagged as system-generated

An auditor asking “show me every document classification changed by AI in Q3” gets a clean answer. That is the kind of question regulators will increasingly ask, and the system needs to answer it directly rather than through analysis after the fact.

The Electronic Signature Boundary

One place we draw a hard line: AI cannot produce an audit record for signing or approving. Those actions require a person to authenticate through the DnXT interface, which creates its own record with that person’s identity, their authenticated session, and a fingerprint of the document at the moment of signing.

This boundary exists because Part 11 Section 11.100 requires an electronic signature to be unique to one individual. AI is not an individual.

What We Haven’t Solved

Transparency requires acknowledging open questions:

  • Recording which AI made the recommendation. When AI suggests something that leads to a change, should the audit trail record which version of which model suggested it? We think yes. We have not built it yet.
  • Chains of AI actions. If one AI action triggers a process that triggers another, each is recorded separately. There is no single record linking them as one line of reasoning. Whether regulators will want that is unclear.
  • Regulatory acceptance. No authority has reviewed or endorsed this approach. We are building from first principles and the existing text of Part 11, which was written before any of this existed.

The audit trail challenge for AI in regulated systems is not primarily technical — it is definitional. The industry needs consensus on what “attributable” means when software acts on a person’s behalf, and that consensus does not yet exist.

A Starting Point, Not a Final Answer

DnXT’s approach is our best answer to a question the industry is still formulating. Recording built into the platform rather than added on, a clear mapping to ALCOA+, tamper detection through a chain of fingerprints, and clear tagging of what AI did — together these form a foundation that can evolve as guidance emerges.

If you are designing AI into regulated systems, we would welcome the conversation, even if your approach looks nothing like ours. The industry needs more shared thinking on this, not proprietary silos.

This article was written by the DnXT Solutions team. We’ve aimed to present our approach accurately, including its limitations. If we’ve mischaracterized any regulatory requirement, we welcome corrections at se******@***********ns.com.