It is 4:50 p.m. on a Thursday. The chief of staff is walking out of a cabinet meeting with a single line in her notebook, underlined twice: “Write our AI policy by the next cabinet meeting.” The provost wants something the deans can point to. General counsel wants something that survives a public-records request. The CIO wants something that does not break the four tools faculty are already using. The president wants one page. The next cabinet meeting is in three weeks.
She has read other institutions' AI policies. Most of them are beautiful and useless — a paragraph affirming a commitment to “responsible and ethical use,” a paragraph about “human-centered values,” a paragraph reserving the right to “evolve as the technology evolves.” Nobody in a department could read one of these and answer a concrete question: Can I put this student's draft IEP into ChatGPT to summarize it? The honest answer the policy gives is a shrug.
That is the failure mode. Most AI policies fail not because they are wrong but because they are unenforceable abstractions — they describe a posture instead of governing a decision. A charter that a campus actually uses does the opposite. It answers the questions people actually have, at the moment they have them, in language a department chair can apply without calling the general counsel. This piece is the template for that document: what goes in it, how to structure the parts that do the real work, and how to keep it alive after the memo ships.
The demand is not hypothetical. Tyton Partners' analysis of higher-ed trends shaping 2026 finds governance moving from optional to expected, with a large and rising share of institutions planning enterprise-wide AI policy inside a three-year window. Deloitte's 2026 higher education trends frame the same shift as a governance-and-trust problem first and a technology problem second. The institutions that wait for a model vendor to solve this for them will be governing by incident report.
What a usable charter actually contains
Strip away the throat-clearing and a charter that governs real decisions has six load-bearing parts. Everything else is preamble. If a section does not change what a specific person is allowed to do on a specific Tuesday, it is decoration.
Scope · who and what it governs
Faculty, staff, students, contractors; instructional use, administrative use, research use. Name what is out of scope explicitly so the gaps are deliberate, not accidental.
Ownership · the committee and the accountable office
A standing committee with a named chair and a single accountable office. A policy with no owner is a policy that drifts the day it ships.
Data classification · the tiers that gate everything
Public, internal, restricted — each tier tied to which tools may touch it. This is the section that answers the IEP question.
Approved-tool list · what is cleared, for what tier
A living list, not an appendix frozen in time. Each entry says which data tier it is cleared to handle and who approved it.
Procurement gate · what every new tool must clear
The diligence checklist a vendor must pass before it joins the approved list. The single most-skipped section, and the one that causes the most damage when skipped.
Review & sunset cadence · how it stays alive
A scheduled review date and an explicit sunset for the approved-tool list. A charter without a review date is a memo with a longer half-life.
Notice the shape of that ladder. The early rungs are organizational and cheap to write. The work — and the risk — climbs as you descend, concentrating in the two sections most policies handle with a single hand-wave: data classification and the procurement gate. Those are the two that this post spends the most time on, because they are the two that decide whether the charter governs anything at all.
Data classification that maps to real systems
The reason the IEP question has no answer in most policies is that most policies never connect a category of data to a category of tool. They say “handle sensitive data responsibly” and stop. A usable charter does the unglamorous thing: it defines a small number of data tiers and, for each tier, says which class of tool is permitted. Three tiers is almost always enough. More than four and the chair stops consulting it.
Two design choices make this table do work rather than decorate a PDF. First, the tiers are defined by example, not by adjective. “A draft IEP is restricted” settles the midnight question; “handle sensitive data appropriately” never does. A chair can match the document in front of them to a row and act. Second, the right-hand column names a class of tool, not a brand, so the table survives the approved-tool list changing underneath it. The classification is durable; the tool list is the part that churns.
The most common mistake here is over-engineering. Institutions reach for the five- or six-tier data-classification scheme their information security office already maintains and bolt AI onto it. The result is a matrix so granular that nobody consults it, which means everybody falls back to instinct, which means the policy governs nothing. Three tiers a department chair can hold in their head beats seven tiers that live in a binder.
Where the line actually gets crossed
The restricted tier is not violated by malice. It is violated by an associate pasting a draft IEP into a free chatbot to “clean up the language” at 11 p.m. because that was the fastest way to finish. The classification only holds if the approved-tool list offers a permitted path that is at least as fast as the prohibited one. A charter that forbids the easy path without funding an approved one is a charter that trains people to route around it.
Procurement and vendor diligence: the questions that matter
The procurement gate is where a charter earns its keep, and it is the section most institutions reduce to “tools must be approved by IT.” Approved against what? Without a standing diligence checklist, “approved” means “nobody objected yet.” The checklist below is the set of questions a vendor must answer in writing before a tool touches anything above the public tier. Treat a non-answer as a no.
Diligence 01 · Isolation
Is our data separated from every other customer's?
Ask specifically: shared multi-tenant database, or a dedicated instance per customer? “Logically separated” and “physically isolated” are different answers with different breach blast radii. Get it in writing.
Diligence 02 · Training & retention
Is our data ever used to train a model? How long is it retained?
The answer you need is “never used for training” and a named retention window. Push past the vendor's own policy to their sub-processors' — the model provider underneath them has its own terms, and those are the ones that bind your data.
Diligence 03 · Compliance documentation
What documentation can you produce, and what is in progress?
Ask for the HECVAT, the DPA, and the SOC 2 status by name. A vendor that distinguishes “completed” from “in progress” honestly is telling you more than one that claims everything is done. Precision is a trust signal.
Diligence 04 · Accessibility
Is there a current VPAT, and what does it actually say?
Section 508 is not optional for a public institution. Read the conformance level, not the cover page: “partially conformant” with a criteria count is a real answer; “fully accessible” with no document behind it is a red flag.
Diligence 05 · Human-in-the-loop
Does the tool ever act on its own, or only draft for a human?
For anything touching a student or a decision record, the answer that keeps you out of trouble is that every output is a draft a person reviews and approves. Autonomous action on restricted data is a category of risk a charter should foreclose, not manage.
Diligence 06 · Security posture
How is data encrypted, authenticated, and access-controlled?
Encryption at rest and in transit, the authentication model, and whether access is allowlist-controlled or open by default. Mundane questions; the ones that show up in the breach post-mortem.
The discipline here is the same one Stanford HAI's 2026 AI Index documents at the sector level: responsible-AI evaluation and governance practice are maturing faster than the policies meant to require them, which means the institutions doing diligence well are the ones writing their own questions rather than waiting for a standard to arrive. The checklist is not a compliance exercise. It is how a committee tells the difference between a vendor that has thought about these problems and one that is hoping nobody asks.
In Hone Studio
When the procurement section asks “what do we require of an AI vendor,” Hone Studio is built to be a worked example of the right answers, stated precisely. Per-client single-tenant isolation: every client gets their own database, their own infrastructure, and their own deployment, so your documents never touch another client's system. Your data is never used to train AI models — contractually guaranteed by every provider used, with zero data retention confirmed with Google and Perplexity. On the documentation row: HECVAT 4 completed, a DPA available on request, FERPA-designed safeguards, and a VPAT/ACR completed (46 of 50 WCAG 2.1 AA criteria fully supported; partially conformant) — with a SOC 2 path in progress, named honestly as in progress rather than as a finished certification. And every AI output is a draft a person reviews before it takes effect.
The mistake of writing rules nobody can follow
There is a temptation, once the procurement gate is sharp, to make the rest of the charter equally exhaustive — to enumerate every permitted use, every prohibited phrase, every workflow. Resist it. The institutions whose policies actually change behavior write fewer rules, not more, and put the specificity where the stakes are. A rule a chair cannot apply without a lawyer is a rule the chair will ignore, and an ignored rule erodes the credibility of the rules that matter.
The test for every clause is the one the chief of staff started with: could a department chair read this and answer a real question without escalating? If yes, keep it. If no, the clause belongs in a procedure document the committee maintains, not in the charter the cabinet adopts. The charter is the constitution; the approved-tool list and the procedures are the statutes. Conflating the two produces a document that is simultaneously too long to read and too vague to use.
Keeping it alive: review cadence and ownership
Every charter that fails fails the same way: it ships, it is celebrated at the cabinet meeting, and then the technology moves and the document does not. A model that was prohibited in March ships an enterprise tier with a no-training guarantee in June, and the policy still bans it because nobody owns the update. Six months later the approved-tool list is a museum, and the real governance has migrated back into hallway conversations and individual judgment — which is exactly the state the charter was written to replace.
Review cadence, concretely
Set three dates the day the charter is adopted, not the day someone remembers it has been a while. A quarterly review of the approved-tool list, owned by the accountable office. An annual review of the full charter, owned by the committee chair. And a standing intake path — one form, one inbox — so a faculty member who wants a new tool triggers a diligence review instead of quietly using it anyway. The cadence is the difference between a living system and a document with a longer half-life.
Ownership is the other half. A charter with no named accountable office is a charter that drifts the day it ships, because “the committee” is not a person and a committee cannot be paged. Name an office that owns the approved-tool list, name a chair who owns the annual review, and write both names into the document. Currency is not a property a policy has; it is a job somebody does.
This is also where the charter and the institution's memory intersect. The diligence answers, the committee's reasoning, the record of why a particular tool was approved for the internal tier but not the restricted one — that institutional reasoning is precisely the kind of knowledge that normally walks out the door when the chief of staff takes the provost job at another institution. The charter that survives a transition is the one whose rationale is captured, not just its conclusions.
In Hone Studio
The same property that makes a charter survive a transition is the one the platform is built to provide. In the Knowledge Base, the adopted charter, the diligence files, and the committee's decision records become retrievable, citable source material — so when the next chief of staff asks “why did we approve this tool for internal but not restricted data,” the Assistant can ground the answer in the committee's own minutes with inline citations rather than reconstruct it from memory. Memory captures the tacit layer underneath the minutes — which arguments carried, which vendor claims the committee learned to distrust. Citations here are assistive: they trace the answer back to the institution's own record so a human can verify it fast, not a guarantee that the record itself was right.
The charter is a system, not a memo
The chief of staff will ship something at the next cabinet meeting. The question is whether she ships a one-page affirmation of values that wins the room and governs nothing, or a six-part charter that a department chair can actually apply at 11 p.m. with a draft IEP open in another tab. The first is easier to write and impossible to use. The second is harder to write and is the only one that survives contact with a real Tuesday.
The inversion to hold onto is this: a good AI charter is not a document you finish. It is a system you run. The scope and the values are the easy, static parts — written once, rarely touched. The parts that do the work are the parts that move: the data tiers as new categories of risk appear, the approved-tool list as the market churns, the diligence answers as vendors mature. An institution that treats its charter as a memo will be governing by incident report inside a year. An institution that treats it as a living system — owned, reviewed on a calendar, with its reasoning captured rather than reconstructed — builds something that compounds the same way the rest of its institutional memory should. The policy that lasts is the one the institution remembers why it wrote.