Schools should evaluate AI in the context of a specific instructional or operational job. The U.S. Department of Education’s current responsible-technology guidance emphasizes educator leadership, educational value, transparency, accessibility, ethics, and protection of student data. NIST’s voluntary AI Risk Management Framework organizes ongoing risk work around four functions: Govern, Map, Measure, and Manage.
The steps below translate those ideas into a practical starting sequence for a school or district team. They are not legal advice and do not replace applicable law, policy, procurement, accessibility, security, or student-privacy review.
1. Choose one bounded purpose
Start with a recurring problem that people can describe and evaluate. Examples might include drafting standards-aligned lesson materials, turning approved notes into a family update, preparing a first draft of an internal staff summary, or organizing a coach’s practice plan.
Write a one-sentence purpose statement:
We are testing whether [defined users] can use [approved AI capability] to improve [specific workflow] while preserving [quality, privacy, access, and review requirements].
Avoid beginning with an undefined mandate to “use AI.” A bounded purpose gives the team something concrete to approve, configure, support, and measure.
2. Assign operational and instructional ownership
Name the people accountable for the pilot before selecting participants. A workable ownership map usually includes:
- Instructional or operational owner: defines what a good result looks like.
- Technology and security owner: evaluates identity, configuration, logging, integrations, and incident handling.
- Privacy or data-governance owner: determines permitted data and required agreements or review.
- Accessibility owner: evaluates whether the workflow and outputs are usable by the people who need them.
- Pilot lead: coordinates training, feedback, questions, and the decision record.
- Executive sponsor: owns the final decision and resources.
Document how users report an incorrect output, inappropriate result, access problem, privacy concern, or suspected security event—and who must respond.
3. Set data and access boundaries before use
Define what participants may enter, what they must not enter, where outputs may be saved, how long data is retained, and which connected systems—if any—are authorized. Do not treat a successful login or provider connection as blanket permission to use institutional or student data.
Questions for the use case
What is the minimum data needed? Can the workflow use fictional, public, aggregated, or de-identified inputs during the pilot? Does the task involve an education record or another protected data category?
Questions for the system
How are accounts provisioned? Which roles can access the capability? What is logged? Where are files delivered? How are access and stored artifacts removed?
Translate the answers into plain-language participant rules. If the team cannot state those rules clearly, the pilot is not ready to start.
4. Define what a person must review
Assign review based on the consequences of the output. An educator drafting a lesson should review alignment, accuracy, accessibility, timing, and suitability. A staff member drafting family communication should verify names, dates, tone, translation quality, and whether the message follows policy. Higher-impact decisions require stronger controls and may be inappropriate for generative AI assistance.
- Identify outputs that must never be sent or published automatically.
- State who is qualified to approve the result.
- Provide a short review rubric for the selected workflow.
- Require users to verify facts, citations, calculations, and policy statements.
- Make escalation easy when an output creates uncertainty or risk.
5. Design a small, representative pilot
Choose enough participants to expose real variation without turning the pilot into an uncontrolled launch. Include the roles that perform the work, the support people who will receive questions, and—when appropriate—the communities affected by the workflow.
Before the pilot begins, capture a simple baseline: how the work is currently completed, how long it takes, what quality problems recur, what tools and handoffs are involved, and what users find difficult. Then provide:
- A purpose statement and permitted-use boundary
- Examples based on the real workflow
- A review checklist and an escalation path
- A short practice session using safe inputs
- A way to record both helpful and harmful or unusable results
A pilot should be long enough to repeat the workflow more than once. One impressive demonstration does not show whether a system is reliable, supportable, or worth adopting.
6. Measure the work, not just tool activity
Login counts and prompt counts show activity. They do not show value. Select a small set of measures tied to the purpose statement.
Quality
Rubric score, accuracy corrections, completeness, accessibility, or approval rate after review.
Efficiency
Time to an acceptable draft, number of handoffs, repeated work avoided, or time spent correcting output.
Experience and risk
User confidence, support needs, blocked tasks, inappropriate outputs, privacy concerns, and unresolved accessibility barriers.
Record where the system fails as carefully as where it helps. A result that saves drafting time but adds greater verification burden may not improve the workflow.
7. Make an explicit next decision
At the end of the pilot, choose one of four paths: stop, revise and test again, continue at the same scope, or expand with additional controls and support. Document why.
Expansion should trigger a fresh review when the user group, data, connected systems, student exposure, intended decision, or consequences change. Risk management continues throughout the system lifecycle; approval of one bounded workflow is not approval of every possible use.
Primary resources for school teams
- U.S. Department of Education: Responsible Use of Education Technology in the Classroom — current principles and questions for evaluating educational technology.
- U.S. Department of Education Office of Educational Technology: Empowering Education Leaders — a toolkit for safe, ethical, and equitable AI integration.
- NIST AI Risk Management Framework — a voluntary framework for incorporating trustworthiness considerations into AI design, use, and evaluation.
- NIST AI RMF Playbook — suggested actions organized around Govern, Map, Measure, and Manage.
Map the guide to Faraday AI
Faraday AI organizes Jasper around purpose-built education workspaces, role- and account-shaped access, editable artifacts, and educator review. Explore Faraday AI for schools, review the security and student data privacy approach, or request a workflow walkthrough.