How can teams practise with AI without using live business data?

The most useful AI practice often resembles real work. That creates an immediate data question.

A claims file, customer email, code repository or research transcript may contain personal, confidential or commercially sensitive information. Moving it into an AI tool without approval can breach organisational boundaries. Replacing it with a generic paragraph, however, may remove the ambiguity and professional cues that the learner needs to practise.

The answer is to design representative material deliberately, using no more sensitive data than the learning task requires.

Realistic practice does not require copied live records

Learning material is realistic when it reproduces the important work, not when every detail comes from a real person or transaction.

Start by identifying the capability being practised. A learner evaluating an AI summary needs source material with relevant facts, omissions and contradictions. Someone framing a problem needs competing objectives and constraints. An underwriter forming questions needs information gaps and domain clues. None of those objectives necessarily requires a real customer record.

This is functional realism. It preserves the decisions, uncertainty, terminology and consequences that matter while removing identifiers and irrelevant sensitivity. Subject-matter experts are essential because they know which patterns make the task credible and which details merely decorate it.

Authored fictional cases are often the simplest option. They also allow the designer to create known reference points for feedback and include rare but important complications without exposing real information.

Choose from a hierarchy of safer materials

Use the least sensitive suitable source. Options include:

• wholly fictional cases written for the learning objective;
• public information that the organisation is permitted to reuse;
• blank or approved templates populated with invented content;
• composite cases that are genuinely reconstructed rather than lightly disguised copies;
• redacted material assessed for remaining confidential or identifying details;
• anonymised information whose re-identification risk has been evaluated;
• pseudonymised information, which may still be personal data; and
• synthetic data generated to reproduce selected structures or statistical properties.

These categories are not interchangeable. Removing a name may leave an address, unusual event or combination of attributes that identifies someone. Replacing a customer number with a code is pseudonymisation, not necessarily anonymisation.

The tool matters too. Material that is acceptable inside one approved enterprise environment may not be permitted in a public service with different input handling, retention or supplier terms.

Synthetic and anonymised data need careful claims

Synthetic data can help when teams need many records or representative relationships without sharing the original dataset. It can be especially useful for technical testing and data-oriented scenarios. It is not automatically anonymous, unbiased or fit for the learning purpose.

Generating synthetic data may require processing real personal information. Unusual records or patterns can sometimes create disclosure risk. Bias and gaps in the source can be reproduced, while privacy protection may reduce the utility of the result. Both privacy and usefulness therefore need evaluation.

Many workplace learning tasks do not need algorithmically generated data at all. A carefully authored set of fictional documents may provide better control over the teaching points. The right question is not “Can we make synthetic data?” but “What information properties must this practice preserve?”

Claims about anonymisation require appropriate data-protection expertise. Learning designers should not make that classification alone.

Keep practice and live validation separate

Practice materials should be labelled, stored and shared under clear rules. Learners need to know that the case is fictional or transformed, what they may put into the tool and whether outputs may be retained or discussed.

Performance on safe material creates learning evidence. It may show that people can frame a task, iterate, check output and notice limitations. It does not show that the same method will work across live variation or meet operational data requirements.

Moving to representative live data requires a separate purpose, approved environment and validation plan. The review should consider who will use the result, how it affects work, what errors matter and what human checks remain.

Safe material keeps practice possible when live data is inappropriate. Used honestly, it creates a bridge to professional capability without pretending to be production proof.

Example

An underwriting learning team writes fictional submissions that reproduce information gaps, inconsistent terminology and relevant risk clues without copying a real insured.

Participants use an approved assistant to organise the material and propose questions. They compare the output with a reference prepared by an experienced underwriter and discuss what the AI missed.

The task remains professionally recognisable while customer and commercially sensitive information stays outside the practice environment.

FAQs

• Is synthetic data automatically anonymous?

  No. The source data, generation method and potential for information to be inferred all matter. Privacy and data specialists should assess the result rather than relying on the synthetic label.

• Is redacting names enough to make business data safe for AI practice?

  Usually not by itself. Indirect identifiers, confidential facts, intellectual property and the combination of remaining details may still create risk. The approved tool and its data-handling terms also matter.

• When should practice move to live or representative operational data?

  Only through a separate approved purpose and environment. Define the evidence needed, users, controls, human review and stopping conditions for the intended operational context.