Concept Note / White Paper

Academic Router

A privacy-first AI routing layer for colleges and universities: one interface, one policy plane, many models, zero-retention defaults, and institution-level governance built for teaching, research, and administration.

Draft v1 Minimal interface CUNY demo frame SUNY expansion path

Executive summary

Academic Router is a proposed AI infrastructure layer for higher education. It takes the most useful part of the OpenRouter pattern — one gateway in front of many model providers — and rebuilds it around the actual requirements of universities: privacy, procurement, identity, role-based access, budget controls, auditability, and pedagogical fit.

Universities do not need another generic chatbot. They need a managed system that lets students, faculty, staff, and researchers reach the right models through a common interface, while institutional administrators keep control over privacy posture, approved use, spending, and risk. Academic Router would provide that layer.

The initial demonstration should target the City University of New York as a constrained, high-value pilot. From there, the platform can expand to the State University of New York and, in time, to consortium or statewide higher-ed procurement.

The problem universities actually have

Higher education has moved into the model era through a patchwork of consumer subscriptions, ad hoc API keys, department-level experiments, and vendor pilots. This creates scattered access, uneven privacy practices, duplicated spending, and no coherent governance layer. One professor uses a premium individual plan. Another department pays a second vendor. A lab runs local models. Students move between all of them with no unified policy, no common interface, and no institutional memory.

Campus IT departments inherit the downside of that patchwork. They face unclear data-retention terms, no consistent zero-retention enforcement, weak visibility into usage, and no way to distinguish routine classroom use from premium research workflows. Procurement offices face the same fragmentation from another angle. They see many subscriptions, many contracts, and little leverage.

Fragmented access

Different schools, departments, and instructors buy different tools, often without shared standards.

Weak governance

Most institutions cannot enforce one privacy posture across many model vendors and endpoints.

Unclear economics

Consumer plans and API accounts mix together, which makes budgeting, forecasting, and chargeback hard.

Poor pedagogical fit

Generic AI products are not organized around coursework, research workflows, or campus roles.

Any serious higher-ed AI platform has to solve all four problems at once. A campus can tolerate a rough interface. It cannot tolerate an incoherent governance model.

The proposal

Academic Router is a university-only AI routing and policy layer. It exposes a single, OpenAI-compatible API and a clean institutional user interface, then routes requests to approved external or self-hosted models based on policy, privacy, cost, capacity, and role.

The user-facing shell should use Open WebUI, which already supports multi-user access, SSO and OIDC, LDAP, SCIM, RBAC, and OpenAI-compatible backends. That allows the product team to focus engineering effort where the institutional value lives: routing, compliance controls, model governance, usage metering, and premium entitlement logic.

Core design principles

The product is not “one more model host.” The product is a governance and procurement layer that turns model access into university infrastructure.

Reference architecture

1. Interface layer

Open WebUI should serve as the primary front end. It already supports self-hosted deployment, multi-user administration, single sign-on, role-based access control, and OpenAI-compatible model backends. This reduces time to demo and makes the MVP legible to institutional stakeholders, because they can see a working portal early.

2. Gateway layer

The gateway is the actual product. It should expose normalized endpoints for chat completions and, later, embeddings, image, and audio tasks. Every request should pass through a policy and routing engine that enriches it with user and institutional context before provider selection.

Auth adapter

Maps campus SSO or API identity into role, campus, department, and entitlement state.

Policy engine

Applies approved-model lists, privacy requirements, budget caps, and role-based restrictions.

Routing engine

Selects the best compliant endpoint based on privacy, cost, latency, and availability.

Provider adapters

Translate normalized requests into OpenAI, Anthropic, Google, Azure, Bedrock, or self-hosted endpoints.

3. Data layer

The data model should separate identity, policy, and usage metadata from content itself. By default, the platform should store no prompt or completion text. It should store enough metadata to support billing, dashboards, budgeting, and incident review, but not enough to create a shadow archive of student work.

4. Observability and controls

Administrators need dashboards for spend, uptime, model popularity, route failures, and privacy mode compliance. They also need simple controls for campus-level catalog management, group entitlements, premium seat pools, and procurement reporting.

Important design rule: when zero-retention is required and no compliant route exists, the system should fail closed. It should never silently drop the user onto a non-compliant endpoint.

5. Provider mix

The gateway should support both external APIs and institution-operated models. External providers supply breadth and fast iteration. Self-hosted open-weight models supply cost control, locality, and long-term bargaining power. The point is not to pick one. The point is to make them all legible under one policy plane.

Privacy and policy posture

Higher-ed adoption depends on clear, enforceable privacy guarantees. OpenRouter’s published zero-data-retention design offers a useful reference: requests can be marked so they route only to endpoints that satisfy a ZDR policy. Academic Router should adopt that idea and harden it for university use.

Baseline privacy posture

Each model listing in the interface should display its policy envelope in plain language: whether the endpoint is zero-retention, whether provider-side training is disabled, whether prompts stay in-region, and whether the model is approved for routine coursework, faculty use, research, or administration.

This is where the platform creates trust. Universities do not only need a secure architecture. They need a system that makes its security posture visible to non-specialists.

Identity, roles, and academic segmentation

Role-based access is not a minor feature in this setting. It is the foundation of sane allocation. A freshman in a writing course, a faculty member preparing lectures, and a digital humanities lab building a custom workflow should not all receive the same model catalog, the same spend profile, or the same privacy exception rights.

Tier Typical users Model access Controls
Standard student Most undergraduates and taught-course users Curated general-purpose writing, study, and reasoning models ZDR-only, moderate caps, no premium coding agents
Faculty and staff Instructors, advisors, administrators Broader catalog, larger contexts, workflow tools Department budgets, workspace controls, reporting
Research / premium Labs, advanced graduate students, software teams Codex-class, Opus-class, API access, agents Premium allocation, project budgets, exception workflows
Campus admins IT, AI office, procurement, compliance staff Administrative, not pedagogical, privileges Catalog, policy, and budget management

This structure keeps premium costs focused where they create institutional value. It also makes the platform intelligible to deans and CIOs, who need to know why some cohorts receive advanced access and others do not.

Economic model and premium-seat logic

The temptation in AI planning is to imagine universal premium access. That is almost always the wrong framing for higher education. A university-scale system should treat high-end model access as a scarce institutional resource, not a flat entitlement for the whole student population.

CUNY’s system-wide population is often described publicly as more than 271,000 when continuing and professional education are included, though more conservative official counts for degree-seeking enrollment are lower. SUNY reported 387,363 students in fall 2025. Together, these systems define an addressable population well above half a million students before faculty and staff are counted.

At that scale, blanket $200 premium subscriptions would produce absurd spend. Premium tiers must therefore be pooled, rationed, or translated into API-metered institutional access.

Illustrative CUNY pilot math

Those numbers are not insane for a cross-campus innovation initiative, but they are much too high to treat premium access as universal. The right move is to combine lower-cost default models with a carefully governed premium lane for coding, advanced research, and specialized use.

How to treat Codex and Opus

Premium coding and flagship reasoning models should anchor a separate entitlement class. The product should not promise those models to every student. It should expose them to faculty, research groups, advanced courses, digital scholarship centers, and institutional pilots through managed seat pools or departmental budgets.

Planning rule: use subscription-equivalent math to illustrate value and upper bounds, then run the platform on institutional APIs and pooled access where possible. That gives universities control over spend and lets them route heavy users toward the most appropriate backends.

Why a CUNY demo makes sense

CUNY is a compelling first demonstration because it combines scale, public mission, diverse student populations, and many distinct academic contexts under one institutional umbrella. It is large enough to surface real allocation and governance problems, but bounded enough to make a pilot narrative clear.

A CUNY demo can show how one platform supports classroom writing, research assistance, software development, student support, and administrative workflows without collapsing them into one undifferentiated model menu. It can also show how a system can enforce privacy and budget rules centrally while still giving individual campuses room to define their own model catalogs and exception pathways.

From CUNY to SUNY

SUNY expands the problem and the opportunity. Its reported fall 2025 enrollment of 387,363 students, along with its multi-campus structure, makes it the natural second-stage proving ground. A successful CUNY pilot would provide a template for a broader system architecture: one policy plane, many campuses, campus-level sub-admin controls, and shared procurement leverage.

Phased rollout

Phase 1: demonstration

Phase 2: CUNY pilot

Phase 3: multi-campus expansion

Phase 4: statewide or consortium model

Risks and constraints

No serious proposal should pretend this is easy. Provider policies change. Premium usage can explode if quotas are vague. Campus identity systems are messy. Faculty often demand access to specific tools. Legal review will slow procurement. Those are all real constraints.

Still, those constraints strengthen the case for Academic Router rather than weaken it. A fragmented landscape already contains every one of these risks, only without a common governance layer to manage them. The question is not whether universities will use many models. They already do. The question is whether they will do so through infrastructure they control.

Conclusion

Academic Router should be understood as public-interest AI infrastructure for higher education. It adapts the gateway logic of OpenRouter, uses Open WebUI to accelerate the user-facing layer, and reorganizes model access around the needs of institutions rather than the incentives of consumer AI products.

The result is not merely a cleaner interface. It is a more durable operating model: one contract surface, one policy surface, one route into many models, and a clear path from experimental pilot to university-scale deployment.

If built well, this would let universities adopt frontier and open-weight models without surrendering governance. That is the real opportunity.

Sources and reference points

Note on enrollment: this draft uses public figures suitable for concept framing. Any formal institutional pitch should verify CUNY-wide totals against current official institutional research or central reporting sources.