Current status: This template is a governance aid. Tenet Gateway is a founding-district program.
A district AI application register is a living inventory of every application that uses AI and the authorization attached to that use. Each entry should identify an accountable owner, approved purpose, eligible users, source systems, data classes, provider and model deployment, decision status, constraints, evidence, and review date. It is more precise than a vendor list because one vendor can support several applications with different purposes and risks.
Download the AI application register CSV
What belongs in the register
Include:
- district-developed applications and automations that call model APIs;
- vendor applications with enabled AI features;
- productivity, communication, tutoring, assessment, analytics, and administrative workflows that use AI;
- pilots, grants, research projects, and limited trials;
- retrieval or search applications that use models over district documents;
- agent-like workflows that can call tools or take actions;
- direct-use AI products when the district wants a unified inventory, with their Edge enforcement surface recorded separately.
Do not wait until procurement discovers a use. Feed the register from architecture review, cloud and API accounts, identity systems, procurement, data-sharing review, department intake, and school-level pilots.
The minimum record
| Field | Required content |
|---|---|
| Application ID | Stable district identifier, not a mutable product name |
| Application name | Plain-language name used by staff |
| Accountable owner | District role responsible for purpose, renewal, and retirement |
| Technical owner | Team responsible for integration and operation |
| Purpose | Specific educational or operational outcome |
| Eligible users | Roles, grades, schools, departments, or service identities |
| AI operation | Generation, summarization, classification, extraction, search, recommendation, or another defined operation |
| Source systems | Systems, repositories, or user inputs that supply data |
| Data boundary | Approved data classes, fields, document sets, and prohibited data |
| Provider and product | Entity and service that process the model request |
| Model deployment | Account, API, model family or version, region, route, and relevant configuration |
| Human responsibility | Required review and who makes the final decision |
| Approval | Status, date, approvers, conditions, and expiry |
| Evidence | Links to vetting, contract, data flow, tests, and decision records |
| Lifecycle | Start, review, material-change, suspension, and retirement dates |
The downloadable CSV includes additional fields for retention, training use, subprocessors, accessibility, security, exception status, traffic layer, enforcement plane, and retirement evidence.
Register each AI use separately
Consider a district productivity platform that adds three AI features:
- Staff draft generic messages from public district information.
- Teachers summarize student-submitted work.
- An administrative workflow recommends outreach using attendance and grade information.
The vendor and contract may be the same. The purpose, users, data, consequence, human review, and approval conditions are different. Treat them as separate register entries or as separately governed use cases under one parent application.
Define a stable application identity
A backend governance system needs more than a shared provider credential. Assign a stable district application ID and bind it to:
- an accountable owner;
- a technical service identity;
- one or more approved purposes;
- approved systems and data classes;
- eligible model deployments;
- constraints and policy version;
- an approval and review record.
This identity makes it possible to distinguish two applications using the same traffic infrastructure. It also makes retirement and incident response practical.
Separate five things that are often collapsed
Vendor
The company providing a service. Vendor review covers organizational, contractual, privacy, security, and support evidence.
Product
The named software or API. A vendor may have several products with different terms and controls.
Deployment
The actual account, region, model, settings, connectors, and route. Consumer and district-managed deployments are not interchangeable.
Use case
The approved educational or operational purpose, users, data, and human responsibility.
Application identity
The district-controlled identity that requests an operation. It should resolve to a registered owner and policy, not merely a billing account.
Recommended statuses
| Status | Use in the register |
|---|---|
| Discovered | Use is known but has not completed intake |
| Intake | Owner, purpose, and deployment are being documented |
| Under review | Required evidence and approvals are in progress |
| Pilot | Time-bounded scope with success and stop criteria |
| Approved | Authorized within the documented boundary |
| Approved with conditions | Authorized only while listed controls remain true |
| Denied | Not authorized; reason and reconsideration path recorded |
| Suspended | Authorization temporarily withdrawn |
| Retired | Use ended; access, credentials, data, and contracts addressed |
Never leave a pilot without an end date. Never leave a discovered use without an owner and triage date.
Model deployment fields that matter
Record enough detail to know which route was approved:
- provider and service;
- consumer, education, enterprise, or API account type;
- model family and version strategy;
- processing region or residency commitment, if applicable;
- logging and history configuration;
- provider training or service-improvement setting;
- retention and deletion terms;
- district traffic gateway or routing layer;
- enabled retrieval sources, tools, or actions;
- contract and data protection agreement.
Avoid treating a vendor’s full catalog as approved because one model deployment passed review.
Connect the register to enforcement
The register is a system of record for authorization inputs. It is not enforcement by itself.
- Direct human use maps to an Edge surface. Tenet Edge governs supported direct-use products through a managed Chrome client.
- Backend application use maps to an API authorization surface. Tenet Gateway is a founding-district program for connecting registered application context to district policy.
The Tenet Gateway founding-district program should be evaluated only within a participating district’s documented production scope. A district can use this register with any technical architecture.
Read AI gateway vs. AI governance control plane to separate policy decisions from traffic functions.
Review and retirement workflow
At intake
Confirm owner, purpose, users, data boundary, deployment, consequence, and proposed timeline. Reject incomplete requests back to the owner rather than asking reviewers to infer purpose.
At approval
Record the decision, approvers, conditions, prohibited uses, policy version, evidence, review date, and disable path.
At material change
Reopen review when purpose, users, data, model, provider terms, connectors, action capability, human review, or scale changes.
At retirement
Revoke credentials and access, disable integrations, export required records, complete deletion obligations, close contracts, notify affected users, and retain only the record required by district policy.
Register quality checks
Run these checks on a regular cadence:
- entries with no accountable owner;
- pilots or approvals past their expiry date;
- uses with broad data labels but no field or document boundary;
- model deployments that do not identify the account type or route;
- applications using shared credentials without a stable application identity;
- enabled AI features absent from the register;
- suspended or retired uses with active credentials;
- material changes with no completed review;
- approvals with no tested disable or revocation procedure.
Frequently asked questions
What is an AI application register?
It is a district-owned inventory of applications that use AI, including each use’s owner, purpose, users, data boundary, model deployment, approval, constraints, evidence, and review date.
How is an application register different from a vendor list?
A vendor list identifies companies or contracts. An application register identifies each deployed use and the district authorization attached to it. One vendor can support several applications with different purposes and risks.
Should embedded AI features be registered?
Yes when they are enabled or used. AI added to an existing product can change purpose, data flow, output, terms, and risk even if the base product was previously approved.
Who owns an application register?
The district should name an accountable program owner and require a business or instructional owner for every entry. Technology, procurement, privacy, security, curriculum, and data owners should contribute through established workflows.
Is Tenet Gateway generally available for registered applications?
Tenet Gateway is a founding-district program. A register is useful regardless of the technical enforcement platform, and supported production scope is documented with each participating district.
Sources
- AI Risk Management Framework Core, NIST
- Generative Artificial Intelligence Profile, NIST
- Checklist: Data Governance, U.S. Department of Education
- Data Security Checklist, U.S. Department of Education
This template is educational information, not legal advice or a statement that any particular AI use is approved.