empes

Case study · 2026

A private AI workspace for a company's staff: one chat, chosen models, costs that stay in bounds

Staff at a mid-sized company were using public AI assistants on their own accounts. We built the company its own AI workspace on Open WebUI and LiteLLM, on its own server: work login, models the company chose, budgets that hold, and help built in.

Client
Mid-sized company
Status
In daily use
Services
Empes AI, Empes Infrastructure
Scope
Private AI workspace, model gateway and budgets, directory login, Microsoft 365 connection, hosting and rollout

Problem

People in the company already used AI every day, to draft mail, summarise documents and check figures. They did it in public assistants, often on personal accounts, with company documents pasted in. That was convenient for them and left the company with no answers to basic questions: which data went where, what it cost, and who still had access after they left.

The company wanted the same convenience under its own rules, and set out what that meant:

  • Accounts from the directory. Nobody would create accounts by hand. Joining and leaving the company had to grant and remove access by themselves.
  • Two kinds of user. Most people want a good chat. A few developers want AI coding tools, each with their own key.
  • Costs that stop, not costs that alert. Spend had to be visible per team, with a limit that refuses the next request once it is reached.
  • A clear promise about data. Prompts go only to models the company chose, and the providers neither keep them nor train on them.
  • Something IT can run. The company’s own IT team had to be able to deploy, update and support it from documentation.

Approach

We started with a short pilot on a hosted platform to agree the shape with the company, then moved the workspace to a server inside its own network.

We did not write a chat application. Two open-source products do the heavy lifting: Open WebUI, the workspace people use, and LiteLLM, a gateway that sits between the workspace and the models. Our work was the system around them, built on five rules:

  • One key, in one place. Only the gateway holds the AI provider’s key. The workspace gets a limited key of its own, so the part people use never holds the company’s billing credential.
  • Budgets that refuse. Every team and every person has a monthly limit, enforced by the gateway, and every request is recorded against the person who made it.
  • What you see is also what you may use. The models a group sees are set in the workspace, and the gateway enforces the same list again, so hiding a model is never the only control.
  • Say exactly what the data promise is. Models are reached through one provider with data collection switched off for every model. That is a real control. It is weaker than “prompts never leave the building”, and we said so, with local models sized as a later step.
  • Everything in version control. Groups, permissions, the model list and every setting are files applied by scripts, so a rebuilt server comes back as the same system.
AI at work, before and afterTwo columns. Before: public assistants on personal accounts, company documents pasted in, no view of cost, and access that outlived employment. After: one company workspace with work login, models the company chose, budgets per team and person enforced by a gateway, and access that follows the company directory.BeforePublic assistants, often on personalaccountsCompany documents pasted inNo view of what it costsAccess that outlives employmentConvenient for people, invisible to the company.AfterOne workspace, signed in with a workaccountOnly the models the company choseBudgets per team and person, enforcedAccess that follows the company directoryThe same convenience, under the company's rules.thecompany'srules, thesameconvenienceAI at work, before and afterTwo columns. Before: public assistants on personal accounts, company documents pasted in, no view of cost, and access that outlived employment. After: one company workspace with work login, models the company chose, budgets per team and person enforced by a gateway, and access that follows the company directory.BeforePublic assistants, often on personal accountsCompany documents pasted inNo view of what it costsAccess that outlives employmentConvenient for people, invisible to the company.the company's rules, thesame convenienceAfterOne workspace, signed in with a work accountOnly the models the company choseBudgets per team and person, enforcedAccess that follows the company directoryThe same convenience, under the company's rules.
Read the diagram as text
  1. Before: Public assistants, often on personal accounts, then Company documents pasted in, then No view of what it costs, then Access that outlives employment. Convenient for people, invisible to the company.
  2. the company's rules, the same convenience
  3. After: One workspace, signed in with a work account, then Only the models the company chose, then Budgets per team and person, enforced, then Access that follows the company directory. The same convenience, under the company's rules.

The decisions behind each of these rules, and how to make them for your own company, are in the guide Private AI chat for a company.

Implementation

How a question is answeredFour layers from top to bottom: people signing in with their work account; the chat workspace with assistants, knowledge and tools; the gateway that holds the only provider key, checks budgets and routes the question; and the chosen models from several vendors, with data collection off. Underneath: directory login, configuration in version control, and a staging copy with runbooks.Peoplesign in with their work account; directory groups decide what each person mayuseChat workspaceOpen WebUI: chat, assistants people build and share, knowledge bases, tools,mail and documentsGatewayLiteLLM: the only provider key, budgets per team and person, routing to acheaper or stronger model, fallbacksChosen modelsseveral vendors through one provider, with data collection switched off forevery modelUnderneathCompany directoryan account is created at first sign-in; sign-in ends when the person leavesthe directoryConfiguration as filesgroups, permissions, models and settings applied by scriptsStaging and runbooksevery change is tried on a copy first; IT has a written guide for each taskHow a question is answeredFour layers from top to bottom: people signing in with their work account; the chat workspace with assistants, knowledge and tools; the gateway that holds the only provider key, checks budgets and routes the question; and the chosen models from several vendors, with data collection off. Underneath: directory login, configuration in version control, and a staging copy with runbooks.Peoplesign in with their work account; directory groupsdecide what each person may useChat workspaceOpen WebUI: chat, assistants people build and share,knowledge bases, tools, mail and documentsGatewayLiteLLM: the only provider key, budgets per team andperson, routing to a cheaper or stronger model,fallbacksChosen modelsseveral vendors through one provider, with datacollection switched off for every modelUnderneathCompany directoryan account is created at first sign-in; sign-in endswhen the person leaves the directoryConfiguration as filesgroups, permissions, models and settings applied byscriptsStaging and runbooksevery change is tried on a copy first; IT has awritten guide for each task
Read from top to bottom. The workspace never holds the provider key; the gateway does, and it checks the budget before any model is called.
Read the diagram as text
  1. People: sign in with their work account; directory groups decide what each person may use
  2. Chat workspace: Open WebUI: chat, assistants people build and share, knowledge bases, tools, mail and documents
  3. Gateway: LiteLLM: the only provider key, budgets per team and person, routing to a cheaper or stronger model, fallbacks
  4. Chosen models: several vendors through one provider, with data collection switched off for every model
  5. Underneath: Company directory: an account is created at first sign-in; sign-in ends when the person leaves the directory
  6. Underneath: Configuration as files: groups, permissions, models and settings applied by scripts
  7. Underneath: Staging and runbooks: every change is tried on a copy first; IT has a written guide for each task

What the staff got:

  • One workspace in the company’s colours, in the staff’s own languages, which can also be added to a phone’s home screen.
  • Models chosen for the job, not the vendor. Entries are grouped by what they are good at, with an automatic default that sends each question to a cheaper or a stronger model as needed. Under every answer it says which model answered and how much it used.
  • Assistants people build and share, knowledge bases for company documents, web search, and image generation.
  • Their own mail and files. Microsoft 365 mail, OneDrive and SharePoint can be used as the signed-in person, with the permissions that person already has.
  • A workspace for files. Whole spreadsheets and attachments can be analysed in a terminal the assistant drives, instead of being squeezed into a chat message.
  • Help where they work. A help assistant, a short written guide, and a form to report a problem.
  • For developers, AI coding tools that use the same gateway, each with a personal key that has its own limit and expires.

What the company got:

  • A weekly usage and spend report for management, showing teams rather than individuals by default.
  • A tested path for every change, so updates reach staff without surprises:
How a change reaches staffSix steps: the change is written as configuration in version control, automatic checks run, a new image is built and labelled with its version, it runs on the staging copy, it is deployed with health checks, and staff see it. If the health checks fail, the previous version comes back by itself.Change written as filessettings, models, toolsAutomatic checksconsistency, a secrets scan,the whole stack startedImage built and labelledone version, never 'latest'Staging copytried before staff see itDeploy with health checkson the company's serverFails: the previous versioncomes backLive for staffHow a change reaches staffSix steps: the change is written as configuration in version control, automatic checks run, a new image is built and labelled with its version, it runs on the staging copy, it is deployed with health checks, and staff see it. If the health checks fail, the previous version comes back by itself.Change written as filessettings, models, toolsAutomatic checksconsistency, a secrets scan,the whole stack startedImage built and labelledone version, never 'latest'Staging copytried before staff see itDeploy with health checkson the company's serverFails: theprevious versioncomes backLive for staff
The same path for a new model, a new tool or an upgrade. A failed health check puts the previous version back without anyone having to act.
Read the diagram as text
  1. Change written as files (settings, models, tools)
  2. Automatic checks (consistency, a secrets scan, the whole stack started)
  3. Image built and labelled (one version, never 'latest')
  4. Staging copy (tried before staff see it)
  5. Deploy with health checks (on the company's server). Otherwise: Fails: the previous version comes back
  6. Live for staff

Outcome

  • Staff have one place for AI at work, signed in with their work account. Access starts and ends with the company directory.
  • Costs are visible and bounded. Spend is reported weekly by team, and a limit stops requests instead of sending a warning after the money is spent.
  • The data promise is clear and kept. Prompts go only to models the company chose, with data collection switched off, and the provider key never leaves the gateway.
  • IT can support it. Runbooks cover the everyday tasks, and every change takes the same tested path, with automatic rollback.

How it can grow

  • Local models for sensitive work. A server with its own AI hardware has been sized, so the most sensitive questions can be answered without leaving the building.
  • More company systems. The same connection that reads mail and documents can reach other tools the company uses, one at a time and with the person’s own permissions.
  • Less hand work for IT. Deploying automatically from inside the network, and scheduled backups with a tested restore.
  • Wider access. A safe route for phones outside the office, and room for more people as the company grows.

What this shows

A private AI chat is an integration project, not an install. The open-source products are good, and they are the easy part. What decides whether it works is the system around them: login from the directory, one key and real budgets, an honest data promise, and a way to change things that IT can trust.

What this means for your team

If your people already use AI on their own accounts, the question is not whether to allow it but where it should run. We can set up the same kind of workspace for you, sized to your team and your systems:

  1. Write down who would use it and with what data, and which of that data must stay inside the company.
  2. Choose where it runs and which models answer, with the data promise in plain words.
  3. Put a gateway in front of the models, with budgets per team and per person.
  4. Connect your directory and your documents, with the same permissions people already have.
  5. Hand it to your IT team with runbooks and a tested way to update it.

The method is in the guide Private AI chat for a company, and it is one of the things we do under Empes AI. If you want a second opinion on your own plan, book a call.

Stack
Open WebUI, LiteLLM, OpenRouter, PostgreSQL, Redis, Docker Compose, nginx, Python, GitHub Actions
Type
Strategy + implementation
  • ai
  • private-ai
  • open-webui
  • litellm
  • internal-tooling
  • governance
  • microsoft-365
  • self-hosted

Book a 30-min scoping call

Bring one process. We will tell you whether automation changes it, and what it would take.

Book a 30-min scoping call hello@empes.it