AI, Accommodations, and Student Privacy in K-12

Current status: This is a planning guide, not a representation of a current Tenet learner-specific accommodation feature and not legal advice.

AI can support accessibility, but it should not become an uncontrolled copy of a student’s IEP, Section 504 plan, disability information, or other sensitive record. A credible district design starts with the responsible human team, a defined educational purpose, the minimum plan-derived information needed, an approved technical surface, clear limits, and evidence that the support works as intended. An AI feature is not proof that a plan has been implemented.

This page is a planning guide. Tenet does not currently present learner-specific accommodation controls as a generally available capability.

Begin with the district’s existing responsibility

IDEA and Section 504 establish district responsibilities that are not transferred to an AI provider. Under IDEA, an IEP is developed, reviewed, and revised through the required team process. U.S. Department of Education guidance on Section 504 explains that public school districts must provide appropriate education and related aids and services based on individual needs and required procedures.

Technology can help deliver an approved support. It cannot decide, by itself, that a support is appropriate, replace the responsible team, or prove that the district met its obligations.

The governing sequence should be:

responsible district team decision
-> approved support and educational purpose
-> minimum necessary implementation signal
-> supported AI or accessibility surface
-> qualified human review and student feedback
-> documented evaluation and revision

Not this:

full student plan
-> general AI profile
-> assumed compliance

Why copying a full plan creates unnecessary risk

An IEP or Section 504 plan can contain far more information than a particular AI interaction needs. Sending the whole record can expose diagnoses, evaluations, goals, services, family information, provider notes, and other context unrelated to the immediate task.

It also creates practical problems:

provider and account terms may not permit the intended data use;
the model may repeat or reveal sensitive context in its output;
conversation history, logs, connectors, or downstream copies can widen access;
stale plan information can persist after a support changes;
a broad profile can be applied in the wrong class or activity;
educators may assume that the tool handled a requirement that it did not actually deliver;
students and families may have no clear explanation of what data was used.

Data minimization is not the same as removing all context. It means identifying the educational purpose first, then using only the information needed for that purpose through an approved workflow.

A minimization ladder for learner-specific context

Prefer the lowest rung that can meet the approved need.

Rung	Example	Privacy posture
Universal design	Clear headings, readable structure, captions, keyboard access, multiple response modes	No learner-specific data required
Class or activity configuration	All students may request text at a selected reading level or hear instructions read aloud	Shared setting, no individual plan data required
Student-selected preference	A student activates an approved display or input option	Limited preference data, with clear scope
Plan-derived support signal	An authorized system indicates a narrow approved support for a specific context	Requires strict purpose, access, lifecycle, and audit controls
Full plan or record	The entire IEP, Section 504 plan, evaluation, or case file	Should not be the default AI context and requires a separate, compelling, reviewed basis

Universal design and ordinary accessibility settings often address the need without transmitting sensitive plan information to a model.

What a plan-derived support signal could look like

A plan-derived support signal is a narrow implementation instruction created through an authorized district process. It is not a diagnosis and should not expose the underlying record.

Examples that might be evaluated by a district team include:

allow text-to-speech for this activity;
present directions in numbered steps;
offer a district-approved language support option;
allow additional response time in a district-controlled assessment workflow;
provide an accessible alternative format already approved for the activity.

Each example still requires context. “Simplify everything” could change academic expectations. “Add more time” may not be meaningful in a tool without a timed workflow. The district must validate that the implementation matches the approved support and the instructional goal.

Eight design requirements

1. Human authority remains explicit

Identify which team or role authorizes the support, who configures it, who verifies delivery, and who can change or remove it. The AI provider is not the plan owner.

2. Purpose is narrow

State the exact task. “Personalize learning” is too broad. “Present teacher-approved directions in a numbered format during this assignment” is testable.

3. Data is minimized

Use a code or instruction that expresses the approved support without including diagnosis, evaluation history, unrelated goals, family information, or the full plan.

4. Source and freshness are trustworthy

The signal should come from an authoritative district system or approved human workflow. It needs an effective date, expiry or review date, and a way to handle changes promptly.

5. Access follows least privilege

Only the people and systems that need the signal for the approved purpose should receive it. A district-wide student profile is not an appropriate default source for every classroom or application.

6. Enforcement is surface-specific

An instruction that works in a district-built application may not work in a third-party chatbot. A display setting may apply to one product but not another. Document which interface, account, model, and workflow are supported.

7. The result is validated

Test whether the support appears, remains appropriate, preserves the learning goal, and works with assistive technology. Include student and educator feedback. Do not infer success merely because configuration was sent.

8. Failure is safe and visible

If the AI surface cannot apply the support, the workflow should not silently continue as though it did. Provide a known fallback and a way for the responsible educator or team to respond.

Privacy and authorization questions

Before any learner-specific AI workflow, document:

the responsible district team and approved educational purpose;
the authoritative source of the support;
the minimum data elements used;
the system and people allowed to access them;
the provider, account type, model deployment, and contract;
provider and district retention, logging, and deletion;
whether output can reveal or imply disability or support status;
required student or family notice and participation;
the FERPA basis and any other applicable federal, state, or local requirements as determined by the district;
the test plan, fallback, review cadence, and correction process.

FERPA’s school official exception can apply to an outside party only when the district determines the particular conditions are met. That includes criteria related to the institutional function, direct control, use and redisclosure, and legitimate educational interest. The label “school official” is not created by a vendor’s statement alone.

A worked example

Suppose an IEP team has determined that a student needs text-to-speech access for certain digital materials.

Weak design

The district copies the student’s full IEP into a general AI account and asks the model to remember all accommodations.

Problems include excessive disclosure, unclear provider terms, uncertain persistence, no reliable link to activity context, and no proof that text-to-speech is available or used.

Better design questions

Can the approved learning platform or device accessibility setting provide text-to-speech without any model access to plan data?
If AI-generated material is used, does the output format remain compatible with the approved accessibility tool?
Can an authorized district system pass only a narrow support code to the district-controlled workflow?
Who verifies the feature before the activity?
What alternative is available if the feature fails?
How will the team receive feedback and revise the implementation?

The most privacy-preserving solution may be an ordinary accessibility capability rather than learner data in model context.

Test the whole workflow

Evaluate more than model output:

sign-in and identity resolution;
correct support assignment and expiry;
behavior across classes and devices;
interface accessibility;
output compatibility with assistive technology;
changes to academic rigor or meaning;
accidental disclosure in text, history, exports, or shared links;
teacher visibility and control;
student understanding and agency;
fallback when the AI product, network, or support signal is unavailable.

Document results by supported surface. A successful test in one application does not prove that the same configuration works in another.

Questions for vendors

Which exact accessibility standards and assistive technologies have been tested?
Can the product provide the desired support without receiving plan or diagnosis data?
What learner-specific data is processed, logged, retained, or used to improve the service?
Can district administrators limit the feature to approved users, purposes, and contexts?
Can the district verify that the support was delivered without retaining the student’s full content?
How are plan changes, removal, export, and deletion handled?
What happens when the feature fails or the model cannot follow the instruction?
Which claims are supported today, in which account and configuration?

Product boundary

Tenet Edge currently applies district and classroom governance on supported direct-use AI surfaces. It should not be described as automatically reading IEPs, Section 504 plans, or delivering learner-specific accommodations. Any future capability in this area would need separate product, privacy, educational, accessibility, and legal review plus surface-specific validation.

Use the AI tool vetting template to evaluate an AI product, and the AI data-boundary framework to document any proposed learner-specific data flow.

Frequently asked questions

Can AI support a student’s accommodations?

AI may be part of an accessible instructional workflow, but a feature does not establish that an IEP or Section 504 plan has been implemented. The responsible district team must determine, deliver, and review each student’s services and supports.

Should a district copy a full IEP or Section 504 plan into an AI prompt?

That should not be the default. Start with the approved purpose and use the least amount of plan-derived information necessary, if any, under district privacy, legal, and educational review.

What is a plan-derived support signal?

It is a narrowly scoped instruction or code derived through an authorized district process, such as offering text-to-speech or chunking directions, without exposing the full plan or diagnosis to the AI service.

Can an AI vendor decide which accommodation a student needs?

A vendor tool should not replace the district’s legally responsible team or individualized decision process. Any automated suggestion must remain within a district-approved workflow with qualified human review.

Does Tenet currently provide learner-specific accommodation controls?

Tenet does not currently present learner-specific accommodation controls as a generally available product capability. This page describes the requirements a credible future design would need to meet.

Sources

This resource is educational information, not legal advice, special education guidance for an individual student, or a representation of a current learner-specific Tenet feature.