Almost any process worth automating with AI touches personal data: customer emails, ID documents, invoices, medical records, bank statements. So at some point in the conversation, someone from legal or risk asks: “Does this comply with Law 1581?”
The good news: Colombia’s data protection law does not prohibit AI. What it requires is that processing has an authorized purpose, is proportionate and is protected. That gets solved in the design of the solution, not with a new paragraph in the privacy policy. In this guide you will see the applicable legal framework, the questions worth answering before you automate and the technical controls that make the difference.
This guide is informational and is not legal advice. Every data processing activity should be validated with your company’s data protection officer or legal counsel.
The legal framework in one minute
| Rule | What it covers |
|---|---|
| Constitution, art. 15 | The right of habeas data: to know, update and correct information collected about oneself |
| Law 1581 of 2012 | The general personal data protection regime: principles, consent, sensitive data, data subject rights, transfers and penalties |
| Decree 1377 of 2013 (compiled in Decree 1074 of 2015) | Regulates consent, the processing policy, transmission to processors and accountability |
| Law 1266 of 2008 | Financial habeas data: credit and commercial information |
| SIC External Circular 002 of 2024 | Specific guidelines for processing personal data in artificial intelligence systems |
The authority is the Superintendence of Industry and Commerce (SIC), through its Personal Data Protection Office.
Who is responsible for what
Law 1581 distinguishes two roles, and understanding them brings order to any conversation with an AI vendor:
- Controller (responsable): whoever decides why and how the data is used. When you automate one of your company’s processes, the controller is still your company.
- Processor (encargado): whoever processes data on the controller’s behalf. The vendor that builds and runs the automation, the cloud it runs on and the AI model service are usually processors.
When data goes to a processor — even outside Colombia — Decree 1377 allows it through a data transmission agreement that sets the scope of processing, the security measures and the processor’s obligations. That agreement is not optional paperwork: it is what lets you show the SIC that the vendor processes data only for what you authorized.
6 questions to answer before automating with AI
1. Is the purpose covered by the consent?
The data subject’s consent must be prior, express and informed, and it covers specific purposes. If you collected data to handle an insurance claim, using it to handle that claim with the help of AI is, in principle, within the purpose. Using it to train a model you will sell to third parties is not. AI does not change the purpose; the tool can tempt you to change it.
2. Is there sensitive data?
The law defines as sensitive any data that affects privacy or whose misuse could lead to discrimination: health, racial or ethnic origin, political views, religious beliefs, union membership, sex life and biometric data. In insurance and financial services it shows up constantly — a medical record in a health claim, a sick leave certificate in a loan application. Processing it requires explicit consent and a higher level of protection.
3. Are you using only the data you need?
Classifying an email does not require sending the full ID number to the model. Minimization — processing only what is essential and masking or pseudonymizing the rest — is the cheapest measure and the one that reduces risk the most.
4. Where is the data processed?
If the model or the cloud is outside Colombia, there is an international data flow. Article 26 of Law 1581 prohibits transferring data to countries without an adequate level of protection, with some exceptions; the SIC publishes its list of adequate countries in its Single Circular. In practice: check the region where data is stored and processed, that the country is on the current list, and that there is a transmission agreement with each processor.
5. Does the model provider learn from your data?
This is the most often forgotten question. Many AI services allow — and some do so by default in their free tiers — using what you send them to improve their models. For personal data, the right setup is no training on your data and no retention beyond what is necessary, and that must be in the contract, not just on a settings screen.
6. Can you honor data subject rights?
Data subjects can access, update, correct and request deletion of their data, and revoke consent. Inquiries must be answered within 10 business days and complaints within 15. If your automation copies data into five different systems, every deletion becomes a problem. Design so that data has a clear lifecycle: where it lives, for how long and how it is erased.
What the SIC expects from AI systems
External Circular 002 of 2024 applies Law 1581 to AI. Its core ideas:
- Proportionality test. Processing data in an AI system must be suitable, necessary, reasonable and strictly proportionate. If the goal can be met with less data, or with anonymized data, that is the option to choose.
- Risk management. Whoever processes data in AI systems must identify, classify, measure, monitor and control the risks, and adopt measures to mitigate them.
- Accountability. Complying is not enough: you must be able to prove it, with documentation, impact assessments and evidence of controls.
- Purpose and consent. Data cannot be collected without consent or used for purposes other than those disclosed — also when the one “using” it is a model.
One point to bear in mind: Law 1581 has no specific rule on fully automated decisions like article 22 of the European GDPR. Even so, keeping a person in the loop on decisions that affect the data subject — rejecting a loan, denying a claim — is the simplest way to meet proportionality and to respond if someone complains.
Technical controls that make the difference
| Risk | Control |
|---|---|
| Too much data sent to the model | Minimization and masking of identifiers before every call |
| Data outside an adequate jurisdiction | Cloud region selection and checking against the SIC list |
| The model provider retains or reuses data | Enterprise services with no training and no retention, by contract |
| Unauthorized access | Encryption in transit and at rest; role-based permissions; least privilege |
| Inability to explain a result | Traceability: every extracted data point linked to its document and the rule applied |
| Adverse decisions without oversight | Mandatory human review before rejecting, denying or refusing |
| Data piling up indefinitely | Retention policies and automatic deletion |
Penalties: why improvising is a bad idea
Article 23 of Law 1581 allows the SIC to impose fines of up to 2,000 monthly minimum wages, suspend processing-related activities for up to six months, order their temporary closure and even the permanent closure of operations involving sensitive data. On top of that comes reputational damage, which in insurance and banking usually weighs more than the fine.
Also remember that companies with total assets above 100,000 UVT must register their databases in the National Database Registry (RNBD). An automation that creates a new personal database must be reflected there.
Common mistakes
- Testing with real data on free tools. Pasting customer emails into a consumer AI chat “to see if it works” is already data processing — and probably an international transfer without a contract.
- Leaving legal for last. If compliance learns about the project once it is built, every adjustment costs twice as much.
- Confusing anonymization with pseudonymization. Replacing a name with a code is still personal data if someone can reverse it.
- Forgetting attachments. The email body gets masked; the scanned ID attached to it does not.
How we approach it at Ditempo
We work with insurers and financial institutions, where data protection is part of the design from day one. During the assessment we map which personal data the process touches, which of it is sensitive and which purpose covers it. From there, the solution processes only what is needed, on enterprise services configured with no training on client data, with traceability and with human review on decisions that affect the data subject. And we document what your data protection officer needs to demonstrate compliance.
See how this fits into a full project in AI process automation, or in a concrete case such as AI claims automation.
Does your AI project touch personal data?
If you have a process in mind and the compliance question is holding you back, tell us what data it involves. In a short conversation we will help you identify the risks and how to solve them in the design. Write to us or talk to us directly on WhatsApp.