Written and reviewed by Irfan Ullah, Founder of TrusteraAI and creator of the TrusteraAI AI Risk Assessment Framework™. Last updated: August 2026 · Regulatory review: August 2026.
This checklist is an operational compliance aid, not legal advice. Applicability depends on your organization’s role, AI system, jurisdiction, sector and use case. Confirm material legal decisions with qualified counsel.
AI compliance checklists published before the July 2026 Digital Omnibus amendment may now contain outdated EU AI Act deadlines. The amendment did more than move dates: it also introduced substantive changes, including two new prohibited practices and an adjustment to how bias-detection data can be processed under GDPR. Treating every provider obligation as live today, when several were deferred by more than a year — while overlooking what actually changed in substance — sends teams chasing controls that aren’t due yet while missing the ones that are.
An AI compliance checklist is a structured set of controls organizations use to verify AI governance across the frameworks that apply to them — typically the EU AI Act, GDPR, ISO/IEC 42001, and NIST AI RMF. A checklist accurate as of August 2026 must reflect the Digital Omnibus’s deferral of Chapter III high-risk obligations to December 2027 and August 2028, its new Article 5 prohibitions, and the fact that several state and national AI laws changed status mid-year. For the broader AI governance framework behind this checklist, see our AI Governance Checklist for SaaS.
A Gartner survey of 302 cybersecurity leaders found that 69% of organizations suspect or have direct evidence of employees using unsanctioned generative AI tools. Separately, IBM’s 2025 Cost of a Data Breach Report found that breaches involving a high level of shadow AI cost organizations $670,000 more on average than breaches without it. This checklist consolidates what’s actually required, what’s still coming, and where to start.
🎯 Start Here
Need the full checklist now? Jump to the Master Compliance Checklist
Confused about what’s actually enforceable in 2026? Jump to What Applies Now vs. What’s Deferred
Not sure which parts apply to you? Jump to Which Frameworks Apply to You?
Just getting started? Jump to Foundation: Governance Before Frameworks
What Is an AI Compliance Checklist?
AI compliance sits at the intersection of several frameworks that overlap but aren’t identical: the EU AI Act (a binding regulation with staged applicability dates), GDPR (which applies whenever AI processes personal data), ISO/IEC 42001 (a voluntary, certifiable management-system standard), and NIST AI RMF (a voluntary US-oriented risk framework). A complete checklist doesn’t just list controls — it tells you which ones are legally required today, which are voluntary best practice, and which are correct but not yet due. It also shouldn’t imply that every listed control is a universal legal requirement for every organization — see “How to Use This Checklist” below for how the role and status tags work.
First, Determine Your AI Act Role
Before working through the checklist, establish which role you hold, since obligations differ by role:
- Provider — develops an AI system (or has one developed) and places it on the market, or puts a GPAI model into service, under its own name or trademark.
- Deployer — uses an AI system under its own authority, other than for personal non-professional use.
- Importer, distributor, and GPAI provider are additional defined roles that apply less often to typical SaaS founders.
A US-based SaaS company serving EU customers may be a deployer for AI tools it uses internally, and may also be a provider where it places an AI system on the EU market or puts it into service under its own name or trademark — this can happen even without a standalone “AI product,” for example when an AI feature is rebranded and shipped as part of an existing product. Your role determines which checklist items below actually apply to you — a deployer generally doesn’t carry provider-only obligations like Annex IV technical documentation.
What Applies Now vs. What’s Deferred
Start with this table before assigning work. It separates obligations that apply now from those deferred by the 2026 amendments.

| Obligation | Status as of August 2026 |
|---|---|
| EU AI Act Article 5 — Original 8 prohibited practices | ✅ Applicable since February 2, 2025 |
| EU AI Act Article 5 — New prohibitions added by the Digital Omnibus (AI-generated non-consensual intimate imagery / CSAM) | ⏸️ Apply from December 2, 2026 |
| EU AI Act Article 4 — AI literacy | ✅ Applicable since February 2, 2025; standard softened by the Digital Omnibus (see our AI Acceptable Use Policy Template for detail) |
| EU AI Act Articles 53–56 — GPAI model obligations | ✅ Applicable since August 2, 2025 |
| EU AI Act Article 6 — Classification rules (Sections 1–3 of Chapter III) | ⏸️ Deferred along with the rest of Chapter III Sections 1–3, on the same December 2027 / August 2028 split — except Article 6(5) |
| EU AI Act Article 6(5) — Commission’s duty to publish classification guidance | ✅ Applicable now (this is a Commission duty, not a provider obligation — see note below) |
| EU AI Act Article 50 — Transparency | ✅ Applicable since August 2, 2026 (deployer duties immediate; provider marking under Article 50(2) has a limited grace period to December 2, 2026 for pre-existing systems); scope limits and exemptions apply — confirm before assuming disclosure is required |
| EU AI Act Articles 9–17 — High-risk provider obligations (Annex III, Chapter III Secs. 1–3) | ⏸️ Deferred to December 2, 2027 |
| EU AI Act Articles 9–17 — High-risk obligations (Annex I, embedded products) | ⏸️ Deferred to August 2, 2028 |
| EU AI Act — High-risk AI intended for use by public authorities | ⏸️ Extended further, to August 2, 2030, under the Digital Omnibus |
| EU AI Act Article 26 — Deployer obligations for high-risk systems | ⏸️ Deferred on the same split as Articles 9–17, per Regulation (EU) 2026/1744 |
| EU AI Act Article 73 — Serious incident reporting | ⏸️ Applies once the underlying high-risk classification’s Chapter III obligations apply — see our AI Incident Response Plan |
| GDPR (all articles) | ✅ Fully applicable, unaffected by the AI Act’s timeline |
| Colorado — SB 26-189 (Automated Decision-Making Technology Act) | Signed May 14, 2026; takes effect January 1, 2027 — but enforcement is currently contested (see note below) |
| California — AI Transparency Act (SB 942, as amended by AB 853) | ✅ Operative since August 2, 2026 — AB 853 moved this date specifically to align with EU AI Act Article 50, per the legislative record |
A note on Article 6: per a Council of the EU working document on the Digital Omnibus, Article 6 itself — the classification rules — doesn’t apply until the deferred date arrives; “as long as Chapter III Section 1 does not apply, Article 6 does not apply, hence no AI system is considered as high-risk.” The one carve-out is Article 6(5), which obligates the European Commission (not providers) to publish classification guidance, and which had its own earlier deadline. In practice this means formally classifying your systems isn’t a live legal duty yet — but since the deadline is fixed, doing the assessment now as preparation, rather than waiting, is what the “Prepare now” tag below reflects.
A note on Colorado: xAI sued over the predecessor Colorado AI Act (SB 24-205) in April 2026, and the Colorado Attorney General has stated he does not intend to enforce SB 24-205 or its replacement, SB 26-189, until the related rulemaking process concludes. The January 1, 2027 effective date stands, but enforcement timing is currently unsettled — treat this as a “Prepare now” item and monitor for updates rather than assuming a fixed enforcement start.
Building a checklist around this table first — before assigning work — prevents teams from spending Q3 2026 on Annex IV technical documentation for a system that isn’t legally required to have it until 2027 or 2028, while a live obligation like Article 50 transparency goes unaddressed.
Which Frameworks Apply to You?
Not every organization needs every section below. Use this as a starting filter, then confirm against your AI inventory:
| Organization / AI role | EU AI Act | GDPR | ISO 42001 | NIST AI RMF | US state laws |
|---|---|---|---|---|---|
| SaaS company using ChatGPT/Claude internally | Limited (Art. 4, 5, 50 only)* | Yes, if personal data involved* | Optional | Recommended | Depends on states served* |
| AI-powered SaaS provider | Potentially broad coverage; assess role and system classification* | Yes, if personal data involved* | Optional | Recommended | Yes, if applicable* |
| GPAI model provider | Yes, where the organization qualifies as a GPAI provider; assess applicable Arts. 53–56 obligations* | Depends on processing | Optional | Recommended | Yes, if applicable* |
| Employer using AI in hiring | Yes* | Yes | Optional | Recommended | Yes* |
| Enterprise relying on AI vendors | Yes* | Yes | Optional | Recommended | Yes* |
*Asterisked cells depend on specifics — role, data processed, and jurisdiction. Confirm against your AI inventory rather than treating the table as a final answer.

How to Use This Checklist
Each item below carries two tags:
- A role tag — [Legal], [Technical], [Governance], or [Operations] — identifying the function best placed to own the item.
- A status tag — Required now, Prepare now, or Recommended.
| Status | Meaning | Action |
|---|---|---|
| Required now | Currently applicable legal obligation | Close gaps immediately |
| Prepare now | Deferred obligation, but the deadline is set | Build evidence and controls ahead of the deadline |
| Recommended | Governance or risk-management best practice, not a standalone legal mandate | Implement according to your own risk appetite |
[Legal] as a role tag means “legal should own this,” not “the law requires exactly this control for every organization.” Not every item applies to every organization or every AI system — apply the context notes to determine relevance, and run this against your AI Inventory system by system rather than as one organization-wide pass. Mark each item ✅ Done, 🔄 In Progress, or ⛔ Gap as you go.
TrusteraAI Compliance Triage
Before working item by item, run each AI system through this sequence — it’s the logic the checklist below is built on:
- Identify the system — is it in your AI inventory? If not, add it before doing anything else.
- Classify your role — provider, deployer, GPAI provider, or some combination, for that specific system.
- Determine applicability — which frameworks and laws actually reach this system, using the matrix above.
- Determine timing — Required now, Prepare now, or Recommended, using the table above.
- Assign ownership — Legal, Technical, Governance, or Operations.
- Collect evidence — policy, risk assessment, technical documentation, training records, or logs, as applicable.
- Record the gap — Done, In Progress, or Gap.
- Review — quarterly, and immediately after any regulatory update, new deployment, or reported incident.

Foundation: Governance Before Frameworks
Framework-specific compliance fails without this foundation in place first.
- [Governance | Recommended] A complete, current AI inventory exists — our AI Inventory Template covers the full 22-field structure
- [Governance | Recommended] Each AI system has a named owner with documented accountability
- [Governance | Recommended] An AI governance owner or review body exists with authority to approve, pause, or halt deployments
- [Legal | Recommended] An organizational AI Acceptable Use Policy exists — our AI Acceptable Use Policy Template has a starting structure
- [Legal | Recommended] A formal AI risk assessment process exists, following the logic in our AI Risk Assessment Checklist
- [Legal | Recommended] A vendor risk assessment process exists for third-party AI tools — our AI Vendor Risk Assessment walks through the domains
- [Operations | Recommended] An AI incident response plan exists — our AI Incident Response Plan has a working template
The Master AI Compliance Checklist
EU AI Act
Prohibited practices (Article 5) — Required now, with one Prepare-now addition:
- [Legal | Required now] Confirm that no prohibited real-time remote biometric identification practice is being used in publicly accessible spaces for law-enforcement purposes, except where a narrowly defined Article 5 exception applies
- [Legal | Required now] Confirmed no AI system performs subliminal manipulation or exploits the vulnerabilities of specific groups
- [Legal | Required now] Confirmed no AI system performs social scoring by or on behalf of a public authority
- [Legal | Required now] Confirmed no AI system performs prohibited biometric categorization inferring sensitive or protected attributes
- [Governance | Recommended] Legal counsel sign-off confirming no prohibited practices are in use is documented as evidence of the Required-now assessment above
- [Legal | Prepare now] Two new prohibited practices added by the Digital Omnibus — AI-generated non-consensual intimate imagery (“nudifiers”) and AI-generated CSAM — take effect December 2, 2026; confirm no AI system falls within either prohibition before that date
Note: a valid GDPR legal basis does not make an otherwise-prohibited Article 5 practice acceptable — these are separate legal questions, and the biometric-categorization item above should be evaluated on Article 5 terms, not GDPR terms.
AI literacy (Article 4) — Required now:
- [Legal | Required now] AI literacy training program exists, satisfying the “support the development of” standard following the 2026 Digital Omnibus amendment
- [Operations | Recommended] Training completion records are retained as evidence of the literacy program above; no certification is required
Transparency (Article 50) — Required now, subject to scope limits and exemptions:
- [Technical | Required now] Users interacting with AI chatbots or virtual agents are informed they’re communicating with AI, unless obvious from context
- [Technical | Required now] AI-generated or manipulated content is machine-readably marked where Article 50(2) applies
- [Technical | Required now] Emotion-recognition or biometric-categorization systems disclose their operation to subjects
- [Legal | Recommended] Confirm whether an Article 50 scope limit or exemption applies to a given system before assuming the general disclosure duty is triggered
High-risk classification (Article 6) — deferred along with Chapter III Section 1; prepare now:
- [Legal | Prepare now] Each AI system is assessed against Annex I and Annex III criteria to determine whether it would be high-risk. Article 6 itself doesn’t formally apply until the deferred date, so this isn’t a live legal duty yet — but doing it now avoids a scramble when the deadline lands
- [Legal | Prepare now] Classification decisions are documented, so the resulting obligations can be actioned as soon as they become enforceable
- [Legal | Prepare now] A process exists to reclassify systems when Annex III is amended or use cases change
High-risk provider and deployer obligations (Articles 9–17, 26) — Prepare now:
- [Technical | Prepare now] Risk management system framework drafted, ready for the applicable deferred date
- [Technical | Prepare now] Data governance and training-data documentation practices established in advance
- [Technical | Prepare now] Automatic logging capability exists for systems likely to be classified high-risk
- [Legal | Prepare now] Technical documentation (Annex IV) drafting has begun, not treated as urgent for 2026
GPAI model obligations (Articles 53–56) — Required now, if you provide a general-purpose AI model:
- [Legal | Required now] Technical documentation for the GPAI model is maintained (commonly discussed in industry as a “foundation model,” though the Act’s defined term is GPAI model)
- [Legal | Required now] A training-data summary consistent with copyright obligations is published
Full timeline detail and Article 73 serious-incident reporting: our AI Incident Response Plan covers the escalation path.
GDPR for AI Systems
Lawful basis and data use:
- [Legal | Required now] Article 6 lawful basis is documented for all personal data processing in AI systems
- [Legal | Required now] Article 9 special-category data has additional documented basis where processed by AI
Automated decision-making (Article 22):
- [Legal | Required now] Decisions based solely on automated processing, including profiling, that produce legal effects or similarly significantly affect individuals are identified across the inventory
- [Legal | Required now] Applicable Article 22(2) exceptions are documented with legal rationale
- [Technical | Required now] Where Article 22(2) applies, implement the applicable safeguards under Article 22(3), including appropriate human intervention and the ability to contest the decision
DPIA (Article 35):
- [Legal | Required now] For each AI system, assess whether a DPIA is required under Article 35 based on the nature, scope, context and purposes of processing and the resulting risk to individuals — large-scale processing, systematic profiling, or special-category data are strong signals but don’t trigger a DPIA automatically in isolation; see the trigger logic in our AI Risk Assessment Checklist
- [Legal | Required now] DPIAs are reviewed when systems are significantly modified
Records and vendors:
- [Legal | Required now] Article 30 processing records reflect AI systems touching personal data
- [Legal | Required now] Article 28 DPAs are in place with AI vendors that act as processors on personal data on your behalf — the data-handling domain in our AI Vendor Risk Assessment covers what to check for
For Spain-specific regulatory context throughout this section, our Spain GDPR Checklist for SaaS and AEPD Inspection Guide go deeper.
ISO/IEC 42001
- [Governance | Recommended] AI management system (AIMS) scope is formally defined
- [Governance | Recommended] An AI policy is established under Clause 5.2
- [Governance | Recommended] AI risks and opportunities are identified under Clause 6
- [Technical | Recommended] AI system documentation is maintained per Annex A, Control 8.1
- [Governance | Recommended] Internal AIMS audits are conducted on a planned schedule
NIST AI Risk Management Framework
- [Governance | Recommended] Roles and responsibilities for AI risk are defined (Govern)
- [Technical | Recommended] AI system context and risks are documented (Map) — see our AI Inventory Template
- [Technical | Recommended] Bias testing is conducted using use-case-appropriate methods (Measure)
- [Operations | Recommended] Residual risk is monitored on an ongoing basis (Manage)
Selected US State AI Laws
This is a selective, not exhaustive, list — state AI law is moving quickly, and both entries below carry additional nuance beyond a single effective date. Confirm current status before relying on any date here.
| State | Law | Who’s affected | Status as of August 2026 | Checklist action |
|---|---|---|---|---|
| Colorado | SB 26-189 (Automated Decision-Making Technology Act) — repealed and replaced the original Colorado AI Act | Developers and deployers of ADMT used in consequential decisions (employment, housing, lending, etc.) | Signed May 14, 2026; takes effect January 1, 2027; enforcement contested pending rulemaking (see note above) | [Legal | Prepare now] Assess whether your AI systems qualify as covered ADMT under the narrower disclosure-and-human-review framework, and monitor the rulemaking/litigation status |
| California | AI Transparency Act (SB 942, as amended by AB 853) | Generative AI providers meeting the statute’s applicability threshold | Operative since August 2, 2026 | [Legal | Required now, if covered] Confirm whether your organization meets the statutory threshold and, if covered, implement the applicable detection and watermarking requirements |
| Other states | Various — automated decision-making disclosure requirements are proliferating | Varies | Varies | [Legal | Recommended] Check state-level requirements against your AI inventory as part of the quarterly review |
AI Security & Incident Response
- [Technical | Recommended] AI-specific threat model documented — prompt injection, model extraction, data poisoning
- [Operations | Required now] AI incident response procedure exists — our AI Incident Response Plan has the full template
- [Legal | Required now] GDPR Article 33 breach-reporting requirements are understood and documented where applicable
- [Legal | Prepare now] EU AI Act Article 73 serious-incident reporting procedures are prepared for systems to which Article 73 will apply once the underlying high-risk classification’s Chapter III obligations take effect
Master Status Dashboard
Use the table below as a manual tracker — fill in your own counts as you complete the checklist above; there’s no automatic calculation here.
| Framework | Total Items | ✅ Done | 🔄 In Progress | ⛔ Gap | % Complete |
|---|---|---|---|---|---|
| Foundation | 7 | ||||
| EU AI Act (Required now) | 10 | ||||
| EU AI Act (Prepare now) | 8 | ||||
| EU AI Act (Recommended) | 3 | ||||
| GDPR for AI | 9 | ||||
| ISO/IEC 42001 | 5 | ||||
| NIST AI RMF | 4 | ||||
| Selected US State AI Laws | 3 | ||||
| AI Security & Incident Response | 4 |
Red flag: any gap in a currently-applicable (Required now) legal obligation should trigger documented remediation regardless of your overall completion percentage — a single missing critical control can matter more than nine completed low-risk ones.
Connecting This Checklist to Your Governance Program
This checklist is the index, not the whole program. Each section links to the resource where the depth actually lives:
Maintain a current AI inventory covering ownership, purpose, data flows and risk classification → identify what could go wrong (AI Risk Assessment Checklist) → confirm a specific tool is safe to use (AI Vendor Risk Assessment) → define what’s allowed (AI Acceptable Use Policy) → plan for when something goes wrong (AI Incident Response Plan) → confirm every framework is covered (this checklist).
Run this checklist quarterly against your AI Inventory, and immediately after any regulatory update, new AI deployment, or reported incident.

Common Mistakes to Avoid
- Treating every EU AI Act obligation as currently enforceable, without checking the Digital Omnibus deferral for high-risk provisions
- Treating the Digital Omnibus as a pure timeline extension and missing its substantive changes, like the two new Article 5 prohibitions
- Assuming Article 6 classification is a live legal duty today rather than a deferred obligation worth preparing for early
- Building a checklist around a single framework (usually the EU AI Act) while GDPR and ISO 42001 obligations go unaddressed
- Assuming AI embedded in existing SaaS products is out of scope because it wasn’t separately purchased
- Treating role tags ([Legal], [Technical]) as a statement that every item is a universal legal mandate, rather than an ownership assignment
- No status tracking — a checklist filled out once and never revisited isn’t a compliance program
- Confusing internal risk-management priorities with actual legal deadlines
- Treating a signed state law as automatically enforced on its effective date without checking for litigation or rulemaking delays
Best Practices
- Determine your AI Act role (provider vs. deployer) before working through the checklist
- Build the “applies now vs. deferred” distinction into every framework section, not just the EU AI Act
- Run this checklist against your AI inventory system by system, not as one blanket organizational pass
- Re-run quarterly, and immediately after any regulatory change — Colorado and California both moved dates in 2026, and the Digital Omnibus shows EU dates and substance can both move
- Assign a single accountable owner per checklist section, not just per item
- Treat this as the connective index to your deeper governance documents, not a replacement for them
Key Takeaways
✅ A checklist accurate as of August 2026 must reflect the Digital Omnibus’s deferral of EU AI Act high-risk provider obligations to December 2027, August 2028, and August 2030 for public-authority use — plus its new Article 5 prohibitions and Colorado’s and California’s mid-2026 status changes.
✅ AI compliance spans multiple frameworks simultaneously — EU AI Act, GDPR, ISO 42001, NIST AI RMF, and increasingly US state law — not just one.
✅ Your AI Act role (provider vs. deployer) determines which obligations actually apply to you.
✅ Distinguish what’s legally required now from what’s correct-but-not-yet-due; this prevents both wasted effort and real gaps.
✅ This checklist is the master index connecting your AI Inventory, AI Risk Assessment, AI Vendor Risk Assessment, AI Acceptable Use Policy, and AI Incident Response Plan.
Frequently Asked Questions
What is an AI compliance checklist?
A structured, framework-organized set of controls verifying that an organization’s AI governance actually satisfies its legal and regulatory obligations, distinguishing currently-required items from voluntary or not-yet-due ones.
Is the EU AI Act’s high-risk section actually required right now, in 2026?
No. Article 6 classification and the Chapter III obligations that follow it are both deferred, along with the rest of Chapter III Sections 1–3, to December 2, 2027 (Annex III), August 2, 2028 (Annex I), or August 2, 2030 (public-authority use). The only exception is Article 6(5), which obligates the European Commission — not providers — to publish classification guidance, and doesn’t create a live duty for organizations to classify their own systems. Prohibited practices (including two new ones the Digital Omnibus added, effective December 2, 2026), AI literacy, GPAI obligations, and Article 50 transparency remain applicable now.
How often should this checklist be run?
Quarterly against your AI inventory, and immediately after a regulatory update, new AI deployment, or reported incident.
Do all checklist items apply to every AI system?
No. Apply items based on the specific system’s role (provider/deployer), risk classification, data processed, and sector — use your AI Inventory to determine which items are relevant to which systems, and the “Which Frameworks Apply to You?” matrix above as a starting filter.
We use AI embedded in third-party SaaS tools we didn’t separately buy — is that in scope?
Yes. Embedded AI features are one of the most commonly missed sources of compliance gaps — see the “blind spot” section of our AI Inventory Template for discovery methods.
How does GDPR interact with the EU AI Act?
They’re designed to coexist, not substitute for each other. The AI Act doesn’t modify GDPR obligations — it adds AI-specific ones. Article 14 human oversight and GDPR Article 22 safeguards overlap significantly, and a single well-documented implementation can sometimes support compliance with both — but the requirements should be assessed separately, since satisfying one does not automatically satisfy the other.
Is the Colorado AI Act currently in effect?
They’re designed to coexist, not substitute for each other. The AI Act doesn’t modify GDPR obligations — it adds AI-specific ones. Article 14 human oversight and GDPR Article 22 safeguards overlap significantly, and a single well-documented implementation can sometimes support compliance with both — but the requirements should be assessed separately, since satisfying one does not automatically satisfy the other.
Who should own this checklist?
Typically the AI governance lead, with each framework section owned by the function most responsible — legal for regulatory sections, security/engineering for technical controls, and executive leadership for the overall governance foundation.