If you're building or buying workflow automation in the EU right now, two pieces of regulation are relevant to almost everything you touch: GDPR, which has been enforced since 2018 and governs personal data broadly, and the EU AI Act, which layers additional obligations on top when a system counts as "AI" under the Act's definition. They're not competing frameworks — they overlap, and a compliant AI system still has to be a compliant data-processing system underneath.
GDPR didn't go away because you added AI
The most common mistake we see is treating "AI compliance" as a separate checklist from "data protection compliance." It isn't. If your automation touches personal data — customer names, emails, behavioral data, anything that identifies a person — GDPR's existing rules apply exactly as they did before: you need a lawful basis to process it, you need to minimize what you collect, and you need to be able to say where it goes and why.
That's the design principle behind the analytics chat app we built for Salsa te Gusta, a dance school whose reporting lived in spreadsheets containing student names and contact details. Before any of that data reached the AI model, names were converted to stable HMAC tokens and contact details were stripped entirely — the model never sees a real name, and the identifying data is only restored client-side, after inference, for authorized staff. That's not an AI-specific feature. It's ordinary data minimization, applied at the one point in the pipeline where it actually matters: before, not after, the data leaves your control.
What the AI Act adds on top
The AI Act introduces a risk-based classification: some AI uses are banned outright (certain forms of biometric categorization, social scoring), some are "high-risk" and carry real documentation and oversight obligations (AI in hiring, credit decisions, medical devices), and most day-to-day business automation — drafting emails, summarizing data, answering questions from your own documents — falls into a lower-risk tier with lighter requirements, mainly transparency: people should generally be able to tell when they're interacting with AI, and providers of general-purpose AI models have their own separate obligations.
The practical takeaway for most workflow automation is this: know which risk tier your use case falls into before you build, because the obligations differ enormously between "AI drafts an internal report" and "AI screens job applicants." Don't assume a use case is automatically low-risk just because it doesn't feel dramatic — the Act cares about the domain (employment, credit, essential services) more than the vibe of the tool.
The design habit that satisfies both
The single most useful pattern we build against both frameworks is human-in-the-loop by design: nothing sent, decided, or acted on automatically without a person reviewing it first. In the support email agent we built, every AI-drafted reply is saved to Gmail as a labeled draft — never sent directly — specifically so a person remains the one who takes the action with legal and customer-facing weight. That single design choice does double duty: it's good practice for trustworthy automation, and it's also the kind of oversight mechanism regulators are explicitly looking for.
What this means if you're evaluating a build
Ask any automation vendor two direct questions: where does personal data go, and who reviews an AI-generated output before it reaches a customer or a decision. If a vendor can't answer both clearly, that's the gap to close before you scale the system — not after.
This is general information, not legal advice — if AI touches a genuinely high-risk decision in your business (hiring, credit, healthcare), get a lawyer who specializes in EU tech regulation involved before you build.