Where to Begin
You have obligations. Chapter 1 covered where they came from.
This chapter covers where to start, and it begins with better news than most people expect: you are not starting from nothing.
This chapter covers:
- Who carries the obligation
- Why this program has a different shape
- What you already have that applies
- Who else in your organization has a stake
- Why the work starts now
- What you need to capture first
Who Carries the Obligation
Start here, because it determines whether this is your problem at all.
When your organization deploys a third-party AI tool, your organization carries the legal obligation. The company that built the model does not carry it for you.
What this means practically:
- Vendor terms do not transfer the obligation
- A vendor's System and Organization Controls report — SOC 2 — does not satisfy it
- Providers and deployers have separate duties
- Their duties do not discharge yours
If a regulator opens an inquiry, they ask you. What you knew. What you assessed. What you documented. When.
"We licensed it from an established vendor" is a procurement position. It is not a regulatory one.
Why This Program Has a Different Shape
If you have run any of these, you know how a compliance program works:
- SOC 2 — System and Organization Controls 2
- ISO 27001 — the international information security management standard
- SOX — internal controls over financial reporting
- PCI DSS — Payment Card Industry Data Security Standard
This one is different in one specific way, and it changes your planning.
Other frameworks give you the list
- SOC 2 gives you trust services criteria
- ISO 27001 gives you Annex A
- SOX gives you a control framework
The work is substantial. But you never have to determine what is expected of you. Someone else assembled the register.
Regulation does not
The obligations are:
- Written by legislators across many jurisdictions
- Drafted in statutory language, not control language
- Published in many places, collected in none
- Revised without notice to you
That moves where the difficulty sits
The standard compliance sequence:
- Identify what applies to you
- Determine what you are obligated to do
- Produce the documentation required
- Maintain it as things change
In SOC 2, step one is finished before you start.
Here, step one is the hardest part of the program. It is where most organizations stall, and it is why the rest of this manual spends so much time on it.
There is no completion point
No certificate. No annual report. No date on which you are finished for the year.
That is not an oversight in the law. The obligations are continuous, so the program is continuous.
You run it. You do not complete it.
What You Already Have
Most organizations have more relevant material than they realize. Find it before you build anything new.
Existing compliance programs
Overlap between programs is normal in compliance work. One piece of evidence often serves several.
| What you already collect | Also serves |
|---|---|
| Vendor data handling terms | SOC 2 and AI obligations |
| Vendor risk assessments | Half the AI intake questions |
| Access reviews | Security and AI oversight |
| Contract reviews | Where processing terms surface |
| Data inventories | Scope and data-type questions |
Two consequences:
- You are not starting from nothing
- You should not collect the same information twice
An existing AI governance intake
Some organizations already have an approval process for new AI tools. If yours does, start there.
What it usually captures well:
- Tool name and vendor
- Requesting team and business justification
- Technical architecture and integration
- IT owner
What it usually misses:
- What the AI actually 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 governance intakes were built to route an approval, not to establish legal obligation. They capture the plumbing. They rarely capture the obligation.
A rule on age: treat a record under six months old 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.
Who owns that process
In most organizations, data privacy and legal own the AI governance intake.
That is useful. It usually means the record you need is one your own function already maintains — not a turf conversation.
Build the Cadence From What You Run
You already have review cycles. Attach this to them rather than inventing a separate rhythm.
The absence of a completion date is disorienting the first time. The answer is to borrow structure from programs that already have one.
- Annual vendor reviews — add the AI questions
- Quarterly access reviews — add AI oversight checks
- Contract renewal — check processing terms
- New vendor onboarding — capture obligations at intake
The earlier this attaches to an existing cycle, the sooner it stops being a project and becomes operations.
Who Else Has a Stake
You may be handling this with a small team, or alone. Either way, you will be asking other people for information.
It helps to know what each of them is actually worried about.
The board — oversight duty Directors must make a good-faith effort to maintain a reasonable monitoring system for material risk. A risk never identified cannot be monitored. Officers carry the same duty. This is corporate law, not regulatory guidance.
The chief executive — reputation For most organizations the penalty is survivable. The publicity is not. Being named by a regulator signals something about how the company is run.
The general counsel — the inquiry The letter arrives on their desk. They answer for the response. At some point they will ask you what the exposure is.
The CFO and audit committee — unquantified exposure An exposure that has not been identified cannot be sized. Reserves, disclosures, and remediation estimates all rest on scoping that has not happened.
IT and security — half your answers They are already involved. They hold much of the information you need in Chapter 3.
Business unit leads — the deployments They own them. These laws attach to their tools, which makes the exposure theirs as well as yours. In practice they are usually helpful. Most people want to know what they are carrying.
Why the Work Starts Now
The reason has little to do with penalties.
A process does not work on day one
You know this from every program you have stood up. Expect several quarters before it produces the results you are looking for.
So the question is not the date
It is whether you meet 2027 with a program that runs, or a compressed effort producing documents nobody trusts.
Those two situations leave different files.
A running program leaves:
- Assessments dated across a period
- Updates recorded when the law changed
- Ownership reassigned as people moved
A compressed effort leaves:
- Documents dated within the same few weeks
Anyone reviewing the file later can tell the difference. That includes regulators.
One practical point on resourcing
Organizations that wait will do this work in the same quarter as everyone else — competing for the same outside counsel.
When You Find a Gap
This will happen. It is worth knowing what it looks like before it does.
How it usually surfaces:
- A regulator or auditor requests something
- A customer questionnaire asks a new question
- A due diligence request lands during a deal
Why the gap existed:
- The work is being done, but proof was never captured
- Nobody knew the requirement applied
- Someone left, and the process left with them
That last one is more common than people expect. A process depending on one person has an expiry date.
What to do:
- Identify what can be done immediately
- Look for overlapping processes that captured part of it
- Check whether another program already does the same work
- Document the short-term fix and the long-term approach
And one rule that is not negotiable.
You do not hide it. You own it, and you pivot to how it gets addressed.
A gap you found and documented is a different situation from a gap someone else found. The first shows a functioning program. The second raises questions about everything you have not looked at.
What You Capture First
Everything in this manual depends on one thing: an accurate description of what is actually deployed.
Not what was approved. Not what the vendor's marketing says. What is running, what it does, and to whom.
That description is called the intake, and it is where the work begins.
A note on vocabulary. In AI governance conversations, this is often referred to as the deployment use case. It means the same thing: one tool, used one way, described accurately.
This manual uses "intake" because it names the act of capturing the information rather than the record that results. When you are talking to a governance team, the two terms are interchangeable.
The intake establishes:
- What the tool is and who built it
- What your team actually does with it
- Where the affected people live
- What data it sees
- Whether it makes or influences decisions about people
- How the vendor handles your data
- What controls you already have
Why it comes first: every obligation in every jurisdiction turns on those facts. Get them wrong and everything downstream inherits the error.
An obligation analysis built on inaccurate intake produces a well-formatted, confidently stated, incorrect result. Nothing about the output looks wrong.
Chapter 3 covers how to capture it properly:
- Who in your organization holds each answer
- What to ask them, in language they will understand
- How to tell a solid answer from a confident guess
- Where the information lives when nobody knows it offhand
- What to do when it does not exist anywhere
It is the least interesting chapter in this manual. It is also the one that determines whether anything after it is worth relying on.
A Note on Scope
This manual is written by a compliance practitioner, for compliance practitioners.
- It is not legal advice
- It does not replace your counsel's judgment
- Points requiring a lawyer are identified where they occur
There are also substantial portions of this work that do not require a lawyer, and cannot be scaled if you insist on one. Every compliance function already works within that constraint.
Where the answer is settled, this manual states it plainly.
Where it is not — and in AI regulation there is more unsettled ground than usual — it says so.
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.