AI Gateway vs. AI Governance Control Plane for School Districts

Current status: Tenet Gateway is a founding-district program. Its supported production scope is established with each participating district.

An AI gateway handles model traffic. An AI governance control plane decides whether the operation should be allowed. A gateway can protect credentials, route requests, apply quotas, retry calls, and collect operational telemetry. A K-12 governance control plane adds the district context a traffic layer does not know by default: application identity, accountable owner, approved purpose, permitted data, eligible deployment, constraints, policy version, and review evidence.

Districts with backend AI applications often need both. They do not need to buy both functions from one vendor or place all AI data in one repository.

A precise comparison

Capability	Traffic gateway	Governance control plane
Protect model credentials	Core function	References credential and deployment policy
Route among providers or models	Core function	Defines which routes are eligible for a use
Apply quotas and rate limits	Core function	Defines role, application, purpose, or risk-based limits
Retry and normalize API calls	Core function	Not a primary function
Collect latency and error telemetry	Core function	Uses bounded evidence to review policy decisions and exceptions
Identify the calling application	Often technical identity only	Connects identity to owner, authority, purpose, and approval
Decide which data class is permitted	Usually custom logic	Core policy concept
Apply K-12 role and roster context	Usually custom logic	Core policy concept where appropriate
Track approval and review dates	Not a typical traffic function	Core governance function
Enforce human-review requirements	Usually custom logic	Expresses the requirement and decision outcome
Maintain district policy versions	Not a typical traffic function	Core governance function

A product can implement features in both columns. The distinction is about responsibility, not branding.

Why an API key is not enough context

An API key can tell infrastructure which account pays for a request. It rarely proves all of the following:

the registered application making the request;
the person or team accountable for the application;
the district-approved educational or operational purpose;
the systems, records, and data classes the use may access;
the provider, account configuration, region, model, and logging settings approved for that purpose;
whether a person must review the result before it affects a student or district process;
which policy version and exception record apply.

Without that context, two very different uses can look like identical API traffic. A generic staff drafting assistant using public text and a student-support workflow using education records might share a provider account. Their governance requirements should not be identical simply because their requests use the same endpoint.

The authorization envelope

A district can describe each requested operation with a small set of policy attributes:

application: family-communications-draft
owner: communications-office
authority: approved-registration-2026-014
purpose: draft-language-for-human-review
requested-operation: text-generation
source-system: approved-public-document-library
data-class: public
model-deployment: district-approved-route-a
human-review: required-before-publication
policy-version: district-ai-policy-3

The governance layer evaluates that envelope and returns a decision. The traffic layer then carries out only an eligible route.

governance decision -> allow with constraints
traffic action -> use approved route, quota, and credential
evidence -> retain bounded decision metadata under district policy

This separation makes decisions explainable. It also lets a district change model-routing infrastructure without rebuilding the policy vocabulary.

What belongs in the control plane

Identity and authority

Authentication answers whether an identity is genuine. Authorization answers what that identity may do. A K-12 control plane should connect technical identities to accountable owners, roles, delegated authority, and approval records.

Purpose

“Use AI” is not a purpose. Useful purpose statements identify the educational or operational outcome, eligible users, and the limits of use. Purpose is important because the same data may be appropriate for one approved workflow and inappropriate for another.

Data boundary

Approval should identify the source system, data classification, fields or document collection, and prohibited data. It should also state what goes to the model provider, what returns, what is logged, and what is retained.

Model deployment eligibility

“Approved model” can be too broad. A deployment includes provider, product or API, account type, model version or family, region, logging and training-use configuration, contract, and route. A consumer account and a district-contracted API deployment should not be treated as interchangeable.

Constraints and evidence

The policy may require redaction, human review, restricted output use, a lower quota, an expiry date, or an exception approval. Evidence should capture the decision needed for later review without creating an unnecessary transcript archive.

How Tenet separates the responsibilities

Tenet’s public architecture uses three terms:

Tenet Edge is the current governance surface for people using supported AI products through a managed Chrome client.
Tenet Gateway is a founding-district program for applying district authorization to backend AI operations.
The Tenet control plane is the shared policy model across identity, purpose, approved data, model eligibility, constraints, and decision evidence.

The Tenet Gateway founding-district program is not presented as a universal replacement for API management or model-routing infrastructure. Its design keeps that infrastructure replaceable. The supported production path, integrations, and validation must be stated in each founding-district implementation plan.

Four architecture tests for a district

Test 1: Can policy distinguish two apps using the same provider account?

If not, the traffic layer may have an account identity but no application-level authorization.

Test 2: Can approval name a data boundary more specific than “student data”?

If not, reviewers cannot tell which source, records, fields, or document collection are actually in scope.

Test 3: Does changing a model route preserve the approval decision?

If not, routing and governance may be coupled so tightly that a technical change silently changes the approved use.

Test 4: Can the district explain a decision without retaining every prompt?

If not, the evidence model may be collecting more content than the governance purpose requires.

Common misconceptions

“Our cloud platform already governs AI”

It may provide strong identity, networking, policy, and logging primitives. The district still needs to configure them around K-12 purpose, data, roles, approvals, and review. Platform capability and district governance are not the same thing.

“An approved vendor means every use is approved”

Approval should attach to a defined use and deployment. A provider can offer multiple products, regions, account types, models, retention settings, and contracts.

“Centralizing every prompt creates accountability”

Accountability requires appropriate evidence, not unlimited collection. A district can retain approval and decision metadata, incident records, and authorized audit evidence while minimizing routine content.

“The gateway can infer educational purpose from prompt text”

Purpose should come from an approved application registration and trustworthy identity context. Guessing purpose from content is weaker and creates additional privacy risk.

A district procurement checklist

Ask any gateway or governance vendor:

How is the calling application identified and bound to an accountable owner?
Can policy express purpose, data class, model deployment, and human-review requirements?
Which decisions happen before model traffic continues?
Which integrations are supported in production today?
What content and metadata are processed, stored, or forwarded by each component?
Can the district use its existing traffic infrastructure?
How are policy versions, exceptions, and review dates represented?
What happens if the policy service is unavailable?
How does the district revoke an application or model route?
Which claims are current, which are pilot-specific, and which remain roadmap items?

Use the AI application register template to establish the inputs to this architecture, then define the data boundary for each district AI application.

Frequently asked questions

What does an AI gateway do?

An AI gateway typically handles traffic functions such as credential protection, routing, quotas, retries, provider selection, and operational telemetry for model API calls.

What does an AI governance control plane do?

A governance control plane defines and distributes policy about identity, authority, purpose, approved data, eligible model deployments, constraints, exceptions, and decision evidence.

Does a school district need both?

A district with backend AI applications commonly needs both sets of functions. They can be implemented in separate products as long as the authorization decision reliably governs the traffic path.

Must a district replace its existing API platform?

No. A governance layer can be designed to work with replaceable traffic infrastructure, subject to supported integrations and the district’s architecture.

Is Tenet Gateway generally available?

No. Tenet Gateway is a founding-district program. Production scope, integrations, controls, and validation are documented with each participating district.

Sources

This resource is educational information, not legal advice. Tenet Gateway is a founding-district program, and no production capability should be inferred beyond a participating district’s documented scope.