Use a local model or plan your chosen AI provider
Keep built-in AI assistance on school-controlled infrastructure with a local LLM, or define a governed bring-your-own AI provider path around your privacy, hosting, and procurement requirements. Schoolyi’s built-in AI worker currently runs a local model on infrastructure you control and does not call OpenAI, Anthropic, Google, or another hosted model provider. If your school requires one of those leading providers, treat it as an integration boundary to validate, govern, and support rather than an already-enabled switch.
Outcomes
Practical results schools report after rolling out local llms & byo ai inside ai assistant & tools.
Keep built-in assistant context on infrastructure the school controls
Compare local capability, privacy, cost, and support trade-offs clearly
Avoid assuming a hosted AI provider is connected when it is not
Give IT and leadership a documented decision before expanding AI use
Product truth
Good school software copy should answer who owns the work, what the handoff produces, and which parts still depend on deployment decisions.
This page describes the supported workflow boundary. Confirm configuration, integrations, data, and policy requirements in a representative pilot before committing to production.
Deep dive
Use these details to turn a product page into an implementation conversation.
Schoolyi’s built-in AI worker currently runs a local model on infrastructure you control and does not call OpenAI, Anthropic, Google, or another hosted model provider. If your school requires one of those leading providers, treat it as an integration boundary to validate, govern, and support rather than an already-enabled switch.
Keep built-in AI assistance on school-controlled infrastructure with a local LLM, or define a governed bring-your-own AI provider path around your privacy, hosting, and procurement requirements. Because local llms & byo ai lives inside ai assistant & tools on Schoolyi, teams stop reconciling exports between spreadsheets and the parent portal.
Evidence layer
Read the supporting product and implementation material before making a capability claim.
Everything included in this capability, from daily workflows to exports your team relies on.
Role-scoped workspaces so each team sees only the tasks they own.
Full module
AI assistant & tools
Staff get navigation help, notice drafts, and text polish, while learners get guided K-12 doubt clearing, explanations, practice, revision, and quizzes from a local AI worker on your server. Optional MCP registry connects approved external tools with role gates and audit.
Explore AI assistant & toolsWorkflow
A typical path from setup through daily use on Schoolyi.
Part of the Local LLMs & BYO AI workflow on Schoolyi, connected to roster, calendar, and role permissions.
Part of the Local LLMs & BYO AI workflow on Schoolyi, connected to roster, calendar, and role permissions.
Part of the Local LLMs & BYO AI workflow on Schoolyi, connected to roster, calendar, and role permissions.
Part of the Local LLMs & BYO AI workflow on Schoolyi, connected to roster, calendar, and role permissions.
Deep dive
Long-form context for evaluators comparing capabilities during an SMS rollout.
Schoolyi’s built-in AI worker currently runs a local model on infrastructure you control and does not call OpenAI, Anthropic, Google, or another hosted model provider. If your school requires one of those leading providers, treat it as an integration boundary to validate, govern, and support rather than an already-enabled switch.
Keep built-in AI assistance on school-controlled infrastructure with a local LLM, or define a governed bring-your-own AI provider path around your privacy, hosting, and procurement requirements. Because local llms & byo ai lives inside ai assistant & tools on Schoolyi, teams stop reconciling exports between spreadsheets and the parent portal.
These areas work closely with local llms & byo ai inside ai assistant & tools.
Straightforward answers for visitors evaluating the product.
Yes. The built-in AI worker runs a local model on infrastructure controlled by the school or its operator, so the built-in assistant does not need a hosted model provider.
Record the model, host, access controls, and owner in the school’s deployment decision before enabling AI features.
A school can define a bring-your-own AI provider requirement for evaluation and integration planning. A hosted provider connection is not wired into the built-in assistant today, so do not assume that OpenAI, Anthropic, Google, or another leading provider can be selected from a settings switch.
Validate the provider contract, data path, retention, regional hosting, support, and failure handling before connecting live school records.
With the built-in local model, prompts and retrieved school context stay on the school-controlled application infrastructure. A hosted provider would introduce an external data path that needs its own approval, contract, retention, security, and data-residency review.
Test the intended prompt and context boundary with representative records before rollout, and document which data is excluded from any provider request.
Choose the local worker when keeping built-in assistance on controlled infrastructure is the priority. Consider a leading hosted provider only when its capability, procurement, privacy, residency, and support requirements have been explicitly approved and the integration path has been tested.
Treat model choice as an operating decision with a named owner rather than a marketing assumption.
We'll show how local llms & byo ai fits your school's ai assistant & tools workflows and which teams benefit first.
Already using Schoolyi? Sign in
