Las decisiones de suscripción, reclamaciones y servicio en el sector asegurador dependen de un contexto que suele estar disperso en numerosos sistemas, como sistemas de administración de pólizas, plataformas de reclamaciones, telemática y datos de riesgo de terceros, entre otros. Recopilar ese contexto manualmente cada vez es lento, inconsistente y difícil de auditar.
Esta arquitectura describe una capa de contexto en MongoDB Atlas, que es una capa de datos operativos en tiempo real que ensambla el contexto de los objetos de negocio en un único objeto vivo que los agentes y las aplicaciones pueden leer, escribir y sobre el que pueden actuar.
La capa de contexto se sitúa entre los sistemas de registro existentes y los flujos de trabajo de suscripción, reclamaciones y servicio impulsados por IA, de modo que las aseguradoras no necesitan reemplazar dichos sistemas para que los agentes puedan utilizarlos. Combina un modelo de documentos flexible, recuperación nativa mediante IA, propagación de cambios en tiempo real y gobernanza a nivel de campo para cumplir con los requisitos de baja latencia y auditabilidad que exigen los procesos de decisión regulados y potenciados por agentes.
Figura 1. Arquitectura de la capa de contexto y flujo de datos del agente de IA
Flujo de datos
Los siguientes pasos describen el recorrido de una solicitud o reclamación individual a medida que avanza a través de la capa de contexto, desde su recepción hasta una decisión auditable por escrito.
Presentación o recepción de reclamaciones
Cuando llega una nueva solicitud o reclamación, el servicio de recepción captura los identificadores principales y los campos estructurados iniciales. Una vez identificada esta información, el servicio de recepción la escribe en una colección
business_objectsde MongoDB Atlas como un único documento.Enriquecimiento y ensamblaje del contexto
Un agente de enriquecimiento especializado recopila el contexto restante que el suscriptor o gestor de siniestros necesita, como límites de cobertura, endosos, descripciones de pérdidas, notas del perito y más. El agente reúne datos del sistema de registros para crear un único registro actualizado. Ahora, un solo documento de MongoDB contiene todo lo que un suscriptor o gestor de siniestros necesita para obtener información, tomar una decisión y actuar.
Memoria del agente y recuperación de estado
Al mismo tiempo que se enriquece el contexto, el servicio también recupera información previa sobre esta solicitud o reclamación, ya que la memoria del agente almacena el historial de conversaciones, el registro de decisiones, el historial de auditorías y el análisis de sentimiento para este caso específico. Esto permite que un agente de suscripción o de reclamaciones retome su trabajo con un conocimiento completo de las intervenciones, recomendaciones y anulaciones humanas anteriores.
Recuperación nativa mediante IA sobre contenido estructurado y no estructurado.
El servicio realiza consultas híbridas
$vectorSearchy$searchsobre el objeto de negocio y los artefactos no estructurados vinculados, como notas de peritos, informes de siniestros o metadatos de imágenes. Para ello, se pueden utilizar incrustaciones y reordenamientos adaptados al dominio, de modo que el agente vea primero el historial y los precedentes más relevantes, en lugar de una lista sin procesar de coincidencias.Decisión del agente, el factor humano y la reescritura de datos
El agente revisa el contexto recopilado y toma una acción, como emitir un presupuesto o solicitar más información. En muchos casos, esta acción deberá ser revisada por un humano, manteniendo así la revisión final siempre bajo su control. Finalmente, el agente registra la decisión, junto con su razonamiento completo, en su propio registro de decisiones en MongoDB como una entrada de auditoría inmutable para garantizar el cumplimiento total, la trazabilidad y la transparencia de las acciones del agente.
Propagación en tiempo real con flujos de cambios
MongoDB Change Streams difunde la actualización a todos los agentes, paneles de control y sistemas posteriores que supervisan el envío o la reclamación. Además, el usuario puede introducir nuevas señales en cualquier momento para que puedan utilizarse para activar directamente a los agentes; por ejemplo, un nuevo indicador de fraude en una reclamación activa al agente de reclamaciones de inmediato, sin necesidad de un ciclo de procesamiento por lotes.
Componentes
Sistemas de registro
Un sistema de registro (SoR), también conocido como sistema único de registro (SSoR), es un único sistema informático que actúa como fuente de datos autorizada para un elemento u objeto de datos crítico. El SoR contiene el "estado verdadero" de los datos, lo que significa que es la versión más actualizada, precisa y conforme a las normas disponible para esa fuente de datos en particular.
En esta arquitectura, los sistemas de registro siguen siendo la fuente de las transacciones comerciales. Conservan sus responsabilidades originales, mientras que la capa de contexto crea un contexto de decisión útil a partir de ellos.
Memoria de objetos de negocio y agentes
Los objetos de negocio almacenan la entidad operativa (ya sea una solicitud, una reclamación o un registro de cliente) como un único documento que se actualiza continuamente. Esto garantiza que cada usuario trabaje con la misma vista actualizada, en lugar de tener que recopilar la información de diversas fuentes. MongoDB almacena la memoria del agente junto con este registro, de modo que los agentes conservan el contexto y el historial de auditoría durante un proceso de decisión de varios pasos.
Recuperación nativa mediante IA
La búsqueda vectorial de MongoDB, combinada con la búsqueda de texto completo y la reclasificación, permite a los agentes recuperar el historial de pérdidas, los precedentes o las directrices más relevantes tanto de campos estructurados como de artefactos no estructurados en una sola consulta, en lugar de tener que coordinarse a través de un almacén vectorial independiente.
Propagación en tiempo real
MongoDB Change Streams y el procesamiento de flujos nativo mantienen a todos los agentes y sistemas posteriores sincronizados con el estado actual de una solicitud o reclamación, y permiten que las nuevas señales o eventos activen un agente directamente en lugar de esperar a un ciclo de sondeo o procesamiento por lotes.
Registro de auditoría
La capa de contexto mantiene un registro de auditoría inmutable para cada lectura y escritura, de modo que todas las decisiones asistidas por IA permanezcan transparentes y rastreables en todo momento. Una única colección reúne la información completa sobre cada decisión, desde la identidad del usuario/agente que la tomó hasta los pasos para llegar a la conclusión, el contexto, los metadatos de la IA, el resultado de la decisión y mucho más.
Limitaciones
Este patrón introduce complejidad y debe adoptarse de forma intencionada.
La capa operativa no siempre es la mejor opción para fines analíticos: esta arquitectura no es adecuada para cargas de trabajo exclusivamente analíticas, repositorios de archivo ni casos de uso donde las decisiones no requieren la recopilación, escritura o auditoría de contexto en tiempo real. Si la necesidad principal es la generación de informes o el análisis por lotes, las plataformas analíticas pueden ser suficientes sin necesidad de añadir una capa de contexto operativo.
La flexibilidad de los esquemas requiere su propia disciplina: este enfoque también exige disciplina en el modelado de datos, la resolución de identidades, la gobernanza y la gestión del ciclo de vida. Una capa de contexto puede acumular objetos grandes y complejos, así como esquemas en constante evolución, por lo que los equipos deben definir los límites de los objetos, las expectativas y los patrones de actualización desde el principio.
La complejidad del sistema ascendente no se eliminará: reduce la fragmentación en el momento de la toma de decisiones, pero sigue dependiendo de un acceso fiable a los datos ascendentes y de la calidad de los mismos. La mala calidad de la fuente o un diseño deficiente de los eventos saldrán a la luz dentro de la capa de contexto en lugar de desaparecer.
La arquitectura funciona mejor cuando se adapta a un caso de uso específico con un modelo de datos predefinido y luego se amplía a partir de un flujo de trabajo de referencia probado.
Obtén más información
Explora las demás arquitecturas de referencia: