Campus AI Development Discussion cases
Try

No results for “{{ query }}”. Try a shorter or more general term.
  1. {{ r.p }} {{ r.h }} {{ r.pre }}{{ r.hit }}{{ r.post }}
{{ searchCount }}Enter opens · ↑↓ move · Esc closes

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 →

Discussion case 01

The prototype everyone now depends on

An advising coordinator vibe-coded a scheduling helper for herself. Eighteen months later, forty advisors use it every day, it reads student records through her credentials, and she leaves the university in two weeks. Nobody else understands how it works.

A hypothetical composite for discussion, not an account of a real institution.

The tension

One viewTurn it off nowIt holds student records through one person’s login, has no owner after she leaves, and was never reviewed. Every day it runs is unmanaged FERPA exposure.
Another viewKeep it running and harden itAdvisors rely on it during registration. Shutting it down pushes them back to spreadsheets and email, which carry their own risks, and punishes the person who solved a real problem.

Questions for discussion

  1. 01Who owns this tool the day she leaves, and who decides?
  2. 02Is two weeks enough to move it to a supported platform, or only enough to document it?
  3. 03What interim controls would make it acceptable for one more term?
  4. 04How did a personal tool reach forty users without anyone noticing, and what would have caught it?
  5. 05Should she be thanked, disciplined or both?
What the framework suggests
  • Audience and data have both moved: it now needs formal review.
  • Data is Level 3 Confidential, so contracted tools, steward approval and scoped credentials apply.
  • Proportionality cuts both ways: an abrupt shutdown has costs the framework counts too.
Where reasonable people disagree
  • Whether a working tool earns a grace period
  • Whether the builder or her manager carries the accountability
  • Whether the fix is a platform rebuild or retirement

Discussion case 02

The agent that drafts the grades

An instructor teaching 300 students builds an agent that reads each submission, drafts feedback and proposes a grade. Teaching assistants approve each one with a single click. Turnaround drops from two weeks to two days, and students say the feedback is more detailed than before.

A hypothetical composite for discussion, not an account of a real institution.

The tension

One viewThis is responsible useA human approves every grade, feedback is faster and richer, and TAs can spend their time on the students who need them most.
Another viewThe human review is nominalA one-click approval across 300 submissions isn’t meaningful oversight. Grades are consequential decisions, and students weren’t asked or told.

Questions for discussion

  1. 01What would make a TA’s approval real review rather than a rubber stamp?
  2. 02Should students be told an AI drafted their feedback and grade? Before or after?
  3. 03How would a student appeal, and to whom?
  4. 04Does it matter whether any of the 300 students are in the EU?
  5. 05Would your answer change if the agent only drafted feedback and never proposed a grade?
What the framework suggests
  • Grades shape decisions about people, which is a legal trigger in several regimes.
  • Review, approval and monitoring need formal-review strength even if documentation stays light.
  • Disclosure belongs in the Accountability question.
Where reasonable people disagree
  • What counts as a human in the loop
  • Whether efficiency gains justify the change without student consent
  • Where feedback ends and evaluation begins

Discussion case 03

The shadow tool that works better

A college office built a request-tracking app on a free no-code platform with an AI builder. It is faster and better liked than the official ticketing system. Central IT discovered it during an audit and wants it shut down because it stores student names on an unapproved service.

A hypothetical composite for discussion, not an account of a real institution.

The tension

One viewShut it downIt sits outside every contract, policy and security control. Tolerating it invites every office to do the same.
Another viewLearn from itIt exists because the official system failed its users. Shutting it down without a better alternative sends people further underground.

Questions for discussion

  1. 01Is the problem the tool, the data in it, or the platform it runs on?
  2. 02Could the same app be rebuilt on a governed platform in weeks rather than months?
  3. 03What would IT need to offer so the next office doesn’t build in the shadows?
  4. 04Who should pay for the rebuild?
  5. 05How should the audit finding be written so it improves the official system too?
  6. 06Does an official system already cover this capability? If not, who owns the gap?
What the framework suggests
  • The data, not the builder, sets the ceiling: student names make it Level 3.
  • Governed platforms exist for exactly this case.
  • Over-governing pushes people to personal accounts; the cost of caution is real.
Where reasonable people disagree
  • Whether shadow IT is a compliance failure or a service signal
  • How quickly IT should be expected to offer an alternative
  • Who is accountable for the office’s data

Discussion case 04

The research code nobody can explain

A lab’s key result rests on an analysis pipeline written almost entirely by a coding agent. The paper is under review. A reviewer asks the team to explain one transformation step, and nobody in the lab can say why it works, only that the outputs looked right.

A hypothetical composite for discussion, not an account of a real institution.

The tension

One viewThe result standsThe pipeline ran, outputs matched expectations, and researchers have always used code they didn’t write, from statistical packages to libraries.
Another viewThe result is not yet trustworthyCode that no one can explain is a method no one can defend. The lab should verify before publishing, even if it delays the paper.

Questions for discussion

  1. 01Is using unexplained AI-written code different from using an unexplained statistical package?
  2. 02What would count as enough verification: tests, a hand-checked subset, an independent rebuild?
  3. 03What should the methods section disclose?
  4. 04Who in the lab is accountable for the code’s correctness?
  5. 05Should the department set a standard, or leave it to each PI?
What the framework suggests
  • Verification and accountability are the questions at stake.
  • Research integrity is one of the guide’s stakes, and provenance is part of the method.
  • The research software engineer scenario shows the rebuild path.
Where reasonable people disagree
  • How much understanding a researcher owes their own code
  • Whether disclosure is enough without verification
  • Who sets the standard: journals, departments or labs

Discussion case 05

The week one group used most of the budget

The campus pools a single AI license across schools. In the first week of term, one research group’s agents, stuck in retry loops, consumed most of the month’s shared budget. Teaching assistants and student services lose access for the rest of the month.

A hypothetical composite for discussion, not an account of a real institution.

The tension

One viewCap every groupHard per-group budgets would have stopped this. Shared resources need enforced limits, not trust.
Another viewCaps penalize real researchResearch workloads are bursty by nature. Rigid caps slow the work the license was bought to support, and most groups never come close.

Questions for discussion

  1. 01Who should have been alerted, and when?
  2. 02Should teaching and student services have protected capacity?
  3. 03Is it fair to bill the group that caused the overrun?
  4. 04What is the right balance between alerts, soft limits and hard caps?
  5. 05Who decides priorities when the pool runs low mid-term?
What the framework suggests
  • This is the shared-pool failure described in the governance chapter.
  • Monitoring and access controls, not documentation, are the controls that matter here.
  • Equity of access is one of the stakes: who loses first when the pool runs dry?
Where reasonable people disagree
  • Hard caps versus alerts and soft limits
  • Whether teaching gets priority over research
  • Who pays for overruns

Discussion case 06

The vendor agent that arrived switched on

A routine release of the campus’s enterprise system turned on a new AI agent by default. It can read and update records across modules through the system’s integration account. Functional staff are already using it to fix data in bulk. No one in IT approved it.

A hypothetical composite for discussion, not an account of a real institution.

The tension

One viewSwitch it off until reviewedIt acts through a broad service account, nobody assessed it, and bulk changes to institutional records need change control.
Another viewGovern it in placeStaff find it useful, the vendor is already under contract, and switching it off loses goodwill and productivity while a review drags on.

Questions for discussion

  1. 01Does the existing vendor contract cover this feature’s data use?
  2. 02What should an agent be allowed to change without a human approving each change?
  3. 03How would you find and reverse a bad bulk update?
  4. 04Should vendor AI features require opt-in at your institution?
  5. 05Who owns the decision: the system owner, IT security or procurement?
What the framework suggests
  • Enterprise configuration is covered on the platforms page.
  • Reach is the question at stake: what it can write, and how much it could break.
  • Access and monitoring need formal review; the registry should list vendor agents too.
Where reasonable people disagree
  • Default-on versus opt-in for vendor AI
  • How much review a contracted vendor feature needs
  • Whether staff who already used it did anything wrong