Safeguarding statement
Last updated: 23 May 2026
What AILitKit is, and what it is not
AILitKit is an adult-only professional planning tool for teachers and school leaders. It generates AI literacy guides from your curriculum context (subject, key stage, topic, scheme of work). It is not a student-facing service, not a safeguarding case-management system, not a tool that processes pupil personal data, and not a substitute for your school's designated safeguarding lead (DSL). Every guide is for teacher review before classroom use.
Safeguarding contact and how to raise a concern
If something the platform produced concerns you, if you believe a request was wrongly refused, or if you want to flag a pattern of activity to us, contact us using any of the routes below. We aim to acknowledge within 1 working day and respond within 5 working days.
- Safeguarding inbox: safeguarding@ailitkit.com for any concern about a generated guide, a classifier decision, or content that has surfaced through the product.
- Appeals (Article 22 human review): the same inbox, with the date, subject, key stage, and topic. A human reviews the decision, takes your point of view into account, and replies. This route is also documented in our Privacy Policy under “Automated decisions and how to appeal”.
- General questions: hello@ailitkit.com.
A named AILitKit safeguarding liaison reviews every message to the safeguarding inbox. We are not a regulated safeguarding service and do not act as a DSL for your school. Where a message describes an active safeguarding concern about a pupil, we will direct you to your own DSL, the NSPCC helpline (0808 800 5000), or the police as appropriate.
How the safeguarding gate works
Every guide-generation request runs through a two-layer content-safety gate before any guide is produced. The classifier reads the subject, key stage, topic, and any free-text description you have written. It does not read uploaded curriculum files; the gate decision is made from the metadata and the free-text only.
- First pass: Meta Llama Guard 4 (12B), via OpenRouter. A strict first-pass classifier against the MLCommons hazard taxonomy (child sexual exploitation, indiscriminate weapons, suicide and self-harm, hate, and related categories). If Llama Guard returns “safe”, the request is allowed and your guide is generated.
- Second pass: curriculum-aware reviewer (Google Gemini), via OpenRouter. Runs only when Llama Guard flagged the request. The reviewer is given your key stage and curriculum context and decides whether the flagged topic fits an established curriculum frame (for example KS3 PSHE drug awareness, KS4 RSHE consent and contraception, GCSE Biology reproduction, A-level Psychology mental health). It returns one of three verdicts.
Both calls run under our OpenRouter account's “Always enforce zero data retention” policy: requests are routed only to model providers that contractually do not retain, log, or train on the input. If no zero-retention provider is available the request fails closed rather than falling back.
What the three verdicts mean
- ALLOW. The topic is fine. The guide is generated normally and no input snippet is stored in the safeguarding log (allowed requests are not reviewed by humans).
- SENSITIVE. The topic engages a safeguarding-sensitive area within a legitimate curriculum frame, for example PSHE drugs education, KS5 Biology drug pharmacology, RSHE, FGM awareness, or Prevent. SENSITIVE is not a warning about the teacher. It records that the system has applied a safeguarding-aware framing (awareness over instruction, age-appropriate depth, DSL signposting) to the generated guide. The verdict, category, model, and a 250-character snippet of the topic and free-text are stored in the safeguarding log; uploaded files themselves are not.
- BLOCK. The request was refused before any guide was generated. You see a message explaining why and how to appeal. The verdict, category, model, and a 250-character snippet are stored.
Hard-block categories (no appeal to the curriculum reviewer)
Two categories are hard-blocked at the safety floor and never escalated to the curriculum-aware reviewer:
- Child sexual exploitation (MLCommons S4): including any request that would describe, depict, or instruct the generation of child sexual abuse material.
- Indiscriminate weapons (MLCommons S9): chemical, biological, radiological, nuclear, and explosive weapons of mass destruction.
There is no legitimate K-12 curriculum framing for these. The hard-block applies regardless of curriculum context. We rely on UK GDPR / EU GDPR Article 22(2)(b) (compliance with applicable law, including laws criminalising child sexual abuse material and proliferation-related content) for these decisions. The appeal route in the section above remains available if you believe a hard-block was applied to a request that did not in fact fall within one of these categories.
What your school admin sees
If you joined AILitKit through a school or trust account, your school administrators (and trust administrators where applicable) can see safeguarding decisions on accounts in their organisation. The view is limited:
- Admins see SENSITIVE and BLOCK rows for staff in the organisation, not ALLOW rows. Routine activity is not visible.
- Each row shows the teacher's name, the verdict, the category, and the first 120 characters of the topic or free-text description.
- This is the same 250-character snippet stored in the safeguarding log, displayed truncated at render time. It is not a separate stored copy.
- Admins cannot read the contents of your guides or the contents of any uploads.
The purpose is to let the designated safeguarding lead step in if a colleague is repeatedly hitting the gate, in the same way a school filtering and monitoring solution surfaces patterns to the DSL under KCSIE Part 2. If you write a request that engages a sensitive curriculum topic, expect your school admin or DSL to be able to see that you did. AILitKit operations staff also have a service-role view across all organisations for support and abuse investigation; use of that view is logged to the administrative-actions audit, retained for 365 days.
Safeguarding controls built into every generated guide
When the curriculum-aware reviewer returns SENSITIVE, AILitKit injects a safeguarding addendum into the system prompt before the guide is generated. The addendum enforces six rules:
- Awareness, not instruction. The guide covers recognition, prevention, support, and where to get help. It never includes step-by-step methods, dosages, sourcing routes, or anything that could enable harm to self or others.
- Age-appropriate framing. Depth and language match what is statutory at the selected key stage; the guide does not pre-empt content from later key stages.
- DSL signposting. Any activity that may surface lived experience or invite disclosure includes a teacher coaching note about your school's DSL referral pathway.
- Teacher-led by default for the most sensitive elements, rather than open student-led activities, unless the framing is explicitly low-risk.
- Statutory reference. KCSIE 2025 is referenced in the governance footer for any Part 1 / Part 5 concern; the draft KCSIE 2026 consultation provisions are additionally referenced for AI-generated imagery, deepfakes, and AI-simulated interaction.
- Category-specific guidance. Each category (self-harm, RSHE, FGM, Prevent, drugs, knife crime, genocide and war crimes, religion and belief, science of reproduction, science of drug action) has a tailored rule. For example, eating disorders are awareness-only with no specific behaviours, weights, or strategies that could be imitated.
Retention of safeguarding records
Safeguarding-classifier decisions are retained for the life of the underlying account and removed by database cascade on account deletion. ALLOW rows hold no input snippet. SENSITIVE and BLOCK rows hold a 250-character snippet of the topic or free-text description and a boolean flag indicating whether an upload was involved. Uploaded files themselves are never written to the safeguarding log at any verdict.
Teacher-led delivery
All AILitKit suggestions are designed for teacher-led delivery. Students should not interact directly with the AILitKit platform. Teachers are responsible for reviewing every guide and adapting it to their classroom context, their school's acceptable use policy, and their own professional judgement.
Acceptable use policy alignment
AI literacy activities should be delivered in line with your school's acceptable use policy and online safety procedures. Where a guide names an external AI tool, AILitKit applies a tool-vetting tier (recommended, conditional, or not approved at this key stage) based on the tool's published age policy, default privacy settings, and educational fit. Schools should still check tools against their own AUP and procurement processes.
Adaptations for every learner
Every guide includes optional notes that open up the activity for the full range of learners in a class: structured entry points, choices of representation, scaffolds, stretch options, and prompts for pupils who already hold strong prior knowledge. These are starting points for any teacher to adapt, not a separate track for a sub-group of pupils.
Regulatory alignment
AILitKit is used by teachers across multiple regions. Below is how the platform aligns with the safeguarding and responsible-AI frameworks relevant to each.
UK: KCSIE 2025 alignment, with attention to the draft KCSIE 2026 consultation
AILitKit aligns with Keeping Children Safe in Education 2025, the current statutory guidance for schools and colleges in England. We additionally watch the draft KCSIE 2026 consultation on AI-specific provisions and apply the draft framing where it strengthens protection (for example, treating AI-generated imagery and AI-simulated interaction as in-scope for safeguarding-aware framing). Specific alignments:
- AI-generated imagery and deepfakes. The draft KCSIE 2026 consultation strengthens the existing 2025 position that AI-generated imagery falls under child-on-child abuse where used to harass, sexualise, or intimidate. AILitKit guides addressing online harms surface this in age-appropriate ways and signpost CEOP for reporting.
- Preventive education. AILitKit supports schools in delivering preventive education on online harms, deepfakes, and AI-simulated interaction through discussion and debate activities that build critical evaluation skills.
- Cybersecurity as a safeguarding matter. Compromised child data is a safeguarding concern, not only an IT one. AILitKit does not require or accept student personal data, and the in-product tool-vetting tier flags any third-party tool we name against its data-protection posture.
- Annual filtering and monitoring review (KCSIE Part 2). Governing bodies must review filtering and monitoring effectiveness at least annually. AILitKit's Whole-Curriculum guides and the per-org safeguarding-decision activity view can support evidence for these reviews; the safeguarding-decision view is intended to surface patterns to your DSL in the same way a filtering-and-monitoring solution does.
For the full statutory text, see the DfE's Keeping Children Safe in Education 2025 on gov.uk and any current consultation update for KCSIE 2026.
UK: DfE Generative AI Product Safety Standards (January 2026)
AILitKit aligns with the DfE Generative AI Product Safety Standards, published in January 2026, including the five named risks the standards call out:
- Cognitive offloading. Every guide is positioned as a planning aid, not a substitute for the teacher's professional judgement; the in-product copy and the printed footer reinforce teacher review.
- Anthropomorphism. The product surfaces itself as a tool, not a colleague or assistant. There is no persona, no first-person voice, and no claim of authorship.
- Manipulation. The classifier sits in front of every generation and the prompt enforces age-appropriate, awareness-not-instruction framing on safeguarding-sensitive topics.
- Emotional dependence. AILitKit does not provide companionship or open-ended conversation; it accepts a curriculum context and returns a guide.
- Distress detection. The product is teacher-only and does not interact with pupils, so the standard's pupil-distress-detection provisions do not engage. Where a teacher writes free-text suggesting personal distress, the safeguarding contact route above applies and the AILitKit safeguarding liaison will respond.
AILitKit also references the DfE's Generative Artificial Intelligence in Education (2025) and the Filtering and Monitoring Standards where relevant.
EU: AI Act and responsible AI
AILitKit supports EU schools in meeting the transparency and literacy obligations of the EU AI Act:
- AI literacy (Article 4). The Act requires providers and deployers of AI systems to ensure sufficient AI literacy among staff. AILitKit directly supports this by helping teachers build AI literacy into their practice and document staff CPD through the in-product Responsible AI for Teachers course.
- Transparency (Article 50). Every AILitKit guide is clearly labelled as AI-generated. Teachers are reminded in-product and contractually that they must review the guide before classroom use.
- Risk classification. AILitKit is a limited-risk AI system under the Act. It generates educational planning suggestions for teachers and does not make decisions about individuals.
- Article 5 (prohibited) and Annex III (high-risk) are different legal categories. AILitKit is neither. We deliberately do not engage Annex III education provisions because those concern AI used for admissions, grading, learner-progression decisions, or proctoring, which AILitKit does not do.
AILitKit also aligns with DigComp 2.2 and its updated AI-specific competencies.
US: responsible AI in schools
For US schools, AILitKit supports responsible AI use alongside existing safeguarding standards:
- ISTE Standards. Activities align with the ISTE Digital Citizen and Computational Thinker competencies.
- AI4K12 Five Big Ideas. Guides can be mapped to Perception, Representation and Reasoning, Learning, Natural Interaction, and Societal Impact.
- District policies. Activities should be delivered in accordance with your district's acceptable use policy and any state-specific AI guidance.
- No student data. AILitKit collects no student data, supporting compliance with FERPA and COPPA by design. See our US Privacy and Compliance page.
UAE: MoE, KHDA, ADEK, and Wadeema's Law alignment
AILitKit supports UAE schools in meeting the Ministry of Education AI literacy mandates effective from the 2025-26 academic year, and in operating within the relevant regional regulators:
- MoE AI Curriculum. The UAE mandates AI literacy integration across all K-12 subjects. AILitKit generates guides mapped to the MoE's seven AI domains.
- KHDA AI Literacy (Dubai). Dubai private schools under KHDA jurisdiction can use AILitKit guides aligned to the KHDA AI Literacy Framework, launched February 2026.
- ADEK (Abu Dhabi). Schools under ADEK jurisdiction receive guides framed against ADEK's curriculum and safeguarding expectations.
- Wadeema's Law (Federal Law No. 3 of 2016). Safeguarding framings in AILitKit guides reference Wadeema's Law and the UAE National Child Protection Policy in place of UK statutory references when the school is operating in the UAE.
- Teacher-led approach. Activities are designed for teacher-led delivery, in line with MoE guidance that AI tools in schools should be supervised by qualified educators.
- Data protection. AILitKit's data practices align with UAE PDPL requirements. See our UAE Data Protection page.
Review cadence
This statement is reviewed at least every six months and immediately after any change to the safeguarding gate, the classifier model, the admin-visibility surface, or the statutory frameworks named above. The “Last updated” date at the top of this page records the most recent revision.