Vetting a new AI tool before your team starts using it

Why this matters to you

Your 2-minute quick win

Send one message in your team chat now: ‘Before using any new AI tool for work, please do not paste in customer, employee, contract, or internal project data until we confirm the tool’s purpose, data use, and supplier role under GDPR.’ You are done when the message is posted in the main team channel and pinned, or copied into the team’s onboarding notes.

AI tools spread fast because they solve small problems in seconds. A draft appears faster. A summary arrives sooner. A translation looks good enough. That speed is useful, but it also hides a basic risk. People start using the tool before anyone checks where the data goes, why the provider needs it, or whether the business can explain that use under GDPR.

The CNIL is clear on the starting point. If personal data is involved, you need a defined purpose, known roles, and a legal basis before the processing starts. That matters even more with AI because teams often treat prompts, uploads, and chat histories like casual notes, when they may contain real information about customers, staff, or suppliers.

This is also a shadow AI problem. A team may not think they are buying software. They may just open a browser tab and start copying work into a chatbot. Yet that simple act can create a new flow of personal data outside the normal tool approval path.

OWASP also warns that generative AI systems bring security and safety risks. For a small or mid-sized business, the lesson is simple. Do not treat a new AI tool like a harmless writing aid. Treat it like a new data processor until proved otherwise.

Why teams miss the risk

Most AI adoption starts with a useful task, not a formal project. Someone wants meeting notes cleaned up. Someone wants a customer email shortened. Someone wants help writing code or classifying images. The first upload feels minor, so no one stops to ask what training, storage, or reuse may happen behind the screen.

The CNIL warns against purposes that are too vague, such as simply saying an organisation is developing or improving an AI system. A business user should take the same lesson into procurement. If a vendor cannot explain the tool type, the expected uses, and the excluded uses in plain words, your team is being asked to trust a black box with live business data.

What you are protecting

You are protecting personal data first. The CNIL describes personal data as information about real people. In a business setting, that includes customer names, email threads, CVs, support tickets, meeting transcripts, complaint details, HR notes, and photos with identifiable people in them.

You are also protecting the context around that data. A prompt can reveal more than the raw text inside it. It can show which client has a dispute, which employee is under review, which prospect is negotiating price, or which product issue has not been announced yet.

You are protecting business confidentiality too. Even when a prompt contains no direct personal data, it may still contain pricing, internal plans, source code, contract wording, or incident notes. Those details can expose strategy, negotiation position, or weak controls.

You are protecting trust. Customers expect their data to be used in ways that fit the service they received. The CNIL says the use of data should not surprise people and should fit their reasonable expectations. If your team drops client material into a new AI tool without checks, surprise is exactly what you create.

You are protecting decision quality as well. OWASP frames generative AI as a source of security and safety risk. That includes the risk that staff rely on output from a tool they do not understand. If the tool is wrong, overconfident, or fed poor inputs, bad output can travel quickly into customer messages, reports, or internal decisions.

The four things to name before any trial

• The purpose: one short sentence that says what the tool will do for your team, such as drafting generic marketing copy or summarising internal process notes.
• The data: the exact categories staff might enter, such as anonymised notes, public website text, or employee records.
• The supplier role: whether the provider acts on your instructions like a processor, or sets the why and how of data use more independently.
• The stop line: the kinds of data no one may enter until further approval, such as special category data, full customer files, or unredacted contracts.

What it costs you if you skip this

The first cost is uncontrolled personal-data processing. The CNIL says data use needs a clear purpose and a legal basis. If your team starts with live data and asks questions later, you may be unable to explain why that processing was necessary or proportionate.

The second cost is role confusion. The CNIL distinguishes between a controller, joint controllers, and a processor. If you do not know which role the provider plays, you cannot set the right contract terms, instructions, or oversight. That weakens both compliance and accountability.

The third cost is over-collection. A team in a hurry will paste in full documents when a short extract would do. The CNIL links necessity to data minimisation. If the task can be done with less data, the full upload was not the safest choice.

The fourth cost is a mismatch with people’s expectations. The CNIL says the use of data should not surprise people. A customer who gave details for support, billing, or delivery may not expect those details to be reused in a new AI tool for wider service improvement.

The fifth cost is exposure to AI-specific failures. OWASP highlights critical security vulnerabilities in LLM applications and broader generative AI systems. Even if your team only uses a front-end chat tool, you still inherit some of that risk. A weak AI workflow can spread sensitive information, produce flawed output, or support poor decisions at speed.

The sixth cost is messy rollback. Once a team has built daily habits around one AI tool, it becomes harder to remove it. Prompts may be scattered across browser history, exports, shared notes, or copied outputs in downstream systems. A five-minute experiment can become a months-long clean-up problem.

Step by step

1. Open a one-page intake note in your usual shared document tool and add the heading ‘AI tool purpose’. Write one sentence that names the tool type and the exact business use, not just ‘AI support’. Done correctly, a colleague can read the first line and understand the task without asking follow-up questions.

2. Add a section called ‘Allowed inputs’ and list the exact data categories staff may enter during the trial. Use plain labels like public website text, anonymised meeting notes, or synthetic examples. Done correctly, the list is short and does not include broad phrases such as ‘business data’ or ‘normal work content’.

3. Add a second section called ‘Blocked inputs’ and name what must stay out of the tool. Put customer files, employee records, complaint details, contract drafts, and any data that identifies a person on that blocked list unless you later approve them. Done correctly, staff can glance at the note and know what not to paste.

4. Ask the supplier one direct question by email or in the sales chat: ‘For data we enter into your AI tool, do you act only on our instructions, or do you also decide the purpose and means of that processing?’ Done correctly, you get a clear answer that helps you map controller, joint controller, or processor roles in the CNIL sense.

5. Ask for the contract terms that cover personal-data processing. If the vendor says it is a processor, ask for the data-processing agreement. Done correctly, you receive a document that states the provider processes data on your instructions, not a vague sales promise.

6. Create a section called ‘Legal basis’ and write the reason your organisation believes the trial is lawful. The CNIL lists six possible GDPR legal bases, including consent, contract, legal obligation, public interest, vital interests, and legitimate interest. Done correctly, the note names one basis and does not leave the box blank.

7. If you choose legitimate interest, add three short lines under it. State the legitimate interest, why the data is necessary, and why the impact on people is not disproportionate. Done correctly, each line is specific to this tool and this use, not copied from another project.

8. Check whether the task can be done with less intrusive data. Replace live names with placeholders, trim documents to the needed paragraph, and remove attachments that add no value. Done correctly, the input still lets the tool perform the task while exposing less about real people.

9. Add a section called ‘Reasonable expectations’. Write who the data relates to and whether they would expect this use. The CNIL says data use should not surprise people. Done correctly, the sentence mentions the original context, such as support, recruitment, or account management.

10. Add a section called ‘Risk limits’ and note the safeguards you will use during the trial. The CNIL gives examples such as anonymisation at short notice, pseudonymisation, limiting retention, and enabling rights like opposition or erasure where relevant. Done correctly, the safeguards match the actual data and trial scope.

11. Run a tiny pilot with one or two named users and one safe task from the allowed-inputs list. Use only low-risk sample material first. Done correctly, the output is useful enough to judge the tool without anyone needing to upload a full live customer case.

12. Write a final go or no-go line at the top of the note. Use one of three labels: ‘Approved for listed inputs only’, ‘Approved after contract fix’, or ‘Not approved for work use’. Done correctly, any employee opening the note can see the decision in three seconds.

What to ask when the supplier is vague

If a supplier talks only about innovation, ask them to restate the tool’s purpose in one sentence. If they cannot say what the system is for, the purpose is still too broad.

If a supplier says everyone uses the tool this way, ask what data categories their business terms actually cover. Market popularity is not your legal basis.

If a supplier avoids role language, ask whether they process data solely on your instructions. If they say they also decide reuse, improvement, or wider product aims, you may not be looking at a simple processor relationship.

Illustrative example

Emma runs operations for a French services firm with forty staff. One account manager wants a new AI chatbot to summarise customer call notes and draft follow-up emails. The tool looks easy to use. It opens in a browser and offers a free trial.

Emma does not ban it on sight. Instead, she follows a short vetting flow. She opens a shared document and writes the purpose: summarise internal call notes into action lists and draft general follow-up emails. She then fills in the allowed-inputs section with anonymised notes, public product text, and fake examples. In blocked inputs, she writes customer names, direct contact details, complaint histories, contract terms, and anything copied from the CRM.

Next, Emma asks the supplier whether it acts only on the company’s instructions or also decides the purpose and means of processing. She also asks for the data-processing agreement if the supplier presents itself as a processor. While waiting, she writes the likely legal basis in the note and records why the task should use the least data possible.

Emma then tests the workflow with one team lead. They take two old call notes and replace each customer name with ‘Client A’ and ‘Client B’. They remove direct contact details and trim the notes to the points needed for a summary. The tool returns a clean action list and a draft email that is good enough to edit.

When the supplier replies, Emma sees that the role language is not fully clear, so she marks the note ‘Approved after contract fix’. She keeps the team on anonymised examples only. After a second exchange, the provider sends clearer processing terms. Emma updates the note to ‘Approved for listed inputs only’ and posts the link in the operations channel. Staff now know the tool may help with draft structure, but not with raw CRM exports or complaint files.

The outcome is not dramatic, and that is the point. The business gets a useful AI assistant for a narrow task. The team keeps personal data out until the purpose, role, and data limits are clear. Emma does not need a huge policy pack. She just creates a visible boundary before habits form.

The near-miss

Now replay Emma’s week with one skipped check. This time, she lets the account manager test the tool immediately because the trial is free and the deadline is close. The user copies a full call note from the CRM, including a customer name, mobile number, complaint summary, and discount discussion. The tool produces a strong draft, so the team likes it.

Only later does Emma ask how the vendor handles data and what role it plays. She still has no simple answer on whether the provider acts only on instructions. She also realises the team cannot explain why a full live record was necessary when a short anonymised extract would have done. Nothing visibly breaks on screen, but the company has already created a new data flow it did not define in advance. The near-miss is not a loud breach. It is quiet, normalised misuse.

How to check it worked

Your vetting worked if any employee can open one document and see four things at once: the tool’s purpose, the allowed inputs, the blocked inputs, and the current decision label. If those details live only in someone’s head, the process did not really happen.

Your vetting worked if the first successful trial used low-risk or anonymised material. That shows the team proved usefulness before exposing real people’s data.

Your vetting worked if the legal basis is written down. The CNIL stresses choosing the legal basis in advance because rights and obligations vary with that choice.

Your vetting worked if the supplier’s role is no longer vague. You may still need legal or procurement help for a final contract, but the business side should at least know whether the vendor claims to act on your instructions or not.

Your vetting worked if the team can explain why the data used is necessary and limited. If users still upload whole files by default, minimisation is not in place yet.

Your vetting worked if staff know the stop line. Ask one random user what they must never paste into the tool. If they hesitate, your blocked-inputs list is not visible enough.

Test yourself

Question: What is the first thing to define before testing a new AI tool with work data?

Answer: A clear purpose that says what the tool will do for the business.

Question: Why is a short blocked-inputs list useful?

Answer: It gives staff an immediate stop line so they do not paste personal or confidential data into the tool by habit.

Question: What makes a small AI trial safer at the start?

Answer: Using anonymised or low-risk sample material first, then expanding only if the purpose, role, and terms are clear.

Common mistakes

Calling the purpose ‘AI productivity’

The CNIL warns against purposes that are too general. ‘AI productivity’ says almost nothing. A usable purpose names the task, such as summarising internal notes or drafting generic copy.

Letting the free trial set the rules

A free or easy sign-up does not reduce the data risk. It often increases it because staff begin before procurement, legal, or security sees the tool.

Using live data to prove value too early

Teams often believe the tool must see a full real document to be tested fairly. In many cases, a trimmed or anonymised sample proves the workflow just as well.

Ignoring reasonable expectations

The CNIL says people should not be surprised by how their data is used. If the original context was support or recruitment, reusing that material in a new AI workflow may need extra thought and stronger limits.

Not writing down the vendor role

If no one knows whether the provider acts on your instructions, contract work becomes guesswork. That is risky even before any formal audit starts.

Assuming AI output quality is the only question

OWASP’s framing is broader than output quality alone. Security and safety risks also matter. A helpful answer from the model does not prove the surrounding data handling is acceptable.

Level up

Create one standard ‘AI tool intake’ page in your shared workspace and require every new tool to use the same seven fields: purpose, allowed inputs, blocked inputs, supplier role, legal basis, risk limits, and final decision. This turns ad hoc shadow AI into a visible list your managers can scan in minutes, and it gives your team one repeatable gate before any live data is pasted.