From the SLED-wide archive edition of September 1, 2026
DC education agency turns staff AI guidance into a red-yellow-green decision framework
District of Columbia Office of the State Superintendent of Education · K-12 education governance and workforce · District of Columbia, United States
- Publisher
- OSSE Releases AI Model Policy to Guide Responsible Staff Use in Schools
- Original publication
- September 1, 2026
- Source retrieved
- Not recorded in the historical archive
What happened
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.
Why it matters
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 and measured results
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.
Limitations and uncertainty
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.
Put this evidence to work
Lighthouse Advisory interpretation, grounded in this source as summarized in the preserved archive. Enriched 2026-09-05; this does not change the original publication date. Labels below come from the analysis itself.
Sales
Role takeaway
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.
Pre-sales engineering
Role takeaway
- 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
Role takeaway
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.
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?
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.
Governance
Who approves, reviews and stays accountable for outcomes?
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.
Security and privacy
What data, permissions and controls need testing?
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.
The preserved archive analysis covered architecture, governance and security. Not assessed for this record: accessibility and workforce, procurement, operating model.
Publication history
- 2026-09-01SLED-wide archive · Issue 056 resources
Stable resource ID: dc-osse-ai-model-policy