AI Pilot Framework · Michelle Blomberg

A short, shared path for faculty and staff to take an AI prototype off a personal server and run it as a safe, district-hosted pilot with real faculty, staff, and students, then move a successful pilot into production. Draft for the district AI CIO’s input.

Why this exists

Faculty are already building useful AI tools, for student-services routing, career readiness, and course design, but they run on personal servers with no safe, shared way to pilot them with real users. The campuses have not provided one. This proposes a district-hosted lane so pilots are safe, comparable, and portable, rather than one-off experiments that live and die on an individual’s laptop.

How to request a pilot

A one-page intake, so the bar to start is low and the request is easy to review:

Project and purpose. Name and one line on the problem it solves.
Who it serves. Faculty, staff, or students, and roughly how many.
Data it touches. None, de-identified, or student records.
AI it uses. Which models or APIs.
What you are asking for. Hosting, an approved API path, and review (below).
Pilot length and success measure. Usually one term, and the single thing that would prove it worked.
Sponsor. A faculty or staff owner accountable for it.

A named reviewer responds within a set window, so a request does not disappear.

What you are asking the district for

Safe hosting. A district-controlled sandbox, isolated from production and student-record systems, where the tool runs in a container (see the Docker note).
An approved AI path. Vetted models and APIs under a district agreement, so faculty are not running user-facing tools on personal keys.
A short review against the guardrails, sized to the risk.

Guardrails that make it safe

Data minimization by default. Collect the least possible; no student PII unless the pilot truly needs it and it passes review.
FERPA and privacy. Any student data needs a purpose and a data-use agreement; prefer de-identified or synthetic data in pilots.
Isolation. Pilots run contained, with no direct access to the student-information system.
Approved AI only. Under agreements that bar using institutional data to train vendor models.
Human in the loop. The tool assists; a person decides. No high-stakes automated decisions about students.
Transparency. Users are told it is a pilot, what it collects, and why.
A sunset date. Every pilot ends and is renewed or turned off, never left running unattended.

Data and APIs in pilots

The default is no student data. The strongest pilots are data-sovereign by design: first name only, stored on the user’s own device, anonymized aggregates, so most need no student records at all. APIs are allowed, but only district-approved ones, never personal keys for anything user-facing, and never sending student PII to a model that trains on it. If a pilot genuinely needs student data, it routes through review and a data-use agreement and is de-identified wherever possible. When in doubt, build the tool so it never sees the sensitive data in the first place.

What success means, and moving to production

Success is the single measure named in the request, met during the pilot, plus three checks: it passed security, accessibility (WCAG), and data review; faculty, staff, or student feedback was positive; and there is a sustainable owner and support plan. A tool that clears those moves from the sandbox to monitored production hosting with a named maintainer. One that does not is documented and retired or revised. The point of a concrete bar is to prevent “pilot forever.”

A plain note on Docker

Docker is a way to package a tool with everything it needs to run into one sealed container, like a shipping container for software. Because the container is self-contained and identical everywhere, the exact prototype a faculty member built runs the same on a district pilot server and later in production, with no “it worked on my machine” surprises, and it stays walled off from other systems, which is what makes it safe to host. It is the standard, low-cost way to move a prototype onto shared, controlled infrastructure.

This is not from scratch

Established frameworks already cover the hard parts, and this adapts them into a lightweight faculty intake rather than inventing a new theory: the NIST AI Risk Management Framework for risk and guardrails, EDUCAUSE’s AI governance and ethical guidelines for higher-ed structure and values, WCET’s AI policy and practice framework, and FERPA for student data. The contribution here is the short, usable request-and-review path, so faculty who build have somewhere safe to go.

AI Pilot Framework: prototype to production