{"slug": "eu-ai-act-becomes-applicable-aug-2-an-engineering-checklist", "title": "EU AI Act becomes applicable Aug 2: an engineering checklist", "summary": "The EU AI Act becomes generally applicable on August 2, 2026, imposing concrete obligations on high-risk AI systems in areas like hiring, credit scoring, and critical infrastructure. An engineering checklist maps each legal requirement to specific practices and evidence artifacts, treating compliance as a continuous system property rather than a one-time paperwork exercise. Penalties reach up to €35 million or 7% of global annual turnover for violations.", "body_md": "On **August 2, 2026**, the EU AI Act (Regulation (EU) 2024/1689) becomes generally\napplicable. If your AI system falls into a high-risk category — hiring, credit scoring, education,\ncritical infrastructure, essential services, and more — a set of concrete, auditable obligations\nstops being \"upcoming regulation\" and becomes the law your system runs under.\n\nMost teams are approaching this the way they approached GDPR in 2018: a compliance project,\nrun by lawyers, producing documents. That approach fails for AI systems for one simple reason:\n**your system changes faster than your paperwork.** A conformity assessment of last\nquarter's model tells a regulator little about what you shipped this morning.\n\nThis is the problem [conformity engineering](/) exists to solve: treat regulatory\nconformity as a *property of the system* — designed in, enforced by pipelines, and\ncontinuously evidenced — rather than a report written about it after the fact. Reliability went\nthrough this transition and produced SRE. Security went through it and produced DevSecOps.\nCompliance is next.\n\nWhat follows is the practical version: the core EU AI Act obligations for high-risk systems,\nmapped to the engineering practice that satisfies each one and the evidence artifact it should\nproduce. Every item follows the same pattern: **Article → Practice → Evidence.**\n\n## First: know your dates\n\n| Date | What applies |\n|---|---|\n| Feb 2, 2025 | Prohibited AI practices banned; AI literacy obligations |\n| Aug 2, 2025 | Obligations for general-purpose AI (GPAI) models; governance bodies operational |\nAug 2, 2026 | General applicability — including the high-risk obligations below (Annex III systems) |\n| Aug 2, 2027 | High-risk AI embedded in regulated products (Annex I) |\n\nPenalties 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.\n\n## The checklist: Article → Practice → Evidence\n\n### 1. Classify your system honestly\n\nArticle 6 + Annex III\n\nEverything downstream depends on whether your system is high-risk. **Practice:** make\nclassification a versioned engineering decision, documented in the repo and re-evaluated on\nevery significant feature change — a use case you add in Q3 can flip a minimal-risk system\ninto a high-risk one. **Evidence:** a dated classification memo with the reasoning, in\nversion control.\n\n### 2. Run a living risk management system\n\nArticle 9\n\nThe Act requires risk management to be \"continuous\" and \"iterative\" across the lifecycle —\nthat is a process requirement, not a document requirement. **Practice:** keep a risk\nregister as code, reviewed at every release; block releases that introduce unmitigated\nknown risks. **Evidence:** the register's change history, tied to release tags.\n\n### 3. Govern your data like it will be audited\n\nArticle 10\n\nTraining, validation, and test data must meet quality criteria, and you must examine\npossible biases. **Practice:** dataset cards for every dataset, lineage tracking from\nsource to model, and bias examinations that run as pipeline steps — not one-time studies.\n**Evidence:** dataset documentation and bias test reports generated per training run.\n\n### 4. Generate technical documentation — don't write it\n\nArticle 11 + Annex IV\n\nAnnex IV documentation must exist before market placement and stay current. Hand-written\ndocs are stale by definition. **Practice:** docs-as-code — generate the Annex IV package\nfrom the system itself (architecture, model versions, eval results) at build time.\n**Evidence:** a reproducible documentation build per release.\n\n### 5. Log for the audit you haven't been asked for yet\n\nArticle 12\n\nHigh-risk systems must automatically record events over their lifetime. **Practice:**\ndesign structured, append-only logging around auditability from day one: inputs,\ndecisions, model version, overrides — with a retention policy. **Evidence:** the logs\nthemselves, immutable and queryable.\n\n### 6. Ship instructions, not assumptions\n\nArticle 13\n\nDeployers must be able to interpret and use the system correctly. **Practice:**\nversioned system cards and instructions for use, shipped with every release like a\nchangelog. **Evidence:** the instructions archive, one per version.\n\n### 7. Make human oversight a feature, not a policy\n\nArticle 14\n\nEffective oversight means a human can understand, intervene, and override. **Practice:**\nbuild approve/override/halt paths into the product surface — oversight that exists only in a\npolicy PDF is not \"effective.\" **Evidence:** oversight interaction logs proving humans\nactually use the controls.\n\n### 8. Prove accuracy, robustness, and security per release\n\nArticle 15\n\nThese are measurable properties. **Practice:** eval suites with regression thresholds\nin CI, adversarial and red-team testing on a schedule, and standard cybersecurity hygiene\nextended to model-specific attacks (poisoning, prompt injection). **Evidence:** eval\nreports attached to every release.\n\n### 9. Let your SDLC be your quality management system\n\nArticle 17\n\nProviders need a QMS. Most engineering orgs already run 80% of one — code review, CI/CD,\nincident response — without naming it. **Practice:** codify your existing lifecycle,\nclose the gaps, and let the pipeline enforce it. **Evidence:** process documentation plus\nthe CI configuration that enforces it.\n\n### 10. Treat conformity assessment as a release gate\n\nArticles 43, 47–49\n\nBefore market placement: conformity assessment, EU declaration of conformity, CE marking,\nand registration in the EU database. **Practice:** model it as the final gate of your\nrelease process, fed by the evidence the previous nine items already generate — that's the\npayoff of engineering conformity instead of documenting it. **Evidence:** the signed\ndeclaration and registration record.\n\n### 11. Monitor after launch like you mean it\n\nArticles 72–73\n\nPost-market monitoring is mandatory, and serious incidents must be reported — as fast as\nwithin 15 days, faster for the worst categories. **Practice:** wire production monitoring\nto an incident process with regulatory reporting as an explicit runbook step.\n**Evidence:** monitoring dashboards and incident records.\n\n## Where to start this week\n\n**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.\n\n*produce their own conformity evidence*as a side effect of running. That is the whole discipline in one sentence.\n\n**The full conformity engineering guide is in progress.**\n\nGet it when it ships — join the waitlist.\n\n[Join the waitlist](/#waitlist)\n\nThis 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.", "url": "https://wpnews.pro/news/eu-ai-act-becomes-applicable-aug-2-an-engineering-checklist", "canonical_source": "https://conformityengineering.com/playbook/", "published_at": "2026-07-07 22:39:17+00:00", "updated_at": "2026-07-07 22:59:33.906425+00:00", "lang": "en", "topics": ["ai-policy", "ai-safety", "ai-ethics", "machine-learning", "developer-tools"], "entities": ["EU AI Act", "Regulation (EU) 2024/1689", "GDPR", "Annex III", "Annex IV"], "alternates": {"html": "https://wpnews.pro/news/eu-ai-act-becomes-applicable-aug-2-an-engineering-checklist", "markdown": "https://wpnews.pro/news/eu-ai-act-becomes-applicable-aug-2-an-engineering-checklist.md", "text": "https://wpnews.pro/news/eu-ai-act-becomes-applicable-aug-2-an-engineering-checklist.txt", "jsonld": "https://wpnews.pro/news/eu-ai-act-becomes-applicable-aug-2-an-engineering-checklist.jsonld"}}