AI governance means more than a rulebook for AI use.
It means establishing evidence and mechanisms to control the authority delegated to AI.
As AI in enterprise systems moves from conversational assistance to direct execution, delegated authority is growing faster than the evidence and controls governing it (p.5).
This is also the shared concern identified by the 14 contributions in the first issue of KCBCA Signals.
The editor's introduction brings the response together in three prescriptions.
Delegate carefully, verify execution, and prepare for failure (p.6).
What should an organization delegate to AI, how much, and under whose responsibility?
This article outlines the key decisions in AI governance.
Capability and authority are different
Being able to produce analysis, read API responses, and write code does not mean being authorized to execute financial, administrative, or deployment decisions (p.5).
A useful model, valid credentials, and a successful API call do not establish that an action is appropriate (p.40).
The starting point is keeping assistance from quietly becoming permission (p.40).
| Category | Capability | Authority |
|---|---|---|
| Examples | Produce analysis, read APIs, write code | Transfer money, deploy, make administrative decisions |
| Questions to ask | Can it perform well? | May it be entrusted with this? Who is responsible? |
| Basis for judgment | Model performance | Evidence and controls for each task |
Three organizational decisions: authority, verification, and failure readiness
The editor's three prescriptions translate into the following organizational decisions (p.6).
1. Authority — what should be delegated? Even with the same AI, the permissible scope differs by task.
Product recommendations can tolerate more uncertainty than refunds, while financial approvals, transactions, and permission changes require much lower residual risk (p.28).
2. Verification — how much should be delegated? Expand autonomy gradually according to the evidence accumulated for each task (p.6, p.29).
A healthy server and a new version tag do not prove that the reviewed code is actually running (p.6).
3. Failure readiness — can it be stopped? Test refusal, revocation, and blocking paths alongside successful cases, and retain evidence explaining consequential actions (p.6).
It must be possible to reconstruct afterward whether an action was permitted, whether it was appropriate, and why it was allowed (p.29).
Use the following table to review your organization's AI governance.
| Decision | Question for the organization | Source |
|---|---|---|
| Authority | Which actions may proceed without human review? | p.28 |
| Risk threshold | Who accepts what level of risk? | p.29 |
| Verification | What confirms actual execution? | p.6 |
| Expanded autonomy | What accumulated evidence permits a broader scope? | p.29, p.40 |
| Failure readiness | Have refusal, revocation, and blocking paths been tested? | p.6 |
| Explainability | Can permission, appropriateness, and the reason be reconstructed? | p.29 |
Practical controls, including permission separation, independent checks before signing, and four stages of delegation, are covered in the “AI agent security checklist” article in late October.
Who sets the risk threshold?
Model providers and technology companies can supply assessments, evidence, and controls.
However, the organization responsible for the activity, such as a bank, hospital, manufacturer, or public institution, must decide what level of risk to accept (p.29).
This is why AI governance cannot be left to a provider's terms of service.
Board responsibility: “we did not know” is not a defence
Traditional risk management assumed that software followed fixed logic and that authenticated people initiated consequential transactions.
Agents with execution authority undermine both assumptions at once (p.16).
Directors and executives have a duty to oversee material operational risks actively and in a defensible manner.
The contribution argues that amid heightened regulatory scrutiny, ignorance of autonomous software's actions is not a defence (p.16).
National approaches: scope and human involvement before speed
The examples in the contribution emphasize where to begin and under what conditions, rather than simply how quickly to proceed (p.11).
| Country | Approach | Source |
|---|---|---|
| United States | Actively promote federal AI adoption, while the AI Action Plan starts with agency groups and high-impact public-service pilots rather than a single agent for citizens | p.11 |
| Canada | 2026 national AI strategy: encourage government adoption and specify privacy, accountability, and human involvement in consequential decisions and tasks | p.11 |
| South Korea | An unusually ambitious approach. The contributor proposes a narrowly scoped public AI pilot environment, or sandbox | p.11 |
Three discussion questions from the editors
The editors of Signals Issue 1 left readers with these questions (p.7).
Q. Where does responsibility end? If an autonomous agent invents a nonexistent package or executes an incorrect financial transaction, where does fiduciary responsibility end: with the provider, the engineering team, or the board?
Q. Should human confirmation be mandatory? Should governments require a “golden hour” time lock and human confirmation through a separate channel for autonomous agents that touch public infrastructure or national financial networks?
Q. How should analysis and execution be separated? If analysis and transaction execution must be strictly separated, what architecture can enforce continuous, cryptographically anchored trust without relying on fixed perimeter firewalls?
These questions have no predetermined answers.
Whether an organization has people and procedures responsible for answering them nevertheless reveals the maturity of its AI governance.
The next question: what evidence justifies greater autonomy?
The first issue's closing remarks say that the remaining question concerns implementation.
What evidence justifies expanding autonomy (p.40)?
The habit of seeking answers should be established before broad autonomous authority becomes routine (p.29).
Frequently asked questions
Q1. Is AI governance only for large companies?
The criterion is whether execution is delegated to AI, rather than company size.
The contribution says that the organization responsible for the activity must determine the level of risk it accepts (p.29).
Once AI starts sending messages or calling tools, decisions are needed regardless of organizational size (p.28).
Q2. Is adding human review enough?
That alone is insufficient.
Even if authentication, access, and API calls are all valid, an action may be inappropriate for its context (p.28).
Decide task by task what may proceed without human review and to what extent. Expand according to evidence, beginning with an observation stage in which humans remain responsible for final actions (p.28-29).
Q3. Will legislation settle the issue?
No. Governance requires working operational controls alongside documented policies (p.6).
The organization responsible for the activity ultimately sets the level of risk it accepts (p.29).
Key points
- AI governance provides evidence and mechanisms to control delegated authority (p.5)
- Capability is not authority (p.5)
- Organizations decide authority, verification, and failure readiness (p.6)
- The organization responsible for the activity sets the risk threshold (p.29)
The goal is not to slow AI adoption.
It is to make useful autonomy accountable and stoppable (p.5).
Start by listing the tasks your organization has delegated to AI in a table.
Read the full KCBCA Signals Vol.1 Issue 1
References: KCBCA Signals Vol.1 Issue 1. Editor's introduction and discussion questions — JJ Park (KCBCA GLOBAL head of publishing), p.5-7; Paul Kim (KCBCA GLOBAL founder and president), p.11; Jack Wong (Scryer CEO and KCBCA GLOBAL director), p.16; Minseung Kang (Tnaps founder and CEO), p.28-29; closing remarks, p.40
