- Six pre-rollout checks: permission-aware retrieval, written no-training terms, encryption, a content-blind verifiable audit log, a residency answer, an oversharing review.
- The checklist is go or no-go, not a scorecard: a strong audit log does not compensate for retrieval that ignores permissions.
- No-training commitments are now standard and inspectable: Anthropic, OpenAI, and AWS all publish them for commercial use.
- Run the oversharing review before connecting sources, because AI does not create exposure, it industrializes whatever exposure already exists.
It is safe to use AI on company data when six checks pass before rollout: retrieval is permission-aware, the model provider commits in writing not to train on your content, data is encrypted in transit and at rest, access is logged content-blind and verifiably, residency is answered contractually, and an oversharing review has been run on the sources. Fail one, fix it first.
Is it safe to use AI on company data?
Safe is a property you verify, not a feeling you develop after two weeks without incident. Using AI on company data is safe when specific controls hold, and reckless when they are assumed. The canonical how-to is using AI on company data without leaking; this page compresses it into the checklist a team runs before switching anything on.
Treat it like a launch review: someone owns each row, each row produces evidence, and any failing row stops the rollout for its scope until fixed. The list is short because the failure modes concentrate: most incidents trace back to retrieval or to permissions, not to exotic attacks.
What is on the pre-rollout checklist?
Six checks, each with a concrete pass condition. The order matters less than the rule that all six pass. If a vendor cannot produce the evidence for a row, that row fails; a roadmap answer is a no for today, whatever it becomes next quarter.
| Check | What to verify | Passes when |
|---|---|---|
| Permission-aware retrieval | Retrieval is scoped to the asker before the model sees anything | A low-clearance test account cannot surface a named sensitive doc |
| No-training terms | The model provider's written commitment covers your product and tier | The clause is in the contract or published terms you can cite |
| Encryption | In transit and at rest, with key management stated | The vendor documents both, and key custody is answerable |
| Content-blind audit | Access is logged as actor, object, and rule, not document text | You can review who read what and verify the log's integrity |
| Data residency | Where content and embeddings physically live | The location is contractual, not a support-ticket answer |
| Oversharing review | Source permissions match intent before connection | Drifted shares are fixed or excluded before go-live |
What do written no-training guarantees look like?
Like plain sentences in commercial terms, which is the point: you are looking for quotable commitments, not marketing pages. Collect the exact clause for every provider in your stack, at your tier, and file it with the rollout decision. The biggest providers all publish theirs, so this check takes minutes.
Start with Anthropic, whose commercial terms provide that "Anthropic may not train models on Customer Content from Services." OpenAI publishes the API-side equivalent in its API documentation: "data sent to the OpenAI API is not used to train or improve OpenAI models (unless you explicitly opt in to share data with us)." Read the scope lines carefully: commitments attach to specific products and tiers, and a consumer plan is usually not one of them.
Which leak paths does the checklist close?
Leaks follow one of four paths: retrieval overshares, the provider trains on inputs, prompts and logs retain sensitive text, or an agent holds broader access than its task needs. The checklist closes each path with a control, and what makes it secure explains the architecture behind the first and hardest one.
The oversharing path deserves its own pass before go-live: an oversharing review walks the sources you plan to connect and fixes permission drift first. Everything after rollout is easier if that review happens before it, because a summary already delivered cannot be revoked.
What happens when a check fails?
A failing check stops the rollout for the affected scope, not necessarily for everything. Connect the sources that pass while the failing ones get fixed, and keep the decision written down: which check failed, what evidence would flip it, who owns the fix, and when it gets re-tested. Scope discipline keeps the project alive without inheriting the risk.
The standing process this checklist samples is setting up access governance; run it continuously once you are live. AIVM Brain was built to make the six rows checkable by default, with plans with SSO and audit published openly; it comes from AIVM and is free to start.