Most campus AI policies fail in one of two ways. The first is the ban: it reads well in a committee meeting and is ignored by lunchtime, because faculty, staff, and students are already using these tools and a policy nobody follows is worse than no policy. The second is the press release: two pages of principles ("we embrace innovation responsibly") that answer none of the questions people actually have. Can I paste student work into a chatbot? Can my office use AI to draft financial aid letters? Which tools has the university vetted?
A useful policy answers those questions. Here's a way to build one that does, drawn from the questions that come up again and again when universities try to put guardrails around these tools.
Decide what the document is for before you write it
"AI policy" usually means at least three different documents wearing one name:
- An acceptable use policy: what data may go into which tools, and who may use them for what. This is the institutional core, and it's the one this article is mostly about.
- Teaching guidance: what's allowed in coursework. This mostly belongs at the course level, inside a campus-wide frame.
- Research guidance: what funders, publishers, and the IRB expect. This is largely set by outside bodies; the campus document's job is to point at their rules.
Trying to force all three into one document produces something too long to read and too vague to apply. Write the core policy, then let teaching and research guidance hang off it as short, separately-owned companions.
Start from the policies you already have
The good news nobody tells committees: most of an AI policy already exists on your campus under other names. Data classification rules already say which information is public, internal, or restricted. FERPA and your privacy policies already limit what can be done with student records. Procurement and security review already govern how software gets adopted. Academic integrity policy already covers unauthorized assistance. An AI policy is mostly a mapping exercise: state clearly how each existing rule applies when the software in question is a generative AI tool. When you frame it that way, the committee argues about a handful of genuinely new questions instead of relitigating settled ones.
The core of the policy is a data question
Strip away the technology and the central issue is old and familiar: what information are you disclosing, and to whom? A consumer chatbot account is an external party. Pasting text into it is a disclosure, and the policy should treat it exactly the way it treats any other disclosure. The practical move is a simple grid: your existing data classification levels down one side, categories of tools across the top.
- Public data (published content, marketing copy): fine in most tools.
- Internal data (drafts, unpublished analyses, meeting notes): only in tools covered by an institutional contract that keeps the data out of training and inside agreed retention terms.
- Restricted data (student records, health information, personnel files, unpublished research data under agreement): only in systems that have passed security and privacy review for that data class, which for many campuses means institutionally hosted or private deployments, and often means not at all.
One grid like this answers eighty percent of the questions a help desk will ever get about AI, and it does so without naming a single product. That matters, because product names age in months. "Tools in category B" survives; "ChatGPT Enterprise" becomes stale the next time a vendor renames something.
A test worth applying to every clause: could a staff member read it and know what to do on Tuesday? "Use AI responsibly" fails that test. "Don't put student records into tools the university hasn't contracted for" passes.
Teaching: set the frame, not the syllabus
Course-level rules belong to instructors, because legitimate practice differs by discipline: a programming course and a first-year writing course can reasonably take opposite positions. What the campus-wide document should do is set the frame instructors work within. Require each syllabus to state its AI rules explicitly, so "the syllabus didn't say" stops being an argument. Offer two or three model syllabus statements instructors can adapt instead of drafting from scratch. And be honest about detection: automated AI-writing detectors produce false accusations at rates high enough that several institutions have stopped using them, and a policy that leans on them invites exactly the disputes it's meant to prevent. Assessment design and conversation with the student remain the reliable tools.
Research: point at the rules that already bind
Much of the research side is decided off campus, and the policy's job is to collect the pointers in one place. Federal agencies have restricted generative AI in grant peer review, and NIH reviewers may not use it in evaluating applications. Major publishers will not accept an AI system as an author and require disclosure of substantive AI use in manuscripts. If a project's data is covered by a consent form, a data use agreement, or an IRB protocol, those documents govern whether it can touch an external AI service at all, and the answer is often no. None of this is your committee's to decide; your document just needs to make sure no researcher can say they didn't know.
Give tools a path in, and name an owner
A policy that only says no teaches people to stop asking. Pair the rules with a route: a lightweight intake where a department can propose a tool and get a security, privacy, and accessibility review with a stated turnaround. Publish the list of tools that have passed, because an approved-tools page is the single most-visited artifact of any AI policy, and every tool on it drains demand away from unvetted alternatives.
Then give the whole thing an owner. A named office (not a committee that dissolves at year end) fields questions, tracks exceptions, and revises the document on a stated cycle. Date the policy, version it, and commit to revisiting it at least annually. In this area, an undated policy is indistinguishable from an abandoned one.
The mistakes that sink these documents
- Banning by default. Unenforceable, and it pushes use underground where no guardrails reach it.
- Writing to a product. Policies organized around named tools are outdated before the ink dries. Regulate data classes and tool categories.
- Principles without answers. If the document can't settle "may I paste this into that," it isn't a policy yet.
- Skipping the people who'll live with it. A draft that faculty, students, and staff never saw will be treated as an imposition, whatever it says. Circulate it, take the comments, and say what changed.
- No enforcement story. Say what happens when the policy is breached and which existing process handles it. Silence here reads as "optional."
Start with the grid
If your campus has nothing today, don't wait for the perfect document. Publish the data-classification grid and a first approved-tools list, name the office that answers questions, and state a date for version two. That single page changes behavior more than any framework document, because it's the page that tells people what to do on Tuesday.