EU AI Act Art.26 Deployer Obligations: Use-Case Restrictions and the Intended Purpose Doctrine (2026)

Post #1642 in the sota.io EU AI Act Compliance Series — ART25-26-DEPLOYER-PACK-2026 #1/5

Most developers building with third-party AI APIs are deployers under the EU AI Act, not providers. That distinction matters enormously: providers bear the heaviest compliance burden (QMS, technical documentation, conformity assessment, CE marking under Art.16), while deployers face a more focused — but still significant — set of obligations under Art.26.

The catch: the boundary between deployer and provider is not fixed. Art.26(2) contains a role-conversion rule that can transform a deployer into a provider overnight, instantly triggering the full Art.16 compliance burden. The trigger is using a high-risk AI system outside its intended purpose.

This is the first post in the ART25-26-DEPLOYER-PACK series. It covers the intended purpose doctrine, what use-case restrictions mean in practice, and how to document compliant deployment before the 2 August 2026 deadline.

Who Is a Deployer? (Art.3(4))

Under Art.3(4) of the EU AI Act, a deployer is any natural or legal person, public authority, agency, or other body that uses an AI system under its own authority — except for personal, non-professional use.

This definition is deliberately broad. If you:

• Integrate a third-party AI API (OpenAI, Anthropic, Google, Amazon) into your product
• Embed an AI feature from a vendor into your SaaS platform
• Deploy a pre-trained model you downloaded from Hugging Face
• License an AI model and serve it to your customers

...you are almost certainly a deployer. The provider is the entity that placed the AI system on the market — the model developer or fine-tuner. You are using that system under your own authority.

The deployer–provider asymmetry: Providers bear the full pre-market compliance burden (risk management system under Art.9, technical documentation under Art.11, conformity assessment under Art.43, CE marking, EU database registration under Art.71). Deployers have post-deployment obligations: use the system correctly, monitor it, maintain logs, and stop if problems emerge.

That asymmetry is deliberately structured so that the entity with the most knowledge about the system — the provider — bears the most compliance weight. Deployers get a lighter touch, but only as long as they stay within the intended purpose.

The Intended Purpose Doctrine

Every high-risk AI system placed on the market must be accompanied by instructions for use that define the intended purpose: the specific use, task, or application for which the system was designed and validated.

A credit-scoring model might have an intended purpose of "evaluating creditworthiness of individual consumer loan applicants aged 18–65 in EU member states." A CV-screening system's intended purpose might be "pre-screening applications for entry-level software engineering roles based on stated technical skills."

Art.26(1) requires deployers to use a high-risk AI system in accordance with its instructions for use. This is not a formality. The instructions for use define the boundary of the system's validated performance. Deployers who read them only to check a compliance box are missing the operational intent.

What "Intended Purpose" Covers

The instructions for use for a high-risk AI system typically specify:

1. The specific task or decision the system is designed for — CV screening for engineering roles is not the same as CV screening for sales roles, even if the model is identical.
2. The input data types and format — a model validated on structured HR data may produce unreliable results when fed unstructured text. Using it outside the specified input format is out-of-scope.
3. The population the system was tested on — a credit model validated on applicants from France and Germany may not perform equitably when deployed for applicants from Romania or Bulgaria, even within the EU.
4. The operating context — "human in the loop for final decisions" is a common constraint. Removing the human oversight step is an out-of-scope use even if the model output is unchanged.
5. Prohibited use cases — providers routinely list specific uses that are explicitly excluded: "not for use in law enforcement contexts," "not for final autonomous decisions without human review."

When a deployer operates within all of these boundaries, they benefit from the Art.26 deployer regime. When they deviate, Art.26(2) activates.

Art.26(2): The Role-Conversion Rule

Art.26(2) of the EU AI Act contains the most consequential sentence in the deployer compliance framework:

If a deployer uses a high-risk AI system for a purpose other than that determined by the provider, the deployer shall be considered the provider of the high-risk AI system for the purpose of this Regulation and shall be subject to the obligations of the provider under Chapter III, Section 2.

Translation: step outside the intended purpose and you become the provider. Overnight. Without any transitional period.

What This Means in Practice

"Subject to Chapter III, Section 2 obligations" means you must comply with:

• Art.9 — Establish a full risk management system with continuous monitoring, risk identification, and mitigation measures across the entire lifecycle
• Art.10 — Data governance: training data quality, bias testing, representativeness checks
• Art.11 — Technical documentation: comprehensive system documentation to the Annex IV template
• Art.12 — Logging: automatic recording of events throughout operation
• Art.13 — Transparency and provision of information to deployers (which now applies to your downstream users)
• Art.16 — The full provider obligations checklist: QMS under Art.17, registration in the EU database, CE marking, EU Declaration of Conformity, cooperation with NCAs
• Art.43 — Conformity assessment: independent review of your system before market placement or putting into service

This is not a marginal compliance increment. Going from deployer to provider typically adds 6–18 months of compliance work, hundreds of thousands of euros in documentation and audit costs, and the need to halt deployment until conformity assessment is complete.

Examples of Role-Conversion Triggers

Scenario 1: Expanding use to a new population. You license an AI risk-scoring model validated for commercial lending decisions. You begin using it to score eligibility for public housing allocations (an Art.26 public authority context). The provider's instructions explicitly cover commercial lending. Public housing allocation falls under Annex III Category 5. Same model, different population and context: Art.26(2) activates.

Scenario 2: Removing human oversight. You deploy an AI recruiting tool with instructions specifying "for candidate pre-screening only, not for final hiring decisions." You integrate the output directly into your HR system's decision workflow without a human review step, automatically rejecting candidates below the threshold. The provider's intended purpose required human oversight in the loop. You have used the system outside its intended purpose. Art.26(2) applies.

Scenario 3: Fine-tuning on your own data. You take a vendor model and fine-tune it on your proprietary dataset to improve performance for your vertical. Depending on the degree of modification, you may have created a new AI system or substantially modified the original — in which case Art.26(2) applies and you are now the provider of the modified system.

Scenario 4: Aggregating outputs for a new decision type. You license three separate AI risk models (credit risk, fraud risk, identity verification) and build an ensemble that combines their scores into a single eligibility decision. The individual models were validated for their specific purposes. Your ensemble is a new system performing a decision not covered by any of the original intended purposes.

The Seven Deployer Obligations Under Art.26

For deployers who remain within the intended purpose, Art.26 imposes the following obligations:

Art.26(1) — Use in accordance with instructions for use. The baseline obligation. Maintain the technical and organisational measures needed to operate the system as specified. This includes preserving required hardware/software configurations, maintaining the operating environment the system was validated for, and not disabling safety features.

Art.26(2) — Role-conversion rule. Explained above. The obligation here is to not trigger this rule — which means actively monitoring whether actual use remains within the intended purpose boundary.

Art.26(3) — Human oversight. Where the instructions for use specify human oversight measures, deployers must ensure these are implemented and effective. If the provider specified that a human must review every output before acting on it, that is an obligation, not a suggestion.

Art.26(4) — FRIA for public authorities. Public authorities, certain regulated bodies, and other entities deploying high-risk AI systems in the categories specified in Art.27 must conduct a Fundamental Rights Impact Assessment before deployment. Private-sector deployers not covered by Art.27 are generally exempt from mandatory FRIA, but the assessment is best practice for any high-risk deployment. (FRIA is covered in post #4/5 of this series.)

Art.26(5) — Post-market monitoring and incident reporting. Deployers must monitor deployed systems and report serious incidents or malfunctions to the provider or NCA as appropriate under Art.73. "If it worked in testing" is not a monitoring strategy.

Art.26(6) — Logs. Deployers must keep logs generated by the high-risk AI system for the period required — minimum three years for most categories. These logs are the audit trail that regulators will request during Art.74 market surveillance.

Art.26(7) — EU database registration for public authorities. Public authorities using high-risk AI systems must register their use in the EU database under Art.71. This obligation applies to the deployer (the public authority), not just the provider.

Art.26(9) — AI literacy. Deployers must ensure that their staff who interact with or oversee high-risk AI systems have sufficient AI literacy under Art.4. This is not an abstract training requirement — it is directly connected to the effectiveness of human oversight under Art.26(3). A human overseer who cannot interpret AI system outputs cannot exercise meaningful oversight.

Documenting Intended Purpose Compliance

Regulators conducting Art.74 market surveillance will request evidence that deployers operated within the intended purpose. "We read the instructions" is not evidence. Defensible documentation means:

1. Scope of use specification. A written document describing your deployment: which system, from which provider, for which exact decision or task, applied to which population, in which geographic and operational context. This document should be signed off by a named responsible person.

2. Instructions-for-use mapping. A line-by-line review showing how your deployment maps to each element of the provider's instructions for use. Where the instructions specify constraints, document how those constraints are enforced technically.

3. Deviation log. A process for identifying and logging any request to expand use, add a new use case, or change the operating context. Each such request should trigger a formal review: does this remain within intended purpose? If not, the deployer must either obtain a new scope from the provider or begin the provider compliance process.

4. Human oversight implementation record. If the system requires human oversight, document the human review workflow: who reviews what outputs, with what authority to override, and what happens when a reviewer flags an issue.

5. Training and competency records. Evidence that staff exercising oversight under Art.26(3) and Art.4 (AI literacy) have completed appropriate training.

The Intended Purpose Test: A Decision Tree

Before deploying (or continuing to deploy) a high-risk AI system, work through this test:

1. Has the provider issued instructions for use?
   → No instructions: the provider may be non-compliant; escalate before proceeding.

2. Does your use case match the described intended purpose?
   → No match: you are a provider under Art.26(2). Stop. Begin Art.16 compliance process.

3. Does your operating context match the specified conditions?
   (Input data type, target population, hardware requirements, environment)
   → Any mismatch: Art.26(2) risk. Obtain clarification from provider before proceeding.

4. Are all specified human oversight measures implemented?
   → Not implemented: Art.26(1) violation AND Art.26(3) violation. Fix before operating.

5. Does your deployment involve a public authority or regulated body?
   → Yes: check Art.27 FRIA requirements. (See post #4/5 of this series.)

6. Are logs configured for the retention period specified?
   → No: Art.26(6) violation. Configure logging before operating.

→ All checks passed: proceed with deployment. Document this review.

Enforcement and Penalties

Non-compliance with Art.26 deployer obligations falls under Art.99's tiered penalty structure. For deployers who violate their obligations (including triggering Art.26(2) and operating as an undeclared provider), the maximum penalty is €15 million or 3% of global annual turnover, whichever is higher.

NCAs are empowered under Art.74 to request access to logs, documentation, and technical systems. Deployers who have not maintained adequate records will have difficulty demonstrating compliance — which regulators will read as non-compliance.

What Comes Next in This Series

This series covers the complete deployer compliance stack:

• Post #1/5 (this post): Art.26 overview — deployer obligations and the intended purpose doctrine
• Post #2/5: Art.26 + fundamental rights — HR, credit scoring, and healthcare deployer obligations
• Post #3/5: Art.26 + AI literacy — Art.4 staff training requirements for deployers
• Post #4/5: Art.27 FRIA — when it is required, how to conduct it, what documentation it produces
• Post #5/5: Art.26 + Art.27 deployer checklist finale — complete August 2026 readiness package

Action Checklist: August 2026 Deployer Readiness (Art.26)

• Identify all high-risk AI systems in use (check against Annex III)
• Obtain and review instructions for use from each provider
• Document your deployment scope against each element of the intended purpose
• Confirm that no deployment extends beyond the intended purpose boundary
• Implement human oversight measures as specified
• Configure logging for the required retention period (minimum 3 years)
• Establish a deviation log process for use-case expansion requests
• If public authority: check Art.27 FRIA requirements and EU database registration (Art.71)
• Ensure staff completing oversight roles meet Art.4 AI literacy requirements
• Designate a responsible person for Art.26 compliance documentation

Deployer compliance is not passive. The August 2026 deadline applies to deployers as much as providers. Start with the intended purpose audit — it is the fastest way to identify whether you are actually operating in the deployer regime or whether you have unknowingly become a provider.

sota.io is an EU-native managed PaaS built for teams building compliant AI systems. No US parent. No CLOUD Act exposure. Start deploying.