AI Compliance Guide: EU AI Act, ISO 42001, NIST AI RMF and U.S. AI Laws

Practical guide · Comply · Version 1.0 · Last reviewed October 3, 2026

Most AI compliance programs get complicated for one reason: they start with the regulations instead of the AI.

I see the same pattern again and again. Legal is reading the EU AI Act. Risk is mapping NIST AI RMF. Someone in compliance wants to know if ISO 42001 certification is worth it. Meanwhile HR has already rolled out an AI recruiting platform, and procurement is halfway through onboarding another AI vendor. Six months later, the organization has four projects asking slightly different versions of the same questions, and nobody can say with confidence which systems are actually covered.

There is a simpler way. This guide answers two questions: which AI rules apply to us, and what do we actually have to do about them? It covers the EU AI Act, ISO/IEC 42001, the NIST AI Risk Management Framework, and the main U.S. federal and state requirements. For each one I start with applicability, then roles, obligations, and evidence, and I end with the mapping that turns a rule into something you can run and prove:

The short version: build one AI governance program, then map it to whatever applies to you. A solid inventory, risk assessment process, testing program, oversight process, vendor program, and evidence structure will support several frameworks at once. You do not need four governance programs.

Step 1: What applies to you?

Start with applicability, not obligations. Before you ask what controls the EU AI Act requires, find out whether it applies to the system in front of you and what role you play. Before you build a California notice, confirm that the business, the processing, and the people affected actually fall within scope. Four questions get most organizations most of the way there.

Very few organizations fit in one row. A U.S. company can be subject to the EU AI Act. A company pursuing ISO 42001 certification will often use NIST AI RMF as its risk method. An employer can have federal anti-discrimination duties and a city-level AI audit requirement for the same hiring tool.

Don’t start by choosing a framework. Start with your systems.

For each AI system, you should be able to answer, at minimum: what it does, who owns it, whether you built it or bought it, what data it uses, who is affected by its outputs and where they are, whether it influences a consequential decision, which vendors or models it depends on, and what role your organization plays.

You can’t do that reliably without an AI inventory. If you don’t have one, build it first; my AI Governance Framework guide lists the fields and the ownership model I recommend. Once the systems are in front of you, applicability gets much easier. A single hiring tool might trigger the EU AI Act for EU applicants, New York City’s audit law for NYC candidates, and federal discrimination law everywhere in the U.S. If you’re pursuing ISO 42001, the same tool also sits inside your management system. That’s one system and several frameworks, which is exactly why you want one governance process, not several.

EU AI Act

Status, October 2026: Regulation (EU) 2024/1689, as amended, including by the Digital Omnibus on AI, Regulation (EU) 2026/1744, in force since July 27, 2026.

Does it apply to you?

Let’s clear up the most common misconception first: the AI Act is not only for European companies. Depending on the facts, it can apply when you place an AI system or general-purpose AI model on the EU market, use AI professionally inside the EU, are based outside the EU but your system’s output is used there, import or distribute covered AI in the EU, or build AI into certain products sold in the EU.

There are exclusions, including national security, military and defense, certain scientific research, purely personal use, and some testing before market release. Treat open source carefully. “It’s open source” does not automatically mean “it’s outside the Act.”

Your role matters as much as your technology

The question most teams ask first is “Is this high-risk?” The better first question is “What are we in relation to this system?”

These are not permanent labels for your company. Decide them system by system: you can be a deployer for one tool and a provider for another. Roles can also shift. If you rebrand, substantially modify, or change the intended purpose of someone else’s AI system, provider obligations can move to you. That’s why your inventory needs a regulatory role field, not just “vendor AI” or “built in-house.” I go deeper on this in EU AI Act: Provider vs. Deployer.

Which risk category is your AI in?

Don’t classify by the technology’s name. A chatbot isn’t automatically low risk, and a machine-learning model isn’t automatically high risk. What matters is what the system does and which decisions it touches. A recruiting chatbot that tells applicants where the office is has very little in common with a system that ranks candidates and recommends who gets an interview.

Don’t write “low risk” in the inventory and move on

For every material classification, I want to be able to reconstruct the reasoning later: what the system does, which provision we assessed it against, what we concluded and why, who approved that conclusion, what evidence supports it, and what kind of change would make us look at it again. That last point matters more than people expect. Vendors update models, business teams add features, an internal assistant becomes customer-facing, and a summarization tool starts recommending decisions. Classification is not a one-time exercise.

Core obligations for high-risk AI

Providers carry the heaviest load: lifecycle risk management, data governance, technical documentation, logging, instructions for deployers, human oversight design, accuracy, robustness and cybersecurity, a quality management system, conformity assessment, registration and declarations where applicable, post-market monitoring, and serious-incident reporting.

Deployers have their own list: follow the instructions for use, assign human oversight to people with the competence and authority to do it, manage the input data under your control, monitor operation, keep the relevant logs, respond to risks and incidents, give the required notices, meet workplace consultation duties, and complete a fundamental rights impact assessment where Article 27 applies.

The practical point is simple. Buying the AI does not hand your responsibility to the vendor. If you deploy a covered system, you need your own controls.

If you own EU AI Act compliance, start here

Don’t begin by turning every article of the regulation into a spreadsheet with hundreds of controls. Export your AI inventory and add these fields if they’re missing:

Then work through one system at a time. Take an AI recruitment tool. First pin down exactly what it does. Does it schedule interviews, summarize CVs, rank applicants, or recommend rejections? Does a human genuinely decide, or do they usually accept the recommendation? Then establish where it’s used and who it affects, then your role, then the classification. Only after that do you decide the controls. The order matters; skip it, and teams spend months building controls for systems that turn out to sit in a different category than they assumed.

EU AI Act: requirement → action → owner → evidence

For Annex III high-risk systems, the key application date is now December 2, 2027. For high-risk AI tied to regulated products under Annex I, it’s August 2, 2028. Please don’t read those dates as permission to start in late 2027. Technical documentation, vendor dependencies, testing, quality processes, and evidence all take longer than anyone plans for.

Enforcement sits mainly with national market surveillance authorities, with the EU AI Office supervising general-purpose AI models. Fines reach €35 million or 7% of worldwide turnover for prohibited practices, and €15 million or 3% for most other obligations. SMEs get the lower of the two amounts, and the Omnibus extended similar relief to small mid-caps.

ISO/IEC 42001

Status, October 2026: ISO/IEC 42001:2023 remains the current edition. Companion standards: ISO/IEC 42005:2025 (AI system impact assessment) and ISO/IEC 42006:2025 (requirements for certification bodies).

Does it apply to you?

ISO/IEC 42001 is voluntary. Organizations usually pursue it because a customer asks for certification, because procurement questionnaires keep asking how AI is governed, or because leadership wants a structure that holds up. It works for any organization that develops, provides, or uses AI.

What makes it different is that it gives you a management system. You’re not just evaluating individual AI systems. You’re setting up how the organization governs AI every time: policies, responsibilities, risk and impact assessment, competence, documentation, operations, internal audit, management review, and corrective action. Certification then gives independent evidence that the system has been assessed.

One caution I give every client: certification is not proof of EU AI Act compliance. There’s real overlap, but they are not the same thing, and you shouldn’t describe them as if they were.

How it’s structured

Clauses 4 to 10 cover the management system itself: context and scope, leadership, planning, support, operation, performance evaluation, and improvement. Annex A sets out AI-specific reference controls for policies, organization, resources, impact assessment, the AI lifecycle, data, information for interested parties, use of AI, and third parties. You decide which controls apply and record that in your Statement of Applicability.

Having the documents is not the same as having an AIMS

You can write an AI policy in a week. That doesn’t mean you have a working management system, and a certification auditor will know the difference. If your procedure says high-risk systems need an impact assessment, the auditor won’t stop at the procedure. The next request will be: show me the systems classified as high risk during the audit period, and their assessments. If the committee approves exceptions, they’ll want the exceptions and the decisions. If staff get role-based AI training, they’ll want to see who needed it, what they received, and whether they finished it.

That’s why I don’t recommend going straight from writing documents to booking a certification audit. Let the system run. Generate records. Find where the process breaks, fix it, and then audit it.

A practical certification path

1. Define what’s actually inside the AIMS scope.
2. Run a gap assessment.
3. Set up policy, responsibilities, and governance.
4. Define your AI risk and impact assessment methods.
5. Decide the applicable Annex A controls and document the Statement of Applicability.
6. Implement the operational processes.
7. Run them long enough to produce meaningful evidence.
8. Complete an internal audit and a management review.
9. Correct the nonconformities you find.
10. Go through Stage 1 and Stage 2 audits with an accredited certification body.
11. Maintain it through annual surveillance and continual improvement.

ISO/IEC 42001: requirement → action → owner → evidence

NIST AI Risk Management Framework

Status, October 2026: AI RMF 1.0 (January 2023) is still the published framework. NIST has said it’s being revised, but no successor has been released. The Generative AI Profile (NIST AI 600-1) remains the key companion for generative AI.

Does it apply to you?

NIST AI RMF is voluntary, and there’s no certification. I treat it as a practical risk-management structure: a common way for governance, technical, risk, legal, and business teams to talk about AI risk without forcing every organization into identical controls. It’s built around four functions, and this is the question I use for each one in practice:

Govern supports everything else; Map, Measure, and Manage repeat across each system’s lifecycle. Don’t wait for the revision. The four functions are expected to stay, and it’s much easier to update a program that exists than to start one later.

Don’t turn it into a giant checklist

This is the easiest mistake to make. A team downloads the framework, converts every statement into a compliance question, and ends up with an impressive spreadsheet and no better risk management. The effort should match the risk. An internal tool summarizing non-sensitive meeting notes doesn’t need the same testing, approvals, and monitoring as an AI system influencing hiring or credit decisions. For each material system, ask what could actually go wrong, decide how you’ll measure it, decide what level of risk you’ll accept, and write the decision down. That’s much closer to what the framework is for than ticking boxes.

How to implement it

Start by mapping what you already have to the four functions. You’re probably not starting from zero: pieces of this already live in information security, privacy, enterprise risk, model risk, vendor management, compliance, and internal audit. Reuse what works, then close the gaps. For generative AI, use the Generative AI Profile rather than treating GenAI risks as if they were the same as a traditional predictive model’s.

NIST AI RMF: outcome → action → owner → evidence

U.S. AI requirements

Status, October 2026. This is the section I’d recheck most often.

There’s still no single federal statute governing private-sector AI. That doesn’t make AI unregulated in the U.S. Consumer protection, employment, anti-discrimination, credit, housing, privacy, and sector rules all reach AI-driven activity, and “the AI did it” is not a defense. On top of that, states and cities keep adding AI-specific rules.

Two federal developments are worth knowing. Executive Order 14365 (December 11, 2025) set a policy of a single national approach and created a Department of Justice task force to challenge state AI laws, but an executive order doesn’t cancel state law on its own, so state AI laws stay enforceable unless a court blocks them or Congress preempts them. And the White House AI accord of September 29, 2026 is a voluntary commitment by leading AI developers; it creates no obligations for companies that use AI.

So the useful question isn’t “Is there a U.S. AI Act?” It’s “Which laws apply to this use of AI, these people, this decision, and these jurisdictions?”

Start with consequential decisions

If AI plays any part in hiring, promotion, termination, credit, insurance, housing, education, healthcare, or another significant decision about a person, give it extra attention. That’s where AI meets long-standing legal protections and most of the new AI-specific rules. Your inventory should record both the decision type and the jurisdictions of the people affected.

U.S. requirements to track

The precise scope tests matter. Don’t implement a notice because a blog post says “California requires AI notices.” Find the actual provision, decide whether your organization and activity are in scope, and document that conclusion.

California: watch the dates carefully

California is a good example of why a compliance calendar needs more than one date column. The CCPA regulations took effect on January 1, 2026, and the risk assessment requirements apply to covered processing from that point, with assessments for existing processing due by December 31, 2027. The first risk assessment submissions to the California Privacy Protection Agency are due by April 1, 2028. The ADMT rules for significant decisions have their own compliance date: January 1, 2027.

“The submission isn’t due until 2028” does not mean “we can ignore the assessment process until 2028.” Track each requirement like this instead of in a single “deadline” column:

U.S. requirements: action → owner → evidence

Crosswalk: build controls once, map them many times

This is where a good governance architecture starts paying for itself.

The table itself isn’t the point; what you do with it is. Say your organization requires an AI impact assessment before certain higher-risk systems go live. Don’t create an “EU assessment,” an “ISO assessment,” a “NIST assessment,” and a “California assessment.” Build one core assessment with the information you need every time, then add jurisdiction-specific questions only where the law genuinely asks for something different. An entry in your evidence register might look like this:

At that point you’re running a compliance program, not collecting documents.

Key dates at a glance

What this means for your AI vendors

Most organizations buy far more AI than they build, which makes vendor governance part of AI compliance, not a separate procurement exercise. Buying an AI product does not transfer your responsibility to the provider. For each material vendor relationship, I’d work through five things:

Confirm the vendor’s role and yours. Decide who is the provider and who is the deployer, and revisit it if you substantially modify or repurpose the product.

Get the documentation you need. If your obligations depend on technical information, test results, logs, or model documentation, agree up front how you’ll get them.

Put cooperation in the contract. Think about material-change notice, incident notice, support for your assessments, access to information, data-use limits, audit or assurance rights, and what happens at termination.

Read the certification scope. “ISO 42001 certified” tells you very little on its own. Which legal entity is certified? Which locations, products, and processes are inside the scope? Who issued it, and when does it expire?

Separate marketing from evidence. A responsible-AI statement, a voluntary pledge, or a trust center page is useful context. It isn’t a contractual commitment, and it isn’t proof that the specific product you’re buying meets your requirements.

My VENDORS guide goes deeper into due diligence questions, evidence requests, contract clauses, and red flags.

Frequently asked questions

We’re a U.S. company. Can the EU AI Act still apply to us?

Yes. Being headquartered outside Europe doesn’t take you out of scope by itself. Look at whether you place covered AI on the EU market, deploy AI in the EU, or fall under another territorial provision, such as your AI’s output being used in the EU.

Did the 2026 amendments change the AI Act timeline?

Yes. The biggest change moved the high-risk dates: Annex III systems now apply from December 2, 2027, and Annex I product-related systems from August 2, 2028. Prohibitions, AI literacy, general-purpose AI model rules, and transparency duties already apply, so don’t treat the later dates as a general postponement.

Is ISO/IEC 42001 legally required?

Generally, no. It’s a voluntary standard. Organizations pursue certification because customers ask for it or because they want independent assurance that their AI management system works.

Do I need NIST AI RMF if I already use ISO 42001?

They work well together. I think of ISO 42001 as the management-system structure and NIST AI RMF as a risk method that runs inside it. You don’t need duplicate controls just to say you use both.

We only buy AI. Are we exempt?

No. Your obligations differ from the provider’s, but deploying third-party AI creates obligations of its own, especially when it affects employees, applicants, customers, or other individuals.

How much documentation is enough?

Enough that another qualified person could reconstruct what happened. For an important AI decision, they should be able to see what was assessed, what risks were found, what testing was done, who decided, what conditions came with the approval, what evidence supported it, and what happened afterward. If your records can’t answer those questions, improve them.

If I were starting this program tomorrow

I wouldn’t start by buying another compliance platform or writing a 100-control AI framework. I’d start with five things.

1. Get the AI inventory into usable shape. System, owner, purpose, vendor, underlying model where relevant, affected people, data, geography, and the consequential decisions it touches.
2. Decide applicability system by system. Record the EU role and classification, the relevant U.S. jurisdictions and requirements, and your ISO and NIST mappings.
3. Build the common controls. Ownership, policy, intake, classification, risk and impact assessment, testing, human oversight, monitoring, incidents, vendor management, training, and records.
4. Attach evidence to every control. For each one, ask: how would I prove we actually did this? If nobody can answer, the control isn’t finished.
5. Work backward from the deadlines. Inventory cleanup, vendor documentation, technical testing, impact assessments, management-system evidence, and remediation all take months.

When a requirement takes effect, the organizations in the best position won’t be the ones with the longest AI policy. They’ll be the ones that know where their AI is, which rules apply to it, who owns the risk, which controls are running, and where the evidence lives.

Primary sources and further reading

• EUR-Lex: Regulation (EU) 2024/1689 (EU AI Act)
• EUR-Lex: Regulation (EU) 2026/1744 (Digital Omnibus on AI)
• European Commission: European AI Office
• ISO: ISO/IEC 42001:2023
• ISO: ISO/IEC 42005:2025
• ISO: ISO/IEC 42006:2025
• NIST: AI Risk Management Framework
• NIST: Generative AI Profile (AI 600-1)
• California Privacy Protection Agency: CCPA regulations
• NYC Department of Consumer and Worker Protection: Local Law 144

Last substantive review: October 3, 2026.