Data security when implementing AI

Data security in AI is decided at the architecture stage, not after launch. You need answers to eight questions: which data enters the model, where it is processed, who has access, what remains in logs and for how long, which GDPR roles apply, what happens in an incident, and whether the user knows they are speaking with AI.

Legal position of this section: August 2026. This is an implementation checklist, not individual legal advice.

“The model provider has a good privacy policy” is not an answer to any of them.

1. What data actually needs to enter the model?

One of the core safeguards is minimisation: do not send what is not needed to complete the task.

In practice, this means three techniques:

• Narrowing the context. A model that classifies a ticket may not need the customer's entire history. A well-built RAG retrieves only the relevant, smallest possible source scope needed for an answer — reducing both data exposure and processing cost.
• Masking identifiers. A PESEL number, contract number, or surname can be replaced with a marker when the task does not require its meaning. The mapping that allows data to be restored still needs protection and handling under the appropriate classification; pseudonymisation is not the same as anonymity.
• Splitting the task. The part that requires sensitive data can remain in code, while only the fragment requiring text interpretation goes to the model. Whether this separation is feasible and worthwhile depends on the process and the cost of an error.

2. Where is the data processed?

Three options, each with real consequences:

Option	Control	Cost	When we choose it
Commercial model through the provider's interface	contractual	often low at the start	when the service terms, location, and data-sensitivity level meet the process requirements
Commercial model with processing in a selected region	contractual plus a location requirement	medium	when compliance requires a specific processing location
Open model on your own infrastructure	greater, technical	high	when data requirements are strict and the team can secure the whole stack

This is a business, legal, and technical decision that must be made before production data is launched. Changing provider or model later may require renewed quality testing, integration work, and safeguards. We break down the selection criteria in what an LLM is and how to choose a model.

3. Will the data be used to train the model?

There is no single answer for “AI.” Check the terms of the specific interface, plan, and settings: the purpose for which data is used, retention, provider-staff access, processing location, and the option to disable storage. These provisions may differ between a consumer and business product from the same provider.

A practical rule: record it in the supplier agreement and implementation documentation, not in an email. If the contractor cannot point to where it is governed, it has not been decided.

4. Who has access to what?

One high-impact risk in RAG implementations and internal assistants is overbroad access: the system retrieves material the person asking should not be able to see. The model may then disclose contract terms or another fragment beyond the user's permissions.

Permissions must operate at the retrieval layer, not the answer layer. In other words: the system must not retrieve fragments the requester cannot access — not retrieve them and then politely omit them. Filtering after the fact is an illusion of security, because the model has already received that data in its context.

This leads to a less obvious conclusion: an AI system must not grant broader access than its sources, and may sometimes need to narrow it further. If no one in the company knows who is entitled to which folder, those rules need to be resolved before the assistant is made available to users.

5. What remains in the logs?

Logs are necessary — without them, you cannot diagnose an incorrect answer or detect abuse. At the same time, logs are another copy of data in another location.

Decisions we make explicitly at the outset:

• what we log: full prompts and answers, or only metadata and source identifiers;
• how long we retain logs;
• who can access them;
• whether logs follow the same retention rules as the source data.

A log stored without an end date is a liability, not an asset.

6. GDPR in practice - what needs to be decided

Without turning this into a legal lecture, here is the practical list of points we close in our implementations:

• Purpose and legal basis for every type of data and every use case.
• The parties' roles. A controller determines the purposes and essential means of processing, while a processor acts on its behalf — you cannot assume the roles solely from a contract label. The EDPB Guidelines 07/2020 are useful here.
• Documentation and risk assessment. A record of processing activities, data protection impact assessment, or data processing agreement may be required depending on the role, scale, and risk of the specific process — not automatically in every project.
• Transfers outside the EEA — whether they occur and which legal mechanism they rely on.
• Fulfilling data-subject rights. You need to be able to find, correct, or erase the relevant records in the index, logs, and copies in line with the applicable retention periods; a full index rebuild is not always necessary.
• Minimisation and retention. The system receives only the data needed for the purpose and does not keep it indefinitely.

We are not a law firm and do not pretend to be one. We are responsible for ensuring that the architecture can meet these requirements; your lawyer or data protection officer performs the legal assessment.

7. What happens when something goes wrong?

Three scenarios that need an answer before implementation:

• The model gave an incorrect answer and someone made a decision based on it. Who will notice, and how? That is why we retain a “the system suggests, a human approves” mode for matters involving risk.
• Someone tried to extract data from the system that they are not entitled to access. Is there a log? Is there an alert?
• The model provider had an outage or changed its terms. Can you switch to another model without rewriting the system? This brings us back to an architecture designed for interchangeability.

8. Does the user know they are talking to AI?

From 2 August 2026, the main part of the EU AI Act applies. Article 50 requires a system intended for direct interaction to inform the person that they are interacting with AI, unless this is obvious from the circumstances and context of use. The information must be clear and provided no later than at the first interaction; the full scope of exemptions and responsibilities is set out in the text of Regulation (EU) 2024/1689.

In practice: name the automated system in the interface, provide an easy route to a human, and do not design the interaction so the user mistakes the system for an employee. Additional obligations may follow from the sector and type of use, so a lawyer or data protection officer should approve the assessment before the solution is released.

What technology cannot solve

Honestly, because this is often left unsaid:

• You cannot completely secure a model with a prompt. An instruction such as “do not disclose confidential information” is guidance, not a safeguard. The safeguard is that the model never received that information.
• You cannot guarantee that a model will never make a mistake. You can reduce the frequency and impact of errors through grounding, testing, permission controls, and approval gates.
• You cannot settle accountability with one sentence in terms and conditions. Controller and processor roles arise from the parties' actual influence over the purposes and means of processing; they must be determined for the specific data flow.

Frequently asked questions

Is it safer to run the model yourself?

In terms of control over data — yes. In terms of real-world security — not necessarily, because it also means maintaining servers, updates, and infrastructure security: work you must do yourself. Running your own model shifts risk; it does not make it disappear.

Can an assistant on the website extract our internal data?

It can if the public path has access to an internal source or if the permissions filter is flawed. That is why public and internal assistants should have separate sources, technical identities, permissions, and tests for data-extraction attempts.

Who on our side needs to be involved?

You need someone who knows the process and — depending on the data and risk — a person responsible for data protection, security, or compliance. We lead the technical work, while the client's process owner approves the purpose and scope of data use after taking legal and technical recommendations into account. Formal roles and responsibility need to be determined from the parties' actual influence over the purposes and means of processing, not just the title used in the agreement.

---

We settle security before the first line of code, during the design and planning phase, not after implementation. If you have compliance requirements and are unsure how to reconcile them with AI, contact us or see LLM integrations.