Scaling to production

A few experiments will become tools others depend on. Scaling takes gates matched to risk, people who can review and support the work, and someone watching the whole portfolio.

Pathway

Experiment → pilot → production

Each step adds the least structure that’s still safe. Most experiments should end as experiments; the gates are for the ones others come to rely on.

	Experiment	Pilot	Production
Who uses it	The builder	A defined group, for a set time	Others depend on it
Data	Public or synthetic	Internal; confidential with steward approval	As classified, in an approved environment
Control tier	T1–T2	T2–T3	T3–T5, set by data and audience
Validation	Does it do the job?	Acceptance criteria tested with real users	Tests from the spec in CI; accessibility testing; protected test files
Security for AI-generated code	No secrets in code; no production credentials	Dependency and secret scanning; scoped credentials	Static analysis, dependency checks, human review of every diff including removals; security review at tier
Data protection	Nothing leaves the sandbox	Minimum necessary data; access logged	Retention, role-based access and audit logs outside the builder’s control
Ownership	The builder	Named owner, review date, registry entry	Named owner and backup, support path, offboarding plan
Gate to the next step	Someone else wants to use it	Pilot measures met and an owner accepts it	Reviewed against the tier on a schedule

The gates draw on the promotion signals, the control tiers, shared responsibility and the governance checklist.

Team development

Growing builders and reviewers

Skills spread through people who have done the work. Most institutions start with a community of practice and formalize it as demand grows.

01Orientation for every builderApproved tools, data classification, the registry and who to ask. Required before using a shared or institutional environment.
02Role-based tracksSpec writing and acceptance criteria for analysts, agent scoping and verification for IT, critical review for faculty and students. See competencies.
03A pool of approved reviewersPeople trained to review T3 and above: diffs, tests and data access. Builders rotate in as they gain experience.
04Time in job descriptionsBuilding and reviewing count as work. When it happens on nights and weekends, it stops when the builder leaves.
05Shared playbooksSpecs, prompts, guardrail files and incident notes, kept in one place the community maintains.

Support model

Who keeps it running

Support has to grow with the number of tools. Set it by tier, and agree who pays before launch.

Tier	Who supports it	Response	Funding
T1–T2	The builder	Best effort, with no promise to others	The builder’s unit
T3	The owning unit, with a named backup; IT for platform issues	Business hours, agreed with users	Unit budget
T4–T5	Shared with IT or a platform team, which takes operational ownership	A formal service level, with on-call where needed	Central funding or chargeback, agreed before production

Signs a tool needs a new home

01Users outside the owning unitOther departments now rely on it.
02More sensitive dataIt has started touching confidential or restricted data.
03The builder is leavingReassign it, hand it to IT or retire it before they go.
04Repeated incidentsOutages or errors the owning unit can’t fix on its own.

Broader adoption

From many tools to a portfolio

As use spreads, the risk moves from single tools to overlap, drift and tools nobody remembers. Someone has to manage the whole set.

01Publish what’s approvedA catalog of approved tools, models and templates, so people start from what exists. Enterprise fit
02Reuse before rebuildingShared components for sign-in, logging and integrations, so each tool doesn’t solve them again.
03Report outcomesEach tool’s success measure from the opportunity filter, reported at its review date.
04Review the portfolio yearlyMerge overlapping tools, retire unused ones and promote the ones others depend on.
05Share across institutionsSpecs, guardrails and lessons travel well, and peer institutions are solving the same problems.

Next: see campus practices, or use the governance checklist.