K-12 AI Governance Software Buyer's Guide and RFP Checklist

Current status: Last reviewed August 11, 2026. This guide is a procurement and implementation framework, not legal advice or a substitute for district-specific review.

K-12 AI governance software should turn district policy into repeatable decisions at the places where AI is actually used. A buyer should be able to identify the enforcement point, supported products, identity and classroom context, data protections, evidence model, deployment requirements, and known limitations before comparing feature lists or pricing.

If your team is still separating workspaces, web filters, product-vetting systems, policy workflows, and runtime controls, begin with What Counts as K-12 AI Governance Software. This buyer’s guide starts after the district understands which category it is evaluating.

The most important distinction is between a policy repository and a policy execution system. A repository helps a district write, approve, or publish rules. An execution system applies configured decisions to supported AI activity. Many districts need both, but an RFP should not treat them as interchangeable.

This guide provides a neutral evaluation framework. It does not assume that every district needs the same architecture or that one product should replace web filtering, identity, rostering, data governance, procurement, or professional judgment.

Start with the district operating model

Software cannot repair an undefined governance process. Before issuing an RFP, name the people who own:

board and administrative policy;
instructional standards and academic integrity;
student privacy and records;
security and incident response;
accessibility and accommodations;
application approval and procurement;
identity, devices, rostering, and support;
teacher guidance and classroom implementation; and
ongoing review when a vendor changes an AI feature.

Use the K-12 AI governance guide to establish the operating model and the district AI governance committee charter to assign decision rights. An RFP should follow those decisions, not become the process that makes them.

Separate the two planes of district AI

District AI activity follows at least two materially different paths.

Direct use: a student or staff member interacts with an AI product on a managed device.
Backend operations: a district application sends an approved AI operation to a selected model deployment.

Direct-use controls may need browser-visible context, product-specific adapters, data loss prevention, teacher rules, and device policy. Backend controls may need application identity, acting-person identity, authorization before retrieval, model routing, token limits, grounding, and tool permissions.

A vendor that governs one path should not imply that it automatically governs the other. Ask bidders to map every claimed feature to the exact execution path. Read The Two Planes of District AI for the architecture distinction.

Ten control areas every RFP should score

1. Policy enforcement point

Ask where the decision is made and what the product can actually change.

Can it allow, guide, warn, transform, or stop a supported action?
Does it operate only at login, only at the network, inside a supported AI surface, or in a backend request path?
Does a block affect the whole website, a particular AI interface, or a single send?
What happens when the policy service is unavailable?
Can the district test a policy before applying it broadly?

Require a diagram and a live demonstration. Avoid answers that describe policy intent without showing the enforcement path.

2. Product and feature coverage

The phrase “supports ChatGPT” is incomplete. Coverage can vary across direct chat, files, images, voice, shared links, connected storage, enterprise workspaces, personal accounts, and newly released features.

Require a dated matrix with:

exact host or product surface;
supported account and device context;
prompt, response, file, image, and voice coverage;
DLP behavior;
policy controls;
known exclusions; and
the date each surface was last tested.

Use the Tenet supported-products capability matrix as an example of the level of qualification a district should expect.

3. Approved and unapproved AI

An approved-product list is necessary but incomplete because AI features can appear inside writing, productivity, research, and learning applications.

Ask whether the product can:

allow district-approved AI destinations;
block known unapproved AI interfaces when configured;
detect observable embedded chat or writing panels;
preserve district allowlists and bypasses;
distinguish deep governed support from interface detection; and
document false-positive handling and vendor-interface drift.

Detection should never be marketed as universal inventory. A browser-visible heuristic cannot see every native application, network call, closed component, or future product change. See Shadow AI in K-12 Schools for the audit and response workflow.

4. Data loss prevention and minimization

A DPA controls provider obligations. It does not decide whether a user should paste an entire student record into an AI request. A no-training commitment controls one use of data. It does not mean the service never processes or retains the submitted content.

Require bidders to state:

where DLP runs;
which content types it covers;
whether it detects district roster data and common identifiers;
whether it warns, blocks, or transforms;
whether transformed output is verified before release;
how unscannable or failed paths behave;
whether raw content or identifier mappings leave the device; and
what district evidence is retained.

Read Why Data Loss Prevention Matters in K-12 AI, the K-12 AI data-boundary framework, and the AI vendor DPA review questions before scoring this section.

5. Identity and authorization

SSO can identify an account. It does not prove authorization to disclose a particular student’s record for a particular purpose.

Ask how the system distinguishes:

the district and managed device;
the signed-in person;
the application making a backend request;
the student’s grade, roster, and class context;
the teacher responsible for the class;
the requested purpose and operation; and
an administrator or support exception.

For backend AI, authorization should happen before record retrieval. DLP after retrieval is useful additional protection, not retroactive authorization.

6. Grade, class, teacher, and schedule context

A single district baseline can establish common rules. It cannot express every instructional context.

Evaluate whether the system can resolve:

grade or grade band;
school and roster;
class and assigned teacher;
subject;
period and schedule;
assignment-specific teacher direction; and
take-home or off-period rules.

Subject-aware take-home policy matters because homework outside a scheduled class can still require the teacher’s approved rule. Ask how subject detection is performed, how ambiguous cases are handled, and which district source remains authoritative.

The Tenet Basic and Tenet District comparison illustrates the difference between one district baseline and a context-rich district tier.

7. Evidence, privacy, and district ownership

More data is not automatically better governance. Require an evidence model that distinguishes operational proof from a transcript warehouse.

Ask:

Does the vendor store prompts or responses?
Can the district choose aggregate, event-level, or no optional reporting?
Can evidence go directly to a district-owned destination?
Who controls retention and deletion?
Are low-count or sensitive events protected from identity leakage?
Can administrators export configuration and review records?
Does the vendor use customer content to improve models or products?

Every answer should identify the data element, purpose, recipient, storage location, access model, and retention period.

8. Human authority and escalation

AI governance software should support district authority, not replace it.

Require clear answers for:

teacher decisions and permitted overrides;
administrator approval and audit trails;
student notice and support;
appeals and false-positive correction;
incident escalation;
emergency disabling or session-ending controls; and
accessibility and accommodation review.

Do not accept a claim that model-generated citations, grounding, or automated scoring guarantees correctness. Those controls can reduce some risks and improve reviewability, but responsible staff remain accountable for consequential educational decisions.

9. Change management

AI products change quickly. A static compatibility claim becomes stale when vendors modify hosts, editors, buttons, data flows, or account behavior.

Ask for:

release monitoring;
regression tests for priority surfaces;
customer notification of material coverage changes;
a documented process for newly embedded AI features;
safe fallback behavior;
versioned policy and configuration history; and
a review date on every public coverage statement.

10. Deployment and support

The implementation plan should name prerequisites, responsible parties, validation steps, and exit criteria.

For managed-device governance, ask about:

supported browsers and operating systems;
device and user policy deployment;
district domain and identity setup;
roster integration and minimum required fields;
teacher and administrator onboarding;
pilot groups and test accounts;
support ownership; and
rollback or disable procedures.

If rostering is required, ask whether the integration follows a recognized standard such as OneRoster, how tenant binding is verified, and how the district limits shared fields. A logo or partner badge is not an implementation design.

RFP checklist

Use the following checklist as minimum response requirements.

Architecture and scope

Diagram direct-use and backend AI paths separately.
Identify every enforcement point.
Define supported devices, browsers, accounts, and applications.
List unsupported or partially supported surfaces.
Explain failure and offline behavior.

Policy

Show how district baseline rules are represented.
Show grade, class, subject, teacher, and schedule differentiation.
Demonstrate assignment or take-home rule behavior.
Explain approvals, overrides, test mode, and rollback.
Provide version and actor history for policy changes.

Data protection

Provide a field-level data inventory and flow diagram.
Define DLP coverage by content type and product surface.
Explain transformation verification and uncertain-result behavior.
Identify all storage, retention, deletion, and subprocessors.
State whether raw prompts, responses, files, or mappings reach vendor systems.

Evidence and operations

Define available events, dashboards, alerts, and exports.
Separate aggregated metrics from detailed evidence.
Demonstrate district-owned destination options where offered.
Document incident response and escalation.
Provide availability, support, and change-notification terms.

Validation

Provide a dated coverage matrix.
Supply a pilot test plan and representative scenarios.
Identify known limitations and false-positive processes.
Demonstrate priority workflows with synthetic or nonstudent data.
Define objective pilot success and stop criteria.

A simple scoring model

Score each control area from zero to three:

Score	Meaning
0	No documented capability or the response does not answer the question
1	Policy statement or planned capability without validated operation
2	Demonstrated capability with stated scope and material limitations
3	Demonstrated, documented, testable capability with district controls and evidence

Weight the categories before reviewing vendor responses. A district focused on student-data protection may weight DLP and evidence more heavily. A district moving from a single approved chatbot to cross-platform governance may prioritize coverage, policy differentiation, and change management.

Keep product cost outside the technical score until evaluators establish which requirements each response actually satisfies. A lower price for a materially different control category is not an equivalent bid.

Common procurement red flags

Pause and ask for evidence when a vendor says:

“Works with every AI product” without a dated matrix;
“FERPA-ready” or similar language without explaining roles, configuration, contracts, and district responsibilities;
“No training” as if it means no processing or retention;
“Real-time governance” without showing the decision and enforcement point;
“AI-powered detection” without false-positive, failure, and override behavior;
“Complete visibility” while omitting native applications, files, voice, connected services, or unsupported hosts;
“District approved answers” when the system only routes to an approved model deployment; or
“Zero setup” when identity, policy, device, roster, and support responsibilities remain undefined.

Pilot before broad deployment

A useful pilot is bounded and falsifiable. Select representative roles, grade bands, classes, AI products, data types, and device conditions. Test approved use, blocked use, ambiguous context, DLP detection, false positives, policy changes, alerts, evidence export, support escalation, and disable behavior.

Do not use real student records to prove a control can protect student records. Begin with synthetic names, documents, rosters, and scenarios. Expand only after the district has approved the data flow, agreements, configuration, and operational ownership.

The AI governance readiness assessment can help identify which domains need evidence before an RFP or pilot begins.

The buying decision

The strongest response is not the one with the longest feature list. It is the one that makes scope inspectable.

A district should be able to answer:

What decision does this system make?
Where is that decision enforced?
Which people, applications, data, and AI surfaces are in scope?
Which are not?
What happens when the system is uncertain or unavailable?
What evidence remains, who owns it, and how long is it kept?
How will the district know when product changes invalidate an assumption?

If those answers are precise, the district can compare architectures, run a meaningful pilot, and write contractual requirements around actual controls rather than category labels.

Sources

Frequently asked questions

What should school districts look for in K-12 AI governance software?

Districts should evaluate where policy is enforced, which AI surfaces and data types are covered, how identity and classroom context are resolved, what happens to sensitive data before a supported send, what evidence the district receives, and how controls are maintained as vendors change their products.

Is an AI web filter the same as AI governance software?

No. A web filter can allow or block destinations and may provide useful discovery. AI governance software can add policy decisions inside supported AI experiences. Districts may use both because they govern different control points. Read the Tenet and web filters comparison.

Is a district-approved AI product automatically safe for every student and assignment?

No. Product approval is one decision. Grade, class, subject, assignment, teacher direction, data sensitivity, account configuration, and the specific feature in use can change what is appropriate.

Should an AI governance vendor store student prompts and responses?

A district should require a precise explanation of what is collected, why it is needed, where it is stored, who can access it, how long it is retained, and whether a lower-data design is available. Transcript collection should never be treated as an automatic requirement for governance.

How should a district evaluate DLP claims for AI?

Ask which products, fields, files, images, voice paths, and connected services are actually covered; where scanning occurs; what happens on uncertainty or failure; whether outgoing content is verified; and how district exceptions are controlled. A broad DLP label is not a coverage specification.

Why do grade-level and teacher rules matter?

A district baseline cannot express every instructional situation. Grade, roster, class, subject, period, schedule, and teacher context can support different rules for a third-grade writing activity, a high school coding class, or homework outside the class period.

What proof should a vendor provide during a pilot?

Require a written coverage matrix, configuration record, test plan, known limitations, change-management process, incident path, data-flow documentation, role mapping, and district-owned export or evidence options. Test priority workflows with representative nonstudent data before wider rollout.