AI Pilot Framework: prototype to production
AI Strategy · Case study
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. Revised and released district-wide by the district AI CIO, and now accepting pilots.
Why this exists
Faculty are already building useful AI tools, for student-services routing, career readiness, and course design, but there is 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 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. 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 note on Docker
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.