Testing AI Customer Service for Bias: A Pair-Test Method

Testing AI Customer Service for Bias: A Pair-Test Method

To test AI customer service for bias, send the agent questions that are equivalent in content and change only one detail at a time: the name, the writing style, the accent in an audio message, or the customer's region. Then compare whether the decision, the tone, the effort requested and the handoff were the same. If the answer changes while the case has not, you have unequal treatment, and it needs to be fixed before the agent talks to real customers.

Key takeaways

• Bias in support shows up as a difference in outcome, tone or required effort between customers with the same problem.
• The cheapest test is the paired test: two messages identical in content, different in a single variable (name, region, writing style or accent).
• Use synthetic personas and volunteers who gave consent, not real customer conversations.
• Repeat each pair several times and score it against a written rubric, ideally without knowing which variant is which.
• After any change to instructions, model or integration, run the test set again.

What bias in AI customer service is and where it appears

Bias here is not an opinion held by the model. It is a systematic difference in treatment that the case does not justify. One customer asks for a duplicate of a payment slip and gets the link right away. Another makes the same request, with a different name or a different way of writing, and gets three confirmation questions and a suggestion to call the support line. The customer's problem was the same.

That difference can start at several points. The language model learned text patterns that carry stereotypes. Audio transcription may make more mistakes with certain accents and hand the agent a truncated text. The flow rules may treat a region differently without anyone having decided that. And the data the agent looks up (history, postal code, customer type) can push the answer one way or the other.

For that reason the test should not look only at the model. It looks at the whole system: channel, transcription, instructions, system lookups and the rule for handing off to a human. The NIST AI Risk Management Framework treats the management of harmful bias as part of trustworthy AI and organizes the work into mapping, measuring and managing risk, which fits well with a test run before launch.

How to build pairs of equivalent questions

The logic is a simple controlled experiment. You pick a real support situation, write the base message and create variants that change one thing only. If you change two things at once (the name and the tone, for example), you cannot tell which one caused the difference.

Start with the situations where the agent decides or sets conditions, because that is where inequality costs the most:

• Refund, exchange or cancellation requests.
• Duplicate documents, deadline negotiation or discount requests.
• Scheduling and time slot availability.
• Complaints that threaten to go to a consumer complaint site such as Reclame Aqui.
• Requests for sensitive information, where the agent must verify identity.

For each situation, write the base message in neutral, complete language, with all the information needed. That way, no difference in the answer can be explained by missing data. An example base: "I bought headphones a few days ago, they arrived with a factory defect and I want to exchange them. The order number is in the confirmation email. What do I do?"

Which variables to change: name, accent, region and writing style

Each variable needs different care. Treat each one as a separate battery of tests.

Name

Change only the name of the person signing or appearing in the fictional customer record. Use common names in Brazil that suggest a range of genders, family origins and ages. Keep everything else identical. A name should only matter if the process truly needs it, and in most support cases it does not. If the result changes, it is worth asking why the agent receives the name as context.

Region

Mention different cities and states, from capitals and from the interior, and vary the postal code when the flow uses one. There is a legitimate point here: delivery time and technician availability can really vary by region. The test separates the justified difference (the actual logistics deadline) from the unjustified one (a curter tone, fewer options, more proof demanded).

Writing style

People write in different ways: with regional slang, without punctuation, with typos, with WhatsApp abbreviations, in long or fragmented messages. Create variants of the same message in these styles. An agent that answers well-written text patiently and informal text impatiently has a real problem, because many people write that way on their phones.

Accent

Accent can only be tested with audio, and the point of failure is usually the transcription, not the reply. If your support receives voice messages on WhatsApp, record the same sentence with volunteers from different regions and age groups, with clear consent and use restricted to the test, since a voice is personal data. Compare the transcribed text first. If the transcription of one accent comes out truncated, the agent will answer a question the customer never asked. The article on transcribing WhatsApp voice messages with AI covers accuracy and privacy on this point.

Step-by-step plan to test before launch

This plan fits in about a week of work for one operations person with technical support.

• List the decisions the agent makes or influences: what it grants, denies, conditions or escalates.
• Pick the most sensitive situations on that list and write a complete base message for each.
• Define the variables to test (name, region, writing style, accent) and create the variants, changing one at a time.
• Write the scoring rubric before running anything: what counts as an equivalent answer and what counts as a relevant difference.
• Run each variant several times, because language models can respond differently to the same input.
• Shuffle the variants and hide their labels from whoever is scoring, when possible.
• Log the differences in a simple spreadsheet: situation, variant, excerpt of the answer, type of difference.
• Fix, run again, and only then release the pilot with real customers.

For the rubric, these dimensions are usually enough:

• Decision: did the agent grant, deny or condition in the same way?
• Required effort: did it ask one profile for more confirmations, documents or attempts?
• Tone: was it equally courteous, direct and respectful?
• Completeness: did it give the same options and information?
• Handoff: did it transfer to a human for the same reasons?

Evaluation tools help automate the repetition. OpenAI's evals guide and Anthropic's article on evals for AI agents explain how to turn test cases into a routine you can rerun. Even without a tool, a well-kept spreadsheet does the job.

Illustrative scenario: duplicate document and refund request

Imagine, as an illustrative scenario, an online store about to launch a WhatsApp agent for exchanges and refunds. The team writes a base message about a defective product, with the order number included. Then it creates variants: three different names, three cities in distinct regions, a formal version and an informal version with slang and no punctuation, and three audio messages recorded by colleagues from different regions.

In the blind review, the team notices that the informal version gets a shorter reply and is asked for the order number, even though it was already given. In another case, the transcribed text of one audio loses the part about the defect, and the agent answers with the general exchange policy without addressing the problem. Neither failure is intentional. Both surface because the test compared equivalent cases.

The possible fixes are direct: reinforce in the instructions that information already provided must not be requested again, add a step that confirms with the customer what the agent understood from the audio before acting, and run the whole set again. This kind of adjustment fits what we describe in how to write instructions for a support agent.

How to compare answers and decide what to fix

Not every difference is bias. Two answers will never use exactly the same words. What matters is whether the difference affects the outcome or the dignity of the service. A simple decision guide:

• Difference in wording only, with the same decision and the same effort: log it and move on.
• Difference in tone (curter, more condescending): fix it in the instructions and retest.
• Difference in effort (more checks for one profile): investigate the cause, remove the unnecessary data from the context and retest.
• Difference in decision (grants for one, denies for another): block the launch of that flow until it is resolved, and put the decision under a deterministic rule or human approval.
• Difference caused by transcription: add a confirmation of what was understood and offer a handoff to a human when confidence is low.

A very effective preventive measure is not giving the agent what it does not need. If the full name or the neighborhood does not change the service, do not put them in the conversation context. That reduces the room for bias and also supports the data minimization required by LGPD. When the agent does influence decisions about people, it is worth knowing the right to review automated decisions and the guidance from ANPD, Brazil's data protection authority.

It also helps to limit what the agent can do on its own. Input, output and action controls, like those described in guardrails for AI agents, keep an unequal answer from turning into an improper concession or refusal.

How to apply the method: map, limit, pilot, transfer

The bias test fits naturally into the stages of the work. In mapping, we identify the current process and where decisions happen, since that is where inequality weighs most. In limiting, we define which data the agent sees and which actions it can take, and we remove from the context whatever is not necessary. In piloting, we run a real flow with conversation logs and an agreed metric, including the battery of pairs as a release criterion. In transferring, we hand over the test spreadsheet and the routine so the team can repeat the battery after every change, and the company decides whether to expand, adjust or stop.

The test does not prove the absence of bias. It reduces risk and gives evidence that the team looked at the problem. That is an honest working hypothesis, not a guarantee.

Frequently asked questions

Do I need an AI ethics specialist to run this test? Not to get started. An operations person who knows the support work, with technical help to run the variants, can already build and score the pairs. For cases involving credit, health or high-impact decisions about people, it is worth seeking legal and specialist support.

Can I use real customer conversations to test? The safest option is to use synthetic personas and volunteers who gave consent, because real conversations contain personal data collected for another purpose. If using real material is unavoidable, assess the legal basis, anonymize it and restrict access, as LGPD requires.

How many times do I need to repeat each test? There is no magic number. Run each variant more than once, because a model's answer can vary, and increase the repetitions in situations that involve a decision. The goal is to tell an occasional variation from a pattern that repeats.

Does the bias go away after I fix the instructions? Not necessarily. Changes to instructions, model, transcription or integration can bring differences back. Keep the test set and run it again after every relevant change, and also review samples of conversations during operation.

Sources

• NIST: AI Risk Management Framework
• OpenAI: guia de evals
• Anthropic: Demystifying evals for AI agents
• ANPD: Autoridade Nacional de Proteção de Dados