EU AI Act in 2026: prohibited, GPAI, high-risk — and who is provider vs deployer

The Act divides obligations by risk and role. Providers place AI systems on the market or put them into service under their name. Deployers use systems under their authority. Importers, distributors, and product manufacturers may also have duties. A company can be a deployer for one tool and a provider for another, especially when it fine-tunes, substantially modifies, or rebrands a system.

High-risk status depends heavily on intended purpose and domain, not just model architecture. A general language model used for drafting marketing copy is not the same as a system used to screen job applicants or influence access to essential services. GPAI adds its own documentation and transparency questions, particularly where a model is adapted into a downstream product.

The practical object to govern is the AI system in context, not the model in isolation. A model, prompt chain, retrieval source, human workflow, monitoring process, and user interface can together produce the regulated behavior. That is why inventories should capture intended purpose, decision impact, instructions for use, oversight points, and post-market monitoring rather than merely listing vendor names.

The checklist cannot decide whether your use case is high-risk. That requires product, legal, compliance, and technical teams to examine intended purpose, user context, affected people, vendor claims, system changes, and the actual decisions the tool supports.

It will not decide whether you are a provider, deployer, or both. That becomes difficult when teams fine-tune a GPAI model, build a workflow around an API, sell an AI-enabled feature, or materially change the system after procurement. The role analysis must be tied to the product lifecycle, not a one-time procurement label.

The checklist also cannot set acceptable risk for human oversight, accuracy, bias, transparency, and logging. Leadership needs to decide where AI can assist, where human review is mandatory, and where the use case should not proceed.

The most common failure is calling every system not high-risk without documenting why. Teams stop at the vendor's marketing category instead of testing intended purpose against Annex III-style use cases, prohibited practices, and local deployment context. That creates a fragile inventory that cannot survive customer or regulator questions.

GPAI and fine-tuning documentation is another weak spot. Engineering teams may know which base model, prompts, data, evaluation set, and guardrails they used, but that knowledge lives in notebooks and pull requests rather than a controlled file. When the product team later sells the feature, no one can explain the model lineage cleanly.

Deployers also assume the provider owns all risk. Providers may supply technical documentation and instructions, but deployers still control user training, input data, monitoring, human oversight, and the decision process around the tool. Teams also skip prohibited-practice screening because they assume their use is too ordinary to raise concern.

AI governance also fails at handoff from experiment to production. A pilot may begin as an internal productivity test, then become embedded in a customer workflow with different users, data, and consequences. If the classification is not revisited at that point, the organization can keep operating under a low-risk assumption that no longer matches the product.

Use the checklist after building an AI inventory with system owner, vendor, intended purpose, users, affected people, model type, data categories, deployment region, and business process. Without that context, each checkbox becomes an abstract compliance question rather than a product decision.

For every system, force a role and risk classification with evidence. Capture why the system is not prohibited, why it is or is not high-risk, whether GPAI obligations are relevant, and which team owns monitoring after launch. The checklist should produce a decision record, not just a status color.

Re-run the checklist when the model, data, user group, or purpose changes. AI Act risk can change when a harmless internal assistant becomes a customer feature or when a general model is fine-tuned for employment, credit, education, or safety-related workflows.