Spotting Leakage and Proxies

Last time you learned to screen an input list on relevance, timing, appropriateness, and defensibility. This lesson zooms in on the timing question, because it hides the single most expensive mistake in AI-informed decisions: a result that looks spectacular in testing and collapses the moment it goes live.

In this lesson, you will learn to:

• Recognise leakage as information that only exists after the outcome you want to anticipate.
• Check a field list against the real moment when a person must act.
• Recommend a corrected test that uses only information available in real life.

Leakage is when a tool is allowed to look at information that only exists after the thing it is supposed to anticipate has already happened. Put plainly: the tool was told the answer before it was asked the question.

It never looks like cheating. It looks like a field sitting innocently in the same spreadsheet as everything else. Historical records are written after the fact, so they contain both the early signals and the aftermath, all mixed together in one tidy row. If nobody separates the two, the aftermath sneaks onto the input list, and the tool learns to read the aftermath instead of predicting anything at all.

The tell is a number that seems too good. When someone shows you 95% or higher on a messy, human, hard-to-predict business outcome, your first instinct should not be delight. It should be a simple question: what was this allowed to look at, and did all of it exist at the moment we would have needed to act?

Here is how that timing check sounds when Simone, who built an invoice-triage tool, shares a result with Emily, a colleague reviewing the same field list:

• Simone: The invoice-triage results came back at 96%. It flags which invoices will end up disputed.
• Emily: That's a strong number for something that messy. Can I ask what it was allowed to look at?
• Simone: Everything on the invoice record. Amount, supplier, line items, the dispute-resolution code, the closing-adjustment note.
• Emily: When does someone fill in the dispute-resolution code?
• Simone: After the dispute has been settled, so we can categorise it. Oh... that's the bit that already knows the answer.
• Emily: Right. So the tool wasn't flagging invoices that would be disputed. It was reading the note we wrote once they already were.

Notice that Emily never questioned anyone's competence. She asked one question about timing, and Simone worked out the problem herself, which is exactly the outcome you want.

There is a second pattern worth naming here. Sometimes an input is genuinely available at decision time but quietly acts as a proxy, a stand-in for something you would never allow directly. An office location, a job grade, or a customer's postcode can travel so closely alongside a protected characteristic that using one is effectively using the other. You cannot spot a proxy by looking at the field name. You spot it by asking what else that field tends to line up with, and whether you would be comfortable if it were replaced by the sensitive thing it mirrors.