University IT
AI Governance Framework
1.1 Framework Overview
This AI Governance Framework (AIGF) establishes a unified, scalable, risk-based, and shared-responsibility approach to the responsible development, deployment, procurement, and ongoing oversight of AI systems across Stanford University. It integrates:
- AIUC-1: Operational AI use-case classification and tiering methodology
- ISO 42001:2023: AI Management System standard for organizational governance
- NIST AI Risk Management Framework (AI RMF): Lifecycle-oriented risk identification and management
- EU AI Act: Regulatory risk classification, transparency, and compliance obligations
- OWASP AIVSS: AI vulnerability and security scoring guidance
The framework's central design principle is proportionality: governance overhead scales to the actual risk and exposure of each system. Low-risk and Moderate risk, individual-use tools are community-managed through self deployed by following the guardrails. High-risk systems with broad exposure receive full review. This proportionality is not a loophole but a deliberate design choice to enable responsible AI use across the University without creating a bottleneck that drives deployment underground.
Every AI system is classified by both its Risk Tier (consequence severity) and its Agent Deployment Category (point of action and audience exposure). Together, these two dimensions determine the deployment pathway: Self-Service Deploy or DRA Review.
Key Objectives:
- Enable trustworthy, compliant, secure, and accountable AI at every stage of the lifecycle.
- Empower the Stanford community to deploy AI responsibly through shared stewardship.
- Scale governance overhead to actual risk: a personal writing assistant and a student admissions screening system are not the same problem.
- Operationalize agent identity, lifecycle governance, and category-specific controls alongside risk tier classification.
This framework shall be maintained as a living document and updated in response to regulatory changes, operational learnings, audit findings, and the evolving AI landscape.
1.2 Definition of Artificial Intelligence
For purposes of this framework, an Artificial Intelligence (AI) system is a machine-based system that, given a set of objectives, is capable of performing actions and generating outputs such as predictions, recommendations, decisions, or content that influence real or virtual environments. AI systems use models trained on data and operate with varying degrees of autonomy. This definition is consistent with ISO 42001:2023 and the EU AI Act (Art. 3(1)).
AI systems can be designed or configured as autonomous components known as agents. An AI agent pursues a goal by determining what actions to take, how to carry them out, and adjusts its next steps based on the results, rather than simply producing a single response to a single input.
This definition intentionally excludes:
- Purely rule-based systems that execute only explicitly programmed logic with no learned or adaptive component
- Traditional statistical models (regression, decision trees, linear classifiers) where the model structure is fully specified by a human and does not adapt from new data
- Business rules engines and workflow automation tools that do not incorporate machine learning
These excluded systems remain subject to Stanford's standard data governance, access control, and change management requirements. They do not require AI registration or classification under this framework.
2.1 Purpose
This framework provides governance guardrails and operational procedures to ensure that AI systems used, built, or procured by Stanford are:
- Safe and reliable in their intended operational context
- Compliant with applicable regulations
- Transparent and explainable to affected stakeholders
- Accountable through defined roles, responsibilities, and audit trails
- Continuously monitored and improved throughout their lifecycle
2.2 Scope of Application
This framework applies to all AI and machine learning systems within the University's control, including:
- Internally developed AI models and pipelines
- AI-embedded commercial software and SaaS products, including AI features added to existing licensed tools after their initial procurement
- Third-party AI APIs and foundation models
- AI agents built using vendor-provided agent development frameworks or agent builder tools (e.g., Microsoft Copilot Studio, Google Gemini Agent Builder)
- AI systems operating on behalf of Stanford users
Exclusions: Purely rule-based systems, traditional statistical models without adaptive learning, and research projects not intended for production deployment are excluded unless they interact with Moderate or High Risk data or decisions affecting such data.
2.3 Governing Principles
All AI activities shall be governed by the following principles:
Proportionality
Governance overhead scales to actual risk and exposure. This is the foundational design principle of this framework. A system with minimal data access, limited autonomy, and no external audience requires minimal governance. A system with high-stakes decision authority, regulated data, and broad external exposure requires full institutional oversight. Proportionality is not a justification for avoiding governance; it is the mechanism that makes governance practical at University scale.
Human-Centric Design
AI systems shall augment human decision-making, not replace human judgment in high-stakes contexts.
Accountability
Clear ownership of AI systems shall exist at every stage, from design through decommission.
Transparency
AI systems shall be explainable to the degree appropriate for their Risk Tier, Agent Deployment Category and affected population.
Fairness and Equity
AI systems shall be regularly audited for bias and shall not perpetuate discriminatory outcomes.
Shared Responsibility
AI deployers hold first-line accountability for systems they register and deploy. Governance scales to risk: Low Risk systems are community-managed, while High Risk systems receive institutional oversight.
Research Integrity
AI systems must not compromise the validity, reproducibility, or ethical conduct of research. IRB coordination is required for AI used in human-subjects research.
Privacy and Data Protection
All AI systems shall comply with applicable laws and regulations through data minimization, purpose limitation, and robust consent mechanisms.
Security and Resilience
AI systems shall be designed and maintained to withstand adversarial conditions, operational failures, and evolving threat landscapes. All AI tools developed, deployed, or procured by the university shall conform to Stanford Minimum Security Standards and align with recognized industry and regulatory frameworks/standards.
Information Disclosure Discipline
The technical and operational details of AI systems (vendors, datasets, infrastructure, model versions, system prompts) shall be disclosed only on a need-to-know basis consistent with the system's risk tier. Unnecessary public disclosure of these details increases Stanford's attack surface.
Continuous Improvement
Governance practices shall evolve with the AI landscape, regulatory changes, and operational learnings.
To enhance our assessment of AI-related risks, the framework introduces AI risk tiers that, while aligned with Stanford's Data Risk Classification, also account for an AI system's actions or tool access, influence on decisions, and level of external exposure and autonomy. AI autonomy is the degree to which an AI system can independently make decisions and take actions, ranging from simple rule-following to fully self-directed agents that operate without human intervention. All AI systems must be classified before deployment and reclassified whenever material changes occur.
3.1 AI Risk Classification Matrix
3.2 AI Agent Deployment Categories
In addition to the Risk Tier classification in Section 3.1, every AI system must be classified into one of three Agent Deployment Categories based on its place of action and population of exposure.
This dual-axis approach reflects a key insight: two AI systems at the same Risk Tier can carry materially different governance burdens depending on whether they augment one individual, automate an internal workflow, or interact with people outside the deploying unit.
3.2.1 Cross-Cutting Rules Re-classification
An agent must be reclassified if its scope, audience, or risk changes. The highest category governs in composition: When agents call other agents, the composed system inherits the controls of the highest category in the chain. A Personal Agent that invokes an External-Facing Agent is governed as External-Facing.
| Dimension | Personal Agent | Business Workflow Agent | External-Facing Agent |
|---|---|---|---|
| Acts on behalf of | One individual | A department, function, or service | Stanford, in front of external parties |
| Credentials used | Individual user account / SSO | Service / departmental account | System account; public or authenticated endpoint |
| Data accessed | Individual's own work product | Internal Stanford systems and records | External-party inputs; selected internal context |
| Output audience | The individual user | Internal staff, faculty, students | Public, applicants, patients, donors, participants |
| Primary risk | Data exfiltration; shadow IT | Privileged action at scale; regulatory exposure | Reputational, legal, and regulatory liability |
| Blast radius | Bounded to the individual | Bounded within Stanford | Extends beyond Stanford |
| Accountable Party | The deployer (user) | Service Owner/Business Owner | Service Owner/Business Owner/Organization Leader |
Effective AI governance requires clear ownership at every level. This section defines the organizational roles, responsibilities, and decision-making authorities required to operationalize this framework.
4.1 Governance Role Definitions
| Role | Responsibility |
|---|---|
| Chief Information Officer (CIO) | Executive accountability for AI governance |
| Chief Risk Officer (CRO) | Advises on the overall institutional risk |
| Chief Information Security Officer (CISO) | Oversees overall information security systems for AI governance |
| Administrative Data Governance Council | Responsible for providing guidance on the use of Stanford administrative data in AI tools. |
| Data Owner | Responsible for cases where Stanford data are involved. |
| Service Owner/Business Owner | Responsible for ongoing compliance. Use-case risk classification and lifecycle management. Completes the AI Registration and DRA submissions if needed. |
| AI Deployer | Responsible for ongoing compliance for personal agents. Completes the AI Registration and DRA submissions. |
| University Privacy Officer (UPO) | Compliance and privacy review; de-identification sign-off |
| IRB / Research Ethics Board | Human subjects AI research review |
| AI Engineer | Implements technical controls, tests models, and deploys AI services |
| Information Security Officer | Establishes and reviews policy. Performs vendor security reviews, security assessments, and contract reviews. |
| Organization Leader | Accountable for ensuring compliance with established standards, addressing any resulting violations, and determining disciplinary outcomes. |
4.2 The Deployer as First-Line Accountable Party
For self-service deployments, the AI deployer accepts first-line accountability by completing the self-deployment checklist. This is a meaningful, auditable act, not a rubber stamp. Deployers who self-certify inaccurately are subject to the same institutional accountability standards as any misconduct finding.
4.3 AI Risk Committee (ARC)
The AI Risk Committee is the cross-functional body responsible for Full Committee Review of High Risk and agentic AI systems, policy approval, and annual governance audit.
The ARC would reside within the DRA process. In addition to ISO and UPO representatives already established within the DRA process the ARC may also consist of committee members from various entities depending on the data type. OGC may be required for legal advice and/or further consultation. The Administrative Data Governance Council may be included in cases where the system handles Stanford Administrative Data.
The deployment pathway is determined by the combination of three inputs: (1) the AI Risk Tier from Section 3.1, (2) the Agent Deployment Category from Section 3.2, and (3) whether the system is using a third party whose AI tools are not approved for Stanford use. This three-factor model ensures that pathway scrutiny scales to both consequence severity and exposure surface.
All deployers should initiate the self-service deployment tool to determine which pathway they need to complete.
The following pathways are defined:
- Self-Service Deploy (Green): Completion of the self-service deployment checklist plus the applicable category addendum in Appendix B will allow for immediate deployment upon registration.
- DRA (Red): Full Data Risk Assessment will include AI Risk Committee review. 3-5 weeks. Required for High Risk and/or Third-Party systems.
| Risk Tier | Personal Agent | Business Workflow Agent | External-Facing Agent | Third-Party (Pending AI Approval) |
|---|---|---|---|---|
| Low | Self-Service Deploy | Self-Service Deploy | Self-Service Deploy | DRA |
| Moderate | Self-Service Deploy | Self-Service Deploy | Self-Service Deploy | DRA |
| High | DRA | DRA | DRA | DRA |
| # | Step | Action |
|---|---|---|
| 1 | Initiate Self-Service Deployment Checklist | The Deployer submits the AI System Record (registration) via the AI Self-Deployment Checklist Form. Mandatory for every system. |
| 2 | Classify the Risk Tier | Deployer classifies the system as Low, Moderate, or High per Section 3.1. |
| 3 | Classify the Agent Category | Deployer selects Personal, Business Workflow, or External-Facing per Section 3.2. |
| 4 | Identify build vs. buy | Internally built? Continue with category + risk tier. Third-party / SaaS / API, refer to DRA Review. |
| 5 | Complete category addendum | Complete the addendum specific to the Agent Category in Appendix B. |
| 6 | Deploy or submit for review | Self-Service: the deployer self-certifies and deploys immediately. DRA / Full Review: submit AI System Record and supporting evidence. |
| 7 | Monitor and re-classify | Continuous monitoring per the system's Risk Tier. Material change in scope, data, audience, or autonomy triggers re-classification. |
Every AI system in scope under Section 2.2 (including agentic AI, AI-embedded commercial software and SaaS products, third-party AI APIs, and foundation models) must progress through six lifecycle stages: Inception, Development and Configuration, Pre-Deployment Review, Deployment and Activation, Active Operation, and Decommissioning. Each Agent Deployment Category (Section 3.2) imposes different gates, owners, and evidence requirements at each stage. Where a system does not map cleanly to an agentic category, the Business Workflow Agent column governs by default for internal systems and the External-Facing Agent column for systems with external exposure.
The lifecycle model serves three purposes: it gives deployers a predictable map of what is expected and when; it gives reviewers consistent decision points to gate progression; and it gives the AI Risk Committee an audit trail spanning the full life of every system. Stage transitions are not automatic, and each requires the named owner to confirm that the entrance criteria for the next stage have been met.
6.1 The Six Lifecycle Stages
- Stage 1 - Inception: The deployer identifies a use case, classifies the candidate Risk Tier and Agent Category, and registers the system in the AI System Registry. The system has no credentials and is not yet built.
- Stage 2 - Development and Configuration: The AI system is built, configured, or procured. System identity is provisioned (see Section 7). Credentials, tool access, and data scope are defined under least-privilege principles. Testing occurs in a non-production environment where applicable.
- Stage 3 - Pre-Deployment Review: The deployer completes the core checklist and the category-specific addendum (Appendix B). The system is routed through the appropriate pathway from Section 5 -- Self-Service or DRA.
- Stage 4 - Deployment and Activation: The AI system goes live. System identity is activated, credentials are issued, monitoring is turned on, and the kill-switch is verified where applicable. A deployment record is appended to the AI System Record.
- Stage 5 - Active Operation: The AI system runs in production under continuous monitoring. Periodic re-review occurs at the cadence required by the Risk Tier. Any material change in scope, data, audience, or tool access triggers re-classification and a return to Stage 3.
- Stage 6 - Decommissioning: The AI system is retired. Credentials are revoked, identities are deactivated, audit logs are retained per institutional retention policy, and the AI System Record is closed with a final disposition note.
| Stage | Personal Agent | Business Workflow Agent | External-Facing Agent |
|---|---|---|---|
| 1. Inception | Owner: Individual deployer. Register tool in the AI Registry. Confirm Risk Tier is at most Moderate or escalate. | Owner: Business Owner. Use-case proposal documented. Risk Tier and Category drafted; data sources identified. Note: If the Business Owner does not own the data they are seeking to access, they must work with the University Privacy Office (UPO) and the data owner to execute a Data Use Agreement (DUA) prior to access. | Owner: Business Owner Use-case brief reviewed by ARC pre-engagement. Regulatory scoping initiated. |
| 2. Dev & Config | User-level identity (SSO). DLP and tenant controls verified. No development beyond the configuration of approved tool. | Service/agent identity provisioned. Least-privilege scopes defined. Sandbox or non-prod environment built. Tool / API allowlist created. | Dedicated agent identity, distinct from any human. Output guardrails configured. Disclosure language drafted; OGC + Comms loop opened. Threat model documented. |
| 3. Pre-Deploy Review | Self-service deployment checklist + B.2 addendum. Acceptable-use training confirmed. | Self-certify (Low or Moderate) or DRA Review (High). Self-service deployment checklist + B.3 addendum. | Self-certify (Low). DRA for Moderate and High. Red-team report on file. Disclosure approved by OGC + Comms. |
| 4. Deploy & Activation | Tool enabled in user's Stanford workspace. DLP active; logging enabled where supported. | Credentials issued; agent identity activated. Production monitoring live. Kill-switch tested and on file. | Phased rollout recommended. Real-time monitoring is active. On-call rotation confirmed; runbook live. Public disclosure visible at first interaction. |
| 5. Active Operation | Annual acceptable-use refresh. Periodic DLP review. Re-classify if usage scope expands. | Continuous logging and drift detection. Quarterly access review. Annual re-review (mandatory for High). | Continuous monitoring with alerting. Monthly output-quality and bias spot checks. Quarterly red-team / abuse review. Annual ARC re-attestation required. |
| 6. Decommissioning | Tool access revoked. Update AI System Record. | Credentials revoked; identity deactivated. Audit logs retained. Final disposition note in System Record. | Public-facing endpoint removed gracefully with notice. Final incident summary archived. Records retained for regulatory window. |
6.2 Re-Classification Triggers
Any of the following changes during Active Operation require the deployer to return AI System to Stage 3 (Pre-Deployment Review) for re-classification under Sections 3.1 and 3.2:
- Expansion of the data the AI system can access (new system, new data domain, new sensitivity tier)
- Addition of new tool calls, APIs, or write permissions
- Change in audience -- e.g., a Personal Agent shared with a team, or a Business Workflow Agent exposed externally
- Material change in the underlying model (different foundation model, fine-tuning, or system-prompt rewrite affecting capability or autonomy)
- Change in operating jurisdiction or regulatory scope
- Incident or near-miss that reveals previously unknown risk
Agent identity is the foundation for every other control in this framework. Without a distinct, attributable, and revocable identity, an agent cannot be authorized, audited, monitored, or decommissioned. Treating agents as anonymous extensions of human users creates serious risk and makes incident response impossible. Therefore, individuals are held accountable for agentic actions outlined in the Stanford AI Tools User Agreement.
This framework requires every AI agent operating at Stanford to have an identity appropriate to its Agent Category. Identity is provisioned during Lifecycle Stage 2 (Development and Configuration), activated at Stage 4 (Deployment and Activation), and revoked at Stage 6 (Decommissioning).
7.1 Core Principles of Agent Identity
Distinct from any human
Business Workflow and External-Facing Agents must operate under their own identity, not under the credentials of the deployer or any individual employee. Personal Agents are an explicit exception: they operate under the user's identity by design, which is why they have a smaller authorized scope.
Attributable
Every action the agent takes must be traceable in audit logs to the agent's identity, the human accountable for it, and the version of the model and prompt in use at the time.
Least-privilege
The identity is scoped to the minimum set of systems, data, and tools required for the agent's defined purpose. Privilege expansion requires re-classification (Section 6.2).
Revocable
The identity must be revocable in a single action by the operational owner, the AI Governance Lead, or the CISO. This is the technical foundation of the kill-switch requirement.
Renewable, not persistent
Credentials and tokens issued to the identity must rotate per ISO policy. Long-lived static credentials are not permitted for Business Workflow or External-Facing Agents.
Disclosed when interacting with people
External-Facing Agents must identify themselves as AI at the start of every interaction. Internal agents that initiate communication with humans (e.g., posting to Slack, sending email) must include a clear AI-origin marker.
7.2 Open Issues for Future Iteration
Three areas of agent identity are evolving rapidly and warrant continued attention as Stanford's deployment scales:
Agent-to-agent identity
When one agent invokes another, the chain of accountability must be preserved. Stanford should require that downstream agents log the calling agent's identity, not just the originating user.
Cross-tenant identity for third-party agents
When a Stanford-deployed agent acts via a vendor API (e.g., a Salesforce agent acting on Stanford data), the identity model must distinguish actions taken by the vendor's platform from actions taken on Stanford's behalf. This should be addressed in the vendor DRA process.
Standards adoption
Emerging standards for agent identity and authorization (workload identity federation, signed agent credentials, OAuth for AI agents) should be tracked by the ISO and folded into this framework on the Q3 annual review cycle.
Transparency and explainability are required at multiple levels: organizational (what AI systems are in use), system (how they work), and decision (why a specific output was produced). Requirements are scaled to the risk tier of each system.
8.1 Information Disclosure Guidance by Risk Tier of Each System
| Risk Tier | What May Be Disclosed | What Should Not Be Disclosed |
|---|---|---|
| Low | General acknowledgment that AI tools are in use; approved tool names from the Stanford AI Tools catalog; general capability descriptions. | Avoid unnecessary disclosure of specific configuration details, prompt structures, or vendor contract terms. |
| Moderate | Existence and general purpose of the system; the fact that it has been reviewed; general data categories processed. Disclosure to directly affected users as described by Section 8.2. | No public disclosure of model versions, training data sources, specific vendor configurations, or system prompt content without ISO review. |
| High | Existence of the system only, as required for regulatory compliance or mandatory AI disclosure obligations. Disclosures to regulators and auditors as required by law. | No public disclosure of architecture, vendors, datasets, model versions, access controls, or system configuration. Public statements about High Risk AI systems must be reviewed by OGC and Communications before release. |
8.2 Disclosure to Affected Individuals
Research subjects must be informed of AI involvement in research through the informed consent process. IRB consent templates should be updated to address AI-assisted research.
Students must be informed when AI is used in assessments, academic risk prediction, or other decisions affecting their standing.
Users interacting with AI systems must be notified at the start of every interaction that they are engaging with an AI system.
8.3 Scientific Transparency
- All AI-assisted research outputs must disclose the AI systems used, including model name, version, and role in the research, in accordance with journal and funder requirements.
- AI System Records are treated as research materials and must be retained for the duration required by applicable research data retention policies.
- The AI System Registry is available to Internal Audit, IRB, and regulatory authorities on request.
- Disclosure requirements by risk tier are outlined and defined in Section 5 of this document.
9.1 Annual Review Cycle
AI governance will be subject to the following review cycle:
- Q1 -- Internal audit of AI governance controls.
- Q2 -- Review of audit findings and framework gaps.
- Q3 -- Regulatory horizon scan, framework update (if required), and agent identity standards review.
- Q4 -- Board / senior leadership AI governance report; KPI performance review.
- Agentic AI system: An AI system that pursues goals autonomously across multiple steps, invoking tools and taking actions in the world without per-step human approval.
- Agent Deployment Category: One of three classifications (Personal, Business Workflow, External-Facing) that captures the locus of action, credential model, and population exposed to an AI system's outputs.
- AI Risk Committee (ARC): The cross-functional body responsible for Full Committee Review of High Risk and agentic AI systems, policy approval, and annual governance audit.
- AI System: A machine-based system designed to operate with varying levels of autonomy that generates outputs such as predictions, recommendations, decisions, or content (ISO 42001 / EU AI Act).
- AI System Record: The unified document combining the registration form for every AI system. Completed at intake and updated throughout the system lifecycle.
- AI Impact Assessment (AIIA): A structured evaluation of the potential risks, impacts, and mitigations for a High Risk AI system prior to deployment.
- Conformity Assessment: A procedure verifying that a High Risk AI system meets applicable requirements before it is placed on the market or put into service (EU AI Act Art. 43).
- Data Drift: A statistically significant change in the distribution of input data provided to a deployed AI model, which may degrade model performance.
- Explainability: The degree to which the internal mechanics and outputs of an AI system can be understood and communicated to a defined audience.
- FERPA: Family Educational Rights and Privacy Act -- U.S. federal law protecting the privacy of student education records.
- Foundation Model: A large AI model trained on broad data at scale, adaptable to a wide range of downstream tasks (e.g., large language models, multimodal models).
- HIPAA: Health Insurance Portability and Accountability Act -- U.S. law governing the privacy and security of protected health information (PHI).
- IRB: Institutional Review Board -- the ethics committee responsible for reviewing research involving human subjects, including AI-assisted research.
- Kill switch: A mechanism allowing an authorized operator to immediately halt an agentic system's execution, releasing all acquired permissions.
- Shared responsibility: The governance model in which AI deployers self-certify and take accountability for lower-risk systems, reducing the bottleneck of centralized review.
- Workload identity: A non-human identity (service account or cryptographically signed credential) used by an automated system or agent to authenticate to other systems.
