Who should be accountable for AI risk management in schools?

Accountability should sit with school leadership, IT, security, and education governance teams together. AI risk affects student privacy, staff identity security, and institutional reputation, so it cannot be left to individual teachers or ad hoc local decisions. Clear ownership is needed for policy approval, tool review, incident response, and ongoing monitoring.

Why This Matters for Security Teams

AI risk in schools is not only a technology issue. It touches student data protection, staff account security, procurement, acceptable use, safeguarding, and board-level duty of care. When accountability is vague, schools tend to approve tools by convenience rather than by risk, then struggle to explain who owned the decision after a data incident or misuse event. Guidance from the NIST AI Risk Management Framework is useful here because it frames AI governance as a cross-functional management problem, not a one-team task.

NHIMG research on NHI governance shows why shared ownership matters: the 2024 ESG Report: Managing Non-Human Identities found that 72% of organisations have experienced or suspect a breach of non-human identities. Schools now face similar patterns when AI tools rely on API keys, service accounts, or delegated access that no single teacher can safely manage alone. In practice, many schools discover weak accountability only after an AI-enabled workflow has already exposed data or bypassed approval controls.

How It Works in Practice

Accountability should be assigned through a named governance model, not assumed informally. School leadership sets risk appetite and approves policy. IT owns identity, access, logging, and approved integrations. Security or an equivalent function reviews controls, incident response, and vendor risk. Education governance, safeguarding, and curriculum leads ensure the use case is appropriate for learning and child protection. This aligns well with the NIST AI 600-1 Generative AI Profile, which treats AI governance as a lifecycle issue spanning design, deployment, and monitoring.

For schools, the practical control point is usually an AI review process that answers four questions before approval: what data the tool can see, what identity it uses, who can change settings, and who receives alerts if behaviour changes. That process should also define escalation paths for privacy incidents, misuse by staff or students, and third-party model updates. The Top 10 NHI Issues page is relevant because AI tools often depend on the same secrets and service identities that become hard to trace once they are shared across departments.

• Assign one accountable owner for the policy, one for technical enforcement, and one for incident escalation.
• Require procurement to include data processing, logging, retention, and identity questions in every AI review.
• Keep a register of approved tools, connected accounts, and the business purpose for each use.
• Review access at term boundaries, after staff changes, and after vendor feature changes.

Current best practice suggests that the board or senior leadership should retain accountability even when technical work is delegated, because delegatee ownership does not replace institutional responsibility. These controls tend to break down in schools with informal tool adoption, shared admin credentials, or heavy reliance on classroom-by-classroom experimentation because no single team sees the full data and identity footprint.

Common Variations and Edge Cases

Tighter AI governance often increases review time and administrative overhead, so schools have to balance speed in teaching and learning against control of privacy and security risk. There is no universal standard for school AI governance yet, but emerging guidance increasingly favours a federated model: leadership owns the policy, IT owns the control plane, and educators own classroom appropriateness within set boundaries. That structure maps well to the NIST Cybersecurity Framework 2.0 because accountability can be tied to governance, protect, detect, respond, and recover activities rather than to a single job title.

Edge cases matter. A district-wide platform with central procurement should have central accountability. A pilot used by one department can still need senior sign-off if it processes student data or connects to school identities. Student-run or teacher-led experiments should have narrower permissions, shorter approvals, and clearer supervision. Where a school outsources IT or relies on edtech vendors, accountability still remains inside the institution even if some controls are operated externally. NHIMG’s NHI Lifecycle Management Guide is useful for mapping ownership across onboarding, monitoring, and offboarding of AI-connected accounts.

In short, the accountable party is the school as an institution, with leadership carrying ultimate responsibility and IT, security, and education governance sharing defined operational duties. The model works best when it is written into policy, procurement, and incident response before a tool is deployed, not after a complaint or breach forces the question.

Related resources from NHI Mgmt Group

• When should organisations build Responsible AI controls into their risk management framework?
• Who should be accountable for AI discovery and MCP server risk decisions?
• How should European IT leaders use AI in service management without increasing compliance or operational risk?
• Who is accountable when AI-assisted service management decisions conflict with evolving EU regulatory expectations?