amBrain
FinTechOct 8, 202610 min de lectura

API, autoalojado o híbrido: cómo puede una empresa regulada procesar documentos con LLM y quién lo lleva a producción

Procesamiento de documentosConfiguración híbrida de LLMSectores reguladosQuién la construye
Error al cargar la imagen

Una empresa regulada puede usar la API de un proveedor bajo contrato, sus propios servidores o una configuración híbrida que reparte los documentos por clase. La configuración híbrida necesita una tabla de enrutamiento con un responsable y un registro de la ruta de cada documento.

Una empresa regulada puede procesar documentos con LLM a través de la API de un proveedor bajo contrato, en sus propios servidores o con una combinación híbrida de ambos. Usa la API si todas las clases de documentos pueden salir bajo contrato, y un modelo autoalojado si no puede salir ninguna. Una configuración híbrida solo compensa cuando hay muchos documentos en cada lado, porque operas dos sistemas y la tabla de enrutamiento queda a tu cargo. Para saber qué empresas han llevado un sistema así a producción, pide los registros que deja tras de sí.

La respuesta corta: pon por escrito tus clases de documentos y adónde puede ir cada una. Si eliges una configuración híbrida, asigna a su tabla de enrutamiento un responsable y un número de versión, y registra la ruta de cada documento. Para comprobar a una empresa, pide ver su registro de rutas y hablar con quien opera el sistema hoy.

¿Cómo se comparan los tres enfoques?

El artículo sobre el perímetro cerrado, enlazado arriba, los compara en detalle. Con la API de un proveedor, tus datos están cubiertos por el contrato y por los controles de datos a los que se compromete el proveedor. La página de controles de datos de OpenAI, consultada el 8 de octubre de 2026, indica que los datos enviados a su API desde el 1 de marzo de 2023 no se usan para entrenamiento, salvo que lo aceptes expresamente (opt-in).

La misma página indica que los logs de monitorización de abusos, que OpenAI usa para detectar usos indebidos y que pueden contener prompts y respuestas, se conservan por defecto hasta 30 días. Se conservan más tiempo si la ley lo exige o si es razonablemente necesario para proteger los servicios de OpenAI o a terceros frente a daños. Para que tu contenido quede fuera de esos logs hace falta la aprobación previa de OpenAI.

En el servicio gestionado de modelos de una plataforma en la nube, el proveedor de nube ejecuta el modelo por ti, y algunos de sus modelos se venden bajo un contrato de nube que quizá ya tengas. La documentación de Microsoft indica que, en los modelos vendidos por Azure, tus prompts y las respuestas del modelo no están disponibles para OpenAI ni para otros proveedores de esos modelos. La documentación de Amazon Bedrock indica que los proveedores de modelos no tienen acceso a los prompts de los clientes ni a las respuestas del modelo. Aun así, el modelo se ejecuta en los servidores de la nube, y es tu equipo de riesgos quien decide si eso cuenta como dentro de tu perímetro, es decir, de la red y los sistemas que controla tu empresa.

Un modelo de pesos abiertos autoalojado, es decir, uno que su creador publica para que cualquiera lo descargue y lo ejecute, funciona en servidores que controlas, así que ningún documento va a un proveedor de modelos. A cambio, operar los servidores y el modelo es tarea de tu equipo.

¿Cómo es una configuración híbrida en la práctica?

Una configuración híbrida reúne en un mismo pipeline una ruta externa (la API de un proveedor o un servicio gestionado en la nube) y una ruta interna. La lógica que decide adónde va cada documento se llama enrutador. Hay tres diseños básicos, y se pueden combinar:

  • Los documentos públicos o de bajo riesgo, como normas y guías publicadas, van a la API, y los expedientes de identificación de los clientes se quedan dentro
  • Todos los documentos pasan primero por el modelo autoalojado, y aquellos en los que falla salen solo si su clase lo permite
  • Los identificadores, como los nombres, se sustituyen por marcadores dentro del perímetro antes de que el texto vaya a la API

¿Quién decide qué documentos pueden ir a una API?

Decide el área de riesgos o la de protección de datos, y el equipo de ingeniería traslada la decisión al código. Ponla primero por escrito en una tabla breve, que aquí llamamos tabla de enrutamiento. Para cada clase de documento, la tabla indica las rutas permitidas, si se exige enmascaramiento y cuánto tiempo puede conservar el texto el proveedor.

Después, el pipeline tiene que determinar la clase de cada documento. Las señales que controlas tú son más seguras que el criterio de un modelo: el canal por el que llegó, el remitente, el tipo de documento. Cuando las señales no coinciden, gana la clase más estricta, y un documento que nadie puede clasificar se queda dentro.

Esta comprobación se ejecuta dentro del perímetro. Una comprobación que pregunta a la API externa si un documento puede salir ya lo ha enviado. Un cambio en la tabla de enrutamiento pasa por revisión y recibe un número de versión y una fecha, como cualquier cambio de código.

¿Podemos enmascarar el texto y enviarlo a la API de todos modos?

A veces, con límites. Herramientas de código abierto como Presidio sustituyen nombres, números de cuenta y otros identificadores por marcadores o los cifran con una clave. Si guardas la clave dentro, el paso de descifrado de Presidio restituye los valores reales cuando vuelve la respuesta; con marcadores, mantienes tu propia tabla de qué marcador corresponde a qué valor. Los datos enmascarados de esta forma se llaman seudonimizados.

El Comité Europeo de Protección de Datos adoptó las Directrices 01/2025 sobre seudonimización el 16 de enero de 2025, como versión para consulta pública. Las directrices indican que esos datos siguen siendo datos personales si hay información adicional que permita vincularlos a una persona. Añaden que esto se aplica incluso cuando el texto enmascarado y esa información están en manos de partes distintas, como cuando el proveedor tiene el texto y tú tienes la tabla o la clave.

El Tribunal de Justicia de la UE abordó la misma cuestión en septiembre de 2025, en el asunto C-413/23 P, en el marco de las normas de protección de datos aplicables a los organismos de la UE. Declaró que los datos seudonimizados no son datos personales en todos los casos ni para todo el mundo: según las circunstancias, el enmascaramiento puede impedir que cualquiera que no sea la empresa que enmascaró los datos identifique a las personas que aparecen en ellos. Para ti, que tienes la tabla o la clave, los datos siguen siendo personales. Pregunta a tu asesor jurídico en protección de datos qué implica esto para tus contratos.

La detección es el segundo límite. Presidio encuentra datos personales con un modelo que reconoce nombres de personas, lugares y organizaciones, y con reglas que detectan formatos conocidos, como los números de cuenta. Su documentación indica que, como la detección es automática, «no hay garantía de que Presidio encuentre toda la información sensible». Fallos típicos en el trabajo con documentos:

  • El reconocimiento óptico de caracteres (OCR), el paso que convierte los escaneos en texto, lee mal un nombre, y el detector ya no ve ahí ningún nombre
  • Se identifica a una persona sin ningún nombre, por un cargo en una empresa pequeña o por un importe único en una fecha concreta
  • El campo enmascarado es justo el que necesitas: si la tarea es extraer el nombre de la contraparte, el texto enmascarado ya no lo contiene

Antes de que nadie apruebe una ruta con enmascaramiento, haz que alguien marque a mano cada identificador en una muestra de tus propios documentos y luego cuenta lo que el detector pasó por alto.

¿Qué pasa cuando un documento toma la ruta equivocada?

En una configuración híbrida, una fuga es un error de enrutamiento. Un pasaporte escaneado adjunto a un aviso rutinario, o el mensaje de un cliente citado al final de un correo reenviado, pueden llevar contenido restringido a la ruta externa. Clasifica cada adjunto por separado y trata el historial citado en un hilo como parte del contenido.

Construye el sistema de forma que una decisión equivocada detenga el documento en lugar de enviarlo fuera. El artículo sobre el perímetro cerrado, enlazado arriba, cubre la parte de red: la ruta interna no tiene claves ni contraseñas del proveedor externo ni acceso de red a él. Añade una regla: cuando el modelo autoalojado está caído, su cola espera o pasa a personas, y nunca se desvía a la API.

Si un documento sale por error, el registro de rutas muestra qué documentos salieron, cuándo y a qué proveedor. El contrato del proveedor indica cuánto tiempo puede conservarlos. Trátalo como un incidente junto con tu equipo de protección de datos, que decide si hay que notificarlo.

¿Cómo se prueba la calidad cuando el trabajo lo hacen dos modelos?

Un conjunto de aceptación es un grupo de documentos reales con la respuesta correcta para cada uno, que se usa para decidir si el sistema aprueba. Los dos modelos de una configuración híbrida responden de forma distinta, así que una única puntuación para todo el pipeline oculta la ruta más débil.

Además, no puedes probar el modelo de la API con documentos restringidos, porque no pueden ir allí. Por eso, el conjunto de aceptación compartido que el artículo sobre el perímetro cerrado recomienda para todas las rutas solo puede contener documentos permitidos en ambas rutas. Úsalo para comparar los dos modelos, y dale a cada ruta su propio conjunto, más amplio, extraído de las clases que procesa. Cuando el proveedor retira el modelo de la API, esa ruta se vuelve a puntuar antes del cambio.

¿Qué hace falta para operar las dos rutas?

Una configuración híbrida duplica los contratos: las condiciones del proveedor y su contrato de encargo del tratamiento, más el contrato de hardware o de nube sobre el que funciona el modelo autoalojado. La Autoridad Bancaria Europea señala que DORA, el Reglamento de Resiliencia Operativa Digital de la UE, es aplicable desde el 17 de enero de 2025. Las entidades financieras de la UE dentro de su ámbito deben mantener un registro de sus acuerdos contractuales con proveedores terceros de servicios de TIC (tecnologías de la información y la comunicación). Añadir un proveedor externo de modelos es una cuestión para ese registro, y la responde tu equipo de cumplimiento.

Las operaciones también se duplican. El proveedor limita cuántas solicitudes puedes enviar por minuto y retira modelos según su propio calendario, así que alguien tiene que vigilar ambas cosas. Tus propios servidores necesitan planificación de capacidad y alguien de guardia por la noche. El enrutador y la capa de enmascaramiento solo los operas tú.

Vigila cada día la proporción de documentos en cada ruta, por clase. Cuando el modelo autoalojado ve primero todos los documentos, una proporción creciente enviada a la API significa que salen más documentos y que la factura de la API crece. A menudo la causa es una plantilla de documento nueva que el modelo interno no sabe leer.

¿Qué debe mostrar la pista de auditoría de cada documento?

Guarda su clase y las señales que la determinaron, la versión de la tabla de enrutamiento y la ruta seguida. Añade si se enmascaró y con qué versión del detector, y el proveedor y la versión exacta del modelo que respondió. Con ese registro, «mostrar todos los documentos de esta clase que salieron del perímetro el trimestre pasado» es una sola consulta a la base de datos.

¿Cuándo es una configuración híbrida la opción equivocada?

Una sola ruta basta cuando todos tus documentos entran en una única clase de datos. Con un volumen pequeño, una segunda ruta cuesta más de lo que ahorra, y una persona puede encargarse de lo que el modelo autoalojado no sabe leer. Una configuración híbrida también hereda cualquier hueco en la cobertura nocturna de los servidores autoalojados. Y cuando un servicio gestionado en la nube de tu región cumple las normas para todas las clases, te da un solo contrato y un solo conjunto de operaciones.

¿Cómo comprobamos que una empresa ha llevado esto de piloto a producción?

Este artículo no clasifica empresas, porque cualquier empresa puede escribir «IA en producción» en su web. Un sistema en producción deja registros que un piloto no deja, así que pide los siguientes, sin los datos de los clientes.

  • La tabla de enrutamiento como documento versionado, y el nombre de la persona que aprueba los cambios
  • Unas cuantas filas del registro de rutas, con la clase, la ruta, la versión de la tabla de enrutamiento y la versión del modelo de cada documento
  • La última ejecución de una prueba que envía un documento restringido hacia el proveedor externo y muestra que se detiene
  • Las puntuaciones de aceptación por ruta y por release, incluida la release que se hizo cuando un proveedor retiró un modelo
  • Si el diseño enmascara texto, los fallos medidos del detector con los documentos de un cliente
  • El runbook (instrucciones escritas para los operadores) para una caída de cada ruta, y quién está de guardia
  • Una llamada con la persona que opera el sistema hoy

¿Cuáles son las señales de alarma?

  • El enmascaramiento se presenta como toda la respuesta en materia de privacidad, sin una tasa de fallos medida
  • La comprobación que decide qué puede salir consulta a la propia API externa
  • El tráfico se desvía a la API cuando el modelo interno está caído, y con él salen documentos restringidos
  • No hay puntuación por ruta, solo una cifra de precisión para todo el pipeline

¿Dónde encaja amBrain?

El único proyecto con modelos de lenguaje que amBrain describe en público es este: «Hemos llevado a producción una integración de LLM dentro del perímetro FinTech de un cliente: extracción y normalización de avisos no estructurados de brókers y de centros de negociación —eventos corporativos, cambios de instrumentos y de márgenes— en registros estructurados que consume el sistema de trading».

Este artículo no es un caso de estudio: no se nombra al cliente y no se revela dónde se ejecutó el modelo en ese proyecto. No afirma que amBrain haya construido una configuración híbrida, una capa de enmascaramiento ni un enrutador para ningún cliente, y no da precios ni plazos.

amBrain se hace cargo de proyectos que se atascaron con otro equipo y los lleva a producción.

amBrain desarrolla software desde 2019. Trabaja 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 los componentes reutilizables de amBrain.

Si estás valorando estas opciones, lleva tus clases de documentos y la lista de registros de arriba a cada empresa con la que hables, amBrain incluida.

Preguntas frecuentes

  • ¿El enmascaramiento nos permite enviar todos los documentos a la API? No. Un texto enmascarado que puedes volver a vincular con una persona sigue contando para ti como datos personales, y los detectores pasan por alto algunos identificadores. Usa el enmascaramiento para reducir la exposición en las clases que ya pueden salir
  • ¿Puede un modelo autoalojado igualar en calidad al modelo de la API? En algunos tipos de documentos, sí. Puntúa los dos con el conjunto compartido de documentos permitidos en ambas rutas antes de decidir cómo repartir el trabajo
  • ¿Podemos empezar con una ruta y añadir la segunda más adelante? Sí, y a menudo es el camino más barato. Construye el enrutador y el registro de rutas desde el primer día, para que añadir la segunda ruta más adelante no obligue a reconstruir el pipeline

¿Tiene un diseño así sobre la mesa?

Traiga su arquitectura actual y el modo de fallo que le preocupa, y lo repasaremos juntos en media hora.