Every data scientist knows the familiar, sinking feeling: a newly trained model returns with an astonishing 99 percent accuracy, and instead of celebrating, a wave of suspicion takes over. Nine times out of ten, the culprit is data leakage—some subtle piece of information buried in the training data that would never actually be available at prediction time in the real world.
To explore this persistent hazard, data scientists recently set out to answer two fundamental questions. First, how dramatic is that artificial accuracy jump when tested on real-world datasets rather than clean, toy examples? Second, if a machine learning pipeline is described to an artificial intelligence model beforehand—with zero hints or warnings that anything is amiss—can the AI successfully spot the leak? Furthermore, does the thoroughness of the answer change depending on the capability tier of the model being asked?
To find out, researchers took four real data projects and intentionally planted a different, well-known leakage pattern into each one. They trained real models both with and without the deliberate leaks, recording the actual performance metrics in each scenario. Separately, they described each pipeline in plain narrative terms to four different variants of Anthropic’s Claude models, ranging from the fastest iterations to the most powerful, asking each one what they would flag before trusting the reported results.
Setting Up the Experiment
Data leakage can infiltrate a machine learning workflow through various routes. A leak might manifest as a feature that mechanically defines the target label, a variable constructed using unauthorized future information, a data split that completely ignores underlying relational structures, or a crucial preprocessing step executed in the wrong chronological order.
For the artificial intelligence evaluation, the experiment tested Claude Haiku 4.5, Claude Sonnet 5, Claude Opus 5, and Claude Fable 5.1, covering a broad spectrum of speed and capability. Each model was evaluated in a fresh session with zero memory of the other tests, relying entirely on a closed-book description of the pipeline, features, or code snippets, with no ability to execute code or inspect the raw data directly. Crucially, none of the AI models were told that a leak existed in the descriptions.
Case 1: The Feature That Already Knows the Answer
The first phase of the experiment utilized datasets from a stock price direction prediction project. The core task was straightforward: predict whether Amazon’s closing stock price would land higher than that same day’s opening price, creating a binary label where the outcome equals one if the closing price exceeds the opening price, and zero otherwise.
When researchers fed the model that same day’s closing price and adjusted closing price alongside the opening, high, low, and volume figures, the validation accuracy soared to 97.0 percent, accompanied by an area under the curve of 0.999. However, when the model was strictly restricted to prior-day data—omitting anything from the day actually being predicted—accuracy plummeted to 51.6 percent with an area under the curve of 0.476, rendering it little better than a coin flip. That stark contrast between 97 percent and 52 percent encapsulates the entire danger of data leakage in a single metric.
When these pipelines were presented to the artificial intelligence models, all four caught the flaw instantly and for the correct underlying reason: the closing price directly defined the target label. Haiku characterized the setup as circular, while Sonnet noted that the model could easily reconstruct the label with a single comparison. Opus went even further unprompted, observing that if the high equals the open, the asset never traded above its opening price, meaning the label must be zero. Opus also correctly established its own baseline, predicting that an honest model should land in the low fifties for accuracy, matching the results of the clean run.
Case 2: The Dataset That Already Told You Where the Line Is
The second test moved to a delivery duration prediction project utilizing historical order data from DoorDash. The objective was to predict the delivery duration in seconds between an order being placed and its arrival. The experimental pipeline introduced an engineered feature representing the store’s average delivery duration, but this feature was constructed by grouping the entire table—combining both training and testing rows together—before performing a random train-test split on timestamped data.
This single engineered feature inadvertently carried two separate leaks. First, the store average was calculated using every row, including the exact rows about to be scored, meaning the model read a smoothed copy of the answer. Second, because the data inherently possessed a chronological order based on timestamps, shuffling the dataset before an arbitrary split allowed training rows to fall chronologically after test rows, a scenario impossible in a true production environment where future orders cannot inform past predictions.
Scored using root mean squared error in seconds, the leaked version reported an error of 862.7 seconds compared to 949.9 seconds for the honest version. This apparent nine percent performance boost came entirely from the leak rather than genuine learning. When evaluated by the AI models, every variant caught the store-average leak, but only three of the four models identified the dangerous practice of shuffling a timestamped table instead of executing a chronological split. Sonnet, Opus, and Fable all raised the chronological issue unprompted, with Fable offering the clearest explanation regarding the training set containing future orders. Haiku, by contrast, stopped after addressing the store-average feature and missed the secondary leak entirely.
Case 3: The Leak You Can’t See in a Single Column
The third case examined fraudster detection data from Revolut, where the objective was to predict whether a user was a fraudster based on their profile and transaction history. The underlying schema was naturally relational, featuring a user table with a fraud label and a transaction table with multiple rows per user. When the joined rows were split randomly, a vast majority of users ended up with transactions on both sides of the train-test boundary, allowing the model to recognize a user it had already encountered during training rather than detecting fraudulent behavior in an unseen individual.
A model trained using this flawed row-level split achieved an area under the curve of 0.960. When the data was properly split by user so that no individual’s transactions crossed the boundary, the honest area under the curve dropped to 0.898—still a solid model, but a realistic one. All four artificial intelligence models successfully named the exact mechanism unprompted, recognizing that because the label lived at the user level, a row-level split compromised the integrity of the evaluation. Opus delivered the most comprehensive response, noting that the true sample size was the count of users rather than transactions, and highlighting additional vulnerabilities such as account status fields that inadvertently revealed investigation outcomes.
Case 4: The Leak That Is Not in the Data at All
The final experiment addressed a loan flagging project featuring imbalanced credit data where roughly ten percent of loans were flagged as bad. To compensate for this imbalance, the flawed pipeline duplicated minority-class rows before performing the data split, leading to identical copies of the same loan landing in both training and testing halves.
When presented with a short code snippet outlining this oversample-then-split workflow—completely devoid of data or performance metrics—all four artificial intelligence models immediately flagged the methodological error. The oversample-then-split approach had reported an inflated area under the curve of 0.986, whereas the corrected split-then-oversample pipeline yielded a modest but honest 0.637. Opus provided the deepest critique, noting that stratifying on already-balanced labels was meaningless, pointing out the absence of random seeds, and questioning whether oversampling was even the correct strategic choice compared to adjusting class weights or reporting recall at a fixed review budget.
Conclusion
Every artificial intelligence model tested in the experiment successfully caught the primary planted leak in each scenario when asked to review the pipeline before trusting the results. This demonstrates that these hazardous patterns are recognizable when explicitly evaluated. However, significant differences emerged in the secondary insights provided alongside the primary catch. While Haiku offered brief and correct answers, its brevity occasionally caused it to miss co-existing leaks. Sonnet and Fable reliably caught multiple flaws when present, and Opus consistently delivered broader contextual insights, including realistic accuracy expectations and critical challenges to overall pipeline methodology.
The findings suggest that leveraging artificial intelligence to review machine learning pipelines before deployment offers a fast, accessible safeguard against common evaluation errors, though the depth of the feedback ultimately depends on the sophistication of the model consulted and the comprehensiveness of the pipeline description provided.
Nate Rosidi is a data scientist, product strategy professional, and adjunct professor teaching analytics. He is also the founder of StrataScratch, a platform designed to help data scientists prepare for technical interviews using real-world interview questions from leading technology companies.
