The leadership page covers what to govern and who decides. This is the operational layer: a sequenced path, the AI security threats and controls, an incident runbook, the identity-and-data plumbing, a reference architecture, build-vs-buy with real cost, procurement teeth, and what to monitor.
Starting points to adapt to local security policy, not a substitute for it. Threat names map to the OWASP Top 10 for LLM Applications; control and contract language should be reviewed against your own standards, security team, and counsel.
The journey is implied across several tools, here it is sequenced, from surfacing a system to running it safely.
Inventory the system, including AI switched on inside tools you already license, and give it a record: owner, purpose, data classes, vendor.
AI Registry & DocsDetermine the highest data class it touches (public → FERPA/PII), who can reach it, and whether your data leaves the boundary or trains a vendor model.
System & data cardsRight-size scrutiny to risk. Vet the tool, the data terms, and the security posture before it ships; capture the contract teeth you need.
Tool Evaluation MatrixSet logging, alerts, and a named incident path before go-live. Operate on a cadence; review drift, cost, and override rates.
Run itMost decisions are really one question: is this a fast approval or a full review? Triage on three axes: the data it touches, how much it can act on its own, and who's exposed.
The threats your CISO will ask about on page one, framed for campus, each mapped to the OWASP LLM Top 10 with a concrete control.
Hidden instructions in user input or fetched content hijack the model's behavior.
On campusA student pastes text that makes a grading assistant ignore its rubric, or a malicious web page redirects a research agent.
ControlTreat all model input as untrusted, constrain tool/permission scope, and keep a human on any consequential action.
The model surfaces data it shouldn't, to the wrong user, or to a vendor that retains it.
On campusStaff paste FERPA-protected records into a personal AI account; a chatbot returns one student's data to another.
ControlDLP at the boundary, no sensitive data into unvetted tools, and contractual no-training / no-retention terms.
Model output is trusted and passed downstream, into SQL, shell, HTML, or emails, without validation.
On campusAn AI feature's output is rendered straight into a page or used to build a query, opening injection or XSS.
ControlValidate and encode every output before it touches another system; never execute model output unguarded.
The system can take more actions, with more autonomy, than the risk justifies.
On campusAn agent wired to the SIS can modify records, not just read them; an integration has write scope it never needs.
ControlLeast privilege on every integration, read-only by default, and explicit approval gates for state changes.
Risk inherited from vendors, plugins, and AI features switched on inside existing systems.
On campusAn LMS or productivity-suite update activates AI that now processes student work under new data terms.
ControlInventory embedded AI, track subprocessors, and re-review vendor terms when features change.
Unmetered usage drives runaway spend or denial-of-wallet, and enables model abuse.
On campusA looping agent or exposed API key burns thousands in tokens over a weekend before anyone notices.
ControlRate limits, budget caps with alerts, key rotation, and per-app quotas at the gateway.
When an AI feature leaks FERPA data on a Tuesday, the first hour decides the blast radius. Pre-agree this runbook so no one improvises.
Confirm it's real, assign an incident lead, and classify severity by data class and exposure. Open the incident channel.
Disable the feature or integration, revoke keys/tokens, and cut the data path. Preserve prompt/response and access logs before anything is wiped.
Determine what data was exposed, whose, and to whom. Map it to FERPA / breach-notification triggers and data-residency obligations.
Engage legal, privacy, and the CISO; brief comms. Start the clock on contractual and regulatory notification SLAs.
Fix the root cause, rotate credentials, restore service under tighter scope, and document the timeline.
Blameless review; feed the lesson into policy, the registry entry, and the controls so it can't recur the same way.
This runbook isn't new ground, it maps to the incident-response lifecycle institutions already follow. Run AI incidents through your existing CSIRT and plan, this just names the AI-specific moves at each phase.
Detect & triage, contain, assess, notify, remediate, and post-incident review follow its preparation → detection/analysis → containment/eradication/recovery → post-event lifecycle.
Preparation, Identification, Containment, Eradication, Recovery, Lessons-learned, the phases here in the same order.
Plan-and-prepare, detect-and-report, assess-and-decide, respond, learn, the same managed cycle, useful if you're ISO-aligned.
The technical runbook stops the bleeding; communication decides whether people keep trusting you. When an AI system causes harm, a biased decision, a privacy exposure, a wrong answer that reached someone, the response is as much reputational as technical. Agree these moves before you need them.
Pre-draft holding statements and an escalation tree the same way you pre-agree the technical runbook. The worst time to design your communications is mid-incident.
"Govern by data" is easy to say, the hard part is the plumbing. Six controls that make it real.
Every AI tool behind institutional SSO/MFA, no shared or personal accounts. Deprovisioning (SCIM) removes access the day someone leaves.
API keys vaulted, scoped, and rotated. Never embedded in client code or notebooks. One key per app, revocable independently.
Inspect and block sensitive data classes before they reach an external model. Make the safe path the default path.
Know where prompts, outputs, and any retrieval data physically live, and whether that satisfies your obligations and contracts.
Define how long prompts, outputs, and logs persist, and prove deletion. Confirm the vendor doesn't retain or train on your data.
Capture an audit trail of who-asked-what-and-what-came-back, while masking secrets and minimizing sensitive content in the logs themselves.
AI doesn't land on a clean field. It has to live with the SIS, LMS, ERP, IdP, and data warehouse. A layered reference keeps governance at the seams.
The pieces above are also a process. Read top to bottom, it's how an AI service goes from need to managed vendor, with each step pointing to the detail that governs it.
Name the problem and the highest data class it would touch, public through FERPA/PII. The data class drives everything that follows.
See: Rapid risk triageDecide whether this is an embedded vendor feature, a licensed platform, or built on a model API, and price the real total cost, not the sticker.
See: Build, buy, or embeddedTriage to a light path or a full review on three axes: the data it touches, how much it can act on its own, and who's exposed.
See: Rapid risk triageVet the tool against the AI security layer and score it before it ships. Right-size scrutiny to risk.
Tool Evaluation MatrixThe cheapest moment to govern AI is before you sign. Require the DPA clauses, no training, deletion, subprocessor notice, breach SLA, residency, attestations, accessibility, audit.
See: Procurement & contract teethPut it behind SSO/MFA, vault and scope its keys, set DLP at the boundary, and define retention and deletion before anyone uses it.
See: Identity, access & the data pipelineTurn on logging and alerts, operate on a cadence, and re-review vendor terms when features or subprocessors change.
Run itDecide up front how this ends: how you get data out, prove deletion, and stand down the tool if the vendor fails, is acquired, or you move on. Exit is a procurement decision, not an afterthought.
See: Decommissioning & vendor exitThree paths, when each fits, and the catch. The cabinet sees budget tiers; your team sees total cost of ownership.
Best whenThe capability is a small part of a tool you already run and the data terms are acceptable.
Fastest path; no new infrastructure.
You inherit their model, data handling, and change cadence, and may not even control when it turns on.
Best whenYou need breadth across the institution and want a vendor to carry the operational load.
Managed, supported, quicker to scale.
Lock-in and per-seat cost; the governance and data accountability are still yours.
Best whenThe use case is differentiated, sensitive, or needs tight control of data and behavior.
Full control of data, prompts, and integration.
You own everything, security, monitoring, and the FTE to run it, for the life of the system.
The cheapest moment to govern AI is before you sign. The clauses to require in the contract or data-processing addendum, and why each one earns its place.
Without an explicit opt-out, your institutional and student data can become training material you can't claw back.
You need a guaranteed, provable path to get data out and have it destroyed when the contract ends.
The vendor's vendors touch your data. You can't govern what you can't see, or be surprised by a new one.
A defined notification window is what lets you meet your own regulatory and contractual clocks.
Where data is processed and stored drives FERPA, export, and sometimes state obligations.
Independent evidence of controls beats a vendor's marketing claims, and satisfies audit.
A current, honest VPAT is a procurement gate, deploying an inaccessible tool is legal and equity exposure.
You may have to explain a consequential AI decision; you need access to the documentation to do it.
Every AI service ends, retired, replaced, or the vendor is acquired or shuts down. An exit you didn't plan is where data gets stranded and obligations get missed. Plan it while you still have leverage: before you sign.
The clauses that make a clean exit possible, deletion and return, data portability, and audit rights, are the same DPA teeth you negotiate at procurement. Exit planning and contracting are one decision, made at the start.
Set this before go-live, not after the first surprise. What to log, what to alert on, and an audit trail that survives a records request.
Build the audit trail to survive a public-records or FERPA request, complete, tamper-evident, and retained to policy, without itself becoming a sensitive-data store.