Privacy Policy

Data controller

AILitKit is operated by IN&ED. For data protection enquiries, including any concern about a guide that was generated, blocked, or flagged, contact hello@ailitkit.com. We aim to respond within 5 working days.

What we collect

When you create an account we collect:

• Email address (for sign-in and transactional email).
• Display name (optional).
• School or trust name (optional).
• Country, and where applicable emirate, used to apply the right regional framework set and safeguarding context (for example, UK accounts are flagged as following Keeping Children Safe in Education).
• Teaching preferences: primary key stage and primary subject.
• Onboarding status, communication preferences, and a record of which transactional emails we have sent you.
• If you applied through the early-access route: your role, urgency, scale, timeline, intended subject, commitment answer, GDPR consent confirmation, and an internal application score and tier. Application records are retained whether or not you activate an account so we can prevent duplicate applications and report on the early-access programme.
• If you are part of a school or trust account: your membership role (member, admin, owner, trust admin), the organisation you belong to, and invitation history.
• If you are a paying customer or a founding member: Stripe customer and subscription identifiers, founding-member status, founding pricing forfeiture date, and timestamps for the founding-conversion reminders we have sent.

When you generate a guide, we save its subject, key stage, year group, topic, free-text description, generated content, activity selections and any feedback you submit. We also save the content-review evidence, resolved findings, correction paths, model names, version, timings and usage estimates. This evidence can include excerpts from the lesson or draft. Original upload text is not kept as a full source document on the guide row; relevant content may be reproduced in the guide or review evidence.

Separately, the safeguarding classifier writes one row per request to a safety-audit log. Allowed requests retain no input snapshot in this log — only the verdict and decision metadata. Sensitive or blocked requests additionally retain the topic and up to 250 characters of your free-text description, plus a boolean flag if an upload was involved. The snippet exists so a reviewer can confirm the decision against the actual request; uploads themselves are never in the audit log. See the "Safety and audit logs" section below for the full retention story.

How we process your data

Guide drafting and content review use Luna as the primary model, with Gemini as the configured backup, through OpenRouter. Safeguarding uses Llama Guard and, when needed, a separate Gemini curriculum reviewer. Model developers and the companies operating inference endpoints are not necessarily the same.

Our OpenRouter account has zero data retention (ZDR) enabled, and requests also require ZDR inference endpoints. This applies to provider processing of prompts and outputs, including retries and fallback. It does not delete your saved AILitKit guides, account records or necessary service metadata. OpenRouter permits temporary in-memory prompt caching under its ZDR policy.

Before new generation, automated safeguarding checks read the subject, stage, year group and topic, plus up to the first 1,000 characters each of the teacher description and extracted upload text. Llama Guard gives a first verdict; a Gemini reviewer runs if that verdict is unsafe, unavailable or unreadable. An additional direct OpenAI moderation check runs when configured, under its separate API terms. If no usable safeguarding verdict is available, generation pauses with a retry message. A usable unsafe verdict is preserved if its reviewer fails; hard-block categories cannot be cleared by that reviewer.

Before saving a newly generated guide, automated checks review lesson fit, accuracy, activity logic, resources, pupil language and AI literacy. Up to four batches inspect the draft against the teacher brief; one correction cycle is allowed, followed by another review of all batches. Failed or unavailable review prevents the new guide from being saved. Saved review evidence and resolved findings may quote the brief or draft. These checks can miss errors and are not human approval or a dedicated final-output safety classifier. Existing guides are not retrospectively checked; eligible saved guides may be reused.

Keyword matching and semantic search use Scaleway embedding models hosted in Paris. Only curriculum terms should be supplied. Guide scheduling through Upstash QStash sends a job identifier, not the lesson text; delivery, retries and dead-letter retention follow the queue account settings.

Automated decisions and how to appeal

Guide generation does not grade pupils, decide admissions or progression, or assess individual learners. Automated service checks do decide whether a request can proceed and whether a draft passes review. A second AI model is not human intervention. You can ask a person to review a refusal or flag by contacting hello@ailitkit.com or safeguarding@ailitkit.com; we aim to respond within five working days. A content flag is not a finding of misconduct by a teacher.

The legal rules for solely automated decisions concern decisions with legal or similarly significant effects on people. We do not assume that every automated content check meets that threshold. Rights under the applicable UK or EU rules remain available, alongside our human-review route.

Teacher review of AI-generated content

Pupil-facing language is targeted using the year group or key stage supplied by the teacher. This is a class-level assumption, not an individual reading-age assessment. Teachers must adapt wording and resources for their actual readers, including SEND and EAL needs, and check third-party tools, links and safeguarding before classroom use.

Every guide is generated by AI and is clearly labelled as such. AILitKit is a planning aid, not a substitute for professional judgement. You must review every guide before classroom use to confirm activities, framing and language are appropriate for your specific learners and your school's policies. If a guide contains anything you consider inaccurate, biased, age-inappropriate, or unsafe, please report it to hello@ailitkit.com — we use these reports to tune the safeguarding rubric and the system prompt.

Lawful basis

For UK/EU processing, we rely on Article 6(1)(b) (contract performance) for account management and guide generation, and Article 6(1)(f) (legitimate interests) for service security, abuse prevention, the layered safeguarding classifier described above, and lifecycle communications tied to your subscription or founding-member status. Regional requirements and school controller/processor responsibilities must be assessed for the applicable service and agreement.

Payments

Payments are processed by Stripe. We do not store your card details. Stripe's privacy policy applies to payment processing. We retain a record of webhook event identifiers received from Stripe (event ID, event type, timestamp) so we can deduplicate retries and reconcile your subscription state; this log does not contain card data and is retained for 12 months for billing reconciliation. Stripe itself retains transaction records for the period required by financial regulation in their jurisdiction (typically 7 years).

Email

All email is sent via Resend. We send three categories of email:

• Transactional email — account activation, password reset, email change confirmations, subscription receipts, renewal reminders, account-deletion confirmations, and organisation invitations sent on behalf of a school or trust admin. We rely on Article 6(1)(b) (contract performance) for these. You cannot opt out of transactional email while you have an active account because they are necessary for the service.
• Lifecycle email — a small number of automated messages tied to the programme you signed up for, for example a single onboarding nudge if you start signup but do not complete it, a welcome to your first generated guide, and (for founding members) two pricing-conversion reminders before access ends and a notification when access ends. We rely on Article 6(1)(f) (legitimate interests) for these.
• Product and service updates — occasional emails about new features, improvements, and educational content relevant to AI literacy in schools. For existing customers and free-account holders we rely on the "soft opt-in" under PECR Regulation 22(3) and Article 6(1)(f) (legitimate interests). For applicants who have not yet activated an account, we rely on the consent given at the point of application. To opt out, email hello@ailitkit.com with "Unsubscribe" in the subject line. We will action your request within 5 working days and the opt-out does not affect transactional or lifecycle email tied to your account.

We do not sell your email address, do not share it for third-party marketing, and do not run advertising trackers. Your email is shared with Resend solely for delivery of the messages described above.

Delivery-status webhooks. Resend sends us delivery-event notifications (bounces and spam complaints) for the invitations and emails we have sent. We store the bounce or complaint status, with the underlying reason code, against the relevant pending invitation so school administrators can chase a colleague through a different channel and so we can stop sending mail to addresses that consistently reject it. This data is removed when the invitation is resolved or expires.

File uploads

After successful generation, cleanup deletes the original uploaded file and clears the extracted text from the upload record, keeping filename, type and date. Unused uploads and failed cleanup are eligible for the scheduled sweep once the upload is over one hour old. The sweep runs every 15 minutes; deletion can take longer if a cleanup attempt fails. Relevant source-derived material can remain in the saved guide and its review evidence.

While a guide is being built, its job record holds the request needed for processing and retries. On completion, failure or expiry, that record loses its input payload and duplicate output. Identifiers, scope, status, timings, usage and support diagnostics remain temporarily: completed jobs are eligible for deletion after 24 hours, and failed or expired jobs after seven days, at the next successful cleanup. The saved guide, its input description and review evidence follow the guide retention period.

Data you should not share

Do not enter identifiable pupil information, assessment records, safeguarding records, EHCP/SEN documents or staff personal data. AILitKit needs curriculum content only. Warnings and input cleaning do not guarantee anonymisation: information entered accidentally can still be processed and appear in a saved guide or audit evidence. Contact hello@ailitkit.com promptly if this happens.

School and trust accounts

If you join AILitKit through a school or trust account, your school's administrators (and, where applicable, your trust's administrators) can:

• See your name, email, role and active/invited status on their member roster.
• Manage your seat, including removing you from the organisation.
• See a list of guides generated by accounts in their organisation showing the scope, subject, key stage, date, and the teacher's name — metadata only. They cannot read the contents of your guides.
• See safeguarding decisions flagged as "sensitive" or "blocked" for accounts in their organisation, so the safeguarding lead can step in if a colleague is repeatedly hitting the gate. Each row includes the teacher's name, the verdict, the category, and a short snippet of the topic or description — the topic and description excerpt retained in the audit log, displayed in the admin view truncated at 120 characters; this is a render-time view of the audit log row, not a separate stored copy of your input. They cannot see decisions that were allowed.

If you are an organisation administrator, the same rules apply to you in reverse: you are accountable, under your school's own data protection policies, for accessing colleague metadata only as needed to administer the account.

Customer support access (impersonation)

To investigate a support request, replicate a billing or generation issue, or run a demo, a member of the IN&ED operations team may issue a single, time-limited magic sign-in link to the email address of your school's owner (or, where no owner is currently recorded, the most recently active admin). The link is generated by Supabase, expires within approximately one hour, and is used to sign in once as the customer; we do not use, store, or share the customer's password. We record every issuance of a support magic-link to our administrative-actions audit log, capturing the operations user who issued it, the target account, the timestamp, and the support context. The audit row is the durable record of the access. We are working to add a notification to the affected school owner so that any future impersonation is also surfaced to you directly; until then you may request the full impersonation history for your account at any time by emailing hello@ailitkit.com.

In-product courses and certificates

If you take an in-product professional-development course (for example, Responsible AI for Teachers), we store your progress against each module and lesson, the date you completed each module, your overall course completion date, and the certificate we issue you on completion. The certificate carries your display name, the course title, the completion date, and a unique verification token.

Public verification. Each certificate has a public verification page at /cert/<token> that anyone holding the token (for example, an inspector or a head teacher) can open without an account. The page shows the certificate holder's display name, the course title, the completion date, and confirmation that the certificate is genuine. The page reveals no other personal data. You can rotate or revoke a certificate by emailing hello@ailitkit.com if you no longer want it externally verifiable.

School and trust visibility. If you joined AILitKit through a school or trust account, your administrators see your course-progress percentage and any certificates you have earned, in the same view that shows your other organisation activity. This supports the trust-wide CPD reporting that many MATs require. Trust administrators see the same view across all schools in their trust. Certificates remain visible to admins for the lifetime of your account.

Safety and audit logs

We keep a small set of internal logs that exist for safety, security and billing reconciliation rather than analytics:

• Safeguarding decisions. Every classifier run records the verdict (allow/sensitive/blocked), which layer reached the verdict, the category, explanation, model used, and latency. For decisions flagged "sensitive" or "blocked" we additionally retain the topic and up to 250 characters of your free-text description, plus a boolean flag if an upload was involved, so a reviewer can confirm the decision against the actual request. Allowed decisions retain no input snippet — by design, allowed requests are not reviewed by humans, so the verdict and metadata are sufficient. The upload body is not stored in this log. The classifier explanation may refer to screened material. The log is retained for as long as the underlying account exists. School and trust admins see only sensitive and blocked entries for their organisation, never allowed entries.
• Stripe webhook idempotency log. A record of Stripe event identifiers and types we have received, used to prevent duplicate processing on Stripe retries. No card data is held here.
• Administrative-actions audit log. Whenever an administrator makes a change to a user account from inside the platform (e.g. sending a password reset, resending an activation email, extending access, suspending or reinstating an account, granting bonus generations, deleting an account) we write one row to an internal audit table. Each row records the acting administrator, the affected account, the action type, a small JSON metadata payload describing the change, and the timestamp. The log is visible only to administrators and is retained for 365 days, after which it is purged by a scheduled cleanup job.
• Administrative alerts. Where an automated job fails (for example, a webhook signature mismatch or a stuck cleanup), we record an alert for our operations team. These records are retained until resolved and may be retained for a further 90 days for trend analysis.
• Background processing. Cleanup, founding-member reminders, onboarding nudges, and the first-week / first-month school-activity emails sent to school admins all run as scheduled jobs on Vercel Cron and Upstash QStash. These jobs touch the data described above and do not introduce new categories of processing.
• Rate-limiting and abuse prevention. Your IP address is processed transiently to enforce per-route rate limits (for example, on bulk-invite, public share, and unauthenticated endpoints). The rate-limit bucket lives in memory or in a short-lived Postgres row keyed by IP, is not joined to your account, and is discarded once the rate-limit window has passed (typically minutes).

Hosting and data storage

The application uses Supabase for database, authentication and upload storage; the database is in the EU (eu-west-1). The application is hosted on Vercel, including processing in the US. An EU database location does not mean all processing stays in the EU.

Cookies and analytics

We use essential cookies for authentication. We do not currently run any third-party analytics, advertising trackers, or marketing pixels. If we add analytics in future, we will update this page first and only use a privacy-focused, anonymous tool.

Third-party services summary

Data retention

Account data remains while your account is active. Saved guides, their input descriptions and review evidence remain until you delete the guide or account. Deleted guides have a 30-day undo window and are then purged by scheduled cleanup.

While a guide is being built, its job record holds the request needed for processing and retries. On completion, failure or expiry, that record loses its input payload and duplicate output. Identifiers, scope, status, timings, usage and support diagnostics remain temporarily: completed jobs are eligible for deletion after 24 hours, and failed or expired jobs after seven days, at the next successful cleanup. The saved guide, its input description and review evidence follow the guide retention period.

After successful generation, cleanup deletes the original uploaded file and clears the extracted text from the upload record, keeping filename, type and date. Unused uploads and failed cleanup are eligible for the scheduled sweep once the upload is over one hour old. The sweep runs every 15 minutes; deletion can take longer if a cleanup attempt fails. Relevant source-derived material can remain in the saved guide and its review evidence.

Safeguarding audit entries remain for the account lifetime. Administrative-actions audit has a 365-day cap. Routine content-review failure diagnostics use check names and counts, not finding text. Hosting logs and provider backups follow their service schedules; deletion from the active database is not a promise of immediate erasure from every backup. Contact us for the retention evidence needed by your school.

Account deletion removes account-linked reports, upload records, memberships and safeguarding entries from active storage. Unlinked billing records, such as Stripe event identifiers, follow their separate accounting retention requirements.

International transfers

Some processing can occur outside the UK/EEA, including Vercel hosting and AI inference routed through OpenRouter. Supabase database and Scaleway embeddings use EU locations; the inference operator and queue location depend on the service configuration. ZDR limits retention and does not itself establish a transfer mechanism.

School procurement should consider the current processor agreements, actual destinations and applicable transfer safeguards, such as EU Standard Contractual Clauses and the UK Addendum or IDTA where required. Do not infer that every processor is DPF-certified or that EU storage removes all international transfers. Request the relevant evidence from hello@ailitkit.com.

For users in the United Kingdom and Ireland

UK users have rights under the UK GDPR as amended, including applicable access, correction, erasure, restriction, portability, objection and safeguards for significant automated decisions. Complaints can be raised with the ICO at ico.org.uk. Ireland is covered by EU GDPR; its supervisory authority is the Data Protection Commission. Our human-review route is available for content refusals and flags.

For users in the European Union

EU users have rights under the EU GDPR, including applicable access, rectification, erasure, restriction, portability, objection and Article 22 safeguards for decisions with legal or similarly significant effects. Your national data protection authority handles complaints. AILitKit labels AI-generated guides and requires teacher review; guide generation is not used for pupil grading, admissions, progression or proctoring.

For users in the United States

FERPA: AILitKit is for professional planning and does not require student education records. Teachers must not enter them. Districts should assess their obligations and agreements before adoption; accidental inclusion of personal data is still possible.

COPPA: AILitKit is designed for adult teachers. Students do not create accounts or interact with the platform. We do not knowingly collect information from children under 13.

CCPA (California): California residents have the right to know what personal information is collected, request deletion, and opt out of sale. We do not sell personal information. You can export or delete your data from account settings.

To exercise your rights or file a complaint, contact your state Attorney General.

For users in the United Arab Emirates

UAE schools should assess applicable data-protection and cross-border transfer requirements, including the federal PDPL or the relevant free-zone regime. AILitKit processes curriculum content and adult account data, and prohibits pupil-identifying uploads. The school should confirm its legal basis, processor agreement, destinations and local regulator requirements with its data-protection contact.

Children's data

AILitKit is designed for use by teachers (adults). Students should not create accounts or interact with the platform directly. We do not knowingly collect data from children. This position supports compliance with COPPA (US), the ICO Age Appropriate Design Code (UK), and similar child protection regulations worldwide.

Your rights

Under applicable data protection law, you have the right to access, correct, export, or delete your data, and to seek human intervention on automated decisions taken by the safeguarding classifier. You can export your data from your account settings, or contact hello@ailitkit.com for any data request. We aim to respond within 5 working days.

Changes to this policy

We may update this policy from time to time. Material changes will be notified via email or an in-app notice. The "Last updated" date at the top of this page records the most recent revision.