GDPR-compliant hosting for AI-generated apps: what SME teams actually need to check

Somewhere in your company, someone on a non-engineering team vibe-coded a real tool with Lovable, Bolt, or a similar AI tool. It works. People use it daily. And there’s a good chance nobody in IT or compliance has ever reviewed it.

That’s not a hypothetical. It’s the default outcome of a genuinely good thing: AI tools let non-developers ship working software in a weekend. The gap is that “working” and “compliant” are different bars, and the second one doesn’t announce itself until an auditor, a customer’s security questionnaire, or a data subject access request asks about it.

The questions a compliance officer will actually ask

If you’re the one who has to answer for one of these tools, here’s what typically comes up, and why each one matters.

Where does the data live? Moving personal data outside the UK or EU adds extra legal steps under GDPR. Most AI-tool platforms default to US-region hosting. If you don’t know where your tool’s database physically sits, that’s the first thing to find out.

Is there a signed DPA? A data processing agreement is required any time a third party handles personal data on your organization’s behalf. A platform’s generic terms of service are not the same thing. A DPA names your organization directly.

Who’s accountable for a breach? GDPR gives you 72 hours to report a personal-data breach once you know about it. That clock doesn’t pause just because nobody’s sure whose job it is to notice the breach.

What’s the retention policy? GDPR asks you to state what data you keep, why, and for how long. Most AI-built internal tools have no answer to this, because nobody set a policy when the tool was built in an afternoon.

Is there a named person responsible? Not a platform’s support queue — an actual person inside or contracted by your organization who can answer for this tool if something goes wrong.

The pattern we see

Across the vibe-coded apps we’ve audited, the same gaps show up whether the builder is a solo founder or an internal team lead: no data residency decision was ever made, the platform’s standard terms got treated as a DPA without anyone checking, and no one person is accountable if the tool breaks or leaks data. None of this means the tool is unsafe to keep using. It means nobody’s checked, and “nobody’s checked” is precisely the fact a regulator or a customer’s due-diligence team will not accept as an answer.

What to do about it

1. Inventory. List every AI-built tool in active use, who built it, what data it touches.
2. Check data residency and DPA status for each one, using the questions above.
3. Fix the gaps — this is either a quick internal cleanup or, if several tools need it, worth doing as a single engagement rather than one at a time.

If you’d rather have someone else run this inventory and fix what it finds, get a free inventory-and-risk audit on one tool to start, or see how we handle it end to end on our for-SME page.

FAQ

Does this apply to a tool with no customer data, just internal data?

Yes, if that internal data includes anything about identifiable people — employee records, internal contact details, anything like that. GDPR covers personal data generally, not just customer-facing data.

We already have a DPA with the platform we host on. Isn’t that enough?

Check whether it actually names your organization and covers the specific processing your tool does, or whether it’s the platform’s generic terms with “DPA” in the title. The two are not always the same document.

How long does an inventory-and-risk audit take?

The same 48 hours as our standard free audit, applied to one tool. If you have several tools to check, that’s the Enterprise Shadow-App Cleanup engagement, scoped after the first audit.