AI Governance · POV
Don't Let Your Company Go Rogue on ChatGPT.
An AI Usage Policy Starts With the Operating Model, Not the Document.
The failure mode is familiar: a company writes an AI usage policy, publishes it on the intranet, and six months later still has the same problem, proprietary code, customer data, and strategy notes flowing into consumer AI tools that retain them. The policy did not fail because it was badly written. It failed because there was no governed way to actually use AI behind it, so the only real choice on offer was "don't," and people ignored it. A usage policy that holds is not a document. It is an operating model the document happens to describe.
30-SECOND POV
- The leak is not the missing document; it is the ungoverned operating model. Employees pasting IP into consumer ChatGPT is a governance-architecture failure, not a training gap. Samsung learned this publicly in 2023.
- Bans produce shadow AI. Prohibit the tool people need and they switch to a personal account, where the data leaves with zero governance. You beat shadow AI by out-competing it on convenience, not by prohibition.
- The framework is four things: a sanctioned gateway, a ZDR agreement, model-agnostic routing, and permissions plus audit. Write the policy document after you have built the machine that enforces it, not before.
The real leak is the operating model, not the missing memo
Most organizations respond to AI risk the way they respond to any risk: they write a document. The document is not the problem. The problem is that the document describes a world the organization has not built. It says "use only approved tools" without an approved tool that does the job. It says "do not share confidential data with AI" without a sanctioned place to use AI on the data people actually work with. So the document describes a policy, and the organization runs on a different one, the one where a product manager pastes the roadmap into a consumer chatbot at 11pm because it is the fastest way to get the summary written.
The mechanism of the leak is worth naming precisely, because "ChatGPT can leak data" is too vague to govern against. On a consumer or default tier without a zero-data-retention agreement, prompts and outputs can be stored, human-reviewed, and used to improve models. That means proprietary content does not just get answered: it can persist in a third party’s systems and, in the extreme, surface in the provider’s future capability. In 2023 Samsung confirmed the concrete version: engineers pasted internal semiconductor source code and meeting notes into ChatGPT, and the company moved to restrict generative-AI use on corporate devices shortly after. The Samsung case is cited so often precisely because it is the ordinary case, not an exotic one. It is what happens by default when capable tools meet ungoverned usage.
The instinct after an incident like that is to ban the tool. It is the wrong move, and predictably so. A ban does not remove the need; it removes the governance. The engineer who needed the summarizer still needs it, so they route around the ban through a personal account on personal hardware, which is the single worst data-governance posture available: the same IP leaving the building, now with no log, no ZDR, and no visibility at all. Prohibition does not reduce shadow AI. It manufactures it.
THE FRAMEWORK
Four layers that make a usage policy enforceable
A usage policy holds when there is a governed operating model underneath it, a centralized, sanctioned way to use AI where the rules are enforced by default rather than requested by memo. This is the "don't go rogue" architecture: one controlled surface, with the four controls below layered onto it. It is the inbound mirror of the sovereignty argument: governing what your organization sends to models, the way owning your channel governs what models take from you.
The sanctioned gateway
One centralized path AI traffic flows through, instead of every team hitting consumer tools directly. It is the single surface where every downstream control is enforced, and wiring it into SSO lets you block unapproved tools at the network layer. Without this, everything below is aspirational.
Zero data retention (ZDR)
A negotiated agreement with each model provider that your prompts, outputs, and telemetry are not stored, trained on, or human-reviewed. This is the floor of not-leaking-IP. Cover the metadata gap explicitly: some terms exclude your content from retention but keep derived metadata.
Model-agnostic routing
The gateway routes to any provider and can switch with low friction, so no single vendor is a dependency. Model liquidity is what gives you leverage: if a provider changes its data terms, you can credibly move, and that credible threat is what keeps your data held on your terms.
Permissions and audit
Role-, classification-, and purpose-based access controls that scope which data and tools each person or agent can reach, plus an append-only log of every call (actor, prompt, model, data touched, result). This is what turns "we have a policy" into "we can prove what happened," which is also the record-keeping an EU AI Act auditor asks for.
The document vs the machine
Once the operating model exists, the written policy becomes straightforward, because it is now describing something real. It names the sanctioned tools (the ones on the gateway), states the data-classification rules (the ones the gateway enforces), defines prohibited uses, and sets the oversight and review cadence. That written artifact still matters (an auditor, a new hire, and a business-unit lead all need the human-readable version), and the structure of it is a solved problem. The nine-section AI policy template is the document to write; this page is the framework to build first. Write the manual after the machine, not instead of it.
The distinction is not pedantic. It is the difference between a policy that survives its first compliance review and one that does not. A document with no enforcing framework produces claims the organization cannot evidence: it says usage is logged, but there is no log; it says only approved tools are used, but nothing blocks the others. Under the EU AI Act’s record-keeping and human-oversight obligations, that gap is exactly what a serious review exposes. Governed routing and an audit trail are not bureaucracy for its own sake; they are how you produce the evidence the policy promises.
The six-line governed-usage checklist
This is the operational test of whether your AI usage policy is a control or a memo. Run it against your own program. The failure is almost never the absence of a document; it is that one or more of these six is missing, and the document quietly assumes all six are present.
- A sanctioned path exists and is the easy one: There is an approved, enterprise-tier AI tool under a ZDR agreement that is genuinely more convenient than a personal ChatGPT tab. If the sanctioned path is harder than the shadow path, you have a shadow-AI program, not a governance program.
- Data classification maps to tools: Every data tier has a defined answer to "which AI tools may touch this." Tier 4 (secrets, PII, regulated data) never enters retention-prone external tools. When in doubt, treat data one tier higher than you think.
- ZDR is signed, and the metadata gap is closed: The agreement with each provider excludes not just your content but the metadata derived from it. A ZDR that only covers content is a partial control sold as a complete one.
- Unapproved tools are blocked, not just discouraged: Enforcement lives at SSO / network / edge, not in a policy PDF. A rule that depends on voluntary compliance is a suggestion. Consumer AI endpoints are blocked; the gateway is the way through.
- Every call is logged and attributable: The audit trail can answer "who sent what to which model, and what data did it touch" for any request. Without it there is no way to detect a leak, evidence compliance, or investigate an incident.
- One owner for the operating model, not just the document: A named executive owns the gateway, the approved-tools list, and enforcement, not only the written policy. If the doc has an owner and the machine behind it does not, the doc is decorative.
The position
The centralized, governed operating model is not a constraint the organization tolerates for compliance. It is the thing that lets people use AI aggressively without the CTO lying awake about where the IP went. A single sanctioned gateway with ZDR, model-agnostic routing, and audit is more convenient than a scatter of personal chatbot accounts, and it is the only version that is also defensible. That is the whole move: make the governed path the easy path, and the shadow path stops being worth taking.
This sits inside the broader sovereignty frame. The strategic case for why this matters at the board level, ownership of the value your data creates, is the AI sovereignty piece. The mirror-image decision on the outbound side, owning the channels you publish on so you control what models ingest from you, is digital sovereignty. Within this cluster, vendor capture risk covers the model-liquidity half of layer three, and AI governance roles covers who owns the gateway and the policy. Build the machine; then the document writes itself.
AI Usage Policy: Frequently Asked Questions
What is an AI usage policy?
What is the difference between an AI usage policy and an AI governance framework?
Can ChatGPT leak company data?
How do you stop employees from putting company data into ChatGPT?
What is a sanctioned AI gateway?
How long should an AI usage policy be, and who owns it?
Is an AI usage policy required for the EU AI Act?
Continue the AI governance cluster
The usage policy is the operating model. The rest of the cluster covers the document, the roles, and the vendor-independence half.