AI governance is not one rulebook. A framework can help an organization think about risk. A standard can establish a structured management system. A law can create obligations that apply because of jurisdiction, role, sector, system, or market activity. These instruments may overlap, but they are not interchangeable.
That distinction becomes important when an AI assistant moves from answering questions to influencing decisions or taking external actions. A team may say, “We follow an AI framework,” while a risk owner needs to ask a different question: Which requirements actually apply to this system, which controls address them, who owns those controls, what evidence shows that they work, and what risk remains?
Consider a fictional internal document assistant. At first, it only answers employees' questions using approved internal material. Later, it receives narrowly scoped tools that can update a business record or send a message. The model may not have changed, but the governed system has. The consequences of errors, the authorization boundary, the evidence required, and the level of human oversight can all change.
The object of governance is the real AI system and its use, not merely the model name.
Educational note: this article explains governance concepts and selected current instruments for learning purposes. It is not legal advice, a certification statement, or a guarantee that a deployment is compliant or safe.
- What these instruments actually are
- Frameworks vs standards vs laws
- NIST AI RMF as a risk-management framework
- ISO/IEC 42001 as a management-system standard
- OECD and UNESCO: principles and normative guidance
- AI laws: what changes when obligations are binding
- How to combine the instruments without creating bureaucracy
- Worked example: turning instruments into controls
- Implementation in practice
- Common mistakes
- FAQ
- References & Further Reading
- Summary
01
What These Instruments Actually Are
It is tempting to place every AI governance document into one mental bucket called “regulation.” That is where many governance programs become confused.
Think about driving. A driving guide can explain how to think about safe driving. A vehicle standard can define technical expectations for a vehicle or management process. A traffic law can impose obligations that you can be legally required to follow. One does not become the other merely because all three talk about safety.
The same distinction helps with AI governance. In professional practice, you may encounter at least five different kinds of instruments:
| Instrument | Primary purpose | Typical force | Governance question |
|---|---|---|---|
| Framework | Provides an organized way to identify and manage risks. | Often voluntary unless adopted by another requirement. | How should we structure our thinking and risk process? |
| Management-system standard | Defines a repeatable organizational management system. | Usually voluntary unless made contractual or otherwise required. | How do we establish, operate, maintain, and improve governance? |
| Principles or recommendation | Expresses values, policy direction, or internationally shared expectations. | Generally non-binding unless translated into another instrument. | What outcomes and values should our AI governance protect? |
| Law or regulation | Creates enforceable legal duties within its scope. | Binding when applicable. | What must we do, for whom, where, by when, and under what legal conditions? |
This distinction is practical rather than academic. The question “Are we compliant with NIST?” is usually badly framed because the NIST AI RMF is intended for voluntary use. A better question is whether the organization has chosen to use it, and how it is being operationalized. Conversely, asking whether an AI law is “a useful framework” can obscure the fact that applicable legal obligations are not optional simply because a team prefers another governance method.
For example, NIST describes AI RMF 1.0 as a voluntary resource for organizations that design, develop, deploy, or use AI systems. NIST also states that AI RMF 1.0 is currently being revised.
ISO/IEC 42001:2023, by contrast, is an international AI management-system standard specifying requirements for establishing, implementing, maintaining, and continually improving an Artificial Intelligence Management System.
You are reviewing a governance document and need to determine whether it is guidance, a management-system requirement, a contractual expectation, an internal control, or a legal obligation.
02
Frameworks vs Standards vs Laws: The Boundary That Matters
The most useful way to compare governance instruments is not by asking which one is “best.” Ask what decision each instrument is designed to support.
| Instrument | What it helps answer | What it does not automatically prove | Useful evidence |
|---|---|---|---|
| NIST AI RMF | How should AI risks and trustworthiness considerations be organized? | That the organization is legally compliant or that a particular system is safe. | Risk records, evaluations, governance decisions, test evidence, monitoring. |
| ISO/IEC 42001 | How can an organization establish and improve an AI management system? | That every AI use is inherently safe or lawful. | Policies, objectives, risk treatment, records, internal review, corrective actions. |
| OECD AI Principles | What values and policy direction should guide trustworthy AI? | That a deployment meets every local legal requirement. | Policy commitments, impact considerations, governance principles, decision rationale. |
| EU AI Act | What legally binding obligations apply to a covered AI system, role, and activity? | That complying with one requirement makes the entire system risk-free. | Required records, assessments, controls, notices, technical documentation, oversight, and other applicable evidence. |
A mature governance program often uses several layers at once. A company may use a framework to organize risk work, a management-system standard to structure its overall governance program, internal policies to establish decision rights, and applicable laws to determine legal duties. None of those layers removes the need to understand the actual AI system.
“Standard” does not automatically mean “law.” A standard can become highly important through contracts, procurement rules, sector expectations, internal policy, or regulatory recognition. But its legal effect depends on the context. Do not turn “a standard says X” into “the law requires X” without checking the applicable legal source.
The same discipline applies in the other direction. A law may establish an obligation at a high level while leaving implementation choices to organizations, technical standards, codes of practice, or supervisory guidance. A governance team still has to translate the requirement into an operational control and then demonstrate that the control works.
Someone asks, “Which framework should we use?” before identifying the legal perimeter, business decision, governance objective, and evidence the organization actually needs.
03
NIST AI RMF: A Practical Risk-Management Framework
The NIST AI Risk Management Framework, or AI RMF, is designed to help organizations manage AI risks and incorporate trustworthiness considerations into the design, development, use, and evaluation of AI systems. NIST describes the framework as voluntary, rights-preserving, non-sector-specific, and use-case agnostic.
The core framework is organized around four functions: Govern, Map, Measure, and Manage. Its companion Playbook provides suggested actions and practices, but NIST explicitly characterizes both as resources for voluntary use.
Imagine a school that wants to make field trips safer. “Govern” is deciding who is responsible. “Map” is understanding the trip, the students, the route, and the hazards. “Measure” is checking whether safety measures actually work. “Manage” is deciding what to change when a problem appears. The framework does not drive the bus; it organizes the work around the bus.
For an AI governance practitioner, the value of the framework is therefore not a decorative label. It is a way to create a repeatable conversation:
- Who has authority over this AI use?
- What system, context, users, affected people, and foreseeable harms are in scope?
- Which risks can be evaluated, measured, or tested?
- Which risks need treatment, acceptance, transfer, avoidance, or escalation?
- What evidence will demonstrate that the chosen controls are operating?
NIST also provides a Generative AI Profile, NIST AI 600-1, released on July 26, 2024. That profile identifies risks and suggested actions specific to generative AI and is intended to work alongside the broader AI RMF.
There is an important current-status caveat for anyone writing a governance policy today: NIST states that AI RMF 1.0 is being revised. That means an organization using AI RMF 1.0 should record the version it adopted and periodically check whether the framework itself has changed.
Risk: A company says “we follow NIST” but cannot identify how the framework changed an actual deployment decision.
Control: Map selected AI RMF outcomes or activities to named internal controls, owners, test methods, escalation paths, and review dates.
Evidence: Completed risk assessment, evaluation results, approval record, monitoring record, and versioned governance decision.
Remaining risk: A structured process can still miss an emerging hazard or misjudge an impact; the framework improves discipline but does not eliminate uncertainty.
You need a common vocabulary for AI risk management and a practical way to connect governance decisions with evaluation and monitoring work.
04
ISO/IEC 42001: From Individual Controls to an AI Management System
ISO/IEC 42001:2023 is an international standard for an Artificial Intelligence Management System, or AIMS. ISO describes it as specifying requirements for establishing, implementing, maintaining, and continually improving an AIMS within an organization.
The important difference is the organizational lens. A risk framework helps organize risk thinking; a management-system standard asks whether an organization has an operating management system around the subject.
A recipe tells you how to make one meal. A restaurant management system is different: it covers menus, purchasing, hygiene, staff roles, quality checks, incident handling, and continuous improvement. ISO/IEC 42001 is much closer to the second idea.
That distinction matters because AI governance fails when organizations treat it as a one-time approval exercise. A management system encourages recurring activities: defining objectives, assigning responsibilities, maintaining documented processes, assessing risks, reviewing performance, and taking corrective action.
ISO also makes an important certification distinction. ISO itself does not perform certification or issue certificates. Certification to management-system standards is performed by independent certification bodies, and certification is not the only way to demonstrate conformity. ISO currently states that certification for ISO/IEC 42001 is voluntary.
That leads to a governance lesson that is frequently missed: an ISO/IEC 42001 certificate is evidence about the assessed management system, not a universal statement that every AI system the organization operates is safe, fair, lawful, or suitable for every purpose.
Risk: Leadership interprets an AI management-system certification as proof that every production AI use is safe.
Control: Keep system-level risk assessments, deployment-specific approvals, evaluation results, and monitoring separate from organization-level management-system evidence.
Evidence: Certification or audit records where applicable, plus deployment-level controls and test evidence.
Remaining risk: A well-run management system can still approve an unsuitable AI use if the underlying assessment or business decision is wrong.
The most productive way to use ISO/IEC 42001 is therefore not as a badge on a slide. Use it to build organizational muscle: ownership, process discipline, records, review, corrective action, and continual improvement.
You need to move from ad hoc AI approvals toward a repeatable organization-wide management system with documented accountability and continual improvement.
05
OECD and UNESCO: Principles Are Not the Same as Controls or Laws
Not every important AI governance instrument is a technical control framework or a statute. International principles can influence policy, procurement, organizational values, and the way governments and companies interpret responsible AI.
The OECD AI Principles were adopted in 2019 and updated in 2024. OECD describes them as the first intergovernmental standard on AI and says they provide practical and flexible guidance built around five values-based principles and five recommendations.
The 2024 update responded to developments including generative AI and addressed topics such as privacy, intellectual property, safety, and information integrity more directly.
UNESCO's Recommendation on the Ethics of Artificial Intelligence, adopted in 2021, is another important global instrument. UNESCO describes it as a global standard-setting recommendation centered on human rights and dignity and covering areas such as ethical impact assessment, data policy, gender, education, health, social well-being, and environmental concerns.
These instruments are valuable because governance is not just a technical exercise. A system can be technically robust and still create serious human or social consequences. Principles help organizations ask whether an AI use is appropriate, beneficial, inclusive, transparent, or respectful of human rights and democratic values.
A principle such as “respect human rights” is important but does not operate like a technical control. A governance practitioner has to translate it into decisions: which uses need impact assessment, who evaluates affected groups, what evidence is reviewed, how people can contest a decision, and what happens if harm is discovered.
That translation step is where governance becomes operational.
Values are not self-enforcing. Governance turns values into decision criteria, controls, evidence, and remedies.
You need to connect responsible-AI principles to organizational decisions without pretending that a principle statement is itself a control.
06
AI Laws: What Changes When Obligations Are Binding
The defining difference with a law or regulation is not that it is “more detailed.” It is that applicable legal obligations have legal force within their scope. The scope still matters: jurisdiction, role, business activity, system type, sector, use case, affected people, and timing can all influence applicability.
The European Union's AI Act is a useful example because it establishes a risk-based legal framework and distinguishes obligations according to categories and roles. It is binding EU legislation rather than a voluntary governance framework. The current consolidated version incorporates amendments made in 2026.
As of the current 2026 text, the AI Act's main application date is 2 August 2026, while some provisions apply earlier or later. The current consolidated text specifies, among other dates, 2 February 2025 for Chapters I and II with certain provisions deferred to 2 December 2026, 2 August 2025 for specified governance and general-purpose-AI provisions, 2 December 2027 for certain stand-alone high-risk systems under Article 6(2) and Annex III, and 2 August 2028 for certain high-risk systems associated with Annex I.
This is exactly why publishing a generic statement such as “the EU AI Act takes effect in 2026” is not enough for a governance decision. A practitioner must identify which provision, role, system category, and application date are relevant.
The Commission also states that Article 50 transparency obligations apply from 2 August 2026. Those rules concern specified situations including informing people that they are interacting with AI and certain requirements concerning AI-generated or manipulated content. The precise scope and exceptions depend on the provision and guidance.
For governance practitioners, three habits are essential when reading an AI law:
- Check the legal source itself. Do not rely only on a blog post, vendor summary, or slide deck.
- Check the version and date. Laws can be amended, implementation dates can move, and guidance can be updated.
- Check applicability. Determine whether the organization's role and actual system fall within the provision.
Risk: A team copies a regulatory deadline from a secondary article and treats it as universally applicable.
Control: Maintain a regulatory register with source, provision, applicability rationale, effective date, responsible owner, and last verification date.
Evidence: Link to the authoritative legal text, recorded applicability assessment, legal or compliance review, and implementation record.
Remaining risk: A legal register can become stale, so it needs ownership and periodic review whenever laws or official guidance change.
The same approach applies outside the EU. A governance program should never assume that one jurisdiction's AI rules describe the obligations everywhere else.
You are making an actual compliance decision. Move from “what does the framework recommend?” to “which legally applicable requirement governs this system and role?”
07
How to Combine a Framework, a Standard, and a Law
You generally do not want three disconnected governance programs. You want one governance process with different instruments serving different purposes.
A useful architecture is:
↓
Determine applicable obligations
↓
GOVERNANCE POLICY + DECISION RIGHTS
↓
FRAMEWORK / MANAGEMENT SYSTEM
↓
RISK + IMPACT ASSESSMENT
↓
OPERATIONAL CONTROLS
↓
TESTS + EVIDENCE + MONITORING
↓
REASSESSMENT / CORRECTIVE ACTION
This is not a prescribed legal architecture from any one source. It is a practical governance pattern that separates the question of what must be done from how the organization structures the work and from how the control is actually implemented and checked.
For example, a law might require transparency in a particular circumstance. An internal policy may state that transparency obligations must be evaluated before production release. A framework may provide the risk-management structure for the assessment. An implementation control may require a particular notice to be present. A test may verify that the notice appears under the relevant conditions. Monitoring may detect when the system changes.
That chain is far stronger than storing five PDFs in a governance repository and labeling the organization “AI compliant.”
A fictional organization decides that high-impact AI uses require named business ownership, documented risk assessment, pre-production evaluation, approval evidence, monitoring, and formal reassessment after material changes. The organization uses NIST AI RMF to structure risk-management conversations and ISO/IEC 42001 concepts to support an enterprise management system. Where an applicable law imposes additional requirements, those legal obligations are mapped separately rather than assumed to be covered by either framework.
Your organization has several governance instruments and the main problem is duplication, unclear ownership, or uncertainty about which document controls a decision.
08
Worked Example: Turning Instruments into Real Governance Decisions
The following scenario is fictional and is included only to demonstrate governance reasoning.
Northstar Service Desk has an internal assistant that answers questions about approved company documents. At launch it has no tools that change records. Six months later, the business proposes two tools: one to update a supplier contact record and one to send a notification email to a designated group.
The organization should not simply say, “The model is the same, so the governance status is the same.”
The new capabilities create additional questions:
- What exactly can the tools change?
- Which users are authorized?
- Can the assistant act without confirmation?
- What happens if the model identifies the wrong supplier record?
- Which actions require approval?
- What evidence is retained before and after an action?
- What happens when the model, tool, permissions, or data source changes?
Now map the governance instruments.
| Layer | Question | Northstar decision | Evidence |
|---|---|---|---|
| Legal perimeter | Which legal duties apply? | Identify relevant jurisdictions, roles, system characteristics, and sector rules. | Applicability assessment. |
| Risk framework | What can go wrong? | Assess incorrect answers, incorrect tool targeting, unauthorized action, and communication errors. | Risk register and evaluation plan. |
| Management system | Who owns the process? | Name system owner, risk owner, control operator, approver, and escalation path. | Roles, policy, review record. |
| Operational control | How is the risk reduced? | Restrict tool scope, require confirmation for defined actions, validate target records, log actions, and test failure behavior. | Control tests and logs. |
Notice what this record does not say. It does not say “NIST approved.” It does not say “ISO certified.” It does not say “legally compliant.” It records an internal governance decision and the evidence supporting that decision.
Risk: The organization evaluates only the underlying model and ignores the tools, permissions, data flows, users, and downstream effects.
Control: Define the AI system boundary for the actual use case, including model provider, application, retrieval, tools, operators, users, and affected people where relevant.
Evidence: System inventory, architecture description, role map, data-flow notes, tool inventory, and deployment approval.
Remaining risk: Boundaries can be incomplete or change over time, especially when vendors, models, tools, and data sources are updated independently.
You need to demonstrate that governance instruments changed a real system decision rather than merely appearing in a policy library.
09
Implementation in Practice: A Proportionate Governance Workflow
A governance program becomes practical when the sequence is clear. The following is an original implementation pattern, not a mandatory checklist from any single framework or law.
Step 1 — Define the system. Record what the AI system actually includes. Do not stop at the model. Capture the application, relevant model providers, retrieval or data sources, tools, permissions, operators, users, and affected people where those boundaries matter.
Step 2 — Determine the legal perimeter. Ask which jurisdictions, sectors, roles, activities, and system characteristics may trigger legal requirements. Record the legal source and the rationale rather than merely adding a regulation's name to a checklist.
Step 3 — Choose the governance instruments. Use a framework when it improves risk organization. Use a management-system standard when the organization needs structured governance processes. Use principles to inform policy and values. Apply binding legal obligations independently.
Step 4 — Translate obligations into controls. “Human oversight required” is not enough. Specify what triggers review, who performs it, what information the reviewer receives, when the reviewer can stop or override the process, how the system enforces the boundary, and how the control is tested.
Step 5 — Create evidence while building. Do not wait until an audit. Evidence should emerge from the operating process: risk decisions, evaluation results, approval records, configuration records, test outcomes, monitoring results, incidents, exceptions, and corrective actions.
Step 6 — Reassess after change. A governance decision is not permanently valid merely because the model has not changed. Changes to retrieval sources, prompts, permissions, tool behavior, data, users, downstream systems, business process, or law can change risk.
Step 7 — Preserve residual risk. Good governance does not require pretending that uncertainty has disappeared. Record what remains unresolved, who accepted or escalated it, and what monitoring will detect if the risk changes.
Northstar decides that informational answers can be produced automatically, while external messages and record changes require a stronger action boundary. The organization therefore assigns a business owner, separates read and write permissions, evaluates wrong-target cases, records action evidence, and establishes a change trigger for reassessment. The governance program does not eliminate model uncertainty; it reduces the blast radius of that uncertainty.
The strongest governance evidence is generated by the control operating, not by the existence of a policy describing the control.
You need a repeatable lifecycle from legal assessment to production monitoring without creating a separate bureaucracy for every framework.
10
Common Mistakes
Mistake 1 — Calling every governance instrument a regulation.
Cause: Similar vocabulary appears across frameworks, standards, policies, and laws.
Consequence: Teams cannot tell what is mandatory and what is adopted voluntarily.
Correction: Add an explicit instrument-type field to the governance register.
Mistake 2 — Treating NIST as a certification or legal compliance badge.
Cause: “We use NIST” is easier to communicate than explaining the actual risk process.
Consequence: Stakeholders may assume legal compliance or independent assurance where neither exists.
Correction: Record how selected framework practices affect decisions and what evidence supports them. NIST identifies AI RMF as voluntary.
Mistake 3 — Treating ISO/IEC 42001 certification as proof that every AI use is safe.
Cause: Certification language sounds broader than the specific management system being assessed.
Consequence: Deployment-level risks can disappear from executive attention.
Correction: Keep organizational management-system evidence and individual system-level evidence distinct. ISO states that it does not itself certify organizations and that ISO/IEC 42001 certification is voluntary.
Mistake 4 — Using a framework as a substitute for a legal applicability assessment.
Cause: Framework checklists are easier to operationalize than legal analysis.
Consequence: A team can produce excellent risk records and still miss a binding requirement.
Correction: Maintain a separate legal-perimeter assessment with authoritative source references.
Mistake 5 — Copying a regulatory deadline from an old article.
Cause: AI regulation is moving quickly and secondary sources are often written for an earlier version.
Consequence: The organization schedules work against the wrong date.
Correction: Verify the current consolidated legal text and record the date on which it was checked. The EU AI Act, for example, has received 2026 amendments affecting its application timetable.
Mistake 6 — Assuming the vendor's documentation equals system-level assurance.
Cause: Vendor materials often describe the model or service, while the organization's deployment adds application logic, data, users, permissions, and business processes.
Consequence: Risks introduced by the deployment remain untested.
Correction: Map provider claims to the exact system boundary and independently test what matters for the use case.
Mistake 7 — Treating human approval as meaningful oversight simply because a button exists.
Cause: “Human in the loop” is used as a label rather than an evaluated control.
Consequence: Reviewers may approve without enough information, time, authority, or ability to intervene.
Correction: Define the approval trigger, reviewer competence, information shown, authority to reject, escalation process, and evidence of the review.
Mistake 8 — Never revisiting the governance decision.
Cause: Approval is treated as a project milestone rather than a lifecycle activity.
Consequence: A system can materially change while retaining an obsolete approval.
Correction: Define explicit reassessment triggers for model changes, data changes, new tools, permission changes, business-process changes, incidents, and legal changes.
You are reviewing an AI governance program that looks mature on paper but produces weak evidence about actual operation.
11
❓ FAQ
No. A framework generally provides a structured approach to governance or risk management, while an applicable law creates binding legal obligations. A framework can help an organization operationalize governance, but it does not replace legal applicability analysis.
A voluntary framework can still provide substantial operational value. NIST AI RMF offers a structured way to organize governance, context, measurement, and risk-management activities. The important point is to document how your organization chose to use it rather than presenting voluntary adoption as a legal obligation. NIST currently states that AI RMF 1.0 is being revised.
No. Certification concerns conformity of a management system to the applicable standard requirements. It does not establish that every AI system is safe, lawful, suitable for every context, or free from residual risk. ISO states that ISO/IEC 42001 certification is voluntary and is performed by independent certification bodies, not by ISO itself.
No. Applicability depends on the Act's scope, the role involved, the characteristics and use of the AI system, and the relevant provisions and dates. The Act uses a risk-based structure and contains different obligations and application timelines. The current consolidated text should be checked when making a real compliance decision.
Treat them as different layers. Determine legal obligations first, use internal policy to establish decision rights, use a framework or management-system standard to structure governance, translate requirements into operational controls, test those controls, retain evidence, and reassess the system as it changes.
12
🔗 References & Further Reading
- NIST — AI Risk Management Framework — primary source for AI RMF 1.0, its intended voluntary use, current framework status, and related resources.
- NIST — AI RMF Resources — primary source listing AI RMF 1.0, the Generative AI Profile, and related materials.
- ISO/IEC 42001:2023 — Artificial intelligence — Management system — primary ISO source for the standard's status and purpose.
- ISO — Certification — primary source clarifying that ISO itself does not perform certification.
- OECD — AI Principles — primary source for the principles and their 2024 update.
- UNESCO — Recommendation on the Ethics of Artificial Intelligence — primary source for the recommendation's scope and normative framing.
- EUR-Lex — Regulation (EU) 2024/1689, Artificial Intelligence Act — primary legal source.
- EUR-Lex — Current consolidated AI Act text — useful for checking the amended application timeline and current consolidated provisions.
- European Commission — Enforcement framework of the AI Act — current first-party explanation of enforcement and application timing.
- European Commission — Guidelines on transparency obligations — current implementation guidance for the AI Act's Article 50 transparency obligations.
Framework, standard, organization, and legal names remain the property of their respective owners.
13
📝 Summary
• A framework organizes governance thinking and risk-management work.
• A management-system standard structures repeatable organizational governance.
• Principles establish values and policy direction, but still need operational translation.
• A law creates binding obligations when its scope applies; it cannot be replaced by choosing a favorite framework.
• A governance program becomes credible when policy becomes a control, the control produces evidence, and the remaining risk is visible to a named owner.
• The real test of AI governance is not how many frameworks are named. It is whether the organization can explain who decided, why the decision was made, how the safeguard works, what evidence supports it, and what happens when circumstances change.
Until the next installment, keep one question at the center of AI governance:
“What obligation or risk are we addressing, what control actually operates, and what evidence would convince an independent reviewer?”
Comments
Post a Comment