Governance
AI policy tied to enforcement mechanisms and operational evidence.
Governance defines the organization's rules for AI and the mechanisms that enforce them.
Connect policy to enforcement
An AI policy may prohibit customer data in unapproved tools and require approved models. It can also set review requirements for customer-facing deployment.
Builders may never encounter a policy stored in a separate wiki. If the delivery path does not apply its rules, the resulting system can bypass them without a deliberate decision.
Use the policy document to record intent, then identify the enforcement mechanism for each rule. Label a rule with no mechanism as a statement of intent.
Enforcement points
Each rule has an enforcement point in the component that processes the action.
| Policy | Enforcement point |
|---|---|
| Only approved models | The routing layer, by classification |
| No customer data to unapproved endpoints | Routing plus redaction at the gateway |
| Customer-facing deployments get review | Ingress: public exposure requires approval |
| Agents cannot write to production without approval | Tool permissions and a broker, in Run |
| Retention limits | Lifecycle policy on the store, in Control |
| Spend limits | Quota at the gateway, in cost |
These mechanisms live in the platform components that process the action. A governance tool can record the rules and evidence, while enforcement remains in the runtime components.
Data exfiltration is the risk register's blind row
Most GRC risk registers carry data exfiltration as a network and endpoint risk. AI adds channels the existing controls do not see, and they all reduce to one visibility question: do you know, today, what data your AI systems are sharing and accessing, internally and externally? If answering needs an investigation, the answer is no.
The AI channels, each with its own enforcement point:
| Channel | Direction | Enforcement point |
|---|---|---|
| Pasted into a prompt on an unsanctioned tool | internal to external | The sanctioned path plus discovery, in shadow AI |
| An assistant reading beyond the asker's entitlements | internal to internal | Read as the user, in identity |
| An agent with open egress, confused or compromised | internal to external | Egress allow-lists at the runtime |
| Retrieved documents carried into provider logs | internal to vendor | Retention terms and routing, in keys and models |
| Credentials and records sitting in traces | internal to internal | Redaction before storage, in traces |
| Bulk export through many small authorized queries | internal to external | Volume monitoring on metrics, quotas per user |
Two properties make the row auditable rather than aspirational. Every AI data access carries the identity it was made under, which makes "what did AI access" a query. And every outbound channel is enumerated, which makes "what is AI sharing" a finite list instead of a shrug. The EchoLeak and Slack AI entries show what the missing row costs.
Decisions that unblock work
Document the decisions teams need before they can deploy, along with the enforcement point for each one:
- Map data classifications to allowed endpoint types.
- List the actions that require human approval before execution.
- Define which systems may be customer-facing and who approves them.
- Express agent autonomy through specific tool permissions.
- Set retention requirements and periods.
Approval fatigue
Frequent approval prompts train reviewers to click through without reading. Limit prior approval to actions where the reviewer can make a meaningful decision.
Reserve approvals for actions that are irreversible, externally visible, or expensive. Everything else should be permitted and recorded, with the review happening after the fact on a sample.
A default password and 64 million job applicants
The McHire recruitment chatbot could be reached with an administrator account whose username and password were both 123456. Behind it, an insecure direct object reference in the internal API let any authenticated account walk the applicant table.
The skipped letter. Secure. The chatbot lacked the access controls used elsewhere in the estate. An admin credential that would fail any password policy survived because nobody treated the chatbot as production infrastructure, and no audit covered it.
AI Incident Database, incident 1179 / Dark Reading: Lessons learned from McDonald's big AI flub
Questions to ask your vendor, or your own team
- For each rule in your AI policy, name the mechanism that enforces it.
- Which data classifications may reach which endpoints, and what checks?
- What actions require human approval, and how often does that approval get clicked through without reading?
- Who signs off on a customer-facing AI deployment, and what do they see?
- If an engineer wanted to break the policy today, what would stop them?
- When was the policy last changed in response to something you learned?