Lesson 2 of 7 · 9 min read
The EU AI Act for Engineers
In this lesson
TL;DR: The EU AI Act (Regulation (EU) 2024/1689, in force since 1 August 2024) sorts AI by risk. Prohibited practices (for example manipulative techniques causing significant harm, social scoring, untargeted scraping of facial images) apply since 2 February 2025. High-risk systems (listed uses such as employment, credit scoring, education, essential services, law enforcement, and safety components of regulated products) must meet requirements including risk management, data governance, technical documentation, logging, human oversight, and accuracy, robustness and cybersecurity. Transparency duties cover chatbots and synthetic content. General-purpose AI model providers have obligations from 2 August 2025, with extra duties for models with systemic risk. The Digital Omnibus (Regulation (EU) 2026/1744, in force 27 July 2026) moved Annex III high-risk obligations to 2 December 2027 and Annex I ones to 2 August 2028 (checked November 2026).
Before you read
Pick an answer before you read further. The lesson below explains it, and guessing first, right or wrong, helps the explanation stay with you.
1A US company with no EU office sells a CV-screening tool to employers in France. Does the EU AI Act apply to it?
The structure: risk tiers
GPAI model duties
For model providers
Your AI system
What is it used for?
Prohibited
Banned practices
Controls
High-risk
- Annex III uses or Annex I products
Also in the picture
Transparency duties
- Chatbots, synthetic content
Minimal risk
- No specific obligations
Classify by use, not by technology
The same model can be minimal-risk in a spell checker and high-risk in a hiring tool. The intended purpose decides the tier.
| Tier | Examples | Core consequence |
|---|---|---|
| Prohibited (Article 5) | Manipulation causing significant harm, exploiting vulnerabilities, social scoring, untargeted facial-image scraping, emotion recognition at work or school (with exceptions); the Digital Omnibus added AI generating non-consensual intimate material or child sexual abuse material | Banned |
| High-risk (Article 6, Annexes I and III) | Safety components of regulated products; listed uses in biometrics, critical infrastructure, education, employment, essential services and credit, law enforcement, migration, justice | Full requirements and conformity assessment |
| Transparency (Article 50) | Chatbots, emotion recognition, deepfakes and other synthetic content | Disclose AI interaction; mark synthetic content |
| Minimal | Most other uses | Voluntary codes; AI literacy measures |
Is an Annex III system really high-risk? The Article 6(3) filter
Being in an Annex III area is not the end of the analysis. Under Article 6(3), a system listed there is not high-risk if it does not materially influence the outcome of decisions and it meets one of four conditions: it performs a narrow procedural task; it improves the result of a human activity already completed; it detects decision-making patterns or deviations without replacing or influencing the human assessment; or it performs a preparatory task. Two rules cut the other way: a system that profiles natural persons is always high-risk, and a provider that relies on the filter must document its assessment and still register the system. The Commission's draft guidelines on high-risk classification (published May 2026, still in draft in November 2026) add that human involvement alone does not take a system out of the high-risk category: what matters is whether the system materially influences the decision.
Roles
Obligations depend on your role. The provider develops or has a system developed and places it on the market under its name, and carries most obligations. The deployer uses a system under its authority in a professional context and has duties such as human oversight, monitoring, logging retention and, for some deployers, fundamental rights impact assessments. Importers, distributors and authorised representatives have their own duties. Substantially modifying a high-risk system, or putting your name on it, can make you a provider.
High-risk requirements, in engineering terms
| Requirement (Articles 9 to 15) | What engineers build |
|---|---|
| Risk management system | Lifecycle risk process: threat models, evaluations, mitigations, residual risk decisions |
| Data and data governance | Documented, relevant, representative training, validation and test data; bias examination |
| Technical documentation | System description, design, data, evaluation and monitoring documentation |
| Record-keeping | Automatic logging of events over the system's lifetime |
| Transparency to deployers | Instructions for use, capabilities and limitations |
| Human oversight | Interfaces and processes that let people understand, monitor, override and stop the system |
| Accuracy, robustness and cybersecurity | Declared accuracy metrics; resilience to errors; protection against attacks specific to AI, such as data poisoning, model poisoning, adversarial examples and confidentiality attacks |
Article 15's cybersecurity clause is where AI security engineering meets the law directly: it names AI-specific attacks that providers of high-risk systems must address.
Three articles engineers end up implementing
Article 9, risk management, requires a continuous, iterative process covering known and reasonably foreseeable risks, including from reasonably foreseeable misuse, with residual risk judged acceptable. Its testing clause is the one security engineers notice: high-risk systems must be tested against "prior defined metrics and probabilistic thresholds" before they are placed on the market. That is a direct invitation to the statistics in the attack success rate lesson: declare the metric and the sample size in advance, for example "the upper 95% confidence bound of the prompt-injection hijack rate is below 1% over at least 300 trials", and gate release on it.
Article 26, deployer obligations. A company using a high-risk system must use it according to the provider's instructions, assign human oversight to people with the competence and authority to exercise it, ensure input data it controls is relevant and sufficiently representative, monitor operation and, on a serious incident, inform the provider first; keep the logs the system generates under its control for at least six months; inform workers' representatives before using such a system at work; and use the provider's information to carry out its data protection impact assessment under GDPR.
Article 27, fundamental rights impact assessment (FRIA). Not every deployer needs one. It applies before first use of an Annex III high-risk system (except critical infrastructure) by bodies governed by public law, private entities providing public services, and deployers of systems for creditworthiness assessment or for risk assessment and pricing in life and health insurance. A FRIA can build on an existing DPIA.
Article 73, serious incidents. Providers report serious incidents to the market surveillance authority within 15 days of becoming aware, within 10 days where the incident may have caused a death, and within 2 days for a widespread infringement or a serious disruption of critical infrastructure. The Digital Omnibus routes reports from providers under the AI Office's exclusive competence to the AI Office. The Commission's draft reporting guidance and template date from September 2025.
Standards: what gives presumption of conformity
Conformity with a harmonised standard whose reference is published in the Official Journal gives a presumption of conformity with the requirements it covers. The first, EN 18286:2026 ("Artificial intelligence: Quality management system for EU AI Act regulatory purposes"), was cited in October 2026 and covers the Article 17 quality management system only. No harmonised standard yet covers Article 9 risk management or Article 15 accuracy, robustness and cybersecurity (checked November 2026). Two other standards help without giving presumption: ISO/IEC 42001, a certifiable AI management system, and ISO/IEC 27090:2026, guidance on security threats to AI systems such as poisoning, prompt injection and model theft, mapped to assets and life-cycle stages.
General-purpose AI models
Providers of general-purpose AI models must maintain technical documentation, give downstream providers information to meet their own obligations, put in place a policy to comply with EU copyright law, and publish a summary of training content. Models with systemic risk (presumed when training compute exceeds 10^25 floating-point operations, or designated by the Commission) must also evaluate and mitigate systemic risks, including adversarial testing, track and report serious incidents, and ensure adequate cybersecurity. These obligations have applied since 2 August 2025, with a transition to 2 August 2027 for models placed on the market before then. A General-Purpose AI Code of Practice, published in July 2025, offers one way to demonstrate compliance.
Timeline (checked November 2026)
| Date | What applies |
|---|---|
| 1 August 2024 | Act enters into force |
| 2 February 2025 | Prohibitions; AI literacy |
| 2 August 2025 | General-purpose AI model obligations; governance and penalties provisions |
| 2 August 2026 | General date of application, including Article 50 transparency duties, except where deferred |
| 2 December 2026 | Digital Omnibus additions: new prohibitions; Article 50(2) marking for systems already on the market |
| 2 December 2027 | Annex III high-risk obligations (moved from 2 August 2026 by the Digital Omnibus) |
| 2 August 2028 | Annex I high-risk obligations (moved from 2 August 2027) |
Penalties scale with the violation: up to EUR 35 million or 7 percent of worldwide annual turnover for prohibited practices, with lower tiers for other breaches. Dates and details have already changed once; check the current consolidated text before relying on them.
Worked example: classifying a CV-ranking tool
A software company sells a tool that ranks job applicants' CVs to an EU bank's HR team.
- Annex III? Yes: employment, including recruitment and selection, is listed (point 4).
- Article 6(3) filter? It fails: ranking materially influences who is shortlisted, and it profiles candidates. The tool is high-risk.
- Provider duties (the software company): Articles 9 to 15 (risk management, data governance, documentation, logging, transparency, human oversight, accuracy and cybersecurity) and an Article 17 quality management system, for which EN 18286 offers presumption of conformity. Annex III obligations apply from 2 December 2027 after the Digital Omnibus.
- Deployer duties (the bank): use it per the instructions, assign competent oversight, keep its logs for at least six months, inform workers' representatives, and feed the provider's information into its DPIA. No FRIA for this tool, because the bank is not a public body or public-service provider and this is not credit scoring or insurance pricing; the bank's separate credit-scoring model would need one.
- Exposure: breaches of high-risk obligations fall in the tier of up to EUR 15 million or 3% of worldwide annual turnover.
Prohibited?
Article 5 list
Annex I or III use?
employment, credit and more
Article 6(3) filter
material influence, profiling
Provider or deployer?
duties differ
Obligations and dates
Articles 9 to 27
The CV-ranking tool
Employment is Annex III point 4
- Recruitment and selection
Ranking shapes shortlists
- Profiles candidates: always high-risk
Bank keeps logs 6 months
- No FRIA for this tool
Rule out prohibition, then find the use
Classification follows intended use, not technology.
Misconceptions interviewers listen for
- "A human in the loop makes it not high-risk." Material influence decides, and profiling is always high-risk.
- "Every deployer of high-risk AI must do a FRIA." Only public bodies, public-service providers and credit or insurance-pricing deployers.
- "Harmonised standards now cover the whole Act." Only EN 18286, for the quality management system, as of November 2026.
- "The Omnibus delayed everything." Prohibitions (February 2025), GPAI obligations (August 2025) and most transparency duties kept their dates; the Annex III and Annex I high-risk dates moved.
- "Signing the GPAI Code of Practice is mandatory." It is voluntary; providers that do not sign must show compliance by other adequate means. In October 2026 the Commission listed 22 full signatories, with one company signing only the safety and security chapter.
What if · interview follow-ups
Hold your answer as the constraints change
You are the security and compliance engineer for a company that builds an AI recruiting assistant sold to EU employers. The interviewer asks how the AI Act shapes your engineering work.
Start here
What if the product team says a recruiter reviews every recommendation, so the system is not high-risk?
What does Article 6(3) actually test?
Human review alone does not remove a system from high-risk; the question is whether it materially influences the outcome, and a system that profiles candidates is always high-risk. Ranking or filtering applicants influences who is considered, so document the assessment and plan for high-risk obligations.
Carry it forwardClassification turns on material influence and profiling, not on whether a human signs off.
Weak answerRelying on human-in-the-loop to escape the high-risk regime.
Constraint changes
What if Article 9's 'prior defined metrics and probabilistic thresholds' apply to your prompt-injection testing?
What would a defensible release gate look like?
Declare the metric, attack set, sample size and threshold before testing, for example that the upper 95% confidence bound on the hijack rate stays below a set percentage over at least a few hundred adaptive trials, and gate release on it. Record the results and re-run them on every model or prompt change, as part of the risk-management file.
Carry it forwardRegulatory testing language maps directly onto pre-registered security evaluations with confidence bounds.
Weak answerReporting a single pass rate from an ad hoc test.
Constraint changes
What if a customer reports that your system contributed to a serious incident?
Who reports, to whom, and how fast?
The deployer informs you as provider first; you report to the market surveillance authority within 15 days of becoming aware, within 10 days if a death may have resulted, and within 2 days for widespread infringements or critical-infrastructure disruption. Prepare the template, the evidence pipeline from your logs and the decision owner in advance.
Carry it forwardIncident reporting has fixed clocks; build the evidence path before you need it.
Weak answerTreating it as an ordinary support ticket.
Constraint changes
What if a customer fine-tunes your model and sells it under its own brand for hiring?
Who becomes the provider?
A company that puts its name on a high-risk system or substantially modifies it can become its provider under Article 25, taking on the provider obligations for that system. Your contracts and documentation should make the allocation explicit and give them the information they need, because downstream providers depend on it.
Carry it forwardRoles follow who places the system on the market and under whose name, not who trained the base model.
Weak answerAssuming the original developer keeps every obligation.
Constraint changes
What if leadership asks whether ISO/IEC 42001 certification makes you compliant?
Which standard is harmonised, and for what?
No. Certification to 42001 shows a working AI management system and is good evidence, but it is not harmonised and gives no presumption of conformity. EN 18286 gives presumption for the quality management system only; risk management and cybersecurity still need their own evidence, for which ISO/IEC 27090 is useful guidance.
Carry it forwardMap each Act requirement to the evidence that satisfies it; no single certificate covers all of them.
Weak answerTreating a management-system certificate as regulatory compliance.
Now defend it
As the defender, what evidence would you keep ready for a regulator or a customer audit?
The classification assessment with its Article 6(3) reasoning, the risk-management file with pre-declared metrics and test results per release, technical documentation and logs retained for the required periods, human-oversight procedures, incident reports with timelines, and the mapping of each requirement to standards and internal controls.
How this shows up in interviews
Expect "what are the risk tiers and what must a high-risk provider do?", "does it apply to us with no EU office?", and "what triggers the systemic-risk regime for GPAI?" Strong answers classify by intended use and role, translate requirements into engineering artefacts, highlight Article 15's cybersecurity duties, and give dates with the caveat that the Digital Omnibus moved them.
Say it in 30 seconds: "The AI Act is risk-tiered by use: banned practices since February 2025; high-risk uses like hiring, credit, education and product safety components needing risk management, data governance, documentation, logging, human oversight and accuracy, robustness and cybersecurity, now from December 2027 or August 2028 after the 2026 Digital Omnibus; transparency for chatbots and synthetic content; and GPAI model duties since August 2025, more above 10^25 FLOPs. It reaches non-EU providers whose systems are used in the EU, and obligations depend on whether you're provider or deployer."
Check yourself
Say or write your answer first, then reveal. Explaining it from memory, in your own words, is the skill an interviewer is checking.
1Your company builds an internal chatbot on a third-party model to answer employees' HR policy questions. What is its likely tier, and what duties might still apply?
2Which parts of Article 15 does an AI security engineer most directly own?
3When is an Annex III system not high-risk under Article 6(3)?
4How long must deployers keep the logs a high-risk system generates?