Field Notes / AI governance
AI governancePractical AI governance and compliance.
Leaders ask how to stop data leaking into AI. Underneath are two different problems: compliance, which is mostly settled when you buy the tool, and governance, which is yours to own.
I have had this conversation with a lot of leaders by now. It nearly always opens with the same question: how do we stop our data from leaking? Keep listening, and it turns out they are worried about quite different things.
Some are worried the model will train on their data, and that their customer list or pricing will turn up in someone else’s answer. Some are worried about an employee using the tool to pull out everything they can reach, in minutes, on the way out of the door. And some are mostly worried on behalf of their people: how do we stop a well-meaning employee from making a mistake they did not know was a mistake?
These are three different problems. The first is compliance, and it is largely solved before anyone types a prompt. The other two are governance, and nobody solves them for you. Mixing them up is how companies end up either banning AI or approving it without thinking about it at all.
Adopting AI is not all or nothing. The risks are known, and you do not have to solve them from scratch.
Compliance: two questions about your data
Will the AI train on my data?
Providers store prompts to run the service. But the API and enterprise tiers offer zero-retention options, where nothing is kept. In the providers’ own chat apps, the control is a training opt-out. Either way, do not rely on a settings page. Confirm it in the contract and the data processing agreement.
If you want maximum control, you can run your own solution. That moves the problem instead of removing it: you now owe the security, the access control and the logging yourself.
What about privacy and GDPR?
Privacy is handled by normal vendor due diligence, the same checks you run when you buy mail, chat or any other system. Where is the data processed? How long is it kept? Which subprocessors are involved? Is zero retention available? Do you need a data protection impact assessment? And if data has to stay in the EU, there are plug-and-play options that keep it there, such as Microsoft Copilot or Mistral.
The trap nobody mentions
The thumbs-up and thumbs-down buttons under an answer can send that whole conversation to the provider for review and training, even when training is switched off for your account. It is exactly the kind of mistake a careful employee makes without knowing it. If you use tools from Anthropic or OpenAI, tell people not to use the feedback buttons. I wrote about this and the other settings in the guide for board members.
Compliance is largely a procurement decision. Run your normal due diligence, secure zero retention, choose where the data lives, and put it in the contract.
Governance: three risks you own
Governance starts with an AI policy. Decide what AI may be used for, and which data may go into it. Tools can then technically limit use to those cases. Without the policy, the tools have nothing to enforce.
Once the policy exists, there are three risks left, and they are yours.
Output you cannot trust
How do you stop wrong or made-up output from reaching customers? Set clear rules for which tasks AI output is allowed for, and how it is checked before it leaves the building. AI can draft an email in the right tone. It cannot decide your terms and conditions.
Actions nobody intended
Agents can now act inside your systems, not just answer questions about them. How do you get the upside without an agent doing the wrong thing? You want AI to improve your documentation, not erase internal knowledge or fill the wiki with confident nonsense. This is where most well-meaning mistakes happen, and where protecting employees matters most: the safest agent is one that can only do what its task needs.
People who want to misuse it
AI makes harmful actions trivial. The risk comes from insiders, compromised accounts and tools with more access than they need. The one that makes leaders go quiet:
A resigning employee can simply ask the AI to export the data they want to take.
What stands between you and that is not the model. It is access limits and activity logs: the AI can only reach what the person should reach, and someone can see what was pulled out.
Some control is a setting. Real control is an architecture.
Standard tools give you real controls, but only up to a point. On a business or enterprise plan you can get zero retention and no training, choose where data is processed, pick which connectors are allowed and limit which teams have access. That is useful protection. It lives inside someone else’s system, on their terms.
Beyond that point, control is not something you switch on. It is something you build. When you need to guarantee behaviour, permissions and where data lives, you run the environment yourself: a gateway you own with keys, spend limits, logging and per-user access, and models you choose, in some cases fully local so nothing leaves the building. The good news is that this is assembled from proven building blocks, not written from scratch.
Most companies do not need to go all the way. It helps to see the options as a spectrum.
- Standard tools. ChatGPT or Claude straight from the provider. You get their features, but little ability to protect data or control behaviour beyond the settings they offer.
- Proxy and control. A gateway in front of the AI. You can monitor spend, set access limits and route simple work to cheaper models. Enough for compliance and basic governance.
- Targeted tools. Specific tools that add value under control, for example analytics on your own data with governed sharing.
- Your own setup. The most control across every use case, with the best models and minimal risk of leaks. It still needs policies, ownership and monitoring.
Be realistic about what control buys
You cannot fully stop people from going around this. A private account is one browser tab away. The infrastructure is there to make the right way the easy way and to prevent unintended mistakes, not to act as a hard wall. And every restriction you add also removes use cases, so the balance matters as much as the controls.
That is why the useful question is not whether you can control AI. You can. It is how much control you need, how much you are willing to invest in it, and how much friction you will accept for your employees. For the leader worried about training, the answer is usually a contract. For the leader worried about extraction, it is access limits and logs. For the leader worried about their people, it is a clear policy and tools that make the safe choice the default.
If you need to go further than the settings allow, I have written up the practical side in a guide to a safe AI environment with your own rules.