Caso ficticio
Son las once de la noche y Juanito Pérez, desarrollador en una empresa de despachos de última milla en una ciudad de la zona central, tiene un error en producción: algunos pedidos no se están asignando a ningún repartidor. Copia el error del log, el JSON del pedido que falló y, para que se entienda mejor, cincuenta filas de la tabla de pedidos. Lo pega todo en un asistente de IA y escribe: «¿por qué falla esto?».
La IA probablemente encuentra el error. Pero el JSON traía el nombre, el RUT, la dirección y el celular de un cliente, y las cincuenta filas, los de cincuenta más.
La respuesta corta: datos de prueba inventados, lo que también se llama datos sintéticos. La IA necesita la forma de los datos, no a tus clientes. Vale para depurar un error y vale para probar algo nuevo.
Para depurar, la IA necesita la forma, no el contenido
Un error casi nunca depende de que el cliente se llame Pedro Pérez y viva en una avenida. Depende de la forma de los datos: que un campo venga vacío, que una comuna traiga tilde, que un número tenga un espacio, que una fecha venga en otro formato. Para encontrarlo, la IA necesita ver esa forma.
La ley lo pide con nombre propio. Los datos tratados deben limitarse a los «necesarios, adecuados y pertinentes» para el fin (artículo 3°, letra c). Y el artículo 14 quáter, el más cercano al trabajo de TI, obliga a la empresa a aplicar medidas «desde el diseño», antes y durante el tratamiento, y medidas para que, por defecto, sólo se traten los datos «específicos y estrictamente necesarios» para cada actividad. Lo desarrollamos en privacidad desde el diseño.
Ejemplo. En vez del JSON real, Juanito pega el mismo JSON con los valores cambiados por otros inventados del mismo tipo:
"nombre": "Cliente Prueba","rut": "11.111.111-1","direccion": "Calle Uno 123","comuna": "Comuna Prueba","telefono": "". Deja tal cual lo que sospecha que causa el error —el teléfono vacío—. En vez de cincuenta filas, describe el patrón: «falla con los pedidos que no traen teléfono; los que lo traen se asignan bien». La IA tiene todo lo que necesita.
Algunos hábitos que ayudan:
- Una fila, no la tabla. Si el error se reproduce con un caso, basta con ese caso, con datos inventados.
- El esquema en vez del dump. La definición de la tabla dice más sobre un error de tipos que mil filas reales.
- El stack trace sin los valores. Muchas trazas imprimen el objeto completo. Corta esa parte o reemplázala.
Para probar, los datos inventados prueban mejor
Los datos reales tienen un problema para probar: traen los casos que ya pasaron, no los que importan. Los datos inventados se pueden armar para cubrir justo lo difícil: el campo vacío, el valor en el límite, el formato raro. Y pedírselos a la IA es rápido.
Ejemplo. Al día siguiente, para que el error no vuelva, Juanito no saca doscientos pedidos reales de producción. Le pide a la IA: «Genera 30 pedidos inventados para probar la asignación de repartidores. Incluye: sin teléfono, con teléfono con espacios, comunas de dos palabras, direcciones con número de departamento, nombres con tilde y con ñ, y una fecha de entrega en otro formato. Usa RUT de formato válido pero inventados». Le salen casos que su muestra real ni siquiera tenía.
Si el equipo guarda esos casos en una base de desarrollo con datos inventados, la próxima vez pegar desde ahí es lo más simple.
Copiar producción a desarrollo ya es tratar datos
Un ambiente de desarrollo con datos reales es otro lugar donde están esos datos, con todas las obligaciones. La ley pide medidas de seguridad adecuadas al riesgo, que aseguren la confidencialidad, integridad, disponibilidad y resiliencia de los sistemas, y menciona expresamente la seudonimización y el cifrado (artículo 14 quinquies). También obliga a la empresa a mantener secreto sobre los datos personales y a adoptar medidas para que sus dependientes lo cumplan (artículo 14 bis). Que el equipo de desarrollo sepa qué no copiar a una base de pruebas, y qué no pegar en una herramienta externa, es una de esas medidas.
Para probar una función, ¿cuál es el dato estrictamente necesario de un cliente real? Casi siempre, ninguno.
Los logs son el problema de fondo
Si los logs de producción guardan nombres, RUT y direcciones, el problema no empieza en el chat de IA: empieza en el log. Ahí está la protección desde el diseño en su forma más concreta. Un log que registra el identificador interno del pedido en vez del nombre del cliente sirve igual para depurar, y no tiene nada que limpiar después.
Y si un dato real tiene que ir
La Ley 21.719 no prohíbe pedirle ayuda a una IA para programar, ni siquiera con datos personales. Si un dato real tiene que ir, pide que sea sólo lo necesario, con una herramienta que trabaje para la empresa bajo un contrato de encargo (artículo 15 bis) y con resguardos si los datos salen de Chile (artículo 27). Con la cuenta personal de un desarrollador en un chat de IA gratuito, nada de eso existe: lo vemos en usar IA en el trabajo. Si tu sistema maneja deudas o datos financieros, que tienen reglas propias, sigue en bancos, IA y secreto bancario.
Dónde entra Plumii
En Plumii, con la plantilla de partida, nombres, RUT, correos, teléfonos y direcciones se tapan antes de llegar al modelo, y tarjetas y contraseñas se bloquean: si el filtro reconoce una contraseña en lo que pegas, el mensaje no llega al modelo y ves por qué. Pero el filtro reconoce los datos por el contexto, en español. En un JSON, un log o una tabla, sin frases alrededor, el contexto es escaso, y un dato raro o mal escrito puede pasar. Los datos de prueba inventados siguen siendo la mejor costumbre. Mira cómo funciona.
Las personas, empresas y situaciones de este artículo son ficticias: las inventamos para explicar la ley, y cualquier parecido con un caso real es coincidencia. Este artículo es información general, no asesoría legal. El texto oficial de la ley está en la Biblioteca del Congreso Nacional.