Guide · AI
AI in production, without leaking your data.
The fastest way to kill an AI project is a data incident the board reads about after the fact. Here is the security and governance that lets you put a model on real data and still defend the decision: where to draw the data boundary, the questions to ask a vendor before you send a single record, and the controls that keep you in the audit and out of the breach notice.
This guide, in 6 parts
The leak risk is a controls problem, not a model problem.
The numbers point one way. Projects get cancelled where the risk controls are inadequate, and the organizations breached through an AI model are almost all the ones with no access controls and no governance policy. The exposure is not the intelligence of the model. It is what data you let it touch and what you can prove about how it was handled.
Good news for the person who has to sign off: every one of these controls is something you can decide, document and check before launch. This guide is the order to do them in.
« What you cannot say about your data, you cannot defend to a board. »
What a production model may and may not touch.
A model is only as safe as the data you connect it to. The first artefact, before any code, is a one-page boundary: the minimum the use case needs on the left, the lines it may never cross on the right. Lift this into your policy and adjust it to your data.
The principle under the table: data minimisation. Send the least that does the job, masked, to a place you can name. Everything else is risk you took on for no return.
Questions to ask before you send a single record.
Most AI in production runs on someone else's model. Before a record leaves your perimeter, get clear answers to these five. A vendor who dodges them is answering them.
Is our data used to train your models, and can we turn that off in writing?
The first question, and the one with the most expensive wrong answer. You want a contractual no, not a setting buried in a console, and confirmation that this holds for every model and feature, including the ones added after you signed. A default that trains on your prompts is a default that leaks your business into someone else's product.
Where does our data physically rest, and who can access it?
Name the region and the legal entity. A model endpoint is still a server in a country with laws, run by staff with credentials. Ask which jurisdiction the data sits in, whether a sub-processor or a foreign parent can be compelled to hand it over, and how access by their own engineers is logged. If they cannot tell you where it rests, you cannot tell your board.
How long do you keep our inputs and outputs, and how do we get them deleted?
Prompts and responses are often retained for abuse-monitoring or quality, sometimes for weeks, sometimes by a human reviewer. Ask the retention window, whether a person ever reads the logs, and how deletion works on request and at exit. Data you forgot was kept is the data that surfaces in the breach notice.
What are your certifications, and will you sign a data-processing agreement?
Ask for current SOC 2 or ISO 27001 reports and read the scope, not just the logo. Insist on a signed data-processing agreement that names the sub-processors, the breach-notification clock, and your audit rights. A vendor who will not put the handling of your data in a contract is telling you how they handle your data.
When you have an incident, how and how fast do we hear about it?
Breaches travel down the supply chain. Ask the notification window in hours, what you are told, and who is liable for what. Then ask how their own model is governed: an unguarded vendor is now part of your attack surface, and their gap becomes your disclosure.
The controls that keep it governed.
Four moves, in order. They are what turns a model running on your data into a system an auditor and a regulator can sign off.
Write the data boundary before you connect anything
Decide, in writing, the smallest set of data the use case needs, and the lines it may never cross. Mask names, IDs and contact details at the source so personal data does not leave your perimeter in the clear. The boundary is a one-page document an auditor can read, not a setting someone remembers to flip. Build it first, because retrofitting a boundary onto a system already wired to everything is how data leaks.
Keep a human in the loop where the action is irreversible
Decide up front which outputs a person reviews and which actions the model may never take alone: a payment, a deletion, a message to a customer, a change to a record of fact. Start with the model proposing and a person approving, and widen its autonomy only as the results earn it. Human review is not a lack of ambition; it is the control that lets the system touch real data and real customers at all, and the one a regulator expects to find.
Put it under change control, like any other production system
An AI feature that changes behaviour when the vendor ships a new model version is a production system, so govern it like one. Log who changed the prompt, the model, the data access and the thresholds, and require a review before any of them move. Decision logging and traceability are what let you reconstruct, months later, why the system did what it did. Without that record there is no audit, only an apology.
Decide who owns the running of it, and the disclosure
Name one accountable owner who watches what the model touches, holds the runbook, and can pull it offline. That person also owns the disclosure obligations: where law now requires you to tell a person they are dealing with AI, or to run and publish a bias audit before the system screens them. Governance with no owner is a policy nobody enforces until the incident makes it everyone's problem.
Disclosure is arriving in law. New York City's Local Law 144 already carries penalties of 500 to 1,500 dollars per day, each day a separate violation, and the EU AI Act's transparency rules apply from August 2026. Treat the obligation to tell people, and to audit, as part of the build.
The board-defensible checklist.
You can put AI on real data and defend the decision when you can tick all six. Until then, you are carrying a risk you cannot yet explain.
- A written data boundary: the minimum data the use case needs, and the lines it may never cross.
- Personal data masked at the source, so names and IDs do not leave your perimeter in the clear.
- Vendor terms in a signed agreement: no training on your data, named region, retention and deletion, breach clock.
- A human in the loop on every irreversible action the model could take.
- Change control and decision logging, so you can reconstruct why the system did what it did.
- A named owner who can pull it offline and who holds the disclosure and audit obligations.
Frequently asked.
How do we put AI in production without leaking our data?
Start with a written data boundary: the smallest set of data the use case actually needs, with names, IDs and contact details masked at the source so personal data never leaves your perimeter in the clear. Pin the vendor terms in a signed agreement that says your data is not used for training, names the region it rests in, and sets retention, deletion and a breach-notification clock. Keep a human in the loop on any irreversible action, put the whole thing under change control with decision logging, and name an owner who can pull it offline. None of that is a model choice; it is the governance that lets the model run on real data safely.
What questions should we ask an AI vendor before sending our data?
Five, in order. Is our data used to train your models, and can we turn that off in writing. Where does the data physically rest, and who can access it. How long do you keep our inputs and outputs, and how do we get them deleted. What are your certifications, and will you sign a data-processing agreement that names your sub-processors. And when you have an incident, how and how fast do we hear about it. A vendor who cannot answer these clearly is one whose handling of your data you cannot defend to a board.
Do we have to tell people when we use AI on their data?
Increasingly, yes, and the obligations are arriving fast. New York City's Local Law 144 already requires a bias audit and candidate notice before an automated tool screens applicants, with civil penalties of 500 to 1,500 dollars per day, and each day counts as a separate violation. The EU AI Act's transparency rules, which apply from August 2026, require that people are told when they are interacting with AI and that AI-generated content is marked. Treat disclosure and audit as part of the build, owned by a named person, not as something to bolt on after launch.
Is it safer to keep AI on our own infrastructure?
Not automatically. Self-hosting gives you control over where data rests and who can reach it, which matters for sensitive records, but it moves the whole burden of access control, patching and monitoring onto you, and IBM found that 97 percent of organizations breached through an AI model lacked proper access controls. A well-governed vendor with a signed agreement can be safer than a self-hosted model nobody is watching. The deciding factor is not where the model runs, it is whether the boundary, the access controls and the logging are real in either case.
How do we make this defensible to our board?
A board does not need the model explained; it needs to see the decision was made carefully. Show the one-page data boundary, the signed vendor terms, the point where a human reviews irreversible actions, the change log, and the named owner who can pull it offline. That record is the difference between a controlled decision and a personal liability if something goes wrong. We use our Hub Map to find where the data, the value and the risk actually sit before any of it is built.
You can draw much of this yourself. Most teams can write the boundary, ask the vendor questions, and read the checklist without help.
Bring us in for the hard part: drawing the boundary on data that is messier than any policy, sizing the controls to what the model can actually reach, and getting it live with a record that holds up in a review. Our Hub Map is how we find where the data, the value and the risk really sit. See the Hub Map, and how we get models to production safely in AI in production.
Have to defend an AI decision to a board?
No deck, no gate. A working session on the real data and the real vendor terms, with the operators who would get it live and keep it defensible.