AI
Self-hosted AI assistant
An optional AI assistant that runs a local model on your own server, so no school data is sent to a third-party model provider.
Available as part of agreed implementation scope
The AI assistant in Schoolyi runs a local model on the same infrastructure as the application. It is optional, off unless enabled, and when enabled it does not send school data to OpenAI, Anthropic, Google, or any other model provider, because there is no call to one.
That design choice costs capability. A locally hosted small model is not as strong as a frontier hosted model, and we would rather say that plainly than imply otherwise. What it buys is a defensible answer to the question a board will ask, which is where the children’s data goes.
What it does: staff help grounded in the platform’s own documentation, drafting assistance for notices, and a learning studio for students and parents. Its scope is the school’s own context rather than open-ended chat.
How it works
- A separate worker process hosts the model and is reached over the local network with a shared token.
- The operator enables the worker at deployment; a platform administrator then enables the assistant per school.
- Retrieval is grounded in platform documentation and the school’s own permitted context, so answers cite something rather than inventing it.
- No outbound call to a hosted model provider exists in the product code.
Who configures it
The worker is enabled and pointed at a model by whoever operates the deployment. A platform administrator then turns the assistant on for the school in AI settings. Off by default.
Implementation considerations
Confirm these details during implementation so the agreed integration scope is delivered predictably.
- A local model is materially less capable than a hosted frontier model. If your expectation is set by a consumer chat product, calibrate downwards.
- It needs server resources. On a small deployment this is a real capacity decision rather than a free feature.
- External Model Context Protocol servers cannot be connected. The MCP configuration surface exists and validates, but there is no runtime client for external servers; the built-in tools are in-process and read-only.
- No cloud model provider integration exists, so a school that wants a frontier model cannot have one here.
Related
Self-hosted AI assistant: common questions
How this integration is planned, configured, and delivered as part of the agreed project scope.
Does any student data leave our server?+
Not to a model provider, because there is no call to one in the product code. The model runs on your infrastructure.
This is the whole reason for the design, and it is the answer worth having when a board or a data protection officer asks.
Is it as good as ChatGPT?+
No. A small locally hosted model is meaningfully less capable, and anyone telling you otherwise is selling something.
It is useful for grounded help and drafting within the school context. It is not a frontier assistant.
Do we have to use it?+
No. It is off unless an operator enables the worker and an administrator enables it for the school.
A school with a policy against AI tooling simply leaves it off, and nothing else in the platform depends on it.
API-first architecture
Connect Schoolyi to the rest of your digital ecosystem
Schoolyi's modular architecture makes it straightforward to add the services and workflows agreed during implementation.
Bring your stack to a walkthrough
Tell us what you already run and which handoffs cost your team time. That is a more useful conversation than a compatibility list.
Already using Schoolyi? Sign in