From the K–12 edition of September 18, 2026
OSSE releases DC LEA AI Model Policy for Staff Use with stoplight prohibitions on discipline, teacher eval, and IEP eligibility
Office of the State Superintendent of Education (OSSE), District of Columbia · K-12 state education agency / LEA guidance · Washington, D.C., United States
- Publisher
- OSSE LEA AI Model Policy for Staff Use (PDF)
- Original publication
- September 2026 (model policy booklet); press release September 1, 2026
- Source retrieved
- 2026-09-19
- Event date
- 2026-09-01
What happened
OSSE’s September 2026 Model AI Policy for Staff Use gives DC LEAs a customizable stoplight: Red bars AI for physical/biometric surveillance, student discipline decisions, teacher performance evaluations, and IEP/Section 504 eligibility determinations; Yellow allows limited use with enhanced oversight (e.g., drafting IEP language, reviewing/grading student work, device monitoring); Green covers lesson planning, tutoring plans, communications, and logistics with human review. Staff must use only approved enterprise tools for PII, complete training before use and renew annually, and keep humans accountable for outputs. The policy explicitly does not set student-use or procurement rules.
Why it matters
A transferable SEA staff-use template for districts that need clear prohibited vs. conditional AI use cases, enterprise-tool mandates, and FERPA/COPPA/CIPA/IDEA-aligned vendor expectations without waiting for binding statewide student-AI rules.
Evidence and measured results
Opened the September 2026 OSSE PDF booklet end-to-end (executive summary, guiding principles, stoplight tables, Red/Yellow/Green narratives, training and procurement recommendations). Cross-checked with OSSE’s Sept 1, 2026 press release describing the same Red/Yellow/Green categories and 45% staff-policy baseline from the LEA survey.
Limitations and uncertainty
Voluntary model policy, not legal advice and not mandatory adoption. Staff-only scope—student GenAI and tool procurement remain local LEA work. Evidence of instructional effectiveness is acknowledged as limited (cites Stanford SCALE 2026 review).
Put this evidence to work
Lighthouse Advisory interpretation, grounded in this source. Enriched 2026-09-19; this does not change the original publication date. Each role follows the same checklist so takeaways compare across sources.
Sales
Role takeaway
- Customer problem
- LEAs lack a clear staff AI use map and fear high-stakes misuse (discipline, eval, IEP eligibility) and consumer-tool PII leakage.
- Stakeholders
- State/SEA leaders
- LEA superintendents
- CTOs
- Special education directors
- HR/talent
- School board counsel
- Discovery questions
- Which staff AI uses are Red-prohibited in your draft policy?
- Can every PII workflow be forced onto approved enterprise tools?
- Is annual AI literacy training tracked before tool access?
- Do teacher-eval or discipline modules include AI features you can disable?
- Value hypothesis
- Vendors that ship stoplight-aligned controls and enterprise DPAs will win SEA/LEA staff-AI readiness work faster than consumer GenAI embeds.
- Potential engagement
- 4–6 week OSSE-stoplight localization: gap map current tools to Red/Yellow/Green, draft LEA policy text, and produce an allowlist/DPA checklist.
- Unsupported claims
- That adopting the model policy improves student learning
- Guaranteed legal safe harbor from FERPA/COPPA claims
- That staff-only policy covers student GenAI risk
Pre-sales engineering
Role takeaway
- Fit
- Fit for LEAs that can centralize enterprise AI entitlements; poor fit for unmanaged consumer chatbot use on staff devices.
- Architecture and integration
- IdP groups → approved AI gateway → per-feature policy flags; separate paths for Yellow grading/IEP-draft with human-accept queues; block Red analytics endpoints.
- Prerequisites
- Authoritative staff AI tool inventory
- Enterprise contracts with DPA language
- Training LMS for annual AI literacy
- Special education and HR process owners
- Constraints
- Staff-only scope (no student-use controls in this policy)
- Voluntary SEA guidance—local adoption varies
- Yellow uses require enhanced oversight capacity
- Security
- Enforce FERPA/COPPA/CIPA/IDEA/HIPAA/DC privacy statute compliance, encryption, MFA, incident reporting, and prohibition of consumer-grade AI for PII.
- Proof of value
- Attempt Red workflows and show hard blocks
- Yellow grading draft requires human accept before gradebook write
- Audit log of blocked consumer AI PII attempts
- Training completion gate before first AI login
Delivery
Role takeaway
- Work
- Localize stoplight language, configure allowlist, deliver pre-use/annual training, communicate to staff unions and SPED leads, and schedule yearly policy reassessment.
- Dependencies
- Legal review
- SPED leadership
- HR/eval owners
- Identity and device management
- Ownership
- LEA CIO and chief academic officer jointly; principals enforce classroom staff practice.
- Skills and adoption
- Mandatory AI literacy and data-protection training before access; annual renewal with proof of completion.
- Governance checkpoints
- Board or superintendent adoption of localized policy
- Allowlist published
- Quarterly Red/Yellow incident review
- Annual policy refresh
- Acceptance criteria
- Documented Red prohibitions implemented in production tools
- 100% of AI-enabled staff accounts training-complete before enablement
- No consumer GenAI approved for PII workflows
- Yellow IEP/grading uses show human sign-off samples
- Risks
- Staff continue shadow consumer AI despite policy
- Yellow grading/IEP drafting drifts into de facto automated decisions
- Student-use gap leaves instructional AI unmanaged
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?
District stacks need an approved enterprise AI allowlist, runtime blocks on consumer GenAI for staff PII workflows, and feature flags that can disable unauthorized AI features inside otherwise-approved products (discipline analytics, eval scoring, eligibility recommenders).
Governance
Who approves, reviews and stays accountable for outcomes?
Boards/LEAs can adopt the stoplight as local policy with community customization; separate student-use and procurement policies are still required. Annual policy reassessment is recommended as capabilities change.
Security and privacy
What data, permissions and controls need testing?
PII use limited to enterprise tools meeting FERPA, COPPA, CIPA, IDEA, HIPAA, and DC Protecting Students Digital Privacy Act; procurement guidance calls for NIST-aligned controls, MFA, encryption, incident response, and bans on unauthorized consumer-grade tools.
Accessibility and workforce
Who is affected, and what skills or accommodations follow?
Annual AI literacy and data-protection training is a workforce prerequisite; SPED staff need clear Yellow vs Red boundaries so assistive drafting does not become eligibility automation.
Procurement
What should contracts, pricing and exit terms secure?
RFPs should require enterprise-grade privacy/security, disablement of Red AI features, human-in-the-loop for Yellow grading/IEP drafting, and documented training-data/bias controls.
Operating model
Which teams own the service once it runs?
Staff AI governance becomes an operating rhythm: allowlist, training gates, yearly reassessment—not a one-time innovation pilot.
Publication history
- 2026-09-18K–12 · Issue 134 resources
Stable resource ID: osse-dc-lea-ai-model-policy-staff-use-202609