Implementación de proyectos con inteligencia artificial con el marco legal desde el diseño

Empezamos por el proceso, no por la herramienta

La mayoría de los proyectos de IA que fracasan empezaron al revés: alguien compró una licencia y después buscó dónde usarla. Nosotros identificamos dónde hay volumen repetitivo, dónde el error sale caro y dónde la automatización aporta de verdad, y descartamos sin rodeos los casos de uso cuyo riesgo legal supera el beneficio operativo. Decir que no a un caso de uso es parte del trabajo, y suele ser la parte que ahorra más dinero.

Diseño de la delegación de tareas

La pregunta central de un proyecto de IA no es técnica: es cuánto se delega y qué queda en manos de una persona. La respondemos tarea por tarea y la dejamos escrita.

• Qué hace el sistema, qué hace la persona y en qué punto exacto está el control humano.
• Criterio de aceptación de cada entregable: qué se considera correcto y quién lo dice.
• Responsable de la revisión, con nombre y cargo, no con el nombre de un área.
• Evidencia que se conserva de cada decisión, para el día en que haya que reconstruirla.
• Qué se hace cuando el sistema falla o entrega un resultado que no pasa la revisión.

Lo que hay que resolver antes de conectar los datos

Es el punto donde más proyectos se devuelven, casi siempre cuando ya hay una inversión hecha y una fecha comprometida. Se revisa antes.

• Finalidad. Si los datos que va a usar el sistema se recogieron para eso o para otra cosa, y qué hay que hacer si fue para otra cosa, bajo la Ley 1581 de 2012.
• Autorizaciones y aviso de privacidad. Si describen el uso que el proyecto va a hacer y qué ajuste requieren.
• Información de terceros. Datos y documentos que la empresa recibió de clientes o proveedores bajo acuerdos de confidencialidad que no contemplan este uso.
• Propiedad intelectual y secreto empresarial. Origen de los contenidos de entrada, titularidad de los resultados y qué información propia no puede salir hacia el sistema, a la luz de la Ley 23 de 1982 y la Decisión Andina 351 de 1993.
• Consumidor. Si el sistema va a interactuar con clientes finales, qué puede prometer y qué queda obligando a la empresa.

Contratación y puesta en marcha

Estructuramos la relación con el proveedor —alcance, datos, propiedad intelectual, confidencialidad, niveles de servicio, responsabilidad, auditoría y terminación— y, cuando el proyecto toca al cliente final, revisamos también ese contrato para que las dos puntas digan lo mismo. En paralelo dejamos lista la política interna de uso, el protocolo de incidentes y la capacitación de las personas que van a operar el proceso, que es donde se juega si el diseño se aplica o se abandona en la primera semana. También acordamos quién autoriza la puesta en marcha y con qué base, para que la decisión de encender el proceso quede documentada y no sea el resultado de una fecha comprometida.

Monitoreo y actualización

Un proyecto de IA no termina el día de la puesta en marcha. Los términos de los proveedores cambian con frecuencia y sin aviso, los modelos se actualizan y los equipos empiezan a usar el sistema para cosas que nadie previó. Revisamos periódicamente el inventario, los incidentes, los cambios contractuales del proveedor y la evolución de la regulación, y ajustamos lo que haga falta antes de que se convierta en un hallazgo.

Qué recibe el cliente

• El diagnóstico de casos de uso, con los que se priorizan y los que se descartan, y la razón de cada decisión.
• El mapa de delegación de tareas, con puntos de control humano, responsables y criterios de aceptación.
• Los documentos de datos personales ajustados al proyecto: autorizaciones, aviso de privacidad y política de tratamiento.
• El contrato con el proveedor negociado y, cuando corresponde, el ajuste al contrato con el cliente final.
• La política interna de uso, el protocolo de incidentes y la capacitación de los equipos que operan el proceso.
• Un plan de revisión periódica, con lo que hay que volver a mirar y cada cuánto.