Digital Childhood Council
Risk Managers & Insurers
Generative AI in schools is a governance and coverage exposure, not only a technology issue.
This page is for school district risk managers, insurers, underwriters, legal counsel, and administrators evaluating student-facing generative AI deployments.
The relevant question is not whether generative AI has educational value. That is a separate inquiry. The risk-management question is whether the district has established the authority, records, contracts, coverage, monitoring, conformance, and correction mechanisms required to make student-facing use governable.
Where students can interact directly with generative AI through school-issued devices, district accounts, approved platforms, embedded features, or technically accessible systems, ordinary digital-tool governance may not be adequate. The system may generate new content in real time, shape student inputs, operate across extended multi-turn sessions, and change through vendor-controlled updates. Those conditions create exposure that cannot be resolved by an acceptable use policy, a vendor disclaimer, or a general assumption that existing coverage applies.
The Risk Question
Can the district demonstrate, from records it independently holds and contracts it can enforce, that the deployment is governed?
A governed deployment requires more than a policy. It requires an operational structure capable of answering:
- What systems and generative features are students able to access on school-issued devices and accounts?
- What did the system and student actually exchange?
- Who or what originated the relevant input or output?
- Who has accepted responsibility for system behavior?
- Is actual use staying within the boundary the district authorized?
- What happens when a student harm, concern, or nonconforming condition is identified?
- Has coverage been evaluated and confirmed for the specific student-facing use case?
The Structural Exposure
Access may exceed approval.
Districts often track formally approved tools, not necessarily what students can actually reach. That includes approved tools, technically accessible tools, embedded generative features, browser-based access, productivity-suite features, search assistants, extensions, and vendor feature rollouts.
Risk exposure attaches to what students can actually reach, not only to what the district has formally approved. A review limited to the approved-tool list has not evaluated that exposure.
AUPs do not establish attribution.
Acceptable use policies generally assume that the student independently authored the input or output in question. Generative systems complicate that assumption. They may suggest prompts, complete inputs, frame questions, continue prior context, or shape a student's reasoning across extended exchanges.
If the district cannot distinguish independently authored student inputs from system-shaped inputs through multi-turn interactions, disciplinary determinations and responsibility assignments may lack the evidentiary foundation they require.
Logs are not enough unless they support reconstruction and attribution.
A district may have usage records, access records, or partial logs. That does not necessarily mean it can reconstruct a disputed interaction. Whether records independently available to the district can show the full interaction sequence is the actual test of whether logging supports governance, not whether logs exist.
If a record is sufficient for reconstruction, it shows student prompts, system outputs, system suggestions, auto-completions, and where relevant, retained context, access conditions, and supervision context, such as whether the interaction occurred at home, at school, or under teacher observation. Where the institution cannot reconstruct those conditions from records it can retrieve, attribution cannot be demonstrated, and accountability, conformance review, and correction are undermined in turn.
Conformance is a structural test, not a policy statement.
Whether student use is remaining within the boundary the district authorized — school policy, instructional purpose, age-appropriate instructional value, supervision conditions, and approved use cases — is a question the district can either answer from its own records or cannot. There is no third option.
This is the Conformance State.
The question is not only whether a specific reported incident violated policy. The threshold question is whether the district can determine, on an ongoing basis and independent of any specific report, whether the deployment is operating within the boundary the district defined.
Without a determinable Conformance State, the district learns whether the system operated within bounds only when an outside party surfaces a problem, if at all.
Reporting is not correction.
A reporting tool, complaint process, or vendor feedback channel does not by itself establish correctability. Correctability requires a binding pathway from identified student harm to verified correction.
Whether the vendor or another accountable entity is contractually required to correct an identified condition, whether correction is verified before comparable student exposure continues, and whether correction applies across the deployment rather than only to the affected student, is what distinguishes a binding pathway from a reporting channel.
Vendor disclaimers do not resolve the district's exposure.
Vendor terms may disclaim outputs, limit liability, reserve unilateral change rights, or decline responsibility for student-facing effects. Those provisions may define what the vendor has not accepted, but they do not, by themselves, establish who remains responsible for the student-facing deployment.
Where the vendor controls output behavior and the district controls access, procurement, device issuance, account provisioning, filtering, logging requirements, and continued availability, the assertion that outputs are outside district control does not resolve the governance obligation.
Coverage assumed is not coverage confirmed.
Student-facing generative AI use should be presented to the district's insurer for specific review. General liability, educators legal liability, cyber, E&O, and other standard coverage forms were not written with AI-generated student harm, disciplinary disputes, privacy issues, civil-rights concerns, or correlated exposure across a student population in mind. Whether any of them apply to a specific deployment is a question for the insurer to answer, not an assumption to carry forward.
Coverage confirmation, as distinct from coverage assumed, addresses policy language, exclusions, endorsements, indemnity, vendor responsibility, liability limits, self-insured retentions, and whether the insurer has evaluated the specific deployment conditions.
The Five Operational Conditions
The Institutional Accountability Framework identifies five operational conditions that must function together for a student-facing generative AI deployment to be governed.
Condition 1
Attribution
Can the district determine who or what originated the relevant input or output?
Condition 2
Reconstructability
Can the district reconstruct what occurred from records it independently holds or can retrieve?
Condition 3
Accountability
Has a named entity accepted responsibility, and does that entity hold authority commensurate with that responsibility?
Condition 4
Conformance
Can the district determine whether actual use remains within the boundary it authorized?
Condition 5
Correctability
Can an identified harm, concern, or nonconforming condition be bound to verified correction?
The Governance Adequacy Test
The IAF's operational test has two layers.
Layer 1 — Deployment-State Review
Can the district determine, on an ongoing basis and independent of any specific incident, whether the deployment is operating within the boundary the district defined?
This is the Conformance State.
Layer 2 — Specific-Event Review
When a specific harm, concern, dispute, disciplinary issue, or claim arises, can the district answer from records it independently holds:
- What happened?
- Who was responsible?
- Why did it happen?
- How will recurrence be prevented?
Accountability Runs in Four Directions
Downward
Institution to Student
What does the district owe the student directly when it authorizes or permits access to a system that interacts with the student?
Upward
Institution to Vendor
What must the district secure from vendors before deployment, including logging, attribution support, correction obligations, change-control notice, responsibility alignment, and enforceable commitments?
Lateral
Institution to Insurer
Has the district disclosed the specific student-facing use case to its insurer and obtained written confirmation of coverage position?
Inward
Institution to Its Own Governance Infrastructure
Has the district built the internal capacity to detect, reconstruct, classify, route, correct, and document concerns from records and mechanisms it can actually use?
Immediate Questions for Risk Managers
Before student-facing deployment continues or expands, governing the deployment requires answers to:
Recommended Next Steps
Read the Framework
The Institutional Accountability Framework is designed to support pre-deployment diligence, legal review, coverage evaluation, and accountability determination for student-facing generative AI deployments.