Automating 80% of your IEC 62304 docs without failing audit: the human–AI boundary

Writing a Software System Architecture (SSA) document for a Class B medical device takes two to three days by hand. Not because the architects don’t know their architecture — they do — but because regulatory documentation is a distinct skill from design, one that repeats at every version, every audit, every release. AI promises to absorb most of it. The real question is not “can it be automated?” but “will the file hold up in front of a notified body?”. The answer lies in a disciplined boundary: 80% mechanical and automatable, 20% irreducibly human judgment.

Why is 80% of an IEC 62304 file mechanical?

Definition: an architecture document has two layers — a baseline identical across all your devices, and content specific to each product. Once you draw that separation, the document is just a template with parameters.

• Layer 1 — the baseline: hosting, security stack (WAF, next-generation firewall, SIEM), CI/CD pipeline (dependency auditing, SAST, SBOM), multi-tenant isolation model, update pathway. This is the same infrastructure for every device you ship.
• Layer 2 — the product-specific: product identity and version, IEC 62304 classification, MDR class, clinical actors, inputs/outputs, use cases, software life-cycle states, third-party components beyond the baseline, specific threat scenarios.

Layer 1 is fixed in the template. Layer 2 lives in a manifest you fill in per product. The generator only combines the two — structure, boilerplate, figures, cross-references. That purely repetitive scope is what weighs 80% of the time, and what makes documentation rot: a section to reword for the audit, a third-party inventory current six months ago, a diagram technically accurate but unreadable for the file.

What can you automate without risk?

Everything deterministically verifiable:

• Structure and boilerplate: recurring sections, the infrastructure baseline, stable regulatory wording.
• Figures: architecture, C4, use-case, state, deployment diagrams — generated from the manifest, never hand-drawn twice.
• Traceability and cross-references: every use case tied to its actor and its scope (medical-device or not), every requirement to its figure.
• Formatting: conversion to Word with the house styles and branding, table of contents, headers — a deliverable that looks like a corporate document, not a script’s output.

These share one property: if they’re wrong, the automated check catches it (a missing field, a figure that won’t compile, an undeclared scope). That is exactly what automation can guarantee.

Which 20% must a human own?

This is the heart of the system: make the 20% explicit rather than bury it. Here is what requires judgment, and why it can’t be computed.

A tool that claims to decide these doesn’t save time: it produces a file that will be challenged at the first audit.

The gate that makes the file defensible

This is the piece most “AI docs” articles skip — and the most important in a regulatory context.

Every run produces, alongside the document, a separate audit report for the lead dev and the Regulatory Affairs specialist. It assigns each section a confidence level — HIGH / MEDIUM / LOW — based on heuristics: how many fields come straight from the manifest, whether the section holds free text that can’t be generated, whether a cross-reference to another quality-system document is required. Two sections are hard-floored to MEDIUM regardless: the third-party inventory (always to cross-check) and the approval block (human signatures).

In parallel, every claim needing validation is highlighted in the document (a “to be confirmed” marker the specialist spots instantly): intended use, risk ratings, versions. The review flow becomes trivial: treat the LOWs first, then the MEDIUMs, check the HIGHs in a quick pass, then read every highlighted passage.

This is not “the AI did it, please sign.” It’s a structured handoff that makes the 20% explicit, named, and owned by the person best positioned to judge it.

That is precisely what makes a generated file defensible: not because a machine produced it, but because the human judgment is traced, not assumed.

What are the concrete results?

On a 3D surgical-planning module in production, after three months of use:

• Full file generation: ~4 minutes (versus 2–3 days of manual writing).
• Regulatory review: ~2 hours — and that is where the value now concentrates.
• 10 figures generated automatically, ~25 items to validate flagged per run.

The gain is not “the human disappears.” It’s the opposite: the marginal cost of an auditable file tends toward zero, and expert time shifts entirely to the 20% that matter. The full pipeline — our approach to IEC 62304 docs generated from CI/CD — rests on the same principle: documentation is born from the sources of truth, the human keeps the judgment.

This boundary — automation collects, the human judges — is not specific to the 62304 file: it also structures information-security compliance, where compliance-as-code continuously collects SOC 2 and ISO 27001 evidence without ever producing the device’s regulatory file either.

FAQ

Does a notified body accept automatically generated documentation?

Yes. What matters is not how the document is produced, but that it is accurate, traced and validated by the right people. A generated file that is then reviewed and signed is as admissible as a hand-typed one — often more consistent, because structure and traceability cannot drift.

Can AI decide the IEC 62304 class of my software?

No. The class (A, B or C) depends on whether a failure can contribute to a hazardous situation — a judgment validated against your Level of Concern, consistent with your device’s MDR classification. The tool takes the class as given; it never decides it.

How long does it take to set up?

Budget a few weeks for the first template + manifest — the real work is to separate once the baseline (Layer 1) from the product-specific (Layer 2). After that, the marginal cost of each new file collapses. The full technical implementation (pipeline, templates, code) is detailed in my field write-up on Medium.