How Do We Protect Sensitive Data Used by AI in Delegated Authority?

Bordereaux and the documents that accompany them rarely contain only underwriting figures.

They often include policyholder names, addresses, vehicle or property details, claims narratives and other personal data, alongside commercially sensitive information about pricing, exposure and coverholder performance.

This data already moves between coverholders, MGAs and insurers under existing data protection obligations.

When an AI tool is introduced to help process that data, oversight teams need to know whether the same protections still hold, and what new questions they need to ask.

This article explains what stays the same, what changes, and what to check before trusting an AI tool with sensitive delegated authority data.

The operational challenge of sensitive data in DA

Delegated authority data flows involve several parties, often across jurisdictions.

A single monthly bordereau might pass from a coverholder's local system, through an MGA's processing team, into an insurer's data warehouse, and potentially through one or more third-party technology providers along the way.

At each step, the data may include:

• Policyholder names, addresses and contact details.
• Vehicle, property or health-related information depending on class of business.
• Claims narratives that can contain sensitive personal detail.
• Commercially sensitive underwriting terms, pricing and loss ratios.

Every organisation handling this data carries some responsibility for protecting it, regardless of how many parties are involved in the chain. Adding a new technology provider, including an AI vendor, extends that chain rather than replacing it.

Traditional approaches to data protection in DA

Organisations have long relied on a familiar set of controls to manage this risk:

• Contractual clauses in coverholder and outsourcing agreements specifying how data may be used, stored and shared.
• Access controls limiting which individuals or teams can view sensitive fields.
• Encryption of data in transit and at rest.
• Manual review processes, where experienced staff check bordereaux and flag anything unusual before it moves further downstream.

These controls remain valid and necessary. However, they were largely designed around known, static system-to-system transfers rather than a landscape where third-party AI tools may access, process or temporarily hold data as part of interpreting it.

As bordereaux volume and complexity increase, manual review in particular becomes harder to sustain consistently, which is part of why organisations look to AI for support in the first place.

Where AI changes the data privacy risk profile

Introducing an AI tool does not automatically create new categories of risk, but it does raise specific questions that traditional vendor relationships may not have needed to answer before.

Key considerations include:

• Model training on submitted data. Some AI tools may, by default, use customer data to improve or train models that are shared across other customers. This needs to be explicitly addressed and typically excluded unless the organisation has agreed otherwise.
• Data residency. AI processing may occur in a different jurisdiction than expected, particularly where a vendor relies on cloud infrastructure or sub-processors in other territories.
• Sub-processing chains. An AI vendor may itself rely on other providers, such as underlying model providers or cloud hosts, extending the chain of parties who touch the data.
• Reduced visibility. It can be harder to see exactly how an AI system has interpreted or stored data internally compared with a traditional, rules-based system with a fixed audit trail.

At the same time, AI tools can also improve certain aspects of data protection when configured correctly, for example by applying consistent access controls, generating detailed audit logs of what was accessed and when, and reducing the number of people who need to manually view sensitive fields during processing.

The overall effect is not simply more risk or less risk. It is a shift in where the important questions sit, from purely contractual and procedural controls to a combination of contractual terms and specific technical configuration.

Operational considerations for governing AI and sensitive data

Before adopting an AI tool that will touch sensitive DA data, oversight teams should work through a small number of practical checks.

• Confirm whether the vendor uses submitted bordereaux data to train models shared across other customers, and ensure contracts prohibit this unless explicitly agreed otherwise.
• Establish data residency and retention terms with the vendor, consistent with the organisation's existing outsourcing and data protection policies.
• Ask the vendor to identify any sub-processors involved in storing or processing the data, and confirm they meet the same standards.
• Agree clear terms on data deletion at the end of the contract or relationship.
• Maintain human oversight of AI outputs involving sensitive data, particularly where those outputs inform decisions that affect policyholders, such as claims handling or eligibility.

None of these steps require specialist AI expertise. They are extensions of the due diligence organisations already apply when outsourcing data processing to any third party, adapted to reflect how AI tools specifically handle and potentially reuse data.

Example

A Lloyd's managing agent is considering an AI tool to automatically extract and validate data from monthly bordereaux submitted by an overseas coverholder handling a marine cargo binder.

Before onboarding the tool, the agent's oversight team reviews the vendor's data handling practices, confirms that policyholder data will not be used to train models shared with other customers, and agrees contractual terms on data residency and retention consistent with the agent's existing outsourcing policy.

The managing agent adopts the AI tool with contractual safeguards in place, giving the oversight team confidence that sensitive policyholder and underwriting data is protected to the same standard as under its existing manual process, while benefiting from faster, more consistent bordereaux validation.

FAQs

• Does using AI to process bordereaux automatically increase data privacy risk?

  Not inherently. AI itself does not increase risk simply by being used. It introduces new questions, such as whether data is used to train shared models or processed in a different jurisdiction, which need to be addressed through vendor due diligence and contracts, in the same way any outsourced data processing arrangement would be assessed.

• What should we ask an AI vendor before sharing bordereaux data with them?

  Key questions include whether the vendor uses submitted data to train models shared with other customers, where data is stored and processed, how long it is retained, which sub-processors are involved, and what happens to the data if the contract ends.

• Who is responsible for data privacy when an AI vendor processes DA data on our behalf?

  Responsibility is typically shared and should be defined clearly in the contract. In practice, the insurer or MGA usually retains ultimate accountability for data protection compliance even when processing is outsourced to an AI vendor.