There is a meeting happening in school districts and companies all over the country right now, and I want to start there because it is the clearest way I know to explain the problem this series exists to solve.

A superintendent, or a VP of operations, or a director of curriculum sits down with a vendor. The vendor has a polished demo. It answers questions instantly, in a confident, articulate voice, on any topic anyone in the room can think to ask about. Everyone in the room is impressed, because it is genuinely impressive. A contract gets signed. Six months later, the usage numbers are disappointing, a parent or a board member has asked an uncomfortable question about where student data is going, and the tool that felt universal in the demo feels, in practice, like it was built for someone else's students and someone else's staff.

I have sat in some version of that meeting more than once, on both sides of the table. What I want to walk through is not that AI is bad. I have spent the better part of two decades building STEM and technology programs, and the last several years of that work specifically on AI-native platforms for education. The claim I actually want to make is the opposite one: the tool in that demo is not wrong, it is generic, and generic is the wrong shape for an institution. Understanding exactly why is the foundation the rest of this series is built on.

The tool answers the average person, and almost nobody in your building is average

A general-purpose AI assistant has to work reasonably well for everyone who might use it: a college student, a retiree, a software engineer, a fourth grader, a first-year teacher, a twenty-year veteran. To do that, it is trained and tuned against something like a population average. Average vocabulary, average background knowledge, average pace, average context.

That is a defensible engineering choice for a consumer product. Inside an institution it becomes a structural liability, because an institution's whole job is to serve people who are not average, in specific and knowable ways.

The student behind
A tool calibrated to grade-level pacing reads a student who needs more time as struggling with the material, when the delay may be language, processing, or simply working carefully.
The employee ahead
A new-hire training assistant tuned to the median employee wastes the time of your most capable staff, who disengage from tools that explain what they already know.
The English learner
Extra time spent processing language before content gets read by a generic tool as struggling with the subject itself, for as long as the person is developing fluency, in every session, silently.
The institution's own standards
A general model trained on the open internet has no idea what your accreditation body, your curriculum framework, or your compliance obligations actually require. It answers plausibly. Plausible is not the same as correct for you.

None of this arrives as an opinion about any particular person. It arrives as a default setting nobody in the room chose, baked into a system nobody in the room can see inside of. That is the first problem with the off-the-shelf purchase. It optimizes for a person who does not exist in your building, and it does this consistently, invisibly, for every person who is not that average, which in practice is most of them.

Your most sensitive data is the product's training exhaust

The second problem is less about pedagogy and more about where information goes once someone starts typing it into a box.

A general consumer AI product is, commercially, built to learn from what is typed into it. That is often disclosed somewhere in a terms-of-service document nobody in the building has read in full, and it is frequently true regardless. Student work, disciplinary records typed in for a summary, an employee's performance review draft, a family's confidential situation described to get help writing a letter: all of it can pass through a third party's servers, sometimes contributing to a model that other customers, elsewhere, will eventually query.

The question every institution should be able to answer
If a board member or a parent asked, in a public meeting, "where does the data our staff type into this tool actually go, and who else can it reach?", could your current AI vendor answer in one plain sentence? If the honest answer is "we're not entirely sure" or "it depends on the settings," that is not a technicality. That is the whole problem this series exists to solve.

This is not a hypothetical risk category. It is the daily operating reality of any tool built on a shared, general-purpose model that your institution does not control and cannot fully audit. A school district handling minors' data, a healthcare-adjacent nonprofit, a company with proprietary process documentation are all, functionally, trusting a stranger's infrastructure with information they have a legal and ethical obligation to protect. Most of the people signing those contracts were never given infrastructure to compare it against, because nobody showed them what the alternative actually looks like. That is what Article 02 in this series is for.

The tool doesn't know who you are, and it never learns

The third problem is the quietest one, and it is the one that shows up as disengagement rather than as an incident report.

A general-purpose AI assistant has no institutional memory of your organization. It does not know your school's mission, your district's graduation requirements, your company's product line, your specific compliance framework, or the particular way your team talks about the work it does. Every conversation starts from zero, generically, and any "customization" is usually a prompt bolted on top: a thin coat of paint over an engine that was never built with your institution in mind.

What generic feels like

Correct-sounding answers that could have come from any school, any company, anywhere. Technically usable. Culturally weightless. Staff use it the way they'd use a search engine, then stop, because it never felt like it belonged to them.

What institution-owned feels like

A system trained on your standards, your curriculum, your policies, your voice, that gets better the longer your people use it, because what it learns stays inside your walls instead of evaporating into someone else's general model.

Independent research on AI adoption in K-12 settings has begun to document a version of this pattern directly. Tools used entirely on their own, without embedding into an institution's actual structure and identity, show a sharp drop-off in sustained engagement, a pattern researchers have started calling the "engagement cliff." The tool does not fail loudly. It just stops feeling relevant, and people quietly go back to what they were doing before.

What this sets up

I am not writing this series to tell you AI is a mistake for your institution. I have built my career on the opposite belief, that AI-native tools, built correctly, are one of the more significant opportunities education and workforce development have had in a generation. What I am telling you is that the fastest purchase is rarely the right one, and that the three problems above, the average-person bias, the data-residency risk, and the cultural blankness, are not flaws you tune away with better prompts. They are consequences of the architecture underneath the product, decided long before anyone in your building typed a word into it.

That architecture can be built differently. It has to be decentralized by design: isolated per institution, resilient without depending on any single outside vendor's uptime, and capable of actually learning who your people are rather than assuming they are the average of everyone. That is not a marketing claim. It is a specific set of engineering decisions, and what comes next in this series walks through exactly what those decisions are and why each one matters to you as the person who has to sign the contract.

Next in this series: 02 · The Architecture of a Decentralized AI Platform, what "decentralized" means as an engineering decision, and the questions it lets you finally ask a vendor.

David Laurenvil is the Principal Consultant of Laurenvil Enterprises. He has spent nearly twenty years in business and STEM education leadership, including as Director of Education at the Fleet Science Center in San Diego, CA, and Executive Director of Kids MakeIt Institute. He designs and builds AI-native educational platforms and decentralized AI infrastructure for schools, districts, and organizations.