Every District Is Racing to Write an AI Policy. Almost None Have a Way to Vet the Tools.

Ohio gave every public school district a July 1 deadline to adopt a formal AI policy. Maryland districts are staring down a deadline this fall. California released a model policy in June. If you run a school or a district office, you already know the pressure: get something in writing before the school year starts, or explain to the board why you have not.

Here is what almost none of those policies include: a free AI tools vetting process. The policy names FERPA. It names academic honesty. It says AI will be used “responsibly.” Then a fifth-grade teacher finds a free lesson-planning tool over the summer, signs up with her school email, and starts feeding it student work samples in August, three weeks before anyone in the district office knows the tool exists. The policy was never the problem. The absence of a process for the next tool request is.

Why Are Districts Writing Policies Without a Way to Vet Tools?

Because a policy is a document, and a vetting process is a workflow, and workflows are harder to write under deadline pressure. A policy can be adapted from a state model in an afternoon. A working intake process, the kind that actually catches a risky tool before a classroom is using it, takes someone deciding who says yes, how fast, and on what evidence. That decision keeps getting deferred past the policy deadline because the deadline was never really about the tools. It was about having a document on file.

Meanwhile the actual tools keep arriving. Free AI products are the easiest thing in a teacher’s or a coordinator’s day to adopt, because nobody has to ask permission to try something with no invoice attached. That is exactly why free tools carry the most risk, not the least. A paid enterprise contract goes through procurement, and procurement asks about data. A free sign-up goes through nobody.

What Does a Real Vetting Process Need to Check?

Not everything a legal team could theoretically ask. Five questions, answered honestly, catch most of the risk:

• Does it train its models on the data you put in? Many free consumer tools do, by default, unless you find and flip a setting almost no one finds.
• Does student or staff data leave the tool at all, and where does it go? If the answer is unclear from the privacy policy in under five minutes, that is itself the answer.
• Is there a school or education-specific account tier, or is this a consumer product a teacher signed up for with a personal or district email?
• Does the tool require a human to review output before it reaches a student or a family? Some tools generate feedback or communications directly. That is a different risk than a drafting tool a teacher edits.
• Who else in the building is already using it? If three teachers found the same free tool independently this semester, that is not an edge case. That is the next item on your vetting list, whether you asked for it or not.

Answer those five for a tool in fifteen minutes, not a fifteen-page compliance review. The goal is a fast, honest check, not a legal opinion on every login page in the building.

Who Should Actually Own This Decision?

Not a committee that meets once a quarter. By the time a quarterly committee reviews a tool, forty teachers have already used it for a semester. Ownership needs to be small and fast: one person from operations or the business office, one from IT, and one working teacher or department lead who will actually use the tool. Three people, a shared form, and a turnaround measured in days.

The business office matters here more than districts usually expect. The office already tracks every vendor relationship and every data-sharing agreement the district holds. A vetting process is not a new discipline for that office. It is the same discipline, applied to tools that arrived without a purchase order.

What Does the Actual Workflow Look Like?

A vetting process that survives contact with a real school year is short enough that people actually use it.

1. One intake form. A single link, a QR code on a staff room wall, anywhere staff already look. Name of the tool, what it is for, who found it. Under two minutes to fill out.
2. The five-question check, done by the small team above, logged the same day the form comes in. Not perfect, just fast and consistent.
3. A published answer list. Approved, approved with conditions, or not approved, visible to every staff member, not buried in an email only the requester saw. This is the step most districts skip, and it is the one that stops the same tool from getting requested five separate times.
4. A short review cadence, monthly is enough, to recheck anything approved under a tool’s older terms of service. Free products change their data policies more often than paid ones, quietly, in a settings page nobody rereads.
5. One visible owner, named in the policy itself, so a teacher with a tool in hand knows exactly where to send the form instead of guessing.

None of this requires new software or a new budget line. It requires someone deciding, on paper, who says yes and how fast, before the next free tool shows up in a teacher’s inbox.

The Part the Policy Document Never Shows

This is the invisible layer under every AI policy a district writes this year: the actual list of tools already running in classrooms, decided one sign-up at a time by people who never saw the policy and were never asked to. Making that layer visible, an honest, current list of what staff are actually using and why, does more for a district’s real risk posture than another paragraph of policy language ever will.

A policy on file protects a district on paper. A working vetting process protects the students and staff actually using the tools, this week, not just at the next board meeting. Districts that get this right treat the vetting workflow as the real policy and the document as its cover page, not the other way around.

If your district has a policy and no process, or a process that lives in one person’s head, The Spotlight Machine’s training builds a working AI vetting workflow with the people who will actually run it, not just another document to file.