A marketing-authorization dossier is thousands of documents arranged into a single, rigidly structured tree. Modules of clinical and non-clinical data, quality sections, regional forms, cross-references that have to resolve, hyperlinks that have to point at the right page, file formats the agency's gateway will accept or silently reject. This is the eCTD — the electronic Common Technical Document, the format health authorities require — and assembling one is months of meticulous, error-prone work.
It is also, almost line for line, the kind of work AI agents are good at. Pull the documents, validate them against the specification, check that every leaf in the tree is present and correctly placed, flag the broken links before the gateway does. The temptation, once an agent can do all that, is to let it press send. That is the mistake. The assembly is machine work. The release is a human act with a named person's accountability behind it.
What the agent is genuinely good at
A submission has two distinct phases, and only the first is repetitive enough to automate cleanly. Before anything goes to the agency, someone has to build the dossier and prove it is complete — work that is slow, exact, and unforgiving of small mistakes.
An agent can do most of it. It can collect the source documents, confirm each is the approved final version rather than a draft, and check formats against the eCTD specification. It can validate the tree — every required section present, every document in the right module, every hyperlink and cross-reference resolving. It can run the technical validation the agency's own gateway will run, so rejections surface inside your walls instead of in a refuse-to-file notice. And it can draft the cover letter and reviewer's guide.
None of that is the submission. All of it is preparation — the work that makes the dossier ready for a person to release. The distinction matters because it is the line the system has to enforce, not suggest.
Where the human act begins
Filing a dossier with a health authority is a deliberate decision by an accountable owner — typically the regulatory-affairs lead — attesting, on behalf of the company, that this exact package is what the sponsor intends the agency to review. It is a one-way door. Once a submission crosses the gateway it is on the record, it starts the agency's clock, and an incomplete or wrong package can mean a refusal, a delay measured in months, or a lasting deficiency.
That accountability is not a workflow nicety. It is the reason a person signs. The lead puts their name to the assertion that the dossier is correct, that the version going out is the version that was reviewed, and that nothing was swapped between approval and transmission. A model cannot make that assertion. It has no professional standing to lose and no liability to feel, and "the agent filed it" is not an answer any regulatory-affairs function wants to give when a package turns out wrong.
So the architecture is fixed before a line of code is written. The agent assembles and validates. The regulatory-affairs lead releases. The system has to make the release impossible for the agent — not discouraged, not flagged after the fact, but structurally barred the moment it is attempted.
Why the prompt is not the boundary
The common shortcut is to write the rule into the agent's instructions. You prepare and validate the dossier and present it for sign-off. You never transmit to the gateway yourself. This reads like a control. It is an instruction, and an instruction is negotiable.
A prompt keeps no record of who decided the agent could reach the publishing system. It has no version history when someone edits it, and no proof — a year later, when the agency asks about a filing — of what the agent was permitted to do the day that dossier went out. Worst of all, it offers no structural barrier to the failure that matters most: an agent that, through a re-prompt or a tool it was quietly granted, ends up able to transmit a package nobody released.
The boundary has to live somewhere the agent cannot edit. That is the argument for a control plane — the policy-and-enforcement layer between an agent's intent and the regulated system — and for grants enforced at runtime rather than written on paper.
What the boundary looks like in practice
In MakerChecker, the submission agent is a named principal that holds one role, granted exactly the doors it needs: read the document repository, read the validation rules, write a draft dossier into a staging area. Those grants are deny-by-default and versioned, so you can reconstruct precisely what the agent could do on the date any dossier was assembled, and every change to that list carries the name of who approved it.
The release to the authority is a separate, gated step. The run reaches the submission gate and stops. It cannot proceed on the agent's authority, because the agent does not hold it — structurally, the same actor that assembled the dossier provably cannot be the one that signs it off and transmits it. The regulatory-affairs lead reviews the validated package and signs, and that signature captures the meaning the act requires.
| Step | Actor | Authority |
|---|---|---|
| Collect documents, confirm final versions | Agent | Read-only grants |
| Validate eCTD structure, links, formats | Agent | Read-only grants |
| Assemble draft dossier and reviewer's guide | Agent | Write draft only |
| Release and transmit to the authority | Regulatory-affairs lead | Gated human signature |
This is the same pattern an approval gate applies to any one-way door. The gate parks the run, demands a named signature, bars the preparer from approving their own work, and records the signer's reason verbatim so the release means what it says. It is the discipline that also keeps an agent from certifying a finished drug batch: the maker assembles the case, a named person owns the decision.
The version problem, and why it bites here
Submissions have a specific failure mode that makes the maker-checker boundary non-negotiable: drift between what was reviewed and what was sent. A reviewer approves version twelve of a clinical summary. Somewhere in the publishing run a later draft gets pulled, and version thirteen slips into the package that crosses the gateway. The signature, if there was one, no longer applies to what was filed.
A control plane closes that gap by binding the signature to the exact dossier version it approved. The lead does not sign "the submission." They sign this build, identified by content, and the transmission can only release the build that was signed. If the package changes, the signature no longer matches and the run stops. That linkage is what 21 CFR Part 11 demands of an electronic signature — that it manifest its meaning under §11.50 and stay bound to its record under §11.70 — applied to a dossier rather than a single form.
Every step in the run lands in an append-only, hash-chained, cryptographically signed ledger. Change one record and the chain visibly breaks. The export verifies offline, against a published spec, with no access to your systems — what an agency reviewer wants, and what a chat transcript can never provide.
What to take from this
Agentic AI was scoped out of the main US model-risk guidance in April 2026, and the EU AI Act's high-risk obligations were pushed to late 2027. Neither moved Part 11. Neither changed who is accountable for what a sponsor files with a health authority. The principle that the actor who assembled the package is not the actor who releases it is date-proof, and the inquiry that tests it will not wait for new AI guidance.
The right deployment is not "an agent that files submissions." It is an agent that does the collecting, validating, and drafting at machine speed, handing a clean, version-locked dossier to the regulatory-affairs lead who still — and only — signs at the one-way door. The months come off the assembly. The accountability stays where it belongs.
MakerChecker is an open-source control plane that enforces this boundary. Book a demo to watch an agent get blocked from approving its own work — live.