Poner un LLM en producción sin darle autonomía

La demo funciona. Alguien pega un documento desordenado, el modelo extrae los campos correctamente y la sala coincide en que esto tiene que ir a producción.

La distancia entre ese momento y un sistema que puedes operar durante un año no es la calidad del modelo. Es el diseño a su alrededor: qué pasa cuando se equivoca, cómo te enteras y quién responde por el resultado.

Empieza nombrando el costo de una respuesta equivocada

Antes que nada, escribe cuánto cuesta una sola salida equivocada. No el promedio. El peor caso realista.

Ese número determina toda la arquitectura. Un modelo que resume notas internas y un modelo que codifica una reclamación médica son la misma tecnología en sistemas completamente distintos.

Costo de una respuesta equivocada	Papel del modelo	Revisión
Molestia leve, fácil de deshacer	Actúa directo	Muestreo después del hecho
Retrabajo interno, sin impacto externo	Actúa y marca baja confianza	Revisa la cola marcada
Alguien externo lo ve, aún recuperable	Propone, una persona confirma	Toda salida, antes de salir
Mueve dinero o crea un registro regulado	Propone, una persona edita y firma	Toda salida, con traza de auditoría
Irreversible o jurídicamente vinculante	Solo asiste	El modelo nunca produce el artefacto

Fíjate en que ninguna fila dice "cuando el modelo sea lo bastante exacto, quita a la persona". La exactitud te mueve hacia abajo en la columna de revisión; no te mueve hacia arriba en la de autonomía. Un modelo 99% exacto en un proceso irreversible sigue produciendo una catástrofe por cada cien ejecuciones.

El umbral es una decisión de negocio

La mayoría de los sistemas con LLM en producción necesita una señal de confianza para que los casos inciertos lleguen a una persona. Dónde se pone ese umbral no es una elección de ingeniería, y tratarlo como si lo fuera es como estos proyectos salen mal.

El umbral es un intercambio entre dos costos:

• Por debajo del umbral, el trabajo va a un humano. Eso tiene un costo conocido por ítem y una cola.
• Por encima del umbral, el trabajo pasa sin revisar. Eso tiene un costo desconocido por error y una tasa.

Fijar el umbral significa que alguien con autoridad presupuestaria decida cuántos errores por mil son aceptables, dado lo que cuesta cada error. El trabajo de ingeniería es medir ambas curvas y presentarlas. No es elegir el número.

La confianza no es lo que el modelo dice de sí mismo

Preguntarle a un modelo qué tan confiado está produce un número que parece una probabilidad y no lo es. Los modelos son sistemáticamente demasiado confiados, y ese número correlaciona más con lo fluida que sonó la respuesta que con si era correcta.

Señales más fiables, aproximadamente por utilidad:

1. Acuerdo entre ejecuciones independientes. Misma entrada, muestreo distinto o formulación distinta. La discrepancia es una señal fuerte de caso incierto.
2. Verificabilidad contra la fuente. Si el modelo extrajo un valor, ¿aparece ese valor en la entrada? Un campo extraído que no está en el documento es una alucinación, por confiado que algo diga estar.
3. Validación estructural. ¿La salida parsea, el total cuadra, el código existe en el catálogo, la fecha es plausible? Barato, determinista y atrapa una proporción sorprendente de fallos.
4. Distancia de la distribución de entrenamiento. Las entradas distintas a todo lo que el sistema ha visto merecen una persona, independientemente de lo que produjo el modelo.

Las tres primeras cuestan llamadas extra o código extra. Ese costo es el precio de saber cuándo detenerse.

Qué debe detectar realmente la revisión humana

"Una persona lo revisa" no es un control salvo que la persona pueda detectar el error. Tres detalles de diseño deciden si la revisión es real:

Muestra la evidencia, no solo la respuesta. Un revisor que ve el valor extraído con un enlace a la línea de origen verifica en segundos. Un revisor que ve solo el valor únicamente puede adivinar.

Haz que la acción correcta sea tan rápida como la perezosa. Si aprobar es un clic y corregir es un formulario, vas a recibir aprobaciones. El camino de edición tiene que ser al menos tan rápido como el de aceptación.

Mide la discrepancia de los revisores. Si los revisores aprueban el 100% de lo que ven, la revisión no está ocurriendo. Ese número es tu mejor señal de si el control es real, y vale la pena alertar sobre él.

Registro, porque te lo van a preguntar

En algún momento alguien va a preguntar por qué el sistema produjo cierta salida cierto día. Si no puedes responder, el sistema no debería estar en un proceso regulado.

Como mínimo, por decisión: la entrada, el modelo y su versión, la versión del prompt, la salida cruda, la señal de confianza, la decisión de enrutamiento y, cuando intervino una persona, quién fue y qué cambió. Retención suficiente para cubrir tu ventana de auditoría.

Aquí también el tratamiento de datos se vuelve concreto: qué va al proveedor del modelo, si puede usarse para entrenar y cuánto tiempo lo conserva. Nuestra posición está escrita en la política de IA, y los controles de acceso alrededor en las prácticas de seguridad.

Decisiones que un modelo no debería asumir

Independientemente de la exactitud, algunas decisiones no deberían quedar detrás de un modelo, porque el fallo no se corrige después:

• Cualquier cosa que termina una relación: denegación de atención, cierre de cuenta, despido.
• Cualquier cosa que crea un registro legal o regulado sin un firmante nombrado.
• Cualquier cosa en la que la persona afectada tiene derecho a una explicación que no puedes producir.

Para esos casos el modelo puede preparar, resumir o redactar. Una persona decide y firma. Eso no es conservadurismo, es el único diseño en el que la responsabilidad tiene dónde aterrizar.

Si el proceso alrededor es en realidad automatización de pantalla y no una decisión, el balance es otro: mira RPA o integración por API. Y si el modelo necesita datos de un sistema que nadie puede cambiar, eso es primero un problema de capa anticorrupción.