# EU AI Act becomes applicable Aug 2: an engineering checklist > Source: > Published: 2026-07-07 22:39:17+00:00 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. *produce their own conformity evidence*as a side effect of running. That is the whole discipline in one sentence. **The full conformity engineering guide is in progress.** Get it when it ships — join the waitlist. [Join the waitlist](/#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.