Earlier editions

An AI governance framework defines who is responsible for AI, what systems and decisions fall within its scope, what actions are permitted, and what evidence is needed to evaluate, change or stop those actions. It should connect organizational policy to the way people, data, models and software actually work together.

For an organization choosing AI governance tools, platforms or consulting support, the practical question is whether that framework can guide a consequential decision: who may let this system do this thing, using which information, under what conditions?

HALO's view is that a framework becomes useful when those answers can be inspected in the operation itself. A policy establishes an expectation. A named owner, an enforceable permission boundary and a record of what happened help establish whether that expectation is being met.

Start with established frameworks, then make the decisions concrete

Organizations do not need to invent the entire discipline. NIST's AI Risk Management Framework 1.0 organizes work through GOVERN, MAP, MEASURE and MANAGE. Governance runs across the other functions; the framework is voluntary and is intended to be adapted to context. These functions are not a mandatory sequence or a completed compliance checklist. NIST AI RMF 1.0, Core.

ISO/IEC 42001:2023 addresses an organizational AI management system: establishing it, putting it into practice, maintaining it and improving it. That is a different level of description from a single model evaluation or approval screen. ISO's overview of ISO/IEC 42001.

Neither reference makes HALO's approach a certification method. The questions below are our operational interpretation: a way to examine whether governance responsibilities connect to actual decisions. They complement established guidance rather than replace its requirements. This article refers specifically to NIST AI RMF 1.0; NIST currently notes that a revision is in progress. NIST AI RMF resources.

Govern the operation, including the handoffs

A useful starting point is one real workflow rather than an inventory of policies alone. Identify its purpose, the people affected, its information sources, its proposed actions and its dependencies. Include the steps outside the model: retrieving a customer record, changing a price, sending a message, approving a payment or reporting a commercial outcome.

Our proposed review covers seven areas. The evidence column describes something an organization should be able to inspect; it is not a claim that every organization needs the same software or approval process.

Area to govern	Decision to make	Evidence to inspect
Systems and purpose	Which uses are allowed, and which people or operations could be affected?	A current workflow inventory, intended-use statement and accountable owner
Decision rights	Who may authorize deployment, accept residual risk, change scope or stop the operation?	Named responsibilities and a recorded decision with conditions
Data authority	Which source is authoritative for each fact, and what happens when sources disagree?	Source/version records, access rules and a conflict-resolution route
Agent permissions	What may the agent read, propose, write, send or commit?	Enforced access boundaries and tests of prohibited actions
Human approval and escalation	Which actions need review, and who handles uncertainty, exceptions or absence?	Approval conditions, review context and an escalation route
Observability and audit	Can someone reconstruct an important action and intervene?	Linked records of inputs, permissions, decisions, actions and exceptions
Change and retirement	When must the operation be reassessed, paused or withdrawn?	Review triggers, change history, fallback and a responsible owner

The scope must extend beyond reliability and business loss. NIST's trustworthiness framing also includes safety, security, transparency, privacy and the management of harmful bias. Consider affected people and the possibility that a technically successful action still causes harm. NIST AI RMF 1.0, Part 1.

Decision rights and accountability

Separate the person who builds the system from the person accountable for the business decision it supports. Name who can authorize its use, approve a material change, accept an unresolved limitation and require a pause.

For a small organization, several responsibilities may belong to one person. The purpose is to make decisions visible, not to manufacture committees. A role name helps only if the person has the information and authority to perform it.

An exception needs an owner too. If the normal approver is absent, define whether the operation waits, escalates or proceeds within a narrower permission. An undocumented assumption about who will intervene is not an operating arrangement.

Data authority and trusted information

Avoid giving a general label such as “trusted data” to every connected source. Instead, ask which system owns a particular fact. A sales tool may contain a copy of an order without becoming the authority for whether payment occurred. A retrieved document may be relevant while an older version is no longer valid for today's decision.

Record the source, relevant version and time, permitted use, and how disagreement is resolved. Define when missing or stale information should prevent a particular action. Access to a source is a separate question from permission to reuse its contents.

HALO examined this distinction in A product configuration is not a purchase. The published account preserves configuration as a useful observation while leaving its connection to an authoritative order unproven. Its lesson is about the scope of evidence, not a claim that every commercial system has the same architecture.

Agent permissions and delegated authority

Treat reading, recommending, editing and committing as different permissions. An agent may need broad information access to make a useful proposal while having tightly limited authority to act on it.

For example, a proposed arrangement might allow an agent to draft a customer response but require approval before sending it, or to suggest an invoice correction without issuing a refund. Those are illustrative choices, not universal rules. The appropriate boundary depends on the consequence, uncertainty and capacity to contain an error.

Inspect how the boundary is enforced. A written instruction to ask permission should not be the only protection when the connected account already allows an irreversible action. Review access, transaction conditions and failure behavior together. Reassess permissions when the workflow, data, tools or consequences change.

Human approval and escalation

Specify what the approver is actually approving. A review is more useful when it shows the intended action, affected records or people, relevant evidence, unresolved uncertainty and the consequences of accepting it.

Bind approval to a defined action and scope. If the proposed action changes materially after review, decide whether approval must be renewed. Define what happens on rejection, timeout, missing evidence and disagreement.

Human involvement has limits. A person who lacks time, context or a meaningful ability to intervene may simply confirm the system's suggestion. Reserve review effort for decisions where it can change the outcome, and make the remaining automated boundaries explicit. More approval steps do not by themselves demonstrate better governance.

Monitoring, observability and auditability

For a consequential action, ask whether an authorized reviewer can establish what was proposed, what information supported it, which permission applied, who approved it where required, and what the receiving system actually did.

These are separate observations. A sender recording success may not establish durable receipt. A generated report may not establish that a user read it. A configured product is not evidence of a paid order.

Collect records proportionate to the risk and protect their contents. An indiscriminate log can create another privacy or access problem. Decide who can inspect records, how long they are needed, and which observations require intervention rather than passive display.

A HALO example: a useful result did not make purchase ready

HALO's published account of governed action describes an inspected Engine purchase contract. Calculation and interpretation had different responsibilities. The tests required purchase to remain unavailable while the accompanying interpretation was pending, failed or in a retryable failure state; an interface correction aligned purchase availability with that condition. A result is not permission to take the next step.

The example establishes a particular historical contract and documented correction. It does not demonstrate that every failure was anticipated, that today's deployed product has been retested in every state, or that the control improved commercial results.

The governance decision was concrete: partial diagnostic work could remain useful without satisfying the prerequisite for purchase readiness. That distinguishes having an output from being authorized to advance the workflow.

HALO uses Governed Action for this concern: assign responsibility and constrain consequential actions according to their evidence, authorization, uncertainty and possible consequences. Warranted Representation governs the accompanying claim: describe only what the evidence supports, with its source, scope and time intact. These are HALO's interpretive disciplines, adopted in September 2026, rather than names attributed to the earlier work. The published evidence account explains why implementation records, reported tests and broader reliability claims must remain distinct.

Here is how a team could record the same kind of decision in another workflow. This is an illustrative review record, not a recovered HALO implementation or an Engine output.

Field	Illustrative entry
Operation	AI-assisted preparation of a customer proposal
Accountable owner	Commercial operations lead; named individual assigned before use
Information authority	Approved customer record and current approved price list
Delegated permission	Prepare a draft; no authority to send or change commercial terms
Approval condition	Authorized reviewer checks recipient, scope and terms before sending
Exception	Conflicting prices or missing authority stops sending and escalates to the owner
Evidence	Source versions, reviewed proposal, approval record and separate sending result
Reassessment trigger	A changed price source, permission, sending integration or material incident

The record is valuable because someone can challenge each entry. Who is the owner? Can the system actually prevent sending? Does the approval cover the final version? The answers determine the next work.

Assess readiness before selecting the platform

A governance product can support an operating arrangement, but the organization must first decide which arrangement it needs. Use a consequential workflow to evaluate prospective tools or consulting support.

1. Name the decision. Ask what the proposed system must help someone decide, permit or prevent. “Improve governance” is too broad to test.
2. Trace the information. Ask how authoritative sources, versions, access and conflicting records will be handled.
3. Demonstrate a boundary. Test an allowed action and a prohibited one, including failure behavior, in an appropriately contained environment.
4. Examine the human handoff. Review what an approver sees, what their decision covers, and what happens when no one responds.
5. Follow an exception. Inspect how missing evidence, rejected actions and incidents reach a responsible person.
6. Reconstruct an outcome. Ask which records support the claim that an action completed and which downstream facts remain unknown.
7. Change or stop the workflow. Examine who can withdraw authority, revise permissions and maintain a safe fallback.

Bring the answers into implementation planning. A system whose authority source is unresolved needs different preparation from one with a clear owner but inadequate monitoring. A small reversible pilot may be appropriate for one uncertainty; a high-impact action affecting people's rights may require substantially more scrutiny before use.

Our suggested connection to established risk work is simple: use GOVERN to clarify responsibility, MAP to understand context, MEASURE to examine behavior, and MANAGE to decide a response. That is an operational reading, not a claim that completing the seven questions satisfies NIST. NIST's Core supplies the fuller categories and limitations.

HALO ENGINE — AI ORCHESTRATION RISK SCAN

You have an AI governance framework. But how well does your operation actually fit together?

Governance depends on more than policies. Your tools, data, workflows, permissions, and controls need to work together.

HALO Engine uses a structured, response-based diagnostic to help you examine those relationships, identify potential weaknesses, and determine what deserves closer attention.

Run the HALO Engine Risk Scan

The scan is based on your responses; it does not independently audit your systems or certify compliance.

Keep the framework answerable to reality

There is a cost to controls: review takes attention, records require protection, and narrowly restricted permissions may limit useful work. There is also a cost to allowing a workflow to advance without knowing who owns the decision. Choose the arrangement deliberately and revisit it as the consequences and available evidence change.

This article's questions are a starting point for organizational review. They do not cover every sector, jurisdiction or AI use. Where obligations or consequences require specialist assessment, bring in the appropriate expertise and verify the applicable requirements.

An AI governance framework should leave an organization able to explain a real action: why it was permitted, whose responsibility it was, what evidence supported it, what happened, and what would make the organization change its mind. That is a more useful test of readiness than the existence of a policy document alone.