Long before anyone trained a model on customer data, the marketing data business worked out the terms for pooling it.
<![CDATA[ <article> <p>Long before anyone trained a model on customer data, the marketing data business worked out the terms for pooling it. Catalog retailers in the 1990s joined data cooperatives that combined their transaction histories so each member could find new buyers, and the arrangements held together because the rules were blunt. </p><p>A retailer contributed data to receive modeled prospects; no member got a rival's customer file; and a company that stopped contributing stopped receiving. Card fraud consortia run on similar give-to-get terms. Nobody would call these systems elegant, but every participant understood the trade.</p><p>Software vendors building AI features are now running into the same question, usually without the rules. Traditional software sat on top of a customer's data and operated on it. AI products learn from data, and on a multi-tenant platform, that learning rarely stays within a single account. </p><p>One company's records can sharpen the enrichment, lead scoring, and recommendations delivered to thousands of others. A vendor can improve its product for every customer by relying on the work of a few, and most contracts say nothing about whether that trade is fair. The customer still owns its data in any legal sense. </p><p>Ownership alone doesn't answer who benefits.</p><h2 id="users-push-back-on-sharing-hard-earned-data">Users push back on sharing hard-earned data </h2><p>HubSpot learned how touchy the question has become when it announced plans to pool enrichment data across customer accounts, including business contact details, employer information, and email deliverability signals, to improve prospect records platform-wide. </p><p>Every account was in by default. Within days, the company dropped the plan and promised that any future enrichment feature built on customer data would be opt-in. <a href="https://www.techradar.com/reviews/hubspot-crm-review" target="_blank">HubSpot</a> had stated clearly that core CRM records would never be shared without permission, so privacy in the usual sense wasn't what upset the sales and RevOps teams, who pushed back. Their concern was harder to answer. Years of work spent cleaning and enriching their own contact data were about to improve the prospecting tools available to every other customer, competitors included, and nobody had asked what they would get for it. The product terms that allowed the change had been updated nearly two years before most customers heard about them.</p><h2 id="ai-creates-accidental-data-companies">AI creates accidental data companies</h2><p>Plenty of software companies adding <a href="https://www.techradar.com/best/best-ai-tools" target="_blank">AI tools</a> have never had to think this way. They are becoming data companies one model at a time, often without deciding to. Whether a customer's information feeds a shared model is often determined by a product team working toward a launch date rather than by anyone who owns the commercial relationship, and the answer is expressed in terms few buyers read. </p><p>McKinsey's 2026 survey on AI trust found that only about 30% of organizations have reached a mature level in AI strategy, governance, and controls. Pooled training data tends to fall between legal, product, and sales, with no single team feeling responsible for explaining it.</p><h2 id="the-need-for-strong-exit-clauses">The need for strong exit clauses </h2><p>Buyers will force the issue long before regulators do. Security certifications and uptime guarantees became standard contract language over the past decade because enough customers asked for them that vendors stopped arguing, and AI data terms are heading down the same road. Procurement teams are starting to ask whether their data trains or enriches models used by other customers, whether participation is opt-in, and whether it can be switched off later without losing core features. The more demanding buyers want to know what a contributing customer receives that a non-contributor doesn't.</p><p>Exit terms will be the hardest part to write. A customer can cancel a contract and demand its records back, but data that has already shaped a production model can't be cleanly pulled out again. Retraining is expensive, and removing one customer's influence from a live model remains an unsolved problem for most vendors. A vendor can honestly say it deleted every record a customer ever uploaded and still be running a model those records helped build. Contracts written for <a href="https://www.techradar.com/best/best-cloud-storage" target="_blank">storage</a> assumed that deleting data ended its use. Contracts written for AI will have to say plainly what persists after a customer leaves, and whether the customer agreed to it when it signed.</p><p>Opt-in consent answers part of the question. A checkbox tells a vendor it may use the data, but it says nothing about the return, and a customer who opts in for nothing in particular has made a poor bargain, even if it's a legal one. The old cooperatives signed up members because members could see exactly what they were getting.</p><p>Vendors that explain their data economics before customers ask will have an easier time at every renewal. The explanation belongs in the product and in the contract, and it should cover which customer data feeds shared models, what those models produce, and what contributors get back. Security questionnaires were once a formality, until buyers made them a condition of the sale. Pooled data terms are on the same schedule, and vendors that write clear ones now will set the standard that the rest of the market will follow.</p> </article> ]]>
