From the K–12 edition of October 14, 2026
Confederation of School Trusts: AI is a board governance issue; keep an AI use-case register, find shadow AI, and test supplier claims against evidence
Confederation of School Trusts (CST) · Public-sector association for school trusts / K-12 governance · England (academy trusts); transferable to U.S. district boards and charter networks with limits
- Publisher
- Confederation of School Trusts
- Original publication
- October 2026 (PDF dated October 6, 2026)
- Source retrieved
- 2026-10-15
What happened
CST's 20-page guide (Sadeghi and Wathen, October 2026) argues AI is a governance issue, not just technology, because suppliers embed AI into products trusts already use. It says boards need stewardship, strategic oversight and assurance rather than technical expertise, and proposes an assurance framework within existing structures. Steps include defining AI scope (generative AI, agents, AI in existing platforms), finding 'shadow AI' through a low-stakes, no-judgement staff survey, and keeping a proportionate AI use-case and systems register (purpose, owner, users affected, data, supplier, human oversight, risks, assessments, approval status, review date) cross-referenced with the information asset register and Record of Processing Activity. Use cases are classified by impact, AI is integrated into existing policies, and supplier claims must be tested against research evidence, data security and pedagogical priorities. It references DfE generative AI product safety standards and filtering and monitoring standards, and includes procurement questions. Why now: published this month and not previously archived.
Why it matters
Board-level governance mechanics (register, shadow-AI discovery, proportional classification) map directly to U.S. school boards and charter management organisations that lack AI policies, as recent archived state surveys show.
Evidence and measured results
Sector guidance from a membership body representing trusts educating more than four million children; not an evaluation. No data on adoption or effectiveness of the framework.
Limitations and uncertainty
English legal and regulatory context (DfE standards, UK GDPR, KCSIE); U.S. transfer requires mapping to FERPA, COPPA and state laws. Guidance, not evidence of outcomes.
Put this evidence to work
Lighthouse Advisory interpretation, grounded in this source. Enriched 2026-10-14; this does not change the original publication date. Each role follows the same checklist so takeaways compare across sources.
Sales
Role takeaway
- Customer problem
- Boards cannot see or assure AI use as suppliers embed AI into existing products and staff use unsanctioned tools.
- Stakeholders
- Board chair and risk/audit committee
- CEO / superintendent
- Data protection officer
- IT director
- Procurement lead
- Discovery questions
- Do you know which tools staff use, including unsanctioned ones?
- Is there a register of material AI uses with owners and review dates?
- How are supplier AI claims tested before purchase?
- Who is notified when a supplier changes AI functionality or model provider?
- Value hypothesis
- A register and assurance cycle could give boards visibility and proportional control over AI risk; efficiency or learning gains are not established.
- Potential engagement
- AI assurance setup: shadow-AI survey, use-case and systems register, impact classification, and AI procurement questions for the board.
- Unsupported claims
- No outcome or savings data in the source.
- Framework effectiveness not evaluated.
- English standards do not establish U.S. compliance.
Pre-sales engineering
Role takeaway
- Fit
- Fits SSO, app-discovery, DPA management and data-classification tooling that can feed a governance register.
- Architecture and integration
- Feed the register from SSO catalogues, network or CASB discovery, DPA records and vendor change notices; apply sensitivity labels to restrict AI processing of protected data.
- Prerequisites
- SSO coverage of key apps
- Data asset register / processing records
- Sensitivity labels in office suite
- Staff survey channel
- Constraints
- UK framework, U.S. law mapping needed
- Discovery misses personal-device use
- Vendors may not disclose model changes
- Security
- Supplier assurance on data use and storage, cyber controls and incident response; classify use cases by data sensitivity.
- Proof of value
- Register reconciles survey and observed usage
- Unsanctioned tools identified and triaged
- Sensitivity labels block AI on protected data in tests
- Supplier change notices captured
Delivery
Role takeaway
- Work
- Build an AI assurance cycle within existing board structures: scope, survey, register, classification, policy integration and continuous review.
- Dependencies
- Board sponsorship
- Data protection lead time
- IT discovery data
- Staff trust for honest survey
- Ownership
- Board risk/audit committee with data protection officer and IT director.
- Skills and adoption
- Board and leader briefings on AI governance; staff guidance on approved, permitted and prohibited uses.
- Governance checkpoints
- Register review dates
- Approval for high-impact use cases
- Procurement AI questions applied
- Independent challenge or external assurance periodically
- Acceptance criteria
- Staff survey completed with target response rate
- Register populated for all material uses with owners and review dates
- Use cases classified by impact
- AI procurement questions adopted
- Risks
- Under-reporting in survey
- Register becomes stale
- Supplier changes unnoticed
- Governance seen as box-ticking
Implementation considerations
Lighthouse Advisory interpretation across the operating dimensions a public-sector buyer must settle before this evidence becomes a design. Each note answers the question under its heading for this specific source.
Architecture and integration
What must connect, and where does the AI sit in the workflow?
Register cross-referenced with data asset registers and processing records; suggests using existing office-suite sensitivity labels to inform AI use. Interpretation: register data should come from SSO, app catalogue and DPA systems rather than a standalone spreadsheet.
Governance
Who approves, reviews and stays accountable for outcomes?
Boards seek assurance through existing structures; continuous assurance as suppliers change functionality or model providers; independent challenge via peer review, external assurance or benchmarking.
Security and privacy
What data, permissions and controls need testing?
Board attention to personal data sharing, supplier data use and storage, cyber controls, incident response and supplier assurance; alignment with UK data protection and safeguarding standards.
Accessibility and workforce
Who is affected, and what skills or accommodations follow?
Boards should consider AI's impact on staff roles and ways of working and ensure psychological safety for staff disclosing AI use; workload reduction is noted as a motivation.
Procurement
What should contracts, pricing and exit terms secure?
Supplier claims tested against research evidence, data security and pedagogical priorities; appendix procurement questions, including alignment with DfE product safety and filtering standards; value-for-money and sustainability considerations.
Operating model
Which teams own the service once it runs?
Governance embedded in existing assurance structures with continuous review, not a one-off approval.
Publication history
- 2026-10-14K–12 · Issue 385 resources
Stable resource ID: cst-governing-ai-in-school-trusts-202610