EU AI Act Technical Documentation + MDR/IVDR Technical File: Building a Unified Document Set for Healthcare AI

Post #2 of 5 in the sota.io EU Healthcare AI Compliance Series

If post #1 of this series explained why healthcare AI developers carry a double compliance burden, this post addresses where that burden hits hardest in practice: technical documentation.

You must produce two overlapping document sets — the EU AI Act Article 11 technical documentation defined in Annex IV, and the MDR/IVDR Annex II technical file. Both are mandatory. Both are inspected. Both feed into your conformity assessment. And if you maintain them as two separate artefacts, you will spend significant time keeping them consistent while they inevitably drift apart.

The good news: the overlap between the two regimes is substantial. With the right document architecture, you can satisfy both with a single master technical file plus two thin adapter layers. This guide shows you how.

Why Healthcare AI Documentation Is Doubly Complex

Under EU AI Act Article 6(1), AI systems embedded in products covered by Union harmonisation legislation listed in Annex I — including both the Medical Device Regulation (MDR, EU 2017/745) and the In Vitro Diagnostic Regulation (IVDR, EU 2017/746) — are automatically classified as high-risk AI systems when the underlying product requires third-party conformity assessment.

This means your conformity assessment is not conducted under the AI Act's standalone procedures described in Article 43. Instead, it is integrated into the existing MDR/IVDR notified body assessment. Your notified body becomes the AI Act conformity assessment body for the AI components. The technical documentation they review must therefore satisfy both frameworks simultaneously.

This integration is a deliberate efficiency choice by the EU legislator. But it puts the documentation burden squarely on you: you cannot file two separate technical packages with two separate bodies. One body, one review, two compliance frameworks.

What EU AI Act Article 11 and Annex IV Require

Article 11 of the EU AI Act requires providers of high-risk AI systems to draw up technical documentation before placing the system on the market. The documentation must demonstrate conformity with the AI Act and provide national competent authorities and notified bodies with sufficient information to assess it.

Annex IV specifies what this documentation must contain. The key sections are:

1. General description of the AI system This includes the intended purpose, version information, hardware requirements, and the broader system or product in which the AI is embedded. For a medical device, this maps directly to the device description section of your MDR technical file.

2. Detailed description of the elements and development process This is where AI Act requirements go substantially further than MDR. You must document:

• The general logic, design choices, and key design assumptions, including the trade-offs made
• The training, validation, and testing data including their provenance, curation methodology, and characteristics
• The algorithms, models, and the main model parameters including hyperparameters
• The description of the performance metrics used during development
• The testing, validation, and verification approaches

MDR Annex II requires design documentation and a description of applied design phases. But it does not prescribe the level of algorithmic detail the AI Act demands. You must go further for AI Act compliance.

3. Monitoring, functioning, and control of the AI system This includes logging capabilities, human oversight mechanisms, and stop functionality. MDR addresses post-market surveillance separately, but the AI Act requires you to build logging into the technical documentation from the start, linked to Article 12 record-keeping obligations.

4. Explainability of the outcomes for the deployer For medical AI, this is substantive. The documentation must explain how the system reaches its outputs. A black-box AI system is compliant only where Annex IV explainability requirements can be met — which for high-confidence diagnostic AI is rarely trivial.

5. The detailed technical description for high-risk systems This includes robustness and cybersecurity measures, accuracy metrics, and the appropriate performance metrics depending on the intended purpose. Article 15 sets out the accuracy, robustness, and cybersecurity obligations that underpin this section.

6. The EU declaration of conformity Referenced in Article 47, this must be included in or annexed to the technical file.

7. Changes and updates Versioning and change management documentation, including a description of how changes to the system are tracked and assessed for their conformity impact.

What MDR Annex II and IVDR Annex II Require

MDR (EU) 2017/745 Annex II sets out the technical documentation requirements for medical device manufacturers. The structure covers:

Device description and specification, including device variants, accessories, intended purpose and intended patient populations, and the intended use environment.

Reference to previous and similar generations of the device, including a comparison of design choices and a justification for any changes.

Design and manufacturing information, including raw materials, processing steps, sterilisation details where relevant, and manufacturing site information.

General safety and performance requirements, mapped to the requirements in MDR Annex I (General Safety and Performance Requirements, GSPR), with a compliance matrix.

Benefit-risk analysis and risk management, following EN ISO 14971:2019. This is your MDR risk management file.

Product verification and validation, including pre-clinical and clinical data summaries, and for class IIb and III devices, a clinical evaluation report under Article 61 and Annex XIV.

Post-market surveillance documentation, including a post-market surveillance plan and, for class IIb/III, a Periodic Safety Update Report (PSUR) plan.

IVDR Annex II mirrors this structure with adaptations for in-vitro diagnostic devices, including analytical and diagnostic performance studies instead of clinical evaluation.

The Overlap Map: Where to Build Your Unified Core

The following areas overlap substantially between AI Act Annex IV and MDR Annex II:

Where AI Act Goes Further: The Gaps You Must Fill

Four areas in Annex IV have no equivalent in MDR Annex II and must be created from scratch:

Training data documentation. You must document the provenance, curation methodology, and characteristics of your training, validation, and testing datasets. This includes bias analysis and steps taken to address identified biases. MDR has no such requirement.

Model architecture documentation. Annex IV requires documentation of the algorithms and models, including key model parameters and hyperparameters. Your MDR technical file likely contains software architecture documents but not model-level algorithmic detail. You need a dedicated model card or algorithm specification document.

Explainability documentation. For each AI output that a deployer (e.g., a hospital or clinician) relies on, you must document how the output is produced and what information the deployer receives to understand it. This is not a clinical evaluation requirement under MDR; it is a new AI Act obligation.

Human oversight documentation. You must document the technical measures that enable human oversight as required by Article 14: the ability to pause, override, or shut down the system, and the information provided to users to enable meaningful oversight. MDR addresses user information in Instructions for Use, but Article 14 requires a higher level of structural documentation about oversight architecture.

Practical Document Architecture for a Unified Technical File

The most defensible structure separates a core technical file — shared between MDR and AI Act — from two thin compliance adapter sections that translate core content into the specific language and format of each framework.

Technical File Master v[X.Y]
│
├── PART A — Core Technical Content (shared)
│   ├── A1. Device and AI System Description
│   ├── A2. Intended Purpose and Intended Users
│   ├── A3. Risk Management File (EN ISO 14971)
│   ├── A4. Software Architecture and Algorithm Specification
│   ├── A5. Training Data Documentation (AI Act primary)
│   ├── A6. Verification and Validation (Test Reports)
│   ├── A7. Cybersecurity Documentation
│   ├── A8. Change History and Version Log
│
├── PART B — MDR Annex II Compliance Adapter
│   ├── B1. GSPR Compliance Matrix (references to Part A)
│   ├── B2. Clinical Evaluation Report
│   ├── B3. Post-Market Surveillance Plan
│   ├── B4. Labelling and Instructions for Use
│
└── PART C — EU AI Act Annex IV Compliance Adapter
    ├── C1. AI Act Annex IV Structure Cross-Reference (maps §1–§7 to Part A)
    ├── C2. Explainability Documentation
    ├── C3. Human Oversight Architecture Documentation
    ├── C4. EU Declaration of Conformity (Article 47)

The key rule: no substantive content lives in Parts B or C. They are cross-reference and gap-fill layers. All substantive technical content lives in Part A. When your notified body reviews the file, they can navigate from either MDR Annex II or AI Act Annex IV into the same core content.

Training Data Documentation: The Hardest New Requirement

For healthcare AI developers, training data documentation is typically the largest documentation gap. MDR does not address it. AI Act Annex IV requires you to document:

• The source(s) of the training, validation, and test datasets, including where externally sourced
• How data was acquired and selected
• The data labelling methodology and criteria
• What data governance was applied (access controls, de-identification, consent frameworks)
• A statistical description of the datasets (size, feature distributions, demographics)
• An analysis of known biases, limitations, or data quality issues
• What steps were taken to address those issues

For medical AI trained on patient data, this documentation must also address GDPR and MDR clinical data requirements. The data you used, how patients consented (or how consent was waived under national ethics approvals), and how data was de-identified must all be traceable.

This is not a small document. For a typical diagnostic AI system, training data documentation runs to 20–50 pages. Build it once, version it alongside your model versions, and store it in Part A.

Versioning Strategy: Keeping the Unified File Current

Both AI Act and MDR require documentation to be kept up to date. When you modify your AI system, you must assess whether the modification:

• Introduces a new intended purpose or changes the existing one (triggers full re-review)
• Changes the underlying model (triggers data and validation documentation update)
• Changes performance metrics materially (triggers clinical evaluation update under MDR, Annex IV §2.5 update under AI Act)
• Changes cybersecurity architecture (triggers both GSPR and AI Act §2.6 updates)

Implement a change control procedure that asks all four questions for every proposed modification. The AI Act adds one AI-specific trigger that MDR does not cover: significant changes to the training data (e.g., re-training on new datasets) should trigger a documentation review even where the software code is unchanged.

Version the full technical file as a single document set, not individual files with independent version numbers. When your notified body reviews a change, they should be able to compare version N and version N-1 as coherent packages.

Working With Your Notified Body on the Dual Framework

If your device requires notified body involvement under MDR/IVDR, that notified body becomes responsible for AI Act conformity assessment of the AI components under the Article 6(1) mechanism. In practice, this means:

Your notified body needs AI Act training. Many notified bodies were designated before the AI Act entered force. Ask your notified body whether they have received guidance from their national designating authority on AI Act integration. The European Commission has published implementing acts and guidance notes for notified bodies.

Technical review will extend. A notified body reviewing a file that now includes AI Act Annex IV training data documentation, explainability sections, and human oversight architecture documentation will take longer. Build at least 20% additional review time into your conformity assessment schedule.

Plan your August 2, 2026 deadline. The AI Act full applicability date for high-risk systems under Annex III is August 2, 2026. For Article 6(1) products like medical AI, the same date applies. If your device is undergoing MDR renewal or initial certification in 2026, the AI Act documentation requirements apply to that submission now.

Immediate Actions for Healthcare AI Teams

You can start building the unified documentation structure today:

1. Audit what you have. Map your existing MDR technical file structure against AI Act Annex IV Sections 1–7. Identify gaps — training data documentation and explainability will almost certainly be missing.

2. Inventory your training data. Contact your data sources and confirm you can document provenance, selection criteria, labelling methodology, and demographics. For proprietary or licensed datasets, check your data use agreements for documentation permissions.

3. Commission an explainability assessment. For each AI output relied on by a clinical deployer, document the output type, the information provided to the user, and the technical mechanisms underlying explainability (e.g., attention maps, SHAP values, confidence intervals).

4. Map your human oversight controls. Review Article 14 and document the specific technical measures you have implemented for each requirement: pause capability, override mechanism, shutdown procedure, and information provided to enable meaningful human review.

5. Open the notified body conversation. Contact your notified body and ask specifically how they plan to handle the AI Act integration in upcoming reviews. Align on document format expectations before you finalise your architecture.

Conclusion

The EU AI Act does not require a new, standalone technical file separate from your MDR/IVDR documentation. But it does require you to go deeper in four areas — training data, model architecture, explainability, and human oversight — than MDR demands.

The unified document architecture in this guide lets you satisfy both frameworks from a single authoritative Part A, with thin adapter layers for each regulatory framework. Build it once. Version it carefully. Present it to your notified body as a single coherent package.

Post #3 in this series covers the QMS alignment question: how to build a quality management system under ISO 13485 that also satisfies EU AI Act Article 17 — and how the two QMS frameworks complement each other rather than conflict.

Sources: Regulation (EU) 2024/1689 (EU AI Act), Art.6, Art.11, Art.12, Art.14, Art.15, Art.17, Art.43, Art.47, Annex I, Annex IV; Regulation (EU) 2017/745 (MDR), Annex I, Annex II; Regulation (EU) 2017/746 (IVDR), Annex II; EN ISO 14971:2019 (Medical devices — Application of risk management to medical devices).