Policy before tooling. Work through these with the offices named, record an owner for each, and revisit when tools, models or law change. Controls scale with the stakes: apply the strictest answer area by area, not to the whole project.
Settle these before licensing tools or enabling agents.
| # | Item | Suggested owner | Owner | Status |
|---|---|---|---|---|
| A1 | Which data classifications may be sent to which AI tools? | Security · Data governance | YesPartlyNo | |
| A2 | Do contracts cover FERPA, retention, and no training on institutional data? | Procurement · Legal | YesPartlyNo | |
| A3 | Who is accountable for AI-generated code that reaches production? | IT leadership | YesPartlyNo | |
| A4 | What disclosure is expected from students, staff and researchers? | Provost · Research office | YesPartlyNo | |
| A5 | How are assessments redesigned so learning is still demonstrated? | Faculty senate · Teaching center | YesPartlyNo | |
| A6 | Are agents sandboxed with scoped, revocable credentials? | Security engineering | YesPartlyNo | |
| A7 | Is accessibility testing a release gate for AI-built software? | Accessibility office | YesPartlyNo | |
| A8 | How are licenses of generated and suggested code reviewed? | Legal · Open-source office | YesPartlyNo | |
| A9 | Is equitable access to licensed tools guaranteed for every student? | Student success · IT | YesPartlyNo | |
| A10 | Which delivery and learning outcomes will tell you it is working? | Institutional research | YesPartlyNo | |
| A11 | Is there a registry of agents and automations, each with a named owner? | Security · IT operations | YesPartlyNo | |
| A12 | Are budgets, rate limits and a kill switch set for shared AI resources? | IT finance · Platform team | YesPartlyNo | |
| A13 | Are shared data definitions and stewards in place before agents reach a system? | Data governance · Institutional research | YesPartlyNo |
Once building is cheap, these show what was built, what it can reach and what it costs.
| # | Item | Suggested owner | Owner | Status |
|---|---|---|---|---|
| B1 | A registry of agents and automationsEvery agent, scheduled job and automation that touches institutional systems is listed with its owner, purpose, data it reads, systems it writes to and review date. See campusairegistry.com for a registry model. | Security · IT operations | YesPartlyNo | |
| B2 | Scoped, revocable credentialsEach agent gets its own service identity with the narrowest scope, never a person’s login. Credentials expire and can be revoked in one place. | Identity and access management | YesPartlyNo | |
| B3 | Budgets and rate limitsPer-team token and API budgets, alerts at thresholds and a kill switch, so one runaway loop can’t drain a shared pool. | IT finance · Platform team | YesPartlyNo | |
| B4 | Audit logs that outlive the builderActions are logged to a central store the builder can’t edit, kept on the institution’s retention schedule rather than in a personal account. | Security operations | YesPartlyNo | |
| B5 | Shared-resource limitsQuotas on compute, storage and calls to the student information system and other shared systems, enforced by the platform rather than by goodwill. | Enterprise architecture | YesPartlyNo | |
| B6 | OffboardingWhen a builder leaves or changes role, their agents are reassigned or retired, and their credentials revoked, as part of normal offboarding. | HR · IT service management | YesPartlyNo | |
| B7 | A catalog of approved modelsWhich AI models are approved for which uses and data levels, which tools depend on each, and when each will be retired, so a model change doesn’t break tools without warning. | IT architecture · Procurement | YesPartlyNo | |
| B8 | A quality gate before an agent is sharedAn agent built for one person can be anything. Before others can use it, it passes automated tests and a human check for fit with campus policy, scaled to the risk. | Platform team · Unit leads | YesPartlyNo | |
| B9 | No agent as a back doorAn agent may use only the tools it is explicitly allowed, and never more than the person invoking it could reach. The same applies when one agent calls another. | Identity · Security | YesPartlyNo | |
| B10 | Enough lineage to explain a decisionLog agent and tool calls well enough to reconstruct how an outcome was reached, such as an advising flag or eligibility result, without storing every intermediate step or more personal data than needed. | Data stewards · Compliance | YesPartlyNo | |
| B11 | Regular access reviewsReview who and what can reach each agent on a schedule, with a clear route to escalate violations and adjust policy from experience. | Security · Internal audit | YesPartlyNo |
For every tool headed to production: does it fit the systems and processes already in place?
| # | Item | Suggested owner | Owner | Status |
|---|---|---|---|---|
| C1 | No existing system already does thisThe capability was checked against current systems; extending one was considered first. | Enterprise architecture | YesPartlyNo | |
| C2 | System of record named for each kind of dataThe tool reads from the authoritative source rather than keeping its own copy. | Data governance | YesPartlyNo | |
| C3 | Process owner agreesThe office that owns the process confirms the tool fits how the work should be done. | Business process owner | YesPartlyNo | |
| C4 | Connected the approved wayPublished APIs or events, not exports, screen scraping or shared spreadsheets. | Integration · IT architecture | YesPartlyNo | |
| C5 | Recorded in the enterprise catalogCapabilities, data, classification, recovery priority and AI profile. See campusenterprisemodel.com. | Enterprise architecture | YesPartlyNo |
For every production agent: what it may do, and what people will assume it can do.
| # | Item | Suggested owner | Owner | Status |
|---|---|---|---|---|
| D1 | A named owner and a “never” listOne accountable person, a narrow purpose, a clear finish line, things it must never do, and a named approver for changes. | Agent’s named owner | YesPartlyNo | |
| D2 | Limits the agent can’t widenSeparate credentials, approved tools and destinations, off-limits data, spending limits, and sub-agents with no more scope than their parent. | Agent’s named owner | YesPartlyNo | |
| D3 | Oversight decided per actionApprove beforehand, watch live or review afterwards, and what happens if the person doesn’t respond. | Agent’s named owner | YesPartlyNo | |
| D4 | A pause, a stop and tamper-evident logsA soft pause, a hard stop that revokes credentials, and logs outside the agent’s control. | Agent’s named owner | YesPartlyNo |
Campus AI Development is an independent project offering recommendations, not requirements, legal advice or institutional policy. Explanations, sources and the full guide: campusaidev.com/governance.