A team wants to summarize customer feedback with AI. Someone exports the entire customer spreadsheet and asks, “Can we upload this?” The first decision should come earlier: which information does the task actually need?
An approved AI tool does not automatically make every dataset appropriate for every use. The useful boundary is specific: this task, these fields, this environment, these people and this retention arrangement.
My VORTA material treats data inventory, sensitivity, data flows and access as part of operational readiness. The following five checks turn that approach into a practical conversation before business information enters an AI system. They support a decision; they do not replace the organization’s privacy, security or contractual review.
1. Define the output before selecting the input
Start with the work you want completed. “Analyze our customers” leaves almost everything open. “Identify recurring delivery complaints from the last month so we can improve the dispatch process” is a more useful instruction.
Now list the information required to produce that output. Complaint category, a relevant comment and a broad delivery region may be enough. Names, email addresses, account balances and the full purchase history may add exposure without helping the decision.
This is a design question, not just a redaction exercise. If the objective can be met using an aggregate already available in the reporting system, there may be no reason to upload individual records at all.
Ask: What would become impossible if we removed this field? If nobody can explain its contribution, leave it out of the initial input and test whether the task still works.
2. Check what the remaining information can reveal
Removing names is helpful, but it does not necessarily make a record anonymous. A distinctive job title, a small location and an unusual event can identify someone when combined. Free-text comments may contain information that is absent from the spreadsheet’s labelled columns.
The NIST AI Risk Management Framework 1.0 discussion of trustworthiness describes privacy risks from inferring information about people. It also notes that de-identification and aggregation can support privacy-enhanced systems. These techniques need to be assessed in context rather than treated as a universal guarantee.
Review both the structured fields and a representative sample of the actual text. Look for personal details, commercially sensitive terms and information belonging to another party. Check whether permission to hold the information also covers the proposed use and service.
When the answer is uncertain, route that specific question to the relevant data owner or privacy and security specialists. Avoid turning “we already have the file” into an assumption that any further processing is acceptable.
3. Confirm the destination and who can access it
“We use the enterprise version” is not a complete description of the destination. Identify the actual account, workspace, tool and enabled connections that will receive the data.
Before transfer, establish:
- Whether this environment is approved for the information’s classification and intended purpose.
- Who can view the conversation, uploaded files and resulting output.
- Whether connected tools or downstream services will receive any of that information.
- What the applicable provider terms and account settings say about data use, retention and deletion.
A statement that content is not used to train a model does not, by itself, answer questions about storage, access or retention. Verify those separately for the service and configuration you are actually using.
The NCSC guidelines for secure AI system development take a lifecycle approach to protecting AI systems and sensitive information. At the user-workflow level, that means looking beyond the prompt box to where information travels and remains accessible.
4. Test with less data before expanding access
Consider an illustrative delivery-complaint analysis. The initial export contains customer names, phone numbers, exact addresses, order values and complaint text. The intended output is a list of recurring service problems, not a decision about individual customers.
A narrower starting point could contain reviewed complaint text, a broad region and a service category. Remove irrelevant details from the text using an approved process before upload. Test a limited sample in the approved environment and compare the resulting themes with a knowledgeable employee’s assessment.
If the output misses an important distinction, add only the information needed to investigate that gap. For example, a delivery-service category might explain differences that names and exact addresses would not.
Reduced data can also reduce usefulness. A small sample may miss rare problems, and broad categories can conceal meaningful differences. Record those limits rather than presenting an exploratory summary as a complete analysis. The question is whether the reduced input supports this decision adequately, not whether it produces a polished answer.
For the related evaluation question, see what leaders should ask beyond an AI accuracy score.
5. Set a boundary for the output and its later reuse
An AI-generated summary can still contain confidential information. A short result is not automatically safe to distribute more widely than its source.
Agree where the output will be stored, who may receive it and what review is needed before sharing. Include uploaded files, chat history, exported reports and any downstream copies in the retention discussion. Do not assume deleting a conversation removes every related copy.
Also define when the original decision must be revisited. Moving from internal complaint themes to individual customer scoring changes the purpose. Adding another data source or connecting an external action tool may change the exposure. These are reasons to reassess the boundary, even when the product name stays the same. My AI change-control guide develops that decision further.
Leave a short record that another person can use
For a routine, approved use, the record can be concise:
- Purpose: the decision or output the task supports.
- Input: required fields, excluded information and known limitations.
- Destination: the approved workspace and any onward transfers.
- Access and retention: who can see inputs and outputs, and how long they should remain.
- Owner: who resolved the boundary questions and when to review the decision again.
More sensitive or consequential uses need a more substantial assessment. The point is to make the boundary understandable enough that a colleague can follow it without reopening every question or quietly extending the scope.
Before the next upload, ask the team to explain those five items. A missing answer is useful information: it shows what needs resolving before the transfer.
If you want to work through a real AI workflow and its operating boundaries, you can schedule a consultation.