Key facts
| Access control | Scoped API keys with rotation; enterprise SSO and RBAC options |
| Deployment | Cloud, VPC, on-prem or air-gapped for records-linked workflows |
| Data grounding | Embeddings and RAG are live for course material and policy search |
| Auditability | Request, model and response logging for safeguarding review |
| Structured output | JSON mode returns feedback and case records in fixed schemas |
| Models | 30+ models behind one API for teaching and administration workloads |
| Pricing model | Flat monthly self-serve plans; no per-token billing on self-serve |
| Endpoint roadmap | Moderation, audio, images, batch and fine-tuning are coming soon |
TL;DR
- Map student-data rules for your jurisdiction before any pilot.
- Keep records-linked workflows on private deployment, not shared tools.
- Require human review of any content students receive.
- Log interactions to support safeguarding and audit inquiries.
- Plan for moderation and content controls as students gain access.
How it works, step by step
- Identify the student data classes in scope and the rules that apply in each jurisdiction you serve.
- Choose deployment per workflow: cloud for public course content, private for records-linked uses.
- Scope keys per application and environment, with rotation and central storage.
- Index approved course material and policies, and require citations in answers.
- Define a review step for feedback, assessments and any content shown to students.
- Set retention and deletion rules for prompts, outputs and logs, including end-of-term cleanup.
- Log request IDs, model versions, sources and reviewer decisions for audits.
Try it yourself
Open the AI data residency checklist →
Student records and age safeguards
Student data is among the most sensitive information an institution holds, and protections for minors are stricter than for adults. Start by mapping what the applicable rules require in each jurisdiction you serve, then keep records-linked workflows on private deployments where prompts, documents and embeddings stay inside the institution's environment.
Apply data minimization as a habit: retrieve only the fields needed to answer a question, and never let identifiers reach shared tools or logs you cannot govern.
Content review and moderation
Anything a student sees should pass a human review or a validated filter. The moderation endpoint is coming soon; until it is available, apply your own input and output filters and keep teacher or administrator review on generated feedback, explanations and messages. For younger learners, keep AI interactions inside supervised interfaces rather than open chat.
Identity, access and shared devices
Campuses run on shared devices, borrowed laptops and personal phones. Issue keys per application rather than per device, keep them server-side, and never embed credentials in client software. Enterprise SSO and RBAC options govern console access, so permissions follow staff roles and are removed on departure.
Where students use an AI feature, authenticate them through your own identity system and pass only a scoped session to the tool layer.
Retention, logging and transparency
Define how long prompts, outputs and logs are kept, and delete them at the end of a term or course where policy requires it. Log request IDs, model versions, sources and reviewer decisions so safeguarding questions and appeals can be answered with evidence. Publish a plain-language summary for staff and students describing what the AI does, what data it sees and who reviews it - transparency reduces misuse and builds trust.
Honest comparison
| Control area | Plugsky capability | Common gap | Owner |
|---|---|---|---|
| Student records | Private VPC, on-prem and air-gapped deployment options | Records in free consumer tools | Data protection officer |
| Content review | Human review gates; citations on answers | Unreviewed AI feedback to students | Academic leadership |
| Access | Scoped keys, enterprise SSO and RBAC options | Shared staff credentials | IT services |
| Retention | Configurable logging under institutional policy | Indefinite retention by default | Privacy office |
| Minors | Controlled interfaces and data minimization | Open-ended student chat | Safeguarding lead |
| Audit trail | Request, source and reviewer logging | No appeal evidence | Governance committee |
Frequently asked questions
Can we use AI with student records?
Only on a private deployment after your data protection review. Keep records behind permissioned tools, minimize identifiers, and follow the specific rules that apply in your jurisdiction.
Is the moderation endpoint available?
Moderation is coming soon. Until then, apply your own filters and require human review for any AI output students receive.
How do we handle minors' data?
Avoid processing it in shared tools, minimize what reaches the model, and keep interactions inside supervised interfaces. Map the applicable rules with your counsel before piloting.
What should we log?
Request IDs, model versions, retrieved sources, outputs and reviewer decisions. Retention should follow institutional policy, including end-of-term deletion where required.
Can lecturers detect AI-written work?
Detection is unreliable. Focus on assessment design, oral checks and process evidence rather than tool-based detection.
How do we make AI use transparent?
Publish a plain-language summary of what the AI does, what data it processes and who reviews its output. Clear rules reduce both misuse and anxiety.
Where should a pilot start?
Use public course material and institutional policies on the free plan, validate citations and review workflows, then extend to records-linked uses on a private deployment.