A customer, an auditor, or your own board will ask this first. Most companies answer it with a feeling rather than a fact. It has an actual answer. You can find it in an afternoon, and you do not need a lawyer to get most of the way there.
The question is not whether to let company information near AI systems. That decision was made for you, months ago, by employees with a browser. The question is where the line sits and whether anyone can state it.
Classify the data, not the tools
The instinct is to make a list of approved tools. It fails immediately, because there is a new tool every week and your list is out of date before it circulates. Worse, it answers the wrong question: the risk was never the brand of the tool, it was what somebody put into it.
Classify the information instead. Three tiers are enough for most companies, and a fourth is usually someone enjoying themselves:
- Public. Already outside the building. Marketing copy, published documentation, anything on the website. Use whatever you like.
- Internal. Not secret, but not for outsiders. Process documents, internal notes, most email, most code. Approved systems only, meaning ones where somebody has read the terms.
- Restricted. Customer records, credentials, financials before they are public, anything covered by an agreement you signed. Named systems, named people, logged access, and a person who owns the decision.
Three tiers travel. An employee can hold three categories in their head and apply them without opening a document. That is the only test a classification scheme has to pass. A seven tier scheme is a scheme nobody uses.
Two different questions that get merged
People say "our data goes to the AI company" as though it were one thing. It is two, and the answers are different.
Does it get stored, and for how long? Enterprise agreements commonly include a retention window and often a zero retention option. Consumer accounts on the same underlying model may behave completely differently. This is a contractual question with a written answer.
Does it get used to train future models? A separate question, with a separate answer, usually no by default on business tiers and often yes by default on free consumer tiers. The distinction matters because the second one is the irreversible one. Storage expires. Training does not.
Ask any vendor, in writing
- Is our input used to train your models, and can that be turned off?
- How long is input retained, and can that be set to zero?
- Which subprocessors see it, and in which countries?
- What happens to it if we leave?
Get the answers in writing, keep them with the register from chapter thirteen, and re-check them on a schedule. Vendor terms change, and they change without anyone sending you a note that fits in your inbox.
The boundary you actually control
Vendor terms are the part everyone thinks about. The part that matters more is the one on your side of the wire, because it is the part you can change unilaterally.
A system's exposure is not the data your company holds. It is the data this system can reach. Those are wildly different numbers and the gap between them is a design decision. My own example from chapter two is embarrassingly low-tech, and that is the point. The machine holds no account of mine. Files arrive one at a time, by hand. The exposure of that system is one folder, and I can say so without checking.
The sentence worth being able to say
If this system were fully compromised tomorrow, here is the complete list of what the attacker would have. If that list is not short, or you cannot produce it, the boundary is not designed. It is just wherever the defaults happened to land.
The failure mode that catches people out
There is one risk specific to these systems that has no equivalent in ordinary software, and it is worth understanding even at a non-technical level.
A model does not reliably distinguish between instructions from you and instructions that appear in the material it is reading. If your system summarizes incoming email, and an email contains text addressed to the AI rather than the human, the system may follow it. It has no strong sense that one of those is the boss and one is the mail.
It turns dangerous when three things are true at once. The system reads content from outside your control, it can reach private information, and it can send something out. Any two of those is usually fine. All three together is the shape of a data leak, and it does not require anybody to break in. It requires somebody to send you an email.
The practical response is not a clever filter, because filters get defeated. It is to break the triangle by design. If a system reads untrusted input, it should not also hold the keys to private data. If it holds private data, its ability to send anything outward should be narrow and specific rather than general. This one principle prevents a whole category of incidents and costs nothing at design time.
What to write down
One page, and it can exist before you have a policy:
- The three tiers, with two or three real examples of each from your own company.
- Which systems are approved for which tier.
- The vendor answers to the four questions above, with the date you got them.
- For each running automation, one line: what it can reach, what it can send, and who owns it.
That last list is the one that turns an anxious conversation into a short one. Most companies cannot produce it. Producing it is most of the work.
Revision trail