AI Compliance Explained: Regulations and How to Operationalize Them

AI compliance starts with a deceptively simple question: For this model, assistant, scoring system or automated workflow, what rules apply, and what evidence proves those rules were followed?

That question is becoming harder to answer as AI moves into credit decisions, clinical workflows, employee screening, fraud detection, customer support and internal productivity tools. A model may rely on training data from one system, customer records from another, outputs from a foundation model provider and a human approval step that happens in a separate application. And each part of that chain can create a regulatory obligation, an internal policy requirement or an audit question that has to be answered later.

AI compliance programs give organizations a way to manage that complexity before an audit or incident review forces the issue. They connect laws and standards to controls, map those controls to evidence, and keep the evidence current as models, data, vendors and use cases change.

AI compliance is the discipline of ensuring that AI systems, and the lifecycle used to develop and operate them, conform to applicable laws, regulations, industry standards and internal policies. It covers the controls an organization uses to prove that an AI system was designed, tested, deployed, monitored and reviewed in line with its regulatory obligations.

That makes AI compliance related to, but distinct from, several neighboring disciplines:

• AI governance defines the operating model — who owns an AI use case, who approves it, who can pause it and how decisions escalate.
• AI ethics defines the principles — fairness, transparency, accountability, privacy, security and human oversight.
• AI risk management defines the methodology — how the organization identifies, measures, prioritizes and mitigates AI-related risk.
• AI compliance proves conformance — which rules apply, which controls address them and what audit evidence supports control attestation.

An AI compliance program usually starts with concrete objects, not abstract principles: an AI inventory, a model card, a training-data summary, a system owner, an access policy, a monitoring dashboard and a record of approvals. These artifacts show whether a system has been classified correctly, whether high-risk AI received the right review, whether human oversight is meaningful and whether post-deployment monitoring is actually happening.

Organizations typically face a layered regulatory environment: broad AI laws, privacy rules, sector-specific supervisory guidance, product safety requirements, employment laws, consumer protection rules and internal risk policies.

EU AI Act

The EU AI Act is widely regarded as one of the most comprehensive AI-specific regulatory frameworks currently in force. It uses a risk-tiered structure that distinguishes prohibited AI practices, high-risk AI systems, limited-risk systems, general-purpose AI models and lower-risk uses. The Act also has extraterritorial reach, meaning it can apply to providers and deployers outside the EU when AI systems or outputs are placed on, or used in, the EU market.

The Act applies in phases, with prohibitions and AI literacy requirements beginning in February 2025, general-purpose AI obligations beginning in August 2025 and a broader rollout continuing through Aug. 2, 2027.

For high-risk AI systems, compliance can require risk management, data governance, technical documentation, logging, transparency, human oversight, accuracy, robustness, cybersecurity and, in some cases, a conformity assessment involving a notified body.

Organizations that build or supply high-risk AI systems typically need a technical file that shows how the system was designed, tested and documented. Organizations that use those systems typically need evidence that demonstrates how the system is deployed, who reviews its outputs, how it’s monitored and how issues are escalated.

GDPR

The GDPR already applies to many AI systems that process personal data, even when those systems are not regulated under a standalone AI law. Article 22 addresses certain rights related to automated decision-making, including profiling, when decisions produce legal or similarly significant effects. Article 35 requires a data protection impact assessment (DPIA) when processing is likely to result in high risk to individuals, which can include large-scale profiling, sensitive data processing or novel technologies.

In practice, GDPR compliance often sits beside AI-specific compliance. A bank using AI for credit decisioning may need to evaluate the use case under the EU AI Act’s high-risk provisions, while also completing a DPIA, documenting lawful basis, enforcing access controls and proving that personal data was handled according to purpose limitation, minimization and retention requirements.

U.S. federal and state rules

The U.S. AI compliance landscape remains a patchwork of laws and regulations. At the federal level, policy has shifted since the 2023 executive order on safe, secure and trustworthy AI. In January 2025, Executive Order 14179, “Removing Barriers to American Leadership in Artificial Intelligence,” revoked certain prior AI policies and directed the administration to review and revise actions that conflicted with its AI policy goals.

That federal shift has not removed compliance pressure, however. Instead, organizations still have to manage federal agency guidance, enforcement activity and state-level requirements. NIST’s AI Risk Management Framework remains a widely used voluntary framework for managing AI risks, and sector regulators continue to apply existing authorities to AI-enabled systems.

At the state and local level, several rules have become important reference points:

• Colorado AI Act / ADMT: Colorado’s 2024 AI Act has been repealed and replaced by SB26-189, signed on May 14, 2026. The new law narrows the framework to automated decision-making technology (ADMT) used to materially influence consequential decisions, while still addressing algorithmic bias concerns through transparency, notice, correction, appeal, and human-review obligations. Covered obligations are generally scheduled to take effect January 1, 2027, with additional implementation details expected through Colorado Attorney General rulemaking.
• NYC Local Law 144: New York City regulates automated employment decision tools, including bias audit and notice requirements for covered employment uses.
• California automated decision-making rules: California finalized CCPA regulations covering automated decision-making technology, risk assessments and cybersecurity audits, with the regulations taking effect Jan. 1, 2026, and phased compliance timing for some requirements.

Sector-specific AI rules

AI compliance also depends heavily on industry context. In regulated sectors, AI systems are often reviewed through existing supervisory frameworks rather than AI-only laws.

• In banking, model risk management guidance has long shaped how firms validate models, document assumptions and maintain governance. The Federal Reserve’s model risk guidance emphasizes development, implementation, use, validation, controls, compliance and board and senior management oversight; in 2026, federal banking agencies also issued revised model risk management guidance emphasizing a risk-based approach.
• In healthcare, HIPAA can apply when AI systems process protected health information, while FDA oversight may apply when AI is part of Software as a Medical Device (SaMD) or an AI-enabled medical device. FDA maintains a list of AI-enabled medical devices authorized for marketing in the U.S., reflecting the growing role of AI in regulated medical products.
• In insurance, the National Association of Insurance Commissioners’ model bulletin sets expectations for how insurers govern AI systems, and describes the information regulators may request during an investigation or examination.
• In financial services and public company disclosure, the SEC has signaled that AI claims must be accurate and supportable. In 2024, the SEC charged two investment advisers with making false and misleading statements about their use of AI, a reminder that AI compliance also includes marketing, disclosure and customer-facing claims.

International AI guidance

Outside the EU and U.S., organizations may also need to account for the U.K.’s principles-based AI regulation approach, China’s generative AI measures and Singapore’s Model AI Governance Framework. Many of these regimes differ in legal force, scope and enforcement maturity, but they tend to converge around recurring expectations: risk classification, accountability, transparency, human oversight, data governance, monitoring and documentation.

Nonbinding instruments also matter because they often become the reference language behind laws, standards and procurement requirements. The OECD AI Principles promote AI safety through trustworthy AI that respects human rights and democratic values, while UNESCO’s Recommendation on the Ethics of Artificial Intelligence applies to all 194 UNESCO member states and emphasizes human rights, fairness, transparency and human oversight.

Laws define obligations, but frameworks help organizations turn those obligations into repeatable operating practices. They give compliance, legal, data, security and AI teams a common way to classify systems, assign controls, collect evidence and attest to control performance.

NIST AI RMF

The NIST AI Risk Management Framework is a voluntary framework for managing risks to individuals, organizations and society associated with AI. NIST organizes the framework around four core functions: Govern, Map, Measure and Manage.

For compliance teams, the NIST AI RMF is useful because it creates a risk-management structure that can be mapped to legal and internal obligations.

• Govern defines roles, policies and accountability.
• Map captures context and intended use.
• Measure evaluates risks and system performance
• Manage prioritizes responses, monitoring and remediation.

ISO/IEC 42001

ISO/IEC 42001 is a certifiable AI management system standard. ISO describes it as the world’s first AI management system standard, designed to help organizations manage AI-related risks and opportunities through a structured system of policies, processes, roles and continual improvement.

For AI compliance, ISO/IEC 42001 is especially useful because it supports formal management-system evidence: scope, governance, risk assessment, impact assessment, lifecycle controls, supplier management, monitoring, internal audit and management review. Organizations that need a certifiable framework often pair ISO/IEC 42001 with more detailed risk or sector guidance.

ISO/IEC 23894

ISO/IEC 23894 provides guidance for AI risk management. It helps organizations that develop, produce, deploy or use AI systems integrate AI-specific risk management into their activities and functions.

Unlike ISO/IEC 42001, which specifies requirements for an AI management system, ISO/IEC 23894 is guidance-oriented. It can help teams define risk sources, analyze potential impacts and structure risk treatment across the AI lifecycle.

IEEE 7000 series

The IEEE 7000 series provides standards focused on ethical and responsible technology design. In an AI compliance program, these standards can help structure topics such as transparency, bias, accountability, privacy and human values. They are typically not the only basis for compliance, but they can help translate ethical commitments into design and documentation practices.

OECD and UNESCO

The OECD AI Principles and UNESCO Recommendation are nonbinding, but they influence law, policy and regulator expectations. They are useful as normative references when organizations need to explain why internal AI policies emphasize fairness, transparency, accountability, human oversight and respect for rights, even where no single binding AI law applies.

Learn more about responsible AI

AI compliance controls provide a way for organizations to implement frameworks and compliance practices into day-to-day workflows and systems. A policy may say that high-risk AI requires human oversight, but a control specifies who reviews the system, where that approval is recorded, how the reviewer sees relevant model outputs and what happens when monitoring shows drift, bias or unsafe behavior.

Governance controls

Governance controls establish who is accountable for AI systems and how decisions are made. They typically include executive oversight, an AI policy, risk-tiering criteria, role assignments and escalation paths.

A high-risk credit model, for example, should have a named model owner, business owner, technical owner and compliance reviewer. The organization should be able to show who approved the use case, which risk tier was assigned, which control set applied and who can require remediation, suspension or rollback.

Common governance controls include:

• AI policy and acceptable-use standards
• AI inventory ownership
• Risk-tiering methodology
• AI officer, model owner and data owner assignments
• Review board or governance council approval
• Exception management with expiration dates
• Control attestation and internal audit review

Documentation controls

Documentation controls create the written record that regulators, auditors, customers and internal reviewers can inspect. In AI compliance, documentation is not a onetime launch task; it has to follow the system as data changes, model versions update, vendors change and use cases expand.

Typical documentation artifacts include model cards, data sheets, training-data summaries, evaluation results, system documentation, architectural diagrams and technical files. Under the EU AI Act, Annex IV describes technical documentation expectations for high-risk AI systems, which can include system purpose, design, development, data, monitoring, validation and risk management information.

For generative AI systems, documentation may also need to cover prompts, retrieval sources, safety filters, human review, prohibited uses and vendor attestations. The goal is not to produce more paperwork for its own sake, but to preserve the context needed to understand what the system does, how it was tested and what evidence supports its approved use.

Assessment controls

Assessment controls evaluate whether an AI system is appropriate for its intended use. These controls may include AI impact assessments, DPIAs, bias audits, red-teaming reports, adversarial testing, privacy reviews, AI security reviews and pre-deployment testing.

A hiring-screening tool, for example, may require a bias audit and candidate notice under one law, a DPIA under another, and an internal assessment that evaluates job relevance, explainability, vendor documentation and human review. A clinical AI system may require validation against intended use, patient safety review and monitoring for performance changes across populations.

Assessment controls should produce durable evidence: test results, reviewer notes, remediation plans, approval records and any unresolved risk accepted by accountable owners.

Operational controls

Operational controls govern how AI systems behave after deployment. They include access management, audit logs, monitoring, incident reporting, human oversight and post-market monitoring.

These controls matter because AI compliance does not end when a model goes live. A model can drift, a prompt template can change, a foundation model provider can update an underlying model, a data pipeline can begin feeding different values or an access policy can expose sensitive fields to a broader group of users. Compliance depends on seeing those changes and preserving the evidence needed to explain them.

Common operational controls include:

• Role-based access control (RBAC)
• Audit logs for data, model and application activity
• Model performance and drift monitoring
• Prompt and response logging where appropriate
• Human-in-the-loop review for consequential decisions
• Incident reporting and escalation procedures
• Post-market or post-deployment monitoring
• Periodic control attestation

Third-party controls

Many AI systems depend on vendors, foundation model providers, SaaS tools, data providers or embedded AI capabilities that the organization did not build. Third-party controls help teams assess those dependencies before deployment and monitor them over time.

Vendor due diligence should capture intended use, data handling, model documentation, security controls, subcontractors, retention policies, training-data commitments, incident notification terms and any available attestations. For foundation models, organizations may also request provider documentation, safety evaluations and information that supports an AI bill of materials (AIBOM), which enumerates the models, data sources, libraries, APIs and vendors involved in an AI system.

AI compliance is only manageable when teams implement traceability: each AI system maps to a risk tier, each risk tier maps to obligations, each obligation maps to controls, and each control maps to evidence.

Inventory every AI system

An AI inventory should include traditional ML models, generative AI applications, internal assistants, embedded AI in SaaS platforms and vendor-provided AI capabilities. Teams cannot classify, monitor or attest to systems they have not mapped.

A useful AI inventory typically captures the system name, owner, business purpose, users, data sources, model type, vendor dependencies, jurisdictions, risk tier, affected populations, approval status and review cadence. For embedded AI, the inventory should also record which SaaS feature uses AI, what data it processes and whether the vendor uses customer data for training or improvement.

Classify systems by risk tier

Each system should be classified against applicable legal and internal criteria. Under the EU AI Act, that may mean determining whether a use case is prohibited, high risk, limited risk or lower risk. Under internal policy, it may mean classifying systems by potential impact on rights, safety, financial outcomes, employment, healthcare, access to services or regulatory exposure.

Risk tiering should be evidence-based. A chatbot answering general policy questions does not create the same obligations as a model recommending patient treatment or ranking candidates for employment. The classification record should explain the reasoning, not merely assign a label.

Map obligations to controls and evidence

Once teams identify the applicable obligations, they need a control map. For each obligation, the map should identify the relevant control, control owner, evidence source and review frequency.

For example:

Automate evidence collection

Manual evidence collection breaks down as the number of AI systems grows. High-risk systems may require quarterly reviews, annual reassessments, incident reporting and ongoing monitoring; even limited-risk systems may need transparency notices, access records and documentation updates.

Evidence automation helps by capturing signals directly from the systems where AI work happens: access history, lineage, model registry metadata, monitoring dashboards, approval workflows, incident systems and policy engines. The goal is to reduce the gap between actual system behavior and the compliance record. When an auditor asks which data a model accessed, who changed a policy or which model version was deployed during an incident window, the evidence should already exist.

Establish a review cadence

AI systems should be reviewed on a cadence that reflects their risk. High-risk systems often warrant quarterly review, especially when they affect rights, safety, eligibility, pricing, employment or regulated decisions. Limited-risk systems may be reviewed annually unless a major change occurs.

Reviews should evaluate whether the system’s purpose, data, model, vendor, user group, jurisdiction or risk profile has changed. A use case that began as an internal productivity assistant can become a customer-facing support tool; a model trained for one region can be reused in another; a SaaS feature can add generative AI without a full procurement cycle. A review cadence helps catch those changes before the compliance record becomes stale.

AI compliance depends on evidence: which data was used, who accessed it, how it moved, which model version was deployed, what policies applied and which controls operated at the time of review.

Snowflake Horizon Catalog supports governance, discovery and compliance workflows by surfacing context such as access history, lineage, classification and policy enforcement. Snowflake’s ACCESS_HISTORY view provides a record of what data was accessed, when access occurred and how data moved from source objects to target objects, which can help teams produce audit evidence for access, lineage and data-use controls.

For ML systems, Snowflake ML Model Registry stores and manages model versions, model metrics and model metadata, supports model lifecycle management and can monitor model performance and drift through Snowflake ML Observability. It also supports RBAC for model access, helping teams connect model governance to the same kinds of controls they use for data access.

For generative AI use cases, Cortex Guard is designed to help identify and filter potentially unsafe or harmful responses before model output returns to the application. Depending on the architecture, teams can pair these safeguards with prompt, response, access and application logs to support generative AI audit trails.

Snowflake Compliance Center gives customers access to security and compliance resources, including certifications and reports that can support vendor due diligence and customer or regulator audits. Snowflake has also achieved ISO/IEC 42001 certification for its AI management system, subject to ongoing surveillance audits, which provides a concrete example of how AI governance, AI risk management and compliance practices can be organized under a certifiable management-system standard.

Together, these capabilities help organizations attach compliance evidence to the systems that produce it: lineage paths, access logs, model metadata, evaluation metrics, policy enforcement records and control artifacts. That does not eliminate the need for legal review, risk classification or human accountability, but it can reduce the manual work required to prove that AI controls are operating.

AI compliance is easiest to prove when it’s built into the lifecycle. An AI system should enter the inventory when the use case is proposed, receive a risk tier before development proceeds, carry documentation through testing and deployment, and preserve evidence as users, data, models and vendors change.

That operating model matters because AI systems rarely stay still. Compliance teams can only manage that movement if they can trace the system from obligation to control to evidence.

The organizations that handle AI compliance well will not be the ones with the most robust policy documents. They will be the ones that can answer specific questions quickly, such as which AI systems are in use, which are high risk, which data they touch, which controls apply, when they were last reviewed and what evidence proves conformance.