The EU AI Act for cloud operations teams

The risk pyramid, in one minute

The Act regulates by risk class. Prohibited practices (Article 5) - social scoring, manipulative systems and similar - are banned outright. High-risk systems (Annex III) include AI used in employment decisions, credit scoring, critical infrastructure management and other listed domains, and carry the heavy obligations. Limited-risk systems face transparency duties (Article 50). Everything else, the large majority of internal tooling, is minimal-risk with no specific obligations beyond the horizontal ones.

The classification question for an ops team is honest usage: an LLM that drafts incident summaries for an engineer to review is a different thing from a system that automatically takes decisions affecting people.

Provider vs deployer: which one are you?

Most operations teams are deployers: they use AI systems under their own authority but did not develop them for the market. Deployer obligations are lighter than provider obligations but real: use systems according to instructions, ensure human oversight where required, and for high-risk systems keep the automatically generated logs (Article 26).

The boundary can move. If you substantially modify a system or put your own AI-powered product on the market under your name, you can acquire provider obligations. Internal agent workflows built on a foundation model API generally keep you a deployer of the model, but document the design decision while it is fresh.

What is actually due from ops teams now

Three horizontal duties already apply and are cheap to satisfy early - and expensive to retrofit under deadline pressure.

• ✓AI literacy (Article 4): people operating AI systems need adequate training for their role. A short, role-specific enablement session with a record of attendance satisfies the intent - a policy PDF nobody read does not.
• ✓Inventory: you cannot classify what you have not listed. Keep a register of AI systems and use cases in operations, each with its risk class and the reasoning: one line of honest justification each.
• ✓Transparency (Article 50): if a chatbot faces users, they must be able to tell they are interacting with AI; AI-generated content in certain contexts must be disclosed. For internal tooling this is usually just a label.

Where cloud governance and AI governance meet

If you already run a governed cloud estate, you have the machinery the AI Act assumes: access control decides who can call which model endpoint, logging captures what agents did, vendor management covers the model provider like any other sub-processor, and data residency decides which workloads may use which region's endpoints. Treating AI governance as an extension of the existing control set, rather than a parallel bureaucracy, is both the cheapest and the most defensible route.

For agent workflows specifically: constrain what tools an agent can call the way you constrain an IAM role: least privilege, audited, revocable. The pattern that survives review is an agent whose every action is attributable and reversible.

A sensible preparation sequence for 2026

Between now and the August 2026 high-risk milestone: complete the inventory and classification, run the literacy session, label user-facing AI, and gap-check anything plausibly Annex III with legal counsel before building compliance machinery around it. Most teams discover their entire ops-AI estate is minimal or limited risk, which converts the AI Act from a threat into a one-page governance appendix.

FAQ