Does the model learn from my data?
It depends entirely on the contract, not on the technology. And the contract can change: in October 2026 Anthropic changed its usage policy with five weeks' notice. Enterprise AI providers state contractually that data sent through their business interfaces is not used to train models. The free or consumer versions of those same tools usually carry different terms.
The practical conclusion is not “AI is dangerous,” but: the risk is in which version of which tool your team uses, and that is an internal policy decision, not a technology one. An employee pasting a contract into a free personal account is a real problem; the same text processed under an enterprise agreement, with limited retention, is another matter.
Which risks actually happen?
Four, and none of them is the one from the movie:
- Shadow AI. The team is already using tools nobody approved or reviewed. It is the most widespread risk and the least measured.
- Excess permissions. An agent connected to the entire document repository when it only needed two folders. If someone asks it something it should not know, it answers.
- No traceability. With no record of what was asked and what was answered, you cannot audit an incident or demonstrate due care.
- Undeclared international transfer. The processing happens outside the country and the company's policies do not mention it.
How does this fit Colombian data protection law?
If the data the system processes includes personal data — customer names, emails, contact information — then Law 1581 of 2012 applies and the AI provider acts as a data processor.
That carries three concrete obligations: the purpose of the processing has to be covered by the consent the data subject gave, the international transfer has to be covered in your data processing policy, and you have to be able to honor a deletion request, which means knowing where every piece of data ended up.
It is policy and contract work, not technical configuration, and it is worth doing before the pilot rather than after.
What should you ask a vendor?
Six questions that reveal almost everything:
- Is the data I send used to train models? Is that in the contract?
- How long are queries and responses retained?
- In which countries is the information processed and stored?
- What record is kept of each interaction, and who can read it?
- How is the system's access limited to only the information it needs?
- What happens to my data if I end the contract?
A vendor who cannot answer the first and the third in writing is not ready to work with confidential information.
What can be done without the data leaving the company?
More than people assume, and there is a range between “everything to the cloud” and “nothing leaves”:
| Approach | What leaves the organization | When it makes sense |
|---|---|---|
| Cloud service under an enterprise agreement | The content of each query, under contract | Most business cases |
| Anonymization beforehand | Only text with no identifying data | Analysis and classification where identity does not matter |
| Local retrieval, external generation | Only the fragment needed, not the repository | Querying internal documentation |
| Model deployed on your own infrastructure | Nothing | Regulated data or a strict contractual restriction |
The last option is the safest and the most expensive to run. Choosing it without needing it is as common as the opposite mistake.
What is the right order to approach it?
Classify before connecting. Before choosing a tool, define three levels of information: what can be processed by an external service as-is, what requires anonymization first, and what does not leave the organization under any circumstances.
With that classification done, the technical decision becomes almost automatic, and the project stops being discussed in terms of fear and starts being discussed in terms of scope. That exercise is part of the architecture design, not an annex added later, because changing it afterwards means redoing the integrations.