Part 11 was written in 1997. It never imagined the analyst was a model

A reconciliation agent proposes two hundred data corrections. A data manager reviews them in eleven minutes and signs. The audit trail is complete, the system is validated, and nobody in the room can say what the signature actually attests to.

The question an inspector will ask, and the answer nobody has

Picture a routine inspection at a mid-size sponsor. The inspector is working through the electronic data capture system for a phase three study, and she has found a batch of query resolutions applied on a Tuesday afternoon in March. Two hundred and eleven of them, closed in a window of about eleven minutes.

She asks the obvious question. Who resolved these?

The audit trail answers immediately and precisely, because it is a good audit trail in a properly validated system. Every entry carries a user, a timestamp, an old value, a new value, and a reason code. The user is svc_dm_recon_02. The data manager standing next to the inspector explains, accurately, that the reconciliation agent proposes corrections against source, that a human reviews and approves them in the system, and that the approval is a Part 11 signature by a named individual. She pulls up the signature record. It is there, correctly manifested, with a printed name and a timestamp and the meaning "approved".

The inspector asks the second question, which is the one that matters. What did the reviewer look at?

There is a pause. Not because anyone did anything wrong, and not because the answer is embarrassing, but because the question has no artifact behind it. The system recorded that a person with the right role, in an authenticated session, clicked the control that applies a signature to a batch. It did not record, and was never designed to record, what that person examined, on what basis they formed a judgment, or whether the eleven minutes represented a careful sampling strategy or a scroll to the bottom of a list.

Nobody is committing fraud in this scene. The sponsor has a validated system, an SOP that requires human review, and trained staff following it. That is exactly why it is worth examining. The gap here is not a compliance failure by a bad actor. It is a structural question that a rule written in 1997 did not need to ask, because in 1997 the entity that produced a record and the entity that signed it were the same species.

What does 21 CFR Part 11 actually require?

Worth restating precisely, because the rule is frequently paraphrased into something vaguer than it is.

Part 11 governs electronic records and electronic signatures that are created, modified, maintained, archived, retrieved, or transmitted under records requirements set out in FDA regulations. It has two operative subparts.

Subpart B, the records half

Section 11.10 lists controls for closed systems. Among them: validation of systems to ensure accuracy, reliability, and consistent intended performance including the ability to discern invalid or altered records; the ability to generate accurate and complete copies suitable for inspection; protection of records throughout the retention period; limiting system access to authorised individuals; and, at 11.10(e), the use of secure, computer-generated, time-stamped audit trails that independently record the date and time of operator entries and actions that create, modify, or delete records.

Two provisions in that list get less attention than they deserve in the agent context. Section 11.10(g) requires authority checks to ensure that only authorised individuals can use the system, sign a record, access the operation or device, alter a record, or perform the operation at hand. And section 11.10(j) requires written policies that hold individuals accountable and responsible for actions initiated under their electronic signatures, in order to deter record falsification. That word, initiated, is doing a great deal of work when the thing being initiated was proposed by a model.

Section 11.50 covers signature manifestations. A signed electronic record must contain, in human readable form, the printed name of the signer, the date and time of execution, and the meaning associated with the signature, such as review, approval, responsibility, or authorship.

Section 11.70 requires that electronic signatures be linked to their respective records so that they cannot be excised, copied, or otherwise transferred to falsify a record by ordinary means.

Subpart C, the signature half

Section 11.100 is the clause that answers the headline question. Each electronic signature must be unique to one individual and must not be reused by or reassigned to anyone else. Before assigning a signature, the organisation must verify the identity of the individual. And persons using electronic signatures must certify to the agency that they intend them to be the legally binding equivalent of handwritten signatures.

Section 11.200 sets the components. Signatures not based on biometrics must employ at least two distinct identification components, typically an identification code and a password. Within a single continuous period of controlled system access, the first signing uses all components and subsequent signings may use at least one component designed to be used only by that individual. Outside such a period, each signing uses all components.

That last provision is where practice and text diverge most visibly. Section 11.200 was written to describe a person at a terminal in a controlled session. Read it next to a batch approval of two hundred and eleven agent-proposed changes, and the phrase "a series of signings executed during a single continuous period" starts to look less like a convenience allowance and more like a description of the exact scenario that needs examining.

It is also worth remembering the 2003 scope and application guidance, in which FDA narrowed its enforcement approach and signalled a risk-based interpretation of several Part 11 controls. That guidance shaped two decades of industry practice and is the reason many validated systems satisfy 11.200 with a username and password re-entry dialog and nothing more.

Why does "attributable" break first?

The data integrity vocabulary the industry actually argues in is ALCOA, expanded to ALCOA+: attributable, legible, contemporaneous, original, accurate, and then complete, consistent, enduring, and available. FDA's data integrity guidance for drug CGMP frames expectations in these terms.

Attributable is first for a reason. It is the property everything else depends on. A record that is legible, contemporaneous, and accurate but not attributable is an orphan: you know what happened and when, and you do not know whose judgment stands behind it. Every other integrity property is about the record. Attribution is the only one about a person.

Here is the useful way to think about what an agent does to that. Imagine a laboratory notebook where a very fast, very diligent assistant writes all the entries in pencil, and the scientist comes through at the end of the day and inks over them. The notebook is complete, legible, and contemporaneous. The ink is genuinely the scientist's. But the notebook now records two different kinds of act with the same appearance: entries the scientist reasoned through, and entries the scientist accepted. From the page alone you cannot tell which is which, and the page is the record.

That is the situation, stated plainly. Part 11 gives the signature a meaning field precisely because the rule's authors understood that signatures mean different things. What the rule could not anticipate is a workflow where the meaning is genuinely ambiguous to the signer themselves.

Why a service account is not an answer

The standard architecture today is a named service account with a documented human owner. It is a reasonable pattern and it satisfies a validation reviewer, and it does not answer the inspector's question for a simple reason: the account attributes to a system, and the owner attributes to a role.

If svc_dm_recon_02 is owned by the Director of Data Management, then every action that account takes is nominally attributable to a person who did not perform it, did not review it individually, and in a large study could not possibly have. The account gives you a name to write on an inspection response. It does not give you an attributable act. We have written about this general failure, where authority is real but invisible and nobody can enumerate what a non-human principal is permitted to do, in the authority graph.

There is a second-order problem that quality teams will recognise immediately. Service accounts drift. The agent's scope expands through ordinary change control from proposing corrections to applying a defined class of them automatically, then to a wider class, and each expansion is individually justified. Six months later the account's authority bears no resemblance to what the original owner assessed, and the owner may have changed roles twice.

Why the review checkbox is not an answer either

The other standard control is an SOP requiring human review before the signature, implemented as a checkbox or a confirmation dialog.

This is better than nothing, and it is worth being fair about why it is used: it is cheap, it is auditable as a procedural control, and in the overwhelming majority of cases the human genuinely does review. The problem is what the artifact proves. A checkbox inside the same system, in the same session, reachable by the same session token, records that a control was clicked. It is a UI event in a system the reviewer is already authenticated to, which means it inherits every property of that session and adds nothing of its own.

We have called this pattern approval theatre in the context of autonomous agents, and the analysis carries over directly: any approval an agent can reach, an agent can satisfy. In a GxP context the concern is usually not a rogue agent clicking its own approval, though as agents gain interface access that stops being hypothetical. The concern is more mundane and more common: the control produces no evidence distinguishable from an automated one, so a genuinely diligent reviewer and a rubber stamp leave identical traces.

If you have ever tried to defend a data integrity observation, you know that identical traces are the problem. The reviewer who did excellent work has no way to demonstrate it.

What would a signature that survives the system look like?

Split the requirement into two artifacts, because two different things need proving.

The first is who signed and over what. A device-bound signature is produced by a private key held in the reviewer's own device hardware, released by a local authentication gesture, over the hash of the specific record content being signed. It is not a session event. It is a cryptographic fact that can be handed to an inspector, an auditor, or a partner and checked against a published key with no call to the vendor and no access to the system that created it.

The second is who authorised the agent. That is a delegation: a signed statement from a named human granting a specific agent a bounded scope, for a bounded time, revocably. The important design detail is that the scope should distinguish proposing from committing.

{
  "id":            "dlg_7741",
  "delegator_key": "mk_2b8e41c9",
  "delegateKey":   "ag_recon_04",
  "scope": {
    "actions": ["edc.read", "edc.propose"],
    "study":   "PRO-2291",
    "forms":   ["DM-04", "DM-07"]
  },
  "constraints":   { "autonomous_commit": false },
  "notBefore":     "2026-09-01T00:00:00Z",
  "notAfter":      "2026-12-01T00:00:00Z",
  "maxChainDepth": 1,
  "revocationId":  "rev_7741"
}

The agent can read and propose. It cannot commit. That is not a policy written in an SOP that a configuration change could quietly contradict. It is a constraint inside a signed object that a verifier checks, and if the agent attempts a commit the chain does not authorise it.

Then the human signature over the record itself, carrying the Part 11 manifestation elements in the payload rather than only in the rendered view:

{
  "type": "gxp.signature",
  "record": {
    "system":       "edc.prod",
    "object":       "form/DM-04/subject/1042/visit/V3",
    "content_hash": "sha256:9c1f4a77e0b3a37b"
  },
  "manifestation": {
    "printed_name": "P. Raghavan",
    "executed_at":  "2026-09-24T11:42:07Z",
    "meaning":      "review and approval of agent-proposed reconciliation"
  },
  "human_key":         "mk_2b8e41c9",
  "agent_delegation":  "dlg_7741",
  "identity_proofing": "idp_2025_11_0442"
}

Verification is a pure function. Check the signature against the published key, recompute the record hash against the record as retained, confirm the delegation was in force at the execution time and had not been revoked, and confirm the identity proofing reference resolves to a completed verification of that individual.

def verify_gxp_signature(receipt, published_key, record_bytes, chain):
    verify_ed25519(published_key, receipt.canonical, receipt.signature)
    assert sha256(record_bytes) == receipt.payload["record"]["content_hash"]
    dlg = chain.resolve(receipt.payload["agent_delegation"])
    assert dlg.covers(receipt.payload["executed_at"])
    assert not dlg.revoked_before(receipt.payload["executed_at"])
    assert "edc.commit" not in dlg.scope["actions"]     # agent could not commit
    return receipt.payload["manifestation"]

Notice what an inspector gets from that. Not an assurance from the sponsor that a review happened, and not a screenshot of a validated system. A checkable artifact that a specific identity-proofed individual applied a signature to this exact record content at this time, under a delegation that did not permit the agent to commit anything on its own.

What does this add to a validated system, clause by clause?

The middle column is not a criticism. Validated systems do these things properly and have done for years. The right reading of the table is that the third column is what survives when the first column's assumptions do not hold: when the session was not what it appeared to be, when the vendor is no longer available, when the study is being reviewed by a partner who does not have access to your EDC, or when the actor was software.

Is this an open question or a settled one?

Open, and being worked on in public, which is the honest framing.

FDA published a draft guidance in January 2025 on considerations for the use of artificial intelligence to support regulatory decision-making for drug and biological products, setting out a risk-based credibility assessment framework for AI models used in regulatory submissions. It is a serious document and it addresses model credibility rather than signature attribution, which is a different question, but its existence signals where agency attention is.

In parallel, the European Annex 11 on computerised systems has been under revision, ICH E6(R3) for good clinical practice was adopted in 2025 with a more explicit risk-proportionate posture toward technology in trials, and GAMP 5 Second Edition addresses iterative and automated approaches to validation. The frameworks are moving. None of them has yet answered the specific question of what a human signature means over machine-produced work.

Our position, and it is a position rather than a finding: Part 11 does not need amending for this. Section 11.100's requirement that a signature be unique to one individual, and section 11.10(j)'s requirement that individuals be accountable for actions initiated under their signatures, already say the right things. What has been missing is an implementation that makes those requirements mean something stronger than a password box, and the arrival of agents is what makes the weakness visible rather than what creates it.

Honest limits

This section matters more than usual, because quality professionals are asked to accept vendor claims constantly and are right to be sceptical.

• A signature artifact does not make you Part 11 compliant. Compliance is a property of your system, your validation, your procedures, and your practice. A cryptographic receipt is evidence within that, not a substitute for any of it.
• Validation is the sponsor's burden. Introducing any component into a GxP workflow means qualifying it: intended use, risk assessment, specification, and verification appropriate to that risk, under your quality system and GAMP-aligned approach. No vendor can hand you a validated state.
• It does not prove the review was adequate. A device-bound signature over two hundred and eleven records in eleven minutes proves who signed and what they signed. It does not prove they read anything. Making review demonstrable is a workflow design problem: sampling plans, per-record signatures for higher risk classes, and exception handling that requires attention where attention matters.
• Identity proofing is upstream. The strength of every signature traces back to the moment the key was bound to a verified individual. If that enrollment was weak, the cryptography faithfully preserves a weak claim.
• Nothing here is regulatory advice. Whether a given implementation satisfies a given clause in your context is a determination for your quality unit, your regulatory affairs function, and your auditors. We build a mechanism. The compliance claim belongs to the sponsor.

What to do this week

1. List your agents. Enumerate every automated or model-driven process that writes to, proposes changes in, or closes items within a GxP system. Most quality units discover the list is longer than expected and was assembled through ordinary change control rather than a single decision.
2. For each one, name the human. Not the account owner, the person accountable for the outputs. If the answer is a role rather than a person, that is your first finding.
3. Check whether the agent can commit. Determine, from configuration rather than from documentation, whether each agent can write final records or only propose them. The gap between the SOP and the permission set is where inspections go badly.
4. Time your batch approvals. Pull the interval between signature events on your largest batch approvals from the last quarter. You are not looking for wrongdoing, you are looking for whether the workflow makes adequate review physically possible.
5. Read 11.10(j) against your agent workflows. Ask literally: which actions are being initiated under whose signature, and does the written policy actually describe that.
6. Decide your signature granularity. Per record, per batch, or per exception class, chosen by risk rather than by what the interface happens to offer.
7. Write the validation outline before the pilot. Intended use, risk classification, requirements traceable to the Part 11 clauses in the table above, and the verification evidence for each. If a supplier cannot support that, the answer is no.
8. See the mechanism. The developer documentation covers the signing and verification calls, and the signing demo shows a record-bound signature and its receipt.

Frequently asked questions

Can an AI agent sign under 21 CFR Part 11? No. Section 11.100 requires each electronic signature to be unique to one individual and requires the organisation to verify that individual's identity before assigning it. An agent is not an individual and cannot be identity-proofed. A human must sign, and the useful question is what that signature attests to and what evidence exists of the review behind it.

Does Part 11 apply to records an AI system generated? Part 11 applies based on whether a record is required by an FDA predicate rule and is maintained electronically, not based on what produced it. A record required under a predicate rule remains within scope regardless of whether a human, a script, or a model drafted it. Your quality unit should make the scope determination for each record type.

Is a service account with a named owner sufficient attribution? It gives you a name for an inspection response, but it attributes actions to a system and its owner to a role. It does not establish that a specific individual formed a judgment about a specific record. Where the predicate requirement is individual accountability, a per-record human signature is a materially stronger position.

How do you attribute agent actions in a Part 11 audit trail? Record the agent as the actor, and separately record the signed delegation that authorised its scope and the human signature that committed the record. The audit trail then answers three questions rather than one: what acted, who authorised it to act, and who is accountable for the result.

Does a device-bound signature satisfy section 11.200? Section 11.200 requires at least two distinct identification components for non-biometric signatures. A key held in device hardware plus a local authentication gesture is a possession factor combined with a second factor, and it binds to the record rather than to the session. Whether a specific implementation satisfies the clause in your context is a determination for your quality unit and auditors.

Do we need to revalidate our EDC to add this? Adding any component to a GxP workflow requires assessment under your change control and a validation effort proportionate to risk, which is usually a qualification of the added component and regression verification of affected functions rather than full revalidation of the platform. Scope it with your CSV lead before piloting.

What does the delegation actually prevent? A delegation with commit excluded from its scope means a verifier will not accept an agent-signed commit as authorised, independently of how the application is configured. It converts a procedural control described in an SOP into a constraint carried inside a signed object.

Sources

1. 21 CFR Part 11, Electronic Records; Electronic Signatures. Electronic Code of Federal Regulations
2. FDA, Guidance for Industry: Part 11, Electronic Records; Electronic Signatures, Scope and Application (2003). FDA guidance documents
3. FDA, Data Integrity and Compliance With Drug CGMP: Questions and Answers, Guidance for Industry. FDA guidance documents
4. FDA, draft guidance on considerations for the use of artificial intelligence to support regulatory decision-making for drug and biological products, January 2025. FDA guidance documents
5. EudraLex Volume 4, Annex 11: Computerised Systems. European Commission EudraLex
6. ICH E6(R3) Good Clinical Practice. ICH efficacy guidelines
7. ISPE, GAMP 5 Guide, Second Edition. ISPE guidance documents
8. W3C Web Authentication (WebAuthn) Level 3 specification. W3C

Part 11 already demands a signature unique to one individual. Agents did not create that requirement, they just made it obvious that a password box was never it.