Checklist de triaje antes de lanzar un proyecto con IA

Antes de lanzar cualquier proyecto con IA, necesitas un checklist de triaje que responda una pregunta incómoda: ¿qué datos salen de tu sistema? Esta guía es para equipos técnicos y de producto que quieren tomar decisiones documentadas, no improvisadas, sobre riesgo y datos personales.

La idea central es simple pero poderosa: el triaje se ejecuta al inicio del proyecto, no al final. Piénsalo como la inspección previa al vuelo de un piloto. No la salta aunque tenga prisa. Y produce una decisión clara: el caso avanza, necesita cambios o se detiene [00:56].

¿Qué revisa el checklist de triaje antes de lanzar IA?

Este checklist tiene seis preguntas, y cada una dispara una acción concreta [01:20]. No son intenciones escritas, son controles verificables. Ese es justamente el punto que queda abierto cuando armas un flujo de datos sin comprobar si los controles funcionan de verdad.

¿Hay datos personales o sensibles en juego?

La primera pregunta revisa tres puntos del flujo: entrada, contexto y salida [01:26]. En la entrada, el texto que llega al modelo puede traer nombres, correos, documentos o datos de salud. En el contexto, el sistema mezcla documentos privados con públicos. Y en la salida, la respuesta podría exponer datos que el usuario nunca pidió.

Mira este ejemplo: alguien escribe "tengo diabetes y vivo en Buenos Aires". Ahí tienes datos de salud y ubicación en una sola oración [01:57].

La segunda pregunta separa dos conceptos que solemos confundir. Un dato sensible no es lo mismo que un dato personal. 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 [02:10]. La regla práctica es clara.

¿Cómo sé si un dato es sensible? Un dato es sensible si puede identificar o discriminar a una persona. Ejemplos: información médica, financiera, biométrica o de ubicación.

¿Quién recibe los datos y qué se guarda en logs?

La tercera pregunta apunta a terceros. Siempre necesitas saber qué datos salen, quién los recibe, si ese tercero es un procesador o un controlador, y en qué país opera [02:47]. Si una empresa en Latinoamérica envía datos a un modelo en otro país, las leyes locales siguen aplicando. Y algo clave: lo que envías puede no quedarse solo ahí.

La cuarta pregunta es sobre logs: qué se guarda, quién accede y por cuánto tiempo [03:07]. Piénsalo como una cámara de banco. Graba, pero con reglas claras.

• Un log abierto a cualquiera no es seguridad, es un riesgo.
• Un log que se puede modificar no sirve para auditoría.
• Guardar logs indefinidamente crea una responsabilidad innecesaria.

Esas reglas convierten un registro pasivo en un control real. Sin ellas, tu log es una puerta abierta.

¿Cuándo se necesita revisión humana?

La quinta pregunta mide el impacto si algo sale mal [03:34]. No es lo mismo un chatbot recomendando productos que un modelo decidiendo quién obtiene un crédito. No todos los errores cuestan igual.

La sexta pregunta cierra el checklist: ¿hay revisión humana donde se necesita? Si la decisión afecta derechos, salud o trabajo, un humano debe poder intervenir. No es opcional [03:56].

¿Cómo funciona el semáforo de decisión rojo, amarillo o verde?

Las seis respuestas alimentan un semáforo que traduce el análisis en una acción [04:10]. Es la forma de que el triaje no quede en un documento olvidado.

• Rojo, detener: casos prohibidos o con daño serio.
• Amarillo, mitigar: hay problemas, pero se pueden corregir.
• Verde, aprobar: todo cumple, pero igual se documenta.

Veamos un ejemplo rápido. Un banco quiere aprobar préstamos con IA [04:25]. ¿Está prohibido? No. ¿Perfila personas? Sí, eso es alto riesgo. ¿Hay sesgo? Sí. ¿Hay revisión humana? No. Resultado: mitigar antes de lanzar.

¿Qué pasa cuando un resumen de IA se vuelve el registro oficial?

Bajemos esto a tierra con un caso concreto. Una empresa decide usar un LLM para resumir sus tickets de soporte y convierte ese resumen en el registro oficial de la compañía [04:52]. El problema es que esos tickets están llenos de datos personales: nombres, correos, incluso datos de tarjetas.

Un cliente escribe: "hola, me llamo Juan Pérez, DNI 12345" [05:19]. La primera pregunta salta sola: ¿el proveedor del modelo está usando esos datos para entrenar su IA?

El impacto real aparece cuando el resumen se vuelve oficial. Una simple alucinación se transforma en un error legal. El ticket original dice "mi pedido llegó tarde", pero el resumen dice "el cliente solicitó un reembolso" [05:44]. Eso es un registro corrupto.

¿Qué es un registro corrupto en IA? Es cuando el resumen generado por un modelo distorsiona el contenido original y ese resumen se vuelve el documento oficial, creando un error legal.

¿Qué acciones concretas exige un caso en amarillo?

Cuando el triaje dice mitigar, necesitas acciones específicas, no buenas intenciones [06:07].

1. 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". Esto se prueba con casos diseñados para romper el sistema, no solo con confianza.
2. Revisión humana obligatoria: un agente compara el ticket original contra el resumen y aprueba con nombre y fecha.
3. Medir la tasa de correcciones: si es alta, el modelo aún no está listo.

Cada mitigación registra riesgo, acción, métrica, resultado, responsable y fecha [06:44]. Esa trazabilidad es lo que separa un control real de una promesa.

Como verificación final, tienes que poder responder con precisión qué datos salen y qué datos se quedan [06:50]. Sale un texto anonimizado hacia el modelo externo. Se queda el ticket original con datos reales, controlados. Si no puedes responder esto claramente, el caso aún no está listo.

Un modelo mental útil: trata cada ticket como un documento legal y al modelo como un empleado junior [07:14]. Necesitas alguien que revise, control sobre las copias y capacidad de corregir errores.

Ahora te toca a ti. Camila, en Chile, trabaja en una startup que quiere usar IA para analizar conversaciones de soporte y detectar clientes en riesgo de cancelación [07:31]. El sistema procesa mensajes, historial de uso y patrones de comportamiento. Identifica si hay datos personales o sensibles, detecta si hay terceros involucrados y define si el caso sería rojo, amarillo o verde. Déjame en los comentarios tu análisis o un caso real que estés viendo.