AI Data Security
Student records are among the most sensitive data a university holds. When AI enters the picture, that responsibility doesn't get lighter. It gets heavier. This page sets out how we secure student and institutional data across every AI system we build, use, or buy.
It draws directly from our Responsible AI Governance Framework, which is available to institutional clients on request.
%20(19).png?width=500&height=500&name=Thesis%20Logo%20Vector%20HEM%20Implementation%20%20(Logo)%20(19).png)
No AI model at Thesis SM is trained on live, identifiable student data. Where data is used in model development at all, it is fully anonymised or pseudonymised first.
We never repurpose student data for AI training or model improvement without explicit institutional consent, and where required, individual student consent. Your data serves the purpose you gave it to us for. Nothing else.
Every AI function we run processes only the data strictly necessary for that function. Retention periods are no longer than the minimum required for the stated purpose. Privacy is designed in from the start, not retrofitted once something ships.
Encryption and access controls
Every AI system that touches student data meets the same minimum standards:
TLS 1.2 as a minimum, TLS 1.3 preferred, for all data flows to and from AI systems
AES-256 as a minimum for any data store containing student personal information
AI system access is limited to authorised personnel and processes only
Third-party AI, on our terms
No student personal data is shared with a third-party AI service without a signed Data Processing Agreement and a completed security assessment. Before any AI vendor is approved, we require:
- Confirmation that the vendor does not train its models on client data by default
- Data deletion and export rights on contract termination, so your data is never locked in
- Data residency in required regions across the UK, US, and Canada
- Contractually committed breach notification to Thesis SM within 72 hours
- Appropriate transfer safeguards for any processing outside the UK or EEA
Vendors are reassessed annually, and after any material change to their AI systems.
Every data flow, documented
Any AI system that processes student data has a documented data flow map, maintained in the Thesis Data Register: what goes in, what the system does with it, what comes out, who can access it, which third parties are involved, and how long data is retained at each stage. Technical documentation is available to institutional clients on request.
Staff discipline, not just system controls
Technical safeguards only work if people follow them. Our engineering and staff policies prohibit sensitive, confidential, personal, or production data, including customer information and credentials, from entering an AI prompt. Staff may only use approved AI tools through company-managed enterprise or team accounts. Personal and free-tier AI accounts are not used for work purposes, full stop.
Independent testing and ongoing review
- Annual third-party penetration testing of all AI system interfaces and APIs
- Quarterly internal review of access logs for AI systems handling student data
- Annual review of every data processing agreement with an AI vendor
- Immediate security review triggered by any AI-related incident or vulnerability disclosure
Regulatory alignment
Our AI data security controls are built to meet obligations under UK GDPR and the Data Protection Act 2018, FERPA in the United States, and PIPEDA and provincial privacy laws in Canada, including the ICO's guidance on AI and data protection. Data Protection Impact Assessments are completed for any AI processing that involves systematic profiling or large-scale processing of special category data.
%20(20).png)
If something goes wrong
We operate a classified AI incident response process. Where an incident constitutes a personal data breach, we follow the applicable notification requirements, including notifying the ICO within 72 hours where UK data is affected. Affected institutions are told promptly and honestly: what happened, what data was involved, and what we're doing about it.