How to Document AI Data Flows for Cyber Insurance Underwriting

Documenting AI data flows for cyber insurance underwriting means recording, for each AI tool, what data enters which service, where it is processed, how long the vendor keeps it, whether it can be used for training, which subprocessors touch it, who can access it and how it is deleted, all backed by contract evidence. That record lets you answer the data questions the actual application asks, accurately, without volunteering guesses or overstating your controls.

This guide expands the data-mapping step of our AI questions in cyber insurance renewals checklist. It assumes you already have an AI tool inventory and an AI acceptable-use policy that sets the data rules.

Why the AI data question carries the most weight

Of the AI topics advisers report seeing on renewal forms, data is the most specific. Northstar IT Advisory wrote in October 2026 that underwriters want to know what data is being sent to third-party AI providers. Daniel Winn of Jensten London Markets told Insurance Business in August 2026 that the core concern is sensitive or regulated information going into public large language models outside the client's environment, as opposed to tools that keep data contained internally.

These are observations from a consultancy and a broker panel, not a standard question set. Insurance Business reported that no standard AI question exists yet. Some forms will ask about data in detail, some briefly, and some not at all.

What is an AI data flow record?

It is a per-tool description of where data comes from, how it reaches the AI service, what the vendor does with it, and where the output goes. Each claim in it should point to a contract clause, an admin setting or a log, not to someone's recollection.

For each tool in the inventory, record:

• Source: the systems or document stores the data comes from.
• Data categories: using your own classification, including any regulated data.
• Entry method: pasted into a chat window, uploaded as a file, pulled by a connector, or sent through an API by your own code.
• Destination: the vendor service and the account tier (company tenant or individual accounts).
• Processing and storage location: the region or country the contract commits to, if it commits to one.
• Retention: what the vendor keeps (prompts, files, outputs, logs) and for how long.
• Training use: whether your inputs or outputs may be used to train or improve the vendor's models under your contract and current settings.
• Subprocessors: the third parties the vendor uses to process your data.
• Access: who at your organisation and at the vendor can see the data.
• Deletion: how you delete data, how long deletion takes, and what happens when you end the contract.
• Output destination: where results go next, such as a ticketing system, a code repository or a customer email.

A simple diagram per tool helps reviewers, but the written record is the evidence.

How do you verify vendor retention and training terms?

Read the terms that apply to your account tier, usually the business agreement, data processing addendum and service-specific terms, and compare them with the settings in your admin console. Save dated copies of both, because terms and defaults change.

Things to check while you read:

• Whether retention differs between chat history, uploaded files, API traffic and abuse-monitoring logs.
• Whether training use is off by default for your tier or depends on a setting someone could change.
• Whether any feature you have enabled, such as connectors or memory, changes the retention picture.
• Whether the commitments survive the end of the contract, and what the deletion timeline is.

If the terms do not answer a question, record "not stated" and ask the vendor in writing. Do not fill the gap with what a marketing page implies.

Subprocessors and access

Most AI services rely on other providers for hosting or model inference. Keep the vendor's subprocessor list, the date you retrieved it, and how the vendor notifies you of changes. Note where the list includes a model provider different from the vendor you signed with, because that changes who actually processes the data.

On your side, record which administrators can change settings, export history or connect new data sources. NIST's AI Risk Management Framework, under GOVERN 6.1, calls for policies and procedures that address AI risks associated with third-party entities, and GOVERN 6.2 calls for contingency processes for failures or incidents in high-risk third-party data or AI systems. Your third-party risk process should include AI vendors on the same terms as other processors.

Deletion and offboarding

Write down how data leaves each service. Cover individual leavers (their history and files), retiring a tool entirely, and ending the contract. NIST's GOVERN 1.7 notes that irregular or indiscriminate deletion of AI systems can increase risk, for example where records may be needed for a later investigation, so align AI deletion with your existing retention schedule rather than deleting on impulse.

Contractual evidence to collect

• The signed business agreement and data processing addendum for each sanctioned tool.
• Service-specific terms covering retention and training use.
• The current subprocessor list, with retrieval date.
• An admin settings export or dated screenshots showing retention, training and connector settings.
• Any vendor security attestations you rely on, with their dates.
• Written vendor answers to questions the terms left open.
• For unsanctioned or prohibited tools: the date found, the action taken, and the evidence of blocking.

How should you answer the application's AI data questions?

Answer exactly what the application asks, from the record, and note exceptions instead of rounding them away. If a question is ambiguous, ask your broker what it means before you answer.

Some practical rules:

• Quote the scope precisely. "Staff may only use the company tenant for client data" is different from "no client data has ever entered a consumer AI tool".
• Do not describe a control you have not evidenced.
• Where the form says nothing about AI, ask your broker whether any AI use should be disclosed anyway. Selorm Kofi Domeh of Talbot Jones told Insurance Business that brokers are largely expected to volunteer what they judge to be a material fact.
• Keep a copy of the submitted answers with the evidence that supported each one.

Duties of disclosure differ by jurisdiction, and Northstar cites the UK Insurance Act 2015 duty of fair presentation as an example where a good-faith answer that turns out to be wrong can still affect a claim. Good records do not guarantee cover, a renewal, a premium or a claim outcome. Have your broker or counsel review the answers and the policy wording; this article is not legal advice.

Sources

• Northstar IT Advisory: Your cyber insurance renewal will ask questions your last one did not
• Insurance Business: Your client's staff are pasting data into ChatGPT. Their cyber insurer wants to know about it
• NIST AI RMF Playbook: Govern