AI Act compliance checklist for businesses

To apply the AI Act in your business, inventory your use cases, identify your legal role, rule out prohibited practices, and link each obligation to verifiable evidence. Under this regulation governing the European market, an AI agent is not automatically a high-risk system: its intended purpose, the people affected, and its influence on decisions determine the assessment. As of October 24, 2026, some rules already apply, while the obligations specific to high-risk systems follow a postponed schedule.

Start with the schedule applicable in October 2026

Compliance starts by separating what needs to be in place today from what needs to be ready for a later deadline. Reusing a checklist published before the 2026 amendments can leave you working with the wrong dates.

The European Commission’s official timeline, consulted for this page as of October 24, 2026, sets out the following milestones:

Rules	Application date	What this means for your business
Initial prohibited practices and AI literacy provisions	February 2, 2025	Review uses and organize appropriate measures
Governance and obligations for general-purpose AI models	August 2, 2025	Distinguish the model provider’s obligations from those of the user
General application, including transparency, subject to specified transitional provisions	August 2, 2026	Check the interfaces and content covered by the rules
High-risk systems covered by Annex III	December 2, 2027	Prepare for obligations associated with sensitive uses
High-risk systems linked to regulated products under Annex I	August 2, 2028	Coordinate AI compliance with product regulation

Postponing the high-risk requirements does not suspend the other rules. It also does not postpone your obligations under personal data protection, employment, or consumer protection law.

This page provides a method for preparation and review. The AI Act glossary entry explains the essential concepts; the article AI Act: what changes for AI agents covers developments in the regulatory framework.

1. Inventory use cases, not just subscriptions

A list of purchased software is not enough. The same service can be used to rewrite a message, analyze job applications, or recommend a business decision. Create a separate entry for each use case whose purpose and risks need their own explanation.

Include business accounts, personal accounts used for work, AI features built into business software, and automations created by contractors. The AI tools catalog can help you recognize the types of tools present in your organization; it cannot replace this internal inventory.

For each entry, record:

the department responsible and the person who authorizes the use;
the specific purpose and uses that are excluded;
the provider, the system used, and any identifiable components;
the users, people affected, and countries involved;
the data accessed, transmitted, stored, or generated;
the actions the system can take and where human decisions fit into the process;
the contractual and technical documents available.

For an agent built in n8n, for example, describe the configured workflow rather than simply naming the platform. An agent that prepares a draft and an agent that changes an employee record require different assessments.

Recommended evidence: a dated use-case record with a named owner and a data flow diagram. The evidence suggested throughout this guide offers practical ways to document your work; it is not a list of universally required forms.

2. Determine whether you are a deployer or a provider

A business using a system under its authority is generally a deployer. A business that develops a system, or has one developed, and places it on the market or puts it into service under its own name may be a provider, including when the system is for internal use. Buying access to an API therefore does not settle your role in relation to the system you assemble.

The consolidated regulation available on EUR-Lex allows you to check these definitions and the responsibilities across the value chain. Article 25 provides, among other things, that changing a system’s intended purpose in a way that makes it high-risk can bring the business under the provider’s obligations.

Point to examine	Business acting as a deployer	Business acting as a provider
Typical position	Uses a system under its authority	Develops a system or has it developed, then places it on the market or puts it into service under its own name
Focus of the assessment	Conditions of use and actual operating context	System design, intended purpose, and compliance
Documentation to obtain	Provider instructions, limitations, and information	Evidence that applicable requirements have been met
Change to watch for	Use beyond the intended purpose	Changes to the system or its intended purpose

Do not confuse the model provider with the provider of the final system. Using a general-purpose model does not automatically transfer every obligation associated with your application to the model’s publisher.

Before assigning a project to an integrator, clarify the roles and expected deliverables. Recommended evidence: a written assessment of those roles, supported by a contractual allocation of tasks, without assuming that a contract removes responsibilities established by the regulation.

3. Rule out prohibited practices before running a pilot

Your first decision is not which security measure to choose. It is whether the proposed use is permissible at all.

The current official presentation of Article 5 on prohibited practices covers, among other things, certain harmful manipulative practices, exploitation of vulnerabilities, certain forms of social scoring, and certain sensitive biometric categorizations. Inferring emotions from biometric data in workplaces or educational institutions is prohibited, except for the medical or safety reasons specified in the regulation.

For a business, pay particular attention to features that claim to infer a candidate’s or employee’s emotional state from their voice or face. A consent option displayed in the interface is not enough to override a prohibition.

The same source states that new prohibitions concerning certain nonconsensual intimate or sexually explicit content and child sexual abuse material apply from December 2, 2026. That schedule does not affect prohibitions that may already arise under other laws.

Recommended evidence: a written decision excluding the use, or a reasoned assessment when a feature’s status is unclear. Ask the provider for a technical description rather than relying solely on its marketing claims.

4. Classify the system by its actual intended purpose

Generative AI or an autonomous loop does not, by itself, make a system high-risk. Examine its intended purpose, the context in which it operates, and its effect on people.

Article 6 and the annexes to the regulation distinguish, in particular, systems linked to certain regulated products and the sensitive uses listed in Annex III: recruitment, certain decisions concerning workers, education, and creditworthiness, among others. Exceptions are subject to specific conditions; simply labeling a tool as decision support is not enough to establish one.

Compare these illustrative scenarios:

rewriting a job advertisement;
extracting information from application files;
ranking candidates to determine who receives an interview.

These descriptions alone do not support a definitive conclusion. They show why you need to examine the output’s actual influence, the criteria used, and human oversight, rather than assigning a single classification to the entire human resources department.

Likewise, do not assume that making an autonomous payment necessarily makes a system high-risk under the regulation. Operational risk and legal classification each require an assessment.

Recommended evidence: a written assessment stating the intended purpose, the category considered, the relevant provisions, and the reasons for the classification. Review it when a new tool, a different group of people, or additional authority to act changes the scenario.

5. Organize AI literacy and human oversight

Article 4 was amended in 2026. According to the official AI literacy FAQ, providers and deployers must take measures to support the development of AI literacy, without a uniform individual proficiency level or a universally required certificate.

Tailor those measures to people’s tasks. Someone who rewrites text needs to know how to check claims and protect confidential information. Someone supervising an agent also needs to understand its permissions, triggers, and shutdown procedure.

A practical program can include:

an explanation of permitted and prohibited uses;
an exercise in spotting errors in representative documents;
a demonstration of the data the agent can access;
a procedure for reporting problems and resuming work manually;
an update whenever significant changes occur.

For oversight, test concrete situations: an inconsistent document, an out-of-scope request, or a recommendation with inadequate justification. Check that the responsible person can recognize the problem and has the authority to stop processing.

Recommended evidence: training materials, attendance records, exercises, and resulting corrections. Signing a workplace AI use policy helps communicate the rules; a signature alone does not demonstrate that people can apply them.

6. Check transparency in interactions and content

Transparency obligations do not apply only to high-risk systems. The Commission’s FAQ on Article 50 distinguishes the responsibilities of providers and deployers.

Providers must, among other things, ensure that people interacting directly with AI are informed of that fact, unless it is obvious. For a customer-facing interface, check exactly how that information appears in practice.

Deployers must disclose the deepfakes covered by the rules. The regulation also requires disclosure for certain generated or manipulated texts published to inform the public on matters of public interest, with a qualified exception where human review or editorial control takes place and editorial responsibility is assigned.

Technical machine-readable marking, which is the provider’s responsibility, is separate from information intended for the public. Article 50 has applied since August 2, 2026; the transition to December 2, 2026, concerns only certain marking and detection obligations for systems already placed on the market before that date.

Recommended check: review the entire journey, from the first interaction to exported content. Keep the relevant disclosure screens, publication rules, and editorial approvals. A spelling check does not amount to a substantive review of the content.

7. Prepare the documentation for high-risk uses

For relevant use cases, prepare for future obligations without presenting all of them as already applicable in October 2026. Article 26 on deployers provides, among other things, for use in accordance with instructions, competent human oversight, monitoring, and management of input data under the deployer’s control.

It also provides for automatically generated logs under the deployer’s control to be retained for an appropriate period of at least six months, unless other applicable provisions state otherwise. This legal retention period should not become a blanket instruction to keep every conversation.

The regulation also sets out requirements to inform affected workers and their representatives, as well as people subject to certain decisions assisted by these systems. It provides for communication with the provider and authorities when risks or incidents arise.

Ask how these obligations can be fulfilled when selecting a service provider: log exports, access to instructions, an incident contact, and the ability to suspend the system.

The fundamental rights impact assessment provided for in Article 27 does not apply indiscriminately to every small or medium-sized business. It covers, in particular, certain public bodies, private providers of public services, and uses related to creditworthiness or life and health insurance.

Recommended evidence: a list of the obligations applicable to the scenario, each linked to a responsible person, a deadline, and an expected document.

8. Handle personal data compliance alongside the AI Act

AI Act compliance does not replace compliance with the GDPR. A use that falls outside the high-risk category may still process sensitive personal information or produce a problematic decision.

The CNIL explains safeguards for AI systems and automated decisions. In particular, having a person involved in the process does not necessarily provide effective oversight if that person cannot reconsider the results or if cases are rejected without meaningful review.

Organize your data review around specific questions:

What purpose justifies each category of data?
What legal basis and information for individuals are planned?
Which service providers receive the data, and in which countries?
Who can access histories and outputs?
How will requests from individuals be handled?
Is a data protection impact assessment necessary?

For an agent, also track transfers to connected tools and export destinations. The model is only one potential recipient among others in the workflow.

Recommended evidence: a map of processing activities and recipients, linked to the relevant processing records and assessments. The article AI agents and GDPR: what data leaves, and where does it go? explores this data flow review in more detail.

9. Control actions and changes in production

The following measures are technical recommendations to adapt to your circumstances; they do not represent identical AI Act requirements for every system.

Start by reducing permissions: use read-only access where possible, dedicated accounts, and access limited to the files needed for the task. Place approval steps where they can still prevent an unwanted consequence, before a message is sent or a sensitive change is made.

Also test the separation between data and instructions. An agent may read a document that attempts to redirect its behavior. Check that incoming content cannot allow it to expand its permissions or bypass an approval.

The guide to securing an AI agent explains these controls; the security assessment helps identify missing protections.

Prepare an incident procedure that names the person able to disable the agent, preserve useful evidence, and resume work manually. Distinguish the technical fix from any notifications legally required under the applicable rules.

Finally, define which changes trigger a reassessment: a new purpose, model, data source, group of affected people, or write permission. Recommended evidence: a change record describing the effect on risks, the tests performed, and the decision to return the system to service.

10. Use a checklist backed by evidence and decisions

Use this checklist to manage the work. Assign an owner to each item, attach evidence, and mark it as satisfied, requiring correction, or not applicable with a justification. A checked box without supporting material or reasoning offers little visibility into the actual situation.

Checks to complete now

Professional uses, including those involving contractors, have been inventoried.
The purpose and excluded uses are documented for each scenario.
The roles of deployer and provider have been assessed.
Prohibited practices have been reviewed.
The system’s classification and applicable schedule are documented.
AI literacy measures are tailored to people’s responsibilities.
Applicable transparency obligations have been implemented.
Data flows and GDPR obligations have been reviewed.
Permissions, approvals, and shutdown procedures have been tested.

Conditional preparation for high-risk systems

The provider’s instructions and limitations are available.
Human oversight and operational monitoring are organized.
Log retention is defined in accordance with applicable rules.
Information for workers and affected individuals is prepared.
The need for a fundamental rights impact assessment has been examined.
Any registration obligations have been checked against the business’s role.

Maintaining the compliance file

An incident procedure identifies contacts and actions.
Changes that could affect the classification are tracked.
Every gap has a corrective action, a deadline, and a decision-maker.
The legal texts and provider documents used are dated and archived.

The useful deliverable is a file that explains why a use was authorized, under what conditions, and with which controls. It should also make it possible to recognize when that authorization needs to be reviewed.

Frequently asked questions

Does the AI Act apply to a small business using an AI assistant?

Yes. Using AI for work can make a small business a deployer under the regulation. However, its obligations depend on the system and its intended purpose: using a writing assistant does not automatically trigger the rules for high-risk systems.

Does every employee need an AI Act certificate?

The regulation does not require a universal certificate. Businesses must take appropriate measures to support AI literacy; they can document internal workshops, guidance, and exercises tailored to the tools employees use.

Are the obligations for high-risk systems already applicable in October 2026?

The revised schedule provides for their application from December 2, 2027, for Annex III systems and August 2, 2028, for systems linked to regulated products under Annex I. Prohibitions and other obligations, including transparency requirements, follow a separate schedule.

Is locally hosted AI software exempt from the regulation?

Local hosting does not provide a general exemption. It can change data flows and technical risks, but the legal classification still depends on the system, its use, and the business's role.

Is human approval enough to make an AI agent compliant?

Approval does not replace system classification or any other applicable obligations. Oversight must also be effective: the person reviewing the result needs enough information, time, and authority to reject or correct it.

AI Act: a compliance checklist for businesses using AI agents and tools