The EU AI Act: What Became Enforceable in August 2026

The EU AI Act stopped being a planning exercise on 2 August 2026, the date its high-risk obligations became enforceable. Most coverage has aimed at model developers, but the larger affected group is everyone else: companies that buy AI systems, embed them in products, or point them at regulated data. This guide sets out what changed, how to tell whether you are a provider or a deployer, and which obligations reach an ordinary buyer. It also covers what to ask a vendor now, including the awkward fact that many still publish no position at all.

What Became Enforceable on 2 August 2026?

High-risk obligations under the EU AI Act became enforceable on 2 August 2026, converting the Act's heaviest requirements from published text into duties with supervisory consequences. For most organisations the preceding period was a mapping exercise: identify which systems might be classified as high risk, and wait. That classification now determines a live obligation rather than a future one.

The practical shift is about evidence. Before enforcement, a plausible internal view of your risk tier was usually enough. Afterwards, the question becomes what you can show — documentation, logs, testing records, and a defensible account of human oversight. Organisations that treated AI governance as a policy document rather than an operational practice feel this most.

One point gets lost regularly: the Act attaches to systems and their use, not to vendor nationality. An AI system placed on the EU market or producing output used in the EU falls in scope regardless of where its provider sits. Buying European discharges no obligation by itself, and buying American creates none.

How Does the AI Act Classify AI Systems?

The Act sorts AI systems into four tiers by risk, and the tier decides how much compliance work applies. Classification is the first thing to establish, because almost every downstream question depends on it.

Tier	What it covers	What it means in practice
Prohibited	Uses the EU has ruled unacceptable, such as certain manipulative or social-scoring applications	Not a compliance project — these use cases are off the table
High-risk	Systems used in sensitive contexts including employment, education, credit, essential services, and safety components of regulated products	The heavy tier: risk management, data governance, documentation, logging, human oversight, and post-market monitoring
Limited risk	Systems interacting with people or generating synthetic content	Mainly transparency: people should know they are dealing with AI or with generated media
Minimal risk	Everything else, which is most business software	No specific obligations under the Act; ordinary GDPR and sector rules still apply

Two classification traps recur in practice. One is assuming the tier follows the technology, when it actually follows the use case. A single language model is minimal risk inside a marketing drafting tool and high risk inside a CV-screening workflow. Another is forgetting that general-purpose models carry obligations of their own upstream, separate from how any individual customer deploys them.

Are You a Provider or a Deployer?

A provider develops an AI system or has one developed and places it on the market under its own name, while a deployer uses an AI system under its own authority in a professional capacity. Most companies reading this are deployers, and deployer obligations are lighter but not trivial.

The distinction is not fixed, which is the part buyers miss. Substantially modifying a high-risk system, or putting your own brand on someone else's, can move you into the provider role along with its far heavier documentation and conformity duties. Fine-tuning a model and shipping it inside your own product deserves legal review, not an engineering assumption.

Deployer duties centre on disciplined use. Broadly, that means operating the system according to the provider's instructions, ensuring input data is appropriate for the intended purpose, assigning competent human oversight, monitoring how the system behaves in production, and retaining logs. Where a high-risk system affects workers or individuals, informing the affected people is generally part of the picture too. None of that is exotic, and all of it needs to be real rather than aspirational.

Which Obligations Reach an Ordinary Buyer?

For a company buying rather than building AI, four obligations do most of the work: classification, vendor evidence, human oversight, and record-keeping. Everything else tends to follow from those four being handled properly.

Maintain an AI inventory with a classification per use case. You cannot demonstrate compliance for systems nobody has listed. Shadow AI inside individual teams is the common failure here.
Collect provider documentation before deployment, not after. High-risk providers owe deployers the information needed to use the system correctly. Obtain it, read it, and keep it.
Make human oversight specific. Naming a role is insufficient; the person needs authority to intervene, the training to interpret output, and a defined path to stop or override the system.
Keep logs and testing records. Enforcement questions are evidential. Retained logs, evaluation results, and incident notes are what turn a claimed process into a demonstrated one.

If you are prioritising: start with any AI touching hiring, credit, education, healthcare, or access to essential services, because those contexts sit closest to the high-risk tier. Internal productivity tooling — drafting, summarising, code assistance — is usually minimal risk and can wait, provided nobody has quietly pointed it at regulated decisions.

What Do Agents and Tool Gateways Change?

Agent architectures complicate classification, because the system that acts is no longer the system you evaluated. A tool gateway routing model output into real actions on real data changes both the risk profile and the audit surface. The resulting compliance question belongs to whoever operates that gateway.

Standardisation has moved fast here. Model Context Protocol (MCP) was donated to the Linux Foundation's Agentic AI Foundation in December 2025, with OpenAI, Google, Microsoft, AWS, Salesforce, and Snowflake among the backers. Broad industry support makes MCP the default plumbing for connecting models to tools and data, and tool or agent gateways operating on regulated data fall inside the Act's scope.

Practically, that argues for treating the gateway as a governed component rather than as glue. Log what tools were called with which arguments, constrain which data sources an agent can reach, and evaluate the composed system rather than the model alone. European-headquartered observability and evaluation tooling such as Langfuse and Giskard exists precisely because composed behaviour is what needs evidence.

What Should You Ask an AI Vendor Now?

Ask five questions, and treat the quality of the answers as information in itself. Vendors that have done the work answer quickly and in writing.

What is your role for this system — provider, deployer, or distributor — and what documentation do you supply to deployers?
Do you classify this product as high risk for any customer use case, and which ones?
What model or models sit underneath, from which suppliers, and in which jurisdictions do they run?
What logging, evaluation, and human-oversight features does the product expose to us?
Where is your published AI Act position, and when was it last updated?

Question five is the revealing one. Many vendors have published nothing formal, including credible European companies. Our review of Zeotap notes that the company has no published AI Act position, which is defensible for a customer-data platform sitting closer to marketing automation than to high-risk AI. Silence is not automatically a red flag. It does mean you cannot rely on the vendor's paperwork, and must document your own reasoning instead.

Where Do European AI Products Sit?

European AI vendors have a jurisdictional advantage and no automatic compliance advantage, and the distinction matters when comparing options. Being subject to EU law from the outset tends to mean earlier engagement with the Act, but the obligations still attach to your use case rather than to the vendor's flag.

Among European options covered on this directory, several have engaged with the Act explicitly. Aleph Alpha built explainability and source attribution into its platform specifically for high-risk interpretability requirements, and holds BSI security certification for German government use. Mistral AI processes API data in European data centres and has been aligning with the Act's general-purpose model requirements. Langfuse offers an EU region plus a fully self-hosted deployment, which matters when evaluation traces contain regulated data.

For a broader survey, see the AI assistants, AI APIs, and AI developer tools categories, our best European AI assistants roundup, and the EU alternatives to OpenAI page. Where a system processes personal data, the hosting question runs alongside the AI Act question — our cloud sovereignty framework guide and data residency guide cover that half.

Frequently Asked Questions

High-risk obligations under the EU AI Act. That is the tier covering AI used in contexts such as employment, education, credit, essential services, and safety components of regulated products. From that date the associated duties — risk management, data governance, technical documentation, logging, human oversight, and post-market monitoring — carry supervisory consequences rather than existing only on paper.

Yes, where the system is placed on the EU market or its output is used in the EU. The Act follows the system and its use rather than the provider's nationality, so an American vendor selling into Europe is in scope and a European vendor is not compliant merely by being European. Buyers should evaluate the specific system and use case, not the flag on the website.

Most companies buying AI are deployers: they use a system under their own authority in a professional context. You may become a provider by developing a system, placing one on the market under your own name or brand, or substantially modifying a high-risk system. Fine-tuning a model and shipping it inside your own product is the boundary case that most often warrants legal review.

Generally no. Drafting, summarising, and code assistance normally sit in the minimal-risk tier, where the Act imposes no specific obligations, though GDPR and confidentiality rules still apply. The classification follows the use case rather than the technology, so the same model becomes high risk once it is pointed at hiring decisions, credit assessment, or access to essential services.

That is common, and it is a documentation problem rather than proof of non-compliance. Ask directly for their role, their classification view, and the documentation they provide to deployers. Where a vendor cannot answer, you retain the obligation to classify the use case yourself and to record your reasoning, which regulators treat very differently from an unexamined default.