AI and Data Protection: Tools That Stay Offline
The question we're asked most often about AI is no longer what it can do. It's: What happens to our data in the process? The concern is justified – and it has a technical answer.
Executives have long understood the impact AI has; it's rarely about enthusiasm or rejection, but about very concrete concerns. First: data migrates unnoticed to third-party services, often bypassing IT. Second: what once ends up in a third-party model cannot reliably be retrieved. Third: every connection of a language model to existing systems creates an attack surface that didn't exist before. Then there's a fourth, separate consideration: ongoing costs arise, along with dependency on a provider who can change prices, models and terms at any time.
These concerns describe the situation quite accurately, and they can be backed up with figures.
Where the concern comes from
Data leakage can be quantified. In early 2023, Cyberhaven analysed the ChatGPT usage of 1.6 million employees: 11% of what employees pasted in at the time was confidential company data – source code, customer data, internal documents. Follow-up reports from the same provider show that this share has continued to rise since; in 2025 it stood at around a third across all AI tools. This mostly happens not maliciously but incidentally, often via private accounts, bypassing IT. Anyone using AI in their business without knowing the data pathway loses control over something they never consciously handed over.
What happens to this data afterwards is a subject of ongoing research. An overview article on the data security of large language models describes the spectrum from passive information leakage to targeted attacks that can retrieve training and input data. What once existed in a third-party system cannot reliably be retrieved.
What is usually underestimated is the connection itself: as soon as a language model is linked to other systems, an attack surface emerges that didn't exist before. A study of 36 real, production-deployed AI applications found that 31 of them were vulnerable – via injected instructions that get the model to do something other than intended. A more recent survey categorises over thirty such attack techniques into four categories, ranging from manipulated inputs to vulnerabilities in the protocols through which AI agents communicate with one another.
The deeper AI is embedded in ongoing operations and the more it is allowed to do there autonomously, the greater the attack surface and dependency become. This follows from the design itself and cannot be eliminated by choice of provider.
Where the AI sits makes the difference
Because this comes down to design, where the AI sits is what matters: for us, it's a tool in the workshop, not part of your business.
We use AI to build software – quickly, affordably, and at a quality that wasn't affordable like this three years ago. But what we deliver is the finished tool. And it runs without the internet, without a subscription, and without the AI provider we used to build it. It cannot send anything outside at all, because there is no pathway for that.
This difference results from the design itself and therefore does not need to be configured or contractually guaranteed: where no connection exists, none can be misused either. A tool without network access cannot be remotely controlled via an injected instruction and incurs no ongoing costs. It also doesn't stop working if a provider discontinues its model or doubles its prices.
What this looks like in practice
Mostly it's unspectacular things that make a big difference day to day:
- HTML dashboards and overviews that run as a single file – in the browser, without a server, without installation.
- Small apps and efficiency software for workflows where no suitable standard solution exists, or where one would be too expensive.
- CAD tools and automations that take over recurring design and evaluation work.
- Analyses and generators that turn existing data into what someone previously had to compile by hand.
This website is itself an example: the images of the projects are created using a CAD image generator that we built for ourselves. It runs locally, needs no internet connection, and no one but us sees the models that go into it.
"A tool without a network connection can neither be remotely controlled nor discontinued – it can only do what it was built to do."
What we don't claim
Offline doesn't mean secure. A local tool doesn't protect against a weak password, an unpatched computer, or an employee who passes on data. It removes exactly one category of risk – uncontrolled leakage via a third-party service – and leaves all others in place.
And there are tasks for which a language model is genuinely required at runtime. When that's the case, we say so, rather than building a solution that doesn't solve the problem. Then we talk about locally run models, about clear data boundaries, and about which data is actually allowed to leave the building.
What we don't do: sell you a subscription that you can't cancel without work grinding to a halt.
Sources
- Cyberhaven Labs: 11% of data employees paste into ChatGPT is confidential – Analysis of actual usage among 1.6 million employees: 4.7% pasted in confidential data, 11% of the pasted material is sensitive.
- Yan et al. (2024): On Protecting the Data Privacy of Large Language Models – A Survey – Overview of passive information leakage and active attacks on language models, as well as the effectiveness of countermeasures.
- Liu et al. (2023): Prompt Injection attack against LLM-integrated Applications – 31 of 36 real-world deployed AI applications could be compromised via injected instructions.
- Ferrag et al. (2025): From Prompt Injections to Protocol Exploits – Systematic overview of more than thirty attack techniques against AI agents, from manipulated inputs to protocol vulnerabilities.
IDEA e.U. · Determined Innovation