Eight builders, eight sets of controls

The same campus AI tools reach very different people. These scenarios run from a governed development team to a student with a course API key. Each lands on a different band or platform track and needs different controls.

A framework for choosing

Six lenses, asked of every scenario

Each scenario page asks the same six questions in its own terms. The strictest answer sets the approach and controls, the same rule as the chooser. See how it fits together.

01DataWhat it touches and how that data is classified
02AudienceWho relies on it, and what happens if it’s wrong
03LifespanHow long it lives and who maintains it
04ReachWhat it can read, write or break
05VerificationHow you’ll know it’s right, and keep knowing
06AccountabilityWho owns it, approves it and discloses it

0104 Spec-driven

Enterprise development team Central IT’s application team is asked to build an integration that brings advising notes into the student information system and flags students for outreach. It will run for years, touch records protected by FERPA and be maintained by people who didn’t write it. Read the scenario →

0203 Agentic

Research software engineer A postdoc vibe-coded an analysis that now underpins a paper. A research software engineer rebuilds it as a pipeline that other groups will run on the cluster and cite. Read the scenario →

03Track A · Low-code

Department platform maker A registrar staff member wants to replace an email-and-spreadsheet process for transcript requests. They describe the process to the low-code platform’s AI, which drafts the form, the approval steps and the notifications. Read the scenario →

04Track B · Enterprise

Functional analyst A finance analyst needs a budget-variance report by department. They ask the enterprise system’s built-in AI to generate the report definition and calculated fields. Read the scenario →

0501 Vibe coding

Business user An office administrator uses the campus AI assistant to write a spreadsheet macro that cleans event registrations, then a small web form for the office. Read the scenario →

0602 AI-assisted

Faculty member An instructor builds a practice-quiz tool for their course with the campus AI platform, then shares it with colleagues teaching other sections. Read the scenario →

0702–03 Assisted to agentic

Student using an AI API A capstone team builds a course-help chatbot that answers questions from course materials. It calls the campus AI gateway with a course-issued API key. Read the scenario →

08Track A · Low-code

Student using an AI platform A student club builds an event sign-up agent in a campus-provided no-code agent builder and shares it with members. Read the scenario →

When a scenario changes, such as an office adopting a business user’s form or a student chatbot opening to a full course, re-run the chooser. The strictest factor sets the new controls.

Discussion cases

Harder cases, no easy answers

Six hypothetical composites built to start arguments in a governance committee, a faculty senate or an IT leadership meeting. Each sets out two defensible views, questions to work through and where the framework points.

Case 01The prototype everyone now depends onTurn it off now — or keep it running and harden it?Open the case → Case 02The agent that drafts the gradesThis is responsible use — or the human review is nominal?Open the case → Case 03The shadow tool that works betterShut it down — or learn from it?Open the case → Case 04The research code nobody can explainThe result stands — or the result is not yet trustworthy?Open the case → Case 05The week one group used most of the budgetCap every group — or caps penalize real research?Open the case → Case 06The vendor agent that arrived switched onSwitch it off until reviewed — or govern it in place?Open the case →

Across every scenario

Shared responsibility

Whoever builds, the work is shared. The institution makes the safe path possible and owns its legal obligations; the builder owns what they ship and the choices they make along the way. Neither side can hand its part to the other, or to an AI tool.

The institution

Makes the safe path possible

01Provide a safe path that is easier than the unsafe oneContracted tools and campus accounts, with data terms that cover the data people actually use. If the approved option is slower than a personal account, people will use the personal account.
02Classify the data and say which tools may touch itPublish the data levels with campus examples, and keep the list of approved tools for each level current.
03Set proportionate controls and staff the reviewsDefine the tiers, name who reviews what, and answer within a reasonable time. A review queue nobody staffs is a policy nobody follows.
04Keep the inventory, budgets and kill switchesKnow which agents, assistants and integrations run on institutional accounts, who owns them, what they cost and how to turn them off.
05Teach, support and plan for exitsOffer training, templates and office hours. Plan for vendor changes, model updates and people leaving.
06Own institutional obligationsAccessibility, privacy, records, security and procurement duties stay with the institution, even when the code was written by someone else or by an agent.

The builder

Owns what they ship

01Know the data before you startCheck its level, use only tools approved for it, and use public or synthetic data where you can.
02Own what you ship, whoever wrote itIf AI wrote it and you run it, it’s yours. Read, test or verify it to the level your tier requires.
03Stay inside the access you were givenAgents should get the narrowest permissions that work. Don’t use personal accounts or tokens for institutional data.
04Disclose and document in proportionSay where AI was used, record what reviewers need, and follow course, journal or funder rules on disclosure.
05Raise your hand when the stakes changeWhen more people rely on it, the data gets more sensitive or something breaks, ask for the next tier instead of waiting to be found.
06Hand it off or shut it downBefore you move on, name a new owner, or retire the tool, its data and its credentials.

How the balance shifts by scenario

The less experience and control a builder has, the more the institution has to provide up front. The more a tool can do, the more the builder must verify.

Scenario	The institution provides	The builder answers for
Central IT team	Enterprise environment, code review, testing pipelines, change control	Every merged change, regardless of how it was written
Functional analyst	Vendor configuration rules, test environments, steward approvals	Configurations and the testing behind them
Platform maker	Licensed platform, connectors, a registry and budgets	Each agent or flow, its permissions and its owner
Business user	Approved assistants, clear data rules, a place to ask for help	What goes into the tool and what gets acted on
Faculty builder	Licensed tools, accessibility support, learning-design guidance	Course tools that are accessible and fair to students
Research software engineer	Research computing, data-steward and IRB processes	Reproducibility, provenance and disclosure
Student on a campus AI platform	The platform, its guardrails and clear course policies	Honest use within course rules
Student using an AI API	Keys or credits, spending limits, guidance on data and security	Keys, costs and any personal data the app collects

Proportionality

Governance in proportion to risk

Too little control exposes people and data. Too much pushes builders to personal accounts and unsanctioned tools, where there is no control at all. Set each control area to the lowest tier that covers its real risk, and apply that area’s controls. The project’s baseline is a label taken from its highest area: it tells reviewers where the most scrutiny belongs, not that every area rises to match.

01Area by area, not all or nothingA student chatbot can need tight access controls and light documentation at the same time.
02Requirements and law set the floorA legal trigger such as FERPA data or a public-facing interface fixes the minimum tier for that area.
03Tiers move with the workRe-tier when users, data or reach change, up or down. Retiring a tool should lower its controls too.

The eight scenarios, area by area

Scenario	Baseline	Review	Documentation	Approval	Data	Access	Testing	Monitoring
Enterprise team	T5 · Critical	T5	T5	T5	T4	T5	T5	T5
Research software engineer	T4 · Institutional	T4	T4	T3	T4	T4	T4	T3
Platform maker	T4 · Institutional	T3	T3	T3	T4	T3	T3	T3
Functional analyst	T4 · Institutional	T3	T3	T3	T4	T3	T3	T2
Business user	T2 · Shared	T1	T1	T1	T2	T1	T1	T1
Faculty member	T3 · Managed	T2	T2	T2	T2	T2	T3	T2
Student with an API	T3 · Managed	T2	T2	T2	T1	T3	T2	T3
Student on a platform	T2 · Shared	T2	T1	T2	T2	T2	T1	T2

What each tier requires

Control area	T1 Personal	T2 Shared	T3 Managed	T4 Institutional	T5 Critical
Review	Self-check against a few hand-verified cases	A colleague looks it over before others rely on it	Platform or center-of-excellence review before production	Human review of every change by someone who can explain it	Independent review plus security, accessibility and equity sign-off
Documentation	A note on what it does and where it lives	A short README: purpose, owner, data used	Registered in the inventory with an owner and backup	A written spec with acceptance criteria and non-goals	Spec traced to tests, decision records and an impact assessment
Approval	None needed	Manager or sponsor is aware	The system or data owner approves	Change advisory approval before each release	An executive owner signs the go/no-go after legal and privacy review
Data	Public or your own data only	Internal data with no restricted fields	Limited confidential data (Level 3) in approved tools under contract	Confidential records at scale (Level 3, such as FERPA and GLBA data) with steward approval and minimization	Restricted data (Level 4) or high-risk uses, in an approved enclave, with an impact assessment
Access	Personal account in a campus-licensed tool	Team space; no shared credentials	Managed environment with role-based access	Scoped service identities; agents never hold production credentials	Least privilege, time-limited credentials and separation of duties
Testing	Spot-check the results	Repeatable checks on sample data	Every path tested, including failures; accessibility check; re-test when the model or prompt changes	Automated tests and security scanning on every change	All of that plus evaluations and red-teaming
Monitoring	None needed	The owner reviews it each term	Platform logs and periodic usage review	Central audit logs, alerts and budgets	Continuous monitoring, an incident runbook and periodic audit