Ambiente de prueba de la API de multas: qué datos usar

Un ambiente de prueba acumula más copias y menos controles que producción: bases restauradas para reproducir un error, volcados que quedan en una notebook, capturas pegadas en un ticket. Es también donde muchos equipos cargan las patentes verdaderas porque "es sólo para probar".

Por eso la pregunta útil no es cómo proteger los datos que ya están adentro, sino cuáles tienen derecho a entrar. Es una decisión de origen: se toma antes del primer fixture.

Cuatro orígenes, de menor a mayor riesgo

Los datos de prueba pueden venir de cuatro lugares:

• valores reservados por especificación, previstos para ejemplos y pruebas;
• fixtures construidos a propósito, escritos desde cero para ensayar una decisión concreta;
• parámetros derivados de agregados, que reproducen forma y volumen sin conservar filas;
• una copia enmascarada de producción.

Los tres primeros no describen a una persona determinada; el cuarto sí, en distinto grado. La regla que aplicamos es no subir en esa escala sin una razón escrita: si el escenario se prueba con el nivel anterior, se prueba ahí.

Donde ya existe reserva, usala: el RFC Editor publica dominios de nivel superior apartados para pruebas y para documentación, y evitan que un correo de laboratorio salga hacia un tercero. Para patentes y números de acta hay que inventarla.

El tercer escalón sirve cuando hace falta volumen y no contenido: se derivan proporciones y tamaños —cuántas actas por patente—, y se descarta la fila que los originó, como en las pruebas de carga.

Generar al azar no es generar seguro

Un identificador con formato válido no es un identificador libre. Si el generador prueba combinaciones hasta que alguna apruebe el validador real, produce valores que alguien puede tener: el vehículo existe, la persona existe y la prueba puede terminar consultando sus infracciones en un portal real.

El criterio es el inverso. El dato de prueba debería fallar el validador de producción y aprobar sólo el del laboratorio: un prefijo reservado, una longitud imposible, un carácter que el formato de patente oficial no admite. Se pierde realismo y se gana una garantía verificable: si ese valor aparece en un log de producción, es un error de configuración.

Enmascarar reduce el riesgo, no lo cancela

La opción que parece prudente —copiar producción y reemplazar lo sensible— es la más cara de sostener. NIST trata la desidentificación como una reducción de riesgo y no como un estado que se alcanza de una vez: recomienda evitar la palabra "anonimización" porque nunca se sabe qué información auxiliar existe para cruzar el conjunto.

La normativa argentina apunta en la misma dirección. La Ley 25.326 define la disociación como el tratamiento que impide asociar la información a una persona determinada o determinable. Mientras esa asociación siga siendo posible, el conjunto sigue siendo una base de datos personales y arrastra los deberes de seguridad y confidencialidad que la autoridad de aplicación resume para los responsables. Llamar "de prueba" al entorno no cambia esa calificación.

Lo que queda afuera del enmascarado son las combinaciones poco frecuentes: un vehículo con muchas actas en una jurisdicción chica puede seguir siendo único aunque se le cambie la patente.

Hay casos en los que igual se sube ese escalón: un error que sólo aparece con actas verdaderas, una consulta que hay que medir contra el volumen real. Lo que cambia entonces no es el enmascarado sino el entorno que lo recibe —mismos controles de acceso que producción, sólo las filas del caso, plazo corto y borrado verificado—. Es un permiso con fecha, no un ambiente nuevo.

El texto libre y los adjuntos son el punto ciego

Reemplazar una patente es fácil porque tiene forma conocida. Un campo de observaciones no la tiene: puede contener un nombre, un domicilio, una patente escrita a mano o el detalle de un descargo. NIST advierte que el texto no estructurado dentro de un conjunto tabular necesita atención propia.

La salida no es enmascarar mejor: es no traerlos. Los textos se escriben de cero y los adjuntos se generan, con la disciplina de cualquier escenario del sandbox.

Un dato real en el ambiente de prueba es un incidente

Un control de entrada que busque el formato de una patente evita los errores repetidos, pero la parte difícil empieza cuando el dato ya entró.

Encontrarlo no es limpieza: hay que reconstruir por dónde llegó, qué copias derivadas se generaron —backups, índices, volcados, mensajes en canales de trabajo— y quién tuvo acceso. Borrar la tabla no borra las réplicas.

Qué verificar antes de cargar un conjunto

Antes de que un conjunto entre al ambiente, revisá cuatro cosas:

• de qué origen de la escala salió cada campo, y si hay una razón escrita para haber subido un escalón;
• si los identificadores fallan el validador de producción en vez de aprobarlo;
• si el texto libre y los adjuntos fueron escritos y generados, no copiados;
• si el conjunto tiene responsable, versión y fecha de baja.

Ninguna depende de una herramienta. Dependen de tratar el ambiente de prueba como lo que es: un lugar con menos defensas, donde la patente más segura es la que nunca llegó.

Metodología

Alcance

Criterios para decidir el origen de los datos que se cargan en un entorno de prueba de consultas vehiculares. No cubre la arquitectura del sandbox, el dimensionamiento de pruebas de carga ni la configuración de un proveedor de enmascarado en particular.

Unidad de análisis

Un conjunto de datos candidato a entrar al ambiente de prueba, con su origen declarado, su riesgo residual de reidentificación y su responsable.

Cobertura

Orientación general de NIST sobre desidentificación, definiciones y deberes generales de la Ley 25.326 y de la Agencia de Acceso a la Información Pública vigentes al 29 de agosto de 2026, y nombres reservados publicados por el RFC Editor.

Limitaciones

• No es asesoramiento legal. La calificación de un conjunto concreto depende de su contenido y de la información auxiliar que exista para cruzarlo.
• El riesgo de reidentificación no se mide una sola vez: NIST advierte que hay que contar con conjuntos hoy desconocidos que puedan aparecer más adelante.
• Los controles automáticos detectan formatos conocidos; el texto libre y los archivos adjuntos siguen requiriendo revisión humana.

Fuentes

• NIST Special Publication 800-188: De-Identifying Government Datasets — National Institute of Standards and Technology (consultada el 2026-08-29)
• Ley 25.326 de Protección de los Datos Personales — Argentina.gob.ar (consultada el 2026-08-29)
• Obligaciones de responsables de bases de datos personales — Agencia de Acceso a la Información Pública (consultada el 2026-08-29)
• Reserved Top Level DNS Names — RFC Editor (consultada el 2026-08-29)

Preguntas frecuentes

¿Alcanza con reemplazar las patentes para poder copiar producción a un entorno de prueba?

No por sí solo. Reemplazar los identificadores obvios reduce el riesgo, pero el texto libre, los adjuntos y las combinaciones poco frecuentes pueden seguir señalando un caso. Mientras la información pueda asociarse a una persona determinable, el conjunto conserva la calificación de base de datos personales y los deberes de cuidado que eso implica.

¿Un identificador de prueba generado al azar puede coincidir con uno real?

Sí, si se genera con el formato válido. Un valor que aprueba el validador de producción es un valor que alguien puede tener. Conviene lo contrario: que el dato de prueba falle ese validador y sólo lo acepte el ambiente de laboratorio.

¿Se puede traer una copia de producción cuando el error no se reproduce de otra forma?

A veces no queda alternativa, y entonces lo que cambia no es el enmascarado sino el entorno que la recibe: mismos controles de acceso que producción, sólo las filas del caso, plazo corto y borrado verificado al cerrar. Es un permiso con fecha, no un ambiente nuevo.

¿Qué conviene hacer si aparece un dato real en el ambiente de prueba?

Tratarlo como incidente y no como tarea de limpieza. Además de quitar el registro, hay que reconstruir por dónde entró, qué copias derivadas se generaron —backups, índices, volcados, entornos individuales— y quién tuvo acceso mientras estuvo ahí.

Notas relacionadas