Delete the payment records before Monday, even if the product’s strongest AI feature gets worse. A model trained or evaluated on data the company has no right to retain turns technical advantage into legal, commercial and reputational exposure.
In 2015, Facebook learned that data collected through Aleksandr Kogan’s personality quiz app had been passed to Cambridge Analytica. Facebook said it demanded that Kogan, Cambridge Analytica and another recipient delete the data and certify that they had done so.
The unresolved question was simple: had the data actually disappeared?
In 2018, reporting by The Observer, based on information from former Cambridge Analytica employee Christopher Wylie, showed why a deletion request and a certificate were weak substitutes for verification. Copies of the data had reportedly remained outside Facebook’s control. The company had treated deletion as an administrative promise when the real problem was technical possession.
A startup facing a Friday deadline operates at a different scale. The mechanism is the same. Once data has crossed into exports, training files, backups, notebooks and derived features, deleting one database table does not settle the question.
The feature had inherited a data-rights problem
Payment records can make an AI feature look unusually capable. They contain repeated behaviour, amounts, timing, merchants, failed transactions and account history. A model can use those patterns to classify activity, predict intent or produce recommendations that feel specific to each user.
That performance can hide a prior question: what gave the company the right to keep those records for this use?
A payment processor may provide data to complete transactions or support an account. That does not automatically grant permanent retention for model training, offline experiments or future product development. The relevant answer depends on the agreement, the user notice, applicable law and the purpose recorded when the data was collected.
I would treat Friday’s discovery as a product incident, not a paperwork problem. The team should pause new training runs, identify every location containing the records and stop the dataset from spreading while counsel or the appropriate privacy lead confirms the company’s position.
This is where small teams often discover that their “dataset” is several datasets: a production table, a CSV on a laptop, a notebook copy, a model-training bucket and a backup nobody remembered during the first meeting.
Deletion has to follow the data
The first useful document is a data map made for action, not presentation. It should show where the original payment records entered the company, who copied them, which systems received them and what each system produced.
Then the team can separate three categories:
- Raw records that can be located and deleted.
- Derived tables that still expose transaction-level information.
- Trained models, embeddings or aggregate outputs that may retain or reveal information from the source.
That third category deserves care. Deleting a CSV does not answer whether the model built from it can remain in production. The team needs a recorded decision from someone qualified to make it, based on how the model was trained, what it can reproduce and what rights covered that processing.
The same inventory also protects runway. Without it, engineers can spend the weekend deleting obvious copies, then discover on Monday that an automated job recreated the dataset from an untouched source.
A related failure appears when teams design around the clean system they expect and miss the unofficial copy people actually use. I wrote about that pattern in the shared spreadsheet the demo did not account for. Data governance breaks in similar places: exports, temporary workarounds and forgotten operational files.
Product performance cannot settle the decision
The hardest objection usually arrives from inside the product team: deleting the records will reduce recommendation quality, delay the demo or erase months of experimentation.
All three may be true.
They still do not create a right to retain the data. A strong feature built on uncertain permission has an unstable foundation. A prospective partner reviewing the product may care less about a few points of model performance than whether the company can explain where its training data came from and prove what happens when retention ends.
The practical choice is to preserve what the company can defend. Keep code, evaluation methods, schemas that contain no personal data, experiment notes and documented aggregate findings where permitted. Delete or quarantine the records and derived assets whose retention cannot be justified. Record what was removed, when, by whom and how deletion was checked.
Then rebuild the feature around data collected with a clear purpose and retention rule. That may mean explicit permission, narrower inputs, synthetic test data or an architecture that computes a result without keeping the underlying transaction history.
Monday needs evidence, not reassurance
Facebook’s Cambridge Analytica problem shows the weakness of treating deletion as correspondence. A request was sent. Certifications were obtained. Years later, the central question remained whether the data had truly been removed.
A founder should leave the weekend with more than a message saying the folder is gone. The useful evidence is a deletion log, a list of affected systems, confirmation that recurring pipelines have stopped, a decision on derived models and a named owner who will check that the data does not return.
The feature may perform worse on Monday. That result is visible and fixable. Undocumented copies of payment records are harder to see, and every new backup or model run makes the eventual correction more expensive.
Before anyone retrains the model, open a blank document and write down four things: the source of each field, the permitted purpose, the retention period and the deletion path. Any empty cell is work that comes before the next experiment.
Comments
No comments yet.