Cómo auditar los riesgos de un proyecto de IA antes de lanzarlo

Por qué esto se hace mal (o no se hace) hoy

La mayoría de proyectos de IA no tiene una auditoría de riesgo, tiene una sensación de riesgo. Alguien en la sala dice “esto se ve bien” o “esto me da mala espina” y ahí termina la revisión. No hay preguntas escritas, no hay respuestas documentadas, no hay un criterio de qué hacer si aparece un problema. El proyecto avanza porque nadie levantó la mano a tiempo, no porque de verdad se revisó.

El otro extremo es igual de común: equipos que sí hablan de riesgo, pero solo en abstracto, en la reunión de kickoff, citando que “la IA hay que gobernarla con criterio”. Ese argumento ya está aceptado. El problema es que nadie lo baja a este proyecto puntual: qué dato específico va a tocar el modelo, qué decisión específica va a tomar solo, a qué cliente específico le puede llegar una respuesta mal calibrada.

Y hay una tercera forma de hacerlo mal, la más cara: auditar el riesgo después del lanzamiento, cuando ya hubo un incidente. Ahí la auditoría se convierte en investigación de daños, no en prevención. El costo de revisar esto antes es horas de reunión incómoda. El costo de revisarlo después es la confianza del cliente, del regulador o del equipo interno que confió en el sistema.

Qué es esta auditoría en concreto (y qué no es)

Esta auditoría no es un documento de veinte páginas sobre ética de la IA. Es una reunión de trabajo, con un checklist de preguntas concretas por categoría de riesgo, donde cada pregunta se responde con datos del proyecto real (no con “creo que sí” ni “probablemente no pasa”), y donde cada riesgo detectado sale de la reunión con una decisión tomada: se mitiga con una medida concreta, se limita el alcance del lanzamiento, o el proyecto no se lanza todavía.

Tampoco es un filtro que un solo rol pueda correr solo. El equipo técnico sabe qué datos entran al modelo y qué tan predecible es su comportamiento; el dueño del proceso de negocio sabe a quién afecta una decisión del sistema si sale mal; alguien con autoridad para decidir alcance tiene que estar en la sala para que la reunión termine en una decisión, no en una lista de preocupaciones sin dueño.

• Un formulario genérico de compliance que se llena por obligación y nadie vuelve a leer.
• Una discusión filosófica sobre si la IA en general es riesgosa: eso ya se asumió antes de llegar aquí.
• Un veto automático a lanzar: la mayoría de riesgos detectados se mitigan o se acotan, no cancelan el proyecto.
• Un reemplazo de la revisión legal formal cuando el sector la exige: esta auditoría dice qué preguntas hay que llevarle a legal, no las responde en su lugar.

El checklist por categoría de riesgo

Corre esto como una reunión de dos a tres horas, con el equipo técnico, el dueño del proceso de negocio y alguien con autoridad de decisión en la sala. Por cada categoría, responde las preguntas con datos concretos del proyecto, no con supuestos.

1. Riesgo de datos

• ¿Qué datos exactos ve el modelo para producir su respuesta: incluyen datos personales, de salud, financieros o de identidad de clientes o empleados?
• ¿Ese dato es estrictamente necesario para la tarea, o se le está pasando al modelo “por si acaso” información que no debería tocar?
• ¿Dónde queda ese dato después de que el modelo lo procesa: se guarda, se usa para entrenar algo más adelante, sale del entorno controlado de la empresa?
• Si la respuesta revela riesgo alto: reduce el dato que se le entrega al modelo al mínimo indispensable (minimización de datos), o exige contractualmente que el proveedor no retenga ni entrene con esa información antes de lanzar.

2. Riesgo de decisión

• ¿Qué decide el sistema solo, sin que un humano revise antes de que el resultado impacte a alguien: aprueba, rechaza, prioriza, responde, clasifica?
• Si el sistema decide mal en un caso puntual, ¿qué tan reversible es el daño y a quién afecta directamente: un cliente, un empleado, un candidato, un paciente?
• ¿Existe hoy un punto de revisión humana antes de que la decisión del sistema se ejecute, o el sistema actúa y recién después alguien se entera?
• Si la respuesta revela riesgo alto: mueve la decisión de automática a “el sistema recomienda, un humano aprueba” para los casos de mayor impacto, y deja la automatización completa solo donde el error es barato y reversible.

3. Riesgo reputacional

• ¿Qué pasa si un cliente recibe, en una captura de pantalla, una respuesta del sistema que suena mal, ofensiva o simplemente falsa? ¿Esa captura es plausible que se viralice?
• ¿El sistema puede prometer algo que la empresa no puede cumplir (un precio, un plazo, una condición) sin que nadie lo detecte antes de que el cliente lo reciba?
• ¿Hay un canal claro para que un cliente reporte una respuesta mala y alguien la revise en horas, no en semanas?
• Si la respuesta revela riesgo alto: limita el alcance de lo que el sistema puede decir (guardrails explícitos sobre precios, promesas y temas sensibles) y define un protocolo de respuesta rápida ante un caso viral antes de lanzar, no después.

4. Riesgo de dependencia de proveedor

• Si el proveedor del modelo o de la plataforma sube el precio, cambia los términos o deja de operar en tu región, ¿qué tan rápido puedes migrar el proceso a otra opción?
• ¿El proceso de negocio quedó diseñado alrededor de una función exclusiva de un solo proveedor, o hay una capa que permite cambiar el modelo sin reconstruir todo el sistema?
• ¿Existe un acuerdo de nivel de servicio (SLA) claro sobre disponibilidad, soporte y tiempos de respuesta ante una falla, o se está operando solo con la confianza en la marca?
• Si la respuesta revela riesgo alto: exige SLA por escrito antes de firmar, y diseña el proceso con una capa de abstracción mínima que no amarre el negocio a features exclusivas de un solo proveedor.

5. Riesgo legal y regulatorio

• ¿El sector donde opera este proyecto tiene una regulación específica sobre uso de IA, datos personales o decisiones automatizadas (salud, banca, seguros, empleo)?
• ¿Alguien de legal o compliance ya revisó este proyecto puntual, o solo se asumió que “como la empresa ya tiene política de IA, esto ya está cubierto”?
• ¿Hay que informar al cliente o al usuario final que está interactuando con un sistema de IA, y ese aviso existe hoy en el flujo real?
• Si la respuesta revela riesgo alto: no lanza el proyecto hasta que legal lo revise puntualmente, aunque exista una política general de IA en la empresa; una política marco no sustituye una revisión específica cuando el sector lo exige.

Errores comunes al auditar riesgos de un proyecto de IA

• Correr la auditoría solo con el equipo técnico, sin el dueño del proceso de negocio: se revisan los datos pero nadie evalúa a quién afecta una decisión mala.
• Responder las preguntas con “no creo que pase” en vez de con evidencia del proyecto real: eso no es una auditoría, es una opinión con formato de checklist.
• Hacer la auditoría una sola vez al inicio del proyecto y nunca repetirla cuando cambia el alcance, la fuente de datos o el proveedor.
• Tratar todo riesgo alto como motivo automático de cancelación, lo que empuja al equipo a esconder problemas para no frenar el proyecto, en vez de mitigarlos o acotar el alcance.
• Confundir “ya tenemos una política de gobierno de IA” con “ya auditamos este proyecto”: la política marco no reemplaza la revisión puntual del caso específico.

Cómo se ve esto en la práctica

Una empresa de servicios financieros estaba por lanzar un asistente que respondía preguntas de clientes sobre el estado de sus productos, con acceso directo a la base de datos de cuentas. En la auditoría de riesgo de datos apareció algo que nadie había puesto sobre la mesa: el modelo tenía acceso a campos que no necesitaba para responder las preguntas típicas del cliente, incluyendo información de otros productos que esa persona ni siquiera tenía contratados.

En riesgo de decisión, el equipo se dio cuenta de que el sistema podía, en teoría, confirmarle a un cliente un saldo o un estado de cuenta con un error de un dígito y que eso se tomara como definitivo sin ninguna verificación posterior. Y en riesgo reputacional, nadie había definido qué pasaba si el sistema respondía con un tono que sonara a asesoría financiera formal, algo que el área legal no había autorizado que un sistema automatizado ofreciera.

La decisión no fue cancelar el proyecto. Fue acotar el alcance de datos a los campos estrictamente necesarios para la consulta, agregar una capa de verificación antes de mostrar cifras de saldo, y definir un lenguaje explícito de “esto es información referencial, confirma con tu asesor” en cualquier respuesta que rozara terreno de asesoría. El proyecto se lanzó dos semanas después de lo previsto, con un alcance más chico y más seguro que el original.

Mi criterio

Cómo saber si la auditoría se hizo bien

• Cada una de las cinco categorías de riesgo tiene una respuesta documentada, no una casilla marcada sin evidencia.
• Todo riesgo alto detectado tiene una decisión registrada: mitigación concreta, alcance reducido, o fecha de lanzamiento pospuesta.
• El dueño del proceso de negocio y el equipo técnico estuvieron en la misma sala, no en reuniones separadas que nadie cruzó después.
• Existe un plan de qué se revisa de nuevo (y cuándo) si el proyecto cambia de alcance, de proveedor o de fuente de datos.
• Si el sector exige compliance formal, legal recibió las preguntas puntuales de este proyecto y no solo la política general de IA de la empresa.

Si después de correr esta auditoría nadie puede decir con claridad qué se decidió por cada categoría de riesgo, la auditoría no se hizo: se simuló. Y un proyecto lanzado sobre una auditoría simulada tiene exactamente el mismo riesgo que uno que nunca se auditó.