6 min read

AI Compliance Requirements: Frameworks and Risks

BEMO on Aug 31, 2026

AI Compliance

Quick Answer: AI compliance requirements come from three places: Framework standards such as ISO/IEC 42001 and the NIST AI RMF. Regulation, including the EU AI Act and sector rules. And customer contracts. For most US companies the contracts bind first. A procurement gate arrives long before a regulator does.

You have accepted that this applies to you. Now you need the list.

The problem is that every source gives you a different one. The standard gives you clauses. The regulation gives you obligations. The customer gives you 40 questions in a spreadsheet.

None of them tell you what file to produce. That is what this page is for.

For every requirement below, we name the artifact an auditor asks to see.

Key Takeaways

AI compliance requirements come from framework standards, regulation and contracts. Contracts usually bind the earliest.
Seven groups cover almost every ask. Inventory, risk and impact, data governance, oversight, transparency, monitoring and supplier management.
Every requirement resolves to a document, a log or a record. If it does not, it is not implementable.
BEMO builds and operates the evidence base, not just the policy set. Book a gap assessment or review BEMO’s AI compliance and ISO 42001 services.

Where AI Compliance Requirements Come From

Three sources. Different enforcement, different timelines, different consequences.

Framework Standards

ISO/IEC 42001:2023 is the certifiable one. Clauses 4 to 10 define the management system. Annex A carries 38 controls across nine control objectives, A.2 to A.10.

Annex A is a reference set, not a checklist. You select through a Statement of Applicability and justify every exclusion. Undocumented exclusions become audit findings.

The NIST AI Risk Management Framework is at 1.0, published January 2023. Four functions: Govern, Map, Measure, Manage. It is voluntary, produces a self-assessment, and carries no certificate. NIST is revising it under the White House AI Action Plan.

Both are recognized AI compliance standards. Only one closes a procurement question. Buyers cite AI compliance standards by name, so the distinction matters.

Regulation

The EU AI Act applies if your systems reach the EU market. Regulation (EU) 2026/1744, the Digital Omnibus on AI, entered into force on 27 July 2026.

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

Article 50 transparency was not deferred and applied from 2 August 2026. Legacy systems have until 2 December 2026 under Article 50(2).

US state AI compliance regulations have proven unstable. Colorado repealed and replaced its 2024 AI Act with SB 26-189.

That law takes effect 1 January 2027, with rulemaking still open. Treat state AI compliance regulations as things you map onto a stable framework layer.

Sector rules need no AI-specific law. BEMO’s compliance hub covers the frameworks side by side. Where AI touches PHI, HIPAA applies. Where it touches CUI, NIST SP 800-171 applies.

Contracts

This is the one that shows up first. Enterprise security questionnaires now carry AI governance sections. Procurement gates and DPAs increasingly name AI use.

A contract has no grace period and no phased rollout. It is answered or the deal stalls.

The Core Requirements

Seven groups of AI compliance requirements. The right column is what actually gets requested.

Requirement	What it means in practice	Evidence an auditor asks for
AI system inventory	Every AI system, model and third-party AI service in scope, with owner, purpose and data touched	Maintained inventory register with review dates and named owners
Risk and impact assessment	Per-system assessment of harm, data sensitivity and decision impact, repeated on change	Completed assessments, assessment procedure, evidence of re-assessment after model change
Data governance and provenance	Documented sources, quality expectations and permitted use for data feeding AI systems	Data classification records, data flow diagrams, source documentation
Human oversight	Defined points where a person reviews, overrides or approves an AI output	Oversight procedure, review logs, records of overrides and escalations
Transparency and disclosure	Users told when they interact with AI, and outputs marked where required	Disclosure notices, UI screenshots, output-marking configuration
Monitoring and logging	Continuous capture of AI interactions and control performance, with defined retention	Audit log configuration, retention settings, monitoring reports over time
Supplier management	Assessment of every third-party model provider, tracked over the relationship	Vendor assessment records, contract terms, reassessment schedule

Here is a useful test on any AI compliance checklist. If a line item cannot become a file, it is not yet a requirement. It is a sentiment.

Most items map to more than one source. One inventory register answers ISO/IEC 42001 Annex A and the NIST Map function. It also covers half a customer questionnaire.

For a deeper clause-level view, see BEMO’s ISO 42001 compliance requirements guide.

What a Customer Questionnaire Actually Asks

Worth reading the contractual version of these requirements, because it arrives first.

The questions repeat across buyers. Which AI systems process our data. Is any of it used for model training. Who reviews AI-generated output before it reaches us.

Then: do you hold ISO/IEC 42001 or an equivalent. What is your AI incident process. Which sub-processors provide AI capability.

Every one of those maps to a row in the table above. A maintained inventory answers the first. A signed data processing position answers the second. An oversight procedure answers the third.

Teams that build the artifacts first answer questionnaires in a day. Teams that build them per-questionnaire answer in three weeks, badly. Then they rebuild the same answers next quarter.

That gap is the argument for a program, not a series of responses.

What Changes if You Are Regulated

Short section, because the principle is simple. Where AI touches regulated data, the existing regime already covers it.

Healthcare. A model that reads PHI is a system processing PHI. HIPAA’s safeguards, BAA obligations and minimum necessary rule apply as written.
Financial services. Model-driven credit, fraud and suitability decisions sit under existing fair lending expectations.
Defense contracting. AI touching CUI inherits NIST SP 800-171. The control set does not change because the processing is a model.

Nobody needs a new rule to be in scope. The AI-specific work is the layer on top: inventory, impact assessment and oversight.

The Risks of Getting This Wrong

Three real categories. No invented penalty figures.

Losing the deal. The most common outcome and the least discussed. A questionnaire arrives and the answers are not available. The procurement cycle slips a quarter or dies.
Data exposure through unmanaged tools. Staff paste customer data into consumer AI tools. Copilot surfaces an over-permissioned HR folder. Neither needs a regulator to become a breach.
Enforcement under regimes that already exist. The likely first enforcement against most US companies is not AI-specific. It is a privacy, sector or contractual action where AI was the mechanism.

Add a quieter one. Certification schedules slip when evidence was never collected. You cannot retrofit twelve months of monitoring records the month before an audit.

Where Requirement Lists Stop Being Enough

A list tells you what is missing. It does not implement anything. This is where AI compliance requirements for enterprises stop being a documentation exercise.

The requirements that fail assessments are the continuous ones.

Monitoring. Turning on logging is a day of work. Reviewing it weekly for a year is a staffing decision nobody made.
Re-assessment after change. A vendor updates a model. Your impact assessment is now describing a system that no longer exists. Who noticed?
Evidence retention. Auditors sample across the period. Gaps in the record read as gaps in the control.
Inventory drift. Teams adopt new tools faster than anyone catalogues them. An inventory built in January is wrong by March.

Any AI compliance checklist for enterprise use assumes an operator. Most enterprise IT teams have no spare person to be one. That is the gap, and it is an operating gap, not a knowledge gap. It is also the reason BEMO sells the operating function rather than a platform seat.

Meeting These Requirements in Microsoft 365 and Azure

Map each requirement to configuration. Turn it on, log it, retain it.

Inventory. Microsoft Defender for Cloud Apps discovers unsanctioned AI applications in use. Run discovery continuously, not once, and pair it with shadow AI controls that block the high-risk ones.
Data governance. Microsoft Purview classification and sensitivity labels define what can reach a model. DLP policies enforce it on prompts and outputs.
Access control. Entra ID conditional access restricts AI tooling by user, device and risk. Privileged identity management covers who can change model settings.
Oversight and output controls. Microsoft Foundry content filtering screens prompts and completions. Foundry evaluations test model behavior before release. Microsoft renamed Azure AI Foundry to Microsoft Foundry, so older guides use the old name.
Monitoring and retention. The Microsoft 365 unified audit log captures AI activity. Set retention against your evidence obligation, then forward to Sentinel for correlation and alerting.
Supplier management. Microsoft publishes its own ISO/IEC 42001 alignment, which supports your vendor file. It does not cover your own deployment.

Our piece on AI in risk and compliance covers where automation helps.

Turn Your AI Compliance Requirements Into an Evidence Plan

Requirements are the easy half. Evidence is the half that fails audits.

So work backwards. Take each requirement, name the artifact, name the owner, name the review cadence. Anything without all three is not implemented.

Then decide honestly who runs it after go-live. If it is the two people already running your environment, the plan fails.

BEMO owns the build and the operation. Inventory, controls, GRC management, auditor coordination and maintenance.

Book a gap assessment to see which requirements you already meet and which need work.

Frequently Asked Questions

The questions that come up most often when teams start building.

Which AI compliance requirements apply to a company that only uses third-party AI?

Nearly all of them. Inventory, access control, data governance, oversight, monitoring and supplier management all apply. Bought AI is treated like built AI. The split changes: the provider covers model development, you cover deployment and use.

Do we need a separate AI policy, or can we extend our existing security policy?

Either works if the AI-specific content is there. ISO/IEC 42001 expects a documented AI policy aligned with other organizational policies. Many teams extend existing policy with AI sections covering acceptable use, oversight and incident handling.

What evidence do auditors actually ask for on AI systems?

Most often: the AI system inventory with owners and completed impact assessments. Also the Statement of Applicability. Then audit log configuration, retention settings, oversight records and vendor assessments. They test whether records span the period, not just the audit week.

How often do AI impact assessments need repeating?

On a defined cadence and on material change, whichever comes first. Annual review is common. A model version change, new data source or new use case triggers reassessment.

Does ISO 27001 certification cover any of these requirements?

A meaningful share. Access control, logging, supplier management and incident response carry over directly. Both standards share Annex SL structure. What ISO 27001 misses is AI-specific: impact assessment, model transparency, data provenance and human oversight.