Most document-automation demos are staged at whole-submission scale, which is exactly the scale that hides the problem. The question that decides whether the workflow survives contact with a regulatory affairs team is smaller: what happens inside one section, claim by claim, when a model drafts it and a human has to sign it. A section drafted with sentence-level source binding and per-claim review gates produces an artifact whose lineage an auditor can reconstruct; a section drafted as free-form model output produces text nobody can trace, so review restarts from the source data and the time saving evaporates.
So let us do it at section granularity. One section, one study report, one reviewer queue.
What does AI-assisted drafting of a submission section actually look like?
Take a single clinical summary section with a defined template — headings fixed, expected content per heading known, and a small set of upstream sources: the study report, the statistical output tables, and previously accepted text from an earlier submission.
The naive workflow is a single prompt. Template in, study report in, draft out, route the whole draft to review as one opaque artifact. It demos well. It fails at the review desk, because a reviewer cannot tell which sentences restate a source, which interpolate between sources, and which the model produced from nothing in particular. Faced with that ambiguity, a competent reviewer does the only defensible thing: re-derives the content from the source data. That is not review, it is redrafting with extra steps.
The workflow we build instead is closer to assisted assembly than to generation. It runs per heading, not per section, and it carries three mechanics that the single-prompt version does not have.
One — retrieval before generation. Each heading’s draft is generated only from a retrieved candidate set: specific passages from the study report, specific rows from the statistical tables, specific paragraphs of previously accepted text. Nothing enters the prompt that has not been identified by document, version, and location. Implementation is unglamorous — a vector index over the source corpus, a chunking scheme aligned to document structure rather than fixed token windows, and a retrieval log persisted alongside each draft.
Two — source binding at sentence level. Every generated sentence carries the identifiers of the passages it was generated from. This is a data-model decision, not a prompt-engineering trick: the drafting step emits structured output where each sentence is an object with a text field and a source-reference list, and the document renderer is what turns that structure into prose. Bind at generation time or you will not bind at all.
Three — a review gate per claim-bearing statement. Statements that assert something about safety, efficacy, or study conduct do not pass on reviewer silence. They are held, assigned to a named reviewer, and released only on explicit accept or edit. Descriptive scaffolding — headings, cross-references, transitional text — moves through on a lighter path.
Which statements can a model draft, and which cannot?
The dividing line is not “hard text versus easy text”. It is whether the statement is a restatement of an identified source or an act of judgement.
| Statement class | Drafting route | Review gate |
|---|---|---|
| Structural and navigational text (headings, cross-references, tabulated study metadata) | Model-generated from template plus retrieved metadata | Automated consistency check; spot review |
| Restatement of a numeric result present in the statistical output | Model-generated with a mandatory binding to the specific table row | Verification against source by a named reviewer |
| Narrative summary of a result already characterised in the study report | Model-generated from retrieved passages only | Named reviewer accept-or-edit, recorded per sentence |
| Interpretation of clinical significance | Human-authored | Author is the accountable signatory; model may suggest phrasing only |
| Benefit-risk position and any statement of regulatory conclusion | Human-authored | Human-authored end to end; no model draft accepted |
| Anything with no resolvable source in the retrieved set | Blocked, surfaced as a gap | Returned to the author with the missing-source reason |
That last row does more work than it looks like it does. The most useful output of a section-level pilot is often not the draft — it is the list of statements the section needs and the source corpus cannot support. Those gaps existed before automation; they were just discovered later, by a regulator’s question rather than a pipeline’s exception.
The record the section leaves behind
When the section closes, the workflow should have produced four artifacts, and the section is not done until all four exist:
- The rendered section, in submission format.
- A sentence-to-source map — for every sentence, the source documents, versions, and locations it was generated from, plus the retrieval timestamp.
- A review ledger — for every claim-bearing statement, who reviewed it, what they did (accept, edit, reject), the before-and-after text where they edited, and when.
- A change history across drafting rounds, so a later question about why a sentence reads the way it does resolves to a decision and a person rather than to a model version.
Together these are what makes the section auditable rather than merely finished. We explore why the audit trail — not model quality — is the binding constraint on regulatory document automation in AI in pharma regulatory submissions; the mechanics above are what preserving that trail costs inside a single deliverable. This is the same evidence our life sciences AI work records in a validation pack for regulated document workflows, and the same pattern shows up almost unchanged in automotive homologation documentation — different regulator, identical source-binding problem.
How do you know the section-level pilot worked?
Section granularity is also where the throughput number comes from, because it is the smallest unit with a real before-and-after. Four measurements, taken on the same section pre- and post-automation:
- Drafting cycle time for the section — first draft request to review-ready.
- Reviewer time per claim-bearing statement — the number that actually determines whether the workflow scales, since review capacity is the scarce resource, not drafting capacity.
- Proportion of generated sentences with a resolvable source citation — a sentence whose citation does not resolve to a real location in a real document version is a defect, regardless of how well it reads.
- Rate of factual corrections per section, against the pre-automation baseline. This is the regression guard.
The pass condition is not “faster”. It is faster with source-citation resolution high and correction rate flat. A pilot that speeds up drafting while the correction rate climbs has moved work downstream into review and validation, where it costs more. In our experience with regulated workflows, that displacement is the most common way a document-automation pilot reports success and still gets rolled back.
A pilot that fails these measures on one section has done its job too. It failed at the cost of one section instead of the cost of a remediation cycle across a submission.
Before extending to the next section
Three conditions, and they are cumulative:
- The source corpus for the adjacent section is as well-identified as the first section’s — same document-version discipline, same chunk-to-structure alignment. Retrieval quality is a property of the corpus, not of the model, and it does not transfer for free.
- The claim classification for the new section has been agreed with regulatory affairs before drafting, not negotiated during review. The table above is section-specific; the boundary between restatement and judgement moves.
- The review ledger from the first section has actually been read by whoever owns the audit response. An unread ledger is not evidence.
What we are still working out is where the honest ceiling sits. Sections dominated by restatement of structured results automate well; sections dominated by interpretation mostly do not, and we are not convinced they should. The interesting open question is whether the middle band — narrative summary of already-characterised results — holds up across therapeutic areas or whether each one needs its own claim classification before a single sentence gets drafted. If you are scoping this work, our engagement approach starts at one section for exactly that reason.
Frequently Asked Questions
What does AI-assisted drafting of a pharma regulatory submission section mean in practice — a worked example?
Stripped down, AI Assisted Drafting Regulatory is the following. It means running the section heading by heading: retrieve identified source passages, generate each sentence only from that retrieved set, bind every sentence to its sources, and gate claim-bearing statements on named human review. The output is a rendered section plus a sentence-to-source map, a review ledger, and a change history.
Which parts of a submission section can AI draft, and which statements must originate from a human author?
Structural text, restatements of numeric results, and narrative summaries of results already characterised in the study report can be model-drafted with binding and review. Interpretation of clinical significance and any benefit-risk or regulatory conclusion is human-authored; the model may suggest phrasing but is not the origin of the claim.
How is each generated sentence bound to a source document and location so a reviewer can resolve it?
Binding happens at generation time, not afterwards. The drafting step emits structured output in which each sentence carries the document identifiers, versions, and locations of the retrieved passages it came from, and the renderer turns that structure into prose. A citation that does not resolve to a real location in a real document version is treated as a defect.
What review gates sit inside a single section, and who signs off on each claim-bearing statement?
Every claim-bearing statement is held and assigned to a named reviewer, who must explicitly accept, edit, or reject it — silence does not pass it. Descriptive scaffolding moves on a lighter automated-consistency path, and human-authored interpretive statements are signed by their accountable author.
What traceability and change-history record does the section-level workflow leave behind for an audit?
Four artifacts: the rendered section, a sentence-to-source map with retrieval timestamps, a review ledger recording reviewer, action, before-and-after text and time for each claim-bearing statement, and a change history across drafting rounds. The section is not complete until all four exist.
How do we measure whether the section-level pilot worked — cycle time, reviewer time, correction rate?
Measure four things on the same section before and after: drafting cycle time, reviewer time per claim-bearing statement, the proportion of generated sentences with a resolvable source citation, and the rate of factual corrections against the pre-automation baseline. The pass condition is faster drafting with citation resolution high and correction rate flat.
What has to be true before extending the same workflow from one section to adjacent sections?
The adjacent section’s source corpus needs the same document-version and chunking discipline, the claim classification for that section must be agreed with regulatory affairs before drafting rather than during review, and the first section’s review ledger must have been read by whoever owns the audit response.
Drafting Section 3.2.S.2.3: a step-by-step walkthrough
Start by feeding the model your certificate of analysis, reference standard documentation, and the ICH Q6A decision trees—then validate every generated claim against source documents before a human reviewer sees the draft. If AI Assisted Drafting Regulatory is on your roadmap, the next step is to map it onto your own constraints rather than copy a reference architecture.
