Security and Data Handling for Sensitive Claim Records

TL;DR — Canotera separates reading from prediction to isolate sensitive data. Generative AI extracts structured features and purges the raw text, passing only anonymized vectors to mathematical models while using cryptographic pointers to maintain traceability.

A claims file is a liability before it is an asset. It contains medical histories and settlement correspondence. When an insurer considers running thousands of pages through an AI pipeline to forecast litigation risk, the immediate question from the security team is how the data is isolated. They are right to ask. Building a system that ingests unstructured, highly sensitive legal and medical documents requires a fundamentally pessimistic architecture. We assume the data is toxic and treat its lifecycle accordingly. Claims organizations are fighting social inflation and third-party litigation funding. They need to set realistic reserves on day one and allocate defense spend accurately. They cannot do that if their security posture prevents them from using the data they already own.

The Ingestion Boundary

The core problem is that predictive models require clean inputs, but claims files arrive as chaotic PDFs. Pleadings, medical records, and adjuster notes are merged into massive, unsearchable blobs. Canotera uses generative AI to read and structure these files. Crucially, the generative layer does not predict the outcome. It acts as a highly specialized extraction engine. We enforce a strict boundary at the ingestion layer. Documents are processed ephemerally. The generative model extracts the facts material to the claim, such as injury severity, jurisdiction, and prior settlement demands. It strips out the noise. This means the downstream mathematical models that actually generate the forecast never interact with raw medical records or unstructured text. We separate the reading from the math. This architectural choice limits the footprint of sensitive data. It only exists in its raw form in our ingestion buffer long enough to be converted into a structured vector. Once the extraction is complete, the unstructured text is purged from memory. We do not write raw claim files to persistent storage. If a system does not hold the data, it cannot leak the data.

Processing thousands of pages per claim introduces latency challenges. A naive approach would feed the entire document bundle into a massive context window, hoping the model retains the relevant details. That is both slow and insecure, holding vast amounts of protected health information in active memory for extended periods. Instead, we use a deterministic chunking and routing pipeline. We classify document types on ingestion and route specific pages to specialized extraction nodes. A medical record goes to a node tuned for medical terminology. A pleading goes to a legal node. This parallel processing reduces the time sensitive data spends in memory and dramatically lowers end-to-end latency.

Traceability Without Retention

Insurers need to know exactly why a settlement range or escalation probability was generated. A black box is useless in claims defense. If we predict a severe reserve delta compared to the current reserve, the adjuster must see the specific drivers. This creates a tension between security and explainability. If we delete the raw documents immediately after extraction, how do we prove the output to the user? We solve this through cryptographic pointer mapping rather than raw data replication. When the generative AI extracts a fact, it generates a directional pointer to the original document residing in the insurer's environment. The Canotera platform stores the extracted feature and the pointer. When an adjuster reviews a forecast in the interface, the application uses these pointers to retrieve and highlight the exact sentence in the source file via the API.

The source of truth remains strictly within the insurer's perimeter. This allows us to provide full traceability for every escalation trigger and comparable case without expanding the attack surface. The adjuster clicks a driver, and the system pulls the exact paragraph from the independent medical examination explaining the required surgery. The data stays where it belongs. This architecture requires a highly resilient API layer. The integration must handle real-time fetching without noticeable lag, which is why we spend significant engineering effort optimizing our API gateways and query performance. Monitoring this system requires a different approach than standard web applications. We cannot simply log the inputs and outputs to debug errors. Logging the inputs means logging protected health information. Our observability stack is built around telemetry and structural validation rather than content inspection. We monitor the shape of the data, the processing time per node, and the API failure rates. If an ingestion pipeline fails, the system logs the sequence of operations and the memory state, explicitly redacting the text strings that caused the failure. Debugging is harder, but the data remains secure. We trade developer convenience for absolute data confidentiality.

Strict Model Isolation

The predictive layer of Canotera relies on mathematical and geometric machine learning models. These models are trained on large volumes of resolved cases with known outcomes to map the topology of litigation. They calculate settlement ranges and detect nuclear verdict risks based on historical patterns. A common fear among chief information security officers is that one carrier's sensitive data will leak into another carrier's model weights, surfacing in an entirely different environment. We prevent this through strict single-tenant model deployment. There is no global pool of data where every client's claims are mixed together. Models are trained on resolved cases, and we deploy dedicated inference instances for each client. The weights are updated based on the specific carrier's closed claims and our proprietary baseline, but the inference pipeline is entirely siloed. When a new case is ingested, the structured data vector is scored against this isolated model. The infrastructure is physically separated at the virtual private cloud level.

Onboarding a new carrier requires calibrating these models against their historical resolved cases. This historical data transfer is often the most vulnerable phase of deployment. We do not require carriers to send us their entire historical archive in plain text. We deploy a lightweight, local sanitization client within the carrier's firewall. This client strips direct identifiers before the historical data ever crosses the network to our training environment. We are interested in the geometry of the claim: the timeline, the venue, the injuries, and the final settlement. We do not need the plaintiff's social security number. By filtering at the source, we reduce the risk of the initial data load and accelerate the security approval process. Security in this context is not a compliance checklist. It is a series of hard engineering constraints that dictate how memory is allocated, how APIs are structured, and how data is discarded. We designed Canotera to fit into the reality of enterprise claims operations. That means assuming the network is hostile, the data is sensitive, and the users require absolute proof for every number we generate. Trust is an engineering problem, not a marketing claim.