presentsUNAIVERSE
The UN AI timeline

    Learn AI /Model Quality and Evaluation /Data leakage

    Data leakage

    Also called: leakage, target leakage.

    Detail

    In five seconds

    What it is

    Data leakage happens when future, target or held-out test information improperly influences model training or evaluation, making performance look better than it is.

    In plain words

    A system can look smart in testing if it was given clues that would not exist in real use. Then the score is misleading.

    An everyday example

    A team is testing whether a new search assistant can sort policy documents into the right folders. One staff member quietly leaves coloured stickers on several folders that match the correct destination, because those stickers were added after the documents had already been filed. During the test, the assistant appears highly accurate because it follows the stickers rather than reading the documents carefully. When new unstickered documents arrive, its performance drops sharply.

    Where the story stops working

    A search assistant in this story can visibly choose the stickers, while a machine learning model does not recognise leakage as suspicious. It only detects statistical patterns. Also, real leakage is often subtle, such as duplicated records, badly timed data preparation, or target-derived variables, not obvious marks placed on folders.

    Remember thisIf a model gets hidden clues during training or testing, a strong score may measure the leak, not the model.

    Understand it

    Understand it

    Why it matters

    A leaked model can pass testing, win budget, and enter operations even though it does not truly work. That creates poor decisions: systems may be procured, deployed or trusted on the basis of scores that were never a fair test. For programme teams, this can mean missed cases, wasted staff time, unfair treatment, or false confidence in dashboards and automation. For technical teams, leakage blocks honest comparison between models because the evaluation no longer reflects reality. Spotting leakage early helps teams ask a simple but powerful question: would this information really be available at the moment we need the prediction?

    Clean evaluation versus leaked evaluation

    After viewing, the reader should be able to explain why a high score can be misleading when future or target-related information enters training or testing.

    1. 01

      Clean features

      Inputs contain only information that would be available when the prediction is actually made.

      Left lane: draw a table labelled 'features available at prediction time' with neutral rows and columns.

    2. 02

      Proper split

      Training data and test data are kept separate so the test remains a fair check.

      Left lane: split the table into two non-overlapping blocks labelled 'train' and 'test'.

    3. 03

      Realistic score

      The model is trained on train data and evaluated on test data, producing a score that is more likely to match real use.

      Left lane: arrows from train to model, then from test to score card labelled 'credible evaluation'.

    4. 04

      Leaked clue enters

      A target-related field, future information, or duplicate case slips into the pipeline.

      Right lane: show an extra highlighted column or duplicate row entering before the split, with a warning symbol.

    5. 05

      Inflated test result

      Because the model or the test has seen an unfair clue, the score looks better than true performance.

      Right lane: arrows to a score card labelled 'too good to trust' with a higher number than the left lane.

    6. 06

      Deployment gap

      When the leaked clue is absent in real use, performance drops.

      Right lane: final arrow to a box labelled 'real-world data without leaked clue' and a lower score badge.

    A side-by-side diagram with two lanes read left to right. The left lane shows a clean pipeline from raw features to split to train to test to realistic score. The right lane shows a leaked clue entering before training or testing, leading to an inflated score and poor real-world performance. A warning icon marks the leak point.

    Hover or tap each lane to highlight the causal path from input design to evaluation result; a toggle can reveal examples of 'future data', 'target-derived column', and 'train-test overlap'.

    Describe this without the diagram

    This diagram compares two evaluation pipelines. In the clean pipeline, the input table contains only features available at prediction time. The data is split into separate training and test sets. A model trains on the training set and is scored on the test set, giving a credible result. In the leaked pipeline, an unfair clue enters before or during evaluation, such as future information, a column derived from the target, or duplicated cases across train and test. The model then gets an inflated score. When used on real-world data where that clue is absent, performance falls. The main message is that leakage creates misleadingly good evaluation results.

    With reduced motion: A static two-column comparison replaces animation. The left column shows clean features, proper train-test separation, and a credible score. The right column shows a leaked clue entering, an inflated score, and then lower real-world performance when the clue disappears.

    A model learns from input data and then produces an output, such as a class label or a score. Leakage happens when model building uses information that would not exist in real use, or information that should have been reserved for a fair test. It also happens when evaluation cases overlap with training cases.

    What goes in matters. If a spreadsheet includes a column created after the outcome happened, or if the same case appears in both training and test sets, the model can pick up shortcuts. Evaluation scores, such as accuracy, may then look unusually strong. The result is a misleading impression of quality.

    A common form is target leakage. This means an input contains target-derived or later information that would not be available when the prediction is made. For example, predicting whether a document will be archived while including a field filled in only after archiving creates an unfair clue.

    This is not the same as overfitting. Overfitting means a model matches quirks in the training data and then performs poorly on new data, even without leaked information. Leakage is a pipeline or evaluation flaw, so the score may be high for the wrong reason. A leaked model can seem excellent until it meets real-world data.

    How “A filing test with answer marks already showing” maps onto the real thing

    In the storyIn the AI system
    coloured stickers added after filinginformation created after the outcome that leaks the correct answer
    assistant using stickers to sort foldersmodel relying on leaked features instead of genuine patterns
    test documents with stickers presentevaluation data contaminated by leakage
    new unstickered documentsreal-world data at deployment time

    A worked example

    A reporting officer in a regional bureau tests a model to predict, at first submission, which implementing partner progress reports will miss clearance by close of business.

    Starting from: A workflow export containing first-submission metadata, later reminder timestamps, final clearance dates and several versions of some reports.

    1. The initial dataset keeps the final clearance date and a reminder timestamp, although neither would be available when the prediction is made.
    2. Rows are split at random, placing early and revised versions of the same progress report on opposite sides of the training and test split.
    3. The resulting performance appears strong because the model can infer the outcome from later workflow events and recognise closely related report versions.
    4. The reporting officer removes all fields created after first submission and groups every version of a report into the same split.
    5. Missing-value handling and other preprocessing are then fitted on the training data alone before being applied to the held-out test data.

    Result: The revised score is lower, but it now tests the intended task. The first evaluation contained both target leakage and non-independent test cases, so it overstated likely performance on genuinely new progress reports.

    In a United Nations workplace

    At Headquarters, a political affairs officer tests an approved classifier to flag incoming field updates for the briefing note due to the front office at 6pm. The historical dataset includes arrival metadata, editorial tags and final inclusion decisions.

    A final section heading, clearance timestamp or inclusion flag was created only after review and would not exist when a new update arrives. Revised versions of the same update may also fall into both training and test sets. Either leak can make the classifier look more reliable than it is.

    Before you try thisField updates may contain confidential, personal or security-sensitive information. They must not be entered into a tool that has not been approved for that material. Use an approved environment, minimise the data used, restrict access and retain human review of every proposed flag.

    Where you may hear it

    • A vendor demo during a procurement unit's technical evaluation
    • An ICT governance board reviewing pilot results
    • A model validation meeting before a dashboard is cleared for release
    • An internal audit interview on how training and test data were separated

    Avoid confusion

    Avoid confusion

    Often confused with

    Common misconceptions

    • If the test score is high, leakage cannot be the problem.

      Leakage often creates exactly that pattern: unusually high scores that look impressive. A test set is only useful if it stays independent and realistic. If future information, duplicate cases, or target-derived fields slip in, the score stops being a trustworthy check.

    • Leakage only means someone intentionally copied answers into the dataset.

      Most leakage is accidental. It can come from a harmless-looking preprocessing step, a timestamp mistake, a column updated after the outcome, or records from the same case appearing in both train and test. The issue is not intent; it is whether unfair information entered the pipeline.

    • Leakage and overfitting are the same thing.

      They can both lead to poor real-world performance, but the mechanism differs. Overfitting means the model learned noise or quirks in the training data. Leakage means the model or the evaluation had access to information it should not have had, so the score was contaminated from the start.

    Quick check

    Which situation is the clearest example of data leakage?

    Go deeper

    Go deeper

    The simple version

    A system can look smart in testing if it was given clues that would not exist in real use. Then the score is misleading.

    The technical version

    Data leakage occurs when prediction-time-unavailable information or held-out evaluation information improperly influences model building, or when evaluation cases are not independent of training. Common mechanisms include target leakage, future data, duplicate or related records across splits, and preprocessing fitted on the full dataset before splitting. Leakage often makes evaluation overly optimistic because features, transformations or model choices benefit from information outside a fair pipeline. Memorisation is a model repeating training examples and can worsen duplicate-record leakage, but it is not the leakage itself. Data exfiltration is unauthorised copying out of a system, not this evaluation flaw. Check whether every feature existed at the prediction point and whether evaluation cases remained isolated from training and model selection.

    Reviewed external resources

    Where this came from

    Drafted with a language model through an offline pipeline, checked against this site's schema, and every external link above fetched to see whether it answers. Treat it as a starting point and check anything that matters against the primary sources. How this site is built and what that means.

    The one thing to remember

    If a model gets hidden clues during training or testing, a strong score may measure the leak, not the model.