Compliance and standards: a map for AI engineering teams

This is a non-exhaustive list of popular laws, certificates and frameworks you may hear about in software products and services.

The big picture

Below is a brief explanation of the common standard acronyms in the field; skip to whichever ones are useful to you.

The table mixes different kinds of obligations: laws you comply with, audits and certifications that prove controls, AI governance frameworks you adopt, and engineering frameworks you turn into day-to-day practice. The rest of this article takes them in those four groups.

Privacy and security laws

Countries today have laws and acts that govern how you handle personal data and keep it secure, and the consequence of getting them wrong is enforcement by a regulator. They are mandatory and should be treated accordingly. Almost every jurisdiction now has its own, and they do not line up neatly, so the task is to know which apply to you and where they diverge.

Two are described in more detail below: EU GDPR is famous, and Singapore's PDPA is widely referenced in APAC.

GDPR

What it is The European Union's General Data Protection Regulation, in force since 2018. Type Law, with extraterritorial reach. Who cares Anyone processing the personal data of people in the EU and EEA, wherever your company is based. Link gdpr-info.eu, the full text and explainer.

GDPR requires you to have a lawful basis for processing personal data, and it grants people enforceable rights over their data: access, erasure, portability, and objection among them. It mandates data protection by design and by default, records of your processing activities, Data Protection Impact Assessments for high-risk processing, breach notification to regulators within 72 hours, and, in some cases, a designated Data Protection Officer. Fines can reach the greater of €20 million or 4% of global annual turnover. For AI specifically, Article 22 restricts decisions based solely on automated processing that have legal or similarly significant effects, which brings automated decisioning into scope. In practice, teams most often slip by training models on personal data, or sending it to a model provider, without a lawful basis or the impact assessment the regulation expects.

Singapore PDPA

What it is Singapore's Personal Data Protection Act of 2012, the country's baseline data-protection law. Type Law, specific to Singapore. Who cares Organisations handling the personal data of individuals in Singapore. Link pdpc.gov.sg, the PDPA and its guidance.

Singapore's PDPA is built on a set of obligations that will look familiar after GDPR — consent, purpose limitation, notification, access and correction, accuracy, protection, and retention limitation — plus a Do Not Call regime, all enforced by the Personal Data Protection Commission (PDPC). Mandatory breach notification arrived in 2021, and penalties can reach S$1 million or a turnover-based cap. Conceptually it is close to GDPR but generally lighter-touch. The important note for a global product is that privacy is localised: being "GDPR-ready" does not make you PDPA-compliant, because jurisdictions differ on the specifics of consent, cross-border transfer, and notification.

Security and trust

Below are two popular standards for information systems. Both focus on verifying security processes, which is how companies establish trust with one another.

ISO/IEC 27001

What it is The international standard for an information security management system, or ISMS. The current edition is ISO/IEC 27001:2022. Type Certifiable by an accredited body, on a three-year cycle with annual surveillance audits. Who cares Enterprise buyers worldwide, and the default trust signal across Europe, the Middle East, and much of Asia. Link iso.org/standard/27001, the standard's official page.

ISO 27001 explains how to run a system: define the scope, assess your risks, decide how you will treat them, document that decision in a Statement of Applicability, and then operate, measure, and improve the whole thing continually. The control catalogue sits in Annex A, which the 2022 revision reorganised into 93 controls across four themes (organisational, people, physical, and technological), with implementation guidance in the companion standard ISO/IEC 27002. The certificate is awarded for running the management system.

For an AI-using team, the practical move is to bring your AI tooling and data flows into the scope of the ISMS: the coding agents, the model providers, the prompt and output logs all become assets and vendors your risk process already knows how to handle.

SOC 2

What it is SOC stands for System and Organization Controls, a reporting framework from the AICPA built on its Trust Services Criteria. Type An attestation report written by a licensed CPA firm. Who cares US enterprise and SaaS buyers, where procurement teams treat it as the baseline trust artifact. Link aicpa-cima.com, the body that defines SOC reporting.

SOC 2 is built on five Trust Services Criteria: security (the mandatory "common criteria" that every report covers), and then availability, processing integrity, confidentiality, and privacy, which you include only if they are relevant. A Type I report assesses whether your controls are designed appropriately at a single point in time; a Type II report assesses whether they actually operated effectively over a period, typically three to twelve months.

The output is a detailed report you share under NDA, and its control environment overlaps heavily with ISO 27001. That overlap is why teams selling on both sides of the Atlantic often pursue both and reuse most of the evidence. Auditors increasingly expect your AI vendors and agents to appear inside that control environment, assessed with the same vendor-risk rigour as any other subprocessor.

Governing modern AI

New standards which emerged in response to the new wave of generative AI systems. The first two are complementary; the third extends the same thinking to the autonomous agents now reaching production.

ISO/IEC 42001

What it is The first international management-system standard for artificial intelligence, an AI management system or AIMS, published in December 2023. Type Certifiable, and deliberately structured like ISO/IEC 27001 so the two interlock. Who cares Organisations that build or deploy AI and want a credible governance story. Link iso.org/standard/81230, the first international AI management standard.

If you already run a 27001 ISMS, 42001 will feel familiar, because it follows the same management-system skeleton: context, leadership, planning, risk, operational controls, and continual improvement. Its annex of controls targets AI-specific concerns the security standards never anticipated: AI impact assessments, data governance for training and inference, transparency to affected people, human oversight, and managing models across their full lifecycle. It is the responsible-AI counterpart to 27001's security focus. It is still early in its adoption curve, but demand is rising as the EU AI Act and enterprise buyers start asking how, specifically, you govern the AI you ship.

NIST AI Risk Management Framework

What it is The US National Institute of Standards and Technology's AI Risk Management Framework, AI RMF 1.0, released in January 2023, with a Generative AI Profile added in July 2024. Type Voluntary guidance. Who cares US federal agencies and their suppliers, and any team that wants a well-structured vocabulary for AI risk. Link nist.gov, the framework and the Generative AI Profile.

The NIST framework is organised around four functions: Govern (the policy and culture layer that sits across everything), Map (establish the context and identify risks), Measure (analyse, assess, and track those risks), and Manage (act on them and prioritise). It is the working method that pairs naturally with 42001: NIST gives you the language and the day-to-day technique, while 42001 gives you the certifiable system that proves to an outsider you are actually doing it. The Generative AI Profile catalogues the failure modes specific to generative models, such as confabulation, data leakage, and prompt injection.

Singapore IMDA Model AI Governance Framework for Agentic AI

What it is Singapore's Model AI Governance Framework for Agentic AI (MGF-Agentic), launched by the IMDA in January 2026 and updated in May 2026, building on its 2020 Model AI Governance Framework. Type Voluntary guidance; there is nothing to certify against. Who cares Teams deploying AI agents that plan, reason, and act autonomously, and anyone watching where Asia-Pacific AI governance is heading. Link imda.gov.sg, the IMDA factsheet for the agentic-AI framework.

It is the first national framework written specifically for agentic systems, and it is organised around four dimensions: bounding the risks an agent is allowed to take, keeping meaningful human accountability for what the agent does, putting technical controls and processes around the agent's actions, and giving end users their own responsibilities. It targets the failure modes unique to agents: automation bias, multi-agent interactions, and third-party agents acting on your behalf. If your product gives an LLM the ability to take actions, it is the most specific checklist currently available, and it complements the agentic workflow patterns we cover elsewhere.

Securing the software

Here are popular engineering practices that help companies achieve high standards.

OWASP

What it is The Open Worldwide Application Security Project, a non-profit that publishes vendor-neutral application-security guidance. Type Reference standards and tooling. Who cares Your own engineers, your security team, and the penetration testers your customers hire. Link OWASP Top 10, the Top 10 for LLM Applications, and the ASVS.

OWASP is best known for the Top 10, its list of the most critical web-application security risks, which is widely used as a baseline in security reviews. The more rigorous artifact, though, is the Application Security Verification Standard (ASVS), which provides testable security requirements graded across three levels. For AI teams the directly relevant document is the OWASP Top 10 for LLM Applications, which catalogues risks like prompt injection, insecure output handling, training-data poisoning, and excessive agency. It has become the shared checklist for securing AI features, and it is the technical substance that the control objectives in 27001, SOC 2, and 42001 ultimately depend on.

SLSA

What it is Supply-chain Levels for Software Artifacts, pronounced "salsa," a framework from the Open Source Security Foundation (OpenSSF) for software supply-chain integrity. Type A graded framework; you verify against build levels, there is no central certificate. Who cares Security teams reacting to supply-chain attacks of the SolarWinds and compromised-package variety. Link slsa.dev and the OpenSSF that maintains it.

SLSA v1.0 organises its requirements into tracks, and the Build track defines levels (roughly L0 through L3) that progressively demand a tamper-resistant, provenance-generating, hardened build pipeline. The core idea is verifiable provenance: a signed, machine-checkable record of how an artifact was built and from which source, so whoever consumes it can confirm it was not tampered with along the way. This matters more as AI agents generate and commit code, and as model weights and training datasets become supply-chain artifacts in their own right that deserve the same provenance scrutiny as any dependency.

The impact of AI

AI changes the compliance map in four practical ways. First, model providers become vendors and processors, so the OpenAI or Anthropic endpoint you call is now a subprocessor that belongs in your vendor-risk register and your data-processing agreements. Second, prompts and logs become regulated data flows: the moment a prompt carries personal data, GDPR and PDPA obligations attach to it, and your retention and access controls have to cover the prompt and output stores too. Third, agents expand both access scope and supply-chain risk, because an autonomous agent with repository access and the ability to run commands multiplies the audit surface and the provenance questions SLSA exists to answer. Fourth, model behaviour creates risks that older security frameworks never named directly, which is exactly the gap the OWASP LLM Top 10, the NIST Generative AI Profile, and ISO 42001 were written to fill.

Putting it in order

The order that works for most teams is:

• Get privacy right regardless of certifications. Government laws do not wait, and the cost of ignoring them is enforcement, so the lawful-basis, data-rights, and breach-notification work starts immediately.

• Start where your buyers are. SOC 2 if you sell into the US, ISO 27001 if you sell into the rest of the world. One of these is usually the first thing enterprise procurement asks for, and it is the foundation everything else reuses.

• Bake OWASP and SLSA into engineering. Wire AppSec testing and build provenance into the pipeline so the controls are continuous.

• Layer AI governance once AI is material. Adopt the NIST AI RMF as your working method first, because it is free and immediately useful, then pursue ISO 42001 certification when buyers or regulators start asking for proof. If you ship autonomous agents fold in Singapore's IMDA agentic-AI framework as well.

• Build one control set, map it many ways. Maintain a single crosswalk so evidence collected for one audit serves the others.

Get the foundations and the data handling right before you scale the AI on top of them.