Run One Assistant for a Whole Institute or Company, and Hand It Over | Heidelberg AI Curriculum
T02-L05
Run One Assistant for a Whole Institute or Company, and Hand It Over
When 150 people use one assistant, its doors, budgets and records are yours to run. Put everyone behind the organisation's login, end a leaver's access with one tested action, give each group a budget, keep lean records, and hand it all to a substitute.
T02-L05 · Chat & assistants · Level 5 Operator · 20-minute read, plus 5 hours of doing
Two people left, their access didn't
The group assistant from last spring is now the institute's assistant. It runs on a server IT looks after, 180 people in twelve groups use it, and it answers from a local model and, for some groups, a hosted one. This month two postdocs left. Their university accounts were closed on their last day, but both still had working accounts on the assistant: they had been created with passwords during the pilot, before the university login was connected. One group's bill for the hosted model tripled, and nobody could say why until IT found a student's script calling the assistant with a personal key, 4,000 times a night. And while chasing that, IT noticed the server logs held the full text of every question since June, because someone had turned logging up to debug a problem and never turned it down.
In a company it's a 150-person medical device supplier. The quality team's assistant became the company's assistant in the summer. Now the works council asks what is recorded about each employee, the finance director asks what each department costs, and the only person who knows how any of it works goes on parental leave in eight weeks.
You are at Level 5 Operator. When the assistant stops, or lets the wrong people in, work stops or leaks for everyone. This book shows you how to run it: who gets in and how they get out, what it costs per group, what you record and for how long, what you watch, and who takes over.
After this you can
Put every person behind the organisation's login, close every other way in, and end a leaver's access with one action you have tested.
List every account, key and emergency access with an owner and a way to revoke it, in an access audit a colleague can repeat.
Give each group a monthly budget and see cost per group, without per-person monitoring the works or staff council hasn't agreed to.
Keep only the records you need to run and audit the service, for a period the data protection officer has signed.
Watch the service weekly, handle an outage or a leaked key from a runbook, and hand it all to a substitute who has run it without you.
Before you start
Books:T01-L01 · From Idea to Working Result: The Four-Quadrant Method for the four-quadrant method. for what Open WebUI keeps and who can reach it. for the this book runs: Open WebUI, a model and Caddy, the web server in front, each in its own (one boxed program), started together by Docker Compose, with and updates. for locking the server itself.
Administrator access to the assistant's server, and a contact in IT who administers the organisation's login system.
Two test accounts in the login system, one ordinary and one to be "offboarded", and permission to disable one of them.
The people involved: the service owner (the institute's managing director or the company's IT lead), your data protection officer, the staff council or works council, and a named substitute with five hours over the next month.
About 5 hours 20 minutes: 20 to read, about 5 hours to do, over a month.
Last verified 23 September 2026. Open WebUI and LiteLLM, the budget gateway here, are free and open source. Without Redis, a small helper database, a deactivated Open WebUI user stays signed in until their login expires: four weeks by default. Details for experts at the end of this book.
The idea in one page
A shared assistant has five things someone must run. Each has a question you should be able to answer on any day.
What
The question
Where it's decided
The way in
Which single action ends a person's access, and how fast?
The organisation's login, and the assistant's session settings
The other doors
Which accounts and keys does that action not reach?
Your access audit
Cost
What did each group spend last month, and what stops a runaway script?
A gateway between the assistant and the models
Records
What is kept about each person, who may read it, and for how long?
The data protection officer and the staff or works council
Continuity
Who runs it when you're away, and have they done it?
The runbook and your substitute
One action for people. Everyone signs in through the organisation's login, the single sign-on (SSO) that already runs email and the intranet. The organisation's IT disables a leaver there, and that one action must end both a fresh login and a session that's still open in someone's browser. Two settings decide whether it does: how long a login lasts in the assistant, and whether the assistant can cancel a session early.
Every other door, listed. SSO only covers people who sign in through it. Pilot accounts with passwords, personal API keys, a script's key, an emergency admin account: each is a door the SSO action never reaches. The access audit lists them all, each with an owner, a purpose and a way to revoke it. Routine password logins are switched off entirely; one sealed emergency account stays, for when the login system itself is down.
Budgets live in a gateway. A gateway is a small program that sits between the assistant and the models, passes every request on, and counts what each costs. This book uses LiteLLM. It can stop a person or a key at a monthly budget, so a runaway script hits a wall instead of the invoice. Groups see their costs as totals.
Records: references, not content. To run the service you need who signed in when, which model was used, what it cost, and errors. You don't need the text of people's questions in your logs. The chats themselves stay in the assistant, where each person can see and delete their own, for a period the data protection officer sets.
A person, not a folder, is the backup. A runbook with a page per situation, and a substitute who has repeated the access audit and the leaver test while you watched without helping.
Worked example: an access audit, a budget and a handover
Structure it (20 min). Lena, who built the group assistant in T11-L04 · Put Your Team's Assistant on a Server Colleagues Can Reach, now runs the institute's service with Paul from IT. After the two leavers she writes: "Anyone who leaves the institute loses the assistant the moment IT closes their university account. Every other way in has an owner. Each group sees its monthly cost and can't overrun it by surprise. We keep only what the data protection officer has agreed. Paul can run all of it without me."
Understand it (90 min). She starts an access audit, a table with one row per way in. Open WebUI's admin panel lists 196 accounts. IT compares them with the university directory: 23 were created with passwords during the pilot, four of them for people who have left. 173 sign in through the university login. Six people have personal API keys, keys that let a program use the assistant in their name, because the pilot's settings let ordinary users create them. One is the student's script.
Then the leaver test, with a test account IT creates for this purpose. The test user signs in and keeps the browser open. IT disables the account in the university directory. A fresh login fails at once. The open browser keeps working: the next day, and the one after. Lena reads Open WebUI's documentation. A login lasts four weeks unless you shorten it, and without Redis, deactivating a user doesn't end the session they already have.
She checks the logs. Open WebUI's audit log, its record of requests, had been set in June to keep full requests and answers. The staff council has never been told that questions were being kept, and neither has the data protection officer.
This changes the problem. She'd thought of it as "connect SSO properly". SSO was connected; the problem is everything around it. Back to Structure it: "The university login is the only routine way in, and a session can't outlive it by more than a working day. Every key is someone's, with a budget. The logs hold references, not questions."
Redis, a small in-memory database, added as one more container on the server. With it, Open WebUI can cancel a deactivated person's session at once. Logins are shortened to 12 hours as a second line of defence.
LiteLLM as the gateway, in its own container, with its small Postgres database for the running totals. Open WebUI sends every model request through it and passes on who is asking; LiteLLM records the cost per person and stops anyone at a monthly limit. IT sums the totals by group once a month.
Uptime Kuma, a free self-hosted monitor, checks every five minutes that the assistant answers and alerts Paul and Lena when it doesn't.
The alternative for the gateway is to give each group its own model connection with its own provider key and spending limit. That works for three groups; for twelve it becomes twelve keys to look after.
open-webui:
environment:
ENABLE_SIGNUP: "false" # nobody creates an account by themselves
ENABLE_PASSWORD_AUTH: "false" # only the university login
JWT_EXPIRES_IN: "12h" # a login lasts at most 12 hours
REDIS_URL: "redis://redis:6379/0" # lets deactivation end a session at once
ENABLE_FORWARD_USER_INFO_HEADERS: "true" # tells the gateway who is asking
redis:
image: redis:7
The first two lines close the password route. The third limits how long any login lasts. The fourth connects Redis, which runs as its own small container. The last makes Open WebUI tell the gateway which person each request comes from. She restarts the containers on the staging server first, the test copy of the server from T11-L04 · Put Your Team's Assistant on a Server Colleagues Can Reach, repeats the leaver test there, and only then on production.
Two more changes route the models through the gateway. In Open WebUI's admin settings, under Connections, the model connection now points at LiteLLM's address, with a key LiteLLM issued, instead of at the provider. And one line in LiteLLM's configuration, named in Details for experts, tells it to read the person's name from what Open WebUI sends along.
The 23 password accounts are converted to university logins where the person is still at the institute; the four leavers' accounts are deactivated. Personal API keys are switched off for ordinary users: Lena removes the API Keys permission from the default permissions every user gets. The student's script gets a proper key issued by the gateway, with its own monthly limit, owned by his group leader. Keys like this are created in LiteLLM's admin page under Virtual Keys, then Create Key, where the budget is set too.
One password account stays: an emergency admin, for when the university login is down. It only works after an administrator switches password login back on at the server, which needs the server login only Paul and the head of IT have. Its password sits in IT's password manager, every use is recorded and reviewed, and the procedure is tested twice a year.
Build it: the leaver test, again (20 min). The test user signs in and keeps the browser open. IT disables the account in the directory at 14:00. A fresh login fails at once. The open browser still works: Open WebUI doesn't know yet. So IT adds one step to its existing leaver process: a nightly script that asks the directory which accounts were disabled and deactivates the matching Open WebUI accounts through Open WebUI's API, its interface for programs. At 02:00 the job runs; with Redis in place, the open session ends at once. The stated window: access ends at the next nightly run, at most 24 hours; immediately if IT deactivates by hand. That line goes into the access audit.
Build it: budgets (40 min). Each person gets a default monthly limit of €15 on the hosted model, set once in LiteLLM as the default budget for every person without their own. LiteLLM counts in US dollars, so Lena enters the dollar amount closest to €15. The local model has no limit, because it runs on the institute's own hardware. Two groups with heavy literature work get €40 per person by agreement with the managing director. On the first of each month LiteLLM's totals go into a one-page report: cost per group, the three largest items, and any key near its limit. Individual figures stay in LiteLLM, where only Lena and Paul can see them, to enforce limits and nothing else. The staff council agrees to exactly that in writing.
Build it: records (30 min). With the data protection officer, Lena writes a records table:
Record
What it holds
Who may read it
Kept for
Sign-ins
who, when, success or failure
Lena, Paul
90 days
Gateway entries
who, which model, cost, errors; no question text
Lena, Paul
90 days
Audit log
request metadata only
Lena, Paul
30 days
Chats
the chats themselves, in the assistant
the person; admins only under the agreed procedure
deleted after 12 months without use
Monthly cost report
totals per group
managing director, group leaders
3 years
The audit log level goes back to metadata: who, when and which request, without any text. The six months of logged questions are deleted, with the data protection officer's agreement and a note in her records. The staff council gets the table.
Build it: weekly watch and runbook (30 min). Every Monday a short post goes to the service channel: availability last week from Uptime Kuma, accounts in the assistant not found in the directory (should be zero), keys near their limit, the date of the last restore test (the last time a backup was actually restored, to prove it works), and any Open WebUI or LiteLLM release waiting to be installed. The runbook has a page each for the assistant is down, a model provider is down, a key has leaked, a budget is used up, a monthly update and someone leaves. The leaked-key page is three steps: delete the key on LiteLLM's Virtual Keys page, issue a new one to its owner, check the key's spending for the last week.
Build it: handover. Paul repeats the full access audit from the runbook while Lena watches without helping: counts accounts against the directory, runs the leaver test, checks the emergency account's alert, reads the monthly report. He gets stuck once, on where LiteLLM's admin password is kept, and the runbook gets the line. In November the university's data protection audit asks for "a list of every account with access to the assistant, and how access ends". Paul sends the access audit.
What it taught her: connecting the login took an afternoon. Finding the doors it didn't cover took a week, and each one had been opened for a good reason by someone trying to help.
Company: the company-wide assistant
Structure it. Jonas, the quality lead from T11-L04 · Put Your Team's Assistant on a Server Colleagues Can Reach, runs the assistant for 150 people; it uses an EU model provider through the company's contract. His deputy, Aylin from IT, takes over in eight weeks. "Everyone signs in with their Microsoft account, and switching off that account ends their access within an hour. Each department has a budget. The works council knows exactly what is recorded. Aylin can run it alone."
Understand it. The company's login is Microsoft Entra ID, Microsoft's account system behind Microsoft 365. Entra can also tell connected apps when an account is created, changed or disabled, through a standard called SCIM, and Open WebUI accepts it. His access audit finds 12 password accounts from the pilot, one shared quality-team account used by three people, and the provider key sitting in plain text in a reporting script on a colleague's laptop.
The works council's first question changes the plan. Per-person costs would show who uses the assistant how much, which is information about employees' behaviour, and in Germany introducing that needs the works council's agreement. Back to Structure it: "Departments see department totals. Per-person figures exist only to stop a runaway, and only two named admins see them, for 90 days."
Choose tools. Entra ID for sign-in and groups, with SCIM so that disabling an account in Entra deactivates it in Open WebUI straight away and ends its session. To connect them, IT switches SCIM on in Open WebUI with a secret token, then in Entra adds Open WebUI as an enterprise application, turns on provisioning (Entra's word for sending account changes), and enters Open WebUI's SCIM address and the token. LiteLLM with a monthly budget per department and a small default per person. The provider's own spending limit on the company account, as a last stop behind LiteLLM.
Build it. The pilot accounts become Entra logins; the shared account is closed and its three users get their own. The reporting script moves to a key issued by LiteLLM, stored in the company's password manager, owned by the finance team. Jonas tests the leaver path with a test account: IT disables it in Entra at 10:00; SCIM reaches Open WebUI within minutes and the open session ends at 10:07. The works council signs an agreement with the records table attached. Aylin runs the audit, the leaver test and a monthly update from the runbook while Jonas watches, and in her second week handles a real case alone: a department's budget runs out on the 20th, and the runbook says who may raise it.
In both cases the login was never the problem. The doors next to it were, and the decisions nobody had written down: what's recorded, what each group may spend, who takes over.
What goes wrong
Pilot accounts outlive the pilot.Symptom: people who left still sign in with a password from the early days. Fix: switch off password logins and sign-up entirely once SSO works. Keep one sealed emergency admin account, with an alert on every use.
Disabling a person doesn't end their session.Symptom: the leaver's fresh login fails, but their open browser keeps working for weeks. Fix: shorten how long a login lasts, and connect Redis or SCIM so deactivation ends sessions. Test with an open browser, not only a fresh login.
Keys nobody owns.Symptom: a script, a personal API key or a shared account runs up costs, and nobody can say whose it is. Fix: every key in the access audit, with an owner, a purpose, a budget and a revocation step. Switch off personal keys for ordinary users.
Budgets only on the invoice.Symptom: you learn about a runaway script from next month's bill. Fix: limits in the gateway per person or key, a monthly report per group, and the provider's own spending limit behind it.
Logs become a copy of everyone's questions.Symptom: debug logging from months ago still records every question. Fix: log metadata only, write down who reads what for how long, and check the log level after every change.
Per-person monitoring by accident.Symptom: the cost report names individuals, and the works or staff council hears about it from someone else. Fix: report by group. Agree in writing who sees individual figures, for what and for how long, before the first report goes out.
The operator is the runbook.Symptom: when you're away, nobody can add a group, raise a budget or answer an auditor. Fix: a runbook page per situation, and a substitute who has done each one while you watched.
Do it yourself (5 hours, over a month)
Structure it (20 min). Write one sentence each for the way in, the other doors, cost, records and continuity: what must be true, and who decides.
Understand it (90 min). List every account, key and admin in the assistant and compare with the directory. Run the leaver test with an open browser and a fresh login. Check the log level and what the logs hold. Ask who has been told what is recorded.
Choose tools (20 min). Decide how deactivation will end sessions, where budgets are enforced, and what monitors availability. Name one alternative and why you didn't pick it.
Build it: doors and leaver path (90 min). Close password logins and sign-up, convert or remove pilot accounts, give every key an owner, seal one emergency account. Test changes on staging first. Repeat the leaver test and write the stated window into the access audit.
Build it: budgets and records (60 min). Set limits per person or key, and the monthly group report. Write the records table with your data protection officer and give it to the staff or works council.
Build it: watch and handover (40 min). Set up the Monday post and the runbook pages. Have your substitute repeat the access audit and the leaver test while you watch without helping. Fix every place they got stuck.
Exit check
Written finding: an access audit for the shared assistant, containing:
every way in: each account type, key and emergency access, with owner, purpose and revocation step;
the leaver test: the one action, the times for a fresh login and an open session, and the stated window;
the budgets: limits per person, key or group, and last month's cost per group;
the records table, signed by the data protection officer, and the staff or works council's agreement;
your substitute's run, with the date and where they got stuck.
It passes when a test leaver loses both an open session and a fresh login within the stated window after one action, no routine password login works, and your substitute repeated the audit from the runbook alone.
Rule to remember
One action should end a person's access; list and own every door that action can't reach.
Details for experts
Checked on 23 September 2026. You don't need this to follow the book; it's for setting things up or answering a colleague.
What
Details
What it means for you
Open WebUI
Release v0.11.4, 21 September 2026. ENABLE_SIGNUP and ENABLE_PASSWORD_AUTH default to true. JWT_EXPIRES_IN, how long a login lasts, defaults to 4 weeks; -1 means never, which Open WebUI warns against.
Set both to false once SSO works, and shorten logins to 8 to 24 hours.
Ending sessions
Without Redis, signing out, a password change or deactivation doesn't invalidate a login that's already been issued. With Redis (REDIS_URL), the login goes on a revocation list at once.
Add Redis before relying on deactivation.
SCIM
SCIM_ENABLED=true (newer name ENABLE_SCIM) and a SCIM_TOKEN open the address /api/v1/scim/v2, where an identity provider (the login system, such as Entra ID) can create, update and deactivate users and groups. Deactivation sets the account to pending and ends its live connections as soon as the update arrives.
The one-action leaver path, where your login system supports SCIM.
AUDIT_LOG_LEVEL: METADATA (who, when, which request), REQUEST or REQUEST_RESPONSE, which add question and answer text. Open WebUI recommends auditing sign-in routes and restricting API key creation to admins; ordinary users need the API Keys permission to create one.
Keep it at METADATA, and check it after every change.
LiteLLM
Open-source gateway; stable release v1.102.1. With ENABLE_FORWARD_USER_INFO_HEADERS=true in Open WebUI, LiteLLM's user_header_mappings reads the person from the X-OpenWebUI-User-Id or X-OpenWebUI-User-Email header. Budgets are counted in US dollars. They can be set per team, user, key, model or end user (the person behind a request), reset on a period such as 30d, and need a Postgres database. A default budget applies to every end user without their own.
Per-person limits stop runaways; group totals come from the monthly report.
Monitoring
Uptime Kuma: free, self-hosted, checks addresses at set intervals and sends alerts.
Heidelberg AI Desk: Catalogued. The route for one computer or a small group, before a server.
Watch
LiteLLM AI Gateway: Routing, API Keys, Budgets, and Guardrails for Local and Cloud Models
LiteLLM AI Gateway: Routing, API Keys, Budgets, and Guardrails for Local and Cloud ModelsPaul Zuradzki
T02-L05: See how LiteLLM scopes model access and sets budgets on gateway keys. Local-model prices are simulated; follow the book for per-person access and logging. Guardrails are mentioned, not demonstrated. The recording has left-channel-only audio.
AI Breakthroughs Everyone MissedVideo · Matt Wolfe · Oct 21, 2026
In this AI news roundup, Matt Wolfe shares lesser-known AI developments. Fish Audio released Drama 3, a text-to-speech model that lets users direct performances in plain English using bracketed stage directions, word-specific effects, sound effects, and multiple voices; it tops Artificial Analysis on pronunciation (scoring above 11 Labs and SpaceX's model) but ranks lower on preference tests, is open-weight (36 billion parameters) on Hugging Face, needs substantial VRAM (roughly 46 GB, or about 32 GB with a community 4-bit quantization), is free for commercial use under $500,000/year revenue, and its API is $10 per million characters now, rising to $50 after November 12. BytePlus (Bite Dance) released OmniHuman 2.0, which generates talking, singing, or acting video from a single image and audio track, now up to five minutes in one continuous shot (versus 60 seconds before), in 720p, with text prompts to control camera moves, and it works on humans, cartoon characters, and animals; pricing dropped from 12 cents to 7 cents per second (about $21 for a full 5-minute video). Tencent Arc Lab released WorldCrafter, a world model that generates navigable video worlds from a single image or line of text. The video also lists additional resources including Matrix Game 4.0, NVIDIA StreamRender-H3, and an Odyssey update.
AI News: 6 New Models & A Nano Banana KillerVideo · Matt Wolfe · Oct 16, 2026
In this weekly AI news roundup, Matt Wolfe covers several new image models and large language models. He leads with Krea 3, a new image editing model now in public beta, calling it the best image editing experience he has had and noting it does cleaner edits than ChatGPT Image or Nano Banana for quick thumbnail changes. Three new image models are featured: Krea 3, Black Forest Labs' open-weight FLUX 3 Image Klein (which can run on consumer GPUs such as the RTX 4070 and be tried free on Hugging Face Spaces), and Alibaba's open-weight Qwen Image 2.1 Turbo. The roundup also covers Google's Gemini 4 Argon, Meta's Muse Wonder, recent OpenAI updates, and Grok Voice 3.0.
AI just BROKE all of the software industry...Video · Wes Roth · Oct 15, 2026
In this creator video, the host argues that AI can now reverse-engineer almost any software, citing examples of games being ported or remixed—Mario 64 in Elden Ring, Spider-Man in Batman: Arkham Knight, Minecraft in GTA V, and Snowboard Kids rebuilt for PC. He points to SRE Bench, a benchmark measuring whether AI agents can reconstruct a program's functionality without its source code, and credits 'GPT-6 Astra' (per the transcript) with solving roughly 88% of tasks on a single attempt and 99.2% within four tries. He references the benchmark's paper, 'The Next Cybersecurity Agent Challenge X: A Realistic Contamination-Free Reverse Engineering Benchmark,' attributed to researchers at Google DeepMind, OpenAI, Anthropic, UCLA, UC Berkeley and Columbia. He explains 'clean-room engineering' as a legal method to replicate software without copying source code. He says he used the model in 'Ultra' mode to build his own video editor from a functional description—canceling his subscription to a video-editing service—and warns of a growing trend of 'revenge software,' where customers clone software from companies that anger them.
GEMINI 4 ARGON IS WEIRD...Video · Wes Roth · Oct 14, 2026
Google has started rolling out Gemini 4 Argon, a new model available to Gemini 'Pro' and 'Ultra' subscribers in Gemini chat and AI in search, and to 'Ultra' subscribers on Antigravity, Google's development platform. The creator tested Google's demos (Wizard Chess and Desk Racer on Google AI Studio) and built his own games, concluding the model is powerful but 'weird' - it tends to build more ambitious first drafts with simpler graphics and more features, and is notably different to prompt than other models, a view echoed by other creators. Google also announced Gemini 4 Argon for robotics, evaluated via Andon Labs' Drone-Bench, and shared safety findings about shortcuts that stopped appearing in the model's reasoning.
