The Privacy Risk Between Your Business and Its AI Models

A business may carefully review an AI model provider and still overlook another company handling the same information. The service that lets employees switch between models can receive their prompts, process uploads and retain conversation records. Its security and contractual terms deserve their own review.

That risk is central to a reported exposure at AI aggregator 302.ai. Cybernews researchers said they discovered 17.6 million files totaling 22.72 terabytes in publicly accessible Azure storage. The material reportedly included images, video, audio, documents and more than 144,000 chat logs containing prompts, AI replies and associated metadata. Some records contained personal information and enterprise customer support conversations.

Cybernews lists August 2, 2026, as the discovery date, August 11 as its initial disclosure and September 8 as the date it observed the exposure closed. It said it had no evidence that malicious actors accessed or downloaded the material. The report did not include a company response to its request for comment. Those findings establish a reported exposure; they do not establish criminal theft, subsequent misuse or a count of affected individuals.

One interface can introduce another data custodian

AI aggregators offer a practical convenience: access to multiple models through a common interface or API. A team can compare answers, change providers or consolidate billing without building separate integrations for every model. The privacy review needs to account for the intermediary providing that convenience.

In a hypothetical customer service deployment, a website sends a customer’s message to an aggregator, which forwards it to a selected model provider. The response returns through the aggregator to the business. Conversation history, uploaded attachments, debugging records and usage information may also be stored along that route, depending on the deployment. This describes a possible architecture, not a verified reconstruction of 302.ai’s systems.

The model’s name in the interface cannot answer who retains those copies. Nor does an enterprise agreement with one model provider necessarily cover a separate intermediary. Procurement needs to identify the legal entity supplying each service, the terms that apply to that account and the parties permitted to process its data.

A fallback setting also deserves attention. If an application routes a failed request to a different model, the approved recipient may change without the employee deliberately selecting another provider. Teams should confirm whether fallback routing exists, which providers it can use and whether its operation stays within the approved data and geographic restrictions.

Chat history can become a second customer database

Companies usually recognize a customer relationship management system as a repository requiring access controls, retention rules and documented ownership. A collection of AI conversations can contain comparable information while receiving far less attention.

Consider a support agent pasting a complaint into an AI assistant to draft a reply. The text may include an order number, address, purchase details and the customer’s explanation of a personal problem. The resulting answer may repeat those details. Saving both messages can preserve multiple versions of the same personal information outside the original support system.

Generated content therefore needs classification too. An output can disclose information copied from an input, describe an identifiable person or contain an inaccurate inference about them. The fact that software produced the text does not make it harmless to publish or retain.

The concern is especially acute when a conversation concerns intimate purchases, health, finances or employment. The source article used the sensitive nature of one reported customer support use case as a headline detail. For a business reviewing its exposure, the more useful question is whether customers expected those conversations to be retained by an additional service and what restrictions governed that retention.

Encryption and access permissions answer different questions

Descriptions of open cloud storage often use “unencrypted” as shorthand for readable information. That wording can obscure the control that failed. Microsoft states that Azure Storage encrypts stored data automatically and decrypts it transparently when serving requests. Encryption at rest can coexist with a configuration that permits outsiders to retrieve readable files.

The public reporting does not establish the complete encryption configuration in this incident. The relevant reported condition is public accessibility. Microsoft’s guidance on anonymous blob access recommends disabling anonymous access; disallowing it at the storage-account level rejects anonymous read requests even where a container had previously allowed them.

A security review should therefore examine the access path as well as encryption settings. Engineering teams should test whether a person without an authorized session can retrieve a private upload or export, whether one customer can access another customer’s records and whether temporary sharing links expire as intended. These tests should use authorized test data and environments.

Configuration monitoring also needs an owner. A review completed before launch offers limited protection if later changes can make a container public or extend access to a new service identity. Preventive policies, restricted administrative permissions and alerts for relevant changes can reduce the chance that one configuration error persists unnoticed.

“Not used for training” leaves several questions open

A contractual restriction on training addresses one use of information. It does not, by itself, establish whether the service retains prompts, how long diagnostic copies survive or which support personnel can inspect them.

Businesses evaluating an aggregator should obtain separate answers about content retention, operational logs, backups, exports and downstream providers. If the vendor offers a zero-retention setting, the agreement and technical documentation should explain which data categories it covers, any exceptions and whether those commitments extend to every provider used by the service.

The 302.ai privacy notice available during this review describes general security measures and says personal information is retained as necessary for service provision, legal obligations, disputes and policy enforcement. Those statements do not establish the precise configuration or contractual terms applicable to a particular business account during the reported exposure. They illustrate why a broad public notice should be supplemented with deployment-specific answers.

Deletion should receive the same scrutiny. Removing a conversation from the visible interface may have a different effect from deleting its attachments, exports, search indexes or backup copies. A useful vendor response explains what disappears immediately, what remains under a restricted retention schedule and how deletion instructions reach downstream processors.

Privacy obligations follow the processing arrangement

Where the GDPR applies, an organization needs to determine the roles of the business, aggregator and downstream providers for each processing purpose. The European Data Protection Board’s guidance distinguishes controllers, which determine purposes and means, from processors acting on their behalf. A provider’s role cannot be resolved solely by calling it an AI tool.

If the arrangement involves a processor and sub-processors, the relevant contracts and authorization requirements need to cover that chain. The EDPB’s opinion on reliance on processors and sub-processors addresses the information controllers need to assess those relationships. Procurement should establish which entities receive personal data, their functions and locations, and the safeguards supporting the arrangement.

That review should also examine whether the intended use fits the purpose for which the business obtained the information. A customer providing details to resolve a support request does not automatically authorize unrelated development or other secondary uses. Data minimization can make the approved task safer: an assistant drafting a shipping update may need the delivery status while having no need for a customer’s full account history.

An exposure also requires a separate notification assessment. Under the GDPR, controllers generally must notify the competent authority without undue delay and, where feasible, within 72 hours of awareness unless the breach is unlikely to create a risk to individuals’ rights and freedoms. High-risk breaches can also require notice to affected people. ICO guidance on the UK GDPR explains the corresponding thresholds and the processor’s duty to inform the controller without undue delay.

Whether any particular organization has those duties depends on the applicable law and facts. A file count cannot resolve that assessment. Neither can the absence of confirmed malicious downloading: investigators still need to assess what personal data became accessible, to whom and with what likely consequences.

Give every approved AI route a recorded owner

The operational challenge is keeping the approved use aligned with the actual deployment. A record that says “AI writing tool approved” is too broad if employees later use it for customer support, upload sensitive documents or enable another model.

A useful approval identifies the permitted task, accountable owner, allowed data categories, recipient services and retention requirements. Restrictions should be reflected in the configuration wherever possible. Reassessment should follow material changes, including a new provider, longer retention, a connected business system or a move from synthetic test data to live customer records.

Captain Compliance’s AI Governance software supports this work through AI inventories, vendor review, assessments, approval workflows and records of assigned controls. Its assessment workflows help coordinate reviews and preserve the evidence supporting a decision. For an aggregator deployment, those records can connect a permitted use to the specific vendor commitments and technical checks on which approval depends.

The distinction between documentation and enforcement remains consequential. Recording “private storage required” does not configure an Azure account. The deployment owner must implement the requirement and provide evidence that it works. Governance software helps organize responsibility, decisions and reassessment; engineering controls protect the access paths.

The export button belongs in the procurement demo

When evaluating the next AI service, ask the vendor to demonstrate what happens after a conversation ends. Have it create a test exchange, attach a harmless sample file, generate an export and explain the resulting copies. Then request deletion and ask how the service handles the original messages, attachment, export and downstream records.

That demonstration will not replace a security assessment, but it can reveal gaps that a model benchmark never will. A company can compare the quality of several AI systems in minutes. Before entrusting one with customer information, it also needs a satisfactory account of where the conversation goes when the screen closes.