How to build AI evaluation datasets from support tickets without exposing personal data

Tools & Technical Tutorials

23 July 2026 | By Ashley Marshall

Your best AI evaluation data is probably sitting in Zendesk, Intercom, HubSpot or Freshdesk. The hard part is turning it into test cases without turning your customers into training material.

Start with the evaluation job, not the ticket archive

The mistake is to begin by exporting every ticket from Zendesk, Intercom, HubSpot Service Hub, Freshdesk or Jira Service Management. That feels thorough, but it creates a large personal data problem before you have a clear testing problem. AI evaluation datasets work best when they are small enough to understand and broad enough to catch real failure modes. Start by defining the job the AI assistant must perform: classify ticket intent, draft a first response, retrieve a policy answer, decide whether to escalate, spot a vulnerable customer, or check whether a proposed refund response follows policy.

OpenAI's evaluation guidance describes evals as structured tests for accuracy, performance and reliability, and recommends collecting datasets from a mix of production data, domain expert examples, historical logs and human feedback. Its support ticket example is deliberately simple: ticket text plus a correct label. That is the right mental model for support teams. You are not building a data lake. You are creating a set of representative test cases with expected outcomes and scoring criteria.

What this means in practice: write the schema before you export the tickets. For an intent classifier, you may need ticket_summary, channel, product_area, expected_label, escalation_required and reason_for_label. You probably do not need the customer's name, full email address, postal address, phone number, full order reference, IP address, attachment contents, free text signatures, internal staff names or payment details. For a response quality eval, you may need the customer problem, the relevant policy extract and a model answer scored by an expert reviewer. You still do not need the customer's identity.

The counterargument is that removing real details makes the test unrealistic. Sometimes that is true, but the answer is not to keep raw personal data. Preserve the shape of the problem with typed placeholders such as [ORDER_ID], [PLAN_NAME], [ERROR_CODE] and [DELIVERY_WINDOW]. If the exact value matters, generalise it. If it does not matter, remove it. The aim is to keep operational realism while stripping identity.

Anonymisation is a legal threshold, not a find and replace

UK teams often say they have anonymised tickets when they have only removed obvious names. The ICO guidance is clear that anonymous information is information which does not relate to an identified or identifiable person, either alone or when combined with other sources. It also says that if information does not meet the legal threshold for anonymisation, you must treat it as personal data. That is especially relevant to support tickets because they are full of narrative context, rare combinations and customer-specific facts.

A ticket can identify someone without containing a name. Consider this example: I am the only tenant at 14 Station Road whose broadband has failed since the hospital discharge on Tuesday. Removing the name and email address does little if the remaining sentence points to a single living individual. Dates, locations, job titles, order histories, complaint details, accessibility needs, medical references, small company names and unusual product combinations can all raise re-identification risk. The ICO also notes that anonymisation can be more complex where large datasets contain a wide range of personal data, and that specialist expertise may be needed.

What this means in practice: use a layered approach. First, run automated detection for direct identifiers and secrets. Tools worth considering include Microsoft Presidio, AWS Comprehend PII, Google Cloud Sensitive Data Protection, Private AI, Nightfall, Zendesk redaction, Intercom data controls, LangSmith gateway redaction for LLM requests, and DLP features in Microsoft Purview. Second, run deterministic rules for your own business identifiers, such as order numbers, account IDs, licence keys and internal case references. Third, manually review a risk-weighted sample, especially tickets involving complaints, finance, healthcare, employment issues, children, legal disputes or vulnerable customers.

A practical test is the motivated intruder question used in UK data protection practice: could a reasonably informed person re-identify the individual using available resources? UCL's 2025 data protection guidance, informed by the ICO's updated guidance, recommends considering rare attributes, geographical precision and other linkable data. In AI eval work, that review should happen before the dataset is uploaded to any model provider, annotation platform or observability tool.

Use pseudonymisation when you need repeatability, but do not pretend it removes GDPR

Many evaluation datasets need consistency. If the same customer appears in ten related tickets, you may need to preserve that relationship to test duplicate detection, escalation history or multi-step case handling. This is where pseudonymisation helps. Under Article 4(5) of the UK GDPR, pseudonymisation means processing personal data so it can no longer be attributed to a specific data subject without additional information, provided that the additional information is kept separately and protected by technical and organisational measures.

The important point is that pseudonymised data remains personal data for the organisation that can reconnect it to the person. The ICO says pseudonymisation starts with one input and ends with two outputs: the pseudonymised dataset and the additional information. Together, they can reconstruct the original personal data. That makes pseudonymisation useful, but it is not a compliance escape hatch. It reduces risk, supports data protection by design, and may help with compatible further processing assessments, but it does not make the UK GDPR disappear.

In practice, replace direct identifiers with stable tokens where stability adds evaluation value. Use CUSTOMER_1042 rather than the name, AGENT_A rather than the staff member, ORDER_8841 rather than the live order number, and COMPANY_SEGMENT_SMALL_SAAS rather than the customer's actual company. Keep the token map in a separate restricted store with a separate retention period, access control and audit log. Most AI evaluation teams do not need the token map after the dataset has been reviewed, so delete it unless there is a documented reason to keep it.

This also improves the engineering quality of the eval. Stable tokens let you test whether a model maintains entity consistency across a conversation without exposing the real entity. They let a reviewer spot whether the model confused CUSTOMER_A and CUSTOMER_B. They preserve the logic of the case while reducing the privacy cost. If you are using tools such as LangSmith, Humanloop, Braintrust, OpenAI datasets, Azure AI Foundry evaluations or custom pytest-based evals, treat the pseudonymised dataset as controlled production-derived data, not as harmless sample text.

Build the dataset like a QA asset, not a model training dump

A support-ticket eval dataset should look closer to a QA test suite than a CRM export. Each row should have an input, a target behaviour, a scoring method and provenance. For example, a refund-policy assistant might have fields for case_type, sanitised_customer_message, policy_context, gold_standard_answer, must_include, must_not_include, risk_flag, reviewer and source_ticket_month. The model does not need the raw ticket ID in the main dataset. If you need traceability during build, keep it in a restricted staging table, then drop it from the released eval file.

Good coverage matters more than volume. Start with 150 to 300 carefully selected cases if you are testing one workflow. Include common tickets, high-volume intents, edge cases, negative cases, policy traps, prompt-injection attempts, ambiguous customer language and tickets where the correct answer is to escalate rather than answer. OpenAI's guidance warns against biased eval datasets that fail to reproduce production traffic patterns, and it gives example targets such as context recall of at least 0.85, context precision above 0.7 and more than 70 percent positively rated answers for a Q and A over documents task. Those numbers are examples, not universal targets, but they show the point: define measurable success before you argue about which model is better.

What this means in practice: sample by risk and by volume. If password reset tickets are 30 percent of support volume, include enough of them to catch regressions. If vulnerable customer handling is 1 percent of volume but high impact, oversample it deliberately and label it as a protected risk category. Keep a holdout set that prompt engineers cannot tune against. Version the dataset in Git, DVC, LangSmith datasets, Braintrust datasets or a controlled object store, and record the redaction policy version used to create it.

The common misconception is that an evaluation dataset must contain the original ticket text to be valid. It does not. It must contain enough truth to reproduce the decision pressure the model will face. For most support AI systems, that means intent, policy context, constraints, tone requirement and expected outcome. Identity is usually noise, and risky noise at that.

Control where the data goes, including traces and review tools

The privacy risk does not end when the eval file is created. Evaluation workflows often copy data into more places than teams realise: prompt playgrounds, tracing systems, annotation queues, spreadsheets, Slack threads, CI logs, vendor dashboards and bug reports. The NCSC's guidelines for secure AI system development say organisations should apply access controls to APIs, models, data, training and processing pipelines across research, development and deployment, and should segregate environments that hold sensitive code or data. That applies directly to evaluation data built from support tickets.

NCSC also recommends releasing AI systems only after appropriate security evaluation such as benchmarking and red teaming, and being clear about known limitations or failure modes. For support AI, privacy-safe evals are part of that release discipline. You need tests that prove the assistant does not reveal hidden customer data, does not invent account facts, does not process secrets pasted into a ticket, and does not send a complaint into an automated dead end when a human review is required.

Tooling choices matter. LangSmith's PII and secrets redaction documentation says its gateway can scan outbound requests before they reach an LLM provider and redact sensitive data in traces, but it also states important limits: provider responses are not covered, traces written directly to the API bypassing the gateway are not scanned, and platform-level ingestion controls may be needed if sensitive data must never enter the system. That is a useful example of the kind of vendor review UK teams should do. Ask exactly which surfaces are redacted, whether scanners fail closed, where data is stored, whether data is used for training, how deletion works and whether audit logs are available.

In practice, create a simple data flow diagram for the eval lifecycle. Ticket system to staging table. Staging table to redaction pipeline. Redaction output to human review. Approved dataset to eval runner. Results to reporting dashboard. For each step, record location, owner, access group, retention period and deletion route. This does not need to become a 40-page document, but it should be concrete enough that your DPO, CTO and support lead can all understand it.

Make the governance lightweight enough that teams will actually use it

The answer is not to turn every support AI improvement into a legal committee. The answer is to create a repeatable dataset build process with clear checkpoints. A sensible workflow has seven stages: purpose statement, field minimisation, automated redaction, pseudonymisation where needed, human risk review, dataset approval, and scheduled re-review. Each stage should leave an artefact: a schema, a redaction report, a sample review record, a dataset version, or an approval note.

For UK organisations, the governance question usually comes down to four tests. First, what is the lawful basis and is the new evaluation purpose compatible with the original support purpose? Second, have you met data minimisation by removing fields not needed for the test? Third, have you assessed whether the output is truly anonymised or merely pseudonymised? Fourth, can you honour customer rights, retention rules and deletion commitments if the dataset still contains personal data? If special category data appears in support tickets, such as health information or union membership, treat those rows as exceptional and either exclude them or put them through a stricter documented route.

Use a small RACI so people know their job. Support operations owns case representativeness. Engineering owns the pipeline and access controls. The DPO or privacy lead owns the data protection assessment. Product owns the success criteria. Subject matter experts own labels and expected answers. Nobody should be able to quietly paste a fresh batch of raw tickets into a model console because the eval set felt stale.

The practical cadence is simple. Refresh the dataset monthly or after a major product, policy or model change. Add new failure cases from production incidents, but sanitise and review them before inclusion. Retire cases that no longer reflect the service. Keep a separate regression set for failures you never want to see again, such as giving legal advice, exposing internal notes, mishandling a vulnerable customer, or promising a refund outside policy. The best governance is not theatre. It is a workflow that makes the right thing easier than the shortcut.

Frequently Asked Questions

Can we use real support tickets for AI evaluation under UK GDPR?

Yes, but you need a clear purpose, lawful basis, minimisation, appropriate safeguards and documentation. If the tickets remain personal data after redaction or pseudonymisation, UK GDPR still applies.

Is removing names and email addresses enough to anonymise support tickets?

Usually not. Tickets can identify people through locations, dates, job details, order histories, rare circumstances or combinations of facts. You need to assess whether re-identification is reasonably likely.

What is the difference between redaction and pseudonymisation?

Redaction removes or masks content. Pseudonymisation replaces identifiers with separate tokens or keys so relationships can be preserved. Pseudonymised data is still personal data for the organisation that can reconnect it.

Should evaluation datasets be fully anonymised or pseudonymised?

Use anonymisation where the identity and relationships are not needed. Use pseudonymisation where repeatability or entity consistency matters, but keep the key separate and protect the dataset as personal data.

How many support tickets do we need for a useful first eval dataset?

For one narrow workflow, 150 to 300 carefully selected cases can be enough to start. Coverage is more important than raw volume, especially for high-risk cases and known failure modes.

Can we upload redacted tickets to an AI vendor evaluation tool?

Possibly, but only after checking the vendor's data use, storage region, retention, deletion, trace logging, subprocessors, training policy and redaction coverage. Gateway redaction alone may not cover every ingestion path.

Do we need a DPIA for this work?

A DPIA is likely if the evaluation involves high-risk processing, sensitive data, systematic monitoring or vulnerable people. Even where a full DPIA is not required, a short documented risk assessment is sensible.

What should we do with tickets containing special category data?

Exclude them by default unless they are essential to a specific risk test. If included, use stricter review, stronger access controls, a clear lawful basis and explicit documentation of why the case is necessary.