Ley 21.719 y software: qué revisar en tus sistemas antes de su entrada en vigencia

Buena parte de las obligaciones de la Ley 21.719 se cumplen —o se incumplen— en el software. Una política escrita no sirve de mucho si el sistema no permite saber quién accedió a un dato, ni eliminar el registro de una persona sin romper la contabilidad.

Este es un checklist técnico: qué capacidades deben tener tus sistemas, cómo verificarlo y qué hacer cuando no las tienen. El marco general de la ley lo cubrimos en qué deberían revisar las empresas.

1. Identificación de usuarios

Qué se exige. Poder atribuir cada acción a una persona identificada.

Cómo verificarlo. Revisa si existen usuarios compartidos del tipo admin, operaciones o sistema usados por varias personas. Es la falla más común y la más fácil de detectar.

Si no lo cumple. Crear usuarios individuales, eliminar los compartidos y establecer una política de credenciales. Es un cambio de configuración, no de desarrollo.

2. Control de acceso granular

Qué se exige. Que cada usuario acceda solo a los datos necesarios para su función.

Cómo verificarlo. Toma un perfil operativo cualquiera y revisa a qué datos personales llega. Si un vendedor puede ver las fichas de personal o las remuneraciones, el control es insuficiente.

Si no lo cumple. Si el sistema soporta perfiles, es configuración. Si no distingue permisos por módulo o por registro, requiere desarrollo o reemplazo.

Punto crítico: el control debe aplicarse también a las consultas de un agente de IA. El agente debe respetar los permisos de la persona que lo consulta, no tener acceso total.

3. Registro de auditoría

Qué se exige. Poder acreditar quién accedió a qué dato, cuándo y desde dónde.

Cómo verificarlo. Pregunta a tu proveedor o revisa el sistema: ¿existe un log de accesos a datos personales, no solo de inicios de sesión? ¿Se puede consultar? ¿Cuánto tiempo se conserva?

Si no lo cumple. Es una de las brechas más habituales en sistemas legados. Muchos registran quién entró, pero no qué consultó. La solución pasa por desarrollo o por una capa intermedia que registre los accesos.

4. Cifrado

Qué se exige. Medidas de seguridad apropiadas al riesgo.

Cómo verificarlo.

En tránsito: que todo el acceso sea por HTTPS con certificado vigente, incluidas las conexiones internas y las integraciones.
En reposo: que la base de datos y los respaldos estén cifrados.
Datos sensibles: cifrado adicional a nivel de campo cuando corresponda.

Si no lo cumple. El cifrado en tránsito es rápido de resolver. El cifrado en reposo depende de la plataforma; en servicios cloud suele ser una opción a habilitar.

5. Eliminación selectiva

Qué se exige. Poder suprimir los datos de una persona cuando ejerce ese derecho o cuando vence el plazo de conservación.

Cómo verificarlo. Es la prueba más reveladora. Pregunta: ¿puedo eliminar todos los datos personales de un cliente específico sin romper la integridad del sistema?

La respuesta suele ser no, porque el registro está referenciado por facturas, movimientos y documentos que deben conservarse por obligación legal.

Si no lo cumple. La solución habitual es la anonimización en lugar de la eliminación: se reemplazan los datos identificatorios manteniendo el registro contable. Requiere desarrollo, y conviene diseñarlo antes de que llegue la primera solicitud.

6. Plazos de conservación aplicables

Qué se exige. Que los datos no se conserven más allá de lo necesario.

Cómo verificarlo. ¿Existe un proceso que elimine o anonimice datos vencidos, o todo se guarda indefinidamente?

Si no lo cumple. Definir plazos por tipo de dato e implementar un proceso automático. Sin automatización, la política no se aplica en la práctica.

7. Respaldos

Qué se exige. Que los respaldos también estén protegidos y sujetos a plazos.

Cómo verificarlo. ¿Dónde están? ¿Están cifrados? ¿Quién puede restaurarlos? ¿Cuánto tiempo se conservan? ¿Qué pasa con un dato eliminado que sigue presente en respaldos antiguos?

Si no lo cumple. Definir política de retención de respaldos y documentar cómo se tratan las supresiones respecto de ellos.

8. Ambientes de desarrollo y pruebas

Qué se exige. El tratamiento en ambientes no productivos también está regulado.

Cómo verificarlo. Pregunta si el ambiente de pruebas usa una copia de la base productiva. La respuesta afirmativa es muy frecuente y constituye un riesgo directo.

Si no lo cumple. Anonimizar o generar datos sintéticos para desarrollo y pruebas. Es una de las correcciones con mejor relación entre esfuerzo y reducción de riesgo.

9. Portabilidad

Qué se exige. Entregar al titular sus datos en un formato estructurado y de uso común.

Cómo verificarlo. ¿Puedes exportar todos los datos de una persona en formato CSV o JSON, desde todos los sistemas donde estén?

Si no lo cumple. Requiere desarrollo, especialmente cuando los datos están repartidos entre varios sistemas.

10. Detección y notificación de brechas

Qué se exige. Detectar incidentes de seguridad y notificarlos.

Cómo verificarlo. ¿Existen alertas ante accesos anómalos, descargas masivas o intentos fallidos repetidos? ¿Alguien las revisa?

Si no lo cumple. Implementar monitoreo y definir el procedimiento de respuesta. La detección tardía agrava tanto el daño como la exposición.

11. Contratos con proveedores tecnológicos

Qué se exige. Regular el tratamiento que hacen terceros por tu cuenta.

Cómo verificarlo. Revisa los contratos de hosting, CRM, correo, herramientas de IA y desarrollo. Deberían establecer finalidad, instrucciones, medidas de seguridad, subcontratación, ubicación de los datos y devolución o eliminación al término.

Punto crítico en IA: verificar explícitamente si el proveedor usa los datos enviados para entrenar sus modelos. Lo desarrollamos en IA privada con datos empresariales.

Resumen de prioridades

Control	Esfuerzo	Riesgo si falta	Prioridad
Usuarios individuales	Bajo	Alto	1
Datos reales en pruebas	Bajo	Alto	1
Cifrado en tránsito	Bajo	Alto	1
Revisión de contratos	Bajo	Alto	1
Control de acceso granular	Medio	Alto	2
Registro de auditoría	Medio	Alto	2
Plazos de conservación	Medio	Medio	2
Anonimización selectiva	Alto	Medio	3
Portabilidad	Alto	Medio	3
Monitoreo de brechas	Medio	Alto	2

Las cuatro primeras son de bajo esfuerzo y alto impacto. Conviene resolverlas antes de planificar cualquier desarrollo.

Preguntas frecuentes

¿Tengo que cambiar mi sistema si no cumple estos requisitos?

No necesariamente. Muchos controles se resuelven con configuración o con una capa intermedia que registre accesos y aplique permisos. El reemplazo se justifica cuando el sistema no permite identificar usuarios ni segmentar accesos de ninguna forma.

¿Cómo elimino datos de un cliente si tengo obligación de conservar sus facturas?

Mediante anonimización: se eliminan o reemplazan los datos identificatorios y se conserva el registro contable con un identificador no atribuible. Es el mecanismo estándar para conciliar el derecho de supresión con las obligaciones tributarias.

¿Usar una copia de la base productiva en pruebas es una infracción?

Es un tratamiento de datos personales sin una finalidad legítima asociada y generalmente sin las mismas medidas de seguridad que en producción. Es una de las prácticas que conviene corregir primero, y su solución —anonimizar o usar datos sintéticos— es relativamente simple.

¿Los sistemas en la nube cumplen automáticamente?

No. El proveedor cloud aporta capacidades de seguridad, pero la configuración, los permisos, los plazos de conservación y el cumplimiento contractual siguen siendo responsabilidad de tu empresa.

¿Qué pasa con los datos que están en planillas Excel?

Están sujetos a las mismas obligaciones y suelen ser el punto más débil: sin control de acceso, sin registro de quién las abrió y frecuentemente duplicadas en varios computadores. Migrarlas a un sistema con controles es una de las medidas de mayor impacto.

Auditemos tus sistemas con criterio técnico

En Syscode revisamos e implementamos los controles técnicos que la Ley 21.719 exige: accesos, trazabilidad, anonimización, retención y adecuación de integraciones.

Agenda un diagnóstico y prioricemos las brechas de tu operación.

Este contenido es informativo y no constituye asesoría legal. Para decisiones de cumplimiento, consulta con un especialista en protección de datos.