El piloto de IA que nunca llegó a producción: qué faltaba en datos y operaciones

El piloto funcionó. Con un conjunto de documentos escogidos a mano, el modelo extrajo los campos, clasificó los tickets y convenció a quienes lo habían pedido. Meses después sigue ejecutándose en un sandbox con datos de muestra, y nadie sabe decir qué haría falta para activarlo en la cola real.

Esa distancia no se cierra cambiando de modelo. Una demo responde si un modelo puede leer un documento. Producción pregunta qué pasa con cada documento, incluido el escaneado, el hilo reenviado y aquel en el que el modelo se equivoca, con datos que quizá nunca tuvieron permiso para llegar al servicio que usó el piloto.

Una demo demuestra que el modelo sabe leer; producción pregunta por cada documento

En 2015, Sculley y sus colegas de Google escribieron que solo una pequeña fracción de los sistemas reales de machine learning está compuesta por el código de machine learning, y que la infraestructura circundante que requieren es vasta y compleja. Un pipeline de modelo de lenguaje tiene la misma forma, y un piloto construido solo con la parte pequeña no tiene a su alrededor nada que le permita funcionar en producción.

Pon lo que tenía el piloto junto a lo que necesita la cola de producción, y el trabajo que falta se convierte en una lista:

• Evaluación: unos pocos ejemplos que a alguien le gustaron, frente a un conjunto etiquetado con un umbral de aprobación acordado por campo
• Datos: exportaciones, muestras o una API alojada, frente a fuentes en vivo que quizá no puedan salir de tu infraestructura
• Entrada: PDF limpios, frente a escaneos, hilos de correo, adjuntos y plantillas que cambian sin previo aviso
• Salida: texto que leía una persona, frente a registros que consume otro sistema y en los que tiene que confiar
• Operaciones: un usuario cada vez, frente al volumen de pico, una caída del servidor del modelo y un responsable después del lanzamiento

Escribe el conjunto de aceptación antes de tocar el modelo

El primer artefacto que falta es un conjunto etiquetado de documentos reales con la respuesta que debe producir cada uno. Sin él, cada cambio de prompt o de modelo lo juzga quien lea la salida ese día, y el piloto no puede superar un filtro que nunca se puso por escrito.

Las Rules of Machine Learning de Google ponen la medición antes que el modelo: su regla n.º 2 es: primero, diseñar e implementar métricas. Para la extracción y el enrutamiento de tickets, la métrica no es una única puntuación para todo el documento:

• Toma los documentos del tráfico real durante un periodo lo bastante largo como para incluir cierres de mes, festivos y los remitentes que usan formatos poco habituales
• Haz que los etiqueten las personas que hoy hacen el trabajo, dos de ellas de forma independiente en una parte del conjunto, y trata sus desacuerdos como lagunas en la especificación y no como ruido
• Puntúa cada campo por separado, porque una fecha errónea no se compensa en la media con un nombre correcto
• Escribe el umbral de aprobación por campo y por tipo de documento, y especifica qué campos pueden automatizarse y cuáles van siempre a una persona
• Mide el proceso manual actual sobre el mismo conjunto, para que el modelo se compare con la línea base real y no con la perfección
• Mantén una parte del conjunto fuera del alcance de quien ajusta los prompts, para que la puntuación final no se mida sobre los ejemplos a los que se ajustó el prompt

Los datos que no pueden salir del perímetro cambian la arquitectura, no solo el proveedor

Cuando el piloto se construyó sobre un modelo alojado con muestras, datos sintéticos o documentos que alguien autorizó a mano, y los datos reales no pueden llegar a un proveedor externo, el resultado del piloto no se traslada: el modelo de dentro puede ser otro modelo, o el mismo modelo de pesos abiertos con otra cuantización y otros ajustes de serving, y en cualquier caso hay que volver a medir su calidad sobre el conjunto de aceptación.

El modelo es el componente obvio que hay que traer dentro. No es el único, porque un pipeline de modelo de lenguaje copia los datos en más sitios que la llamada al modelo:

• El servidor de inferencia y los pesos del modelo, con sus versiones fijadas
• Los embeddings y el índice vectorial, que derivan de los documentos y que hay que proteger igual que los propios documentos
• Los prompts, las salidas y las trazas en los logs, ya que un prompt registrado contiene el documento a partir del cual se construyó
• El conjunto de aceptación, la herramienta de anotación y la cola de revisión
• La monitorización y el seguimiento de errores, que se convierten en una copia externa de los datos cuando funcionan como servicio alojado

El enmascaramiento ayuda donde los logs tienen que salir de una zona restringida. Presidio, un framework de código abierto que nació en Microsoft, detecta y anonimiza datos personales en texto, y su documentación indica que, como la detección es automática, no hay garantía de que encuentre toda la información sensible. El enmascaramiento reduce la exposición; no sustituye a mantener los datos dentro.

La entrada es la mitad poco vistosa: escaneos, hilos y adjuntos

Un piloto recibe documentos; producción recibe lo que produzcan los remitentes. Antes de cualquier llamada al modelo, el pipeline tiene que convertir eso en texto que después pueda citar:

• Los escaneos y las fotos pasan por OCR, cuyos errores en dígitos y en columnas de tablas llegan al modelo como texto con apariencia de certeza
• Los hilos de correo y de tickets arrastran respuestas citadas, firmas y avisos legales, así que hay que separar el último mensaje del historial
• El contenido suele estar en los adjuntos, y cada formato necesita su propia vía de extracción
• Cada chunk conserva su origen, el archivo, la página y el offset, para que cada campo extraído pueda rastrearse hasta el fragmento del que salió
• Los duplicados, como un aviso reenviado o un ticket reabierto por correo, se detectan antes de que se conviertan en dos registros

Las entradas largas necesitan su propio cuidado. En Lost in the Middle, publicado en TACL en 2024, Liu y sus colegas mostraron que, en los modelos que probaron, el rendimiento a menudo es máximo cuando la información relevante está al principio o al final del contexto de entrada, y se degrada de forma significativa cuando está en medio de un contexto largo. Dividir un documento largo por secciones, conservando el origen en cada chunk, es una opción por defecto más segura que suponer que el modelo lee todo el contexto por igual, y el conjunto de aceptación muestra qué se cumple en tus documentos.

La salida estructurada necesita un esquema, un validador y un lugar para la respuesta errónea

La decodificación restringida (constrained decoding) limita el modelo a un JSON que cumple un esquema: vLLM la admite como structured outputs, y llama.cpp mediante gramáticas. Fija la forma del registro, dentro de las características de esquema que admite el backend y siempre que la generación no se corte por el límite de tokens, pero no su veracidad: un registro bien formado puede seguir llevando la fecha equivocada.

La veracidad se comprueba después del modelo, con código en el que el negocio ya confía:

• Comprobaciones de tipo y formato: fechas, divisas e identificadores con dígito de control, como el ISIN
• Reglas entre campos, como una fecha de fin de periodo que no puede ser anterior a su fecha de inicio
• Consultas a datos de referencia que la empresa ya mantiene, como un instrumento o un cliente conocidos
• Coherencia con el origen: cada valor extraído, antes de la normalización, tiene que aparecer en el fragmento que cita

La confianza del propio modelo es un filtro débil. El GPT-4 Technical Report de OpenAI, publicado en 2023, muestra que en un benchmark de opción múltiple el modelo preentrenado estaba muy bien calibrado y que el postentrenamiento redujo la calibración. Una certeza autodeclarada o una probabilidad de token es una señal que hay que contrastar con el conjunto de aceptación, no un umbral en el que confiar por defecto.

Un registro que falla cualquier comprobación va a una cola de revisión, no al sistema aguas abajo. La cola es un producto en sí misma: necesita un responsable, un plan de capacidad en horas de revisores, el fragmento de origen mostrado junto a cada campo y correcciones que vuelvan al conjunto de aceptación.

Los tickets y los documentos son entrada no confiable para el modelo

Un ticket de soporte es texto escrito por alguien de fuera de la empresa, y un documento puede llevar instrucciones que su remitente colocó a propósito. El OWASP Top 10 for LLM Applications 2025 sitúa la prompt injection en primer lugar, incluida la inyección indirecta, en la que las instrucciones llegan dentro de contenido externo que procesa el modelo, como un sitio web o un archivo.

Tres entradas de esa misma lista se traducen en reglas de diseño para un pipeline de documentos:

• Prompt injection: marca cada documento y ticket como contenido no confiable, separado de las instrucciones en una plantilla que el remitente no puede editar
• Manejo inadecuado de la salida (Improper output handling): valida la salida del modelo antes de que cualquier sistema actúe sobre ella, como validarías la entrada de un usuario
• Agencia excesiva (Excessive agency): da al pipeline el mínimo privilegio que necesita su tarea, para que un modelo que lee tickets no pueda cerrar cuentas ni enviar pagos

OWASP también señala que no está claro si existe una prevención infalible de la prompt injection. El peso lo soportan las comprobaciones de la salida y el límite de privilegios, no la redacción del prompt.

Fija el modelo, el prompt y el parser como una sola versión

El comportamiento de un pipeline es el resultado de varios artefactos que cambian de forma independiente. Trátalos como una sola release y guarda su identificador en cada registro que produzca:

• Los pesos del modelo por checksum, con la cuantización y la versión del servidor de inferencia
• La plantilla del prompt, el esquema de salida y los parámetros de decodificación
• El motor de OCR, las reglas de chunking y los validadores
• La versión del conjunto de aceptación con la que se puntuó la release

Fijar versiones no hace que las salidas sean idénticas. Thinking Machines Lab mostró en septiembre de 2025 que un servidor de inferencia puede devolver completions distintas para el mismo prompt con temperatura cero, porque el resultado de una solicitud depende de cuántas otras solicitudes comparten su lote; la misma publicación muestra que los kernels invariantes al lote eliminan este efecto a costa de velocidad. Salvo que el servidor ejecute esos kernels, la reproducibilidad significa volver a ejecutar el conjunto de aceptación en cada release y comparar puntuaciones, no esperar un texto idéntico.

Operaciones: capacidad, colas y la hora en que el servidor del modelo está caído

La capacidad se planifica en tokens, no en documentos. Mide la distribución de la longitud de entrada y de salida con tráfico real, porque un adjunto largo puede costar tanto como muchos tickets cortos, y el tiempo de generación crece con la longitud de la salida.

Los sistemas de serving agrupan las solicitudes en lotes para mantener ocupado el acelerador. En el paper de vLLM, presentado en SOSP 2023, Kwon y sus colegas informaron de que paginar la caché key-value de la atención mejoró el throughput entre 2 y 4 veces con el mismo nivel de latencia en comparación con los sistemas que evaluaron. Los lotes más grandes suben el throughput y también la latencia de cada solicitud, algo que una cola de back-office puede absorber y un paso interactivo no, así que los dos se separan:

• Trabajo interactivo, como el triaje de tickets por el que espera un agente de soporte, con su propia capacidad y un objetivo de latencia
• Trabajo por lotes, como la extracción nocturna, en una cola que absorbe los picos y se puede pausar
• Backpressure entre la ingesta y el servidor del modelo: una cola acotada y un límite de concurrencia, para que un pico de documentos espere o se rechace con una señal de reintento en lugar de sobrecargar el servidor
• Procesamiento idempotente con el documento como clave, para que un reintento tras una caída no cree un segundo registro
• Un fallback al proceso manual cuando el servidor del modelo no está disponible, para que el trabajo espere a una persona en lugar de desaparecer

El fallback es lo que hace reversible la activación del pipeline. El proceso manual que existe hoy sigue siendo el suelo, y el pipeline le va quitando trabajo campo a campo en lugar de sustituirlo en una sola fecha.

Monitoriza las respuestas, no solo los servidores

Los dashboards de los servidores dicen si el pipeline respondió. No dicen si las respuestas eran correctas, y un modelo que se degrada con una plantilla nueva mantiene su latencia. La monitorización de un pipeline de extracción o de tickets cubre ambas cosas:

• La tasa de envío a la cola de revisión y las correcciones de los revisores por campo, por tipo de documento y por release
• Una muestra periódica de registros automatizados que las personas vuelven a comprobar frente a los criterios de aceptación
• Deriva de la entrada: remitentes nuevos, plantillas nuevas, la mezcla de idiomas y la longitud de los documentos
• Fallos de los validadores por regla, que pueden revelar un formato nuevo antes de que se muevan las métricas de precisión
• Tokens, horas de acelerador y antigüedad en cola por tipo de documento, junto a la latencia de cada etapa

El Generative AI Profile del NIST, NIST AI 600-1, publicado en julio de 2024, organiza este trabajo bajo las cuatro funciones de su AI Risk Management Framework: gobernar, mapear, medir y gestionar. Los nombres importan menos que la consecuencia: medir después del lanzamiento es una actividad con nombre propio y con personal asignado, no algo que hace el equipo del piloto cuando tiene tiempo.

Despliega por campo y por tipo de documento: shadow, asistido y después automatizado

Activar el pipeline para todo en una sola fecha junta todos los riesgos en un único evento. Un despliegue por etapas los mantiene separados:

• Shadow: el pipeline procesa tráfico en producción, no escribe en ningún sitio y sus registros se comparan con lo que produjeron las personas
• Asistido: el pipeline rellena previamente, una persona confirma cada registro y las correcciones se cuentan por campo
• Automatizado por campo y por tipo de documento, solo donde el umbral de aprobación se mantiene con tráfico en producción, y todo lo demás sigue pasando por revisión
• Un interruptor para volver al modo asistido por tipo de documento, que el responsable operativo acciona sin una aprobación aparte cuando una tasa monitorizada supera su límite

Un piloto que lee bien los documentos y aun así nunca llega a producción no ha fallado en la lectura. Nunca se le dio un conjunto de aceptación que superar, una ruta de datos que tuviera permitido usar, un lugar para sus respuestas erróneas ni un responsable para el día después del lanzamiento.

La empresa que lleva esto a producción pide tus documentos antes que tu preferencia de modelo

La pregunta que motiva este artículo, quién puede poner un pipeline de LLM dentro de tu propia infraestructura y llevarlo realmente a producción, tiene una prueba que no necesita una lista de proveedores. Una empresa que hace este trabajo pregunta por la aceptación y las operaciones antes de recomendar un modelo:

• Pide revisar una muestra de documentos y tickets reales, incluidos los malos, dentro de tu entorno o bajo tu acuerdo de datos, y pregunta cómo los gestiona hoy el proceso manual
• Propone construir primero el conjunto de aceptación con tu gente, con umbrales de aprobación por campo, antes de cualquier ajuste
• Enumera cada lugar al que se copiarán los datos, desde los pesos y los índices hasta los logs, las trazas, los datos de evaluación, la herramienta de revisión y la monitorización, y muestra que cada uno se queda dentro
• Pone los validadores, la cola de revisión y el fallback al procesamiento manual en el mismo documento de diseño que el modelo
• Trae una release que fija juntos modelo, prompt, esquema y parser, y un despliegue de shadow a automatizado por campo
• Concreta quién opera el pipeline después del lanzamiento, quién revisa la muestra y a quién se llama cuando se detiene el servidor del modelo

Cada punto es algo por lo que puedes preguntar en la primera conversación, y una respuesta vaga significa que el trabajo que le faltaba al piloto todavía no se ha acotado.

Así que la primera pregunta no es qué modelo ejecutar dentro de tu perímetro. Es qué campos, en qué documentos, aceptarías automatizados, medidos frente a qué, y quién recoge los registros que no superan la validación.

Lo que amBrain puede sustentar públicamente más allá de la integración en producción descrita en el resumen de arriba: amBrain lleva construyendo software desde 2019. Trabajamos en tres formatos: entrega completa, un equipo dedicado o ingenieros integrados en tu equipo.