AI on company data: a six-part pre-launch review
Contents
The pre-launch review
Evidence, scope and a decision
Six checked boxes cannot prove that an AI system is safe. They can make a launch meeting much more useful: each box should name a requirement, the evidence for it and the consequence of a gap. Use this starting review for one proposed workflow, then add risks specific to the data and actions involved.
Bring a scope the review can actually approve
Write the intended users, data, client and actions at the top of the review. “All company knowledge” gives the reviewer little to work with. “Two support staff searching the approved public help centre in the web application, with no write tools” is a scope someone can assess.
Name the source owner, technical owner and person responsible for the release decision. A vendor meeting establishes buying evidence; this review checks whether the actual configuration about to go live matches the intended use.
Six checks, each with evidence and a gap
Treat the table as a starting set, not a certification or exhaustive security assessment. A failed requirement blocks the scope that depends on it; an unrelated strength cannot compensate. Record documented commitments separately from observed tests.
| Check | Evidence to bring | What a gap changes |
|---|---|---|
| 1. Access enforcement | Actual identity/grant configuration; allowed and denied results including citations, document opens and applicable client paths. | Exclude restricted sources or the unproven route until the required boundary is established. |
| 2. Processing and training | Terms/settings for each relevant service, account and processor; training use and request retention recorded separately. | Do not send data whose permitted use is incompatible or unresolved. |
| 3. Storage and removal | Documented encryption and key handling; inventory of imports, caches, conversations, logs and deletion procedures. | Resolve storage or retention requirements before those data enter. |
| 4. Operational records | A scoped sample showing useful actor/action outcomes, access restrictions and retention; coverage and integrity limits stated. | Add the investigation capability your incident response depends on. |
| 5. Processing location | Locations for stored content and model processing, matched to applicable contractual or organizational requirements. | Exclude the workflow if a required location cannot be established. |
| 6. Source sharing | Source owner confirms intended readers; broad links and stale groups are corrected or excluded. | Do not let an assistant make unintended source grants easier to exploit. |
A small example of a partial go decision
In a fictional review, a team proposes two source sets: public help articles and restricted support tickets. The public set has a reviewed processing route, assigned owner and acceptable operating records. The ticket connector’s per-user access behavior remains unresolved.
The decision is to launch only the public-help workflow with two staff and no agent or write tools. Tickets are excluded from the configured connection, not merely forbidden in the prompt. The technical owner must demonstrate the ticket access requirement before a separate expansion decision.
If the tool cannot isolate the public source set from the tickets, this partial launch is unavailable. The scope reduction must exist in configuration as well as meeting notes.
One successful refusal is not the whole access review
Use synthetic records for the test. Check that an authorized identity can retrieve the intended document and an unauthorized identity cannot obtain its body, revealing title or linked content. Exercise relevant sessions and routes after grants change. The complete access-test example shows how one apparent refusal can still fail.
NIST’s Zero Trust Architecture distinguishes authentication from authorization and rejects trust based only on network location or ownership. For this review, successful login does not answer which resources that identity may use.
Record the launch decision and its next trigger
Finish with the approved sources, users and actions; excluded scope; open requirements and owners; and events that require another review. A new connector, broader data, changed identity path or enabled write tool can invalidate an earlier decision.
The checklist does not inspect every application vulnerability, prompt-injection path or operational failure. Add the relevant reviews for your use rather than claiming that six passes close every leak path.
Apply the same standard to HeyBrain. Consult the published privacy policy for policy statements and inspect the capabilities of the actual proposed setup; this page does not assert that all six controls are product defaults. For planning the work before this meeting, use the access-governance rollout plan.
Prepared by HeyBrain Editorial Team with AI assistance. Examples are fictional illustrations, not observed customer incidents or product tests. This correction retains the original publication date and removes unsupported security guarantees. Primary sources were checked on 13 October 2026.
