Definitions

Definitions

The gate

Results

1. Tier decides the work: minimal needs two items, high needs eight plus a sign-off.
2. Prohibited is not fixable with paperwork.
3. Missing evidence is named, so a failure is a to-do list.
4. Dates are data: keep them in config and review them.

Design rules

• Classify at design time, and again when the domain, users or features change.
• Keep an evidence manifest per system: model card, risk assessment, evals, decision logs, oversight design, retention, sign-offs.
• Gate releases in CI, failing closed, with named reasons.
• Re-check on drift (tier, domain, removed evidence, new model version).
• Track law dates and status centrally, with an owner and a review cadence; cite primary sources.
• Minimise personal data and honour deletion (module 6) so GDPR duties are tractable.
• Disclose AI interaction and mark synthetic media where required.
• Involve counsel early for classification, contracts and incident reporting; do not self-certify.
• Map to a framework (NIST AI RMF, ISO 42001) to organise the work.
• Log and escalate (module 9): regulators ask for evidence of oversight.

Interview questions, with the follow-ups

Common mistakes

• Treating compliance as a final-week task.
• Self-classifying risk without legal review.
• Hard-coding dates from a blog post.
• Assuming "no EU users" or "no AI law" means nothing applies (GDPR, sector and state rules).
• Paperwork that does not match behaviour: a model card nobody maintains.
• No drift checks after the system gains a new domain or tool.
• Believing a passing gate means legal compliance.

What the example does not do

• No legal analysis: tier rules, obligation lists and the "prohibited" set are simplified; real definitions have exceptions and conditions.
• Evidence is a boolean, not a reviewed document.
• Sources are secondary (blogs), read on one day; I did not read the Official Journal text, and omnibus details may differ.
• GDPR, US and sector rules appear only as notes; the code covers the AI Act-style tiers.
• No conformity assessment, registration, incident reporting or contract analysis.
• Optional real experiment (I did not run this): take one real system, have counsel classify it, and compare their obligation list with the one required() generates; fix the gap in the code.

For the curious Engineering orientation, not legal advice

The example classifies 10 invented systems and 4 of 10 pass the gate; the failures name what is missing (disclosure, human oversight, two-person sign-off, a prohibited practice). The tiers and obligations are my simplification. Laws and dates were read on 31 October 2026 from secondary sources, not the Official Journal, and counsel decides the real classification.

What you must be able to say (one page)

• This is engineering orientation, not legal advice. Classification, deadlines and liability are decisions for counsel. What an engineer owns is making the system evidenced: documented, logged, overseeable and gated. Laws and dates below were read on 2026-10-31 from secondary sources (law-firm and compliance blogs, not the Official Journal text), so verify before relying on any of them.
• The EU AI Act is risk-based. It categorises systems into levels of risk (minimal, high, unacceptable) with obligations for transparency, accountability and human oversight. Simplified: prohibited (cannot be placed on the market), high-risk (listed domains such as employment, credit, education, biometrics, critical infrastructure: risk management, logging, human oversight, documentation), limited risk (transparency: tell people they are talking to AI, mark synthetic media), minimal (little beyond good practice).
• Dates moved, so keep them in config, not in your head. From the sources I read: the Digital AI Omnibus was reported adopted in mid 2026 and in force on 27 July 2026; Annex III high-risk obligations moved from 2 August 2026 to 2 December 2027; Annex I (AI in regulated products) to 2 August 2028; generative-AI marking for systems already on the market gets a grace period to 2 December 2026; a new prohibition on systems generating non-consensual intimate imagery or child sexual abuse material applies from 2 December 2026. Prohibitions (2 February 2025) and general-purpose model obligations (2 August 2025) are earlier, from my general knowledge. The obligations themselves did not change, only the dates. Treat all of it as "check at review time".
• GDPR is already in force and applies to agents that touch personal data: lawful basis, minimisation, purpose limitation, retention, data-subject rights including erasure (module 6), and restrictions on solely automated decisions with significant effects (Article 22, from my general knowledge).
• US: a patchwork, no federal law. From the sources I read: Colorado's original AI Act never took effect and was repealed and replaced by a narrower automated-decision law (SB 26-189, signed 14 May 2026) effective 1 January 2027; California's SB 53 (frontier AI transparency and incident reporting) took effect 1 January 2026; federal preemption of state laws had not been enacted as of mid 2026. State law changes fast.
• Industry rules stack on top: PCI DSS for payments, SOX for financial reporting, plus sector rules (health, finance). They constrain agent data access and behaviour even if no AI law applies.
• What engineers do about it: classify each system early; derive obligations from the tier; keep evidence (model card, risk assessment, eval report, decision logs, human-oversight design, retention policy, sign-offs) in a manifest; put the checks in CI as a gate that fails closed; re-run on drift.
• My example classifies 10 invented systems and gates them: 4 of 10 pass; failures are named (missing disclosure, missing human oversight, missing two-person sign-off, prohibited practice). 16 tests. The tiers and obligation lists are my simplification, not the law.