Privacy is often one of the first things on the checklist when a business signs off on an AI chatbot.
- Will the service use chats to train its models?
- How long does it store the data?
- Who can see it, and what happens if an employee deletes a chat?
These are significant questions, but they don’t necessarily convey the whole picture about AI chat privacy. The application the employees use to chat with the chatbot may have third-party services that measure activity, assess performance, or record user sessions.
Research in October 2026 discovered that certain AI chat platforms were sharing discussion data with third-party trackers, even the actual instructions entered by users. This poses an issue that business security evaluations cannot ignore: who else may be getting information through the chat interface, even if the vendor agrees not to use it to train the model?
What AI Chat Privacy Policies May Leave Out
Most organisations want to know what happens to their information once it is in the hands of an AI supplier. They examine how interactions are stored, if employee prompts are utilised to train algorithms and what contractual protections exist for commercial customers. But there's another component of the process to think about.
The prompt has been entered by the employee into a web application before it reaches the model. That program may include analytical tools, customer support widgets and other components run by third parties. The services may also gather information on how individuals utilise the site.
Some may even get information from the chats themselves depending on how they are configured. So a promise that customer data won’t be used to train an AI model doesn’t always mean it won’t be collected for another purpose. These partnerships may be described in broad categories such as analytics providers or service partners in the privacy policies.
A separate list of subprocessors or data processing agreement may provide more detail. That doesn't mean the provider is hiding anything, either. The purposes of different papers vary, and the legal requirements depend on the information involved and the law that applies.
For enterprise buyers, the question is whether those disclosures tell the whole story about the app’s third-party data sharing. To answer that, they need to know how information can leave the chat interface in the first place.
How Third-Party Scripts Can Access AI Chat Data
An AI chatbot website is more than a place to send enquiries to a language model and display the replies. Like many current web applications, it can load additional software to measure performance, study user behaviour and support the people using it.
Some of that software is third-party software. It’s commonly delivered via JavaScript, the coding language that browsers employ to make websites interactive.
Analytics and session-recording tools
Analytics instruments can assist providers in discovering which features users utilise, where they face problems, and how they navigate around an application. Session-recording technologies take things one step further and recreate what happened throughout a visit, including interactions with different portions of a page.
Microsoft's literature on session recording, for example, details how Clarity can reproduce page activities such as clicks, scrolling, and navigation. The technique can be useful to uncover usability flaws, but its collection settings need special caution when the page contains sensitive information.
These technologies may observe a chat session that is displayed on the same webpage. If the application hasn't properly restricted what they can gather, data intended for the chatbot could end up in the data given to an analytics provider. Masking controls can stop some content from being recorded.
Other technical safeguards can restrict what outside code can access. Their effectiveness depends on the implementation of the application.
What information can reach third parties?
It’s not just full prompts or AI-generated responses that are at risk. Third-party technologies may gather discussion titles, site addresses, chat identifiers and account information that helps identify the individual using the service. Say, for example, an employee asks an AI assistant to help draft a confidential proposal for an acquisition.
Even if the whole proposal is not sent, a conversation title using the name of the target company may reveal information that the organisation has not disclosed. OWASP’s guidance on third-party JavaScript says external scripts can read information from a webpage’s document object model, or DOM.
That is the framework that the browser employs to represent the material presented on a page. There is a big difference here. Finding a third-party script doesn’t necessarily mean it’s gathering confidential conversations. Security teams need to know whether it can access sensitive information, what it is configured to collect and what is actually sent.
Recent research has begun to answer those questions.
What Research Reveals About AI Chat Data Leakage
In October 2026, researchers published "Penny for Your Prompts: A Measurement Study of Contextual Leakage in AI Chat Platforms." The study looked at the online interfaces of 42 general-purpose and specialist AI chat platforms, including applications for healthcare, legal and educational usage.
Researchers identified that 21 platforms shared chat titles with third-party trackers and nine shared user prompts verbatim. They also found platforms transferring users’ email addresses to outside trackers, creating ways to correlate chat info with identifiable people. Instead of only logging which other services handled requests, the researchers instrumented the JavaScript engine of the browser.
This allowed them to link information transfers to the user behaviours and methods of webpage-content collection used. The findings extend the work of researchers at the University of California, Davis. In its research, Tracking Conversations, 17 out of the 20 most popular AI chatbots shared information with at least one third party.
Three transmitted plaintext conversation content via Microsoft Clarity’s session-replay technology. The researchers also matched the observed data transfers with the published privacy policies and found occasions where the recipients were not explicitly named.
In 2026, a study called Prompt Like a Butterfly, Sting Like a Tracker looked at nine conversational AI services on the web and on Android devices. It raised more concerns about tracking IDs, chat data, and sharing features. The research analysed different platforms using different approaches, so their results can't be combined into an industry-wide estimate.
Nor do they show that every AI chatbot leaks chats, or that all product setups work the same. What they do show is that there is a measurable danger of AI chatbot data leaking through application components, a risk that traditional model-focused privacy queries might miss.
What Enterprises Should Check Before Approving an AI Chat Platform
A privacy policy is a good place to start an AI privacy review, but shouldn’t be the only evidence required to sign off on a platform. The idea is not to eliminate all external services that an application utilises. It is to see what information those services get, if the collection is required and if the organisation can live with the risk of this.
Identify who receives application data
Ask the provider to clearly describe the external services that are used to run its chat application. This should include analytics, session recording, customer support and other services that might get information from the interactions of employees. A list of subprocessors can give you a sense of the organisations processing personal data on behalf of the provider, but it won’t necessarily explain every connection on the browser side or exactly what the recipient is collecting. Good questions to ask include:
- What information does the chat interface provide to third parties and why?
- What types of information can each recipient gather?
- Can any recipient see prompts, answers or chat information?
- How do these actions show up in the privacy notice and the contractual agreements?
The responses should be sufficiently explicit to be compared with the confidentiality and data protection needs of the organisation. A blanket promise that the supplier uses trusted partners does not clarify what those partners can view.
Verify what the application actually transmits
Then the next step is to compare such disclosures with the behaviour of the application. Security teams can perform controlled browser testing to see what network requests occur while a human is interacting with the chatbot.
They can enter synthetic test information to see if specific prompt messages, conversation titles or IDs are included in requests to external destinations. Testing should encompass relevant behaviours such as beginning discussions, producing replies, renaming chats, and using sharing capabilities.
The objective is to find out what data is involved without disclosing real business data in the evaluation process. Network traffic alone won't always tell you how information was gathered. Some data may be altered, encoded or transmitted via services that require more examination.
And this is where the provider's technical documentation and clear responses come in handy. If a transfer is unexplained, you should request an explanation rather than automatically assume it is due to wrongdoing. Similarly, a clean test does not show that all possible information flows have been checked out.
Examine privacy controls and product configurations
It is not simply the name of the product that matters, but also the version of the chatbot under evaluation. The settings, contracts or technical controls may vary between consumer and enterprise subscriptions. Some apps provide private-chat modes, and others allow providers to disable analytics or suppress sensitive parts of session recordings.
In testing private settings on 10 services, UC Davis researchers saw no leakage of content or identity, although some third-party connections continued. That’s a helpful result, but it doesn’t prove that all private-chat features offer the same protection. Enterprise buyers should determine which controls are applicable to the deployment they intend to make and if those settings can be validated.
Providers should also be asked how sensitive fields are excluded from collection, and whether they evaluate such exclusions following application upgrades. Where a vendor states that prompts cannot reach its analytics systems, the organisation should be able to understand the technical measures that support that claim.
Establish how changes will be reviewed
Approval should not depend entirely on what the application looked like at one review. Providers can add new features, alter analytics services, or update the scripts their websites load. These changes could influence which organisations get information and what data they have.
The NIST Generative AI Profile offers a broader basis for assessing hazards associated with generative artificial intelligence systems and third-party dependencies. For application privacy, that entails figuring out who is accountable for reviewing changes that could impact the original approval.
Organisations should specify timescales for vendors to inform them of important changes, what changes need to be reassessed and who will review the evidence. They should also note any conditions related to the approval.
For example, a platform might be appropriate for typical business queries but not for talks that involve certain categories of sensitive or regulated information. This provides the firm with a decision they can act on, rather than just a label of accepted or denied with no rationale behind it.
What a Privacy Review Can and Cannot Establish
A rigorous privacy examination only goes so far. A browser test logs what happens under certain conditions, with a certain account, setup and set of interactions. It cannot guarantee that all possible data transfers have been discovered. That doesn’t make testing pointless. It means the findings need to be contextualised.
An assessment should record what product version was tested, what information was entered, what destinations were observed and whether the results were consistent with the provider’s disclosures. The UK Information Commissioner’s Office guidance on accountability also emphasises the necessity of maintaining a record of how companies assess and manage personal data risks, including interactions with other organisations.
For corporate purchasers, the best evidence is a combination of technical observations, unambiguous explanations from the seller and contractual promises. Where such sources differ, the organisation must settle the disagreement or record the doubt remaining before taking an approval decision.
The purpose is not to prove that an application can never leak information. It’s understanding the dangers well enough to know what information the business can fairly expect it to take care of.
Final Thoughts: AI Chat Privacy Requires More Than Provider Assurances
An AI provider may enforce strict controls on model training and conversation retention, but may still rely on external services to run its chat application. Those services raise another set of questions regarding who gets information and what they are allowed to collect. T
he new research provides businesses with a compelling reason to address those questions before allowing a platform for sensitive business use. It also illustrates the requirement for privacy documentation, technological testing and vendor accountability to support each other.
With AI chat apps becoming embedded in day-to-day business processes, businesses will need to constantly re-check that the information flows they originally allowed are still taking place. For more on the security and governance decisions affecting enterprise AI adoption, EM360Tech continues to examine how organisations may weigh new technologies against the risks of deploying them in practice.
Comments ( 0 )