The EU AI Act is a risk-based legal framework for AI systems placed on the EU market, put into service, or used in circumstances covered by the regulation. It doesn't turn every AI agent into a high-risk system, and it doesn't create one identical checklist for every organisation.
The work begins with scope: what the system does, which role the organisation holds, which people or market it affects, and which risk category applies.
This guide is an operational overview, not legal advice. Confirm the current law and its application to each use case with qualified counsel.
Current application timeline
The implementation timetable changed after the original regulation was published.
According to the European Commission's current AI Act overview:
- Prohibited-practice and AI literacy provisions began applying on 2 February 2025.
- Governance rules and obligations for providers of general-purpose AI models began applying on 2 August 2025.
- The AI Office and national authorities assumed enforcement powers from 2 August 2026, when transparency provisions also began applying.
- Certain high-risk requirements apply later under the current timetable, including 2 December 2027 for specified Annex III areas and 2 August 2028 for certain systems embedded in regulated products.
Do not rely on an old article that describes August 2026 as one universal high-risk deadline. Check the Commission's enforcement timeline and the current legal text for the system in question.
Start with the organisation's role
Obligations depend partly on whether the organisation is acting as a provider, deployer, importer, distributor, product manufacturer, or provider of a general-purpose AI model.
An enterprise that builds an agent for internal use may hold a different role from a vendor placing an AI system on the market. Material modifications, branding, integration choices, and intended purpose can affect that analysis.
Record the role decision for each use case and retain the supporting rationale. Do not infer it from the vendor contract alone.
Classify the use case, not the technology label
The Act uses a risk-based structure.
Prohibited practices
Certain uses are prohibited. If a proposed use case may fall into this category, stop and obtain legal review before development or deployment.
High-risk systems
Some AI systems are high risk because of their intended purpose or because they are safety components of regulated products. Relevant obligations can include risk management, data governance, technical documentation, logging, transparency to deployers, human oversight, accuracy, robustness, cybersecurity, post-market monitoring, and incident processes.
Transparency obligations
Certain interactive or generative systems have disclosure, marking, or labeling obligations. The European Commission's Article 50 guidance describes the transparency provisions that began applying on 2 August 2026.
Limited or minimal risk
Many AI systems fall outside the high-risk categories. Other laws, contracts, internal policies, security controls, privacy requirements, and sector rules may still apply.
The use of an agent, LLM, or chatbot doesn't determine the category by itself. Intended purpose and context do.
Translate obligations into an operating model
Legal analysis identifies the obligations. The operating model assigns ownership and turns them into work.
For each AI system or agent, record:
- Intended purpose and prohibited uses
- Legal role and risk classification
- Accountable business owner
- Model, agent, data, and system dependencies
- Approved people and delegated authority
- Human-oversight points
- Testing and change-control requirements
- Monitoring, incident, and review processes
- Evidence that must be retained
This information should remain connected to the production workload rather than living only in an assessment document.
Do not translate legal obligations directly into product features
A platform control can support an obligation without satisfying it by itself.
| Governance need | Operational evidence a platform may contribute | Work that remains with the organisation |
|---|---|---|
| Human oversight | Review trigger, reviewer identity, decision and resulting action | Define competent reviewers, authority, training and operating process |
| Logging and traceability | Agent identity, policy version, tool actions, blocks and outcomes | Determine legal scope, retention, access and review obligations |
| Risk management | Runtime exceptions, incidents, policy breaches and control performance | Maintain the risk process, assessment, treatment and accountability |
| Data governance | Source references, transformations and destination controls | Establish lawful basis, quality, provenance, rights and lifecycle governance |
| Technical documentation | Versioned configuration and run evidence | Maintain the complete system, intended-purpose and conformity documentation |
| Accuracy, robustness and security | Evaluation results, runtime failures, attacks and recovery events | Define acceptable performance, testing, monitoring and remediation |
This distinction prevents a feature checklist from becoming an unsupported compliance claim.
What changes when an agent can act
An agent can move beyond generating content and take actions in enterprise systems. It may read records, submit transactions, send messages, update cases, or call other agents.
That increases the importance of several operational controls.
Agent identity
The organisation should be able to distinguish the workload, its owner, and any delegated context from the person it acts for. A shared integration credential isn't a complete accountability model.
Bounded authority
The agent should receive only the systems, data, and actions required for its job. Approval should be explicit before execution, with thresholds and prohibited actions represented as enforceable permissions or policy.
Credential boundary
Keep the agent from holding a credential it could use to reach a system directly. Every action should be proposed to a gateway that decides, holds the credential, applies network egress policy and acts. The required boundary depends on the system and risk.
Sensitive-data protection
Apply configured data rules before information reaches a model, tool, or destination that shouldn't receive it. Verify which party sees the original value and which sees a redacted or protected form.
Runtime action control
Evaluate consequential actions before they execute. A blocked action should follow a defined fallback, such as human review, rather than leaving the run in an ambiguous state.
Accountable evidence
Retain enough context to reconstruct the governed run: identity, inputs, active control configuration, policy results, protected-data handling, access events, actions, fallbacks, and outcome.
These controls may support several legal and governance requirements. Whether any one of them is legally required depends on the system and role.
A practical implementation sequence
- Inventory use cases. Include agents, models, vendors, embedded AI features, and material dependencies.
- Classify scope and role. Document intended purpose, legal role, risk category, and applicable transition dates.
- Assign accountability. Name the business owner and the teams responsible for risk, legal, security, engineering, operations, and human oversight.
- Define authority. Specify approved systems, data, actions, thresholds, and fallbacks.
- Map controls. Connect each requirement to an organisational, technical, contractual, or human control and identify its owner.
- Test the real workflow. Include expected use, foreseeable misuse, sensitive data, blocked actions, failures, and human review.
- Retain evidence. Link design decisions and approvals to runtime results and business outcomes.
- Monitor change. Reassess when the model, tools, intended purpose, data, authority, or operating context changes.
Evidence to prepare for review
A defensible evidence set may include:
- Inventory and intended-purpose record
- Role and risk classification rationale
- Risk assessment and control mapping
- Data sources and data-governance records
- Test and evaluation results
- Human-oversight design and operating evidence
- Agent identity and permission configuration
- Runtime policy results
- Logs of attempted, blocked, and completed actions
- Incident and corrective-action records
- Change history and approval records
The evidence format should let a reviewer connect the control to the system and use case it governs.
Where Difinity.ai fits
Difinity supports the governed execution part of the operating model.
Hub configures agents, authority, policies and review. Teams can record the use case, identity, owner, approved connections, permissions, policies, provider rules, and sensitive-data handling. Every governed route writes to the run trail as it executes, and the Platform API is the system of record that holds the result.
Flow is the runtime that applies configured controls while workloads execute across models, tools, and enterprise systems. Every action a workload proposes leaves through the tool gateway, which holds the credential, decides, and acts. Permitted actions continue. Disallowed activity is blocked or routed to a defined fallback. The run returns evidence linking the policy context, action, and outcome.
Difinity can support EU AI Act readiness and evidence work. It doesn't classify a system legally, guarantee compliance, replace counsel, or complete every organisational obligation.
For agent-level operational evidence, start with the guides to AI agent audit trails and human approval for consequential agent actions. These controls can support a wider compliance process, but do not determine legal status by themselves.
Frequently asked questions
Is the EU AI Act fully applicable now?
The Act applies progressively. Several provisions and enforcement powers are already applicable, while certain high-risk requirements have later dates under the current timetable. Check the Commission's current timeline for the use case.
Is every enterprise AI agent high risk?
No. Classification depends on intended purpose, context, and the categories in the Act, not on the fact that the system uses an agent or LLM.
Does the Act require an AI gateway?
The Act sets obligations and outcomes rather than mandating one product architecture for every system. A gateway may support model-traffic controls. Agents that take enterprise actions usually require wider identity, authority, tool, and evidence controls.
Can software make an organisation compliant?
No. Software can support controls, records, monitoring, workflow, and evidence. Compliance also depends on governance, people, process, legal scope, contracts, testing, oversight, and ongoing operation.
What should an enterprise do first?
Inventory the system, document intended purpose and organisational role, classify the use case, assign an owner, and map the applicable obligations to controls and evidence. Do this before granting broad production authority.
Build evidence into the run
Compliance work is easier when policy, technical control, and evidence remain connected. For agents, that means defining authority before execution and retaining a complete account of what the agent attempted and achieved.
Use the EU AI Act Classifier as an initial educational aid, review the official sources, and obtain legal advice for the final determination. To see Difinity's governed execution path, explore the platform or request a demo.
