Is AI Automation Secure Enough for Insurance?

Start by understanding the data

Before considering the AI itself, an insurance business should understand exactly what information the proposed workflow needs.

For example, an AI receptionist might need to collect:

• a caller's name;
• telephone number;
• email address;
• company;
• reason for calling;
• policy or claim reference;
• and information required to route the enquiry.

An FNOL system may require considerably more, potentially including details about an accident, injuries, third parties and supporting documentation.

These are very different workflows.

The first security principle is therefore simple:

Only collect and process the information the workflow actually needs.

Giving an AI system access to an entire database simply because it might occasionally be useful is very different from providing access only to the information required for a specific task.

Narrower access generally makes the system easier to control, monitor and understand.

Map where the information goes

AI automation rarely consists of one piece of software.

A voice workflow, for example, might involve:

Telephone network → Voice platform → AI model → Workflow automation → Email or internal system

A website assistant might involve:

Website → AI platform → Approved knowledge base → Workflow → Customer service team

Every organisation considering automation should understand this chain.

Useful questions include:

• Which systems receive the information?
• Where is it processed?
• Where is it stored?
• Is a recording created?
• Is a transcript created?
• Which organisation operates each component?
• Which employees can access the information?
• Are subcontractors or subprocessors involved?
• How long is information retained?
• How is it deleted?
• Is information transferred to another system?
• What happens if one of those systems becomes unavailable?

This exercise is sometimes more important than debating which AI model is being used.

The security of the complete workflow matters.

AI training and operational use are not the same thing

One concern we regularly encounter is:

“Will our customer information be used to train an AI model?”

That question should always be answered clearly.

There is an important distinction between information being processed by an AI system to perform an agreed task and information being reused to train a model.

For example, a voice assistant may need to process a caller's words in order to understand what they are saying and respond appropriately.

That does not automatically mean those conversations should subsequently become training data.

At Riskbotix, our position is clear:

Client data, recordings, transcripts and Personal Data are not used by Riskbotix for AI model training.

Where anonymised and aggregated operational information is used to improve workflows or monitor performance, it should be handled separately and in accordance with the agreed contractual arrangements.

The same question should also be asked of the technology providers used within an automation stack.

Control what the AI can access

An AI system does not need access to everything simply because it is technically possible to give it access.

Consider an insurance voice receptionist.

It might need access to an approved knowledge base containing:

• opening hours;
• contact details;
• products offered;
• departmental responsibilities;
• general company information;
• and instructions for routing enquiries.

It probably does not need unrestricted access to:

every policyholder record;

every claims file;

employees' email accounts;

internal financial systems;

or unrelated company documents.

This is the principle of limiting access according to the job being performed.

The same applies to actions.

If the purpose of an automation is to capture an enquiry and send a summary, there may be no reason for it to have permission to modify a policy record, approve a payment or change a claim.

The fewer systems and actions an automation can access, the smaller the potential impact if something goes wrong.

Keep the knowledge controlled

Generative AI can be extraordinarily capable, but unrestricted answers are not always appropriate in an insurance environment.

A customer-facing system can instead be designed to work within an approved information set.

For example, an insurance assistant might answer questions using:

• information supplied by the business;
• approved FAQs;
• product descriptions;
• company procedures;
• contact information;
• and explicitly authorised website content.

If a question falls outside that information, the correct behaviour may be to escalate it rather than attempt to construct an answer.

This creates an important distinction between:

“Answer anything you can.”

and:

“Answer these types of questions using this approved information, and escalate everything else.”

The second is a much more controlled proposition.

Be careful when AI can take actions

The security implications become more significant when an AI system can do something rather than simply provide information.

Examples could include:

• transferring a telephone call;
• sending an email;
• creating a CRM record;
• booking an appointment;
• uploading a document;
• changing information in another system;
• or triggering a wider automated workflow.

These actions can be extremely useful.

But each integration should have defined permissions and business rules.

A system designed to create a new enquiry record, for example, does not necessarily need permission to edit every existing customer record.

Where practical, integrations should therefore be designed around the minimum access required to complete the intended workflow.

What about prompt injection and manipulation?

AI systems introduce some security considerations that conventional software does not handle in exactly the same way.

One is the possibility that a user deliberately attempts to persuade an AI system to ignore its instructions, reveal information or perform an unauthorised action.

This is often referred to as prompt injection.

The answer should not rely solely on telling the AI:

“Don't do that.”

More robust protection comes from the architecture around the AI.

For example:

• restrict the information the system can access;
• restrict the actions it can trigger;
• separate public knowledge from sensitive internal data;
• validate important actions outside the language model;
• apply defined business rules;
• require human approval where appropriate;
• and monitor unexpected behaviour.

In other words, the AI should not be the only security control protecting the workflow.

Recordings and transcripts need their own rules

Voice automation creates another important question:

What happens to the conversation after the call?

Depending on the configuration, a system may create:

• an audio recording;
• a transcript;
• a structured summary;
• extracted data fields;
• or a combination of these.

Businesses should decide which of these they actually need.

If the operational requirement is simply to create a structured enquiry, retaining every recording indefinitely may be unnecessary.

The appropriate retention period will depend on the purpose of the processing, applicable legal and regulatory requirements and the organisation's own policies.

What matters is that retention is deliberate rather than accidental.

The same applies to access.

A transcript containing customer information should not automatically be available to everyone simply because it is convenient to store it.

Third-party suppliers are part of the security assessment

Most modern technology services depend on other technology providers.

AI is no exception.

A business considering an AI automation should therefore understand the important suppliers involved in delivering it.

Depending on the workflow, these might provide:

• telephony;
• speech recognition;
• language models;
• cloud infrastructure;
• workflow automation;
• email;
• storage;
• or CRM functionality.

This does not mean that using third parties is inherently insecure.

Insurance companies already depend on cloud providers, software platforms, payment services, email systems and other external technology.

The important issue is supplier governance.

Organisations should understand which third parties form part of an important workflow and consider the security, contractual, data protection and resilience implications accordingly.

Security is also about resilience

Confidentiality is only one part of security.

An insurance business should also consider:

What happens if the system stops working?

An automation should not create a single point of failure without an appropriate fallback.

Depending on the process, this could include:

• routing calls elsewhere;
• reverting to a conventional telephone process;
• providing alternative contact details;
• queueing information for later processing;
• alerting a member of staff;
• or reverting to a manual procedure.

The more important the business process, the more important these questions become.

Security therefore includes not only preventing unauthorised access but also ensuring the organisation can continue operating when technology fails.

Data protection remains data protection

Using AI does not remove an organisation's existing data protection responsibilities.

Businesses still need to consider matters such as:

• the purpose for which personal information is being processed;
• whether all information being collected is necessary;
• transparency;
• retention;
• individual rights;
• security;
• supplier relationships;
• and accountability.

Depending on the nature of the system and the information involved, a Data Protection Impact Assessment may also be appropriate.

AI should therefore be incorporated into the organisation's existing governance framework rather than treated as something operating outside it.

Human oversight still matters

Not every security control is technical.

People remain important.

Someone should understand:

• what the automation is designed to do;
• which information it can access;
• where its boundaries sit;
• how exceptions are handled;
• how performance is monitored;
• what happens if something goes wrong;
• and who is responsible for making changes.

This is particularly important when an AI system interacts directly with customers.

Real interactions should be reviewed, particularly during the early stages of deployment.

Unexpected situations can then be identified and the workflow refined.

A controlled AI system should become better governed over time, not simply be deployed and forgotten.

Questions to ask before deploying AI in an insurance workflow

A useful security review does not need to begin with hundreds of technical questions.

Start with the fundamentals:

• 1. What is this automation actually intended to do?
• 2. What information does it genuinely need?
• 3. Which systems will process or store that information?
• 4. Which third parties are involved?
• 5. Is our data used for AI model training?
• 6. Who can access recordings, transcripts or extracted information?
• 7. How long is information retained?
• 8. What other systems can the AI access?
• 9. What actions can it perform?
• 10. What happens when the AI is uncertain?
• 11. What happens if the service fails?
• 12. Who monitors and governs the workflow?

If these questions cannot be answered clearly, the automation probably needs more work before deployment.

So, is AI secure enough for insurance?

There is no technology that becomes secure simply because a supplier says that it is.

AI should be treated in the same disciplined way as other technology used in an insurance business — while also recognising the additional risks created by generative systems.

The objective is not to eliminate every conceivable risk.

It is to understand the workflow, minimise unnecessary exposure and put proportionate controls around the risks that remain.

That means:

Know what data is being used.

Know where it goes.

Limit who and what can access it.

Restrict what the automation can do.

Define what happens when it is uncertain.

Plan for failure.

Keep people accountable.

Implemented in that way, AI automation does not need to mean handing control of sensitive insurance processes to an unrestricted machine.

It can mean something much simpler:

using carefully controlled technology to perform a clearly defined task more efficiently.