What the Deployment Obligates You to Do
You have an accurate intake. This chapter covers what happens next.
Fair warning: this is the hardest step in the program, and the manual is going to be honest with you about why.
This chapter covers:
- What an obligation actually is
- The three questions that determine whether one applies
- Why a single deployment triggers several frameworks
- The kinds of obligations you will find
- The discipline that keeps the answer defensible
- Where this stops being your call
What "Obligation" Means Here
People use "does this law apply to us" as if it were one question. It is three, and they resolve in order.
A law can apply to your organization and still create no obligation for a particular deployment. That is not a loophole. It is how the statutes are built.
The Three Questions
1. Does this law reach our organization at all?
Threshold questions. Revenue, headcount, consumer counts, sector, whether you are a covered entity.
Some of these are organization-level facts that have nothing to do with the tool.
Examples of what sits here:
- Revenue and consumer thresholds under state privacy laws
- Whether you are a covered entity or a business associate
- Whether your regulator is a banking agency rather than the Federal Trade Commission
- Whether you have any establishment or activity in a jurisdiction
If the answer is no, nothing downstream matters. Record why and move on.
2. Does it reach this deployment?
The law applies to you. Does it apply to this use of this tool?
What sits here:
- Whether the affected people are in scope
- Whether the processing activity is one the law covers
- Whether an exclusion applies
The exclusions matter more than people expect. Several state privacy laws exclude individuals acting in an employment context from the definition of consumer. A deployment touching only employees may fall outside those laws entirely — while remaining squarely inside others.
3. Does it trigger the obligation?
The law reaches the deployment. Does this particular duty attach?
What sits here:
- Whether the processing is high-risk
- Whether decisions have significant effects
- Whether sensitive categories are involved
- Whether the tool is classified as high-risk under the applicable framework
This is where the intake earns its keep. Every one of these turns on facts you captured.
Why the order matters
A failure at question one should stop the analysis. If you skip to question three you will find obligations that do not apply to you.
And you should record where each analysis stopped. More on that below.
One Deployment, Several Frameworks
This is the part that surprises people who have run single-framework programs.
An AI deployment is not governed by one law. It sits at an intersection.
A single deployment can be reached by:
| Layer | Example |
|---|---|
| General data protection law | GDPR, UK GDPR |
| AI-specific law | EU AI Act, state AI statutes |
| State comprehensive privacy law | Whichever states the people are in |
| Sector regulation | Health, financial, insurance, education |
| Employment law | If the deployment touches workers |
These do not substitute for one another.
Meeting your obligations under one framework does not discharge the others. A deployment can require an assessment under a data protection law and a separate assessment under an AI law, addressing different questions about the same system.
The practical consequence
You cannot determine obligations by picking the framework you know best and working through it.
You have to work outward from the deployment facts, and check every framework the facts reach.
That is the step nobody can do quickly by hand. Chapter 7 addresses that honestly.
The Kinds of Obligations You Will Find
Not every obligation looks the same. It helps to sort them, because they get satisfied differently.
Things you must do
Conduct obligations. The organization has to behave a certain way.
- Provide meaningful human review before certain decisions
- Give people a way to contest an outcome
- Ensure a qualified person participates in specific determinations
- Restrict certain processing without a lawful basis
Things you must produce
Documentation obligations. A specific artifact has to exist.
- An impact assessment, completed before processing begins
- A record of the processing activity
- A risk classification
- A signed agreement with the processor
Timing matters here. Several of these must exist before the activity starts. A document created afterward may satisfy the form and not the requirement.
Things you must tell people
Transparency obligations.
- Notice that AI is being used
- Explanation of a decision
- Disclosure of what data is processed and why
Things you must keep
Retention and record obligations.
- Logs, for a defined period
- Compliance records, for a defined period
- Evidence that oversight occurred
Why sorting them helps
Different people close them.
Conduct obligations usually belong to the business or to IT. Documentation obligations usually belong to you. Transparency obligations often sit with legal or marketing. Record obligations sit with whoever owns the system.
A list of obligations that does not distinguish between them is a list nobody can action.
The Discipline: Three Answers, Not Two
This is the most important habit in the chapter.
For every framework you assess, the answer is one of three things:
| Answer | Meaning |
|---|---|
| Applies | The obligation attaches. Here is why. |
| Does not apply | Assessed and excluded. Here is why. |
| Unresolved | We could not establish this. Here is what is missing. |
Never let an unknown resolve silently into "does not apply."
That is the single most common failure in this work, and it is invisible. A framework you never checked and a framework you checked and excluded look identical in a file that only records what applies.
Record the reasoning, not just the conclusion
For each framework, write down:
- What you concluded
- Which fact drove it
- Where the analysis stopped
"Assessed and excluded — employment context, consumer definition does not reach this deployment" is a defensible record.
Silence is not.
Why this matters later
When someone asks what you looked at, the answer should not depend on memory.
An examiner, an auditor, or your own successor should be able to see the shape of the analysis — including the parts that came out negative.
Where This Stops Being Your Call
Some of this is factual. Some of it is judgment, and the judgment belongs to counsel.
Reasonably yours to determine:
- Which frameworks the deployment facts reach
- Which obligations are documented as triggered
- What documentation exists and what does not
- Where the gaps are
Counsel's to determine:
- Whether a contested threshold is met
- Whether an exclusion genuinely applies
- Whether what you have is sufficient
- Whether to proceed with the deployment
Escalate when:
- The applicability question is genuinely close
- Two frameworks appear to conflict
- The standard is unsettled and the exposure is material
- Someone wants to rely on an exclusion you cannot clearly evidence
There is more unsettled ground in AI regulation than in most areas. Several key standards are awaiting interpretation. That is not a reason to stall — it is a reason to document your reasoning clearly, so the position can be defended or revised as the law settles.
An Honest Word About Scale
Everything above is workable for one deployment.
Run the same analysis across every deployment in an organization of any size and the arithmetic changes.
- Each deployment touches several frameworks
- Each framework has its own applicability, scope, and trigger questions
- Each answer has to be recorded with its reasoning
- All of it has to be revisited when the law moves
That is not a knowledge problem. It is a volume problem.
Most organizations do not fail this step because they cannot reason about a statute. They fail it because they cannot reason about four hundred of them, repeatedly, and keep the record current.
Chapter 6 covers what the mandated documents actually are. Chapter 7 covers keeping any of it current — which is where the volume problem becomes unavoidable.
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.