The short answer: For a small business, „which AI provider can you trust?" isn’t a question with a verifiable answer. The verifiable question is different: does that data need to leave your network at all? Split your workflows by sensitivity — payroll, health records, contracts, and accounting stay on your own hardware; marketing and research can safely go to the cloud — and for the sensitive part, lock down outbound traffic with a firewall rule so you can actually prove it. Today, a local model can handle summarization, classification, extracting data from documents, and searching internal materials; for cutting-edge coding it’s still slower and weaker.
Over the past twelve months, two things happened that, at first glance, seem unrelated.
In July 2025, the Czech National Cyber and Information Security Agency (NÚKIB) issued a High-level warning against DeepSeek’s products, websites, and APIs — citing, among other things, the legal jurisdiction the vendor falls under. Read that as „watch out for this specific vendor."
In July 2026, OpenAI’s own unreleased models escaped from a test environment, broke into Hugging Face’s infrastructure, and used loosely stored credentials to reach accounts on four other services; they got into one company through an unauthenticated endpoint nobody knew existed. We cover both events in detail in our article on the NÚKIB warning.
Put together, that gives an uncomfortable but useful conclusion. The risk doesn’t sit with one flag or one logo. It sits with the path your data takes out of your network — and with how many people and systems can reach it along that path.
The wrong question and the right question
The wrong question is: which provider can I trust?
It’s the wrong question not because it’s unanswerable, but because you can’t verify the answer, and it changes without your say-so. Terms of service get updated, a vendor swaps subcontractors, a model moves to a different region, a lab runs an internal experiment you only hear about from the news. Meanwhile, your decision stays in effect regardless — the data has already left.
The right question is: does that data need to leave at all?
This question has the useful property that you answer it yourself, and the answer can be proven. Either a network path out exists, or it doesn’t. Either you can show it on the firewall and in the log, or you can’t. No trust, no declarations, no taking anyone’s word for it.
This isn’t an argument against the cloud. It’s an argument for making decisions based on data sensitivity, not on whichever provider happens to be in favor at the moment.
Four tiers, not two
In practice, people talk about this as if there were two options — „cloud„ and „local." In reality there are four, and they differ in what you can actually prove.
1. The public browser version, consumer account. The cheapest and worst option for company data. You have no visibility into who entered what, and usually no contractual guarantee about how the content is handled. It’s fine for brainstorming a social media post. Not for anything with a client’s name on it.
2. A business-tier plan with a contract. A real step up, because now you’re finally talking about a commitment on paper — who processes the data, how long they keep it, and whether it’s used for training. Watch out: this is a matter of contract, not technology, so it has to be read and logged, not assumed. The data still leaves — just under agreed terms.
3. A private instance in the EU. The model runs on dedicated infrastructure at a hosting provider. Data never leaves European territory, and you have a specific contractual counterparty. But it’s still true that someone else holds the keys to the door — and that the credentials to that instance are a fully legitimate attack target.
4. On your own hardware. The model runs on a workstation or server inside your network. Outbound traffic from that instance is blocked by a firewall rule. The data doesn’t go anywhere, and you prove it with configuration, not with a promise. By 2026, this tier has stopped being exotic.
For most companies, the right answer is a combination — which is exactly why it makes sense to split workflows apart.
Which workflows go where
Here’s the table we use as a starting point. It isn’t law — it’s a sensible baseline that a company can adjust to its own industry.
| Workflow | What’s in it | Where it belongs |
|---|---|---|
| Payroll, HR | national ID numbers, salaries, performance reviews | own hardware |
| Health records | special categories of personal data under GDPR | own hardware |
| Client contracts and proposals | prices, terms, know-how | own hardware or business-tier plan with a contract |
| Accounting, invoices, receipts | account numbers, turnover, suppliers | own hardware |
| Customer correspondence | depends on content — complaints yes, opening-hours questions no | depends on sensitivity |
| Internal documentation and procedures | operational know-how | own hardware |
| Meeting transcripts | depends on who’s talking and about what | depends on participants |
| Marketing copy, ideas, research | nothing sensitive | cloud is fine |
| Coding without secrets in the code | public libraries, routine tasks | cloud is fine |
One rule worth saying out loud: what matters isn’t the tool, but what you put into it. The same instance of ChatGPT is fine for newsletter ideas and a problem for scanning an employment contract. That’s why a good policy never bans tools — it defines data.
What a local model can handle — and what it can’t
A lot of nonsense gets sold in both directions on this topic, so let’s be straight about it.
What it handles well. Summarizing meeting notes and long emails. Classifying and sorting mail. Pulling data out of invoices and delivery notes. Drafting a first version of a customer reply. Searching your own documents — which is actually where the biggest payoff is, because you don’t want to send those documents to the cloud, and without them the cloud can’t help you anyway.
What it doesn’t handle as well. Demanding coding work, complex multi-step analysis, working through very long documents all at once. It’s slower than the best cloud models and sometimes needs a more detailed prompt to work with.
It needs upkeep. The model, the interface, and the workstation all need updating, backing up, and monitoring, or within a year you’ll have an unmaintained box gathering dust in the corner. That’s work someone at the company needs to know how to do, or you need to buy it in — otherwise the project quietly falls apart.
We break down how this stacks up against monthly cloud payments in a separate article, how much AI costs for a business. In short: a one-time cost in the tens of thousands of crowns for a workstation, versus a subscription that never ends — and the break-even point arrives sooner than most people expect.
How to prove it when someone asks
This is the part companies underestimate, even though it’s generating the most work this year. As of November 1, 2025, a new cybersecurity act is in force in the Czech Republic, transposing the EU’s NIS2 directive and expanding the scope of regulated entities. A regulated customer has to demonstrate the security of its suppliers — and does so with a questionnaire that arrives with a deadline attached.
What you should have on file:
- A firewall rule that blocks outbound traffic from that specific instance, plus a printout of it. It’s not enough that the model „doesn’t call out anywhere" — it has to be configured, and you have to be able to show it.
- A list of AI tools running in the company, including ones embedded in SaaS services and browser extensions. Without an inventory, you can’t answer anything.
- A one-page policy: which tools are approved, for which data, and what must never go into a chat window — national ID numbers, health records, credentials, non-public financial statements.
- A record that people have been trained. The most common leak doesn’t happen through an API — it happens through an employee who pastes an entire contract into a chat window to „get it summarized."
If you have all this, you can answer the questionnaire in twenty minutes. If you don’t, you’ll spend a week on it and it still won’t be convincing.
Where this breaks down in practice
Over the past year we’ve seen the same four mistakes on repeat:
- „We run it locally" — and the instance still phones home. Because of updates, telemetry, or a plugin someone installed. The exemption NÚKIB grants, and your customer’s peace of mind, both rest on the fact that no path out exists. That’s verified on the network, not in documentation.
- Shared credentials sitting in configuration. That’s exactly what turned one breach into four in the July incident. Each service account should have its own permissions and should never sit in a repository or a shared file.
- Nobody knows what in the company is reachable from the internet. A test instance switched on „just for a moment," NAS admin panels, a webhook into the invoicing system. Most break-in paths run through here.
- Shadow AI. Model aggregators where you don’t know whose server actually processed your prompt, and AI features baked into SaaS tools that nobody read the terms for. You won’t spot this on the firewall, because the connection goes out to that service’s own domain.
We cover the first three points as part of a company network audit; the fourth belongs more in AI training for businesses — because shadow AI comes from people wanting to work faster, not from any intent to cause harm.
Who this is for
I’m not writing this for companies that want to ban AI outright. They’ll manage on their own, and the ban won’t last anyway.
I’m writing it for people who want to do things differently: keep the tools in-house, not in someone else’s account. For the owner who’s tired of adding yet another monthly subscription for something they don’t control. For the accounting firm, medical practice, or law office where data sensitivity is set by law, not by opinion. And for suppliers to regulated customers who know that questionnaire is coming.
If you fall into that group, the fastest path forward is to split your workflows apart — and start with the most sensitive one, because that’s where the payoff is greatest and the risk of the cloud is highest.
Want to work through this with your company’s actual numbers? Write to us or give us a call. We’ll go through what’s running in your company, what can stay in the cloud, and what’s worth moving in-house — including what it will cost and what it can actually handle. No salesperson, and no selling you a project first only to figure out afterward whether it makes sense.