Ten AI workflows in production across nine business functions

The problem

A large research university had the conditions that usually stall AI programs. Knowledge was spread across hundreds of policy documents that staff could not reliably find or interpret. Service requests queued for days while being routed by hand. Document-heavy review work, in admissions and elsewhere, consumed more than thirty minutes per case. Departments planned capacity without a shared forecast.

Each of those is a business problem before it is an AI problem, and each was owned by a different part of the institution. None of those parts reported to me.

The constraints

• Institutional data could not leave the institution's governance boundary.
• Every workflow had a different owner, and none of them reported to me.
• Answers drawn from policy had to be traceable to the governing document.
• Anything touching a person's record or an external reply needed human approval.
• Cost had to be knowable per request, not discovered in an invoice at the end of a quarter.
• The estate was already substantial and already had to keep running: 600+ servers across on-premise data centers, 12 research centers, 390 laboratories, and 7,000+ staff and faculty on a US$41M technology budget.

What was built

One governed platform, then ten workflows on top of it. The platform came first because ten separate integrations to ten separate providers would have produced ten separate governance problems.

Large language models are reached through a governed in-house gateway sitting over direct provider interfaces, carrying more than 20 models across 5 providers, with routing, personally identifiable information masking, audit logging and per-query cost metering built in rather than added afterwards. Retrieval-augmented generation returns citations. Vision and optical character recognition handle document intelligence. Underneath sit on-premise data centers, clustered SQL Server including vector search, .NET applications, and Microsoft 365, Teams and Entra single sign-on for identity.

Representative workflows

• An institutional answer gateway over 367 governed policy documents, role-aware and delivered across five channels, answering with citations.
• AI-native admissions screening using vision, optical character recognition and document parsing.
• An advising and course-planning engine running against live student records.
• Procurement split-request detection using similarity analysis and graph clustering, to surface purchases divided to stay under approval thresholds.
• An AI service desk that drafts every response and sends none. A human approves every reply.

That last one is the clearest expression of the governance model. The system does the drafting, which is most of the work. It never does the sending, which is where the risk lives.

The governance model

Every use case was assigned a risk tier during design, and the tier determined the controls rather than the other way round. Low-risk retrieval over published policy could answer directly, with citations so a reader could check it. Anything that touched an individual record, or that would leave the institution as a reply to a person, required a human in the loop before it went anywhere.

Three things made that hold up in practice. Documents were governed, so there was a defensible answer to "where did this come from". Access was role-aware, so a single gateway did not become a way around existing permissions. And every query was logged, so the question "what has this thing actually been doing" had an answer.

Data control was not a policy statement. It was an architectural consequence of running the platform in-house on direct provider interfaces.

The cost model

Cost metering was built in from the first day rather than reconstructed later, which is why there is a per-query figure at all.

The unit cost is a consequence of the architecture, not a negotiation. Running in-house over direct provider interfaces, with routing that sends each request to a model sized for it, is what keeps the number where it is. A per-seat licensing model over the same volume of usage behaves very differently.

No return-on-investment figure is published here. What a comparable unit cost would be worth inside another institution depends on that institution's baseline, and that is a conversation rather than a claim.

Adoption

Adoption at that scale, across departments with no reporting line to the program, is the part that does not happen by mandate. It happened because each workflow started from a pain point that the sponsoring department already wanted solved, and because a working prototype existed before anyone was asked to commit.

What changed operationally

• Service operations moved from days to minutes on routed requests.
• Document-heavy review dropped from more than thirty minutes to under five.
• Demand forecasting is now used by 25 departments for planning.
• 367 governed documents are served through a single role-aware gateway across five channels, rather than being searched for across shared drives.

What another institution can take from this

1. Build the platform once, then the workflows

   Ten point solutions produce ten governance conversations, ten cost models and ten integration surfaces. One governed gateway with routing, masking, logging and metering turns each new workflow into an application problem rather than a policy problem.

2. Meter from the first day

   A per-query cost figure is only available if the instrumentation was there from the start. Retrofitting it means arguing about apportionment instead of reporting a number.

3. Let the risk tier choose the controls

   Deciding the tier during design, before anything is built, avoids both of the usual failures: a blanket approval requirement that kills adoption, and an ungoverned system that eventually produces an incident.

4. Draft everything, send nothing

   For anything that leaves the institution, having the system draft and a human approve captures most of the time saving while leaving accountability exactly where it already sat.

5. Start where the pain is already owned

   Workflows shipped into departments that did not report to the program because those departments already wanted the problem solved. A prototype they could use settled the question faster than any presentation would have.

6. In-house is a strategy, not a fallback

   Running the platform inside the institution on direct provider interfaces is what produced both the data-control position and the unit cost. Those two results came from the same decision.

If this resembles your situation

The AI Pain-Point Prototype Sprint is the equivalent of how each of those ten workflows began: one problem, one working prototype, one production handoff plan. If the question is which use cases are safe and realistic in the first place, that is the Governed AI Readiness Assessment. Where the difficulty is coordination across departments, IT, security and vendors, that is the Fractional AI Program Director role.