# Data Governance for District AI: From SIS to Agent > K-12 · AI Course · K12-9 > Source: https://ibl.ai/solutions/k-12/course/district-data-governance-for-ai > Last updated: 2026-08-25 **The data plumbing behind district AI — rostering, identity, retention, and the governance that stops an agent reading records it should never see.** ## The Short Answer **Most district AI incidents are access-control failures rather than model failures. ibl.ai enforces role-based retrieval so an agent inherits the user's permissions, never the administrator's, running inside district infrastructure where you own all the code and the data — so the access model is one the district can inspect and audit itself.** On ibl.ai you own all the code and the data, run it model-agnostic across any LLM, and pay with no per-seat pricing — so you can deploy anywhere, from your own cloud to a fully air-gapped network. [Request Access](https://ibl.ai/contact) · [Explore K-12](https://ibl.ai/solutions/k-12) ## Course facts - **Level:** Advanced - **Duration:** 6 hours across 8 modules - **Format:** Technical workshop with access-control labs - **Modules:** 8 - **Catalog code:** K12-9 - **Frameworks covered:** FERPA, COPPA, NIST CSF 2.0, 1EdTech OneRoster ## What is this course about? Most district AI failures are access-control failures, not model failures. This course maps district data across SIS, LMS, assessment, special education, health, and discipline systems, then builds role-based retrieval so an agent inherits the user's permissions rather than the administrator's — plus the governance committee and breach response that has to sit around it. ## Who is this course for? - District data and integration architects - CTOs and information systems managers - Privacy officers with technical responsibility - Student information system administrators ### What do I need before starting? - Familiarity with your SIS, rostering, and identity systems - Comfort with access control concepts ## What will I be able to do afterwards? - Map district data across every system an agent might reach - Implement rostering and identity so permissions are inheritable - Build role-based retrieval that respects the requesting user's scope - Design retention and deletion schedules that actually execute - Run breach response for an incident involving an AI system ## What does each module cover? ### Module 1 — What data does a district actually hold? A complete inventory across SIS, LMS, assessment, special education, health, and discipline systems. _(45 min)_ **Objectives** - Inventory every system holding student data - Classify each by sensitivity tier - Identify the systems with the weakest access controls **Topics:** System inventory · Sensitivity tiering · Special education and health data · Control gap identification **Activity:** Build the district data inventory and tier every system. ### Module 2 — How do rostering and identity underpin everything? OneRoster, SSO, and role definitions as the foundation permissions inherit from. _(50 min)_ **Objectives** - Map roles from the identity provider through to data access - Assess rostering data quality and its consequences - Handle role changes and offboarding **Topics:** OneRoster · SSO and identity providers · Role definition · Offboarding **Activity:** Trace one user's role from the identity provider to their SIS data scope. ### Module 3 — How does an agent inherit the user's permissions? Role-based retrieval, and why an agent running with admin scope is the core district AI risk. _(60 min)_ **Objectives** - Implement retrieval scoped to the requesting user - Prevent privilege escalation through the agent - Test cross-boundary access systematically **Topics:** Permission inheritance · Privilege escalation · Scope enforcement · Boundary testing **Activity:** Configure role-based retrieval and run a cross-boundary access test suite. ### Module 4 — How do you make retention schedules actually execute? Retention and deletion that runs rather than existing as a policy document. _(50 min)_ **Objectives** - Translate retention policy into executable schedules - Handle deletion across derived data and indexes - Verify deletion actually occurred **Topics:** Executable retention · Derived data deletion · Index and embedding deletion · Verification **Activity:** Delete one student's record and verify removal across every derived store including embeddings. ### Module 5 — Why does de-identification usually fail? Small-population re-identification, and why district data resists anonymization. _(45 min)_ **Objectives** - Explain re-identification risk in small populations - Assess whether de-identification is achievable for a given use - Choose alternatives when it is not **Topics:** Re-identification risk · Small population problem · Quasi-identifiers · Alternatives to anonymization **Activity:** Attempt re-identification on a de-identified district data set and document what worked. ### Module 6 — How do you run a data governance committee? Membership, cadence, and the authority a committee needs to actually decide. _(45 min)_ **Objectives** - Define committee membership and decision authority - Set a cadence that matches the pace of requests - Design an approval workflow staff will use **Topics:** Committee composition · Decision authority · Request cadence · Approval workflow **Activity:** Draft the committee charter and run a mock approval session on three real requests. ### Module 7 — What does breach response look like with an AI system involved? Incident response when the exposure path runs through retrieval, logs, or model context. _(45 min)_ **Objectives** - Identify AI-specific exposure paths - Run containment across model context and logs - Determine notification obligations and document the analysis **Topics:** AI exposure paths · Context and log containment · Notification analysis · Documentation **Activity:** Tabletop a retrieval-permissions breach and produce the notification determination. ### Module 8 — Building the access-control matrix The workshop module: a complete matrix across three agents and four user roles. _(60 min)_ **Objectives** - Build a complete access-control matrix - Verify every cell with a test - Document it for audit **Topics:** Matrix construction · Cell-by-cell testing · Audit documentation · Change management **Activity:** Build the matrix and write a passing test for every cell. ## What is the capstone project? **District AI data governance package.** Produce the complete governance package: data inventory with sensitivity tiers, role-based access-control matrix with passing tests, executable retention schedule with verified deletion, committee charter, and a breach response plan covering AI-specific paths. _Deliverable:_ A governance package with a tested access-control matrix and verified deletion evidence. ## How are learners assessed? - Cross-boundary access test suite must pass with zero leakage - Deletion verification across derived stores including embeddings - Re-identification exercise documented with findings ## What ships with the course? - **Facilitator guide.** Session-by-session running order, discussion prompts, and the questions that reliably derail a room. - **Learner workbook.** Exercises, checklists, and the templates each module's activity produces. - **Hands-on lab environment.** A sandboxed ibl.ai deployment so exercises run against real agents, not screenshots. - **Assessment bank.** Scenario questions and rubric criteria mapped to each stated learning outcome. - **Source bibliography.** Every primary regulation and standard cited on this page, linked and dated. ## Which AI agents does this course use? - [Administration Agent](https://ibl.ai/solutions/k-12/agent/administration-agent) - [Student Safety Agent](https://ibl.ai/solutions/k-12/agent/student-safety-agent) - [Special Education Agent](https://ibl.ai/solutions/k-12/agent/special-education-agent) - [Assessment Agent](https://ibl.ai/solutions/k-12/agent/assessment-agent) ## Where does the course material come from? Every module is grounded in primary sources — the regulation, standard, or research itself, not a summary of it. Each was resolved at authoring time. - [Student Privacy Policy Office](https://studentprivacy.ed.gov/) — U.S. Department of Education. Governs the access and retention requirements the matrix implements. - [1EdTech (IMS Global)](https://www.imsglobal.org/) — 1EdTech Consortium. OneRoster specification underpinning the identity work in Module 2. - [Cybersecurity Framework](https://www.nist.gov/cyberframework) — NIST. Structures the breach response and control design work. - [Student Privacy Compass](https://studentprivacycompass.org/) — Future of Privacy Forum. District practice guidance on data governance committees. ## Delivery notes Binding guidance for anyone preparing and delivering this course: - Module 4's embedding deletion is the step districts and vendors both miss. A record deleted from the SIS but still present in a vector index has not been deleted, and the verification exercise must prove it. - Module 5's re-identification exercise should succeed. Use a small synthetic district where quasi-identifiers genuinely re-identify students — the lesson is that de-identification fails here, and a failed attempt teaches the opposite. - This is the most technical K-12 course. Do not mix audiences; run K12-1 for policy stakeholders instead. - The access-control matrix in Module 8 should ship as a reusable template with the test harness attached. Districts will not build the test harness themselves. - Use a synthetic district throughout. Real rostering data in a workshop environment is exactly the failure this course exists to prevent. ## Why run AI training on a platform you own? - **You own the course, not a licence to it.** Course content, learner data, and the platform run inside your perimeter — you own all the code and the data. - **Model-agnostic delivery.** Run the course's AI components on any LLM — Claude, GPT, Llama, Gemini, Command — and switch anytime. - **No per-seat training licences.** Usage-based or self-hosted, so cost tracks actual use rather than headcount. - **Deploy anywhere.** Cloud, private VPC, on-premise, or fully air-gapped — including for cohorts that cannot use public AI tools. ## Frequently asked questions ### What does the Data Governance for District AI: From SIS to Agent course cover? Most district AI failures are access-control failures, not model failures. This course maps district data across SIS, LMS, assessment, special education, health, and discipline systems, then builds role-based retrieval so an agent inherits the user's permissions rather than the administrator's — plus the governance committee and breach response that has to sit around it. It runs 6 hours across 8 modules across 8 modules, at advanced level, and closes with a capstone: District AI data governance package. ### Who should take Data Governance for District AI: From SIS to Agent? It is written for District data and integration architects, CTOs and information systems managers, Privacy officers with technical responsibility, Student information system administrators. Prerequisites: Familiarity with your SIS, rostering, and identity systems; Comfort with access control concepts. ### Can we run this course on our own infrastructure? Yes. ibl.ai is model-agnostic and deploy-anywhere — cloud, private VPC, on-premise, or fully air-gapped — and you own all the code and the data. Cohort data, submissions, and any material learners upload stay inside your perimeter, which matters for k-12 teams that cannot send work to a public AI tool. ### How do we get access to Data Governance for District AI: From SIS to Agent? Request access and we will set it up for your cohort — hosted by ibl.ai, or running against your own deployment. Tell us the group size and timing you need, and whether it should run inside your own perimeter. ### How much does AI training for k-12 cost on ibl.ai? There is no per-seat pricing — you pay for usage or self-host and pay only for the infrastructure, so a 5,000-person rollout does not cost 5,000 licences. 1.6M+ users across 400+ organizations run the platform this way, including NVIDIA, MIT, and Syracuse University. ## More K-12 courses - [The K-12 AI Compliance Stack: FERPA, COPPA, and CIPA](https://ibl.ai/solutions/k-12/course/k12-ai-compliance-stack): The three federal rules governing AI in a district, what each requires of a vendor, and the deployment architecture that satisfies all three at once. - [Safe AI Tutoring for Minors: Guardrails and Escalation](https://ibl.ai/solutions/k-12/course/safe-ai-tutoring-for-minors): Building a tutoring agent for children — content moderation, self-harm escalation, grooming-pattern detection, and the mandatory-reporter workflow behind it. - [AI Lesson Planning Aligned to State Standards](https://ibl.ai/solutions/k-12/course/ai-lesson-planning-standards-aligned): Generate standards-aligned lessons that survive a curriculum audit — grounded on your state's standards, your adopted materials, and your scope and sequence. - [AI in the IEP Process: Drafting, Compliance, and the Human Signature](https://ibl.ai/solutions/k-12/course/ai-in-the-iep-process): Cut IEP paperwork without ceding a legally binding decision — drafting present levels, goal writing, and the IDEA requirements no agent can satisfy for you. - [Academic Integrity and Assessment in K-12](https://ibl.ai/solutions/k-12/course/academic-integrity-and-assessment-k12): What to do when every student has a writing machine — grade-band policy, assessment redesign, and why detection tools create more problems than they solve. - [Teaching AI Literacy: A K-12 Scope and Sequence](https://ibl.ai/solutions/k-12/course/k12-ai-literacy-scope-and-sequence): A vertically-aligned AI literacy progression from elementary through high school — what to teach at each band, and the activities that make it concrete.