AI Tool Approval Standard
A published standard and decision tree that make review requirements predictable and proportionate before a unit purchases or deploys a tool.
Using the framework in practice
The documentation hierarchy says how AI is described. The operating model says how decisions actually get made — a transparent, risk-proportionate route from an idea to a governed deployment, with named accountability at every step and a lightweight record behind every artifact.
Risk-based intake & routing
A registry should not send every inquiry to a full committee. A short, transparent intake makes it easy to do the right thing, then routes the request to a proportionate review path based on data, context, integration, automation, and who is affected.
What intake asks
A single set of questions frames every request and populates the first draft of its use-case record:
- What institutional problem or opportunity is the use case meant to address?
- Which context applies — teaching & learning, research, student support, administration, employment, or another defined domain?
- What service, system, or model is involved, and is it already approved, conditional, unreviewed, or retired?
- What data will be entered, accessed, generated, or retained — and what is its institutional classification?
- Will the use make, recommend, rank, predict, or automate a decision that affects people?
- Who is affected, and could the use create disparate impact, accessibility barriers, or heightened harm?
- What human review, authority, and ability to override exists, and what integrations create new data flows?
Where a request is routed
The answers place a request on one of five proportionate paths, escalating with data sensitivity, scale, automation, and consequence:
1
Guidance only Self-serve
Personal experimentation or low-risk use with no institutional data, no integration, and no material impact on people. Point to public guidance and go.
2
Standard local review Delegated
Low-to-moderate-risk use of an already-approved service under documented local conditions, handled by a delegated unit point of contact.
3
Cross-functional review Specialist
Moderate-or-higher data, external-facing workflows, integrations, substantial scale, or affected students, employees, or community members.
4
Central committee review High-impact
High-impact decisions, sensitive populations or data, regulated activity, novel systems, substantial automation, or unresolved risk tradeoffs.
5
Prohibited or paused Blocked
Uses inconsistent with policy, unsupported by controls, or posing unacceptable privacy, security, civil-rights, accessibility, integrity, or safety risk.
The route is the product. Publishing this decision tree openly is what turns governance from a gate into a service: requesters can see, before they buy or build, whether they need guidance, a local sign-off, a specialist review, or a committee decision.
Decision rights & roles
Governance must be centralized enough to set institutional guardrails and distributed enough to fit diverse academic, research, and operational settings. The registry should show who decides what — not merely who is consulted.
| Role | Primary responsibility | Registry responsibility |
|---|---|---|
| Executive sponsors | Set institutional direction, risk appetite, and resourcing. | Approve the governance charter, escalation thresholds, and annual reporting. |
| AI Governance Officer | Coordinate enterprise AI governance and operating processes. | Own standards, intake coordination, register integrity, and reporting. |
| AI Governance Committee | Decide or recommend on significant, novel, or high-impact uses. | Review evidence, set conditions, resolve exceptions, and watch risk trends. |
| Service owner | Own the institutional AI service and vendor relationship. | Maintain the service card, data scope, controls, and renewal information. |
| System / use-case owner | Own the configured deployment and its business or academic outcome. | Maintain system records, attest to controls, monitor performance, request renewal. |
| Local AI point of contact | Provide unit-level intake support and delegated review where authorized. | Keep local records complete and synchronized with the central registry. |
| Specialist reviewers | Assess privacy, security, accessibility, legal, procurement, research, and civil-rights issues. | Attach findings, required mitigations, and review dates to records. |
The governance lifecycle
Approval is an event within a lifecycle, not the end of one. The registry makes each stage visible and preserves the full decision history — from first idea to renewal, suspension, or retirement.
Discover
A community member identifies a possible use and consults quick guidance, examples, and the tool catalog.
Intake
The requester creates a use-case record: purpose, context, data, service/system/model, users, and anticipated impact.
Triage
The decision tree assigns a review route and identifies the reviewers and evidence required.
Assess
Reviewers weigh privacy, security, procurement, accessibility, legal, research, records, academic, and civil-rights considerations.
Decide
The authorized decision-maker records approval, conditional approval, denial, pause, or escalation — with rationale and conditions.
Implement
The owner configures the system, completes controls, trains users, provides notices, and establishes monitoring.
Publish
The registry presents an appropriately scoped record — public, campus-visible, unit-visible, or restricted — per the visibility labels.
Monitor
The owner tracks performance, incidents, complaints, adoption, drift, and model or vendor changes against the approved conditions.
Renew, change, suspend, or retire
Scheduled reassessment and event-triggered review keep the record current; the full history is preserved.
Operational controls
Five controls give the operating model teeth — turning principles into predictable requirements that connect to procurement, security, and everyday campus decisions.
Local Register Pattern
Authorized colleges and units run delegated reviews for lower-risk uses, with every local approval synchronized to — or visible through — the central registry.
Procurement Control
Governance review before any AI-enabled service is bought, renewed, expanded, or integrated — including AI embedded in LMS, CRM, and productivity platforms.
Reauthorization Schedule
Periodic reassessment for approved services and high-impact uses, with an earlier review triggered by material changes to models, terms, data flows, or scale.
Emergency Suspension Authority
A named authority can immediately suspend, limit, or retire a tool on security, privacy, civil-rights, bias, or compliance concerns — with the decision, rationale, and reinstatement conditions recorded.
Document metadata block
Each artifact should start with a simple header so its type, owner, and visibility are unambiguous.
Document Title: [Title] Document Type: [Policy / Profile / Service Card / System Card / Model Card / Review] Primary Audience: [Users / Governance / Public / Auditors] Visibility: [Public / Institution-wide / Restricted Internal / Confidential] Owner: [Office / Team] Approver: [Role / Committee] Version: [x.y] Review Date: [YYYY-MM-DD]
Document review workflow
Alongside the use-case lifecycle, publishing an artifact follows five short steps, with visibility checked at the points where it matters.
- Author proposes the document type and visibility.
- Service owner confirms scope and intended audience.
- Privacy, security, and governance reviewers validate the visibility choice.
- Approver confirms publication location and access controls.
- Visibility is rechecked whenever the service changes materially.
What counts as a material change. For a shared platform, review is continuous rather than one-time: a material change includes enabling a new model, modality, tool, or integration, or opening up a new category of downstream use. Any of these re-triggers the workflow before it goes live.
Practical end state
The framework is both a transparency tool and a governance operating model.
The result is a documentation stack that lets institutional users understand what AI tools exist and how to use them, while giving reviewers and auditors enough internal evidence to assess risk, controls, and accountability — a structured institutional memory of how AI is proposed, assessed, approved, constrained, monitored, changed, and retired.
Suggested use: publish this site as a framework overview, then attach detailed templates and supporting documents as appendices or linked source artifacts.
Take the framework with you
Read the whole framework as a formal whitepaper, or walk the seven layers starting from the hierarchy.