IA para seguros

Puede mostrarle qué dice su póliza y citar la cláusula, que es distinto. La decisión de cobertura sobre un siniestro concreto es un acto técnico de la compañía, con hechos que el sistema no conoce: causa, peritaje, estado de la cuenta. Lo diseñamos para que responda «según el artículo 4.2 de su clausulado, este amparo cubre X con un deducible de Y» y para que escale a un asesor en el momento en que la pregunta pasa de qué dice la póliza a qué va a pasar con el reclamo. Esa frontera se define por escrito antes de construir.

Con dos cosas y ninguna es el modelo. Primero, etiquetando la polaridad de cada fragmento en la ingesta —si es un amparo, una exclusión, una condición o una definición— y filtrando por esa etiqueta antes de rankear. Segundo, midiéndolo aparte: dentro del conjunto de evaluación hay un subconjunto de preguntas cuya respuesta correcta es «no está cubierto», y se reporta su acierto por separado del número general, porque el promedio las esconde.

Se reindexa la versión nueva con su vigencia y el sistema recupera filtrando por la fecha del siniestro o de la consulta, no por «la última». Esa es la parte que casi ningún proveedor implementa y la que causa el fallo más caro: responder con el clausulado vigente hoy sobre una póliza emitida hace dos años bajo otro texto. La vigencia es metadata obligatoria en la ingesta, no un detalle.

Sirve mejor para un corredor, en realidad. Un corredor maneja productos de varias compañías y su asesor necesita comparar coberturas entre condicionados distintos, que es exactamente el trabajo que un buen sistema de recuperación hace bien y una persona hace lento. La diferencia es que en un corredor la fuente son documentos de terceros y hay que resolver primero cómo se obtienen y se actualizan.

Solo si ustedes lo aceptan. Cuando el caso lo exige desplegamos sobre Azure OpenAI o Amazon Bedrock dentro de la suscripción de la compañía, así que los documentos y las consultas no salen de su nube. En cualquier configuración usamos planes empresariales donde lo enviado por API no se usa para entrenamiento, y filtramos datos personales antes de que nada llegue al modelo.

Sí, y suele ser lo que separa un asistente útil de una demo. Preguntas como «¿cuál es mi deducible?» necesitan la póliza concreta del asegurado, no el condicionado genérico. Integramos por API contra el core o el CRM para traer la póliza vigente y sus anexos, y a partir de ahí la recuperación se hace sobre el documento que aplica a esa persona. Sin esa integración el asistente solo puede hablar de productos en general.

Un primer ramo con documentación ordenada suele tomar de seis a ocho semanas hasta producción, con algo funcionando desde la primera semana. Los ramos siguientes salen más rápido porque la ingesta y la medición ya están armadas. Se cotiza con alcance, precio y fecha cerrados en una propuesta a 48 horas de la primera llamada, y el precio lo determinan el volumen documental, cuántos sistemas hay que integrar y qué umbral de precisión exige el caso.

Es el caso más frecuente. Conviene empezar por el diagnóstico antes de reconstruir: en una semana medimos el sistema actual con un conjunto de referencia propio y entregamos los fallos ordenados por impacto, cada uno con su arreglo y su esfuerzo estimado. Casi siempre el modelo no es el problema — lo es la fragmentación del condicionado y la falta de filtros por producto y vigencia, y eso se rehace sin botar el resto. Si el diagnóstico no llega a tres hallazgos accionables, no se cobra.