¿Tu ERP puede cumplir con la Ley 21.719? Ocho cosas que tiene que poder hacer

La Ley 21.719 no menciona la palabra «ERP» ni una sola vez. Habla de responsables, titulares, finalidades y bases de licitud.

Y sin embargo, casi todas sus obligaciones terminan aterrizando en el mismo lugar: el sistema donde efectivamente viven los datos de sus clientes y trabajadores.

Este artículo no explica la ley — eso ya está bien explicado en muchos sitios de abogados. Explica qué tiene que poder hacer su sistema para que esa ley se pueda cumplir. Es la parte que un abogado no puede resolver y que se descubre tarde.

Cuánto cuesta equivocarse

Partamos por el número, porque es el que cambia la conversación. La ley clasifica las infracciones en leves, graves y gravísimas, y fija para cada una un tope de multa.

Categoría	Sanción	Tope en pesos
Leve	Amonestación o multa de hasta 5.000 UTM	$358.245.000
Grave	Multa de hasta 10.000 UTM	$716.490.000
Gravísima	Multa de hasta 20.000 UTM	$1.432.980.000

Son topes, no montos fijos: la Agencia determina cada multa considerando atenuantes y agravantes. Pero el orden de magnitud es el punto. El tope de una infracción leve supera los 350 millones de pesos, y para una empresa mediana cualquier cifra de esta escala deja de ser un costo administrativo.

Tres cosas de esta tabla que sorprenden a casi todos:

• «Leve» no significa barato. La infracción más fácil de detectar de toda la ley es leve: no publicar qué datos se tratan, con qué base legal y por cuánto tiempo. Se verifica entrando al sitio web de la empresa, sin fiscalizar nada. Y el tope son 5.000 UTM.
• Hay una categoría residual. Todo incumplimiento que no esté listado como grave o gravísimo es, por defecto, infracción leve. No existen conductas sin sanción.
• Ocultar cuesta el doble que fallar. Sufrir una brecha de seguridad es infracción grave. Omitir deliberadamente su comunicación es gravísima, con el doble de tope. El día del incidente, «arreglémoslo antes de que se note» es la decisión más cara que se puede tomar.

Y hay dos agravantes que conviene conocer. En caso de reincidencia la multa puede llegar hasta el triple. Y por infracciones gravísimas reiteradas dentro de 24 meses, la Agencia puede decretar la suspensión de las operaciones de tratamiento de datos por hasta 30 días, prorrogable por períodos sucesivos hasta que la empresa se ajuste. Para cualquier compañía que dependa de sus sistemas, eso pesa más que la multa.

Las sanciones, además, quedan anotadas durante cinco años en un registro público y gratuito. Aparecen en cualquier licitación y en cualquier revisión de proveedores.

¿Y si postergan la ley?

Hay que decirlo, porque está en las noticias y porque cambia el cálculo de cualquiera que esté leyendo esto. El 1 de septiembre de 2026 el Gobierno ingresó al Senado un proyecto de ley, con suma urgencia, para postergar la entrada en vigencia.

Propone tres cosas:

• Mover la entrada en vigencia del 1 de diciembre de 2026 al 1 de diciembre de 2027.
• Durante los primeros doce meses de vigencia, extender a todos los obligados —no solo a las empresas de menor tamaño— la facultad de la Agencia de imponer una amonestación por escrito en lugar de una multa.
• Ampliar el Consejo de la Agencia de tres a cinco miembros, con mandatos escalonados de seis años.

El Ejecutivo lo fundamenta en la complejidad técnica, institucional y operativa de la implementación, y en la necesidad de que la Agencia esté debidamente constituida antes de ejercer sus funciones. Traducido: el organismo que debe fiscalizar todavía no está en condiciones de hacerlo.

Lo que hay que tener claro

Es un proyecto, no una ley. Mientras el Congreso no lo apruebe y no se publique en el Diario Oficial, la fecha vigente sigue siendo el 1 de diciembre de 2026. Quien hoy afirme que la ley «se postergó» se está adelantando a los hechos.

La amonestación es una facultad, no un derecho. El texto dice que la Agencia podrá amonestar en vez de multar durante el primer año. No dice que deba hacerlo. No es un año de gracia garantizado.

El estándar no cambia ni una coma. Lo que hay que hacer es exactamente lo mismo; solo se corre la fecha. Y una agencia que parte con un año de preparación y un consejo ampliado fiscaliza mejor, no peor, que una que arranca a medio armar.

Por qué esto no debería cambiarle el plan a nadie

Hay tres presiones que no dependen de la fecha de vigencia ni de la Agencia, y que en la práctica llegan antes que cualquier fiscalización.

Los clientes grandes y el Estado. Es el canal por donde va a llegar la exigencia de verdad, y merece su propia sección — está más abajo.

La responsabilidad civil. La indemnización que puede demandar una persona afectada corre por un carril propio, separado de la multa administrativa.

El tiempo que toma el trabajo. Levantar el inventario de datos, revisar los contratos con proveedores, definir plazos de conservación y construir lo que falta en los sistemas toma meses repartidos entre gente que además tiene su pega. Un año adicional no es un año de descanso: es la diferencia entre hacerlo bien y hacerlo a última hora, que es cuando se cometen los errores caros.

Estado del proyecto al momento de escribir: ingresado al Senado el 1 de septiembre de 2026, radicado en las comisiones de Constitución y de Hacienda, sin votación. Actualizaremos esta sección cuando se resuelva.

Si le vende a una empresa grande o al Estado, esto le llega antes

Acá está, en nuestra opinión, el punto que menos se está diciendo y el que más va a determinar cuándo le toca a cada empresa.

Circula la idea de que la ley se va a exigir de verdad solo a las grandes. Conviene precisarla, porque es media verdad. Lo que existe es una facultad de la Agencia para sancionar con amonestación escrita en lugar de multa a las empresas que califican como de menor tamaño según la Ley 20.416, durante los primeros doce meses de vigencia. Tres precisiones sobre eso:

• Es facultativo. La ley dice que la Agencia «podrá», no que deba.
• La amonestación se registra públicamente igual que una multa. El costo reputacional no se evita.
• No exime de ninguna obligación. Es una tolerancia sancionatoria, no una moratoria: lo que hay que cumplir se cumple desde el día uno.

Pero incluso si esa tolerancia funcionara perfecto, no protege del canal por donde la exigencia va a llegar de verdad. Y ese canal no es la Agencia: es el contrato.

Por qué una empresa grande está obligada a exigírselo a usted

La ley obliga al responsable de los datos a regular por escrito su relación con cada proveedor que los trate por encargo: qué datos, con qué finalidad, por cuánto tiempo, con qué medidas de seguridad y qué pasa al terminar el contrato. Y le obliga a elegir proveedores que ofrezcan garantías suficientes.

Léalo del otro lado: una compañía grande no puede cumplir la ley sin exigírselo a sus proveedores. No es buena voluntad ni celo excesivo del área legal — es la única forma que tiene de cumplir su propia obligación. Por eso el anexo de tratamiento de datos va a llegar, y va a llegar a todos.

Con el Estado el mecanismo es idéntico y más rígido. Los organismos públicos son responsables de datos igual que cualquier empresa, y contratan a través de licitaciones. Cuando la exigencia entre en las bases, deja de ser una cláusula negociable y pasa a ser un requisito de admisibilidad: no es que le pongan una multa, es que su oferta queda fuera. Para un proveedor del Estado eso es bastante peor que una sanción.

Cuál es entonces su plazo real

No es la fecha de vigencia de la ley. Es la próxima renovación de contrato o la próxima licitación a la que se presente — lo que ocurra primero. Y esa fecha, para la mayoría de las empresas, es bastante anterior.

Ahí es donde la postergación deja de ser buena noticia. Un año más de plazo para la Agencia no es un año más de plazo para su cliente principal, que va a mandar el anexo cuando le toque revisar contratos, tenga la ley vigencia o no.

La pregunta práctica, entonces, no es «¿me van a fiscalizar?». Es: si mañana su mayor cliente le manda un anexo de tratamiento de datos para firmar, ¿lo puede firmar con tranquilidad? Firmar declarando medidas de seguridad que no existen es un problema bastante mayor que no haber firmado nada.

La prueba de los 30 días

Antes de la lista, haga este ejercicio mental. Toma un minuto y ordena todo lo demás.

¿En cuántos sistemas distintos tendría que buscar? ¿Sabe con certeza que no se le quedaría ninguno?

En casi todas las empresas que hemos visto, la respuesta honesta es que nadie lo sabe. Y esa incertidumbre no es un problema legal: es un problema de arquitectura de sistemas.

1. Saber qué datos personales contiene

Parece obvio y no lo es. Un ERP mediano tiene cientos de tablas y miles de campos, y ninguno viene marcado como «esto es un dato personal».

El RUT de un cliente lo es. El nombre de un contacto lo es. La dirección de despacho lo es. El campo de observaciones donde alguien escribió «llamar al celular de la señora Carmen» también lo es, y no está en ningún inventario.

Lo que hay que poder responder: qué tablas y qué campos contienen datos de personas identificables, y cuáles de esos son datos sensibles.

Y acá hay una particularidad chilena que descoloca a todos: además de los datos de salud, el artículo 2 letra g) clasifica como sensible la situación socioeconómica. No tiene equivalente en la ley europea. Eso significa que la tabla de remuneraciones y cualquier clasificación por nivel socioeconómico están en régimen reforzado: estándar de seguridad más alto, y si hay una filtración hay que avisarle además a los propios afectados, no solo a la Agencia.

Este inventario es la base de todo lo demás. Conviene una aclaración, porque circula mucho lo contrario: la ley no obliga a llevar un registro de actividades de tratamiento — la guía oficial de la Secretaría de Gobierno Digital lo dice textualmente. Lo que sí obliga es a publicar qué categorías de datos se tratan, con qué base legal, por cuánto tiempo y a qué países viajan, y a poder acreditar que el tratamiento es lícito. Y eso es imposible sin el inventario. O sea: el registro no es la obligación, es la única forma de cumplirla.

2. Reunir todo lo de una persona

Acá es donde la mayoría de los ERP falla, y falla por una razón estructural: fueron diseñados para responder «qué pasó con esta factura», no «qué sabemos de esta persona».

Los datos de un mismo cliente están repartidos entre el maestro de clientes, los contactos, las órdenes, las facturas, la cobranza, los despachos, los tickets de soporte y —casi siempre— algún campo de texto libre. Reunirlos exige recorrer todo eso.

Sin una consulta preparada de antemano, responder una solicitud de acceso se convierte en un proyecto de varios días con alguien de TI dedicado. Con la consulta preparada, son minutos.

La recomendación práctica: construir esa consulta ahora, mientras no hay presión. Es un desarrollo acotado que se hace una vez y sirve para siempre.

3. Eliminar sin romper la contabilidad

Esta es la que genera más confusión, y donde la respuesta intuitiva es la equivocada.

Un cliente ejerce su derecho de supresión y pide que borren sus datos. Pero ese cliente tiene facturas emitidas, y la normativa tributaria obliga a conservar esa documentación por seis años. Borrarlo del sistema rompería la contabilidad y crearía un problema mayor que el que resuelve.

El punto fino: un dato realmente anonimizado deja de ser un dato personal y, por lo tanto, sale del ámbito de la ley. Pero «realmente» es exigente. Reemplazar el nombre por «Cliente 4471» no sirve si en otra tabla queda el RUT, ni si el registro es único y reidentificable cruzándolo con otra información.

La pregunta para su sistema: ¿tiene una función de anonimización, o la única opción es borrar el registro entero? Si es lo segundo, hay desarrollo por delante.

4. Saber quién vio qué

La ley exige poder demostrar que se cumple, no solo cumplir. Y hay cosas que sin registro no se pueden demostrar de ninguna forma.

Si ocurre una filtración de datos de clientes, la primera pregunta es quién tuvo acceso. Si el sistema no registra los accesos, la respuesta es «no sabemos» — y esa respuesta, ante la Agencia, se parece mucho a una confesión.

Muchos ERP registran las modificaciones pero no las consultas. Saber quién editó un registro es útil; saber quién lo miró o quién exportó la base completa a Excel un viernes por la tarde es lo que realmente importa en un incidente.

5. Accesos por rol, no «todos administradores»

Es la brecha más común y la más fácil de arreglar.

En muchas empresas medianas, media docena de personas tiene perfil de administrador del ERP porque en algún momento alguien necesitó algo y era más rápido darle todo. Nadie lo revisó después.

La ley pide que el acceso a los datos personales se limite a quien lo necesita para su función. Eso significa que el vendedor no debería poder ver las remuneraciones, y que quien liquida sueldos no debería poder exportar la cartera completa de clientes.

Y el punto que casi nadie revisa: los accesos de quienes ya no trabajan en la empresa. Vale la pena mirarlo hoy.

6. Purgar lo que ya venció

Los ERP no borran nada. Es una virtud contable y un problema de cumplimiento.

Si la política de privacidad declara que los datos de un prospecto se conservan 24 meses —y declarar el plazo de conservación es obligatorio, artículo 14 ter letra i)— tiene que existir algo que efectivamente los elimine a los 24 meses. Declarar un plazo que no se cumple es peor que no declararlo: documenta el incumplimiento por escrito.

Lo que hay que revisar: si el sistema permite definir políticas de retención y ejecutarlas de forma automática, o si eso hoy depende de que alguien se acuerde.

7. El ambiente de pruebas — el que nadie documenta

Este es el que aparece en cero artículos sobre el tema y el que más veces hemos encontrado en la práctica.

Cuando se desarrolla o se prueba una integración, la costumbre universal del rubro es levantar un ambiente de pruebas con una copia de la base de producción. Es lo más cómodo: datos reales, casos reales, se detectan problemas reales.

También significa que existe una segunda copia completa de todos los datos personales de la empresa, habitualmente en un servidor con menos controles, con accesos más laxos, sin respaldo cifrado y a veces en el notebook de un desarrollador.

Esa copia es un tratamiento de datos personales tan real como el sistema productivo, y está sujeta al mismo deber de seguridad del artículo 14 quinquies. Casi nunca aparece en ningún inventario, porque quien lo arma no sabe que existe y quien la creó no sabe que hay que declararla.

Y hay algo peor: copiar la base productiva a un ambiente de pruebas sin autorización del cliente es, para un proveedor de TI, tratar sus datos «con un objeto distinto del convenido» — la conducta del artículo 15 bis inciso 2, que convierte al proveedor en responsable de datos para todos los efectos legales.

La solución correcta no es prohibir los ambientes de prueba: es anonimizar los datos al copiarlos. Nombres, RUT, correos y teléfonos reemplazados por datos sintéticos coherentes que permitan probar igual. Es un desarrollo acotado, se hace una vez y elimina una exposición completa.

8. Las integraciones son flujos de datos

Cada integración que saca datos del ERP es un tratamiento que hay que poder describir, con su finalidad, su destinatario y su base de licitud.

Los casos habituales en una empresa chilena mediana: el sistema de facturación electrónica, la plataforma de despacho, el marketplace donde se vende, el sistema de remuneraciones, la herramienta de correo masivo, el respaldo en la nube.

Dos preguntas por cada una:

• ¿Qué datos salen exactamente? No «se integra con el marketplace», sino qué campos viajan. Muchas integraciones mandan más de lo necesario simplemente porque era más fácil mandar el registro completo.
• ¿A dónde van a parar? Si el destinatario procesa fuera de Chile, es una transferencia internacional y hay que declararla.

El principio de minimización de la ley aplica también acá: solo se debe tratar lo necesario para la finalidad. Una integración que envía el RUT y el teléfono del cliente cuando el marketplace solo necesita el número de orden está tratando datos de más. Escribimos sobre este tipo de decisiones en las siete preguntas antes de integrar sistemas.

Lo que no está en el ERP

Todo lo anterior mira hacia adentro del sistema, y es donde nosotros podemos ayudar con más precisión. Pero sería deshonesto terminar ahí, porque ordenar el ERP no deja a una empresa cumpliendo la ley. Hay tres frentes fuera del sistema que en la práctica concentran tanto riesgo como el sistema mismo.

1. Los datos que viven fuera del sistema

La planilla Excel con las remuneraciones que alguien bajó para hacer un análisis. Los currículums de los postulantes que quedaron en una carpeta compartida. Las licencias médicas escaneadas en el correo de la jefa de personal. El grupo de WhatsApp donde se coordinan los turnos con nombres y teléfonos. Las cámaras de seguridad y el reloj control con huella.

Nada de eso está en el ERP, y todo eso es tratamiento de datos personales con las mismas obligaciones. Un inventario que solo mire el sistema deja fuera, típicamente, la mitad de los datos de la empresa. Y es la mitad peor protegida, porque nadie la administra.

2. Los terceros que reciben esos datos

El contador externo que procesa las remuneraciones. La mutual. La caja de compensación. La plataforma de firma electrónica. El proveedor de nube donde está el respaldo. Todos ellos tratan datos personales por encargo de la empresa, y la ley exige que esa relación esté regulada por escrito: qué datos, para qué, por cuánto tiempo, con qué medidas de seguridad y qué pasa al terminar el contrato.

La mayoría de estas relaciones existe hace años sin ningún documento que las describa. Y la responsabilidad frente al titular de los datos no se traspasa por el hecho de haber contratado a alguien: sigue siendo de la empresa.

3. El propio sitio web

Es el frente más expuesto y el más barato de resolver. La ley obliga a informar públicamente qué categorías de datos se tratan, con qué fundamento, por cuánto tiempo se conservan y a qué países se transfieren; y a tener publicado un medio de contacto vigente para que las personas ejerzan sus derechos.

Eso se comprueba entrando al sitio, sin necesidad de fiscalizar nada ni de pedirle documentos a nadie. Es, con diferencia, la infracción más fácil de detectar de toda la ley — y también la más simple de evitar. Un formulario de contacto que recoge nombre, correo y teléfono sin una política de privacidad detrás ya es un incumplimiento visible desde el navegador.

Ninguno de estos tres frentes se resuelve con software. Se resuelven con un inventario honesto, unos cuantos documentos bien redactados y algunas decisiones sobre qué se deja de guardar. Lo mencionamos porque preferimos que conozca el mapa completo antes de contratarle a alguien —a nosotros incluidos— solo una parte.

Si su ERP no puede hacer varias de estas

Es lo más probable, y no significa que haya que cambiarlo.

Casi ningún ERP del mercado chileno fue diseñado pensando en esta ley, sencillamente porque es nueva. Lo que sí hay que hacer es saber cuáles de estas ocho capacidades faltan, y cerrar las brechas por orden de riesgo.

1. Inventariar

   Qué sistemas contienen datos personales, incluidos los ambientes de prueba, las planillas del área comercial y los respaldos. Esta etapa siempre encuentra algo que nadie tenía presente.

2. Cerrar lo barato primero

   Revisar accesos, dar de baja usuarios que ya no corresponden y sacar la documentación sensible de carpetas compartidas. Cuesta poco y reduce bastante exposición.

3. Construir lo que falta

   La consulta de acceso consolidado, la función de anonimización y la anonimización del ambiente de pruebas. Son tres desarrollos acotados que se hacen una vez.

4. Automatizar la retención

   Que los plazos declarados se cumplan solos, sin depender de que alguien se acuerde.

5. Ensayar

   Simular una solicitud de acceso completa y medir cuánto toma. Es la única forma de descubrir el sistema que faltaba en el inventario.

Ese último paso es el que más recomendamos y el que casi nadie hace. Nosotros lo hicimos primero con nuestra propia empresa, que tiene tres personas y cinco sistemas, y aun así apareció algo que no teníamos considerado.

¿Quiere saber en qué está su sistema?

Nosotros hicimos este ejercicio primero con nuestra propia empresa antes de ofrecérselo a nadie. Lo invitamos a tomarnos un café y revisar su caso: qué sistemas tienen datos personales, cuáles de estas ocho capacidades faltan y qué convendría cerrar primero. Sin costo ni compromiso, y si vemos que están bien, se lo decimos. Conversemos.

Este artículo aborda el ángulo técnico del cumplimiento. Las materias propiamente jurídicas —redacción de políticas, contratos y cláusulas— corresponden a un abogado, y trabajamos junto a ellos en esa parte.