⏱ 5 min read
Conversations about artificial intelligence and sensitive data usually start in the wrong place. People debate whether a given tool is secure, whether it stores conversations, whether it trains on what you type. Reasonable questions, but they arrive late.
The prior question is different: what information from your organization is allowed to leave your organization. Most have not answered it formally. Not out of negligence, but because it was never necessary: while information moved between internal email and shared folders, the perimeter held on its own. Artificial intelligence did not create this problem. It made it visible.
Without that prior definition, any technical control applies to a foundation nobody established. An employee who pastes an entire contract into a chat window is not violating a policy: they are operating where none exists.
What follows are four levels of solution, from simplest to most costly. They are not alternatives to one another. In a real operation, they coexist.
Level 0. Don’t send the data
The most obvious and the least practiced. It is also worth noting that information which should not leave an organization covers two distinct things: personal data, whose protection is imposed by law, and confidential information, whose protection is imposed by contract.
Much of the work done with artificial intelligence does not require the document. It requires the structure of the problem. Drafting a non-compete clause for a services agreement under Mexican law does not need the names of the parties, their addresses, or the amounts. It needs the legal figure, the jurisdiction, and the subject matter.
Before deciding how to protect a document, it is worth asking which part of the task actually depends on the sensitive data. The frequent answer is: none. The full file gets sent out of convenience, not necessity.
This level costs nothing and resolves more cases than one would assume. It deserves to be exhausted before investing in the others.
Level 1. Substituting identifiers
When a document genuinely must be processed in full, the approach is to replace identifiers with keys before sending it, and restore them when the result comes back.
The mechanism is straightforward. A script scans the document, locates identifiers, replaces them with markers, and stores the correspondence in a separate table. The substituted version is sent. When the result returns, the substitution is reversed.
It works well with anything that has fixed form. Tax identification numbers, national identity codes, social security numbers, bank accounts: all have predictable structure and are reliably detected with regular expressions. That part holds.
Names are a different matter, and candor is warranted here. There is no regular expression for personal names. Entity recognition is required, and in Spanish, compound surnames, particles, and corporate names containing proper nouns produce errors in both directions: identifiers that pass undetected, and ordinary words flagged as names.
Contextual reidentification also remains. A document in which every name has been substituted, but which describes the public works director of a specific municipality during a specific period, identifies the person as effectively as naming them would.
And one point tends to be overlooked: the correspondence table. The moment a file exists stating which key equals which person, that file concentrates the entire sensitivity of the process. Where it lives, who can access it, and how long it is retained is half the problem, not an implementation detail.
Practical conclusion: substitution is a useful and accessible layer, not a guarantee. It reduces exposure. It does not eliminate it.
This level is developed in more detail, including published evidence on its actual limits, in Best practices for handling sensitive information before using AI.
Level 2. Your own model, for the right task
Running a language model on your own infrastructure is considerably more accessible today than two years ago. Tools exist that install and run open models with minimal configuration, and a mid-range server is sufficient for medium-sized models. The information never leaves the organization’s network.
That said, it is worth avoiding the kind of enthusiasm that produces disappointment.
A medium-sized open model does not replace a frontier model for complex reasoning. The difference is real and becomes apparent immediately in analysis requiring multiple hypotheses, long context, or detection of subtle contradictions.
Inference without hardware acceleration is also slow. Tolerable for occasional queries; not for volume. And maintenance falls to you: updates, backups, server security.
The correct framing is not “run your own model” but “run a model for the tasks that suit it.” Field extraction from documents, classification by type, duplicate detection, name normalization, first-pass summarization: a local model performs well at all of these, and no information leaves the perimeter. That is the use case that justifies the investment.
For analysis demanding full capability, the answer lies in the next level.
Level 3. Processing under contractual conditions
Artificial intelligence providers offer arrangements where information is not used for training and is not retained beyond processing. It is also possible to run models inside cloud infrastructure the organization already controls, so data never transits third-party systems.
The central point of this level is that the protection is contractual rather than technical. What protects the organization is what was signed: the scope of processing, retention period, security obligations, processing location, and consequences of breach.
For operations in Mexico there is an additional element. When a provider processes personal data on the organization’s behalf, it acquires the status of processor under data protection law, which carries specific obligations. If processing occurs outside national territory, the cross-border transfer regime applies. This is not a formality: it determines whether the processing is lawful.
Before signing, three things merit precise verification: what is retained and for how long, where processing occurs, and what happens to the information when the relationship ends.
This layer and the previous one are developed in In-house model or contract: two ways to use AI without exposing information.
How they combine
No organization operates on a single level.
The usual arrangement is a combination: Level 0 is exhausted for everything that admits abstract formulation; identifiers are substituted for routine work with commercial tools; repetitive volume that does not require deep reasoning is processed locally; and contractual processing is reserved for analysis that genuinely demands full capability over complete information.
Deciding what belongs at each level is not a technical question. It depends on a prior classification of the information, and that classification is the organization’s responsibility, not the provider’s.
That is where to begin. Before choosing a tool, define what information may leave, what may leave transformed, and what may not leave in any form. With that definition in place, the technical choice becomes straightforward. Without it, whatever tool is adopted will be used blind.