Data Boundaries for K-12 AI Applications

Current status: This is a planning framework, not legal advice. Tenet Gateway is a founding-district program and does not imply generally available record-level authorization.

A K-12 AI data boundary states exactly which identity may use which data, for which approved purpose, through which model deployment, under which constraints and review. It is more useful than a blanket FERPA label, “no sensitive data,” or “approved vendor” because it connects policy to a traceable data flow.

A strong boundary names the source system, permitted fields or document collection, prohibited data, provider and account, model route, logs, retention, human responsibility, and evidence. It also has an owner, approval, expiry, and material-change process.

The authorization formula

Use this structure for every material AI operation:

governed identity
+ approved purpose
+ permitted source system
+ permitted data class, fields, or document set
+ eligible provider and model deployment
+ required constraints and human review
+ current policy and approval
= authorized operation

If any term is unknown, the boundary is incomplete.

Six layers of a complete boundary

1. Purpose boundary

State what the use is meant to accomplish and what it must not do.

Weak: “Improve instruction.”

Stronger: “Generate optional practice-question variants from teacher-authored, non-student source material for teacher review in grade 7 science. The use may not grade students or create learner profiles.”

Purpose controls which data is necessary. Without it, minimization has no reference point.

2. Identity and authority boundary

Identify the human or application actor, accountable owner, eligible roles, and approval record. A provider API key is a technical credential, not a complete statement of district authority.

For backend applications, use a stable application identity tied to the district AI application register.

3. Source and data boundary

Name:

source systems and repositories;
permitted fields, records, folders, or document collections;
prohibited categories and locations;
date range and population in scope;
whether free text, attachments, images, audio, or metadata are included;
whether the application can infer new sensitive information;
the method used to minimize, transform, or redact data.

“Directory information,” “student data,” and “de-identified” each require district-specific facts and definitions. Record the actual elements and transformation.

4. Deployment boundary

Identify the provider, product, account type, region, model, logging configuration, history setting, training-use setting, route, connector, and contract. A different account or model path can create a materially different data flow even when the vendor name is unchanged.

5. Output and action boundary

State what the output can be used for and who must review it. Distinguish among:

ideas or drafts for human consideration;
content presented directly to students;
recommendations that inform a decision;
classifications or scores;
actions that change a record, message a person, or trigger a workflow.

The higher the consequence, the stronger the validation, qualified human responsibility, appeal, and fallback need to be.

6. Evidence and lifecycle boundary

Define which approval, policy, decision, error, exception, and incident evidence is required. Then set location, access, retention, deletion, review, and low-volume privacy protections.

Do not collect a full transcript merely because logging is available. Event metadata can also be identifying or sensitive.

A data-flow worksheet

Stage	Record these facts
Collection	Actor, interface, fields, files, sensors, and account metadata
District context	Identity, role, roster, policy, source system, and retrieved material
Transformation	Minimization, masking, pseudonymization, redaction, and verification
Provider request	Exact outgoing content, metadata, model deployment, and recipient
Provider processing	Subprocessors, region, temporary and retained data, and training use
Response	Output content, confidence or uncertainty where available, and model metadata
Downstream use	Display, human review, copy, storage, record update, communication, or action
District evidence	Decision metadata, incident record, analytics, access, and retention
End of life	Export, revocation, deletion, contract closeout, and retained governance record

Verify the exact outgoing representation. A process that attempted to remove personal information is not enough if the sent text, file, name, metadata, or attachment still contains it.

A practical data classification

Districts should use their existing classification standard. If one is not yet usable for AI review, begin with a small crosswalk:

Working class	Examples	Default AI posture
Public	Published board policies, public website text, open curriculum resources	May be eligible for approved uses and deployments
Internal	Draft procedures, ordinary internal operations, nonpublic staff material	Purpose and deployment review required
Confidential	Identifiable student or employee records, security-sensitive operations	Narrow purpose, least privilege, contract, legal review, and strong controls required
Restricted	Credentials, secrets, highly sensitive records, regulated or safety-critical information	Generally prohibited unless a separately authorized architecture and compelling need are established

The table is a starting point, not a legal classification. Map it to district records schedules, state requirements, security policy, and data-owner decisions.

Four worked examples

Public communications draft

Purpose: Draft a public announcement from an already published board document.

Boundary: Public source document, staff user, approved district account, draft output, communications review before publication, short provider retention under contract.

Not included: Unpublished personnel, student, security, or legal material.

Teacher practice-question generation

Purpose: Create question variants from teacher-authored source material.

Boundary: Named course folder containing no student submissions, approved teacher roles, defined product account, teacher review before use.

Not included: Student work, grades, accommodations, or answer keys unless separately approved.

Student tutoring application

Purpose: Provide hints on a defined curriculum skill.

Boundary: Registered application identity, eligible grade and course, approved content repository, limited session context, age-appropriate interface, educator-owned escalation and review process.

Not included: Broad SIS access, discipline records, special education records, or unrelated conversation history.

Attendance outreach recommendation

Purpose: Suggest cases for qualified staff review.

Boundary: This is a higher-consequence use. It requires explicit source fields, data-owner approval, testing for error and disparate impact, qualified human review, no automatic adverse action, clear access and retention, and a process to correct data and challenge results.

Not included: An assumption that an AI score is objective or sufficient for action.

Direct-use and backend enforcement

The same data-boundary vocabulary must reach different technical surfaces.

Direct use at the Edge

Tenet Edge applies district guardrails and on-device personal-information redaction on supported direct-use text paths through a managed Chrome client. This should not be described as complete protection for every file type, upload path, AI product, or configuration. Districts need a current support matrix and precise data-flow documentation.

Backend application use

Tenet Gateway is a founding-district program for evaluating registered application context before an approved model request continues. It should not be described as generally available record-level authorization. Each participating district must document the supported identities, integrations, policy fields, failure behavior, and production validation.

Read AI gateway vs. AI governance control plane for the architecture boundary.

Redaction, pseudonymization, and de-identification are different

Redaction removes or replaces selected content. Its effectiveness depends on detection, transformation, and verification of the exact outgoing data.
Pseudonymization replaces an identifier with another value while preserving controlled linkability. It is not anonymization.
De-identification is a contextual determination about whether information can identify a person under the applicable standard and surrounding data. Removing a name alone may not be enough.

None of these techniques makes purpose, provider, deployment, retention, contract, or access review unnecessary.

Evidence without an unnecessary transcript archive

A bounded authorization record can include:

application or governed user context;
approval and policy version;
purpose and data-class identifiers;
eligible model route;
decision and applied constraints;
timestamp and review correlation ID;
exception code and expiry, if any;
operational outcome such as success or error.

Whether prompt or response content is needed for a specific incident or regulated record is a separate district decision. Define it explicitly, restrict access, and set retention. Avoid silent expansion from event evidence into routine content collection.

Boundary red flags

Pause review when:

the purpose is “all educational uses” or similarly unlimited;
the data scope is “anything the user can access”;
the application uses a shared credential with no stable identity or owner;
the provider, account type, model, or route is unknown;
a connector can search an entire drive or repository by default;
redaction is claimed without testing the exact outgoing text and files;
a consequential output can act without qualified human review;
the approval has no expiry, change trigger, or disable path;
evidence retention is indefinite because it has not been decided;
a full IEP, Section 504 plan, or other sensitive record is proposed where a narrower signal could meet the purpose.

Frequently asked questions

What is a data boundary for a district AI application?

It is the documented limit on which identity may use which source systems, fields, records, or document sets for a defined purpose through an eligible model deployment, with stated constraints and evidence.

Is saying no student data an adequate boundary?

Usually not. The phrase may hide identifiers, free text, account metadata, attachments, logs, or inferred information. Name the permitted and prohibited elements and trace the full data flow.

Is redacted data automatically safe to send to an AI provider?

No. Redaction can reduce exposure, but the district should verify the outgoing representation, consider remaining context and linkability, and review the provider, purpose, contract, retention, and applicable requirements.

Should AI decision logs contain full prompts and responses?

Not by default. Define the evidence needed for approval, operations, incidents, and review, then minimize content and set access and retention accordingly.

Does Tenet Gateway provide record-level data authorization today?

Tenet Gateway is a founding-district program. Record-level authorization should not be inferred as a generally available capability; each participating district’s supported scope must be documented.

Sources

This framework is educational information, not legal advice or a statement that a particular use is authorized.