Building an AI Immune System for Insurance Core Systems: Tiered Self-Healing Platform Design

The author proposes a self-healing platform (codenamed "Bianque") for a life insurance group's heterogeneous production systems, ranging from modern Spring Boot 3 services to legacy JSP/Servlet applications. The platform is designed as a digital immune system with four layers: self-protection (rate limiting, circuit breaking), perception (real-time aggregation of logs, traces, and service tickets), diagnosis and repair (multi-agent root-cause analysis, automated infrastructure recovery, and code patch generation with regression tests), and knowledge accumulation (structured case library enabling faster resolution of recurring faults).

Tiered Coverage by System Maturity

Systems are classified into three tiers:

Tier 1 (Spring Boot 3, Git + CI/CD + containerized): full closed-loop — observation, root-cause diagnosis, patch generation, controlled release with human merge approval.

Tier 2 (Spring Boot 2, partial CI/CD): observation, diagnosis, and repair suggestions; patch automation only where CI/CD maturity allows.

Tier 3 (JSP/Servlet, no Git/pipeline/trace): observation, alerting, and log aggregation only via sidecar collection; no tracing or auto-repair.

This tiering avoids over-promising on legacy systems while delivering immediate observability value across the board.

Current Pain Points and Loss Model

The existing incident flow relies on customers discovering failures, leading to a 4–8 hour end-to-end MTTR for P2 incidents, with over 60% spent on waiting and handoffs. Five pain points are identified: slow detection (no business-semantic monitoring), difficult localization (cross-system, multi-database logs), slow repair (dev capacity booked by feature work), recurring faults (no centralized knowledge base), and compliance pressure (regulatory reporting deadlines and audit trails). A layered loss model quantifies effort across Tier 1/2/3 using real incident counts, on-call costs, P1 incident impact pricing, and repeat-fault waste — establishing a baseline for before/after comparison.

Target State for Tier 1

The goal is to compress the incident lifecycle: automatic capture → agent-based root-cause localization within ≤3 minutes → graded response (L1 auto-recovery / L3 patch generation) → change-request ticket with root-cause report and test results → canary release with auto-rollback → case ingestion for future instant matching. Tier 2 stops at diagnosis + suggestion; Tier 3 stops at observation + alerting.

Four Non-Negotiable Business Principles (Regulatory Alignment)

Code changes always require human approval before release — agents can author patches and run tests, but merge and deploy need a human sign-off.

Customer data never leaves the domain — policy numbers, ID numbers are masked before entering any LLM; models are deployed privately.

Full audit trail and rollback capability — every automated action is logged; every release has a rollback plan.

Tiered capability ≠ lowered compliance — Tier 3 log collection still passes through the same desensitization pipeline; compliance requirements are uniform.

Value Estimation (Layered, Pending Calibration)

MTTR is broken into four segments with current vs. target times:

Detection: 30–120 min (ticket-driven) → <1 min (all tiers, via three-source real-time sensing + ticket semantic parsing).

Localization: 30–180 min → ≤3 min (Tier 1/2, via agent correlation of logs/traces/code).

Repair: L1 15–30 min / L3 days → L1 ≤5 min (deployment-shape dependent) / L3 ≤1 day (Tier 1 only, via auto-patch).

Verification & retrospective: 30–60 min + missing retrospectives → automated canary guardrails + auto case ingestion.

Three value layers are summarized: observation value (all tiers, reduced on-call and triage effort), diagnosis value (Tier 1/2, faster root-cause, fewer dev interruptions), and self-healing value (Tier 1 only, MTTR compression + patch automation + lower recurrence). All figures are placeholders awaiting real operational data.

Why Build Instead of Buy: Three Differentiators

General AIOps products handle multi-system observability but stop at metric alerts and repair recommendations. The custom platform adds: (1) code-level root-cause + controlled patching for Tier 1 (class/method/SQL-line precision → auto-patch → approval gate); (2) financial-grade approval chain (L1/L2/L3 grading + CR ticket + human sign-off aligned with regulator expectations); (3) data ownership and flywheel — cross-system case library owned by the group, growing richer with each incident, creating a compounding advantage.

Four Moats

Cross-system case library: unified knowledge base of incidents, ops corpus, and terminology mappings — a data asset that appreciates over time.

Data flywheel: each incident auto-ingested → recurrence instant-matched → more scenarios validated → library thickens — first-mover positive loop, cold-start barrier for latecomers.

Compliance chain: approval gates deeply embedded in org processes and regulatory reporting templates — requires platform + process + people co-adaptation, not replicable as a product.

Heterogeneous adaptation: already-integrated group-wide access protocols, log/trace collection, multi-database diagnostics, deployment-shape adapters — engineering asset that would need re-integration if bought.

Risks and Mitigations

AI misjudgment triggering secondary faults (High): Action allow-list (only idempotent ops like restart/failover/scale); blast-radius assessment per action; L2+ requires human approval; full rollback capability.

Generated patches introduce new defects (High): Three gates: compile + existing tests + AI-generated regression tests; 10% canary start; metric anomaly auto-rollback; human sign-off mandatory.

Data security & compliance (Medium): Private model deployment; mandatory field-level masking before LLM ingress; full-chain audit logs; least-privilege design.

Org acceptance (approvers afraid to sign) (Medium): CR tickets attach full evidence chain (root-cause, plan, tests, blast radius), turning approval from trust-based to evidence-based; dual-review transition period for P2.

Platform itself becomes a failure source (Medium): Deployment isolation from core systems; platform failure auto-degrades to "alert-only mode" (immune system must not become the disease).

Engineering effort crowds out core projects (Low): Phase 0: 2 people × 2 months; observability output also accelerates core-system integration testing — symbiotic investment.

The article concludes that the generational gap in incident response is shifting from "who has more people" to "whose systems can heal themselves," and the group's heterogeneous reality may allow a pragmatic path: first make everything observable, then enable self-healing for the subset that is ready.