Skip to content

Compliance & Security

A practical framework for GDPR and EU AI Act compliance

Compliance is not a stage where legal joins at the end. It is a constraint that has to be visible on the architecture diagram.

Published: Last updated: 7 min readNeuros Security · Security & Compliance

In short

How do you stay compliant with data protection law when using AI?

Compliance is built in three steps, all of them architectural decisions: produce a data flow inventory, place the system in a risk class, and run the model on-premises where required. If which personal data reaches which service is not written down, no compliance claim can be verified; and where the risk class comes out high, risk management, technical documentation and human oversight cannot be added later — they are designed in.

Most compliance questions in AI systems reduce to one: which data, for what purpose, goes where, and stays for how long?

How do you build a data flow inventory?

For every AI feature, input data, processing location, retention period and third-party sharing should appear in one table. That table is the shared ground for both the technical and the legal conversation.

  • Mask or pseudonymise personal data before it reaches the model.
  • Pin down the data processing agreement and retention policy with your model provider.
  • Make human oversight mandatory for high-risk use cases.
  • Persist decision rationales to satisfy explainability obligations.

Which risk class does an AI system fall into?

The EU AI Act classifies systems by risk level. Hiring, credit assessment and biometric identification fall into the high-risk category and require additional documentation.

When is running the model on-premises the right call?

Where data sovereignty is critical, a deployment running open-weight models on your own infrastructure is now viable both technically and economically.

EU AI Act risk classes and the obligations each brings
Risk classExample useObligation
UnacceptableSocial scoringProhibited
HighCredit scoring, hiring pre-screeningRisk management, data governance, technical documentation, record-keeping, human oversight
LimitedCustomer chat assistantTransparency: the user must know they are talking to an AI
MinimalSpam filtering, recommendation rankingNo additional obligation

Sources

  1. 016698 sayılı Kişisel Verilerin Korunması KanunuT.C. Mevzuat Bilgi Sistemi · 2016
  2. 02Kişisel Veri Güvenliği Rehberi (Teknik ve İdari Tedbirler)Kişisel Verileri Koruma Kurumu · 2018
  3. 03Regulation (EU) 2024/1689 — Artificial Intelligence ActAvrupa Birliği Resmî Gazetesi · 2024
  4. 04Regulatory framework for AIAvrupa Komisyonu · 2024
  5. 05AI Risk Management Framework (AI RMF 1.0)NIST · 2023

Frequently asked

Questions we get asked

The inventory answers four questions: which personal data is collected, on which legal basis it is processed, where it goes and how long it is kept. In practice the third is hardest — data reaches more places than expected in most organisations: log records, analytics tools, backups and support systems. An inventory that omits those paths comes up short in an audit.

It does not mean the system is banned but that it becomes documentation-bound. In the high-risk class a risk management process, data governance, technical documentation, record-keeping, transparency and human oversight all become mandatory. Every one of those requirements touches the architecture, which is why leaving the classification to the end of development means rewriting a finished system.

No; the need is set by the data type and the transfer conditions. On-premises is the right call when special-category personal data is processed, when data may not cross a border, or when the system must keep working during an outage. In other cases region choice, encryption, access rights and retention can be settled contractually. The decision belongs before the architecture starts.

Let's discuss this with your team

We can run a technical session to translate any of this into your own context.