Personal Data Protection
Insurance and banking conversations are full of personal details: names, phone numbers, policy holders and account information. Achilles protects these in two separate places, because they face different risks. The conversation itself is protected by masking, and the audit record is protected by hashing. Both are needed, and this page explains each in plain terms so your compliance team can assess them.
Two places, two protections
| Where | Who could see it | Protection |
|---|---|---|
| The conversation | The AI model and the person chatting | Masking: part of the value is hidden, for example Pr********ma |
| The audit record | Anyone with console or database access | Hashing: the value is replaced by a fixed code that cannot be turned back into the original |
It is tempting to think masking on its own makes the logs safe. It does not, which is why the platform protects the audit record separately.
Choosing what counts as personal
When an agent's abilities are set up, the fields that hold personal details are marked. A lookup of renewals might mark the customer name, and a lead creation might mark name and phone. This single marking drives both protections. If you add a new ability with personal fields, make sure those fields are marked. The Agent Builder proposes this for you, and you should review it.
Who sees what
Masking depends on role. You choose which roles are trusted to see real values.
| Role example | What they see |
|---|---|
| Frontline broker or agent | Masked names, for example Pr********ma |
| Branch manager | Real names, if you have listed the role as trusted |
| Administrator | Real names, if listed as trusted |
Masking happens before the AI model sees the data, so the model works with the hidden version for roles that are not trusted. Tie roles to your existing user groups as described in Roles and access.
If a role is allowed to see real values, the agent may repeat them in its reply, and that reply is recorded. Keep the trusted list short, and review it whenever staffing or responsibilities change.
What is written to the audit record
Personal fields are converted to a code before they are stored. The same customer always produces the same code, so an investigator can ask whether two conversations concerned the same person, without the name ever being stored. Fields that are not personal, such as a premium amount, are stored normally so you can still review what happened. Empty fields stay empty.
What is not covered
Being clear about limits helps your risk assessment.
- The agent's reply text. If a trusted role is shown a real name and the agent repeats it, that name appears in the reply and the conversation record.
- Handoff packages. When a conversation is passed to a human, the package includes the transcript and the data that was retrieved so the person can act. It reflects what the customer saw, so masked values stay masked, but it is otherwise readable. Send handoffs only to appropriate people. See Human handoff.
- What customers type. Details a customer types freely, such as a phone number in a message, are part of the conversation text. Masking applies to fields returned by your systems.
- Codes are not a secret vault. They are designed for matching, not for locking data away. Treat them as sensitive, and note that the same value produces the same code across environments.
Practical guidance for compliance teams
- Ask for the list of fields marked as personal for each agent, and check it against your data classification.
- Confirm which roles are trusted to see real values, and that this list matches policy.
- Test in the Playground with your narrowest role and check that details are hidden.
- Open a test conversation in Sessions and confirm that personal fields show as codes in the record.
- Include agents in your usual data-protection assessments, covering purpose, retention and where data is processed. Your Achilles contact can supply technical detail, and the IT overview covers hosting.
- Restrict console access to people who need it. See Users and teams.
The platform keeps the audit record and does not delete it automatically today. Agree a retention approach with your Achilles contact if your policy sets limits.
To see how everything is recorded and reviewed, continue to Audit trail.