AI Tool Vetting and Approval Template for K-12 Schools

Current status: This template supports district review and is not a legal or compliance determination.

A K-12 AI tool review should approve a defined use and deployment, not merely a vendor name. Record the educational or operational purpose, eligible users, exact product and account type, data flow, model deployment, privacy and security terms, accessibility, human oversight, evidence, conditions, owner, and review date. A tool that is appropriate for generic staff drafting may not be appropriate for student use or education records.

Download the AI tool vetting CSV template

How to use this template

Assign an accountable district owner before review begins.
Describe one use case in plain language. Split materially different uses into separate records.
Collect provider evidence and test the configured product with non-sensitive scenarios.
Route the record to the reviewers required by district policy.
State the decision, conditions, expiry date, and material-change triggers.
Publish the appropriate result to staff, educators, students, and families.

The visible framework below matches the downloadable CSV. A district can add state-law, board-policy, collective-bargaining, records-management, or procurement fields without losing the core structure.

Part 1: define the use before reviewing the tool

Field	What to record	Why it matters
Use case name	A short, specific name	Keeps the decision tied to a bounded use
Accountable owner	District role and department	Makes renewal, incidents, and retirement actionable
Educational or operational purpose	The outcome and intended benefit	Prevents approval for undefined future uses
Eligible users	Grades, roles, schools, or departments	Terms and risks can differ by age and role
Prohibited uses	Tasks the approval does not cover	Makes boundaries visible to users
Scale and duration	Pilot or production, user count, start and end dates	Sets the evidence and review level
Human responsibility	Who reviews output and who makes decisions	Prevents delegation of accountability to the model

A useful purpose statement

Middle-school science teachers may use the district-managed account to draft question variants from teacher-authored, non-student source material. A teacher must review every item before students see it. The approval does not cover grading, student profiling, or the submission of education records.

That statement is easier to govern than “teachers may use AI.”

Part 2: identify the exact deployment

Record the product as it will actually be used:

vendor and product name;
consumer, education, enterprise, or API account type;
identity and single sign-on configuration;
administrative console and role controls;
model or model family, if selectable;
region or processing location, if relevant;
training-use, retention, history, and sharing settings;
plug-ins, connectors, retrieval sources, and enabled tools;
district contract and data protection agreement;
current terms, privacy notice, subprocessors, and security documentation.

Do not assume a provider’s marketing page describes the configured district deployment. Capture links or dated copies of the documents that control the actual account.

Part 3: map the data flow

For each stage, state what data is involved and who can access it.

Stage	Questions
Input	What may users type, paste, upload, record, or connect?
Context	Does the product add account data, conversation history, retrieved documents, or system instructions?
Provider processing	Which provider and subprocessors process the request, and in which configuration?
Output	What does the model return, and where can that output be copied or stored?
Logs and analytics	What content and metadata are retained by the provider, district, or another service?
Training and improvement	Can data be used to train or improve models or services, and which setting or term controls that use?
Deletion and export	Can the district delete, export, place a hold on, or return data when needed?

Classify the data at field or document level when possible. “Student data” is too broad for a meaningful decision. Use the K-12 AI data-boundary framework for a deeper review.

Part 4: evaluate privacy and legal conditions

Ask district legal and privacy reviewers to document the legal basis and contract requirements for the specific use. Relevant questions can include:

Does the use involve personally identifiable information from education records?
If the district relies on FERPA’s school official exception, has it determined that the specific arrangement satisfies the required conditions, including direct control and legitimate educational interest?
If users include children under 13, what COPPA role and authorization model applies to the specific collection and educational context?
Which state student-privacy, biometric, records, public-records, and breach-notification rules apply?
Does the contract limit use, redisclosure, retention, training, advertising, profiling, and sale as required by district policy and law?
Are parent, eligible-student, employee, or community notices required?
Who handles access, correction, deletion, complaint, and incident requests?

The FTC amended the COPPA Rule in 2025. Use current official materials and qualified counsel instead of copying a stale checklist from another district.

Part 5: test quality and safety in context

Test the configured product against the district’s intended use. Include:

factual accuracy and source behavior;
uncertainty and fabricated content;
age-appropriate response behavior;
harmful, sexual, violent, bullying, and illicit-content scenarios appropriate to the use;
crisis-resource behavior and escalation boundaries;
bias and disparate-impact scenarios relevant to the educational context;
instruction-manipulation and data-exposure scenarios;
performance across languages and reading levels in scope;
behavior when a user asks the model to act outside the approved purpose;
administrator controls, reporting, and disable procedures.

Record test cases, dates, configuration, reviewer, and results. A provider benchmark is useful evidence, but it does not replace local evaluation of the intended use.

Part 6: review accessibility and student support

Evaluate the actual interface and workflow, including keyboard use, screen-reader support, captions, color contrast, cognitive load, language access, and compatibility with district assistive technology. Determine whether an AI-dependent assignment creates a barrier for students who cannot or should not use the product.

Do not treat an AI feature as proof that an IEP or Section 504 plan has been implemented. Individualized educational decisions remain with the responsible district team. See AI, accommodations, and student privacy for a planning framework.

Part 7: evaluate security and operations

Collect evidence appropriate to risk and scale:

authentication, single sign-on, multifactor support, and role design;
encryption and key-management descriptions;
tenant separation and administrative access;
vulnerability management and independent assessment reports;
incident response and district notification terms;
backup, continuity, recovery, and service-dependency information;
audit logs and access to district-relevant evidence;
data export, deletion, portability, and contract termination procedures;
a district-tested disable, credential-revocation, or access-removal process.

Independent certifications can support a review. They do not determine whether the educational use, data flow, or contract fits district policy.

Part 8: make a documented decision

Use clear statuses:

Status	Meaning
Intake	Owner and use have been identified; evidence collection has not begun
Under review	Required reviewers are evaluating the record
Pilot	Time-bounded, limited-scope use with defined success and stop criteria
Approved	Use is allowed within the documented scope
Approved with conditions	Use is allowed only if listed controls remain in place
Denied	Use is not authorized; reason and reconsideration path are recorded
Suspended	Approval is temporarily unavailable pending review or remediation
Retired	Use has ended and exit obligations have been completed

An approval record should include:

decision and date;
approving roles;
conditions and prohibited uses;
eligible users and deployment;
data boundary;
training and communication requirements;
evidence and open risks;
expiry and next review date;
material-change triggers;
owner for renewal, incident response, and retirement.

Minimum evidence request

Request these items before a medium- or high-risk review:

Product terms and privacy notice for the exact account type.
Data protection agreement and relevant contract language.
Data-flow and subprocessor information.
Retention, deletion, training-use, and advertising practices.
Security documentation appropriate to the risk.
Accessibility conformance information and known limitations.
Administrative control and identity documentation.
Model or AI feature documentation, known limitations, and change process.
Incident and customer-notification procedure.
Export, termination, and deletion procedure.

Material changes that require review

Reopen the decision when the provider, district, or use changes any of the following:

purpose, user group, or scale;
source system, data fields, or document collections;
provider, account type, model, region, or route;
retention, training use, sharing, or advertising terms;
enabled connector, tool, or action capability;
human-review requirement;
contract or subprocessor list;
observed quality, safety, accessibility, privacy, or security performance.

Frequently asked questions

What should a school district review before approving an AI tool?

Review the defined purpose, eligible users, data flow, provider and account configuration, model behavior, privacy terms, security, accessibility, human oversight, evidence, contract, exit plan, and review date.

Can a district approve an AI vendor once for every use?

A vendor-level review is useful, but approval should attach to a specific product, account type, deployment, user group, purpose, data boundary, and configuration.

Should a free consumer AI account be treated like a district-contracted account?

No. Account terms, retention, training use, administrative controls, age eligibility, and support can differ. Record the exact account and deployment being reviewed.

What approval statuses should a district use?

A practical set is intake, under review, approved, approved with conditions, pilot, denied, suspended, and retired. Every nonfinal status should have an owner and next review date.

Does completing the template establish legal compliance?

No. The template organizes evidence and decisions. District legal and privacy leaders must evaluate the specific facts and applicable federal, state, and local requirements.

Sources

This template is educational information, not legal advice or a compliance certification.