AI Project Intake in Higher Education: Where To Start
- David Holstein
- 2 days ago
- 8 min read
TLDR: AI project intake in higher education is the missing piece on most campuses right now. Every unit has an idea, the ideas arrive through whatever channel the requester has access to, and the institution has no queue to put them in. The reflex is either to approve everything and govern later, or to freeze everything behind an AI policy that is still being drafted. Both produce the same outcome, which is ungoverned pilots that surface at renewal. The alternative is a short intake, a two-question risk tier, and a three-level gate, then sequencing the approved work by what each use case actually depends on rather than by one institutional readiness score. This piece covers what to capture, how to tier it, and what a declined request should receive instead.
Every Unit Has an Idea and There Is No Queue
Advancement wants an agent that drafts donor correspondence. The registrar wants something that answers the same forty questions every August. A dean has a vendor demo scheduled for a tool that reads accommodation letters. Research computing already built something and did not tell anyone, because it works.
The requests are good. That is what makes this hard. If they were bad ideas the answer would be easy.
What most institutions lack is not an AI strategy. It is a place to put the requests. Ideas arrive at a cabinet meeting, in a budget line item, through a vendor who went around IT entirely, and in a hallway. Some become commitments before central IT hears about them. Others sit unanswered long enough that the unit buys something on a departmental card, and the institution inherits an AI system it never evaluated.
EDUCAUSE named a version of this in its 2026 Top 10, framing the human edge of AI as helping people across the institution engage with these tools critically and safely, and noting that AI capability is landing with individuals rather than staying an institutional decision. The 2025 EDUCAUSE AI Landscape Study found teaching and learning to be the functional area most focused on AI adoption. Both point the same direction. The demand is distributed. The governance usually is not.
Saying No Is Not a Strategy, and Neither Is Saying Yes
Two responses show up repeatedly, and they fail in opposite directions.
The first is the freeze. Nothing moves until the AI policy is finished and the committee is seated. This feels responsible, and what it does is push work off the books, because demand does not pause while a policy is drafted. Six months later the institution finds three live agents it never evaluated, and the governance program begins its life in an enforcement posture.
The second is the open door. Everything gets approved, pilots multiply, and each one carries its own data path and vendor relationship. That is the pattern behind the consolidation problem we wrote about in one platform versus five point solutions. Governing after the fact means auditing systems that already touch student data.
Speed and governance are not a tradeoff on a campus. Institutions that move quickly innovate first. Institutions that pair that speed with governance from the start are the ones that scale and hold the trust of the people they serve. Intake is where those two things meet, and it is the cheapest place to put them together.
What AI Project Intake in Higher Education Has to Capture
Intake has to be short enough that a busy person uses it. If it demands a business case, a data classification, and a security review before a request can exist, the request will not exist in the system. It will still happen.
Five lines is enough to route anything.
Requester and unit. Who is asking and on whose behalf. This is also how you spot the fourth request this month from one college, which usually signals a process problem rather than an AI problem.
The outcome asked for. Not the tool, but what should be different when this works. A request for a chatbot is a solution. A request to stop answering the same registration question four hundred times in August is an outcome, and it may not need an agent at all.
The data it would touch. Described in plain language by the requester and classified later by someone in IT. Asking a department administrator to determine FERPA applicability at intake is asking for a wrong answer.
Who is accountable for what it produces. Not who builds it, but who owns the output when it is wrong. Every agent needs a named human, and a request that cannot name one has told you something useful before any review happens.
What it replaces. A manual step, a vendor contract, a queue. This is the field that makes the outcome measurable later, and the one most requests leave blank on the first pass.
The Risk Tier Is Two Questions
Elaborate risk matrices do not survive contact with a real queue. Two questions do most of the sorting.
Does it touch protected data? Student records, health information, HR records, research data under a sponsor agreement, anything covered by a state privacy statute. Yes or no.
Can it act, or can it only answer? An agent that drafts a response for a human to send is a fundamentally different risk than an agent that updates a record, sends the message, or approves something. The distinction between advisory and agentic is the one that matters most, and it is the one institutions collapse most often.
Those two answers produce three gate levels. Advisory work on non-protected data builds and gets monitored. Anything that acts, or touches protected data, gets reviewed before it builds. Anything that does both goes to the governance body. The virtue of a model this small is that a request can be tiered in the meeting where it is raised rather than waiting for a committee cycle.
Approved work then needs somewhere to be registered, monitored, and reported on, which is the role AI Control Tower plays for higher education, with the policy scaffolding covered in our practical AI governance framework for Now Assist. Intake is the front of that system. Without it, Control Tower inventories whatever happened to get built.
Sequence by Data Dependency, Not by a Readiness Score
Once requests are in a queue and tiered, the question becomes what to build first. The common approach is an institutional AI readiness assessment that produces a score, and the score says the institution is not ready.
That answer is not useful, because readiness is not an institutional property. It is a property of each use case.
An agent that closes knowledge gaps depends on curated, current articles and very little else. An agent that handles employee lifecycle events depends on clean HR and identity data. An agent that calls service impact depends on CMDB accuracy and service mapping, a much heavier dependency and the reason that use case usually comes later.
Three use cases, three different readiness answers, same institution, same day. A single score averages them into a number that blocks the easy one and gives false comfort about the hard one.
Run the dependency check per request during triage instead. What data does this use case need, is that data good enough today, and if not, is the gap a short cleanup or a program of work. That question is answerable in a way an institutional readiness score is not.
Start Small on Purpose
There is a reason to begin with the lighter use cases beyond the fact that they are easier.
Small wins create champions. A registrar whose August question volume drops becomes an advocate in rooms where IT is not present, and that advocacy funds the next phase. Institutions that open with the hardest, most visible use case tend to spend their political capital before producing anything anyone can point at.
Run it as a loop rather than a launch. Define the use case, quantify the baseline before anything is built, monitor the metric, then design the next iteration of the same agent rather than jumping to an unrelated one. The value of an agent is a delta, and a delta needs a starting number. Depth on a working use case compounds faster than breadth across pilots.
What a Declined Request Should Receive
The fastest way to kill an intake process is to let requests disappear into it. If the answer is no, or not yet, the requester needs something back or they will stop using the queue and go around it.
Three responses cover most declines. A date, meaning the request is valid and sequenced behind a dependency, with a specific thing that has to be true first. A redirect, meaning the outcome is achievable without AI, usually through workflow or a knowledge fix, and here is who picked it up. Or a substitution, meaning something already in flight serves this outcome and the requester should join that effort.
The response that ends the process is silence, followed by a vendor conversation the requester has on their own.
FOR THE CIO READING THIS
You are being asked two questions at once. The board wants to know what the institution is doing with AI. Your security and privacy people want to know what is already running that they have not seen.
Intake answers both, and it is a smaller commitment than an AI strategy. A queue with five fields and a two-question tier gives you a list of what people want, a record of what was approved, and a defensible reason for everything that was not. Start there and the strategy writes itself from real demand rather than from assumptions about it.
Frequently Asked Questions
Where should AI project intake in higher education live?
In the same place the rest of technology demand lives. A separate AI queue seems tidy and creates a second portfolio almost immediately, since many AI requests turn out to be workflow or knowledge problems. What they need is extra fields and a tiering step, not a separate front door.
Do we need an approved AI policy before we start taking requests?
No, and waiting is usually the more expensive choice. Intake without a finished policy still gives you an inventory of demand, a record of decisions, and a tiering rule applied consistently. The policy is better written afterward, when you know what people are actually asking for.
How do we handle AI that units have already built or bought?
Register it without penalty. An amnesty pass, where existing tools get recorded and tiered with no consequence for having gone around the process, surfaces far more than an audit will. Attach the same accountability question every new request answers, which is who owns the output when it is wrong.
Who should sit on the governance body that reviews level three requests?
Small and empowered beats large and representative. Practically this means IT, security, privacy or general counsel, and a functional leader from the requesting domain, with the ability to decide in the room. A committee that can only recommend to another committee adds a cycle without adding judgment.
What is the first AI use case most institutions should sequence?
Usually something that depends on knowledge quality rather than transactional data accuracy, because the dependency is lighter and the baseline is measurable. Deflection against a known ticket volume gives a clean before-and-after number, which is what the second use case needs to get funded.
The Honest Summary
AI project intake in higher education is not a governance program. It is five fields, two questions, and three gate levels, in place before the demand turns into live systems that were never evaluated. The institutions handling this well are not the ones with the most complete policy. They have a queue, a tiering rule applied the same way every time, and a habit of sequencing by what each use case actually depends on.
The demand is already on campus. The only real choice is whether it arrives somewhere you can see it.
Talk it through with us
If AI requests are arriving faster than your institution can sort them, we are happy to work through what intake, tiering, and the first sequenced use case should look like on your campus.
Start a discovery conversation with Bettera or read more about our Now Assist work.
About the author. David Holstein is the founder and CEO of Bettera, a ServiceNow consulting and implementation partner built exclusively for higher education. Bettera works with colleges and universities on ITSM, ITOM, CSM, SPM, and AI governance, with an AI-native delivery model.
