EU AI Act: what audit findings should high-risk teams expect?

There is no track record of EU AI Act audit findings yet, because the high-risk rules are not in force. So the useful question is where teams will likely be short against Articles 9 to 15. Expect gaps in documentation, record keeping and evidence of human oversight before gaps in the model itself.

This post reads the structure of the Act's high-risk chapter and a published timeline. It is explanatory and not legal advice. It does not suggest any product certifies you.

When do the rules apply?

The Act's implementation timeline page, last updated 31 August 2026, lists these dates:

• Prohibited practices and AI literacy duties: 2 February 2025.
• General purpose AI model rules: 2 August 2025, with models already on the market before that date having until 2 August 2027.
• The remainder of the Act: 2 August 2026, unless specified otherwise.
• High-risk systems under Annex III: 2 December 2027.
• High-risk systems under Annex I: 2 August 2028.

That page did not say whether its dates may change again, and EU timelines have moved before, so confirm the dates against the official text before you plan.

What does the high-risk chapter require?

Section 2 of Chapter III covers Articles 8 to 15. The titles we confirmed are:

• Article 9: Risk Management System
• Article 10: Data and Data Governance
• Article 11: Technical Documentation
• Article 12: Record-Keeping
• Article 13: Transparency and Provision of Information to Deployers
• Article 14: Human Oversight
• Article 15: Accuracy, Robustness and Cybersecurity

We did not read the full article text for this post, so treat the notes below as a way to organize your own reading of it.

Where will the likely gaps be?

These are predictions from the structure of the requirements, not observed findings.

Risk management that is a document, not a process (Article 9). A one time risk assessment will look thin against a requirement framed as a system. Keep it living: versioned, reviewed on change, linked to testing.

Data governance without lineage (Article 10). If you cannot say where training and test data came from, who approved it and how it was checked, expect questions. A dataset inventory with sources and licenses is the starting point.

Technical documentation written after the fact (Article 11). Documents reconstructed from memory contradict the code. Generate them as part of the build where you can.

Logging that exists but cannot answer a question (Article 12). Record keeping needs to support tracing what the system did. Test it by picking a past decision and trying to reconstruct it.

Oversight on paper (Article 14). Naming a reviewer is not oversight. Show that a person can understand, intervene in and override the system, and that they have done so.

Cybersecurity without a supply chain view (Article 15). The system's components, models and datasets are third party code and data. An inventory of dependencies, models and their versions, with a way to learn about vulnerabilities, is the kind of evidence a security reviewer asks for. The OWASP LLM supply chain entry is a good checklist for the model side.

What to do

1. Decide whether your system is high-risk, and under Annex III or Annex I, with counsel.
2. Read Articles 9 to 15 in the official text and make a row per obligation.
3. For each row, name the artifact that proves it and the owner.
4. Build a dependency and model inventory, with versions and sources.
5. Test your logs by reconstructing one past output end to end.
6. Run a human oversight exercise and keep the record.
7. Recheck the application dates every quarter.

Quick check

Sources

• EU AI Act implementation timeline
• EU AI Act, Chapter III section 2
• OWASP GenAI: LLM03:2025 Supply Chain

Last reviewed: 18 October 2026.