Private AI readiness checklist for business teams.

How to use this checklist

Copy the items into whatever your team uses to track work. Assign one owner per item, not a group. For each item record the decision, the date, and where the evidence lives. Review the list at the start of the pilot, at the end, and before any expansion. Items that do not apply to your deployment shape — for example server operations on a desktop-only pilot — should be marked not applicable with a one-line reason, not deleted, so the next reviewer sees the decision.

1. Data and use case

Decide what the pilot is for and what it may touch before anyone installs anything.

• Named workflow, team, and business outcome that will be measured. Evidence: one-page pilot brief.
• Data owner for the material the workflow uses, and the data classes involved. Evidence: classification note signed off by the owner.
• Prohibited content and data classes that must never reach a hosted model. Evidence: written policy.
• Retention need for chats, documents, and generated output. Evidence: retention decision recorded.
• Acceptable model destinations per data class: local device, customer server, named hosted provider. Evidence: destination matrix.
• Representative test material that contains no production secrets. Evidence: the test set, reviewed by the data owner.

2. Identity and endpoints

Who can use the system, on which devices, and how that ends.

• SSO and provisioning ownership: which identity provider, who administers it, whether SCIM is in scope. Evidence: integration record.
• Administrator and break-glass access defined and stored. Evidence: access list and procedure.
• Inventory of managed devices that will run the desktop client. Evidence: device list.
• How clients receive server configuration and policy, and how quickly a policy change reaches a device. Evidence: measured propagation time.
• Revocation test: a user disabled in the directory loses access on their device within the agreed window. Evidence: timed drill result.
• Endpoint exposure: every model API is bound to loopback or behind authenticated TLS; nothing listens on an open port without a reason. Evidence: port scan or configuration review.

3. Models and knowledge

What the system will run and what it will know.

• Approved model sources and licences, with the repository and revision recorded for each model. Evidence: model register.
• Memory and latency measured on the target hardware for each approved model. Evidence: benchmark notes with prompts used.
• Every document and embedding destination mapped — parse, chunk, embed, index, retrieve, generate — with its location. Evidence: data-flow diagram.
• Source permissions preserved in retrieval for any shared index. Evidence: test with two users of different access.
• Update and deletion of a source removes its derived chunks and vectors. Evidence: drill result.
• Verified installers: checksums for every desktop build compared before installation. Evidence: checksum record against the published values.

4. Operations and recovery

Who keeps it running and how it comes back.

• Owners assigned for monitoring, audit export, certificate renewal, backup, restore, upgrade, rollback, capacity, and incidents. Evidence: RACI or equivalent.
• Backup taken and restored to a clean environment, timed. Evidence: restore drill with duration.
• Upgrade and rollback rehearsed on the pilot deployment. Evidence: drill log.
• Redacted support bundle collected and reviewed for content it must not contain. Evidence: bundle review note.
• Renewal calendar for certificates and licences with owners. Evidence: calendar entries.
• Logs and metrics checked for prompt or document text; only operational metadata present. Evidence: log sample review.

5. Policy and evidence

What the organisation can prove afterwards.

• Destination policy enforced technically where the deployment allows (server-delivered policy, gateway routing, DLP) and documented where it does not. Evidence: policy configuration export.
• Audit trail identified: which user, which model, which destination, when. Evidence: sample export.
• Telemetry decision made: disabled, or pointed at an internal project, with the setting recorded. Evidence: configuration.
• Vendor access confirmed absent: no standing vendor credential in the environment. Evidence: account review.
• Compliance position stated in terms of implemented controls, not certifications, using the vendor’s Trust Center as the source. Evidence: assessment note.

6. Pilot exit criteria

Write these before the pilot starts; the table is a template.

Expand only when every threshold is met and the operational path ran without an engineer in the room. Anything else is a longer pilot, which is fine — it is cheaper than a rollback.