La IA no es el problema.
El contexto sí lo es.

El argumento económico y de precisión a favor del grounding de los LLMs para la modernización del software empresarial

Cuando la IA reemplaza a desarrolladores junior en tareas de codificación de alcance limitado, genera código nuevo o analiza aplicaciones pequeñas y simples, la ecuación económica es sencilla. Los LLMs son más baratos y productivos que los desarrolladores humanos en estos escenarios. La IA opera dentro de un contexto restringido, centrándose en una porción acotada de código donde su razonamiento probabilístico funciona bastante bien.

Pero cuando se le pide a la IA que realice ingeniería inversa de sistemas de software muy grandes y personalizados que funcionan como el «cerebro del negocio» en empresas software-intensivas, los LLMs tienen dificultades, y tanto la investigación como la experiencia de campo confirman la causa raíz: la IA necesita urgentemente contexto arquitectónico, grafos de dependencias, flujos de transacciones y de datos. Esta necesidad se vuelve aún más pronunciada cuando se trata de transformar un «sistema de aplicaciones», es decir, un conjunto de aplicaciones interconectadas que juntas soportan workflows críticos para el negocio.

Estado de la situación

La industria de la IA gasta sumas sin precedentes en potencia de cómputo bruta. Los hyper-scalers invirtieron más de 370.000 millones de dólares en infraestructura de AI solo en 2025. Se proyecta que el consumo mundial de electricidad de los data centers se duplique hasta 945 TWh en 2030. ¿Por qué? Porque investigaciones revisadas por pares del MIT (2025) y otras instituciones han revelado un punto llamativo: la mayor parte de las mejoras de la IA en los últimos años ha provenido de asignar más hardware y energía al problema, no de algoritmos más inteligentes. Pero más compute no significa más precisión. En la transformación del software empresarial, la brecha entre «plausible» y «correcto» es donde los proyectos fracasan.

Algunos argumentarán que los LLMs mejoran visiblemente año tras año, y los proveedores señalan con razón los avances en reinforcement learning orientado al razonamiento, el pre-training a mayor escala y las nuevas arquitecturas de modelos. Estos avances son reales. La pregunta es: ¿en qué proporción? Y la respuesta respalda la tesis de este artículo: la IA necesita inputs más inteligentes y contextuales para alcanzar su pleno potencial.

Si la capacidad de la IA es fundamentalmente una función de cuánto compute se consume, entonces una IA sin grounding —la que debe descubrir su entorno mediante una exploración paso a paso— está quemando el recurso más costoso de la economía de la IA, mientras produce niveles de precisión e integridad estructural demasiado bajos para la modernización empresarial. Los enfoques sin grounding cuestan 10 veces más y producen resultados demasiado poco fiables para una modernización a escala. Sin grounding, los LLMs hacen arqueología probabilística sobre millones de líneas de código, y la arqueología probabilística produce resultados probabilísticos.

La tesis

La mitigación más eficaz no es un mejor prompt ni un modelo más grande. Es inyectar inteligencia determinista en la ecuación: flujos de datos reales, rutas de ejecución verdaderas, puntos de integración factuales. Información en la que la IA puede confiar para razonar sobre decenas de miles de componentes interconectados. En lugar de oponer inteligencia determinista y probabilística, este artículo sostiene que las grandes empresas deben combinar el poder de la IA con la precisión y exactitud de la tecnología de análisis determinista, para lograr la precisión e integridad estructural que requiere la modernización empresarial, a una fracción del costo.

I. La física del progreso en IA.
El compute es (casi) todo

1. La sabiduría convencional

El relato popular sobre el progreso de la IA es más o menos el siguiente: investigadores en los mejores laboratorios inventan nuevos algoritmos, arquitecturas y técnicas de entrenamiento ingeniosas. Estos avances hacen los modelos más inteligentes. El hardware ayuda, pero la verdadera magia está en el software.

Este relato es, en el mejor de los casos, incompleto. Un cuerpo creciente de investigaciones rigurosas y revisadas por pares demuestra que la infraestructura física de la IA —GPU, data centers y la electricidad para alimentarlos— ha sido el principal impulsor de las ganancias de capacidad, significativamente más que las mejoras algorítmicas o las arquitecturas de modelos.

2. La evidencia del MIT FutureTech

Dos artículos del MIT FutureTech ofrecen el análisis empírico más detallado de esta dinámica: «What Drives Progress in AI? Trends in Compute» (enero de 2025), y lo que parece ser un artículo de seguimiento «On the Origin of Algorithmic Progress in AI» (enero de 2026).

Este análisis, elaborado por Slattery, Roded, Del Sozzo y Lyu en el Laboratorio de Ciencias de la Computación e Inteligencia Artificial del MIT, establece el caso fundamental. Tomando como base los trabajos de Thompson et al. (2022) y Ho et al. (2024), el artículo concluye que el escalado del compute ha contribuido aproximadamente el doble que el progreso algorítmico a las ganancias de rendimiento efectivo de la IA (Ho et al., 2024). La potencia de cómputo utilizada para entrenar modelos de IA frontier ha aumentado aproximadamente 4-5 veces al año, superando con creces la Ley de Moore. Los actores industriales dominan el desarrollo de modelos frontier precisamente porque solo ellos pueden costear el compute necesario —el coste de entrenar un único modelo frontier asciende ya a decenas o cientos de millones de dólares. Finalmente, la relación entre compute y rendimiento sigue leyes de escalado suaves y predecibles: más compute produce de forma fiable mejores modelos, en todos los dominios.

El artículo concluye: «Si bien las mejoras algorítmicas desempeñan un papel vital, la mayoría de las ganancias de rendimiento han provenido del aumento de la potencia de cómputo.»

Este artículo de seguimiento (enero de 2026) va más lejos. En lugar de estimar la contribución relativa del hardware frente a los algoritmos, plantea una pregunta más profunda: ¿los propios avances de eficiencia algorítmica dependen del escalado del compute? La respuesta es sí. Mediante la eliminación quirúrgica de innovaciones relacionadas con algoritmos y experimentos de escalado (probando algoritmos con distintos presupuestos de compute), los autores descubren que las estimaciones anteriores acreditaban a los algoritmos una mejora de 22.000× en la eficiencia de entrenamiento entre 2012 y 2023. El nuevo artículo solo puede dar cuenta de «menos de 100×» de innovaciones algorítmicas específicas cuando se prueban experimentalmente. La brecha se explica por la «dependencia de escala»: dos innovaciones clave (la transición de LSTMs a Transformers y el cambio al equilibrio datos-parámetros óptimo de Chinchilla) ofrecen rendimientos de eficiencia crecientes a medida que el compute crece. A pequeña escala de compute, estas innovaciones aportan ganancias modestas. A escala frontier, parecen transformadoras.

El hallazgo principal: «hasta el 91 % de las ganancias de eficiencia medidas dependen del scaling exponencial histórico del compute.» Si los presupuestos de compute hubieran permanecido constantes, las innovaciones algorítmicas por sí solas habrían producido menos del 10 % de las mejoras observadas en la frontier actual. El artículo introduce también un concepto crítico: la «dependencia del marco de referencia». Una secuencia de modelos Transformer progresivamente más grandes (pero por lo demás idénticos) puede parecer mostrar un progreso algorítmico continuo en relación con una baseline LSTM, aunque nada en el procedimiento de entrenamiento haya cambiado. El «progreso» es enteramente un artefacto del desplazamiento a lo largo de una curva de scaling donde la brecha con la referencia crece con el compute. Esto crea lo que los autores describen como «la apariencia de progreso algorítmico sin nuevas innovaciones.»

Conclusión: «Los algoritmos no son más inteligentes. El hardware los hace parecer más inteligentes.»

Puede parecer contundente, pero los hallazgos del MIT no son aislados. Son coherentes con un amplio conjunto de investigaciones:

• «The Bitter Lesson» de Richard Sutton (2019). El influyente investigador de IA argumentó a partir de 70 años de historia de la IA que «los métodos generales que aprovechan el cómputo son, en última instancia, los más efectivos, y por un amplio margen.» Los métodos que aprovechan el conocimiento humano del dominio pierden sistemáticamente frente a los métodos que escalan con el compute.
• El análisis «AI and Compute» de OpenAI documentó que el compute utilizado para entrenar modelos frontier aumentó aproximadamente 10× al año, y que «en muchos dominios actuales, más compute parece conducir de manera predecible a un mejor rendimiento.»
• Harvard Kempner Institute, «The Power of Scale in Machine Learning» (2025) demostró que GPT-3 era 100× más grande que GPT-2 pero estaba basado en la misma arquitectura. Las ganancias de capacidad provenían principalmente de la escala, no de una gran novedad algorítmica.
• Toby Ord, «Evidence that Recent AI Gains are Mostly from Inference-Scaling» (2025): incluso para los modelos de razonamiento de última generación, el 82 % de las ganancias de rendimiento en los benchmarks MATH provenía del inference-scaling (gastar más compute en el momento de la inferencia), no de avances algorítmicos.
• Epoch AI, «Can AI Scaling Continue Through 2030?» (2024): proyecta que la producción de GPU se expandirá entre un 30 y un 100 % al año hasta 2030, identificando el crecimiento de los clusters de GPU como el principal impulsor del progreso continuo de la IA.

3. Los mercados de capitales y los proveedores de energía están de acuerdo

El mercado mismo revela dónde se está creando valor. El mayor ganador corporativo de la era de la IA no es una empresa de algoritmos —es NVIDIA. Los hyper-scalers cuentan la misma historia. Amazon, Microsoft, Google y Meta gastaron colectivamente más de 200.000 millones de dólares en capex de infraestructura de IA en 2024, con proyecciones que superan los 330.000 millones en 2025.

En el lado energético, la Agencia Internacional de Energía proyecta que el consumo mundial de electricidad de los data centers se duplicará hasta aproximadamente 945 TWh en 2030, el equivalente a unas dos veces la energía total consumida en Francia en 2024. El Departamento de Energía de EE. UU. informa que la electricidad consumida por los data centers pasó de 58 TWh (2014) a 176 TWh (2023), con proyecciones de entre 325 y 580 TWh para 2028.

II. La economía del grounding de la IA.
El impuesto agente vs el descuento grounding

El costo de una IA sin grounding se manifiesta en dos dimensiones. La primera es económica: tokens desperdiciados, exploración redundante, compute desbocado. La segunda, que se aborda en la Parte III, es más relevante: degradación de la precisión y compromiso de la integridad estructural del software resultante.

1. El impuesto de exploración

Cuando un agente de IA opera sobre un codebase grande, complejo y multi-tecnológico sin contexto arquitectónico determinista, debe descubrir la estructura del sistema mediante exploración, suposiciones, preguntas y ensayo-error. Cada prompt exploratorio, cada recarga de contexto, cada falso inicio causado por alucinaciones, cada ciclo de iteración consume tokens. Los agentes de IA se enfrentan a un problema de descubrimiento exponencial, que puede describirse de forma simplificada así:

1. La IA examina un componente e identifica dependencias desconocidas.
2. La IA investiga las dependencias más prometedoras, descubriendo incógnitas adicionales por cada dependencia.
3. El patrón se repite, creando un árbol de descubrimiento que puede alcanzar cientos de nodos.

Lo que debería ser una tarea enfocada se convierte en una «expedición de cartografía» que consume potencialmente millones de tokens, con una precisión que se degrada a lo largo del proceso debido a la naturaleza probabilística de cada bucle, construyendo esencialmente probabilidad sobre probabilidad sobre probabilidad. Es un problema de precisión. Cada inferencia probabilística se convierte en el fundamento de la siguiente. Para cuando el agente ha encadenado decenas de dependencias inferidas, la confianza acumulada es extremadamente baja. El desperdicio de tokens y la pérdida de precisión comparten la misma causa raíz: el agente está adivinando, y cada suposición amplifica la anterior.

2. Cuantificar el desperdicio

Los escasos estudios empíricos disponibles —principalmente de SWE-bench— miden agentes en repositorios Python open source bien estructurados de 10K a 100K líneas. Los objetivos de modernización empresarial son fundamentalmente diferentes: más grandes (con frecuencia 1M a 10M+ LOC), multilenguaje (Java, COBOL, C, frameworks, SQL, PL/SQL), con escasa documentación, décadas de deuda técnica acumulada, comentarios engañosos, dependencias circulares y convenciones de nomenclatura que frustran la exploración por palabras clave.

Estos estudios se centran en el consumo de tokens. Pero la economía va más allá del costo de los tokens: el verdadero gasto son los fallos y el retrabajo causados por una precisión e integridad insuficientes. Sin grounding, cada inferencia probabilística amplifica la siguiente, y el retrabajo provocado por alucinaciones se acumula a lo largo de las iteraciones. El desperdicio más importante no son los tokens en sí, sino un nivel de precisión tan bajo que los proyectos de modernización basados únicamente en IA son vistos cada vez más como fracasos.

Para que este artículo sea difícil de rebatir, las estimaciones que se presentan a continuación son deliberadamente conservadoras. Se extrapolan a partir de datos medidos en codebases más simples y tienen como objetivo establecer un orden de magnitud. Se invita a los lectores a considerar que las condiciones reales en entornos empresariales probablemente empujen el consumo real por encima de estas estimaciones, no por debajo.

2.1 Ingeniería inversa y refactoring

2.1.1 Primera capa: Ingeniería inversa

Esta capa cubre el trabajo analítico de comprensión de la arquitectura de cada módulo, sus dependencias, flujos de datos y lógica de negocio. Se realiza una vez por módulo, típicamente unos 50 módulos para una aplicación empresarial de tamaño mediano JavaScript/Java/SQL de 500K LOC.

(1) Nota sobre la fase de descubrimiento: La regla general según las fuentes indica que 1 token ≈ 4 caracteres para texto en inglés, pero el código es más denso, aproximadamente 3-4 caracteres por token dependiendo de la verbosidad del lenguaje. El recuento estático de tokens del codebase completo de 500K LoC sería de unos 6 millones de tokens (solo operaciones de lectura). El agente no lee todo el codebase durante la fase de descubrimiento, ya que la ventana de contexto (200K efectiva para 1M nominal) no puede contenerlo. Por ello, el agente lee selectivamente alrededor del 5-10 % del codebase, entre 250K y 500K tokens de código bruto, más prompts, historial, etc. 500K tokens para un descubrimiento «aproximado» parece ser el orden de magnitud correcto, 300K para ser conservador. Cabe destacar que, como el agente nunca puede «ver» más que un pequeño fragmento de la aplicación en un momento dado, trabaja a través de una cerradura, vuelta tras vuelta, releyendo fragmentos e intentando construir un modelo mental que en realidad no puede sostener.

(2) Con grounding, el agente recibe el mapa de componentes, sabe exactamente qué archivos modificar y comprende las dependencias de antemano. Similar a la reducción del 23-54 % constatada por SWE-Pruner, pero el grounding va más allá del pruning: elimina por completo la exploración para la parte del contexto arquitectónico (arquitectura real precalculada, grafos de dependencias, call flows, transacciones de extremo a extremo desde las entradas del usuario hasta el acceso a datos). Una estimación conservadora debería situarse en el rango de 100K-150K tokens por tarea de refactoring.

(3) La pérdida de precisión se acumula entre las fases. Un límite de módulo mal identificado en la Fase 1 conduce a un mapeo incorrecto de dependencias en la Fase 2, que produce un análisis erróneo de los flujos de datos en la Fase 3, que corrompe el rastreo de la lógica de negocio en la Fase 4. Para cuando el agente llega a la validación, está comprobando su trabajo frente a su propio modelo defectuoso, no frente a la realidad.

2.1.2 Segunda capa: Refactoring

Un refactoring completo es un conjunto de tareas, donde una «tarea» es un único ticket Jira o pull request, un cambio/funcionalidad/corrección específico (p. ej., «extraer la lógica de validación de pagos en un servicio separado», «refactorizar el manejo de errores en el flujo de pago», etc.)

Estas tareas se dividen en varias categorías:

• Refactoring estructural. Extracción de clases monolíticas en servicios, eliminación de dependencias circulares, separación de responsabilidades (p. ej., lógica de negocio mezclada en controladores o capas DAO), extracción de utilidades compartidas, reorganización de estructuras de paquetes. En una aplicación de 500K LOC, pueden existir cientos de estas.
• Modernización de la capa de datos. Migración a un framework de persistencia moderno, reestructuración de relaciones entre entidades, normalización de esquemas desnormalizados, extracción de patrones repository, reemplazo de procedimientos almacenados por lógica de aplicación (o viceversa), migración de una base de datos a otra.
• Refactoring de API e integraciones. Implementación de un mecanismo de API adecuado, estandarización del manejo de errores en todos los endpoints, reemplazo de llamadas síncronas por patrones event-driven, etc.
• Actualizaciones de framework e infraestructura. Migración desde versiones más antiguas, reemplazo de librerías obsoletas, actualización de patrones de autenticación/autorización, preparación para la contenedorización, reemplazo de soluciones propias de logging/configuración por frameworks estándar.
• Aspectos transversales — estandarización del manejo de excepciones, adición de observabilidad adecuada, hardening de seguridad, reemplazo de configuraciones hardcoded por configuración externalizada, introducción de inyección de dependencias donde falta, etc.
• Una regla general en la modernización empresarial es aproximadamente 1 tarea por 500 líneas de código, sabiendo que algunas zonas requieren un refactoring más intensivo y otras son solo retoques menores. Eso da 1.000 tareas para 500K LOC, lo cual se alinea con el dimensionamiento/pricing típico de los grandes GSI para programas de modernización.

La estimación de 1.000 tareas está en el extremo bajo del rango, especialmente considerando que cada una de ellas es un pull request discreto y revisable.

2.2 Estimación del número promedio de tokens por tarea

La documentación de Claude Code menciona que un desarrollador consume aproximadamente 300K-600K tokens por tarea básica (tareas de codificación en codebases familiares y de pequeño tamaño). SWE-bench por su parte muestra ~1M de tokens por tarea para repositorios Python pequeños (10K LoC) y bien estructurados. Para tareas de refactoring Java/SQL en entornos empresariales, el agente debe redescubrir el contexto cada vez, gestionar falsos inicios, recargas de contexto, etc. Una estimación mínima realista por tarea de refactoring debería situarse entre 1,5M y 2M de tokens. Esta cifra por tarea utilizada en este modelo también es deliberadamente conservadora. El baseline de SWE-bench de ~1M de tokens por tarea se midió en lo que son, sin duda, las condiciones más favorables que un agente de IA puede encontrar. Incluso bajo estas condiciones favorables, el agente consumió 693K tokens solo en operaciones de lectura (911K tokens en total a lo largo de aproximadamente 51 turnos de interacción, Sonnet 4.5) para intentar corregir un único bug.

El hallazgo del ICLR 2026 de una varianza de hasta 10× entre ejecuciones en tareas idénticas refuerza la idea de que una tarea con un promedio de 1,5M de tokens podría fácilmente alcanzar 5-10M en una ejecución desfavorable. En términos generales, los informes del sector indican que los workflows agentic han multiplicado el consumo de tokens por tarea entre 10 y 100× desde finales de 2023 (Adaline Labs, 2025). Por tanto, la estimación de 1,5-2M es una cifra que los profesionales empresariales pueden encontrar optimista.

3. Traducir los tokens en dólares (y en valor de negocio)

La modernización de nivel empresarial justifica el uso de modelos frontier; aplicando las estimaciones anteriores y la tarificación de Opus 4.6 (15 $/75 $ por millón de tokens de input/output) y un costo mixto de I/O de tokens (80/20 Input/Output), un programa de modernización de 1.000 tareas sobre una aplicación Java/SQL de 500K LOC costaría aproximadamente 43.000 $ en consumo de tokens solo, sin grounding arquitectónico. Con grounding determinista, el mismo programa consumiría aproximadamente 125 millones de tokens a un costo de unos 3.300 $, con un ahorro de unos 40.000 $ y más del 90 % de los tokens.

(*) Costo mixto (80/20 Input/Output), en línea con los hallazgos de SWE-bench sobre el balance Input/Output.

Vale la pena destacar que, sin grounding, la ingeniería inversa y el refactoring no están claramente separados en la práctica. Lo que ocurre es que el agente recibe una tarea (p. ej., «extraer la validación de pagos en un servicio separado») y comienza a explorar el codebase para entender el área relevante, luego intenta realizar los cambios en el código, luego explora más para validar dependencias, etc. Económicamente, esto significa que por cada dólar gastado en cambios de código reales, se gastan tres dólares en redescubrir el contexto arquitectónico. Con grounding, la ingeniería inversa se realiza una sola vez, fuera del agente, mediante CAST Imaging u otro motor de análisis determinista. La arquitectura precalculada se convierte en el input de cada tarea de refactoring.

4. El problema de los agentes desbocados. Y empeora.

Los escenarios anteriores asumen supervisión humana. Cuando las organizaciones despliegan agentes de IA autónomos sin grounding determinista, la economía puede volverse peligrosa:

• Bucles de exploración infinitos: el agente descubre una dependencia, la explora, encuentra más dependencias, continúa indefinidamente. Puede consumir más de 1M de tokens antes de la intervención humana.
• Espirales de alucinación: el agente hace una suposición incorrecta, la desarrolla, recibe retroalimentación contradictoria, intenta reconciliarlo, hace una nueva suposición errónea. La ausencia de convergencia implica un consumo ilimitado de tokens.
• Bucles test-fallo: el agente genera código, los tests fallan, el agente asume una mala comprensión, re-explora todo el codebase, lo intenta de nuevo, falla de nuevo. Puede quemar millones de tokens antes de la terminación.

Cada uno de estos modos de fallo no solo quema tokens. Produce código construido sobre errores acumulados, amplificando la crisis de precisión descrita en la Parte III más adelante.

Los frameworks agentic modernos incluyen ahora guardrails —presupuestos de tokens, límites de iteraciones, detección de bucles y cortacircuitos de costos— que previenen los escenarios más extremos de descontrol. Los mecanismos de guardrails y control de costos han surgido desde 2025 para prevenir costos desbocados. Los frameworks agentic (LangChain/LangGraph, CrewAI, etc.) permiten ahora establecer un número máximo de «pasos de pensamiento» por ejecución de agente... y Anthropic u OpenAI aplican cuotas de solicitudes por minuto y diarias/semanales, precisamente porque los grandes usuarios de Claude Code estaban quemando tokens a tasas insostenibles. Estos mecanismos son necesarios y bienvenidos. Pero son limitadores de daños, no soluciones. Los guardrails limitan el techo del desperdicio; el grounding elimina la causa del desperdicio.

III. El riesgo real.
Por qué la precisión es el factor decisivo, no el costo

Los ahorros de costos importan, pero no son la razón por la que fracasan los proyectos de modernización. El argumento real a favor del grounding determinista es la precisión y la integridad estructural.

Sin grounding arquitectónico, los agentes de IA que operan sobre aplicaciones de nivel empresarial están, por diseño, «adivinando». Infieren dependencias en lugar de conocerlas. Asumen patrones estándar donde existen desvíos legacy. Alucinan límites de servicios que no coinciden con la realidad. Los propios LLMs, cuando se les pregunta directamente, lo reconocen: necesitan inteligencia arquitectónica determinista (mapas reales de componentes, grafos de dependencias verificados, rutas de ejecución factuales, acceso a datos preciso...) para razonar de forma fiable sobre sistemas complejos.

Gemini de Google, por ejemplo, menciona la necesidad de un «Architectural Cheat Sheet». En resumen, piden ser groundados, o ser «context-aware». Una vez que se proporciona ese contexto, la diferencia en precisión e integridad es medible. Sin grounding, la precisión de la IA en aplicaciones empresariales complejas ronda el 30 % según varios proyectos reales. Con contexto arquitectónico determinista inyectado en el proceso, esa cifra supera el 85 % según un gran integrador de sistemas global que ha probado esto en múltiples aplicaciones de nivel empresarial.

Esto importa porque en la modernización de software empresarial, la precisión no es un espectro. Es un umbral: un módulo refactorizado en un 85 % no es útil en un 85 %. Si el 15 % restante incluye dependencias omitidas, fronteras de transacción rotas o flujos de datos cortados, el módulo puede ser peor que lo que reemplazaba.

Un enfoque basado únicamente en IA también puede introducir vulnerabilidades, romper la lógica de negocio o corromper datos silenciosamente. En industrias reguladas —banca, seguros, sanidad, aeronáutica, etc.— un único defecto estructural no detectado puede desencadenar fallos de auditoría, incumplimientos normativos o incidentes operacionales cuyos costos superan con creces cualquier ahorro en tokens. La integridad estructural amplifica esta preocupación. Incluso cuando los cambios de código individuales parecen correctos de forma aislada, el efecto acumulado de cientos de modificaciones generadas por IA en un sistema complejo puede degradar las cualidades a nivel de sistema —resiliencia, seguridad, rendimiento— de formas que solo se hacen visibles bajo carga o en producción. El análisis determinista aplicado según estándares establecidos (CWE para vulnerabilidades de seguridad-resiliencia-eficiencia, ISO 5055 para la calidad estructural global a nivel de sistema) proporciona la capa de verificación que la IA probabilística simplemente no puede ofrecer por sí sola. Sin ella, cada cambio generado por IA es una apuesta no verificada sobre la solidez estructural, lo que significa que la carga de verificación humana crece de forma exponencial.

Los artículos del MIT ayudan a replantear el problema de las alucinaciones. Los LLMs son sistemas probabilísticos. Cuando se les pide que deduzcan relaciones arquitectónicas a partir del código, infieren en lugar de analizar. El artículo del MIT de 2026 muestra que las mejoras algorítmicas no han cambiado esto fundamentalmente. Lo que ha mejorado es que más compute hace que los outputs probabilísticos parezcan más plausibles. Pero mientras que «más plausible» o «muy plausible» es aceptable en numerosas áreas, en ingeniería de software «más plausible» no es «correcto».

Así, aunque un ahorro de aproximadamente 40.000 $ en un programa de modernización es bienvenido, la pregunta más fundamental es: ¿cuál es el costo de modernizar incorrectamente una aplicación mission-critical? Para la mayoría de las empresas, la respuesta es varios órdenes de magnitud por encima del presupuesto de tokens. El grounding determinista no solo hace la IA más barata: la hace suficientemente confiable para usarla en los sistemas que más importan.

Conclusión

Con una precisión del 30 %, un programa de modernización de 1.000 tareas no produce una aplicación modernizada —produce un pasivo. Cada dependencia rota no detectada, cada flujo de datos cortado, cada transacción silenciosamente corrompida es un defecto que se manifestará en una auditoría, en producción o en una brecha de seguridad.

Esto no es un problema de costos. Es una crisis de integridad.

Los números hablan por sí solos. Sin grounding, un programa de modernización de 1.000 tareas quema aproximadamente 43.000 $ en tokens —de los cuales el 92 % se gasta en que el agente intente entender lo que está mirando, no en cambiar código. Con grounding determinista, el mismo programa cuesta aproximadamente 3.300 $.

El grounding determinista cambia la ecuación por completo. No haciendo la IA más inteligente, sino dándole algo que ninguna cantidad de compute puede generar por sí sola: la verdad sobre cómo funciona realmente un sistema. Grafos de dependencias reales. Rutas de ejecución verificadas. Flujos de datos factuales. Cuando la IA sabe en lugar de adivinar, la precisión supera el 85 %, el consumo de tokens cae un orden de magnitud, y la modernización se convierte en un proceso de ingeniería controlado en lugar de un costoso experimento probabilístico.

La decisión para las empresas no es si deben usar la IA —esa pregunta está resuelta. La decisión es si dejar que la IA explore a ciegas, quemando el recurso más escaso de la economía tecnológica en alucinaciones y retrabajo, o groundarla con inteligencia determinista y dirigir cada token hacia trabajo productivo.

Un camino lleva al 40 % de proyectos de IA agentic que Gartner predice serán abandonados para 2027. El otro lleva a una modernización impulsada por IA que realmente entrega resultados —dentro del presupuesto, a tiempo y con la integridad estructural que los sistemas mission-critical exigen.