How We Built a 21 CFR Part 11 Audit Trail for AI-Initiated Actions

The Problem Nobody Has Solved Yet

When an AI agent modifies data in a regulated system, who is accountable? What gets recorded? Can an auditor distinguish between a change made by a human and one initiated by an AI? These questions sit at the intersection of 21 CFR Part 11 audit trail AI regulatory compliance — and the honest answer is that the industry hasn’t fully figured this out yet.

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

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

Structural vs. Bolt-On Audit Trails

Most enterprise software adds audit logging as a feature — developers call a logging function after performing an action. This creates two problems: developers sometimes forget to call it, and the audit record is separate from the data operation, which means they can fall out of sync.

DnXT’s approach is structural. Our PlatformDataWriter — the component through which all regulated data writes flow — automatically calls the audit service on every INSERT, UPDATE, and DELETE. Developers don’t choose whether to audit. It happens because of how the data layer works.

This matters for AI interactions specifically because AI agents may invoke dozens of operations in rapid succession. If auditing depends on each operation remembering to log itself, gaps are inevitable. When auditing is built into the write layer, every operation is captured regardless of what initiated it.

What Every Audit Record Captures

Our AuditTrailWriter is classified as a Tier-1 GxP-critical validated component. Every record captures four dimensions:

• WHO — userId and clientIpAddress, sourced from the SessionUserBean. For AI-initiated actions via MCP, the userId maps to the API key’s service account, and the source field is tagged mcp-open-gxp.
• WHAT — entityType, entityId, and action. Actions include: CREATE, UPDATE, DELETE, ACCESS, EXPORT, SIGN, APPROVE, REJECT, LOGIN, LOGOUT.
• WHEN — Server-side UTC timestamp. Never client-provided. This is a deliberate choice: in a distributed system where AI agents may run in different time zones, the server is the single time authority.
• WHY — A key-value detail map capturing field-level changes (old value, new value), context, and reason.

ALCOA+ Compliance in Practice

ALCOA+ is the FDA’s data integrity framework. Here’s how each principle maps to our implementation:

• Attributable — Every record links to a userId and IP address. AI actions are attributable to the service account associated with the customer’s API key, which is itself linked to a named administrator.
• Legible — Standardized JSON format for all detail maps. No free-text dumps.
• Contemporaneous — Server-side UTC timestamp generated at write time, not retroactively.
• Original — The audit record is the original event record. It’s not a copy or summary of something stored elsewhere.
• Accurate — Input sanitization via regex validation on IDs and dates before storage.
• Complete — The ComplianceAgent in our OQ Dashboard runs a daily check for audit trail gaps exceeding 1 hour. If the audit service was down and records were missed, we know about it.
• Consistent — All services use the same AuditTrailWriter component. There are no service-specific audit implementations that might diverge.
• Enduring — Records are stored in Oracle with the same backup and retention policies as all regulated data.
• Available — Audit trail queries are exposed via REST API (and will be available via MCP tools in the Open GxP server).

Tamper Detection: The Hash Chain

Each audit record includes a SHA-256 hash computed from: recordHash = SHA-256(recordId + entityId + userId + timestamp + action + details). Additionally, each record stores previousRecordHash and a sequenceNumber, forming a hash chain.

If any record in the chain is modified after the fact, the hash chain breaks — the modified record’s hash won’t match the previousRecordHash stored in the next record. This is detectable by any auditor with read access to the audit table.

This isn’t blockchain — it’s simpler and more practical. It’s a linked list of hashes that makes tampering detectable without requiring distributed consensus.

AI vs. Human Attribution

When a 21 CFR Part 11 audit trail records an AI-initiated action, the source field distinguishes it from a human action:

• Actions from the Publisher UI: source: "publisher-ui"
• Actions from the Reviewer UI: source: "reviewer-ui"
• Actions from the MCP server: source: "mcp-open-gxp"
• Actions from internal services: source: "system"

An auditor running a query like “show me all document classification changes made by AI agents in Q3” gets a clean result set. This is the kind of question regulators will increasingly ask, and the system needs to answer it without post-hoc analysis.

The E-Signature Boundary

One area where we draw a hard line: AI agents cannot generate audit records with action type SIGN or APPROVE. These actions require human authentication through the DnXT UI, which creates a separate audit record with the human’s userId, their authenticated session, and the document’s SHA-256 hash at the moment of signing.

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

What We Haven’t Solved

Transparency requires acknowledging open questions:

• AI model versioning in audit records: When an AI agent makes a recommendation that leads to a data change, should the audit trail capture which AI model version made the recommendation? We think yes, but we haven’t implemented it yet.
• Cascading AI actions: If an AI agent triggers a workflow that triggers another AI agent, the audit trail captures each action independently. There’s no “chain of AI reasoning” record that links them. Whether regulators will want that is unclear.
• Regulatory acceptance: No regulatory authority has reviewed or endorsed this approach. We’re building based on first principles and the existing Part 11 text, which was written before AI agents existed.

The audit trail challenge for AI in regulated systems isn’t primarily technical — it’s definitional. We need industry consensus on what “attributable” means when an AI agent acts on behalf of a human, and that consensus doesn’t exist yet.

A Starting Point, Not a Final Answer

DnXT’s AI regulatory audit trail is our best answer to a question the industry is still formulating. Structural audit logging, ALCOA+ mapping, hash-chain tamper detection, and source-based AI attribution form a foundation that can evolve as regulatory guidance emerges.

If you’re designing AI interactions for regulated systems, we’d welcome the conversation — even if your architecture looks different from ours. The industry needs more shared thinking on this problem, not proprietary silos.

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