An EU AI Act compliance checklist begins before the control list

A useful EU AI Act compliance checklist does not ask every company to complete every requirement in the Regulation. It establishes which system is being assessed, why it exists, which actor the organization is, which category may apply, and which evidence supports the conclusion.

I learned the importance of that order while building Skybridge. A platform can contain access controls, approval screens, logs, and release records. Those components answer engineering questions. They become regulatory evidence only when attached to the relevant legal duty and the exact system version.

Use this checklist to verify classifications, exemptions, deadlines, sector-specific consequences, ownership, and release evidence for the exact system.

Stage 1: identify the system and legal scope

Write one sentence describing the intended purpose, users, affected people, inputs, outputs, and actions. Record where the system is offered, used, and where its output is used. Article 2 contains territorial and activity scope rules that can reach some organizations outside the EU.

Then test whether the product or process meets the Act's definition of an AI system. The Commission has issued guidelines on that definition because conventional software and fixed rules should not be classified casually. Store the reasoning and the version of the guidance used.

Minimum evidence:

• system name and version.
• intended purpose and prohibited uses.
• markets, users, and affected groups.
• model, application, and connected services.
• scope conclusion, reviewer, and date.

Stage 2: assign roles and classify the intended purpose

Identify the provider, deployer, importer, distributor, product manufacturer, and authorized representative where relevant. Add upstream GPAI model providers and component suppliers to the map even when they occupy a different regulatory track.

Next, screen the intended purpose against Article 5 prohibited practices, Article 6 and Annex III high-risk categories, product legislation in Annex I, and Article 50 transparency cases. Record uncertainty. A legal-review flag is a valid outcome.

Human review belongs in the control assessment. It should not be used as shorthand for a lower risk category. An AI system used to rank applicants can remain within an employment high-risk category even when a manager confirms the final decision.

Stage 3: screen immediate obligations

Some requirements already apply and deserve an early pass across the inventory.

Article 50 is narrower and more detailed than “label everything made with AI.” Direct interaction, provider-side machine-readable marking, deepfakes, emotion recognition, biometric categorization, and certain text published on matters of public interest have different rules and exceptions. Use the Commission's July 2026 guidelines for the exact case.

Stage 4: prepare high-risk evidence where applicable

The amended timetable provides additional preparation time for specified high-risk systems. It does not turn high-risk work into a task for the week before the deadline.

Where classification indicates a high-risk system, map the responsibilities that apply to the organization's role. Provider work can include risk management, data governance, technical documentation, logs, information for deployers, human oversight design, accuracy, cybersecurity, quality management, conformity assessment, registration, and post-market duties. Deployer duties differ and include operating according to instructions, assigning competent oversight, monitoring, controlling input data where applicable, keeping logs under its control, and responding to risk or incidents.

Create an obligation matrix with five columns: legal provision, accountable party, system control, evidence, and current gap. The named legal decision owner owns the interpretation. Engineering and operations own proof of actual behavior.

Stage 5: examine suppliers and the AI value chain

An enterprise application may depend on a model API, a connector gateway, cloud infrastructure, a vector store, and a communication provider. The supplier list must follow the data and capability path.

Ask each relevant provider for the exact product, plan, region, model, terms, documentation, restrictions, and change process. Record whether the supplier supports the evidence your own role requires. A model card cannot explain the authorization logic in your retrieval layer. An application security document cannot describe the upstream model's training or evaluation.

Skybridge uses multiple model providers and external connectors. Maintaining a provider inventory taught us to record the route selected for each system, not merely every provider the platform could support.

Stage 6: test the release in production-like conditions

Policy becomes evidence through observable cases.

For a system that prepares supplier communication, test an unauthorized project, a revoked user, conflicting sources, a prompt injection inside a document, a changed recipient, an expired approval, a repeated event, and a provider timeout. Define the required response before running the case.

Compsia uses two internal release gates. Gate A covers the real-data path, including authority, providers, access, retention, incident ownership, export, and deletion. Gate B adds action controls, provenance, authenticated approval, replay handling, failure tests, rollback, and manual fallback. These are delivery controls rather than statutory EU AI Act categories. They help produce evidence for the applicable duties without pretending to replace legal analysis.

The Skybridge cockpit records Gate A and Gate B evidence at release level, keeping implemented controls, accepted operating boundaries, and required follow-up in the correct decision record.

Stage 7: monitor changes and incidents

Set review triggers for changes to purpose, users, affected groups, data, model, provider, retrieval, action authority, interface, and market. Article 25 makes some changes especially consequential for high-risk systems because rebranding, substantial modification, or a changed intended purpose can alter provider responsibility.

Keep system logs, approval records, release history, incident decisions, corrective action, and current instructions according to the duties and other applicable laws. More logging is not automatically better. Retention, access, security, and personal-data rules still apply.

The final checklist row should be a decision signed by named owners: release, release with conditions, narrow, continue evaluation, or stop. Compsia's secure enterprise AI framework explains how the surrounding production path supports that decision.

Questions about AI Act compliance checklists

Is there one official EU AI Act checklist?

The Commission provides the AI Act Service Desk, Explorer, and a beta Compliance Checker. These tools support orientation. They do not replace a case-specific legal assessment or the evidence needed to operate the system.

Does this checklist apply only to high-risk AI?

No. The early stages screen scope, prohibited practices, literacy, transparency, GPAI dependencies, and role. The high-risk evidence stage applies only where the classification and dates make it relevant.

Can an organization finish AI Act compliance once?

A documented assessment can reach a decision for a defined system and version. Material changes, incidents, new guidance, and new uses can reopen the assessment.