AI governance is the policies, roles, processes and controls used to direct and oversee the development, deployment and operation of AI systems. It addresses accountability, risk, compliance and oversight across the AI lifecycle, from organizational decisions to the behavior of individual systems.
In a few years AI governance has gone from a set of principles to a discipline with standards, law and a profession. NIST published its AI Risk Management Framework in January 2023. ISO/IEC 42001, the first management system standard for AI, followed in December 2023, and in 2025 ISO added a standard for the bodies that certify against it. The EU AI Act entered into force in 2024 and is being applied in stages; after a 2026 amendment, its main obligations for stand-alone high-risk systems apply from December 2027. The IAPP found that 77 percent of the organizations it surveyed were working on AI governance. The field now agrees broadly on what a governance program contains. The open question is how it reaches AI systems that decide their own actions while they run.
Governance, management and assurance
Three activities share the word, and programs work better when they are kept apart.
- Governance sets direction and accountability: which uses of AI the organization accepts, at what risk, and who answers for them. ISO/IEC 38507 addresses this layer to the governing body itself.
- Management is the system that carries the direction out: policies, roles, processes, assessments and controls. ISO/IEC 42001 specifies the requirements for an AI management system that is established, implemented, maintained and continually improved.
- Assurance shows that the system works: internal audit, external certification of a management system, and, under the EU AI Act, conformity assessment of high-risk systems.
What an AI governance program contains
| Component | What it decides or produces | Where frameworks address it |
|---|---|---|
| Accountability | Named owners, oversight bodies, escalation paths | NIST GOVERN 2.1; OECD accountability principle; EU AI Act Article 26(2) for deployers’ oversight |
| Inventory | Which AI systems exist, who owns them, what they are for | NIST GOVERN 1.6 |
| Purpose and classification | The intended purpose and context of each system, and its risk tier | NIST MAP 1.1; EU AI Act Articles 3(12) and 6 |
| Assessment | Risk and impact assessments before deployment and on change | NIST MAP and MEASURE; EU AI Act Articles 9 and 27; ISO/IEC 42005 |
| Lifecycle controls | Data, testing and approval requirements before a system ships | ISO/IEC 42001; EU AI Act Article 17 for providers |
| Monitoring and response | Performance, incidents, override and decommissioning in operation | NIST MANAGE 4.1; EU AI Act Articles 26(5) and 72 |
| Records | Documentation and logs that show what happened | EU AI Act Articles 12 and 26(6); see AI audit trail |
Purpose is the anchor
Almost every element of that table hangs from one fact: what the system is for. The EU AI Act defines intended purpose as the use for which an AI system is intended by its provider, including the specific context and conditions of use. Risk classification follows from it: the Act’s list of high-risk uses is written as systems “intended to be used” for named purposes. NIST’s MAP 1.1 asks that intended purposes and prospective settings be understood and documented. Assessments, testing, instructions for use and monitoring are all measured against that purpose.
This design is sound for systems whose purpose is settled when they are approved. A credit scoring model scores credit. Once its purpose is assessed and documented, the remaining governance question is whether it keeps performing that purpose well, which is what monitoring answers.
Agents receive their purpose at run time
A general-purpose agent is approved for a purpose stated broadly: support the HR team, assist engineering, help finance with operations. What it is asked to do arrives with each task, from whoever gives the task. These are two different things. The intended purpose in the EU AI Act’s sense is defined by the provider for the system, in its instructions for use and documentation, and it is what classification follows. The purpose of a task is an instruction for one run. A task does not by itself rewrite the system’s intended purpose or its legal classification, but two runs of the same approved agent can serve purposes that would have been assessed very differently if anyone had assessed them.
The frameworks see the tension. The EU AI Act defines a general-purpose AI system as one able to serve a variety of purposes, and its Article 25 makes anyone who changes a system’s intended purpose so that it becomes high-risk into that system’s provider. Draft Commission guidance published for consultation in 2026 treats a system presented as broadly applicable, without high-risk uses excluded, as having an intended purpose that also covers them. And the frameworks do not stop at approval: NIST requires post-deployment monitoring plans, the Act requires deployers to monitor high-risk systems in operation, and Singapore’s Model AI Governance Framework for Agentic AI, the first written for agents, calls for continuous monitoring and notes that agents need permissions that change with “the context, risk levels, and task objectives.”
The gap is narrower than “governance ignores run time”, and more practical. Monitoring is measured against the purpose approved for the system, or against risk in general. What most programs do not yet capture is the purpose of each task as a governance record of its own: what this run was asked to do, which systems it should need, and under which policy. Without that record, the question an auditor will eventually ask, whether a given run stayed within what the agent was approved for, has no evidence to answer it. The system’s intended purpose is still set at approval; for agents, the purpose of each run is set at run time, and governance has to record it there: at the start of each run, as declared intent and declared scope, compared with each action as the run proceeds. That is the work of runtime governance. Recording a task’s purpose is not the same as authorizing it: the record makes the purpose reviewable, and whether that purpose was acceptable remains a decision for the people and controls the program assigns.
Evidence of process and evidence of behavior
A governance program produces two kinds of evidence. Evidence of process shows that the program exists and operates: policies, assessments, committee minutes, a certificate. Evidence of behavior shows what the governed systems actually did. Certification of a management system is evidence of the first kind, by design: it attests that the organization governs AI systematically, not how a particular system behaved on a particular day.
For predictable systems, strong process evidence is a reasonable proxy for behavior. For agents it is a weaker one, because the behavior is assembled at run time. The surveys point the same way. ISACA’s 2026 poll of more than 3,400 professionals found that 38 percent of organizations have a formal, comprehensive AI policy, and that 56 percent do not know how long it would take to halt an AI system during a security incident. In a 2026 Cloud Security Alliance survey commissioned by Aembit, 68 percent of organizations said they cannot clearly distinguish the activity of AI agents from that of people.
Behavior evidence for agents is a per-run record: what the run was asked to do, what it was allowed to reach, what it attempted, how each attempt compared with the applicable policy, and which version of that policy applied. It also closes the loop the frameworks call for. Purposes requested at run time but never approved, and actions that repeatedly fall outside scope, are exactly the inputs a program needs to update its inventory, its assessments and its policies.
An example
A company runs a mature program. Its HR helpdesk agent is in the inventory, its approved purpose is answering employees’ questions about HR policy, its risk assessment found it low risk, and it passed testing before launch. It holds read access to the HR policy library and, so that it can answer questions about leave balances, to the HR information system.
A manager asks it to shortlist internal candidates for a team lead role, based on last year’s performance reviews. The agent reads the reviews from the HR information system and returns a ranked list. Every artifact in the program is intact and every access was permitted. But this run served a purpose the program never assessed: evaluating people for promotion. Had that been the system’s intended purpose, it would be the kind of employment use the EU AI Act lists among high-risk uses. One task does not reclassify the system; whether repeated use of this kind changes anyone’s obligations is a question for the program’s legal review. For governance, it is a potentially high-risk use that no one assessed. Nothing at the level of the system changed. The change happened in one task, and only a record of that task makes it visible to a reviewer.
Where Sentience fits
Sentience Governor, the free, open-source runtime governance library, keeps that per-run record. A governed session declares its objective and scope when it starts; each attempted action is compared with the scope and the operator’s policy, with the objective kept as context; and each governed event records a fingerprint of the governance profile in force, so a reviewer can see which version of policy governed the run. In the example, a session declared for answering HR policy questions with the policy library as its scope would record the reads from the HR information system as outside that scope and flag them. The limit matters as much as the flag. Governor flags the scope and policy violations it supports; it does not judge whether an action serves the objective. Had the session’s scope included the HR information system, as the agent’s leave-balance work could justify, the same reads would be in scope, and Governor would not determine that they served an objective no one approved. The record would still show the declared objective, the task as given and every read, for a reviewer to judge. Governor records a task’s purpose; it does not authorize it. It records and flags, and it does not stop the agent. Its record is kept per session, on the machine where the agent runs.
The Governor Model, the architecture in Sentience’s white paper, describes where this leads: scope, memory, identity and policy governed together in a continuous loop rather than set once at approval; the paper presents architecture and direction rather than shipped capability. For organizations whose governance has to act at run time, Sentience Runtime Enforcement applies policy at the execution control points in your own infrastructure, course-corrects routine deviations, escalates consequential actions to your reviewers and stops execution when required, with an intervention record for every decision. Sentience Secure Runtime connects approval to deployment: a workflow is validated in an isolated environment, its execution policies, data access, egress and authorization requirements are tested on real runs, and what passes is captured as a reusable deployment template, which teams then harden and build on for production, so production starts from what was validated rather than from scratch.
Often confused with
AI agent governance. The part of AI governance that deals with agents’ authority, actions and effects. AI governance is the whole discipline, for every kind of AI system.
Responsible AI. A set of principles, such as fairness, transparency and accountability. Governance is the machinery that turns principles into decisions, owners and evidence.
AI risk management. The identification, assessment and treatment of AI risks. NIST describes governance as the function that enables risk management; governance also decides who is accountable and what the organization will and will not do.
AI compliance. Meeting specific legal and regulatory obligations. Governance includes compliance and also covers decisions no law requires.
Where the concept stops
AI governance establishes who decides, by what rules, and how an organization knows its rules are followed. It does not, on its own, establish what a particular AI system did on a particular occasion, whether an agent’s task fell within the purpose it was approved for, or whether a well-run program produced acceptable behavior. Those depend on records of each run, compared with the purpose and policy that applied, and on people who act on what the records show.