Does Your App Even Need to Be GDPR Compliant?

You collect email addresses. There is a contact form, probably some session logging, and a database you did not configure by hand. The app works, customers are using it, and GDPR has been sitting in the back of your mind for months as a European problem for companies with legal departments.

That last part is the bit worth checking, and it takes about two minutes.

This post is not legal advice. It is a way to work out whether you have a question worth taking to someone qualified, which is a different and much cheaper thing to find out.

Does GDPR apply to a small business?

There is no size threshold, no revenue threshold, and no exemption for being early. GDPR applies whenever you process personal data belonging to people in the EU or EEA, and processing covers storing, viewing, transmitting or analysing it. Jurisdiction follows the person whose data it is, not your company's address.

So the applicability question is genuinely simple, even though everything downstream of it is not.

If all three land on yes, the regulation reaches you and the useful next step is a conversation with someone qualified. If any of them is a clear no, you probably have less to think about than you feared, which is a legitimate outcome of asking.

This is a threshold check, not a legal analysis. Edge cases are real: passive traffic from Europe that you never marketed to, business-to-business data, and special categories like health information all change the picture, and they are exactly the cases where a general article stops being useful.

Who is responsible for GDPR compliance in a small company?

You are, if you are the one deciding what gets collected and why. That makes you the controller, and controller accountability does not transfer to the vendors who handle data on your behalf. They are processors, they carry their own duties, and your responsibility for the decisions stays where it started.

That answer surprises people, so it is worth being blunt about two versions of the question.

Not having a data protection officer does not move the responsibility, because most small companies are not required to appoint one in the first place.

And using a service that markets itself as compliant does not move it either. Your processors owe you certain things, including a written agreement covering what they may do with the data, but the obligation to have that arrangement in place is yours.

What did a regulator actually say about AI apps?

On 29 May 2026 the Belgian data protection authority's inspection arm published what it saw after investigating one conversational AI smartphone app. Its observation, hedged carefully, is that organisations building these apps sometimes get to their formal data protection obligations only after the product work is done.

On 29 May 2026 the Belgian Data Protection Authority's Inspection Service published a short account of what it saw after investigating a conversational AI smartphone app.^[1] It observed that organisations developing or operating such apps "sometimes focus heavily on product development, user experience and scalability, while formal data protection obligations are only fulfilled in a structured way later on."

Read that carefully. It is an observation with a hedge in it, from an inspection of one app. There is no fine here, no sanction, and no company named. What makes it worth your attention is who is saying it and what they say next.

The same note says technical safeguards only form a complete whole when they are demonstrably based on a prior impact assessment. And it lands directly on the thing an AI-built app does without being asked: it flags that when conversations are retained, analysed, "shared with external providers or used for model retraining," people have to be told clearly.^[1]

The scope is honest and narrow. This was chatbots and conversational AI, not every AI-built app. The overlap with what you built is your judgment to make, and if your app sends user input anywhere near a model API, the overlap is not small.

Where do AI-built apps create data flows nobody designed?

In the parts you never opened. This is the real reason the question is harder now than it was three years ago, and it has nothing to do with the regulation changing, because it has not.

When an AI tool scaffolds an application it makes infrastructure decisions on your behalf, quickly and without narrating them. Where the database sits and in which region. Which analytics or email service got wired in. Whether user input travels to an external model API, and what that provider does with it afterwards.

Each of those is a place personal data goes, and each one is a relationship that may need a written agreement behind it. The regulator's note names this too: it observed that role allocation across complex AI ecosystems "is not always obvious," and that a lack of clarity there often produces gaps in contractual arrangements.^[1]

The scaffold built the data flow. The accountability for it landed on you, and mapping it is the work.

Does being small or US-based change any of it?

Not the applicability question, no. Size has no bearing on whether the regulation reaches you, and neither does where your company is registered. Both change other things, including which specific duties apply and how data may travel afterwards, but neither one decides whether you are in scope.

On size, the regulation has no revenue or headcount threshold for whether it applies. Some individual duties do scale, including a record-keeping derogation for organisations under 250 employees in certain circumstances, so it is not true that nothing changes with size. What does not change is whether you are in scope.

On location, the trigger is where the person is, not where you are. US-incorporated and US-marketed does not put you outside it if Europeans hand you their data.

Your customers being US companies does not settle it either, because their employees and their own end users are people too. Where data travels once you hold it is a further question with its own rules, and it is one to raise with counsel rather than settle from an article.

One adjacent thing, kept deliberately brief because it is a separate regime. The EU AI Act is not GDPR. Its transparency obligations began applying on 2 August 2026, including a duty to tell people when they are interacting with an AI system.^[3] If your app has a chatbot, that is a second question to ask, not a restatement of the first.

Is there a GDPR certification that proves compliance?

Not the way the search results imply. The regulation does provide for certification schemes and approved ones do exist, but the text is unusually direct about what one is worth, and it is not what a badge-shaped search result suggests.

Article 42 states that certification "shall be voluntary" and that a certification under it "does not reduce the responsibility of the controller or the processor for compliance with this Regulation."^[2]

There is no badge that clears you, which is the honest reason this post is a decision guide rather than a checklist. A checklist implies a finish line. What actually exists is a set of obligations that attach to decisions you have already made, some of which were made by a tool on your behalf while you were shipping.

Where that leaves you

If the three questions all landed on yes, you have something to look at. The next move is a proper look at your actual data flows rather than a weekend spent reading regulation summaries. Someone qualified can map where data goes, name who your processors are, work out your lawful basis, and tell you what remediation is proportionate for a company your size.

If they did not all land on yes, you have your answer and you can stop thinking about it.

Either way the underlying situation is the same one that shows up everywhere else in an AI-built app: the tool made real decisions on your behalf and did not write them down. We wrote up the wider version of that problem, and the payment-data version of this same question if money moves through your app too.