Why teams move design control into software
A design file links thousands of records: requirements, risks, specifications, test results, reviews and changes. In documents and spreadsheets, those links break every time something changes. Design control software keeps the records and the links in one controlled system, so the design and development file is assembled as work happens rather than at the end.
2026 raised the stakes. Since February 2, 2026, the QMSR applies ISO 13485 clause 7.3 to US design controls, FDA withdrew its 1997 design control guidance, and inspections follow a new compliance program that evaluates design inputs, outputs, review, verification, validation, software validation and transfer (FDA, Withdrawn guidance; FDA, QMSR inspections). Tools built around “820.30” templates need updating.
What to automate, and what not to
| Activity | Automate? | Why |
|---|---|---|
| Linking requirements, risks, design outputs and tests | Yes | Links are the most error-prone part of a manual design file |
| Change impact analysis | Yes, as a suggestion | Software can show every record a change touches; engineers judge significance, as clause 7.3.9 requires (FDA) |
| Design review packages | Yes | Assembling records for review is clerical; the review itself is not |
| Coverage reports (untested requirements, uncontrolled hazards) | Yes | Mechanical checks a tool does better than people |
| Approvals and e-signatures | Yes, with Part 11 controls | Audit trails and signature manifestation are required for electronic records |
| DHF export or index | Yes | One click from records to a file an inspector can follow |
| Deciding a requirement is met, a risk is acceptable, a design is ready | No | These are engineering and quality judgments |
Where AI fits in design control
AI is useful where design work is reading-heavy: drafting requirement wording, proposing trace links, finding requirements with no test, spotting contradictions between documents and summarizing test reports. Research on LLM-based tracing is advancing; a February 2026 study reported “state-of-the-art F2 scores, outperforming traditional IR baselines” (arXiv, TraceLLM).
The guardrails are already set by enforcement. In an April 2026 warning letter, FDA found a firm had “used AI to create drug product specifications, procedures, and master production or control records” and stated AI output “must be reviewed and cleared by an authorized human representative of your firm’s QU” (FDA warning letter, Purolea). That letter concerned drug manufacturing, but the principle carries to design records: AI may suggest and cite; qualified people decide and sign.
Validating design control software
Design control software is QMS software, so it must be validated for its intended use. FDA’s Computer Software Assurance guidance describes “a risk-based approach to establish confidence in the automation used for production or quality management systems” (FDA, CSA guidance). In practice:
- Define intended uses: which design records the tool creates, links or approves.
- Rate risk per feature: a trace-coverage report that hides a gap is higher risk than a formatting feature.
- Use vendor evidence for standard functions; test your configuration and workflows.
- Test AI features separately: measure suggestion accuracy on your own data and confirm humans approve every output.
- Re-assess on updates, especially for cloud tools with frequent releases.
Design control software selection checklist
- Structure maps to ISO 13485 clause 7.3 and the QMSR, not only 820.30
- Bidirectional traceability across needs, requirements, risks, outputs and tests
- Change impact view with links to affected records
- Coverage reports for untested requirements and uncontrolled hazards
- Design review packages and recorded decisions
- Part 11 audit trails, e-signatures and access control
- Exportable design and development file an inspector can follow
- Integrations with risk, test, software and document control tools
- AI features cite sources and require human approval
- Vendor validation evidence and a risk-based CSA approach
Automate the record keeping, verify the reasoning
Tools can link records; they cannot tell whether a test report actually proves a requirement or a risk control is adequate. AskDona reviews the content of design records against ISO 13485 clause 7.3, the QMSR or your own procedure, flags unsupported conclusions, missing evidence and inconsistencies, and cites the passage behind every finding. It works alongside the system that stores the records.
Run a sample design file assessment on one exported design file. AskDona shows the evidence; your teams decide.
FAQ
What is design control software? Software that manages design control records and their links, from user needs and requirements to verification, validation, reviews and changes.
What is DHF automation? Assembling the design and development file automatically from linked records instead of compiling documents by hand.
Does design control software need validation? Yes, proportionate to risk, following FDA’s CSA approach for QMS software (FDA).
Can AI write design controls? AI can draft and suggest, but qualified people must review and approve, as FDA’s 2026 enforcement shows (FDA).
Do I need to update my tool for the QMSR? Likely yes, if templates and procedures reference 820.30 or the withdrawn 1997 guidance.
References
All pages opened and checked by October 14, 2026.
| Source | Type | Date | Used for |
|---|---|---|---|
| FDA: Withdrawn guidance | Regulator | Current | 1997 guidance withdrawn |
| FDA: QMSR risk-based inspections (slides) | Regulator | Apr 1, 2026 | Design elements inspected |
| FDA: QMSR Design and Development (slides) | Regulator training | 2026 | Clause 7.3.9 changes |
| arXiv: TraceLLM | Research preprint | Feb 1, 2026 | AI tracing |
| FDA warning letter: Purolea | Regulator | Apr 2, 2026 | Human review of AI |
| FDA: CSA guidance | Regulator guidance | Feb 2026 | Software validation |