EU AI Act 2026: Cloud Compliance Checklist for High-Risk AI Deployers

August 2026 was meant to be the month the EU AI Act's high-risk rules became enforceable. Instead, days before that deadline, the EU adopted the AI Omnibus, which moved most high-risk obligations to late 2027 and 2028. The rest of the Act still became generally applicable on 2 August 2026, and more rules take effect on 2 December 2026.

Short answer: The EU AI Act's high-risk rules do not generally apply yet. Under the AI Omnibus (Regulation (EU) 2026/1744), obligations for high-risk AI systems listed in Annex III apply from 2 December 2027. Obligations for high-risk AI embedded in products covered by Annex I apply from 2 August 2028. Prohibited practices, AI literacy and the Article 50 transparency rules already apply, and national authorities can enforce them.

For organizations that use AI rather than build it, the extra time is a preparation window, not a pause. This guide explains:

• what applies now;
• how to tell whether a system is high-risk;
• what deployers must do;
• where GDPR fits in;
• which cloud infrastructure controls help you achieve and prove compliance.

What Changed Under the EU AI Act in 2026?

The AI Omnibus was adopted on 8 July 2026, published in the Official Journal on 24 July and entered into force on 27 July 2026. It postponed the high-risk rules, added new prohibited practices and eased some obligations, but left the Act's risk-based structure intact. The timeline now looks like this:

The AI Omnibus also made several targeted changes that matter to organizations using AI:

• AI literacy: Article 4 now requires measures that support the development of AI literacy, rather than ensuring a sufficient level of it.
• Bias detection: a new Article 4a lets providers and deployers process special categories of personal data where strictly necessary to detect and correct bias, under strict safeguards.
• Safety components: the definition is narrower. AI used in a regulated product only for user assistance, performance optimization, automation or convenience no longer counts as a safety component.
• Machinery: AI in machinery moved to a sector-specific approach under the Machinery Regulation.
• Small mid-caps: several simplifications that previously applied only to SMEs now also cover small mid-cap enterprises (SMCs). These include simplified technical documentation, proportionate quality management, priority sandbox access and lower fine caps.

What about AI systems already in use?

High-risk AI systems placed on the market or put into service before the relevant application date are generally subject to the high-risk rules only if their design changes significantly after that date. The Omnibus clarified that this grace period applies per type and model of system. Systems intended for use by public authorities must comply by 2 August 2030 regardless. Major updates can count as a significant design change, so ask your provider how planned releases are classified.

What Already Applies to AI Deployers Today

Deployers already have obligations under the EU AI Act, even though the high-risk deadlines have moved. Four sets of rules apply now.

Prohibited AI practices (Article 5)

Since 2 February 2025, certain uses of AI have been banned. These include social scoring, manipulative or exploitative techniques that cause significant harm, untargeted scraping of facial images to build recognition databases, and emotion recognition in workplaces and schools except for medical or safety reasons. From 2 December 2026, deployers must also not use AI systems to generate or manipulate non-consensual intimate material or child sexual abuse material.

AI literacy (Article 4)

Providers and deployers must take measures to support AI literacy among staff and other people who operate or use AI systems on their behalf. These measures should reflect people's knowledge, the context of use and the people the systems affect. The obligation does not require you to guarantee a specific level of literacy, but you should be able to show what you did: role-based training, usage guidelines and a record of who completed them.

Transparency obligations (Article 50)

Article 50 has applied since 2 August 2026. For deployers, it means:

• informing people when they are exposed to an emotion recognition or biometric categorization system;
• disclosing that image, audio or video content is a deepfake, meaning it was artificially generated or manipulated (lighter requirements apply to evidently artistic, creative or satirical work);
• disclosing that text published to inform the public on matters of public interest was AI-generated or manipulated, unless it went through human review and someone holds editorial responsibility for it.

Providers of generative AI systems must also mark outputs in a machine-readable format as AI-generated. Systems already on the market before 2 August 2026 have until 2 December 2026 to comply, so ask your vendors whether their tools will meet that deadline. The European Commission published guidelines on the transparency of AI-generated content in July 2026.

Enforcement

The penalty provisions have applied since August 2025, and national enforcement began on 2 August 2026. Breaches of the Article 50 transparency obligations fall in the same fine tier as breaches of deployer obligations (see the penalties section below).

Is Your AI System High-Risk?

An AI system is high-risk under the EU AI Act in two cases. The first is when it is a safety component of a product covered by the EU product legislation in Annex I, or is such a product itself. The second is when it is used for one of the specific purposes listed in Annex III. Classification depends on the system's intended purpose and how it is used, not on whether it relies on machine learning or generative AI.

Annex I: AI in regulated products

This category covers AI in products regulated by EU harmonization legislation that requires third-party conformity assessment, such as medical devices, toys, lifts or radio equipment. Since the Omnibus, AI used only for non-safety functions such as user assistance, performance optimization, automation or convenience does not count as a safety component. These obligations apply from 2 August 2028.

Annex III: high-risk use cases

Annex III lists specific use cases, not whole sectors. Using AI somewhere in HR does not automatically make it high-risk; using it to screen job applicants does. The areas are:

• Biometrics: remote biometric identification, biometric categorization based on sensitive attributes, and emotion recognition where it is not prohibited.
• Critical infrastructure: safety components in the management and operation of critical digital infrastructure, road traffic and the supply of water, gas, heating and electricity.
• Education and vocational training: admissions, evaluating learning outcomes, assessing education level and detecting cheating in tests.
• Employment and worker management: recruitment and candidate screening, decisions on promotion or termination, task allocation based on behavior or personal traits, and performance monitoring.
• Access to essential services: eligibility for public benefits, creditworthiness assessment and credit scoring (except fraud detection), risk assessment and pricing for life and health insurance, and emergency call triage.
• Law enforcement: for example, assessing the reliability of evidence.
• Migration, asylum and border control: for example, examining asylum, visa and residence permit applications.
• Administration of justice and democratic processes: including AI intended to influence the outcome of elections or referendums.

The Article 6(3) exception

An Annex III system is not high-risk if it does not pose a significant risk of harm and does not materially influence decisions. Examples include a system that:

• performs a narrow procedural task;
• improves the result of work a human has already completed;
• detects patterns in decisions without replacing human assessment;
• performs a preparatory task.

A system that profiles individuals is always high-risk. Providers relying on the exception must document their assessment and register the system in the EU database, in a simplified form after the Omnibus.

As a deployer, ask your provider for its classification in writing. The Commission published draft guidelines on the classification of high-risk AI systems in May 2026. Final guidelines are due by August 2027.

Provider or Deployer? Understand Your Role

Most organizations that use AI are deployers: they use an AI system under their own authority in a professional context. A provider develops an AI system, or has it developed, and places it on the market or puts it into service under its own name or trademark. Your role determines your obligations, and one organization can hold different roles for different systems.

• A bank licenses a credit-scoring tool and uses it as intended. The bank is a deployer.
• A company hosts a vendor's model on its own cloud servers and uses it for its intended purpose. The company is still a deployer: hosting an AI system does not make you its provider.
• A company builds its own candidate-ranking model and uses it internally. The company is both provider and deployer, because putting a system into service for your own use counts.

When a deployer becomes a provider (Article 25)

Article 25 is the rule most likely to catch AI teams off guard. A deployer, distributor or other third party is treated as the provider of a high-risk AI system, with the full set of provider obligations, if it:

• puts its own name or trademark on a high-risk AI system already on the market;
• makes a substantial modification to a high-risk AI system so that it remains high-risk;
• changes the intended purpose of an AI system, including a general-purpose AI system, so that it becomes high-risk.

The third case is common. Suppose you build a candidate-screening or credit-decision workflow on top of a general-purpose large language model. You may then become the provider of a high-risk system, responsible for risk management, technical documentation, conformity assessment and registration.

Under the Omnibus, the original provider must cooperate with the new provider by sharing documentation and technical access. That duty does not apply if the original provider clearly specified that its system must not be turned into a high-risk system. Check vendor terms for such restrictions before you build.

Where your cloud provider fits

An infrastructure provider that supplies compute, storage and networking is normally neither the provider nor the deployer of the AI systems its customers run. Under GDPR, it usually acts as your processor.

If you are the provider of a high-risk system, Article 25(4) expects written agreements with third parties that supply tools, services or components used in the system. Those agreements should cover the information and assistance you need to comply. Depending on how this is interpreted, it can include infrastructure services, so make sure your contracts cover logging, access, incident notification and documentation.

EU AI Act Deployer Obligations: The Practical Checklist

From 2 December 2027, deployers of Annex III high-risk AI systems must meet the obligations in Article 26, and in some cases Articles 27 and 86. In practice, that means ten things.

1. Use the system according to the provider's instructions

Take appropriate technical and organizational measures to use the system in line with its instructions for use (Article 26(1)). Keep the instructions in your documentation. Treat any departure from them as a change that needs review, because using a system outside its intended purpose can make you its provider.

2. Assign competent human oversight

Assign oversight to people with the necessary competence, training and authority, and give them the support they need (Article 26(2)). They should understand the system's limitations, know when not to rely on its output and be able to use the intervention measures the provider has built in.

3. Control the quality of input data

To the extent you control the input data, make sure it is relevant and sufficiently representative for the system's intended purpose (Article 26(4)). In a retrieval-augmented generation (RAG) setup, for example, the documents and databases the system retrieves from are input data under your control.

4. Monitor the system and act on risks

Monitor the system's operation based on its instructions for use (Article 26(5)). If you have reason to believe its use may present a risk to health, safety or fundamental rights, do two things without undue delay: inform the provider or distributor and the market surveillance authority, and suspend use.

If you identify a serious incident, notify immediately: first the provider, then the importer or distributor and the relevant authorities. Financial institutions can meet the monitoring obligation through their internal governance rules under EU financial services law.

5. Keep logs for at least six months

Keep the logs the system generates automatically, to the extent they are under your control (Article 26(6)). The retention period must suit the system's intended purpose and be at least six months, unless EU or national law, in particular data protection law, provides otherwise. Financial institutions keep these logs as part of the documentation required under financial services law.

6. Inform workers before workplace use

Employers must inform workers' representatives and affected workers before putting a high-risk AI system into service or using it in the workplace (Article 26(7)).

7. Inform affected people and explain decisions

People subject to decisions made or assisted by an Annex III high-risk system must be told that the system is being used (Article 26(11)). Where a decision has legal effects on someone or similarly significantly affects them, they have the right to a clear and meaningful explanation of the AI system's role and the main elements of the decision (Article 86). Set up a process to answer these requests before go-live.

8. Register your use if you are a public authority

Public authorities and EU bodies that deploy high-risk AI systems must register their use in the EU database, and must not use a system that has not been registered (Article 26(8)).

9. Carry out a fundamental rights impact assessment where required

Some deployers must complete a fundamental rights impact assessment (FRIA) before first use (Article 27):

• bodies governed by public law;
• private entities providing public services;
• deployers using AI for credit scoring, or for risk assessment and pricing in life and health insurance.

The assessment covers how and how often the system will be used, who is affected, the specific risks of harm and the human oversight measures. It also covers what you will do if risks materialize, including how you will handle complaints. You must notify the market surveillance authority of the results.

The Omnibus lets you cross-reference relevant parts of your GDPR data protection impact assessment instead of duplicating them, and the AI Office is developing a template questionnaire.

10. Cooperate with authorities

Be ready to cooperate with competent authorities in any action they take in relation to the system (Article 26(12)). In practice, that means knowing where your documentation, logs and assessments are, and who is responsible for responding.

GDPR AI Compliance: Where the AI Act Meets Data Protection

The AI Act does not replace GDPR. When an AI system processes personal data, both laws apply, and the most efficient approach is one governance process that covers both. Our guide to GDPR compliance in the cloud covers the infrastructure basics. For AI systems, focus on these points:

• Lawful basis: identify a legal basis for each purpose, including system inputs, outputs, logs and any fine-tuning or evaluation.
• Data minimization: send the system only the personal data it needs, and apply the same discipline to prompts and logs.
• Special category data: GDPR Article 9 still restricts processing of health, biometric and other sensitive data. The new AI Act Article 4a gives providers and deployers a narrow basis to process such data where strictly necessary to detect and correct bias. Safeguards apply, including pseudonymization, strict access controls, no sharing with other parties and deletion once the bias is corrected. Article 4a creates no obligation to do this.
• Automated decisions: GDPR Article 22 restricts decisions based solely on automated processing that have legal or similarly significant effects. Human oversight under the AI Act should be genuine review, not a rubber stamp.
• Data protection impact assessment: Article 26(9) of the AI Act requires deployers to use the information in the provider's instructions when carrying out a GDPR data protection impact assessment. Where a FRIA is also required, you can cross-reference the two.
• Retention: the AI Act's six-month minimum for logs sits alongside GDPR's storage limitation principle. Set a defined retention period for each log type, document why, and delete data when the period expires.
• Transparency: combine AI Act notices with the information GDPR Articles 13 to 15 require, so people receive one coherent explanation.
• Processors, location and transfers: have data processing agreements with your cloud and AI vendors, and know their subprocessors. Confirm where data is stored and from where it can be accessed, including remote support access. Transfers outside the EEA need a valid transfer mechanism under GDPR Chapter V.

Separate proposals to amend GDPR itself are still going through the EU legislative process. They include a dedicated legitimate-interest basis for AI and a narrower definition of personal data. Until they are adopted, plan on the current GDPR text.

Cloud AI Compliance: What Your Infrastructure Should Provide

Cloud infrastructure does not make an AI system compliant. It provides the technical controls that make compliance achievable and, just as important, provable when an authority or auditor asks.

Shared responsibility: who does what

Compliance gaps often appear between parties, when each assumes another is handling a control. A simple responsibility matrix prevents that:

If you self-host an open model and build your own application on it, you may sit in both the provider and the deployer columns.

Questions to ask your cloud provider

1. In which data centers will our AI workloads, logs and backups be stored, and can we keep them in the EU?
2. Who can access our environment remotely, from where and under which controls?
3. Can we set our own log retention and deletion periods, and are logs protected against tampering?
4. Do you support customer-managed encryption keys?
5. Which subprocessors are involved, and how are we notified of changes?
6. Which certifications and audit reports can you share?
7. How quickly will you notify us of security incidents affecting our environment?
8. Can we export all our data and logs if we leave?

How Cloud4U supports AI compliance

Cloud4U operates data centers in Frankfurt and the Netherlands, which lets EU customers keep AI workloads, logs and backups within the EU. Services relevant to the controls above include:

• GPU servers for machine learning;
• private cloud environments;
• virtual machine encryption;
• S3 object storage for log archives;
• cloud backup and disaster recovery.

For architecture ideas, these guides cover related controls:

• Self-hosted LLM inference with vLLM: keeps prompts and outputs inside your own environment.
• AI routers and LLM gateways: give you a single point to log and govern model calls.
• Zero Trust in the cloud: access control.
• Confidential computing: protecting data while it is being processed.

Cloud4U provides the infrastructure. Classifying your AI systems and meeting AI Act obligations remains the responsibility of the organizations that build and use them.

EU AI Act Penalties: Why Preparation Matters

Penalties under Article 99 depend on the type of infringement. For most companies, the maximum is the fixed amount or the stated percentage of worldwide annual turnover, whichever is higher:

For SMEs and start-ups, the lower of the two amounts applies. The Omnibus extends that rule to small mid-cap enterprises for the second and third tiers, but not for prohibited practices.

These are ceilings, not standard amounts. Authorities must consider factors including:

• the nature, gravity and duration of the infringement;
• the number of people affected and the harm caused;
• the organization's size and turnover;
• its degree of responsibility given the technical and organizational measures it had in place;
• its cooperation with authorities and any mitigation measures;
• whether the breach was intentional or negligent.

Good preparation therefore reduces both the likelihood and the size of a fine. GDPR fines apply separately when personal data is involved.

Cloud Compliance Checklist for AI Deployers

Use this phased checklist to turn the obligations above into a work plan.

Now

• Build an inventory of every AI system in use, including AI features inside SaaS tools. Record its provider, intended purpose, the data it processes and its business owner.
• Check each use against the Article 5 prohibitions, including the new ones that apply from 2 December 2026.
• Put Article 50 notices in place for deepfakes, emotion recognition, biometric categorization and AI-generated public-interest text.
• Launch role-based AI literacy measures and record participation.
• Map personal data flows into and out of each AI system and update your records of processing.
• Confirm where AI workloads, logs and backups are hosted and who can access them.

Before 2 December 2026

• Confirm with generative AI vendors that their outputs will carry machine-readable AI marking.
• Update acceptable-use policies for image, video and audio generation tools to reflect the new prohibitions.

Before 2 December 2027

• Classify each system against Annex III and the Article 6(3) exception, and get the provider's classification in writing.
• Confirm your role for each system, and check Article 25 before customizing, rebranding or repurposing it.
• Collect the instructions for use and check registration status.
• Name human overseers, train them and define their authority and escalation paths.
• Configure logging with at least six months' retention and a defined deletion period.
• Set up monitoring, suspension and incident notification procedures.
• Complete data protection impact assessments and, where required, fundamental rights impact assessments.
• Prepare notices for workers' representatives and affected people, and a process for explanation requests.
• Document responsibilities with your cloud and AI vendors in your contracts.
• Create an evidence file for each system and schedule internal audits.
• Track the Commission's final classification guidelines and the publication of harmonized standards.

Next Steps

The AI Omnibus gave organizations more time, not fewer obligations. Start with an inventory of the AI systems you use, confirm which obligations already apply, and build the logging, oversight and data controls you will need by December 2027. If you are planning where to run AI workloads, talk to the Cloud4U team about EU-hosted infrastructure for AI.