The default way schools adopt AI is to send student work to a vendor's cloud. That choice creates three problems at once, and all three land hardest on the schools with the least money.First, student data leaves the building. Minors' writing, questions, and mistakes travel to a third party under terms a teacher rarely reads. Second, the bill scales with use, so the more students benefit, the more it costs, which pushes schools to ration access. Third, it requires reliable internet, which many schools do not have in every classroom.There is a design that removes all three. Run a small open model locally, on hardware the school owns, sandboxed from the internet. I research offline and sandboxed LLMs for secure academic computing, and the architecture that protects sensitive research transfers cleanly to a school lab. The constraints are nearly identical: keep the data in, keep the cost flat, keep it working when the network does not.What "offline and sandboxed" means hereOffline means the model runs on a local machine and does not call an external API to generate a response. The weights sit on a disk in the building.Sandboxed means the model process is isolated. It reads the prompt, returns an answer, and has no path to send data out. A student can use it with no account, no login, and no data trail left behind.This is possible in 2026 because open models small enough to run on modest hardware have become genuinely useful. A model in the few-billion-parameter range runs on a single workstation with a consumer GPU, or even on CPU for lighter tasks, and handles the work a school actually needs: explaining a concept, checking writing, answering questions about a text, helping debug a first program.The privacy caseThis is the one that should move a district first. With a local model, there is no question to answer about where student data goes, because it does not go anywhere. A 14-year-old's half-formed essay never leaves the lab.Compliance gets simpler too. The hardest part of student-data rules is tracking what a vendor does with the data after it arrives. Remove the vendor from the path, and most of that burden disappears. The data remains under the school's control, governed by its own policy.I take this seriously in my own research because the academic data I work with cannot be stored in a third-party cloud. The same reasoning applies, with more force, to data from minors.The cost caseCloud AI has a per-use bill that never ends. Even at the low 2026 prices, a class of 30 students running dozens of prompts a day adds up over the course of a school year, and it grows with usage. The economics punish success.A local model inverts that. The school buys or repurposes one capable workstation, sets it up once, and the marginal cost of each additional prompt is electricity. A lab that serves 30 students costs about as much to run as one that serves 5. There is no metering, no overage, no quarterly surprise.For a school choosing between paying a vendor every month forever and buying one machine once, the multi-year math favors the machine, and it favors it more the more the tool gets used. That is the opposite of the cloud incentive, and for a budget-constrained school it is the point.The reliability caseA cloud tool is only available when the internet is. In many schools, classroom connectivity is inconsistent, and a lesson that depends on a live API fails on days when the network does.A local model has no such dependency. It works in a basement lab with no signal. It works during an outage. It works on a field trip with a laptop, even without a connection. For teachers, that reliability is the difference between a tool they can plan a lesson around and one they cannot trust to be there.How to start smallA district does not need to commit to a full rollout to test this. A realistic first step:Take one capable workstation. A single machine with a recent consumer GPU is enough to start.Install a local inference runtime. Several mature open-source options run a model with a simple local interface and no external calls.Load one small open model that fits the hardware. Start with a general-purpose model in the few-billion-parameter range.Disconnect or firewall the machine so the model cannot reach the internet. This is the sandbox.Give one class access for one unit. Measure what students do with it, what works, and what the model cannot handle.From there a district can decide whether to add machines, try a larger model, or fine-tune on its own curriculum, all without changing the privacy or cost properties that made the approach worth trying.Where the limits areI will name the tradeoffs, because a claim with no tradeoffs is a sales pitch. A small local model is less capable than a frontier cloud model on the hardest tasks. It will be slower on a weak machine. Someone in the building has to set it up and maintain it, which is real work for a school with no IT staff to spare.None of those limits outweigh the three problems the approach removes for routine classroom use. For explaining, checking, and tutoring, a small local model is good enough today, and good enough that does not leak student data, does not bill by the prompt, and does not need the internet is the better tool for most schools.The schools that adopt AI well in the coming years will not be the ones with the largest cloud contracts. They will be the ones that kept student data in the building, kept the cost flat, and kept the tool working when the network went down. A model on a local machine does all three, and a district can prove it to itself with one workstation and one class.