# How to evaluate insurance AI data security

Original article: https://decla.com/guides/insurance-ai-security

Text version: https://decla.com/guides/insurance-ai-security/llms.txt

## Section outline

- [Choose the task before requesting evidence](https://decla.com/guides/insurance-ai-security#scope)
- [A buyer evidence-request worksheet](https://decla.com/guides/insurance-ai-security#checklist)
- [Turn answers into a use decision](https://decla.com/guides/insurance-ai-security#method)
- [Worked example: a policy answer does not clear an action](https://decla.com/guides/insurance-ai-security#example)
- [Read public policies at the right scope](https://decla.com/guides/insurance-ai-security#sources)
- [Frequently asked questions](https://decla.com/guides/insurance-ai-security#faq)

Evaluate insurance artificial intelligence (AI) security around a specific agency task: which data it uses, who can access it and what action it can take. Ask for dated evidence that covers that scope, then record what is supported, unknown or held before sharing agency data.

## Choose the task before requesting evidence

An agency buyer, operations lead and security reviewer can use this checklist together. Describe one proposed workflow, its data categories and destinations. Separate offline preparation from connected retrieval, draft creation, sending and system-record changes. Each adds a different access or action question; an answer about one does not settle the others.

## A buyer evidence-request worksheet

Original buyer checklist. Fill in the evidence reference, as-of date and reviewer disposition for the proposed task; these questions do not certify security or establish a vendor control.

| Evidence area | Question to ask | Evidence owner and requested artifact | Unknown or hold boundary |
| --- | --- | --- | --- |
| Task and interface | Which task, environment and interface does the evidence cover? | Task owner and vendor technical owner; dated workflow description. | An unspecified product-wide answer leaves the task scope open. |
| Identity and permission | Who acts, what can that identity read or change, and how is access removed? | Agency access owner and vendor technical owner; exact grant scope and revocation evidence. | Mailbox visibility does not establish draft or send permission. |
| Data path and providers | Which inputs, outputs and copies reach each provider or destination? | Vendor data owner; current data-flow and processor list for this workflow. | A model-provider policy alone does not describe service storage. |
| Retention and deletion | What happens to source files, generated artifacts, logs and backups after use? | Vendor data owner; category-specific schedule and deletion evidence. | Record exceptions and unresolved copies instead of assuming zero retention. |
| Review and external action | What exact source, recipient, artifact edition and action does review cover? | Agency process owner and vendor technical owner; configured rule and scoped test. | A wording review does not establish authority to send or update a record. |
| Failure and readback | How are denied access, changed inputs and unknown results handled? | Task owner and vendor technical owner; allowed test traces and separate result check. | A response or screenshot does not establish the stored outcome. |
| Report and contractual scope | Which service, period and exceptions do supplied reports and agreements cover? | Vendor evidence owner and agency contract reviewer; approved dated materials. | Record exclusions and applicability questions; a badge is not the report. |

## Turn answers into a use decision

1. Record the answer and its scope (Owner: Agency buyer and evidence owner)

   Keep the source reference, edition, as-of date, task/interface and named evidence owner with each answer. Distinguish a public policy statement from a supplied report, configuration description and observed test.

2. Resolve the consequential unknown (Owner: Agency security reviewer and task owner)

   Name the exact missing permission, data destination or action condition. Ask the responsible owner for the smallest public-safe evidence that answers it. Do not request credentials or raw customer records as a substitute.

3. Make a bounded use decision (Owner: Agency decision owner)

   Record whether to continue evidence review, limit the proposed use or hold it. State the accepted scope and remaining questions. Reopen affected decisions when the workflow, provider, source edition or action changes.

## Worked example: a policy answer does not clear an action

Illustrative example using synthetic data. P1, G1, I1, D1 and E1/H1 are fictional evidence references and proposed decisions, not Decla configurations, tests or customer records.

| Checkpoint | Answer or proposed change | What remains unresolved | Owner and next decision |
| --- | --- | --- | --- |
| P1: public statement | A vendor policy describes model inference retention. | Service-file and log retention evidence absent. | Buyer: request the task-specific data path and schedule; do not label all data unretained. |
| G1: proposed grant | Mailbox read access is described for fictional interface I1; draft creation is the proposed action. | Draft grant not supplied; proposed connected test held. | Access owner: establish the exact acting identity and draft permission. Sending is outside this proposed test. |
| D1 v2: new destination | The proposed draft now includes a new external recipient. Earlier review covered offline wording in D1 v1. | The old wording review does not cover the new destination or external action. | Process owner: review the revised source, recipient and action before expanding use. |
| E1 / H1: evidence receipt | A current file-retention schedule arrives; receiver accepts reviewing its applicability. | One document is available. G1 permission and the changed-action decision remain open. | Security reviewer: compare schedule scope and exceptions; H1 is evidence review, not deployment approval. |

## Read public policies at the right scope

Decla’s public Privacy Policy displays an effective date of April 26, 2026. It describes zero data retention for AI model inference while separately listing service-data retention periods. Treat those as company policy descriptions at different scopes; a model-inference statement does not establish that every service file or log is deleted after a task.

Decla’s public Terms display an effective date of August 26, 2026. Section 7.2 assigns customer review of AI-generated content; the introduction says a conflicting signed master services agreement (MSA) controls. The footer separately describes version 2.1 changes and supersession of April 21, 2026 version 2. These statements are not audit findings or proof of a deployed approval control. Both bodies were checked October 6, 2026.

Sources:

- [Decla Privacy — public policy description](https://decla.com/privacy) — accessed 2026-10-06
- [Decla Terms — displayed date and review wording](https://decla.com/terms) — accessed 2026-10-06

## Frequently asked questions

### Is it safe to use AI with client data at an insurance agency?

It depends on the specific task. Evaluate AI security around the data it uses, who can access it and what action it can take. Ask for dated evidence that covers that scope, then record what is supported, unknown or held before sharing agency data.

### What is Decla?

Decla is AI software for independent insurance agencies and brokerages. It connects to your AMS, email and carrier portals and does back-office work inside them. Your team reviews the work before it goes out.