A practical checklist for planning private AI.

Define what private means for your project

Private can describe where a model runs, who can use it or which organisation controls its data. These are separate decisions. Begin with a written boundary: which information must stay inside your network, which may be processed by an approved provider, and who is allowed to see each source.

Draw the complete route from an employee's question to the answer. Include document storage, search indexes, model processing, connected tools, logs, backups and support access. Running a model locally does not by itself constrain what a connected email or web tool can send outside the network.

Start with one permissioned collection

Choose a small collection with a clear owner and current documents. Mark material that is outdated, confidential or restricted to a particular team. Decide how a document is removed from both the original store and any derived search index.

For an illustrative internal policy assistant, a member of the sales team should not gain access to restricted personnel documents through search. Test the same question as users with different roles. An answer should identify its supporting document when that is part of the agreed workflow, and acknowledge when an approved source does not contain the answer.

• Who owns each document collection?
• Which roles may search it?
• How are access changes applied?
• How are updated and deleted documents reflected?
• What should happen when sources disagree?

Separate answering from taking action

A system that searches approved documents has a different risk profile from one that can send email, modify records or run commands. List every proposed tool and specify its permitted inputs, destination and approval step. Start with read-only access where it can meet the need.

Treat retrieved text as information, not permission to change the system's rules. Include test documents that ask the assistant to reveal another user's records or send information to an unapproved destination. The expected result is refusal or escalation, not obedience to the document.

Evaluate the system before choosing hardware

Prepare a review set containing ordinary questions, ambiguous requests, missing answers, conflicting documents and requests outside the user's permissions. Have a person assess accuracy, supporting evidence and appropriate refusal. Keep the test set separate from examples used to tune the system.

Measure response time and resource use with the expected document sizes and simultaneous users. Compare the whole operating cost: hardware or hosting, model and software licences, updates, integration maintenance and support. Do not buy a machine based only on a model name or a single demonstration.

Agree the operating responsibilities

Before launch, assign responsibility for account access, software updates, document freshness, failure alerts and recovery. Define what can appear in logs, how long records remain, and how a deletion request is handled across documents, indexes and backups. Use synthetic data for the first restore exercise.

The acceptance record should state what was tested, what remains unsupported and which changes require retesting. Keep consequential decisions with an authorised person. A useful first release has a narrow job, known limits and an owner who can stop it when something goes wrong.

• An approved data-flow and access map
• A reviewed evaluation set and results
• Explicit tool and approval boundaries
• A documented update, retention and recovery process
• Business-owned accounts and a clear support agreement