What is AI Governance?
AI governance is the system of policies, responsibilities, controls, and evidence an organization uses to decide how AI may be developed, deployed, and used. It connects decisions about acceptable risk to the people, systems, and processes that put those decisions into practice.
For a concise explanation of the term, read the AI governance glossary entry.
In an enterprise, that means answering concrete questions: who may use an AI application, which data it may receive, what actions an agent may take, and who responds when something goes wrong. A useful governance program can explain both the rule and how the organization checks whether it is followed.
The scope extends beyond security. The OECD AI Principles include fairness and privacy, transparency, safety, and accountability. The NIST AI Risk Management Framework is voluntary guidance covering the design, development, use, and evaluation of AI systems. This page focuses on turning governance decisions into controls for enterprise AI usage.
Why AI governance changed with generative and agentic AI
Generative and agentic AI make the context of use central to the governance decision. The same underlying model can support an employee drafting text, an application summarizing records, or an agent selecting tools and acting on the results. Approving the model does not resolve the permissions and data handling of each workflow.
Hypothetical example: a support team approves an assistant to draft replies using a public knowledge base. Connecting that assistant to customer records changes the data boundary. Letting it issue refunds changes the authority boundary. Those changes deserve review even if the model stays the same.
The policy therefore needs to describe the permitted purpose, data, and actions. “Approved AI tool” is an incomplete decision if it leaves all three open. Teams also need a way to notice when an approved workflow changes.
Model governance vs usage governance
Model governance and usage governance address complementary questions. The distinction below describes their emphasis, rather than two separate standards or mutually exclusive programs. Model governance also continues after deployment.
| Governance question | Emphasis in model governance | Emphasis in usage governance |
|---|---|---|
| What is being evaluated? | A model's suitability, behavior, and limitations for its intended use | A person's, application's, or agent's use of AI in a specific workflow |
| What evidence helps? | Evaluation results, data documentation, version history, and known limitations | Available records of access, activity, policy decisions, approvals, and outcomes |
| What change prompts review? | A model update, changed evaluation results, or a new intended use | New data access, tool permissions, users, destinations, or permitted actions |
| What decision follows? | Whether and under what conditions the model is suitable | Whether this use is permitted and what controls it requires |
A model can be suitable for summarization while a particular transfer of customer records remains prohibited. Conversely, a correctly authorized workflow can still produce an inaccurate summary. Evaluating model behavior and controlling use both matter.
The AI usage governance pillar explains how to define permitted uses and review changes to their data, outputs, and purpose.
The enterprise AI governance surface
An operational inventory should describe the relationships between people, applications, agents, data, tools, and actions. These six surfaces are a practical way to examine a workflow, not a claim that one integration can observe them all.
Humans
Identify the person requesting the work, the person accountable for the use case, and anyone authorized to approve exceptions. Separate an employee's personal account from an organization-managed account where that distinction affects permitted use.
Applications
Record where AI is accessed: a browser application, desktop client, embedded feature, or internal service. Include the owner and approved purpose. An application name alone does not establish which account, configuration, or data access is in use.
Agents
Describe the decisions delegated to the software, the tools available to it, and the conditions for human review. Govern the behavior and authority granted to the system. For a closer examination of the terminology, read AI Agent.
Explore policies, approvals, and evidence in the AI agent governance pillar.
Data
Map what the workflow reads, sends, generates, and stores. Include the destination and who can access the resulting records. Consider the governance system's own data collection as well: inspecting a prompt can itself create another copy of sensitive content.
Tools
Identify the functions exposed to the application or agent and the permissions used to call them. A tool that reads a record and a tool that modifies it require different decisions, even when both connect to the same service.
Actions
Distinguish a proposed action from an attempted or completed one. Drafting a refund recommendation, approving it, and issuing the refund are separate events. Keeping those states distinct helps avoid treating a logged request as proof of what actually happened.
The enterprise AI security pillar connects these paths to the people who control the affected resources and coordinate a security response.
Core AI governance capabilities
A practical program needs a path from discovery to reviewable decisions. The capabilities below describe organizational needs; they are not a checklist of features promised by any individual product.
Discovery
Build an inventory from available evidence, such as approved applications, use-case registrations, and relevant technical signals. Record how each entry was discovered and when it was checked. Mark unknown coverage explicitly so an incomplete inventory does not look complete.
Visibility
Connect the available activity to its user, application, and business context. State which fields are missing. An event without prompt content may show that an interaction occurred while leaving the data involved unknown. Retain that distinction in investigations and reports.
Policy
Write rules that someone can apply to a concrete request. Include the scope, permitted behavior, responsible owner, exceptions, and review conditions. NIST's AI RMF Playbook, GOVERN connects AI policies to existing organizational governance and data governance, including deployed and third-party systems.
For the hypothetical support assistant, a policy could permit drafting from the public knowledge base, restrict customer-record access to assigned cases, and require a designated approver for refunds. Each clause has a different implementation point.
For the approval process, examine why AI governance must move from models to actions.
Enforcement
Place the control where it can affect the relevant decision. That might be an application permission, a data access rule, or a check before a tool executes. Validate the permitted path, the prohibited path, and what happens if the control is unavailable.
OWASP's Excessive Agency guidance recommends limiting tool functionality and permissions, requiring human approval for high-impact actions, and enforcing authorization in downstream systems. A model's own decision that an action is acceptable does not replace authorization.
Audit
Preserve enough evidence to reconstruct the decision: the requested action, relevant context, rule applied, decision, and observed outcome where available. Document gaps and retention choices. The OECD accountability principle calls for traceability of datasets, processes, and decisions across the AI system lifecycle, appropriate to context.
Reporting
Report decisions that need attention, not just activity totals. Useful questions include which workflows lack an owner, which exceptions remain open, and which controls have unverified coverage. Name the data source and period so readers can distinguish a measured finding from an assumption.
What runtime governance adds
Here, runtime AI governance means applying governance decisions to AI activity while a workflow is operating, using the context available at that point. It connects an approved policy to an actual interaction or action, rather than stopping at initial approval of the use case.
Timing determines what a control can do. A check positioned before an action can participate in deciding whether it proceeds. Telemetry received after completion can support investigation and subsequent response, but it cannot prevent that completed action.
Pre-execution governance refers here to the subset that evaluates a proposed action before execution, at a point capable of withholding permission. It depends on an integration that participates in the execution path. A log collector alone does not provide that control.
In the hypothetical refund workflow, a pre-execution check would evaluate the refund request before submission. A later event could confirm the result. The audit should distinguish the authorization decision from the evidence of completion, including a missing result.
Runtime controls still depend on clear ownership, appropriate permissions, and review of the underlying use case. They address the operational moment within a broader governance program.
How KonaSense approaches AI governance
KonaSense organizes its product around AI usage in different work environments. The relevant integration and its limits should be evaluated for the workflow in question.
Kona for Browser supports policy evaluation for prompts in supported AI web applications. Its privacy documentation describes sending prompt content to the organization's KonaSense tenant for policy evaluation. The available intervention depends on the supported integration and inspection mode.
For work involving coding agents, explore Kona for Agents. For desktop telemetry, the technical note on OpenTelemetry and AI application governance explains the observational path and its limits. Available context depends on what the application exports; asynchronous telemetry cannot stop an action that has already completed.
FAQ
Who should own AI governance?
Assign an accountable program owner and explicit responsibilities for each use case. Business owners define the intended outcome; security, privacy, risk, and engineering contribute the controls and review within their remit. Record who accepts exceptions and who responds to incidents so shared participation does not leave decisions unowned.
Does an approved AI application make every use acceptable?
Approval needs a scope. An application approved for public material may need a different decision for confidential records or actions in production systems. Document permitted data, users, and actions, then review changes to those conditions.
How should an organization start?
Choose one consequential workflow. Name its owner, map its data and permissions, define the permitted actions, and identify available evidence and control points. Test the policy against a permitted request and a prohibited request. Use what those checks reveal to improve the workflow before expanding the program.