EU AI Act 2026: Business Compliance Checklist

Decision summary: A practical post-2 August 2026 checklist for AI roles, risk triage, transparency, human oversight, vendor controls and safe pilots.

· · 7 min read

Decision summary: classify the use, not the tool

Under the EU AI Act, the first question is not which model you bought but what the system does and which role you occupy. The same assistant may be low impact when it drafts internal copy and materially more sensitive when it makes or triggers decisions about people. Start by recording the purpose, affected people, data, automated actions and the point where a human can intervene.

This guide is not legal advice. Duties depend on jurisdiction, sector, risk class and whether you are a provider, deployer or downstream provider. A safe starting point is a reversible, measurable, human-approved pilot with a written decision record. Verify legal thresholds against the current official EU text and qualified counsel before a consequential launch.

What changed on 2 August 2026?

The European Commission says that from 2 August 2026 the AI Office and national authorities began enforcing specified AI Act provisions. Article 50 transparency requirements also started to apply to certain interactive AI systems and synthetic content: people may need to be told that they are interacting with AI, while deepfakes and specified generated content may require visible or machine-readable marking. High-risk-system dates can be later and vary by use; there is no single deadline for every AI system.

Operationally, “we use AI” is not an inventory. Each record should identify purpose, role, market, data, affected people, output type and the date relevant to that use. The implementation timeline can change, so re-check the official source before procurement or legal decisions.

Role map: provider, deployer and downstream provider

If you develop a system and place it on the market under your name, you may be a provider. If your organisation uses it for staff or customers, you may be a deployer. If you connect a general-purpose model to your own product, you may also sit downstream in the value chain. More than one role can exist in one project. Look past marketing labels: who sets the intended purpose, modifies the system, selects data and answers to users?

For each use, record a business owner, technical owner, vendor and model version, purpose, input/output data, automated action, human approval, user notice, retention, stop mechanism and last review date. Reopen the assessment whenever the vendor, model, data or permissions change.

A four-bucket risk triage

Use four buckets for an initial screen. First, stop and seek specialist review if the use may involve a prohibited practice. Second, run a high-risk assessment if it touches employment, credit, critical infrastructure, education, essential services or another consequential domain. Third, assess transparency duties for chatbots, synthetic media or outputs that could mislead people. Fourth, even a low-impact internal productivity tool still needs data, security, accuracy and human-oversight controls.

Do not score risk from the model name alone. Consider connected systems, reversibility, number of affected people, personal data, cost of error and time to human intervention. When classification is uncertain, disable automatic action and keep the system in recommendation mode.

Article 50 transparency checklist

When a person directly interacts with an AI system, any required disclosure should be timely, clear, understandable and accessible. Do not hide it in a privacy policy. For generated images, audio, video or public-interest text, verify whether visible labels or machine-readable marks apply to your role and whether an exception is relevant.

Check whether the notice is localized, screen-reader accessible and retained when output is exported. Provide a route to human support and preserve evidence of which version showed which notice. Systems placed on the market before 2 August 2026 may have limited transition rules for specific marking duties; confirm this in the official Article 50 guidance instead of assuming an exemption.

Technical and operational controls for safe automation

Turn the NIST AI RMF into a working loop: govern ownership, map the context, measure quality and risk, then manage what you find. Define success, an acceptable error boundary and stop conditions before the pilot. Test ordinary examples plus missing documents, conflicting instructions, other languages, unauthorized data requests and service outages.

If an AI agent can use tools, apply OWASP's excessive-agency lesson: expose only necessary functions, begin read-only, require human approval for sending, paying, deleting or other consequential acts, keep secrets outside the model and log every action. Maintain separate recovery plans for prompt injection, data leakage, incorrect output and vendor failure.

A 30-day implementation plan

Days 1-5: inventory AI uses and assign an owner. Days 6-10: screen role and risk; route uncertain or consequential uses to legal, security and the responsible business team. Days 11-15: complete notices, human handoff, permissions, retention and vendor terms. Days 16-23: run normal and adversarial tests. Days 24-30: open a constrained pilot, monitor error and intervention metrics, and record a continue/stop decision.

The schedule is not a compliance certificate. Missing evidence is a valid reason not to launch. The best pilot is reversible, measurable, frequent, supported by accessible data and owned by a named human. Use the process-mapping guide to set the boundary and the RPA-versus-AI guide to compare delivery options.

Vendor and pilot decision matrix

Ask for more than a demo. Obtain the model and subprocessor list, data location and retention, training-data terms, security reports, incident-notice window, version-change policy, output-marking support, audit-log access, portability and exit route in writing. “AI Act compliant” is not evidence by itself; ask which control supports which obligation for which role.

Model scenario: an SME classifies incoming email and drafts replies. In a lower-risk pilot, AI only classifies and drafts; an employee approves sending, sensitive categories route to a human, and the model cannot delete CRM records or initiate payments. Measure not only speed but misrouting, human correction rate, data incidents and recovery time. This is an illustrative assumption, not a customer result.

Methodology

Claims are assessed for feasibility, cost, risk and measurability. Illustrative calculations are assumptions; legal, security and investment decisions require primary-source verification.

Source note

In-text links and named regulatory or technical documents are starting points. Unverified customer outcomes are not published.

Change log

— Native editorial review is pending at the v3.0 publication gate.

Frequently asked questions

Is every AI system high-risk under the AI Act?

No. Classification depends on intended purpose, domain and actual function. A lower-impact tool can still trigger transparency, privacy, security or contractual duties.

Must a chatbot tell users that it is AI?

Article 50 provides disclosure duties for specified interactive AI systems. Confirm your role, use and any exception against the current official guidance.

Can a non-EU company be affected by the EU AI Act?

Offering systems in the EU, directing a use at people in the EU or participating in the value chain can require a scope assessment. Obtain advice for the concrete situation.

What documents should an AI automation keep?

Start with purpose and ownership, role/risk assessment, data flow, human oversight, test results, version/vendor record, user notice, incidents and change history.

Can we pilot before the assessment is complete?

A reversible, low-impact, constrained and human-approved test may be possible. Do not enable consequential production actions while classification or controls remain uncertain.