AI governance is not a launch review: build controls into the agent lifecycle

Govern the whole AI system

Governance is often reduced to model selection or content moderation, yet behaviour emerges from models, prompts, retrieved data, tool interfaces, permissions and human workflows. Even with a fixed model, a knowledge or parameter change can alter business outcomes.

The inventory should therefore use the system-and-use-case as its unit, recording audience, task, data class, models, tools, owners, risk tier and active version. Without it, an organisation cannot know what is live, who can use it or who owns an incident.

Risk classification must reach the action level

One agent can contain both low- and high-risk tasks. Reading public product information and changing a customer contract cannot share one control policy. Classification considers affected people, data sensitivity, reversibility, financial or legal impact and human involvement.

The risk tier drives evaluation depth, approvers, log retention, rollout and incident response. It is not a permanent project label: when an agent moves from advice to action, risks and controls must be reassessed.

• Low risk: retrieval, summaries and internal drafts
• Medium risk: operating advice, customer segmentation and workflow routing
• High risk: external sends, financial writes and rights or compliance decisions
• Prohibited or separately assessed: uses without a lawful basis or organisational authority

Preserve provenance and permission for data and knowledge

Governance asks where data came from, why it can be used, who may access it, how long it is retained and how it can be corrected or deleted. Retrieved knowledge also needs version, validity and applicability so obsolete rules stop influencing outputs.

Personal data, trade secrets and cross-border data cannot be protected by prompts alone. Access should inherit enterprise identity, sensitive fields should be minimised or masked, logs should avoid duplicating full inputs, and external model calls need explicit processing and retention boundaries.

Tool permissions define the agent’s real authority

The largest risk is often not saying the wrong thing but doing the wrong thing. Each tool action should declare required roles, parameter limits, maximum blast radius, idempotency and approval points. Models should never bypass business services to access databases directly.

External communication, payment, pricing and permission changes need dual control: the model proposes a constrained action and the execution layer revalidates identity and business rules. Even when upstream content is prompt-injected, the underlying service should reject unauthorised requests.

Connect change, monitoring and incident response

Models, prompts, knowledge, rules and tools all need versioning. A change record describes affected use cases, evaluation scope, rollback and approver. High-risk changes use staged rollout and retain a switch back to a safe mode.

Production monitoring covers refusals, blocked privilege attempts, human edits, complaints and abnormal cost—not just exceptions. Incident reviews ask why controls missed the issue and turn findings into new cases, rules or permission changes.

Map regulation to the actual service, not a generic checklist

China’s Interim Measures for Generative AI Services primarily address services offered to the public in China and set expectations around data, personal information, reliability and provider responsibility. Internal enterprise use still requires analysis under personal information, data security, sector rules and contracts.

The EU AI Act uses risk tiers and places logging, documentation, human oversight, accuracy and cybersecurity duties on certain high-risk uses. Cross-regional organisations need an obligation matrix based on provider, deployer, audience, location and impact rather than mechanically stacking every rule.