Campus AI Development Use case scenarios

Use case scenarios 01 of 08

Scenario 01

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.

Most governedLeast governed

Questions to consider

Six lenses from the scenario framework. Any answer that raises the stakes moves this scenario toward stricter controls; take your answers to the chooser.

01 Data What it touches and how that data is classified
  1. Which FERPA-protected fields does it read or write, and has the data steward approved each one?
  2. Is test data synthetic or masked?
02 Audience Who relies on it, and what happens if it’s wrong
  1. Which advisors and students act on its flags, and what happens when a flag is wrong?
  2. Has the outreach logic been checked for disparate impact?
03 Lifespan How long it lives and who maintains it
  1. Who maintains it in three years, and is the spec enough for them?
  2. What happens at the next student information system upgrade?
04 Reach What it can read, write or break
  1. What can the service account write, and could it be narrower?
  2. What is the rollback if a release corrupts records?
05 Verification How you’ll know it’s right, and keep knowing
  1. Does every acceptance criterion have a test?
  2. Can the reviewer explain each agent-written diff they approve?
06 Accountability Who owns it, approves it and discloses it
  1. Who signs the go/no-go?
  2. Is it recorded in the agent registry and change log?

How the work goes

  1. 01SpikeExplore the vendor APIs with an agent in a sandbox, then throw the code away.
  2. 02SpecifyWrite requirements, acceptance criteria and non-goals; review them with the registrar and the data steward.
  3. 03BuildAgents implement scoped tasks against the spec in feature branches.
  4. 04Review and gateHumans review every diff; automated security, accessibility and test gates run on every merge.
  5. 05Release and operateChange advisory approval, production with audit logs and a named owner on call.

Proportionate controls

T5 · Critical

Governance should match the risk: enough to protect people and data, no more. Each control area keeps its own tier on the five-tier scale, and those are the controls to apply. The baseline is a label for the project as a whole, taken from its highest area.

  1. Review T5 Independent review plus security, accessibility and equity sign-off
  2. Documentation T5 Spec traced to tests, decision records and an impact assessment
  3. Approval T5 An executive owner signs the go/no-go after legal and privacy review
  4. Data T4 Confidential records at scale (Level 3, such as FERPA and GLBA data) with steward approval and minimization
  5. Access T5 Least privilege, time-limited credentials and separation of duties
  6. Testing T5 All of that plus evaluations and red-teaming
  7. Monitoring T5 Continuous monitoring, an incident runbook and periodic audit
Raises the tier
  • Agents gain write access to production or act without a human in the loop
  • The logic moves into admissions, aid or discipline decisions
Legal triggers that raise it →
Over-governing looks like
  • Running full change advisory for a copy edit
  • Requiring an impact assessment for internal tooling only the team uses
Excess controls push builders toward unsanctioned tools.
Minimum controls
  • A written spec traced to tests
  • Human review of every diff before merge
  • Security, accessibility and equity review as release gates
  • Scoped service accounts; agents never hold production credentials
  • A named owner and audit logs
Watch for
  • Review falling behind the volume of agent output
  • Specs drifting from the code
  • Over-trust in an AI first-pass review
When it moves up

This is already the most governed scenario. The next step is multi-agent orchestration, which adds the need for an agent registry and budgets (see operating controls).