1. Reconstruye dónde viven y cómo se mueven los datos
Parte por casos reales, no por el organigrama. Elige procesos que traten datos de clientes, prospectos, colaboradores, proveedores o usuarios y sigue el recorrido desde la captura hasta el archivo, eliminación o transferencia. Incluye ERP, CRM, plataformas SaaS, planillas, formularios, correo, carpetas compartidas y exportaciones locales.
El entregable útil es un mapa operativo que muestre qué dato entra, para qué se usa, quién lo consulta, qué sistema manda cuando existen diferencias y qué copia queda fuera del flujo formal. Esa reconstrucción permite que legal, operación y tecnología discutan sobre la misma evidencia.
- Sistema o canal donde nace el dato.
- Finalidad operacional del tratamiento.
- Responsable interno y equipos con acceso.
- Traspasos entre sistemas, planillas o terceros.
- Regla de conservación, archivo o eliminación.
- Evidencia disponible para reconstruir una decisión.
2. Convierte los derechos de titulares en flujos ejecutables
La Ley 21.719 refuerza derechos de las personas sobre sus datos, incluyendo acceso, rectificación, supresión, oposición, portabilidad y bloqueo. Para una empresa, el riesgo operacional aparece cuando el derecho existe en la política pero nadie puede ejecutar el caso de punta a punta.
Diseña un flujo con entrada, validación, responsable, búsqueda de datos, decisión, revisión cuando corresponda y evidencia de cierre. Si una solicitud exige revisar cinco sistemas y tres planillas, esa dependencia debe quedar visible antes de automatizar cualquier respuesta.
- Canal de entrada claramente identificado.
- Criterio para validar identidad y alcance de la solicitud.
- Responsable primario y ruta de escalamiento.
- Fuentes que deben consultarse para responder.
- Punto de revisión humana para decisiones sensibles o ambiguas.
- Registro de qué se respondió, cuándo y con qué evidencia.
3. Diseña protección desde el proceso, no al final del proyecto
El texto diferido de la Ley 19.628 incorpora el deber de aplicar medidas técnicas y organizativas adecuadas desde el diseño, antes y durante el tratamiento. En la práctica, eso obliga a mover la conversación desde el documento hacia el proceso: quién necesita acceso, qué dato es estrictamente necesario, qué acción debe quedar registrada y cómo se revisa una excepción.
No toda medida requiere software nuevo. Muchas brechas parten por permisos amplios, cuentas compartidas, exportaciones sin dueño, copias que nadie depura o decisiones sensibles que no dejan rastro. Primero ordena el flujo. La tecnología se justifica cuando reduce riesgo o carga operativa sin esconder la responsabilidad.
- Revisar permisos por rol y necesidad real de acceso.
- Evitar copias y exportaciones sin responsable definido.
- Separar ambientes, usuarios y evidencias cuando el riesgo lo exige.
- Definir qué eventos deben generar alerta o revisión.
- Mantener una bitácora suficiente para reconstruir acciones relevantes.
4. Detecta tratamientos de alto riesgo antes de escalar
La normativa contempla evaluación de impacto en protección de datos personales cuando un tratamiento, por su naturaleza, alcance, contexto, tecnología o finalidad, pueda producir un alto riesgo para los derechos de las personas. La evaluación no debería aparecer al final de una implementación: debe ayudar a decidir si el diseño necesita límites, controles adicionales o una alternativa más simple.
Desde operación, una señal de alerta es que el equipo no pueda explicar qué datos alimentan una decisión, qué criterio se aplica, quién puede intervenir y cómo se corrige un error. Además, la ley exige la evaluación en ciertos supuestos, entre ellos la evaluación sistemática y exhaustiva basada en tratamiento o decisiones automatizadas que produzca efectos jurídicos significativos, el tratamiento masivo o a gran escala, el monitoreo sistemático de zonas de acceso público y determinados tratamientos de datos sensibles o especialmente protegidos sin consentimiento. La calificación concreta de cada caso debe validarse jurídicamente.
- Qué daño podría producir un error, acceso indebido o uso fuera de finalidad.
- Qué volumen, frecuencia y alcance tiene el tratamiento.
- Qué decisiones dependen de datos o modelos automatizados.
- Qué controles preventivos, detectivos y correctivos existen.
- Quién acepta el riesgo residual antes de poner el flujo en producción.
5. Prueba controles mientras se define el calendario de vigencia
Al 9 de septiembre de 2026, la fecha legal vigente sigue siendo el 1 de diciembre de 2026. El Ejecutivo presentó una propuesta para trasladarla al 1 de diciembre de 2027 y el proyecto continúa en tramitación. Mientras esa modificación no sea aprobada y publicada, no conviene tratar la postergación como un hecho consumado.
Ejecuta simulaciones controladas: una solicitud de acceso, una rectificación, una baja de permisos, un dato duplicado y un incidente ficticio. El objetivo no es demostrar que la política existe. Es comprobar que el equipo puede identificar responsables, consultar las fuentes correctas, tomar una decisión, escalar cuando corresponde y dejar evidencia suficiente.
- Caso de prueba documentado y repetible.
- Tiempo de respuesta interno medido.
- Fallas y dependencias registradas sin ocultarlas.
- Backlog de brechas legales, operativas y tecnológicas separado por tipo.
- Responsable y fecha de corrección para cada brecha prioritaria.