Two artefacts, two audiences, one decision that separates them: the intended-use statement. An evidence pack answers what an auditor walking your workflow will ask about controls, lineage, change-control sign-offs and validation per regulated step. A regulatory submission answers what a regulator asks about a device or product claim under a specific pathway. They are not the same document at two levels of polish, and treating them that way is the most common way regulated AI programmes waste a quarter.
The failure runs in both directions. Some teams bloat the internal pack with submission-grade narrative nobody reads, because “we might need it later” feels cheap at the time. Others assume the pack will be lifted wholesale into a dossier and discover, well after the structure is frozen, that it answers the wrong questions in the wrong order. Both are rework, and both are avoidable by making one call early.
What test decides whether a workflow triggers submission obligations?
The divergence point is the intended-use statement — not the model architecture, not the data sensitivity, not whether the deployment sits inside a hospital or a GxP manufacturing site.
If the AI workflow makes or materially informs a clinical determination, submission obligations attach and the evidence pack becomes an input to a dossier rather than a substitute for one. If the workflow supports operational or administrative steps inside a covered environment — scheduling, document routing, batch-record transcription, retrieval over internal SOPs — the pack is the terminal artefact and there is no dossier to feed.
“Materially informs” is where the argument actually happens, and it is not an engineering call. Regulatory affairs owns the classification. What engineering owns is asking for it before the pack structure is fixed, because the structure differs depending on the answer. We see this sequencing mistake regularly: the pack gets built to whatever shape the first auditor conversation implied, and the intended-use question surfaces three months later when someone drafts the marketing claim.
The boundary in one table
| Question | Evidence pack | Regulatory submission |
|---|---|---|
| Who reads it | Internal auditor, external compliance auditor, customer’s quality team | Regulator, under a named pathway |
| What it proves | Each regulated step was governed, logged, approved, validated | The product claim is safe and effective for a stated intended use |
| Organising unit | Workflow step | Product claim and pathway requirement |
| Owner | Quality plus engineering | Regulatory affairs |
| Lifecycle | Standing artefact, updated as the workflow runs | Point-in-time dossier, versioned against submission events |
| Trigger | Any regulated data or regulated process step | Intended use that makes or materially informs a clinical determination |
| Terminal? | Yes, below the submission threshold | Always — the pack feeds it, does not replace it |
Which sections travel and which stay home
The details of Evidence Pack Ends Regulatory matter at this point. Validation evidence is the section most likely to be reused as a dossier input — a validation report that names its protocol, its acceptance criteria, its dataset and its model version is already close to submission shape. Model provenance and lineage travel reasonably well. Change-control records travel in summary form, as evidence that a controlled process exists, rather than record by record.
What stays internal: access trails, per-user training records, site-specific SOP references, and the operational runbook material an auditor asks for when walking a facility. A regulator is not examining who logged in on a Tuesday; an auditor is.
The practical consequence is a structural one. Build validation evidence so it is self-contained — protocol reference, intended-use scope, acceptance criteria, results, deviations, sign-off — and it serves both readers without being authored twice. Build it as a narrative summary embedded in the pack’s prose and you will re-author it under deadline. This is the same discipline that keeps the two artefacts distinct in the first place; we cover the ownership split in Evidence Pack vs Validation Evidence: Where the Two Artefacts Meet.
Deciding before the structure freezes
A short decision rubric, run with regulatory affairs in the room:
- State the intended use in one sentence, in the form a regulator would read it, not the form a proposal would. If the sentence contains a clinical determination, stop and route to regulatory affairs for pathway classification.
- Name the regulated steps in the workflow and mark which of them the AI touches. Steps the AI merely observes are still in the pack; they are rarely in a dossier.
- Decide the terminal artefact — pack only, or pack plus dossier input. Write the decision down with a date and an owner, because it will be challenged.
- Fix the validation-evidence format to the stricter of the two requirements, regardless of the answer. This is the one place where over-building is cheap and under-building is not.
- Re-run the rubric whenever intended use is restated. A marketing claim change, a new customer segment, or an expanded deployment scope can move the boundary without anyone touching the model.
Step 5 is the one teams skip. The moment intended use is restated — often in a sales conversation rather than a design review — the classification is stale and the pack may now be an input rather than an endpoint.
What third-party and hosted models do to the boundary
A hosted model inside the regulated step does not move the submission threshold; intended use still decides that. It does change what the pack has to carry, because the provider’s controls are now part of your evidence chain and you cannot produce their internal artefacts on demand. In practice this means the pack needs the contractual surface — BAA or equivalent, data-handling commitments, model-version notification terms — plus your own evidence that the boundary between your system and theirs is instrumented.
Where a submission does apply, this is also where dossiers get thin. A dossier that describes a third-party component as “a large language model API” without version pinning, change-notification terms, or validation against the specific served version is describing a system nobody can characterise. Our broader position on structuring governance artefacts for AI systems sits in AI governance and trust, and the vertical view — how this classification lands in a real clinical or manufacturing workflow rather than in the abstract — is worth reading alongside it.
The cost of getting it wrong in each direction
Over-building means submission-grade documentation effort on workflows that will never be submitted: cost without benefit, and a pack so dense that the auditor’s questions get harder to answer, not easier. Under-building means shipping a claim you cannot defend, discovering it at the worst possible moment, and rebuilding the evidence base under a clock you do not control.
Deciding the boundary before the pack is structured means one artefact build instead of a rework cycle when regulatory affairs re-scopes the intended use. That is the whole return on getting this right: not a better document, but one pass instead of two.
The question worth carrying forward is narrower than “are we regulated.” It is: who in this organisation is allowed to restate the intended use, and does the pack owner find out when they do?
Frequently Asked Questions
What does ‘where the evidence pack ends and a regulatory submission begins’ mean in practice for an AI workflow?
An evidence pack transforms into a regulatory submission at a precise boundary that most development teams misidentify. It means identifying the point at which internal audit evidence stops being sufficient and a regulator’s questions take over. The evidence pack is organised by workflow step and proves governance; a submission is organised by product claim and pathway requirement. The pack is either the terminal artefact or an input to a dossier — never a replacement for one.
What test decides whether an AI workflow triggers submission obligations at all — and who owns that call?
The test is the intended-use statement: if the workflow makes or materially informs a clinical determination, submission obligations attach. If it supports operational or administrative steps inside a covered environment, the pack is terminal. Regulatory affairs owns the classification; engineering’s obligation is to obtain it before the pack structure is fixed.
Which evidence-pack sections are reusable as submission inputs, and which are internal-only by design?
Validation evidence is the most reusable section, followed by model provenance and lineage, with change-control travelling in summary form. Access trails, per-user training records and site-specific SOP references are internal by design — an auditor walking a facility needs them, a regulator assessing a product claim does not.
How should validation evidence be structured so it serves both an internal auditor and a possible dossier without being authored twice?
Make each validation report self-contained: protocol reference, intended-use scope, acceptance criteria, dataset and model version, results, deviations, and a named sign-off. Formatted that way it can be read standalone by either audience. Embedded as narrative summary inside pack prose, it will have to be re-authored under submission deadline.
How does this boundary change when a third-party or hosted model sits inside the regulated step?
The threshold does not move — intended use still decides it. What changes is the pack’s contents: the provider’s controls become part of your evidence chain, so the pack must carry the contractual surface (data-handling commitments, model-version notification terms) plus your own instrumentation of the boundary between your system and theirs.
Knowing when to pivot from pack to submission
Evidence packs stop at internal due diligence; regulatory submissions begin when you address agency-specific requirements and statutory endpoints. The teams that do tend to ship the boring, correct version first.
