Article 26 deployer obligations for high-risk AI systems

What Article 26 deployer obligations ask you to do before and during use

If you have just learned that a system you operate is high-risk, Article 26 sets out what you must do as a deployer: use the system as the provider instructed, put trained people in charge of human oversight, check that the data you feed it is fit for purpose, watch it in operation, keep its logs, tell the people affected, and, if you are a public authority, register it. These duties apply to a system you did not build, so your first job is to obtain the provider's instructions for use and read them against your own workflows. Article 26(1) and (2) require you to use the system in line with those instructions through technical and organizational measures, and to assign oversight to people who have the necessary competence, training, authority and support. The risk here is a team that runs the tool the way the sales deck describes it rather than the way the provider limited it. Confirm now who in your organization holds that oversight role and whether they have documented training.

Article 26(4) applies only where you control the input data, and then you must make sure it is relevant and sufficiently representative for the system's intended purpose. Article 26(5) requires you to monitor operation, suspend use if the system presents a risk, and inform the provider and the market surveillance authority, and to report serious incidents to the provider first. Article 26(6) requires you to keep logs under your control for at least six months unless other EU or national law sets a longer period, so check which logs the system writes and where they are stored before go-live. Article 26(7) requires employers to inform workers' representatives and affected workers before workplace use, and Article 26(11) requires you to inform people subject to decisions made or assisted by an Annex III system. Article 26(8) requires public authority deployers to register under Article 49, and Article 26(9) requires you to use the provider's information for GDPR data protection impact assessments.

Deployers often find these duties harder than provider duties because much of the evidence sits with the provider: the technical documentation, the risk management records and the instructions for use. Ask your provider in writing for the instructions and the log format, and agree how incidents will be shared. Breach of these obligations falls under Article 99, where the fine for most operator obligations can reach EUR 15 million or 3% of total worldwide annual turnover, whichever is higher, with the lower figure applying to SMEs.

Which deployers, systems and teams Article 26 reaches

Article 26 applies only after four scoping questions are answered: who you are under the Act, how your system is classified, where its output is used, and whether you are a public authority. Each answer changes which duties apply and who inside the organization owns them.

Deployer status under the Act

Article 26 binds deployers, meaning organizations that use an AI system under their own authority. An organization that only buys a system for internal use is usually a deployer, but a company that builds or substantially changes a system may be treated as its provider. Check who designed the intended purpose, who controls the system's configuration, and whose name appears on the system in use. Record the answer in your AI system inventory.

High-risk classification under Article 6

Article 26 duties depend on whether the system is high-risk, and Article 6 decides that. Annex III lists use cases such as employment, credit scoring and essential services, while Annex I covers AI that is a safety component of regulated products. Confirm the system's intended purpose against each Annex entry, and check the Article 6(3) exemption before concluding that a listed use is out of scope. Document the reasoning, because the assessor will ask for it.

EU use or EU output under Article 2

The Act reaches deployers established in the EU, and also non-EU deployers whose AI output is used in the EU. A hiring tool run from a US data center that ranks candidates for an EU subsidiary is in scope. Map where decisions are made, where the people affected are located, and which entities receive the output. Hosting location alone does not settle the question.

Public authority deployers and registration

Public authority deployers have an extra duty under Article 26(8). They must register the system under Article 49 and must not use a high-risk system that is missing from the EU database. Confirm whether your organization is a public authority, a body acting on its behalf, or a private entity providing a public service, because the registration duty depends on that status. Ask legal counsel to confirm the position in writing.

Operations, HR and clinical or credit users

Article 26 requires human oversight by people with the necessary competence, training, authority and support. In practice this means the staff who read outputs and act on them, such as recruiters, loan officers, clinicians or claims handlers. Identify each role that can accept, override or stop an output, and confirm each one has documented training. Staff who only receive outputs without the authority to challenge them still need a defined escalation path.

Security, legal, procurement and third parties

Security owns logging, access and incident response, legal owns worker information and the Article 26(9) use of provider information for data protection impact assessments, and procurement owns the contract terms that let you meet instructions for use. Third parties include the provider, hosting partners and integrators, and each may change the system's purpose or configuration. Ask providers and integrators to confirm, in writing, which duties they carry and which fall to you.

How an assessor tests each Article 26 duty

This table compares each group of Article 26 deployer duties against the test an assessor usually runs, the evidence requested and the findings that appear most often. Read it as a checklist of what the deployer must be able to show operating, not what software it has installed. The main takeaway is that paper roles and untested procedures fail more often than missing tools.

Duty group	Test approach	Evidence requested	Common findings
Use per instructions for use (Art. 26(1))	Document review, then walkthrough of how the system is configured and used day to day	Provider instructions for use on file, internal procedures tying use to those instructions, records of deviations and changes	Instructions never obtained from the provider, or obtained but not mapped to internal procedures
Human oversight assignment (Art. 26(2))	Interview named overseers, then check their authority in practice	Appointment records, role descriptions, competence and training records, evidence of authority to halt or override output	Oversight roles assigned on paper with no documented authority, training or time allocated
Input data relevance and representativeness (Art. 26(4))	Sample of input data sets, review of how the deployer selects or controls inputs	Data specifications, data quality checks, records of checks against the intended use population	Deployer controls inputs but has no criteria for relevance or representativeness
Monitoring, suspension and reporting of risk (Art. 26(5))	Walkthrough of the monitoring process, then sample of past alerts and any suspensions	Monitoring procedure, alert records, suspension decisions, notices sent to the provider and the authority	No defined trigger for suspension, or monitoring that does not reach the people who can stop the system
Serious incident reporting to the provider (Art. 26(5))	Tabletop interview on the incident path, then review of any incidents logged	Incident procedure, contact details for the provider, incident records with dates and notices sent	Procedure exists but names no owner, or the provider was never told of a logged incident
Log retention and access (Art. 26(6))	System walkthrough to confirm logs are generated, retained and reachable by the deployer	Retention settings, log samples covering at least six months where the deployer controls them, access records	Logs sit with the provider or a vendor and the deployer cannot retrieve them, or retention is shorter than required
Worker and affected person notices (Art. 26(7) and 26(11))	Interview with workers' representatives and HR, review of notice texts and timing	Copies of notices, dates of delivery to workers' representatives, records of notices to affected people	Notice sent after deployment began, or no record that affected people were informed
Public authority registration (Art. 26(8))	Document review of the registration record and of the system inventory	EU database registration reference, inventory showing each system checked against the database	Public body uses a high-risk system that is missing from the EU database
Provider information for GDPR DPIAs (Art. 26(9))	Review of the DPIA file for each system and interview with the data protection officer	DPIA documents citing the provider information used, dated and signed off	DPIA written without using the provider's instructions or technical information

Implementing Article 26 in sequence, with the output of each step

This sequence takes a deployer from classification through registration in the order Article 26 implies, with a named output at each step. Each output is a document or setting that an assessor can ask to see, so the evidence file reflects what the organization actually does.

Confirm classification and deployer role
Confirm that the system is high-risk under the Act's classification rules and that your organization acts as a deployer. A deployer that changes the intended purpose or puts its own name on the system can take on provider duties under Article 25, so check those triggers before go-live. Record the classification rationale, the intended purpose, the role decision and the named owner who approved both. The output is a signed classification memo that links the system to its entry in your AI system inventory, which the assessor will trace first.
Collect provider instructions and DPIA inputs
Obtain the provider's instructions for use and the information the provider supplies for data protection impact assessments under the GDPR, as Article 26(9) expects. Compare the planned use with the intended purpose and conditions stated in those instructions, and send any gap to the provider in writing. Keep each document with its version number and date, then link it to the DPIA file. The output is an instructions register and a use statement that matches the deployment, which the assessor will compare against what the system does in production.
Name human overseers and record competence
Assign each high-risk system to named people who hold the competence, training, authority and support needed to oversee it, as Article 26(2) requires. Record the authority to pause the system or override its outputs, the training each overseer has completed, and the channel through which they reach the provider for support. Repeat the review when staff move roles or the system changes materially. The output is a signed oversight assignment for each system, with training records attached, which the assessor will test by asking an overseer to explain how they would intervene.
Define input data controls and review method
Where your organization controls the input data, write a data control standard that states what data is relevant and sufficiently representative for the intended purpose, as Article 26(4) requires. Specify the sources, exclusion rules, sampling method, the reviewer and the review cadence, and confirm the cadence with your risk owner. Run the first review before use and record the findings. The output is the data control standard and dated review records showing that inputs were checked against it and that gaps were corrected or escalated.
Set monitoring, suspension and escalation paths
Monitor the system against its instructions and the risk indicators you defined, and set the conditions under which use must stop. Article 26(5) requires you to suspend use, inform the provider and the market surveillance authority where the system presents a risk, and report serious incidents to the provider first. Document each path, the decision owner and the contact at each end, then rehearse the path with a tabletop exercise. The output is an escalation runbook with the rehearsal record, which the assessor will use to check that the steps can actually be followed.
Configure log capture and retention
Configure the logs under your control so they are captured and kept for at least six months, unless other Union or national law requires a different period, as Article 26(6) requires. For self-hosted components, enable the audit features they provide, such as Nextcloud's admin_audit app writing to audit.log, OpenBao audit devices for API requests, or Langfuse traces for LLM calls. Confirm that each log contains the fields your assessor will need, and restrict who can read or alter it. The output is a retention setting and a log inventory that shows where each record lives and how it is protected.
Prepare worker and affected person notices
Before first use at the workplace, inform workers' representatives and the affected workers, as Article 26(7) requires. Where an Annex III system makes or assists decisions about natural persons, inform those people under Article 26(11). Draft the notice text, choose a delivery method that reaches each group, and keep a record of who received the notice and when. Confirm with employment counsel where national consultation rules add steps. The output is a notice template and a dated distribution log that shows each recipient group was informed before use.
Register where the deployer is a public authority
If your organization is a public authority, public body or EU institution acting as a deployer, register the system in the EU database under Article 49 before use. Article 26(8) also bars you from using a high-risk system that is missing from that database. Check that the registered details match the classification memo, the instructions and the inventory entry. The output is a registration confirmation for each system and a reconciliation record showing that the database, the inventory and the live deployment agree.

Evidence artifacts that show Article 26 compliance and how to keep them current

Article 26 is tested through records, not intentions. The six artifacts below are the ones an assessor or market surveillance authority is most likely to ask for, and each needs a named owner, a version history and a documented review cycle to remain usable between audits. Set the cadence and retention periods yourself and write them into your AI governance policy.

Instructions for use on file

Keep the provider's instructions for use as a controlled document, recording the version, the date received and the date your organization last checked it against the system's configuration. Store the copy in your document management system with a named owner and a change log, so you can show which version governed each deployment. Check that every update from the provider triggers a review of your internal procedures. Assessors usually find a copy in someone's inbox, with no version or date, and no evidence that the team running the system followed it.

Human oversight assignment and training

Record which named people oversee each high-risk system, what authority they hold to override or stop it, and what competence and support they have received. Keep training records with dates, content and attendance, and link each one to the role description. Update the assignment when staff change, and test whether the overseer can actually interpret outputs and intervene. The common gap is an oversight role named in a policy but held by someone with no training record, no stop authority and no time allocated to the task.

Input data specifications and sampling reviews

Where your organization controls the input data, document the specification for relevance and representativeness, the data sources, and the sampling method you use to check them. Record each review with the sample taken, the findings and the corrective action. Version the specification whenever a data source or population changes. Assessors often find a specification written at go-live and never revisited, even after the input population shifted, leaving no evidence that data quality was monitored.

Monitoring and incident records with escalation timestamps

Keep monitoring logs that show who reviewed system behavior, what risk indicators were checked and when. For each incident or suspected risk, record the time of detection, the decision to suspend use, the notice sent to the provider and any report to the authority, with timestamps. Test the escalation path at least once so the record shows it works. The usual gap is an incident handled informally in chat or email, with no timestamp showing when the deployer first knew of the risk, which is the point an assessor will examine first.

Log retention configuration and access records

Document where logs generated under your control are stored, how long they are retained, who can read or change them, and how that access is recorded. Set the retention period to at least the minimum in Article 26(6), or a longer period required by other Union or national law. Keep the configuration files and a record of changes to them. Self-hosted platforms can supply part of this evidence. For example, Nextcloud's admin_audit app writes to audit.log, and OpenBao audit devices keep JSON logs of API requests. Confirm each setting in your own environment, because a default path or rotation policy can delete records before the retention period ends.

Notices to workers and affected people

Keep a copy of each notice sent to workers' representatives and affected workers before workplace use, and to people subject to decisions under Article 26(11). Record the date, the recipients, the channel and any acknowledgment, and file the notice against the system's version. Recheck notices when the system changes materially. Assessors commonly find a notice drafted but never sent, or a distribution list that omits affected people, so ask for proof of delivery rather than the draft.

Why the six-month log rule is a configuration question, not a policy statement

Article 26(6) requires a deployer of a high-risk AI system to keep the logs under its control for at least six months, unless other Union or national law sets a different period. That sentence only works if the deployer can answer four questions about its own system: which logs the system generates, where they are written, who can reach them, and whether another law requires a longer period. A written retention policy that says "six months" does not answer any of them. Start with an inventory of log sources for each high-risk deployment, including application logs, administrative audit trails, model input and output records, and any tracing data a monitoring tool captures. For each source, record the storage location, the retention setting, the access groups and the deletion process. Where the deployer runs the platform itself, these are settings it can change. For example, a self-hosted collaboration platform may write admin audit events to a file in its data directory unless an administrator redirects them, and the retention of that file is then whatever the operator's backup and rotation job enforces. Confirm each setting in the environment in use, not only in the vendor documentation.

The common failure is a provider that holds the logs in its own hosted service, while the deployer has no export path, no read access and no contractual right to retrieve records when it needs them. The deployer then cannot show that logs under its control exist, and it cannot support an investigation or a complaint if the provider's retention ends or the relationship does. Close this gap in the contract before deployment. Ask for a defined list of log types, a format the deployer can read without the provider's tooling, an export mechanism with a stated delivery method, a retention period no shorter than the deployer's obligation, and notice before any deletion. Also agree who responds to an authority request for logs and within what period. If the provider cannot commit to these terms, the deployer should either move the logs into storage it controls or treat the platform as unsuitable for that use. Confirm with counsel whether any other Union or national law applies to the sector, because it may set a longer period that overrides the six-month minimum.

What meeting Article 26 costs in money and effort

This table compares the main cost and effort components of Article 26 deployer compliance, marks each as one-time or recurring, and lists what pushes it up or down. Read it as a checklist for scoping a written quote, since no currency amount or duration is supplied for these items and the real figures depend on your systems and sector.

Cost component	One-time or recurring, and who is paid	What drives it up or down
Legal and classification review	One-time per system, plus periodic review. Paid to in-house counsel or outside lawyers, and to a consultant if one is engaged	Up: number of systems and unclear Annex III fit. Down: an existing AI inventory and documented classification reasoning
Provider contract changes for instructions, logs and incident cooperation	One-time negotiation, then recurring checks at renewal. Paid to internal procurement and legal	Up: many vendors, closed provider terms, no log export. Down: standard addenda covering Article 26(1), (6) and (5) reporting
Human oversight design and training	One-time design, recurring refresher training. Paid to internal staff, HR or training providers	Up: high autonomy, many users, decisions about people. Down: reuse of existing role-based access and training records
Input data controls and review	Initial setup, then recurring sampling reviews. Paid to data engineers and domain owners	Up: deployer-controlled data pipelines, broad source mixes. Down: fixed input sources and documented relevance checks
Monitoring and incident handling	Setup one-time, operations recurring. Paid to platform, security and operations teams	Up: many alert sources, customer-facing use. Down: shared SIEM and ticketing, defined suspension and reporting runbooks
Log storage and retention engineering	Build one-time, storage and review recurring. Paid to platform engineers and infrastructure	Up: long retention beyond six months, high request volume, sensitive payloads. Down: existing log pipelines and tiered storage
Worker and affected person notices	One-time notice drafting, recurring for new systems. Paid to HR, works councils liaison and legal	Up: many workplaces and works council consultation. Down: existing employee communication channels
Registration effort for public authorities	One-time per system, updated on change. Paid to internal compliance staff	Up: number of systems and data fields required. Down: a maintained system register that already holds the required data
External review, testing or auditor sampling time	Periodic. Paid to independent auditors or assessors, and to testers if scoped	Up: sampling depth, poor evidence trails. Down: evidence captured by default in logs and tickets

Which self-hosted open-source tools can produce Article 26 evidence

Article 26 duties turn on records: what the system did, who reviewed it, what data went in, and how long logs were kept. The four tools below can produce parts of that record when they run inside your own infrastructure. None of them makes a system lawful or replaces the competent people Article 26 requires you to assign.

Nextcloud admin_audit logs

The admin_audit app records additional event information to audit.log in the data directory, or to a path set with logfile_audit. For Article 26(6), this file can support the record of who accessed or changed a system that holds high-risk outputs or data, provided you retain it under your control for at least six months unless other law requires longer. Confirm that the events you need, such as access to decision records, are actually captured in your configuration, and that the log is protected from alteration.

OpenBao audit device logs

OpenBao audit devices write a detailed JSON record of every API request and response, including errors, with most sensitive values hashed using HMAC-SHA256. This supports Article 26(2) by showing who requested secrets or access to the systems that feed a high-risk workflow. Hashing protects credentials, but it also means reviewers cannot read those values directly, so plan how you will match hashed entries to people during an inquiry. Confirm which requests your deployment records and where the devices write their logs.

garak model probe reports

garak probes language models for hallucination, data leakage, prompt injection, misinformation, toxicity generation and jailbreaks. It writes a JSONL report of every attempt and evaluation, plus a hit log of attempts that found a vulnerability. These files support Article 26(5), where you monitor for risk before continuing use, and give evidence of input and output testing before changes go live. A clean run covers only the probes executed against the configuration tested, so treat results as a snapshot and rerun after model or prompt changes. Confirm the probe set matches your system's risks.

Langfuse operation traces

Langfuse records each trace of a request, including LLM calls, retrieval steps, tool executions and custom logic, with timing, inputs, outputs, token usage and metadata. For deployers that control input data under Article 26(4), traces show what data reached the model and what it returned, which supports review of relevance and representativeness and the monitoring evidence Article 26(5) expects. Traces can contain personal data, so check retention and access controls under GDPR before enabling full capture. Confirm that your application sends the trace fields you need, since capture depends on instrumentation.

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

Your organization is the deployer, so it owns every decision that Article 26 places on a deployer. That includes deciding whether a system is high-risk in the first place, assigning human oversight to named people with the competence and authority to act, and deciding when to suspend use. Legal and operational judgment stays inside the organization, even when outside advisers inform it.

Classification decision: Record whether each AI system falls under Annex III and why, and have a named owner sign off on the conclusion.
Human oversight assignment: Name the people who oversee each system, confirm they have the necessary competence, training, authority and support, and document it.
Instructions for use: Hold the provider's instructions in a controlled file and make your own use conform to them.
Worker and affected person notices: Decide the wording, timing and recipients of notices to workers' representatives, affected workers and affected people.
Suspension decision: Decide when to pause a system that presents a risk, and who informs the provider and the authority.

Before you rely on any outside party for these items, confirm in writing which decisions remain with your named owners.

An implementation partner prepares the technical and documentary groundwork that lets your team make and evidence its decisions. Typical work is configuring logging, organizing evidence and writing operating procedures. The partner does not take over legal interpretation, the oversight assignment or the suspension decision, because those decisions must sit with your organization.

Logging configuration: Set up retention of logs under your control, including the six-month minimum in Article 26(6) unless other law sets a longer period. For example, the admin_audit app in Nextcloud writes to audit.log in the data directory or to a path set with logfile_audit.
Evidence folders: Build a structured store for instructions, training records, notices, logs and review minutes that your team can hand to an assessor.
Monitoring runbooks: Draft the steps for monitoring, suspending use and reporting serious incidents to the provider first.
Oversight training material: Prepare course content for overseers, which your team approves and delivers.
Provider document mapping: Map the provider's information to your data protection impact assessment duties under Article 26(9).

The partner should not sign notices, certify compliance or act as the named overseer unless that role is explicitly assigned to it in a written scope.

Where deployers usually fall short on Article 26 and how to close each gap

Most deployer gaps under Article 26 come from documents, people and data flows that exist on paper but are not controlled by the deployer. Each card below names one common failure, the action that closes it, and the evidence an assessor or market surveillance authority would expect to see.

Instructions for use not on file

Article 26(1) requires a deployer to use a high-risk system in line with the provider's instructions for use. Many deployers hold a link to a vendor portal or an old PDF with no record of which version governs current use. Close the gap by filing the version in force, the date it was received, and a named owner who reviews vendor updates. Evidence is a controlled copy of the instructions, a change log showing each revision, and a record that operating procedures match the stated intended purpose and conditions of use.

Oversight without authority to stop

Article 26(2) assigns human oversight to people with the necessary competence, training, authority and support. A named reviewer who cannot halt the system or override its output does not meet that test. Close the gap by writing down who may suspend use, what triggers a stop, and how the reviewer is trained on the system's limits. Evidence includes the oversight role description, training records, the stop procedure, and logs of at least one exercised override or suspension, where one has occurred.

Logs held by the provider

Article 26(6) requires deployers to keep logs under their control for at least six months unless other Union or national law sets a longer period. Where the provider retains the only copy, the deployer cannot produce them for an authority. Close the gap by exporting logs into storage the deployer owns, with access controls and a retention rule. Confirm with the vendor which logs the system generates. Self-hosted platforms can supply audit trails, such as the admin audit log in Nextcloud, which writes to a path the administrator sets, and OpenBao's audit devices, which record every API request.

Input data never reviewed

Article 26(4) applies where a deployer controls the input data fed to the system. It must ensure that data is relevant and sufficiently representative for the intended purpose. Teams often connect data sources and never test what goes in. Close the gap with a documented input data review covering source, relevance to the intended purpose, representativeness across affected groups, and a schedule for re-checking when sources change. Evidence is the signed review record, data source register, and results of sample checks kept with the system's logs.

No path to suspend and report

Article 26(5) requires a deployer that finds a system presents a risk to monitor it, suspend use, and inform the provider and the relevant authority. Serious incidents must go to the provider first. Without a written trigger and contact route, staff tend to wait for a vendor reply before acting. Close the gap with an incident playbook that names the suspension decision owner, the provider contact, the authority notification path, and timing targets set by the deployer. Evidence is the playbook, a tested contact list, and records of past monitoring findings and notifications.

Workers and affected people not informed

Article 26(7) requires employers to inform workers' representatives and affected workers before a high-risk system is used at the workplace. Article 26(11) requires deployers of Annex III systems that make or assist decisions about people to inform those people. Notices are often missed when a tool is adopted by a business unit rather than HR or legal. Close the gap by mapping each decision-support use to a notice, a consultation step for workers, and a named owner. Evidence is the dated notice, the consultation minutes, and the notice text kept with the system record.

Public authority use of unregistered systems

Article 26(8) requires public authority deployers to register under Article 49 and forbids use of a high-risk system that is missing from the EU database. Procurement may add a system without anyone checking registration status. Close the gap by adding a registration check to the approval gate for every new system and a periodic inventory review. Evidence is the database entry reference for each system in use, the approval record showing the check, and the inventory with registration status. Confirm the current registration process with the provider and the competent authority.

What buyers ask about Article 26 cost, timing and outside help

Can we meet Article 26 ourselves without an outside firm?

Yes, in most cases. Article 26 places duties on the organization that uses a high-risk system, and most of them are organizational: following the provider's instructions for use, assigning trained people to human oversight, checking input data, monitoring the system, keeping logs and informing workers and affected people. The work is largely governance, documentation and logging configuration, so an internal team with legal, security and business owners can carry it. Outside help is most useful when you run several high-risk systems, when provider documentation is thin, or when your logging needs engineering work. Confirm early which duties your own team has the skills to cover.

What drives the effort of Article 26 compliance?

The main drivers are the number of high-risk systems you deploy, how much autonomy each one has, and the quality of the instructions the provider supplies. Effort also rises when existing logs are incomplete, when input data is under your control and must be checked for relevance and representativeness, and when you are a public authority, which adds a registration duty under Article 49. Systems that already write detailed audit trails need less engineering than those that do not. Ask for an inventory of systems and an assessment of each provider's documentation before estimating scope, because those two facts shape most of the work.

Who must we cooperate with under Article 26?

You work with the provider of each high-risk system, and with the national market surveillance authority where it applies. Article 26 requires you to use the system according to the provider's instructions, to inform the provider when you identify a risk or a serious incident, and to use the provider's information for data protection impact assessments under GDPR. Workers' representatives and affected workers must be informed before workplace use, and affected people must be told when an Annex III system makes or assists decisions about them. Agree in writing with each provider how information, incident reports and log access will flow before go-live.

What skills and roles does our team need for Article 26?

You need named people with the competence, training, authority and support to exercise human oversight, which Article 26 requires you to assign deliberately. In practice this means a business owner for each system, a reviewer who can understand and override its outputs, a security or platform engineer who manages logs and access, and a legal or compliance lead who tracks the provider's instructions and your notification duties. Document who holds each role and what training they completed. Staff who cannot stop or question a system in practice do not meet the oversight duty, even if their names appear on a chart.

Does Article 26 require an external certificate or audit?

No. Article 26 does not require a deployer to obtain a certificate, and an independent assessor is not a deployer requirement under this article. Your obligations are checked through the authority's enforcement powers, which means you must be able to show your records if asked. Any certification or audit you buy is a voluntary choice, for example to support a customer contract or a wider management system. Only an independent auditor or certification body can issue an audit report or certificate. An implementation partner can prepare systems, logs and evidence, but cannot issue either.

What is the maximum fine for breaching Article 26?

Breaches of most operator obligations, including Article 26, carry fines of up to EUR 15 million or 3% of total worldwide annual turnover, whichever is higher, under Article 99. For small and medium enterprises, the rule reverses and the lower of the two amounts applies, as Article 99 sets out. Prohibited practices carry higher ceilings, and misleading information given to authorities carries a separate lower ceiling. Fines are a ceiling, not a forecast, and regulators weigh factors such as severity, cooperation and duration. The practical cost of a breach also includes suspended systems, remediation work and customer impact, which can exceed the fine itself.

When do the high-risk rules that Article 26 depends on apply?

Under the 2026 amendment, 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. Earlier, these dates were 2 August 2026 and 2 August 2027. Article 26 duties attach once you use a high-risk system, so plan your inventory, logging and oversight arrangements against these dates. Confirm the current consolidated text on EUR-Lex before fixing your project plan, since amendments have already changed the timeline once.

How does DeployOpen help with Article 26 readiness?

DeployOpen plans, implements and hardens self-hosted open-source platforms inside your own infrastructure, and can configure the logging, access control and monitoring that produce Article 26 evidence. Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts, and a quote follows from that written scope. DeployOpen prepares systems and evidence but does not decide your legal obligations, issue audit reports or certify compliance. Ask for a written statement of which Article 26 duties the work covers and which remain with your legal and governance teams.

How DeployOpen works on this

DeployOpen helps deployers prepare the systems, logs, procedures and records that Article 26 Obligations of deployers of high-risk AI systems asks them to keep, inside their own infrastructure. The organization remains responsible for its controls, and only an independent assessor or authority can judge whether the obligations are met.

How we scope

We agree a written scope before work starts, covering which high-risk systems, teams and deployment environments are included.
We confirm with you which Article 26 duties apply, such as human oversight, input data control, log retention and worker notification.
We identify which provider instructions for use and which logs and records must be in place, and confirm them with your provider.

How we build

We configure self-hosted platforms so audit logs, prompt traces and access records are retained under your control for the period you set.
We set up monitoring, alerting and suspension procedures so the system can be paused and the provider and authority informed.
We test log completeness and access controls, and document how human overseers are assigned, trained and supported.

How we hand over

You receive a documented evidence pack mapped to each Article 26 duty, with configuration records, test results and named owners.
Procedures for worker notification, incident escalation to the provider and data protection impact assessment inputs are delivered as editable documents.
We walk your compliance and engineering teams through what each artifact shows and where you must keep it up to date.

How we support

Ongoing support, upgrades, backups and continuous security testing are available as retainers after the fixed-scope work is complete.
Retainers can cover log retention checks, configuration drift review and updates when the provider changes instructions for use.
Before you engage, ask us to confirm in writing which obligations are excluded from scope and which evidence your assessor will require.