A Proven AI Operating Model Roadmap for Institutions

Most universities are not behind on AI tools. They are behind on the model that makes tools work.

That distinction matters more than almost anything else a leadership team can understand right now. The gap between institutions moving fast and institutions stalling is not about which platforms they purchased. It is about how clearly they have defined who owns AI work, what decisions belong where, and what value they are actually trying to create.

This is a roadmap for building that model. It is not theoretical. It is the sequence that works.

Why the Operating Model Comes First

When AI adoption stalls, the instinct is to look at the tools. Wrong direction.

Stalled adoption is almost always a governance problem. No one owns the work. Decisions require consensus that never arrives. Faculty pilots produce results that never scale because no one has the authority to scale them. The institution keeps moving — meetings, task forces, policy drafts — without actually moving.

The operating model is the answer to three questions: Who decides? What do they decide? And what does success look like? Until those questions are answered clearly, every AI investment is speculation.

Institutions that have built effective AI operating models share one characteristic: they resolved decision rights before they expanded tool access. The sequence is not accidental. It is the only sequence that works.

Phase 1: Establish the AI Ownership Structure

The first move is naming an owner, not a champion.

A champion advocates. An owner decides. Those are different jobs, and confusing them is the single most common structural error in AI governance. A champion can build enthusiasm. Only an owner can resolve the conflicts that show up when AI work crosses departmental lines, which it always does.

The owner does not need to be a new hire or a new office. In most institutions, this is a reassignment of decision authority to an existing senior leader — a provost, a chief academic officer, or a designated deputy. What matters is that the person has the authority to say yes, say no, and hold people accountable for outcomes.

Underneath the owner, the operating model needs three functions: strategy (what problems AI should solve), implementation (how pilots get run and scaled), and governance (how policy, ethics, and compliance are managed). In smaller institutions, one person may cover two of those functions. The functions still need to exist, even if the org chart is lean.

One more thing: AI does not belong in IT. IT manages infrastructure. Strategy owns how work changes. Put AI in IT and it will be treated as a technology procurement problem. That frame prevents the operating model from ever forming.

Phase 2: Define the Value You Are Building Toward

Before piloting anything, the institution needs to answer one question: what does value look like here?

This sounds obvious. It is not. Most institutions skip it and go straight to pilots, which means they have no way to evaluate whether the pilots worked. They generate activity. They cannot generate evidence.

Value in an AI operating model typically falls into three categories. The first is productivity: AI reduces the time required to complete defined tasks. The second is capability: AI allows the institution to do things it could not do before, or do them at scale. The third is experience: AI improves outcomes for students, faculty, or staff in measurable ways.

Pick one category to start. Define what success looks like in specific, measurable terms. “Improve student outcomes” is not a definition. “Reduce time-to-advising-response from 72 hours to 4 hours” is a definition. The specificity is not bureaucratic overhead. It is the only way to know if the work is worth continuing.

This step also forces the uncomfortable resource conversation. What faculty time, staff support, and infrastructure investment does this actually require? That question gets asked upfront or it derails the pilot six months in.

Phase 3: Run a Bounded Pilot with Clear Accountability

A pilot has four components: a defined problem, a defined owner, a defined timeline, and defined success criteria. If any of those are missing, it is not a pilot. It is an experiment without a hypothesis.

The problem should be specific and painful. Not “improve advising” but “students in their second year are not getting advising contact before add/drop deadlines, and 12% are dropping courses they need.” The more specific the problem, the easier it is to design an AI-assisted solution and evaluate whether it worked.

The timeline should be short. Twelve weeks is usually enough to generate evidence. Eighteen months is a research project, not a pilot.

The owner is accountable for results, not just progress. Progress reports are not accountability. Results are.

One more constraint: run one pilot at a time in each area, not five simultaneously. Tool sprawl is not capability. Five concurrent pilots with no clear owner, no shared measurement framework, and no pathway to scale is expensive noise. One focused pilot with clear ownership and a real decision at the end is how institutions build the confidence to move.

Phase 4: Build Consensus With Results, Not Votes

Faculty buy-in does not come before pilots. It comes from pilots.

This is the belief that costs institutions the most time. The governance instinct is to build consensus first, then move. That instinct made sense in a different environment. It does not make sense in this one.

Waiting for consensus before piloting is not caution. It is delay with process attached. The faculty members most likely to resist AI adoption are not going to be converted by a task force. They will be converted by a colleague who ran a pilot, got a result, and can describe what actually changed.

After a successful pilot, the institution has something that votes cannot produce: evidence. Evidence changes the conversation. It moves skeptics who cannot be moved by argument. It gives the owner something to point to when the governance debate starts — and it will start.

The sequence is pilot, then evidence, then scale, then policy. Policy that precedes practice is almost always wrong in some important way. Write it after you know what you are governing.

Phase 5: Build the Capability Layer

Tools do not create capability. People using tools to solve problems create capability.

The capability layer is the institution’s accumulated knowledge of how to use AI effectively — which tools solve which problems, how to prompt and configure them, where the failure modes are, and how to train new people quickly. This knowledge does not transfer automatically. It has to be built deliberately.

The practical mechanism is a community of practice: a small group of faculty and staff who have run pilots, share what worked, and help the next wave of pilots move faster. This is not a committee. It does not have voting authority. It is a network of people who have done the work and are willing to teach others.

The other component is documentation. Every pilot produces knowledge. That knowledge disappears if it is not written down and accessible. A shared repository of pilot results, design decisions, and failure modes is not glamorous. It is the difference between an institution that builds capability over time and one that reruns the same pilots every two years.

What the Roadmap Delivers

An AI operating model built on this sequence delivers three things a tool purchase never can.

First, decision velocity. When ownership is clear and criteria are defined, decisions that currently take months take days. The institution does not need consensus. It needs clarity on who decides.

Second, scalable confidence. Faculty and staff who have seen a pilot work are ready to try the next one. Institutions that pilot fast and share results build internal confidence faster than any training program. The culture shifts because the evidence shifts.

Third, a defensible position. When the board asks what the institution is doing on AI, the answer is not a list of tools purchased. It is a description of an operating model: who owns it, what value it is creating, and what the evidence shows. That answer holds up. A list of platforms does not.

The Single Biggest Barrier

It is not resistance from faculty. It is not budget. It is not technology.

It is the belief that the institution must get AI right before it scales.

That belief feels like rigor. It acts like an anchor. Institutions that are waiting to get it right are watching other institutions build the capability, culture, and confidence that come only from doing the work. The gap is not closing. It grows every semester that passes without a completed pilot.

The operating model described here does not require getting it right before moving. It requires moving with enough structure to learn. The difference is not semantic. One of those approaches produces results. The other produces plans.

Build the model. Run the pilot. Build consensus with evidence.

That is the roadmap. Everything else is commentary.

Quinn Koller works with university presidents and provosts on academic strategy and AI operating model design. If your institution is past the pilot conversation and ready to build the model, reach out.