Posts

Navigating AI Standards and Regulations

/in

Note: This post is written with a lot of help from AI, used to summarize the standards mentioned below.

 

Artificial intelligence (AI) is reshaping industries, but it also brings new risks.

From security vulnerabilities to compliance challenges, organizations must balance innovation with responsibility.

New standards were created and newer are emerging to guide this effort, most notably ISO/IEC 42001, ISO/IEC 22989, NIST AI RMF and the EU AI Act.

Together, they define how we should understand, manage, and regulate AI.

 

The Standards: ISO/IEC 42001, ISO/IEC 22989, NIST AI Risk Management Framework (AI RMF)

ISO/IEC 22989 focuses on concepts and terminology. By standardizing the language around AI, it ensures consistency in communication between developers, regulators, and policymakers. It provides a shared foundation for technical and strategic discussions, making it easier to align projects and compliance efforts.

 

ISO/IEC 42001 sets the framework for an Artificial Intelligence Management System (AIMS). As if we didn’t have enough Management Systems (ISMS, CSMS, DRMS, etc.), now we have AIMS.

It provides requirements for organizations to govern AI responsibly throughout its lifecycle.

Much like ISO 27001 for information security, this standard enables organizations to implement repeatable processes, assign roles, manage risks, and continuously improve their AI practices.

In short, ISO/IEC 22989 tells us how to talk about AI, while ISO/IEC 42001 tells us how to manage it.

NIST AI Risk Management Framework (AI RMF) is developed by the National Institute of Standards and Technology.  It gives guidance on managing the risks of AI systems: trustworthiness, safety, fairness, explainability, etc.

NIST also works on “crosswalks” linking the AI RMF to international standards like ISO, OECD guidelines, etc.

 

The Regulation: EU AI Act

The EU AI Act goes beyond voluntary standards. It is a regulation with binding legal requirements for AI systems placed on the EU market.

The Act classifies AI systems by risk:

  • Unacceptable risk systems (e.g., manipulative or exploitative applications) are prohibited.
  • High-risk systems (e.g., AI in healthcare, critical infrastructure, recruitment) must meet strict conformity assessments, documentation, and testing requirements.
  • Limited and minimal risk systems face transparency obligations or no specific restrictions.

Unlike ISO standards, which are voluntary, the EU AI Act will be legally enforced. Non-compliance may lead to heavy fines and product bans.

 

Comparing Standards and Regulation

  • ISO/IEC 22989 provides consistent terminology.
  • ISO/IEC 42001 defines organizational governance for AI.
  • NIST AI RMF guidance on managing the risks of AI systems: trustworthiness, safety, fairness, explainability.
  • EU AI Act imposes legally binding obligations at the product and deployment level.

While ISO and NIST standards are process-driven and supportive, the EU AI Act mandates specific outcomes.

Organizations can use ISO/IEC 42001 to establish governance processes that make compliance with the EU AI Act easier, but certification alone does not replace the legal requirements.

U.S. standards tend to be voluntary or guidance-based, not binding across all states or businesses, unlike the EU AI Act. There is no single federal law with comprehensive AI regulation yet;

instead it’s a patchwork of executive orders, agency actions, state laws, and voluntary standards. The U.S. places strong emphasis on risk management frameworks, public-private collaboration, innovation, and aligning with international standards.

In the U.S. there are some more standards on AI like Center for AI Standards and Innovation (CAISI) and various initiatives and plans for AI systems. Also there are some state laws and regulations which require some large AI model developers to publicly disclose safety protocols and report certain kinds of risk or incidents (California SB 53).

 

Key Risks Introduced by AI

  1. Model drift and performance risk — AI systems degrade over time, causing hidden failures.
  2. Bias and discrimination — Training data can produce unfair outcomes, raising legal and ethical issues.
  3. Lack of explainability — Black-box models hinder audits, accountability, and trust.
  4. Data protection risks — Models may leak or memorize personal data, creating privacy concerns.
  5. Security vulnerabilities — Adversarial attacks, poisoning, and prompt injection threaten system integrity.
  6. Supply chain dependency — Reliance on third-party models introduces hidden weaknesses.
  7. Regulatory non-compliance — Misclassifying risk or skipping assessments can result in fines and reputational damage.

How Standards Address These Risks

  • ISO/IEC 22989 ensures clarity in measurement and reporting.
  • ISO/IEC 42001 and NIST AI RMF requires lifecycle controls, risk assessments, monitoring, and continuous improvement.
  • EU AI Act mandates transparency, testing, and conformity assessments tailored to specific use cases.

When combined, these frameworks help organizations create trustworthy AI systems while meeting regulatory demands.

 

The Next Level of Compliance

To reach the “next level” of compliance, organizations must integrate voluntary standards and mandatory regulation into one cohesive program:

  1. Adopt common terminology using ISO/IEC 22989 across all teams.
  2. Implement an AI management system aligned with ISO/IEC 42001.
  3. Map AI products against EU risk categories and prepare compliance checklists.
  4. Generate technical evidence such as model cards, data lineage, and test results.
  5. Automate monitoring and incident response to detect model drift and adversarial attacks.
  6. Integrate privacy engineering to ensure alignment with GDPR.
  7. Secure the AI supply chain by tracking third-party components and models.
  8. Prepare for external audits and conformity assessments, leveraging ISO processes as supporting evidence.

Compliance should not be treated as a static checklist. The future of responsible AI lies in continuous monitoring, automated governance, and embedding compliance into MLOps pipelines.

Conclusions

AI standards and regulations are converging to create a new compliance landscape.

ISO/IEC 22989 provides the vocabulary, ISO/IEC 42001 offers governance, and the EU AI Act enforces legal obligations.

Organizations that align with all three will not only reduce risk but also strengthen trust in their AI systems. The next level of compliance means going beyond certification—building AI practices that are transparent, secure, and continuously monitored.

The EU provides a strong, comprehensive, binding regulatory framework for AI with clear risk categories, prohibited uses, and enforcement.

The U.S. currently relies more on existing laws, executive orders, and sectoral regulation, giving more flexibility but less predictability.

For global players, achieving dual compliance is increasingly necessary. The trend suggests U.S. regulation will become stronger over time, potentially drawing from EU models.

 

The post Navigating AI Standards and Regulations first appeared on Sorin Mustaca’s blog.

Policy vs Standard vs Procedure: why, what, how

/in

Ever wondered what the differences between these terms are?

We use them in GRC very often, but we rarely think what they mean. This creates in time some stretching of these concepts, meaning that their meanings overlap to a certain degree.

 

A Policy is a high-level, mandatory statement of principles and intent.
A Standard is a mandatory, specific requirement that defines what is needed to comply with a policy.
A Procedure is a detailed, step-by-step set of instructions on how to implement a standard or fulfill a policy.
Policies set goals, standards define the required outcomes, and procedures provide the detailed roadmap to achieve them, forming a hierarchical structure within an organization.

Policy

What is it
A high-level, broad statement of principles, intent, or requirements designed to guide decisions and achieve outcomes.
Purpose
To establish strategic goals, the intent, to support an organization’s mission, comply with laws, or minimize risk.
Answers
Describes the Why must something be done.
Mandatory
Yes, policies are mandatory and define why must something be done. Because of their generic nature of defining the need and not the implementation, they rarely change and are not negotiable.
Example
An IT Security Policy that states the organization will protect sensitive data from unauthorized access.

Standard 

What is it
A mandatory, specific technical requirement or rule that provides concrete, measurable details for policy compliance.
Purpose
To provide the specific rules, metrics, and technical configurations necessary to make policies meaningful and effective.
Answers
Describes the What must be done to implement the policy.
Mandatory
Yes, standards are mandatory and define specific configurations, timelines, or processes. Because of their specific nature of describing the implementation, they can change because of the dynamic of the specific industry.
Example
An IT Security Standard for Encryption data that is required by a Policy that states that the organization will protect sensitive data from unauthorized access. The standard will define what encryption algorithm will be used, when to use it, what kind of data should be encrypted and who is responsible for implementing it.

Procedure

What is it 
A detailed, step-by-step set of instructions outlining the specific actions to be performed to implement a standard or policy. 

Purpose
To provide clear, actionable guidance on how to execute a task and to ensure consistent, repeatable measurable results. It also defines Who should do something and When.

Answers
Describes the How must something be done that is defined by the standard or directly by the policy.
Mandatory
Yes, procedures are mandatory and specify the exact steps an employee must follow. Because they define detailed requirements on how to implement a standard or policy, they change as needed. 

Example
A step-by-step instruction set on how to encrypt data in a database, a hard drive, emails and other types of information.

How They Work Together (Hierarchically) 

  1. Policy (The Goal): The high-level statement of intent, like an IT security policy.
  2. Standard (The Rule): The specific requirements that support the policy, such as password complexity standards.
  3. Procedure (The Steps): The detailed instructions on how to follow the standard, like the steps to change a password.
This top-down structure ensures that policies are actionable and that goals are met through consistent, documented processes.

What about Guidelines?

Guidelines: are at the bottom, offering recommended and flexible support for the entire framework. They are optional and usually accompany procedures and standards.

Read more

The post Policy vs Standard vs Procedure: why, what, how first appeared on Sorin Mustaca’s blog.