---
title: "Protecting data in AI use: the choices that come before the architecture"
url: https://zerofive.ai/en/blog/compliance/protecting-data-ai-choices-before-architecture
canonical: https://zerofive.ai/en/blog/compliance/protecting-data-ai-choices-before-architecture
language: en
published: 2026-11-02
updated: 2026-10-29
author: "ZeroFive.AI"
tags: data protection, data classification, NIS2, GDPR, AI gateway, AI Rating
abstract: "Classification, destinations, residual risk and accountability: the choices to make before routing data to AI models, across GDPR, NIS2 and the AI Act."
---

# Protecting data in AI use: the choices that come before the architecture

**In short.** A scheme that routes every request to different models according to the class of the data only works if the company has already decided how to classify its data, where each class may be processed, which residual risk it accepts and who signs it off. Neither the GDPR nor NIS2 requires data to be processed in Italy, so a national perimeter for critical data is a risk choice that has to be justified in writing. The check covers the whole context that reaches the model, retrieved documents included, and carries on into responses and logs.

When we ask a company how it protects the data that ends up inside an artificial intelligence model, the answer we hear most often is the name of a tool, the licence for the assistant built into the productivity suite, or the contract with a provider that promises processing in Europe. That is useful information, though it describes what people work with and leaves out the step that comes first, namely who decided which data may enter which model, by what criterion, and who carries the risk of whatever gets through anyway.

If you look at the record of processing activities of many companies that use AI every day, the model providers are often missing, and when they do appear the purpose for which they receive the data is not stated. We know this gap from the inside too, because in the first months when we used different models for different jobs, our own rules about what to send where also lived in the heads of the people doing the work, and a rule that lives in someone's head cannot be checked or recorded.

The routing scheme we propose to enterprise clients, the one that sends each request to a different model according to the class of the data, is the visible part of the work and gets built quickly once the upstream decisions have been made. Those decisions are what take time, and they belong to the company and its board. Copying the architecture without making them leads to the same outcome as answering with the name of the licence, at a higher cost.

## Data classification

Everything starts with a classification, and it is a business decision before it is a technical one, because whoever is accountable for the data has to establish that a supplier contract is confidential or that patient records must not leave a given perimeter, while IT's job is to apply the rule so that it does not depend on people's memory.

In our projects we use three classes, each with a colour, because they have to be understood by the people who apply them every day without opening a manual. Green is data that is public or meant to become public, such as marketing material, documentation already released and regulatory texts. Yellow is confidential internal information, including information that contains ordinary personal data (a name, an email address, a role mentioned in minutes), which may leave the perimeter only after that data has been masked. Red is data that never leaves the chosen perimeter: the special categories of Article 9 GDPR such as health data, criminal records data, financial information on identified clients, trade secrets and information on the security of systems, which for a NIS2 entity is a target in its own right.

The line between yellow and red is where most classifications turn vague, and it should be written down with examples taken from the company's real documents, board minutes, a claims file, a sales proposal, a support ticket, each assigned to a class with the reason next to it. Two people reading the policy must reach the same class for the same document.

The class should be attached to the source, meaning the repository, folder or system the data comes from. Asking whoever writes the request to label it every time means entrusting protection to their attention in that moment, and attention in the moment is the first thing to give way on a busy day.

## Destinations and the regulatory framework

For each class you have to decide where it may be processed, and here we see mistakes in two opposite directions, those who think the contract with a large provider covers everything and those convinced that the law requires every piece of data to stay in Italy.

The GDPR requires personal data to remain within the European Economic Area or any transfer outside it to rest on an adequate basis, and it makes no distinction between a data centre in Milan and one in Frankfurt. NIS2, transposed in Italy by Legislative Decree 138/2024, contains no localisation requirement: in Article 24(2)(d) it asks for risk management measures that include supply chain security, and model providers are part of that chain like any other ICT supplier. Italy's AI law, Law 132/2025, lost during its passage through Parliament the provision that would have required systems used by public administrations to run on servers in Italy, and it now provides that public procurement may favour solutions that locate strategic data in data centres on national territory.

The Italian perimeter is therefore a risk choice, and like any risk choice it has to be justified in writing. There are sound reasons for making it: providers headquartered in the United States are subject to the 2018 CLOUD Act, which allows US authorities to request data held by US companies even when it is stored abroad; some sectors receive guidance from their supervisory authorities, or have clauses with their own clients, that point in that direction; for an essential entity under NIS2, reducing the number of jurisdictions involved makes incident handling simpler.

The choice has a cost. Frontier models are mostly used through the large cloud platforms, while Italian infrastructure offers open weight models on dedicated GPUs or zero-retention inference services, with performance that varies a great deal from task to task. The class scheme exists to pay that cost only on the data that justifies it: green and yellow may use the frontier model with processing restricted to European regions, red goes only to the infrastructure in Italy.

## Residual risk and who accepts it

None of these choices brings risk down to zero, and part of the work is describing what remains and having it formally accepted by whoever has the authority to do so.

Masking personal data in the yellow flow relies on detection systems that make mistakes, and a name spelt in an unusual way or a customer code in an unexpected format can slip through unmasked. Even when it works, masked data is pseudonymised data, and the Court of Justice of the European Union, in its judgment of 4 September 2025 in Case C-413/23 P, made clear that it remains personal for the controller who keeps the key to link it back to the person, while for a recipient with no reasonable means of doing so it may not be. For the company the yellow flow is therefore processing in every respect, with the provider appointed as processor, the record updated and the privacy notice naming it among the recipients, and the same judgment provides the argument for maintaining that what reaches the provider identifies nobody.

The European profile of cloud platforms ensures that processing takes place in EU regions, but a request can be served by any of them, so yellow data may pass through Dublin, Frankfurt or Stockholm. Anyone who has promised their own clients processing in Italy needs to know this before signing.

For an essential or important entity the question of who accepts this residual risk already has an answer in the law, because Legislative Decree 138/2024 gives the management and governing bodies the task of approving risk management measures and overseeing their implementation, with direct liability for those who sit on those bodies. The other roles need to be written down just as precisely: the data owner decides the class, the DPO checks consistency with the GDPR, the CISO is accountable for the security of the gateway and the providers, and the CAIO, where there is one, keeps the routing rules together and brings them to the board when they change. A one-page responsibility matrix is worth more than many procedures, because on the day of an incident the first question is who was supposed to decide.

## Context, response and log of a request

Almost every data protection scheme, the first version of ours included, reasons about the user's question, yet in the systems companies use every day the question is the least risky part of what reaches the model.

An assistant connected to the document archive adds the passages retrieved from documents to the question, an agent adds the results of the tools it calls, and a long conversation carries along everything written before it, so a harmless question about the holiday calendar can travel together with an extract from an employee's personnel file. The gateway has to classify the composed context, the one that actually goes out to the model after documents have been retrieved and tools called, assigning it the highest class among the sources involved.

The same care applies to the response, which can carry a red item retrieved from a source back in clear text and end up in a channel with weaker rules, an email to an outside party or a ticket shared with a supplier.

The gateway log, used for audits and incident notification, contains by design the data the system protects. It has to be treated with the highest class it records, and therefore kept inside the Italian perimeter, with access limited to those who need it and retention periods decided before it is switched on.

## Records, monitoring and people

A routing rule goes stale as soon as the company connects a new archive or adopts a different model, and with AI that happens often. The gateway therefore feeds two records that must be kept aligned: the record of processing activities required by the GDPR, which has to list new providers and new purposes, and a register of AI systems showing use case, data class, permitted destination and owner. The second also becomes the basis for the AI Act when a use case falls among the high-risk ones in Annex III, whose obligations apply from 2 December 2027 and require those who use such systems to keep logs for at least six months.

Alongside the records there needs to be a periodic review, on a schedule approved by the board, that looks at blocked requests and at the false negatives found in spot checks, and decides on new sources to connect. That is when the classification is updated for the new documents that have entered the flows in the meantime.

The gateway only protects the flows that pass through it. Anyone who finds the approved tool awkward opens a personal account on a consumer service, and there no classification applies. Article 4 of the AI Act, rewritten by the Digital Omnibus (Regulation (EU) 2026/1744), requires providers and deployers to take measures that support the AI literacy of their staff, without requiring a specific level to be guaranteed. A policy that tells each person which data they may use with which tool, backed by training built on the real cases of their own job, is the most concrete measure a company can document, while a policy people do not understand produces unauthorised AI, the one flow the log will never know about.

## The scheme that follows

With these choices made, the architecture almost draws itself, and it is the one we propose to enterprise clients handling regulated data.

![Red data does not cross the border: routing by data class between the Italian perimeter and EU regions, with the AI gateway, masking of yellow data and the log inside the perimeter](/schema-instradamento-dato-en.png)

Every request reaches the gateway with its context already composed, and the gateway reads the class of the sources, looks for personal data and applies the rule. Green and yellow may go to either destination, with yellow leaving for the frontier model only after masking, while red has a single route, the infrastructure in Italy on dedicated GPUs or through a zero-retention inference service. The log sits inside the Italian perimeter and feeds the records.

Building the gateway is technical work that is validated with a prototype and entrusted to people who know how to do it. The decisions that configure it can be tested with a few questions for your CAIO, or for whoever plays that role in your company:

- Who decided which data may enter a model outside the company, and where is it written down?
- Does the class come from the source of the data or from the choice of whoever writes the request?
- Does the check look only at the question, or at the whole context that reaches the model, retrieved documents included?
- In which regions are requests processed, and does that match what we promised our clients?
- Who formally accepted the residual risk, and when did they last review it?
- Where is the log kept, and who can read it?

When the answers come quickly and with a document in hand, the scheme is a consequence. When they come with the name of a product, there is a conversation to open at board level before an inspection or an incident opens it for you. In the Risk dimension of the AI Rating these are among the first questions we ask, and if you want to start there you can [book a call](https://calendly.com/fabiolalli/zerofive) or write to hello@zerofive.ai.