AI obligation mapping: documents to prepare

AI obligation mapping identifies which artificial intelligence systems your organisation uses, who controls them, and which compliance duties attach to each one. The exercise starts with an inventory, not a legal opinion. Get the paperwork right at the outset, and the rest of the process moves quickly.

What changes once mapping starts

Once the inventory begins, internal deadlines follow on their own. Each system flagged as high-risk, or as one that processes personal data, opens its own documentation trail. Vendor contracts get reopened for review. Data protection records get cross-checked against the new inventory. The mapping exercise itself carries no external filing deadline, but the obligations it surfaces almost always do.

This matters for budgeting time, not just legal risk. A mapping exercise that stops at the inventory stage leaves every downstream obligation unaddressed. Treat the inventory as the start of the work, not the end of it.

Documents to prepare

Assemble these before the first mapping session starts. Missing documents slow the exercise down more than any legal question raised during it.

Each document does more than tick a box. The system inventory gives scope; the vendor contracts confirm who is legally responsible for what; the data flow diagrams show whether personal data crosses borders. Without all three, the classification step in the next section cannot proceed reliably.

Steps to take

Follow this order. Skipping the inventory step is the most common reason mapping projects restart from scratch.

1. List every AI system in use, including tools embedded inside third-party software. IT compiles the list.
2. Classify each system by function and by the type of data it touches. Compliance leads this step.
3. Identify the organisation's role for each system: provider, deployer, or distributor. Legal confirms the classification.
4. Cross-check vendor contracts for subprocessor status where an AI vendor also processes personal data. Where an AI vendor sits inside your data chain, the contract review follows the same logic as How subprocessor approval process technology contract documents to prepare.
5. Flag any system delivered under a software escrow or source-code release arrangement. The mapping only needs to note that one exists; the underlying document logic is set out separately in How escrow arrangements IP licence documents to prepare runs.
6. Compile the completed inventory into a single register, with an owner named for each entry. Compliance owns the register going forward.

Who decides and how long it takes

Internal governance decides scope, not a court or a regulator. The compliance function, or the data protection officer where one is appointed, approves the mapping methodology before work starts. Senior management signs off the completed register at the end. Where the classification step disputes a system's risk tier, that disagreement goes back to the compliance function for a documented decision, not to the original system owner.

For an organisation running fewer than twenty active AI tools, a first mapping cycle typically takes two to four weeks from kick-off to signed register. Larger estates take longer, mainly because vendor responses take longer to collect than the internal analysis does.

If your situation differs

If your organisation only deploys AI systems built by others, the mapping stays narrower. Focus on vendor documentation and usage terms rather than technical design records.

If the inventory reveals a patent dispute tied to one of the underlying models, that dispute runs on its own separate timeline. See Revocation proceedings: stages and deadlines for how that process is structured.

If your organisation also issues tokenised assets and an AI system feeds pricing or eligibility data into that process, the offering documentation is a separate file. It is defined in Offering document in token issuance: definition and use.

If the mapping is your organisation's first cycle, expect the vendor response stage to take longer than every other step combined. Build in extra calendar time before setting an internal deadline.

What this page does not cover

This page sets out the mapping procedure and the paperwork behind it. It does not set thresholds for what counts as high-risk, and it does not state specific statutory deadlines. Those depend on the system and the sector involved, and change too often to fix on a general page.

This page also does not replace a full compliance audit. It also does not cover training or procurement decisions that predate the mapping exercise; those sit with the teams that made them. Where your organisation shares control of an AI system's data with another party, joint controllership brings its own separate document set, addressed elsewhere rather than folded into this procedure.

Related publications

Where AI obligation mapping overlaps with joint control of the underlying data, the document set differs from a single-controller case. See How joint controller arrangement data protection documents to prepare for that variant.

Verified

Checked against publicly available regulatory guidance and current supervisory authority publications, as of the review date shown on this page. Where a specific figure or threshold changes, the organisation's own register remains the source of truth, not this page.

FAQ

How long does AI obligation mapping take in practice?

For a small AI estate, two to four weeks is typical from kick-off to a signed register. The bottleneck is usually vendor response time, not internal analysis.

Which documents are needed to start?

A system inventory, current vendor contracts, and any existing data flow diagrams. Without these three, the first mapping session has nothing concrete to work from.

What happens if the other side does not respond?

Mark the vendor as unconfirmed in the register and proceed on the terms already available in the contract. Escalate through procurement if the gap affects a high-risk system.

— Rasa Tumenaite, AURELIS