Campus AI Development Use case scenarios

Use case scenarios 03 of 08

Scenario 03

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.

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. What does a request contain, and which connectors carry it?
  2. Does any data leave the platform?
02 Audience Who relies on it, and what happens if it’s wrong
  1. How many staff and students will use it?
  2. What do they fall back on if it fails?
03 Lifespan How long it lives and who maintains it
  1. Who is the backup owner?
  2. What happens to it when you change jobs?
04 Reach What it can read, write or break
  1. Which systems does the flow write to: email, the student information system, document storage?
  2. Could a misconfigured step send records to the wrong person?
05 Verification How you’ll know it’s right, and keep knowing
  1. Have you tested every approval path, including rejections and timeouts?
  2. Has the center of excellence reviewed it?
06 Accountability Who owns it, approves it and discloses it
  1. Is it in the platform inventory with a named owner?
  2. Who approves changes once it’s live?

How the work goes

  1. 01DraftBuild in a developer environment with sample data.
  2. 02OnboardComplete maker training and request a managed environment.
  3. 03ConnectUse only approved connectors; data policies block the rest.
  4. 04ReviewThe center of excellence reviews the solution before production.
  5. 05OwnName a backup owner and review the app each term.

Proportionate controls

T4 · Institutional

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 T3 Platform or center-of-excellence review before production
  2. Documentation T3 Registered in the inventory with an owner and backup
  3. Approval T3 The system or data owner approves
  4. Data T4 Confidential records at scale (Level 3, such as FERPA and GLBA data) with steward approval and minimization
  5. Access T3 Managed environment with role-based access
  6. Testing T3 Every path tested, including failures; accessibility check; re-test when the model or prompt changes
  7. Monitoring T3 Platform logs and periodic usage review
Raises the tier
  • The flow writes to the student information system
  • It is rolled out campus-wide
Legal triggers that raise it →
Over-governing looks like
  • Line-by-line code review of a low-code flow
  • Demanding a full spec for a three-step approval
Excess controls push builders toward unsanctioned tools.
Minimum controls
  • Managed environments for anything shared
  • Connector data-loss policies
  • Maker onboarding before shared access
  • Solution review before production
  • A named owner and backup
Watch for
  • Connector sprawl
  • Apps orphaned when the maker leaves
  • Per-user licensing that limits who can take part
When it moves up

When the process needs logic the platform can’t express, or deep integration with the student information system, hand it to the enterprise team.