[ implementation · schools ]
A school AI pilot should protect learning conditions before it pursues novelty.
The first question is not whether AI is local or cloud-based. It is whether a narrowly defined use improves teaching or learning without creating an unexamined student-data flow, unequal access, or a shortcut around assessment.
Set a purpose and a boundary
Choose one role—teacher planning, accessibility support, feedback practice, or supervised research literacy. State which decisions remain with staff and students. Do not start by giving a general assistant broad access to student work or accounts.
Map learner data
List prompts, uploads, identifiers, logs, account data, and outputs. Confirm age-appropriate permissions, contract terms, retention, parental and legal obligations, and who can administer the service. Local processing may reduce transfer but does not remove these duties.
Design for access
Test the actual school devices, bandwidth, assistive technologies, home access, language needs, and account availability. A feature that only works on newer personal devices can widen a gap even if its model runs locally.
Keep assessment legible
Specify permitted assistance, disclosure expectations, and evidence of student process. Evaluate the work, not a detector score alone. AI detection is not a reliable substitute for assessment design or a conversation with a student.
A pilot protocol
- Assign a sponsor, instructional owner, technical owner, and privacy/procurement reviewer.
- Publish a one-page use case: population, data, permitted tasks, vendor or device boundary, and stop conditions.
- Run a time-limited pilot with an equivalent non-AI path for students who cannot or should not use it.
- Collect teacher workload, student understanding, access friction, errors, and unexpected data flows—not just usage counts.
- Review evidence with affected staff and families before expanding, changing the policy, or purchasing more.
This is operational guidance, not education, child-privacy, accessibility, or procurement legal advice. Use local policies and qualified review where required.
[ MPS implementation library ]
Choose a boundary, then test it.
Decision framework
Compare privacy, capability, cost, latency, resilience, and device fit.
On-device vs cloud
The canonical workload-level deployment comparison.
Individuals
Choose a bounded, reversible personal workflow.
Schools
Plan classroom use with student-data and access boundaries.
Small organizations
Start with a managed, testable operational use case.
Developers
Build and measure a local, cloud, or hybrid boundary.
Glossary
Plain-language deployment and provenance terms.
Methodology & sources
What this library measures, assumes, and does not claim.