TL;DR: AI programs become materially easier to govern when teams separate Security for AI from AI for Security, route every model or agent call through a policy gateway, and tie provenance, evaluation, and evidence exports to release gates, according to LEVO. The operational shift is from ad hoc pilot controls to replayable, auditable execution with predictable cost and safer tool use.
NHIMG editorial — based on content published by LEVO: a practical guide for CIOs to ship AI programs that are reliable, cost disciplined, and audit ready
By the numbers:
- Only 5.7% of organisations have full visibility into their service accounts.
- 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.
Questions worth separating out
Q: How should security teams govern AI systems that can act without human approval?
A: Security teams should govern autonomous AI the same way they govern other high-risk identities, but with runtime enforcement instead of periodic review.
Q: Why do AI programmes need provenance and traceability to be audit ready?
A: Because auditors and internal reviewers need to reconstruct what data influenced a response, what policy applied, and what action was taken.
Q: What are the most common failure modes in production AI governance?
A: The usual failures are free-form outputs reaching effectful tools, missing approval capture, weak retrieval provenance, and one-time red teaming that does not keep pace with prompt and corpus changes.
Practitioner guidance
- Route all effectful AI calls through a gateway Require every model or agent request that can change data, trigger a workflow, or call a tool to pass through a gateway that enforces policy, schemas, approvals, budgets, and trace export.
- Make provenance part of the release gate Sign corpora and index manifests, attach source IDs to retrieval, and block releases unless the trace can show which sources influenced each response.
- Add evaluation packs to CI and change control Test for injection resistance, schema compliance, grounding, and cost thresholds whenever prompts, corpora, models, or routes change, then fail closed on poor results.
What's in the full article
LEVO's full article covers the operational detail this post intentionally leaves for the source:
- Step-by-step governance patterns for routing model and agent calls through a production gateway
- Detailed scorecard design for injection block rate, grounding, schema pass rate, and cost per task
- Procurement and contract language for open traces, policy export, and evidence clauses
- 30, 60, 90, and 365-day implementation checkpoints for AI programme rollout
👉 Read LEVO's practical guide to reliable, auditable AI programs →
AI governance without drift: what CIOs need to standardise now?
Explore further
Policy gateways are becoming the control plane for AI governance. The article is right to put routing, approvals, schemas, and traces at the boundary, because that is where AI systems become operationally real. In governance terms, the old split between policy and execution no longer works when model calls can trigger tools, budgets, and external side effects. Practitioners should treat the gateway as the minimum enforceable layer for any production AI programme.
A question worth separating out:
Q: How do organisations separate AI governance from AI security testing?
A: AI governance defines what should be allowed, while AI security testing verifies whether the deployed system actually stays within those boundaries. Governance without runtime validation is only policy on paper, especially once agents can retrieve data, call tools, and trigger workflows on their own.
👉 Read our full editorial: Reliable, auditable AI programs need a paved road and evidence bus