AI Compliance Evidence File: What EU Regulators Actually Want

# The document bundle that decides your fine

When an EU market surveillance authority knocks on your door under the AI Act, they are not asking for a PowerPoint about your AI strategy. They want a specific bundle of documents proving that your high-risk AI system was assessed, monitored, and controlled before it went live. That bundle is your AI compliance evidence file, and without it, fines under Article 99 can reach €15 million or 3% of global annual turnover for a provider, whichever is higher.

The good news: building this file is not a six-month legal project. A focused team at a 50-person company can do it in four to six weeks if they know what regulators are actually looking for.

# What regulators check first

Market surveillance authorities work from a checklist. They want to see that you followed the obligations in Articles 9 through 17 of the AI Act, which cover risk management, data governance, technical documentation, logging, transparency, human oversight, accuracy, and quality management. Those eight areas map almost perfectly onto the six documents described below.

Authorities also check dates. A document created the week before an audit is a red flag. Each item in your evidence file needs a version history showing it was created and reviewed during normal operations, not assembled in a panic.

# The six documents in a defensible evidence file

1. Risk management record

This is your written proof that you ran a systematic process to identify, estimate, and evaluate risks before deployment. Article 9 requires this to be a continuous process, not a one-off exercise. At minimum, the record should list every identified risk, the likelihood and severity of each, the mitigation measure applied, and the residual risk accepted. Two to three pages is fine. Fifty pages of boilerplate is not.

2. Technical documentation

Annex IV specifies exactly what technical documentation must contain: the system's intended purpose, the architecture, training data sources, validation results, and known limitations. If you are a deployer buying a third-party AI tool rather than building your own, you still need to hold vendor-supplied documentation and verify it covers Annex IV requirements. Ask your vendor for this on day one.

3. Data governance log

Under Article 10, training and validation data must meet specific quality criteria. Your data governance log records where data came from, what checks were applied, what biases were identified, and how they were addressed. For deployers using a vendor's pre-trained model, this section documents the data you feed into the system at runtime, such as employee performance scores or CV data in an HR context.

4. Automatic logging records

Article 12 requires high-risk AI systems to generate logs automatically. Your evidence file should include a sample of these logs alongside your policy for how long logs are retained and who can access them. The minimum retention period for logs in high-risk systems is set at the period of the system's lifetime or, at a minimum, six months, depending on applicable sectoral law. Check which rule is stricter for your sector.

5. Human oversight protocol

This is the document most SMEs skip and regulators notice immediately. Article 14 requires that natural persons are able to understand, monitor, and override AI outputs. Your protocol should name the specific role responsible for oversight, describe how that person receives AI outputs, and document what override options exist. A one-page Standard Operating Procedure signed by a named manager is sufficient.

6. Conformity assessment report

For most high-risk AI categories listed in Annex III, a self-assessment conformity procedure is permitted rather than third-party audit. The report documents your conclusion that the system meets the requirements and the evidence that supports it. It must be signed, dated, and accompanied by your EU declaration of conformity before any high-risk system goes into service.

# Physical versus digital, and how long to keep it

The AI Act does not mandate a specific format, physical or digital. What it does mandate is availability. Under Article 18, technical documentation must be kept for ten years after the high-risk AI system is placed on the market or put into service. Ten years is longer than most companies keep HR records.

A shared digital folder with access controls works perfectly. What does not work is documentation scattered across personal email inboxes, outdated SharePoint sites with broken permissions, or a single person's laptop. Use a folder structure that mirrors the six documents above. Name files with ISO 8601 dates (YYYY-MM-DD) so version history is immediately visible to any auditor.

Back up quarterly. Label each version clearly. Archive rather than delete old versions.

# Who owns the file

Ownership should sit with one named role, not a committee. In practice, the right owner depends on your structure.

If you have a compliance officer, this is their file. Full stop. If you do not, the COO or a senior operations manager is the natural owner because they control processes rather than technology. The CISO or CTO can own the technical documentation section specifically, but someone outside IT must own the whole file. Regulators are skeptical when technical teams self-certify without business-side oversight.

The owner's responsibilities are concrete: ensure all six documents exist, schedule reviews, keep the version log, and be the named contact if an authority asks for the file. Write that into a job description or a formal mandate document, and put that mandate document inside the file itself.

# How often to refresh

The risk management record and human oversight protocol should be reviewed every time the AI system changes significantly, and at least once every twelve months regardless. What counts as a significant change? A new training dataset, a new use case, a new integration with another system, or a change in the user population.

The technical documentation and data governance log should be updated whenever the underlying system or your data inputs change. Even if you are a deployer with a static vendor tool, your runtime data changes constantly. Review the log at least every six months.

The conformity assessment report needs to be re-run after any significant change. Many companies treat it as a one-time task. That is wrong. If you changed the system, you changed the basis of the conformity conclusion.

Set calendar reminders. Assign them to a named person. Document the outcome of each review, even if the outcome is "no changes required."

# The August 2026 deadline is real

The high-risk AI obligations under the AI Act apply from 2 August 2026 for most Annex III systems. That gives a company starting today roughly twelve months. Building a complete, defensible evidence file from scratch takes four to six weeks of focused work. Add time for vendor documentation requests, internal sign-off, and a dry-run self-audit, and twelve months is comfortable but not generous.

Companies that start in Q1 2026 will be scrambling. Companies that start now will have a reviewed, version-controlled file sitting ready.

# The one action to take this week

Print or copy the six headings above and check which documents you already have in any form. Most companies have fragments: a vendor data sheet, an IT risk log, a vague policy document. The gap analysis takes one hour. Once you know your gaps, you can sequence the work.

If you want a structured gap analysis with a clear output report, Khairos AI Comply offers a free 2-minute compliance check that maps your current situation against the six document requirements and tells you exactly where to start.