AI makers are rediscovering an old bargain about sharing data
TechRadar argues that software vendors adding AI features face the same pooled-data trade-offs that marketing cooperatives settled decades ago.
According to TechRadar, AI software vendors are revisiting a problem that the marketing data business worked out long before machine learning became common: how companies should share customer information when each of them wants something in return. The outlet's analysis points to 1990s catalog retailers, who joined data cooperatives that combined their transaction histories so each member could find new potential buyers.
TechRadar describes those cooperatives as durable because their rules were simple. A retailer that contributed records received modeled prospects in return. No participant received a competitor's customer file, and a company that stopped contributing also stopped receiving the pooled results. The article notes that card fraud consortia operate on similar give-to-get terms, which suggests the arrangement has worked across more than one industry.
The central claim of the piece is that AI product teams now face the same question about pooling and reusing customer data. TechRadar credits the older systems with clarity rather than elegance: everyone involved understood the trade they were making.
The article focuses on this historical parallel rather than on any specific product, contract or policy change, so its argument is best read as a framing of the problem instead of a report on a new industry decision.
Background
Direct marketing has long relied on shared information. Mail-order and catalog businesses built lists of customers and their purchasing habits, and through the decades these lists were rented, exchanged and combined. Data cooperatives grew out of this practice, allowing members to contribute their records to a common pool and then use statistical models to predict which people outside their own customer base were likely to respond to an offer.
The logic that made these pools workable was reciprocity. Members did not hand over their most valuable information for free; they received analytical output in return, and the rules generally kept competitors from seeing one another's raw files. Fraud prevention followed a related pattern. Banks and card networks have shared signals about suspicious activity so that a problem spotted in one place can be flagged elsewhere, again on terms that every participant accepts.
Modern machine learning raises the stakes. A model is only as useful as the examples it learns from, and customer interactions, support logs and usage patterns are often the most informative examples a company has. Using that material to improve a product can blur the line between serving a customer and training a system that serves others. Privacy frameworks in the European Union and several U.S. states have tried to define what consent, purpose and retention should look like in this setting, though the rules differ widely in detail and enforcement. Software vendors therefore face a question the marketing industry faced earlier, but with more personal data, more complex models and a more public debate about what customers were promised.
Why it matters
The parallel TechRadar draws is useful because it shows that data pooling is not new and that it can work when the terms are clear. The difficulty for AI vendors is that their products often do not map neatly onto the old model. A cooperative could define what was shared, who could see it and what members received. An AI feature may learn from data in ways that are harder to trace, and the output may not return to the contributor in any obvious form.
That gap matters for trust. Customers who agreed to one kind of use may not expect their information to shape a general-purpose system. Businesses that depend on their own proprietary data may worry that a vendor's model could benefit a rival. A give-to-get rule, if applied to AI, would need to say what counts as a contribution, what counts as a benefit and how departures from the arrangement are handled. Without those answers, the trade can look less like a fair exchange and more like a transfer that only one side can see.
The argument also invites a broader question about whether the lessons of older data markets transfer at all. Cooperatives were smaller, more formal and easier to police than today's sprawling software ecosystem. Still, the basic insight that a shared pool needs rules everyone can understand remains relevant, and it gives both vendors and customers a shared vocabulary for a debate that is often conducted in vague terms.
What to watch
Watch how AI vendors describe what they do with customer data in their own terms of service and product documentation. Clear language about training, retention and opt-outs will tell users far more than general promises about security or innovation.
Watch whether business customers begin to negotiate data terms more explicitly, especially where their own records might improve a model that competitors also use. Contract language on exclusivity and benefit-sharing could become a more visible part of software deals.
Finally, watch regulators and courts for signs of how existing privacy rules apply to data used in model training. Their interpretations will shape which give-to-get arrangements are practical and which are likely to draw scrutiny.
Viewpoints
Commentary from our columns: three angles on this story.
The Skeptic open questions and weak points
The historical comparison is appealing, but it deserves a hard look before anyone accepts it. Catalog cooperatives were built around a fairly narrow product: a list of likely buyers. An AI feature may draw on far more than purchase history, including text, behavior and patterns that nobody contributed on purpose. The old rules about who received what and who could see whose file were enforceable because the data was discrete and the outputs were easy to inspect. Neither condition is obviously true for a large model.
There is also a question of who sets the terms. Cooperatives were governed by members who could leave. Many software customers today accept updated terms with little negotiation and limited visibility into how their information is reused. A give-to-get bargain only works if both sides can see the bargain. Before calling the trade clear, we should ask whether customers can actually see what they are contributing, what they get back, and what happens when they stop. Those are open questions, and a tidy analogy does not answer them.
The Ledger the business angle
From a business standpoint, the cooperative model is interesting because it turned data into a shared asset with defined returns. Each member paid in through contribution and collected in the form of better prospects. The economics only held because the rules made departure costly and cheating visible. AI vendors have every reason to study that structure, since their products depend on data they often do not own.
The difficulty is that the returns are harder to price. A retailer could judge whether a modeled prospect list was worth its contribution. A customer of an AI feature, or a company whose internal records helped train it, has a much murkier sense of what they gained. Vendors that want durable relationships with business customers may find that clear, auditable exchange terms are a competitive advantage rather than a cost. The companies that treat data pooling as a simple grab will likely discover that partners stop contributing.
The Rulebook privacy, safety and regulation
The most useful lesson in this story may be the insistence on clarity. Cooperatives that worked had rules that participants could understand and enforce. That principle sits uneasily with how data is often handled in AI products, where consent may be buried in long documents and the path from a customer's input to a model's behavior is rarely explained in plain terms.
Privacy frameworks ask some of the right questions: what the data is for, how long it is kept, who can use it and whether people can say no. But the question of fairness in a shared pool goes further. Even if an arrangement is technically permitted, it should be legible to the people whose information makes it possible. Regulators and product teams alike would do well to ask whether an ordinary customer, reading a summary, would recognize the bargain being made. If they would not, the arrangement may be on weaker ground than its designers assume.