Most AI governance programs start the same way: a policy document, a committee, and a false sense of coverage. The policy says what the system should do. It says nothing about what the system will do when someone pushes it, and that gap is where the actual risk lives.

A policy can state principles, but it cannot govern an AI system unless those principles are translated into operating decisions for each use case. For every AI deployment, someone must be able to identify the system, own its outcomes, define its data access, set the boundary for autonomous action, and prove that those boundaries hold under pressure.

Those are the five governance decisions that matter. Each must be explicit, assigned to a named owner, and tested:

1. 1. 1. Which systems are in scope. Name the sanctioned deployments, pilots, and shadow tools your teams adopted without telling you. If it touches organizational data, it is in scope whether it was formally approved or not.
      2. Who owns each use case. Assign a named person, not a committee, who is accountable for what the system does and authorized to approve what it may do next.
      3. What data each system may access. Define the approved data stores, fields, and classifications. Excessive permissions quietly enable many of the AI incidents that matter most.
      4. Which actions require human approval. Reading is one thing; writing, sending, executing, deleting, and purchasing are another. Establish the line before the agent crosses it.
      5. How unsafe behavior will be tested. Define the test cases, success criteria, and retesting cadence. If you cannot describe how a control will be tested, you do not yet have a reliable control.

With those five answered, the program builds in layers. Start with discovery: catalog every AI system, including the ones procured outside IT, and build the AI bill of materials your governance will reference. Shadow AI is not an edge case. In most organizations, it is the majority of the footprint, and it is the piece traditional tooling misses entirely.

Then work the three risk surfaces every AI deployment shares. First, posture: what you have, where it is exposed, what it is allowed to touch. Second, the prompt boundary: injection, jailbreaks, data leakage, and unsafe output, tested against the OWASP Top 10 for LLM Applications. Third, the agents and integrations: tool poisoning, permission abuse, and exfiltration through connected tools, tested against the OWASP MCP Top 10. Findings from all three map back to the same governance frame, NIST AI RMF or ISO 42001, so technical results land in the risk register instead of a separate silo.

Establish human approval where actions cross a trust boundary. The rule is simple: the more irreversible the action, the stronger the approval. Drafting an email needs none. Sending it to a customer does. Querying a database needs none. Deleting records does.

Finally, put testing on a cadence. Point-in-time testing rots fast because the models, prompts, tools, and permissions all change. Test before launch, after material changes, and on a schedule that matches how fast the system evolves.

What to do this week

Pick one AI system your organization depends on and answer the five decisions for it in writing. If you cannot answer all five, you have found your starting point.

Related reading:

• Top 5 Security Threats CISOs Face in 2026: the threat behaviors making governance urgent. (https://www.lares.com/blog/top-5-security-threats-cisos-2026/)
• Before You Scope Your Next Security Assessment: how to write an RFP that gets real coverage. (https://www.lares.com/blog/before-you-scope-your-next-security-assessment/)
• The Collapse of the Testing Boundary: an agent breakout kill chain mapped to MITRE ATT&CK and ATLAS. (https://www.lares.com/blog/openai-agent-breakout-hugging-face/)
• Why Purple Teaming is Mission-Critical: why point-in-time tests can't catch AI agents that fail in minutes. (https://www.lares.com/blog/purple-teaming-mission-critical-ai-security/)