What Happens to Your Users' AI Data When Your Vendor Gets Acquired: Enterprise Risk Guide 2026

47 AI startups were acquired in 2024. Each one had enterprise customers. Each enterprise had users whose data was stored on the acquired company's infrastructure. When the acquisition closed, those users' data became an asset of the acquirer — subject to the acquirer's data practices, product decisions, and business interests.

What an acquisition actually transfers

When an AI company is acquired, the assets transferred include intellectual property, engineering talent, and user data. The data is often the most valuable asset — it is what trained the model and what continues to train future versions.

From a legal standpoint, data held by the acquired company becomes the property of the acquirer on the transaction close date. The acquirer assumes the data handling obligations of the acquired company, but those obligations are defined by the contracts and policies in place at the time of acquisition.

If those contracts do not include explicit deletion rights, prohibition on secondary use, or data portability guarantees, the acquirer is free to use the data under whatever terms were in the original agreements — even if those terms are broader than what enterprise customers believed they had agreed to.

The typical SaaS privacy policy says something like "we will not sell your data to third parties." An acquisition is not a sale. The data transfers as part of the business. That clause, which many enterprise buyers treat as a data protection guarantee, does not protect against acquisition.

The Rewind case study

Rewind built an AI personal assistant that stored and indexed user interactions. The product's original value proposition was local-first processing: your data stays on your device, AI happens on your hardware.

The business evolved. Cloud-dependent features were added. The local-first promise became partial, then largely nominal for users who enabled advanced features.

Meta acquired Rewind. The product was shut down. Users who had relied on Rewind for personal information management — years of indexed work history, communications, and activity — found that access ended on a fixed date.

Several issues compounded for enterprise users of similar products. First, data export was not straightforward. Users who wanted to extract their stored data before shutdown had to act within a specific window and navigate export tools that were not designed for bulk retrieval. Second, the shift in data practices from the original local-first promise to cloud-dependent operation had happened incrementally, without a clear moment where users understood their data was now on external servers. Third, no enterprise-grade advance notice or data retention period was offered.

For enterprises whose employees used Rewind for work-related productivity — meeting notes, document history, research — the shutdown was a business disruption, not just a personal inconvenience.

The Meta Ray-Ban pattern

Meta's Ray-Ban smart glasses capture audio and video. The AI assistant processes voice commands. In 2024, reporting documented that some audio captured through the Ray-Ban glasses was reviewed by human contractors as part of Meta's AI quality and safety processes.

The contractors were located outside the US. The review was not clearly disclosed to users. Users who understood they were interacting with an AI system were not clearly informed that human contractors might review those interactions.

This pattern is not unique to Meta. Standard terms of service for most cloud AI products include language permitting human review for quality, safety, and model improvement purposes. The disclosure is present — in dense legal language that does not match user understanding of how AI systems work.

For enterprise deployments, this pattern is directly relevant. When employees use an enterprise AI tool, they may reasonably assume they are interacting with automated systems. If those interactions are being reviewed by human contractors at the AI vendor — to improve the model, to flag safety concerns, or to maintain quality — employees are not aware of it, and the enterprise has not approved that access pathway.

The relevant question for enterprise legal and compliance teams: does your current cloud AI vendor agreement explicitly prohibit human review of inputs? If not, what does the vendor's standard policy permit?

What standard SaaS AI agreements miss

Most enterprise AI vendor agreements are adapted from standard SaaS contract templates. They were not written to address the specific risks of AI data handling. Four categories of protection are absent from 68% of standard agreements.

Explicit deletion rights. A standard agreement may say data will be deleted within a reasonable time after contract termination. It does not specify what "reasonable" means, what data categories are covered, or what happens to model weights that have learned from the data. Explicit deletion rights specify a timeframe (30 days post-termination), what is covered (all raw data and derived models trained on the data), and a verification mechanism.

Data portability requirements. The right to export your data in a usable format before contract termination or before a vendor is acquired. Without this, data stored in a proprietary format on the vendor's infrastructure may be practically irretrievable even if technically accessible.

Prohibition on training use. A clause that explicitly prohibits the vendor from using your enterprise data or your users' interaction data to train or fine-tune any model — including after an acquisition. This clause is the most commonly negotiated point in AI enterprise contracts and the most commonly missing in standard terms.

Change-of-control notification. A requirement that the vendor notify you within a defined period (typically 30-60 days) if a change of control event occurs that affects data handling — and that gives you termination rights if the new entity's data practices are not acceptable.

Negotiating these clauses requires legal counsel and is not free. But the alternative — operating without these protections at the scale of an enterprise AI deployment — is not risk-free.

The limits of contractual protection

Contracts slow and constrain vendor behaviour. They do not prevent it entirely.

An AI vendor that is acquired by a company with different values may choose to honour the terms of existing enterprise contracts — accepting the legal and financial consequences of non-compliance — as the cost of making a product or policy decision they view as higher priority. Contracts are enforced through litigation, which is slow, expensive, and rarely the fastest path to protecting user data.

More practically: an acquired vendor that is shutting down may not have the operational capacity to fulfil deletion and portability obligations on the contracted timeline. If the engineering team is being redeployed to the acquirer's products and the product is being sunsetted, the contractual deletion timeline may not be the acquirer's operational priority.

The contractual layer protects you in the long run. It does not protect your users' data in the 90 days following an unexpected acquisition announcement.

The architectural layer — keeping data off external servers entirely — is the only protection that holds in that scenario.

The architectural alternative

On-device AI changes the risk model fundamentally, not contractually.

If AI inference runs on the user's device using open-source model weights, there is no data stored on the AI vendor's infrastructure. An acquisition of the company that published the model weights has no effect — the weights are already on the device, operating under an open-source license that the acquirer cannot retroactively change.

If audio transcription runs on the device using Whisper, no audio ever reaches a cloud server. Human contractor review of audio is physically impossible. There is nothing to review.

If text generation runs locally on llama.cpp, no user queries are transmitted externally. No vendor policy change can affect the data handling of interactions that never left the device.

This is the architectural argument for on-device AI. It is not primarily a cost argument — though the cost case at scale is strong. It is a structural elimination of the risk scenarios that make cloud AI a CISO concern: acquisition risk, policy change risk, and undisclosed processing risk.

Protecting against the scenarios that have already happened

The scenarios in this article are not predictions. They have already occurred. The Rewind acquisition happened. The Meta Ray-Ban contractor review happened. OpenAI policy changes have happened multiple times.

Enterprise teams can respond in two ways.

The first is the contractual response: negotiate explicit deletion rights, data portability requirements, prohibition on training use, and change-of-control notification into every AI vendor agreement. This is appropriate for cloud AI features where cloud capability genuinely outperforms on-device alternatives and the data is not regulated.

The second is the architectural response: use on-device AI for features where the data is sensitive, regulated, or where a vendor shutdown would disrupt critical operations. This is appropriate for clinical documentation, financial services AI, internal productivity tools, and any feature where "the vendor was acquired and shut down" is a business continuity risk.

Most mature enterprise AI deployments use both. The decision is feature-by-feature, based on data sensitivity and the consequences of each risk scenario materialising.

How Wednesday advises enterprise clients on AI vendor risk

Wednesday's starting point for any cloud AI engagement is the risk scenario review: what is the worst-case outcome if the vendor is acquired? What happens to the feature if the vendor changes their data terms? What is the enterprise's exposure if user interactions are reviewed by third parties?

For features where any of those scenarios is unacceptable — typically because the data is regulated, the feature is operationally critical, or the data sensitivity is high — Wednesday's recommendation is on-device architecture, not contractual patches over cloud AI risk.

Off Grid is the reference for what on-device AI can deliver. Text, voice, and image AI — working offline, serving 50,000+ users, with no external vendor dependencies. The risk scenarios in this article are not Wednesday's customers' problem because the architecture makes them structurally irrelevant.