Hosting and ownership
TritonAI gives campus services approved routes to AI models and campus information. Anyone can review the privacy, security, and accessibility decisions behind those routes on this site.
The platform does not make a service trustworthy on its own. Each service still needs a stated purpose, data it is allowed to use, a named owner, and people who check the results.
How a supported service fits together
The shared foundation
Hosting, model access, information sources, and actions solve different problems. Each needs its own approval and operating boundary.
A service can use approved enterprise cloud models or models hosted locally at SDSC. Which route it takes depends on the data involved and the controls that data requires.
Supported applications reach models through a single managed gateway. It gives everyone the same technical path. It does not approve what data a service may send through it.
When someone asks a question, the assistant looks the answer up in sources it is cleared for. The model itself was not trained on private campus content.
Skills and connectors expose only the capabilities approved for a service. The service defines who may use them, where a person reviews the result, and when the workflow must stop or escalate.
Where people experience it
The same architecture sits behind all of these. Each one still needs its own named owner and an approved support path.
A campus assistant for chat, documents, and available models.
An assistant sitting on a department site, answering from that site's content.
AI features delivered through approved campus applications.
Course tools built around what the instructor wants students to learn.
Department tools and supervised workflows built through supported APIs.