La plataforma de inteligencia contractual de Amazon aborda el punto ciego de cartera de RAG
Amazon publicó una arquitectura de inteligencia contractual basada en ocho campos extraídos, creando una plataforma de inteligencia contractual de Amazon para responder preguntas que los chats basados solo en RAG gestionan mal.
El diseño de referencia aborda un persistente problema empresarial. Un chatbot suele poder recuperar una cláusula de pago de un acuerdo. Pero se vuelve poco fiable cuando se le pide sumar valores, comparar fechas o contar documentos sin firmar entre cientos de contratos.
La respuesta de Amazon no es un prompt más grande ni una ventana de contexto más extensa. Separa la comprensión de documentos del análisis de cartera. Los agentes de IA extraen y verifican campos, una base de datos realiza los cálculos y Amazon Quick ofrece a los usuarios una única interfaz para ambos flujos de trabajo.
Esa distinción pone bajo presión a los asistentes contractuales basados únicamente en recuperación. El sistema trata la generación aumentada por recuperación, o RAG, como un componente en lugar de como la base de datos para todas las preguntas. El resultado es una prueba útil de dónde encajan los agentes empresariales y dónde los sistemas de datos convencionales siguen siendo esenciales.
Lo que Amazon realmente construyó
El diseño convierte cada contrato cargado tanto en un documento consultable como en un registro estructurado de base de datos.
AWS publicó la arquitectura de inteligencia contractual el 29 de septiembre de 2026. Se trata de una implementación de referencia, no de un anuncio de un servicio jurídico autónomo ni de un despliegue para clientes.
Una aplicación React proporciona la interfaz de usuario. Los PDF de contratos entran en un bucket de Amazon Simple Storage Service, que activa una canalización de procesamiento automatizada.
El primer agente lee cada PDF y extrae ocho campos. AWS afirma que la implementación utiliza Claude Sonnet 4.6 de Anthropic y devuelve JSON estructurado con una puntuación de confianza para cada campo.
Un segundo agente lee de forma independiente el mismo documento. Según AWS, este verificador utiliza Claude Haiku 4.5 y compara sus hallazgos con el resultado del extractor.
Los dos agentes se ejecutan mediante el SDK de código abierto Strands Agents en Amazon Bedrock AgentCore. AgentCore proporciona el entorno de ejecución gestionado donde el código de los agentes se ejecuta y escala.
Un desacuerdo no significa automáticamente que el verificador tenga la razón. Para el estado de las firmas, el sistema llama a Amazon Textract como desempate visual. El registro verificado pasa después a Amazon Aurora PostgreSQL.
El PDF original sigue otra ruta. Permanece disponible a través de una base de conocimientos para la recuperación específica de documentos, incluidas preguntas sobre condiciones de pago o cláusulas individuales.
Amazon Quick se sitúa sobre ambas fuentes. Su capacidad Quick Sight muestra paneles construidos a partir de registros de base de datos. Su interfaz conversacional puede dirigir las preguntas hacia analítica estructurada o recuperación de documentos.
La distinción importa porque esas fuentes responden a tipos de preguntas diferentes. Buscar una cláusula requiere texto relevante. Obtener un total de cartera requiere todos los registros aplicables y un cálculo fiable.
El diseño también transmite el estado de la canalización al navegador mediante conexiones WebSocket. Los usuarios pueden ver si un archivo se está extrayendo, verificando, comprobando o almacenando.
Esa visibilidad es más que un refinamiento de interfaz. Un flujo de trabajo empresarial resulta más fácil de inspeccionar cuando los usuarios pueden ver qué etapa de procesamiento produjo un retraso o desacuerdo.
AWS afirma que un contrato puede avanzar por la canalización en segundos en condiciones típicas. Esto sigue siendo una afirmación de diseño, y el rendimiento real dependerá de la longitud del documento, la concurrencia, la disponibilidad del modelo y la configuración regional.
La publicación sigue a un diseño anterior de AWS para gestión de contratos de enero de 2026. Esa versión hacía hincapié en múltiples agentes especialistas para tareas jurídicas, de riesgo, cumplimiento y flujo de trabajo.
La nueva arquitectura es más acotada y reveladora. Se concentra en la precisión de extracción y la analítica de cartera, que exponen debilidades que las demostraciones conversacionales suelen ocultar.
Por qué RAG no puede sumar una cartera de contratos
RAG selecciona pasajes relevantes, mientras que el análisis de cartera exige registros completos y cálculos controlados.
La investigación original sobre RAG combinó un modelo de lenguaje con conocimiento externo recuperado. Ese patrón ayuda a un modelo a responder preguntas sin colocar una colección completa de fuentes dentro de su prompt.
Un sistema típico divide los documentos en fragmentos y crea representaciones vectoriales de ellos. Cuando un usuario plantea una pregunta, la búsqueda semántica recupera un conjunto limitado de fragmentos estrechamente relacionados.
Este mecanismo funciona bien cuando la respuesta deseada existe en unos pocos pasajes. Una pregunta sobre lenguaje de terminación puede recuperar la cláusula pertinente sin volver a leer cada página.
El mecanismo se convierte en un problema cuando la pregunta abarca toda la colección. Pensemos en un responsable de compras que pregunta por el valor total comprometido en todos los acuerdos activos.
El recuperador sigue seleccionando los fragmentos que parecen más relevantes. No garantiza que cada acuerdo activo aporte un valor completo y correctamente normalizado.
Aumentar el número de fragmentos recuperados no resuelve por completo el problema. Los contratos contienen etiquetas repetidas, enmiendas, tablas, notas al pie y fechas conflictivas. Los pasajes relevantes también pueden superar el contexto utilizable del modelo.
La capacidad que falta no es fluidez conversacional. Es cobertura.
AWS ilustra el problema con una cartera hipotética de 250 contratos. Con entre 10 y 20 páginas cada uno, esa cartera puede contener hasta 5.000 páginas.
Una persona puede terminar inspeccionando cada documento y manteniendo una hoja de cálculo. Sin embargo, cada nuevo acuerdo o enmienda puede dejar obsoleta la hoja de cálculo.
Un asistente RAG puede responder más rápido y, aun así, omitir registros fuera de su ventana de recuperación. La respuesta puede sonar completa incluso cuando el cálculo cubre solo un subconjunto.
Este es el principal contraste detrás de la plataforma de inteligencia contractual de Amazon: chat basado solo en RAG frente a extracción seguida de consultas a bases de datos.
Con el enfoque de extracción, cada contrato pasa por el mismo esquema. Valores, fechas, contrapartes, estados de firma y otros campos seleccionados se convierten en filas y columnas.
Una base de datos puede entonces filtrar registros activos, agruparlos por proveedor y calcular totales. También puede devolver los registros detrás del resultado para su posterior inspección.
Esa arquitectura no vuelve obsoleto a RAG. Le asigna una función más acotada que coincide con sus fortalezas.
La recuperación de documentos sigue siendo valiosa para preguntas que se resisten a la normalización. El lenguaje de pagos, las disposiciones de responsabilidad, las excepciones y las obligaciones inusuales suelen necesitar su texto circundante.
La analítica estructurada atiende a otra capa. Admite preguntas como cuántos acuerdos han vencido, qué contratos sin firmar implican el mayor valor o qué renovaciones se acercan a una fecha seleccionada.
Las dos rutas pueden complementarse. Una consulta estructurada identifica los contratos que requieren atención, mientras que la recuperación devuelve las cláusulas que los respaldan.
Esta división también produce un modelo de fallos más claro. Los errores de recuperación afectan una respuesta sobre un documento. Los errores de extracción pueden afectar a los paneles y a cada agregado construido a partir del campo almacenado.
Eso hace que la canalización de ingestión sea más importante que la interfaz de chat. La capa conversacional solo es tan fiable como los registros y las fuentes de recuperación que tiene detrás.
Cómo la plataforma de inteligencia contractual de Amazon cambia la ruta de los datos
La arquitectura traslada el trabajo más difícil del momento de la consulta al momento de la ingestión.
Un asistente basado solo en RAG pospone la interpretación hasta que alguien formula una pregunta. La plataforma de inteligencia contractual de Amazon interpreta campos contractuales seleccionados cuando cada documento entra en el sistema.
Ese cambio crea una capa analítica reutilizable. Una vez que una fecha de renovación ha sido extraída, verificada y almacenada, múltiples paneles y preguntas pueden utilizar el mismo valor normalizado.
El primer paso es la ingestión de documentos mediante Amazon S3. Una carga inicia el flujo de procesamiento sin requerir que un analista abra el archivo manualmente.
Según AWS, el agente de extracción lee el PDF de forma nativa. Produce los ocho campos esperados y adjunta puntuaciones de confianza que los componentes posteriores pueden inspeccionar.
Las puntuaciones de confianza son señales, no garantías. Pueden ayudar a priorizar el trabajo de revisión, pero no establecen que un valor extraído coincida con el significado jurídico de una cláusula.
El verificador independiente introduce una segunda lectura. El uso de un miembro diferente de la misma familia de modelos pretende reducir los errores correlacionados derivados de repetir el mismo proceso de extracción.
Esta idea se parece a una revisión por dos personas, pero la analogía tiene límites. Dos modelos del mismo proveedor aún pueden compartir patrones de entrenamiento, puntos ciegos y debilidades en el manejo de documentos.
AWS evaluó combinaciones de extractor y verificador con 20 contratos. El equipo etiquetó manualmente ocho campos en cada contrato, produciendo 160 valores de referencia.
Esa evaluación sugirió que el extractor importaba más que el verificador. Según los autores, un modelo de extracción más capaz mantuvo los resultados al emparejarse con un verificador más ligero.
AWS también afirma que los modelos más potentes no siempre proporcionaron una mejora significativa en ese conjunto de datos. La compañía recomienda probar los modelos disponibles con los contratos y criterios de aceptación de cada organización.
Esa salvedad es importante. Veinte contratos constituyen una prueba orientativa, no evidencia de que la combinación seleccionada se generalice entre sectores, idiomas o estilos de redacción.
Después de la verificación, la base de datos se convierte en el sistema para preguntas agregadas. Amazon Quick se conecta a Aurora PostgreSQL y puede consultar datos en vivo en lugar de esperar una exportación separada.
Amazon Quick también se conecta a la base de conocimientos que contiene los documentos fuente. Por tanto, su agente de chat puede admitir preguntas estructuradas y consultas de documentos individuales dentro de una sola interfaz.
Este enrutamiento es el mecanismo arquitectónico detrás de cómo funciona la inteligencia contractual de Amazon. El modelo no realiza cada cálculo leyendo prosa contractual durante cada conversación.
Para una solicitud agregada, la fuente estructurada suministra registros filtrados y cálculos. Para una solicitud específica de un documento, la base de conocimientos recupera texto contractual relevante.
AWS presenta resultados de ejemplo basados en una cartera de muestra con 20 contratos. Los ejemplos incluyen valor de cartera, totales de contratos vencidos y recuentos de acuerdos firmados y sin firmar.
Esas cifras ilustran la interfaz. No son resultados operativos de una cartera de clientes divulgada y no deben interpretarse como evidencia de rendimiento.
Los paneles integrados ofrecen otra forma de inspeccionar los mismos datos. Los usuarios pueden ver totales de cartera, estado de firmas, resultados de extracción y comparaciones de confianza sin salir de la aplicación.
Esa base compartida puede reducir las discrepancias entre las salidas del panel y del chat. Ambas interfaces pueden hacer referencia a los mismos registros verificados de base de datos para preguntas analíticas.
El diseño también preserva el acceso al material fuente. Los analistas no tienen que tratar un valor de base de datos como la última palabra cuando una decisión contractual requiere leer la cláusula.
Este patrón híbrido va más allá de los contratos. Las reclamaciones de seguros, los documentos de cumplimiento, los arrendamientos y los registros de incorporación pueden combinar campos repetibles con lenguaje específico de cada documento.
También se ajusta a un principio más amplio de combinación de conocimientos. Los hechos estructurados y el contexto de la fuente sirven a propósitos diferentes, y los sistemas útiles necesitan un puente gobernado entre ambos.
La verificación importa más que otra llamada al modelo
La parte más instructiva del diseño es su negativa a dejar que los modelos de lenguaje resuelvan cada disputa.
Durante las pruebas, AWS descubrió que el verificador a veces clasificaba bloques de firma vacíos como firmados. En algunos casos de falsos positivos, la confianza reportada alcanzó entre el 95 y el 100 por ciento.
El modelo reconocía palabras y una disposición asociadas con la firma. Luego trataba la presencia de un campo de firma como evidencia de que alguien lo había firmado.
Ese fallo expone un problema recurrente de la IA generativa. Una puntuación de confianza puede describir la certeza interna del modelo sin demostrar que la conclusión subyacente sea correcta.
AWS respondió añadiendo Textract solo cuando los dos modelos discrepaban sobre el estado de la firma. Textract examina características visuales para detectar firmas manuscritas o digitales.
La decisión crea un control de tres partes. Un modelo realiza la extracción, otro la verifica y un servicio especializado de visión por computadora resuelve una clase definida de desacuerdo.
Es una opción más adecuada que pedir a un tercer modelo de lenguaje que vote. Un tercer modelo podría reproducir la misma confusión semántica entre una línea de firma y una firma real.
El patrón también limita la comprobación especializada a los casos en disputa. Así preserva el flujo de trabajo principal y aplica un método técnico diferente cuando los modelos muestran incertidumbre.
Sin embargo, Textract sirve como desempate para la presencia de una firma, no como árbitro de todos los campos. Los valores contractuales, las reglas de renovación, las fechas y las identidades de las partes pueden generar ambigüedades distintas.
Una enmienda puede sustituir un valor anterior. Una cláusula de renovación automática puede requerir una interpretación contextual. Puede existir una firma mientras el acuerdo sigue incompleto por otro motivo.
Estos casos requieren reglas de escalamiento explícitas. La publicación de AWS indica que los desacuerdos no resueltos deben pasar a un revisor humano cuando los servicios deterministas no puedan resolverlos.
Ese circuito humano es fundamental para una adopción responsable. Determina si la automatización reduce el trabajo rutinario o simplemente oculta registros inciertos dentro de una base de datos.
El sistema debe conservar cada valor extraído, su ubicación de origen, las salidas de ambos modelos y la resolución final. De lo contrario, los revisores no pueden reconstruir por qué un panel incluye una cifra concreta.
Las organizaciones también necesitan umbrales específicos por campo. Un nombre de contacto incorrecto y una fecha de terminación incorrecta no conllevan el mismo riesgo operativo.
El marco de IA de NIST enfatiza las pruebas, la evaluación, la verificación y la validación de los sistemas de IA. Los flujos de trabajo contractuales necesitan estas prácticas al nivel de cada campo de datos.
Los equipos deben medir precisión, exhaustividad y rendimiento de coincidencia exacta por campo. También deben seguir las tasas de desacuerdo, las correcciones de los revisores y los errores detectados después de la aprobación.
La precisión debe segmentarse por tipo de documento. Los PDF nativos, las páginas escaneadas, las tablas, las enmiendas, las anotaciones manuscritas y los acuerdos multilingües pueden comportarse de forma diferente.
La evaluación de AWS con 20 contratos ofrece una metodología inicial. No aporta suficiente diversidad para establecer la fiabilidad en producción para la cartera de otra organización.
Un piloto útil debe muestrear los documentos que generan mayor riesgo. Esto incluye plantillas inusuales y archivos de baja calidad, no solo acuerdos limpios basados en un formulario estándar.
La verificación de doble modelo del diseño sigue siendo valiosa porque hace observable el desacuerdo. Crea un evento medible que puede activar comprobaciones deterministas o revisión humana.
Sin embargo, el acuerdo entre modelos no puede tratarse como verdad absoluta. Dos agentes pueden producir el mismo valor erróneo, especialmente cuando el texto fuente es ambiguo.
El control esencial es la trazabilidad. Cada valor estructurado debe permitir a un revisor volver a la página, cláusula y decisión de extracción que lo produjo.
La precisión, el acceso y la economía siguen sin demostrarse
La arquitectura de referencia define un mecanismo creíble, pero no establece la preparación para producción de todas las carteras contractuales.
La primera incertidumbre es la escala de evaluación. AWS utilizó 20 contratos y 160 valores etiquetados al comparar combinaciones de modelos.
Esa muestra puede revelar diferencias evidentes entre configuraciones. No puede representar toda la variedad de patrones de formato, redacción, escaneo, idioma y enmiendas presentes en los acuerdos empresariales.
La segunda incertidumbre es la cobertura del esquema. Ocho campos pueden respaldar paneles útiles, pero las operaciones contractuales suelen depender de obligaciones más complejas y fechas condicionales.
Una fecha de renovación puede depender de periodos de notificación. Un valor puede combinar tarifas comprometidas, cargos por consumo, créditos o aumentos indexados.
Aplanar esos términos en un único registro puede crear una ilusión de certeza. El esquema debe conservar los calificadores cuando un campo no pueda representarse como un simple número o fecha.
La tercera incertidumbre se refiere al cambio de modelos. AWS señala que la disponibilidad de modelos evoluciona y aconseja a los desarrolladores volver a probar el sistema antes de depender de nuevas opciones.
Un modelo de reemplazo puede alterar el comportamiento de extracción incluso cuando la aplicación circundante no cambia. Por tanto, los equipos de producción necesitan conjuntos de evaluación fijos y puertas de lanzamiento.
La cuarta incertidumbre es la autorización. Los contratos pueden contener precios confidenciales, información de empleados, obligaciones de seguridad y términos estratégicos de proveedores.
AWS afirma que AgentCore admite aislamiento de sesiones, mientras que los controles de políticas pueden ubicarse fuera del código del agente. La documentación de AgentCore describe entornos de ejecución separados para las sesiones de usuario.
Sin embargo, el aislamiento de infraestructura no crea automáticamente permisos empresariales correctos. La documentación de AWS indica que los backends de clientes deben mantener la relación entre los usuarios y los identificadores de sesión.
Los desarrolladores también deben aplicar controles de acceso en las capas de documentos, bases de datos, paneles y herramientas de agentes. Una interfaz de chat no debe revelar un registro que el mismo usuario no puede abrir en otro lugar.
La quinta incertidumbre es la economía operativa. La publicación de AWS ofrece un modelo de costes de ejemplo, pero las condiciones comerciales cambian y las cargas de trabajo de las carteras difieren.
Los costes de procesamiento dependen del número de páginas, llamadas al modelo, reintentos, almacenamiento, capacidad de la base de datos, concurrencia y frecuencia de las consultas de los usuarios. La revisión humana puede convertirse en la mayor variable.
Un caso de negocio creíble debe medir el coste por registro aceptado, no el coste por invocación del modelo. Una extracción barata que genera una extensa carga de revisión no es económicamente barata.
El panorama competitivo también ofrece varias rutas de implementación. El modelo de extracción de contratos de Microsoft devuelve campos estructurados de contratos mediante Document Intelligence.
Document AI de Google también convierte documentos no estructurados en datos estructurados para el procesamiento posterior.
Estos productos difieren en esquemas, personalización, orquestación, analítica e integración en la nube. Los compradores deben comparar el ciclo de control completo, no una única referencia de extracción.
La diferenciación de Amazon en este diseño es la conexión entre agentes, verificación, una base de datos relacional, analítica integrada y preguntas y respuestas sobre documentos.
Esta integración puede atraer a organizaciones que ya operan en AWS. También puede aumentar el compromiso arquitectónico en almacenamiento, modelos, bases de datos, analítica y controles de identidad.
Los equipos deben probar la portabilidad antes de producción. Los registros extraídos y los datos de procedencia deben utilizar esquemas documentados que permanezcan accesibles fuera de una interfaz conversacional.
También deben definir la responsabilidad de los fallos. Los equipos de compras, operaciones legales, ingeniería de datos y seguridad pueden asumir que otro grupo valida la salida.
Un flujo de trabajo necesita un único responsable de los cambios de esquema, los umbrales de evaluación, las colas de excepciones y las revisiones de acceso. Sin esa responsabilidad, el sistema puede automatizar la inconsistencia.
La lección más amplia es que la inteligencia contractual es un proyecto de gobernanza de datos con una capa de ingestión de IA. Tratarla como una implementación de chatbot minimiza el trabajo necesario.
Lo que los compradores deberían vigilar a continuación
Tres señales mostrarán si esta arquitectura se convierte en un sistema operativo fiable para los datos contractuales o sigue siendo una convincente demostración de referencia.
La primera señal es la evidencia de evaluación procedente de conjuntos de contratos más grandes y diversos. Los compradores necesitan resultados a nivel de campo en escaneos, enmiendas, tablas, idiomas y patrones de redacción poco comunes.
La precisión publicada por sí sola no será suficiente. La evidencia útil debe revelar la composición del conjunto de datos, las categorías de errores, las políticas de revisión y la frecuencia con que ambos modelos coincidieron en un valor incorrecto.
Una mejor evidencia reforzaría la afirmación central de Amazon de que la verificación independiente mejora la fiabilidad. Los errores correlacionados persistentes debilitarían el argumento a favor del diseño de doble modelo.
La segunda señal es la gestión de excepciones lista para producción. La plataforma necesita colas de revisión configurables, citas de fuentes, historial de aprobaciones y rutas claras para los desacuerdos no resueltos.
Amazon Quick incluye capacidades con intervención humana, pero las organizaciones deben mostrar cómo encajan esos controles en las operaciones contractuales diarias. Los revisores necesitan contexto, no otra puntuación de confianza sin explicación.
Un flujo de trabajo maduro debe permitir a alguien corregir un campo, documentar el motivo y actualizar la analítica posterior sin perder la salida original.
Las implementaciones exitosas también separarán la automatización de bajo riesgo de las decisiones de alto riesgo. Los recuentos de cartera pueden tolerar controles diferentes a los de avisos de terminación o compromisos financieros.
La tercera señal es la adopción más allá de las cargas de trabajo de demostración. Hay que observar implementaciones de clientes divulgadas que conecten la calidad de extracción con resultados operativos medibles.
Los indicadores relevantes incluyen el tiempo de revisión, las tasas de corrección, la frecuencia de registros desactualizados y el porcentaje de contratos procesados sin escalamiento. Estas métricas importan más que la velocidad de respuesta de un chatbot.
La competencia también dará forma a la adopción. Microsoft y Google ya admiten la extracción estructurada de documentos, mientras que las plataformas de gestión del ciclo de vida de contratos ofrecen flujos de trabajo específicos del dominio.
Amazon debe demostrar que Quick y AgentCore reducen el trabajo de integración sin limitar la flexibilidad del esquema ni la gobernanza. Los competidores deben demostrar rutas igualmente coherentes desde los documentos hasta la analítica de cartera verificada.
La plataforma de inteligencia contractual de Amazon presenta su argumento más sólido a través de la arquitectura, no de la novedad del modelo. Reconoce que la recuperación, la extracción, la verificación y el cálculo son tareas separadas.
Ese reconocimiento ofrece a los equipos empresariales una regla práctica de decisión. Mantenga RAG para localizar y explicar pasajes fuente. Utilice registros estructurados para contar, ordenar, comparar y totalizar.
Después, coloque controles de revisión donde una respuesta incorrecta alteraría una decisión legal o financiera. Ninguna puntuación de confianza de un modelo debe eludir automáticamente ese juicio.
Para los equipos que evalúan IA contractual, el siguiente paso es un piloto representativo. Seleccionen documentos difíciles, etiqueten los campos requeridos, definan umbrales de aceptación y midan el esfuerzo de los revisores.
Pregunten si cada respuesta puede rastrearse hasta su fuente. Prueben los permisos entre usuarios, contratos, paneles y sesiones de chat. Recalculen los agregados tras las correcciones y enmiendas.
Lo más importante es comparar la arquitectura híbrida con el proceso que sustituye. ¿Produce datos de cartera más actualizados, con menos errores ocultos y una pista de auditoría defendible?
Esa es la prueba que importa. Una plataforma de inteligencia contractual de Amazon tiene éxito cuando hace que toda la cartera pueda consultarse de forma fiable, no simplemente cuando un contrato produce una respuesta convincente.
