The AI Compliance Checklist

Why AI compliance is now a business requirement

An AI compliance checklist is no longer a nice-to-have artifact that a governance team assembles once and files away. It has become the operating manual for deploying artificial intelligence inside a regulated, contract-bound enterprise. The organizations shipping AI fastest in 2026 are not the ones that skipped governance — they are the ones that made it repeatable, so that every new model, feature, and vendor can be cleared through the same disciplined set of checks rather than a bespoke negotiation each time.

Three forces have converged to make this shift permanent. The first is regulation. The EU AI Act introduced binding, risk-tiered obligations that apply to high-risk AI systems regardless of where the provider is headquartered, and it is only the most prominent of a growing body of law. Sector regulators in finance, healthcare, and employment have made clear that existing rules on fairness, privacy, and consumer protection apply to automated decisions just as they apply to human ones. "The model did it" is not a defense that survives contact with a regulator.

The second force is procurement. Enterprise buyers now send detailed AI-specific security questionnaires alongside their traditional vendor assessments. They ask how training data was sourced, whether customer data can be used to train shared models, how prompt injection is mitigated, and which frameworks a vendor's controls map to. A vendor that cannot answer crisply loses the deal — or, at best, watches it stall in security review for months. Compliance readiness has become a revenue function, not merely a cost center.

The third force is accountability. Boards and executives are now personally answerable for AI-related harm — discriminatory outcomes, privacy breaches, leaked intellectual property, or unsafe automated actions. The reputational and financial cost of an AI failure that a reasonable governance program would have caught is difficult to explain away after the fact. A documented, followed checklist is the clearest evidence that an organization exercised due care.

What follows is a practical, section-by-section checklist. It is organized around the areas that every serious AI governance program has to cover, and it is written so that each item is something you can actually verify, assign an owner to, and produce evidence for. The final sections show how these controls map onto the major frameworks — so that a single well-designed control can satisfy SOC 2, the NIST AI Risk Management Framework, the EU AI Act, and ISO/IEC 42001 at once — and how to keep the whole program alive after the first audit is behind you.

How to use this checklist

Before working through the sections, it helps to set a few ground rules so the checklist produces an auditable program rather than a wall of unowned to-dos. Governance that is not assigned, evidenced, and dated is indistinguishable from governance that does not exist. Treat every item below as the seed of a control with four attributes: an owner, an implementation, a piece of evidence, and a review date.

• Scope by risk, not by enthusiasm. Inventory your AI use cases first, then apply the most rigorous checks to the systems that make or materially influence consequential decisions — credit, hiring, medical triage, safety — and lighter-touch checks to low-stakes internal tooling.
• Assign a single accountable owner to each item. Shared ownership is no ownership. Every control needs one name attached, even if several teams contribute to it.
• Define the evidence up front. For each item, decide now what artifact proves it is in place — a policy document, a log export, a signed approval, a test report. Evidence you have to invent during an audit is evidence auditors distrust.
• Write the control once, map it many times. Do not maintain separate control sets for each framework. Maintain one, and map each control to the relevant clauses of SOC 2, NIST AI RMF, the EU AI Act, and ISO/IEC 42001.
• Set a review cadence per item. Some controls are static; most are not. Bias testing, model documentation, and third-party assessments all decay and must be refreshed on a schedule.

With that framing established, the checklist proper begins with the foundation everything else rests on: the data.

Data governance & privacy

AI systems are only as trustworthy as the data that trains, tunes, and prompts them. Data governance is where most AI compliance failures actually originate — an unlawful processing basis, a dataset used for a purpose no one consented to, or sensitive records quietly flowing into a third-party model. Get this section right and much of the rest becomes tractable; get it wrong and no downstream control can fully compensate. The goal here is to be able to state, for any data that touches an AI system, exactly where it came from, why you are allowed to use it, and where it is permitted to go. Deflected covers the operational side of this exposure through data leakage controls and shadow AI discovery, but the governance foundation is yours to own.

• Establish a lawful basis for every processing activity. Document the specific legal basis — consent, contract, legitimate interest, or a statutory obligation — under which each category of personal data is collected, used for training, and used for inference. Record it before processing begins, not retroactively.
• Maintain a data inventory and lineage map. Keep an up-to-date record of every dataset used across the AI lifecycle: its source, owner, classification, retention period, and the systems it feeds. You cannot govern data you cannot see.
• Enforce data minimization. Collect and retain only the data an AI system genuinely needs for its stated purpose. Excess data is pure liability — it expands the blast radius of any breach and undermines the proportionality that regulators expect.
• Capture and honor purpose limitation. Data gathered for one purpose should not silently become training data for another. Bind each dataset to the purposes it was collected for and require explicit re-authorization to extend them.
• Obtain and record valid consent where it is the basis. Where processing relies on consent, ensure it is freely given, specific, informed, and revocable — and keep records that demonstrate when and how it was captured.
• Prohibit unauthorized use of data for model training. Contractually and technically prevent customer or employee data from being used to train shared or vendor models without explicit, documented authorization. This is one of the first questions in every enterprise AI questionnaire, and the answer must be unambiguous.
• Classify and segregate sensitive data. Identify special-category data — health, biometric, financial, children's data — and apply stricter handling, access, and retention rules to it throughout the AI pipeline.
• Implement data subject rights workflows. Build the operational ability to fulfill access, correction, deletion, and objection requests, including the harder case of removing an individual's influence from a trained model or its retrieval store.
• Apply de-identification where feasible. Use anonymization, pseudonymization, or synthetic data to reduce the personal-data footprint of training sets, while documenting the residual re-identification risk honestly.
• Govern data residency and cross-border transfers. Know where AI data is stored and processed, and ensure any cross-border movement rests on a valid transfer mechanism.
• Set and enforce retention and deletion schedules. Define how long training data, prompts, outputs, and logs are kept, and delete them on schedule. Indefinite retention "just in case" is a compliance and security liability.

Model governance

If data governance answers "what are we allowed to use," model governance answers "do we understand and control what we have built or adopted." This section is about knowing every model in your estate, documenting how it behaves, validating that it does what it claims, and testing it for the failure modes — bias, drift, and unsafe behavior — that separate a demo from a production system a regulator will accept. Model governance is also where the EU AI Act and ISO/IEC 42001 concentrate much of their attention, so investment here pays back across multiple frameworks.

• Maintain a complete model inventory. Catalog every model in use — built in-house, fine-tuned, or consumed via API — with its owner, purpose, risk classification, data dependencies, and deployment status. An unknown model cannot be governed, and shadow models are where uncontrolled risk hides.
• Produce model cards and documentation. For each significant model, maintain a model card describing its intended use, training data provenance, known limitations, evaluation results, and out-of-scope uses. This documentation is both a governance tool and the evidence auditors ask for first.
• Classify each model by risk tier. Assign every use case to a risk level using criteria aligned with the EU AI Act's tiers, so that oversight, testing, and documentation scale with potential harm rather than being applied uniformly.
• Validate model performance before deployment. Require documented validation against defined accuracy, robustness, and reliability metrics on representative data before a model reaches production, and re-validate after material changes.
• Test for bias and fairness. Evaluate models for disparate impact across protected and relevant subgroups using appropriate fairness metrics, document the results, and remediate or formally accept residual risk. For decision-influencing systems this is not optional.
• Establish a formal approval gate. No model reaches production without sign-off from an accountable owner who has reviewed its documentation, validation, and risk assessment. Record the approval and its basis.
• Version and track models and datasets. Keep immutable version records linking each deployed model to its training data, configuration, and evaluation artifacts, so any decision can be traced back to the exact model that produced it.
• Define and monitor for model drift. Set performance thresholds and monitor production behavior against them, so degradation from changing real-world data is detected and triggers revalidation rather than silently harming outcomes.
• Document intended use and prohibited use. State clearly what each model is approved for and what it must not be used for, and communicate those boundaries to the teams building on top of it.
• Assess and test for adversarial robustness. Subject models to red-teaming and adversarial testing to understand how they behave under manipulation, evasion, and extraction attempts before attackers make that discovery for you.
• Retain a decommissioning process. Define how models are retired, including archiving documentation, revoking access, and handling data, so end-of-life is as governed as deployment.

Model governance produces the paper trail that lets you answer the two questions every AI auditor eventually asks: can you show me the inventory of what you run, and can you show me the evidence that each item was validated and approved. If the answer to both is a confident yes with artifacts attached, most of the rest of an audit becomes routine.

Security controls

AI compliance is inseparable from AI security. A model that is beautifully documented and lawfully trained is still non-compliant if an attacker can extract its data through a crafted prompt or intercept its traffic. This section covers the technical controls that protect the confidentiality, integrity, and availability of AI systems — including the AI-specific attack surface that traditional security tooling does not understand, and the forward-looking encryption posture that protects data with a long sensitivity horizon. Deflected's prompt-injection defenses and output guardrails address much of this surface directly.

• Enforce least-privilege access control. Restrict who and what can access models, training data, prompts, logs, and configuration to the minimum required, using role-based or attribute-based access control with regular recertification of entitlements.
• Require strong authentication. Protect all access to AI systems and their management planes with multi-factor authentication and, where possible, phishing-resistant methods.
• Encrypt data in transit and at rest. Apply AES-256 for symmetric encryption of stored data and secure protocols for data in motion, with disciplined key management, rotation, and separation of duties.
• Adopt post-quantum encryption for long-lived data. For any data that will still be sensitive years from now, defend against the harvest-now, decrypt-later threat by adopting NIST post-quantum standards: ML-KEM-1024 (FIPS 203) for key encapsulation, deployed as a hybrid X25519 + ML-KEM key exchange so a proven classical algorithm runs alongside the post-quantum one, layered over AES-256 for symmetric protection.
• Defend against prompt injection. Treat all untrusted input — direct user input and retrieved documents alike — as potentially adversarial, and deploy inline inspection that detects and blocks injection attempts before they reach the model or trigger tool calls.
• Control model outputs. Inspect model responses for sensitive data, unsafe content, and insecure output that could be executed downstream, and block or redact before the output reaches a user or another system.
• Constrain agent and tool permissions. Where models can call tools or take actions, scope those permissions tightly, require approval for high-impact actions, and sandbox execution so a manipulated agent cannot cause disproportionate harm.
• Protect against model extraction and inversion. Apply rate limiting, query monitoring, and anomaly detection to defend against attempts to reconstruct model weights or recover training data through systematic querying.
• Log all security-relevant events immutably. Capture prompts, responses, access, configuration changes, and security decisions in tamper-evident logs suitable for audit and forensic investigation, with defined retention.
• Manage secrets and credentials properly. Store API keys, model credentials, and service secrets in a managed vault, never in code or prompts, and rotate them on a schedule.
• Harden the deployment environment. Apply standard infrastructure security — network segmentation, patching, vulnerability management — to the systems hosting AI workloads, treating them as the high-value targets they are.

Encryption choices deserve particular attention in a compliance context because they are one of the few controls whose adequacy is judged against a future threat rather than a present one. Data encrypted today with classical public-key cryptography and a long sensitivity horizon is already exposed to adversaries who capture it now and wait for quantum computers to break it later. Building the hybrid post-quantum posture described above into your AI data flows is how you keep that data defensible for its full lifetime rather than only until the cryptographic ground shifts.

Transparency & human oversight

Regulators and enterprise customers increasingly demand that AI be explainable to the people it affects and governable by the people responsible for it. Transparency and human oversight are the controls that keep a human meaningfully in — or on — the loop, and that ensure decisions can be explained, contested, and corrected. This section is where the EU AI Act's obligations around disclosure, human oversight, and the right to an explanation become concrete, and it is often the area enterprises have thought about least.

• Disclose AI use to affected people. Inform users when they are interacting with an AI system rather than a human, and when content or a decision has been generated or materially shaped by AI, in clear and accessible language.
• Provide meaningful explanations of decisions. For consequential automated decisions, be able to explain the main factors that drove an outcome in terms the affected person can understand, and support the ability to contest it.
• Define human oversight for each use case. Specify, per system, whether a human reviews decisions before they take effect, monitors them in aggregate, or can intervene and override — and ensure the human has the authority, information, and time to act, not just a nominal role.
• Guard against automation bias. Train and support human reviewers so they critically assess AI outputs rather than rubber-stamping them, and design interfaces that surface uncertainty and dissenting signals.
• Enable override and appeal. Provide a functioning mechanism for a human to override an AI decision and for an affected person to appeal one, with those events logged and reviewed.
• Label AI-generated and synthetic content. Mark AI-generated media where required, and maintain provenance signals so downstream consumers can distinguish authentic from synthetic content.
• Publish clear acceptable-use guidance. Give employees and customers plain guidance on what each AI system may and may not be used for, so oversight is shared rather than concentrated solely in a governance team.
• Document system limitations honestly. State the known limitations, error rates, and failure modes of AI systems to the people relying on them, so oversight is informed by realistic expectations.
• Maintain an accessible record of decisions. Keep decision logs that allow an individual case to be reconstructed and reviewed after the fact, supporting both accountability and continuous improvement.

The test of this section is simple: if a customer or regulator asks why a particular automated decision was made, can you explain it, show who was accountable for it, and demonstrate that the affected person could have contested it? A program that can answer yes has turned transparency from a slogan into a control.

Third-party & supply-chain risk

Very few enterprises build their entire AI stack in-house. Foundation models, fine-tuning services, vector databases, embeddings providers, evaluation tools, and open-source components all enter the estate from outside — and each one imports risk that your own controls do not automatically cover. The AI supply chain is also uniquely opaque: a poisoned dataset or a backdoored open-weights model can carry hidden behavior that no amount of downstream testing reliably surfaces. This section is about extending governance to everything you did not build yourself. Deflected addresses the deeper end of this problem through model supply-chain vetting.

• Maintain a third-party AI inventory. Catalog every external model, API, dataset, library, and tool in your AI stack, with the vendor, purpose, data exposure, and criticality of each.
• Assess vendors for AI-specific risk. Extend vendor due diligence to cover how providers handle your data, whether they use it for training, their security posture, their compliance certifications, and their own subprocessors.
• Bind data-use terms contractually. Ensure contracts explicitly prohibit unauthorized training on your data, define data handling and residency, and preserve your audit and exit rights.
• Vet models and datasets for integrity. Before adopting third-party models or datasets, evaluate them for poisoning, backdoors, and hidden triggers, and verify provenance and integrity through checksums and trusted sources.
• Scan open-source and dependency components. Apply software composition analysis to AI libraries and dependencies, tracking known vulnerabilities and license obligations as you would for any critical software.
• Evaluate model provenance and licensing. Confirm you have the rights to use each model and dataset for your intended purpose, and that license terms do not impose obligations you cannot meet.
• Assess subprocessor and downstream exposure. Understand the chain behind each vendor — the infrastructure and model providers they in turn depend on — so a failure two links away does not surprise you.
• Require vendor breach and change notification. Contractually require timely notification of security incidents and material changes to models or data practices that could affect your compliance posture.
• Plan for vendor concentration and exit. Identify single points of failure in your AI supply chain and maintain a realistic plan to migrate or degrade gracefully if a critical provider fails or changes terms.
• Reassess third parties on a schedule. Refresh vendor risk assessments at least annually and on renewal, since a provider's data practices and security posture can change without notice.

Monitoring & incident response

Compliance is a continuous state, not a milestone. Models drift, attackers probe, data flows change, and a control that was effective at deployment can quietly fail months later. This section covers the controls that keep AI systems observed in production and that ensure the organization can detect, respond to, and learn from incidents when — not if — they occur. It is also the section that turns the rest of the checklist from a static snapshot into a living program. Deflected's AI incident response practice is built around exactly this lifecycle.

• Monitor model behavior continuously. Track accuracy, drift, output distributions, and anomaly signals in production so degradation and misbehavior are caught early rather than discovered through customer harm.
• Detect AI-specific attacks in real time. Monitor for prompt injection, jailbreak attempts, data exfiltration, extraction patterns, and abnormal agent behavior, with alerting tuned to signal rather than noise.
• Define AI incident criteria and severity. Establish what constitutes an AI incident — a data leak through output, a successful jailbreak, a discriminatory outcome, a manipulated agent action — and classify severity so response is proportionate.
• Maintain an AI incident response plan. Document roles, escalation paths, containment steps, and communication procedures specific to AI incidents, and integrate them with your broader security incident response.
• Preserve forensic evidence. Ensure logging is sufficient to reconstruct what happened during an incident — which prompts, which model version, which data — and protect that evidence from tampering.
• Meet breach notification obligations. Know your regulatory and contractual notification timelines and be able to meet them, including the harder judgment of when an AI-specific incident constitutes a reportable data breach.
• Run response exercises. Rehearse AI incident scenarios so the plan works under pressure and the responsible people know their roles before a real event.
• Conduct post-incident reviews. After every incident and near-miss, perform a blameless root-cause analysis and feed the lessons back into controls, testing, and the checklist itself.
• Track and report metrics to leadership. Report on AI risk posture — incidents, drift, testing coverage, open findings — to executives and the board on a regular cadence, so governance is visible and accountable at the top.
• Maintain continuous control assurance. Periodically test that the controls in every section above are still operating as intended, rather than assuming that a control implemented once remains effective.

Continuous monitoring is what allows an organization to make an honest claim that is otherwise impossible: not merely that its AI was compliant at the moment of the last audit, but that it remains governed today. That distinction is exactly what regulators and enterprise buyers are increasingly probing for.

Framework mapping: SOC 2, NIST AI RMF, EU AI Act, ISO/IEC 42001

The checklist above is deliberately framework-agnostic, because maintaining separate control sets for every standard is how governance programs collapse under their own weight. The efficient approach is to implement each control once and map it to the clauses it satisfies across the frameworks that matter to your organization. Four frameworks anchor most enterprise AI programs, and they are complementary rather than competing — each answers a different question. Deflected's AI Governance & Compliance engagement is built around producing exactly these mappings and the evidence behind them.

SOC 2

SOC 2 is the trust-services framework that enterprise procurement teams rely on to evaluate a vendor's security posture. It is not AI-specific, but its Trust Services Criteria — security, availability, processing integrity, confidentiality, and privacy — map cleanly onto much of this checklist. Your access controls, encryption, logging, monitoring, incident response, and vendor management from the sections above are largely the same evidence a SOC 2 examination expects, applied to AI systems. For AI vendors specifically, our guide to SOC 2 for AI covers how to extend a traditional report to cover model and data controls. Map your security and monitoring controls here first — it is often the framework an enterprise buyer asks about before any other.

NIST AI Risk Management Framework

The NIST AI RMF is the leading voluntary framework for identifying and managing AI risk across the model lifecycle. It is organized around four functions — Govern, Map, Measure, and Manage — that align naturally with this checklist: Govern corresponds to your policies and ownership, Map to your inventories and risk classification, Measure to your validation, bias testing, and monitoring, and Manage to your remediation and incident response. Because it is a framework rather than a regulation, the AI RMF is an excellent backbone for organizing your controls before mapping them to binding regimes. Map your model-governance and monitoring controls to its Measure and Manage functions in particular.

EU AI Act

The EU AI Act is the European Union's binding, risk-based regulation of AI systems, with real obligations that scale from minimal for low-risk uses to substantial for high-risk ones. It is where the risk classification, technical documentation, human oversight, transparency, and post-market monitoring items in this checklist stop being good practice and become legal requirements for in-scope systems. If you serve EU users or deploy high-risk systems, treat the EU AI Act as the regime that sets your floor, and ensure your model documentation, oversight design, and monitoring can withstand regulatory scrutiny rather than merely internal review.

ISO/IEC 42001

ISO/IEC 42001 is the international standard for an AI management system — the first certifiable standard dedicated to governing AI as an ongoing organizational capability rather than a set of point controls. Where the other frameworks address what to control, ISO/IEC 42001 addresses how to run the management system that keeps those controls alive: leadership commitment, defined roles, continual improvement, and internal audit. Our ISO/IEC 42001 overview goes deeper, but for mapping purposes, treat it as the framework that ties your operationalization and maintenance practices together and makes them certifiable. It is the natural home for the operationalization controls in the next section.

How to operationalize and maintain the checklist

A checklist that lives in a document is a wish list. A checklist that lives in your workflows, tooling, and review cadence is a governance program. The final and most important step is turning the items above into something that runs continuously with clear ownership, real evidence, and a cadence that keeps it current as your AI estate, the threat landscape, and the regulations all evolve. This is precisely the discipline that ISO/IEC 42001 formalizes and that a mature program treats as routine.

• Stand up an AI governance function. Establish a cross-functional group — security, legal, data, and product — with a clear charter, decision rights, and executive sponsorship, so governance has a home and authority rather than living in the gaps between teams.
• Convert each checklist item into an owned control. Assign every item an accountable owner, an implementation, a defined evidence artifact, and a review date, and track them in a system rather than a spreadsheet that goes stale.
• Embed governance into the AI lifecycle. Build the checks into how models are proposed, built, approved, and deployed — a governance gate in the delivery pipeline — so compliance is a step in the process, not an audit that happens afterward.
• Automate evidence collection. Wherever possible, generate evidence automatically from logs, pipelines, and tooling rather than manually assembling it before each audit, so your compliance posture is always current and defensible.
• Set a tiered review cadence. Review high-risk systems and their documentation at least quarterly, re-run bias and security testing after material model or data changes, refresh third-party assessments annually or on renewal, and reconcile the whole program against regulatory change on a scheduled basis.
• Run internal audits. Periodically test that controls operate as documented, using an independent internal reviewer, and treat findings as inputs to improvement rather than failures to hide.
• Maintain a risk register and remediation tracker. Record accepted risks, open findings, and remediation plans with owners and due dates, so nothing falls through the cracks and leadership can see the true state of AI risk.
• Report to leadership on a regular cadence. Give executives and the board a recurring, honest view of AI risk posture, so accountability sits where it belongs and governance receives the resources it needs.
• Train the people in the loop. Keep builders, reviewers, and decision-makers current on AI risks, policies, and their specific responsibilities, since controls executed by untrained people fail quietly.
• Watch the regulatory horizon. Assign responsibility for tracking emerging AI regulation and framework updates, and feed changes back into the checklist before they become urgent.
• Improve continuously. Treat every incident, audit finding, and near-miss as a signal to strengthen the checklist itself, so the program compounds in maturity rather than ossifying.

Done well, this turns AI compliance from a recurring fire drill into a quiet, dependable capability — one that lets your teams adopt AI quickly because the guardrails are already in place, and lets leadership sign off because the evidence is already on hand. You can see how these controls connect to the broader program on our compliance overview, and how they combine with real-time defense across the AI Governance & Compliance engagement.

Frequently asked questions