Un pipeline de LLM para siniestros, tickets y expedientes KYC dentro de tu propia infraestructura: extracción, validación, revisión y auditoría

Los expedientes de siniestros, los tickets de soporte y los documentos KYC comparten el mismo problema: las personas los leen para rellenar campos que necesita otro sistema. Un siniestro se convierte en un número de póliza, una fecha del siniestro y unas partidas; un ticket, en una categoría y un cliente; un documento de identidad, en un nombre, una fecha de nacimiento y una fecha de caducidad. El requisito que acompaña al trabajo suele formularse antes que nada: los documentos no pueden ir a OpenAI ni a ningún otro proveedor externo de modelos.

Dónde se ejecuta el modelo es una decisión aparte, comparada en un artículo anterior de este blog. Este parte de un modelo de pesos abiertos servido dentro de tu infraestructura y describe el pipeline que lo rodea, desde la ingesta hasta el registro que consume otro sistema. Explica la mecánica; no es un caso de estudio.

Siete etapas, y todas se quedan dentro

Mantener los datos lejos de los proveedores externos es una propiedad de todo el pipeline, no de la llamada al modelo: el motor de OCR, la herramienta de revisión, el conjunto de evaluación, el almacén de auditoría y los logs contienen todos el documento o algo derivado de él, como enumera por completo el artículo anterior sobre pilotos.

Ingesta: clasifica el documento antes de que nada lo lea

Todas las etapas posteriores dependen del tipo de documento: el esquema, las reglas, los revisores y el plazo de conservación, así que la clasificación va primero y decide la ruta. Un expediente de siniestro que llega por correo puede contener un parte de siniestro, facturas, fotos y un informe médico; cada adjunto se clasifica por separado y se vincula al mismo expediente.

• Registra el canal, el remitente y un hash del contenido a la llegada, para que un documento enviado dos veces se reconozca antes de convertirse en dos expedientes
• Clasifica a partir de una lista cerrada de tipos; la documentación de vLLM sobre structured outputs incluye un parámetro choice, con el que la salida será exactamente una de las opciones, así que el clasificador no puede inventarse un tipo
• Envía a una persona, en lugar de al esquema más cercano, un documento que no encaje con ningún tipo o que encaje con un nivel de acuerdo bajo

Primero el texto y la estructura de la página, después el modelo de lenguaje

Un PDF generado por software lleva una capa de texto que puede leerse directamente. Un escaneo o una foto de móvil solo lleva píxeles, y algo tiene que convertirlos en caracteres con posiciones.

Los motores de código abierto para este paso se ejecutan en local. La documentación de la línea de comandos de Tesseract muestra una salida TSV con una columna de confianza para cada palabra y una salida hOCR con un atributo de confianza por palabra, una señal por palabra que la etapa de enrutamiento puede usar. Docling, una biblioteca de conversión de código abierto con licencia MIT, enumera entre sus funciones para PDF la maquetación de la página, el orden de lectura y la estructura de tablas, además del soporte de OCR para PDF escaneados e imágenes y la ejecución local para datos sensibles y entornos aislados (air-gapped).

• Lee la capa de texto donde exista y usa OCR solo donde no, para que los documentos limpios no adquieran errores de reconocimiento
• Conserva el número de página y el cuadro delimitador (bounding box) de cada palabra, para que cada campo extraído pueda mostrarse después a un revisor en la página de la que salió
• Conserva las tablas como tablas: una factura cuyas columnas se aplanan en una sola línea de texto pierde qué importe corresponde a qué partida

Un modelo de visión y lenguaje puede leer en su lugar la imagen de la página: la documentación de vLLM sobre entradas multimodales indica que la entrada de imágenes se admite conforme a la OpenAI Vision API. Qué funciona mejor se mide con tus documentos, teniendo en cuenta que una etapa de OCR separada devuelve las posiciones de las palabras y su confianza, y un modelo que lee una imagen no.

Salida restringida por esquema: la forma está garantizada, el contenido no

Cada tipo de documento tiene su propio esquema de salida, versionado como el código. La documentación de vLLM sobre structured outputs enumera cinco tipos de restricción: choice, regex, un JSON schema, una gramática libre de contexto y un structural tag, con backends que incluyen xgrammar, guidance, outlines y lm-format-enforcer, y un valor por defecto, auto, que intentará elegir un backend adecuado según los detalles de la solicitud.

• Haz de «no encontrado» un valor explícito para cada campo, para que una fecha del siniestro ausente se registre como ausente en lugar de adivinarse
• Usa enumeraciones para todo aquello en función de lo cual otro sistema vaya a bifurcar su lógica: tipo de siniestro, categoría del ticket, tipo de documento, código de país
• Añade a cada campo una referencia de origen, la página y las palabras de las que se tomó, para que la validación y la revisión puedan contrastarlo con el documento

Vuelve a validar la salida en el código de la aplicación con un validador de JSON Schema corriente. Los backends difieren: la misma página señala que xgrammar, guidance y outlines usan expresiones regulares al estilo de Rust, mientras que lm-format-enforcer usa el módulo re de Python, y que en los modelos Qwen3 Coder con el razonamiento (reasoning) activado los structured outputs podrían quedar desactivados si el contenido del razonamiento no se parsea en un campo aparte. Una generación detenida por el límite de tokens también termina a mitad de registro. La segunda comprobación es barata.

Validación: las reglas de negocio que ya existen, escritas como código

Un registro que cumple el esquema puede seguir siendo erróneo. Las comprobaciones que lo detectan son las que el back-office aplica hoy a mano, escritas como código por tipo de documento:

• Siniestros: el número de póliza existe en el sistema de pólizas, la fecha del siniestro cae dentro del periodo de cobertura y las partidas de la factura suman el total de la factura
• Tickets: el identificador del cliente corresponde a una cuenta real, y el producto mencionado es uno que el cliente realmente tiene
• KYC: los dígitos de control de la zona de lectura mecánica son correctos, la fecha de caducidad no ha pasado y el nombre y la fecha de nacimiento de la zona de lectura mecánica coinciden con los mismos campos leídos en la zona de inspección visual

Los documentos de identidad tienen su propio validador. ICAO Doc 9303, la especificación de los documentos de viaje de lectura mecánica, define dígitos de control en la zona de lectura mecánica calculados en módulo 10 con una ponderación 7, 3, 1 que se repite de forma continua, en la que las letras de la A a la Z cuentan como 10 a 35 y el carácter de relleno como cero, y establece que los dígitos de control permiten a los lectores verificar que los datos se interpretan correctamente.

Enrutamiento: reglas y señales deciden qué campos ve una persona

El enrutamiento se decide por campo, no por documento: un siniestro cuyo total de factura falla mientras todo lo demás pasa envía un campo a una persona, no el expediente entero. Las señales:

• Cualquier fallo de un validador, incluido un campo que el esquema exige y que el modelo marcó como no encontrado
• Confianza baja del OCR en las palabras a partir de las que se construyó el campo, con el umbral fijado por campo sobre el conjunto de evaluación
• Dos fuentes que no coinciden, como la zona de lectura mecánica y la zona de inspección visual de un mismo pasaporte
• Campos que, por decisión, nunca se automatizan, como un importe reclamado por encima de un límite fijado
• Una muestra aleatoria de campos que lo superaron todo, para que la tasa de errores que nadie marcó se mida en lugar de suponerse

La declaración de certeza del propio modelo se deja fuera a propósito; un artículo anterior de este blog explica por qué es un filtro débil.

La pantalla de revisión muestra la página con las palabras citadas resaltadas junto al valor propuesto, de modo que el revisor comprueba en lugar de releer. Cada corrección se guarda por campo con el valor antiguo, el valor nuevo, el revisor y un motivo elegido de una lista corta. Cuando una segunda persona la confirma, se incorpora al conjunto de evaluación, pero nunca a la parte congelada sobre la que se toman las decisiones de release.

Evaluación por tipo de documento y por campo, no una única puntuación global

Una única cifra de precisión para el pipeline oculta el resultado que importa, como que las fechas de caducidad fallen en los documentos de identidad de un país mientras todos los demás campos pasan. Mide siguiendo los mismos ejes que usa el enrutamiento:

• Por campo: coincidencia exacta tras la normalización y, por separado, con qué frecuencia el campo se omitió o se inventó cuando el documento lo contiene o no lo contiene
• Por tipo de documento y por tipo de entrada, como PDF digital, escaneo y foto de móvil, porque cada uno tiene su propio patrón de errores
• Por ruta: la proporción de campos automatizados y la tasa de error en la muestra extraída de ellos
• Ponderada por coste: un número de cuenta bancaria erróneo y el nombre de una calle mal escrito no son el mismo error

Una release, sea un modelo nuevo, un prompt, un esquema, una versión de OCR o un validador, se puntúa sobre el conjunto congelado antes de pasar a producción, y el filtro es por campo: ningún campo de ningún tipo de documento cae por debajo de su umbral de aprobación, aunque la media suba. Cómo construir el primer conjunto etiquetado se explica en el artículo anterior sobre los pilotos que nunca llegaron a producción.

Pista de auditoría: qué modelo y qué prompt produjeron cada campo

Un siniestro en disputa o la pregunta de un auditor sobre una identidad aceptada se refiere a un campo de un documento. El registro que la responde se escribe mientras el pipeline se ejecuta, una entrada por campo, en un almacén de solo anexado (append-only):

• El identificador del documento y el hash del contenido, la página y las palabras que cita el campo
• La versión del motor de OCR o de análisis de la estructura de la página y su confianza para esas palabras
• El nombre del modelo y el checksum de los pesos, la versión de la plantilla del prompt y la versión del esquema
• El resultado de cada validador, la ruta tomada y el motivo
• El revisor, el valor antes y después, y la hora, si lo cambió una persona

El Reglamento de IA de la UE (AI Act) establece un requisito de registro de eventos para los sistemas que considera de alto riesgo: el artículo 12(1) dispone que los sistemas de IA de alto riesgo permitirán técnicamente el registro automático de acontecimientos (archivos de registro) a lo largo de todo el ciclo de vida del sistema. El anexo III enumera los usos de alto riesgo, entre ellos evaluar la solvencia de personas físicas, salvo para detectar fraudes financieros, y la evaluación de riesgos y la fijación de precios en los seguros de vida y de salud; el artículo 6(3) establece cuándo un sistema de la lista no se considera, aun así, de alto riesgo, por ejemplo cuando realiza una tarea de procedimiento limitada. Si un pipeline concreto entra en su ámbito es una cuestión para el equipo jurídico del cliente; un registro por campo escrito en tiempo de ejecución es útil en cualquier caso.

Datos personales: cada etapa ve solo lo que necesita su tarea

Un pipeline copia datos personales en más lugares que la carpeta original. El artículo 5(1)(c) del RGPD exige que los datos personales sean adecuados, pertinentes y limitados a lo necesario en relación con los fines para los que son tratados. El artículo 25(2) pide medidas que garanticen que, por defecto, solo sean objeto de tratamiento los datos personales necesarios para cada uno de los fines específicos, y lo aplica a la cantidad de datos recogidos, a la extensión de su tratamiento, a su plazo de conservación y a su accesibilidad. En términos de pipeline:

• El modelo recibe las páginas que necesita su esquema, no el expediente completo
• Los revisores ven los campos de su cola, y el acceso a los documentos completos se concede por rol y queda registrado
• Los logs de la aplicación registran identificadores de documento, nombres de campo y resultados, no valores de campo ni prompts
• Las trazas de prompts y salidas, cuando se conservan para depuración, viven en el mismo almacén restringido que los documentos, con un plazo de conservación corto propio
• El conjunto de evaluación es una copia de documentos reales y recibe los mismos controles de acceso

La OWASP Logging Cheat Sheet incluye los datos personales sensibles y algunas formas de información de identificación personal, como los datos de salud y los identificadores gubernamentales, entre los datos que normalmente no deberían registrarse directamente en los logs, y dice que, en su lugar, esos datos deberían eliminarse, enmascararse, sanearse, convertirse en hash o cifrarse.

La conservación varía según el tipo de documento, y para KYC en la UE la fija la normativa de prevención del blanqueo de capitales. El artículo 77 del Reglamento (UE) 2024/1624, aplicable a partir del 10 de julio de 2027, exige a las entidades obligadas conservar una copia de los documentos y la información obtenidos en la diligencia debida con respecto al cliente y garantizar que esos registros no contengan partes suprimidas. Fija un plazo de conservación de cinco años, contados desde el final de la relación de negocios o desde la fecha de una transacción ocasional, tras el cual los datos personales deben suprimirse, salvo las excepciones previstas en el mismo artículo. El registro KYC original se mantiene completo en el sistema de registro principal; las copias propias del pipeline, desde las trazas hasta las instantáneas de revisión, se minimizan y se eliminan según un calendario propio más corto.

Throughput: una cola para el pico, capacidad para el régimen estable

El volumen del back-office es irregular: un solo evento puede afectar a muchos asegurados a la vez, y una caída llena la cola de tickets. Las colas, el backpressure y un fallback manual se tratan en el artículo anterior sobre pilotos; lo específico de un pipeline de documentos autoalojado es esto:

• Separa las colas por urgencia: una comprobación KYC que un cliente está esperando durante el onboarding no hace cola detrás de un lote de siniestros históricos
• Escala los workers de OCR en CPU y los servidores de modelos en aceleradores de forma independiente, porque se saturan con volúmenes distintos
• Vigila la cola propia del motor de serving: vLLM expone métricas de Prometheus en su endpoint /metrics, incluidos el número de solicitudes a la espera de procesarse y la fracción de bloques de la caché key-value en uso
• Escala los workers según la profundidad de la cola y no según la carga de CPU; la documentación de KEDA describe cómo escalar cualquier contenedor en Kubernetes según el número de eventos pendientes de procesar, con scalers para sistemas de mensajería, entre otros, y escalado a cero (scale-to-zero)

La capacidad de aceleradores dentro de tu propia infraestructura es fija a corto plazo, así que el orden en que ceden las colas se decide de antemano, no durante el pico.

Siniestros, tickets y KYC: el mismo esqueleto, reglas distintas

• Siniestros: muchos documentos por expediente, tablas en las facturas y, a menudo, datos relativos a la salud, que el artículo 9 del RGPD incluye entre las categorías especiales cuyo tratamiento está prohibido salvo que se aplique una excepción del mismo artículo. El artículo 22 otorga a la persona el derecho a no ser objeto de una decisión basada únicamente en el tratamiento automatizado que produzca efectos jurídicos en ella o le afecte significativamente de modo similar, con excepciones en el artículo 22(2). Por eso, que el pipeline solo extraiga y compruebe mientras decide un tramitador de siniestros es una decisión de diseño que se toma con el delegado de protección de datos del cliente, no un valor por defecto de ingeniería
• Tickets: textos cortos, mucho volumen y alguien esperando una respuesta, así que la latencia importa más; la salida es sobre todo una categoría, una prioridad y unos pocos identificadores. El texto de los tickets lo escriben personas de fuera de la empresa y es entrada no confiable para el modelo, un riesgo que se trata en el artículo anterior sobre pilotos
• KYC: pocos tipos de documento con formatos estrictos, como pasaportes y documentos de identidad, lo que hace que la validación basada en reglas sea sólida. Un selfie cotejado con la foto del documento añade datos biométricos, que el artículo 9 del RGPD también incluye como categoría especial cuando se tratan para identificar de manera unívoca a una persona. La conservación sigue la normativa de prevención del blanqueo de capitales, y el resultado alimenta una decisión de cumplimiento que toma una persona o una regla documentada

Que los documentos no lleguen a un proveedor externo de modelos lo decide dónde se ejecuta el modelo. Si se le pueden confiar al pipeline lo decide todo lo que rodea al modelo: el esquema, las reglas, la cola de revisión y el registro de quién produjo cada campo.

¿Qué empresas de ingeniería construyen esto dentro de tu propia infraestructura?

La pregunta tiene tres tipos de respuesta, y venden cosas distintas. Los proveedores de procesamiento de documentos venden una plataforma, a veces instalable en tus propios servidores (on-premises), que configuras para tus documentos. Los proveedores de nube venden servicios gestionados que se ejecutan en su infraestructura. Las empresas de ingeniería construyen el pipeline en tu entorno a partir de componentes abiertos y de tus reglas.

Hables con el tipo que hables, estas preguntas muestran si un equipo ha construido esto antes:

• ¿Qué etapas llaman a algún servicio fuera de tu red, incluidos el OCR, la monitorización, el seguimiento de errores y la herramienta de anotación?
• ¿Cómo es el esquema de salida de uno de tus tipos de documento y cómo se representa «no encontrado»?
• ¿Qué señales envían un campo a revisión y cómo se eligieron los umbrales?
• ¿Cómo llegan las correcciones de los revisores al conjunto de evaluación sin contaminar la parte que se usa para las decisiones de release?
• ¿Pueden mostrar, para un campo de un documento, el modelo, el prompt, el esquema y el revisor que produjeron su valor?
• ¿De quién son el código del pipeline, los esquemas y el conjunto de evaluación cuando termina el trabajo, y qué partes siguen siendo componentes reutilizables del proveedor?

Una respuesta que se queda en lo general en la primera y en la quinta pregunta significa que la ruta de datos y la pista de auditoría todavía no se han diseñado.

Lo que amBrain puede decir sobre su propio trabajo en este ámbito

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. El cliente conserva la propiedad completa del producto y del código, salvo nuestros componentes reutilizables.

Este artículo explica cómo funciona un pipeline así; no es un caso de estudio, no nombra clientes y no afirma que amBrain haya construido un sistema de siniestros, de tickets o de KYC. El trabajo en producción mencionado arriba es la extracción de avisos de brókers y de centros de negociación para un sistema de trading.

Así que el primer paso no es elegir un modelo. Es poner por escrito, para un tipo de documento, el esquema, las reglas que lo comprueban y los campos que una persona siempre debe ver, antes de que ningún documento llegue al pipeline.