AI obligation mapping: stages and deadlines

AI obligation mapping is the internal exercise of listing every AI system in use across an organisation, working out which rules apply to each one, and assigning an owner and an internal deadline to every resulting task. Done properly, the exercise runs for three to eight weeks depending on how many systems, vendors and business units are involved.

What changes once the mapping starts

Before the mapping exists, obligations sit scattered across contracts, procurement records and individual team knowledge. No one can say with confidence how many AI systems the organisation actually uses, or which team is responsible for keeping each one compliant. Once the register exists, every system has a named owner and a date by which the next action is due. Risk moves from unknown and unmanaged to known and tracked, which is the position a board or a counterparty expects if a question is ever raised.

What to do

1. The compliance lead lists every AI system in use, including systems built in-house, systems bought from a vendor and systems embedded inside another product.
2. The same team records, for each system, what it does, what data feeds it and who inside the organisation is accountable for it.
3. Legal and compliance jointly classify each system by function and by the sensitivity of the data or decisions it touches.
4. For each system, the team identifies the obligations that follow from that classification: documentation, human oversight, logging, security testing, incident reporting.
5. Management assigns one internal owner per obligation, with an internal deadline set ahead of any external one.
6. The finished register goes to a governance forum for sign-off, then follows a fixed review schedule rather than sitting static.

Who decides

Within the organisation, the compliance or data protection function usually runs the mapping day to day. Sign-off sits with whichever internal forum already governs data protection and security decisions, often a small group combining legal, IT and a member of senior management. That forum sets the internal deadline for each obligation and decides when the register needs a refresh. External deadlines, where they exist, come from a regulator, a customer or a vendor contract; internal deadlines should always sit ahead of them, never on the same date.

Common forks

If the AI system was built in-house, the mapping can rely on internal documentation and does not depend on a third party answering requests. If the system is licensed from a vendor, the mapping needs to check what happens if that vendor stops supporting the product, the same question a technology escrow arrangement is built to answer. See Escrow arrangements: stages and deadlines.

If the system was developed jointly with another company, the mapping should also flag who controls the underlying patent filings, since a partner filing alone can change who owns rights tied to the model. See When a joint development partner files alone: the deadline.

If a vendor relies on its own subprocessor to run part of the system, the mapping should record whether that subprocessor went through the standard approval step, because an unapproved subprocessor is exactly the kind of gap the register exists to catch. See Subprocessor approval process: stages and deadlines.

What this page does not cover

This page describes the internal procedure only. It does not calculate a specific external deadline for a specific system, since that depends on which rules apply and when the system entered use, and needs a case-by-case check. It does not decide whether an AI feature bundled into a digital-asset offering changes the timeline for that offering; a suspended token offer runs on its own separate clock. See Suspension of an offer step by step in practice. Nor does it replace advice on a specific contract or a specific incident.

Verified

This page describes internal procedure rather than statute, which is how procedural pages in this section are written throughout. It reflects mapping practice as currently applied, and is reviewed each time that practice changes.

Related reading

A closely related procedure applies where two organisations control the same data jointly, rather than one organisation mapping its own obligations alone. See How joint controller arrangement data protection runs in practice.

Next steps

If a business partner or vendor exercises an audit right while the mapping is still underway, handle that separately first. See When an audit right is invoked without notice in practice.

If the mapping flags a cross-border transfer mechanism that a regulator or counterparty later questions, that also runs on its own track. See When a transfer mechanism is questioned: what to do first.

FAQ

How long does AI obligation mapping take in practice?

For a single business unit with a handful of AI systems, the mapping usually takes three to four weeks from inventory to sign-off. Organisations with several business units, multiple vendors or overlapping products should plan for six to eight weeks, mostly because gathering vendor documentation takes longer than the internal steps.

Which documents are needed to start?

The starting point is a list of AI systems already known to procurement, IT and each business unit, plus any vendor contracts and data processing agreements already in place. Internal policies on data protection and security, and any existing risk register, save time because they already hold half the classification work.

What happens if a vendor does not respond to a request for documentation?

The mapping records the request, the date it was sent and the outstanding item, rather than pausing until the vendor answers. If the vendor stays silent past the internal deadline, the item is escalated internally and, where the contract allows it, a formal request follows with its own deadline attached.

— Rasa Tumenaite, AURELIS