From Data Maps to Action Maps: What Enterprise Buyers Need to Know About AI Agents

Key Takeaways

• Under Art. 25 EU AI Act , once the relevant high-risk obligations apply, an enterprise deployer or other third party may become the provider of a high-risk AI system where, for example, it changes the intended purpose of an AI system, including a general-purpose AI system, so that the system becomes high-risk under Article 6.
• For organizations within the scope of NIS2 Directive, reliance on external AI services and APIs may need to be addressed through supply-chain cybersecurity risk management under Art. 21(2)(d) NIS2 Directive, depending on the entity, service and deployment context.
• AI agent action maps complement traditional data-flow documentation used to fulfill the requirement under Art. 30 GDPR by documenting runtime operational authority, permission boundaries and the implementation of human oversight where relevant under Art. 14 EU AI Act once the corresponding high-risk obligations apply.
• Enterprise buyers should assess whether agent governance tooling provides intervention controls proportionate to the agent's authority, including permission restriction, temporary suspension or controlled shutdown capabilities.

Introduction: Data Flows Do Not Show the Full Risk

During enterprise AI procurement, compliance teams routinely analyze data maps to track how inputs traverse system boundaries. However, as organizations transition from passive retrieval copilots to autonomous systems, traditional data maps may not capture the active operational authority of AI agents. A July 2026 review by the UK Financial Conduct Authority (FCA) indicated that 20% of UK retail financial services consumers are likely to use systems capable of acting autonomously within preset goals. For enterprise buyers, a meaningful AI agent risk assessment therefore requires attention not only to data flows but also to execution boundaries. A structured AI agent action map can help evaluate the runtime capabilities, permission structures and potential liabilities of autonomous systems as part of a broader AI agent governance framework.

1. Why Data Maps Are Not Enough for AI Agents

To understand the limits of traditional governance, organizations must evaluate how autonomous software interacts with corporate systems. Data maps primarily depict information flows, whereas agents can also exercise operational authority that requires separate runtime analysis.

1.1 Data maps focus on information movement

Traditional data-flow maps, often used to support records of processing activities (ROPA) under Art. 30 GDPR and broader accountability, focus on how personal data moves through systems and organizations. Article 30 GDPR itself requires documentation such as processing purposes, categories of data subjects and personal data, recipients, transfers, retention periods and, where possible, a general description of security measures. But it does not prescribe a technical data-flow diagram. These records and maps remain important, but they do not by themselves represent the runtime execution capabilities of a system that can dynamically plan and invoke tools.

1.2 AI agents combine data access with operational authority

Unlike traditional SaaS integrations that read or write structured database fields under strict API constraints, autonomous agents combine data retrieval with the authority to execute material actions. Utilizing protocols like the Model Context Protocol (MCP), agents can dynamically compose plans, access multiple databases and invoke third-party APIs to achieve high-level goals. The risk shifts from simple data exposure to unauthorized operational execution, where an agent acts as a non-human identity within the enterprise environment.

1.3 A data-only view leaves key questions unanswered

Without mapping runtime authority, security and privacy teams may struggle to assess whether existing controls are sufficient for Art. 32 GDPR (security of processing) or to perform a Data Protection Impact Assessment (DPIA) under Art. 35 GDPR where required. Traditional data maps do not necessarily show who authorized a specific automated transaction, how execution boundaries are enforced or what happens when a sequence of automated actions must be stopped or reversed. Where an agent makes or materially determines a decision based solely on automated processing that produces legal effects or similarly significant effects on an individual, Art. 22 GDPR may also require separate assessment. This operational blind spot can also complicate the implementation of data protection by design and by default under Art. 25 GDPR.

2. What an AI Agent Action Map Should Contain

To address these gaps, buyers should require vendors to supply an action map alongside traditional documentation. This deliverable can help translate regulatory requirements and identified risks into technical and organizational guardrails.

2.1 Purpose and permitted actions

An effective AI agent action map should define the exact boundaries of the agent's mandate. Under Art. 5(1)(b) GDPR, personal data must be collected for specified, explicit and legitimate purposes. For an autonomous agent, one practical way to operationalize purpose limitation is to define a bounded set of permitted actions and prohibited uses, helping reduce unauthorized secondary processing or autonomous tool use.

2.2 Systems, tools and permissions

The map should document the enterprise repositories, third-party APIs and administrative tools the agent can access. Dynamic governance requires robust identity boundaries. To address credential risks, organizations should apply non-human identity governance controls to agent service accounts. Relevant controls can include least-privilege permissions, credential lifecycle management, session monitoring, and periodic review of access across connected systems.

2.3 Consequences and action levels

Actions should be categorized by their real-world consequences and reversibility. Read-only processes (such as querying a database) pose different regulatory risks from write actions (such as sending an email, transferring funds or updating customer files). The map should identify the exact "commit moment", the point at which an agentic plan transitions into an irreversible physical or business action, and separately flag workflows that may involve decisions based solely on automated processing that produce legal or similarly significant effects on an individual, for which Art. 22 GDPR may require assessment. The commit moment is a governance concept rather than a statutory Article 22 GDPR test, but it can help determine where additional review or intervention controls are appropriate.

2.4 Human control and evidence

The action map should document how human-oversight measures are operationalized for applicable high-risk systems once the relevant EU AI Act obligations apply. Art. 14 EU AI Act requires such systems to be designed and developed so that they can be effectively overseen by natural persons; human-in-the-loop (HITL) and human-on-the-loop (HOTL) are useful governance models, but they are not themselves statutory categories in Art. 14 EU AI Act. The map can therefore identify where human review, intervention, or system interruption is available. Controls may feature graduated enforcement mechanisms rather than only binary shutdowns. Possible implementation measures include human review gates, temporary restrictions on tool use, suspension of execution privileges, and controlled shutdown mechanisms. These are governance and engineering choices rather than prescribed Article 14 EU AI Act implementation methods.

3. How Enterprise Buyers Should Assess Agent Actions

Procurement teams must shift from evaluating high-level product capabilities to analyzing discrete action pathways and the regulatory liabilities they trigger.

3.1 Assess the consequence, not only the technology

Buyers should evaluate the agent based on the potential impact of its decisions rather than its technical sophistication. This focus is consistent with the risk-management framework laid down in Art. 9 EU AI Act for high-risk systems. Following the Digital Omnibus on AI, the relevant Chapter III Sections 1–3 high-risk obligations apply from 2 December 2027 for systems classified under Article 6(2) and Annex III, and from 2 August 2028 for systems classified under Article 6(1) and Annex I. For instance, an agent performing resume screening or employee evaluation may fall within a high-risk category under Annex III, whereas an agent summarizing generic public documentation may not trigger the same classification and compliance pathway.

3.2 Match controls to the action

Controls must be proportional to risk. To manage runtime execution safely, organizations can use graduated execution permissions, compensating or rollback workflows, and temporary read-only modes. Such controls can reduce the need for abrupt system shutdown while preserving intervention options proportionate to the consequences of the agent's actions.

3.3 Map responsibility across the AI stack

Under Chapter IV GDPR and as clarified by the EDPB controller–processor guidance (Guidelines 07/2020), compliance responsibilities depend on the factual role of each party as controller, joint controller or processor in relation to the relevant processing; commercial labels such as SaaS vendor or enterprise customer are not determinative. For a high-risk AI system, an enterprise customer that qualifies as a deployer is subject to the specific obligations in Art. 26 EU AI Act once those obligations apply. Enterprise buyers must also consider Art. 25 EU AI Act: a distributor, importer, deployer or other third party can become the provider of a high-risk AI system in specified circumstances, including where it puts its name or trademark on an existing high-risk system, substantially modifies such a system while it remains high-risk, or changes the intended purpose of an AI system, including a general-purpose AI system, so that it becomes high-risk under Article 6 EU AI Act. In that case, the party is subject to the provider obligations referred to in Article 16 EU AI Act rather than simply "inheriting" an undefined set of liabilities. Separately, providers and deployers should address the AI literacy duty in Article 4 EU AI Act for staff and other persons dealing with the operation and use of AI systems on their behalf, taking account of their knowledge, experience, education, training and the context of use.

3.4 Require evidence, not general assurances

Vague contractual declarations are typically insufficient to demonstrate regulatory compliance. For high-risk systems once the relevant obligations apply, the EU AI Act lays down requirements including transparency and instructions for use (Art. 13) and accuracy, robustness, and cybersecurity (Art. 15). Separately, transparency obligations (Art. 50) apply from 2 August 2026. The European Commission's final July 2026 guidelines on Article 50 clarify the duties of providers and deployers of certain AI systems. In particular, Article 50(2) EU AI Act concerns providers of AI systems, including general-purpose AI systems, that generate synthetic audio, image, video or text content and requires outputs to be marked in a machine-readable format and detectable as artificially generated or manipulated. These system-level transparency duties should not be conflated with the separate obligations of general-purpose AI model providers under Article 53 EU AI Act. Where a DPIA is required, buyers may also use the EDPB's April 2026 DPIA template, which the Board adopted and then submitted to public consultation. For organizations within the scope of NIS2 Directive, reliance on external AI services may also need to be assessed as part of supply-chain cybersecurity risk management under Article 21(2)(d) NIS2 Directive. More specific supplier documentation requirements may apply to entities covered by Commission Implementing Regulation (EU) 2024/2690. It is to mention that AI APIs are not automatically classified under NIS2 as "critical third-party services."

4. From Action Mapping to Procurement Readiness

Transitioning from theoretical risk analysis to operational readiness requires a structured implementation methodology. Buyers should embed the action map into their standard procurement workflows.

4.1 Start with one concrete use case

To transition to dynamic governance, avoid trying to map the entire enterprise infrastructure simultaneously. Identify a single, high-value, lower-risk pilot, such as an automated customer support agent configured to retrieve order details and issue standard refunds. This isolated scope simplifies the execution of an initial AI agent risk assessment.

4.2 Break the workflow into material actions

Deconstruct the selected agentic workflow into distinct operational steps. Separate data retrieval (querying database systems) from transactional actions (processing a payment modification) and communications (emailing the customer).

4.3 Connect each action to a control and evidence

For each material action, specify the matching control. Higher-impact or irreversible write actions may justify step-up authentication, dual approval or human confirmation, depending on the risk. Logging should be sufficiently complete, reliable and protected against unauthorized alteration to support auditability and oversight. For high-risk AI systems, the EU AI Act also contains specific automatic logging requirements in Article 12, alongside separate human-oversight and accuracy, robustness and cybersecurity requirements in Articles 14 and 15.

4.4 Use the map as a living document

Static spreadsheets may become difficult to maintain for dynamic AI agent deployments. The action map should therefore be maintained as a living record and updated when model APIs, tools, permissions or operational boundaries materially change. Automated updating can help at scale, but it is not itself a requirement of Art. 25 or 32 GDPR. Keeping the documentation current can nevertheless support risk-based compliance and help organizations verify that the system remains within its authorized parameters.

Conclusion: Map Authority, Not Only Data

Data mapping remains foundational for GDPR compliance, but agentic systems require governance teams to look beyond information flows. In enterprise AI procurement, legal, security and privacy teams should evaluate not only where data flows, but also where operational authority is exercised, what consequences an action can produce and where intervention remains possible. An action map can complement existing compliance documentation by providing a structured view of runtime authority, attribution and auditability without treating any single technical control as a substitute for the underlying legal analysis.