Private AI readiness checklist

Explain the work and alternatives

Who does the task today, how much effort does it take and what happens when it fails? Compare AI with search, rules or process changes.

Confirm sources and permissions

Are documents current and owned? Who may access, correct or remove each source? Define what must not enter the system.

Agree on continuation criteria

Choose questions and expected outcomes, access boundaries, an operating owner and thresholds suited to the case. Record what the pilot cannot prove.

The output of this review

Write a one-page record of the chosen task, a non-AI alternative, permitted data, constraints, operating owner and three or four tests that would change the decision. If a reliable source or permission to use it is missing, record that blocker before choosing infrastructure. A well-scoped pilot may recommend fixing the process or data first.

This list does not replace legal, security or impact assessment where required. Its role is to make clear what those specialists must resolve and what the technical team can legitimately test.

1. Name one workflow and its owner

Write down who performs the task now, which system holds the authoritative information and what a better outcome would change. Include the cost of a wrong answer or an unavailable service. If several teams describe different tasks, choose one to assess first. Compare it with a simpler search, rules or process change before committing to generation.

2. Confirm data can be used

Inventory sources by owner, age, format, access group and permitted purpose. Ask who can correct or withdraw each source, whether a pilot may copy it and where prompts and outputs may be processed or retained. If an essential source lacks an owner or permission, record that as a blocker. A choice of model cannot repair an unresolved right to use data.

3. Define a safe boundary for the pilot

Specify users, permitted actions, human review points, integrations and the first environment. Identify which network or procurement restrictions need specialist approval. Decide how users will report errors and how the team can stop the pilot. “Private” should describe a tested data flow and operating boundary, not an assumed legal status.

4. Agree evidence before seeing a demo

Prepare a few representative tasks with expected outcomes and failure conditions. For a document assistant, include an answer supported by a current source, a question it should decline and a source restricted to a different role. For an action-taking workflow, include a rejected action and a human approval. Record how cases were selected, who will review outputs and what the pilot cannot prove about production load or long-term accuracy.

A one-page decision record

Finish with the task, owner, baseline alternative, allowed data, candidate architecture, operating owner, tests, unresolved approvals and the next decision. Mark each item as known, assumed or unresolved. The outcome can be discovery, a bounded pilot, a technical audit of an existing system or a decision to wait. See private AI consulting for architecture choices and technical audit when a pilot already exists.