What Is AI Compliance? A Guide for Security Teams

Quick Answer: AI compliance is the practice of governing the AI systems your organization already runs. It covers knowing what AI exists, assessing risk, controlling access, and holding evidence. Obligations arrive from two directions: customer contracts and regulation. Contracts usually bind first. It applies to any company using AI, including companies that only buy third-party models.

A security questionnaire lands from an enterprise prospect. Three of the questions are about AI governance. Who owns AI risk. Which AI systems touch customer data. How model outputs are reviewed.

Nobody on your team can answer them. Not because the controls are missing. Because no one has ever written down which AI systems the company runs.

That gap is now a revenue problem. Enterprise buyers are adding AI questions to the same reviews that ask for SOC 2. Procurement will not wait for a regulator.

This article sets out what AI compliance covers and who it applies to. It also names the rules in play and the real implementation cost.

Key Takeaways

• AI compliance covers four things: inventory, risk assessment, access and output controls, continuous evidence.
• Most obligations reach you through contracts and security questionnaires before any regulator does.
• An AI inventory is the prerequisite. You cannot assess or govern systems you have not listed.
• ISO/IEC 42001 is the only certifiable answer. The NIST AI RMF is guidance, not a certificate.
• BEMO runs the inventory, the controls and the evidence for teams without a dedicated AI owner. Book a gap assessment or see how BEMO handles AI compliance and ISO 42001.

What AI Compliance Actually Covers

Most definitions stop at "following AI regulations." That is too narrow to act on. The work breaks into four domains.

• Knowing what AI systems exist. Every model, feature and third-party service in your environment. What data each one reads. What each one produces. Who turned it on.
• Assessing the risk each system creates. Not a generic risk register. A per-system judgment on data sensitivity, decision impact and failure mode.
• Controlling access and output. Who can use which system. What data can reach it. What happens to what it returns.
• Holding evidence that the first three happen continuously. Logs, review records, assessment dates. An auditor asks for artifacts, not intentions.

Here is the same answer stated plainly, because teams keep missing it.

AI compliance is the practice of governing the AI systems your organization already runs. It spans inventory, risk, control and evidence.

It is not a single regulation. It is a set of obligations assembled from framework standards, sector rules and customer contracts.

That last source is the one that arrives first. A signed contract clause is enforceable this quarter. AI regulatory compliance is the slower half of the problem.

Who AI Compliance Applies To

Four groups already know they are in scope.

• SaaS vendors shipping AI features. Their customers ask during procurement, every time.
• Healthtech and fintech. AI touching PHI or financial decisions inherits an existing regulatory regime immediately.
• Government contractors. Federal buyers are adding AI governance language to solicitations and flow-down clauses.
• Companies building their own models. The obvious case, and the smallest one.

Then there is the group that thinks none of this applies. Companies that build no AI at all.

They run Microsoft 365 Copilot. Their CRM added an AI summarizer. Their helpdesk tool scores tickets with a model. Their recruiting platform ranks candidates.

None of that was procured as AI. All of it is AI, and all of it is in scope. AI regulatory compliance does not care whether you wrote the model or bought it.

If you consume a third-party model, you own the deployment risk. The vendor owns the model. You own what your people feed it.

The Frameworks and Rules in Play

Four sources of obligation matter. Treat the first two as the stable layer.

ISO/IEC 42001:2023 is the world’s first AI management system standard. Its Annex A carries 38 controls across nine control objectives, numbered A.2 to A.10.

You select controls through a Statement of Applicability. It is the only item on this list you can hold a certificate for.

The NIST AI Risk Management Framework is at version 1.0, published January 2023. It is voluntary and produces a self-assessment, not third-party assurance.

NIST released a preliminary draft Cyber AI Profile in December 2025. AI RMF 1.0 is being revised under the White House AI Action Plan.

The EU AI Act timing has moved. Regulation (EU) 2026/1744, the Digital Omnibus on AI, entered into force on 27 July 2026.

It pushed standalone high-risk obligations under Annex III to 2 December 2027. Embedded systems under Annex I move to 2 August 2028.

Article 50 transparency obligations were not deferred. They applied from 2 August 2026 as written. Systems already on the market get until 2 December 2026 under Article 50(2).

State-level rules are less stable and worth less planning weight. Build on the ISO and NIST layer, then map statutes onto it.

Choosing an AI Compliance Framework

Most teams ask which one to pick. That is the wrong question in the wrong order.

An AI compliance framework is a method, not a product. Two are worth your time.

Use the NIST AI RMF as the method. Its four functions give you a way to identify systems, measure risk and manage it. It costs nothing and needs no auditor.

Use ISO/IEC 42001 as the system of record. It turns that method into documented, auditable practice with a certificate at the end.

Work done under one is reusable in the other. Both cover inventory, risk assessment, oversight and continual improvement.

The deciding factor is what your buyer will accept. A procurement team asking for proof of certification cannot be satisfied by a self-assessment.

That is the practical answer to what is AI compliance at the framework layer. One method, one system of record, one certificate.

Sector rules need no new AI law to bite. If a model reads PHI, HIPAA already applies. Governance work sits on top of the regime you already carry, rather than replacing it.

For the requirement-by-requirement view, see our breakdown of AI compliance requirements.

Where AI Compliance Programs Stall

This is the honest part. Programs rarely fail on the standard. They fail on operations.

The inventory is never complete. AI features arrive inside tools bought for something else. Marketing enables an AI writer. Support turns on auto-summarization. Nobody files a ticket.

Nobody owns it. Model risk sits between security, legal and product. Security owns the controls. Legal owns the contract language. Product owns the model choice. No one owns the outcome.

Impact assessments get treated as documents. A team completes one, files it, and moves on. The standard expects a repeated process tied to system changes.

Monitoring evidence does not exist. The controls may be real. The record proving they ran for twelve months is not. Auditors test the record.

Teams plan it as a project. Gap assessment, remediation, done. ISO/IEC 42001 requires an operating management system, with surveillance audits every year.

The Staffing Math Nobody Runs First

Look at the numbers before deciding to build this internally.

BEMO's published in-house comparison puts a single compliance hire at $84,000 to $132,000 a year.

That is before tooling or auditor fees. Recruiting and onboarding takes months. Most programs need three or four such people.

Audit fees sit on top of that, and they recur every year.

Now compare that to the actual scope of work. One inventory, kept current. One risk process, repeated. One evidence base, held for twelve months and sampled by an auditor.

That is not a headcount problem you solve with a platform subscription. It is an operating function, and it needs an operator from day one.

There is one more. Inventories go stale in weeks. Adoption outpaces cataloguing, so a point-in-time list is wrong by the next quarter.

These are the real AI compliance risks across a large estate. The AI compliance risks that fail audits are operational, not technical.

Microsoft 365 and Azure Surfaces That Carry the Controls

Policy without configuration is paper. Here is where the controls actually live in a Microsoft environment.

Discovery of shadow AI. Microsoft Defender for Cloud Apps surfaces unsanctioned AI tools in use. This is how the inventory gets built, and rebuilt.

Data classification and loss prevention. Microsoft Purview sensitivity labels and DLP policies apply to prompts and outputs, not just files. Classify first, then decide what can reach a model.

Access control. Entra ID conditional access governs which users and devices can reach AI tooling. Privileged identity management covers admin access to model configuration.

Copilot boundaries. Microsoft 365 Copilot respects existing permissions. That is the problem. Over-permissioned SharePoint becomes a disclosure surface. Permissions cleanup comes before deployment.

Model-layer guardrails. Microsoft Foundry content filtering runs prompts and completions through classification models. Evaluations test model behavior before release.

Microsoft renamed Azure AI Foundry to Microsoft Foundry, so older documentation uses the previous name.

Logging and retention. The unified audit log captures AI interactions. Set retention to match your evidence obligation, not the default. Sentinel correlates those logs with the rest of your estate.

Microsoft publishes its own ISO/IEC 42001 alignment for its AI services. That helps your supplier assessment. It does not certify your deployment.

How BEMO Runs AI Compliance

BEMO does not sell you a dashboard. BEMO runs the program. The path is staged, and you start where you are.

Stage 1, shadow AI. Detect unsanctioned AI tools. Block high-risk external platforms. Stop sensitive data leaving. BEMO’s published implementation timeline for this stage is four weeks.

Stage 2, Copilot security. Permissions cleanup, DLP policies for AI, conditional access, full audit logging of AI activity. Roughly six weeks.

Stage 3, AI agent security. Identity, access and monitoring for agents, plus an AI control board. Roughly twelve weeks. BEMO governs agents rather than building them for you.

Stage 4, ISO 42001. Policies, AI risk assessments, system inventory, training and GRC management in Drata. Then auditor coordination through the Stage 1 and Stage 2 audits.

Each account gets a named team. Compliance engineer, virtual CISO, security engineer, SOC analyst and support. AI managed services sit on a Diamond or Platinum security foundation.

See the full path on the AI managed services page, or start at BEMO.

Start Your AI Compliance Program With an Inventory

Every other step depends on the first one. You cannot risk-assess an unknown system. You cannot control access to a tool you have not found.

So the sequence is fixed. Discover what is running. Assign an owner. Assess each system. Configure the controls. Then keep the evidence.

Most teams stall between step one and step two. Nobody was staffed for step two. That is the gap BEMO fills.

Book a gap assessment for a mapped view of your AI systems and your gaps.

Frequently Asked Questions

The five questions buyers and boards ask most often.

Is AI compliance a legal requirement?

Partly. The EU AI Act is binding law for systems in EU scope. In the US there is no single AI statute. Most US organizations meet AI obligations first through customer contracts and security questionnaires. Existing sector rules such as HIPAA also apply.

Does AI compliance apply if we only use third-party AI tools?

Yes. Buying a model does not transfer the deployment risk. The vendor is responsible for the model. You are responsible for what data reaches it and who uses it. Output review is yours too. Third-party AI still belongs in your inventory.

What is the difference between AI compliance and AI governance?

Governance is the internal system: policies, ownership, decision rights and oversight. Compliance is proving that system meets an external requirement. That may be a standard, a regulation or a contract. Governance is what you build. Compliance is what you demonstrate.

Does our SOC 2 or ISO 27001 already cover AI?

Partially. Both cover access control, logging and vendor management, which carry over. Neither covers AI-specific risks such as model bias, output transparency or impact assessment. ISO/IEC 42001 shares Annex SL structure with ISO 27001, so existing work reduces the gap.

Where do we start if we have no AI inventory?

Start with discovery, not policy. Use Defender for Cloud Apps to surface AI tools already in use. Then review SaaS contracts for AI features enabled by default. Assign an owner per system before writing any documentation.