Conversation Guides
Three conversations, in order. Business lead first, IT second, vendor when the published documentation does not answer it.
Conversation 1 — The Business Lead
Goal: understand what the tool does and what the output drives.
Do not open with the regulatory question. Open with the work. The regulatory answer falls out of the description.
The Four Questions
1. What does this tool do for your team?
Let them explain it in their own terms.
2. How does it do that?
This is where the mechanism surfaces.
3. What data specifically does it access?
Business leads usually know this well. It is their business.
4. Does it perform any tasks without a person triggering it?
Expect a clear answer. Teams treat this as a feature.
Follow-Ups Worth Asking
| Question | Why |
|---|---|
| What happens after the tool produces its output? | Reveals whether it influences decisions |
| Who sees it, and what do they do next? | Same |
| Does anyone review before it affects someone? | Human oversight |
| Every time, or only some cases? | The distinction that matters |
| Who else in the organization uses this tool? | Catches parallel deployments |
| Who in IT supports you on this? | Sets up conversation 2 |
Listen For — Autonomy
These phrases mean the tool acts on its own:
- Runs automatically
- No manual intervention
- Processes overnight
- Handles it end to end
- Frees the team from
You are usually recognizing this rather than extracting it.
Listen For — Two Use Cases
The tell is the word "and." Two verbs, two outputs, two different things happening.
Examples:
- "It drafts the responses, and it also flags which accounts to prioritize"
- "It summarises the call, and then it scores the interaction"
- "It handles scheduling, and it screens the initial applications"
If you hear it:
- Say so plainly — most people find it obvious once pointed out
- Start a second worksheet
- Note both here before you forget the second one
Second use case identified: ________________________________
Before You Leave
- I can describe the use case in one sentence
- I know what the output drives
- I know who is affected
- I have the name of the IT contact
- I asked whether other teams use this tool
Conversation 2 — IT
Goal: find out what the tool is connected to and what it can reach.
Who to ask: the person the business lead named. Every team adopting a tool has one — either they recommended it or they are wiring it in.
The Questions
| Question | Answer |
|---|---|
| What is this connected to? | |
| What can it read that we have not discussed? | |
| Where is it hosted — which region? | |
| Does any data leave that region? | |
| Does it run on a schedule, or only on request? | |
| What integrations were configured? | |
| What security measures are in place? | |
| Who has administrative access? |
The One to Push On
"What can it read?"
The business lead describes what they put into the tool. That is often narrower than what the tool can reach.
Ask specifically about:
- Shared drives or document repositories
- Mailboxes
- Customer or member record systems
- Ticketing or case systems
- Calendars
- Anything else connected at setup
If the Answers Differ From Conversation 1
That is normal and worth recording.
Discrepancy noted: ________________________________
Resolved by: ________________________________
Do not assume either person is wrong. They are answering from different vantage points.
Conversation 3 — The Vendor
Goal: training, retention, logging, and sub-processors.
Only after you have checked published documentation and your own files.
Check First
- Vendor trust or security page
- Product documentation
- Admin console settings
- The contract and processing agreement
- Implementation or kick-off materials
- Security review from procurement
If it is there, you are done. Record where you found it.
If You Have to Ask
Frame the request in a category the vendor recognizes.
A third-party vendor due diligence request is something every vendor has handled many times. A request framed as unfamiliar gets deprioritized.
It is also accurate — this information genuinely serves those purposes.
Draft Email
Subject: Third-party vendor information request — [your organization]
Hello,
We are completing third-party vendor due diligence for [tool name], which we use for [brief description].
Could you confirm the following, or point me to where it is documented:
- Is customer data used to train or improve your models? If so, is opt-out available?
- How long are prompts, inputs, and outputs retained?
- Are prompts logged or stored, and for how long?
- Who are your sub-processors, and where are they located?
- In which region is our data processed and stored?
If there is a standard documentation pack that covers these, that would be ideal.
Thank you, [name]
On timing: every vendor is different. Some respond in days. Some need escalation through your account manager. Do not build a schedule around an assumption.
Record What You Get
| Question | Answer | Source |
|---|---|---|
| Model training on our data | ||
| Retention period | ||
| Prompt logging | ||
| Sub-processors | ||
| Processing region |
If the Answer Conflicts With the Contract
The contract takes precedence. What a support contact says does not override an executed agreement.
But a conflict is not just a tiebreaker. It is a signal to escalate.
If the vendor describes handling that differs from the agreement, your processing agreement or privacy notice may need updating. That is procurement's and legal's work.
Sequence:
- Conflict noted
- Handed to procurement
- Procurement clarified with the vendor
- Aligned answer received and recorded
Everyone then works from the same record.
The Discipline Across All Three
Derive but verify.
You will work some answers out from what people tell you. Form the hypothesis, then confirm it with the person or document that can settle it.
Never conclude you are right because your reading is reasonable. Reasonable and wrong look identical on the page.
Use and reuse
Free to use, share, and adapt within your organization. Attribution appreciated, not required. No warranty of any kind — this is practitioner guidance, not legal advice, and sufficiency is determined by your counsel.
LegisGate · Regulatory Intelligence for AI Deployments · legisgate.com
Written by compliance and audit practitioners who spent decades on the other side of the table.
Version 1.0 · Current as of August 2026 · Verify time-sensitive claims against current sources before relying on them.