Local AI for Companies: Running Ollama and Open WebUI Safely

ChatGPT, Claude, Gemini, and other generative AI systems are firmly part of everyday work now. Employees use them to draft emails, summarize meeting notes, review source code, or write technical documentation.

That creates a real problem for companies: what information is actually allowed to leave the building and reach an external AI service?

Pasting customer data, internal documents, source code, contracts, personal information, or confidential business data into just any cloud chatbot can quickly turn into a privacy and security risk.

That's why running AI locally, inside the company, is an interesting alternative. With Ollama as the runtime for large language models and Open WebUI as a comfortable web interface, companies can run their own AI systems on their own infrastructure. For a step-by-step installation guide, see Open WebUI + Ollama: Your Own ChatGPT Alternative on Linux (Read article).

But "installed locally" doesn't automatically mean "secure" — let alone "GDPR-compliant".

This article shows how companies can run Ollama and Open WebUI in a way that treats privacy and security as a first-class concern from day one.

Why local AI is becoming interesting for companies

With classic cloud AI services, a request typically leaves your own infrastructure.

Simplified, the data flow looks like this:

Employee → Internet → AI provider → AI model → Response

For plenty of everyday questions, that's not a problem. It gets trickier with information like:

• customer data
• employee data
• contract content
• internal emails
• helpdesk tickets
• server configurations
• log files
• source code
• internal process descriptions
• unpublished financial figures
• confidential documents

With local AI, the data flow can instead look like this:

Employee → internal Open WebUI → internal Ollama server → local AI model

The actual model computation then happens on hardware the company controls itself.

For locally run models, Ollama explicitly states that local prompts and responses are not transmitted to Ollama. At the same time, Ollama now also offers cloud models. That means an Ollama setup today isn't automatically an exclusively local system.

That distinction is exactly what matters for companies.

What are Ollama and Open WebUI?

Ollama

Ollama provides a runtime for executing numerous open, locally available AI models. It also exposes an API that other applications can use to talk to those models.

Examples of available model families include:

• Qwen3
• Gemma 3
• gpt-oss
• numerous specialized coding, embedding, and reasoning models

Qwen3, for example, is available in sizes ranging from small models to very large variants. Gemma 3 is likewise available in several sizes, while OpenAI's gpt-oss is offered as, among others, a local 20B and 120B variant.

That lets a company match the model it uses to its hardware and use case.

Open WebUI

Open WebUI puts a user-friendly interface in front of the underlying models. For employees, the result looks a lot like a familiar AI chat:

• start new chats
• choose models
• upload files
• analyze documents
• provide knowledge bases
• manage users
• assign roles and permissions
• use APIs
• integrate SSO

Open WebUI supports OIDC, LDAP, roles, groups, and other access-control mechanisms, among others. That makes it a much better fit for a centrally run company deployment than an Ollama install on every individual workstation.

The biggest mistake: local doesn't automatically mean GDPR-compliant

One of the most common misconceptions is: "The AI runs on our own server, so we no longer have a privacy problem."

It's not that simple.

A local architecture can offer a real privacy advantage, because data doesn't necessarily have to be sent to an external AI provider.

But personal data is still personal data — whether it's processed in Frankfurt, at a hyperscaler, or in your own server room.

The GDPR requires, among other things:

• lawfulness of processing
• purpose limitation
• data minimization
• storage limitation
• integrity and confidentiality

Article 32 additionally requires technical and organizational measures appropriate to the risk of the processing involved.

A local AI setup can be made more privacy-friendly. It does not, however, make privacy work optional.

Where local AI offers real privacy benefits

1. Company data can stay inside your own network

The most obvious benefit shows up in the data flow. If a local model is used and external interfaces are consistently disabled or blocked, prompts don't need to be sent to an external model provider.

That reduces the number of systems involved, and potentially the number of external vendors too. That can be especially relevant for:

• legal departments
• HR departments
• internal IT
• software development
• support
• research and development
• technical documentation
• internal knowledge bases

2. The company controls the infrastructure

With a self-hosted setup, administrators get to decide:

• which server the system runs on
• who is allowed to access it
• which models are available
• what data gets stored
• which networks are reachable
• which backups are created
• when data gets deleted
• what logs are generated
• which external services are reachable

That's a meaningful difference compared with a fully externally hosted SaaS system.

3. Your own security policies can be enforced technically

An AI usage policy for employees is a good idea. We cover how to build one in AI Policy for Companies: What Employees Can and Cannot Do (Read article). Even better, though, is when certain rules are also enforced technically.

Examples:

Cloud models forbidden? Then cloud features get disabled.

Only approved models allowed? Then only those models get made available.

No public chat sharing? Then sharing gets turned off.

Access only for employees? Then login happens through the central identity provider, for example.

Technical controls are far more reliable than hoping every employee follows every policy every single time.

Watch out: Ollama now has cloud features

This point matters a lot. Ollama is still frequently described, blanket-style, as "local AI".

By now, though, the platform also supports cloud models and other cloud features.

Anyone who wants to run a genuinely local-only system should explicitly disable these features. Ollama supports, for example:

OLLAMA_NO_CLOUD=1

Alternatively, the setting can be made in the Ollama configuration:

{
  "disable_ollama_cloud": true
}

After a restart, cloud features are disabled. That means Ollama's cloud models and its web search are no longer available.

For especially sensitive environments, you shouldn't rely on an application setting alone. A network rule at the firewall or proxy level is also recommended.

The rule of thumb: what the AI system isn't allowed to reach shouldn't be technically reachable in the first place.

A sensible architecture for local company AI

A simple company architecture can be built like this:

Employee
  |
  | HTTPS
  v
Reverse proxy / load balancer
  |
  v
Open WebUI
  |
  | internal network
  v
Ollama server
  |
  v
Local AI models

Optionally, further components can be added:

+----------------+
| Identity       |
| Provider / SSO |
+-------+--------+
        |
        v
Employee --> Reverse proxy --> Open WebUI
                                    |
                    +---------------+----------------+
                    |                                |
                    v                                v
              Ollama server                    PostgreSQL
                    |
                    v
               local LLMs

Larger installations can also use multiple Ollama backends. Open WebUI supports multiple, load-balanced Ollama connections.

Never expose Ollama's port 11434 unprotected

Ollama's API runs on the following by default:

127.0.0.1:11434

That's sensible on its own, since it's only reachable locally. Via OLLAMA_HOST, though, it can be changed to something like:

0.0.0.0:11434

which makes Ollama potentially reachable over the network.

Be careful here. The local Ollama API requires no user login by default. That's exactly why port 11434 should never simply be exposed to the internet. Even inside a company LAN, access should be restricted.

Better:

User
  |
  v
Open WebUI
  |
  v
Firewall
  |
  v
Ollama:11434

Only Open WebUI, or explicitly authorized systems, should be able to reach Ollama.

Open WebUI belongs behind HTTPS

Even when an application is run purely internally, users shouldn't access it over unencrypted HTTP.

Open WebUI recommends running production installations over HTTPS, or behind a properly configured reverse proxy. HTTPS protects chat history, login credentials, and uploaded files in transit, among other things.

A typical setup:

https://ai.company.internal
  |
  v
Nginx / HAProxy / Caddy
  |
  v
Open WebUI

A valid internal or publicly trusted TLS certificate should also be used.

Never turn off authentication

Open WebUI can be run without user login. That's done with, for example:

WEBUI_AUTH=False

That might be convenient for a personal test machine. For a company installation, it's usually the wrong call. Open WebUI enables authentication by default.

Inside a company, central authentication should be used wherever possible. Suitable options include:

• OpenID Connect
• OAuth
• LDAP
• Keycloak
• Microsoft Entra ID
• Okta
• other existing identity providers

Open WebUI supports the corresponding SSO flows. That lets user accounts be tied to the company's existing identity.

Even more importantly: when an employee leaves the company, their access can be revoked centrally.

Disable local passwords once SSO is set up

Once SSO is fully configured, it can make sense to also disable local password login. Open WebUI provides, for example:

ENABLE_PASSWORD_AUTH=false

The documentation recommends this approach specifically for properly configured, production SSO setups. That reduces the number of parallel authentication paths.

Chat history is company data too

The actual model request is only part of the privacy picture. Open WebUI can persistently store chats, files, user accounts, and configuration.

An employee might write, for example: "Please summarize employee X's sick note."

Even if that prompt never leaves the company network, it can still end up sitting in the Open WebUI database afterward.

That's why companies need to decide:

• How long are chats retained?
• Is sensitive data allowed to be entered at all?
• Who can view chat history administratively?
• When does data get deleted?
• What data ends up in backups?
• Who has access to the database?
• Are storage media encrypted?

Privacy doesn't end at the AI model.

Administrators are a special zone of trust

Open WebUI has far-reaching administrator privileges. By default, functions exist that let administrators access chat information and exports. Open WebUI explicitly points out that an administrator is, infrastructurally, a highly privileged user: anyone with access to the server and database can generally bypass technical access restrictions inside the interface.

For sensitive installations, settings like these should be reviewed:

ENABLE_ADMIN_CHAT_ACCESS=false
ENABLE_ADMIN_EXPORT=false
BYPASS_ADMIN_ACCESS_CONTROL=false

Important: these settings don't replace a genuine separation of administrative responsibilities. A root user on the database server is still a root user.

The same least-privilege principle ultimately applies to AI agents that might get access to a system like this. We explain how to properly limit AI agent permissions in What Permissions Should an AI Agent Get? Security Rules for Agents (Read article).

For especially sensitive departments, a separate AI instance can even make sense. For example:

• Open WebUI General
• Open WebUI HR
• Open WebUI Legal
• Open WebUI Engineering

That way, data sets and administrative responsibilities can be kept more clearly separated.

Encrypt the database

For small installations, Open WebUI often uses SQLite. The hardening documentation supports encrypted SQLite via SQLCipher:

DATABASE_TYPE=sqlite+sqlcipher

For production installations with multiple users, the Open WebUI documentation instead recommends PostgreSQL, for better scalability and reliability. The database should only be reachable over internal networks.

With PostgreSQL, storage encryption needs to be implemented at the database, storage, or operating-system level accordingly.

Backups belong in this picture too. An encrypted production server doesn't help much if an unencrypted database backup lands on a freely accessible NAS every night.

Actually running Open WebUI offline

For heavily isolated environments, Open WebUI has an offline mode:

OFFLINE_MODE=true

This disables various outbound functions and update checks. Any required models and embeddings then need to already be available locally.

You should also check which features are actually needed. A security-focused environment might deliberately do without:

• external model providers
• web search
• external tools
• user webhooks
• public sharing
• external embedding services
• direct provider access
• server-side code execution

The smaller the attack surface, the easier the system is to keep under control.

Turn off community sharing

Open WebUI offers various sharing features. For sensitive company environments, this in particular should be reviewed:

ENABLE_COMMUNITY_SHARING=false

The Open WebUI hardening documentation recommends disabling sharing when sensitive data is involved.

That doesn't prevent every conceivable form of data leakage — a user can still copy or photograph content, for instance. But it does remove unnecessary technical sharing options inside the application itself.

Block direct provider connections

One particularly problematic scenario: the company builds a secure local AI setup — and then employees can turn around and add external AI providers themselves inside the interface.

That would partially undo the whole point. Open WebUI has a configuration option for exactly this. The setting:

ENABLE_DIRECT_CONNECTIONS=false

is disabled by default and should stay disabled for a controlled local-only system. The same principle applies to unnecessary API passthrough features.

Don't leave CORS set to "*"

Another classic security mistake involves cross-origin resource sharing. The Open WebUI documentation notes that CORS_ALLOW_ORIGIN can default to *.

For a production installation, only the actual address in use should be allowed instead. Example:

CORS_ALLOW_ORIGIN=https://ai.company.com

Or for multiple internal front ends:

CORS_ALLOW_ORIGIN=https://ai.company.com;https://portal.company.com

This is also just part of general web-application hardening.

Only enable code execution if you actually need it

Modern AI interfaces can do a lot more than generate text by now. Tools, Python code, functions, and external interfaces make a system more powerful — but they also expand the attack surface at the same time.

If employees only need to draft text, write documentation, summarize content, or answer technical questions, server-side code execution may not be needed at all.

Open WebUI recommends disabling unneeded code execution and automatic package installation for hardened installations.

The principle: features you don't need shouldn't just sit unused — they should be turned off.

Roll out updates in a controlled way

For production Open WebUI systems, you also shouldn't blindly track a rolling tag like :main.

Open WebUI explicitly recommends pinning a specific version for reproducible, production deployments. For example, following this scheme:

ghcr.io/open-webui/open-webui:vX.Y.Z

A sensible update strategy looks like this:

New version
  |
  v
Review release notes
  |
  v
Create a backup
  |
  v
Update staging
  |
  v
Functional test
  |
  v
Security test
  |
  v
Update production

Extra caution is needed around database migrations in particular. Open WebUI notes that database migrations can't necessarily be undone just by downgrading the container.

What hardware does local AI need?

The hardware you need depends heavily on the model. Relevant factors include:

• model size
• quantization
• context window
• number of concurrent users
• CPU performance
• RAM
• GPU
• VRAM

Small models can often run without issue on ordinary machines. Larger models benefit significantly from capable GPUs.

Examples from the current Ollama model library illustrate the scale involved:

These figures correspond to the published Ollama model variants and shouldn't be equated with the total RAM or VRAM actually required.

For a company, running a pilot is a good idea before buying expensive GPU hardware.

Which tasks are a good fit for local AI?

Local AI doesn't have to try to replace the most capable cloud service in every single scenario. It's particularly interesting for tasks where privacy matters more than squeezing out maximum model performance.

IT support

Example: "Analyze this journalctl excerpt and explain why the service won't start."

Logs can contain sensitive information. Local processing can be genuinely interesting here.

Internal documentation

Example: "Turn these technical notes into clear internal documentation."

That way, internal system names, IP addresses, or architecture details stay inside the company.

Email drafts

Example: "Turn these bullet points into a professional reply to the customer."

The employee should still only use data whose processing is actually allowed for that purpose.

Analyzing source code

Developers can have internal projects analyzed without necessarily sending the code to an external model provider. For proprietary software especially, that can be a significant advantage.

Internal knowledge base

Combined with retrieval-augmented generation — RAG for short — internal documentation can be made searchable. For example: "According to our internal docs, how do we set up a new HAProxy server?"

That can turn a simple chat interface into an internal knowledge assistant. The embeddings and document stores this creates need to be factored into the privacy and security assessment too, though.

Be careful with personal data

Just because processing happens locally doesn't mean any personal data can be fed into an AI system.

Before rolling anything out, companies should define categories such as:

Green — usually low-risk: publicly available information, general technical questions, anonymized text, sample configurations, general documentation.

Yellow — check first: internal documentation, log files, customer tickets, internal emails, business contract information.

Red — only with a clearly defined purpose and approval: health data, extensive HR records, special categories of personal data, highly sensitive trade secrets, credentials, passwords, private keys, API secrets.

An internal AI policy should spell out these categories for employees in plain language.

Privacy-friendly local AI as a complete concept

A secure installation isn't just: install Docker, start Ollama, start Open WebUI, done.

A better architecture considers several layers:

Only the combination of all these measures turns local AI into a serious company service.

Example of a local-only security profile

A hardened environment might, conceptually, use settings like these:

# Ollama
OLLAMA_NO_CLOUD=1

# Open WebUI
WEBUI_AUTH=true
OFFLINE_MODE=true

ENABLE_COMMUNITY_SHARING=false
ENABLE_DIRECT_CONNECTIONS=false
ENABLE_ADMIN_CHAT_ACCESS=false
ENABLE_ADMIN_EXPORT=false

BYPASS_ADMIN_ACCESS_CONTROL=false

CORS_ALLOW_ORIGIN=https://ai.company.com

With SSO set up, add for example:

ENABLE_PASSWORD_AUTH=false

Depending on the use case, further features like code execution, tools, web access, and uploads can be restricted too.

What matters is not adopting configurations like this blindly. The specific security profile has to match the company, its threat model, and the features it actually needs.

Local-only also means controlling outbound network traffic

For especially sensitive systems, I'd go one step further.

Not: "Our configuration says the cloud isn't used."

But rather: "Our network technically prevents the AI system from reaching unapproved cloud services."

For example:

AI VLAN
  |
  v
Firewall
  |
  +--> DNS allowed
  +--> NTP allowed
  +--> Controlled updates allowed
  |
  +--> Internet blocked by default

Updates or new models can then be delivered through a controlled process. That produces a much more auditable security model.

Can local AI prevent shadow AI?

It can't eliminate shadow AI entirely. But it can be an important part of the solution. We cover exactly what shadow AI means and the risks it creates in Shadow AI at Work: When Employees Secretly Use ChatGPT (Read article).

If employees don't get a usable internal AI service, they'll often go find one on their own. The result can be private accounts on whatever AI platform they happen to pick.

If the company instead provides a fast, convenient internal AI assistant, the incentive for these workarounds drops. We walk through the technical and organizational measures that complement local AI here, step by step, in Preventing Shadow AI: Technical and Organizational Measures (Read article).

The goal shouldn't be "AI is banned." It should be: "For internal and confidential tasks, you have our approved AI available to you."

Technology, policy, and training all have to work together here.

Is Ollama with Open WebUI a real ChatGPT alternative?

For plenty of internal tasks: yes. For every task: no.

Large commercial cloud models still have an edge for certain complex tasks, especially large contexts, specialized tools, or heavily compute-intensive reasoning work. We show exactly how ChatGPT, Claude, and Gemini differ in everyday sysadmin work in ChatGPT vs. Claude vs. Gemini for System Administrators (Read article).

Local models have other advantages instead:

• data sovereignty
• your own infrastructure
• controllable network boundaries
• no classic per-request token costs for local inference
• free choice of model
• offline operation
• integration into internal systems

Companies don't necessarily have to choose between cloud or local. An interesting strategy can also be:

Public data           → approved cloud AI
Internal data         → local AI
Especially sensitive data → isolated local AI or no AI processing at all

Data classification is what decides.

Conclusion: local AI is privacy by architecture

Ollama and Open WebUI now let companies build a genuinely capable AI platform of their own with manageable effort.

The biggest benefit isn't that all privacy problems suddenly vanish. The real benefit is this: the company gets substantially more control over the data flow.

Models can run on your own hardware. External providers can be avoided. Users can be authenticated centrally. Network access can be technically restricted, and data can be processed entirely within your own infrastructure.

That's exactly where the potential of local AI lies. To get there, though, it has to be run like an actual company service: with access controls, with encryption, with backups, with patch management, with network segmentation, with roles and permissions, with a deletion concept, and with documented policies.

An unprotected Open WebUI container and an openly reachable Ollama port are not a privacy strategy.

A well-thought-out local-only architecture, on the other hand, can be a genuinely useful building block for many companies — letting them use generative AI productively without automatically shipping data to an external AI provider on every single internal prompt.

Frequently asked questions about Ollama, Open WebUI, and privacy

Is Ollama GDPR-compliant?

No piece of software is automatically "GDPR-compliant". What matters is how and for what purpose personal data is processed. Local Ollama models can avoid transmitting data to external AI providers, which makes a privacy-friendly architecture easier to build. The company's other GDPR obligations still apply.

Does Ollama send my prompts to the internet?

For locally run models, Ollama states that it does not receive local prompts and responses. Ollama now also offers cloud models and cloud features, though. For a strictly local setup, these should be disabled with OLLAMA_NO_CLOUD=1 or disable_ollama_cloud.

Is Open WebUI suitable for companies?

Open WebUI supports multi-user operation, roles, groups, OIDC, LDAP, and other access controls. Production installations still require proper hardening, though.

Does Open WebUI need internet access?

Not necessarily. Open WebUI has an offline mode. For fully isolated installations, the required models, embeddings, and other components must be available locally.

Can Ollama run completely without the cloud?

Yes. Ollama supports a local-only mode that disables cloud features. For especially high security requirements, outbound network traffic should additionally be restricted with firewall rules.

Should Ollama's port 11434 be reachable from the internet?

No. Ollama binds to 127.0.0.1:11434 by default but can be reconfigured for network access. Since the local API isn't meant to be run like a typical public web service with user authentication, it belongs behind a firewall, a reverse proxy, or inside a trusted internal network.

Sources and further reading

This article reflects the legal and factual status as of September 12, 2026. The technical and privacy-related information draws in particular on the current Ollama documentation, the current Open WebUI hardening documentation, and information from the European Union and the European Data Protection Board. Ollama documents its local-only mode, the API's default binding to localhost, and its now-available cloud features. Open WebUI documents extensive hardening, authentication, database, and network options.

The privacy assessment is based in particular on the principles in Article 5 and the security requirements in Article 32 of the GDPR. The European Data Protection Board also notes that the use of AI systems continues to raise data-protection questions around the processing of personal data.

Note: This article does not constitute individual legal or privacy advice.

Related articles

Open WebUI + Ollama: Your Own ChatGPT Alternative on Linux (Read article)

Shadow AI at Work: When Employees Secretly Use ChatGPT (Read article)

Preventing Shadow AI: Technical and Organizational Measures (Read article)

AI Policy for Companies: What Employees Can and Cannot Do (Read article)

What Permissions Should an AI Agent Get? Security Rules for Agents (Read article)

ChatGPT vs. Claude vs. Gemini for System Administrators (Read article)