Private LLM chat for education

Private LLM chat for education: why a campus assistant is not a staff rollout

A university IT or academic technology leader who must offer a chat assistant to thousands of students and staff is not running a staff pilot at a larger size. Student records fall under FERPA (34 CFR Part 99), which applies to any institution that receives funds under a program administered by the US Secretary of Education. Some campuses also enroll minors, which brings the COPPA Rule (16 CFR Part 312) into play for operators collecting personal information from children under 13. Usage is also uneven: students arrive in bursts before deadlines and exams, so the design must handle a heavy tail of occasional users on shared GPUs rather than a steady population of daily power users. Confirm with counsel which student populations, including dual-enrolled high school students and minors in summer programs, fall under each rule before the first user logs in.

The identity model changes the design most. A campus assistant is usually driven by the university directory, not by a list of accounts an admin maintains. Open WebUI documents SSO through OIDC and LDAP and SCIM 2.0 provisioning of users and groups, and LibreChat supports federated sign-in as well, so the first design decision is which group attributes the directory emits and how they map to roles. A student must never inherit staff permissions, and a staff member with a research appointment must not gain access to student education records by way of a shared knowledge base. Plan a separate knowledge scope for each population, enforce it with groups and per-resource permissions, and confirm that the directory can supply the affiliation attributes you need.

The short answer on platforms: use Open WebUI or LibreChat for the interface, vLLM or Ollama for model serving, and an AI gateway such as LiteLLM for budgets, keys and logs, all deployed in the institution's own infrastructure. Ollama is a practical starting point for small models and modest concurrency, while vLLM is the more likely fit for shared campus traffic, which you should confirm with a load test on your own GPUs. Open WebUI's branding clause applies above 50 users in any rolling 30-day period, so a campus-wide rollout needs a license decision before launch. Treat the gateway as the place where per-department budgets and student-level usage records are enforced.

Which education rules shape the assistant build

This table maps each education-related requirement to what it means for the campus assistant's design, access model and evidence. Read each row against your institution's funding, student population and data flows, because applicability depends on those facts and must be confirmed with counsel. The main takeaway is that identity, record-keeping and retention decisions made at build time are much harder to add after pilot users are onboarded.

Requirement	What it means for the build	Evidence an assessor or auditor will expect
FERPA school official conditions (34 CFR 99.31)	If a hosting partner or vendor handles student records, it must perform a service staff would otherwise do, work under the institution's direct control, and follow redisclosure limits. Keep the operator inside the institution's own accounts where possible.	Signed agreement defining school official status, direct control terms, and documented roles for anyone with administrative access to chat stores
Legitimate educational interest (34 CFR 99.31(a)(1)(ii))	Chat history, uploads and knowledge bases must be scoped so staff see only records tied to their role. Group-based access in the interface and separate knowledge collections per department reduce exposure.	Role and group mapping from the directory, access reviews, and test results showing a user cannot retrieve another department's uploaded files
Disclosure record (34 CFR 99.32)	Where a chat retrieves or summarizes personally identifiable information from education records, the platform should log who accessed which record and why, for as long as the underlying records are kept.	Retention settings for access logs aligned with the records schedule, plus sample log entries linking user, record and purpose
Inspection window (34 CFR 99.10(b))	If chats or uploads contain education records, the institution must be able to locate and produce them within 45 days of a request. Ask whether the chat store can be searched by student identifier.	Documented search procedure, a tested export of one user's chat and file history, and named owners for responding to requests
COPPA retention and security (16 CFR 312.8 and 312.10), if children under 13 use the assistant	Applies only if the scope includes pupils under 13 and the operator collects their personal information. Requires a written security program, annual risk assessment, a designated coordinator and a written deletion timeframe.	Written information security program, risk assessment records from the most recent cycle, and a data retention policy with deletion timeframes for children's data
GLBA Safeguards Rule through Title IV (16 CFR Part 314)	Institutions in Title IV aid programs agree to the Safeguards Rule. Any system holding student financial aid data needs a written security program, multi-factor authentication for all users and FTC notification within 30 days of a qualifying event affecting at least 500 consumers.	MFA enforcement settings for the chat login, incident response plan naming the 30-day notification step, and the written information security program
ADA Title II web accessibility (28 CFR Part 35 Subpart H)	Public institutions must make web content and mobile apps accessible. The chat interface, admin consoles and any embedded help pages fall within that scope, so accessibility testing belongs in the build plan rather than after launch.	Accessibility test results against the referenced technical standard, a remediation log, and a published accessibility statement for the assistant
EU AI Act record-keeping (Articles 12(1) and 19(1))	Applies only if a use case is high-risk under the Act. Then the system must technically allow automatic event logging over its lifetime, and providers must keep logs for at least six months unless other law requires more. Confirm classification before designing logging.	Log design document showing which events are captured, retention period set at or above six months, and a classification memo from counsel

How student, staff and minor data get separated in one assistant

Student records are governed by FERPA when the institution receives funds from a program administered by the US Secretary of Education (34 CFR 99.1). Students should be able to use the assistant for coursework, but the policy has to define which education records may be pasted or uploaded, because an assistant that receives a transcript or disciplinary file has created a new place where that record lives. The campus group policy and its knowledge collections decide what a student account can reach.

Permitted inputs: Course materials, public catalog content and the student's own drafts, with a written rule against pasting other students' records or advising notes.
Group mapping: Students are assigned to a student group from the directory through OIDC or LDAP, with model access and knowledge collections granted per group.
Chat history: Confirm whether history is visible only to the student, whether administrators can read it and under what logged process.
Retention: Set a deletion timeframe for chat history and uploads, and document it in the retention policy.

Confirm in a test that a student account cannot see a staff knowledge collection, even by guessing its identifier.

Which open-source platforms fit a campus assistant and why

A campus assistant needs an interface that federates with the university directory, a serving layer that copes with bursty use on shared GPUs, and a gateway that enforces budgets and logging. The five platforms below cover those layers, and each leaves policy decisions with the institution.

Open WebUI as the chat interface

Open WebUI documents SSO through OIDC and LDAP, SCIM 2.0 user and group provisioning, role-based access control with groups, API keys and authenticator-app MFA, which map onto directory-driven student and staff roles. Check the branding clause: it restricts altering or removing branding in deployments above 50 users in any rolling 30-day period unless the institution holds an enterprise license or written permission. Confirm the license position before a campus-wide rollout.

LibreChat as an alternative

LibreChat is MIT licensed, which removes the branding restriction that applies to Open WebUI. It is a credible interface to evaluate, but the institution must test its identity federation, group provisioning, retention settings and audit trail against the same requirements as Open WebUI. Do not assume feature parity; ask the partner to demonstrate each requirement in a pilot tenant.

vLLM for shared GPU serving

vLLM is an Apache-2.0 serving engine that exposes an OpenAI-compatible endpoint, suited to serving many occasional users from shared GPUs. The institution still decides which open-weight models run, how many GPUs are committed, and how concurrency is capped during exam periods. Ask the partner to size throughput for peak concurrency, not average daily use, and to show how the endpoint is restricted to internal callers.

Ollama for departmental deployments

Ollama is an MIT runtime that suits smaller or departmental pools rather than a campus-wide shared service. Its default of one parallel request per model and a queue of 512 requests will shape user experience under load, so tune OLLAMA_NUM_PARALLEL and test the queue before wider use. Set OLLAMA_NO_CLOUD=1 so cloud features are switched off, and confirm the local API is never exposed without an authenticated proxy in front of it.

LiteLLM for budgets and logging

LiteLLM is an MIT gateway that can apply per-group budgets, request logging and guardrails in front of the model servers, which is where campus cost allocation and audit records usually sit. The enterprise directory in its repository is under separate terms, so confirm which features the institution would use fall outside it. The gateway does not decide retention periods or which student data may be sent to a model; those policy choices stay with the institution.

What serving thousands of occasional users on shared GPUs costs

Campus demand is bursty. Usage climbs during course starts, assignment deadlines, exam periods and admissions peaks, then drops sharply. That pattern makes peak concurrency and queueing, not total user count, the number that drives the GPU bill. Thousands of registered accounts may produce only a few hundred simultaneous generations at the busiest hour, and that peak is what the hardware must absorb without users waiting. Ask every bidder to state the concurrency figure they sized for, the peak period they assumed, and the response time they expect at that peak. A quote that sizes by seat count alone should be treated as incomplete.

The cost has five components, and they split differently between one-time and recurring spend. One-time items include GPU servers or the setup work for cloud GPUs, the identity federation and security hardening, and the initial configuration and testing. Recurring items include cloud GPU hours if you rent capacity, power and hosting for owned hardware, the interface's enterprise license if you choose one, storage for chat history and logs, patching of model runtimes and interfaces, and staff time for operations. Make sure the quote separates these lines. Cloud GPUs bill by the hour whether or not students are online, so reserved capacity for predictable peaks and on-demand capacity for overflow are worth pricing separately. Confirm with the vendor whether the interface license is priced by seat or by active users, because that changes the figure substantially at campus scale.

The main drivers are concurrency per model, model size and context length, number of replicas, and retention volume. Ollama defaults to one parallel request per model (OLLAMA_NUM_PARALLEL), allows up to three loaded models per GPU (OLLAMA_MAX_LOADED_MODELS) and queues up to 512 requests (OLLAMA_MAX_QUEUE). A quote built on those defaults will show queueing under exam-week load unless the partner has raised the parallelism and tested it. vLLM instead batches concurrent requests on the GPU, so its throughput depends on memory for the KV cache, which grows with context length. Require the partner to state which runtime they chose, the parallelism or batch settings, the maximum context length, and load test results at your assumed peak. Each of these settings changes how many GPUs you need.

How a campus rollout moves from a pilot cohort to the full student body

The sequence takes a campus assistant from a scoped pilot to full enrollment in waves, with each phase producing a signed artifact that gates the next.

Classify data and fix the scope
The university's privacy office, registrar, legal counsel and the DeployOpen team agree which records, populations and use cases are in scope, including whether any student education records may be pasted or uploaded. Records are classified and written data rules are set for prompts, uploaded files, chat history and retention. Work is done when a signed scope document and data rules are approved by the data owners. Ask the partner to show how FERPA school official conditions and contractor control obligations are written into the agreement, and confirm the GLBA and COPPA applicability for your population with counsel.
Map directory attributes to access groups
The identity team and DeployOpen design how the university directory feeds the assistant through OIDC or LDAP, and how SCIM 2.0 provisioning maps directory attributes such as affiliation, program and enrollment status to Open WebUI groups. Each group gets defined model access, file upload rights and knowledge base permissions, and student and staff populations are kept in separate groups with separate data boundaries. The output is a group matrix that the data owners sign off, along with a test plan showing that a deprovisioned user loses access. Confirm with your directory team which attributes are reliable enough to drive access.
Run a pilot cohort within the branding threshold
A small, named cohort uses the assistant under a pilot acceptable use policy that covers permitted data, citation expectations, academic integrity rules and reporting of misuse. Open WebUI's branding clause applies above 50 users in any rolling 30-day period unless the institution holds an enterprise license or written contributor permission, so the pilot is either kept at or below that count or covered by one of those arrangements before it grows. The output is the signed pilot policy and documented test results for authentication, group access, file handling and logging. Confirm the license position with the vendor before enrolling anyone beyond the pilot.
Scale to multiple replicas with shared state
Once the pilot passes, the platform moves off a single container to multiple replicas. The Open WebUI scaling guide calls for PostgreSQL instead of SQLite, Redis for sessions, websocket connections and application state, and shared file storage so uploads and knowledge remain reachable from every replica. DeployOpen configures these components, and the university's platform team reviews backup and restore for each. The output is a load test report at the expected concurrency and an operations runbook covering failover, scaling and restore steps. Ask whether the external vector database used for knowledge features has the same backup and access controls as the rest of the stack.
Size model serving for concurrent campus use
Model serving is tuned to the concurrency the load test measured, not to total headcount, because occasional users on shared GPUs create bursts at class start times and assignment deadlines. Ollama's default of one parallel request per model and its queue limit are compared against vLLM's serving characteristics for the chosen models, and the team sets the parallelism, loaded model count and queue depth accordingly. The output is a sizing record that states the GPU count, models served and the queueing behavior seen under test. Ask the partner to show how queue wait time is measured and what happens to requests when the queue is full.
Enroll students and staff in staged waves
Enrollment proceeds by group in waves, with each wave opened only after the previous one meets agreed thresholds for response time, error rate, queue depth and per-user cost. Monitoring tracks concurrency, queued requests, model load time and GPU utilization by group, and cost reports show spend per group or API key where the chosen tooling supports it. Each wave closes with a short report recording issues, policy exceptions and changes made. Confirm before the first wave which thresholds the university has set, who can halt enrollment, and how cost is charged back to departments.
Operate with a patch cadence for fast-moving releases
After full enrollment, the platform is run under a documented support model covering security patches, version upgrades and model updates. The project release cadence is fast: Open WebUI published v0.12.0 on October 10, 2026 and v0.12.3 on October 16, 2026, and Ollama published v0.40.5 on October 14, 2026 with v0.40.6 as a pre-release on October 16, 2026. Each upgrade is tested in a staging copy against the group matrix and load test before production. The output is a support agreement, a change calendar and a quarterly review of acceptable use incidents and access reviews. Ask the partner how they test releases, roll back a failed upgrade and handle a license change in a dependency.

What auditors and compliance offices ask the assistant to prove

This table maps each compliance question a campus office or assessor may raise to the component that produces the evidence and the gap to close before rollout. Read each row as a control question, the evidence it needs, and the system that must generate it. DeployOpen prepares this evidence, but auditors, regulators and the institution's own compliance staff decide whether it is sufficient.

Control or question	Evidence to produce	Component that generates it	Where it usually fails
Legitimate educational interest (34 CFR 99.31(a)(1)(ii))	Roster of groups and roles that can open student-related chats or files, with the reason each group needs access	Identity provider groups and Open WebUI role-based access control with groups and per-resource permissions	Broad staff groups granted access by default, and roster changes never reviewed after a term ends
Disclosure record (34 CFR 99.32)	Log of who accessed or received personally identifiable information from student records, with the stated legitimate interest	Gateway and application logs, retained for as long as the records are kept	Logs exist but do not record which user or group accessed which student data, or they roll over too quickly
Contractor as school official (34 CFR 99.31(a)(1)(i)(B))	Written agreement showing the institution controls use and maintenance of the records, and redisclosure limits	Contract file and administrator access list for the hosting and implementation partner	Vendor support staff hold standing access without a documented institutional approval
Minors' chat data (16 CFR 312.10), where under-13 users are in scope	Written retention policy with a deletion timeframe, and deletion records for chat history and uploads	Open WebUI chat retention settings, database and file storage cleanup jobs, and deletion logs	Retention is set in policy but chats persist in backups, exports or vector stores after the stated period
Multi-factor authentication (16 CFR 314.4(c)(5))	Configuration showing MFA enforced for every account that reaches the assistant, including administrators	Identity provider MFA policy and the Open WebUI authenticator-app MFA setting	MFA applied to staff but not to administrators, API key holders or service accounts
Written security program and risk assessment (16 CFR 314.4 and 312.8)	Current written program with a named coordinator, and dated risk assessment records	Institution governance documents, system security plan and change records kept with the platform	Risk assessment written once at launch and not updated after model, plugin or version changes
Log retention for high-risk use (EU AI Act Articles 12 and 19)	Automatic event logs kept for at least six months where the assistant is classed as high-risk and no other law sets a longer period	Gateway and application logging configured for retention, with access restricted to compliance staff	Institution has not classified each use case, so logging requirements are never assigned
Accessibility of the interface (28 CFR Part 35 Subpart H)	Dated accessibility test results for the chat interface and admin screens, with remediation records	Independent accessibility testing against the applicable standard, tracked in the project's issue log	Testing covers the default theme only, and custom branding or plugins introduce new barriers

What to ask an implementation partner before a campus engagement

Start by asking the partner how they map directory groups to FERPA school official roles. A campus assistant only stays inside the school official exception if the contractor performs a service the institution would otherwise use employees for, works under the institution's direct control, and follows the redisclosure limits in 34 CFR 99.33(a). Ask the partner to show the group-to-role table they would build from the university directory, who approves each mapping, and how a student who loses an enrollment status is removed from student-facing scopes. Then ask how they separate minor and adult data, since COPPA applies to operators collecting personal information from children under 13 and the eCFR text of 16 CFR Part 312 sets the written security program and retention duties that follow. Ask for the retention and deletion timeframes they would configure for chat history and uploaded files in each population, and for the written retention policy that comes with them. Next, ask how they will handle the Open WebUI branding clause for a campus-wide rollout. The license restricts altering or removing branding above 50 users in any rolling 30-day period unless the operator holds an enterprise license or written permission, so a university-wide assistant will almost certainly need one of those paths before launch. Ask who in the partner's team confirms the user count against that threshold, and who pays for the license decision. Also ask how they size GPUs for peak concurrency and queueing rather than average usage, including the Ollama settings for parallel requests, loaded models and queued requests they would set, and what they would measure during a pilot before scaling to the whole campus. Finally, ask how they test accessibility, how they produce the disclosure record that FERPA requires for each disclosure of personally identifiable information, and whether they operate the platform after go-live or only build it. Ask for a written scope that lists each deliverable, the test method for accessibility, the log fields for the disclosure record, and who holds the administrator and on-call roles after handover. Request the evidence list in writing as well: configuration exports, access review reports, retention job logs, and the documented results of the accessibility and load tests. Confirm the final list with the university's counsel and privacy office before signing.

Questions universities ask before hiring help with a campus chat assistant

What drives the cost of a campus chat assistant?

The cost is driven by scope, GPU capacity, identity integration, retention and logging design, and accessibility testing. Hardware or cloud GPU spend recurs, while design, integration, hardening and testing are largely one-time project work. Scope is the biggest lever: a single staff pilot with one identity source costs far less to build than a campus-wide rollout with separate student and staff policies, several directories and audit reporting. Ask any partner for a quote that lists each component separately: GPU servers or cloud GPUs, the chat interface and any enterprise license, identity integration, security testing, operations and support.

How long does a campus chat assistant take to deliver?

The duration depends mainly on scope and approvals rather than on the software itself. Directory integration, a data classification decision, the acceptable use policy and the accessibility review each have their own queue, and institutions often wait on those more than on build work. A pilot for one department can move faster than a campus rollout that needs sign-off from legal, privacy, student affairs and accessibility offices. Ask for a written schedule that shows which milestones depend on the university's own decisions, so delays on either side are visible.

What must the university supply before work starts?

The university must supply four things: directory owners who can grant read access to identity attributes and group membership, a FERPA or privacy officer who approves what student data may enter the system, a decision on GPU capacity and who pays for it, and a named owner for the acceptable use policy. Without the directory owners, SSO and group mapping stall. Without the privacy officer, student data rules cannot be written. Without a policy owner, no one can decide what staff and students may paste or upload. Confirm these names in the first planning meeting.

Can our IT team build a campus chat assistant internally?

Many IT teams can deploy Open WebUI or LibreChat in a test environment, but production readiness usually stalls on identity, scaling and governance. Typical gaps include mapping directory groups to model access, setting up PostgreSQL and Redis for multiple replicas, sizing GPUs for concurrent users, designing separate retention for student and staff chats, and producing audit records that a privacy office can review. Assess your team against each of those items. If the gaps are narrow, an internal build may suit you. If several are open, a partner can cover them under a written scope while your staff keep ownership of operations.

Does self-hosting make a campus chat assistant FERPA compliant?

No. FERPA is a set of obligations on the institution, and self-hosting does not satisfy them by itself. Self-hosting helps because prompts and files stay in infrastructure the university controls, which supports the direct control and access restriction requirements in 34 CFR Part 99. The institution must still limit access to records by legitimate educational interest, keep a record of disclosures, and handle access requests within the required period. Any hosting contractor must also meet the school official conditions. Treat the assistant as a system that produces evidence for a compliance review, not as a compliance certificate.

Does the Open WebUI branding license apply to a campus-wide rollout?

Yes, it can. The Open WebUI License forbids altering or removing Open WebUI branding in deployments that exceed 50 users in any rolling 30-day period, unless the operator holds an enterprise license or written contributor permission. A campus with thousands of users will exceed that threshold, so branding changes such as a university logo and name need either the enterprise route or permission. Open WebUI publishes enterprise options that include white-labeling, but pricing is not published and is quoted after contacting sales with an expected seat count. Confirm the license position with counsel before the interface is branded.

Can student prompts ever reach a cloud model?

Only if the university configures that path. A self-hosted deployment can run entirely on local models, and Ollama states that when it runs locally it does not see your prompts or data. Its cloud features can be turned off with OLLAMA_NO_CLOUD=1 or the server configuration file. Open WebUI can also connect to external providers such as OpenAI or Anthropic, so the connection list must be controlled. Ask the partner to show the list of enabled providers, how each is disabled for student accounts, and how that setting is verified during testing.

How DeployOpen scopes and runs a campus assistant

DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source assistants inside the university's own cloud accounts, data centers or networks. For a campus assistant, that means agreeing in writing how staff and student data are separated, how the directory connects, and how shared GPU capacity is sized before any build starts.

How we scope

Written scope agreed before work starts, covering user populations, directory sources and which student and staff groups can reach which models
Confirmation of the education records and personal data the assistant may touch, with the registrar, privacy office and IT governance involved
Sizing inputs for occasional-use concurrency on shared GPUs, documented so the university can compare options and quotes

How we build

Deployment of Open WebUI or LibreChat with Ollama or vLLM in the university's environment, with OIDC or LDAP federation to the campus directory
Group-based role mapping that separates student and staff access, plus configuration of acceptable use controls and file upload limits
Security testing of the chat interface and model endpoints, with findings tracked and resolved before the pilot begins

How we hand over

Runbooks for user provisioning, group changes, model updates, backups and logging retention, written for the university's own operations team
Architecture and access-control documentation that the privacy office and auditors can review, including the logs kept for each request
Knowledge transfer sessions with the administrators who will run the platform after the engagement ends

How we support

Ongoing support, upgrades and continuous security testing are available as retainers, so model and interface releases can be tested before rollout
Patching and backup support for the chat platform, databases and GPU hosts, scoped in the same written agreement
Periodic review of acceptable use settings, group mappings and retention rules as the academic calendar and policies change

Private LLM chat for education