Campus AI Development Use case scenarios

Use case scenarios 07 of 08

Scenario 07

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.

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 goes into prompts, and could classmates’ information end up there?
  2. Is the data synthetic or course material only?
02 Audience Who relies on it, and what happens if it’s wrong
  1. Is it only for the team, or will classmates use it?
  2. What happens if it gives a wrong answer before an exam?
03 Lifespan How long it lives and who maintains it
  1. Does it end with the course, or will it be reused?
  2. Who owns the code and the key after the term?
04 Reach What it can read, write or break
  1. Where is the API key stored, and could it leak to a public repository?
  2. What is the budget, and what happens when it runs out?
05 Verification How you’ll know it’s right, and keep knowing
  1. How will you test answers against the course materials?
  2. How will the instructor tell what the team did from what the model did?
06 Accountability Who owns it, approves it and discloses it
  1. Who is the faculty sponsor?
  2. How is AI use disclosed in the submission?

How the work goes

  1. 01Request keysThe instructor requests course-scoped keys through the developer program.
  2. 02BuildThe team uses synthetic data and course materials only.
  3. 03Run through the gatewayThe gateway enforces the budget and logs every call.
  4. 04Sponsor reviewThe faculty sponsor reviews it before classmates use it.
  5. 05Close outKeys expire at term end; the project is archived or handed off.

Proportionate controls

T3 · Managed

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 T2 A colleague looks it over before others rely on it
  2. Documentation T2 A short README: purpose, owner, data used
  3. Approval T2 Manager or sponsor is aware
  4. Data T1 Public or your own data only
  5. Access T3 Managed environment with role-based access
  6. Testing T2 Repeatable checks on sample data
  7. Monitoring T3 Platform logs and periodic usage review
Raises the tier
  • Classmates use it for graded work
  • Any real student data reaches it
Legal triggers that raise it →
Over-governing looks like
  • Treating a course prototype like a production system
  • Denying API access instead of issuing scoped, budgeted keys
Excess controls push builders toward unsanctioned tools.
Minimum controls
  • A course-scoped key with a budget and end date
  • Synthetic data only
  • No access to other students’ records
  • A faculty sponsor
  • Disclosure in the submission
Watch for
  • Keys committed to public repositories
  • Runaway costs
  • Classmates’ data entered into prompts
  • Integrity of graded work
When it moves up

If the chatbot is adopted for next term’s course, treat it as a staff tool: register it and add review, as for a faculty builder.