What does private mean in practice?
Follow the information. Ask who can use it, under which rules, and what evidence you can inspect.
Start with a data-flow explanation
Ask the provider to trace a representative request from your business tool to the answer or action. Include the model service, retrieval system, logs, backups, support tools, and any outside service that receives information.
For every stop, record the information involved, the operator, its location, and the reason it is needed. A diagram is a useful beginning; the service configuration and agreement should support it.
Private is a description that needs detail. It does not automatically mean on-premises equipment, customer-owned hardware, or no service providers. Compare the actual arrangements.
Questions for the provider
- Which services process the prompt, retrieved records, attachments, and response?
- What information enters operational logs or support systems?
- Can the processing arrangement change, and how will we be told?
- Which restrictions can we configure, and which depend on contractual commitments?
Separate information access from action authority
Being able to read a record is different from permission to change it, send a message, or approve a transaction. Ask the provider to demonstrate both boundaries with sample accounts.
Test a requester with access, another without it, and someone whose role has just changed. Include connected tools and retrieved information. Ask what happens when permissions cannot be checked.
- Who administers the environment and approves access changes?
- When can provider staff see business information for support?
- Which actions require a person’s approval, and what exactly does that approval cover?
- How are refusals, approvals, completed actions, and failed attempts recorded?
Ask about each use of your information
Document retrieval, saved conversation history, extracted facts, and model training are different uses. Do not accept one answer about “learning” as an explanation of all of them.
Request the terms for every relevant model and outside service, together with the configuration that applies to your account. Ask whether information may be used for model improvement, evaluation, abuse monitoring, or human review, and which choices you control.
Scroll the table horizontally if needed. Keyboard users can focus the table and use arrow keys.
| What accumulates | What to ask |
|---|---|
| Retrieved company records | Which records are indexed, how are permissions checked, and when are changes reflected? |
| History and stored memory | What is retained, who can inspect it, and how can errors be corrected? |
| Trained artifacts | Is any training performed? If so, who owns and can export the resulting artifacts? |
Plan the end before the beginning
Ask for a retention schedule covering source copies, indexes, histories, logs, and backups. Confirm how deletion requests propagate and what must be retained for an identified reason.
Agree an export format and perform a sample export before relying on it. Separate rights to your business data from ownership of hardware, software, and model weights. Record the time and costs associated with transition support.
- What remains after a document is deleted from its original tool?
- How long can backup copies remain, and who can restore them?
- What can we take to another provider in a usable format?
- How are service accounts and connected-tool permissions revoked?
Bring the explanation into a demonstration
Use sample records and a defined task. Inspect an allowed request, a denied request, an approval-required action, and a failed connection. Compare the recorded results with the provider’s explanation.
A policy describes a commitment. A configuration describes a control. A test shows what happened in that test. Keep each piece of evidence attached to the question it answers.
Use the buyer’s demonstration checklist →