The EU AI Act for companies that use AI.

Who does it apply to?

The Act speaks in roles. A provider is the organization that develops an AI system (or a general-purpose model) and places it on the market or puts it into service under its own name or trademark. A deployer is the entity using the system under its authority - think HR using a résumé screener, or a bank using a credit decisioning workflow. Importers and distributors have their own lighter duties when they bring third-country systems into the EU.

Most enterprises are deployers for the agents and copilots they run internally, even when the model weights are hosted elsewhere. If you customize prompts, connect proprietary data, or change default behavior, regulators will look at your governance, not only the upstream model card. That is why platform features such as approvals, audit trails, and environment separation show up in product roadmaps - not as nice-to-haves, but as operational controls.

Small businesses are not exempt by size alone. The Act differentiates by risk class and by whether you touch regulated domains (employment, education, essential public services, law enforcement, etc.). A mid-sized ecommerce shop using minimal-risk copy suggestions faces different duties than the same company scoring contractors with automated psychological inference.

Professional services firms and agencies should pay attention when they resell AI to clients: you may be closer to a provider or distributor in the chain than you expect, especially if you white-label a solution. Contractual pass-through clauses help, but they do not replace your obligation to know which Annex III use case you are enabling.

For a concise product-side view of how AgentWorks encodes safeguards for deployers, see our AgentWorks compliance page, which maps controls to the workflows compliance teams actually run.

Startups often ask whether using an API absolves them from documentation duties. In practice, you still need to describe your specific deployment: which business rules you added, which datasets you connect, and which failure modes you tested. The provider's system card is an input to your file, not a substitute for it - especially when you chain multiple models or tools in one agent.

Public-sector buyers should also track procurement clauses that reference conformity assessments and CE marking concepts for high-risk systems. Even if you are not the manufacturer, your tender may require proof that subsystems were placed on the market lawfully, which ripples to your software supply chain.

Risk categories explained

The Act sorts AI into four bands. Unacceptable risk practices - such as certain manipulative, social scoring, or remote biometric identification scenarios - are banned outright with narrow public-interest exceptions. If your roadmap drifts close to those areas, stop and involve legal before you ship, not after marketing publishes a landing page.

High-risk systems are listed in Annex III and include many workplace, education, credit, and safety-related use cases. They trigger the heaviest conformity obligations: risk management systems, data governance, technical documentation, logging, human oversight, and post-market monitoring. High-risk is not a statement about model size; it is about the context of use.

Limited risk mainly introduces transparency duties - users should know they are interacting with an AI system or consuming synthetic content when that could influence decisions. Chatbots that pretend to be human without disclosure, or deepfakes without labels, are the canonical examples.

Minimal risk covers the long tail of productivity tools that do not touch the sensitive contexts above. You still need security, privacy, and honest marketing, but you are not running a full Annex IV technical file for every spell-checker-style feature.

General-purpose AI models add another overlay: systemic models may need additional documentation, downstream transparency, and - in some cases - serious incident reporting. Platform vendors that host many tenants should plan for how they will surface model identity, version, and policy changes to customers when regulators ask for traceability.

When in doubt between limited and high risk, run a structured decision record: intended purpose, affected population, degree of automation, reversibility of outcomes, and whether a human reviews before impact. That memo becomes the first page investigators read - make it factual, dated, and signed by a named owner.

Insurance and enterprise risk teams increasingly ask for this classification pack during renewals. Treat risk tier documentation as a living artifact you refresh whenever you add a new integration, dataset, or autonomous tool permission.

Key requirements for AI platforms

Whether you build or buy an AI platform, auditors will expect a coherent story across four themes: evidence, transparency, people, and change management. Evidence means immutable logs that tie outputs to prompts, tools, model versions, and human reviewers. Transparency means user-facing disclosures where required and internal documentation that non-engineers can navigate during an inquiry.

Personally identifiable information must be minimized, purpose-limited, and aligned with GDPR principles - retention schedules, subprocessors, and DPIAs are still the baseline. The AI Act adds emphasis on training, validation, and testing data quality for higher-risk contexts, so your data catalog should know which datasets feed which agent.

Risk assessment is continuous. A quarterly review that only checks accuracy misses the point; regulators care about misuse, drift, and emergent tool-calling behavior. Platforms should therefore support canary runs, red-team findings tracking, and rollback paths when a prompt template or plugin changes behavior in production.

Human oversight is not a checkbox for "someone looked once." It is about meaningful intervention: the right person sees the right context, can edit or reject an action, and leaves an audit record. That is why workflow engines pair approvals with the same thread the model saw - not a separate email chain nobody can reconstruct later.

If you are evaluating vendors, ask how each requirement is demonstrated - not whether marketing claims EU alignment, but which screens an investigator would click through. Our compliance features walk through PII controls, forbidden-use policies, audit logs, transparency labels, and risk scoring so you can map them to your own control matrix.

Security architecture still matters: tenant isolation, secrets rotation, and least-privilege API scopes are prerequisites for any credible AI governance story. Logs are only trustworthy if tamper resistance and access controls match the sensitivity of the underlying decisions.

Vendor management should extend to prompt libraries and third-party plugins. Each new tool is a new subprocess with its own data flow; your register of processing activities should reflect that reality before go-live, not after an internal audit finds shadow agents.

How AgentWorks supports compliance

AgentWorks does not make a use case compliant. Whether a system is high-risk depends on what you use it for. What the product gives you are the controls and records an assessment asks for, as settings rather than as a policy document.

Human oversight: before an agent sends, books, posts or changes something, it shows exactly what it wants to do and waits for a person to approve, reject or edit it. Workflows have an approval step of their own, and on Business an approval can need more than one person. Every decision is recorded with who made it and when.

Transparency and prohibited uses: chats carry an AI-transparency label, and messages are checked for prohibited uses under Article 5 before they reach a model. Personal data can be detected and anonymised before it is sent. Detection in free text is never perfect, so treat it as a reduction of exposure, not a guarantee.

Records: each workflow gets a risk classification that feeds an AI-system register, next to a GDPR processing register and an audit log of access changes and compliance events. These sit in the Security tab on Business and Enterprise. Every chat model runs in the EU, and the platform itself runs on our own servers in Germany.

For the full list of controls, see the AgentWorks compliance page.

Your compliance checklist

Use this sequence as an internal workshop agenda. It is not legal advice, but it mirrors what competent authorities ask for in desk reviews - especially when AI touches employees, customers, or safety-critical processes. Cross-reference each item with your compliance features evidence as you mature the program.

• Inventory every AI use case, owner, data source, and third-country transfer path; tag Annex III proximity.
• Decide provider vs deployer role per system and document contract flow-down requirements.
• Classify risk band, including GPAI obligations if you fine-tune or chain large models in production.
• Publish internal transparency artifacts: who may use agents, which integrations are approved, and how incidents escalate.
• Implement technical logging that binds prompts, tool calls, model IDs, and human approvals for sensitive actions.
• Run DPIAs/FRIAs where GDPR or the AI Act triggers them; store signed conclusions with version history.
• Train staff on refusal patterns, red-team findings, and how to escalate suspected prohibited uses.
• Schedule quarterly control testing: sample runs, verify logs, and confirm rollback drills after vendor upgrades.

Download the companion PDF checklist above to share with legal, security, and product leads. When you are ready to operationalize controls inside an AI agent platform, continue on the AgentWorks compliance page and start a pilot with human approvals enabled from day one.