What Is AI Governance, and How Do You Run It Continuously?

AI governance is the set of policies, roles, controls and evidence an organization uses to decide which AI systems it runs, how they may be used and whether their controls keep working. Running it continuously means those decisions stay open for as long as each system is in use. A change to a model, a data source, a supplier or a use case reopens the assessment, and every control around the system is tested on a schedule with its evidence kept.

I lead AI at DigitalXForce, and the gap I see most often sits between the policy and the system. The policy is approved once, while the models, prompts, suppliers and agents under it can change every month. This page defines the discipline, walks through its lifecycle, sets it against the frameworks and laws that shape it, and explains what makes it continuous.

What does AI governance cover?

AI governance covers every AI system the organization builds, buys or uses, including AI embedded in software from suppliers and generative AI tools that staff use on their own. For each system, it decides who owns it, what it may be used for, which data it may reach, which rules apply to it, how it is tested and monitored, and who may stop it.

It has 4 working parts.

• Policies say what the organization allows, such as approved uses, prohibited uses and rules for data.
• Roles say who decides, including the executive accountable for AI, the owner of each system and the people assigned to oversee it.
• Controls turn each policy into something that can be checked, such as an approval before production, an access limit or a monitoring threshold.
• Evidence shows that each control operated, with its source and its date.

A policy with no controls is a statement of intent, and controls with no evidence cannot be shown to a board or a regulator. A written policy for staff use of public AI tools is often the first piece in place, and A Workplace Policy for Public AI Tools sets one out.

What is AI risk management, and how does it relate to AI governance?

AI risk management is the part of AI governance that identifies, measures and treats the risks each AI system poses to people, the organization and society. NIST’s AI Risk Management Framework, AI RMF 1.0, organizes that work into 4 functions: Govern, Map, Measure and Manage. NIST describes Govern as a cross-cutting function that informs and runs through the other 3, and it says risk management should be continuous, timely and performed throughout the AI system lifecycle.

The difference is one of scope. Risk management asks what could go wrong with a system and what to do about it. Governance adds the organizational decisions around that work: who is accountable, which systems are allowed at all, how the answers are recorded and how the organization proves the controls still work.

Which frameworks and laws shape AI governance?

Five public sources shape AI governance programs, and each plays a different role.

NIST released the AI RMF 1.0, published as NIST AI 100-1, on 26 January 2023, for voluntary use. It lists the characteristics of trustworthy AI as valid and reliable, safe, secure and resilient, accountable and transparent, explainable and interpretable, privacy-enhanced, and fair with harmful bias managed. NIST’s page says the AI RMF 1.0 is being revised as part of the White House AI Action Plan, so programs built on it should expect a new version.

NIST published NIST AI 600-1, the Generative Artificial Intelligence Profile, in July 2024 as a companion to the AI RMF. It defines 12 risks that are unique to or made worse by generative AI, from confabulation to information security and value chain and component integration. Its suggested actions focus on 4 considerations: governance, content provenance, pre-deployment testing and incident disclosure.

ISO/IEC 42001:2023, published in December 2023, specifies requirements for establishing, implementing, maintaining and continually improving an AI management system, as ISO describes it. It is a management system standard built on the Plan, Do, Check, Act cycle, the same kind of standard as ISO/IEC 27001 is for information security.

The EU AI Act, Regulation (EU) 2024/1689, is law. It entered into force on 1 August 2024 and sorts AI systems into 4 levels of risk, with obligations that grow with the risk. Its dates changed in 2026 under the AI Omnibus, and the section on dates below gives them as the European Commission now states them.

The OECD AI Principles were adopted in May 2019 and updated in May 2024. The OECD notes that the European Union, the Council of Europe, the United States and the United Nations use its definition of an AI system and of the AI lifecycle in their own legislative and regulatory frameworks and guidance, which makes that definition a useful common reference when rules from several jurisdictions apply.

What is the AI governance lifecycle?

The lifecycle has 7 stages, and each one leaves evidence the next one depends on. The table maps each stage to an outcome in the NIST AI RMF 1.0 and to the EU AI Act provision that applies to high-risk systems.

I would start with stage 1, because every other stage depends on it. An organization cannot classify, assess or monitor a system it does not know it runs, and AI now often arrives inside ordinary software updates instead of through a formal project. ISO/IEC 42001 does not appear as a column because its clause text is sold by ISO. ISO describes the standard as an integrated approach to managing AI, from risk assessment to the treatment of risks, so it frames the whole table instead of mapping to one row.

How should AI systems be classified by risk?

Classify each system twice: once against the law that applies to it, and once against the organization’s own risk tolerance.

The EU AI Act sets 4 levels, as the European Commission describes them. Unacceptable risk covers the practices the Act prohibits outright, which the Commission now lists as 9, with the last of them applying from 2 December 2026. High risk covers uses that can seriously affect health, safety or fundamental rights, such as AI in critical infrastructure, education, employment, access to essential services, law enforcement, migration and the administration of justice, and it carries strict obligations before such a system can be placed on the market. Transparency risk covers systems such as chatbots and generative AI, whose users must be told they are dealing with a machine or whose output must be identifiable. Minimal or no risk covers most AI systems in use in the EU, according to the Commission, such as spam filters, and the Act adds no rules for it.

The organization’s own tier adds what the law does not ask. It usually weighs the sensitivity of the data a system can reach, how much the system can do on its own and how much the business depends on it. NIST’s AI RMF asks for the same thing in MAP 1.5, where risk tolerances are determined and documented, and in MAP 2, where each system is categorized. The classification under the Act stays the organization’s decision, made with its counsel, and no tool can make it on the organization’s behalf.

When do the EU AI Act’s obligations apply after the AI Omnibus?

The European Commission’s pages give these dates, taking into account the AI Omnibus, which the AI Act Service Desk calls the Digital Omnibus on AI.

• The Act entered into force on 1 August 2024.
• The prohibited practices and the AI literacy obligations have applied since 2 February 2025.
• The governance rules and the obligations for general-purpose AI models have applied since 2 August 2025.
• Most of the remaining rules, including the transparency rules in Article 50, have applied since 2 August 2026, when enforcement also started.
• A 9th prohibition, on AI systems that generate non-consensual sexually explicit content or child sexual abuse material, applies from 2 December 2026, and the AI Omnibus introduced it.
• The rules for high-risk systems in the Annex III areas apply from 2 December 2027.
• The rules for high-risk AI built into products covered by Annex I, such as lifts or toys, apply from 2 August 2028.

The Commission says the AI Omnibus was proposed on 19 November 2025, reached political agreement on 7 May 2026 and entered into force on 27 July 2026. Older guidance that gives 2 August 2026 for all high-risk rules is out of date. The FAQ answer on the EU AI Act gives the same high-risk dates.

How do organizations assess AI use cases before deployment?

Assess the use case before anyone builds or buys the system, and test the system before anyone relies on it. The NIST AI RMF puts most of this work in its Map function.

1. State the intended purpose, the users, the setting and the laws that apply, as MAP 1.1 asks.
2. Classify the system under the Act and under the organization’s own tiers.
3. Record the likely impacts on people and on the organization, with their likelihood and size, as MAP 5.1 asks.
4. Test the system for the risks its tier calls for, and for a generative system, use the 12 risks in NIST AI 600-1 as a checklist.
5. Decide whether it should proceed, as MANAGE 1.1 asks, and record who decided and on which conditions.

For a high-risk system under the Act, Article 9 requires a risk management system that runs across the whole lifecycle, so the assessment is the first entry in a record that keeps growing. Before a formal assessment, a short self-check can show where a program stands, and the AI Readiness Check offers one.

How should human oversight of AI be documented?

Document oversight as a control with named people, clear authority and a record of use. The EU AI Act requires high-risk systems to be designed so that natural persons can oversee them effectively while they are in use (Article 14), and it requires deployers to assign that oversight to people with the necessary competence, training and authority (Article 26). The NIST AI RMF asks, in MAP 3.5, that processes for human oversight are defined, assessed and documented.

A useful oversight record answers 5 questions.

• It names who oversees the system and what training they have.
• It says what they are allowed to do, such as reviewing an output, overriding a decision or stopping the system.
• It says when they are expected to step in, such as for decisions above a threshold or outputs the system marks as uncertain.
• It records each intervention with its date and reason.
• It shows that the stop mechanism was tested, which NIST’s MANAGE 2.4 describes as mechanisms to supersede, disengage or deactivate a system.

How do organizations monitor AI risk after deployment?

Monitor each production system against the expected state written at approval, and keep every reading with its date. NIST’s AI RMF asks that the system’s functionality and behavior are monitored in production (MEASURE 2.4), that risks are tracked over time (MEASURE 3.1) and that post-deployment monitoring plans are implemented (MANAGE 4.1). Under the EU AI Act, providers of high-risk systems run a post-market monitoring system (Article 72), and deployers monitor the system’s operation on the basis of the instructions for use (Article 26).

What to watch depends on the system. For most, it includes performance against the tested baseline, drift in inputs and outputs, access to sensitive data, the actions an agent takes in other systems, and complaints or incidents. Each signal needs a threshold, an owner and a response, or it is only a chart.

How do organizations manage model changes and reassess AI risk?

Treat certain changes as events that reopen the assessment, instead of waiting for the annual review. My test for whether a program is continuous is whether a change like this reopens the assessment without anyone having to remember to ask.

• A supplier changes the model underneath a product, which reopens the tests that depended on the old model’s behavior.
• The system gains a new data source or access to more sensitive data, which reopens the data and privacy review.
• An agent gains new tools or permissions, which reopens its access controls in the same way as for any privileged account.
• The system is used for a new purpose, which can move it into a different tier under the Act.

NIST’s AI RMF asks for change management inside post-deployment monitoring plans (MANAGE 4.1) and for a planned frequency of periodic review (GOVERN 1.5). Article 9 of the EU AI Act asks for the high-risk risk management system to be reviewed and updated regularly. A supplier’s model is a supplier risk as well, and How to Continuously Validate Third-Party Controls sets out how to keep checking a supplier after onboarding. NIST covers the same ground for AI in GOVERN 6 and MANAGE 3, which address risks from third-party software, data and AI.

How do organizations track AI exceptions and remediation?

Keep AI exceptions in the same register as every other control exception. Each one needs a named person who accepted it, a reason, a compensating measure where one exists and an expiry date, and each remediation needs an owner, a due date and a retest.

The NIST AI RMF names the options in MANAGE 1.3, where responses to high-priority AI risks can mitigate, transfer, avoid or accept them, and it asks in MANAGE 1.4 that the negative residual risks are documented. An exception that never expires has quietly become the policy, so the register should show every exception past its date.

How does AI governance connect to existing GRC and to enterprise risk?

AI governance connects to GRC when AI controls sit in the same control library as every other control, and to enterprise risk when AI risks sit in the same register. An AI system is an asset with controls on its data, its model and its use, and a failed AI control should reach the same risk register, the same remediation queue and the same board report as a failed access control.

A common control framework makes the first connection. It lets one AI control, such as an approval before production, answer the NIST AI RMF, ISO/IEC 42001 and the EU AI Act at once. The second connection is the one NIST CSF 2.0 asks for in its Govern function, where cybersecurity risk is part of enterprise risk management, and it applies to AI risk in the same way. How AI governance fits into the wider model is set out in How Continuous Control Assurance (CCA) Fits Into Enterprise Trust, Risk, Security and Compliance Management (TRiSCM™), and which AI measures a board should see is covered in What Cybersecurity Metrics Should Boards See?.

How do organizations map AI regulations across jurisdictions?

Map every obligation once to a shared set of controls, and track each jurisdiction’s dates separately. The EU AI Act is binding law with fixed dates. The NIST AI RMF is voluntary guidance. ISO/IEC 42001 is a management system standard, and the OECD AI Principles supply the definition of an AI system that several jurisdictions share.

Most obligations reduce to the same few controls: an inventory, a classification, an assessment before use, human oversight, monitoring, incident handling and records. When those controls are defined once and mapped to each source, a new law or a new version of the AI RMF becomes a mapping exercise, and the organization does not have to rebuild its program each time.

What does continuous AI governance look like, and how does Continuous Control Assurance (CCA) apply to AI?

Continuous Control Assurance (CCA) uses evidence, monitoring and validation to determine whether controls continue to operate as expected. Applied to AI, it means each AI control has an expected state, evidence read from the system that enforces it, a test on a schedule set by how fast that evidence can change, and a finding with an owner when the test fails. Continuous Control Monitoring (CCM) monitors conditions, evidence and signals associated with controls, and for AI that includes the inventory, the models’ behavior and the access each system holds.

A continuous program can answer these questions on any given day, with evidence.

• It can say how many AI systems are running, and how many of them have an owner, a classification and an approval.
• It can say which production systems are monitored, and when each was last read.
• It can say which systems changed since their last assessment, and whether the change reopened it.
• It can say which exceptions are open, who accepted them and when they expire.

The same chain from requirement to retest that governs every other control is set out on the Continuous Control Assurance page.

An illustration: a supplier changes its model

This example is an illustration. The organization is invented, and the example uses no figures.

A European insurer uses a supplier’s AI tool to draft replies to customer complaints, and a second, in-house model to help staff prioritize claims. The inventory lists both with their owners. The claims model is classified as high-risk under the insurer’s own tiers, and the insurer’s counsel reviews it against the Act’s Annex III categories. The complaints tool sits in the insurer’s transparency tier, because the insurer has decided to tell customers when a reply was drafted with AI.

In the spring, the supplier announces that it has moved its tool to a new underlying model. The change reopens the assessment of the complaints tool, and the insurer runs its tests again on a sample of past complaints before the new version goes live. One test finds that the new model includes internal notes in some draft replies. The finding goes to the tool’s owner, the supplier fixes the prompt template, the tests are run again and pass, and the tool goes live with the reassessment on file. The claims model, which did not change, keeps its monthly monitoring, and its overseers’ interventions are logged as before.

How DigitalXForce runs AI governance

TRiSCM, or Trust, Risk, Security and Compliance Management, is a category of enterprise software defined by DigitalXForce that converges automated governance, risk and compliance with security posture management into a single real-time system, replacing periodic control validation with continuous control assurance. AI TRiSCM is its AI module, and the AI TRiSCM and AI Risk Governance module discovers AI assets across cloud, code, pipelines, containers, model endpoints and RAG stores, assesses LLMs, copilots, agents and models, and maps them to the NIST AI RMF, ISO/IEC 42001, the EU AI Act, the OWASP LLM Top 10 and MITRE ATLAS. The glossary entry adds production approval, policy gates, exception management and remediation tracking across the AI lifecycle. The module’s EU AI Act mapping follows the AI Omnibus dates, and the classification of each system under the Act stays with the organization.

Each AI system is assessed on a schedule and when it changes. AI risks sit in the Enterprise Risk Management register next to every other risk. A risk operations center is an operating model for continuously measuring, prioritizing and reducing risk, in the way a security operations center handles threats; DigitalXForce’s implementation is X-ROC, the XForce Risk Operations Center. A failed AI guardrail raises a risk in X-ROC with its evidence attached and an owner.

AI JedAI is the DigitalXForce AI engine that analyzes: it reasons over control evidence and live telemetry, maps documents to controls and frameworks, scores and prioritizes risk, and recommends remediation mapped to framework requirements. XForce GPT is the DigitalXForce generative AI engine that writes: it produces the plain-language risk narratives and board-ready reports, generates policies, standards and plans, and runs the embedded assistant. We apply the same rule to our own engines that this page applies to everyone else’s, so analysts review what the AI produces before anyone relies on it.

The Digital Trust Score is DigitalXForce’s composite score from 300 to 850, computed continuously from live control evidence across seven sub-postures: security, compliance, audit, resilience, third-party, AI and risk. Its AI posture measures the completeness of the AI inventory, the risk of each model and use case, the sensitive data each one can reach, and whether a person oversees it, and the Digital Trust Score methodology explains how to read it.

Where DigitalXForce is not the answer

An organization with a handful of AI tools, no regulatory exposure and no board question about AI does not need a governance module yet, and a written policy with an inventory kept in a spreadsheet will serve it for now. A startup or small company whose immediate need is its first SOC 2 report should start with DigitalXForce Lite, which runs the same platform in the cloud with the same functionality and a faster deployment. DigitalXForce also does not give legal advice, so the classification of a system under the EU AI Act stays with the organization and its counsel.

Questions about AI governance

What is AI governance?

AI governance is the set of policies, roles, controls and evidence an organization uses to decide which AI systems it runs, how they may be used and whether their controls keep working. It covers AI the organization builds, buys or uses, including AI inside supplier software.

What is continuous AI governance?

Continuous AI governance keeps the governance decisions open for as long as each AI system is in use. A change to a model, a data source, a supplier or a use case reopens the assessment, and every control around the system is tested on a schedule with its evidence kept.

What is AI risk management?

AI risk management is the part of AI governance that identifies, measures and treats the risks each AI system poses. The NIST AI RMF 1.0 organizes it into 4 functions, Govern, Map, Measure and Manage, and says it should be continuous and performed throughout the AI system lifecycle.

How should AI systems be classified by risk?

Classify each system against the law that applies and against the organization’s own tiers. The EU AI Act sets 4 levels, unacceptable, high, transparency and minimal risk, and the organization’s own tier usually weighs data sensitivity, autonomy and business dependence. The classification under the Act stays the organization’s decision, made with its counsel.

When do the EU AI Act high-risk rules apply?

After the AI Omnibus, the European Commission states that the rules for high-risk systems in the Annex III areas apply from 2 December 2027, and the rules for high-risk AI built into products covered by Annex I apply from 2 August 2028. Guidance that gives 2 August 2026 for all high-risk rules is out of date.

How should human oversight of AI be documented?

Name the people who oversee each system and their training, state what they may do and when they are expected to step in, log every intervention, and test the stop mechanism. The EU AI Act asks deployers of high-risk systems to assign oversight to people with the necessary competence, training and authority.

How does AI governance connect to Continuous Control Assurance (CCA)?

Continuous Control Assurance (CCA) uses evidence, monitoring and validation to determine whether controls continue to operate as expected. Applied to AI, each AI control gets an expected state, evidence, a scheduled test and a finding with an owner when it fails, so AI controls are validated the same way as every other control.

Sources

• NIST released the Artificial Intelligence Risk Management Framework (AI RMF 1.0), NIST AI 100-1, on 26 January 2023, at https://doi.org/10.6028/NIST.AI.100-1. Its landing page at https://www.nist.gov/itl/ai-risk-management-framework says the framework is being revised. The outcomes cited are in Tables 1 to 4 of the Core.
• NIST published Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile, NIST AI 600-1, in July 2024, at https://doi.org/10.6028/NIST.AI.600-1. The 12 risks are in section 2.
• ISO describes ISO/IEC 42001:2023, Information technology, Artificial intelligence, Management system, published in December 2023, at https://www.iso.org/standard/42001.
• The European Commission sets out the AI Act, its 4 levels of risk, its application timeline and the AI Omnibus dates at https://digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai, last updated on 3 August 2026.
• The Commission’s AI Act Service Desk gives the implementation timeline, including the Digital Omnibus on AI, at https://ai-act-service-desk.ec.europa.eu/en/ai-act/timeline/timeline-implementation-eu-ai-act, and the text of Articles 5, 6, 9, 14, 26, 50 and 72 of Regulation (EU) 2024/1689 at https://ai-act-service-desk.ec.europa.eu/en/ai-act/article-5 and the matching addresses for the other articles.
• The OECD describes the OECD AI Principles, adopted in May 2019 and updated in May 2024, and its definition of an AI system, at https://oecd.ai/en/ai-principles.
• NIST published The NIST Cybersecurity Framework (CSF) 2.0, CSWP 29, on 26 February 2024, at https://doi.org/10.6028/NIST.CSWP.29.
• Every source above was read on 26 September 2026.

What this looks like in practice.

Reading about continuous evidence is one thing. Watching a control get tested against live data from your own stack is another. A 30 minute walkthrough on your frameworks shows the difference.

Request a demo