Blog

What to Fear with AI – and What Not To

A schematic view of data protection when using AI: data flows, a local model and an enterprise service.

The subject of data protection and AI leaves me a bit grouchy. It is another observation from the October “AI Transformation of Healthcare” conference. We fear something that almost never happens in practice, we overlook what actually can happen, and we fail to see what we are missing out on.

The risk that gets repeated over and over is that sensitive data will become part of a model’s knowledge and someone will extract them from it. That concern is debatable. A language model can be seen as a form of lossy compression: pulling specific training data back out, one-to-one, is rare and takes a specialized attack.

In our “cloud laboratories” — read: on a single virtual machine — we tried this on 25 October 2026 with Llama 3 8B. No chat template, temperature set to zero, so the result could be reproduced.

First we gave the model the beginning of a sentence from the U.S. Declaration of Independence, a text that exists in countless copies on the internet. It completed it word for word, all 48 words. Then the opening of Mácha’s Máj, a famous Czech romantic poem by K. H. Mácha, well known here but far rarer in global training data. It did not finish the poem. It went its own way: after “první máj” (“the first of May”) came “první červen – první červenec” (“the first of June – the first of July”). Finally, the start of a fictional discharge report the model could never have seen. It invented a diagnosis and then got stuck in a loop on a date.

This is not an accident. Meta reports over 15 trillion training tokens for Llama 3; the weights of the 8-billion-parameter model come to around 16 GB, three orders of magnitude less than the text itself would occupy. Most of the verbatim information therefore has to be discarded. This is not proof that a model remembers nothing. It is a demonstration. It recalls verbatim mainly what it has seen many times. A unique record it will not repeat; it invents its own — and that is a different risk, because the output can look like a genuine document. Targeted attacks in the literature have managed to extract even rarer texts from models, sometimes including personal data.

Our test of 25 October 2026 on Llama 3 8B. Only a frequently repeated text was recalled verbatim; for the fictional report, the model invented a diagnosis.

The greater risk is therefore the flow of data itself, and its short-term storage at the provider, should a breach and a leak occur there.

But the enterprise services of the major providers do not, as a rule, train on customer data, and retention can be limited by contract, with a number of services down to zero. That is precisely so they can minimize risk and ease customers’ concerns. Running models locally may look like the answer. But which of us has our own security team, patches around the clock and watches access better than Microsoft or Google? According to the IBM Cost of a Data Breach 2026 report, 30% of breaches involved data in companies’ own infrastructure, and 23% in the public cloud. On-premises infrastructure is not automatically safer.

What we lose when we do not use AI

I would like the debate to turn towards how we map and use the options we probably already have in the company — typically Microsoft Azure, Google Vertex or AWS — or how we find and contract AI services at enterprise level. It would help to start with the question of what we lose when we do not use AI, and not only with everything that might go wrong.

Every day that we do not have AI, or cannot have it, someone else in our field is profiting from it. According to Eurostat, in 2025 at least one AI technology was used by 17.6% of enterprises with 10 or more employees in the Czech Republic and by 42% in Denmark (dataset isoc_eb_ai). The same GDPR applies in both. Among EU firms that had considered AI but do not use it, 52.7% cite concerns about data protection and privacy. At best, then, we are not developing our own potential; at worst, over time, it could cost us our existence.

And once something as useful as AI is available, people will find a way to benefit from it anyway. Then you have shadow AI, ready-made.

Three layers of the debate: what we fear, what can actually happen, and what we miss out on when we do not use AI.

Which data belongs where

It does not have to be complicated. Just three levels, and a clear rule for what may go to each.

A public service, typically a private account in a browser, is no place for patients’ or customers’ personal data, trade secrets, credentials or sensitive internal documents. A general description of a problem, or a public text, often is. This is exactly where people will turn if the company offers them nothing else.

An enterprise cloud service, ideally with storage in the EU, contractually barred from training on customer data and with short or zero retention, can already take ordinary internal work: drafts, analyses, summaries. Not everything belongs there either. But it is a place where the risk of data flowing out can be handled by contract and configuration, not by a ban.

A local model on your own machine or on your own network makes sense where the data should not leave the company at all. Not because it is automatically safer, but because the data do not travel outside. Patching, access and operations are then our responsibility.

That also includes an agreement on who will check the result before it is used for real. Responsibility stays with the person, not the model.

So the question is not whether to be afraid of data, but how to sort them when working with AI.

The obligatory question at the end remains the same: where you are, are you still asking “whether to use AI at all”, or already “which kind, and on what terms”?

I published a shorter version on LinkedIn on 29 October 2026.