Casos de uso realistas

Un modelo de lenguaje produce texto plausible; un modelo de anomalías produce un puntaje. Ninguno de los dos «sabe» si acierta. Por eso la utilidad de una tarea depende menos de la herramienta que de dos propiedades de la tarea. La primera: si la salida se puede comprobar contra algo que ya existe, como la alerta original, un esquema o un informe publicado. La segunda: cuánto cuesta equivocarse y si hay una persona que lo detecte antes de que cause daño.

Una tarea de salida verificable y costo bajo es el mejor lugar para empezar; una de salida no verificable y costo alto es el peor, con o sin IA.

Abre casos_de_uso. La columna salida_verificable toma tres valores: sí, parcial y no. Una forma de dimensionar el piloto es sumar cuánto trabajo semanal cae en tareas cuyo resultado se puede comprobar del todo; el resto necesita otro tratamiento.

Dos filas combinan costo alto de error, salida que no se puede comprobar y ninguna revisión humana. Esa combinación es la que más cuidado merece: cuando el modelo falla, nadie lo ve y el daño ya ocurrió. Entre las dos, la de mayor volumen es la que concentra más exposición cada semana.

El equipo ya hizo un piloto de la tarea de resumen: un analista contrastó 40 resúmenes con la alerta original. Fíjate en la definición de error de notas_del_piloto: un resumen que omite un dato o que inventa uno cuenta como error, aunque suene bien. El porcentaje de resúmenes sin error es la cifra que sirve para decidir cuánta revisión hace falta.

Seis de cada cuarenta resúmenes tuvieron algún error, y dos de ellos añadieron un dato que no estaba en la alerta. Un dato inventado es más peligroso que uno omitido, porque se lee con la misma seguridad que los datos ciertos. Eso no obliga a descartar la herramienta, pero sí a decidir cómo se usa su salida.