The GDPR+ approach and BYOK architecture

What this article is, and what it is not. It is a description of an architecture and a list of technical checks. It is not legal advice: your situation depends on your data, your purposes and your clients. We describe what the technology lets you observe; legal qualification is done with a legal professional.

Introduction: trust is not declared, it is observed

Most vendor "compliance" pages say the same thing: we take your data seriously, we respect the regulation, we are committed. Those sentences share one flaw — the reader cannot verify any of them.

An architecture, by contrast, can be observed. So the useful question is not "do they promise to behave?" but:

who holds the account with the AI provider, and therefore who controls the settings?

That question has a binary answer, and it decides everything else. That is the subject of this article: what a personal API key concretely changes, what it does not, and the six things you can go and verify yourself in ten minutes.

1. The shift that changes the nature of the problem

In a model where the vendor includes the artificial intelligence, they buy the capacity wholesale and resell it to you. Processing goes through their account, under their terms, in the region they chose. You inherit decisions you did not make and, most often, cannot read.

With a personal key, the account is yours. Four consequences, all observable:

• the contractual relationship with the AI provider is direct: you accept what you accept, and you can produce it;
• the processing region is a setting in your console, not information to request;
• the retention period is visible and sometimes configurable, from the same place;
• the training parameter on your content is read on screen, not believed.

The word that matters here is "observable". A contractual commitment is worth what its author is worth; a setting you can see is worth what the screen shows. The difference appears the day you are asked to prove it — not before.

The parallel economic reasoning is covered in sovereignty and cost control.

2. What "GDPR+" means here, in three principles

The "+" does not denote superior compliance — no such thing exists. It denotes three architectural choices made beyond what is required, because they reduce risk at the source.

Minimise before securing. The best-protected data is the data that was never sent. Before encrypting a flow, the question is: does this field need to leave? A process that only needs a product's text does not need the customer's name.

Make leaving easy. Portability is not only an obligation, it is a design test. An architecture you cannot leave with your data is an architecture that holds you — whatever its stated terms. The key being yours, the history is too.

Promise nothing you cannot show. This is the most binding principle for us, and it comes from a real mistake on our side: our pages publicly announced a facility our checkout did not create. We removed it from every page rather than maintain it. A promise that cannot be derived from a fact is a promise to withdraw, not to rephrase.

3. What the architecture does NOT do — the section missing everywhere

Three limits. Omitting them would be exactly the flaw the previous principle forbids.

It does not make you compliant. Controlling the parameters does not fill in your processing register, does not write your impact assessment, does not draft your notice to data subjects, and does not define your legal bases. Those are jobs in their own right.

It only covers the AI flow. Your forms, your analytics, your third-party scripts, your exports to a management tool all still exist and are not affected. On the consent side, see our approach to cookies.

It does not survive bad practice. A key shared across several clients, or dropped into a versioned configuration file, cancels most of the benefit. Sovereignty is a property of usage, not a property of the contract.

4. The six checks you can run yourself

None of them requires taking our word. Allow ten minutes.

• Open your AI provider's console and read the processing region actually in effect
• Check the training parameter on your content, and take a dated screenshot — the screenshot is the proof, not the memory
• Record the retention period for usage logs, and compare it with what your own notices state
• Verify there is one key per client, never a shared key
• Verify that no key sits in a versioned repository or in a web-accessible file
• Write down in three lines how you would retrieve everything and switch provider tomorrow morning

The sixth is the most revealing. If you cannot answer it, the question is not compliance — it is dependency.

5. The point professional buyers look at first

If you sell to organisations under regulatory obligations — healthcare, public sector, sensitive data — the AI provider question arrives early in their purchasing process, and it is eliminatory.

What they ask is almost never "do you have a policy?" but "where does the data go, under what contract, and how do you show it?". An architecture where the client holds their own account answers in one sentence, with a screenshot to back it. A pooled architecture answers with a document, which is not the same thing and does not get handled at the same level of the org chart.

This is not a marketing argument, it is a shorter sales cycle. And it is measurable: count the number of round trips between the question and the validated answer.

Conclusion

An architecture does not replace compliance, and no technical diagram excuses the legal work. What a personal key provides is more modest and more solid: the position from which you can verify without asking anyone's permission.

Trust built on a declaration must be re-evaluated at every change of vendor, terms or price. Trust built on an access does not need re-evaluating: you open the console, and you see.

The test that sums up the article: if you were asked today to prove where your clients' data goes, how many people would you have to contact to answer? If the answer is "none", the architecture is doing its job.

Further reading: sovereignty and cost control, our six commitments on responsible AI, why AIFORYA chose this model, and our alternative to Complianz. On the tooling side: analytics and consent — premium versions with a full refund within 14 days.