EU AI Act & GDPR - an engineering perspective
Most compliance problems aren’t caused by “missing policies”. They happen because teams don’t have a shared understanding of how their AI system actually works: what data flows where, which decisions are automated, and what controls exist in production.
This page explains how we approach EU AI Act and GDPR in practice - in a way that helps you ship, sell, and scale. It’s not legal advice or certification.
If your score is medium/high, an audit is the fastest path to clarity and an implementation plan.
What the EU AI Act is (in practice)
The EU AI Act is a risk-based framework for AI systems. Obligations depend on the use case, impacted groups, and how the system is deployed - not on whether you use “AI”.
- Most teams start wrong: they ask “are we high-risk?” before mapping system boundaries and decision points.
- Correct starting point: what the system does, who it affects, where automation happens, and what data it uses.
- Outcome: a practical understanding of risk drivers and what controls you need to implement.
What GDPR means for AI teams
GDPR is not just a privacy policy. For AI systems it’s primarily about data-flow discipline: lawful basis assumptions, minimization, retention, vendor chain, and what happens across training/inference/logging.
- Know your data: what personal data touches the system (even indirectly) and where it is stored.
- Know your vendors: processors, subprocessors, and cross-border transfers.
- Know your outputs: leakage paths, logging, and user access boundaries.
How we think about compliance
Our approach is intentionally simple: compliance is an engineering problem when you translate it into system reality.
1) System > model
A compliance review that focuses only on the model misses most real-world risk. We treat the “AI system” as the full product: UI, workflows, data sources, vendors, logs, and automation points.
2) Data flows > documents
Documentation is an output, not the start. First map training → inference → outputs → feedback → logs. Then documentation becomes accurate and easy to produce.
3) Controls > policies
Real safety and compliance come from controls in production: access boundaries, logging, monitoring, human oversight, incident handling, and change management.
4) Risk tier decides the workload
“High-risk” vs “limited-risk” is not a label - it changes what you must implement. The goal is to identify the tier early enough to avoid expensive rework.
5) Ship-ready outputs
We focus on outputs your team can use immediately: system map, risk register, GDPR touchpoints, and a tickets-ready roadmap.
6) Practical, not performative
The job isn’t to “look compliant” - it’s to reduce risk while enabling sales, EU launch, and enterprise procurement.
Common misconceptions
- “We use OpenAI, so it’s not our problem.”
You still own the product behavior, data flows, and user impact. - “We’re not high-risk because we don’t do scoring.”
Risk depends on the use case and impact, not buzzwords. - “We’ll fix compliance later.”
Later is usually expensive refactoring of logging, oversight, and data retention.
- “We just need a privacy policy.”
For AI teams, the hard part is operational: tracking data, vendors, and outputs. - “We can answer questionnaires without changing anything.”
Procurement expects evidence: controls, logs, processes, ownership. - “Docs will make us compliant.”
Docs help, but controls in production reduce risk.
When you likely need an audit
You don’t need a heavy audit for every AI feature. Most teams engage when one of these is true:
Go audit-first if
- You’re preparing for enterprise procurement / vendor due diligence
- You’re launching to EU customers or expanding EU usage
- The system influences decisions about people (access, eligibility, ranking, profiling)
- You handle sensitive or large-scale personal data, or rely on multiple vendors
- You need a concrete roadmap with owners, effort, and implementation steps
DIY-first can work if
- Your system is early-stage and scope is well-defined
- Data flows are simple and vendor chain is short
- You need an initial “risk posture” and documentation draft
- You mainly want clarity before engaging an audit
US → EU launch: what changes
If you’re expanding from the US to the EU, the biggest shift is not “more paperwork”. It’s that buyers and regulators expect evidence that your system is controlled: traceability, oversight, risk management, and data governance.
What teams usually underestimate
- Vendor and subprocessors mapping (who touches data)
- Retention and logs (what you store, for how long, and why)
- Human oversight definition (who is accountable for decisions)
- Evidence for claims (monitoring, evaluation, change management)
Fast path to readiness
- Start with a quick assessment to identify risk drivers
- Run an audit to validate tier + obligations and produce an implementation plan
- Implement controls with your team or ours