Si tu IA procesa datos de clientes en Colombia, la Ley 1581 de 2012 aplica completa y la SIC ya lo fiscaliza: con la Circular Externa 002 de 2024 tienes que declarar la IA en el aviso de privacidad, mandarle al modelo el mínimo dato posible y demostrar qué se envió y a quién.
Qué cambió con la Circular Externa 002 de 2024
La SIC no创造了 una ley nueva: traduce la existente al contexto de la IA. La diferencia práctica es que la fiscalización ya no se queda en formularios ni cookies, sino que revisa sistemas automatizados que tratan datos personales. Si tu chatbot, tu transcripción de llamadas o tu generador de correos trabaja sobre información de clientes, quedas dentro del alcance.
La circular también cambia dónde se mira. El título de la política importa menos que lo que el sistema hace realmente. Y la diferencia entre lo que informas y lo que ocurre se convierte en el hallazgo más fácil deakamarkar en una revisión.
Las cuatro obligaciones que ya aplican
1. Finalidad declarada y real
La finalidad que informas al titular tiene que coincidir con lo que el sistema hace. Si el aviso dice que sus datos se usan para "atender sus solicitudes" y en realidad alimentan un modelo que prioriza cartera o redacta perfiles de consumo, hay una finalidad no autorizada. Corregir eso pasa por reescribir el aviso, no por cambiar el código.
2. Aviso de autorización y aviso de privacidad: dos documentos
El aviso de autorización es el que firmas el cliente; el aviso de privacidad es el que publicas. Ambos importan y ninguno reemplaza al otro. La circular es explícita sobre el segundo: debe informar el tratamiento, la finalidad y las transferencias que ocurren cuando el dato entra a un proveedor de IA.
3. Minimización y separación entre el dato que identifica y el que entrena
El principio de finalidad y el de minimización se vuelven técnicos: el modelo debería recibir el mínimo, en la forma menos identificable posible. No es lo mismo pasar correo@cliente.com que pasar un identificador derivado y estable, con el mapa de reversión guardado aparte y con control de acceso.
4. Control de acceso y trazabilidad
Quién desarrolló el sistema, con qué permisos accede a los datos, qué se envió a la API y quién lo aprobó. Eso ya no es un archivo de política: es un registro con fecha. En Drupal significa revisar roles, permisos de campo y el historial del sistema de registro.
Qué debe decir tu política de privacidad cuando hay IA
En un sitio Drupal, el punto de partida es el módulo privacy_policy del core, que ya publica una política bajo una URL estable y permite versionarla. Sobre eso, el trabajo real es de contenido. Revisa que la política contenga, como mínimo:
- Identificación del responsable y de sus datos de contacto, y del tratamiento que hace.
- Finalidades concretas, con la IA nombrada como parte del proceso cuando aplique: "usar un modelo de lenguaje para redactar respuestas de soporte".
- Datos tratados: qué campos, de qué clientes, con qué periodicidad.
- Transferencias a terceros: nombre del proveedor de IA, o al menos la categoría de proveedor, el propósito y si la información se usa para entrenar sus modelos.
- Derechos: cómo ejercerlos, ante quién responder y en qué plazo.
- Retención: cuánto tiempo se conservan datos, prompts, respuestas y registros.
- Medidas de seguridad técnicas: cifrado, control de acceso, anonimización o seudonimización.
El módulo hmdp de la comunidad ayuda a mapear qué campos son sensibles y a generar secciones de la política a partir de esa clasificación. Si tu información de contacto vive en un content type, es preferible generar esos campos desde el nodo y no escribirlos a mano.
Cómo anonimizar en PHP y Drupal antes de llamar la API
El error más común y más caro es mandar el objeto completo. La solución es una lista blanca: construir el payload con solo lo que el modelo necesita.
// Drupal 11 — src/Service/OrderPayloadBuilder.php
namespace Drupal\mi_modulo\Service;
use Drupal\Core\Config\ConfigFactoryInterface;
use Drupal\Component\Utility\Hash;
class OrderPayloadBuilder {
public function __construct(
private ConfigFactoryInterface $configFactory,
) {}
public function build(array $pedido): array {
$secreto = $this->configFactory->get('mi_modulo.settings')->get('pseudonym_secret');
return [
'cliente_ref' => 'cli_' . substr(
Hash::hmacBase64((string) $pedido['cliente_id'], (string) $secreto),
0,
24
),
'canal' => $pedido['canal'],
'total' => $pedido['total'],
'productos' => array_map(
fn (array $item) => ['sku' => $item['sku'], 'cantidad' => $item['cantidad']],
$pedido['productos']
),
// Explícitamente fuera: nombre, correo, teléfono, dirección, documento.
];
}
}
Dos detalles que marcan la diferencia en una revisión:
- El secreto con el que se calcula el HMAC no debe vivir en configuración exportable (queda en el repo y en el despliegue). Usa variables de entorno, credenciales del servidor o el módulo
Key. - El mapa que traduce
cliente_refa la persona real debe vivir en una tabla separada, con acceso restringido a un rol concreto. Sin ese mapa, el dato es seudonimizado; con acceso abierto, es solo un pseudónimo de adorno.
Agrega una prueba que impida la regresión. Es la forma más barata de mantener la regla:
// Drupal 11 — tests/Unit/OrderPayloadBuilderTest.php
public function testPayloadNoExponeDatosPersonales(): void {
$payload = $this->builder->build($this->pedidoConDatosReales);
$json = json_encode($payload, JSON_THROW_ON_ERROR);
$this->assertStringNotContainsString('andres@example.com', $json);
$this->assertStringNotContainsString('3001234567', $json);
$this->assertStringNotContainsString('CC 1.234.567', $json);
}
El inventario que necesitas para el Registro Nacional de Bases de Datos
La SIC administra el RNBD, donde se declaran las bases con datos personales que alcanzan los criterios que la entidad fija (volumen de titulares o tratamiento de datos sensibles). No esperes a armarlo en un Excel a mano: genera un inventario técnico reproducible con Drush y consérvalo fechado junto con la versión de tu sitio.
# Drupal 11 — columnas de identidad en las tablas base del sistema
drush sql:query "SELECT table_name, column_name
FROM information_schema.columns
WHERE table_schema = DATABASE()
AND table_name IN ('users_field_data', 'user__data', 'sessions', 'watchdog')
AND column_name IN ('name', 'mail', 'pass', 'status', 'timestamp', 'hostname');"
# Campos de negocio que guardan datos de contacto o ubicación
drush sql:query "SELECT DISTINCT field_name
FROM information_schema.columns
WHERE table_schema = DATABASE()
AND table_name LIKE 'field_data_field%'
AND (field_name LIKE '%phone%' OR field_name LIKE '%address%' OR field_name LIKE '%document%');"
Sobre esa salida armas el formulario: qué tablas contienen datos de personas, para qué se usan, cuántos titulares, si hay datos sensibles y quiénes son los terceros a quienes se transfieren. En un proyecto con IA, esa última fila es el proveedor del modelo, y es la que antes nadie llenaba.
Qué cláusulas pedir en el contrato con el proveedor de IA
La Circular Externa 002 de 2025 puso el foco en transferencias de tecnología que involucran datos personales: verificación previa de cumplimiento, protección desde el diseño, anonimización o seudonimización cuando sea viable y garantías contractuales entre las partes. En la práctica, eso se traduce en cláusulas que debes pedir por escrito:
- Limitación de la finalidad: el proveedor usa tus datos únicamente para prestarte el servicio.
- No entrenamiento: ninguna anotación queda usada para entrenar o mejorar modelos propios o de terceros, salvo autorización expresa.
- Lista de subencargados y mecanismo para que te avises cuando agregue uno.
- Ubicación del procesamiento y, si hay transferencia internacional, las garantías de ese flujo.
- Retención y eliminación al terminar el contrato, con plazo cierto.
- Notificación de incidentes en un plazo corto y definido, no "tan pronto como sea razonablemente posible".
- Auditoría y derecho a pedir evidencia del cumplimiento.
- Acuerdo de tratamiento de datos firmado, con confidencialidad, seguridad y ayuda a la atención de derechos de titulares.
El texto oficial está en la sede electrónica de la SIC y los criterios técnicos de Drupal 11 están en la documentación oficial de Drupal.
Qué cambia si el proyecto de ley de IA avanza
El Proyecto de Ley 043 de 2025 fue radicado ante el Senado el 28 de julio de 2025 y recibió mensaje de urgencia el 10 de septiembre de 2025. Tópicamente clasifica los sistemas por nivel de riesgo y crea deberes adicionales para los de alto riesgo. Al ritmo actual sigue en trámite y el articulado cambia entre versiones, así que trátalo como escenario, no como norma vigente: la noticia del Senado sobre su radicación y el seguimiento en el OECD AI Policy Observatory te dan el estado real.
Lo útil de esa separación: las circulares 002 de 2024 y 002 de 2025 ya son exigibles, así que no dependas del proyecto de ley para acatarlas.
Preguntas frecuentes
¿Estoy obligado a registrar mi base en el RNBD por usar IA en un chatbot?
Solo si tu base cumple los criterios que fija la SIC (volumen de titulares o datos sensibles). El criterio exacto está en las resoluciones vigentes del RNBD. Lo que sí es obligatorio, en todos los casos, es saber qué datos tienes y hacia dónde los mandas.
¿Puedo enviarle las conversaciones completas a un modelo de lenguaje?
No es lo recomendable. Los chats contienen nombre, teléfono, documentos y datos de salud con frecuencia. Manda un identificador seudonimizado y los campos que el modelo necesita; la trazabilidad la das con tu propio registro, no con la memoria del proveedor.
¿Me salva tener publicada la política de privacidad en el pie de página?
Ayuda, pero no alcanza. La política informa; lo que te protege es que el tratamiento descrito coincida con el comportamiento real del sistema y que existan aviso de autorización, minimización efectiva, contratos con el proveedor y trazabilidad de accesos.
¿Qué pasa si un cliente no autoriza el uso de sus datos con IA?
Ese tratamiento no se puede ejecutar sobre sus datos, aunque la política general lo anuncie. En un CRM o un ERP eso significa separar la base de autorizados de la que no, y tener el filtro aplicado en consultas, exportaciones e integraciones, no solo en la interfaz.
Tu siguiente paso concreto: esta semana genera el inventario con las consultas de Drush, elige una integración con IA y aplica el payload de lista blanca, y luego agenda con tu abogado la revisión del aviso de privacidad y del contrato con el proveedor. En Saibher trabajamos en Drupal y PHP, y esto es justo el tipo de trabajo que hacemos: dejar la integración lista y con la trazabilidad documentada, para que el problema legal nunca aparezca después.
