AI compliance: requirements, applicability and a practical checklist

AI compliance is meeting the specific legal, regulatory, standards and contractual requirements that apply to your AI systems, and keeping evidence that you did. It is outward-facing: someone else (a regulator, auditor or customer) defines the requirement, and you show you meet it.

That is different from AI governance, which is the internal system of ownership, risk assessment, controls and oversight that decides how AI is used. Governance is what makes compliance repeatable rather than a one-off project. We explain the distinction in AI governance versus compliance.

Requirements depend on where you operate and where the people affected by your AI are. The EU has the most developed AI-specific regime; the United States relies on state laws and existing sector rules. Statuses below were checked on 3 October 2026; confirm with the official sources before acting.

Not legal advice. The EU Commission and state legislature sites are the authority for current dates, and further amendments are possible.

Work out applicability system by system, using four questions: what is your role, what is the system used for, who does it affect, and where are they? Run these questions against every entry in your AI inventory, not once for the whole organisation.

1. List the AI systems you build, buy, embed in products or let staff use. Include vendor AI features.
2. Identify your role for each: provider (develops or places a system on the market), deployer (uses it under your authority), importer or distributor. Roles differ per system and can change if you substantially modify a third-party system.
3. Identify the use case and whether it falls into a regulated category: a prohibited practice, an Annex III high-risk area (for example employment, education, essential services or biometrics), a transparency case such as chatbots or synthetic media, or a general-purpose model.
4. Identify who is affected and where. The EU AI Act can apply to non-EU organisations whose system outputs are used in the EU; GDPR and state laws turn on where the individuals are.
5. Check personal data use: if the system processes personal data, GDPR duties apply regardless of AI Act classification.
6. Record the conclusion, the reasoning and the date, and re-run it when the use case, model or law changes.

AI compliance proves you meet specific external requirements; AI governance is the internal system that decides how AI is used and keeps you in control. Compliance without governance tends to be a snapshot; governance without compliance mapping can miss legal duties.

A practical AI compliance checklist covers inventory, role and classification, risk assessment, controls, documentation, transparency, oversight, vendor management, training and monitoring. Use it per system, and keep the evidence next to each item.

• Inventory: every AI system recorded with owner, purpose, vendor, data and location.
• Applicability: provider or deployer role, risk category and applicable laws documented.
• Prohibited practices: screened and confirmed not in use.
• Risk assessment: documented, including impact on individuals; DPIA completed where required.
• Data: data quality, provenance and personal data handling reviewed.
• Testing: accuracy, robustness and bias testing with recorded results.
• Human oversight: defined roles, authority to intervene and training.
• Transparency: notices for AI interaction and synthetic content where required.
• Vendors: due diligence and contract terms for third-party AI.
• Staff: AI literacy measures and an acceptable use policy.
• Approvals: sign-off before launch and after material change.
• Monitoring: metrics, incident process, reassessment triggers and review dates.

Auditors and regulators expect dated, attributable records showing that a control exists and operated, not statements of intent. Evidence should be retrievable per system and show who did what and when.

• Inventory and classification records with reasoning and dates.
• Risk assessments, DPIAs and impact assessments.
• Test and evaluation results, with versions of the model and data tested.
• Approval records and exceptions with expiry dates.
• Training and AI literacy records.
• Monitoring outputs, incident logs and corrective actions.
• Vendor due diligence files and contracts.
• Policies with owners, version history and review dates.

Evidence goes stale. Set review dates and record when each item was last verified.

The most common failures are an incomplete inventory, misclassifying systems, unclear ownership and missing evidence. Most are process gaps, not technical ones.

• Shadow AI: tools in use that nobody registered, so they were never assessed.
• Vendor blind spots: AI features inside purchased software treated as out of scope.
• One-off classification: a system assessed at launch and never reassessed after a model or purpose change.
• Outdated legal assumptions: working to superseded deadlines, for example EU high-risk dates before the Digital Omnibus or Colorado dates before SB 26-189.
• Role confusion: a deployer that modifies a system and takes on provider-level duties without noticing.
• Policy without evidence: a good document and no records showing it is followed.
• Consequences vary by law. Under the EU AI Act, fines for transparency breaches reach up to EUR 15 million or 3% of worldwide annual turnover, whichever is higher, with higher ceilings for prohibited practices.

Look for software that keeps an inventory, records classification and applicability, maps requirements to controls, stores evidence and approvals, and shows what is out of date. Be wary of tools that claim to make you compliant: software supports the work but legal responsibility stays with you.

• Clear sourcing and versioning of the requirements it maps.
• Per-system records, not only organisation-wide checklists.
• Evidence and approval history you can export for an auditor.
• Honest statements of what is automated and what is manual.

AIGovernr gives teams a workspace to register AI systems, classify them, assign requirements and tasks, attach controls and evidence, and record approvals. Its framework releases are versioned and mapped to published obligations; coverage shows mapped content, not your compliance status, and the product does not provide legal validation or certification.