AI obligation mapping: what the decision maker looks at
AI obligation mapping is the internal exercise that lists every AI system in use, the duty attached to each one, and the date each duty falls due. The person reviewing the map checks three things: coverage, ownership, and the point past which a gap becomes expensive to close. A map without one of those three is not yet a map a decision maker can sign off.
What the map is expected to cover
A usable map lists each system that touches AI in production, the business function it serves, and the category of duty that attaches to it. Categories typically include transparency toward the people affected by a decision, a human oversight step, record-keeping over time, and a duty to report certain incidents to a regulator or to an internal risk owner. The map does not list legal citations. It lists systems, owners, and dates, and it stays useful only as long as someone keeps updating it.
The exercise fails most often not because a system is missed, but because a system is added to the register once and never revisited once its role in the business changes. A pilot that becomes a live product changes category. A model that was internal-only and now feeds a customer-facing feature changes category too, and the map has to catch that change on the same day it happens, not at the next scheduled review.
Where an AI system depends on a vendor that processes data on the company's behalf, the mapping exercise has to reach past the company's own systems. The vendor record used for that step is the same one built during subprocessor approval, described in our guide to How subprocessor approval process technology contract what the decision.
The stages the decision maker reviews
Most mapping exercises move through the same five stages, though the order can shift depending on how many systems a company already has in production and how much of the underlying documentation already exists somewhere in the business.
| Stage | Output | Typical owner | Typical duration |
|---|---|---|---|
| Inventory | List of AI systems in use, with a business owner attached to each | Compliance lead | 1–3 weeks |
| Role classification | Record of the company's role for each system: builder, deployer, or distributor | Legal and product | 1–2 weeks |
| Risk tiering | Documented risk category for each system, with the reasoning behind it | Compliance lead | About 1 week |
| Documentation package | Technical file, data sheet, and oversight log per system | Product and engineering | 2–6 weeks, depending on system count |
| Sign-off and escalation | Decision record and a remediation plan for any open gap | Decision maker | Ongoing |
The decision maker rarely reads the underlying documentation line by line. What gets reviewed is the sign-off record: which systems carry a gap, who owns closing it, and by what date. A register that lists twenty systems and no open gaps is either finished or has not been checked closely enough, and an experienced reviewer treats both possibilities as worth a second look.
What changes once the map exists
Before a map exists, obligations are scattered across contracts, product specifications, and individual engineers' working knowledge. Once it exists, a missed deadline becomes visible to more than one person, which changes how the company treats delay. A gap that used to sit quietly inside a project plan now sits on a register that someone is expected to close, and closing it late has a name and a date attached.
The same shift happens to budget conversations. Once a gap is on the register, funding a fix stops being a discretionary decision and becomes a line item with a deadline attached to it, which tends to move faster through internal approval than an unregistered request ever did.
Where the AI system is licensed from a third party rather than built in-house, the map should also record what happens if that third party stops supporting the model. That is the same question a file has to answer in an escrow arrangement, covered in our guide to How escrow arrangements IP licence what the decision maker.
Pausing a system that is already live is a different exercise from delaying one that has not launched yet. The same distinction governs the decision to pause a running process rather than a process that never started, a point covered in our guide to Suspension of an offer token issuance what the decision.
What to do
- Compliance lead builds the initial inventory from procurement records, not from memory.
- Product owner confirms which systems are still in pilot and which are already live.
- Legal assigns a role — builder, deployer, or distributor — to each system on the list.
- Compliance lead sets a risk tier for each entry and records the reasoning in one line.
- Decision maker signs off the register and sets a date for closing every open gap.
- Compliance lead re-runs the inventory whenever a new system enters production or an existing one changes function.
Who decides and on what timeline
The sign-off usually sits with whoever already owns data protection or technology risk inside the company — a data protection officer, general counsel, or a risk committee, depending on how the company is structured. The forum is internal, not a regulator's office, and the register rarely leaves the building unless an incident forces it out.
The timeline is set by the company itself, though a gap that touches an already-live system tends to move faster than a gap in a system still in pilot. A board or risk committee that meets quarterly is not a fast enough forum for a live gap, so most companies build a shorter escalation path for anything already in production.
Scenarios worth separating
If the company only deploys systems built by someone else, the mapping exercise is mostly a vendor exercise: contracts, subprocessor records, and a role classification per system. The heaviest work sits with legal and procurement rather than engineering.
If the company also trains or fine-tunes a model, the file grows to include technical documentation the company itself has to produce and keep current, which shifts the heaviest work onto product and engineering instead.
If a supplier disputes its own role classification and the disagreement reaches a counterparty before the mapping is finished, timing starts to matter more than the underlying facts. The pattern that follows once someone else has already acted is set out in When the other side moved first in this situation.
What this page does not resolve
This overview does not classify a specific system for a specific company, and it does not set the exact wording of a technical file. It does not decide which regulator has jurisdiction over a cross-border deployment, or how a group of companies should split ownership of a shared system. Those questions depend on facts a general procedure page cannot hold, and answering them without those facts would do more harm than leaving the question open.
Verified
This overview was reviewed on 4 March 2025 against publicly available guidance issued by European Union institutions and national supervisory authorities. It describes a common internal process rather than a specific statutory duty, and it should be read alongside advice on the company's own systems rather than in place of it.
Related reading
Companies running an AI obligation map alongside a data-sharing arrangement often ask the same ownership question in a different setting — see our guide to How joint controller arrangement data protection what the decision.
Talk to us
A partner reads first messages in minutes during business hours and confirms a price for the mapping work within one business day.
FAQ
How long does AI obligation mapping take in practice?
A first pass over a modest AI estate — a handful of systems, one main jurisdiction — typically takes between four and eight weeks from inventory to sign-off. A larger estate with several vendors and jurisdictions runs longer, mainly because the documentation stage stretches out as more systems need their own technical file.
Which documents are needed to start?
The exercise starts from procurement records, existing vendor contracts, and a list of systems already in production or pilot. Nothing needs to be drafted from scratch before the first inventory stage begins, which is why the stage itself rarely takes longer than three weeks.
What happens if a vendor does not respond to a mapping request?
The system stays on the register as an open item rather than being left off the list altogether. The decision maker sets a follow-up date and, if the vendor stays silent past that date, treats the missing information as a risk factor in its own right rather than as a reason to pause the rest of the exercise.