How an EU Company Legally Uses a US AI Vendor (the Part Everyone Skips)

By Konstantinos Karamatzianis · Co-Founder, Dabster Labs · Client engagement, anonymised at the client’s preference

The situation

A Cyprus training provider that serves financial-services firms had done the sensible thing: it used AI across its daily work, drafting outreach, triaging inbound mail, tagging courses, and it had the vendor’s terms of service on file. On paper, covered. In reality the legal substrate underneath was missing. Every AI call that carried a customer’s name was a transfer of personal data to a US processor, and none of the machinery EU law expects, a lawful basis on record, a transfer assessment under the Schrems II ruling, a way to honour someone’s right to object, was actually in place. The day a regulator or a corporate client asked “show me your controls”, there would have been no answer. For a company whose own clients are regulated, that gap was a liability.

What we built

A complete compliance layer over the AI, designed as nine controls on a single matrix, so that any regulator question maps to exactly one row. Where is your audit log? Row three. Show me your transfer mechanism? Row five. The controls span the three bodies of law that apply to a small EU company using a US AI vendor: GDPR, the Schrems II transfer rules, and the EU AI Act. The centrepiece is technical, a layer that strips personal data out of every AI request before it leaves the building and restores it on the way back, so the vendor never sees a readable name. Around it sit the documents regulators ask for first, including a Transfer Impact Assessment that most businesses do not know they need.

What changed

• Answer-readiness. When a financial-services client sends a due-diligence questionnaire, or a regulator asks how AI is handled, there is a documented answer instead of silence.
• The right to object works in one click. A single flag on a contact makes every AI workflow refuse to process that person, reversible and logged, rather than a promise nobody can enforce.
• The US-transfer problem is closed. A Transfer Impact Assessment, the document the Schrems II ruling made mandatory and almost everyone forgets, is written, signed and on file, so the AI calls rest on solid legal ground.
• Proof without exposure. Every AI call leaves an audit line that proves personal data was stripped, using hashes and counts, never the data itself, so the evidence exists without creating a second place the data lives.
• The frame is reusable. Once the architecture exists, each new AI feature drops into the same controls at marginal cost, instead of reopening the compliance question every time.

How it works

Every internal AI integration routes through one middleware layer. Before a request leaves, known names and organisations are swapped for opaque tokens, and a set of pattern checks catches anything else, emails, local ID and bank formats, phone numbers, so that readable identifiers are stripped before they reach the vendor. The response comes back with the tokens still in place and the layer restores the real values locally, from a mapping held in memory for that one request and never written down. Sitting around that are the organisational controls: a processing register, the vendor agreement and transfer clauses, a signed internal AI-use policy that also discharges the AI Act’s staff-literacy duty, and the Transfer Impact Assessment that ties it together.

Where it stands

Live across the company’s AI-assisted work. The technical build was one focused session; the paperwork that wraps it took longer, as signatures do. The result is AI that is useful day to day and defensible on demand, which for a business whose clients are themselves regulated is not a nice-to-have, it is the price of using AI at all.

Using AI in a regulated business, or selling to clients who are? We build the compliance layer that lets you say yes to the due-diligence questionnaire. Book a free audit and we will show you where the gaps are.

How the data actually flows

The distinction that makes this lawful is simple once you see it: almost nothing personal ever leaves the EU, and the small amount of text that does has already had its personal data minimised, to the extent technically feasible, before it is sent.

What stays inside the EU boundary: the CRM, its database, every uploaded file and the workflow engine all run on EU-hosted infrastructure. Personal records sit there at rest and are never copied to the vendor. The provider is the controller of that data; the platform operator acts as processor (GDPR Art.4(8)).

What actually crosses to the US vendor: when a task genuinely needs the language model, the request first passes through a PII egress sanitizer that wraps every model call, including tool-call payloads. Names, emails, phone numbers and other identifiers are removed or replaced before the prompt is sent. What travels is sanitized text: the instruction and the minimum context needed to complete the task, and as little as possible that could identify a person.

What comes back: the model returns text, which is written straight back into the EU-hosted CRM. Actions that would touch a person’s record are held for human approval (GDPR Art.22) rather than executed automatically, and error logs redact PII so nothing personal leaks through the diagnostic path either. The model sees a job to do, not a data subject.

The controls we put in place

• Data-processing agreement with the vendor. The US AI vendor is engaged as a processor under a signed data-processing agreement that defines purpose, retention and the processor role before any traffic flows.
• Standard contractual clauses for the transfer. The transfer to the US rests on the EU standard contractual clauses incorporated into that agreement, the mechanism that gives the transfer a lawful basis.
• Transfer impact assessment. A written transfer impact assessment documents the non-EU model calls: what is sent, why the sanitizer minimises the personal data that could travel, to the extent technically feasible, and the residual risk that remains after the clauses and the sanitiser are in place.
• Data minimisation. The egress sanitizer enforces minimisation at the point of the call, and a daily retention purge (GDPR Art.5(1)(e)) clears data that is no longer needed. Right-to-erasure (Art.17) and export (Art.15/20) are handled inside the EU CRM, so a request never has to reach across the border.
• EU-hosted orchestration. The workflow engine, CRM, database and file storage all run on EU-hosted infrastructure. The model is a stateless step called from inside that boundary, not the place the data lives.

Built with

• A self-hosted, EU-hosted workflow orchestration engine (n8n) for the pipelines
• A self-hosted open-source ERP/CRM platform as the system of record
• PostgreSQL and MariaDB for storage, running inside the EU boundary
• Docker on EU-hosted Linux infrastructure
• Python and Node services, driven by cron, REST APIs and webhooks
• A frontier LLM accessed as a stateless step, under a data-processing agreement, behind a PII egress sanitizer
• SMTP for notifications and human-approval hand-offs

This case study describes the technical and documentation layer we build. The legal instruments themselves, the data processing agreement, the standard contractual clauses and the transfer impact assessment, should be reviewed by qualified counsel before you rely on them. Nothing here is legal advice.