On August 2, 2026, the EU AI Act (Regulation (EU) 2024/1689) becomes generally applicable. If your AI system falls into a high-risk category — hiring, credit scoring, education, critical infrastructure, essential services, and more — a set of concrete, auditable obligations stops being "upcoming regulation" and becomes the law your system runs under.
Most teams are approaching this the way they approached GDPR in 2018: a compliance project, run by lawyers, producing documents. That approach fails for AI systems for one simple reason: your system changes faster than your paperwork. A conformity assessment of last quarter's model tells a regulator little about what you shipped this morning.
This is the problem conformity engineering exists to solve: treat regulatory conformity as a property of the system — designed in, enforced by pipelines, and continuously evidenced — rather than a report written about it after the fact. Reliability went through this transition and produced SRE. Security went through it and produced DevSecOps. Compliance is next.
What follows is the practical version: the core EU AI Act obligations for high-risk systems, mapped to the engineering practice that satisfies each one and the evidence artifact it should produce. Every item follows the same pattern: Article → Practice → Evidence.
First: know your dates
| Date | What applies |
|---|---|
| Feb 2, 2025 | Prohibited AI practices banned; AI literacy obligations |
| Aug 2, 2025 | Obligations for general-purpose AI (GPAI) models; governance bodies operational |
| Aug 2, 2026 | General applicability — including the high-risk obligations below (Annex III systems) |
| Aug 2, 2027 | High-risk AI embedded in regulated products (Annex I) |
Penalties scale to the violation: up to €35M or 7% of global annual turnover for prohibited practices, and up to €15M or 3% for non-compliance with most other obligations. These are GDPR-class numbers — which is exactly why boards are starting to ask engineering, not just legal, what the plan is.
The checklist: Article → Practice → Evidence
1. Classify your system honestly
Article 6 + Annex III
Everything downstream depends on whether your system is high-risk. Practice: make classification a versioned engineering decision, documented in the repo and re-evaluated on every significant feature change — a use case you add in Q3 can flip a minimal-risk system into a high-risk one. Evidence: a dated classification memo with the reasoning, in version control.
2. Run a living risk management system
Article 9
The Act requires risk management to be "continuous" and "iterative" across the lifecycle — that is a process requirement, not a document requirement. Practice: keep a risk register as code, reviewed at every release; block releases that introduce unmitigated known risks. Evidence: the register's change history, tied to release tags.
3. Govern your data like it will be audited
Article 10
Training, validation, and test data must meet quality criteria, and you must examine possible biases. Practice: dataset cards for every dataset, lineage tracking from source to model, and bias examinations that run as pipeline steps — not one-time studies. Evidence: dataset documentation and bias test reports generated per training run.
4. Generate technical documentation — don't write it
Article 11 + Annex IV
Annex IV documentation must exist before market placement and stay current. Hand-written docs are stale by definition. Practice: docs-as-code — generate the Annex IV package from the system itself (architecture, model versions, eval results) at build time. Evidence: a reproducible documentation build per release.
5. Log for the audit you haven't been asked for yet
Article 12
High-risk systems must automatically record events over their lifetime. Practice: design structured, append-only logging around auditability from day one: inputs, decisions, model version, overrides — with a retention policy. Evidence: the logs themselves, immutable and queryable.
6. Ship instructions, not assumptions
Article 13
Deployers must be able to interpret and use the system correctly. Practice: versioned system cards and instructions for use, shipped with every release like a changelog. Evidence: the instructions archive, one per version.
7. Make human oversight a feature, not a policy
Article 14
Effective oversight means a human can understand, intervene, and override. Practice: build approve/override/halt paths into the product surface — oversight that exists only in a policy PDF is not "effective." Evidence: oversight interaction logs proving humans actually use the controls.
8. Prove accuracy, robustness, and security per release
Article 15
These are measurable properties. Practice: eval suites with regression thresholds in CI, adversarial and red-team testing on a schedule, and standard cybersecurity hygiene extended to model-specific attacks (poisoning, prompt injection). Evidence: eval reports attached to every release.
9. Let your SDLC be your quality management system
Article 17
Providers need a QMS. Most engineering orgs already run 80% of one — code review, CI/CD, incident response — without naming it. Practice: codify your existing lifecycle, close the gaps, and let the pipeline enforce it. Evidence: process documentation plus the CI configuration that enforces it.
10. Treat conformity assessment as a release gate
Articles 43, 47–49
Before market placement: conformity assessment, EU declaration of conformity, CE marking, and registration in the EU database. Practice: model it as the final gate of your release process, fed by the evidence the previous nine items already generate — that's the payoff of engineering conformity instead of documenting it. Evidence: the signed declaration and registration record.
11. Monitor after launch like you mean it
Articles 72–73
Post-market monitoring is mandatory, and serious incidents must be reported — as fast as within 15 days, faster for the worst categories. Practice: wire production monitoring to an incident process with regulatory reporting as an explicit runbook step. Evidence: monitoring dashboards and incident records.
Where to start this week
- Classify (item 1). Half the anxiety disappears when you know which obligations actually apply to you.
- Gap-assess against the checklist. For each item: does the practice exist, and does it produce evidence automatically? Most teams find logging and evals are close, documentation and risk management are not.
- Pick the two worst gaps and engineer them — pipeline checks and generated artifacts, not documents. A generated Annex IV package is worth ten hand-written ones.
Get it when it ships — join the waitlist.
Join the waitlist
This article is an engineering guide, not legal advice. Obligations vary by role (provider vs. deployer), sector, and member-state implementation — validate your specific situation with qualified counsel.