The short version
Start with a redacted sample rather than production. Grant read-only, scoped, revocable access to the minimum needed. Get the training, retention and residency positions in writing. And treat a practitioner who volunteers narrower access than you offered as a strong signal — it is usually the clearest indicator of someone who has done this inside a regulated business.
General guidance on how these arrangements are usually structured, not legal advice.
Start with a sample, not production
Almost no discovery work needs live production access. What it needs is a representative sample: enough real records to measure the exception rate and test the awkward cases, with names, account numbers and anything personal removed or replaced.
This costs you an afternoon of extraction and removes most of the risk from the riskiest phase, which is the one before you have decided whether to work with this person at all. If a practitioner insists on production access to scope, ask precisely what they cannot determine from a sample. Sometimes there is a real answer. Often there is not.
Will our data be used to train a model?
Ask, and get it in writing, because the answer depends on which product is being used and under which agreement. Enterprise arrangements commonly include commitments that customer data is not used for training, and some support zero-retention configurations, but these are contractual positions rather than universal defaults — and they vary by model and deployment route.
Two things follow. The consultant should be able to tell you exactly which service and plan the work runs on, and what that plan’s position is. And the same question applies to their tooling, not just the model provider — the transcription service, the notes tool, whatever they paste things into. That is the leak people forget.
Where is the data processed, and for how long?
If you have data residency obligations, raise them before anything is connected, not after. Inference can often be pinned to a geography and retention periods can often be configured, but both are decisions someone has to make deliberately at setup.
Retention matters beyond compliance. Session transcripts and logs are exactly what you want when reconstructing a decision months later, and exactly what you do not want held indefinitely by a third party. The right answer is a defined period that satisfies both, written down.
What access should they actually get?
- Read-only, until there is a specific reason otherwise.
- Scoped to the systems in the brief, not a general account.
- Their own credentials, never a shared or generic login — otherwise the audit trail cannot attribute anything.
- Time-limited and revocable, with an actual expiry rather than an intention.
- Logged, so you can see what was accessed and when.
None of this is specific to AI. It is ordinary supplier access hygiene, and the reason it is worth restating is that these engagements often start informally — a screen share, a folder of exports, a login borrowed for an afternoon — and never get tightened afterwards.
What should the agreement cover?
Beyond a standard confidentiality clause: what they may access, what they may retain and for how long, whether anything may be used to improve their own tools or become a case study, what happens to copies at the end of the engagement, and their obligation to notify you if something goes wrong.
The case study clause is worth naming explicitly. Most practitioners want to write up the work, and most clients are willing if they are asked and the details are anonymised. Deciding that up front is far easier than negotiating it after delivery, when one party wants something the other never agreed to.
How do I judge whether they take this seriously?
Ask what access they need and see whether they argue it down. The people who have deployed inside banks and hospitals tend to propose narrower access than you offered, name a retention period without being pushed, and mention their own tooling unprompted.
The opposite tell is someone who wants broad access early “to move quickly”. Speed is a real benefit and it is not worth the cost of an incident. Anyone who has been through one already knows that, and it shows in how they answer.
What if we're in a regulated industry?
The controls are the same, the documentation burden is higher, and the sequencing changes: your compliance function is consulted before the engagement rather than shown it afterwards. Financial services, healthcare and legal practices all have supervisory expectations about outsourcing and third-party access that apply whether or not anyone has written an AI-specific rule yet.
Two practical consequences. Data residency stops being a preference and becomes a requirement, so confirm where inference runs before anything is connected. And you will need evidence rather than assurances — access logs, a defined retention period, a signed agreement — because “the consultant told us it was fine” is not a control.
Should we use our own environment or theirs?
Yours, wherever practical. A practitioner working inside your tenancy, with your credentials and your logging, keeps the data where your controls already apply and leaves an audit trail you own. It is slightly slower to set up and considerably easier to explain later.
Where that is genuinely impractical — a discovery phase on a redacted sample, say — be explicit about what leaves and for how long. The thing to avoid is the middle state nobody decided on: production extracts sitting in a consultant’s working folder because it was convenient during week two and nobody revisited it.
What should happen at the end of the engagement?
A defined offboarding, agreed at the start: credentials revoked on a named date, copies of data deleted with confirmation in writing, and handover of the prompts, configuration and evaluation sets you paid for. Then verify the revocation rather than assuming it.
This is the step most commonly skipped, because the project ends amicably and nobody wants to be officious. Six months later an access review finds a live credential belonging to a supplier who finished in the spring, and that is a finding regardless of whether anything happened.
Do we need a DPA as well as an NDA?
If personal data is involved, almost certainly — an NDA covers confidentiality between the two of you, while a data processing agreement covers the obligations that attach to personal data itself and is a requirement under GDPR-style regimes when a supplier processes it on your behalf.
Many engagements can avoid the question entirely at discovery stage by working on redacted samples with no personal data in them, which is another argument for starting there. If personal data becomes necessary later, that is the point to involve whoever handles data protection for you.