The Conformity Engineering Playbook: Preparing Your AI System for August 2, 2026
On August 2, 2026 , the EU AI Act (Regulation (EU) 2024/1689) becomes generally<br>applicable. If your AI system falls into a high-risk category — hiring, credit scoring, education,<br>critical infrastructure, essential services, and more — a set of concrete, auditable obligations<br>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,<br>run by lawyers, producing documents. That approach fails for AI systems for one simple reason:<br>your system changes faster than your paperwork. A conformity assessment of last<br>quarter's model tells a regulator little about what you shipped this morning.
This is the problem conformity engineering exists to solve: treat regulatory<br>conformity as a property of the system — designed in, enforced by pipelines, and<br>continuously evidenced — rather than a report written about it after the fact. Reliability went<br>through this transition and produced SRE. Security went through it and produced DevSecOps.<br>Compliance is next.
What follows is the practical version: the core EU AI Act obligations for high-risk systems,<br>mapped to the engineering practice that satisfies each one and the evidence artifact it should<br>produce. Every item follows the same pattern: Article → Practice → Evidence.
First: know your dates
DateWhat applies<br>Feb 2, 2025Prohibited AI practices banned; AI literacy obligations<br>Aug 2, 2025Obligations for general-purpose AI (GPAI) models; governance bodies operational<br>Aug 2, 2026 General applicability — including the high-risk obligations below (Annex III systems)<br>Aug 2, 2027High-risk AI embedded in regulated products (Annex I)
Penalties scale to the violation: up to €35M or 7% of global annual turnover for prohibited<br>practices, and up to €15M or 3% for non-compliance with most other obligations. These are<br>GDPR-class numbers — which is exactly why boards are starting to ask engineering, not just legal,<br>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<br>classification a versioned engineering decision, documented in the repo and re-evaluated on<br>every significant feature change — a use case you add in Q3 can flip a minimal-risk system<br>into a high-risk one. Evidence: a dated classification memo with the reasoning, in<br>version control.
2. Run a living risk management system
Article 9
The Act requires risk management to be "continuous" and "iterative" across the lifecycle —<br>that is a process requirement, not a document requirement. Practice: keep a risk<br>register as code, reviewed at every release; block releases that introduce unmitigated<br>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<br>possible biases. Practice: dataset cards for every dataset, lineage tracking from<br>source to model, and bias examinations that run as pipeline steps — not one-time studies.<br>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<br>docs are stale by definition. Practice: docs-as-code — generate the Annex IV package<br>from the system itself (architecture, model versions, eval results) at build time.<br>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:<br>design structured, append-only logging around auditability from day one: inputs,<br>decisions, model version, overrides — with a retention policy. Evidence: the logs<br>themselves, immutable and queryable.
6. Ship instructions, not assumptions
Article 13
Deployers must be able to interpret and use the system correctly. Practice:<br>versioned system cards and instructions for use, shipped with every release like a<br>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:<br>build approve/override/halt paths into the product surface — oversight that exists only in a<br>policy PDF is not "effective." Evidence: oversight interaction logs proving humans<br>actually use the controls.
8. Prove accuracy, robustness, and security per release
Article 15
These are measurable properties. Practice: eval suites with regression thresholds<br>in CI, adversarial and red-team testing on a schedule, and standard cybersecurity hygiene<br>extended to model-specific attacks (poisoning, prompt...