What is AI usage governance?
AI usage governance is the set of policies, responsibilities, controls, and evidence used to determine and verify how people, applications, and agents may use AI in an organization.
This operational definition connects an approved use to the activity that follows. It covers who may use a tool, for which purpose, with which data, what may be done with the result, and who reviews changes to those conditions. A tool can remain on the approved list while a new use requires a different decision.
The broader AI governance program establishes organizational responsibilities and acceptable risk. Usage governance makes those decisions usable in a workflow: an employee preparing a document, an application processing records, or an agent performing delegated work.
Why usage governance differs from model governance
A model evaluation can establish evidence about suitability for a task. It does not establish that a particular employee may submit a particular document or share the resulting analysis with a particular audience. Those decisions depend on the context of use, including information the model itself may never receive.
The two forms of governance remain connected. Changing the purpose of an application may require another model evaluation as well as different permissions. Conversely, keeping the same model does not preserve an approval when the workflow changes. NIST's AI RMF Playbook, MAP 1.1 emphasizes documenting intended purpose, users, and deployment context. The practical question is which assumptions from that review still hold for the activity being performed.
An approved tool, a changed context
Hypothetical example: a procurement team approves an AI application, used through an organization-managed account, to draft internal comparisons from public product descriptions. An analyst then wants to add negotiated supplier prices and send the completed comparison to potential suppliers.
The application and model have not changed. The inputs and intended audience have. The original approval does not cover those changes merely because the interface is familiar. The following decisions are illustrative conditions for this hypothetical workflow, not KonaSense features or findings from a customer environment.
| Use or proposed change | Decision the organization needs | Evidence relevant to that decision |
|---|---|---|
| Draft an internal comparison from public descriptions | Confirm that the activity fits the approved purpose and account conditions | Source references, the applicable approval, and available account context |
| Add negotiated prices | Determine whether this data may be processed in this application and configuration | Data-owner decision and the applicable processing conditions |
| Send the comparison to suppliers | Decide which information may be disclosed and who must review it | The reviewed version, intended recipients, and release authorization |
The data owner can resolve whether negotiated terms may enter the application. The person responsible for supplier communications can review the proposed disclosure. The application owner needs to establish which configuration and controls support either decision. An approval from one of these roles should not silently stand in for the others.
Who and what uses AI inside an enterprise
The form of access changes where a condition can be applied and what evidence is available. The same workflow may cross several surfaces; identifying the desktop application alone does not describe an embedded agent or a connected service.
Browser AI
Review the application, account, feature, and material submitted through the browser. A rule permitting public research can require a different check from a rule requiring an organization-managed account. Neither is fully expressed by the application's domain name.
Desktop AI
Examine the files, folders, connectors, or other context available to the application. Permission to open a local document and permission to send its contents to another service are separate questions. Exported telemetry can help describe activity, but its fields need to be checked before using it as evidence of the data processed.
Coding assistants
Distinguish access to project context, the generation of a suggestion, and its acceptance into a codebase. A repository approved for one assistant does not automatically establish permission to include credentials, unrelated projects, or restricted files. Review the actual configuration and workflow instead of treating installation as the approval boundary.
CLI agents
Identify the working environment and the identity whose permissions the process uses. A request to explain a command and authority to run it have different effects. For tools that delegate execution, AI agent governance provides the more detailed account of tool access, approvals, and action evidence.
Autonomous workflows
Assign an owner to work that continues without a person initiating each step. Document its input sources, permitted destinations, operating conditions, and means of suspension. A scheduled process also needs a review trigger when its data source, permissions, or purpose changes; unattended execution does not remove that responsibility.
Data policy includes the output
A usage policy needs to follow information through the work, including what happens after the model returns a result. In the procurement example, authorizing the application to process negotiated prices would not by itself authorize disclosure of those prices to other suppliers. A generated comparison can carry forward information from its inputs.
The policy should therefore distinguish processing permission from release permission. State the permitted audience, storage location, and review required for the output. If people use the result to make a decision, define the review appropriate to that use. Permission to generate a draft is not evidence that its statements have been checked against their sources.
Information handling also applies to the governance process. A prompt collector or investigation record can create another copy of the material being governed. Decide what evidence is needed, who can access it, and how long it should be retained. A complete conversation history is not automatically necessary to verify a particular approval or release decision.
Discovery supplies context for the usage decision
Discovery can reveal an application or an interaction. Usage governance needs to relate it to the conditions that matter for the task. An application record, an identity record, and an approval may describe different scopes or times, so their relationship should be established before combining them into a conclusion.
For known tools, maintain the approved uses alongside the application inventory. Include the owner and the conditions that would require another review. This lets a team assess a changed use without treating every interaction as a new procurement exercise or treating the initial purchase as permission for everything that follows.
When the relevant approval or activity is unknown, retain that uncertainty and assign the question to someone who can resolve it. The Shadow AI pillar covers investigation of incomplete signals and usage outside approval or management. A missing field should not be converted into either a finding of acceptable use or an allegation of disclosure.
Make policy depend on relevant context
A context-aware policy uses the facts needed for a decision. For the procurement workflow, those facts include the source material, the approved processing conditions, and the intended recipients. A device identifier may help locate the activity, but it cannot establish the business purpose or authorize a disclosure.
Separate a declared purpose from technical observations and from an authorized decision. The analyst can explain the task. An integration may report the application and submitted content. A designated owner decides whether the proposed use fits the policy. Some facts can be checked automatically; others need an accountable review. State which kind of evidence supports each condition.
An exception should identify the specific change it permits, its owner, and its limits. If confidential inputs are approved for an internal comparison, the exception should not silently expand to external distribution. Make it possible for the next user or reviewer to understand what remains restricted without reconstructing the original discussion.
Apply each condition at a point that can affect it
Different conditions require different implementation points. Application access can be constrained through available identity and permission mechanisms. Data submission may be checked through a compatible integration in the input path. Review of an externally shared document belongs in a process that can withhold that release. One control should not be credited with effects outside the step it governs.
Validate both the permitted use and a use that should receive a different outcome. For the hypothetical comparison, verify how restricted inputs are handled and whether an unreviewed output can reach the proposed recipients. Identify paths the validation did not cover. These are proposed checks, not tests performed for this page.
Runtime governance contributes where a policy is evaluated during an interaction or action. That evaluation still needs the right context and a component able to apply the decision. Procedural reviews and permissions remain relevant elsewhere in the workflow; the existence of a runtime check does not complete the usage-governance program.
Keep evidence that supports the next review
A useful record connects the approved conditions to the use examined. It identifies the relevant application and configuration, the source of the activity evidence, the decision or exception applied, and what could be verified about the result. Keep approval, observed activity, and reviewed output distinguishable so a later reviewer can see which question each record answers.
Revisit the conditions when inputs, recipients, permissions, application behavior, or business purpose change. NIST's AI RMF Playbook, GOVERN 1.5 calls for planned monitoring and periodic review with assigned responsibilities. The review interval should reflect the use and its risks; a calendar reminder does not replace review of a material change.
For the procurement team, the useful outcome is a clear account of which comparisons remain within approval, which require review, and who owns unresolved questions. Activity volume alone cannot show that those conditions were followed. Reports should retain the period, evidence source, and coverage limits behind their conclusions.
How KonaSense addresses AI usage governance
KonaSense provides different integration paths for AI usage. Their roles should be assessed against the conditions of the workflow rather than treated as interchangeable coverage.
Kona for Browser supports policy evaluation for prompts in compatible AI web applications. Its privacy documentation describes sending prompt content to the organization's KonaSense tenant for evaluation. The available intervention depends on the integration, configuration, and inspection mode.
For agent workflows, Kona for Agents connects supported runtime events to policy evaluation. In the PreToolUse path of the Claude Code adapter implementation reviewed for this page, a denial can be returned as a tool-use denial and an escalation as a request for user approval. That implementation falls back to Allow when evaluation fails; its behavior should not be generalized to other runtimes or installations.
The reviewed desktop OTLP trace-ingestion path processes exported events in the background and returns an OTLP response without an intervention decision for the application. Its available context depends on the attributes exported. This path can contribute activity evidence, but it should not be presented as a mechanism for preventing the reported operation.
These mechanisms support parts of a governance process. The organization still needs to define permitted uses, assign decisions to the right owners, and verify the controls and evidence available for each workflow.