The EU AI Act's High-Risk Audits Have Started: What Enterprise Teams Should Have Ready by Q4 2026

The EU AI Office started its first wave of high-risk system audits this month. The regulatory theory has ended and the operational phase has begun. Every enterprise we work with in Europe is now scrambling to answer a question they were told they had a year to prepare for: can you produce, on request, evidence that a specific AI system your business uses meets the conformity, documentation, and post-market monitoring obligations of the AI Act. Most of the answer is engineering work. Most of that engineering work has not been done.

The pattern we are seeing on the ground is not unique to any one industry. Financial services, insurance, healthcare, HR technology, staffing, and border-adjacent logistics are the earliest audit surfaces. The gaps are similar across all of them. This is the readiness picture we would want to see on any Q4 2026 audit table, and the shortest path to close each gap that we have observed in the field.

Confirm the scope before you plan the work

The single most common mistake we see is teams preparing for AI Act obligations they do not actually have and skipping the ones they do. Get the classification right first.

• High-risk under Annex III. The default audit target. If your system is used for biometrics, critical infrastructure, education, employment, credit or insurance decisions, law enforcement, migration, or administration of justice, treat every model in scope as high-risk until proven otherwise.
• Deployer versus provider obligations. An enterprise that self-hosts and adapts a foundation model is a provider for that model. An enterprise that buys a SaaS product with a fixed vendor model embedded is usually a deployer. The obligations are meaningfully different. The audit will apply the correct set based on your actual configuration, not on what your vendor's marketing says.
• GPAI overlay. The general-purpose AI model rules that entered into force in July apply on top of Annex III where applicable. If you build on a frontier model you inherit obligations upstream that you must be able to evidence downstream.

Do this classification exercise in a room with legal, security, and engineering present. Every downstream artefact depends on it. We have seen weeks of documentation work wasted because the wrong classification was locked in early.

The eight artefacts an audit expects to see

Once scope is confirmed, the audit surface is concrete. These are the eight artefacts we assemble for every high-risk engagement. If any of these do not exist for a system you have already deployed, that system is your first priority.

1. Technical documentation package

A single controlled document describing the system's intended purpose, its architecture, its training and evaluation data lineage, its performance characteristics, and its known limitations. Article 11 spells out the required contents. Do not write this at audit time. Generate it from the same sources your engineering team already uses so it stays current.

2. Risk management system

A living register of identified risks, their mitigations, their residual severity, and the review cadence. This is a Quality Management System artefact, not a slide deck. If your risk management for the model consists of a Confluence page nobody has edited since launch, you do not have one.

3. Data governance evidence

Provenance and quality records for every dataset used to train, fine-tune, or evaluate the model. Article 10 requirements are strict on relevance, representativeness, and appropriate handling of sensitive attributes. For third-party data, get the provider's compliance letter now, not on the day the auditor asks.

4. Human oversight design

Documented decisions about where humans intervene, what information they see, and what they are trained to do. Vague statements like "a human reviews the output" do not survive scrutiny. The audit asks for the specific UI, the specific role, the specific training material, and the intervention rate over the last quarter.

5. Accuracy, robustness, and cybersecurity measures

Article 15 expects continuous evidence, not a one-time launch test. This means an evaluation suite that runs on every material model change, adversarial testing that includes prompt injection and data poisoning for LLM-based systems, and an operations record of production incidents and their resolutions.

6. Post-market monitoring plan

A written plan and the log entries proving it is executed. Concept drift, distribution shift, and disparate performance across subpopulations are the specific properties the plan must monitor. A quarterly review is the minimum cadence we recommend clients commit to on paper.

7. Incident logging and reporting

A defined pipeline for serious incidents and near-misses, with reporting timelines that meet the fifteen-day obligation for serious incidents. Most enterprise incident systems today were built for outages, not for algorithmic harms. They usually need extending, not replacing.

8. Conformity assessment and CE registration

Where the AI Act requires conformity assessment before market entry, the internal or notified body review must be complete and the system registered in the EU database. If you deployed a high-risk system before registration, prioritise closing that gap even ahead of the audit trail.

How much lead time you actually have

The audit letters we have seen give a working window of roughly six to twelve weeks between initial notification and the substantive review. That is enough time to produce documentation for a system you already understand well. It is not enough time to reconstruct data lineage, retrofit a monitoring plan, or run adversarial evaluation from a standing start. The teams that will get through their first audit cleanly are the ones that have already done ninety percent of the work.

The Q4 2026 readiness plan we run with clients

For enterprises that are behind, the plan is straightforward and time-boxed. It has to be, because the work is not glamorous and it competes with everything else the engineering team has been asked to do this quarter.

• Weeks 1 to 2. Inventory and classify. Every AI system currently in production, its provider or deployer status, and its Annex III classification if any. A concrete list, not a taxonomy. We staff a two-person team to complete this pass in ten working days.
• Weeks 3 to 4. Gap analysis against the eight artefacts. For each in-scope system, a red/amber/green score on each artefact with the specific remediation task attached.
• Weeks 5 to 10. Close reds first. Documentation packages, data lineage reconstruction, and human oversight redesign are the three items that consume most of the calendar. Everything else is faster in comparison.
• Weeks 11 to 12. Tabletop the audit. A one-day exercise with a mock auditor asking for each artefact against a chosen system. The gaps this exposes are the ones you fix before December.

What we are telling clients about long-term posture

Passing one audit is a milestone. Building an operating model that makes the next audit routine is the actual goal. That means moving AI Act obligations off a compliance function that is asked to inspect after the fact and into the engineering flow that produces the system in the first place. Documentation generated from code. Evaluation suites run in continuous integration. Incident logging identical for algorithmic harms and traditional outages. Data lineage that survives the departure of the engineer who trained the model.

The enterprises that get through 2026 audits with the least noise are not the ones with the biggest compliance teams. They are the ones whose engineering teams already treated most of these artefacts as basic hygiene.

If you are looking at a first audit in Q4 and the gaps above map to your reality, the highest-leverage move you can make this week is the two-person inventory pass. Everything else depends on it.