A central multi-model AI platform
The institution provides a single governed gateway to multiple models, together with shared tooling and API access, in place of uncoordinated individual adoption.
The scenario
The institution elects to provide a single governed platform rather than allow faculty, staff, and researchers to enter institutional data into independently procured consumer tools. The platform offers one access point to multiple frontier and open models through a model gateway, shared tooling on top of that gateway (retrieval over institutional knowledge, prompt libraries, and no-code assistants), and API access for researchers and departmental developers. The intent is to make the governed option the default, reducing the incentive for uncoordinated adoption.
Three governance responsibilities
A platform of this kind establishes three distinct governance responsibilities that are frequently conflated. They should be kept separate: a single body may oversee all three, but the questions, owners, and review cadence differ.
Governing the platform itself
Governance of the gateway as a system: the data-routing policy, guardrails, logging, cost controls, availability, and access. This is a central responsibility reviewed on a standing cadence.
Governing the models offered through it
Governance of each model the platform exposes: vendor terms and data-training/retention policy, the data classifications it may process, a model card, routing logic, and version changes and deprecation. This layer cuts across the other two, the same model underlies both the platform and the applications built on it, and is documented as a model card in the registry.
Governing the initiatives built on the platform
Governance of each assistant, retrieval application, or API integration as a distinct initiative with its own purpose, data, risk tier, and accountable owner. The platform lowers the effort required to build; governance ensures the resulting applications remain documented and accountable rather than constituting uncoordinated adoption at a higher layer.
What makes it hard
- Data flows multiply: each model, tier, and endpoint carries different retention and model-training terms, making the question of which data classification may be processed by which model an active policy matter.
- Equity and cost are in tension: the justification for central provision is equitable access, yet a small number of intensive users or unbounded API jobs can consume the available budget.
- Model sprawl: offering multiple models entails maintaining multiple model cards, routing logic, version changes, and deprecations over time.
- API access expands the surface area: the ability to build on the platform can reproduce uncoordinated adoption at the application layer unless the resulting applications are documented and owned.
- Responsibility is divided: the platform team owns the gateway, while each application built on it requires a separate accountable owner.
How the framework applies
The moves in sequence, each tied to a pillar, the tool to reach for, and what you walk away with.
- 1Pillar 1
Establish the institutional rationale for the platform as infrastructure
Anchor the platform in institutional purpose before addressing architecture: equitable access independent of ability to pay, data sovereignty, cost discipline, and support for innovation. This rationale justifies central funding and establishes the criteria against which the platform is later evaluated.
Strategic CompassProducesCampus AI Vision statement (platform as infrastructure) - 2Pillar 2
Define the norms the platform is required to enforce
Determine the values the platform enforces by default: human oversight, transparency regarding AI use, data minimization, and the exclusion of vendor model training on institutional data absent explicit consent. These principles are implemented as platform configuration rather than stated only as policy.
Pillar 2 · AI PrinciplesProducesAI Principles statementPlatform acceptable-use baseline - 3Pillar 3
Publish a data-routing policy governing which data may reach which model
Apply the data-classification by tool-category matrix to specify which data classifications are permitted against which models and endpoints, distinguishing public models, enterprise no-training endpoints, and self-hosted open models. This is the principal operational artifact, converting general caution into a defined reference.
Tool Evaluation MatrixProducesData-classification × model routing policy - 4Pillar 4
Conduct vendor due diligence and define the data boundary
For each model and tooling vendor, verify retention, use of data for training, sub-processors, and data residency through the contract rather than vendor marketing materials. Establish a risk registry and document the platform as a system, with a model card for each model behind the gateway.
Governance Question GuideProducesRisk registrySystem Card (the platform)Model Card per model - 5Pillar 6
Confirm the institutional readiness to operate the platform
Verify the capacity to operate the platform rather than only to launch it: single sign-on and identity, centralized logging and monitoring, cost controls and quotas, a defined support model, and the staff competencies required to maintain routing and guardrails.
Maturity AssessmentProducesReadiness assessment summary - 6Pillar 7
Make the division of responsibility explicit
Distinguish the responsibilities clearly: the platform team owns the gateway, routing, logging, and guardrails; each application built on the platform has a named owner; data stewards hold the rights to the source corpora used for retrieval; and every user carries baseline acceptable-use obligations. Ambiguity at this level is a principal cause of undocumented applications.
Pillar 7 · Roles & ResponsibilitiesProducesRoles & Responsibilities matrixPer-application ownership register - 7Pillar 8
Operate the platform and maintain visibility of applications built on the API
Operate with onboarding and quotas, content filtering and data-loss prevention, monitoring and incident response, and a defined model-deprecation and version process. Each application built on the API is registered, and proportionate review maintains visibility of applications that would otherwise constitute uncoordinated adoption at the application layer.
AI Use Case RegistryProducesAI use case / application registryOperations and monitoring runbook
Key decisions
Procurement is generally preferable unless the institution has sufficient platform-engineering capacity to sustain a custom build; routing, logging, and guardrails represent the substantive engineering effort rather than the model calls.
Default to enterprise no-training endpoints for any data above the public classification; the routing policy renders the boundary enforceable.
Permit low-risk, public-data use openly, and place any use involving protected data or autonomous action behind lightweight registration and review.
Quotas protect both the equity objective and the budget; chargeback alone can reintroduce the ability-to-pay disparity the platform was intended to address.
Watch-outs
- Applications built on the API can reproduce uncoordinated adoption at the application layer; a per-application registry and proportionate review are necessary, not optional.
- Model cards become outdated as vendors update models; version changes can alter behavior without notice.
- The exclusion of training on institutional data must be verified in the contract rather than inferred from vendor representations.
- The equity objective is not met if access requires technical expertise; no-code assistants should be funded alongside direct API access.
Measuring it
The platform is evaluated as an initiative across Outputs (applications in production, users onboarded), Outcomes (equitable access, reduction in uncoordinated adoption, cost avoided), and Efficacy (model performance, content-filter accuracy, incident rate), in addition to the maturity and readiness gains the capability itself represents.
Open the Strategic Compass