Loading
What process automation actually requires from a GDPR and AI Act perspective: the gap most COOs miss
·4 min read
When a COO signs off on an automation tool that routes customer enquiries, flags contract anomalies, or schedules workforce tasks, the procurement decision typically rests on a feature comparison and a cost model. The legal question rises usually when a data protection officer reviews the stack, looks into whether the tool processes personal data and whether anyone signed a data processing agreement before the first workflow went live. And usually, by that point, the tool has been running for weeks.
GDPR Article 28 is the clause that governs this. Any third party that processes personal data on behalf of a controller, which describes every automation platform routing employee records, customer details, or contact data through its infrastructure, operates as a data processor and must be bound by a written agreement specifying what it can do with that data, on whose instruction, and under what conditions. As Legiscope's March 2026 analysis of Article 28 notes, the Court of Justice of the European Union confirmed in its December 2025 Russmedia ruling that a processor which independently determines the purposes and means of processing is automatically reclassified as a controller and becomes directly liable. An automation tool that decides, through its own logic, how to handle a data input is not simply a neutral pipe. It may already be a controller.
This reclassification risk is where the AI Act, EU Regulation 2024/1689, enters the picture. Most process automation tools sold today include AI-driven components: routing decisions, anomaly detection, prioritisation engines. Where those components make or materially influence decisions about people, the Act assigns obligations to the entity that built the system and separately to the entity that deployed it. The provider designs the system and documents its capabilities. The deployer, typically the company that bought the tool and put it in front of employees or customers, carries responsibility for how those capabilities function in the specific operational context. As Glean's March 2026 analysis of AI compliance in automated workflows states plainly: when an AI agent executes a workflow touching personal information or financial records, every step in that chain carries the same legal and ethical scrutiny as a human decision. Signing a vendor contract does not transfer the deployer's share of that scrutiny.
The practical situation most COOs face is not one tool but several, each talking to the others. A workflow built in n8n or Make may call a CRM, a communication platform, a document processor, and a third-party AI model in a single execution. Each connection that transmits personal data is a sub-processing relationship under GDPR, requiring prior controller authorisation and a contract chain that extends through every node. Orbiq's March 2026 guide to GDPR Articles 28 to 34 for SaaS deployments identifies this explicitly: every third-party vendor processing personal data on an organisation's behalf requires a signed data processing agreement, including subcontractors. In a ten-tool automation stack, that means ten agreements, each auditable, each specifying data categories, retention limits, and breach notification windows.
NIS2, the EU's Network and Information Security Directive (Directive 2022/2555), adds a third layer for organisations classified as essential or important entities. Article 21(3) of the Directive requires those entities to assess ICT supply chain risk, which regulators have interpreted to include the automation tools and AI systems integrated into operational processes. A company using a US-headquartered automation platform, processing EU data under standard contractual clauses, carries a supply chain exposure its NIS2 risk register must account for. Zapier processes EU customer data under standard SCCs by virtue of its US headquarters; n8n, Frankfurt-based and self-hostable, offers a different risk profile precisely because the data need not leave the controller's own infrastructure. That difference does not appear in a feature comparison table.
There is a fair counterpoint here. Many automation vendors have invested substantially in compliance infrastructure: data processing agreements available on request, ISO 27001 certifications, EU data residency options. Make, acquired by Celonis in 2022, operates under EU law and publishes its DPA terms. Comidor, the Greek business process automation vendor, holds ISO 27001 certification. A COO who has done the work of obtaining and reviewing these agreements before deployment is materially better positioned than one who assumed the vendor's general terms covered it.
Procurement timelines treat the legal review as downstream of the build decision, when the GDPR's Article 28 requirement is that the processor relationship and its contractual terms must be established before processing begins. For AI-augmented tools, the AI Act adds a requirement to document the system's intended purpose and data governance before deployment. Both obligations land before go-live. Organisations that have compared automation platforms on their EU data architecture already understand the structural differences between tools; completing the compliance review before deployment is what converts that structural understanding into a defensible decision. A vendor selected for data residency and governance reasons still needs its DPA signed, its sub-processors listed, and its AI components assessed against the intended use case before the first workflow processes a name.