A colleague wants to deploy an AI-written app.
Do not begin with yes or no. Begin with purpose, information, access, ownership and the route back when it fails.
Updated 10 September 2026 · Release worksheet and worked example
The production gate
What the useful demonstration does not prove
Purpose
What school problem does it solve, and what is the manual alternative?
Ownership
Name the business owner and a technical owner who can recover it.
Information
Record what enters, leaves, persists and is deleted.
Access
Use school identity, least privilege and separately stored secrets.
Delivery
Use a school-owned repository, repeatable build and controlled deployment.
Testing
Unit, security and regression checks must run before production.
Operations
Logs, alerts, capacity, backup, restore and a support route.
Exit
A documented retirement or replacement path if the creator leaves.
A natural response
“The idea may be valuable. Let’s keep the prototype moving while we register the owner, information, access, hosting, tests, costs and support route.”
When it becomes business-critical
The creator’s promise is not a support model.
An application may begin as a useful shortcut and quietly become essential to admissions, cover, reporting or communications. Once other people rely on it, the school needs measurable reliability, dependency updates, regression testing, capacity planning, recovery and a second person who understands the service.
1. Separate AI-written code from an app that uses AI
An app can be written with an AI assistant and run without sending information to an AI service. Another app may send every prompt, attachment or database record to a model provider. Record which situation you actually have. Review the deployed code, hosting, logs and external services; the author’s recollection of a prompt is not an inventory.
Start the worksheet with one sentence describing the task, the people who will use it and the consequence of an incorrect result. Draw the data route in plain words: input → application → storage or external service → output → deletion. Name the person who can approve each destination. Use synthetic data during the prototype.
2. Test the failure that would matter
Choose tests from the app’s purpose. Record the account used, expected result, actual result and evidence. A screenshot of the happy path is useful, but it cannot demonstrate access control or recovery.
| Risk | Useful test | Pass evidence |
|---|---|---|
| One user sees another user’s records | Use two separate test accounts and try direct access to each other’s record URL. | The server refuses unauthorised access, including outside the normal screen flow. |
| A failed save looks successful | Interrupt the connection and simulate the storage service being unavailable. | The app explains the failure, preserves useful input and does not invent a saved record. |
| Repeated clicks duplicate an action | Submit the same request twice and retry after a delayed response. | The result follows an explicit duplication rule; an email, booking or charge is not accidentally repeated. |
| Someone cannot use the interface | Complete the main task by keyboard, with zoom and with assistive technology where needed. | Labels, focus, errors and the completion message remain usable. |
| The creator leaves or the service fails | A second authorised person restores a test backup and deploys the recorded version. | They recover the service using school-owned access and written instructions. |
If the deployed app calls a model, add tests for inappropriate disclosure, misleading output and instructions embedded in uploaded material. Restrict the model’s ability to trigger actions. A generated answer must not silently become an authoritative pupil record or an unreviewed decision.
3. Worked example: a classroom equipment booking app
Illustrative case. A teacher has built a useful booking prototype using an AI coding assistant. It stores staff email addresses, room names and bookings. It does not need pupil information or a live model API.
The team removes the unused model integration, moves the repository and hosting into school ownership and uses school sign-in. A two-account test reveals that changing the booking ID in a URL exposes another member of staff’s booking. The technical owner fixes and retests server-side authorisation before release.
A small staff pilot then checks conflicting bookings, cancellations, keyboard use and recovery from a failed save. The business owner accepts the remaining limitations, names a support contact and retains a simple manual booking route. Only the agreed staff group receives access. The example demonstrates a release process, not a certification of any particular application.
4. Make the decision reviewable
Record the version, business and technical owners, approved data, permitted users, test evidence, support route, cost limit, recovery instructions and next review date. Choose prototype only, limited pilot or approved for the stated use. Write the conditions alongside the decision.
Reopen the decision when the app takes new data, gains public users, connects to a model or becomes essential to a school process. The downloadable worksheet gives the next reviewer somewhere to start. In a US district, include the district’s application approval and student privacy review; in other settings, use the equivalent local process.