A buyer reviews purchasing records beside a laptop showing selected attachments, a closed document folder, and a small machined metal component on a charcoal desk.

Where Does Your AI Send Your Information?

Applied AI / 03 November 2026 / 7 mins

A supplier comparison can carry customer details, negotiated prices, and internal plans into services the buyer never sees. Before expanding an AI workflow, follow the information and establish who can access it, where it goes, and how long it stays.

One Operational Ecosystem, Part 6

The buyer uploads a spreadsheet and asks the assistant to compare two suppliers. A minute later, a useful summary appears. The prices are correct, the delivery dates are clear, and the engineer can check the proposed component against the specification.

The spreadsheet also contains another customer's forecast, negotiated prices from three other suppliers, and an internal margin calculation on a separate tab.

None of that was needed for the comparison. It went with the file anyway.

This is a hypothetical extension of the purchasing workflow we have followed throughout this series. In Part 5, we looked at whether the assistant improves the completed job. Before expanding its use, we also need to account for the information it receives and where that information goes.

A result can be accurate, useful, and produced through a process the business would never have approved if someone had explained the data movements first.

Start with what leaves the business

"We only use it for purchasing" describes a purpose. It tells us very little about the information involved.

A supplier comparison might include prices, drawings, specifications, names, email addresses, delivery locations, and production schedules. Together, those records can reveal what the business is building, who it depends on, and what it expects to sell.

Attachments deserve particular attention. A workbook can contain hidden sheets. An email chain can carry an earlier negotiation. A document can include comments that were never intended for a supplier or service provider.

The same problem appears in software development. A developer asking for help with an error may paste a log containing customer details or credentials. Source code can reveal proprietary business rules and internal system structure even when it contains no personal information.

The first useful exercise is to inspect a representative request. Include the attachment, retrieved records, and any context the application adds automatically. Ask what each piece contributes to the task.

For our buyer, the assistant may need the specification revision, quoted price, quantity, and delivery terms. It probably does not need the customer's name or the company's margin target. A prepared comparison form could supply the necessary fields without sending the entire workbook.

Removing context indiscriminately can make the answer worse. The aim is to choose the information deliberately and test whether the task still works.

Permission to read is a separate decision from permission to share

The buyer already has access to the workbook. That does not settle whether its contents can be sent to an outside service.

A business may hold information under customer agreements, supplier terms, or privacy obligations that limit how it can be used. An employee's access to a shared drive does not explain those limits to an assistant.

An approved workflow therefore needs a clear boundary: which records may be supplied, for which purpose, and to which service. Staff need a usable way to stay within it.

"Be careful with confidential information" leaves too much interpretation to someone trying to finish an order. A form that selects approved fields, or an integration that retrieves only the relevant record, gives them something concrete to work with.

For personal information, this also supports data minimization. The UK Information Commissioner's Office guidance on AI explains the need to identify the minimum personal data required for the purpose. The specific legal requirements depend on the business and the people whose information it handles.

In my Applied AI Handbook, I describe a "Data Reality Check" that belongs before system design: establish whether the data can lawfully be used, document its sources, and clarify ownership and retention obligations. In this purchasing example, that means checking whether the supplier records can be shared with the chosen service and what happens to them afterward. Having access to the workbook is only the starting point.

Follow the request beyond the chat window

The tool the buyer sees may sit in front of several services.

The application might extract text from the spreadsheet, send part of it to a model provider, and store the conversation for later review. A monitoring service might record requests when something fails. A support team might inspect those records during an investigation.

Those are possibilities to establish for the actual service, rather than assumptions about every AI product.

Someone should be able to explain the route in ordinary language: what is transmitted, which organizations receive it, what they retain, and who can access it. Include connected tools and diagnostic records in that explanation.

The UK National Cyber Security Centre's cloud guidance treats storage, processing, management, access, and jurisdiction as part of protecting cloud data. It also includes derived information such as logs and metadata in the assessment.

This matters because protecting the original spreadsheet does little for a second copy left in a support log with broader access.

Ask what "not used for training" covers

A commitment not to use customer data for model training addresses an important question. Other questions still need answers.

How long are requests and responses retained? Can provider staff access them for support or abuse investigations? Which subcontractors process them? What happens to stored conversations when an account is closed?

Check the terms and settings for the exact product and account being used. A consumer chat account, a business subscription, and an API integration may have different arrangements.

For the purchasing workflow, record the agreed conditions alongside the service configuration. If the business relies on a particular retention setting, someone needs to verify that it is enabled and remains enabled.

Deleting the conversation from the buyer's screen should not be treated as proof that every associated copy has been removed. Establish what deletion means under the service's documented retention arrangements.

Location and jurisdiction need separate attention

Selecting a hosting region answers part of the question. The legal entity providing the service, overseas support access, and subcontracting arrangements also matter.

The concern is practical. Which organizations can obtain the information, under what conditions, and what options does the business have if something goes wrong? Government access requirements, contractual protections, and routes for resolving disputes can differ across jurisdictions.

Nationality alone is a poor basis for that assessment. A domestic service can have weak controls. An overseas provider can offer strong protections, while still introducing legal or contractual questions that need examination.

The NCSC's guidance on using cloud platforms securely recommends considering countries, jurisdictions, provider access, and rights to use data when setting organizational guardrails.

For sensitive customer or proprietary information, involve the people responsible for security, privacy, and contracts before approving the workflow. Give them the actual data flow and service terms. A vendor's country of origin and a selected storage region are insufficient on their own.

Local deployment still needs a boundary

Running a model on equipment controlled by the business can reduce reliance on external processing. The surrounding application still needs examination.

Does it call an outside document extraction service? Send diagnostic information elsewhere? Use remote backups? Allow a support connection? Can the assistant invoke a tool that transmits information?

These connections may be legitimate and useful. They need to be included in the decision about what the system is allowed to send.

If the purchasing workflow requires information to remain inside a particular environment, that requirement should be enforced and tested across the whole workflow. The model's location is one part of that work.

Make the boundary observable

Use synthetic purchasing records to test the approved route before introducing sensitive information. Inspect the requests and logs available to your team. Confirm which fields are sent and whether diagnostic logging captures content unnecessarily.

Those checks establish what you can observe. They cannot prove that a provider retains no downstream copies. Provider documentation, contractual commitments, and appropriate assurance still have a role.

Limit access to stored conversations and logs, set a retention period that serves a defined purpose, and decide who handles an accidental disclosure. If credentials are included in a request, deleting the chat alone does not resolve the exposure; the credentials may need to be revoked or replaced.

Repeat the assessment when the workflow changes. Connecting the assistant to a shared drive can greatly expand what it can retrieve. Adding a new tool can change where information goes. An approval for comparing selected quotes should not silently become approval to search every customer folder.

Give the buyer a workable process

Return to the original task. The buyer needs a reliable comparison and a decision they can explain.

A workable process gives them an approved way to supply the relevant records, a clear limit on what can be shared, and someone to ask when an attachment falls outside that limit. The business knows which services receive the information and the conditions under which they handle it.

Before adding the next connection, ask the person responsible for the workflow to explain where a single purchasing record goes, who can access it, and when it is removed.

Any gaps in that explanation are work to complete before sending more information.