Article 26 of the EU AI Act assigns operating duties to the organisation that uses a high-risk AI system under its authority. The work covers instruction-bound use, capable human oversight, input data, live monitoring, suspension and incident routes, automatic logs, notices, registration, impact-assessment inputs, and cooperation with authorities. Regulation (EU) 2026/1744 changed the application calendar and scope rules in July 2026. The Article 26 text remains in place, with the Chapter III duties applying from 2 December 2027 for Annex III systems and 2 August 2028 for Article 6(1) Annex I systems to which Article 26 applies. This guide translates each paragraph into an operating control and an evidence request. It is general information, current to 27 July 2026, and does not replace advice on a specific deployment.
Confirm that you are a deployer of a high-risk system
The Article 3(4) definition covers a natural or legal person, public authority, agency, or other body using an AI system under its authority, apart from personal non-professional use. The same organisation can hold different roles for different systems. It may deploy a vendor system, provide another system under its own name, or become a provider through the Article 25 value-chain rules.
Article 26 sits in the high-risk chapter. Start with Article 6, the system’s intended purpose, and the scope rules in Article 2. One route covers AI that is a regulated product or safety component under Annex I and requires third-party conformity assessment. The other covers Annex III uses such as certain systems in biometrics, critical infrastructure, education, employment, essential services, law enforcement, migration, and justice. Article 6(3) contains a bounded exception for some Annex III systems, while profiling of natural persons remains high-risk. Record the classification analysis and the facts supporting it. The high-risk classification guide walks through the decision.
| Question | Evidence to keep |
|---|---|
| Does the organisation use this system under its authority? | Role analysis, contracts, system owner, operating boundaries, and any Article 25 provider trigger review. |
| Is this AI system high-risk under Article 6? | Intended purpose, Annex I or Annex III path, Article 6(3) assessment where relevant, and approval of the classification. |
The 2026 amendment changed the calendar
The legal source for this guide is the Official Journal text of Regulation (EU) 2024/1689, read together with Regulation (EU) 2026/1744. The amending regulation was published on 24 July 2026 and entered into force on 27 July 2026.
Regulation (EU) 2026/1744 amends Article 113. Chapter III Sections 1, 2, and 3 now apply from 2 December 2027 to systems classified as high-risk under Article 6(2) and Annex III, and from 2 August 2028 to systems classified under Article 6(1) and Annex I. Article 26 is in Section 3.
The amended Article 2(2) limits the AI Act rules for Article 6(1) systems tied to products in Section B of Annex I to Article 6(1), Article 60a, and Articles 102 to 112. Article 26 therefore does not apply to those systems through that route. The 2 August 2028 Article 26 date concerns Article 6(1) systems covered by the remaining scope rules, including qualifying Section A products. Record the applicable Annex I section before assigning Article 26 controls.
The same amendment replaces Article 111(2). A high-risk system placed on the market or put into service before its applicable Chapter III date generally enters the requirements when it is subject to significant design changes from that date. Providers and deployers of high-risk systems intended for use by public authorities must take the necessary compliance steps by 2 August 2030. Teams using this transition should document the system’s first placement or service date, design baseline, later changes, and public-authority use.
Two deployer duties run on separate clocks. Regulation (EU) 2026/1744 replaces Article 4 with a duty to take measures that support the development of staff AI literacy, without requiring a guaranteed level for any individual. Article 50 transparency applies from 2 August 2026 to specified systems and uses across risk tiers. Plan both duties on their own dates.
| Date | Deployer work |
|---|---|
| Already applicable | Article 4 AI-literacy measures, as amended by Regulation (EU) 2026/1744. |
| 2 August 2026 | Article 50 transparency duties for deployers where the listed use triggers them. |
| 2 December 2027 | Chapter III duties, including Article 26, for Article 6(2) and Annex III high-risk systems. |
| 2 August 2028 | Chapter III duties, including Article 26, for Article 6(1) Annex I systems within the applicable Article 2 scope. |
| 2 August 2030 | Article 111(2) compliance endpoint for high-risk systems intended for use by public authorities. |
Use the system within its instructions
Article 26(1) requires appropriate technical and organisational measures that keep use aligned with the provider’s instructions. Treat the instructions as an operating boundary. Translate intended purpose, supported inputs, known limitations, required oversight, accuracy conditions, environmental assumptions, maintenance, and prohibited uses into configuration and release controls.
Keep the provider’s Article 13 information with the deployed version. A model, prompt, tool, data source, or business-purpose change can alter the assumptions that made the original instructions workable. Review changes before release and record the decision that the intended use remains inside the documented boundary.
- Name the business owner and technical owner for the deployed system.
- Pin the provider instructions and system version used for each release.
- Convert use limits into configuration checks, access rules, and approval conditions.
- Review vendor updates, local adaptations, new data sources, and new operating contexts.
- Document deviations, corrective action, and the authority that accepted a permitted change.
Assign human oversight with real authority and support
Article 26(2) requires natural persons with the necessary competence, training, authority, and support. The provider designs the human-oversight measures under Article 14; the deployer assigns people who can use them in the operating environment. Evidence should show that each person could understand a case, intervene, disregard an output, or stop use within their authority.
Define the decisions each overseer can make, the information they receive, their access, coverage, escalation path, and response target. Test the path with realistic cases. Article 26(3) preserves other Union and national duties and the deployer’s freedom to organise its resources when implementing provider-defined oversight measures. Record how the chosen organisation satisfies the required measures. The Article 14 implementation guide covers approvals, overrides, stop mechanisms, and evidence in depth.
| Control | Evidence |
|---|---|
| Named assignment | Person, role, system scope, start date, and delegation record. |
| Competence and training | Training content, completion, practical assessment, refresh trigger, and known limitations. |
| Authority | Approval, override, escalation, and suspension rights tied to the person’s role. |
| Support | Case context, provider instructions, access to specialists, staffing, and escalation coverage. |
| Operating proof | Decision records, overrides, interventions, drills, exceptions, and corrective actions. |
Control the input data you actually control
Article 26(4) applies to the extent the deployer exercises control over input data. Within that boundary, the input data must be relevant and sufficiently representative for the intended purpose. Record which inputs come from the deployer, a provider, a user, or another system. Assign validation and remediation only where the organisation can perform them.
Operational checks can cover allowed sources, required fields, freshness, population coverage, format, provenance, and drift against the intended use. A failed check needs a defined outcome: reject the input, route it for correction, narrow the use, or suspend the affected path. Keep the test result and action with the run or batch it governed.
Monitor operation, suspend risky use, and route incidents
Article 26(5) requires monitoring based on the instructions for use and, where relevant, provider notification under Article 72. Define the signals, thresholds, owners, review frequency, and provider feedback path before launch. For an agentic system, relevant signals may include policy decisions, tool-call failures, overrides, blocked actions, output quality, input drift, complaints, safety events, and changes in downstream effects. The exact set follows the intended purpose and known risks.
When use in accordance with the instructions may present a risk within Article 79(1), the deployer must inform the provider or distributor and the relevant market-surveillance authority without undue delay and suspend use. A serious incident triggers immediate notification first to the provider, then the importer or distributor and the relevant market-surveillance authorities. Article 73 applies mutatis mutandis when the provider cannot be reached. Build one triage path that records the trigger, severity analysis, contacts, timestamps, suspension decision, and recovery authority.
Financial institutions subject to Union financial-services rules on internal governance can satisfy the Article 26(5) monitoring obligation through those relevant arrangements. Keep the mapping that shows which existing control covers each Article 26 monitoring element. The post-market monitoring plan provides a companion structure for the provider-deployer evidence flow.
| Observed state | Defined response | Evidence |
|---|---|---|
| Inside instructions and thresholds | Continue use and retain the monitoring result. | Signal values, system version, review result, and timestamp. |
| Potential Article 79(1) risk | Suspend affected use and notify the provider or distributor and market-surveillance authority without undue delay. | Trigger, risk analysis, suspension scope, notices, and responsible person. |
| Serious incident | Notify the provider immediately, followed by the importer or distributor and market-surveillance authorities. | Incident record, causal facts known at the time, notice sequence, recipients, and timestamps. |
| Provider unreachable | Run the Article 73 route as Article 26(5) requires. | Contact attempts, reporting decision, authority submission, and follow-up. |
Retain the automatic logs under your control
Article 26(6) requires the deployer to keep automatically generated logs to the extent those logs are under its control. The period must be appropriate to the intended purpose and at least six months, unless other Union or national law provides differently, including data-protection law. Financial institutions subject to Union internal-governance requirements maintain the logs as part of the documentation kept under the relevant financial-services law.
Define the controlled log boundary with the provider. Record system and version, timestamps, relevant inputs or governed references, outputs, policy decisions, human interventions, errors, and downstream effects needed to reconstruct operation. Apply access control, integrity checks, deletion rules, legal holds, and privacy minimisation to that evidence. Other applicable rules, including data-protection law, still govern how long personal data may be retained.
Article 26 specifies retention and control conditions. Article 12 governs the provider-side logging capability for high-risk systems. The Article 12 logging guide connects event design, traceability, and the provider-deployer handoff.
Complete the notices, registration, and assessment handoffs
Article 26 contains duties that activate for particular deployers or uses. Put each qualifier in the system inventory so the control follows the deployment context. Some deployers also have a separate Article 27 fundamental-rights impact assessment; track that requirement beside the Article 26 controls.
| Article 26 paragraph | Who or what triggers it | Operational action |
|---|---|---|
| 26(7) | An employer puts a high-risk AI system into service or uses it in the workplace. | Inform workers’ representatives and affected workers beforehand under applicable Union and national rules and practice. |
| 26(8) | Public authorities, Union institutions, bodies, offices or agencies, or persons acting on their behalf deploy an Annex III system covered by Article 49(3). | Register the deployer, select the system, and register its use in the Article 71 EU database; refuse use and inform the provider or distributor when the required registration is missing. |
| 26(9) | A GDPR Article 35 or Law Enforcement Directive Article 27 data-protection impact assessment is required. | Use the provider’s Article 13 information as an input to that assessment. |
| 26(11) | An Annex III high-risk system makes or assists decisions related to natural persons. | Inform those persons that they are subject to use of the high-risk AI system, subject to the law-enforcement rule stated in the paragraph. |
| 26(12) | A competent authority acts in relation to the high-risk system. | Cooperate and retain the request, response, materials supplied, owner, and dates. |
Treat post-remote biometric identification as a specialist path
Article 26(10) creates a detailed path for law-enforcement deployers using high-risk post-remote biometric identification in a targeted criminal investigation. It requires authorisation ex ante, or without undue delay and no later than 48 hours, from a judicial authority or an administrative authority whose decision is binding and subject to judicial review. The paragraph also covers a narrow exception for initial identification based on objective and verifiable facts directly linked to the offence, strict necessity, stopping and deleting data after rejected authorisation, limits on adverse decisions based solely on output, documentation in the police file, availability to authorities, annual reporting, and the option for Member States to adopt stricter rules.
Handle this path with specialist legal and operational review for the relevant Member State. Keep it separate from the ordinary Article 26 checklist because its authorisation, documentation, data, and reporting requirements are specific.
Understand the penalty tier without turning it into a forecast
Article 99(4)(e) places non-compliance with Article 26 in the tier of administrative fines up to EUR 15 million or, for an undertaking, up to 3% of total worldwide annual turnover for the preceding financial year, whichever is higher. Article 99(6) uses the lower of the percentage and fixed amount for SMEs, including start-ups. Regulation (EU) 2026/1744 adds the same lower-cap treatment for small mid-cap enterprises.
The final amount depends on national enforcement rules, procedural safeguards, and the circumstances listed in Article 99(7), including gravity, duration, affected people, responsibility, technical and organisational measures, cooperation, notification, intent or negligence, and mitigation. Use the tier to set governance priority. Counsel should assess exposure for a specific infringement.
Run the Article 26 checklist against live operation
A useful readiness check follows one deployed system from role analysis through a real run and its retained evidence. Download the Article 26 deployer runtime checklist and assign an owner and evidence link to every applicable item.
- Scope: confirm deployer role, high-risk path, applicable date, legacy-system treatment, and related Article 4, Article 27, Article 50, data-protection, employment, and sector rules.
- Prepare: pin instructions and versions; assign oversight; define input controls, monitoring thresholds, suspension authority, incident contacts, retention, notices, registration, and authority cooperation.
- Exercise: run a representative case, an oversight intervention, an invalid-input case, a risk-triggered suspension, a provider-unreachable incident drill, and a log-retrieval test.
- Inspect: reconcile the run, policy outcome, human decision, provider communication, downstream effect, automatic logs, and evidence export by stable identifiers.
- Approve: record gaps, owners, remediation dates, residual limitations, and the accountable person who accepts the readiness verdict.
Map the work into KLA Control Plane
KLA Control Plane can hold the operating records used in an Article 26 program. Policy Builder owns policy rules and Simulation. Decision Desk owns human Decision Requests and durable decision receipts. Lineage Explorer reconstructs a governed execution. Evidence Room creates and verifies Sealed Evidence Bundles from scoped records. These product objects support an evidence path; the deployer still owns classification, legal interpretation, control design, operation, and regulatory decisions.
A practical mapping starts with the Article 26 checklist. Connect each requirement to its business owner, provider instruction, policy or procedure, runtime signal, human decision, Lineage Record, retention class, incident path, and evidence artifact. Test the mapping on the deployed system and keep the observed gaps. The Evidence Room sample shows the export shape available for an evidence review.
| Article 26 work | KLA object | Evidence question |
|---|---|---|
| Instruction-bound use and input rules | Policy Builder rule and Simulation result | Which version evaluated the action, and what outcome did it produce? |
| Human oversight | Decision Request and decision receipt in Decision Desk | Who had authority, what context did they review, and what did they decide? |
| Monitoring and investigation | Lineage Record in Lineage Explorer | What happened in order, with which system, policy, tools, and effects? |
| Retained review package | Evidence Factory Job and Sealed Evidence Bundle in Evidence Room | Which scoped records were packaged, omitted, and independently verified? |
Frequently Asked Questions
Does Article 26 apply to every organisation using AI?
Article 26 applies to deployers of high-risk AI systems. Other rules can apply across risk tiers, including the Article 4 AI-literacy duty and specified Article 50 transparency duties. Confirm the organisation’s role and the system’s Article 6 classification first.
When do Article 26 deployer obligations apply after the 2026 amendment?
Regulation (EU) 2026/1744 moves Chapter III Sections 1, 2, and 3 to 2 December 2027 for Article 6(2) and Annex III systems, and to 2 August 2028 for Article 6(1) and Annex I systems within the applicable Article 2 scope. Amended Article 2(2) excludes Article 26 from the rules that apply to Section B Annex I systems through that route. Article 111(2) contains transition rules for earlier systems and a 2 August 2030 endpoint for high-risk systems intended for public-authority use.
How long must a deployer keep Article 26 logs?
Article 26(6) requires automatically generated logs under the deployer’s control to be kept for a period appropriate to the intended purpose and for at least six months, unless other applicable Union or national law provides differently. The retention design also has to respect data-protection and sector rules.
What makes human oversight operational under Article 26?
Assign identified natural persons with the competence, training, authority, and support needed for the system and use. Define their decisions, access, intervention and suspension rights, coverage, escalation route, and evidence. Test those arrangements on representative cases.
Does buying a compliant high-risk AI system satisfy the deployer duties?
A provider supplies the system, instructions, logging capability, and provider-side controls required by the Act. Article 26 assigns separate duties to the deployer for how the system is used, overseen, monitored, suspended, logged, communicated, and supported in its operating context.
Does KLA certify Article 26 compliance?
KLA Control Plane uses Policy Builder for policy rules, Decision Desk for a Decision Request, Lineage Explorer for a Lineage Record, and Evidence Room for a Sealed Evidence Bundle. Those records can support an Article 26 control and evidence program. Classification, legal conclusions, operating controls, and the compliance determination remain with the deployer and its advisers.
Key Takeaways
Article 26 turns use of a high-risk AI system into an operating responsibility. The deployer has to know the system’s instructions and boundaries, assign capable people with authority, control the inputs it owns, monitor operation, suspend risky use, route incidents, retain controlled logs, deliver the required notices, complete conditional registration and assessment work, and cooperate with authorities. Regulation (EU) 2026/1744 gives teams a revised calendar. Use that time to exercise the controls on real runs and collect the evidence each owner will need.