Qué pasó
El Department for Work and Pensions (DWP) es el organismo británico que administra las prestaciones sociales. Para detectar fraude en la ayuda de vivienda usó un algoritmo que asignaba a cada expediente un nivel de riesgo y enviaba los más altos a revisión humana. La idea, sobre el papel, es razonable: hay más expedientes que investigadores, y priorizar es exactamente lo que un sistema automatizado hace bien.
En junio de 2024, The Guardian reportó el resultado: el algoritmo marcó como alto riesgo a 200.000 personas, y dos de cada tres resultaron legítimas. Se gastaron unos 4,4 millones de libras en revisiones que no recuperaron un centavo.
Dos números en la misma frase. El primero cuenta a las personas investigadas sin motivo. El segundo cuenta lo que costó investigarlas.
Por qué pasó
El sistema se aprobó con un piloto. Y un piloto exitoso no es una medición: es una muestra, tomada en condiciones que casi nunca se repiten en producción. En un piloto los casos suelen estar más limpios, el equipo está más atento y el conjunto de datos es más chico y más homogéneo. Todo eso empuja el resultado hacia arriba.
Cuando ese mismo sistema sale a operar sobre la población completa, se encuentra con la realidad: variaciones que la muestra no contenía, situaciones legítimas que se parecen a las irregulares, expedientes con datos incompletos por razones que no tienen nada que ver con el fraude. La tasa de acierto baja. Eso no es una sorpresa, es lo esperable.
Lo que falló no fue la caída. Fue que nadie había definido de antemano cuánto podía caer antes de detenerse. Sin ese umbral escrito, el deterioro se vuelve invisible: cada mes se revisan expedientes, cada mes se cierra la mayoría sin hallazgos, y ese resultado se lee como "el sistema está trabajando" en vez de "el sistema se está equivocando dos de cada tres veces".
Hay un tercer elemento, y es de contabilidad. El costo de la revisión estaba en un presupuesto. El costo de las 200.000 personas investigadas sin motivo no estaba en ninguno, porque lo pagaron ellas. Un sistema cuyo error no aparece en ninguna línea del presupuesto de quien lo opera es un sistema que puede fallar durante años sin que nadie lo note.
Dónde te puede pasar a ti
No hace falta un ministerio. El patrón aparece en cualquier automatización que se aprobó con una prueba y se soltó sin un termómetro:
- El bot que en la demo resolvió veinte consultas seguidas y hoy escala la mitad a un humano, pero nadie mide qué proporción escala.
- El modelo de scoring de leads que se validó con los cien mejores clientes del año pasado y hoy prioriza mal, sin que nadie compare su ranking contra las ventas reales.
- La automatización de facturación que funcionó con los casos típicos y que un año después tiene a alguien corrigiendo excepciones a mano, en silencio.
La señal de alarma no es que el sistema falle. Es que nadie sepa decir en qué porcentaje falla, ni desde cuándo.
Cómo se evita
- El piloto declara sus condiciones. Cuántos casos, de qué periodo, con qué sesgos conocidos. Un piloto sin esa ficha no autoriza a escalar nada.
- Un umbral de parada escrito antes de arrancar. "Si la tasa de acierto baja de X durante dos periodos seguidos, el sistema se detiene y se revisa." La cifra se fija antes de tener resultados, cuando todavía no hay nada que defender.
- La medición corre sola. Un tablero que se actualiza sin que nadie lo pida, y que se mira aunque el mes haya ido bien. La revisión que depende de que alguien se acuerde no ocurre.
- El costo del error se contabiliza. Horas dedicadas a revisiones que no encontraron nada, personas afectadas, retrabajo. Si ese costo no tiene una línea, nadie lo va a defender.
- Un canal de apelación. Quien fue marcado tiene que poder decirlo, y esa corrección tiene que volver al sistema.
Cómo lo hacemos en Catalizadora
Ninguna automatización que entregamos sale sin su termómetro: un umbral escrito antes de encenderla y una medición que corre sola y avisa cuando el resultado cae por debajo. Contamos las veces que el sistema se equivoca con el mismo detalle con que contamos las que acierta, y esa cifra vive en un tablero que el cliente ve, no en un reporte que preparamos nosotros. Cuando un umbral se rompe, el sistema se detiene: no espera a la siguiente reunión.