The EU AI Act’s high-risk provisions enter into force on 2 August 2026, but enforcement will begin with the first requests for documentation—not the last. Regulators will prioritise cases where evidence is missing, incomplete, or inconsistent. For CTOs and CISOs, this means compliance is not about ticking boxes; it is about constructing a defensible audit trail that proves conformity before the first inspection arrives.
The EU AI Act’s high-risk provisions enter into force on 2 August 2026, but enforcement will begin with the first requests for documentation—not the last. Regulators will prioritise cases where evidence is missing, incomplete, or inconsistent. For CTOs and CISOs, this means compliance is not about ticking boxes; it is about constructing a defensible audit trail that proves conformity before the first inspection arrives.
This guide outlines how to build that trail using the May 2024 draft guidelines from the AI Office and the European Artificial Intelligence Board (EAIB) as a roadmap.
---
Why Documentation Gaps Will Trigger Enforcement First
The AI Act does not prescribe a single conformity assessment procedure for all high-risk systems. Instead, it requires providers to choose between internal controls (Annex VI) or third-party certification (Annex VII), depending on the system’s risk tier and sector. Both routes, however, share a common requirement: documentary evidence that the system meets the seven mandatory requirements of Title III, Chapter 2.
Regulators will not wait for incidents to occur. The AI Office has signalled that its first enforcement wave will focus on documentation gaps—cases where providers cannot produce records of risk assessments, data governance, or testing logs. This approach mirrors the GDPR’s early enforcement pattern, where supervisory authorities targeted missing records of processing activities (ROPA) and data protection impact assessments (DPIA).
For high-risk systems, the stakes are higher. A missing or incomplete technical documentation file (Article 11) can lead to fines of up to 15 million EUR or 3% of global turnover, whichever is higher. More critically, gaps in evidence can trigger market surveillance actions, including withdrawal of the system from the EU market (Article 79).
---
What the Draft Guidelines Require You to Prove (Not Just Implement)
The May 2024 draft guidelines from the AI Office and EAIB clarify that compliance is not about implementing controls—it is about proving that those controls were designed, tested, and maintained. The guidelines break this into three layers of evidence:
1. Design and Development Evidence
- System description: A detailed technical specification that includes the system’s intended purpose, architecture, and key components (Article 11(1)(a)).
- Data governance: Records of data collection, cleaning, labelling, and bias mitigation (Article 10). The guidelines emphasise that providers must document data provenance, including sources, licensing, and any synthetic data generation.
- Risk management system: A living document that evolves with the system’s lifecycle (Article 9). The guidelines require providers to show how risks were identified, assessed, and mitigated at each development stage.
2. Testing and Validation Evidence
- Conformity assessment records: Logs of internal or third-party testing that demonstrate compliance with the seven requirements (Article 43). The guidelines specify that providers must retain raw test data, not just summary reports.
- Bias and robustness testing: Evidence of testing for discrimination, adversarial attacks, and edge cases (Article 15). The guidelines recommend using standardised benchmarks (e.g., ISO/IEC 42001 or sector-specific frameworks) to ensure consistency.
- Post-market monitoring: A plan and logs showing how the system’s performance is tracked after deployment (Article 61). The guidelines require providers to document feedback loops from deployers and end-users.
3. Operational and Governance Evidence
- Quality management system (QMS): Documentation of policies, procedures, and roles responsible for AI governance (Article 17). The guidelines align this with ISO 9001 or equivalent standards.
- Human oversight: Records of how human reviewers are trained, how their decisions are integrated into the system, and how their feedback is used to improve the model (Article 14).
- Incident reporting: Logs of any serious incidents or near-misses, including root cause analysis and corrective actions (Article 62).
The draft guidelines make it clear: regulators will not accept undocumented claims. For example, a provider cannot simply state that its system is "bias-free"; it must produce the testing methodology, datasets, and results that support that claim.
---
Building a Compliance Evidence Repository: Step-by-Step
Creating an audit-ready evidence repository requires a structured approach. Below is a step-by-step framework aligned with the draft guidelines.
Step 1: Map the System’s Lifecycle to Evidence Requirements
Start by mapping the system’s development stages (design, training, testing, deployment, monitoring) to the AI Act’s documentation requirements. Use the following template:
| Lifecycle Stage | AI Act Requirement | Evidence Type | Retention Period |
|---|---|---|---|
| Design | System description (Art. 11(1)(a)) | Technical specification, architecture diagrams | 10 years post-deployment |
| Training | Data governance (Art. 10) | Data provenance logs, bias mitigation reports | 10 years post-deployment |
| Testing | Conformity assessment (Art. 43) | Test logs, benchmark results, third-party certs | 10 years post-deployment |
| Deployment | Human oversight (Art. 14) | Training records, decision logs | 10 years post-deployment |
| Monitoring | Post-market monitoring (Art. 61) | Incident logs, user feedback, performance metrics | 10 years post-deployment |
Step 2: Assign Ownership and Access Controls
Documentation is only as strong as its chain of custody. Assign clear ownership for each evidence type:
- Technical teams (e.g., data scientists, engineers) own raw data, test logs, and system descriptions.
- Compliance teams (e.g., legal, risk) own governance documents, risk assessments, and incident reports.
- IT/security teams own access controls, versioning, and retention policies.
Use role-based access controls (RBAC) to ensure only authorised personnel can modify or delete evidence. The draft guidelines recommend immutable logs for critical records (e.g., test results, incident reports).
Step 3: Automate Evidence Collection Where Possible
Manual documentation is error-prone and unscalable. Automate evidence collection for:
- Data governance: Use tools to log data sources, transformations, and bias checks (e.g., data lineage platforms).
- Testing: Integrate testing frameworks (e.g., MLflow, Weights & Biases) to automatically capture test results, model versions, and performance metrics.
- Incident reporting: Deploy monitoring tools (e.g., SIEM, AI-specific observability platforms) to log anomalies and trigger alerts.
The draft guidelines encourage automation but warn that automated logs must be tamper-evident. Use cryptographic hashing or blockchain-based solutions to ensure integrity.
Step 4: Align with Existing Frameworks
The AI Act does not require reinventing the wheel. Align your evidence repository with existing frameworks:
- ISO/IEC 42001: Provides a structure for AI management systems, including documentation requirements.
- NIST AI Risk Management Framework (RMF): Offers guidance on risk assessment and testing.
- GDPR: If the system processes personal data, ensure data governance records align with GDPR’s accountability principle (Article 5(2)).
The draft guidelines explicitly reference ISO/IEC 42001 as a presumption of conformity for certain requirements (e.g., risk management, QMS).
Step 5: Conduct Mock Audits
Before regulators arrive, test your evidence repository with mock audits. Focus on:
- Completeness: Are all required documents present and up-to-date?
- Consistency: Do records align across teams (e.g., does the risk assessment match the test results)?
- Accessibility: Can you retrieve evidence within 48 hours, as regulators may require?
Use the AI Office’s conformity assessment checklist (published alongside the draft guidelines) as a benchmark.
---
Risk Assessment Documentation: Beyond Checklists to Defensible Records
Risk assessments are the cornerstone of high-risk AI compliance. The AI Act requires providers to implement a risk management system (Article 9) that is continuous, iterative, and documented. The draft guidelines clarify that regulators will scrutinise not just the outcomes of risk assessments but the process behind them.
What Regulators Will Look For
- 1Risk Identification: Evidence that all potential risks were considered, including: - Bias and discrimination: Testing for disparate impact across protected groups (e.g., gender, ethnicity). - Adversarial attacks: Testing for robustness against manipulation (e.g., data poisoning, model inversion). - Systemic risks: Risks to public health, safety, or fundamental rights (e.g., autonomous weapons, social scoring).
- 2Risk Mitigation: Documentation of controls implemented to reduce risks to an acceptable level. The guidelines require providers to show: - Design-stage mitigations: E.g., fairness-aware algorithms, explainability tools. - Operational mitigations: E.g., human oversight, fail-safe mechanisms.
- 3Residual Risk Acceptance: Records of any risks that could not be fully mitigated, including justification for acceptance (e.g., cost-benefit analysis).
How to Document Risk Assessments Defensibly
- Use a standardised methodology: The draft guidelines recommend frameworks like ISO 31000 or NIST AI RMF to ensure consistency.
- Link risks to evidence: For each identified risk, reference the specific test, audit, or control that addresses it. Example: > *Risk: Gender bias in hiring recommendations.* > *Evidence: Bias testing report (Test ID: HR-2024-05-15), mitigation: fairness-aware re-ranking algorithm (Model Version: v3.2).*
- Update dynamically: Risk assessments must evolve with the system. The guidelines require providers to reassess risks after