ontologyTypes×3
- Claim — claimNo, lossType, amount, status, fraudScore
- Policyholder — name, policyNo, ssn (PII, restringido)
- Payout — amount (restringido), method, approvalState
Automatización de siniestros · Plano de referencia
Automatice el siniestro. Controle el pago.
Un plano de referencia para siniestros de daños y responsabilidad civil — recepción, triaje de fraude y aprobación de pagos como acciones gobernadas sobre el runtime de Cortex. Los pagos iguales o superiores a $5,000 se derivan a una persona antes de que se mueva un dólar, cada decisión de triaje se explica y el resultado completo se sella en el Trust Ledger. Este plano especifica la ontología, las políticas, las acciones y los agentes; el pack firmado e instalable está en la hoja de ruta.
pago ≥ $5,000 → aprobación humana (409 sin ella) · objetivos representativos · plano de referencia (aún no es un artefacto firmado)
insurance-claims · Plano de referencia
Automatización de siniestros de segurosPlano
ontologyTypes3
policies5
actions4
agents3
plano de referencia · aún no es un artefacto firmado
plano de referencia ▸ ontología · políticas · acciones · agentes
Qué gobierna este pack
Un plano gobernado: la solución completa, especificada.
El plano de siniestros gobierna el camino desde un siniestro declarado hasta un resultado pagado (o denegado). Especifica la ontología de siniestros (siniestro, asegurado, pago), las políticas que limitan los pagos autónomos y fuerzan las retenciones por fraude, las acciones de Action Fabric que aprueban o deniegan un pago y tres agentes curados — de modo que la automatización de siniestros se define como una sola solución gobernada en la que el paso que mueve el dinero siempre está bajo control humano.
Objetivos representativos
Los objetivos para los que está ajustado el pack.
Objetivos ilustrativos para este caso de uso, configurables en cada despliegue: las compuertas que los aplican están especificadas en el plano.
~70%
Tasa de procesamiento directo
Objetivo representativo — los siniestros de riesgo bajo se liquidan automáticamente por debajo del límite.
100%
Explicación del triaje
Cada decisión de triaje lleva una explicación y evidencia.
≥ $5,000
Aprobación del pago
Umbral estricto — los pagos iguales o superiores se derivan a aprobación humana.
Qué incluye
Cuatro secciones gobernadas, un plano.
Un plano especifica las cuatro secciones gobernadas que agrupa un Solution Pack. Cuando se publique como pack firmado, el mismo envoltorio — canonicalize → sha256 contentHash → HMAC signature — es lo que lo hará portable y demostrable.
policies×5
- Pago ≥ $5,000 → requiere aprobación humana
- fraudScore por encima del umbral → retención para investigación
- ssn está restringido — lectura denegada fuera de intake
- Denegar requiere un código de motivo citado (sin denegaciones silenciosas)
actions×4
- approvePayout — riskTier: high, sujeta a aprobación ≥ $5k
- denyClaim — riskTier: medium, requiere motivo citado
- requestDocuments — riskTier: low, ejecución automática
- flagFraud — riskTier: medium, abre una investigación
agents×3
- Claims Intake — estructura el FNOL en la ontología
- Fraud Triage — puntúa el riesgo y cita las señales utilizadas
- Payout Approver — propone el pago y deriva ≥ $5k a una persona
Qué hace
Agentes gobernados, asignados a controles reales de Cortex.
Cada capacidad de este pack la aplica un control del runtime que puedes auditar: identidad, política, aprobaciones de acciones y un Trust Ledger sellado. El pack los configura; la plataforma los aplica.
La línea de $5,000 es una puerta estricta
- approvePayout es una acción de Action Fabric de riesgo alto: a partir de $5,000 el agente solo puede proponer — una persona aprueba antes de que el dinero se mueva. Por debajo del límite, los siniestros de riesgo bajo se liquidan de forma directa.
Triaje de fraude que muestra su razonamiento
- El agente Fraud Triage puntúa cada siniestro y cita las señales que utilizó. Sin denegaciones de caja negra: cada retención y cada marca llevan una explicación que un revisor (o un regulador) puede leer.
Las denegaciones necesitan un código de motivo
- denyClaim no se ejecuta sin un motivo citado — la política obliga a que toda decisión adversa nombre la regla en la que se apoya, de modo que tanto el reclamante como el inspector obtienen una respuesta.
Un recibo en cada resultado
- Aprobar, denegar o compensar — cada acción ejecutada emite un recibo firmado en el Trust Ledger encadenado por hash, de modo que un pago en disputa tiene detrás un registro verificable.
La PII del asegurado permanece bloqueada
- ssn y el importe del pago son propiedades restringidas: lectura denegada fuera de los agentes que las necesitan, lo que mantiene los datos sensibles del reclamante fuera de los prompts que no deberían verlos.
Vigile la flota, pause a demanda
- Cada agente de siniestros reporta al Control Tower con su estado en vivo — pause un agente que se comporte mal, desactive una herramienta o arme el kill switch en toda la flota.
$5,000Umbral de aprobación de pagos (con control humano)
100%Decisiones de triaje con explicación
3Agentes gobernados en el pack
10-hopProcedencia en cada decisión de pago
Cómo se publicará
Hoy un plano; en la hoja de ruta, un pack firmado e instalable.
Este plano especifica por completo la ontología, las políticas, las acciones de Action Fabric y los agentes. Cuando se publique como Solution Pack heredará el mismo empaquetado que usa cada pack de Cortex: canonicalize → sha256 contentHash → HMAC signature, y después un flujo con verificación previa importPreview → importApply que comprueba hashOk + signatureOk antes de escribir una sola fila, y solo en tu propio tenant.
- Ontología, políticas y acciones de Action Fabric especificadas y listas para empaquetar
- Al publicarse: verifyPack comprueba hashOk y signatureOk antes de la importación
- Se ejecuta en el mismo runtime gobernado que el pack Tax ya disponible: mismas compuertas, mismo ledger
- ¿Lo quieres antes? Tráenos tu flujo de trabajo y priorizaremos su desarrollo.
packs · verify + import
Reembolso por debajo del límite200 OK
Pago en el umbral409 hold
Retención por fraudeheld
Denegación sin citablocked
importApply verifica primero ▸ 409 si no es válido · solo hace upsert en tu tenant
Del plano al pack publicado
Cómo este plano se convierte en un pack instalable.
El diseño está hecho; lo que queda es el empaquetado. Un plano lleva las mismas cuatro secciones gobernadas que un pack publicado: solo que todavía no está sellado ni firmado.
- 01
Especificado hoy
La ontología, las políticas, las acciones de Action Fabric y los agentes de arriba son el diseño real: la misma forma que el runtime aplica a cada pack publicado.
- 02
Empaquetado y firmado
Cuando se publique, los contenidos pasarán por canonicalize → sha256 contentHash → HMAC signature y aterrizarán en el registro, en el canal stable o beta, exactamente como el pack Tax.
- 03
Verificar e instalar
importApply vuelve a comprobar hashOk y signatureOk y luego hace un upsert idempotente en tu propio tenant. Hasta entonces, podemos montarte el flujo de trabajo a partir de este plano.
Gobernanza incluida
Los controles que ya citan tus auditores, integrados.
Los permisos de ontología, las políticas de cierre seguro, las compuertas de aprobación y el Trust Ledger sellado se corresponden directamente con los marcos ante los que reporta este caso de uso. Alineado con, sin declarar nunca una certificación que no tienes.
NAIC Model Acts · gestión de siniestrosGDPR · datos del reclamanteSOC 2 · auditoríaISO 42001 · registros de IAEU AI Act · registro de eventos
Funciona con el resto de la plataforma
El pack es configuración; quien aplica es el runtime.
Este pack se apoya en el mismo runtime gobernado que el resto de soluciones de Cortex. Explora los controles que configura y el sector al que sirve.
Página del sector asegurador
La demo de Northwind Claims: recepción de siniestros, triaje de fraude y la puerta de aprobación de pagos de $5,000.
Action Fabric
Aprobar / denegar / compensar como acciones dry-run → propose → approve → execute con recibos.
Control Tower
Vigile cada agente de siniestros en vivo y pause la flota en cuanto algo parezca ir mal.
Oversight
Ajuste el piso de autonomía para los pagos — la automatización solo puede endurecer la puerta de aprobación humana.
Lance una automatización de siniestros que mantiene el pago bajo control.
Traiga su flujo de siniestros y levantaremos el pack gobernado a partir de este plano — automatizando el siniestro mientras cada dólar por encima de $5,000 sigue deteniéndose ante una persona.