Data for AI Products
Using Your Own Product's Data as a Training Asset
The data you need is usually already inside your product. It is just wearing a disguise.
PMs consistently underestimate what they already have and overestimate what they need to buy. So before you write a single line of a vendor RFP, do the inventory. You are looking for places where a human already made a judgement inside your product, because a recorded human judgement is a label in disguise.
Here is what that looks like across product types.
| Signal already in your product | What it can teach a model | The trap |
|---|---|---|
| Support agent replies to tickets | Tone, escalation policy, correct resolutions | Agents copy-paste macros. The model learns the macro, not the reasoning. |
| Search queries with no click | What your search is failing at, which is a gold mine for a retrieval feature | The absence of a click is ambiguous. It can mean "bad results" or "found the answer in the snippet". |
| Edits users make to your AI's draft output | The single highest-value fine-tuning signal you can own. The delta between machine output and human-accepted output is the lesson. | You have to instrument it deliberately. Most teams throw the edit away and only save the final text. |
| Thumbs up / thumbs down | Coarse preference. Useful in aggregate, weak per example. | Fewer than 1 in 100 users click it, and the ones who do are angry. Heavily skewed. |
| Human review queues (fraud, moderation, credit) | Expert decisions on exactly the hard cases you care about | Reviewers only saw cases the old system flagged. Your data has a hole shaped like your old system. |
| Internal wikis, SOPs, playbooks | Grounding knowledge for RAG | Half of it is out of date, and nothing in the document says which half. |
The third row is the one I want you to sit with. If your product already shows an AI-generated draft that a user then edits, you are sitting on a proprietary preference dataset that no competitor can buy. Every edit is a human telling you, for free, exactly how your model was wrong. Grammarly, GitHub Copilot, and every serious AI writing product on the market is built on this loop. If you are not capturing the pre-edit and post-edit pair, you are throwing away your moat every single day.
Fig 1.4 - The edit-capture loop. The blue node is the only part that requires a deliberate product decision, and it is the only part that competitors cannot replicate.
Now the uncomfortable part. Having the data is not the same as being allowed to use it. Two questions decide this, and both belong to you, not to legal, because legal cannot answer them without you.
1. Did the user consent to this specific purpose? A privacy notice that says "we use your data to improve our services" was written before anyone imagined model training. Under India's DPDP Act, 2023, with the DPDP Rules notified on 14 November 2025 and substantive obligations landing on a phased timeline into 2027, consent must be free, specific, informed, and tied to an itemised purpose. Under GDPR, you need a lawful basis you can point to and defend. "It was on our terms" is not a plan.
2. Can you take it back out? If a user exercises deletion rights, you can delete their row from your database in an afternoon. Removing their influence from a trained model is a genuinely hard research problem. Design for this before you train, by keeping training data as a rebuildable snapshot with clear lineage, not as a mystery blob someone exported to a laptop in March.
YOUR MOVE THIS WEEK
Run a 45-minute "data inventory" with one engineer and one ops lead. Three columns: signal, where it lives, whether we are allowed to train on it. You will be surprised twice. Once by how much you already have, and once by how little of it is currently being kept.