Imagina la situación. Tu equipo lleva tres años con un modelo en producción. No es el estado del arte, pero funciona: predice razonablemente bien, el pipeline de datos está estabilizado, el sistema de monitorización detecta la mayoría de las derivas, y todo el mundo sabe cómo tocarlo sin romper nada. Es el tipo de sistema que genera confianza silenciosa — nadie habla de él porque no da problemas.
Entonces aparece algo nuevo. Puede ser una arquitectura que acaba de publicarse en un paper, un framework que la comunidad ha adoptado masivamente en los últimos meses, o simplemente la constatación de que el enfoque que usasteis ya no es el que elegiríais hoy. Alguien en el equipo plantea la pregunta inevitable: ¿no deberíamos migrar a algo más moderno?
Y antes de que nadie haya abierto un notebook, antes de que se haya evaluado nada, aparece la primera respuesta. No viene de un análisis técnico. Viene de un lugar más visceral:
“Pero si llevamos tres años con esto…”
“Hemos invertido muchísimo tiempo en ajustar este pipeline…”
“El modelo ya lo conocemos bien, sería empezar de cero…”
Estas frases suenan a prudencia técnica. Suenan a experiencia. Pero en muchos casos encubren algo diferente: la falacia del coste hundido aplicada a decisiones de ingeniería de modelos.
Este entrada trata justamente de eso: de cómo un sesgo cognitivo bien documentado en economía contamina silenciosamente las decisiones técnicas en ciencia de datos, cómo identificarlo cuando ocurre, y cómo construir un marco de decisión que lo neutralice.
Tabla de contenidos
Antes de aplicar el concepto al mundo del machine learning, conviene definirlo con precisión, porque se malinterpreta con frecuencia.
Un coste hundido (sunk cost en inglés) es cualquier recurso ya consumido que no puede recuperarse independientemente de la decisión que tomes a partir de ahora. Tiempo, dinero, esfuerzo, atención — si ya se gastaron y no hay forma de recuperarlos, son costes hundidos.
La conclusión económica es tan simple como incómoda: los costes hundidos no deberían influir en ninguna decisión racional futura. La única información relevante para una decisión es lo que ocurre a partir del momento en que la tomas: los beneficios esperados de cada opción y los costes futuros de cada camino. El pasado, en tanto que irrecuperable, es irrelevante.
Esto choca frontalmente con nuestra intuición. El ejemplo clásico es la entrada de cine: pagas diez euros por una película que a los treinta minutos resulta ser horrible. La decisión racional es irte. Los diez euros ya están perdidos tanto si te quedas como si te vas. Quedarte solo añade tiempo perdido al dinero perdido. Y sin embargo, la mayoría de las personas se quedan — porque “ya han pagado” y marcharse se siente como un desperdicio.
Ese mismo mecanismo, trasladado a decisiones de ingeniería con mucho más en juego, produce errores mucho más costosos.
La falacia del coste hundido es precisamente eso: el error de dejar que recursos irrecuperables del pasado distorsionen decisiones que deberían basarse exclusivamente en el futuro. No es irracionalidad aleatoria — es un patrón predecible y bien documentado en economía del comportamiento. Y en ciencia de datos, tiene formas de manifestarse que son especialmente difíciles de detectar porque se disfrazan de argumentos técnicos legítimos.
La particularidad de los proyectos de ML es que acumulan costes hundidos en capas. No es solo el tiempo de entrenamiento inicial — es el tuning, las iteraciones, las pruebas fallidas, las integraciones, el conocimiento tácito del equipo, la documentación. Cada capa añade peso emocional a la decisión de cambiar. Y ese peso se filtra en el razonamiento técnico de formas que conviene identificar.
Este es el argumento más frecuente y, en su forma más pura, el más claro ejemplo de falacia.
El pipeline de datos — ingesta, transformación, feature engineering, validación — representa semanas o meses de trabajo. Está testeado, tiene sus quirks documentados, y el equipo sabe exactamente en qué puntos puede fallar. Cuando alguien propone migrar el modelo a una arquitectura diferente que implicaría rehacerlo, la resistencia es inmediata: ”¿Sabes el trabajo que nos costó montar esto?”
El problema es que esa frase mira hacia atrás. La pregunta relevante no es cuánto costó montarlo, sino cuánto costaría rehacerlo ahora y qué se gana a cambio. Si el pipeline existente tiene deuda técnica acumulada, si está acoplado a decisiones de diseño que ya no tienen sentido, si mantenerlo tiene un coste operativo creciente — todo eso son argumentos prospectivos perfectamente válidos para migrar. Pero “ya lo tenemos” no lo es.
Pero hay una sutileza importante: que el pipeline existente tenga valor real (documentación sólida, tests, estabilidad probada) sí es un argumento legítimo para quedarse, pero debe cuantificarse y compararse con los beneficios de migrar. Lo que no vale como argumento es simplemente su existencia como resultado del esfuerzo pasado.
El conocimiento acumulado sobre un modelo concreto — sus puntos ciegos, sus condiciones de fallo, sus rangos de operación seguros — tiene valor real. No es un coste hundido en sentido estricto: es un activo que el equipo posee y que puede aplicar a futuras iteraciones.
Pero este argumento se pervierte cuando se usa para evitar el coste de aprender algo nuevo, en lugar de para cuantificar el valor real de lo que se conoce.
La distinción importa: si el conocimiento acumulado sobre el modelo actual es transferible al nuevo (comprensión del dominio, intuiciones sobre las features, experiencia con los patrones de deriva), entonces su valor no desaparece con la migración — se reutiliza. Si en cambio es conocimiento muy específico sobre los artefactos de una implementación concreta (este hiperparámetro concreto en esta versión de esta librería), entonces su valor sí desaparece, pero eso no es argumento para quedarse — es simplemente un coste de transición a incluir en el análisis.
Donde aparece la falacia es cuando el argumento es “nos costó mucho aprenderlo” en lugar de “lo que sabemos vale X y perderíamos Y al migrar”.
El tuning de hiperparámetros, la selección de features, el ajuste de umbrales de decisión — en modelos complejos sobre dominios difíciles, esto puede representar un trabajo enorme. Y hay una tentación natural de tratar ese trabajo como un argumento en sí mismo para no cambiar.
Aquí el error es confundir estabilidad con bondad técnica. Un modelo muy ajustado puede estar sobreajustado al comportamiento histórico de los datos, incluyendo sus anomalías. El hecho de que funcione en producción no significa que sea el mejor enfoque posible — significa que el equipo ha aprendido a hacerlo funcionar. Eso tiene valor, pero no es lo mismo que valor intrínseco de la arquitectura.
El argumento correcto sería: “El tuning actual nos da un rendimiento de X, replicar ese rendimiento en la nueva arquitectura estimamos que costaría Y tiempo, y la ganancia esperada es Z.” Eso es análisis racional. “Hemos invertido años en esto” no lo es.
Hay una dimensión organizacional que merece mención aparte: cuando el coste hundido no es solo técnico sino político o reputacional.
Si un modelo fue una apuesta grande del equipo, si se presentó internamente como una solución estratégica, si hay personas cuya identidad profesional está vinculada a esa tecnología — migrar implica implícitamente reconocer que aquella elección fue subóptima. El coste hundido se convierte en coste reputacional, y eso añade otra capa de resistencia que raramente se nombra de forma explícita pero que contamina el análisis técnico.
Este patrón es particularmente difícil de detectar porque se racionaliza con facilidad. El argumento que se verbaliza es técnico; el argumento real es proteger una narrativa. Identificarlo requiere una honestidad organizacional que no siempre es cómoda.
Para cualquier decisión de migración o mantenimiento de modelo, existe una pregunta que neutraliza de forma eficaz la influencia de los costes hundidos:
Si empezaras este proyecto desde cero hoy, con el conocimiento actual, ¿elegirías esta arquitectura y esta tecnología?
La respuesta a esta pregunta no determina automáticamente qué hacer — pero sí determina qué argumentos son válidos.
Si la respuesta es sí, entonces mantener el modelo actual es probablemente la decisión correcta, y los costes hundidos no tienen ningún papel en ese razonamiento. El sistema existe, funciona, y lo elegirías de nuevo. No hay problema.
Si la respuesta es no, entonces la conversación correcta es sobre costes y beneficios futuros: ¿cuánto cuesta migrar? ¿Qué se gana? ¿En qué horizonte temporal? ¿Cuál es el coste de no migrar (deuda técnica, mantenimiento creciente, riesgo de obsolescencia)? Todas esas son preguntas legítimas con respuestas que pueden justificar tanto migrar como quedarse. Lo que no es legítimo como argumento es el esfuerzo pasado.
El test funciona porque obliga a separar dos cosas que tendemos a mezclar: la evaluación de la tecnología en sí, y el coste de transición hacia algo diferente. Ambas son relevantes, pero son independientes y deben analizarse por separado.
Hay una conexión entre la falacia del coste hundido y el concepto de deuda técnica que no suele hacerse explícita, y que creo que es especialmente relevante para proyectos de ML.
La deuda técnica — en su sentido más amplio — es el coste futuro que pagas como consecuencia de decisiones pasadas que priorizaron la velocidad o la conveniencia sobre la calidad estructural. En software general está bien documentada. En machine learning tiene características propias que la hacen especialmente peligrosa.
Un modelo de ML no es solo código: es código más datos más artefactos de entrenamiento más decisiones de diseño implícitas en su arquitectura. Cada uno de esos componentes puede acumular deuda. Y a diferencia del software general, parte de esa deuda es invisible: está codificada en los sesgos del conjunto de entrenamiento, en las features que se incluyeron sin justificación rigurosa, en los umbrales que se ajustaron a mano para resolver un caso edge y que nadie recuerda por qué tienen ese valor.
La conexión con los costes hundidos es esta: cada vez que un equipo decide no migrar o no refactorizar porque “ya está montado”, está convirtiendo el coste hundido actual en deuda técnica futura. El coste hundido de hoy es el interés que pagarás mañana.
Esto tiene una implicación práctica importante: el coste de migrar no es estático. Tiende a crecer con el tiempo, porque la deuda técnica se acumula y porque el ecosistema sigue evolucionando mientras el sistema permanece estático. Un análisis honesto de costes de migración debe incluir esta dinámica temporal — no es lo mismo migrar ahora que dentro de dos años.
En proyectos de machine learning, la deuda técnica toma formas particulares que vale la pena enumerar:
Una vez identificada la falacia y aplicado el test racional, la pregunta que queda es cómo estructurar el análisis de la decisión real. Aquí propongo un marco en tres ejes.
Este es el eje que más atención recibe, y con razón — pero tiende a subestimarse porque se calcula de forma incompleta.
El coste de migración visible incluye: tiempo de desarrollo para implementar la nueva arquitectura, tiempo de validación y testing, coste de reentrenamiento, periodo de operación en paralelo durante la transición, y coste de actualizar la documentación y los procesos.
El coste de migración invisible — el que se omite con más frecuencia — incluye: el tiempo de aprendizaje del equipo si la nueva tecnología es desconocida, el coste de los errores que inevitablemente aparecen durante la transición, el impacto en otros proyectos del equipo durante el periodo de migración, y el riesgo de regresión en métricas de negocio durante la transición.
Un análisis honesto debe intentar cuantificar ambos. Los costes invisibles tienden a multiplicar los visibles por un factor que varía según la complejidad del sistema y la experiencia del equipo con la nueva tecnología.
Este eje tiende a sobreestimarse en la dirección contraria: cuando hay entusiasmo con una nueva tecnología, el beneficio esperado se infla.
Los beneficios legítimos de migrar pueden incluir: mejora en métricas de rendimiento del modelo, reducción del coste de mantenimiento operativo, mejor alineación con el ecosistema actual (más soporte, más documentación, más talento disponible), reducción de riesgo técnico por obsolescencia, y mejora en la capacidad de iterar rápido en el futuro.
Para cada uno de estos beneficios, la pregunta relevante es cuándo se materializa y con qué probabilidad. Un beneficio de rendimiento que solo aparece tras seis meses de tuning en la nueva arquitectura tiene un valor presente diferente al de un beneficio inmediato.
Este es el eje que más frecuentemente se omite en el análisis, y es donde la dinámica temporal se vuelve crítica.
El coste de no migrar no es cero y no es estático. Incluye: el coste de mantenimiento creciente de un sistema sobre tecnología que pierde soporte activo, el riesgo de no poder incorporar mejoras futuras, el coste de oportunidad de no tener las capacidades que la nueva arquitectura permitiría, y la acumulación de deuda técnica con interés compuesto.
En el contexto específico del machine learning, hay un coste adicional que merece mención: el coste de deriva del modelo frente a un entorno cambiante. Un modelo estático en un dominio dinámico pierde rendimiento con el tiempo. Si la nueva arquitectura ofrece mecanismos más robustos de adaptación continua, el coste de no migrar incluye esa degradación acumulada.
La decisión racional es migrar cuando:
Beneficio esperado de migrar > Coste de migración + Coste de oportunidad del tiempo de migración
Y la decisión racional es quedarse cuando la desigualdad se invierte. Pero hay dos condiciones adicionales que modifican este análisis simple:
Un aspecto que suele omitirse en esta discusión es el papel que juega la monitorización existente del modelo en la decisión de migrar o mantener.
Un sistema bien monitorizado — con alertas de deriva de datos, seguimiento de métricas de rendimiento en producción, logging detallado de predicciones — proporciona información objetiva sobre el estado real del modelo. Esa información es exactamente lo que necesitas para construir el análisis de costes y beneficios con datos reales en lugar de suposiciones.
Si el modelo está degradando silenciosamente — si las métricas de producción muestran una tendencia a la baja aunque no haya alertas activas — eso es un argumento prospectivo concreto y cuantificable para migrar. No es el coste hundido del pasado: es el coste presente y creciente de mantenerse.
Si en cambio el modelo mantiene sus métricas estables y el sistema funciona con un coste de mantenimiento bajo y predecible, eso también es información objetiva — e inclina la balanza hacia quedarse, al menos hasta que aparezca un beneficio claro de migrar.
La monitorización, en este sentido, es la herramienta que convierte una decisión contaminada por sesgos cognitivos en una decisión basada en evidencia. Equipos sin monitorización robusta son más vulnerables a la falacia del coste hundido porque no tienen datos objetivos con los que contrastar los argumentos emocionales.
Para hacer concreto el marco anterior, recorramos un escenario hipotético con suficiente detalle para que sea útil.
Nótese que en ningún momento del análisis aparece el argumento “llevamos cuatro años con esto”. No porque sea incorrecto recordarlo, sino porque no aporta información relevante para la decisión.
Esta entrada trata principalmente de identificar la falacia del coste hundido, pero sería un análisis incompleto si no aclarara explícitamente que quedarse con el modelo actual puede ser perfectamente la decisión correcta — y no por las razones equivocadas.
Quedarse es racional cuando:
La diferencia entre estas razones válidas para quedarse y la falacia del coste hundido es siempre la misma: las razones válidas son prospectivas. No dicen nada sobre el pasado. Solo dicen que el futuro esperado de quedarse es mejor que el futuro esperado de migrar.
Para terminar este análisis, un checklist práctico. Si en una discusión sobre migración de modelo escuchas — o te descubres usando — alguno de estos argumentos, es una señal de alerta que merece examen:
La falacia del coste hundido en machine learning no es un problema de falta de conocimiento técnico — es un problema de cómo estructuramos el razonamiento sobre decisiones que involucran inversiones pasadas significativas.
Los equipos técnicos son, en general, buenos evaluando arquitecturas. Son menos buenos separando esa evaluación de la historia emocional del proyecto. Y esa dificultad no es una debilidad personal: es el resultado predecible de cómo funcionan los sesgos cognitivos bajo condiciones de incertidumbre y presión.
El antídoto no es ignorar el pasado — es ser explícito sobre qué argumentos pertenecen al análisis racional y cuáles son residuos emocionales de inversiones anteriores. El test de la pregunta contrafactual (¿lo elegirías hoy?) y el marco de análisis en tres ejes (coste de migrar, beneficio de migrar, coste de no migrar) son herramientas sencillas pero efectivas para estructurar esa separación.
Cuando un banco evalúa una solicitud de crédito necesita responder a una pregunta aparentemente simple:…
En el octavo aniversario de Analytics Lane seguimos ampliando nuestro laboratorio de aplicaciones interactivas y,…
Hoy, 2 de mayo de 2026, Analytics Lane cumple exactamente ocho años. Todo empezó con…
La nueva herramienta permite calcular la rentabilidad real de inversiones con múltiples aportaciones, retiradas y…
Analytics Lane continúa ampliando su laboratorio de utilidades para desarrolladores y analistas de datos con…
Analytics Lane continúa ampliando su laboratorio de herramientas para desarrolladores con el lanzamiento del Formateador…
This website uses cookies.