EU AI Act, August 2026: what changes and what pseudonymized prompts do for you

On 2 August 2026 the next large block of the EU Artificial Intelligence Act starts to apply. Most of the attention goes to providers of high-risk systems, but the date also matters for ordinary teams that paste documents into hosted models: transparency duties become concrete, and the GDPR continues to apply to every prompt that contains personal data. This post gives a plain summary of what applies from August 2026, explains how the AI Act and the GDPR interact, and looks closely at what pseudonymisation, the technique of replacing identifiers with labels, actually achieves under the GDPR. The legal points are kept general; the details vary by role and sector, and the texts are the authority.

The AI Act timeline in brief

The AI Act (Regulation (EU) 2024/1689) entered into force in August 2024 and applies in stages. At the time of writing the main milestones are:

Date	What applies
2 February 2025	Prohibited practices (Article 5) and AI literacy duties (Article 4)
2 August 2025	Obligations for providers of general-purpose AI models (GPAI), governance structures, penalties
2 August 2026	Most remaining provisions, including obligations for high-risk systems listed in Annex III and the transparency obligations of Article 50
2 August 2027	High-risk obligations for AI in regulated products (Annex I) and extended deadlines for some GPAI models

The European Commission has published guidelines and a code of practice for GPAI providers, and has been preparing guidelines on the Article 50 transparency obligations. Timelines and details have been the subject of proposals to adjust them; check the current state of the legislation and the Commission's guidance before relying on a specific date. The Commission's AI Act page is the place to start, and the full text is on EUR-Lex.

What August 2026 means for the everyday user of AI

Three points are relevant if you are not a provider of a high-risk system but a team that uses hosted models on documents:

High-risk uses (Annex III). If AI is used in areas such as employment decisions, credit scoring, education, essential services or law enforcement, the system's provider and deployer take on obligations: risk management, data governance, human oversight, logging, transparency to the people affected. A team that runs CVs through an assistant to rank candidates should ask whether it is now a deployer of a high-risk system.
Transparency (Article 50). Providers must ensure that people know they are interacting with an AI system where that is not obvious, and that certain AI-generated content is marked as such. Deployers have duties for deepfakes and for AI-generated text published to inform the public on matters of public interest. Guidelines are being prepared to clarify the practical details.
GPAI transparency. Providers of general-purpose models have had documentation and copyright-policy duties since August 2025, which indirectly means more published information about how models are trained and what data is used.

None of these replace data protection law. Which brings us to the second regulation.

The GDPR applies at the same time

The AI Act says explicitly that it does not affect the GDPR. Any prompt, upload or agent workflow that involves personal data remains processing under the GDPR: it needs a lawful basis, must respect purpose limitation and data minimisation, must be transparent to data subjects, and, if the provider is outside the EEA, must comply with the transfer rules. The AI Act adds obligations for certain uses; it does not lower the GDPR bar for any of them.

In practice this means a compliance question about "using AI on this document" is usually two questions:

Does the AI Act classify this use, and if so what does that require?
What personal data is in the document, and is this processing lawful under the GDPR?

The second question is where most teams have direct control, and where pseudonymisation helps.

What pseudonymisation is under the GDPR

Article 4(5) GDPR defines pseudonymisation as processing personal data in such a way that it can no longer be attributed to a specific person without the use of additional information, provided that this additional information is kept separately and protected by technical and organizational measures. Replacing "Jane Doe" with "Person 1" and keeping the table that links the two on your own device is a textbook example. The GDPR names pseudonymisation as an appropriate safeguard in several places (for example in Article 25 on data protection by design and Article 32 on security).

Recital 26 draws the line that matters: pseudonymised data that could be attributed to a person by using additional information is still personal data. Only information that does not relate to an identified or identifiable person, or that has been anonymised so that the person is no longer identifiable, falls outside the Regulation.

What pseudonymisation does and does not do

It helps to be precise, because the technique is sometimes oversold.

What it does:

Removes identifiers from what the provider receives. If the mapping table stays local, the model, its logs, its training pipeline and its human reviewers see labels, not people.
Counts as a safeguard. It supports data minimisation and security by design, and it is a recognized risk-reduction measure in a data protection impact assessment.
Limits the damage of provider-side events. Retention windows, breaches and policy changes affect a document without identifiers far less.
Keeps the document useful. Consistent labels preserve who did what, which is why they beat black bars for AI tasks (see pseudonymization vs anonymization vs redaction).

What it does not do:

It does not turn the data into non-personal data for you. You hold the key, so the GDPR still applies to you and your processing.
It does not remove indirect identifiers by itself. A rare job title, a small town and a date can identify someone even without a name; review the output with that in mind.
It does not cover special-category content. A medical narrative about "Person 1" is still a medical narrative; consider removing such sections rather than labelling them.
It is only as good as the separation. Uploading the mapping table alongside the file, or pasting it into the same chat, undoes the safeguard.

Practical implications for teams pasting documents into models

Given the two regulations, a workable routine for teams looks like this:

Classify the use. Ask whether the task falls into an Annex III area. If it might, involve whoever owns AI Act compliance before proceeding.
Pseudonymise before sending. Replace names, companies, contact details and identifiers with consistent labels on your device. Keep the mapping table separate.
Use a plan with the right commitments. Prefer business or API tiers where the provider commits not to train on your content and defines retention; check the current terms.
Review indirect identifiers. Scan the pseudonymised text for combinations that still single someone out.
Keep records. Note what was shared, in what form, with which provider. Both regulations reward documentation.
Restore locally. Put the real names back into the answer on your device, not in the provider's chat.

Doing step 2 without another third party

Unformation performs the pseudonymisation entirely in your browser: no upload, no account, and you can verify with the Network tab or with Wi‑Fi off that nothing leaves the device. The flow is four steps: upload, choose a rule (labels, redaction, fake values, masks or hashes), review, download. The mapping table is exported as CSV or JSON and never leaves your device; the de-anonymizer applies it in reverse to an AI answer. Because the tool itself is not a processor of your data, it does not add a new party to your GDPR analysis. See security for the design.

Do it now

Open Unformation, drop the document you plan to send to a model, and download the pseudonymised copy plus the mapping table. If you work with Word files, start at the DOCX anonymizer.