Blog · · 10 min read

EU AI Act compliance checklist for product AI agents

EU AI Act compliance checklist for product AI agents

An EU AI Act compliance checklist fails when it starts with controls instead of applicability. The team copies a generic list, assumes every agent is high-risk, or builds against a deadline that changed in July 2026. The result is either expensive over-control or a paper checklist that misses the agent's real execution paths. This guide gives product teams a concrete alternative: classify the use and your legal role, map only the applicable duties to runtime controls, attach evidence to each control, and block releases when that evidence is missing.

This is an engineering and product-governance framework, not legal advice. Have qualified counsel confirm the classification and legal interpretation. Give that review an accurate system record, then turn the approved decision into behavior the product can enforce.

Start with applicability, not a universal control list

The AI Act uses a risk-based structure. The European Commission's current framework distinguishes prohibited practices, high-risk systems, transparency risks, and minimal or no-risk uses. It also separates obligations across providers and deployers. Your product category, intended purpose, affected people, market, and role matter more than whether the marketing page calls the feature an agent.

Create an applicability decision before a developer adds compliance flags to the runtime. At minimum, record:

  1. Name the intended purpose, including the user, decision, workflow, data, and effect. "Customer service" is too broad. "Draft a reply for an employee to review" and "automatically deny a customer's request" create different risk questions.
  2. Record where the system is offered and used, along with the users, affected people, and any sector-specific rules.
  3. Determine whether your company is acting as a provider, deployer, importer, distributor, or another regulated actor for this deployment. Buying a model does not automatically make you only a deployer. The regulation text is the source of truth for the defined roles and duties.
  4. Screen prohibited practices first. Then determine whether the intended purpose meets a high-risk route, a transparency obligation, or neither.
  5. Name the legal or compliance approver, product owner, and engineering owner. Link the source version used for the decision and record the review date.
  6. Reopen the decision when the intended purpose, audience, autonomy, tool authority, data, model, market, or legal timeline changes.

Do not encode the risk tier as a keyword match over a product description. A system can use the same model and orchestration code in two workflows with different intended purposes. Classification belongs to the versioned use case, not to the model name or repository.

Treat dates as versioned inputs

The current Commission overview says Article 50 transparency rules took effect in August 2026. It also says the July 2026 AI Omnibus amendment moved rules for certain Annex III high-risk areas to 2 December 2027 and rules for systems integrated into regulated products to 2 August 2028. Older checklists can still show the superseded August 2026 high-risk date.

Do not let a date copied from a blog become the only release condition. Store the legal source URL, source version or publication date, jurisdiction, effective date, and next review date in the applicability record. The Commission's 2 August 2026 transparency update confirms that the transparency rules are already in force even though some high-risk duties follow a later schedule.

Use one compliance contract per product use case

A useful contract joins the legal decision to implementation. It can live as YAML, JSON, or a database record, but it should be reviewable in a pull request and queryable during an audit.

applicability_decision:
  id: support-refund-agent-eu-v3
  intended_purpose: propose and execute policy-approved refunds
  markets: [EU]
  actors:
    provider: product-company
    deployer: merchant-customer
  risk_lane: transparency
  prohibited_practice_screen: passed
  classification_owner: [email protected]
  source_reviewed_at: 2026-08-19
  reassess_on:
    - intended_purpose_change
    - autonomous_limit_increase
    - new_sensitive_data
    - new_market
    - legal_source_update

obligations:
  - id: article-50-interaction-disclosure
    applies: true
    runtime_paths: [chat-start, resumed-conversation, agent-handoff]
    control: disclose-ai-identity-before-interaction
    owner: product-experience
    evidence: [ui-test, localized-copy-snapshot, release-manifest]
    release_gate: required
  - id: high-risk-controls
    applies: false
    rationale: current intended purpose does not meet recorded high-risk route
    legal_review: LEGAL-284

Counsel and the responsible business owners still make the legal decision. The record connects their approved conclusion to the product. Every applies: true entry needs a runtime path, owner, evidence artifact, test, and failure policy. Every applies: false entry needs a rationale and reviewer so the team can reassess it later.

Turn Article 50 transparency into product behavior

The Commission says users must be clearly informed when they are interacting with an AI system, including a chatbot, AI agent, or avatar. Its Article 50 transparency summary also describes marking and labelling duties for certain generated or manipulated content. The exact obligation and exceptions depend on the system and output, so map each applicable case separately.

For a conversational product agent, test disclosure as behavior:

  • Show the disclosure before or at the start of the interaction, not only in terms of service.
  • Preserve it when a conversation resumes on another device or channel.
  • Repeat or adapt it when a human hands the conversation to an agent, or an agent hands it to another automated system.
  • Test every supported locale and assistive-technology path.
  • Record the copy version, component version, test result, and release that shipped it.
  • Prevent a white-label configuration from silently removing a required notice.

The AI Act Service Desk page for Article 50 should be linked directly from the obligation record. That gives reviewers the operative article-specific source rather than a paraphrase copied into an internal wiki.

Expand the matrix only when high-risk duties apply

Do not apply a high-risk checklist just because the agent can call tools. If counsel confirms that a use case falls into a high-risk route, expand the contract to cover the applicable requirements and actor duties. The Commission's overview identifies risk management, data quality, activity logging, technical documentation, information for deployers, human oversight, robustness, cybersecurity, and accuracy as core high-risk areas.

A current Microsoft agent-governance checklist is useful for translating those areas into engineering work. Its own analysis is also a warning: a runtime toolkit may partially support logging or policy enforcement while leaving organizational training, data governance, complete technical documentation, or deployer processes outside its boundary. Treat framework features as evidence inputs, not as proof of conformity. Use the Commission or regulation for dates because Microsoft's June 2026 review predates the July amendment.

Map the confirmed duties into these implementation groups:

Risk and change management

Keep a risk register tied to the intended purpose and foreseeable misuse. Connect production incidents, evaluation failures, model changes, and newly granted tools back to that register. A monthly meeting without system events feeding it is not a lifecycle control.

Runtime authorization

Evaluate authority before every consequential tool call. The policy decision should include the user, tenant, agent release, requested operation, target resource, parameters, and current product state. A prompt instruction is not an authorization control. One implementation is a policy decision service outside the model's reasoning loop. The Open Policy Agent decision API accepts structured input and evaluates named policy decisions. Configure the agent-to-tool gateway to deny the request when the decision is undefined or the policy service is unavailable. That fail-closed behavior is an implementation recommendation, not an OPA guarantee.

Logging and technical evidence

Record the request identity, applicable policy version, model and tool versions, authorization result, action receipt, verified outcome, and human intervention. Do not store unrestricted prompts or chain-of-thought merely because the word "logging" appears in a checklist. Define data minimization, access, integrity, retention, and deletion for the evidence store.

Link each release to a system description, intended purpose, architecture, limitations, evaluation results, risk register, oversight design, and operating instructions. Generate what you can from release manifests and tests, but require human approval for legal assertions and unresolved documentation gaps.

Human oversight and recovery

Define what the reviewer can see and do. An approval button is insufficient if the person cannot understand the action, inspect the target and consequences, reject or modify it, stop the system, or reverse a reversible effect. Test timeout, stale approval, changed product state, unavailable reviewer, and emergency shutdown paths.

Accuracy, robustness, and cybersecurity

Declare metrics for the actual use case, not for the model in isolation. Test policy bypass, prompt injection through connected content, tool failure, stale context, conflicting writes, provider outage, and malformed output. Release gates should combine statistical quality checks with deterministic forbidden-effect tests.

Bind evidence to the release that produced it

A compliance folder full of screenshots becomes unreliable as soon as the prompt, model, policy, tool schema, or UI changes. Give every behavior-affecting release one immutable identifier and attach evidence to it.

For each obligation, require four proof types where they make sense:

  • The design record contains the approved applicability decision, control design, owner, and threat or misuse analysis.
  • Build records identify the policy, schema, configuration, UI component, and release manifest by version.
  • Test records contain the exact test case, environment, input fixture, expected result, actual result, and timestamp.
  • Runtime records include bounded logs, policy decisions, receipts, incidents, interventions, and monitoring reports from the deployed release.

A release gate should fail when an applicable obligation has no owner, no runtime-path coverage, an expired review, or a required test without a passing result. Do not replace missing evidence with a manually checked box.

Test the contract against a realistic agent flow

Consider a support agent that reads an account, proposes a refund, requests approval above a threshold, calls a payment API, and reports completion.

Run the contract through the whole path:

  1. The UI identifies the automated agent at the start of each relevant interaction.
  2. The context layer retrieves only records the current user and merchant may access.
  3. The policy engine evaluates the refund amount, account, merchant policy, user authority, and agent release.
  4. A durable approval record binds the reviewer to the exact proposed action and expires if the account state changes.
  5. The payment tool returns an execution receipt.
  6. The agent verifies the refund against the authoritative payment record before claiming success.
  7. The evidence record joins the disclosure version, context references, policy decision, approval, tool receipt, verification result, and release ID.
  8. A changed workflow, such as using the same agent to decide eligibility for an essential service, triggers a new applicability review before deployment.

The same contract also defines failure behavior. If the policy service is unavailable, consequential calls fail closed. If evidence storage is unavailable, the runtime either pauses the regulated path or enters a documented safe mode. If the classification is expired, the release pipeline blocks promotion.

Verify the EU AI Act compliance checklist before release

Use these checks as a release gate:

  • The intended purpose, affected people, markets, actors, and risk lane have named reviewers.
  • Prohibited-practice screening is explicit and current.
  • Every applicable obligation maps to all execution paths, including streams, retries, resumptions, handoffs, background work, and administrative tools.
  • Every control has an owner, version, test, evidence artifact, and failure policy.
  • Article 50 disclosure is visible and tested in the product where it applies.
  • High-risk controls are included only when the approved classification requires them.
  • The team can retrieve evidence by use case, release, obligation, and date without exposing unrelated customer data.
  • Reassessment triggers are wired to product and release changes rather than left as a calendar reminder.
  • A qualified reviewer has confirmed the legal interpretation and current source dates.

Then run one negative test: change a required disclosure component, disable the policy service, or remove a mandatory evidence artifact in a staging release. The gate must fail for the expected reason. A gate that still passes does not enforce the checklist.

Common implementation mistakes

Assuming every agent is high-risk

This wastes engineering effort and obscures the duties that actually apply. Classify the intended use first.

Assuming a vendor makes the product compliant

A model, agent framework, policy engine, or logging service can support controls. It cannot decide your intended purpose, regulated role, complete system boundary, or organizational obligations.

Using one disclosure for every channel

Web chat, voice, email, embedded widgets, resumed sessions, and agent-to-human handoffs can expose different interaction paths. Test each one.

Collecting logs without an evidence model

Raw traces do not prove which policy allowed an action, whether it succeeded, which release ran, or whether the record is complete.

Freezing a deadline in code

Legal timelines and guidance change. Store the source and review date, then make legal updates a reassessment trigger.

Letting the model enforce its own limits

Consequential authorization, budgets, and prohibited actions need deterministic enforcement outside the reasoning loop.

Build the first contract now

Choose one production agent use case. Write its intended purpose and actor map, obtain a reviewed risk classification, and create one obligation entry with a runtime path, owner, evidence artifact, test, and release gate. Use Article 50 interaction disclosure if it applies to the flow. Then deliberately break the control in staging and prove the gate blocks release. That small vertical slice is more useful than a complete-looking checklist that no deployed system can enforce.

References

Be first in line.

Join the waitlist and we'll email you the moment it's ready. No sales call.

Try the demo →
or talk to us