What data is going into your AI tools?

Why the data going into AI tools needs visible governance

When staff use public AI tools, Copilot-style assistants, embedded AI features or specialist workflow platforms, the most important question is often simple: what data is actually going in?

For owner-led firms, professional services teams and regulated businesses, the answer affects confidentiality, data protection, vendor risk, audit evidence and client trust. The tool may look like a writing assistant, but the input can include client names, contract clauses, deal details, customer complaints, claims notes, board papers, financial data or internal operating procedures.

The practical starting point is not a long policy document. It is a clear view of data categories, where each category may be used, who can approve exceptions and how outputs are checked.

The safest approach is to classify inputs before teams use AI

The safest approach is to classify input data before teams use AI tools. Treat each AI use case as a small data-flow decision: what goes in, where it is processed, whether it may be retained, who reviews the output and what evidence is kept.

As a baseline, most firms should separate AI input data into four groups:

• Open information: public web copy, published policies, generic examples and non-confidential templates.
• Internal information: process notes, meeting summaries, draft plans and operational data that should not leave approved systems.
• Client or customer information: documents, names, facts, case details, financial records, claims data or support history.
• Restricted information: special category data, privileged legal material, credentials, security details, M&A plans, disciplinary records and anything covered by strict contractual controls.

Open information may be suitable for low-risk drafting. Internal information may be acceptable only in approved tools with the right settings. Client and restricted information should require stronger controls, redaction or a clear business-approved exception.

Map your AI data risks before they become client issues

What to record in an AI input-data register

A lightweight input-data register gives leaders a practical control without slowing every task. It should show which teams are using AI, what data they put into tools and which guardrails apply.

For each AI use case, record:

• the business task, such as drafting, research, analysis, triage, coding, summarisation or client service support;
• the tool or vendor, including whether it is public, enterprise-managed or embedded in another platform;
• the input data categories used;
• whether personal data, client confidential data, financial data or privileged material is involved;
• the retention and training settings you rely on;
• the accountable owner;
• the required human review step;
• the evidence kept for audit or management review.

This does not need to be complex. A spreadsheet, workflow register or governance tool can work if it is maintained and reviewed. The key is that leaders can answer the question without asking every employee to reconstruct their behaviour from memory.

How professional firms should handle client and regulated data

Legal, financial services, insurance and accountancy firms need tighter rules because AI input data can touch professional duties as well as operational risk.

For legal work, the control should consider confidentiality, privilege, client consent and whether the tool environment is approved for matter-related information. For financial services, leaders should connect AI use to Consumer Duty, SM&CR accountability, model or vendor governance and the ability to evidence reasonable review. For insurance, claims and underwriting teams need care around personal data, fairness, explainability and complaint handling.

A practical rule is useful: if the input would make a client, regulator or board uncomfortable if copied into an unmanaged third-party tool, it needs a managed route or should not be entered.

Put recurring AI governance checks on a sensible cadence

Data controls that work in day-to-day teams

Good AI governance should make safe behaviour easier than unsafe behaviour. The controls below are usually more effective than a policy that people read once and forget.

• Approved-tool list: name the tools staff may use and the data categories allowed in each one.
• Redaction rules: give examples of what must be removed before prompting, including names, IDs, account numbers and privileged detail.
• Prompt examples: show safe prompts for common tasks, not only banned prompts.
• Access controls: limit sensitive AI workflows to trained roles and enterprise-managed accounts.
• Output review: require human checks for accuracy, bias, confidentiality and client suitability.
• Exception route: provide a named approval path when a team has a legitimate reason to use higher-risk data.
• Audit trail: keep enough evidence to explain what was done, by whom and under which control.

These controls should be owned by the business, not buried in IT. IT can help enforce approved systems, but the business owner decides whether a data use is appropriate for the task and risk.

Common mistakes when firms ask staff to use AI

The most common mistake is assuming the tool category tells you the risk. It does not. The same AI assistant can be low risk when used to summarise public information and high risk when used with client documents, complaint histories or board papers.

Other mistakes include:

• approving a tool without checking retention, training and admin settings;
• letting teams paste client data into free accounts because the paid tool rollout is slow;
• focusing only on prompt quality while ignoring input-data sensitivity;
• forgetting that embedded AI features in existing software can create new data flows;
• failing to document who reviewed and accepted the output.

The fix is to connect AI enthusiasm to a small operating model: approved tools, data categories, review steps and evidence. That gives teams permission to use AI where it helps, while protecting the data that should never be treated casually.

Conclusion: answer the data question before the model question

Before choosing a model, buying another AI tool or writing a wider policy, answer the data question. What is going in, who controls it, where does it go, what settings apply and who checks the result?

If those answers are unclear, the firm does not yet have a reliable AI operating model. If they are clear, AI adoption becomes easier to govern because teams know which data is safe, which data needs controls and which data is out of bounds.

Turn AI policy into practical workflow controls