Questions to ask before adding private AI

Define what private means for this task

‘Our own AI’ can mean a dedicated application, selected business knowledge, user permissions, connected tools, and an agreed deployment. It does not necessarily mean a newly trained model or a system that runs entirely on your premises.

Write down the requirement behind the word private. Is the concern access between clients, provider retention, processing location, staff permissions, or the ability to remove a document? Different requirements lead to different technical and contractual decisions.

Compare suitable existing business tools with a custom application. The right answer depends on the workflow and the controls available, rather than the logo on the chat window.

Establish which information is permitted

Start with a data inventory for the proposed task. Identify the source, owner, sensitivity, intended purpose, and people allowed to use each category of information.

Canada's privacy commissioners recommend using synthetic or de-identified information when personal information is unnecessary, and establishing authority before entering sensitive or confidential material into a prompt. Assess the actual use with the people responsible for privacy and professional obligations.

For an early demonstration, use invented documents or an approved public procedure. Keep real client and patient details out of a general project enquiry.

1. Which sources are approved for this use?
2. Can the first task work with less information?
3. Who confirms that the intended use is appropriate?
4. What must never be sent to the model or recorded in logs?

Ask for evidence, rather than labels

Turn the important questions into things a supplier or delivery team can show. The responsible roles below are examples; name the actual owner in your business.

Distinguish a grounded answer from a verified fact

An answer linked to a source gives a person somewhere to check. It can still misunderstand the source, miss context, use an outdated document, or answer a question the material does not support.

Agree what happens when a source is missing or the answer is uncertain. Identify which outputs are drafts and which actions require explicit approval. Professional judgement should stay with the person responsible for it.

Test correction, removal, and failure

Use examples from the actual task, with permission, plus synthetic cases for missing information, misleading instructions, and access boundaries. Check what the system does when a user asks for a source they should not see.

Ask how an outdated document is replaced and how removal affects source copies, search indexes, conversations, logs, and external providers. A visible delete button does not explain all of those steps.

Define a way for staff to flag an incorrect answer, find the source, and continue the work manually. Review the complete workflow before adding actions that change records or send messages.

Name the operating owner

Deployment is a continuing responsibility. Agree who handles access changes, provider updates, monitoring, incidents, costs, and support.

Managed APIs, dedicated cloud infrastructure, and self-hosted models have different tradeoffs. Hosting alone does not guarantee accuracy or compliance. Choose the arrangement after the requirements are clear, and record the responsibilities in the project scope.

A useful first discussion ends with a defined task, approved example information, a review plan, and the evidence needed for a pilot—not a blanket promise about security.