On June 16, 2026, the European Parliament approved a provisional agreement pushing the core high-risk AI compliance deadline for Annex III systems from August 2, 2026 to December 2, 2027. The agreement (part of the "AI Omnibus") awaits formal Council adoption and Official Journal publication — until those occur, the original August 2, 2026 date remains technically binding. Either way, Article 26's deployer obligations are fixed: the extension shifts when enforcement starts, not what it requires.
Your procurement team has signed contracts for HR screening tools, credit assessment software, or AI-powered access management. Under Article 26, you are a deployer of a high-risk AI system. Here is what that legally requires of your organization, regardless of which enforcement date applies to you.
Key Takeaways
- A deployer is any organization that uses a high-risk AI system in a professional context without being the entity that developed or placed it on the market. Most enterprises buying AI tools from vendors are deployers, not providers.
- Article 26 imposes 12 distinct obligations on deployers: from human oversight and input data governance to worker notification and log retention of at least six months.
- Deployers who make a "substantial modification" to a high-risk AI system become providers and acquire the full provider obligation set, a classification with significantly higher compliance burdens.
Provider vs. Deployer: Why the Distinction Matters
The EU AI Act splits responsibility between the entity that develops and places an AI system on the market (the provider) and the entity that deploys it in a professional context (the deployer). Most enterprises using off-the-shelf or SaaS-based AI tools are deployers. The compliance obligations are materially different in scope.
Providers bear the primary burden: conformity assessment, CE marking, technical documentation (Annex IV), the Article 9 risk management system, post-market monitoring under Article 72, and serious incident reporting under Article 73. Deployers bear a lighter but still legally binding set of obligations under Article 26. Crucially, they face those obligations regardless of whether the AI system was built with EU AI Act compliance in mind.
Determining your status is the first step. If your organization:
- Purchased or licensed an AI system from a third party
- Uses it in your own operations for a purpose listed in Annex III
- Did not develop the system or make it available to other organizations for their use
...you are a deployer. If you built the system internally, acquired a foundation model and fine-tuned it for distribution, or substantially modified a system you purchased, you may be a provider, with all of the heavier obligations that classification carries.
What Counts as a High-Risk AI System (Annex III)
Article 26 applies only to high-risk AI systems. Annex III of the EU AI Act lists the categories. For enterprise deployers, the most commonly encountered Annex III categories are:
| Annex III Category | Examples in Enterprise Context |
|---|---|
| Employment and workers management | CV screening tools, performance monitoring AI, task allocation algorithms, interview scoring systems |
| Access to education and vocational training | Admissions scoring, student assessment AI, dropout prediction systems |
| Credit and insurance scoring | Automated creditworthiness assessment, insurance risk classification |
| Access to essential services | Benefit eligibility determination, utility service scoring |
| Biometric identification | Real-time remote biometric identification (note: strict additional rules) |
| Law enforcement (primarily public sector) | Predictive policing tools, risk assessment in criminal justice |
A practical challenge: many enterprises already deploy high-risk AI without recognizing it. Productivity suites, HR platforms, and credit management software increasingly embed AI decision-support features that may qualify as Annex III systems regardless of how they are marketed. Before assessing compliance, audit your existing software stack for AI capabilities that influence Annex III outcomes — not just tools explicitly purchased as "AI."
Not all AI tools in these domains are automatically Annex III high-risk — the system must actually make, assist, or meaningfully influence decisions affecting individuals to qualify. But the threshold is lower than many enterprises assume: an AI system that ranks candidates, scores creditworthiness, or recommends whether to grant a benefit typically qualifies.
Article 26: The 12 Deployer Obligations
Article 26 of the EU AI Act sets out 12 obligations for deployers of high-risk AI systems. Here is each one translated into operational terms.
Article 26(1) — Use according to instructions. Deployers must take appropriate technical and organizational measures to ensure they use the system strictly according to the provider's instructions for use. This means reading and operationalizing the user documentation your AI vendor supplies, not treating it as standard software EULA material. Instructions for use under the AI Act are a compliance input, not a formality.
Article 26(2) — Human oversight. Deployers must assign human oversight to natural persons with the necessary competence, training, and authority to understand the system's capabilities and limitations, monitor its output, override or disregard outputs when appropriate, and report malfunctions. The word "authority" is load-bearing: a compliance officer who monitors but lacks the authority to override a hiring algorithm's output is not fulfilling Article 26(2).
Article 26(3) — Non-interference with human oversight. Deployers must not place any restriction on natural persons designated for human oversight that would prevent them from fulfilling their function. If your organizational structure or performance incentives effectively prevent designated overseers from overriding AI outputs — for instance, a productivity KPI that penalizes overrides — Article 26(3) is violated regardless of whether a formal oversight role exists on paper.
Article 26(4) — Input data governance. Where the deployer controls input data, they must ensure it is relevant and sufficiently representative for the intended purpose. This directly addresses training data bias at the deployment stage: if your team feeds a CV screening system with a non-representative applicant pool, Article 26(4) creates liability for the deployer, not just the provider.
Article 26(5) — Operational monitoring and incident response. Deployers must monitor the system's operation, identify risks to health, safety, or fundamental rights, inform the provider immediately of non-conformity or serious incidents, and suspend use where deployment poses an unacceptable risk. This requires a monitoring workflow, not a passive assumption that the provider's post-market surveillance covers your deployment context.
Article 26(6) — Log retention. Deployers must retain automatically generated logs for at least six months, or longer if required by GDPR or other applicable law. Logs that document AI system decisions or recommendations on individuals likely qualify as personal data and must be managed under GDPR data retention obligations alongside the AI Act retention requirement.
Article 26(7) — Worker notification. Before deploying a high-risk AI system in a workplace context, deployers must inform workers and their representatives. This is a pre-deployment obligation, not a post-deployment notice. HR teams deploying productivity monitoring, task allocation, or performance assessment AI must satisfy this before the system goes live.
Article 26(8) — Registration (public authorities only). Public bodies must register their high-risk AI systems in the EU database before use and must not use unregistered systems. Private enterprises are not subject to this specific obligation.
Article 26(9) — DPIA integration. Deployers must use the technical documentation provided by the provider to conduct their GDPR data protection impact assessment (DPIA) where one is required. Article 26(9) explicitly creates a bridge between the EU AI Act and GDPR: the provider's Annex IV technical file feeds into the deployer's GDPR compliance framework for AI systems.
Article 26(10) — Biometric identification pre-authorization. Where a deployer uses a high-risk AI system for real-time remote biometric identification in publicly accessible spaces, they must obtain prior authorization from the relevant market surveillance authority (except in law enforcement contexts governed by separate provisions). This is one of the most tightly regulated uses of AI in the Act and effectively prohibits general commercial deployment of real-time biometric identification without explicit authorization.
Article 26(11) — Individual notification. Deployers must inform individuals subject to a high-risk AI system's output that they are interacting with or being assessed by such a system. Applicants assessed by a CV screening tool, employees subject to productivity monitoring AI, and customers whose creditworthiness is evaluated by an automated system all have a right to know.
Article 26(12) — Cooperation with authorities. Deployers must cooperate with competent market surveillance authorities, providing access to documentation and systems upon request.
Secure Privacy's Privacy & AI Governance Platform maps your AI systems against each of these 12 obligations, generating the documentation trail that market surveillance authorities and internal auditors expect to see.
When Deployers Become Providers: Article 25 and the Substantial Modification Rule
Article 25 of the EU AI Act addresses what happens when a deployer's actions cross into provider territory. A deployer who makes a "substantial modification" to a high-risk AI system acquires all the obligations of a provider — including conformity assessment, CE marking, and the full technical documentation burden.
Substantial modification means a change that affects the system's compliance with the essential requirements or its intended purpose. In practice, this includes: fine-tuning a model on your own data that shifts its capabilities significantly, adding new use cases not covered in the provider's instructions, or integrating the system into a larger pipeline that materially changes how it functions. Standard configuration (setting parameters within the range the provider specifies) is not a substantial modification.
This rule has direct implications for enterprises that buy AI platforms with low-code or no-code customization options. If your HR team builds a custom performance assessment workflow on top of a vendor AI platform, the question of whether that configuration constitutes a substantial modification is a legal determination your AI governance function needs to make and document.
Enforcement Timeline: What the 2026 AI Omnibus Extension Changes
The high-risk AI compliance calendar for deployers in 2026-2027:
| System Category | Original Deadline | Current Deadline (Pending Formal Adoption) |
|---|---|---|
| Annex III standalone systems (HR, credit, education, etc.) | August 2, 2026 | December 2, 2027 |
| Annex I systems (AI in regulated products) | August 2, 2026 | August 2, 2028 |
| Prohibited AI practices (Article 5) | February 2025 | No change |
| GPAI model obligations | August 2, 2025 | No change |
The Omnibus extension is provisional. The text was approved by the European Parliament on June 16, 2026, but formal Council adoption and Official Journal publication have not yet occurred. Until they do, the original August 2, 2026 date remains technically binding law. Organizations should not treat the extension as confirmed until publication.
The extension does not change the obligations. Article 26's 12 requirements are fixed. The extension changes when a market surveillance authority can enforce them — not what your compliance program needs to contain.
Maximum fines for violations of high-risk AI obligations: €15 million or 3% of global annual turnover, whichever is higher.
EU AI Act Deployer Compliance Checklist (2026)
Before the applicable enforcement deadline, deployers should have the following in place:
Article 4 — AI literacy (already in force)
- Note: Article 4 (staff AI literacy) applied from February 2, 2025. Deployers must ensure personnel who operate or oversee AI systems have sufficient AI literacy for their role. This obligation predates the high-risk enforcement deadline — non-compliance is already actionable.
System inventory and classification
- Inventory of all AI systems in use or under procurement
- Annex III classification determination for each, with documented reasoning
- Provider-deployer status determination for each system
Article 26(1) — Instructions for use
- Provider's instructions for use reviewed, accessible to relevant teams
- Technical controls in place to enforce use within the specified parameters
Article 26(2) — Human oversight
- Named oversight personnel for each high-risk AI system
- Training records for oversight personnel
- Authority delegation allowing override of AI outputs documented
- Escalation pathway for output disputes
Article 26(4) — Input data
- Assessment of input data representativeness for systems where deployer controls inputs
- Documented decision on any representativeness gaps
Article 26(5) — Monitoring
- Monitoring workflow for each high-risk AI system
- Incident reporting channel to provider
- Decision criteria for when to suspend use
Article 26(6) — Log retention
- Log retention policy: minimum six months, aligned with GDPR retention schedule
- Log access controls (logs likely contain personal data)
Article 26(7) — Worker notification
- Pre-deployment notification procedure for workplace AI systems
- Documentation of notification delivered to workers and representatives
Article 26(9) — DPIA integration
- DPIA (if required) completed using provider's technical documentation
- DPIA updated when system or context of use changes materially
Article 26(11) — Individual notification
- Notice to individuals assessed by high-risk AI, with system identification
- Notice timing: at or before the point of assessment
Substantial modification assessment
- Documented assessment for any customization: does this constitute a substantial modification?
- Legal sign-off on the assessment where modifications are significant
Secure Privacy's Privacy & AI Governance Platform supports Article 26 compliance through processing activity documentation, DPIA workflow management, and third-party AI system assessment registers — covering the documentation and monitoring requirements deployers need to demonstrate.
Frequently Asked Questions
Is every enterprise that uses an AI tool a deployer under the EU AI Act?
Only if the tool qualifies as a high-risk AI system. General-purpose tools (word processors, email clients, recommendation systems used for non-Annex-III purposes) do not trigger Article 26. The classification depends on the system's intended purpose and whether that purpose falls within Annex III.
Does the December 2027 extension apply to all enterprises?
The extension applies specifically to Annex III high-risk standalone systems. Annex I systems (AI embedded in regulated products like machinery or medical devices) have a different extended deadline of August 2, 2028. Both extensions are provisional pending formal Council adoption. Organizations in jurisdictions that may apply the original August 2026 date should monitor publication of the Official Journal.
What is a Fundamental Rights Impact Assessment (FRIA), and do deployers need one?
A FRIA is required under Article 27 for deployers that are public bodies, or private organizations providing public services that use Annex III high-risk systems. Private-sector deployers outside these categories are not legally required to conduct a FRIA but should consider it as a governance best practice. The December 2027 Omnibus extension also applies to the FRIA obligation for covered deployers.
What happens if the provider's AI system isn't AI Act compliant?
Deployers must use systems according to the provider's instructions for use. If a provider has not completed conformity assessment, the system should not be used for high-risk purposes — and deployers bear responsibility for the decision to deploy. Article 26(5) requires suspending use if deployment poses an unacceptable risk regardless of the provider's compliance status.
Can we delegate Article 26 compliance to our AI vendor?
No. Article 26 obligations fall on the deployer directly. A contractual provision requiring the vendor to "ensure compliance" does not shift the regulatory obligation. Your organization bears the compliance burden; the vendor bears the provider obligations. The two are complementary, not interchangeable.
If we integrate two high-risk AI systems together, what are the compliance implications?
Integration that materially changes the functioning or intended purpose of either system should be assessed for substantial modification. If the integrated system constitutes a new system with its own Annex III use case, the integrating organization may itself become a provider of that combined system — with the attendant conformity assessment requirements.
