Tomás programa en una fintech de préstamos en línea, en Las Condes. Está construyendo la función para que un cliente repacte su crédito desde la aplicación, y necesita casos de prueba realistas. Lo más rápido es sacar doscientos clientes reales de producción —RUT, renta, deudas, cuotas atrasadas, número de cuenta— y pegárselos a un asistente de IA: «genérame casos de prueba a partir de estos y dime qué puede fallar».
La IA lo hace. Y doscientas personas que pidieron un crédito acaban de quedar en una conversación de desarrollo.
Lo que hay en una base de una fintech
En una fintech, buena parte de los datos de clientes tiene reglas propias en la Ley 21.719:
- Datos de obligaciones financieras. La ley los trata en su Título III (artículos 17 a 19) y permite tratarlos sin consentimiento cuando se hace conforme a esas normas, incluidos los datos sobre la situación socioeconómica del titular (artículo 13, letra a).
- Datos sensibles. La situación socioeconómica está entre los datos sensibles (artículo 2°, letra g). Lo que un cliente cuenta al pedir una repactación —que quedó cesante, que no le alcanza— habla de ella.
- Un aviso doble si algo se filtra. Ante una vulneración de seguridad con riesgo razonable para los titulares, la ley pide reportarla a la Agencia; y cuando toca datos sensibles o datos de obligaciones económicas, financieras, bancarias o comerciales, comunicarla también a cada persona afectada (artículo 14 sexies).
Si tu fintech es parte del sector financiero regulado, súmale las normas propias del sector.
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). Y pide protección desde el diseño y por defecto: que sólo se traten los datos estrictamente necesarios para cada actividad (artículo 14 quáter). Lo desarrollamos en privacidad desde el diseño.
Para probar una función de repactación, ¿cuál es el dato estrictamente necesario de un cliente real? Casi siempre, ninguno.
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. Y en una fintech, parte de lo difícil está escrito en la ley.
Si tu producto informa deudas a terceros o decide qué se puede informar, el artículo 17 y el 18 te dan una lista de casos de prueba:
- Una deuda repactada. El artículo 17 exceptúa de lo que se puede comunicar la información de obligaciones «en cuanto hayan sido repactadas, renegociadas o novadas», o que tengan alguna modalidad pendiente. Para la función de Tomás, es el caso central.
- Una deuda pagada. No se puede seguir comunicando después de pagada o extinguida (artículo 18).
- Una deuda con más de cinco años desde que se hizo exigible. Tampoco se puede comunicar (artículo 18).
- Una deuda prescrita. Hay que suprimirla de los registros sin que nadie lo pida (artículo 17).
- Una morosidad originada durante la cesantía del deudor. No se puede publicar ni comunicar (artículo 17).
Ejemplo. En vez de doscientos clientes reales, Tomás le pide a la IA: «Genera 30 clientes inventados para probar una función de repactación de créditos de consumo. Incluye: deudas al día, con 1 a 90 días de atraso, ya repactadas una vez, pagadas el mes pasado, con más de cinco años desde que se hicieron exigibles, y clientes que informaron estar cesantes. Usa RUT de formato válido pero inventados, y montos realistas en pesos». Le salen casos que su muestra real ni siquiera tenía.
El mismo criterio vale para depurar: para entender un error, la IA necesita la forma de los datos, no los datos. La regla general está en datos reales de producción en un chat de IA al programar.
Lo que la ley no dice
La ley no prohíbe usar IA para programar en una fintech, ni siquiera con datos personales. Pide lo necesario y nada más, seguridad acorde al riesgo, un contrato con el proveedor que trata los datos por cuenta de la empresa (artículo 15 bis) y, si los datos salen de Chile, que esa transferencia internacional cumpla el artículo 27. Con la cuenta personal de un desarrollador, ninguna de esas cosas está.
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, el mensaje no llega al modelo y ves por qué. El filtro reconoce los datos por el contexto, en español; en una tabla o un JSON sin frases alrededor, un dato raro puede pasar. Y no reconoce los datos sensibles: «quedó cesante en marzo» llega al modelo, sin el nombre. Los datos inventados siguen siendo la mejor costumbre. Mira cómo funciona.
Este artículo es información general, no asesoría legal. El texto oficial de la ley está en la Biblioteca del Congreso Nacional.