The Regulatory Reality of AI and Electronic Signatures

As AI agents become more capable and more integrated into regulatory workflows, there will be growing pressure to let them “approve” or “sign” documents on behalf of humans. After all, if an AI agent can review a document, classify it, check it against validation rules, and confirm it meets requirements — why can’t it sign?

The answer is straightforward: because 21 CFR Part 11 says electronic signatures must be attributable to specific individuals. An AI agent is not an individual. This isn’t a technical limitation — it’s a regulatory requirement that exists for good reasons.

What Part 11 Actually Requires

Four sections of 21 CFR Part 11 are directly relevant to AI electronic signature questions:

  • Section 11.50 — Signatures must show: the printed name of the signer, the date and time of signing, and the meaning of the signature (e.g., review, approval, responsibility, authorship).
  • Section 11.70 — Signatures must be linked to their respective electronic records so that signatures cannot be excised, copied, or otherwise transferred to falsify an electronic record. In practice, this means cryptographic binding to a specific document version.
  • Section 11.100 — Each electronic signature must be unique to one individual and not be reused by, or reassigned to, anyone else.
  • Section 11.200 — Electronic signature components (what you know + what you have) must be non-reusable — designed for single use per signing event.

An AI agent fails Section 11.100 immediately: it is not “one individual.” It may act on behalf of multiple users, using a shared service account. Even if you assigned a unique identity to each AI agent, the spirit of the regulation — human accountability for regulated decisions — would not be met.

The Correct Pattern: AI Recommends, Human Signs

The pattern that works within the existing regulatory compliance framework:

  1. AI reviews the document — checks formatting, validates against eCTD rules, flags potential issues, classifies content.
  2. AI presents findings to the human — “This document passes 22 of 23 validation rules. Rule 14 (bookmark structure) has a warning. Here’s what I’d suggest fixing.”
  3. Human makes the judgment call — accepts the AI’s recommendation, overrides it, or requests more analysis.
  4. Human signs in the application — authenticates with their own credentials, applies their own electronic signature with a specific meaning (APPROVAL, REVIEW, RESPONSIBILITY, or AUTHORSHIP).
  5. System records both — the AI’s analysis and the human’s signature are both in the audit trail, linked to the same document version.

This isn’t a workaround. It’s how AI should interact with regulated signing workflows. The AI adds speed and thoroughness. The human adds judgment and accountability.

How DnXT Enforces This Architecturally

Policy isn’t enforcement. Telling an AI agent “don’t sign documents” via a prompt or configuration file is a convention that can be overridden. DnXT enforces the boundary architecturally:

No Sign Tool in the MCP Server

The customer-facing MCP server design includes four e-signature tools:

  • esign_get_status — check signature status for a document
  • esign_get_signatures — list all signatures on a document
  • esign_request — request a signature from a user (creates PENDING record, sends email)
  • esign_validate — verify signature integrity (hash check)

There is no esign_sign tool. It doesn’t exist in the tool registry. An AI agent connected via MCP literally cannot call a function to sign a document, because that function isn’t exposed.

The ESignatureService Design

Our ESignatureService is a Tier-1 GxP-critical validated component with these properties:

  • Signature integrity: Each signature includes a SHA-256 hash computed from SIG_ID + DOC_HASH + USER_ID + TIMESTAMP + MEANING. This binds the signature to the exact document version at the moment of signing.
  • Immutability: Signatures cannot be modified after creation. Revocation creates a new audit record — it doesn’t modify the original signature.
  • Status tracking: PENDING → SIGNED (or DECLINED, REVOKED, EXPIRED). The transition from PENDING to SIGNED requires authentication through the DnXT UI, not through an API call.
  • Meaning enforcement: Every signature must have one of four meanings: APPROVAL, REVIEW, RESPONSIBILITY, AUTHORSHIP. This isn’t a free-text field — it’s an enum.

Workflow Gate Integration

When a workflow transition requires e-signature approval, the workflow engine’s preCheck endpoint returns requiresHumanAction: true. An AI agent calling workflow_advance receives this flag and knows it cannot proceed — the human must sign first.

The Open Question: Will This Framework Hold?

We should be transparent about what we don’t know:

  • FDA hasn’t addressed AI and Part 11 directly. The current Part 11 text was written in 1997. While FDA’s emerging technology program engages with AI broadly, there’s no published guidance on how AI agents should interact with electronic signature workflows.
  • Industry practice is evolving. Some organizations are exploring “AI-assisted review” where the AI performs a preliminary review and the human’s signature attests to both their own judgment and their review of the AI’s analysis. Whether this satisfies Part 11 is untested.
  • International harmonization is unclear. EU Annex 11, Japan’s ERES guidelines, and other regional frameworks have their own requirements. A global pharma company needs an approach that works across jurisdictions.

The safest position today is the one DnXT takes: AI agents can participate in every step of the regulatory workflow except signing. When regulatory guidance catches up to technology, we can expand. Starting permissive and restricting later is much harder than starting restricted and expanding.

For Organizations Evaluating AI-Signature Workflows

When evaluating how a regulatory technology platform handles AI and e-signatures, ask three questions:

  1. Is the restriction architectural or policy-based? Can the AI agent technically call a sign endpoint, even if it’s told not to? If yes, you have a policy gap.
  2. How does the audit trail distinguish AI-initiated actions from human signatures? Can an auditor filter for “all signatures” and confirm they were all human-authenticated?
  3. What happens when the AI recommends signing and the human disagrees? Is the disagreement recorded? Can the human override the AI’s recommendation and have that override audited?

This article was written by the DnXT Solutions team. We’ve aimed to present the regulatory requirements accurately. If we’ve mischaracterized any Part 11 provision, we welcome corrections at se******@***********ns.com.