GDPR-compliant hosting for AI-built internal tools
Someone on your team built a tool the whole company now runs on. We find it, secure it, and put a named, accountable engineer behind it.
Get a free inventory-and-risk auditWhy shadow AI apps are a real risk, not a formality
It usually starts small. Someone in ops or sales gets tired of a manual process, opens Lovable or Bolt on a Friday afternoon, and by Monday there's a working tool. It gets used. Then it gets relied on. Nobody files a ticket, because nobody thinks of it as "real" software, it's just the thing that replaced the spreadsheet.
That's the gap. The tool holds customer records, or employee data, or contract terms, the same categories of personal data your main systems are already careful with. But it's hosted wherever the AI platform's free tier put it, with whatever security policy the AI generated by default, and no data processing agreement covering what happens to that data. If a customer asks where their data lives, or an auditor asks for your record of processing activities, this tool is the one nobody can answer for.
It's not a hypothetical. AI builders like Lovable and Bolt commonly scaffold apps with row-level security left off or misconfigured, which means the database is more open than anyone realized. Add a US-hosted backend by default, no signed DPA, and a backup policy nobody's tested, and one internal tool can be the weakest point in your entire compliance posture, not because anyone was careless, but because nobody was ever assigned to own it.
What a typical inventory turns up
Every team is different, but the same handful of gaps show up again and again in an internal AI-built tool that's never had a formal review:
- No data processing agreement. The tool processes personal data on the company's behalf, but there's no signed DPA naming who's responsible for it, which is what UK/EU GDPR requires.
- A privileged key sitting in the frontend. A database key that should stay server-side, readable by anyone who opens the browser's developer tools.
- Backups that have never been restored. Something runs on a schedule, but nobody has ever tried pulling the data back out to confirm it works.
- Data hosted outside the EU by default. The platform's default region, not a deliberate choice, which complicates a straight answer to a customer's security questionnaire.
- No one person accountable for it. The person who built it may have moved teams or left. If it breaks at 6pm on a Friday, there's no on-call, just whoever notices first.
None of this means the tool is a mistake. It means it grew past the point where "nobody's watching it" was an acceptable answer, and it's due the same operational discipline as anything else that touches customer data.
What you get
A signed DPA
A real data processing agreement, backed by a UK/EU-reachable entity with a rehearsed breach-response runbook, not a template PDF.
EU data residency
Your own Postgres database, hosted in the EU, with tested backups: a straightforward answer to your next security questionnaire.
A named human
One accountable engineer for every tool we take on, not a rotating support queue nobody in your org can name.
How it works for an SME team
- 1. Free inventory-and-risk audit. We check one vibe-coded tool your team already relies on: the same 15-point production audit we run for individual founders, applied to your internal tool.
- 2. Enterprise Shadow-App Cleanup. If you have more than one such tool, our fixed-scope rescue inventories all of them, fixes what's broken, and produces GDPR records-of-processing documentation and a signed DPA. See rescue services.
- 3. Ongoing managed hosting. Each tool converts to its own flat-rate subscription. See pricing.
FAQ
What is a shadow AI app?
An internal tool someone on your team vibe-coded with an AI tool like Lovable or Bolt, that your IT department never reviewed, provisioned, or signed off on. It runs on someone else's hosting, with someone else's idea of security.
Do we need a DPA for an internal tool?
If the tool processes any personal data (customer records, employee data, anything identifiable), yes. A data processing agreement is required under UK/EU GDPR wherever a processor handles that data on your behalf.
What does "EU data residency" actually mean here?
Your database and backups are hosted on EU servers, not routed through a US platform's default region. That matters for GDPR data-transfer rules and for straightforward answers to a customer's security questionnaire.
How do we even find out how many of these tools exist?
Most teams don't know the real number until they ask around. Start with the one everyone already mentions when this comes up, the spreadsheet-replacement tool, the client portal someone built over a weekend. The free audit covers that one first; if there are more, the Enterprise Shadow-App Cleanup inventories the rest.
What happens if we do nothing?
The tool keeps running on whatever hosting and security settings it started with. If it holds personal data with no DPA and no tested backup, that's the exposure a regulator or an auditor asks about, not hypothetically, on the next compliance review.
Do you fix bugs in the app itself?
No. We run the infrastructure: servers, deploys, backups, monitoring, incident response, the DPA and EU hosting underneath it. We don't rewrite the app's logic or add features. If the tool works but nobody's watching what it runs on, that's exactly what this covers.