AI governance frameworks

The EU AI Act is binding law, not a methodology. It sorts AI systems into risk tiers — prohibited, high-risk, limited-risk and minimal-risk — and attaches obligations accordingly. High-risk systems carry the heaviest load: risk management, data governance, technical documentation, logging, human oversight, accuracy and robustness requirements, and conformity assessment before market placement. Because obligations attach to a system's use rather than its architecture, the practical first step is a defensible inventory that classifies every AI use case. Tooling matters most for classification, evidence collection and keeping technical documentation current as systems change.

The NIST AI Risk Management Framework is voluntary in the United States and organises AI risk work into four functions: Govern, Map, Measure and Manage. Govern is cross-cutting, establishing policy, accountability and risk tolerance. Map builds context — intended purpose, stakeholders, potential impacts. Measure applies quantitative and qualitative assessment of bias, explainability, security and performance. Manage allocates resources, implements controls and maintains post-deployment monitoring. Its strength is methodology: it tells you how to reason about AI risk without prescribing specific controls, which makes it a common backbone under other, more prescriptive regimes.

ISO/IEC 42001:2023 is the first international standard specifying requirements for an AI Management System (AIMS). It follows the familiar ISO management-system pattern — context, leadership, planning, support, operation, performance evaluation, improvement — which means organisations already certified to ISO 27001 will recognise the structure and can often reuse much of the governance scaffolding. Its distinguishing value is that it is certifiable: an accredited body can audit and issue a certificate, which is increasingly what enterprise customers and procurement teams ask for as evidence of responsible AI practice.

The GDPR predates the current AI wave but governs a great deal of it, because most AI systems process personal data. The provisions that bite hardest on AI are the lawful-basis requirement, purpose limitation and data minimisation, the transparency obligations, and Article 22's restrictions on solely automated decision-making with legal or similarly significant effects. Data protection impact assessments are frequently the existing process AI governance gets bolted onto, which is why so many privacy platforms have extended into AI governance.

Colorado's SB 24-205 is the most significant US state-level AI law to date, targeting algorithmic discrimination in consequential decisions — employment, lending, housing, education, healthcare and insurance among them. It imposes duties of reasonable care on both developers and deployers of high-risk AI, including impact assessments, risk management programs, disclosure to affected consumers and notification to the state attorney general when discrimination is discovered. It is a useful bellwether: its structure echoes the EU AI Act's risk-tier logic and several other states have drafted along similar lines.

SOC 2 is an attestation, not a regulation: an independent auditor reports on controls relevant to the Trust Services Criteria of security, availability, processing integrity, confidentiality and privacy. It says nothing about AI specifically, but it is the compliance artefact most B2B buyers ask for first, and it is the reason so many compliance-automation platforms became the on-ramp for AI governance. In practice organisations extend an existing SOC 2 control set to cover AI systems rather than starting a separate program.

HIPAA governs protected health information in the United States, and its Privacy and Security Rules constrain how AI systems in healthcare may access, process and disclose patient data. AI-specific pressure points include using PHI for model training, ensuring de-identification actually holds against re-identification attacks, vendor business associate agreements covering model providers, and audit logging sufficient to reconstruct who saw what. Tooling here tends to emphasise data-layer controls and access governance rather than model documentation.

The EU's Digital Operational Resilience Act targets ICT risk in the financial sector, including the third-party providers financial entities depend on. Its relevance to AI is operational resilience and concentration risk: if a bank's critical process depends on an external model provider, DORA's requirements around ICT risk management, incident reporting, resilience testing and third-party oversight apply. It is increasingly cited alongside the EU AI Act by financial-services buyers evaluating AI vendors.

NIS2 raises baseline cybersecurity requirements across essential and important entities in the EU, covering risk management measures, supply-chain security, incident reporting and management accountability. Where AI systems form part of critical operations, NIS2's security and supply-chain obligations extend to them, which is why AI security and governance vendors serving European critical infrastructure increasingly map to it.