{"resourceId":"dc-osse-ai-model-policy","versions":[{"version":"legacy/2026-09-01/dc-osse-ai-model-policy","resource":{"id":"dc-osse-ai-model-policy","title":"DC education agency turns staff AI guidance into a red-yellow-green decision framework","organization":"District of Columbia Office of the State Superintendent of Education","sector":"K-12 education governance and workforce","geography":"District of Columbia, United States","publishedAt":"September 1, 2026","sourceName":"OSSE Releases AI Model Policy to Guide Responsible Staff Use in Schools","sourceLabel":"DC OSSE model-policy announcement","sourceUrl":"https://osse.dc.gov/node/1844711","evidenceClass":"standards-guidance","outcomeClass":"emerging","topics":["knowledge-work","data-security","governance-procurement","accessibility-workforce","operating-model"],"finding":"OSSE released its first model policy for staff AI use after a February 2026 survey found that only 45% of DC local education agencies had established a staff AI policy. The voluntary template classifies uses as red, yellow, or green: it prohibits AI for student and staff surveillance, discipline, teacher evaluation, and IEP or Section 504 eligibility; permits guarded use for activities such as drafting IEP language and grading; and allows lower-risk drafting, customization, analysis, communication, and logistics with awareness and human review.","sledRelevance":"This is a practical state-level pattern for giving educators usable decisions rather than a list of principles. It also recognizes that the same tool can move between risk levels depending on whether it drafts material, influences a review, or makes a consequential determination.","evidence":"The agency says the policy was built from a national policy review and consultation with local school leaders. It requires approved enterprise tools, human accountability, training before use, demonstrated AI literacy, and annual renewal; links personally identifiable information to FERPA, COPPA, CIPA, IDEA, HIPAA, and District privacy requirements; and announces two forthcoming educator courses. This is implementation guidance, not evidence that the controls have improved learning, privacy, or compliance.","architectureImplications":"Enforce the stoplight model through identity-aware approved tools, data classification, blocked or approval-gated capabilities, logging, and workflow-specific configurations. Separate general drafting from systems that access student records or influence IEP, grading, discipline, monitoring, or employment decisions.","governanceImplications":"Require each LEA to tailor and formally adopt the policy, name accountable owners, define evidence for yellow-use approval, map training to permissions, document human review, and schedule updates as models and laws change. Extend the framework with separate student-use and procurement policies because OSSE explicitly leaves those areas out of scope.","securityPrivacyImplications":"Restrict sensitive work to enterprise tools with contractual data-use limits, retention and deletion controls, least-privilege access, audit logs, and vendor cybersecurity evidence. Treat disability, health, discipline, surveillance, and evaluation data as higher-risk even when AI only drafts a recommendation.","caveats":"The policy is voluntary guidance and not legal advice. OSSE has not reported adoption, compliance, incident, equity, accessibility, or outcome data, and the release does not govern student use or establish a complete AI procurement standard."}},{"version":"enrichment/2026-09-05T02:42:45.193Z/dc-osse-ai-model-policy","resource":{"id":"dc-osse-ai-model-policy","title":"DC education agency turns staff AI guidance into a red-yellow-green decision framework","organization":"District of Columbia Office of the State Superintendent of Education","sector":"K-12 education governance and workforce","geography":"District of Columbia, United States","publishedAt":"September 1, 2026","publicationDate":"2026-09-01","eventDate":null,"sourceName":"OSSE Releases AI Model Policy to Guide Responsible Staff Use in Schools","sourceLabel":"DC OSSE model-policy announcement","sourceUrl":"https://osse.dc.gov/node/1844711","evidenceClass":"standards-guidance","outcomeClass":"emerging","topics":["knowledge-work","data-security","governance-procurement","accessibility-workforce","operating-model"],"finding":"OSSE released its first model policy for staff AI use after a February 2026 survey found that only 45% of DC local education agencies had established a staff AI policy. The voluntary template classifies uses as red, yellow, or green: it prohibits AI for student and staff surveillance, discipline, teacher evaluation, and IEP or Section 504 eligibility; permits guarded use for activities such as drafting IEP language and grading; and allows lower-risk drafting, customization, analysis, communication, and logistics with awareness and human review.","sledRelevance":"This is a practical state-level pattern for giving educators usable decisions rather than a list of principles. It also recognizes that the same tool can move between risk levels depending on whether it drafts material, influences a review, or makes a consequential determination.","evidence":"The agency says the policy was built from a national policy review and consultation with local school leaders. It requires approved enterprise tools, human accountability, training before use, demonstrated AI literacy, and annual renewal; links personally identifiable information to FERPA, COPPA, CIPA, IDEA, HIPAA, and District privacy requirements; and announces two forthcoming educator courses. This is implementation guidance, not evidence that the controls have improved learning, privacy, or compliance.","architectureImplications":"Enforce the stoplight model through identity-aware approved tools, data classification, blocked or approval-gated capabilities, logging, and workflow-specific configurations. Separate general drafting from systems that access student records or influence IEP, grading, discipline, monitoring, or employment decisions.","governanceImplications":"Require each LEA to tailor and formally adopt the policy, name accountable owners, define evidence for yellow-use approval, map training to permissions, document human review, and schedule updates as models and laws change. Extend the framework with separate student-use and procurement policies because OSSE explicitly leaves those areas out of scope.","securityPrivacyImplications":"Restrict sensitive work to enterprise tools with contractual data-use limits, retention and deletion controls, least-privilege access, audit logs, and vendor cybersecurity evidence. Treat disability, health, discipline, surveillance, and evaluation data as higher-risk even when AI only drafts a recommendation.","caveats":"The policy is voluntary guidance and not legal advice. OSSE has not reported adoption, compliance, incident, equity, accessibility, or outcome data, and the release does not govern student use or establish a complete AI procurement standard.","streamIds":["state-government","k12"],"roles":{"sales":"Interpretation — Problem and stakeholders: District and state education leaders, HR, special-education teams, educators, and privacy staff need practical decisions about staff AI tasks. Discovery: Can a teacher distinguish permitted drafting from prohibited determinations, and how are higher-risk uses approved? Value hypothesis: A task-based stoplight framework could make policy usable and align access with accountable human review. Potential engagement: Tailor the voluntary template to actual district workflows and pilot training and approval controls. Evidence boundary: The release describes policy development and requirements, not adoption or improved compliance, privacy, equity, or learning. It excludes student use and is not a complete procurement standard; local review and separate policies remain necessary before operational reliance.","engineering":"Interpretation — Fit: Translate staff-use categories into controls around approved enterprise tools and specific workflows. Architecture: Tie identity, data classification, approvals, logs, and capability restrictions to distinct drafting, grading, IEP-support, and other tasks. Prerequisites: Adopted definitions, accountable reviewers, approved contracts, and training records. Constraints: One tool can support both low-risk drafting and prohibited decisions; a product allowlist is insufficient. Security: Test retention, deletion, least privilege, and sensitive student or employee data boundaries. Proposed validation: Walk red, yellow, and green scenarios through the environment, including exceptions and human review. Verify that drafting cannot silently become surveillance, eligibility determination, or employment evaluation, and that training completion does not grant unrestricted access.","delivery":"Interpretation — Work and dependencies: Tailor and adopt policy, map tasks to controls, establish yellow-use approvals, and prepare role-specific training. Ownership: District leadership owns policy; instructional and special-education leaders define uses; IT and privacy enforce data rules; supervisors verify human accountability. Skills and adoption: Teach staff to recognize risk-category changes and seek approval or report incidents. Governance checkpoints: Review sensitive workflows before launch and renew literacy and controls on the adopted cycle. Proposed acceptance: Staff correctly resolve representative scenarios, approval and review records are retrievable, prohibited capabilities fail controlled tests, and exceptions have owners. Risks: Student-use and procurement gaps, inconsistent adoption, and sensitive drafting outputs can persist even when a stoplight framework appears simple."},"retrievedAt":null,"enrichedAt":"2026-09-05T02:42:45.193Z","enrichmentBasis":"archived evidence"}}]}