> For the complete documentation index, see [llms.txt](https://handbook.harmonic.security/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://handbook.harmonic.security/reference/governance-and-frameworks/g.2-eu-ai-act-obligations-for-deployers.md).

# G.2 EU AI Act obligations for deployers

EU AI Act obligations for enterprise deployers, including classification, human oversight, monitoring, logging, transparency, and evidence.

*Last reviewed: August 18, 2026*

{% hint style="info" %}
The EU AI Act gives deployers their own duties. Once the relevant high-risk provisions apply, those duties cover use according to instructions, human oversight, monitoring, logs, notices, and, for specified deployers and uses, fundamental rights impact assessment.
{% endhint %}

This page is for organizations that buy, configure, integrate, or operate AI systems. Under the EU AI Act, an organization can be a deployer even when it did not build the model or system. Article 25 can treat a distributor, importer, deployer, or other third party as a provider when it puts its name or trademark on a high-risk system, makes a substantial modification, or changes the intended purpose in a way that makes the system high-risk. Legal should determine the role for each use case.

## Start with classification

Classify each AI use case before deciding what obligations apply.

| Question                                                                                                                      | Why it matters                                                           |
| ----------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------ |
| Is the system prohibited under Article 5?                                                                                     | Prohibited practices are not allowed once the relevant provisions apply. |
| Is the system high-risk under Article 6 or Annex III?                                                                         | High-risk systems trigger the main deployer obligations.                 |
| Does the system make or support decisions about natural persons?                                                              | Notice and fundamental-rights questions become more important.           |
| Is the organization only using the system, or modifying it substantially?                                                     | Substantial modification can change the legal role.                      |
| Does the use involve employees, customers, students, patients, applicants, borrowers, insureds, or public-service recipients? | These are common affected-person categories for high-risk review.        |

## Deployer obligations for high-risk AI systems

For high-risk AI systems, deployers should prepare to show that they:

* Use the system according to the provider's instructions for use.
* Assign human oversight to people with appropriate competence, training, authority, and support.
* Monitor system operation based on the instructions for use.
* If use according to the instructions may present a risk under Article 79, suspend use and notify the provider or distributor and the relevant market-surveillance authority without undue delay.
* Report serious incidents through the provider, importer, distributor, and relevant authority path required by Article 26.
* Keep automatically generated logs under the deployer's control for at least six months, unless another applicable law sets a different period.
* Use relevant and sufficiently representative input data when the deployer controls input data.
* Inform workers and worker representatives before putting a high-risk AI system into service in the workplace, where applicable.
* Inform affected natural persons when an Annex III high-risk AI system makes or assists decisions about them.
* Cooperate with competent authorities.

Treat this as a control checklist, not a paperwork exercise. A deployer who cannot show logs, oversight assignment, and monitoring evidence will struggle to prove the system is governed.

## Fundamental rights impact assessment

Article 27 requires a fundamental rights impact assessment before first use for specified high-risk systems and deployers. It covers bodies governed by public law, private entities providing public services, and deployers of the creditworthiness and life or health-insurance systems listed in Annex III points 5(b) and 5(c). The article excludes the critical-infrastructure systems in Annex III point 2 from this requirement.

A practical assessment should include:

* The business process where the AI system will be used.
* The intended purpose and frequency of use.
* The categories of people and groups affected.
* The specific risks of harm in that context.
* The human oversight measures used.
* Measures to use if the identified risks materialize, including internal governance and complaint mechanisms.
* The relationship to any data protection impact assessment.

If a DPIA already covers some items, do not duplicate work. Link it and add the AI-specific pieces: intended purpose, model behavior, oversight, affected groups, monitoring, and escalation.

## Transparency and notice

Article 26 requires deployers of Annex III high-risk systems to inform natural persons when the system makes or assists in a decision about them. Other transparency duties may apply to chatbots, emotion recognition, biometric categorization, deepfakes, and certain AI-generated public-interest text. Match the notice to the applicable article and use case.

Notices should say:

* The AI system is being used.
* The decision or process it supports.
* The deployer responsible for the use.
* The type of data used.
* How a person can request more information, correction, review, or escalation when applicable.

Do not let the vendor own this alone. The provider can supply instructions, but the deployer knows the local context, affected people, and decision process.

## Timeline to track

The base regulation and the 2026 amendment process need to be read together:

* The Act entered into force on August 1, 2024.
* Chapters I and II, including AI literacy and prohibited practices, have applied since February 2, 2025.
* Governance rules and obligations for general-purpose AI models have applied since August 2, 2025.
* Most remaining provisions apply from August 2, 2026, including several Article 50 transparency duties.
* The original regulation set August 2, 2027 for high-risk systems covered by Article 6(1), which are systems tied to regulated products.
* On May 7, 2026, the European Parliament and Council reached a political agreement on the AI Omnibus. The Commission says the agreed timeline moves Annex III high-risk rules to December 2, 2027 and product-embedded high-risk rules to August 2, 2028.

The Omnibus dates reflect the political agreement reported by the Commission. Confirm the final adopted text and Official Journal publication before treating them as settled legal deadlines.

## Common EU AI Act obligations for deployers security failures

* The team assumes the provider owns all EU AI Act obligations.
* The system is classified once and never reclassified after a feature or workflow change.
* Human oversight is assigned to people who lack authority to stop the system.
* Logs exist in the vendor platform but are not retained or accessible to the deployer.
* A DPIA exists, but it does not cover AI-specific context, affected groups, or oversight.
* Notices say "AI may be used" but do not explain the specific decision process.

## EU AI Act obligations for deployers security controls checklist

* Classify each AI use case by risk tier and legal role.
* Record whether the organization is deployer, provider, distributor, importer, or more than one.
* Keep provider instructions for use with the system record.
* Assign trained human oversight with authority to intervene.
* Test monitoring, logging, and incident escalation before production.
* Prepare affected-person notices where required.
* Run a fundamental rights impact assessment when Article 27 applies.
* Reassess after substantial modification, new data classes, new affected groups, or new automation.

## Frequently asked questions about EU AI Act obligations for deployers

### Do internal enterprise AI tools count?

They can. The Act applies to deployers established or located in the EU. It can also apply to a provider or deployer outside the EU when output produced by the system is used in the EU. Internal use is not a general exemption.

### Is a chatbot high-risk?

Not by default. Classification turns on the AI system's intended purpose and use. A drafting chatbot may fall outside the high-risk categories, while a system that materially supports employment, education, credit, insurance, public benefits, or another Annex III decision may be high-risk.

### Can vendor documentation satisfy deployer obligations?

It helps, but it is not enough. The deployer must document local use, input data, oversight, monitoring, logs, notices, and incidents.

### What should security own?

Security should own technical control evidence: identity, logs, DLP, connectors, runtime controls, incident response, and monitoring. Legal, privacy, HR, compliance, and the business owner should own legal classification and affected-person obligations.

## Applicable handbook articles

*This table applies only when the organization is acting as a deployer and the EU AI Act duties described on this page apply to the system.*

This mapping is deliberately limited to the deployer duties described on this page. It does not import provider obligations or turn every prudent AI security control into an EU AI Act requirement.

| Handbook area                            | Applicable articles                                                                                                                                                                                                                                      | Why they apply                                                                          |
| ---------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------- |
| 1. Identity & access                     | 1.7 Human-in-the-loop and approval policies                                                                                                                                                                                                              | Human oversight and authority.                                                          |
| 2. Connectors, extensions & supply chain | 2.7 The supply-chain review workflow                                                                                                                                                                                                                     | Provider instructions, system-version intake, and material-change control.              |
| 3. Runtime, sandboxing & autonomy        | <p>3.2 Approval policies and least-privilege autonomy<br>3.9 Central hosted-agent runtime hardening</p>                                                                                                                                                  | Human intervention, suspension, and runtime monitoring.                                 |
| 4. Data protection                       | <p>4.2 Data classification for AI prompts and outputs<br>4.4 Retention and Zero Data Retention</p>                                                                                                                                                       | Input-data relevance and retention of deployer-controlled logs for at least six months. |
| 5. Threats & adversarial testing         | <p>5.6 Incident response for AI systems<br>5.7 Threat modeling AI systems</p>                                                                                                                                                                            | Incident duties and technical input to rights-impact review.                            |
| 6. Observability, audit & evidence       | <p>6.1 The audit gap: what you can and can't see<br>6.2 OpenTelemetry for AI runtime<br>6.3 Compliance APIs by platform<br>6.5 Routing AI telemetry to your SIEM<br>6.6 Evidence by surface and investigation paths<br>6.7 Continuous review cadence</p> | Logging, monitoring, investigation, and evidence availability.                          |

## Further reading

The links below are the primary framework, law, regulator, standards-body, or official maintainer sources used for this page.

* [Regulation (EU) 2024/1689, Artificial Intelligence Act](https://eur-lex.europa.eu/eli/reg/2024/1689/oj/eng), especially Articles 2, 25, 26, 27, 50, and 113
* [European Commission AI Act implementation overview](https://digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai)
* [European Commission guidance for providers and deployers of high-risk systems](https://digital-strategy.ec.europa.eu/en/policies/guidelines-ai-high-risk-systems). The page identifies the July 2026 material as draft guidance and reports the May 2026 political agreement on timing.

## Related handbook guidance

* [Governance & Frameworks](/reference/governance-and-frameworks.md)
* [4.4 Retention and Zero Data Retention](/handbook/4.-data-protection-and-residency/4.4-retention-and-zero-data-retention.md)
* [1.7 Human-in-the-loop and approval policies](/handbook/1.-identity-and-access/1.7-human-in-the-loop-and-approval-policies.md)
* [6.3 Compliance APIs by platform](/handbook/6.-observability-audit-and-evidence/6.3-compliance-apis-by-platform.md)
* [G.7 Ownership and RACI for AI security](/reference/governance-and-frameworks/g.7-ownership-and-raci-for-ai-security.md)


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://handbook.harmonic.security/reference/governance-and-frameworks/g.2-eu-ai-act-obligations-for-deployers.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.