Chapter XIII · FINAL PROVISIONS
Article 113 — Entry into force and application
▼ Primary text, verbatim. Our annotations appear below, visibly separated.
This Regulation shall enter into force on the twentieth day following that of its publication in the *Official Journal of the European Union*.
It shall apply from 2 August 2026.
However:
(a) Chapters I and II shall apply from 2 February 2025, with the exception of Article 5(1), first subparagraph, points (ba) and (bb), and Article 5(1a) and (1b) which shall apply from 2 December 2026;
(b) Chapter III Section 4, Chapter V, Chapter VII and Chapter XII and Article 78 shall apply from 2 August 2025, with the exception of Article 101;
(c) Chapter III, Sections 1, 2, and 3, with the exception of Article 6(5), shall apply from:
(i) 2 December 2027 as regards AI systems classified as high-risk pursuant to Article 6(2) and Annex III; and
(ii) 2 August 2028 as regards AI systems classified as high-risk pursuant to Article 6(1) and Annex I;
(d) Articles 102 to 110 shall apply from 27 July 2026.
This Regulation shall be binding in its entirety and directly applicable in all Member States.
This text is meant purely as a documentation tool and has no legal effect. The Union's institutions do not assume any liability for its contents. The authentic versions of the relevant acts, including their preambles, are those published in the Official Journal of the European Union and available in EUR-Lex.
Passages marked with the accent edge in the primary text were inserted or replaced by the amendment.
Show the text as adopted, before the amendment
The authentic 2024 text of this provision, shown for comparison. It no longer states the law.
This Regulation shall enter into force on the twentieth day following that of its publication in the *Official Journal of the European Union*.
It shall apply from 2 August 2026.
However:
(a) Chapters I and II shall apply from 2 February 2025;
(b) Chapter III Section 4, Chapter V, Chapter VII and Chapter XII and Article 78 shall apply from 2 August 2025, with the exception of Article 101;
(c) Article 6(1) and the corresponding obligations in this Regulation shall apply from 2 August 2027.
This Regulation shall be binding in its entirety and directly applicable in all Member States.
Done at Brussels, 13 June 2024.
*For the European Parliament*
*The President*
R. METSOLA
*For the Council*
*The President*
M. MICHEL
What this means for you
In your terms · Data and data governance
Dataset lineage is yours: where each set came from, how it was prepared, what its gaps are, and the bias examination that was actually run.
- Dataset cards with provenance
- Bias examination report
Failure smells likeSomeone asks which data the model was trained on and the answer is a bucket path, with no record of how the set was assembled or what it was assumed to represent.
In your terms · Data and data governance
Lineage only holds if the pipeline records it: per-training-run records tying model versions to exact dataset versions.
- Per-run lineage records
In your terms · Data and data governance
The data assumptions are yours to state. Article 10(2)(d) asks for the assumptions about what the data is supposed to measure and represent, and that is a product claim about a population, not an engineering detail.
- Stated assumptions per data set
- Representativeness note for the target population
In your terms · Data and data governance
Bias-correction processing of sensitive data has its own conditions; that trade-off is decided with your privacy function.
In your terms · Technical documentation
The Annex IV file describes your system, and drift makes it wrong. Generate what can be generated from the source of truth instead of hand-maintaining prose.
- Annex IV technical file
- Doc generation wired into CI
Failure smells likeThe documentation describes the system as it was designed two releases ago, and nothing in the pipeline forces it to move with the code.
In your terms · Technical documentation
Intended purpose, as written here, bounds everything else: it decides classification and what misuse means.
In your terms · Technical documentation
Decide early whether the simplified SME form applies to you; it changes the documentation workload materially.
- Documentation format decision on record
In your terms · Automatic recording of events
Logging capability is a design-time decision, not a config you bolt on later: correlation IDs and event coverage live in the code.
- Decision-correlation IDs across services
In your terms · Automatic recording of events
You already have the pipeline. The gap is usually schema and retention: events rich enough to reconstruct one specific decision on one specific date, protected against tampering.
You already haveA log pipeline and retention config. The gap is decision-grade fidelity, not plumbing.
- Inference event schema
- Tamper-evident log storage
- Replay runbook
Failure smells likeA regulator asks why one decision happened on one date, and the best answer available is a dashboard screenshot.
In your terms · Automatic recording of events
This is the obligation that makes answering why the system decided something possible at all.
In your terms · Automatic recording of events
Long-retention, full-fidelity decision logs are a real storage line item and a real privacy surface; budget both.
In your terms · Transparency and instructions for deployers
Interpretability of output is partly interface design: expose confidence, provenance and known failure modes where the deployer can see them.
- Output metadata deployers can read
In your terms · Transparency and instructions for deployers
Part of the instructions is operational fact: Article 13(3)(e) wants the computational and hardware resources, the expected lifetime and the maintenance and update cadence. Those numbers come from you, and whatever gets printed becomes the commitment operations is held to.
- Resource, lifetime and maintenance inputs for the instructions
In your terms · Transparency and instructions for deployers
The instructions for use are a product artifact: what the system is for, what it must not be used for, and what the deployer has to set up.
- Instructions for use per system
Failure smells likeA deployer uses the system for something it cannot actually do well, and the instructions never said where the edge was.
In your terms · Human oversight
The stop and override paths have to exist in the architecture, tested like any other critical path.
- Kill switch and override, with tests
In your terms · Human oversight
Oversight needs operational teeth: alerting a human can act on, and a runbook for actually stopping the system.
- Oversight runbook
In your terms · Human oversight
Oversight is a runtime capability with real access paths: who can override, on what screen, with what information in front of them.
- Oversight UX with override path
Failure smells likeThe oversight step exists on the screen, but the person doing it has no basis on which to disagree with the output and no way to stop the system.
In your terms · Accuracy, robustness and cybersecurity
Adversarial input, prompt injection and poisoning resistance are test suites, not adjectives.
- Adversarial and injection test suite
In your terms · Accuracy, robustness and cybersecurity
Declared once, held every day after: the accuracy and resilience levels in the documentation become production SLOs with monitoring behind them.
- Model performance SLOs with alerts
Failure smells likeThe accuracy declared in the technical file drifts from production metrics with nobody watching the gap.
In your terms · Accuracy, robustness and cybersecurity
Article 15(3) requires the accuracy levels and the relevant metrics to be declared in the instructions for use. Whichever number you publish becomes the promise the system is measured against, so it is a product decision before it is a benchmark.
- Declared accuracy levels and metrics
In your terms · Accuracy, robustness and cybersecurity
The declared levels go into the technical documentation; overdeclaring creates a standing gap between paper and production.
In your terms · Quality management system
The quality management system reaches into how you build. Article 17(1)(b) and (c) name design control, design verification and the testing procedures by name: if the written system is not how the team actually works, it is a document that will not survive being checked.
- Design control and verification procedures
- Test and validation records
In your terms · Quality management system
Your runbooks and change-management practice will be exhibits in it.
In your terms · Quality management system
The quality management system governs how a change reaches production, modifications to an already assessed system included. It sets the pace at which you can ship.
In your terms · Quality management system
The QMS is where the other obligations get operationalized as written policies and procedures with named owners.
- Documented QMS with named owners
Failure smells likeCompliance lives in the heads of three people, and how a change reaches production depends on which of them you ask.
In your terms · Keeping the documentation for ten years
The technical file you generate today must still be producible a decade from now.
In your terms · Keeping the documentation for ten years
Durable, restorable storage for the archive is an operations problem: test the restore, not just the backup.
- Archive restore test on a schedule
In your terms · Keeping the documentation for ten years
Ten years outlives your stack, your vendors and probably your storage format. Custody needs a named owner and a migration plan.
- Ten-year documentation archive with named custodian
Failure smells likeA request arrives for the file of a system retired four years ago, and the repository it lived in was archived with the team that owned it.
In your terms · Keeping the automatically generated logs
Log formats you change casually today are formats someone must still parse months from now.
In your terms · Keeping the automatically generated logs
Most platforms run days of retention and sampled events; this wants months, complete, and recoverable on request.
You already haveRetention exists, typically at days or weeks and sampled. The floor here is months, complete.
- Retention policy meeting the six-month floor
- Restore test on aged logs
Failure smells likeThe logs covering the period under question were rotated out, on a retention default nobody set with this obligation in mind.
In your terms · Keeping the automatically generated logs
Retention at decision fidelity is a storage budget and a privacy trade-off to settle with your DPO, not a default.
- Retention budget and DPO sign-off
In your terms · Corrective actions and duty of information
Withdraw, disable or recall are operational verbs: the paths to actually do them, per system, exist before the day you need them.
- Withdraw-or-disable runbook per system
- Downstream notification list
Failure smells likeA non-conformity is found and the only way to disable the system is a redeploy nobody dares to run.
In your terms · Corrective actions and duty of information
The decision that a system is non-conformant, and who gets told, is a recorded judgment call with your name near it.
- Corrective-action decision record
In your terms · Cooperation with competent authorities
Producing months-old logs for one system on request is a retrieval procedure you can rehearse.
- Evidence retrieval procedure
In your terms · Cooperation with competent authorities
An authority request is answered from what exists: the response path, the language question and the named owner are decided in advance.
- Authority response runbook with named owner
Failure smells likeA reasoned request arrives with a deadline on it, and answering means asking four teams what they happen to have.
In your terms · Authorised representative for third-country providers
EU launch timelines gain a dependency: the representative exists before the system is made available.
In your terms · Authorised representative for third-country providers
If your company sits outside the EU and sells in, this is a prerequisite to market entry, not paperwork to backfill.
- Written mandate for the authorised representative
Failure smells likeThe system is on the Union market and the written mandate was never signed, so there is nobody in the Union who can answer for it.
In your terms · Importer obligations
Distribution deals for third-country AI systems carry these checks in the critical path.
In your terms · Importer obligations
Reselling a non-EU system into the EU makes you the importer: the verification duties are yours before the first sale.
- Import verification record per system
Failure smells likeYou placed a third-country system on the market and cannot show that you checked its conformity assessment before you did.
In your terms · Distributor obligations
Reseller and marketplace agreements carry these checks in the critical path.
In your terms · Distributor obligations
A marketplace or reseller motion for high-risk AI needs these checks wired into onboarding, not sampled afterwards.
- Distribution verification checklist
Failure smells likeYou are making a system available that nobody in your chain has ever checked for a CE marking or a declaration of conformity.
In your terms · Becoming the provider along the value chain
Fine-tuning or wrapping a third-party system can quietly change who counts as its provider.
In your terms · Becoming the provider along the value chain
White-labelling and repurposing decisions are where this triggers: putting your brand on it or changing what you destine it for each flips the role on its own, and a substantial modification is the third route.
- Repurposing check in launch review
In your terms · Becoming the provider along the value chain
The software analogy holds: the moment you rebrand it, change it substantially or repurpose it, the whole compliance surface is yours.
- Value-chain role assessment per system
Failure smells likeA white-label deal ships, and only afterwards someone realizes the provider obligations moved with it.
In your terms · Deployer obligations
Deployer-side logs and monitoring are yours even when the model is someone else's.
- Deployer-side log retention
In your terms · Deployer obligations
If you deploy third-party AI in your workflows, the usage constraints in the instructions become your product constraints.
- Deployment instructions record per system
Failure smells likeThe system runs in production the way the team found convenient, not the way the instructions for use require, and nobody ever compared the two.
In your terms · Deployer obligations
Named, competent oversight roles are assigned by you, and worker information duties precede workplace rollouts.
- Named oversight roles
- Worker information notice
In your terms · Fundamental rights impact assessment
The assessment describes your actual process: which decisions the system feeds, who is affected, what can go wrong for them and what you will do about it.
- Fundamental rights impact assessment
Failure smells likeThe system goes live to the public and the first assessment of what it does to people is the complaint that follows.
In your terms · Fundamental rights impact assessment
Whether your organization is in scope is the first question; the answer decides real pre-deployment work.
- Scope determination on record
In your terms · Conformity assessment
Substantial modifications reopen the assessment; release planning has to know that.
In your terms · Conformity assessment
Which assessment route applies, and whether a notified body is involved, is a decision to make long before the deadline, because it shapes the whole evidence chain.
- Conformity route decision per system
Failure smells likeThe launch date is set and the conformity route was never decided, so whether a notified body is involved becomes a question asked too late to answer.
In your terms · EU declaration of conformity and CE marking
Digital systems carry a digital CE marking; it is part of the shipping surface.
In your terms · EU declaration of conformity and CE marking
The declaration is the formal claim that everything upstream (risk management, data, documentation, assessment) holds; signing it is the accountability moment.
- EU declaration of conformity per system
Failure smells likeThe system is on the market with no signed declaration behind it, because drawing one up was treated as paperwork that follows the release.
In your terms · Registration in the EU database
Claiming the not-high-risk carve-out is itself a registered, documented act.
In your terms · Registration in the EU database
Registration is an external, dated record of what you placed on the market and under what classification; it has to match your documentation.
- Registration entries per system
Failure smells likeThe system has been in service for months, the database entry was never made, and no internal step would ever have caught it.
In your terms · Real-world testing outside sandboxes
Test cohorts and their consent state are data your system has to track.
In your terms · Real-world testing outside sandboxes
A live test can be ordered to stop. Article 60(7) requires immediate mitigation on a serious incident, suspension or termination failing that, and a procedure for prompt recall: the watch on the test and the paths to halt and pull it back are operational work that exists before recruitment starts.
- Test monitoring with a halt path
- Prompt-recall procedure
In your terms · Real-world testing outside sandboxes
A pilot with real users of a would-be high-risk system is a regulated activity: the plan and the consent flow are launch blockers, not afterthoughts.
- Real-world testing plan
- Informed-consent flow for test subjects
Failure smells likeTesting in the field started because it was the fastest way to learn, and the plan, the approval and the consent were left as things to sort out later.
In your terms · Real-world testing outside sandboxes
Whether your pilot is inside or outside this regime is a scoping call to make before recruitment starts.
- Testing-regime scope determination
In your terms · Risk management system
Risk treatments become design constraints and test cases; each identified risk should map to something you can point at in the codebase.
- Risk-to-control mapping in the design docs
In your terms · Risk management system
Risk management is not a document you sign once. Article 9(2)(c) feeds it from the post-market monitoring system, which is your telemetry: the risks that only appear in the field reach the register through you or they do not reach it.
- Field-risk signal feed into the register
- Escalation path for emergent risk
In your terms · Risk management system
Foreseeable misuse is a product question: how will people actually use, and abuse, this feature.
- Foreseeable-misuse analysis per release
In your terms · Risk management system
Someone has to own the loop: a living risk register wired into how the system actually changes, reviewed on a cadence you can evidence.
- Living risk register with review cadence
Failure smells likeThe risk register's last edit predates the last three releases.
Obligations derived from this article
If you would rather not read the law
The basics page explains the Regulation's own categories in order: scope, role, tier, date. The engineering view groups the obligations by the platform capability they demand.