AI Registry & Documentation
Most campuses didn't adopt AI through a single decision, tools arrived through procurement, vendor suites, research computing, and features switched on inside existing systems. This is the layered model for documenting all of it: who owns each tool, what data it may handle, what risk it carries, and what gets published versus kept internal. It operationalizes Pillar 4, the use-case and risk registries live inside it.
See the six pathways AI enters campus, and the types of AI to govern See the full model at campusairegistry.comThe documentation hierarchy
Seven layers, narrowing from institution-wide rules to the evidence behind a single deployment, and from user-friendly guidance toward technical evidence. Each layer answers a narrower question than the one above it.
Strategy, AI principles, acceptable use, data classification, academic integrity, procurement and privacy/security/accessibility requirements, and the consolidated AI risk registry that rolls up risk across the whole portfolio.
Context-specific overlays that adapt the NIST AI RMF to particular settings. Context profiles govern how AI is used (teaching, research, administration, student engagement); platform profiles govern shared services (institution-managed platforms, cloud, agentic AI).
Two paired institutional indexes, a catalog of supported services (supply side) and a registry of approved/proposed AI use cases (demand side), each with scope, audience, and allowed data classes.
User-facing documentation: what a tool is, who it's for, and under what rules. The main document the community reads.
Deployment-level documentation: architecture, integrations, controls, governance boundaries, and, for multi-model platforms, the model catalog, routing logic, and change management.
Vendor model cards or internal summaries covering intended use, limits, and local context.
Per-deployment risk registers, reviews, data-flow diagrams, evaluations, incident records, and due diligence, the local evidence the consolidated registry rolls up.
Three cards do the connective work
A simple rule keeps the hierarchy coherent as it grows. Most documentation hangs off these three card types.
The main user-facing document, scope, audience, approved use, and data guidance for a tool people choose from.
Sits beneath a service card when a service is a configured institutional deployment, architecture, controls, governance boundary; for platforms, the model catalog and routing.
Sits below the system level, the actual models used, whether vendor-published or internally summarized.
Two governance lanes
A shared institution-managed platform (one service offering several models) is governed along two complementary lanes, continuously rather than once.
Ownership, approved data classes, the model catalog and routing, security controls, logging, and change management. Indexed by the service catalog at layer 3.
Downstream tools, use cases, eligible groups, and required approvals. Indexed by the use-case registry at layer 3; each use case is mapped against the relevant context profile to decide approval.
Two registries, two altitudes
Risk is documented twice over, once locally, once across the portfolio.
Sits beneath each system card, the local risks, controls, and reviews for one deployment.
Aggregates those entries into one portfolio view, the documented output of the RMF's Map, Measure, and Manage functions.
Visibility & publication
Not every document should be public. Each artifact carries one of four labels, so transparency means disclosing the right thing to the right audience, not publishing everything.
Safe for open publication.
e.g. User guidance, service summariesVisible to all credentialed campus users.
e.g. Most service cards, profile summariesLimited to approved internal stakeholders.
e.g. System cards, control evidenceLimited due to sensitive security, privacy, legal, or incident content.
e.g. Incident records, full RMF profilesWhat each implementation needs
The same framework documents very different categories of AI, each tends to require a particular combination of artifacts.
The review operating model
Every artifact opens with a short metadata header (title, type, audience, visibility, owner, approver, version, review date) and moves through a five-step review. For a shared platform, review is continuous: a new model, modality, tool, or integration re-triggers it before going live.
- 1Author proposes the document type and visibility.
- 2Service owner confirms scope and intended audience.
- 3Privacy, security, and governance reviewers validate the visibility choice.
- 4Approver confirms publication location and access controls.
- 5Visibility is rechecked whenever the service changes materially.
Adapted from “A Campus AI Registry & Governance Framework” (Joe Sabado, 2026), CC BY 4.0, see the full model at campusairegistry.com. Pairs with the Governance pillar, the Governance Guide, and the registry templates in Resources.