IA y datos personales: qué pedir al proveedor antes de contratar

La pregunta de compra empieza antes de subir archivos

Una empresa grande quiere incorporar IA para resumir solicitudes y preparar respuestas. El proveedor muestra un resultado convincente con documentos de ejemplo. La decisión de contratación necesita otra conversación: qué información real recibirá el sistema, quién puede utilizarla y qué evidencia permitirá comprobar los límites acordados.

La Agencia Nacional de Ciberseguridad advierte del riesgo de perder confidencialidad al ingresar datos en herramientas de IA. También recomienda contar con aprobación institucional para usarlas en el trabajo y prestar atención a las decisiones que se delegan en agentes. Es una orientación pública de seguridad, no una certificación de herramientas o proveedores. ANCI: uso más seguro de la IA.

Para convertir esa advertencia en una evaluación comercial, proponemos pedir un mapa del recorrido de la información. Una frase como «se procesa en la nube» deja abiertas preguntas sobre el servicio contratado, sus copias, sus registros y las personas que intervienen. El mapa debe permitir discutir esos puntos con TI, seguridad y quienes revisan el contrato.

Definir los datos necesarios para una tarea concreta

La Ley N°19.628 distingue los datos relativos a personas identificadas o identificables y describe operaciones que constituyen tratamiento, entre ellas almacenar, comunicar y utilizar información personal. Su artículo 4 regula la autorización del tratamiento y contempla reglas y excepciones que deben analizarse en el caso concreto. BCN: Ley N°19.628.

Como criterio de evaluación, recomendamos separar la tarea del conjunto completo de documentos disponibles. Si la IA debe clasificar una solicitud, acuerda primero qué campos necesita y qué resultado se espera. No asumas que requiere adjuntos, identificadores o conversaciones históricas solo porque estén disponibles en el mismo sistema.

Empieza la prueba con información ficticia y evita mezclarla con registros reales. Después, el responsable interno puede revisar qué información tiene fundamento para utilizarse y bajo qué condiciones. Esta decisión debe quedar identificada en el proyecto; no corresponde deducirla de que un archivo se pudo cargar técnicamente.

Pedir respuestas que se puedan contrastar

Proponemos que el proveedor documente las diferencias entre los archivos de entrada, las respuestas, los registros de actividad y otras copias que pueda crear la solución. Para cada componente, pide la ubicación del procesamiento, las condiciones de conservación y los accesos previstos. Las respuestas deberían corresponder al servicio y configuración ofrecidos, con sus limitaciones.

Pregunta también qué terceros participan y qué uso se autoriza para la información. Si la propuesta habla de entrenamiento, mejora del producto o supervisión humana, solicita que precise a qué información se refiere y en qué condiciones. Si declara que un uso no ocurre, pide la documentación del producto o la configuración que sustenta esa afirmación.

La comparación útil se hace sobre el mismo caso. Un proveedor puede ofrecer una instalación en infraestructura de la empresa y otro un servicio gestionado. Ninguna etiqueta resuelve por sí sola todos los accesos, copias y responsabilidades. Pide que cada alternativa explique el recorrido completo antes de compararlas.

Convertir los acuerdos en alcance y aceptación

La Ley N°19.628 contempla que, cuando el tratamiento se efectúa por mandato, este se otorgue por escrito y deje constancia de las condiciones de uso de los datos. Ese punto debe revisarse junto con la finalidad y el marco aplicable a la operación. Un acuerdo de confidencialidad no describe necesariamente todo lo que hará el sistema. BCN: reglas de utilización y mandato.

Como recomendación de contratación, vincula la propuesta técnica con las condiciones acordadas: información incluida, usos permitidos, acceso de terceros, conservación, salida del servicio y responsables de incidentes. Indica también quién puede autorizar cambios. El objetivo es evitar que la oferta comercial, el contrato y la implementación describan servicios diferentes.

Una prueba de aceptación puede seguir un documento ficticio desde su carga hasta su retiro. Comprueba qué aparece en la respuesta, qué personas pueden acceder y qué evidencia entrega el proveedor al aplicar la política acordada. No presentes ese ensayo como prueba universal: registra el escenario, la configuración y lo que todavía queda pendiente.

Separar las reglas vigentes de los cambios propuestos

La Ley N°21.719 introduce modificaciones al régimen de protección de datos y contiene disposiciones de vigencia diferida. Además, el Ministerio de Economía comunicó una propuesta para ampliar el plazo de implementación. Un anuncio de una iniciativa no reemplaza el texto legal aplicable al momento de contratar. BCN: Ley N°21.719 y disposiciones transitorias. Ministerio de Economía: propuesta de ampliación.

En la evaluación proponemos conservar una referencia a la versión normativa que revisó el responsable legal, la fecha de esa revisión y los puntos que afectan al proyecto. Evita convertir una fecha leída en una presentación comercial en la única base de la planificación. Esta pauta organiza antecedentes para decidir; no determina la aplicación de cada regla a una empresa.

Qué decisión llevar a la reunión con el proveedor

La gerencia debería poder decidir qué tarea vale la pena evaluar y con qué límites. TI y seguridad necesitan saber qué integración, identidades y registros tendrán que revisar. El proveedor debe distinguir las capacidades demostradas, los compromisos contractuales y las condiciones que aún no puede acreditar.

Si esos antecedentes no están listos, un primer alcance puede concentrarse en documentar el caso y probarlo con datos ficticios antes de habilitar información real. Una evaluación de seguridad y gobierno de IA puede ordenar esas decisiones. El resultado esperado de esa conversación es un alcance verificable, sin atribuir al proveedor certificaciones o garantías que no haya demostrado.