Who counts as a deployer under Article 26?

A deployer under Article 3(4) is any natural or legal person, public authority, agency, or other body that uses an AI system under its authority. A bank using a third-party credit scoring system is the deployer. A hospital using a vendor-provided diagnostic support system is the deployer. A government agency using a high-risk AI system for migration decisions is the deployer. The deployer obligations under Article 26 attach to the entity that operates the system in production, regardless of whether that entity developed the system, purchased it, or accessed it through a SaaS subscription.

Does Article 26 apply when we use a third-party AI tool internally?

Yes. The deployer obligations apply to the entity that uses the system, regardless of whether the system was developed in-house or supplied by a vendor. A team using a third-party AI tool for HR screening is the deployer of a high-risk system under Annex III. The vendor is the provider. The two operate under distinct obligations under Articles 16 and 26. The deployer carries the monitoring, retention, and incident reporting obligations even when the model and the documentation are produced by the vendor.

Do we need to inform workers before deploying a high-risk AI system?

Article 26(7) requires deployers that are employers to inform affected workers and worker representatives before putting a high-risk AI system into service in the workplace. The notification is separate from the GDPR-required notice. It covers the AI system specifically, including the categories of decisions the system will be involved in and the human oversight measures the employer has implemented. The provision interacts with national labor law in some Member States, which may extend the notification window or add consultation requirements.

What is the penalty for failing Article 26 obligations?

Article 26 violations fall under the Article 99 tier of €15 million or 3% of global annual turnover, whichever is higher. The penalty is the same as for other high-risk non-compliance, including Article 12 record-keeping and Article 13 transparency failures. Member States retain discretion to set lower penalties for SMEs, but the upper bound applies for enterprises operating across multiple Member States.

EU AI Act Article 26: The Deployer Obligations Most Teams Miss

Article 26 of the EU AI Act puts the operational obligations of a high-risk AI system on the deployer. The provider designs the system to be compliant under Article 12 and Article 13. The deployer runs it, monitors it, keeps the logs, and acts on incidents. The mandate takes effect on August 2, 2026. Most enterprise teams reading the regulation focus on Article 12 and miss that Article 26 is where the day-to-day compliance work sits. The penalty tier for Article 26 non-compliance is the same €15 million or 3% under Article 99.

I want to walk through what Article 26 specifies, where the operational gaps recur, and what infrastructure produces deployer evidence that satisfies an inquiry.

Mandate

Article 26 enumerates the deployer's obligations across the lifecycle of a high-risk AI system. The provisions are operational, ongoing, and structurally distinct from the design-time obligations that fall on the provider.

Deployers must use the system in accordance with the instructions for use supplied by the provider. They must assign human oversight under Article 14 to natural persons with the necessary competence, training, and authority. They must ensure the input data is relevant and sufficiently representative for the intended purpose, where the deployer controls the input data. They must monitor operation on the basis of the instructions for use and inform the provider if a serious incident occurs. They must keep the automatically generated logs under Article 19 for the required retention period. They must inform affected workers and worker representatives before deploying a high-risk system in the workplace.

The list reads like an operational runbook. Most organizations I look at have built infrastructure for none of it.

Use in accordance with instructions

The deployer must operate the system within the bounds described in the provider's instructions for use. That obligation extends to the input data, the user population, the operating environment, and the integration boundaries. A deployer who uses a high-risk credit scoring system on a population the provider has not validated produces an Article 26 violation independent of any model decision.

Human oversight assignment

Article 26 requires the deployer to assign human oversight to people with the competence, training, and authority to act. Three properties have to hold together. A trained reviewer who cannot intervene fails the test. A reviewer with intervention authority but no domain training fails the test. A trained reviewer who learns of a problem from an end-of-quarter dashboard cannot act inside the runtime window the regulation expects.

Monitoring of operation

The deployer must monitor the operation of the system in line with the instructions for use. Monitoring under Article 26 is not the same as application observability. It is purpose-specific monitoring against the risk conditions the provider identified, the accuracy thresholds the provider published, and the foreseeable misuse cases the documentation flagged. Most enterprises monitor application uptime, throughput, and error rates. None of those tell the deployer whether the system is operating inside the boundary the provider defined.

Compliance gap

Most deployers of high-risk AI systems today fail Article 26 along three recurring axes.

Instructions for use are not operationalized

The provider's instructions describe how the system must be operated. The deployer's runtime stack does not encode those instructions as enforcement rules. The deployer assumes operators will read the documentation and behave accordingly. Article 26 expects the deployer to ensure compliance, not to hope for it. The architectural answer is to encode the instruction constraints as policy at the runtime layer and to enforce them per request.

Human oversight is assigned but not equipped

Many deployers assign a person to oversight without providing the runtime signal that oversight requires. The assignee receives an end-of-day summary, an aggregated dashboard, or an exception report. Article 26 expects the oversight to function in time to prevent harm, which means the assignee needs per-decision visibility at the moment of decision. The infrastructure question is how the oversight signal reaches the assignee inside the runtime window.

Incident reporting is missing the source data

Article 26 requires the deployer to inform the provider if a serious incident occurs. The deployer must also report to the national competent authority. The reports require source evidence: which request produced the incident, what data was involved, what policy was in effect, what the outcome was, and which human verified or acted on the output. Without the per-decision audit record, the deployer cannot file a complete report.

What the architecture must produce

An architecture that satisfies Article 26 produces, at runtime, evidence that the system is operating inside the instructions for use, evidence that human oversight is functioning, and per-decision records that support incident reporting.

That evidence is not a quarterly attestation. It is per-request, structured, and signed. It is available to the deployer's compliance function on demand. It is searchable by user, by request, by time range, by policy version, and by incident classification. It connects the runtime audit record to the provider's documentation, so a regulator can move from the abstract description in the instructions to the concrete record at the request layer.

The same audit infrastructure that satisfies Article 12 and Article 19 satisfies the evidence half of Article 26. The encoding-instructions-as-policy half requires an inline enforcement layer that can apply per-route, per-role rules and fail closed when the request falls outside the documented operating boundary.

DeepInspect

This is the runtime infrastructure Article 26 requires above the application layer. DeepInspect sits as a stateless proxy between authenticated users and the LLM API. Provider instructions are encoded as policy: routes the system is permitted to take, roles authorized to use them, data classifications allowed to flow through, and outputs subject to human verification. Every request is evaluated against the policy and produces a signed per-decision record.

For Article 26, that combination produces the operational evidence the deployer needs. Use-in-accordance is encoded as enforced policy. Human oversight signal is generated per request and routed to the assigned reviewer inside the runtime window. Incident reporting draws on the per-decision record set, which contains identity, classification, policy version, and outcome for every request.

If you are running AI in a high-risk category and your Article 26 readiness depends on the application's runbook, that readiness is incomplete.

Book a demo today.

A serious incident is defined in Article 3(49) as an incident that leads to the death of a person or serious damage to health, a serious and irreversible disruption of critical infrastructure, an infringement of fundamental rights, or serious damage to property or the environment. Deployers must report serious incidents to the provider and to the national competent authority. The reporting timeline depends on the severity: within fifteen days for most incidents, within forty-eight hours for incidents involving widespread infringement or critical infrastructure, and within two days for incidents involving death. The shorter reporting windows depend on the deployer having the evidence available at the time the incident is identified.