AI Compliance Checklist 2026: EU AI Act, GDPR, ISO 42001, and Beyond

Enterprise EU AI Act preparation checklist

AI compliance is no longer a single-framework problem. Organizations operating in 2026 must satisfy obligations across multiple intersecting frameworks simultaneously: the EU AI Act, GDPR (which applies to AI systems processing personal data), ISO 42001 (the AI management system standard), NIST AI RMF (for US-aligned organizations), and sector-specific regulations in finance, healthcare, and infrastructure.

This checklist provides a unified compliance reference. It is organized by framework and designed to be used by compliance teams conducting quarterly reviews, legal counsel assessing AI deployments, and product teams preparing for enterprise procurement security reviews.

🛡️ AI Act Ready by Design Knowlee implements audit-trail-by-default, human-in-the-loop on high-risk processes, and risk-classified job metadata at runtime — not bolted on. For deeper technical detail, see the AI Act Compliance Software Guide and the 25-point High-Risk AI Systems Checklist.

Last Updated + Changelog

Last updated: 2026-04-29 — This checklist is maintained monthly to reflect regulatory enforcement milestones, guidance updates from the EU AI Office, and practitioner feedback. Check back each month for the latest controls.

• 2026-04-29: Added GDPR Article 22 + SOC 2 CC4 (Change Management) cross-references; expanded SOC 2 section to full CC1–CC9 mapping.
• 2026-04-15: Updated Annex III sectoral guidance for Article 6 high-risk classification post-Capo III enforcement; added Article 6(3) exception documentation note.
• 2026-03-31: Added GPAI model obligations (Articles 52–56) reflecting 2 August 2025 applicability date confirmed by AI Office.
• 2026-03-10: Expanded NIST AI RMF GOVERN function to align with NIST AI 100-1 v1.1 subcategory numbering.
• 2026-02-28: Added sector-specific healthcare section (EU MDR / IVDR) following first wave of AI medical device enforcement notices.

How to Use This Checklist

Each section covers one framework. Items are marked with the organizational role primarily responsible:

• [Legal/Compliance]: Policy, documentation, regulatory obligation tracking
• [Technical]: Engineering, architecture, security, and data science
• [Governance]: Senior management, AI Review Board, executive accountability
• [Operations]: Day-to-day AI system management and monitoring

Status tracking: Assign each item one of three statuses:

• DONE: Fully implemented with documented evidence
• IN PROGRESS: Implementation underway with target completion date
• GAP: Not yet started — requires remediation plan

Run this checklist against your AI system inventory. Not every item applies to every system — use the context notes to determine applicability.

Section 1: Foundation — AI Governance Structure

Before checking framework-specific requirements, verify these foundational governance elements are in place. Deficiencies here cascade into every other section.

1.1 AI Inventory

• [Governance] A complete, current inventory of all AI systems in use or development exists.
• [Governance] Each AI system has a named AI System Owner with documented accountability.
• [Governance] The inventory includes: system name, purpose, data inputs, outputs, provider (internal/third-party), deployment context, and risk classification.
• [Governance] The inventory is reviewed and updated at least quarterly.
• [Technical] Shadow AI systems (AI tools used by employees outside of IT-sanctioned deployments) are identified through monitoring and included in scope.

1.2 AI Governance Body

• [Governance] An AI Review Board or equivalent governance function exists with defined membership and meeting cadence.
• [Governance] The Board has documented authority to approve, pause, or halt AI deployments.
• [Governance] Terms of reference for the AI Review Board are documented and approved by executive leadership.
• [Governance] AI ethics and compliance is a standing agenda item in executive and board reporting.

1.3 AI Policy

• [Legal/Compliance] An organizational AI Policy exists, approved by senior management.
• [Legal/Compliance] The policy covers: responsible use principles, prohibited uses, oversight requirements, incident reporting, and third-party AI procurement standards.
• [Legal/Compliance] The policy is communicated to all staff who use or oversee AI systems.
• [Legal/Compliance] The policy is reviewed at least annually.

Section 2: EU AI Act Compliance

2.1 Prohibited AI Practices (Article 5 — Applicable since 2 February 2025)

All organizations:

• [Legal/Compliance] You have confirmed no AI system in your organization performs real-time remote biometric identification in public spaces (except where legally authorized).
• [Legal/Compliance] You have confirmed no AI system performs subliminal manipulation of individuals.
• [Legal/Compliance] You have confirmed no AI system performs social scoring of individuals by or on behalf of a public authority.
• [Legal/Compliance] You have confirmed no AI system is used to infer sensitive attributes (race, political views, sexual orientation, etc.) through biometric categorization without legal basis.
• [Legal/Compliance] You have confirmed no AI system scrapes facial images from the internet or CCTV without legal basis to build recognition databases.
• [Governance] A formal sign-off exists from legal counsel confirming no prohibited AI practices are in use.

2.2 High-Risk AI Classification

• [Legal/Compliance] Each AI system in your inventory has been assessed against Article 6(1) (regulated product safety component) and Article 6(2) / Annex III (application domain) criteria.
• [Legal/Compliance] Classification decisions are documented with legal reasoning.
• [Legal/Compliance] Any Article 6(3) exception claims (not high-risk despite Annex III domain) are documented with evidence.
• [Governance] Classification decisions have been reviewed by legal counsel.
• [Legal/Compliance] A process exists for reclassifying systems when use cases change or Annex III is amended.

2.3 High-Risk AI — Provider Obligations (Articles 9–17)

Apply these checks only to AI systems you DEVELOP and place on the market as high-risk.

Risk Management System (Article 9):

• [Technical] A documented risk management system covers the full lifecycle of each high-risk AI system.
• [Technical] Risk management includes iterative identification, estimation, evaluation, and mitigation of risks.
• [Technical] The risk management system is reviewed and updated with each significant system change.

Data Governance (Article 10):

• [Technical] Training, validation, and test datasets are documented with provenance and quality assessment.
• [Technical] Data governance practices address relevance, representativeness, accuracy, and completeness.
• [Technical] Bias assessment of training data is documented.

Technical Documentation (Article 11 + Annex IV):

• [Technical] Technical documentation covering all 15 Annex IV elements exists and is current.
• [Technical] Documentation is maintained throughout the system lifecycle and updated for significant changes.

Automatic Logging (Article 12):

• [Technical] The AI system automatically logs events relevant to operation, performance, and anomalies.
• [Technical] Logs are immutable, timestamped, and stored securely.
• [Technical] Log retention period is defined and meets regulatory requirements.

Transparency to Deployers (Article 13):

• [Technical] Instructions for use are provided to deployers covering: intended purpose, performance metrics, technical requirements, human oversight measures, and maintenance requirements.
• [Legal/Compliance] Instructions for use are contractually delivered to deployers.

Human Oversight Design (Article 14):

• [Technical] The system is technically capable of being monitored by designated humans.
• [Technical] Override, interrupt, and halt capabilities are implemented and tested.
• [Technical] The system provides interpretable outputs to support human oversight.

Accuracy and Robustness (Article 15):

• [Technical] Accuracy metrics are defined, measured, and declared in documentation.
• [Technical] Resilience to errors, faults, and inconsistencies is tested and documented.
• [Technical] Cybersecurity measures addressing AI-specific threats are implemented.

Conformity Assessment (Article 43):

• [Legal/Compliance] The applicable conformity assessment pathway (self-assessment vs. third-party) has been determined.
• [Legal/Compliance] Conformity assessment is completed before market placement.
• [Legal/Compliance] CE marking is affixed where required.

EU Database Registration (Article 49):

• [Legal/Compliance] High-risk AI systems are registered in the EU AI database before placement on the market.
• [Legal/Compliance] Registration information is kept current.

2.4 High-Risk AI — Deployer Obligations (Article 26)

Apply these checks to high-risk AI systems you USE that were developed by third parties.

• [Operations] You have received and reviewed the provider's instructions for use.
• [Operations] Designated human oversight persons are assigned, qualified, and trained for each high-risk AI system.
• [Operations] You use the system only within its declared intended purpose as specified by the provider.
• [Legal/Compliance] You have a process for reporting anomalies and serious incidents to the provider.
• [Legal/Compliance] Where applicable, a Fundamental Rights Impact Assessment (FRIA) has been completed.
• [Legal/Compliance] Where applicable, you have registered in the EU AI database as deployer.

2.5 GPAI Model Obligations (Article 52–56 — Applicable since 2 August 2025)

Apply if you PROVIDE a GPAI model (foundation model) placed on the EU market.

• [Legal/Compliance] Technical documentation for the GPAI model is maintained.
• [Legal/Compliance] A summary of training data is published consistent with copyright obligations.
• [Legal/Compliance] Policies to comply with EU fundamental rights law are documented.
• [Legal/Compliance] If the model exceeds 10^25 FLOPs training compute or is designated systemic risk by the AI Office: adversarial testing conducted, incident reporting process established, cybersecurity measures implemented.

2.6 Transparency Obligations (Article 50)

Apply to all AI systems interacting with humans or generating content.

• [Technical] Users interacting with AI chatbots or virtual agents are informed they are communicating with AI.
• [Technical] AI-generated content (images, audio, video) is marked as AI-generated.
• [Technical] Emotion recognition or biometric categorization systems disclose their operation to subjects.

Section 3: GDPR Compliance for AI Systems

The EU AI Act and GDPR create overlapping obligations for AI systems processing personal data. This section covers the AI-specific GDPR obligations.

3.1 Legal Basis and Purpose Limitation

• [Legal/Compliance] Legal basis under Article 6 GDPR is documented for all personal data processing in AI systems.
• [Legal/Compliance] Where special category data (Article 9) is processed in AI training or operation, additional legal basis is documented.
• [Legal/Compliance] AI systems process personal data only for declared purposes — no secondary use without additional legal basis.
• [Technical] Technical controls prevent AI systems from using personal data for undeclared purposes.

3.2 Data Subject Rights in AI Contexts

• [Legal/Compliance] Article 22 — Automated Decision-Making: AI-influenced decisions that produce legal or similarly significant effects on individuals are identified across your AI system inventory.
• [Legal/Compliance] Article 22(2) — Exceptions: Where automated processing relies on an Article 22(2) exception (contract, law, or explicit consent), the exception is documented with legal rationale per system.
• [Legal/Compliance] Article 22(3) — Safeguards: For each Article 22(2) system, safeguards are implemented: human review is available on request, the data subject can express their point of view, and they can contest the decision.
• [Technical] Human review workflow for Article 22(3) is technically implemented — not just policy-stated — with documented escalation path and SLA. (Cross-reference: SOC 2 CC4.1 — Change management controls for processes affecting individuals.)
• [Legal/Compliance] Article 15(1)(h) — Right of Access: Meaningful information about the logic, significance, and envisaged consequences of automated processing is provided to data subjects on request.
• [Technical] Erasure (right to be forgotten) requests can be fulfilled — personal data in training datasets and AI outputs can be identified and removed.
• [Technical] Data portability obligations are addressed for AI-processed personal data.
• [Operations] A register of Article 22-in-scope AI decisions is maintained and reviewed quarterly.

3.3 Data Protection Impact Assessment (DPIA)

• [Legal/Compliance] A DPIA (Article 35 GDPR) has been completed for AI systems that involve large-scale processing of personal data, systematic profiling, or processing of special categories.
• [Legal/Compliance] DPIAs are reviewed when AI systems are significantly modified.
• [Legal/Compliance] Where a DPIA indicates high residual risk, the supervisory authority has been consulted (Article 36).

3.4 Data Minimization and Retention

• [Technical] AI systems process only the personal data necessary for their stated purpose.
• [Technical] Training data personal information is pseudonymized or anonymized where possible.
• [Legal/Compliance] Retention schedules for AI training data and operational logs are defined and enforced.
• [Technical] AI-generated outputs containing personal data are subject to the same retention controls as other personal data.

3.5 Third-Party AI Processors

• [Legal/Compliance] Data Processing Agreements (DPAs) under Article 28 GDPR are in place with all AI vendors who process personal data on your behalf.
• [Legal/Compliance] DPAs specify the subject matter, duration, nature, and purpose of AI processing.
• [Legal/Compliance] Third-country transfers of personal data to AI providers are covered by appropriate safeguards (SCCs, adequacy decisions).

Section 4: ISO 42001 AI Management System

4.1 Context and Scope (Clause 4)

• [Governance] Scope of the AIMS is formally defined and documented.
• [Legal/Compliance] Internal and external issues relevant to the AIMS are identified and monitored.
• [Governance] Interested parties and their requirements are identified.
• [Governance] The organization's role in the AI value chain (provider, deployer, or both) is formally stated.

4.2 Leadership (Clause 5)

• [Governance] Top management demonstrates leadership commitment to the AIMS.
• [Governance] An AI Policy (Clause 5.2) is established, communicated, and maintained.
• [Governance] Roles, responsibilities, and authorities for AI governance are assigned.

4.3 Planning (Clause 6)

• [Legal/Compliance] AI risks and opportunities are identified and assessed.
• [Governance] AIMS objectives are established, documented, and measurable.
• [Governance] Plans for achieving objectives include actions, resources, timelines, and responsible parties.

4.4 Support (Clause 7)

• [Governance] Resources required for the AIMS are identified and provided.
• [Operations] Competency requirements for AI-facing roles are defined.
• [Operations] Training records for AI-facing staff are maintained.
• [Legal/Compliance] Required AIMS documentation is controlled and maintained.

4.5 Operation (Clause 8)

• [Technical] AI system impact assessments are conducted for systems in scope.
• [Technical] AI system documentation (Annex A, Control 8.1) is maintained for all systems.
• [Technical] Human oversight mechanisms are implemented and documented.
• [Legal/Compliance] Third-party AI provider due diligence process is documented and operated.

4.6 Performance Evaluation (Clause 9)

• [Governance] Internal AIMS audits are conducted on a planned schedule.
• [Governance] Management review occurs at planned intervals with documented outputs.
• [Operations] AIMS performance against objectives is monitored and measured.

4.7 Improvement (Clause 10)

• [Operations] Nonconformities are identified, documented, and addressed through corrective action.
• [Operations] Root cause analysis is conducted for significant nonconformities.
• [Governance] Continual improvement of the AIMS is actively pursued.

Section 5: NIST AI Risk Management Framework

5.1 GOVERN Function

• [Governance] Organizational roles and responsibilities for AI risk are defined (GOVERN 1.1).
• [Governance] AI risk tolerance is documented and communicated (GOVERN 1.2).
• [Governance] Organizational policies for responsible AI are established and maintained (GOVERN 2.1).
• [Legal/Compliance] Legal, regulatory, and contractual AI risk requirements are identified (GOVERN 4.1).

5.2 MAP Function

• [Technical] Organizational context for each AI system is documented (MAP 1.1).
• [Technical] Scientific and technological risks of each AI system are identified (MAP 1.5).
• [Technical] AI-specific risks to individuals, communities, and society are mapped (MAP 2.1).
• [Technical] Impacts on the AI lifecycle from third-party data and models are identified (MAP 3.1).

5.3 MEASURE Function

• [Technical] Methods and metrics for measuring AI risk are established (MEASURE 1.1).
• [Technical] AI system performance is evaluated before and after deployment (MEASURE 2.2).
• [Technical] Bias testing is conducted using methods appropriate to the use case (MEASURE 2.7).
• [Technical] AI system resilience to adversarial inputs is tested (MEASURE 2.8).

5.4 MANAGE Function

• [Operations] Responses to AI risk, including risk response plans, are documented (MANAGE 1.1).
• [Operations] Residual risks after treatment are monitored on an ongoing basis (MANAGE 1.3).
• [Operations] Feedback mechanisms from users and affected communities are established (MANAGE 4.1).
• [Governance] AI risk monitoring and escalation procedures are tested (MANAGE 2.2).

Section 6: SOC 2 Trust Services Criteria for AI Systems

SOC 2 Type II certification provides third-party-verified evidence that your organization's controls meet the AICPA Trust Services Criteria. For AI-deploying organizations, each Common Criteria (CC) category creates specific AI obligations.

6.1 CC1 — Control Environment

• [Governance] The board of directors or equivalent demonstrates accountability for AI-related risk as part of the overall control environment.
• [Governance] Management establishes an organizational structure with defined reporting lines for AI governance.
• [Operations] Individuals with AI-related responsibilities are qualified; training records demonstrate competency.
• [Legal/Compliance] Policies covering AI ethical use, acceptable use, and prohibited behaviors are communicated to all personnel.

6.2 CC2 — Communication and Information

• [Technical] Relevant internal information about AI system performance, incidents, and anomalies is captured and communicated to responsible parties.
• [Legal/Compliance] External communications about AI system capabilities, limitations, and data handling are accurate and kept current.
• [Operations] Mechanisms exist for users and affected parties to report AI-related concerns, errors, or adverse outcomes.

6.3 CC3 — Risk Assessment

• [Governance] AI-specific risks (model drift, adversarial inputs, bias, hallucination, third-party model dependencies) are included in the enterprise risk assessment.
• [Technical] Risk assessment considers fraud risk from AI-generated content, including deepfakes and social engineering vectors.
• [Governance] Risk assessments are updated when AI systems or their deployment contexts change materially.

6.4 CC4 — Monitoring Activities

• [Operations] AI system outputs are monitored on an ongoing basis for accuracy, bias drift, and anomalous behavior. (Cross-reference: GDPR Article 22(3) — human review safeguards.)
• [Technical] Automated monitoring alerts are configured for threshold breaches in AI system performance metrics.
• [Governance] Internal audit evaluates the effectiveness of AI controls as part of the SOC 2 monitoring scope.
• [Operations] Deficiencies identified through monitoring are evaluated and remediated in a timely manner.

6.5 CC5 — Control Activities

• [Technical] Controls are designed and implemented to mitigate AI-specific risks identified in CC3.
• [Technical] Controls include both preventive (access controls, input validation, output filtering) and detective (logging, anomaly detection) types.
• [Legal/Compliance] Controls over third-party AI vendors include contractual obligations, regular assessments, and SLA verification.

6.6 CC6 — Logical and Physical Access Controls

• [Technical] Access to AI model weights, training data, inference infrastructure, and configuration is restricted to authorized personnel.
• [Technical] Privileged access to AI infrastructure is logged, reviewed, and governed by a least-privilege policy.
• [Technical] API keys and credentials for AI services (internal and third-party) are managed via a secrets management system — not hardcoded.
• [Technical] Multi-factor authentication is enforced for access to AI development and production environments.

6.7 CC7 — System Operations

• [Operations] AI system capacity is monitored to detect performance degradation that could affect outputs.
• [Technical] Incident response procedures cover AI-specific failure modes: model unavailability, accuracy degradation, adversarial compromise.
• [Operations] AI system incidents are logged, classified, and responded to within defined SLAs.
• [Technical] Recovery procedures for AI systems are documented and tested.

6.8 CC8 — Change Management

• [Technical] Changes to AI models, training data, inference pipelines, and configurations are subject to formal change management — authorized, documented, tested, and reviewed.
• [Technical] Model retraining and fine-tuning events are treated as changes requiring approval and testing before production deployment.
• [Legal/Compliance] Significant AI system changes trigger reclassification review under EU AI Act Article 6 and GDPR Article 35 DPIA review.
• [Operations] Rollback procedures for AI model changes are documented and tested.

6.9 CC9 — Risk Mitigation

• [Governance] Vendor risk management for AI providers includes SOC 2 report review, AI-specific due diligence questionnaires, and contractual security obligations.
• [Legal/Compliance] Business continuity plans address the unavailability of critical AI services, including third-party foundation model providers.
• [Governance] Residual AI risks accepted by management are documented with named accountable owners.

Section 7: Sector-Specific Compliance

7.1 Financial Services (EU: EBA AI Guidelines, DORA, MiFID II)

• [Legal/Compliance] AI systems used in credit decisions comply with EBA Machine Learning guidelines on model risk management.
• [Legal/Compliance] AI systems used in trading or investment advice comply with MiFID II requirements for algorithmic trading controls.
• [Technical] AI systems covered by DORA (Digital Operational Resilience Act) are included in ICT risk management.
• [Legal/Compliance] Model validation processes for financial AI systems are documented and conducted by independent functions.

7.2 Healthcare (EU MDR, IVDR, Clinical AI)

• [Legal/Compliance] AI medical devices or IVDs are registered under MDR/IVDR and comply with relevant notified body requirements.
• [Legal/Compliance] Clinical AI tools in diagnostic or treatment recommendation roles are subject to clinical validation.
• [Technical] Post-market surveillance for AI medical devices includes AI-specific performance monitoring.

7.3 Public Sector

• [Legal/Compliance] Fundamental Rights Impact Assessments (FRIAs) are completed for high-risk AI deployments.
• [Legal/Compliance] Procurement of AI systems from vendors includes AI compliance due diligence.
• [Governance] Public-facing AI systems include disclosure of AI use consistent with transparency obligations.

Section 8: AI Security and Incident Response

• [Technical] AI-specific threat model is documented covering adversarial inputs, prompt injection, model extraction, and data poisoning.
• [Technical] AI systems are included in the organization's vulnerability management program.
• [Technical] Access controls for AI training data, model weights, and inference infrastructure are implemented and reviewed.
• [Operations] An AI incident response procedure exists: detection, containment, investigation, notification, and recovery steps are documented.
• [Operations] Staff know how to report AI incidents — including unexpected AI outputs, suspected adversarial attacks, and AI-related data breaches.
• [Legal/Compliance] Serious incident reporting obligations under Article 73 of the EU AI Act are understood and processes are established.
• [Legal/Compliance] AI incidents that also constitute personal data breaches are reported under GDPR Article 33 within 72 hours.

Master Status Dashboard

Use this table to track overall compliance posture across frameworks.

Red flag threshold: Any framework below 60% complete requires an immediate remediation plan with executive escalation.

How Knowlee Helps Close Compliance Gaps

Many items in this checklist require technical capabilities that must be built into your AI platform — not bolted on afterward. Knowlee provides:

• Automatic, immutable audit logging: Directly addresses Article 12 logging, GDPR accountability, and ISO 42001 Clause 9 evidence requirements.
• Human-in-the-loop workflows: Configurable approval gates satisfy Article 14 human oversight and GDPR Article 22 compliance.
• Explainability traces: Every output includes reasoning chains and source citations — satisfying transparency and accountability checklist items.
• GDPR-aligned data handling: Data minimization, retention controls, and subject rights support built into the platform.
• SOC 2 Type II certification: Third-party verification that Knowlee's controls satisfy CC1–CC9 Trust Services Criteria — directly mapped in Section 6 of this checklist.

[link:/glossary/ai-act] | [link:/glossary/iso-42001] | [link:/glossary/trustworthy-ai]

FAQ: AI Compliance Checklist

Q: How often should we run this checklist?

The full checklist should be run annually as part of your AI governance review cycle. Individual sections should be triggered by specific events: a new AI deployment (run the full checklist for that system), a regulatory update (run affected sections for all systems), an AI incident (run security and GDPR sections), or a significant system modification (run classification and provider obligation sections).

Q: Do all checklist items apply to every AI system?

No. The checklist is a comprehensive reference, not a universal requirement. Items should be applied based on the specific AI system's characteristics: its risk classification, whether you are provider or deployer, what data it processes, and what sector you operate in. The context notes throughout the checklist guide applicability.

Q: What counts as a "significant modification" that triggers reclassification?

The EU AI Act does not define "substantial modification" with mathematical precision, but the Commission's guidance indicates that modifications affecting the system's intended purpose, performance metrics, safety properties, or risk profile are substantial. Retraining on new data, adding new use cases, or changing the target user population typically require reclassification review.

Q: We use AI embedded in third-party SaaS products (CRM, ERP, productivity tools). Are those in scope?

Yes, if those AI capabilities are used in ways that fall within Annex III domains or involve personal data processing at scale. Many organizations have significant AI exposure through embedded features in existing software that has never been inventoried. The foundational AI inventory checklist (Section 1.1) should capture all AI capabilities, including those embedded in third-party products.

Q: How do we handle the overlap between GDPR and the EU AI Act on automated decision-making?

The two frameworks are explicitly designed to coexist. The EU AI Act does not modify GDPR obligations — it adds to them. Where both apply, you must satisfy both. The EU AI Act's human oversight requirements (Article 14) and GDPR's Article 22 obligations have significant overlap: both require meaningful human review for consequential automated decisions. A single technical implementation (human approval gates in AI workflows) can satisfy both, provided it is documented as serving both purposes.