Getting the Answers
Chapter 3 covered what the intake captures. This chapter covers how to get it.
Most of it comes from two conversations. Some of it comes from a vendor. A useful amount is already sitting in files your organization maintains.
This chapter covers:
- The conversation with the business lead
- Recognizing when one deployment is actually two
- The conversation with IT
- Getting information out of a vendor
- Keeping the controls answers honest
- Where the information lives
- What to do when it does not exist
Start With the Business Lead
They requested the tool, or their team uses it. They know what it does and why.
Ask the broad questions first
Do not open with the regulatory question. Open with the work.
The sequence:
- What does this tool do for your team?
- How does it do that?
- What data specifically does it access?
- Does it perform any tasks without a person triggering it?
The first three establish the picture. The fourth is the one people forget to ask.
Why that order works
You are not asking "does this make decisions about people." That question invites a defensive answer, or a confused one.
You are asking what the tool does. The regulatory answer falls out of the description.
Someone explaining that the tool ranks inbound applications so recruiters know who to call first has told you it influences decisions about people. They did not need to know that was the question.
They know their data
Business leads almost always know what data they work with. It is their business.
What they may not be able to tell you:
- What the tool is connected to
- What it can reach beyond what they described
- Where it runs
- Whether it operates on a schedule
That is not evasion. It is a different job.
Autonomy is usually volunteered
When you ask the fourth question, expect a clear answer more often than not.
Teams treat autonomous processing as a benefit. It is frequently the reason they wanted the tool, and it will appear in the justification written to get the purchase approved.
Phrases that mean yes:
- Runs automatically
- No manual intervention
- Processes overnight
- Handles it end to end
You are usually recognizing this rather than extracting it.
Recognizing Two Use Cases
This comes up constantly, and it is worth watching for.
A team will describe one tool deployment that contains two separate processes. They will not think of it as two things, because to them it is one tool doing their work.
What it sounds like:
- "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"
Each of those is two use cases wearing one description.
The tell is usually the word "and." Two verbs describing two different outputs, doing two different things to different people.
Why it matters
Chapter 3 covered the reason: different use, different obligation set. The first half of that sentence may carry very little. The second half may carry a great deal.
An analysis covering the first while your organization is running both leaves a gap nobody knows about.
What to do about it
Recognise it. Say so plainly to the business lead — most people find it obvious once it is pointed out.
How your organization handles the split from there is an internal decision. Some teams run separate intakes immediately. Others record both and sequence them.
That is a process question for your function, not a rule this manual can set for you.
Then Talk to IT
Every team adopting an AI tool has an IT person attached to it. Either they recommended it, or they are connecting it to your environment.
You do not have to find out who to ask. Ask the business lead who supports them.
What IT tells you
- What systems the tool connects to
- What it can access beyond what was described
- Where it is hosted
- Whether it runs on a schedule
- What integrations were configured
The gap this closes
The business lead describes what they put into the tool. IT tells you what the tool can reach.
Those are frequently different. A tool connected to a shared drive, a mailbox, or a customer record system sees considerably more than the person using it thinks about.
Ask specifically: what is this connected to, and what can it read?
Getting Answers From the Vendor
Training, retention, and logging usually come from the vendor. Sometimes it is published. Often it is not.
Look at what you already have first
Before contacting anyone:
- Training materials from implementation
- Kick-off call notes and decks
- The procurement file
- Security review documentation
- The contract and any processing agreement
A surprising amount is already in the building.
Then email the vendor contact directly
If it is not published and not in your files, ask.
Frame the request in a category they already recognize. Third-party vendor due diligence for a security certification is a request every vendor has handled many times. It is also accurate — that information genuinely serves those purposes.
A request framed as unfamiliar gets deprioritized. A request framed as routine gets answered.
On timing: every vendor is different. Some respond in days, some do not respond without escalation. Do not build a schedule around an assumption.
When the vendor answer conflicts with the contract
This happens, and it matters.
The contract takes precedence. What a support contact or salesperson says does not override an executed agreement.
But a conflict is not simply a tiebreaker to resolve. It is a signal to escalate.
Why: if the vendor is describing handling that differs from the agreement, your processing agreement or privacy notice may need updating. That is procurement's and legal's work, not yours.
The sequence:
- Note the conflict
- Hand it to procurement
- Let them clarify with the vendor
- Take the aligned answer back
Everyone then works from the same record. That is the point.
Keeping the Controls Answers Honest
The controls block asks what safeguards you already have. Signed agreements, transfer mechanisms, privacy notices, retention rules, training, named oversight.
This is where intakes go soft, because everyone wants the answer to be yes.
The follow-up question
Whatever answer you get, ask the same thing:
Show me how you can prove that.
Acceptable answers:
- A document
- A link
- A screenshot of a configured setting
- A named person who owns it
That is not an accusation. It is the next reasonable question, and it is exactly what a regulator or auditor will ask.
What "yes" often means
A policy document exists. That is not the same as the policy covering this deployment.
Check the scope, not just the existence:
- Does the retention schedule cover this tool
- Does the privacy notice describe this processing
- Does the processing agreement name this service
- Is the training completed by the people using it
A retention policy that does not mention this system is not a control for this system.
When you cannot substantiate it
Record it as unresolved.
Unresolved and documented is a defensible position. It shows you looked and you know where the gap is.
A yes you cannot support is not.
Where the Information Lives
When nobody knows an answer offhand, it is usually recorded somewhere.
The deployment
| What you need | Where to look |
|---|---|
| What the tool does for the team | Business lead; the approval request |
| Deployment status — pilot, live, inherited | Business lead; IT; change records |
| Model maker and AI type | Vendor documentation; IT |
| Connections and integrations | IT; the architecture record |
| Where it is hosted | IT; the vendor's documentation |
| Autonomous operation | The business justification; IT configuration |
The footprint
This is the one people skip, and it is where the surprises are.
| What you need | Where to look |
|---|---|
| Where employees are located | HR; payroll |
| Remote workers in other states or countries | HR; IT device and access records |
| Where customers or members are located | The customer record system; billing |
| Where applicants come from | The applicant tracking system |
| Where support requests originate | The ticketing system |
| Any European residents at all | All of the above — one is enough |
A single EU resident brings the General Data Protection Regulation into scope. So does one employee working remotely from another state, for that state's law.
The data
| What you need | Where to look |
|---|---|
| Data categories the tool sees | Business lead; IT |
| Whether it combines data from multiple sources | IT; the integration record |
| Roughly how many people are affected | Business lead; system user counts; HR |
| Whether vulnerable groups are in scope | Business lead; the population being served |
| Revenue and consumer-count thresholds | Finance; legal |
The vendor
| What you need | Where to look |
|---|---|
| Model training on your data | Vendor documentation; the contract |
| Retention of prompts, inputs, outputs | Vendor documentation; the contract |
| Whether prompts are logged | Vendor documentation; admin settings |
| Sub-processors | Vendor trust page; the processing agreement |
Your controls
| What you need | Where to look |
|---|---|
| Signed data processing agreement | Procurement; the contract file |
| Transfer safeguards | The processing agreement; legal |
| Privacy notice coverage | The published notice; privacy team |
| Legal grounds for sensitive data | Privacy team; legal |
| Retention rules | Records management; the retention schedule |
| Prior impact assessments | Privacy team; the governance record |
| Documented risk classification | Privacy or legal; the governance record |
| Named owner for oversight | The governance record; business lead |
| Escalation path | Incident response documentation; security |
| Staff training records | Learning system; the team's own records |
Start with your own files. Ask people second.
When It Does Not Exist Anywhere
This will happen, and it is worth being clear about what it means.
It usually does not mean the information is hard to find. It means nobody ever captured it.
- The approval recorded the business justification but not the data categories
- The vendor questionnaire asked about security but not about model training
- The contract was signed but never mapped to the actual deployment
Two things to do
First, record it as unresolved. Not as a no. There is a real difference between "the tool does not do this" and "we cannot currently establish whether it does."
An unknown that is documented can be closed later. An unknown recorded as a no disappears.
Second, fix it going forward. This is the more valuable half.
If a field is missing for this deployment, it will be missing for the next one. Add it to the process that should have captured it:
- Add the data categories to the AI request form
- Add training and retention questions to the vendor questionnaire
- Record hosting region on the asset record
- Capture the affected population at approval, not afterwards
That advice helps whether or not anything else changes. The next deployment arrives with the answers already attached.
Starting From an Existing Governance Record
If your organization already has an AI approval process, use it. Do not start from scratch.
What it usually gives you:
- Tool and vendor
- Requesting team and justification
- Technical architecture
- IT owner
What it usually misses:
- What the tool does to people's data
- Where the affected people live
- Vendor training and retention terms
- Whether staff have been trained
- Whether vulnerable populations are in scope
Most approval processes were built to route a decision, not to establish legal obligation. They capture the plumbing.
A rule on age. Under six months, treat it as a strong starting point that still needs verification. Older than that, re-baseline it. Deployments expand, vendor terms change, and use cases drift from what was approved.
The Discipline That Holds It Together
You will work some answers out rather than being told them directly. That is normal.
Derive but verify.
Form the hypothesis from what you have. Then confirm it with the person or the document that can settle it.
Never conclude you are right because your reading is reasonable. Reasonable and wrong looks identical on the page.
Chapter 5 covers what happens once the intake is accurate: determining what the deployment actually obligates you to do.
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.