EU AI Act Articles 9–17 in engineering terms
The substantive obligations on high-risk AI under the EU AI Act, translated from legal language to engineering practice. Each Article with one-sentence summary, plain-language explanation, engineering implications, and a CIO-grade compliance checklist. Audit-survivable readiness percentages from MindMap's 50-enterprise benchmark.
Article 9 — Risk Management System
High-risk AI systems must operate within a continuous, documented risk-management system spanning the entire AI lifecycle.
What the Article requires
Article 9 requires providers of high-risk AI systems to establish, implement, document and maintain a risk-management system that runs throughout the AI lifecycle. The system identifies foreseeable risks to health, safety and fundamental rights, evaluates risks under intended use and reasonably-foreseeable misuse, and adopts targeted risk-management measures. Critically, it is not a one-time exercise — the system is updated continuously as the AI evolves.
In engineering terms
Maps to existing enterprise risk-management frameworks but specifically extends to AI lifecycle artefacts: training-data risks, model behaviour risks, deployment-context risks, and misuse risks. Engineering teams typically bolt this onto SR 11-7 (US BFSI), the FCA SYSC framework, or analogous existing-risk taxonomies.
Compliance checklist
- ✓Documented risk-management process specifically applied to AI systems
- ✓Identified, evaluated and treated risks to health, safety and fundamental rights
- ✓Risk-management decisions documented with rationale
- ✓Continuous-update cycle, not a one-time assessment
- ✓Integration with the existing enterprise risk function
Article 10 — Data and Data Governance
Training, validation and testing data sets must be of relevant, representative, free of errors and complete to the best extent possible — with documented data-governance practices throughout.
What the Article requires
Article 10 governs the data used to train, validate and test high-risk AI systems. Data must be relevant, representative, free of errors and complete. Data-governance practices must address design choices, data collection processes, data preparation (labelling, cleaning, augmentation), assumptions about what the data represents, prior assessment of availability/quantity/suitability, examination of biases, and identification of any gaps or shortcomings. The Article also creates a special-category-data exception for bias detection and correction.
In engineering terms
Implies a training-data lineage capability — provenance, transformation history, quality metrics — that most enterprises don't have for the AI systems they procure as products. Sovereign deployment of customer-trained or customer-fine-tuned models is the cleanest path to evidence; for off-the-shelf vendor systems, the vendor-side documentation must be obtained and validated.
Compliance checklist
- ✓Documented data-collection processes
- ✓Training-data lineage and provenance records
- ✓Bias examination performed and documented
- ✓Data-preparation steps (labelling, cleaning, augmentation) recorded
- ✓Quality, representativeness and completeness assessments
Article 11 — Technical Documentation
Technical documentation per Annex IV must demonstrate the system meets Articles 9-15 requirements and be available to authorities for ten years post-placing-on-market.
What the Article requires
Article 11 requires providers to draw up technical documentation before placing the high-risk AI system on the market. The documentation must include everything in Annex IV — system description, design, components, training data, intended use, performance metrics, risk-management system, evaluation procedures, post-market monitoring plan. It must be kept up to date and made available to national competent authorities on request for ten years.
In engineering terms
The Annex IV format is the single biggest documentation discipline most enterprises don't have today. Most existing system documentation is fragmented across architecture decisions, runbooks and READMEs; restructuring it into the Annex IV format is largely translation work. MindMap maintains an Annex IV template that takes typical enterprise system documentation and restructures it — saves substantial time vs writing from scratch.
Compliance checklist
- ✓Annex IV-format technical documentation drafted
- ✓System description, design, intended use captured
- ✓Training-data sources, quality, preparation documented
- ✓Performance, accuracy, robustness, cybersecurity evidence
- ✓Document control with version history and update process
- ✓10-year retention plan
Article 12 — Record-keeping
High-risk AI systems must automatically log events during operation, with log retention sufficient to satisfy traceability requirements.
What the Article requires
Article 12 requires high-risk AI systems to technically record events relevant to identifying situations where the system could present risks, to facilitating post-market monitoring, and to enabling subsequent monitoring of operation. The logs must be retained appropriately considering intended purpose. For some applications (e.g., biometric identification) specific log content is mandated. The record-keeping must be designed into the system, not bolted on as an afterthought.
In engineering terms
Implies an observability substrate — Langfuse self-hosted or equivalent — that captures every inference, every decision, every escalation. Most customers log enough but few log in a format that survives audit review. The critical engineering controls: content-addressed audit storage (immutable, replayable by hash), structured event schemas (not free-form JSON dumps), and SIEM integration so the audit trail is part of the existing operational fabric.
Compliance checklist
- ✓Auto-generated event logs from the AI system
- ✓Log retention period defined and implemented
- ✓Tamper-evident or content-addressed log storage
- ✓SIEM integration for the operational audit trail
- ✓Replay capability for any historical decision
Article 13 — Transparency and Information to Deployers
Providers must accompany high-risk AI systems with clear instructions for use, system characteristics, intended use, performance metrics, and the level of accuracy expected.
What the Article requires
Article 13 requires providers to design high-risk AI systems with sufficient transparency to enable deployers to interpret outputs and use them appropriately. Instructions for use must include provider identity, system characteristics, intended use, level of accuracy/robustness/cybersecurity, foreseeable circumstances that may lead to risks, performance regarding specific groups, training data information, and the human-oversight measures designed in.
In engineering terms
For internal AI systems the 'deployer' is the customer's own operational teams; the documentation must enable the team to use the system within its intended scope. For vendor-supplied systems the deployer must validate that the vendor's Article 13 disclosures match the actual system behaviour. The most common gap: vendor disclosures are written for marketing rather than operational use.
Compliance checklist
- ✓Clear instructions for use for downstream deployers
- ✓Provider identity and contact information
- ✓Intended-use boundary clearly specified
- ✓Performance characteristics and limitations disclosed
- ✓Human-oversight measures designed in and documented
Article 14 — Human Oversight
High-risk AI systems must be designed so a human can effectively oversee, understand, monitor, intervene, override, and choose not to use the system in any particular case.
What the Article requires
Article 14 requires high-risk AI systems to be designed to enable effective human oversight during the period the system is in use. The oversight must be operable by a person who can: fully understand capabilities and limitations, monitor operation to detect anomalies, remain aware of automation bias, interpret outputs correctly, decide not to use the system in any particular case, and intervene to halt or reverse the system. For some Annex III categories (e.g., biometric ID), two-person oversight is required.
In engineering terms
The translation from regulatory language to engineering practice is non-trivial. Most existing 'human in the loop' implementations don't satisfy the effective-oversight standard. MindMap's approach: a structured oversight protocol per AI system, documented competence requirements for the human reviewer, explicit override authority captured in the audit trail, and an automation-bias-mitigation discipline (cooling-off periods on rapid-fire decisions, mandatory two-person review on high-stakes outputs).
Compliance checklist
- ✓Documented oversight protocol per AI system
- ✓Named reviewer roles with competence requirements
- ✓Override authority captured in audit trail
- ✓Automation-bias mitigation (e.g., randomised review samples)
- ✓Two-person review where required by Annex III subcategory
Article 15 — Accuracy, Robustness and Cybersecurity
High-risk AI systems must achieve appropriate levels of accuracy, robustness and cybersecurity, including resilience against adversarial input and feedback loops.
What the Article requires
Article 15 sets three substantive performance requirements. Accuracy: declared metrics and measurement methodology. Robustness: resilience against errors, faults, inconsistencies, and the technical state of the art. Cybersecurity: resilience against attempts to alter use, behaviour or performance, including data-poisoning, model-poisoning, adversarial examples, and confidentiality attacks. The Article also addresses 'feedback loops' (where outputs are reused as future training inputs) — these must be mitigated.
In engineering terms
Accuracy is the easy part for teams with mature ML/AI engineering — declare the eval metric, run the harness on every release, publish the result. Robustness implies a structured evaluation harness with adversarial scenarios. Cybersecurity for AI is the newest discipline: prompt-injection threat modelling, model-poisoning detection on continuous-learning systems, and the feedback-loop mitigation discipline for any system whose outputs train downstream models.
Compliance checklist
- ✓Accuracy metrics declared and tracked across releases
- ✓Robustness eval harness including adversarial scenarios
- ✓Prompt-injection threat model documented
- ✓Cybersecurity controls per ENISA AI guidelines
- ✓Feedback-loop mitigation discipline
Article 17 — Post-market Monitoring System
Providers must establish a documented post-market monitoring system to actively collect, document and analyse data on the AI system's performance throughout its lifetime.
What the Article requires
Article 17 requires providers to establish a post-market monitoring system proportionate to the risks of the high-risk AI system. The system must actively and systematically collect, document and analyse relevant data on the AI's performance after placing-on-market, evaluate continuous compliance with Articles 8-15, and feed back into corrective actions. Implementing acts may further specify the monitoring requirements per use case.
In engineering terms
The lowest-scoring Article on MindMap's 50-enterprise readiness benchmark (19% audit-survivable). Most customers have not built the operational substrate for AI-specific post-market monitoring. The fix is a Langfuse-or-equivalent observability layer with structured drift detection, an incident-and-near-miss registry, and a periodic review cadence (typically monthly) feeding into corrective-action workflows.
Compliance checklist
- ✓Observability platform deployed (Langfuse self-hosted or equivalent)
- ✓Drift-detection rules per AI system
- ✓Incident and near-miss registry with workflow
- ✓Monthly performance-review cadence
- ✓Corrective-action workflow with audit trail
Article 25 — Provider vs Deployer Trigger
A deployer that makes substantial modifications, rebrands, or repurposes an AI system becomes the provider — and takes on the full Articles 9-15 obligation stack.
What the Article requires
Article 25 closes the escape hatch most enterprises think they have. Three triggers convert a deployer into a provider: (a) substantial modification of the system, (b) putting the system on the market under one's own name or trademark, (c) substantially modifying the intended purpose. Once provider status attaches, the full Articles 9-15 evidence stack applies — the customer can no longer rely on the upstream vendor's compliance posture.
In engineering terms
Across MindMap's audit of regulated enterprise AI portfolios, 70% contain at least one Article 25 trigger — typically a fine-tuned foundation model in a credit-scoring pipeline, a vendor LLM repurposed for a regulated use case, or an AI feature white-labelled and shipped under the enterprise's brand. Each trigger turns an integrator into a provider in the regulator's eyes.
Compliance checklist
- ✓Inventory of fine-tuned models, rebranded vendor systems and repurposed AI
- ✓Article 25 classification for each AI system
- ✓Provider-stack evidence collection for triggered systems
- ✓Vendor disclosures validated against actual customer use
- ✓Cross-functional sign-off on Article 25 determinations
Article 26 — Deployer Obligations
Deployers of high-risk AI must use the system per the provider's instructions, assign competent human oversight, monitor operation, retain logs, and inform employees and affected persons.
What the Article requires
Article 26 sets the obligation stack for high-risk AI deployers (the customer using the system, not the provider building it). Use systems per instructions for use; assign human oversight to natural persons with the competence, training and authority needed; monitor operation; report serious incidents to providers; retain auto-generated logs for at least six months; inform employees who will be subject to the AI, and affected persons of natural persons subject to AI-supported decisions.
In engineering terms
Compared to provider obligations under Articles 9-15, deployer obligations are tractable — most enterprises can satisfy them with proportionate governance: a competent oversight function, log retention discipline, and clear staff communications. The risk is Article 25 conversion (see Article 25) — many self-perceived 'deployers' have Article 25 triggers they haven't catalogued.
Compliance checklist
- ✓Use of high-risk AI conforms to provider's instructions
- ✓Named human-oversight roles with documented competence
- ✓Log retention (minimum 6 months) operationalised
- ✓Serious-incident reporting workflow to providers
- ✓Employee and affected-person notifications in place
Article 27 — Fundamental Rights Impact Assessment (FRIA)
Public-sector deployers and certain essential-services deployers must conduct a Fundamental Rights Impact Assessment before first deployment.
What the Article requires
Article 27 obliges specific deployer categories — public-sector bodies, private bodies providing public services, deployers of credit-scoring and insurance-pricing AI — to perform a Fundamental Rights Impact Assessment before first use of a high-risk AI system. The assessment must describe deployment processes, the categories of natural persons affected, specific risks of harm to affected persons, human-oversight measures, and the measures to be taken if risks materialise.
In engineering terms
FRIAs sit alongside DPIAs (under GDPR Article 35) but are more focused on fundamental rights — non-discrimination, dignity, freedom of expression, fair trial — rather than data-protection narrowly. Template-and-fill works once an enterprise has done one or two; the first one is the hardest. MindMap maintains a FRIA template developed against the Council of Europe FRIA framework that maps cleanly to the EU AI Act's specific requirements.
Compliance checklist
- ✓FRIA performed before first deployment of in-scope high-risk AI
- ✓Deployment process description
- ✓Categories of natural persons affected identified
- ✓Specific risks of harm catalogued
- ✓Human-oversight measures matched to risks
- ✓Risk-materialisation response plan
Article 50 — Transparency Obligations for Specific AI Systems
AI systems interacting with natural persons, generating synthetic content, performing emotion recognition or biometric categorisation, and deep fakes carry specific transparency obligations regardless of risk tier.
What the Article requires
Article 50 applies regardless of high-risk classification. Providers of AI systems intended to interact with natural persons (chatbots) must inform users they're interacting with AI unless obvious. Providers of generative AI must ensure synthetic content is detectable (watermarking). Deployers of emotion-recognition or biometric-categorisation systems must inform exposed natural persons. Deployers of deep-fake-generating AI must disclose the synthetic nature of the output. Some exceptions for law enforcement and freedom-of-expression contexts.
In engineering terms
Implementation is mostly UX work — chat-interface disclosure copy, C2PA-style provenance signals on generated media, consent flows for emotion-recognition deployments. Easy to get right at the start, expensive to retrofit. The watermarking discipline is the only technically non-trivial part: providers must use 'effective, interoperable, robust and reliable' techniques as far as technically feasible.
Compliance checklist
- ✓Chatbot interactions disclosed to users (UX copy)
- ✓C2PA or equivalent watermarking on generated media
- ✓Emotion-recognition deployments disclose exposure
- ✓Deep-fake outputs labelled as synthetic
- ✓Documentation of disclosure mechanisms
Article 53 — GPAI Baseline Obligations
Providers of general-purpose AI models must produce technical documentation, training-data summaries, copyright-compliance policies, and information for downstream deployers.
What the Article requires
Article 53 sets baseline obligations on every general-purpose AI (GPAI) model provider. Technical documentation covering training, testing, evaluation results, and resource usage. Information for downstream providers integrating the GPAI into their AI systems. A copyright-compliance policy. A 'sufficiently detailed summary' of training data made publicly available. The provisions apply regardless of training-compute scale — every GPAI provider carries the baseline.
In engineering terms
Most enterprise customers are not GPAI providers; they're integrators of GPAI models from vendors. Article 53 affects them indirectly via the downstream-deployer information provisions: vendor disclosures should cover what's needed for integration, and Article 11 (technical documentation) for the customer's own high-risk system depends on having that vendor information. Sovereign deployment of customer-trained or customer-fine-tuned models creates a Article 25 trigger (see Article 25) — customer becomes provider.
Compliance checklist
- ✓Technical documentation for the GPAI model
- ✓Training-data summary published
- ✓Copyright-compliance policy
- ✓Downstream-deployer information package
- ✓Vendor-disclosure validation if integrating third-party GPAI
Article 55 — GPAI Systemic-Risk Obligations
GPAI models above the 10^25 FLOP training-compute threshold carry additional systemic-risk obligations including evaluations, adversarial testing, incident reporting and cybersecurity.
What the Article requires
Article 55 adds obligations on top of Article 53 for GPAI models with systemic risk — defined as models trained on >= 10^25 FLOPs of compute, or otherwise designated by the AI Office. Obligations: state-of-the-art model evaluations including adversarial testing, assessment and mitigation of systemic risks at Union level, serious-incident tracking and reporting, and adequate cybersecurity protection for the model and its physical infrastructure.
In engineering terms
Article 55 affects very few enterprises directly — the threshold catches frontier-model providers like OpenAI, Anthropic, Google, Mistral. For enterprise integrators the question is which downstream evidence each frontier vendor provides under Article 55 — adversarial-test reports, systemic-risk assessments, incident logs. The vendor disclosures cascade into customer-side Articles 9-15 evidence.
Compliance checklist
- ✓Confirm whether your GPAI provider crosses the 10^25 FLOP threshold
- ✓Obtain vendor Article 55 disclosure pack
- ✓Cascade vendor Article 55 evidence into customer Article 11 documentation
- ✓Adversarial-test review (vendor-provided)
- ✓Incident-tracking integration if vendor-managed
Need to operationalise Articles 9–17?
MindMap runs a 90-day path that takes enterprises from standing start to audit-survivable evidence on all 8 Articles. Talk to the engineering team.