En la gestión de calidad para industrias reguladas, la memoria institucional que resuelve un problema casi siempre está enterrada en algún lugar del historial de un cliente. Un defecto similar investigado el año pasado, una Corrective and Preventive Action (CAPA) que corrigió la causa raíz, un hallazgo de auditoría que señaló la misma brecha. Ese conocimiento reside en miles de millones de documentos que ningún humano puede buscar por similitud semántica entre idiomas y formatos, por lo que cada investigación comienza desde cero. Octave Reliance ha ayudado a cada organización a recopilar documentos a través de múltiples sistemas para facilitar sus búsquedas y mantener un registro de todo lo que poseen. El equipo de Octave Reliance vio desbloquear este historial como su mayor oportunidad para ayudar a los clientes a trabajar más rápido y mantener el cumplimiento. El obstáculo era igual de claro: los registros de quejas, los hallazgos de auditoría y las acciones correctivas llevan los requisitos de aislamiento más estrictos de la plataforma, y esos eran exactamente los registros que la IA necesitaba leer. En una plataforma que sirve a más de 14,000 clientes en dispositivos médicos, productos farmacéuticos y fabricación de alimentos, una sola divulgación involuntaria de un cliente a otro tendría consecuencias regulatorias que superarían con creces cualquier beneficio de la IA.
Octave opera en 180 países, sirviendo a más del 60% de las Global Fortune 500. Su sistema de gestión de calidad nativo en la nube, Reliance, da soporte a más de 650 clientes empresariales con más de 40 aplicaciones, desde la gestión de quejas y el seguimiento de CAPA hasta la gestión de auditorías y la calidad de proveedores. Todos generan datos regulados sobre los que la IA podría razonar. Cada cliente es un inquilino separado y ningún dato puede cruzar el límite de un inquilino.
Ante esto, el equipo de Reliance tomó una decisión inusual: en lugar de lanzar una sola función de IA, dedicó su primer ciclo a construir una base sobre la que se apoyaría cada función futura. Esa base desde entonces ha reducido el tiempo de despliegue por caso de uso en un 50 por ciento. Si está llevando IA a una plataforma de software como servicio (SaaS) donde los datos son valiosos, pero el aislamiento es innegociable, el razonamiento trasciende la gestión de calidad. En esta publicación, recorremos las cuatro tensiones que moldearon el diseño y la base de tres capas que Octave construyó con Cohere Embed v4 en Amazon Bedrock. Luego seguimos el pipeline que incorporó mediante embeddings 2 mil millones de documentos y el Complaint Triage Assistant que lo demostró en producción.
Por qué una base y no una función
Los talleres de visualización con AWS revelaron cuatro casos de uso de alto impacto: resumen y clasificación de quejas, monitoreo de preparación para auditorías, generación de narrativas de incidentes y puntuación predictiva de riesgos de calidad. También revelaron la idea que lo moldeó todo después de docenas de aplicaciones, cada una con diferentes tipos de documentos y flujos de trabajo. Construir IA para una de ellas de forma aislada significaba reconstruir la infraestructura para la siguiente.
Así que el equipo invirtió el plan: construir primero la plataforma horizontal y luego cortar en ella segmentos verticales de funciones. El resumen y la clasificación de quejas fueron primero, para probar la arquitectura antes de que siguiera el resto.
Las cuatro tensiones
Antes de seleccionar un solo modelo, el equipo dedicó su tiempo a cuatro problemas que tiraban en direcciones distintas. Ninguno podía sacrificarse.
Hacer que los datos estén disponibles sin arriesgar una divulgación involuntaria. Los registros de quejas, las CAPA, los procedimientos operativos estándar (SOP) y los hallazgos de auditoría pertenecen a un inquilino y deben ser inaccesibles para otro. Ni siquiera una consulta errante de la IA podría cruzar. El almacén de vectores, la lógica de recuperación y el contexto de generación debían estar limitados a un solo inquilino.
Ejecutar agentes de forma aislada. Los permisos que rigen las herramientas, los almacenes de datos y los endpoints de modelo de un agente debían estar limitados al usuario solicitante en lugar de a un rol de servicio compartido, disponibles solo durante la ejecución y respetando los derechos de acceso de ese usuario. Un grupo de agentes compartido con credenciales estáticas fallaba en los tres aspectos.
Leer contenido que no se puede confiar. Los agentes aquí ingieren quejas, adjuntos de correo electrónico, PDF escaneados e imágenes de fuera de la organización. El OWASP Top 10 para aplicaciones de modelos de lenguaje de gran escala (LLM) (2025) nombra las amenazas que se aplican directamente: inyección de instrucciones a través del contenido ingerido (LLM01), divulgación de información sensible (LLM02), manejo inadecuado de la salida (LLM05) y agencia excesiva (LLM06). Las instrucciones ocultas en un PDF adjunto no son hipotéticas a este volumen.
Generar embeddings de 2 mil millones de documentos sin esperar un trimestre. Reliance aloja más de 2 mil millones de documentos, con inquilinos individuales que almacenan millones de archivos de Word, PDF, formularios escaneados, hojas de cálculo, imágenes y correos electrónicos. El equipo se comprometió a incorporar incluso al inquilino más grande dentro de un solo día laboral. Como estos documentos fundamentan decisiones regulatorias, la calidad no podía sacrificarse por el rendimiento. Una queja pasada por alto erosiona la confianza en todo el sistema.
Dónde aterrizó la arquitectura
Mantener cuatro tensiones a la vez redujo considerablemente las opciones. Amazon Bedrock las abordó como una sola plataforma: acceso multmodelo a través de una única API, la residencia por Región de AWS y AWS Identity and Access Management (IAM) la gobernanza que la cuenta de AWS ya aplica, y Guardrails como controles de contenido en producción en lugar de algo que construir.
La base se resuelve en tres capas, mostradas en la Figura 1. La preparación de datos incorpora como embeddings documentos de calidad con Cohere Embed v4 on Amazon Bedrock y los escribe en un almacén de vectores por inquilino en Amazon OpenSearch Service. La ejecución segura pasa una solicitud de usuario a través de AgentCore Gateway, una capacidad de Amazon Bedrock AgentCore, que aplica autenticación y políticas antes de entregarla a una sesión de microVM aislada que llama a un modelo de Anthropic Claude en Amazon Bedrock. Envolviendo ambas, la protección de contenido aplica Amazon Bedrock Guardrails dos veces: filtrado de entrada a la ida, filtrado de salida antes de que nada llegue al gestor. La recuperación, la ejecución y el cribado permanecen en etapas separadas, de modo que cada una puede aplicarse y evidenciarse por sí misma.
Figura 1: Arquitectura de alto nivel de la base de Reliance AI
Elegir cómo representar los datos
Nada más funcionó hasta que los documentos fueron recuperables. Eso significaba hacerlo con precisión, en todos los idiomas y formatos, y sin cruzar un límite entre inquilinos. El equipo evaluó los modelos de embedding contra su propio corpus en lugar de las tablas de clasificación públicas. Las preguntas decisivas eran específicas de estos datos: qué relación tiene una foto de una carcasa agrietada con el párrafo que la describe, y una queja en alemán con una CAPA en inglés.
Cohere Embed v4 on Amazon Bedrock ganó en cinco aspectos y no eran independientes entre sí. Lo que se decidió primero fue cuánto del pipeline quedaba innecesario. Los registros de calidad llevan fotos de productos defectuosos, formularios de inspección escaneados y diagramas anotados junto con texto. Embed v4 coloca ambas modalidades en un único espacio vectorial. Una foto de una carcasa agrietada y el párrafo que describe ese defecto son recuperables con una sola consulta, sin un pipeline separado por modalidad. El soporte multilingüe nativo hace el mismo trabajo en el otro eje: los documentos llegan en varios idiomas, a menudo dentro del corpus de un solo inquilino, y no requieren preprocesamiento de traducción. Dos pipelines que el equipo nunca tuvo que construir, y dos lugares menos donde un documento podía caerse de la recuperación.
Los tres aspectos restantes se resolvieron en dónde podían vivir los vectores y cuánto costarían. Los datos de los clientes no pueden salir de su Región de AWS, ni siquiera para la inferencia, por lo que la disponibilidad del modelo en la Región en Amazon Bedrock era una condición previa y no una comodidad. Embed v4 admite inferencia en la Región en las Regiones EE.UU. Este (N. Virginia) (us-east-1), Europa (Irlanda) (eu-west-1) y Asia Pacífico (Tokio) (ap-northeast-1), cubriendo tres de los requisitos de cumplimiento regional de Octave. La disponibilidad de modelos y funcionalidades varía según la Región y cambia con el tiempo. Para ver la cobertura actual, consulte Regional availability by models en la Amazon Bedrock User Guide. Dentro de cada Región, los costos de Amazon OpenSearch Service escalan linealmente con el número de dimensiones. Eso hizo que las dimensiones de salida configurables de Embed v4, de 256 a 1,536, merecieran ser probadas en lugar de aceptarse por defecto. Las pruebas contra consultas de producción representativas mostraron que 512 dimensiones mantenían la precisión objetivo mientras reducían el almacenamiento aproximadamente un 66 por ciento respecto al valor predeterminado de 1,536. La ventana de contexto de 128K tokens rindió frutos en otro lugar por completo: fragmentos de aproximadamente 4K tokens se agrupan muchos por solicitud, que es de donde provino el rendimiento de incorporación.
Mantener a los inquilinos separados en tiempo de ejecución
La pregunta más difícil era dónde aplicar la separación entre inquilinos. El código de la aplicación habría funcionado, pero habría significado que cada futuro equipo de funcionalidades lo hiciera bien en cada ruta de código, donde una sola comprobación omitida arriesga una divulgación inadvertida entre inquilinos. En cambio, el equipo empujó el aislamiento al tiempo de ejecución. AgentCore runtime, una capacidad de Amazon Bedrock AgentCore, aplica la separación por debajo de la capa de aplicación y, como permanece independiente del framework y del modelo, el framework de agentes y los modelos elegidos para el Complaint Triage Assistant no se vieron limitados por la decisión de aislamiento.
Cada sesión de usuario se ejecuta en una microVM dedicada con su propia CPU, memoria y sistema de archivos, detenida y depurada cuando la sesión termina. Esa es una separación a nivel de hardware diseñada para sostenerse sin importar cómo se comporte el agente. AgentCore lleva la identidad del usuario autenticado a través de toda la cadena de ejecución: las bóvedas de tokens OAuth por usuario verifican que el agente actúe para ese usuario específico en lugar de una identidad de servicio compartida, y las credenciales se acotan por agente y solo existen durante la sesión. AgentCore Gateway autoriza a nivel de herramienta, operación y parámetro. El razonamiento automatizado proporciona verificación formal contra las reglas definidas. Es la misma disciplina detrás de IAM y Amazon Simple Storage Service (Amazon S3) de la validación de políticas. La Figura 2 traza esa separación a través de dos inquilinos.
Figura 2: Separación de sesiones de AgentCore entre inquilinos. Cada microVM se detiene después de su uso con la memoria depurada.
Por lo tanto, una queja presentada por un gestor de calidad del Inquilino A llega únicamente al almacén de tokens, las herramientas y el sandbox del Inquilino A en AgentCore Code Interpreter, una capacidad de Amazon Bedrock AgentCore. La sesión del Inquilino B no tiene ninguna ruta hacia ninguno de ellos.
Tratar el contenido ingerido como no confiable
Esta tensión no tenía una respuesta limpia. Un adjunto de una queja es una entrada no confiable, pero también es aquello que el agente existe para leer, por lo que no se podía rechazar el contenido sospechoso. El equipo optó por la defensa en profundidad.
Octave aplicó Amazon Bedrock Guardrails sobre la lógica del agente en lugar de dentro de ella, en tres puntos del flujo de trabajo de quejas. La API ApplyGuardrail evalúa el texto extraído de los adjuntos antes de la incrustación, los documentos recuperados y las salidas de las herramientas antes de que entren en el contexto del agente, y el informe sintetizado antes de que el gestor lo vea. El contenido derivado de adjuntos se pasa con etiquetado de entrada, marcándolo como dato y no como instrucción. Eso es lo que hace detectable una inyección enterrada a mitad de un documento. La información de identificación personal (PII) se enmascara a la entrada.
La detección por sí sola no era suficiente, por lo que debajo se encuentra la agencia acotada. Sea lo que sea que se le pida a un agente, AgentCore Gateway sigue gobernando qué herramientas puede invocar, y la extracción de documentos se ejecuta en el sandbox de AgentCore Code Interpreter sin salida de red ni persistencia más allá de la sesión. Una carga útil oculta en un PDF tiene que derrotar cada capa, no solo una.
El efecto: las tasas de detección y enmascaramiento se rastrean por inquilino, de modo que lo que detectó el filtrado es algo que Octave puede demostrar en lugar de afirmar.
Hacer pasar 2 mil millones de documentos por el pipeline
Delante del modelo de incrustaciones se encontraba el problema más difícil: extraer contenido utilizable de archivos de Word, hojas de cálculo, PDF digitales, páginas escaneadas, fotografías e hilos de correo electrónico. Aparecen varios idiomas, a veces dentro de un mismo registro. Y tenía que ejecutarse lo suficientemente rápido como para que la incorporación tomara un día en lugar de un trimestre. La Figura 3 muestra el pipeline resultante de extremo a extremo.
Figura 3: Pipeline de ingesta: procesamiento de documentos basado en eventos desde la plataforma de aplicación a través de la orquestación de Step Functions hasta el índice de OpenSearch por inquilino.
Los eventos de documentos se ramifican a través de Amazon Simple Notification Service (Amazon SNS) y Amazon Simple Queue Service (Amazon SQS) hacia una máquina de estados de AWS Step Functions. Esa máquina de estados orquesta el análisis, la fragmentación y la incrustación a través de ejecuciones concurrentes de AWS Lambda dentro de una Amazon Virtual Private Cloud (Amazon VPC) dedicada. Dado que el paralelismo proviene de distribuir lotes entre ejecuciones en lugar de escalar un solo recurso, el rendimiento crece sin necesidad de rediseñar la arquitectura.
El análisis maneja la heterogeneidad: jerarquía semántica preservada de archivos de Word y hojas de cálculo, reconocimiento óptico de caracteres (OCR) aplicado a PDF escaneados sin capa de texto, imágenes incrustadas tratadas como contenido de primera clase. Los fragmentos llevan metadatos: inquilino, tipo de documento, aplicación de origen, idioma y un hash de contenido. Esos metadatos impulsan tanto el filtrado de recuperación como la aplicación de espacios de nombres por inquilino.
El rendimiento provino del empaquetado. Entrelazar muchos fragmentos de 4K en solicitudes únicas contra la ventana de contexto de 128K de Embed v4 redujo las llamadas a la API para un corpus grande en aproximadamente un orden de magnitud. En las pruebas internas de Octave en Amazon Bedrock, Embed v4 entregó 28 millones de tokens por minuto. Después de ajustar los tamaños de lote con los arquitectos de soluciones de Cohere hasta eliminar los cuellos de botella de memoria, el pipeline sostuvo 1.4 millones de documentos por cada 24 horas por carga de trabajo de inquilino. Eso es lo que hizo real el compromiso de un solo día hábil.
El Asistente de Clasificación de Quejas
Un hospital informa jeringas defectuosas a un fabricante de dispositivos médicos, y el registro llega con correo electrónico, fotos de las unidades dañadas y documentación de respaldo adjuntos. Un gestor de calidad tiene que reunir el contexto a través de esos formatos, determinar si algo similar se ha reportado antes y encontrar qué lo resolvió. Solo entonces se puede asignar una prioridad, a menudo dentro de una ventana de reporte medida en días.
El asistente está construido con el Strands Agents SDK, de código abierto por AWS, que compone flujos de trabajo agentivos como grafos, con nodos como invocaciones de herramientas o llamadas al modelo y aristas como las dependencias de datos entre ellos. El runtime de AgentCore ejecuta ese grafo y lo aísla por sesión, y cinco etapas llevan una queja desde los adjuntos sin procesar hasta un informe terminado.
La extracción de documentos va primero. Los PDF, las imágenes, los adjuntos de correo electrónico y los videos entran todos en AgentCore Code Interpreter, que analiza cada artefacto en una representación intermedia estructurada. Un modelo Claude en Amazon Bedrock resume entonces el registro, y ese resumen, en lugar de la fuente sin procesar de miles de tokens, se convierte en la consulta de recuperación. La recuperación la ejecuta contra el índice de OpenSearch del inquilino de incrustaciones de Embed v4, revelando quejas anteriores similares y sus CAPA, con AgentCore Gateway garantizando que solo se puedan alcanzar los espacios de nombres autorizados.
Lo que regresa no se considera confiable por similitud únicamente. Una llamada al modelo separada puntúa los resultados por confianza y descarta las coincidencias que comparten vocabulario pero difieren en la causa raíz. Lo que sobrevive pasa a la síntesis, donde Anthropic Claude Sonnet en Amazon Bedrock ensambla la salida: hechos clave, sentimiento, indicadores de urgencia, los registros históricos más cercanos con sus resultados y una prioridad de clasificación recomendada.
Los informes completados se almacenan en caché en Amazon DynamoDB con un tiempo de vida (TTL) por entorno, de modo que las vistas repetidas no cuestan nada adicional. El gestor ya no empieza de cero, sino desde la memoria institucional.
La Figura 4 coloca ese motor detrás de un límite de API privada. Una solicitud del portal llega al runtime de AgentCore a través de un Amazon API Gateway privado y una función Lambda, y la recuperación lee el índice de documentos mediante acceso basado en roles con URL prefirmadas mientras los adjuntos permanecen en Amazon S3. Los resúmenes almacenados en caché y los trazas de OpenTelemetry salen hacia la tabla de resumen y el panel de evaluación.
Figura 4: Motor de resumen: el flujo de trabajo potenciado por AgentCore que gestiona la extracción de documentos, la recuperación, el razonamiento y la síntesis dentro de un límite de API privado, con almacenamiento en caché de respuestas y observabilidad completa.
La Figura 5 reduce el mismo recorrido a una sola línea, con Guardrails filtrando en ambos extremos.
Figura 5: Pipeline del Asistente de Clasificación de Quejas desde la ingesta hasta la salida del gestor
Demostrando lo que hizo el agente
La observabilidad aquí no es solo la forma en que el equipo de ingeniería depura, sino también cómo se integran con las capacidades de auditoría del sistema para cumplir los requisitos de cumplimiento. Un auditor puede preguntar por qué una queja concreta se clasificó de la manera en que se hizo, y «el modelo lo decidió» no sobrevivirá a esa conversación.
AgentCore captura trazas compatibles con OpenTelemetry en cada nodo del grafo: cada llamada al modelo, cada recuperación y cada ejecución de AgentCore Code Interpreter. Meses después, Octave puede mostrar qué documentos recuperados y qué prompts produjeron un informe determinado. El registro de invocaciones del modelo de Amazon Bedrock añade un registro por inquilino de cada solicitud y respuesta, delimitado mediante la identidad de IAM que AgentCore propaga, con costos atribuidos al inquilino iniciador en Amazon CloudWatch.
Sin conexión, AgentCore Evals vuelve a ejecutar el flujo de trabajo contra una verdad fundamental anotada por expertos tras cualquier cambio en prompts, modelos o parámetros de recuperación, e informa sobre la fidelidad del resumen, la precisión de recuperación en K y la integridad de la salida. Un prompt que se lee mejor pero recupera peor se detecta antes de que los usuarios lo vean.
Resultados
El Asistente de Clasificación de Quejas lleva tres meses en producción, y las siguientes cifras reflejan ese periodo.
El gestor que antes abría una investigación sin nada ahora la abre con el historial relevante ya recopilado. Las 4–6 horas que Octave mide por investigación son el trabajo que el pipeline absorbió: la extracción en varios formatos, la búsqueda de precedentes y la lectura necesaria para distinguir un defecto genuinamente similar de una coincidencia de redacción.
La base también cambió la velocidad con la que Octave lanza. Según su propio recuento, los ciclos de desarrollo para nuevas capacidades de IA pasaron de meses a semanas. La preparación compartida de datos, la ejecución segura y la recuperación son las tres capas de la Figura 1. Redujeron el tiempo de implementación por caso de uso en un 50 por ciento, porque cada nueva capacidad las hereda en lugar de reconstruirlas. Eso permitió lanzar la búsqueda semántica en el Q2, dos trimestres antes del objetivo original del Q4.
Mirando atrás
La decisión de construir primero una base fue la que el equipo más puso en duda. Meses de trabajo de infraestructura son difíciles de defender cuando las partes interesadas quieren una función de IA que puedan ver. La siguiente ronda de casos de uso le dio la razón. Dos decisiones la sostuvieron: el aislamiento impulsado en sesiones de microVM y la propagación de identidad en lugar del código de la aplicación, y los modelos de incrustaciones evaluados contra el propio corpus de Octave, lo que reveló el equilibrio de 512 dimensiones que ningún benchmark habría mostrado.
El equipo también trazó una línea que decidió no cruzar. El asistente presenta contexto y precedentes. El gestor de calidad sigue tomando la decisión. En una industria donde esa decisión tiene peso regulatorio, ese límite determinó qué se automatizó y qué no.
Qué viene después
Octave está extendiendo ahora la base en toda la suite Reliance. La monitorización de preparación para auditorías, la generación de narrativas de incidentes y la puntuación predictiva de riesgos de calidad son lo siguiente, cada uno construyendo sobre la misma infraestructura.
Si su plataforma enfrenta una tensión similar: datos valiosos detrás de requisitos estrictos de aislamiento. La experiencia de Octave muestra que los equilibrios son manejables. Para saber más sobre los servicios detrás de esta historia, consulte Amazon Bedrock, la documentación de Amazon Bedrock AgentCore, y Cohere en Amazon Bedrock. Para obtener orientación arquitectónica relacionada, consulte AWS vector solutions: Build agentic AI where your data lives y Scaling agentic AI: Enterprise patterns without vendor lock-in.