What You Are Actually Capturing
Chapter 2 ended on the intake. This chapter covers what goes into it.
Start with the part most organizations get wrong, because getting it wrong makes everything after it wrong too.
This chapter covers:
- Why tools are not the unit of analysis
- What changes an obligation set
- What the intake actually captures
- Who in your organization holds each answer
Tools Are Not the Unit
The instinct is to build a tool inventory. Twenty tools, twenty rows, twenty analyses.
That instinct is wrong, and it will produce an incomplete picture.
Obligations do not attach to software. They attach to what the software does, to whom, and where.
The unit is the deployment
A deployment is three things together:
| Element | Question it answers |
|---|---|
| The tool | What is running |
| The use case | What your team does with it |
| The jurisdiction | Where the affected people live |
Change any one of the three and you have a different deployment.
Different deployment, different obligation set.
One tool, three use cases
Take a general-purpose AI assistant. Same vendor, same license, same product.
| Use case | What changes |
|---|---|
| Drafting internal communications | No decisions about people |
| Scoring sales leads for follow-up | Now it ranks individuals |
| Screening job applicants | Now employment law attaches |
Three uses of one tool. Three different pictures.
The first may carry very little. The third carries employment law, discrimination exposure, and in several jurisdictions a specific assessment duty.
Counting that as "one tool" hides two of the three.
One use case, three jurisdictions
Now hold the use case still and move the people.
The same applicant-screening deployment reaches:
- Applicants in Illinois
- Applicants in New York City
- Applicants in Germany
Same tool. Same use. Three different obligation sets, because the law follows the people, not your office.
The arithmetic
This is why a tool count understates the work.
- 20 tools does not mean 20 analyses
- Some tools have one use case
- Others have four or five
- Each use case may reach several jurisdictions
You cannot scope this from a software inventory. You scope it from a deployment inventory, and the second is always larger than the first.
What this means for the intake
One intake per deployment. Not per tool.
If a business lead describes three distinct things their team does with one tool, that is three intakes.
That feels like more work at the start. It is considerably less work than discovering later that your analysis covered one use and your organization is running three.
What Changes an Obligation Set
Beyond the three core elements, a handful of facts move the answer more than anything else.
These are the questions to get right:
- What data does the tool actually see
- Does it make or influence decisions about people
- Who are those people — employees, customers, patients
- Are any of them in a vulnerable group
- What industry are you in
- How does the vendor handle your data
Each of these can change the obligation set on its own. Several of them change it substantially.
Two examples of how much turns on a single answer:
- Biometric data in Illinois carries a private right of action
- Employment context changes which state privacy laws reach the deployment
You do not need to know which law each answer triggers. You need to capture each answer accurately.
Start Wide, Then Narrow
Before the categories, one thing worth knowing: you will not have every answer on every deployment, and you do not need them to start.
A small number of answers determine whether the analysis is right at all. The rest determine how precise it is.
The seven that matter most
| Answer | Why it is load-bearing |
|---|---|
| The tool | Identifies what is being assessed |
| The use case | Different uses carry different obligations |
| Where the affected people are | Determines which laws reach you at all |
| Your industry | Determines which sector rules layer on |
| What data it sees | Drives most obligation triggers |
| Who it affects — employees or the public | Changes which laws apply entirely |
| Whether it decides about people | Separates routine processing from consequential |
Get these wrong and the analysis is wrong. Get these right and you have something usable, even if the rest is incomplete.
Everything else narrows
The remaining fields rarely change whether an obligation exists. They change how confidently you can rule things in or out.
Without them, the picture stays wide. More frameworks remain possible. More items sit unresolved.
With them, the picture narrows. Frameworks get excluded with a documented reason. Obligations move from "may apply" to "applies" or "does not apply."
What this means practically
A wider result is not a wrong result. It is a less precise one, and it is honest about being less precise.
The failure is not missing information. The failure is guessing to fill the gap, which produces a narrow answer built on nothing.
So:
- Capture the seven properly
- Add what else you can
- Mark the rest unresolved
- Refine as answers arrive
A deployment assessed with seven solid answers and six unresolved is in a defensible position. One assessed with thirteen answers where six were invented is not — and nothing about the second one looks worse on the page.
What the Intake Captures
Six categories. Each one exists because it changes the legal picture.
1. The tool
- Product or service name
- Vendor
- Who built the underlying model, if known
- Where it runs
The last two are useful, not essential. If nobody knows, that is a fine answer.
2. The use case
The single most important field.
Describe what your team does with it, what data goes in, and what the output drives.
Be concrete. "We use it for HR" is not a use case. "It screens inbound applications and ranks them for recruiter review" is.
One use per intake. If the description contains "and also," you probably have two.
3. The footprint
Where the affected people live.
Not where your office is. Not where the vendor is hosted. Where the people whose data the tool sees actually are.
This is where surprises show up. Two in particular:
- Customers in states you had not considered
- Any European resident bringing GDPR into scope
A single EU resident is enough. So is one employee working remotely from another state.
4. The data
What the tool sees or uses.
Categories that matter most:
- Personal identifiers
- Health information
- Biometric data used to identify someone
- Financial and employment records
- Behavioral signals
- Precise location
Also: whether the tool combines data from multiple sources. Matching separate data sets together raises the risk profile in several frameworks.
5. The people and the decisions
- Who the tool interacts with or decides about
- Whether it makes or influences decisions about individuals
- Whether it scores, ranks, predicts, or segments people
- Whether it acts without being triggered by a person
- Whether any affected group is in a vulnerable category
On that fourth point. Autonomous processing is usually easy to find, because teams treat it as a feature.
It is often the reason they wanted the tool. "It handles this without anyone touching it" is the business case, and it will be in the justification they wrote to get the purchase approved.
Listen for it in the value proposition:
- Runs automatically
- No manual intervention
- Processes overnight
- Handles it end to end
- Frees the team from
You are rarely extracting this. You are usually just recognizing it.
A note on vocabulary. You will meet the term ADMT — automated decision-making technology. It appears in California's rules, in Colorado's law, and in vendor material.
It describes what these questions are getting at: computation standing in for human judgment in decisions that matter to people.
One thing worth knowing. The decision questions and the oversight questions are read together.
A tool that scores applicants with real, case-by-case human review sits differently than the same tool where review is nominal. Same output. Different picture.
That is why "is there human review" is not a yes or no. Someone approving a queue of two hundred recommendations is not exercising judgment on any of them.
Capture what is actually happening. The determination comes later.
Vulnerable groups include patients, children, elderly individuals, people with disabilities, and people in financial vulnerability.
Employees belong in this category too. Not because of who they are, but because of the relationship. An employee cannot freely refuse their employer's processing, and data protection guidance treats that power imbalance as a vulnerability factor.
6. The vendor and your controls
- Whether the vendor trains models on your data
- How long they retain prompts, inputs, and outputs
- Whether they log what is sent to the tool
- What safeguards you already have documented
The last one is where most intakes go soft. Chapter 4 covers how to keep it honest.
Who Holds Each Answer
You will not get the intake from one person. Expect two conversations, sometimes three.
The business lead knows the work
They know what the tool does, what value it provides, what data it works with, and who acts on the output.
They almost always know their data specifically. It is their business.
What they may not be able to tell you: the plumbing. What the tool connects to, where it runs, what else it can reach.
IT knows the infrastructure
Every team adopting an AI tool has an IT person attached to it. Either they recommended it, or they are wiring it into the environment.
That person knows:
- What systems the tool connects to
- What it can access beyond what was described
- Where it is hosted
- Whether it runs on a schedule
You do not have to hunt for who to ask. There is always someone.
The vendor knows their own handling
Training, retention, logging, sub-processors.
Sometimes this is published. Often it is not. Chapter 4 covers how to get it.
Where the split usually falls
| Question | Who answers |
|---|---|
| What does the tool do for us | Business lead |
| What data does it work with | Business lead |
| What does it connect to | IT |
| Where does it run | IT |
| Does it act without being triggered | Either — expect to ask both |
| Training and retention terms | Vendor, then contract |
| Do we have a signed data processing agreement | Procurement or legal |
That last row is worth noting early. Some of what you need is already in a file somebody else maintains.
The Principle Underneath All of It
You will not get every answer directly. Some you will work out from what people tell you.
That is fine, and it is normal in compliance work. But hold the discipline:
Derive but verify.
Form the hypothesis from what you have been told. Then confirm it. Never assume your reading is correct because it is reasonable.
A confident wrong answer in the intake produces a confident wrong analysis downstream — and nothing about the output will look wrong.
Chapter 4 covers how to run the conversations, where the information lives when nobody knows it offhand, and what to do when it does not exist anywhere.
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.