
Are employees allowed to use ChatGPT? Must confidential company data be processed exclusively with a local AI? Is a European cloud automatically GDPR-compliant? And does a small business now need its own AI server?
The most important answer first: there isn't one single AI operating model that's generally allowed or forbidden for companies.
What matters isn't simply whether an AI runs in the cloud or in the company's own server room. What's relevant includes the specific purpose, the data used, its protection requirements, the provider's contract terms, possible data transfers, and the risks of the particular AI application.
That's exactly why a cloud AI can be entirely defensible for one use case while the same solution is unsuitable for another process.
Conversely, a locally run language model can prevent data from leaving the company — but an insecure installation, missing access controls, or an unprotected AI server can still pose a significant security risk.
So the better question isn't "Which AI are we allowed to use?" but: "Which AI are we allowed to use for which data and which business process?"
Cloud, local or hybrid: what does that actually mean?
Before companies make a decision, three fundamentally different operating models need to be distinguished.
| Model | Description | Typical benefit | Typical risk |
|---|---|---|---|
| Cloud AI | AI is run by an external provider | Powerful models, almost no infrastructure of your own | Data leaves your own infrastructure |
| Local AI | Model runs on your own servers or devices | Maximum control over data and infrastructure | Company bears operations and security itself |
| Hybrid AI | Local and cloud systems are combined | Flexibility and controlled data flows | Architecture and permissions become more complex |
None of these variants is automatically the right one. In many companies, a hybrid AI model is likely to prevail in the long run.
Is cloud AI allowed at work?
In principle, a company can use cloud AI. There's no blanket ban on cloud AI simply because a service runs outside the company's own data center, or because generative AI is used.
But companies must know which data they're sending to the service and what happens to that data afterward.
Germany's Federal Office for Information Security (BSI) puts exactly these questions at the center: what data is transmitted? Where is it sent? Can personal information be extracted from an AI system? And how is sensitive data protected?
With external cloud services, information security, provider transparency, and suitable evidence of security measures all play an important role. The BSI also recommends factoring in the protection requirement of the processed data when choosing cloud services.
Cloud AI can, for example, be well suited for writing text with public information, brainstorming, translating non-confidential content, general research, marketing ideas, or code assistance for source code that contains no trade secrets, credentials, or personal information.
It becomes problematic, however, when employees copy unvetted personal data, customer information, contracts, personnel files, trade secrets, or credentials into any public AI service.
"We use the enterprise version" isn't a sufficient check
Business and enterprise offerings from many AI providers can offer far more control than free public accounts. Even so, a company shouldn't rely solely on the product name.
What matters is clarifying, contractually and technically, what happens to the information entered. Among other things, you should clarify: are inputs or uploaded files used to train models? Where is data processed and stored? Which subprocessors are involved? How long are prompts, files and responses retained? What deletion options exist? What access, role, and logging functions are available? How are personal data and international data transfers handled? Is there a suitable data processing agreement if processing on behalf of the company applies? Can administrators centrally control features like plugins, external tools, file uploads, or connectors? What security and compliance evidence does the provider provide?
Only then can you sensibly decide which data may be processed with a given service.
When does local AI make sense?
A local AI runs inside the company's own infrastructure — for example on a workstation, a powerful AI server, a virtualization cluster, or a dedicated GPU system. Common platforms now make it possible to run language models entirely within a company network.
The big advantage: prompts and company data don't have to leave the company's own infrastructure. That can be especially interesting when working with sensitive information — such as internal documentation, technical configurations, source code, research data, contract information, internal knowledge bases, or business-critical know-how.
Local AI can also be interesting if a company wants to build an internal knowledge platform using Retrieval Augmented Generation — RAG for short. Rather than training an entire company's knowledge directly into a language model, a system instead retrieves relevant information, for example from an internal document collection or database, and feeds it to the language model for a specific query. For a concrete, privacy-friendly and GDPR-compliant way to secure such a local platform with Ollama and Open WebUI, see Local AI for Companies: Running Ollama and Open WebUI Safely (Read article).
Local AI doesn't automatically mean GDPR-compliant AI
That's one of the most common misconceptions. Just because a model runs on a company's own server, data protection and security requirements don't disappear. If a local AI processes personal data, the corresponding data protection requirements still apply.
Germany's Datenschutzkonferenz (the conference of German data protection authorities) explicitly points out that companies must consider data protection criteria when selecting, implementing, and using AI applications.
A local AI server also needs a sound permissions concept, secure authentication, updates, network segmentation, logging, and protection against unauthorized access. A poorly secured local AI server can become an attractive target. The BSI generally points out that vulnerabilities, misconfigurations, and inadequately secured servers can endanger the confidentiality and integrity of stored data.
On-premises, in other words, isn't a compliance feature. It's merely an operating model.
The probably most sensible path: hybrid AI
For many companies, a hybrid architecture is likely the most interesting solution. Rather than a single AI system handling every task, different models are used depending on the protection requirement.
A company might, for example, use a powerful cloud AI for general tasks while running a local model for confidential content. In practice that could look like this:
| Task | Sensible variant |
|---|---|
| General brainstorming | Cloud |
| Public marketing copy | Cloud |
| Translating public content | Cloud |
| Research without confidential data | Cloud |
| Internal IT documentation | Local or hybrid |
| Analyzing internal logs | Local or a controlled enterprise cloud |
| Source code of proprietary applications | Local or a vetted enterprise solution |
| Company wiki | Local / RAG |
| Customer information | Hybrid or local, depending on the process |
| HR data | Especially careful case-by-case review |
| Trade secrets | Local or a tightly controlled environment |
| Public information plus internal knowledge | Hybrid |
This creates a kind of AI classification similar to classic data classification. Not every prompt needs the same security level.
A practical four-tier model for company data
Companies can significantly simplify their AI usage by sorting information into protection classes.
Tier 1: Public. Examples include website copy, published press releases, publicly available product information, or general knowledge. An approved cloud AI can often be used here without issue, as long as no other restrictions apply.
Tier 2: Internal. Examples include internal work instructions, simple documentation, or organizational information. A controlled company solution should already be used here.
Tier 3: Confidential. This can include source code, internal calculations, contracts, unpublished product information, or detailed system configurations. A local or especially well-secured hybrid solution can make sense for information like this.
Tier 4: Especially sensitive. This can include, for example, certain personal or especially sensitive data. Use cases like this shouldn't simply be approved independently by an employee. Data protection, information security, and, where relevant, other responsible departments should be involved beforehand.
That turns "Are we allowed to use AI?" into a far more useful question: "Which data class may be processed with which approved AI?"
Matching product in my shop · German-language edition
KI ohne Bauchschmerzen
This practical German-language guide for small businesses and SMEs shows step by step how to roll out AI in a company in a controlled way — with 50 prompt templates, 15 workflows, and a structured 21-day plan for a secure AI rollout without a huge IT project.
GDPR and AI: the storage location alone doesn't decide
When AI is used with personal data, the GDPR continues to play a central role.
The European Data Protection Board explicitly clarified at the end of 2024 that questions such as the legal basis, anonymization, and the processing of personal data must be specifically assessed when developing and using AI models. Whether an AI model can be considered anonymous, for example, must be judged based on the specific case.
That means: "the server is in Europe" still isn't a complete data protection assessment. What matters is the entire processing chain. Companies should understand who processes data, for what purpose, whether subprocessors are involved, and whether data is used for additional purposes.
A particularly critical situation is one where employees use their own AI accounts without approval. That quickly creates shadow AI: company data ends up in systems that neither IT, nor data protection, nor management controls. For the technical and organizational measures that actually help against this, see Preventing Shadow AI: Technical and Organizational Measures for Companies (Read article).
The EU AI Act doesn't decide between cloud and local
There's an important point with the EU AI Act, too: the AI Act evaluates AI primarily based on its function and risk — not on whether the server sits in the basement or in the cloud.
The AI Act follows a risk-based approach. Different requirements arise depending on the specific use. That means the same underlying technology can be deployed in two completely different legal situations.
A language model that helps an employee draft a general email is something different from an AI system used in a sensitive HR or decision-making process. The use case decides. Not the logo on the AI tool. And not the language model used, by itself, either.
Further AI Act rules became relevant in August 2026
For companies, it's especially important that further provisions of the European AI Act became practically relevant, and enforcement was expanded, as of August 2, 2026. For a detailed breakdown of what applies since then, see EU AI Act Since August 2026: What Companies Really Need to Know (Read article).
Among other things, transparency obligations under Article 50 now apply to certain AI systems. Depending on the use case, people must, for example, be able to recognize when they're interacting with an AI system. Transparency requirements also apply to certain AI-generated or manipulated content.
It's important, though, not to work from outdated AI Act timelines. As of October 2026, revised transitional periods apply to certain high-risk areas. The European Commission names, for example, December 2, 2027 for certain high-risk systems, and August 2, 2028 for high-risk AI integrated into regulated products. Companies should therefore always work with the current version and the specific use case for AI Act projects.
AI literacy is relevant for companies too
One point is underestimated in many AI projects: it's not just the technology that needs to be controlled. Employees also need to know how to use AI responsibly.
Article 4 of the AI Act contains requirements to promote the AI literacy of staff and other people who use AI systems on a company's behalf. This obligation has in principle applied since February 2, 2025; the European rules were adjusted again in 2026.
Enterprise AI without training is therefore not a particularly sustainable strategy. Employees should, for example, understand which information they're allowed to enter and which they aren't, why AI can hallucinate, when results need to be checked, and which systems are approved for which tasks.
Why an AI gateway becomes interesting for companies
Another option for larger or technically well-equipped companies is a central AI gateway. Instead of employees accessing various external AI services directly, communication runs through a central company platform.
The gateway can, for example, authenticate users, approve models, log access, filter sensitive content, and use different AI systems depending on the specific use case. A request could, for example, automatically be routed to a local AI if it contains confidential information. A general request, by contrast, could use a more powerful cloud model.
That turns hybrid AI from just an infrastructure decision into a security architecture.
Matching product in my shop · German-language edition
MCP Server Praxisleitfaden 2026
This German-language practical guide explains clearly how AI agents can be connected to internal systems in a controlled way — including central gateways, policies, least privilege, and GDPR questions around remote access, all relevant to a company-wide AI gateway.
Local versus cloud: which is more secure?
A blanket answer would be irresponsible. A large professional cloud platform can be considerably better secured in terms of physical security, redundancy, monitoring, and patch management than a single server at a small company.
At the same time, using the cloud means additional parties and infrastructure components are involved in processing. Local systems reduce this external dependency, but increase the company's own responsibility in turn.
For cloud services, the BSI therefore recommends looking at the protection requirement and the specific security requirements. Information security should be part of a company's risk management.
So the question shouldn't be "What's more secure?" but: "Which risk can we control better ourselves?"
When cloud AI can be the better choice
Cloud AI has a decisive advantage: companies get access to powerful models without having to manage their own GPU servers, models, updates, and scaling.
This lets small and medium-sized businesses in particular use AI without first building substantial infrastructure. If the information being processed has a low protection requirement and a suitable provider and matching contract terms have been chosen, this can be an economically sensible solution.
When local AI can be the better choice
Local AI becomes especially interesting when a company wants to analyze large volumes of confidential internal information. That's particularly true when data should ideally not be transmitted to external AI providers at all.
Local AI can also be interesting for internal knowledge systems, RAG architectures, log analysis, document search, or specialized technical assistants. However, the company then needs its own expertise for hardware, updates, backups, access protection, monitoring, and model management. For a detailed, practical comparison between cloud AI and a local Ollama-based solution, see Which Local AI Fits Small Businesses? Cloud vs. Ollama Compared (Read article).
When hybrid is the better architecture
The hybrid variant makes sense when a company wants neither to give up powerful cloud models nor to let sensitive information leave the company uncontrolled. A good hybrid concept could, for example, work on this principle: public information goes through cloud AI, internal information goes through a controlled company AI, confidential information goes through local AI, and especially sensitive processes only go through after individual review and approval.
This architecture is far more flexible than a blanket cloud ban. And it also prevents employees from drifting toward unapproved tools out of convenience.
The most dangerous AI is often not the officially introduced one
Perhaps the biggest risk arises when a company makes no decision at all. Employees will use generative AI regardless. That's when private accounts, browser tools, unknown plugins, and uncontrolled AI services appear.
From an IT perspective, an officially approved and technically controlled AI is therefore often better than the illusion that no AI is being used at the company at all.
A clear AI policy should therefore define: which systems are allowed? Which data may be processed? Which features are blocked? Who's allowed to approve new AI services? How must results be checked? And who's the point of contact for uncertainties? For what such a policy can concretely look like, see AI Policy for Companies: What Employees Can and Cannot Do (Read article).
A sensible AI strategy for small businesses
A small business doesn't necessarily need its own GPU cluster. A practical starting point can look much simpler.
First, a controlled cloud solution is introduced for general tasks. In parallel, the company defines data classes and clear rules for employees. Use cases where confidential data genuinely needs to be processed are then identified. Only once there's a real need does it make sense to add a local AI or a hybrid platform.
That prevents building substantial infrastructure that's barely needed in everyday use.
Example: a company with 30 employees
Picture a mid-sized company with sales, accounting, IT, and marketing teams.
Marketing uses an approved cloud AI for social media ideas and publicly available product information. Sales uses the same platform for drafting help — but isn't allowed to upload full customer data or confidential contracts there. IT additionally runs a local language model that can analyze internal documentation and log files. An internal RAG platform lets employees search approved company documents. Especially sensitive information is only processed within defined systems.
The company, in other words, doesn't own one AI. It owns an AI architecture. And that's likely the direction professional enterprise AI is headed.
Decision matrix: cloud, local, or hybrid?
| Criterion | Cloud | Local | Hybrid |
|---|---|---|---|
| Fast to get started | very good | medium | medium |
| Own infrastructure needed | low | high | medium to high |
| Control over data | depends on the provider | very high | high |
| High-end top models | very good | hardware-dependent | very good |
| Scalability | very high | hardware-dependent | high |
| Maintenance effort | low to medium | high | medium to high |
| Processing sensitive internal data | only after review | well suited | very controllable |
| Cost at low usage | often cheap | comparatively high | medium |
| Cost at heavy usage | can rise sharply | more predictable | well controllable |
| Technical know-how required | low to medium | high | high |
So which AI should a company use?
The short answer: cloud AI, local AI, and hybrid AI can all, in principle, be part of a company's strategy. What matters is the specific use.
A cloud solution can make sense for general tasks. Local AI can offer advantages for confidential company information. A hybrid architecture can connect both worlds.
The most important step, then, isn't choosing a particular model. It's introducing AI governance. Companies should know: who uses which AI with which data for which purpose and under which rules?
Whoever can answer that question is considerably further along than a company that merely announces: "ChatGPT is banned."
Conclusion: it's not cloud or local that decides — it's control
The debate around enterprise AI is often reduced to a technical question: cloud or your own server? But the real challenge is organizational in nature.
A company has to classify data, evaluate applications, control access, train employees, and create clear responsibilities.
Cloud AI can be right. Local AI can be right. Hybrid AI can be right. It becomes dangerous above all when nobody knows which systems are actually being used and what information ends up there.
For many companies, a controlled hybrid strategy is therefore likely to be especially interesting: powerful cloud models where they're defensible, local processing where control is especially important, and clear rules about which employee may use which system for which purpose.
The most important decision in 2026 is therefore no longer "Are we using AI?" but: "How are we using AI in a controlled way?"
Frequently asked questions about AI for companies
Is ChatGPT allowed at work?
Using a cloud-based AI service isn't automatically prohibited just because it's an external service. However, companies must check the purpose, the type of data, contract terms, data protection and information security. Especially sensitive company or personal data shouldn't be processed uncontrolled through private or unapproved accounts.
Is local AI automatically GDPR-compliant?
No. Systems running locally can still process personal data and are then subject to the corresponding data protection requirements. The company's own infrastructure must also be adequately secured.
Do companies have to run AI locally?
No. There's no general requirement that enterprise AI must run on a company's own servers. What matters is the data, the purpose, the risks and the applicable legal requirements.
What is hybrid AI?
A hybrid AI architecture combines local and cloud-based AI systems. Sensitive information can be processed locally, for example, while general tasks are handled by powerful cloud models.
What data shouldn't simply be entered into a public AI?
This can include personal data, credentials, API keys, internal contracts, trade secrets, confidential source code and other information with a higher protection requirement. What always matters is the data classification and the approved company solution.
Does the EU AI Act also apply to companies that just use AI?
Yes. The AI Act distinguishes between different roles. Operators, or "deployers," of AI systems can also have obligations depending on the application. The specific requirements depend on the actual use.
What's the most sensible approach for small businesses?
A staged approach is often sensible: controlled cloud AI for general tasks, clear AI policies and data classes, and then local or hybrid systems for use cases with a higher protection requirement.
You'll find more practical guides on AI, data protection, and enterprise IT on the KI-Buster blog.
Sources and further information
Editorial status: October 17, 2026. The legal and security-related statements in this article are based in particular on publications by the European Commission on the AI Act and its current application in 2026, guidance from Germany's Datenschutzkonferenz on AI and data protection, the European Data Protection Board's opinion on the processing of personal data in connection with AI models, and recommendations from Germany's Federal Office for Information Security (BSI) on securing AI and cloud systems. This article provides a general technical and organizational overview and does not replace individual legal or data protection advice.
A concrete application of this decision is covered in RAG for Small Businesses: Search Your Documents with AI (Read article)