Data security in underwriting automation: what carriers must verify before trusting an AI vendor

The governance gap in underwriting AI adoption

Commercial P&C carriers are moving faster on AI adoption than at any point in the last decade. According to industry analysis, 22% of insurers plan to have an agentic AI solution in production by the end of 2026. Carriers that invested heavily in advanced analytics and AI between 2022 and 2024 achieved combined ratios six points lower and premium growth three points higher than slower adopters.

The business case is settled. The security question is not.

In conversations with underwriting leaders across carriers and MGAs, a pattern emerges: the procurement team evaluates accuracy, speed, and integration. The security review happens later, often as a checkbox exercise. By the time the CISO's team gets involved, the pilot is already running, underwriting data is already flowing, and the vendor's architecture is already embedded in the workflow.

This sequence is backwards. For underwriting automation specifically, data security is not a procurement afterthought. It is an underwriting risk.

Why underwriting data demands a higher security standard

Underwriting data is not generic enterprise data. It includes proprietary risk appetite guidelines, pricing models, loss history, broker relationships, and competitive intelligence about which risks a carrier wants and which it declines. A breach of underwriting data does not just trigger a notification obligation. It exposes the carrier's competitive positioning to the market.

Consider what flows through a typical underwriting automation platform: broker submission emails with policyholder PII, loss runs containing five to ten years of claims detail, SOVs with property valuations and construction data, internal appetite rules that define which risks to pursue, and underwriter notes capturing judgment calls on borderline risks. Every one of these data categories carries regulatory, competitive, and reputational exposure.

The challenge is compounded by the nature of AI systems. Unlike a traditional database that stores data at rest, an AI underwriting platform actively processes, extracts, enriches, and routes this data. The attack surface is not a single database. It is the entire data pipeline from submission ingestion through decision output.

The five-point vendor security evaluation framework

Based on patterns from carrier procurement processes, regulatory guidance, and the security architecture decisions that matter most for underwriting AI, here is a practical framework for evaluating any vendor in this space.

1. Certifications: the baseline, not the finish line

SOC 2 Type II and ISO 27001 certifications should be non-negotiable entry requirements. SOC 2 Type II verifies that a vendor's security controls have been operating effectively over a sustained period (typically 6 to 12 months), not just that they exist on paper. ISO 27001 confirms an information security management system is in place and independently audited.

But certifications alone are insufficient. They confirm that a vendor has a security program. They do not confirm that the program is designed for the specific risks of underwriting data. A vendor can be SOC 2 certified and still commingle client data in shared infrastructure, train models across client datasets, or lack meaningful access controls between client environments.

The evaluation question is not "are you SOC 2 certified?" It is "what does your SOC 2 scope cover, and does it include the AI training and inference infrastructure that touches our underwriting data?"

At Pibit.AI, the CURE™ platform maintains SOC 2 (AICPA), ISO 27001, and NIST AI RMF compliance. The scope explicitly covers the full data pipeline from submission ingestion through extraction, enrichment, and decision output.

2. Data residency and access controls

Where does the data live? Who can access it? These questions seem basic, but the answers in underwriting AI are often more complex than vendors initially represent.

Key evaluation criteria include geographic data residency (is underwriting data stored in jurisdictions that align with your regulatory requirements?), encryption standards (AES-256 at rest, TLS 1.3 in transit as minimums), access control granularity (can the vendor demonstrate role-based access that limits which of their employees can see your underwriting data?), and data retention policies (how long does the vendor retain your submission data after processing, and what happens to it after contract termination?).

The last point is particularly important. Some vendors retain processed data indefinitely for "model improvement." If a carrier's loss run data, appetite rules, or pricing signals persist in a vendor's system after the relationship ends, the carrier has lost control of its competitive intelligence permanently.

3. Model isolation: the differentiator most carriers miss

This is where the evaluation separates vendors built for enterprise underwriting from vendors repurposing generic AI infrastructure.

Model isolation means that each client's data, models, and underwriting guidelines operate in a dedicated, segregated environment. No data from Client A is used to train, fine-tune, or improve models serving Client B. No underwriting rules from one carrier leak into another carrier's decisioning logic.

Why this matters practically: a carrier's underwriting appetite is proprietary intellectual property. If a vendor trains a shared model on data from multiple carriers, the model absorbs patterns from all of them. Your appetite for certain risk classes, your pricing thresholds, your declination patterns become embedded in a model that also serves your competitors. The AI becomes a mechanism for competitive leakage, and most carriers never realize it is happening.

Evaluation questions: Does the vendor run separate model instances per client, or a shared multi-tenant model? Are client environments hosted on isolated infrastructure (separate cloud instances, not just logical separation)? Can the vendor provide a written commitment that your data will never be used to train models serving other clients?

The CURE™ platform operates on dedicated AWS instances per client, with complete model isolation. Each carrier's extraction models, enrichment rules, and underwriting logic are trained and deployed independently. No cross-client data sharing occurs at any layer of the stack.

4. Provenance and explainability: the regulatory imperative

The regulatory landscape for AI in insurance is shifting rapidly. The EU AI Act, taking effect in August 2026, requires insurers using AI to support underwriting or claims automation to maintain auditable documentation explaining how models work, how bias is tested, and how decisions can be challenged. While this regulation targets EU markets directly, US carriers operating globally are already adapting their vendor requirements in anticipation.

In the US, state-level AI regulations are tightening. Colorado's AI Act requires deployers to use reasonable care to avoid algorithmic discrimination. New York's Circular Letter 1 (2019) already requires insurers to demonstrate that AI-based underwriting decisions are actuarially justified. Multiple other states have proposed or enacted similar requirements.

For underwriting automation vendors, this means two things. First, every data point extracted from a submission document must be traceable to its source. If an AI system extracts a loss ratio from a loss run, the system must be able to point to the exact page, table, and cell where that number originated. Second, decisioning logic must be explainable. If the system flags a submission as outside appetite, the carrier must be able to explain why in regulatory or legal proceedings.

Vendors that treat provenance as a "nice to have" will become compliance liabilities as these regulations take hold. The evaluation question: can the vendor demonstrate field-level provenance (linking every extracted data point to its source document and location) and provide audit trails for every automated decision?

The CURE™ platform was designed around provenance from the ground up. Every extracted data point links back to the source document, page, and location. The platform provides full audit trails for all automated decisions, enabling carriers to meet current and emerging regulatory requirements for AI transparency.

5. Incident response and breach notification

Even with strong preventive controls, carriers must evaluate a vendor's preparedness for security incidents. Key evaluation criteria: Does the vendor maintain a documented incident response plan specific to AI system compromises? What are the contractual notification timelines for data breaches (24 hours should be the maximum)? Does the vendor carry cyber liability insurance adequate to your exposure? Has the vendor conducted a penetration test within the last 12 months, and will they share the executive summary?

These are not hypothetical concerns. Munich Re's 2026 cyber insurance analysis confirms that third-party vendor compromises remain one of the most common breach vectors for insurance carriers. The vendor you trust with underwriting data must be at least as rigorous about breach preparedness as you are.

The cost of getting this wrong

The financial exposure from inadequate vendor security is not abstract. A breach of underwriting data triggers regulatory notification costs, potential fines under state privacy laws, remediation expenses, and E&O exposure if policyholder data is compromised. Beyond the direct costs, competitive intelligence leakage through shared AI models is a silent loss that never appears on a balance sheet but erodes underwriting advantage over years.

Carriers that invested in AI governance early, including proper vendor security evaluation, data isolation requirements, and explainability standards, are building a structural advantage. They move faster on AI adoption because their security foundation supports it. Carriers that skip this step will find themselves either pulling back from AI entirely when regulators ask questions they cannot answer, or locked into vendor relationships where their proprietary underwriting intelligence has already been compromised.

A practical next step

Before the next underwriting AI vendor evaluation, assemble a cross-functional team: underwriting leadership, IT security, compliance, and legal. Use the five-point framework above as a structured scorecard. Weight model isolation and provenance at least as heavily as accuracy and speed. The vendors that score well on all five dimensions are the ones built for the regulatory and competitive reality carriers face in 2026 and beyond.

The question is not whether AI will transform commercial underwriting. That trajectory is clear. The question is whether the AI infrastructure your carrier depends on is secure enough, isolated enough, and transparent enough to protect the underwriting advantage you have spent decades building.

Why AI alone will not fix submission intake explores the broader architecture question. For carriers evaluating document extraction accuracy alongside security, why 95% AI extraction is not production ready provides the accuracy evaluation framework. And submission clearance in our glossary defines the intake workflow these systems automate.