Key Takeaways
- The Annex III high-risk obligations applied from 2 August 2026. An EU AI Act compliance guide written now is not about preparing — it is about producing the classification decisions and technical files you already owe.
- Classification is a documented decision, not a label. Rely on the Article 6(3) derogation and you must still document the assessment and register the system. The exemption creates paperwork.
- Most enterprises are both provider and deployer. Article 25 turns a deployer into a provider the moment you put your name on a system, substantially modify it, or repurpose one into a high-risk use.
- Annex IV documentation is mostly build output: architecture, data provenance, dated test logs and change records either fall out of engineering or they are assertions.
- Some evidence cannot be reconstructed. Logs, monitoring records and incident timelines exist only if you collected them at the time.
Legal has a spreadsheet with 340 AI use cases on it. Engineering has a platform team that ships weekly and has never heard of Annex IV. The board asked last month whether you are compliant, and the honest answer was that nobody could say — not because the answer is bad, but because the question was never decomposed into decisions with owners, evidence and dates.
Two artifacts carry most of the weight: a documented classification decision per AI system, and, where that system is high-risk, an Annex IV technical file kept current. Registration, conformity assessment, instructions for use and post-market monitoring all hang off those.
A practitioner’s reading, not legal advice.
Where an EU AI Act Compliance Guide Has to Start Now
The Annex III obligations applied on 2 August 2026 — earlier this month — and Annex I product safety components follow on 2 August 2027. Penalties reach 15 million euro or 3 percent of worldwide turnover for most obligations, with a separate 7.5 million or 1 percent tier for supplying incorrect or misleading information — the tier reconstructed documentation walks into. Article 15’s security requirements are covered separately in EU AI Act Article 15.
How Do You Run a High-Risk Classification Decision?
1. Fix the unit of analysis
Classify systems, not projects or models. A system is a deployed capability with an intended purpose; one model serving three purposes is three decisions.
2. Test against Annex III
Eight areas: biometrics; critical infrastructure; education; employment and worker management; access to essential private and public services, including creditworthiness and insurance pricing; law enforcement; migration and border control; and administration of justice. The two that surprise enterprises are employment — CV filtering, task allocation, performance monitoring — and creditworthiness. Both are usually internal systems nobody called a regulated product.
3. Apply the Article 6(3) filter honestly
An Annex III system falls outside high-risk if it poses no significant risk of harm, in one of four situations: a narrow procedural task, improving the result of a previously completed human activity, detecting decision patterns without replacing the human assessment, or a preparatory task. Profiling of natural persons is always high-risk. Invoke the derogation and you must still document the assessment before market and register the system.
4. Write the decision down
One page per system: intended purpose, Annex III area considered, facts relied on, conclusion, derogation reasoning if used, date, decision-maker. An undated conclusion is worth nothing.
Are You a Provider, a Deployer, or Both?
Most enterprises are both, and the roles carry different evidence:
Role trigger. Provider: you develop a system, or have one developed, and place it on the market under your own name. Deployer: you use one under your authority.
Documentation. Provider: the Annex IV file, drawn up before market and kept current. Deployer: the provider’s instructions for use, plus your own usage records.
Logs and oversight. Provider: support automatic logging across the lifetime and design so oversight is possible. Deployer: retain logs under your control for at least six months, and assign oversight to people with authority to override.
The swap. Article 25: put your name on a high-risk system, substantially modify it, or repurpose one — including a general-purpose model — into a high-risk use, and you become its provider.
How Do Enterprises Prove Compliance With EU AI Act Technical Documentation Requirements?
With a file assembled while the system was built. Annex IV lists nine headings; they resolve into four artifact types, only two of which can be written after the fact.
Description. Intended purpose, provider, versions, how the system interacts with hardware and software it is not part of, instructions for use, capabilities and limitations, expected accuracy for specific groups.
Build output. System architecture, design specifications, third-party tools and services used, computational resources, data provenance and labelling procedures, validation procedures, dated test logs.
Process. The Article 9 risk management system, the record of lifecycle changes, the Article 72 post-market monitoring plan.
Conformity. The harmonised standards applied or alternative solutions used, plus the EU declaration of conformity.
Description and process can be written. Build output cannot — it either falls out of how you built the system, or it is an assertion. Article 11 requires the file drawn up before market and kept up to date, meaning a change history; Article 18 requires ten-year retention.
The Evidence You Cannot Reconstruct
Logs. Annex IV asks for test logs dated and signed — a run this month describing March behaviour is not that. Article 12 separately requires automatic recording across the system’s lifetime, retained by deployers for at least six months.
Post-market monitoring. The Article 72 record starts the day the plan does; there is no backfill. Same for the classification memo — one written before deployment reads differently from one written after a regulator asks.
Incident timelines. Article 73 allows 15 days from awareness of a serious incident, 10 where a person has died, and 2 for widespread infringement or serious disruption of critical infrastructure. None are met retrospectively.
Dividing the Work Without Stalling Engineering
Legal owns role determination, the Annex III mapping, the derogation memo, contractual flow-down, and sign-off on the declaration of conformity.
Compliance owns the register, the mapping from Annex IV headings to internal artifacts, evidence freshness, registration filings, incident reporting, and the fundamental rights impact assessment where Article 27 applies.
Engineering owns exports, not prose: architecture and dependency descriptions from the build, data lineage from the pipeline, dated test logs from CI, Article 12 logging, and a change feed for model and dataset changes.
The failure mode is asking engineers to write documentation: it arrives late, from memory, in a text box. Ask for an export instead, and run classification as a standing queue with a five-day decision SLA so no release waits on it.
Where Cranium Fits
Classification is a legal decision; the technical file is an engineering artifact. The gap between them is where AI Act programs stall. The AI Trust Loop runs Discover, Observe, Govern, Secure, and Prove:
- Discover CodeSensor™ generates an AI Bill of Materials from your GitHub, GitLab, Bitbucket and Azure DevOps repositories — models, datasets, technologies with resolved versions, infrastructure, static system prompts — exportable as CycloneDX or SPDX. Much of what Annex IV asks you to describe.
- Observe Guardian records what each system did, per interaction — sessions, events, token and cost tracking, alerts to your SIEM. Contemporaneous, not reconstructed.
- Govern The AI System Manager holds each system’s owner, documentation and compliance status, with EU AI Act obligations attached, self-attestation, scoring and a Document Library.
- Secure Arena™ runs adversarial testing mapped to MITRE ATLAS and the OWASP Top Ten for LLMs, producing dated artifacts.
- Prove The Cranium AI Card™ is a living, exportable transparency report per system, mapped to the EU AI Act, NIST AI RMF and ISO 42001. My Vendors aggregates the AI Cards providers return; AI Trust Hubs share the record with regulators.
Cranium does not file your registration or sign your declaration of conformity; that stays with you and your counsel. What it does is make sure that when you sign, the file underneath is current and the dates are real.
Frequently Asked Questions
We missed 2 August 2026. What comes first?
Classification across the whole estate, at speed — you cannot triage what you have not scoped. Then a dated remediation plan with named owners — better than a gap an authority finds.
Is an internal tool used only on employees in scope?
It can be. Employment and worker management is an Annex III area, and CV filtering, task allocation and performance monitoring sit inside it.
Our provider says they are compliant. Is that enough?
No. You need their instructions for use, the documentation supporting your obligations, and your own logs and oversight records — the dependency in Applying NIST’s AI RMF to Third-Party AI.
Do we need a notified body?
For most Annex III systems, conformity assessment runs through internal control; certain biometric systems can require the notified body route. Confirm with counsel.
See Cranium in Action
See EU AI Act obligations, evidence and AI Cards maintained per system—schedule a personalized demo: cranium.ai/get-a-demo/
