How to Run an AI Risk Classification Intake Process for Universities

Start with a classification model, not a generic software form

A university AI intake process should begin with classification. A generic software request can capture vendor information, procurement needs, and basic security contacts, but it often misses the AI-specific factors that shape institutional risk. The intake should capture how an AI tool or agent will access data, behave, call tools, integrate with campus systems, and act on behalf of users before it is approved.

The classification model should help governance teams separate low-risk productivity use from tools that touch student records, protected research data, administrative systems, or autonomous agent workflows. That distinction allows the university to match review depth to actual risk instead of routing every request through the same process.

Define risk tiers using university-specific criteria

Risk tiers should reflect the data, systems, autonomy, and operational impact involved in the proposed use case. The following tier definitions preserve a practical separation between routine AI assistance and higher-risk uses that require deeper review.

A six-step campus AI intake review workflow

The intake process should assign each request to a risk tier, route it to the right reviewers, document the decision rationale, and define runtime conditions such as permission limits, logging, monitoring, and reassessment triggers.

1. Capture the proposed AI use case

   Document what the AI tool or agent will do, who will use it, what decisions or workflows it supports, and whether it is intended for productivity, teaching, research, administration, or operational use.

2. Identify data access and data movement

   Capture what categories of university data the AI tool can view, process, retain, or transmit, including student records, protected research data, internal departmental data, and public or low-sensitivity information.

3. Assess agent autonomy and system permissions

   Determine whether the system only assists a human or can take actions through tools, APIs, plugins, databases, connected systems, or other agents. Document whether access is read-only or write-capable.

4. Assign the risk tier

   Classify the request as low, moderate, or high risk using the university-specific criteria for data sensitivity, system access, autonomous action, tool-calling, write permissions, and material operational impact.

5. Route to the appropriate approval authority

   Use the assigned tier to determine which governance, security, privacy, procurement, or research stakeholders must review the request before approval.

6. Define runtime conditions and reassessment triggers

   For approved systems, document permission limits, logging, monitoring, reassessment triggers, and any runtime controls that must remain in place after deployment.

Add agentic AI questions that traditional SaaS reviews miss

Agentic AI systems require additional scrutiny because risk is shaped by what the agent can do at runtime, not only by what vendor hosts the application. A static application may present information to a user. An AI agent may interpret a prompt, choose a tool, query a system, transform data, and initiate an action. The intake process must capture those capabilities before approval.

The form should ask whether the AI can call tools, APIs, plugins, databases, or other agents. It should capture the complete list of downstream systems the agent can reach, the permissions associated with each connection, who can change those permissions, and whether actions are read-only or write-capable. It should also ask whether a human must approve each action, whether the agent can operate on a schedule, and whether it can send information to third-party systems.

For high-risk agentic use cases, approval should include runtime governance conditions. Intake-time review is a decision point, but it cannot ensure that risk remains stable after deployment. Vendors may change capabilities, administrators may expand permissions, and users may discover new ways to connect tools. Universities should define runtime controls such as least-privilege permissions, tool approval workflows, agent identity, audit logging, monitoring, and review triggers as part of the original approval.

Documentation needed for an auditable higher education AI approval process

An auditable intake process should make the decision path clear enough for governance teams to understand what was requested, how it was classified, who reviewed it, and which conditions apply after approval.

• The proposed AI tool or agent use case, including how it will behave and who will use it.
• The categories of university data the system can view, process, retain, or transmit.
• The downstream tools, APIs, plugins, databases, connected systems, or other agents the AI can reach.
• The permissions associated with each connection, including whether actions are read-only or write-capable.
• The risk tier assigned to the request and the rationale for that classification.
• The governance, security, privacy, procurement, or research stakeholders required for review.
• The approval decision, approval authority, and any conditions attached to the approval.
• The runtime controls required after deployment, including permission limits, logging, monitoring, and reassessment triggers.

Operational tradeoffs for university governance teams

A strong AI intake process should be structured without becoming unnecessarily heavy. If every request is routed through the deepest review path, faculty, researchers, staff, and students may avoid the process entirely. If the process is too lightweight, the institution may approve tools without understanding data access, autonomy, integrations, or governance requirements.

The practical balance is to use classification as the routing mechanism. Low-risk productivity use can move through a lighter review. Moderate-risk use can require clearer documentation and human oversight. High-risk tools and agents should receive deeper review, especially when they involve sensitive or regulated data, broad system access, autonomous action, external tool-calling, write permissions, or material operational impact.