AI Compliance for Startups: EU AI Act, ISO 42001 & NIST

Key takeaways:

• The EU AI Act is binding law. It applies if your AI affects anyone in the EU, and requires risk classification, documentation, and human oversight for high-risk systems.
• Using a third-party AI model, like OpenAI, Anthropic, or anyone else's, doesn't exempt you from these requirements. The Act regulates how AI is deployed and used, not just how it's built.
• NIST is a US risk management framework, while ISO 42001 is a certifiable management system standard.
• Most companies don't need three separate compliance programs. One AI system inventory and one risk register, mapped across whichever of these frameworks actually apply, covers all of them.

‍

This post lays out what each of the EU AI Act, NIST AI RMF, and ISO 42001 framework requires, who has to follow which, and how GDPR and the security frameworks you may already hold fit into the picture.

This applies whether you're training your own models or just using someone else's. Yes, even deploying AI you didn't build still puts obligations on you.

‍

The EU AI Act

‍

The EU AI Act is the world's first comprehensive AI regulation, and the only framework in this article with the force of law behind it. It applies based on where your AI's effects land, just like GDPR. If your product is used by people in the EU, or processes their data, or makes decisions that affect them, you should worry about it.

The Act sorts every AI system into one of four risk tiers, and the tier determines what you actually have to do:

• Unacceptable risk: Banned outright. Social scoring, untargeted scraping of facial images to build recognition databases, and a short list of similarly invasive practices aren't regulated, they're prohibited. There's nothing to comply with here except not building it.
• High-risk: This is where the real compliance work sits. Covers AI used in hiring and employment decisions, education and exam scoring, credit and insurance underwriting, critical infrastructure, and law enforcement. Providers of high-risk systems must: run a risk assessment before deployment and keep it current; use training data that's relevant, representative, and checked for errors and bias; maintain technical documentation detailed enough for a regulator to reconstruct how the system works; log system activity so decisions can be traced after the fact; build in a way for a human to meaningfully oversee and override the system; and register the system in an EU public database before placing it on the market.
• Limited risk: Covers chatbots, deepfakes, and AI-generated content. The requirement is disclosure: tell people they're talking to AI, or that what they're looking at was AI-generated. No risk assessment or registration required.
• Minimal risk: Most day-to-day AI, such as spam filters, recommendation engines, and inventory forecasting, falls here and carries no specific obligations under the Act.

Penalties scale with the violation: up to €35 million or 7% of global annual turnover for deploying a prohibited system, with lower tiers for other infringements. However, for most startups, the bigger operational risk isn't just the fine. A high-risk system found non-compliant can be ordered withdrawn from the EU market outright, which stops revenue.

GDPR and The EU AI Act 

‍

If your AI system touches personal data, trains on it, generates outputs from it, or uses it to make decisions, GDPR keeps applying. The AI Act adds obligations on top of it, but it doesn't replace any of them. Three GDPR requirements stay relevant specifically because of how AI processes data:

‍

• You need a lawful basis for every use of personal data your AI touches, the same requirement as any other processing, but easy to lose track of once data is flowing through a model pipeline instead of a simple database query.
• You owe an explanation when an AI system makes a decision that significantly affects someone, like a loan denial, a job rejection, or an automated account suspension. GDPR Article 22 gives people the right to know that, and to contest it.
• You need a Data Protection Impact Assessment for AI processing likely to result in high risk to individuals, which covers most systems that would also qualify as “high-risk” under the AI Act.

The AI Act's documentation requirements and GDPR's data mapping requirements ask for a lot of the same information. Build your data inventory once, structured to answer both, and avoid maintaining two records that quietly drift out of sync.

NIST AI RMF

‍

The NIST AI Risk Management Framework, published by the US National Institute of Standards and Technology, provides organizations with a common structure for identifying and managing AI-related risks. It's referenced in US federal procurement guidance. 

‍

It has become the framework that many enterprise security teams reach for when they evaluate how a vendor handles AI risk. It’s a similar role SOC 2 plays in a security review.

The framework organizes that work into four functions:

• Govern: who's accountable for AI risk inside your organization, and what policies exist to back that up.
• Map: understanding the context a specific AI system operates in and what could go wrong with it.
• Measure: assessing and tracking those risks with actual metrics.
• Manage: acting on what you've measured, by mitigating, accepting, or escalating risk as appropriate.

ISO 42001

‍

ISO/IEC 42001 is the first international standard for AI management systems, and what makes it different from NIST AI RMF: it's certifiable. An accredited third party audits your organization against it and issues a certificate. It’s the same model ISO 27001 uses, since 42001 was deliberately built on the same management-system structure.

‍

But it’s important to mention that ISO 42001 doesn't certify that your AI product is accurate, unbiased, or safe. It certifies that your organization runs a real management system around how AI is governed: documented ownership, risk assessments that get maintained, and audit evidence that a third party has actually checked. That's the claim a growing number of enterprise procurement teams are now asking for by name in RFPs and due diligence questionnaires.

‍

Because the structure mirrors ISO 27001, organizations that already hold that certification find significant overlap: similar documentation conventions, similar internal audit cycle, and similar management review process. Building the second program is usually faster than building the first.

‍

Where ISO 27001 and SOC 2 fit

‍

If you already hold ISO 27001 or SOC 2, it's worth being precise about what those certifications cover, because it's not AI governance. They protect data and systems from unauthorized access, breaches, and operational security failures. Neither was built to address what's specific to AI, like biased outputs, model drift over time, or whether a system's decisions can be explained.

Think of it as two different layers of the same stack. ISO 27001 and SOC 2 secure the infrastructure your AI runs on. ISO 42001 governs how the AI itself is managed. You need both if you're serious about either security or AI governance. One doesn't substitute for the other, and most companies pursuing AI governance seriously are already holding or pursuing one of the security certifications anyway.

Which of These Actually Applies to You

‍

Three questions narrow this down:

• Does your AI affect anyone in the EU? If yes, the EU AI Act applies regardless of your size or where you're based.
• Do you sell mainly to US enterprises? If yes, expect NIST AI RMF's vocabulary to show up in security reviews even though nothing legally requires it.
• Are buyers asking for third-party-verified proof specifically? If RFPs or due diligence are naming certification directly, that's the signal ISO 42001 is worth pursuing.

These aren't mutually exclusive, and for most companies with any EU exposure and enterprise ambitions, the realistic answer is some combination of all three.

‍

Building one program instead of three

‍

The inefficient way to approach this is to treat each framework as its own project: its own risk assessment, its own documentation, its own owner. That triples work for requirements that overlap substantially. A more efficient sequence would be:

• Inventory every AI system first: Every framework here starts with knowing what AI you have and what data each one touches.
• Build one risk register: Structure it to capture EU AI Act risk tier, NIST function mapping, and ISO 42001 control coverage for each system in a single record, instead of triplicating the same assessment three different ways.
• Map controls once and reuse the evidence: A control that satisfies an ISO 42001 requirement frequently also satisfies a related NIST function and contributes to AI Act documentation. Document it once and point to it from all three.
• Name an owner: Someone needs to own AI governance the way someone already owns information security. Without a named owner, none of the above survives past the first audit cycle.

Building an AI Governance Program that holds up

‍

Most startups don't need three separate compliance projects. They need one governance program mapped across whichever of these frameworks actually apply to their business. 

‍

SecureLeap helps startups identify their real exposure and build the AI inventory and risk register that satisfies multiple frameworks at once. We also help you prepare for the audits that turn governance into something an auditor, investor, or enterprise buyer can verify properly.

Ready to find out which AI compliance frameworks actually apply to you? Book a free 30-min call here or send us an email. 

‍

FAQ: Frequently asked questions on AI Compliance

‍

What is AI compliance?

‍

AI compliance is governing how an organization develops, deploys, or uses AI systems in line with applicable laws and standards, covering risk assessment, documentation, oversight, and accountability for AI-related decisions. It overlaps with data privacy and information security compliance but addresses risks specific to AI, such as biased outputs and model drift, that those fields weren't built to cover.

Is the EU AI Act mandatory for startups outside the EU?

‍

Yes, if your AI affects people in the EU. The Act applies based on where your AI's effects land (EU users, EU personal data, and decisions affecting EU residents), not where your company is incorporated. 

Do I need to comply with AI regulations if I only use third-party AI tools like OpenAI or Anthropic?

‍

Yes. The EU AI Act regulates how AI is deployed and used, not only how it's built. If you embed a third-party model into your product, you're still responsible for the risk tier that use case falls into, what data the AI processes, and what oversight exists over its outputs. The scope of your obligations differs from a company training its own models, but using someone else's model doesn't erase them.

What's the difference between the EU AI Act, NIST AI RMF, and ISO 42001?

‍

The EU AI Act is binding law with fines for non-compliance. NIST AI RMF is a voluntary US risk management framework with no certification. And ISO 42001 is a voluntary but certifiable management system standard, auditable by an accredited third party. None of the three substitutes for another, because they operate at different layers: legal requirement, risk methodology, and auditable management system.

Do I still need ISO 27001 or SOC 2 if I get ISO 42001?

‍

Yes. ISO 27001 and SOC 2 protect your systems and data from security failures and breaches, while ISO 42001 governs AI-specific risks that those frameworks don't address. 

Is NIST AI RMF certification required?

‍

There's no certification body for NIST AI RMF, since it's a risk management framework, not something you get certified against. It's referenced in US federal procurement guidance and used by enterprise security teams as a shared reference for evaluating how a vendor manages AI risk, so being able to map your controls to its four functions is what a security review increasingly expects to see.

‍