An AI Act compliance checklist starts with your role

An AI Act compliance checklist should begin with one uncomfortable fact: the same company can be a provider, deployer, importer, and distributor at the same time. Your role attaches to a specific AI system and a specific use, not to the logo on your office door. If you label the whole business a deployer and move on, every later answer may be wrong.

The practical job is to build a defensible, reviewable chain. Keep the reasoning close to the product record so a new owner can reproduce it after staff change, a vendor update, or a customer dispute. The operating record should survive the people who first made the call. The job is from product inventory to role, scope, risk class, duties, evidence, and deadline. That chain matters more than a polished policy. A regulator, enterprise buyer, or board member will ask how you reached the classification and whether the product behaves as the file says it does.

This checklist reflects Regulation (EU) 2024/1689 as amended by Regulation (EU) 2026/1744, which entered into force on 27 July 2026. It is an engineering and management guide, not a substitute for advice on a disputed classification or a launch with serious fundamental-rights consequences.

Inventory uses, not vendor names

Start with one record for every real use of AI, including internal tools, product features, customer-specific configurations, experiments exposed to users, and models distributed to other companies. A vendor list is too coarse. One foundation-model API might power harmless copy suggestions, candidate ranking, and a support bot; those uses can trigger different roles and duties.

Give each record a stable system ID and name the business owner, technical owner, model or service, intended purpose, affected people, input data, output, customer, countries, release state, and decision influenced by the output. Record whether a person can override the result and what happens when nobody does. Attach vendor terms and version numbers rather than relying on a link that can change later.

Do not wait for procurement to find everything. Ask finance for AI subscriptions, scan source repositories for model SDKs and endpoints, review browser extensions approved by IT, and interview teams about spreadsheet plugins and meeting assistants. Shadow AI matters because Article 4 requires providers and deployers to take measures for sufficient AI literacy among staff and others operating AI systems on their behalf. Training cannot cover tools the company refuses to see.

Use separate rows when purpose or control changes. A résumé summarizer sold to recruiters is one record. Your own use of the same component to rank applicants is another. A customer who relabels or substantially modifies it may create a third provider relationship. This extra detail feels tedious until a sales deal asks for an answer in two days. Then it is the difference between evidence and improvisation.

The inventory should also identify systems that were retired. Keep the last deployed version, retirement date, data-retention decision, open incidents, and customers still running an older release. The Act has transition rules for systems already on the market, but a version history is necessary to show whether a later change was significant. Calling every update maintenance does not make it so.

Decide whether the Act reaches the system

The Act reaches more than EU-incorporated companies. Article 2 covers providers placing AI systems or general-purpose AI models on the EU market, deployers located in the EU, and providers or deployers outside the EU when the output produced by the system is used in the EU. A US startup with no EU office may therefore be in scope. Location of servers is not the decisive test.

First decide whether the software is an AI system under Article 3. The definition covers a machine-based system designed to operate with varying levels of autonomy, which may adapt after deployment and infers from inputs how to generate outputs such as predictions, content, recommendations, or decisions that can influence physical or virtual environments. The Commission guidelines on the AI-system definition explain that inference is a distinguishing feature and that ordinary software following rules defined solely by people may fall outside. The guidelines are non-binding, so save the reasoning rather than writing only a yes or no.

Do not treat machine learning as the only gate. A system can fit without learning after deployment, and marketing language does not decide the issue. Conversely, a database query, deterministic tax calculator, or fixed workflow does not become AI because the product page says intelligent. Describe the technical mechanism, who sets the rules, what the system infers, and what output it produces.

Then test the exclusions and special cases. The Act excludes AI used solely for military, defence, or national-security purposes; systems and models developed and put into service solely for scientific research and development; and activity before market placement or service, subject to conditions. Free and open-source releases receive some exemptions, but the label does not erase prohibitions, transparency duties, or rules for high-risk systems and general-purpose models with systemic risk. Personal non-professional use is outside the deployer definition.

Record the territorial hook per use. Useful evidence includes EU customer contracts, availability settings, intended user countries, and where outputs enter a decision. Geo-blocking that exists only in a presentation will not help if the signup flow accepts EU customers and the sales team supports them.

Assign every operator role per system

Role determination controls the obligation set, so write it as a short decision memo for each system. Article 3 defines the actors; Article 25 explains when a downstream party can become the provider. The names resemble supply-chain law because that is how the Act works.

A provider develops an AI system or general-purpose AI model, or has one developed, and places it on the market or puts it into service under its own name or trademark. Payment is irrelevant. A SaaS company that wraps a third-party model in its branded hiring product can be provider of the resulting AI system even though it did not train the underlying model. It may also remain a deployer of the vendor model in another context.

A deployer uses an AI system under its authority in a professional setting. Your customer will often be the deployer, but your company is also a deployer when HR uses an applicant-screening tool or support staff use an assistant. The word user in product analytics is unhelpful here because the Act distinguishes deployers from affected natural persons.

An importer is an EU-established person that places on the market an AI system bearing the name or trademark of a provider established outside the EU. A distributor makes an AI system available in the EU supply chain but is neither the provider nor the importer. A non-EU provider covered by the Act may need an authorised representative in the EU under the applicable provisions. Record the legal entity, not merely the team, for each role.

A company becomes provider of a high-risk system when it puts its name or trademark on that system, makes a substantial modification, or changes the intended purpose so that the system becomes high-risk, subject to the details in Article 25. This is the trap in white-label agreements. The contract may call you a reseller while the product and law make you the provider.

For each row, complete these five tests:

1. Who determines the intended purpose and release under a name or trademark?
2. Who operates the system professionally, and under whose authority?
3. Who first brings a non-EU provider's system into the EU market?
4. Who supplies it onward without taking another role?
5. Has anyone relabelled, substantially modified, or repurposed it?

Write multiple roles if multiple answers apply. Then map obligations by role instead of searching for one universal checklist. Have counsel review ambiguous relabelling, modification, and territorial cases before launch, because a contract cannot privately cancel a statutory role.

Classify the use before scoring its risk

The Act uses legal categories, not a home-grown low-medium-high matrix. Internal risk scoring can help engineering, but it cannot replace the sequence of prohibited practice, general-purpose model, high-risk system, specific transparency duty, and other system. A low score from security does not exempt an employment system listed in Annex III.

Check Article 5 first. Prohibited practices include specified forms of manipulative or deceptive techniques causing significant harm, exploitation of vulnerabilities, social scoring, some predictive policing, untargeted scraping of facial images, certain emotion recognition in workplaces and schools, sensitive biometric categorisation, and most real-time remote biometric identification for law enforcement in public spaces. Each prohibition has elements and exceptions. Match facts to the text; do not classify by a one-line nickname. Regulation (EU) 2026/1744 added prohibitions concerning systems intended to generate child sexual abuse material or non-consensual sexually explicit or intimate content, with those additions applying from 2 December 2026.

Next separate a general-purpose AI model from an AI system built on it. A model is a technical component capable of a wide range of tasks; the downstream application is the system people use. Providers of general-purpose models have model-level documentation, downstream information, copyright-policy, and training-content-summary duties under Article 53, with extra evaluation, systemic-risk, incident, and cybersecurity duties for models classified as presenting systemic risk. A software company calling an external model through an API usually is not the model provider, but it may be provider of its application. Fine-tuning does not automatically settle the answer. The Commission's GPAI guidelines say only significant modifications make a modifier subject to provider duties for the modified model, and the legal assessment depends on what changed.

For high-risk classification, run both routes. Article 6(1) covers an AI system that is a safety component of a product, or itself a product, under Annex I legislation when the product requires third-party conformity assessment. Article 6(2) and Annex III cover listed uses in areas such as biometrics, critical infrastructure, education, employment, access to essential services, law enforcement, migration, and justice. The intended purpose and the function in the decision matter more than the department buying it.

An Annex III use may avoid high-risk status under Article 6(3) when it does not pose a significant risk of harm to health, safety, or fundamental rights and does not materially influence decision-making, including certain narrow procedural, preparatory, pattern-detection, or review tasks. Profiling natural persons keeps an Annex III system high-risk. If you rely on the exception, Article 6(4) requires a documented assessment before market placement or putting into service, and providers register the system when the relevant registration duty applies. Treat that memo as a classification deliverable, not a note in a ticket.

Finally, test Article 50 even when a system is not high-risk. It covers direct interaction with people, machine-readable marking of synthetic outputs by providers, disclosure for emotion-recognition and biometric-categorisation systems by deployers, and disclosure of deepfakes and certain AI-generated public-interest text. These are use-specific duties. The residual category is not no risk; GDPR, consumer law, copyright law, employment law, product safety rules, and contracts may still apply.

Build the evidence pack around the role

Documentation should prove a claim, name an owner, and stay tied to a released version. A folder full of vendor PDFs is not a compliance system. Create an evidence index that connects every requirement to the artifact, approver, date, product version, and review trigger.

For any in-scope system, keep the scope memo, role memo, classification analysis, intended-purpose statement, system and data-flow description, vendor records, AI-literacy plan, transparency text, incident path, change log, and applicable-law register. Add the actual user interface or output sample that proves a notice appears. A requirements document saying a label should exist proves only that somebody wrote a requirement.

A provider preparing a high-risk system needs the deeper Article 9 to 15 and provider-duty package when those provisions apply: risk management, data governance where training or validation data is used, technical documentation under Article 11 and Annex IV, automatic logging, instructions for deployers, human-oversight design, accuracy, resilience, cybersecurity, quality management, conformity assessment, registration, declaration of conformity, CE marking where required, corrective action, post-market monitoring, and serious-incident reporting. Build these artifacts during development. Reconstructing design decisions after an incident produces weak evidence and bad engineering.

A deployer of a high-risk system has a different file. It should show use according to instructions, assigned human oversight, monitoring of input data and operation, log retention under its control, incident escalation, worker information where relevant, and a fundamental-rights impact assessment when Article 27 applies. Certain public bodies and private entities providing public services have that assessment duty, as do specified deployers of systems used for creditworthiness and life or health insurance risk and pricing. The assessment is not a generic ethics slide; it addresses affected groups, impacts, oversight, complaints, and mitigation in the actual deployment.

Importers verify conformity assessment, technical documentation, CE marking, declaration, instructions, and the provider's authorised representative before placement. Distributors verify required marking, declaration, instructions, and upstream compliance before making a high-risk system available. Both need stop-and-escalate procedures when they have reason to think a system is non-conforming. A purchase order does not perform these checks.

The evidence index can be kept in a repository in a format people can review:

system_id: hr-screen-014
version: 3.2.1
intended_purpose: rank applicants for recruiter review
roles:
  company_a: provider
  customer: deployer
classification:
  route: Annex III employment
  result: high-risk
controls:
  human_oversight: docs/oversight-v3.md
  logging: specs/event-log-3.2.yaml
  instructions: releases/3.2/instructions.pdf
review_triggers:
  - intended purpose changes
  - model or threshold changes
  - new affected population
owner: product-compliance
approved_release: 2026-08-01

This fragment is deliberately boring. Its value is traceability: a reviewer can move from legal conclusion to deployed version and evidence without guessing which document is current.

Put transparency in the product surface

Transparency duties require a notice at the moment and place where a person encounters the system or content. Hiding an AI statement in terms of service usually fails the practical test because the affected person does not see it before or during the interaction. Article 50 generally requires information to be clear and distinguishable, at the latest at first interaction or exposure, and accessible to people with disabilities.

For a chatbot or voice agent, tell people they are interacting with AI unless that fact is obvious to a reasonably informed, observant, and circumspect person in context. Test the real interface with ordinary users. A bot name or sparkle icon does not reliably communicate the fact, especially when the product deliberately writes like a person. Keep a screenshot, localized copy, accessibility test, and release test.

Providers of systems that generate synthetic audio, image, video, or text must design outputs so they are marked in a machine-readable format and detectable as artificial or manipulated, subject to technical feasibility and the Act's exceptions. This is a provider-side control, not the same duty as a visible disclosure to a reader. Regulation (EU) 2026/1744 gives providers of such systems already placed on the market before 2 August 2026 until 2 December 2026 to comply with Article 50(2). New placements do not get that specific transition.

Deployers using emotion-recognition or biometric-categorisation systems must inform exposed people, subject to exceptions, and process personal data under the applicable data-protection rules. Deployers of systems that create or manipulate deepfake image, audio, or video must disclose the artificial origin, with tailored treatment for evidently artistic, fictional, satirical, and similar works. For AI-generated or manipulated text published to inform the public on matters of public interest, disclosure applies unless a human review or editorial-control condition and responsibility for publication are met.

Do not collapse machine-readable marking, visible disclosure, and high-risk instructions into one transparency task. They serve different recipients and can all apply to one feature. Assign separate acceptance tests for the output metadata, the person-facing notice, and the operator documentation.

Use the amended dates, not an old slide

The date list must reflect the law now in force. Regulation (EU) 2024/1689 entered into force on 1 August 2024 and uses staged application. Regulation (EU) 2026/1744 changed several stages in July 2026, so many 2024 and 2025 summaries now give the wrong high-risk dates.

The operative timeline for most software companies is:

• 2 February 2025: Chapters I and II started applying, including definitions, AI-literacy measures, and the original prohibited practices.
• 2 August 2025: governance provisions and obligations for providers of general-purpose AI models started applying; providers of models placed on the market after that date entered the new regime.
• 2 August 2026: the Act's general application date brought most remaining provisions into effect, including Article 50 transparency duties; Commission enforcement powers for general-purpose model providers also apply.
• 2 December 2026: the new prohibited-practice provisions added by Regulation (EU) 2026/1744 apply, and pre-2 August 2026 generative systems reach the Article 50(2) marking deadline.
• 2 December 2027 and 2 August 2028: Chapter III Sections 1 to 3 apply respectively to Annex III high-risk uses and Article 6(1) Annex I product-related high-risk systems.

There are other transition points. Providers of general-purpose models placed on the market before 2 August 2025 must comply by 2 August 2027. Operators of certain high-risk systems first placed on the market or put into service before the relevant high-risk application date are generally brought into the regime when the design is significantly changed after that date, while providers and deployers of high-risk systems intended for public authorities have a 2 August 2030 backstop under Article 111. Exact treatment depends on the system and amendment history.

A delayed high-risk deadline is preparation time, not permission to ignore existing duties. Prohibitions and AI literacy already apply. General-purpose model rules and most transparency duties already apply. Product teams also face GDPR, equality, consumer, sectoral, and contractual requirements today. Use the later dates to finish controls with release evidence instead of scheduling classification for the week before enforcement.

Put every date in a compliance calendar with the legal provision, affected system IDs, accountable executive, working deadline, and external deadline. Set the working deadline early enough for product changes, conformity work, customer notices, and contract updates. A calendar entry called AI Act compliance with no affected systems is decoration.

Turn the checklist into release gates

A useful checklist can stop a release. It does not live as an annual questionnaire owned only by legal. Add gates to discovery, procurement, architecture review, launch, material change, incident response, and retirement, with an owner who can block deployment when the evidence is missing.

At intake, require a system record, intended purpose, countries, affected people, and vendor identity. Before design approval, require the scope, territorial, role, prohibited-practice, GPAI, high-risk, and Article 50 analyses. Before launch, require the applicable notices, instructions, logging, oversight, vendor terms, testing, and evidence index. High-risk systems need the provider or deployer package appropriate to their role when the relevant provisions apply.

Procurement needs its own gate because vendor assurances are inputs, not conclusions. Ask the vendor to identify its legal entity and role, describe the system and model chain, commit to version and change notices, supply documentation needed for your role, allocate incident cooperation, address logs and retention, and explain what happens if it discontinues the service. If the vendor refuses information that you need to operate lawfully, record the risk and choose whether the business can accept it. A security questionnaire cannot answer role or intended purpose.

Changes should reopen classification when they affect purpose, users, geography, model, training or retrieval data, autonomy, decision weight, output type, branding, or supply chain. Use a diff, not a vague materiality checkbox. A feature that begins as drafting assistance can become employment decision support after a manager adds an automatic rejection threshold. The code change may be small while the legal change is large.

Use this release record as the minimum sign-off:

SYSTEM ID AND VERSION:
INTENDED PURPOSE APPROVED BY:
EU SCOPE AND TERRITORIAL HOOK:
OUR ROLE OR ROLES:
PROHIBITED PRACTICE CHECK:
GPAI MODEL DUTIES CHECK:
HIGH-RISK ROUTE AND RESULT:
ARTICLE 50 DUTIES AND TEST EVIDENCE:
DOCUMENT INDEX AND VENDOR EVIDENCE:
NEXT REVIEW TRIGGER AND OWNER:
RELEASE DECISION, DATE, APPROVER:

When an incident occurs, preserve the version, inputs, outputs, logs, human actions, affected group, timeline, vendor communications, and mitigation. Route it against AI Act serious-incident rules where applicable, plus data-breach, safety, consumer, and contractual procedures. One event can trigger several clocks. Teams lose time when every policy assumes another team owns the first assessment.

Retirement is also a gate. Remove access, decide lawful retention, preserve required logs and conformity evidence, notify customers when necessary, revoke integrations, and close monitoring obligations. Keep enough history to explain which version operated for which customer and whether a successor reused the same intended purpose.

Give one person the map and many people the controls

An accountable executive should own the system map, deadlines, and unresolved classifications, while control owners remain in engineering, product, HR, procurement, security, support, and legal. Centralising every task in legal creates a queue and hides design decisions. Decentralising the map creates conflicting roles and forgotten systems.

Review the inventory quarterly and on every trigger event, but review high-impact deployments more often when incidents, drift, or vendor changes demand it. Report a small set of facts to leadership: systems without owners, role decisions awaiting review, prohibited uses stopped, controls overdue, vendor evidence missing, incidents open, and deadlines at risk. Counts should lead to named records, not a green score assembled from self-attestation.

A Team & AI Audit from oleg.is can help a founder connect this compliance map to team ownership, tooling, and engineering cost, but counsel should own contested legal interpretations. The useful output is a smaller operating system for decisions: each AI use has a role, classification, evidence file, release gate, and date. If any of those five fields is blank, the system is not ready merely because the model works.