EU AI Act high-risk obligations, what they require

What the EU AI Act high-risk obligations require from your organization

If a customer, contract or regulator now expects AI Act compliance, the high-risk rules in Chapter III Section 2 (Articles 8 to 15) apply from 2 December 2027 for Annex III systems and from 2 August 2028 for Annex I product systems, following Regulation (EU) 2026/1744. Those dates give you time, but the work of building documentation, logs and oversight arrangements takes longer than the time remaining, so the planning decision is needed now. Start by establishing which role you hold, provider or deployer, and which category your system falls under, because those two facts decide which duties apply to you.

Your organization owns its controls. It decides how risk is managed, how data is governed, how human oversight works and who answers for the system. An implementation partner can prepare the systems, configure logging, assemble technical documentation and build the evidence trail, but it does not certify your system. Only an independent assessor or, for the systems that require one, a notified body issues conformity outcomes. Ask any partner to put in writing which artifacts it will produce, which parts remain your staff's responsibility, and which external body will review the result.

Providers and deployers carry different sets of duties under the same articles. Providers must meet the Article 9 to 15 requirements, run a quality management system and keep technical documentation and the declaration of conformity for 10 years. Deployers must follow the provider's instructions, assign competent human oversight, keep logs for at least six months and inform workers and affected people. A deployer that rebrands, substantially modifies or repurposes a system into high-risk use takes on the provider's duties under Article 25(1). Confirm this boundary with your contracts before you start building evidence, because a gap in either direction leaves a duty without an owner.

Which Articles 8 to 15 requirements every high-risk system must meet

Articles 8 to 15 set out the design and documentation requirements that every high-risk AI system must meet before it is placed on the market. The seven requirements below work as one system: the risk management process feeds the data, documentation, logging, instructions, oversight and testing that an assessor will expect to see together.

Risk management system

Article 9 asks the provider to run a continuous, documented process that identifies known and foreseeable risks to health, safety and fundamental rights, estimates them, puts mitigations in place and tests whether those mitigations work. The process must run across the full lifecycle, not once at launch. An assessor will look for a risk register tied to intended purpose, residual risk decisions with named owners, and records of how risks changed after each release.

Data and data governance

Article 10 requires that training, validation and testing datasets are subject to governance practices suited to the system's purpose. Teams must document data origin, collection, labelling, cleaning, and assumptions about the people and contexts the data represents, and examine gaps and bias. Assessors typically ask for dataset cards, lineage records, bias examinations and the rules used to decide which data was excluded.

Technical documentation under Annex IV

Article 11 requires technical documentation, structured according to Annex IV, that lets authorities judge conformity before the system reaches the market and keep it current afterward. It covers the system's design, development, intended purpose, performance and the risk management outputs. SMEs and small mid-caps may use a simplified Commission form. The file should be kept in one controlled repository with version history that matches each released build.

Automatic logging

Article 12 requires high-risk systems to record events automatically over their lifetime, so that outputs can be traced and risky situations identified. Logs should capture the period of use, reference data where relevant, and the inputs that led to a match or decision. Assessors will check that logging is switched on by default, protected against tampering and retained in a way that supports investigations after an incident.

Instructions for deployers

Article 13 requires the provider to supply clear instructions so that deployers can use the system correctly and interpret its outputs. The instructions must state the intended purpose, known limitations, accuracy levels, foreseeable misuse, and the measures needed for human oversight and log management. For a deployer, this document is the baseline for the Article 26 duties. Check that the instructions match the system as shipped and are updated with each material change.

Human oversight design

Article 14 requires the system to be designed so that natural persons can understand its capabilities and limits, monitor it, interpret its outputs and, where needed, override or stop it. The design must account for automation bias, meaning the tendency to accept machine output without checking it. Evidence includes interface designs, override and stop controls, training materials for overseers and test results showing that operators can actually intervene.

Accuracy, robustness and cybersecurity

Article 15 requires an appropriate level of accuracy, robustness and cybersecurity, consistent across the lifecycle. Accuracy metrics must be declared in the instructions and tested against the intended purpose. Robustness covers errors, faults and inconsistent behaviour, and cybersecurity covers attacks that target the data, the model or the surrounding infrastructure, including data poisoning and adversarial inputs. Assessors look for test reports, declared metric values, and security testing records for each release.

Provider duties versus deployer duties for high-risk systems

A provider is the party that develops a high-risk AI system, or has it developed, and places it on the EU market or puts it into service under its own name or trademark. Before placement, the provider must have a quality management system in place, complete conformity assessment, sign an EU declaration of conformity, affix CE marking and register Annex III systems in the EU database under Article 16. The provider then keeps technical documentation, QMS records and the declaration for 10 years under Articles 18 and 47, and runs post-market monitoring under a plan kept in the technical file.

Quality management system: a documented system covering design, development, testing, data handling, risk management, post-market monitoring and incident handling.
Conformity assessment: most Annex III systems use internal control, while some biometric systems and Annex I products need a notified body.
Declaration and CE marking: the provider signs the EU declaration of conformity and affixes CE marking before the system reaches the market.
EU database registration: Annex III systems are registered in the EU database before placement.
Serious incident reporting: reports go to the market surveillance authority within 15 days, 10 days for a death, and 2 days for critical infrastructure disruption or widespread infringement.

Confirm with your counsel and notified body, if one applies, which evidence package each market surveillance authority will expect.

How a high-risk system moves from build to the EU market

The sequence runs from confirming that the AI Act applies to a system, through the documents and controls that show it meets Articles 8 to 15, to the declaration, CE marking and registration that allow it onto the EU market. Each phase produces a named output that the next phase depends on.

Confirm scope and classify the system
The organization first establishes that it is a provider or deployer under the Act, that the system is an AI system within the definition, and that it falls under Annex III or is a safety component or product covered by Annex I. The classification decision includes whether the Article 6(3) exemption is claimed and why. Legal or compliance owners sign the classification record, which states the role, the high-risk route and the applicable Chapter III section. The output is a documented classification decision that names the intended purpose, because the purpose drives the route. Confirm the applicable dates against the 2026 amendment before planning work.
Run a gap assessment against Articles 8 to 15
Engineering, product and compliance staff compare the current system and its development practice against each requirement in Chapter III Section 2: risk management, data governance, technical documentation, logging, instructions for use, human oversight, and accuracy, robustness and cybersecurity. The assessment records which requirements are met, partly met or missing, with the evidence that exists for each. Teams often find that logging and documentation are the largest gaps in systems built without regulated delivery. The output is a gap register with an owner and a remediation item for every open requirement.
Establish the risk management system and data governance
The provider sets up a documented, iterative risk management process that identifies foreseeable risks to health, safety and fundamental rights, estimates and evaluates them, and records the measures taken, including residual risk. In parallel, data governance covers how training, validation and testing datasets are sourced, labeled, examined for bias and documented. Risk owners and data stewards sign off each cycle. The output is a risk register, a dataset record set and test results that link each identified risk to a control or an accepted residual risk. Harmonised standards on risk management were still in development in mid-2026, so confirm the current status of any standard you intend to cite.
Compile the technical file under Annex IV
The provider assembles the technical documentation that describes the system's general characteristics, design and development process, monitoring and control, performance metrics, and the risk management and post-market monitoring plans. Documents are version-controlled and tied to the release they describe. The technical file is kept for 10 years after the system is placed on the market, under Articles 18 and 47. The output is a versioned technical file that an assessor can read without interviewing the engineering team, with a reference to the release it covers. Simplified forms are available to SMEs and small mid-caps under Article 11(1).
Implement the quality management system
The provider documents a quality management system covering the regulatory compliance strategy, design and development control, testing and validation procedures, data management, incident handling, post-market monitoring, record keeping and resource management, as Article 17 requires. Process owners run the procedures and keep the records that show they are followed. EN 18286:2026 on quality management was cited in the Official Journal on 14 October 2026 and gives a presumption of conformity for the elements it covers. Use it as the structure where it fits, and confirm which of its elements apply to your organization. The output is a QMS manual, procedures and a record set that matches the procedures.
Complete the conformity assessment route
For most Annex III systems, the provider completes an internal-control assessment under Annex VI, which checks the QMS and the technical file against the requirements. Some biometric systems and Annex I product systems need a notified body under Article 43, and the notified body reviews the QMS and technical documentation and issues the certificates it is responsible for. The assessment body, not the consultant, reaches the conformity finding. The output is either an internal assessment record signed by the provider or a notified body certificate with its validity conditions. Ask a notified body early about its queue and scope, because that step is outside the provider's control.
Sign the EU declaration of conformity
Once the assessment is complete, the provider drafts and signs an EU declaration of conformity stating that the system meets the requirements of Chapter III Section 2. The declaration names the system, the version, the assessment route and any notified body involved. It is kept with the technical file and made available to authorities on request. The signatory should be a person with authority to commit the organization. The output is a signed, dated declaration linked to the specific system version that was assessed. A change that affects conformity may require the assessment to be repeated.
Affix CE marking and register the system
Before placing the system on the market, the provider affixes the CE marking in the manner the Act prescribes and, for Annex III systems, registers the system in the EU database before it is placed on the market or put into service. Registration records the provider, the system and its intended purpose, and it is one of the public-facing duties the Act assigns. Confirm the current database requirements and the exact data fields with the Commission guidance before filing. The output is a CE-marked product or documented marking process and a database entry reference that is stored in the technical file.

Which application dates apply and what happens to systems already on the market

The high-risk rules in Chapter III Sections 1 to 3 now apply from 2 December 2027 for Annex III systems and from 2 August 2028 for Annex I product systems. Regulation (EU) 2026/1744 moved these dates back from 2 August 2026 and 2 August 2027, so any plan built on the original dates needs to be re-baselined. Which date governs a given system depends on whether it falls under Annex III use cases or is a safety component of, or a product covered by, Annex I legislation. Confirm that classification with counsel before you fix a delivery date. The same amendment also touches 2 December 2026 for certain items, which you should check against the EU AI Act timeline page rather than treat as settled here.

Amended Article 111(2) governs systems already on the market. A high-risk system placed on the market before the application dates is covered only if it undergoes significant design changes after those dates, so the design history of each system matters. Ask engineering and product teams to document every release, retraining, change of intended purpose and architecture change, with dates. Then have counsel decide which changes count as significant and whether any of them pulled the system into the amended rules. Keep that record with the technical file, because it is the evidence you will need to justify treating a system as legacy.

Systems intended for use by public authorities are handled differently and must comply by 2 August 2030, even where the general dates would otherwise let them stay on their existing design. If your organization sells to public bodies, or if a public authority deploys a system you supply, add this earlier-than-general obligation to your planning and check whether the system's intended purpose has been extended to public-sector users. Any change that expands the intended purpose or user group should trigger a fresh review of both the legacy position and the 2030 deadline.

Incident deadlines and fines that apply to operators

Operators of high-risk AI systems face fixed clocks for reporting serious incidents, a monitoring plan that must exist before the market test, and fines set as the higher of a fixed amount or a share of worldwide turnover. These cards cover the deadlines, the plan, the penalty tiers and the authorities that enforce them.

Serious incident reporting clock

Article 73 requires providers to report serious incidents involving a high-risk system to the market surveillance authorities. The general deadline is 15 days after the provider becomes aware of the incident. Your incident runbook should assign who starts that clock, who confirms the incident is serious, and which authority receives the report. Confirm with counsel how the clock applies when a deployer is the first to learn of the problem.

Shorter deadlines for severe cases

Article 73 shortens the window for the most serious events. A death must be reported within 10 days, and a serious incident causing critical infrastructure disruption or a widespread infringement must be reported within 2 days. Because these clocks are short, the triage step must be able to run on a weekend. Test the escalation path with a tabletop exercise before the system is live.

Post-market monitoring plan

Article 72 requires providers to run post-market monitoring under a plan written into the technical file. The plan describes how field performance, drift, complaints and logged events are collected and reviewed after launch. The Commission will issue a template for the plan by 2 September 2027. Check the plan against that template when it appears, and assign an owner who can act on the findings.

Fines for operator breaches

Article 99 sets fines for breaches of provider, deployer, importer, distributor or authorised representative obligations at up to EUR 15 million or 3% of worldwide annual turnover, whichever is higher. Fines for misleading national authorities or notified bodies reach up to EUR 7.5 million or 1%, whichever is higher. For a large group, the turnover percentage usually sets the exposure, so finance and legal teams should model it early.

National authorities enforce the Act

National market surveillance authorities enforce the AI Act for AI systems, so the authority in each member state where your system is used or placed on the market is the body that can investigate and fine. Identify these authorities for each country where you operate, and record the contact route in your incident plan. The AI Office handles general-purpose model rules and certain AI systems built on a provider's own model, so check which body applies to your system.

What high-risk compliance costs and who gets paid

This table compares the main cost components of high-risk AI Act compliance, showing who is paid, whether each cost is one-time or recurring, and what drives it up. Use it to see which parts of the work your own staff can carry and which parts you may buy from outside. The Commission's cost figures are covered on the compliance cost page, and any fee depends on the written scope of each engagement.

Cost component	Who is paid	One-time or recurring, and what drives it
Internal engineering and product staff	Your own employees	Recurring. Building logging, data governance, accuracy testing and documentation features; the number of high-risk systems and how often they change drive the effort.
Legal and governance	Your in-house counsel or outside law firms	Mostly one-time for role analysis and contracts, then recurring for policy upkeep. Drivers include the number of roles you hold (provider, deployer, importer) and the number of supplier contracts to amend.
Implementation partner (systems and evidence preparation)	An implementation partner such as DeployOpen, under a written scope	One-time for setup of QMS records, technical documentation and logging, with some recurring support. Drivers include the number of systems, the state of existing evidence and whether the platform is self-hosted in your environment.
Independent assessor or notified body	An independent assessor or a notified body	One-time per assessment route, with reassessment after substantial change. Drivers include whether the system falls under internal control or needs a notified body, and the scope of the review. Only these parties issue conformity outcomes.
Tooling and self-hosted evidence platforms	Software vendors, cloud providers or your own infrastructure budget	Recurring licenses or hosting, plus one-time configuration. Drivers include log volume, retention needs of at least six months for logs and ten years for documentation, and the number of environments.
Post-market monitoring	Your own staff, with optional partner or vendor support	Recurring for as long as the system is on the market. Drivers include the monitoring plan in the technical file, incident volume, and the reporting deadlines for serious incidents.
Quotes and written scope	Partners and assessors issue quotes	Ask each party for a written scope listing systems, deliverables, evidence owners and what is excluded before comparing prices.

What must be in place before a conformity assessment

A conformity assessment tests evidence, not intentions. The six areas below are the working artifacts an assessor or notified body will ask to see, and each one feeds the technical file that Annex IV describes.

System inventory with role and risk tier

Start with a register of every AI system in scope, recording the organization's role for each (provider, deployer, importer or distributor), the intended purpose, the Annex III or Annex I category that applies, and the reasoning behind the risk tier. Record who signed off the classification and when it was last reviewed. Re-check the register whenever a system is rebranded, substantially modified or repurposed, because Article 25(1) can make a deployer the provider. Confirm the tier against current text, since the high-risk dates changed in 2026.

Risk management and data governance records

Article 9 expects a risk management system that runs across the whole lifecycle, and Article 10 expects documented data governance covering training, validation and testing data. Keep dated risk registers, the reasoning behind each mitigation, residual risk decisions and test results tied to specific model versions. For data, record provenance, labelling methods, known gaps and bias examination. Assessors look for a traceable line from each identified risk to a control and a test result.

Logging architecture under organizational control

Article 12 requires automatic logging that supports traceability over the system's life, and Articles 19 and 26(6) require logs to be kept for at least six months under the control of the provider or deployer. Design where logs are written, who can alter them, and how they are exported to storage the organization owns. Test retrieval during a mock incident. Confirm with your platform team that logs survive a vendor change or a hosting migration, because a third party holding the only copy weakens your position.

Human oversight design with named people

Article 14 expects high-risk systems to be designed so that people can understand outputs, monitor operation, intervene and stop the system. Write an oversight design for each system that states the decision points where people review outputs, the signals that trigger escalation, and the authority to override. Name the individuals assigned to oversight and confirm they have the training and the access to do the job. Record the instructions for deployers under Article 13 alongside this design, since deployers depend on it.

Technical file drafted to Annex IV

The technical documentation under Article 11 must follow the content set out in Annex IV, covering the system's general description, development process, monitoring, performance metrics, risk management and changes over time. Draft it as a living document held under version control, with each section pointing to the evidence behind it. Providers keep this file for 10 years under Article 18. SMEs and small mid-caps may use a simplified Commission form under Article 11(1), so confirm eligibility before you plan the work.

QMS aligned to EN 18286:2026

Article 17 requires a quality management system covering the provider's policies, procedures and records. EN 18286:2026 was cited in the Official Journal on 14 October 2026 as the first harmonised standard on quality management, which gives a presumption of conformity when relied on. Other standards, including prEN 18228 on risk management, were still in drafting in mid-2026, so confirm which harmonised standards cover each requirement before you rely on them. Where a standard is not yet available, the QMS must still meet Article 17 directly.

Who does what: your team, an implementation partner and the assessor

Your organization stays accountable for the AI system and for every decision that changes its risk profile. Under the AI Act, the legal duties sit with the provider or deployer you are in relation to the system, and no implementation partner can take them over. Your team decides the intended purpose, accepts residual risk, approves the human oversight design and signs off the documentation that describes the system.

Risk decisions: Choose the intended purpose, accept residual risk and decide whether a change is significant enough to affect the system's status.
Control ownership: Name an accountable owner for each requirement in Articles 9 to 15 and for the provider or deployer duties that apply to your role.
Human oversight: Assign competent people with authority to intervene, and define what they are trained to check.
Sign-off: Approve technical documentation, the quality management records, instructions for use and any declaration before they are relied on.
Incident and reporting decisions: Decide when an event is a serious incident and own the reporting clock under Article 73.

Ask your legal or compliance lead to confirm which role your organization holds for each system before you assign these owners.

How to choose an implementation partner or assessor for AI Act work

Implementation partners prepare systems, controls and evidence, while independent assessors and notified bodies judge conformity. Keeping those roles distinct, and checking experience and scope in writing, is the fastest way to avoid paying for work that the high-risk obligations will not accept.

Confirm the firm's role

Ask whether the firm builds and documents your high-risk system or independently assesses it. A firm that designed the system and then certifies its conformity may lack the independence the assessment needs, so the same firm should not do both for one system unless there is a clear, documented reason. Get the answer in writing before shortlisting, because it determines who signs what in the conformity file.

Ask for Annex IV experience

Request named examples of technical documentation prepared against Annex IV for high-risk systems, and ask who on the team wrote them. Confirm the firm has worked through the Article 9 risk management system, Article 10 data governance and Article 12 logging, not only general security assessments. Ask to see a redacted document outline so you can judge depth before signing.

Check notified body status

Some biometric systems and Annex I products need a notified body, while most Annex III systems use internal control. Confirm which route your system follows, then verify that any body you engage is actually notified for the relevant conformity assessment. Only the notified body or independent assessor issues the certificate; a consultant preparing the file cannot stand in for that step.

Settle who owns the evidence

Ask who keeps the technical documentation, quality management records, logs and the EU declaration of conformity after handover. Providers keep technical documentation, QMS records and the declaration for 10 years, and logs must be kept for at least six months, so these records must remain accessible to your organization even if the partner's engagement ends. Require that all artefacts are delivered in your own repositories.

Fix the scope in writing

Before work starts, require a written scope listing the systems covered, the deliverables, the roles each party carries and the acceptance criteria. Ask how changes to scope are priced and approved, and how the partner will handle a system that moves into high-risk use later. Fixed-scope agreements make it clear what is owed and what remains your responsibility as the provider or deployer.

Questions buyers ask about EU AI Act high-risk obligations

When do the EU AI Act high-risk obligations apply now?

Not yet for most systems. As amended by Regulation (EU) 2026/1744, the high-risk rules in Chapter III Sections 1 to 3 apply from 2 December 2027 for Annex III systems and from 2 August 2028 for Annex I product systems, replacing the earlier dates of 2 August 2026 and 2 August 2027. The Act's other chapters, including the prohibitions and AI literacy duty, already apply. Confirm your system's annex placement first, because that decides which date governs your work.

Do we need a notified body for a high-risk AI system?

Usually not. Most Annex III high-risk systems use internal-control conformity assessment under Annex VI, where the provider checks its own compliance and signs the EU declaration of conformity. A notified body is involved for some biometric systems and for Annex I products under Article 43. Your assessor or legal counsel should confirm the route for your specific system, since the answer depends on its category and whether a harmonised standard is applied in full.

How long does preparation for high-risk obligations take?

The Act does not set a preparation duration, so no timeline can be drawn from it alone. What drives the effort is the number of high-risk systems, how much technical documentation already exists, the state of your quality management system, and the data and logging gaps in each system. Ask your assessor or implementation partner for a phased plan keyed to the 2027 and 2028 application dates, and confirm the schedule against the amended text before committing.

What does the work need from our staff?

Expect demands on several functions at once. Engineering owns the risk management system, data governance, logging and accuracy testing. Product and compliance own the instructions for use, the intended purpose statement and the quality management system. Legal reviews the declaration and contracts along the value chain, and a named human oversight owner must be able to intervene in the system. Early in the program, ask who signs off each Article 8 to 15 requirement so that gaps have an accountable owner.

Can we prepare for high-risk obligations ourselves?

Yes, a provider can prepare the system, controls and evidence in-house, and internal-control conformity assessment does not require an outside party. Outside help typically covers gap analysis, building the technical file, testing logging and robustness, and running the assessment workflow. Only an independent auditor or notified body issues conformity or certification outcomes, so any consultant can prepare evidence but cannot certify it. DeployOpen prepares systems and evidence on your infrastructure under a written, fixed scope.

What happens to AI systems already on the market?

Under amended Article 111(2), systems already on the market before the application dates are generally covered only after significant design changes. Systems intended for public authorities must comply by 2 August 2030. Any substantial modification restarts the question, so track changes to models, training data and intended purpose carefully. Confirm with counsel how your change log maps to the significant-change test, because the boundary decides whether a legacy system falls under the new requirements.

How long must we keep logs and documentation?

Providers keep technical documentation, quality management system records and the EU declaration of conformity for 10 years under Articles 18 and 47. Providers and deployers keep logs under their control for at least six months under Articles 19 and 26(6). Longer periods may apply under other laws, such as sector rules or data protection law, so confirm the retention schedule with counsel. Set storage, access controls and deletion rules for logs before go-live so the six-month minimum is met reliably.

What do the fines look like for high-risk breaches?

Breaching provider, deployer, importer, distributor or authorised representative obligations carries fines of up to EUR 15 million or 3% of worldwide annual turnover, whichever is higher, under Article 99. Misleading authorities carries up to EUR 7.5 million or 1%, also whichever is higher. The fine ceiling scales with turnover, so a larger group faces a higher maximum. National market surveillance authorities enforce these rules for AI systems, which is why documented evidence matters during any inquiry.

How DeployOpen prepares high-risk systems and evidence for assessment

DeployOpen is a Chainscore Labs company that plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure. For EU AI Act high-risk obligations, we prepare the systems, controls and evidence that an independent assessor will review, while your organization keeps ownership of its controls and any conformity decision.

How we scope

We confirm which AI systems are in scope and whether each one is a provider or deployer case under the Act.
The written scope lists the Article 9 to 15 requirements, the systems covered and the evidence we will produce.
Engagements are fixed-scope, so deliverables and timelines are agreed in writing before any work begins.

How we build

We configure logging, access controls and monitoring on the self-hosted platform inside your cloud or data center.
We draft the risk management, data governance and technical documentation records mapped to Annex IV content.
We run security and accuracy testing on the system and record the results, findings and remediation steps.

How we hand over

You receive the evidence pack, configuration baselines, test records and runbooks in formats your assessor can review.
We walk your compliance and engineering staff through each artifact and document who owns it after handover.
Retention settings for logs and records are set to match the periods your organization must keep them.

How we support

Ongoing support, upgrades and continuous security testing are available as retainers after handover.
Retainers can cover post-market monitoring inputs, incident response support and updates to the technical file.
Independent auditors and certification bodies issue any report or certificate, and DeployOpen does not.