Borrado a pedido de datos de multas: qué se puede y qué no
Una solicitud de baja alcanza a las copias que guardamos, no al registro oficial que emitió el acta ni a lo que una obligación legal manda conservar. Conviene aclararlo antes de aceptar el pedido.
Por Marco Ferreiro ·
Un cliente pide dar de baja los datos de una flota que dejó de operar. Otro quiere que desaparezca una patente que vendió. Un tercero, después de una auditoría interna, pide eliminar todo lo que la integración haya guardado sobre su empresa. Las tres solicitudes usan el mismo verbo y piden cosas distintas.
La confusión es previsible. Borrar se aplica por igual a la copia que almacenamos, al registro que emitió la jurisdicción y al rastro de que la consulta existió. Sólo la primera capa está bajo nuestro control: responder sin separarlas produce una promesa incumplible o un borrado que rompe una obligación.
Conviene resolverlo antes del pedido: definir el alcance por escrito, ejecutarlo con comprobante y decir con claridad qué queda —la deuda de esa patente sigue existiendo aunque se borre la copia—.
Tres capas que se llaman igual
La copia derivada es lo que la plataforma almacenó para una cuenta: resultados de consultas, reportes generados, exportaciones, adjuntos, listas de patentes o CUIT que se subieron y los índices y cachés construidos sobre eso. Esa capa se borra a pedido porque somos quienes la creamos.
El registro de origen es el acta en el sistema de la jurisdicción que la labró. No es nuestra base y no la administramos. Borrar la copia no la modifica: una consulta posterior puede volver a traer la misma infracción, con el mismo número y el mismo estado. El pedido tampoco cancela una deuda ni cierra un expediente.
La tercera capa es lo que alcanza una obligación de conservación: comprobantes de facturación, registros de seguridad y la constancia de que las operaciones ocurrieron. Ahí el borrado no es una decisión de producto.
Qué habilita la normativa y qué acota
El marco argentino de protección de datos personales reconoce, junto con el acceso y la rectificación, el derecho de supresión, y prevé plazos acotados para atender esas solicitudes. Las guías de la Agencia de Acceso a la Información Pública lo presentan en esos términos y ubican la respuesta del lado del responsable de la base.
La misma normativa acota el alcance. La supresión puede no proceder cuando existe una obligación legal de conservar los datos o cuando afectaría derechos o intereses legítimos de terceros. No es una excusa de uso general: hay que poder nombrar la obligación concreta.
En sentido inverso, el marco prevé que los datos se destruyan cuando dejan de ser necesarios o pertinentes para la finalidad que los justificó. Buena parte del borrado no debería depender de que alguien lo pida: una retención declarada por tipo de dato resuelve de antemano la mayoría de estos pedidos.
Qué queda después de borrar
Un borrado prolijo deja una constancia mínima: identificador de la solicitud, alcance, momento y resultado, sin el contenido eliminado. Sin ella no hay cómo demostrar después que el pedido se atendió, ni notar que un proceso repuso el acta desde una fuente secundaria.
Los respaldos merecen una respuesta explícita. Editar un backup fila por fila compromete su integridad y su valor como respaldo. El criterio habitual es ejecutar la baja en el sistema vivo, impedir que una restauración reponga el dato y dejar que la copia expire según su propio plazo.
También hay filas compartidas. Un registro puede referirse a más de una persona: el titular, el conductor declarado y la empresa que consultó. Borrar la fila entera elimina el dato de un tercero que no pidió nada. En esos casos se borra el campo, no la entidad.
El borrado como operación de la API
Si la integración lo expone, el endpoint necesita el mismo rigor que cualquier mutación: alcance explícito, ejecución asincrónica con estado consultable, idempotencia por identificador de pedido y un comprobante que enumere lo alcanzado y lo excluido, con el motivo de cada exclusión.
El pedido casi nunca termina en la base principal. Cachés, índices de búsqueda, exportaciones y almacenes analíticos guardan copias que sobreviven a un borrado en el origen. La mecánica de esa propagación es la misma que la de una corrección publicada, descrita en cómo se propaga una rectificación.
El receptor también cuenta. Si la flota ya descargó el CSV de multas o procesó un webhook, el dato está en su infraestructura: la API puede avisar, no borrar por ella. El contrato debería decir quién queda responsable tras la entrega.
Qué verificar antes de prometer un borrado
Antes de comprometerse, conviene tener respuesta escrita para cinco preguntas:
- qué almacenamientos existen y quién administra cada uno;
- qué retención declara cada almacenamiento hoy;
- qué obligación concreta sostiene cada excepción;
- cómo se comprueba que el dato no reaparece;
- qué comprobante recibe quien pidió el borrado.
La prueba vale más que la política. Se crea un acta ficticia, se ejecuta la baja, se restaura un respaldo en un entorno aislado y se busca el identificador en cada capa, incluidos logs y métricas. Cómo conservar evidencia sin arrastrar el contenido está en auditoría sin payloads completos.
Un borrado honesto no es el que promete que no quedó nada. Es el que puede decir, con evidencia, qué se eliminó, qué sobrevivió, por qué motivo y durante cuánto tiempo más.
Metodología
- Alcance
- Alcance real de una solicitud de borrado en una integración de infracciones: qué copias controla la plataforma, qué queda fuera de su alcance y qué constancia sobrevive. No cubre el procedimiento para impugnar un acta ni el trámite ante la autoridad de control.
- Unidad de análisis
- Una solicitud de borrado identificada, con su alcance declarado, los almacenamientos que efectivamente alcanza y el comprobante que devuelve.
- Cobertura
- Marco general de la Ley 25.326 y su decreto reglamentario, junto con las guías de derechos y de obligaciones publicadas por la Agencia de Acceso a la Información Pública, al 29 de agosto de 2026.
Limitaciones
- No es asesoramiento legal. Cada empresa puede tener obligaciones de conservación propias, contractuales o sectoriales, que corresponde revisar con quien la asesora.
- Los plazos concretos de respuesta y de retención dependen de la normativa aplicable y del contrato de servicio; acá se describe el criterio, no un calendario.
- El borrado en una plataforma no modifica el registro de la jurisdicción que emitió el acta ni el estado de una deuda.
Fuentes
- Ley 25.326 de Protección de los Datos Personales — Argentina.gob.ar (consultada el )
- Derechos de las personas respecto de sus datos personales — Agencia de Acceso a la Información Pública (consultada el )
- Obligaciones de responsables de bases de datos personales — Agencia de Acceso a la Información Pública (consultada el )
- Decreto 1558/2001 — reglamentación de la Ley 25.326 — Argentina.gob.ar (consultada el )
Preguntas frecuentes
¿Borrar los datos de la plataforma hace desaparecer la multa?
No. El acta vive en el sistema de la jurisdicción que la emitió, que es un responsable distinto. Borrar la copia elimina lo que la plataforma guardaba para esa cuenta; la infracción y su estado siguen existiendo y una consulta nueva puede volver a traerla.
¿Se puede borrar todo lo que una empresa pide borrar?
No siempre. La normativa de protección de datos personales reconoce el derecho de supresión, pero también prevé que no proceda cuando existe una obligación legal de conservar los datos o cuando afectaría derechos de terceros. Lo honesto es responder qué se borró, qué no y por qué motivo concreto.
¿Qué pasa con los respaldos cuando se pide un borrado?
Un respaldo no se edita fila por fila sin comprometer su integridad. El criterio habitual es ejecutar la baja en el sistema vivo, impedir que una restauración reponga el dato y dejar que el respaldo expire según su propio plazo. Ese plazo conviene declararlo antes, no explicarlo después.
¿Queda registro de que se pidió un borrado?
Sí, y conviene que quede. Se conserva una constancia mínima —identificador de la solicitud, alcance, momento y resultado— sin el contenido eliminado. Sin esa constancia no se puede demostrar más tarde que el pedido se atendió ni detectar que un proceso repuso el dato.
Notas relacionadas
Auditar consultas de multas sin guardar payloads para siempre
Una secuencia mínima de eventos y hashes encadenados puede revelar alteraciones sin convertir cada respuesta sensible en un archivo permanente.
Enlace a un informe de multas: expiración, revocación y reenvío
Un enlace que abre el informe de multas de una flota funciona como una credencial delegada. Debe vencer, limitar su alcance, resistir cachés y poder revocarse sin filtrar datos.
Firmas HTTP y replay en una integración de multas
Una firma válida puede reenviarse si no cubre método, destino, contenido y tiempo. Nonce, ventana de vigencia y almacenamiento atómico permiten detectar duplicados.