Yes, if the consultant will see anything you'd mind leaking: customer data, pricing, supplier terms or system access. A short mutual NDA is cheap and sets expectations. But it only promises confidentiality; it doesn't make sharing personal data lawful or secure, so share the minimum, use redacted samples, and add data-processing terms where personal data is involved.
It depends on what you're sharing and when. A first conversation about how your business runs needs no NDA at all. Sending a spreadsheet of guest bookings does, and probably needs more than an NDA. The mistake small businesses make most is treating the signature as the protection, then sending everything. The best protection is data the consultant never receives. None of what follows is legal advice; for the wording of any agreement, speak to a solicitor.
What an NDA does, and what it doesn't
A non-disclosure agreement is a contract in which one or both sides promise to keep certain information confidential and use it only for an agreed purpose. A typical NDA for consultants covers:
- a definition of what counts as confidential information;
- the purpose the information may be used for, such as "assessing and delivering an AI automation project";
- who else may see it, usually only people who need it and are bound by the same terms;
- how long the obligations last;
- what happens at the end: return or deletion of the information;
- the usual exclusions, such as information that is already public or that the consultant already knew.
What an NDA doesn't do matters just as much:
- It doesn't stop a leak. It gives you a claim after the event, which is expensive to pursue and doesn't un-leak anything.
- It doesn't make sharing personal data lawful. Under data-protection law such as the GDPR, when someone processes personal data on your behalf you usually need specific data-processing terms with them, covering security, sub-processors, deletion and more. An NDA isn't a substitute. What to check in a data processing agreement explains those terms.
- It doesn't set security standards. Unless it says so, it doesn't require encryption, two-factor sign-in or anything else specific.
- It doesn't cover which AI tools the consultant uses. Unless you add a clause, nothing stops your data being pasted into a consumer chat app.
- It doesn't decide who owns the work. Ownership of workflows, prompts and documents belongs in the consulting contract. The clauses to check in an AI consulting contract covers those.
When to sign one: a decision table by what you're sharing
The need for an NDA, and for more than an NDA, follows the data rather than the stage of the project:
| What the consultant will see | NDA? | Also needed | Better approach |
|---|---|---|---|
| A description of how a job works, no data | No | Nothing | Talk freely; keep screens closed |
| Anonymised samples and field lists | Optional | Nothing, if properly anonymised | The default for scoping work |
| Pricing, margins, supplier terms, plans | Yes, mutual | Nothing else usually | Share summaries where they're enough |
| Customer or guest personal data | Yes | Data-processing terms | Minimise first; share only the fields needed |
| Login access to your systems | Yes | Data-processing terms if personal data is reachable; access controls | Their own account, lowest role that works, removed at the end |
| Health, allergy, financial or ID data | Yes | Data-processing terms and advice | Keep out of the project unless it truly can't work without it |
Two rules of thumb follow. If the consultant needs no personal data, the NDA is about your commercial secrets and can be short. If they need personal data, the NDA is the least important document in the pile.
Share samples, not the database
Most AI scoping work needs examples and structure, not your whole customer history. A consultant working out whether AI can draft enquiry replies needs to see what enquiries look like, what fields your booking system holds, and how many arrive each week. They almost never need names, emails or phone numbers. What an AI consultant needs from you lists the access and information a project typically requires.
An eight-room guest house shows how this works in practice; the figures are illustrative. Its owner is working with a consultant on automated replies, and the booking system export has 1,240 rows from the past two years. Before and after minimisation:
| Column in the export | Shared? | What was sent instead |
|---|---|---|
| Guest name, email, phone, home address | No | Removed |
| Booking reference | Replaced | B001, B002 and so on |
| Arrival date | Generalised | Month only |
| Nights, room type, booking channel | Yes | Unchanged |
| Price paid | Generalised | Price band |
| Dietary and access notes | No | Removed entirely |
| Payment status | No | Not needed for the job |
The owner also sent 40 real enquiry emails with names and contact details replaced by [first name] and [email], and a list of the booking system's fields. The consultant had everything needed to design the automation, and the guest house shared no identifiable guest data at all. Preparation took about 45 minutes, plus 20 minutes checking. That's the whole cost of not needing to worry.
Fake records for testing: synthetic data
Redaction works for showing a consultant what your data looks like. For building and testing an automation, there's often a better option: synthetic records that have the same shape as your real ones but describe nobody. A consultant can build and test an entire enquiry-to-booking workflow against 50 invented bookings, then connect it to live data only at the end, under a limited account.
You can ask a chat assistant to generate them from your field list rather than from your data:
Create 50 fictional guest-house bookings as a table with these
columns: ref, arrival_date, nights, room_type, guests, channel,
price, special_request. Use obviously fake names. Include awkward
cases: a booking with no arrival time, a same-day booking, a
two-room family booking, a cancellation, a request in capitals,
and two bookings that overlap in the same room.Check the result before anyone relies on it. In an illustrative run, every price came out as a round number and none of the special requests were longer than one line, which makes testing too easy. Asking for "prices like 187.50" and "some requests of three or four sentences" fixed both. Synthetic data won't contain the odd things real customers do, so the final check against a small sample of real records, under proper terms, still matters.
Redacting with AI, then checking its work
A chat assistant on a business plan can speed up redaction, but it misses things, so treat its output as a first pass. A prompt that works on emails:
Redact the emails below so no individual can be identified.
Replace: first names with [first name], surnames with [surname],
email addresses with [email], phone numbers with [phone], street
addresses with [address], booking references with [ref].
Keep everything else word for word, including dates, prices and
room types. After the emails, list every replacement you made,
with the email number, so I can check it.
[paste emails]In an illustrative run on 40 enquiries, three problems came up. A mobile number written with spaces inside a sentence ("call me on oh seven seven...") wasn't recognised as a phone number. A guest who signed off with a nickname kept it, because it didn't look like a name. And one email mentioned a child's medical condition in passing, which the prompt hadn't asked about and the model left in. The replacement list made the first two easy to spot. The third was caught only because the owner read every email before sending, which remains the step you can't skip. For bulk documents rather than emails, see redacting personal data from documents with AI, and for the principles behind it, anonymising client data before you paste it into AI.
Do the redaction on a plan whose terms you've checked. Business plans from the main AI vendors (ChatGPT Business and Enterprise, Claude Team and Enterprise, Microsoft 365 Copilot, Gemini in Workspace) don't train on your content by default; consumer plans rely on a model-training switch in the privacy settings.
The AI tools question: where your data goes next
This is the part most NDAs leave out. An AI consultant's work involves AI tools, so ask directly which ones will touch your data, on what plans, and under whose account. Useful facts to have in mind:
- Consumer chat plans let users switch off the use of their chats for training, but the switch is per account, and you can't see the consultant's settings.
- OpenAI says data sent through its API isn't used for training by default.
- Retention rules change. Since June 2026, Anthropic has kept prompts and outputs on its most capable models for 30 days even for customers who had zero-retention arrangements, and it added an application route back to zero retention in September 2026. Terms you checked last year may not be the terms today.
- If the consultant works inside their own team workspace, whoever administers that workspace can usually export its contents. On Claude Team, for instance, the Primary Owner can export organisation data, including members' chats.
The practical answers: prefer that the consultant works inside your accounts where possible (you control retention and can remove them at the end), and put the AI tools question into the agreement.
Five questions settle most of this in one conversation, and the answers tell you a lot about how a consultant works:
- "What's the least data you need to start?" A good answer names fields and samples, not "send me everything and I'll look".
- "Which AI tools will touch our data, on which plans?" Look for named tools on business terms, not "whatever works best".
- "Can you work inside our accounts?" Many can, and it keeps retention under your control.
- "Who else might see it?" Subcontractors, assistants or partners should be named, or ruled out.
- "How will you confirm deletion at the end?" A specific process beats a general promise.
Illustrative clause wording to adapt with your solicitor
The wording below is an illustration of the points worth covering, not a template to sign. Laws differ, and a solicitor should adapt it to your situation.
1. Purpose. The Consultant will use Confidential Information only
to assess, design and deliver the AI automation project described
in the proposal dated [date].
2. AI systems. The Consultant will not enter Confidential
Information into any AI system unless (a) the system is provided
under business or enterprise terms under which inputs are not
used to train models, and (b) the Client has approved that system
in writing. Approved systems: [list].
3. Minimum necessary. The Client will provide anonymised or sample
data where practicable. The Consultant will request identifiable
personal data only where the project cannot proceed without it,
and will state why.
4. Access. System access will be through named accounts created by
the Client, with the lowest permissions needed, removed on
completion. Credentials will not be shared.
5. Return and deletion. Within [14] days of the end of the
engagement, the Consultant will return or delete all Confidential
Information, including copies in email, cloud storage and AI
workspaces, and confirm this in writing.
6. Subcontractors. The Consultant will not share Confidential
Information with subcontractors without the Client's prior
written consent and equivalent written obligations.Clause 2 is the one that matters most for AI work and the one standard templates lack. Clause 3 turns data minimisation from a good intention into an agreed way of working. If the consultant will process personal data, the data-processing terms sit alongside all of this; they don't replace it.
A guest house, a letting agency and a tour operator compared
The guest house above needed only a short mutual NDA, because it shared commercial information (occupancy patterns and prices) and anonymised samples. When the project moved to connecting the live booking system, the consultant got a named account with a limited role, and data-processing terms were added because that account could reach guest records.
A letting agency is at the other end. Its systems hold tenant references, bank details and sometimes information about vulnerable tenants. A consultant scoping AI for maintenance requests should work from anonymised requests and a description of the system, not from live records. If they need access later, it should be to a test copy or a limited role, with data-processing terms signed first and a clear list of what they can see.
A tour operator sits in between. Its supplier contracts and margins are commercially sensitive, so an NDA makes sense early. It also holds medical and dietary information about guests on adventure tours. That information should simply stay out of an AI automation project about, say, itinerary emails, whatever NDA is in place.
A signed NDA isn't a licence to send everything
One way this goes wrong is easy to imagine. A boutique hotel owner signs a consultant's NDA and, keen to help, emails a full export of the guest database: names, emails, phone numbers, allergy notes and, from an old check-in process, some passport numbers. In a later meeting the consultant mentions having "run the list through ChatGPT to spot patterns". It turns out to have been a personal account. Nothing malicious happened, and the NDA was intact in spirit; the consultant kept the information confidential by their own lights. But guest data, including sensitive details, had gone into a consumer tool the hotel knew nothing about.
What the owner did next is the right sequence: asked the consultant, in writing, what was shared and where, and to delete it and confirm; recorded what had happened and when; and took advice from the hotel's data-protection adviser on whether anything needed reporting. The lesson wasn't that NDAs are useless. It was that the export should never have left the building in that form. Sharing only the fields the project needed, as the guest house did, would have made the whole episode impossible.
The guest house's pre-sharing checklist, filled in
Before anything left the building, the owner answered eight questions in a short note that went to the consultant with the NDA:
- What does the project need to see? Enquiry wording, booking fields, weekly volumes, channel mix.
- What personal data does that involve? None, once redacted.
- Redaction done and checked? Yes: 40 emails and the export, each read by the owner.
- NDA? Mutual, two pages, signed by both.
- Data-processing terms? Not yet; to be signed before the consultant gets any system access.
- Approved AI tools? The consultant's business-plan workspace only, named in the NDA.
- How will access work later? A named account with a front-desk role, removed at the end.
- Deletion date? 14 days after the project ends, confirmed in writing.
It took ten minutes to write and removed every awkward question from the later stages of the project.
If the consultant won't sign, or sends their own
Many consultants have a standard mutual NDA and will send it before you ask; that's a good sign. If they send theirs, read it for the points above, especially purpose, AI tools and deletion, and ask for additions rather than starting over. If they won't sign any confidentiality commitment at all but still ask for customer data, that's a reason to stop. If they refuse a one-sided agreement with heavy penalty clauses, that's reasonable, and a mutual version usually settles it.
Whichever way it goes, the sequence stays the same: decide what the project really needs to see, minimise and redact it, agree confidentiality and, where personal data is involved, data-processing terms, and only then send anything. The paperwork matters, but the data you never send is the only data that can't leak.
NDAs and AI consultants: follow-up questions
Should the NDA be mutual or one-way?
Mutual is usually fairer and easier to agree. You're sharing business data; the consultant may share methods, templates or pricing. A mutual NDA protects both with the same terms, and consultants are more likely to sign it without negotiation. One-way NDAs with large penalty clauses are the ones that stall conversations.
How long should confidentiality last?
Many NDAs set a fixed period, often a few years, for ordinary business information, with longer or indefinite protection for trade secrets and personal data. Pick a period that matches how long the information stays sensitive; your pricing from three years ago may not matter, but a guest's details always do. Your solicitor can advise on what's typical for your situation.
Does a free first call need an NDA?
Not usually, provided you keep it to descriptions and anonymised examples. Most consultants will talk about how your business runs without any paperwork. Save the NDA for the point where real data, pricing or system access changes hands, and don't send anything sensitive before it's signed.
Can I ask the consultant to delete my data at the end?
Yes, and you should. Ask for return or deletion of your data within a set number of days after the engagement ends, including copies in their email, cloud storage and any AI workspaces, and ask for written confirmation. Accept that some records, such as invoices, may have to be kept for legal reasons.
Further reads
- How to Classify Business Data Before Using AI Tools — Sort your data by sensitivity before anyone sees it.
- Is It Safe to Put Customer Data Into ChatGPT? — The customer-data question from your own side.
- How to Stop AI Tools Training on Your Business Data — The settings that keep your data out of model training.
- What to Check in an AI Tool's Privacy Policy and Terms — What to read in any AI tool's privacy terms.
- Shadow AI: How to Stop Staff Pasting Client Data Into Free Tools — The same risk inside your own team.
- Free AI Consultations: What You Get and How to Use Them Well — What to keep off a first, free call.
- AI Consultant or DIY: Which Suits a Small Professional Firm? — When a small professional firm can set up AI itself, when outside help earns its fee, and the split approach many firms settle on.
- Do Small Medical Practices Need an AI Consultant? — When a small medical practice can handle AI itself, the signs outside help will pay for itself, what a consultant shouldn't do, and a scoped brief to adapt.
- How to Choose an AI Consultant: 20 Questions to Ask First — Twenty questions to put to any AI consultant, what strong and weak answers sound like, and a scoring sheet filled in for a farm shop.
- How to Run a Paid Discovery Phase Before a Full AI Project — A stage-by-stage plan for a paid AI discovery phase, with a filled-in brief, a feasibility test on real emails and a go or no-go decision rule.
- How to Vet an AI Consultant's Case Studies and References — A grouped vetting checklist, a case study taken apart claim by claim, a reference-call script with sample notes, and a church office choosing a consultant.
- Who Owns the AI Workflows a Consultant Builds for You? — Legal ownership and practical control of AI automations: assignment vs licence, whose accounts they run in, platform transfer rules and sample clauses.
- AI Tools and AI Development: The Complete 2026 Guide — the AI hub, including every tutorial in the AI-for-business series.
Sources: OpenAI, Anthropic, Google and Microsoft business-plan data terms and privacy settings (checked September 2026); Anthropic data retention notices. This tutorial is general information, not legal advice.