K-12 AI Governance Software: What Counts, What Doesn't, and How Districts Should Evaluate It

Current status: Last reviewed August 16, 2026. Product categories overlap and vendor capabilities change. This guide classifies control points rather than awarding a universal product ranking.

K-12 AI governance software turns district policy into controls across AI products and district-built AI applications. It is different from a student chatbot, a web filter, or a software-vetting database.

Those other systems can still be important. The mistake is treating every product that helps with one part of AI adoption as if it provides the same control. A managed student workspace, a web filter, an application inventory, a policy repository, and a runtime control layer answer different questions.

This guide gives districts a practical way to separate those categories before comparing vendors. It does not declare that one architecture is right for every school system. It asks a simpler question: where does each district decision become an actual control?

Governance is the system, not the product label

The National Institute of Standards and Technology organizes AI risk management around four connected functions: govern, map, measure, and manage. Governance is cross-cutting. It establishes policies, responsibilities, risk tolerance, documentation, and accountability that inform the other functions.

For a school district, that means AI governance is larger than any one software purchase. It includes:

board and administrative policy;
instructional standards and academic integrity;
student privacy, records, and data minimization;
cybersecurity and incident response;
application review, contracting, and procurement;
identity, devices, rostering, and authorization;
teacher guidance and classroom decisions;
technical controls at the places where AI is used; and
continuing review when products, models, laws, or district needs change.

Software supports this operating system. It does not replace district leadership or professional judgment. The useful market question is therefore not, “Does this vendor say governance?” It is, “Which governance job does this product perform, and where?”

The five product categories districts should separate

Category	Primary job	Strongest control point	What it does not establish by itself
AI workspace or walled garden	Give students or staff a managed AI experience inside one provider environment	The provider’s own application	Policy across unrelated AI products or district-built backend applications
Web filter and student-safety monitoring	Allow, block, categorize, or alert on destinations and browsing activity	Network, DNS, browser, or device access	What a user may ask after an approved AI destination is open
Vendor-vetting and DPA repository	Organize applications, approvals, privacy review, agreements, and usage evidence	Procurement and administrative workflow	Runtime enforcement inside an approved AI interaction
Policy-document workflow	Draft, review, approve, publish, and version district policy	Board and administrative records	A technical decision at the moment an AI action occurs
Cross-platform runtime governance	Apply approved policy to supported direct AI interactions and backend AI operations	The supported user interaction or application request path	Contracts, broad web filtering, identity infrastructure, or the district’s full governance process

These categories can overlap. A provider may offer capabilities from more than one row. Classification should follow demonstrated control points, not the broadest marketing label on a website.

1. AI workspaces and walled gardens

An AI workspace gives teachers or students a purpose-built environment for AI activity. It may include teacher-created experiences, product-specific content controls, session visibility, assignment templates, and centralized administration.

For example, SchoolAI describes Spaces as teacher-configured experiences with parameters for standards, goals, and tone, plus a teacher dashboard for viewing student sessions. That is a meaningful product model. A district may prefer it when consistency inside one managed environment matters more than access to several general-purpose AI products.

The architectural boundary is equally important. The provider governs activity inside its own environment. It does not automatically carry the same district rule into ChatGPT, Gemini, Claude, an AI writing panel embedded in another application, or an AI operation made by a district server.

Ask a workspace provider:

Which student and staff experiences are inside the managed boundary?
Which model providers, subprocessors, accounts, and features are included?
What teacher and administrator context reaches each interaction?
What data is collected, retained, or available in reports?
What happens when a user leaves the workspace for another AI product?

A workspace can be an intentional district strategy. It should not be described as cross-platform governance unless the controls actually extend beyond the provider’s environment.

2. Web filters and student-safety monitoring

Web filters govern destinations and broad browsing behavior. They can block websites, categories, proxies, harmful material, or newly identified threats. Safety-monitoring products may add alerts and investigation workflows.

GoGuardian, for example, describes GoGuardian Admin as K-12 web filtering with filtering policies across users, devices, operating systems, and browsers. That is a clear and valuable control point. It is also different from deciding what a student may submit after an approved AI site is open.

A web filter can answer questions such as:

May this user or device access this destination?
Is this domain or page category allowed?
Should the district block an unknown or unapproved website?
Does observed browsing activity require an alert or review?

It usually cannot answer every in-surface question, such as:

Is brainstorming allowed while full-answer generation is not?
Which teacher rule applies to this class or take-home assignment?
Does the prompt contain more student information than the task requires?
May a district application retrieve a particular record before calling a model?

Districts should not remove broad filtering merely because they add AI governance. The controls are complementary. Read Tenet compared with an AI web filter for a more detailed division of responsibility.

3. Vendor-vetting and DPA repositories

Vendor-vetting systems help districts inventory applications, collect requests, assign reviews, document approval status, organize privacy information, and communicate which tools are permitted. Some also measure high-level application use.

Instructure describes LearnPlatform as an edtech effectiveness system with product libraries, requests, review workflows, privacy information, application inventory, and usage analysis. Its documentation also makes an important boundary explicit: LearnPlatform equips districts with information, while the district determines whether a product meets its privacy requirements.

This category can answer:

Which products has the district reviewed?
What approval or privacy status has the district assigned?
Which agreements, resources, and review notes are associated with the product?
Which applications appear to be used across the organization?
Who owns the next procurement or review action?

That record is essential, but approval is not runtime authorization. A signed agreement does not decide whether a specific student record is necessary for a specific prompt. A product inventory does not apply a teacher’s rule inside an approved AI chat. A no-training statement does not mean content is never processed or retained.

The U.S. Department of Education’s student-privacy guidance similarly treats evaluation of an online service as a district responsibility. Districts should understand what information a service collects, uses, and transmits before deciding whether to adopt it.

Use the AI application register, AI tool vetting template, and vendor DPA review questions to structure that work.

4. Policy-document workflows

Policy workflows help a district draft, review, approve, publish, acknowledge, and version rules. They can create a durable record of who approved a policy and which text was in force on a particular date.

That is governance work. It is not the same as technical enforcement.

A policy may say that students can use AI for brainstorming but not final-answer generation. A document workflow can preserve that sentence and its approval history. A runtime control must still determine whether the rule applies to the current student, class, product, feature, and action, then guide, warn, transform, allow, or stop the supported activity.

Districts should require a clean handoff between policy records and operational controls:

Who owns the authoritative rule?
Which users, applications, grades, classes, purposes, and data types does it cover?
How is the approved rule represented in technical configuration?
How is a change tested before broad rollout?
How can the district prove which configuration was active?
What happens when policy language cannot be translated into an enforceable control?

Do not force every principle into automation. Some rules require human judgment, instruction, professional development, or case-by-case review.

5. Cross-platform runtime governance and enforcement

Runtime governance applies district decisions at supported AI control points. Those control points can exist in two different planes:

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

Direct-use governance may use device identity, account context, product-specific behavior, grade or class rules, on-device data protection, and an approved-product policy. Backend governance may use application identity, acting-person identity, authorization before retrieval, purpose, data classification, model eligibility, limits, and tool permissions.

The common requirement is not a particular implementation. It is a repeatable decision with a defined authority, input context, enforcement point, failure behavior, and evidence boundary.

A district evaluating this category should ask:

Can the vendor demonstrate the exact place where a decision is made?
Does the action affect an entire destination, one AI interface, one message, or one backend operation?
Which users, devices, applications, products, features, and content types are supported?
What context is authoritative, and what happens when context is missing?
Does sensitive-data handling occur before the supported send or retrieval?
What raw content, if any, reaches the governance vendor?
How are false positives, exceptions, product changes, and unavailable services handled?
What evidence can the district own without creating an unnecessary transcript repository?

Read The Two Planes of District AI and How School Districts Can Govern Student Use of AI Tools for the underlying architecture.

Where Tenet by TrueMadeAI fits

Tenet by TrueMadeAI is K-12 AI governance software. It is designed as a runtime governance layer, not as a general web filter, student chatbot, DPA repository, or board-policy authoring system.

Tenet Edge

Tenet Edge governs supported direct AI use on district-managed Chrome devices. Depending on the product surface, tier, and configuration, controls can include a district baseline, product and usage rules, guidance inside supported AI experiences, on-device data loss prevention, optional blocking for detected unapproved AI interfaces, and classroom-aware policy in Tenet District.

Coverage is not universal. Product hosts, features, account types, files, images, voice, embedded interfaces, and connected services can behave differently. Districts should use the dated supported-products capability matrix during rollout planning.

Tenet Gateway

Tenet Gateway is a founding-district program for approved backend AI operations inside district applications. The intended control boundary includes application identity, acting-person context, authorized purpose, data access, eligible model route, limits, failure behavior, and evidence for the scoped operation.

Gateway program participation does not mean that every district application, model route, or data flow is already approved for production. Each workflow requires written scope and validation with the participating district.

What Tenet does not replace

Tenet can work alongside:

the district’s web filter and student-safety systems;
provider-specific education workspaces and account controls;
application inventory, procurement, and DPA workflows;
identity, device management, and rostering;
board and administrative policy records;
professional development and classroom instruction; and
district legal, privacy, security, accessibility, and curriculum review.

That boundary is a feature, not a gap in the definition. A credible governance architecture identifies which system owns each decision instead of claiming that one dashboard replaces the district’s entire operating model.

A practical evaluation sequence

Districts can compare unlike products without collapsing their categories by following this sequence.

Step 1: Name the AI paths

List the exact direct-use products, embedded AI features, and district-built backend operations in scope. Include accounts, devices, users, purposes, and content types.

Step 2: Map the current controls

For each path, document the existing workspace settings, web filtering, identity, application approval, contract, policy record, data protection, teacher guidance, and incident process.

Step 3: Identify the missing decision

State what the district cannot currently decide or prove. Examples include applying a class rule inside an approved chatbot, minimizing sensitive data before a supported send, blocking a detected unapproved writing panel without blocking the surrounding application, or authorizing a backend record retrieval before a model call.

Step 4: Match the product category to the gap

Buy a workspace when the district wants one managed AI environment. Buy or retain a web filter for destination and browsing controls. Use a vetting repository for application approval and contract records. Use policy workflow for authoritative documents. Evaluate runtime governance when the gap exists at the supported interaction or backend operation.

Step 5: Require evidence at the enforcement point

Ask the vendor to demonstrate the priority workflow with representative nonstudent data. Record the exact product surface, configuration, decision, outcome, limitation, and fallback behavior.

Step 6: Pilot the whole operating model

Test the technical control together with staff ownership, student notice, teacher guidance, support, exceptions, incident response, and change management. A successful feature demonstration is not yet a successful district rollout.

Use the K-12 AI governance software buyer’s guide and RFP checklist to turn this category map into evaluation requirements.

Questions to put in every vendor meeting

Which product category or categories are you claiming?
Where does your system observe context and make a decision?
What can the system allow, guide, warn, transform, stop, or document?
Which exact AI surfaces and backend paths are supported today?
What happens outside that coverage?
Which district system remains authoritative for identity, roster, policy, approval, and contracts?
What student or staff data reaches your systems?
How do you handle unavailable context, scanning errors, false positives, and vendor-interface changes?
What evidence can the district inspect or own?
Which claims are demonstrated, which are planned, and when was each capability last tested?

A clear answer will often show that several tools are complementary rather than direct substitutes. That clarity is the starting point for a defensible K-12 AI governance architecture.

Frequently asked questions

What counts as K-12 AI governance software?

K-12 AI governance software should connect district authority to repeatable controls over approved AI use. A district should be able to identify the policy owner, user and application context, enforcement point, data boundary, evidence, failure behavior, and known coverage limits. A policy library or monitoring dashboard can support governance without performing runtime enforcement.

Is a student AI workspace the same as AI governance software?

No. A student AI workspace can provide a managed environment, teacher visibility, and product-specific safeguards inside its own experience. Governance software addresses district decisions across the AI products and application paths the district chooses to support. A district may use both.

Is a web filter enough to govern AI in schools?

No single control is enough. A web filter is valuable for destination access, category controls, and broad browsing safety. It usually does not carry assignment, teacher, data-minimization, or backend-application rules into every allowed AI interaction.

Do vendor vetting and data privacy agreements replace runtime governance?

No. Vetting and agreements help a district decide which service may be used and under what obligations. Runtime governance addresses what an authorized person or application may do in a specific supported interaction. The controls solve different parts of the problem.

What should a district compare before buying AI governance software?

Compare the exact enforcement point, supported products and features, identity and classroom context, sensitive-data handling, evidence model, district ownership, failure behavior, change-management process, deployment requirements, and written limitations. Require a dated capability matrix and representative pilot tests.

Where does Tenet by TrueMadeAI fit?

Tenet by TrueMadeAI is K-12 AI governance software. Tenet Edge applies district controls to supported direct AI use on managed Chrome devices. Tenet Gateway is a founding-district program for approved backend AI operations inside district applications. Tenet complements web filtering, product vetting, provider controls, identity, procurement, and staff training rather than replacing them.