EU AI Act Checklist

Create one checklist row per AI system, general-purpose AI model, or downstream product integration. The row should state whether the activity involves placing on the EU market, putting into service, using the system in the EU, or using output in the EU.

Record the operator role before assigning obligations. The AI Act distinguishes providers, deployers, importers, distributors, authorised representatives, product manufacturers, downstream providers, and affected persons. A company can hold more than one role for the same AI value chain.

Classify the checklist row before drafting controls. If a practice is prohibited, the practical answer is to stop, redesign, or escalate before deployment. If the system is high-risk, move to the high-risk evidence section. If it is limited-risk, check transparency obligations. If it is minimal-risk, keep the classification record and monitor for changes in purpose, data, users, or integration.

For Annex III systems, do not rely only on the sector label. Record the intended purpose, whether the system materially influences decision-making, whether profiling of natural persons is performed, and whether a narrow-task or preparatory-task exception is being claimed.

For each high-risk AI system, collect evidence before placing it on the market or putting it into service. The evidence pack should show that the provider can demonstrate compliance to a competent authority or notified body, and that deployers have the information needed to use and monitor the system appropriately.

When the system is already subject to sectoral product legislation, note whether AI Act evidence can be integrated into the existing product compliance, quality, or post-market files instead of creating a duplicate set.

For general-purpose AI models, keep a model-level record separate from downstream AI system records. Downstream teams need enough information to understand capabilities and limitations, while providers need their own technical documentation, copyright-policy evidence, and public training-content summary where Article 53 applies.

For GPAI models with systemic risk, add systemic-risk evaluation, mitigation, cybersecurity, and serious-incident records. Do not treat a downstream application review as a substitute for model-provider obligations.

Run transparency checks for both high-risk and non-high-risk AI systems. Article 50 duties are triggered by specific interactions and content types, so the checklist should identify the user-facing moment when information, marking, or disclosure must appear.

Keep the implementation evidence close to the product artifact: screenshots, UI copy, API fields, machine-readable marking approach, accessibility review, and the release version in which the notice or marker ships.

Close each checklist row only after it names the records that will be updated after release. High-risk systems need a documented post-market monitoring system and plan; deployers also need a path to inform providers and authorities when operation shows risk or a serious incident occurs.

Incident playbooks should separate high-risk AI system reporting from GPAI systemic-risk reporting, because the recipients and templates can differ.

Use these fields for the AI Act inventory and evidence table. They are designed to make each row reviewable while keeping confidential preparation artifacts and non-public company materials separate from published evidence references.

Reopen the row when the intended purpose changes, a GPAI model or supplier changes, the system enters a new Annex III use case, a transparency trigger is added, a serious incident occurs, or a competent authority, notified body, customer, or internal approver requests new evidence.