The Two Planes of District AI: Direct Use at the Edge and AI in the Backend

Current status: Tenet Edge is the current direct-use governance surface. Tenet Gateway is a founding-district program whose production scope is defined with each participating district.

School districts now need to govern two kinds of AI activity. Direct AI use is a student or staff member working in an AI product. Backend AI use is a district application calling a model through an API. Both need consistent district policy, but they do not need the same enforcement point, traffic path, or conversation archive.

Tenet calls these the Edge plane and the backend application plane. Tenet Edge applies policy where people use supported AI products on managed devices. Tenet Gateway is a founding-district program for governing AI operations performed by district applications. A shared control plane can align the policy vocabulary across both.

Why tool approval is no longer enough

An early AI governance program often begins with a list: which chatbots may students use, which staff tools are approved, and which sites should be unavailable. That list is useful, but it covers only visible, direct use.

AI is also becoming part of district-built and vendor-built applications. A family communication workflow may draft text with a model. A staff application may summarize an approved document collection. A tutoring application may create practice questions in the background. In each case, the user might never open an AI website. The application makes the model call.

The U.S. Department of Education’s 2023 report on AI in teaching and learning treats AI as a system-level policy concern, including privacy, human oversight, evaluation, and equity. NIST’s AI Risk Management Framework similarly organizes work across governance, context mapping, measurement, and ongoing management. These sources point toward an operating model, not a one-time vendor decision.

Plane	What happens	District question	Enforcement surface
Edge: direct use	A student or staff member works in an AI product	What may this person do in this role, class, and instructional context?	The managed interaction surface
Backend application use	A district application sends a request to a model API	Is this application authorized for this purpose, data class, and model deployment?	A district-controlled policy decision before approved traffic continues

Plane one: direct AI use at the Edge

Tenet Edge governs people using supported AI products directly through a managed Chrome client.

A district might approve an AI product for learning while still needing the experience to reflect district baseline rules and classroom context. A history teacher may permit an activity that would be inappropriate during an assessment. An elementary classroom may need different boundaries than an advanced computer science course. A destination-level allowlist cannot express all of those distinctions inside an approved product.

Tenet Edge is designed to apply district and classroom guardrails at the interaction surface. District policy, teacher rules, identity context, and roster or schedule mappings inform local policy decisions. For ordinary Edge enforcement, student prompt and response content does not need to be processed or stored on TrueMadeAI servers.

That statement has boundaries. Tenet’s backend still handles configuration and can receive event metadata. A district can also select supported district-owned analytics destinations. Districts should define which events are retained, who can access them, and when they are deleted. Precise data-flow documentation is more useful than a broad promise that all data stays in one place.

Questions the Edge plane must answer

Which AI products and managed-device configurations are supported today?
Which students, staff members, schools, classes, and schedules are in scope?
Which district rules are fixed, and where may teachers make a class-level choice?
What happens when a user attempts an action outside policy?
Which event metadata is recorded, where is it sent, and who may review it?
How are compatibility and policy behavior validated when AI products change?

Tenet publishes product claims only for tested surfaces and supported configurations. A district implementation should use the current compatibility and trust documentation, not assume every AI website behaves alike.

Plane two: AI used by district applications

Tenet Gateway is a founding-district program for district applications that use model APIs in the backend.

A traffic gateway can handle valuable infrastructure work: routing requests, protecting API credentials, applying quotas, retrying failed calls, and recording operational telemetry. Those functions do not, by themselves, answer whether a particular K-12 use is authorized.

A district governance decision needs more context:

Which application is acting?
Who owns it and who approved its use?
What educational or operational purpose is documented?
Which systems and data classes may it access?
Which provider, account configuration, region, and model deployment are eligible?
What human review or other constraints apply?
What decision evidence is retained, and for how long?

For a backend operation, the authorization question can be expressed as:

application identity
+ accountable owner and delegated authority
+ approved purpose
+ requested AI operation
+ approved system and data class
+ eligible model deployment
+ current district policy
= allow, deny, constrain, redact, require approval, or record for review

The Tenet Gateway founding-district program is designed to keep commodity traffic infrastructure replaceable. A district may already have a cloud, API-management, or model-routing platform. Tenet’s role is the K-12 authorization and governance logic that sits above or beside that traffic layer, subject to the scope defined with the founding district.

One control plane does not mean one data lake

A shared control plane means that the district can maintain a consistent set of definitions and decisions across AI activity:

district, school, role, course, and classroom policy;
approved AI products, applications, providers, and model deployments;
identity and roster context;
authorized purposes and approved data classes;
policy versions, exceptions, and review dates;
common decision and audit semantics.

The data paths remain separate. At the Edge, policy is applied where a person uses a supported AI product. In the backend plane, a district-controlled runtime evaluates an application’s authorization context before an approved traffic layer sends the request onward. Sharing policy intelligence does not require collecting every prompt in a central repository.

Why districts need both planes

An Edge-only program leaves backend application calls outside the governance model. A gateway-only program leaves direct use in subscription AI products outside it.

Shared policy concept	Direct use at the Edge	Backend application AI
Identity	Student or staff role, managed device, roster and schedule context	Application identity, accountable owner, and sometimes delegated human authority
Purpose	Class, assignment, age group, and instructional context	Registered educational or operational use case
Data boundary	What a person may submit to an approved product	Which approved systems and data classes an application may access
Model eligibility	Supported product, account configuration, and district policy	Provider, deployment, region, logging setting, contract, and route
Evidence	Bounded policy and safety events under district rules	Authorization and operational decision records under district rules

When these concepts live in unrelated spreadsheets and informal review processes, the district can end up answering the same question differently across products. A shared control plane provides a consistent vocabulary while preserving the technical and privacy boundaries appropriate to each plane.

What this framework does not promise

It does not make every provider, model, product, or account configuration equivalent. Terms, retention, training use, geography, logging, and contract commitments matter.
It does not turn a policy document into a legal conclusion. District privacy, legal, curriculum, accessibility, and technology leaders retain their responsibilities.
It does not mean a student’s IEP, Section 504 plan, or education record should be copied into an AI context. Learner-specific support requires a separate, privacy-conscious design and district approval.
It does not mean the Tenet Gateway founding-district program replaces a general-purpose traffic gateway.
It does not represent roadmap ideas as generally available capabilities. The Tenet Gateway founding-district program has district-specific scope and validation.
It does not promise complete file-content protection across every product and upload path. Supported Edge behavior must be stated by tested surface and configuration.

A practical starting sequence

Inventory AI use. Include direct-use products, AI embedded in purchased software, district-built applications, and informal pilots.
Assign decision rights. Name owners for instructional policy, privacy review, accessibility, security, technical enforcement, and application approval.
Create an application register. Give every backend use an owner, purpose, data boundary, model deployment, status, and review date.
Define provider and deployment eligibility. Approval should identify the product, account type, configuration, region, contract, and model route when relevant.
Choose the enforcement surface. Direct use is an Edge problem. Backend API use is an application-authorization problem. Some programs need both.
Define bounded evidence. Decide what must be recorded, where it is retained, who reviews it, and when it is deleted.
Review material change. Revisit approval when a provider changes terms, a model changes, a data source expands, or the educational purpose changes.

Use the district AI application register template to inventory backend uses, and the AI tool vetting and approval template for direct-use and embedded tools.

Frequently asked questions

What are the two planes of district AI?

The Edge plane is people using AI products directly. The backend plane is district applications calling models through APIs. The two planes need common policy concepts but different enforcement points.

Is an AI gateway the same as an AI governance control plane?

No. A traffic gateway can route requests, protect credentials, apply quotas, and collect operational telemetry. A governance control plane defines whether a use is authorized for a specific identity, purpose, data class, and model deployment. Read the detailed AI gateway and control plane comparison.

Does one control plane require one conversation archive?

No. A shared control plane can distribute policy and normalize decision records while preserving separate data paths and district-defined retention boundaries.

Is Tenet Gateway generally available?

Tenet Gateway is a founding-district program. Its scope, supported integrations, and production validation are defined in each participating district’s implementation plan.

Can a district govern AI with a web filter alone?

A web filter can allow or block destinations, but it does not by itself govern context inside an approved AI product or backend AI calls made by district applications.

Sources

This resource is educational information, not legal advice. Districts should apply their own legal, privacy, accessibility, procurement, and instructional review processes.