Start with shared services
TritonGPT, approved model access, campus assistants, training, and support give everyone a common starting point.
Shared campus capability
Make AI easy to use and easy to manage
TritonAI gives UC San Diego a shared path from everyday AI assistance to supervised campus workflows. The program runs common services, helps teams build on them, and keeps a named owner responsible for every service it supports.
How the program works
Departments build on shared services
Build around a campus need
Teams can embed an assistant, use the Developer APIs, or work in TritonAI Harness when a job needs more than chat.
Operate what proves useful
A pilot becomes a supported service once the evidence and review points are clear. It also needs an owner, approved hosting, accessibility checks, and a support path.
From TritonGPT to TritonAI
How the parts fit together
TritonGPT gives the campus broad access to AI. TritonAI adds the builder path, governed context, and operating model required when an application carries out work across several steps.
Access
TritonGPT and embedded assistants give people approved ways to ask questions and work with documents.
Build
Developer APIs, TritonAI Harness, and reusable skills help teams assemble supervised workflows.
Connect
Approved sources, scoped connectors, and reviewed shared context let a service use the information its task permits.
Operate
Hosting, observability, support, review gates, and named owners keep useful services accountable over time.
Program priorities
What we weigh when we build a service
We settle the technology, the governance, and the support model together, because changing one changes the others.
Governed infrastructure
Sign-in, hosting, and data handling controls scale with what the service touches and what it could get wrong.
Model flexibility
Everything runs through one gateway with several approved hosting options behind it, so no single vendor can strand us.
Specific pain points
We start from a problem that comes back every week, with someone who owns it and something worth measuring.
Human accountability
Anyone using the service can see who reviews the output and how to escalate when it goes wrong.
How we measure
Counting users is not enough
A service has to make something at the university measurably better without making anything else worse.
- Reach
- Who can use it, who does, and whether they come back.
- Efficiency
- Hours and rework the service hands back to people.
- Quality
- Whether reviewers agree the output is complete and correct.
- Trust
- Who it excludes, how often it escalates, and who is watching.
TritonAI architecture
One governed route from a campus need to an accountable service
- Campus need
- TritonAI gatewayIdentity · routing · policy
- Approved resources
- ModelsChosen for the task
- KnowledgeGrounded at request time
- ToolsBounded capabilities
- Human reviewOwnership · evidence
Controls across the serviceEvaluation · accessibility · monitoring
Architecture
What sits around the model
The model is one piece. Around it sit the routes it can call, the campus sources it can read, the accessibility and evaluation checks it has to pass, and the person answerable when it gets something wrong.