EU AI Act Audit-Ready Evidence Packet: 30 Documents Every High-Risk AI Provider Must Have Before August 2026

Post #1477 — EU-AI-ACT-AUDIT-READINESS-SPRINT-2026 #1/5

It is 60 days before August 2, 2026. A national competent authority (NCA) inspector sends your legal team a document request. Under Art.74, market surveillance authorities have direct access rights to your technical documentation, test records, and conformity evidence. What exactly do they ask for — and is your documentation ready to deliver within the response window?

This post maps the 30 documents that form a complete audit evidence packet for high-risk AI providers. Organized by the five core obligation clusters that inspectors verify, this guide closes the gap between compliance work done and compliance work that can be proven.

Why Proof Structure Matters More Than Compliance Work

Most teams spend 90% of their time on the technical obligations and 10% on documentation. NCA inspectors work in the opposite direction: they read documentation first, then verify technical claims.

An undocumented control is, from an NCA perspective, a control that does not exist. A well-documented risk management system with three minor gaps is often treated more favourably than an excellent technical implementation with no written records.

Art.74 authorizes market surveillance authorities to:

• Request complete access to technical documentation
• Conduct on-site inspections of systems and development environments
• Run independent tests of AI system behaviour
• Take corrective measures including withdrawal from market where documentation is missing or non-conforming

The following five bundles represent what inspectors systematically request.

Bundle 1: Risk Management System (Art.9) — 6 Documents

Art.9 requires providers to establish a continuous risk management system throughout the AI system lifecycle. Inspectors verify that this is a living process with auditable records — not a static document produced once during development.

Document 1: Risk Management Plan

The governance document defining your risk management process, responsible roles, review cadence, and escalation paths. Must explicitly cover the entire lifecycle from initial design through decommissioning. Common gap: missing post-deployment update schedule.

Document 2: Risk Register

An itemized list of identified risks with likelihood and severity scoring, each linked to specific mitigation measures. Must include foreseeable misuse scenarios, not only intended use. Common gap: risks identified only for intended use; misuse scenarios undocumented.

Document 3: Risk Control Measures Log

For each risk in your register, the specific technical and organizational controls implemented, with cross-references to test evidence. Must distinguish between controls that reduce likelihood and controls that reduce severity. Common gap: measures listed without test citations.

Document 4: Residual Risk Acceptance Record

A signed record that remaining risks after mitigation are acceptable relative to your system's intended purpose and user population. Must identify who has authority to accept residual risk and the basis for their decision. Common gap: unsigned or undated, with no decision rationale.

Document 5: Vulnerability Monitoring Log

Evidence that risk management is continuous — including dates, methods used, and findings from each monitoring cycle. Must show what changed (or was confirmed unchanged) in each review. Common gap: log exists but contains no monitoring findings, only schedule records.

Document 6: Risk Management Version History

A change log showing when the risk management system was updated, what changed, and what triggered the update. Must include incident-triggered updates, not only scheduled reviews.

Bundle 2: Training Data Governance (Art.10) — 5 Documents

Art.10 requires that training datasets meet quality criteria, are sufficiently representative, and that the governance process is fully documented. Inspectors specifically focus on bias examination records and data provenance.

Document 7: Training Data Specification

The complete specification of datasets used — what they are, why each was selected, how they map to the intended purpose, and what quality criteria they must satisfy. Must cover training, validation, and test splits.

Document 8: Data Provenance Record

Where each dataset originated, collection methodology, licensing status, and all preprocessing transformations applied. Must be traceable back to original sources. Common gap: preprocessed data documented without original source provenance.

Document 9: Bias Examination Report

The documented process and results of your examination for biases in training data — covering demographic representation, proxy variable risk, and class imbalances relevant to your use case. Must include the methodology used and who conducted the examination.

Document 10: Data Governance Policy

Your organizational policy covering data quality gates, access controls, dataset versioning, and the process for retiring or replacing training data. Must assign roles and responsibilities for data governance decisions.

Document 11: Post-Deployment Data Monitoring Record

Evidence that data governance continues after deployment — including distribution shift monitoring, performance degradation alerts, and any triggered dataset updates.

Bundle 3: Technical Documentation (Art.11 + Annex IV) — 7 Documents

Art.11 requires technical documentation sufficient for authorities to assess conformity. Annex IV specifies mandatory content in detail. This bundle is typically the largest and the one most likely to have gaps in systems built without the regulation in mind.

Document 12: System Description and Intended Purpose Statement

The complete intended purpose — including target user population, geographic scope, use conditions, contraindicated uses, and the specific outcome the system is designed to achieve. Must be precise enough to define the boundaries of your conformity assessment scope.

Document 13: System Architecture Diagram

A technical diagram showing all components, data flows, integration points, third-party API dependencies, and the boundary between your AI system and operator environments. Must be kept current with each release.

Document 14: Model Card and Algorithm Description

The technical specification of the model(s) deployed — training methodology, evaluation methodology, accuracy and performance metrics, and known limitations. Must include performance breakdowns by relevant subgroups.

Document 15: Test and Validation Records

All test results demonstrating that the system meets its claimed performance specifications across representative test populations. Must include both pre-deployment validation and post-deployment performance data.

Document 16: Cybersecurity Measures Description

The security controls implemented to address adversarial manipulation, data poisoning, model extraction, and unauthorized access. Must include the threat model that justified your control selection.

Document 17: System Change Log

A versioned history of all material changes to the AI system, with assessment of whether each change meets the threshold for "substantial modification" requiring reassessment.

Document 18: Compliance Self-Assessment Matrix

A structured document mapping each Art.9 through Art.15 obligation to the specific implementation evidence in your documentation package. This is your own audit of your own audit packet — and it signals organizational maturity to inspectors.

Bundle 4: Transparency and Human Oversight (Art.13 + Art.14) — 5 Documents

Art.13 requires that deployers receive sufficient information to operate the system appropriately. Art.14 requires that human oversight measures are technically enabled and documented.

Document 19: Instructions for Use

The complete document provided to deployers — covering intended purpose, accuracy metrics by context, input and output format specifications, integration requirements, monitoring obligations, and known limitations. Must be sufficient for a deployer to make an informed decision about deploying the system.

Document 20: Human Oversight Specification

Technical documentation of how your system enables human review, override, and intervention — including the interface design decisions and technical mechanisms that support effective oversight without creating undue operational burden.

Document 21: Deployer Notification Procedure

The written procedure for notifying deployers when a significant system event occurs — including your response window, notification template, and escalation path for events affecting deployer obligations.

Document 22: Transparency Delivery Record

Evidence that you have fulfilled Art.13 obligations for each active deployer — including communication logs or signed acknowledgment records.

Document 23: Override and Stop-Function Test Record

Test evidence demonstrating that human operators can effectively pause, override, or stop the AI system. Must include test scenarios, test dates, and test results.

Bundle 5: Conformity Assessment and Post-Market Monitoring (Art.43 + Art.47 + Art.72) — 7 Documents

Art.43 covers the conformity assessment process. Art.47 requires a signed declaration. Art.72 establishes ongoing post-market monitoring obligations that continue throughout the product's commercial lifetime.

Document 24: Conformity Assessment Procedure Record

Documentation of which conformity assessment route was selected, why it applies to your system's classification, who conducted it, and when. Must include the scope boundary that defined what the assessment covered.

Document 25: EU Declaration of Conformity

The signed declaration under Art.47 — must include your company's full name and address, the AI system's intended purpose, the conformity assessment procedure used, the reference to applied harmonised standards, and the signature of the authorizing person with their role.

Document 26: CE Marking Authorization Record

If CE marking is required, the internal authorization record approving affixation — including the authorizing role, date, and the documentation package it was based on.

Document 27: EU Database Registration Confirmation

Proof of registration in the EU database for high-risk AI systems prior to market placement. This confirmation record must be current — registration that predates a substantial modification may require reregistration.

Document 28: Post-Market Monitoring Plan

Under Art.72, a proactive plan for collecting and analysing data on system performance in deployment — including the specific metrics tracked, the thresholds that trigger corrective action, the data collection method, and the review cadence.

Document 29: Serious Incident Response Procedure

Your written procedure for identifying what qualifies as a serious incident, escalating within your organization, and reporting externally. Must define the roles responsible at each escalation step and include communication templates.

Document 30: Post-Market Monitoring Reports

Periodic reports generated from your Art.72 plan — demonstrating that you are actively tracking performance against declared specifications and responding to findings. Inspectors look for continuity: one report filed at launch is insufficient.

How to Package Your Evidence Packet

NCA inspectors typically issue structured document requests with response windows. Organizing your documentation in advance — with a master index mapping each regulatory obligation to its specific evidence location — reduces your response time from weeks to hours.

A practical directory structure:

/audit-evidence-packet/
  00-MASTER-INDEX.md             # Maps each obligation to document location
  01-risk-management/            # Bundle 1: Documents 1-6
  02-training-data/              # Bundle 2: Documents 7-11
  03-technical-documentation/    # Bundle 3: Documents 12-18
  04-transparency-oversight/     # Bundle 4: Documents 19-23
  05-conformity-registration/    # Bundle 5: Documents 24-30
  06-change-records/             # Version history cross-referenced by bundle

Each bundle directory should contain a BUNDLE-README.md listing what each document covers and its current version. When an inspector requests "your Art.9 documentation," you can respond with a single archive — not a hunting expedition through your Confluence instance.

The 30-Document Audit Checklist

BUNDLE 1 — RISK MANAGEMENT (Art.9)
□  1.  Risk Management Plan
□  2.  Risk Register
□  3.  Risk Control Measures Log
□  4.  Residual Risk Acceptance Record
□  5.  Vulnerability Monitoring Log
□  6.  Risk Management Version History

BUNDLE 2 — TRAINING DATA (Art.10)
□  7.  Training Data Specification
□  8.  Data Provenance Record
□  9.  Bias Examination Report
□ 10.  Data Governance Policy
□ 11.  Post-Deployment Data Monitoring Record

BUNDLE 3 — TECHNICAL DOCUMENTATION (Art.11 / Annex IV)
□ 12.  System Description and Intended Purpose Statement
□ 13.  System Architecture Diagram
□ 14.  Model Card and Algorithm Description
□ 15.  Test and Validation Records
□ 16.  Cybersecurity Measures Description
□ 17.  System Change Log
□ 18.  Compliance Self-Assessment Matrix

BUNDLE 4 — TRANSPARENCY + HUMAN OVERSIGHT (Art.13 + Art.14)
□ 19.  Instructions for Use
□ 20.  Human Oversight Specification
□ 21.  Deployer Notification Procedure
□ 22.  Transparency Delivery Record
□ 23.  Override and Stop-Function Test Record

BUNDLE 5 — CONFORMITY + REGISTRATION + POST-MARKET (Art.43 + Art.47 + Art.72)
□ 24.  Conformity Assessment Procedure Record
□ 25.  EU Declaration of Conformity
□ 26.  CE Marking Authorization Record
□ 27.  EU Database Registration Confirmation
□ 28.  Post-Market Monitoring Plan
□ 29.  Serious Incident Response Procedure
□ 30.  Post-Market Monitoring Reports

What Comes Next in This Series

This is post 1 of 5 in the EU AI Act Audit Readiness Sprint 2026:

• #1 (this post): The 30-document audit evidence packet — what NCAs request
• #2: Writing a Risk Management Plan that survives an inspection (Art.9 deep dive)
• #3: Building an Annex IV Technical Documentation package — what auditors actually read
• #4: EU Declaration of Conformity and database registration — the August 2026 final steps
• #5: Audit Readiness Finale — a complete 60-day sprint checklist

Infrastructure Note

One operational factor that simplifies evidence packaging: infrastructure jurisdiction. When your AI system's training pipelines, model weights, and technical documentation reside on EU-jurisdiction infrastructure, you avoid CLOUD Act complications — the risk that US authorities compel simultaneous access to documentation under US law while your NCA review is in progress.

Deploying on sota.io keeps your workloads on Hetzner Germany — single EU legal order, no US parent, no CLOUD Act exposure. That structural clarity extends to your audit evidence: all technical documentation and monitoring data stays within EU jurisdiction throughout the NCA review process.

August 2, 2026 is 60 days away. Build your evidence packet before the request arrives.