Checklist de triaje antes de lanzar IA

Antes de poner en producción cualquier sistema con inteligencia artificial, existe una pregunta que pocos equipos se hacen a tiempo: ¿qué datos salen de nuestro sistema? No después del lanzamiento, sino antes. Construir un checklist de triaje permite tomar decisiones claras y documentadas sobre si un caso avanza, necesita ajustes o debe detenerse por completo. Este proceso funciona como la inspección previa al vuelo de un piloto: no se salta, aunque haya prisa, y se ejecuta al inicio del proyecto.

Para llegar a este punto se necesitan dos bases previas: un lente ético que identifique a quién afecta el sistema, qué daño puede ocurrir y quién responde; y un flujo completo de datos con sus diez pasos del ciclo de vida, cuatro zonas de frontera y tres puntos de riesgo con dueño y evidencia [0:40]. La pregunta clave ahora es si esos controles son verificables o solo intenciones escritas.

¿Cuáles son las seis preguntas del checklist de triaje?

El checklist se compone de seis preguntas, y cada una dispara una acción concreta que obliga al equipo a documentar con precisión.

¿Hay datos personales en juego?

Se deben revisar tres puntos del flujo de datos [1:18]. En la entrada, verificar si el texto que llega al modelo contiene nombres, correos, documentos, datos de salud o financieros. En el contexto, evaluar si el sistema mezcla documentos privados con públicos. En la salida, determinar si la respuesta podría exponer datos que el usuario no pidió. Un ejemplo claro: alguien escribe "tengo diabetes y vivo en Buenos Aires", combinando datos de salud y ubicación en una sola oración.

¿Hay datos sensibles o terceros involucrados?

Sensible no es lo mismo que personal [1:55]. Un dato es sensible cuando su exposición puede causar daño real: información médica, financiera, biométrica, ubicación o datos que revelen etnia o género, incluso de forma indirecta. La regla práctica es directa: si puede identificar o discriminar, es sensible.

Respecto a terceros [2:20], siempre se necesita saber:

• Qué datos salen del sistema.
• Quién los recibe.
• Si actúa como procesador o controlador.
• En qué país opera.

Si una empresa en Latinoamérica envía datos a un modelo en otro país, las leyes locales siguen aplicando. Y lo que se envía puede no quedarse solamente ahí.

¿Qué se guarda en logs y cuál es el impacto si algo falla?

Los logs funcionan como una cámara de banco [2:52]: graban, pero con reglas claras. Un log abierto a cualquiera no es seguridad, es un riesgo. Un log modificable no sirve para auditoría. Y guardar logs indefinidamente crea responsabilidad sin necesidad. Se debe definir quién accede y por cuánto tiempo.

Sobre el impacto [3:18], no es lo mismo un chatbot recomendando productos que un modelo decidiendo quién obtiene un crédito. No todos los errores tienen el mismo costo. Y si la decisión afecta derechos, salud o trabajo, un humano debe poder intervenir. No es opcional.

¿Cómo funciona el semáforo de decisión?

Las respuestas a las seis preguntas alimentan un sistema de semáforo con tres niveles [3:42]:

• Rojo: detener. Casos prohibidos o con daño serio.
• Amarillo: mitigar. Hay problemas, pero se pueden corregir.
• Verde: aprobar. Todo cumple, pero se documenta igualmente.

Un ejemplo ilustrativo: un banco quiere aprobar préstamos con IA [3:56]. No está prohibido, pero perfila a personas (alto riesgo), presenta sesgo y carece de revisión humana. Resultado: amarillo, mitigar antes de lanzar.

¿Qué pasa cuando un resumen de IA se convierte en registro oficial?

Una empresa decide usar un LLM para resumir tickets de soporte y convertir ese resumen en el registro oficial de la compañía [4:18]. Los tickets contienen nombres, correos, datos de tarjetas. Cuando el resumen se vuelve oficial, una simple alucinación de la IA se transforma en un error legal. El ticket original dice "mi pedido llegó tarde", pero el resumen genera "el cliente solicitó un reembolso". Eso es un registro corrupto [4:55].

Las mitigaciones concretas son:

• Filtrar información personal antes de que salga del sistema: en vez de "Juan Pérez, DNI 12345", el modelo recibe "Usuario A, ID redactado" [5:15]. Esto se prueba con casos diseñados para romper el sistema.
• Revisión humana obligatoria: un agente compara ticket original versus resumen, aprueba con nombre y fecha, y se miden las tasas de correcciones [5:33]. Si son altas, el modelo no está listo.

Cada mitigación registra riesgo, acción, métrica, resultado, responsable y fecha. Como verificación final, se debe poder responder con precisión: qué datos salen del sistema y qué datos se quedan [5:52].

El modelo mental más útil es tratar cada ticket como un documento legal y al modelo como un empleado junior: necesita supervisión, control sobre las copias y capacidad de corregir errores.

Ahora es tu turno. Camila, de Chile, trabaja en una startup que quiere usar IA para analizar conversaciones de soporte y detectar clientes en riesgo de cancelación [6:18]. El sistema procesará mensajes de clientes, historial de uso y patrones de comportamiento. ¿Hay datos personales o sensibles? ¿Hay terceros involucrados? ¿Sería rojo, amarillo o verde? Dejá tu análisis en los comentarios.