La IA no ha reemplazado nada. Ha cambiado el precio de todo

El debate iba sobre lo que no era

Durante tres años, la conversación pública sobre la IA ha sido una discusión sobre el reemplazo. Un bando decía que no estaba pasando nada: un autocompletado con buen marketing. El otro decía que todo se acababa: las profesiones, las empresas, el propio mercado laboral. Ambos hablaban alto, ambos estaban seguros de sí mismos, y ambos cometían el mismo error: trataban una curva como si fuera un acontecimiento.

La vieja observación de Roy Amara sigue vigente. Sobreestimamos el efecto de una tecnología a corto plazo y lo subestimamos a largo plazo. El corto plazo produjo mucho drama y muy poco cambio. El largo plazo está llegando ahora, y es mucho menos dramático y mucho más trascendente de lo que esperaba cualquiera de los dos bandos.

Nada fue reemplazado. Muchísimas cosas cambiaron de precio. Y los precios son la materia prima de la estrategia.

Para un directivo que gestiona una empresa que a la vez produce software y consume software para funcionar, hay exactamente un cambio de precio que importa más que todos los demás: el coste de construir una herramienta que encaje exactamente con tu negocio, en lugar de alquilar una que no encaja.

Dos precedentes que valen por diez tertulianos

Las fábricas no se volvieron más rápidas cuando llegó la electricidad. La electricidad llegó en la década de 1890. La productividad industrial no se movió de forma significativa hasta los años veinte. La razón está bien documentada: la primera generación de fábricas electrificadas arrancó la máquina de vapor, atornilló un enorme motor eléctrico y dejó todo lo demás exactamente igual: los ejes de transmisión en el techo, las correas de cuero, las máquinas apiñadas alrededor del eje motriz porque ahí era donde estaba la potencia.

Habían cambiado la fuente de energía y conservado la arquitectura. La ganancia fue prácticamente nula.

La explosión de productividad llegó cuando alguien se dio cuenta de que la electricidad permitía poner un pequeño motor en cada máquina. Una vez que cada máquina llevaba su propia potencia, el eje de transmisión sobraba, y una vez desaparecido el eje, podías organizar la planta según el flujo real del trabajo. Ese fue el cambio. El motor era solo el habilitador.

Los contenedores eran una caja de acero. Cuando Malcolm McLean envió el primer buque portacontenedores desde Newark en 1956, la innovación era casi vergonzosamente simple. Las ganancias tardaron unos veinte años en materializarse, porque exigían reconstruir puertos, barcos, grúas, camiones, ferrocarriles, procedimientos aduaneros y convenios laborales. Y la distribución de ganadores fue brutal y geográfica: Newark subió mientras los muelles de Manhattan morían; Felixstowe subió mientras los muelles de Londres morían. La tecnología estaba al alcance de todos. La reorganización, no.

La lección que enseñan ambos precedentes es la misma, y es la lección en la que está fracasando ahora mismo la mayor parte de la adopción de IA:

La tecnología no es el cambio. La reorganización es el cambio.

Una herramienta de IA metida en un flujo de trabajo intacto es un gran motor eléctrico atornillado a un eje de transmisión. Funciona. Produce una demo. No produce casi ninguna ventaja acumulativa. La ventaja pertenece a quien detecte qué restricción ha desaparecido y reorganice la planta.

La restricción que ha desaparecido es el coste de escribir software que encaje.

Parte 1: El suelo — donde la IA asiste y no va a reemplazar

Toda empresa de software se asienta sobre un suelo de infraestructura: hipervisores, redes, almacenamiento, identidad, el plano de datos del cortafuegos. En la mayoría de las empresas, este suelo es hoy una mezcla de componentes de código abierto y comerciales, y la posición honesta es que no deberías estar construyendo nada de él.

Y no es porque sea «demasiado difícil». Es por cinco razones estructurales que la IA no toca:

La física no aparece en la ventana de contexto. Un enlace SFP28 que no levanta por un desajuste de FEC. Un disco que devuelve ILLEGAL REQUEST ante un IDENTIFY truncado. Una curva de ventilación, un backplane, un cable marginal. El diagnóstico de infraestructura real depende con frecuencia de estados que no son texto y no son alcanzables desde un prompt.

Asimetría de consecuencias. Un commit erróneo cuesta un revert. Una regla de cortafuegos errónea cuesta una caída o una brecha. Un comando de almacenamiento erróneo cuesta datos que no vuelven. La tasa de error tolerable difiere en órdenes de magnitud, y la tasa de error es precisamente donde los sistemas actuales siguen siendo poco fiables.

La responsabilidad no se puede delegar. Bajo PCI DSS, SOC 2, ISO 27001 o NIS2, hay una persona con nombre y apellidos responsable de cada control. Puedes delegar trabajo en un modelo. No puedes delegarle la responsabilidad, y ningún auditor aceptará el intento.

Los sistemas en producción no son bases de código. Un clúster de tres años tiene historia, deriva, decisiones sin documentar y un estado que nadie puede observar por completo. El código es legible. La infraestructura es arqueológica.

La economía de lo común. Hay quizá cuatro hipervisores que merecen la pena, y cada uno representa miles de años-persona. Construir el quinto era una mala idea en 2015 y lo sigue siendo hoy. Que el código sea más barato no lo convierte en buena idea.

Así que el suelo se sigue comprando o adoptando. Pero fíjate en lo que la IA hace realmente aquí, porque no es poco:

• Colapsa el tiempo de consulta en superficies documentales enormes. La mayor parte del tiempo de un sénior resolviendo incidencias no es pensar: es buscar cosas.
• Lee cuarenta mil líneas de logs y propone tres hipótesis ordenadas por plausibilidad.
• Escribe el rol de Ansible, el runbook, el informe post-incidente: la deuda de documentación que todo equipo de infraestructura arrastra y nunca salda.
• Explica un subsistema desconocido a las 03:00 al único ingeniero que está despierto y que no es su responsable.

Esto tiene un valor enorme. Simplemente es valor en el lado de la asistencia, y esa es una posición estructural, no temporal. La infraestructura es donde la IA es más útil como asistente y menos apropiada como agente autónomo.

Parte 2: Donde la IA cotrabaja — y qué determina realmente la frontera

«Asistente frente a agente» suele discutirse como una cuestión de capacidad del modelo. No lo es. La variable que importa es quién sostiene el bucle de verificación.

Modo asistente. El humano inicia, el humano revisa cada salida, el humano está en el bucle en cada paso. Es lo correcto para acciones irreversibles, sistemas en producción y cualquier cosa donde el coste de una acción errónea supere el coste de una lectura humana.

Modo agente. La IA inicia e itera contra un oráculo automatizado. El humano revisa el resultado y el diff, no cada paso. Esto requiere dos cosas:

1. Una señal de verificación rápida y fiable: tests, un verificador de tipos, un linter, un entorno de staging, un apply idempotente con un dry-run que funcione.
2. Un radio de impacto acotado: una rama, un contenedor, un namespace de pruebas, un rollback que se haya ensayado de verdad.

Si no tienes ninguna de las dos, no tienes IA agéntica. Tienes IA sin supervisión, que es una cosa distinta y considerablemente peor.

La implicación estratégica es la parte que los directivos pasan por alto sistemáticamente:

La cantidad de apalancamiento de IA que puedes extraer con seguridad es función de tu cobertura de tests, tu CI, tu capacidad de rollback y el aislamiento de tus entornos.

Dos empresas que compren licencias idénticas obtendrán retornos radicalmente distintos, y la diferencia no estará en el modelo. Un equipo con CI de verdad y entornos reconstruibles puede encargar una tarea a un agente y revisar un diff. Un equipo sin ellos debe revisar cada línea, lo que limita su ganancia aproximadamente a la velocidad de tecleo.

Esta es una buena noticia para una empresa de 10–50 personas. La madurez de ingeniería se construye en meses, y es el multiplicador de toda inversión posterior en IA. Arregla el bucle de verificación antes de ampliar la huella de agentes. Para la infraestructura en concreto, tu bucle de verificación ya tiene nombre: el modo --check, terraform plan, reconstrucciones inmutables y una observabilidad lo bastante buena como para decirte en minutos que algo se ha movido.

Parte 3: Los tres cajones, y la factura que ya estás pagando

Cada pieza de software que toca tu empresa cae en una de tres categorías. La mayoría de las empresas tienen las fronteras mal situadas — y se colocaron ahí por razones que eran correctas en su momento.

Cajón 1: Alquilar siempre. Asume el coste desde el primer día.

Sistemas operativos. Suites ofimáticas. Chat y vídeo. Correo y calendario. Proveedores de identidad. Nóminas e impuestos. Procesamiento de pagos.

Comparten propiedades: función commodity, interfaces bien definidas, cero diferenciación competitiva y, a menudo, una responsabilidad regulatoria que sería una locura asumir voluntariamente. Algunos son valiosos precisamente porque todos los demás los usan. Construir aquí no es ahorro, es vanidad. Presupuéstalo y deja de revisar la decisión.

Cajón 2: Construir sobre primitivas compradas.

La categoría que nadie nombra, y donde vive la mayor parte del trabajo real. No construyes una base de datos; construyes tu aplicación sobre Postgres. No construyes un proveedor de identidad; construyes tu flujo de accesos encima de uno. No construyes un bus de mensajes, un almacén de objetos ni una pila TLS.

Construyes la capa que codifica tu lógica sobre primitivas que no has escrito tú. Aquí es donde el efecto de la IA es mayor, porque el ensamblaje, la integración y el pegamento son exactamente el trabajo que mejor hace.

Cajón 3: Las herramientas donde alquilar te perjudica activamente.

Aquí está el meollo. Cuando alquilas software que codifica un proceso, no estás comprando una capacidad. Estás comprando la opinión de otro sobre cómo debería hacerse tu trabajo, y luego reorganizando tu empresa para adaptarte a ella.

Ese trueque fue racional durante treinta años. El desarrollo era lento y la gente era cara, así que pagar en distorsión de procesos para no pagar en ingeniería era una aritmética correcta. Era correcta en 2010. Ahora se está reajustando.

Y la factura que estás pagando no es la del proveedor. Busca estas cuatro partidas, ninguna de las cuales aparece en tu informe de gasto en SaaS:

Distorsión de procesos. Pregunta a cada equipo: ¿qué hacemos de forma incómoda porque la herramienta lo exige? Cada apaño, cada hoja de cálculo paralela, cada «ese campo simplemente no lo usamos» es un pago. Tu mejor gente está absorbiendo fricción a diario para que el modelo de datos de un proveedor permanezca intacto.

Latencia de cambio. La última vez que el negocio necesitó un cambio real en una herramienta alquilada, ¿cuánto tardó? Si la respuesta es «lo solicitamos y está en su roadmap», tu capacidad de cambiar cómo operas está limitada por una empresa cuyas prioridades las marca su cliente mediano, no tú. En un mercado que se mueve, la latencia de cambio es posición competitiva.

Coste de salida, que se acumula. Gravedad de los datos, integraciones, hábitos reentrenados, registros históricos. Cada año que te quedas, irte cuesta más. No es un accidente; es el modelo de negocio.

Propiedad de los datos y de la semántica. No solo dónde viven las filas, sino quién define qué significa una fila y quién puede cambiar esa definición un martes cualquiera.

Frente a esas cuatro partidas, el contrapeso solía ser un desarrollo de dieciocho meses. Hoy, para una herramienta interna bien acotada, un equipo pequeño y competente asistido por IA puede tener una v1 funcionando en semanas. Eso no hace que la decisión sea automática. Hace que vuelva a ser una decisión, por primera vez en una década — una que deberías estar reexaminando activamente en lugar de heredar.

La prueba del shadow IT. Ya sabes que este argumento es cierto, porque toda empresa tiene hojas de cálculo críticas para el negocio y bases de datos de Access medio abandonadas sosteniendo procesos con alfileres. Existen porque la herramienta oficial no encajaba y alguien construyó la pieza que faltaba en el único medio que tenía a su alcance. Las empresas siempre han querido herramientas que encajen. Simplemente no podían permitirse construirlas como es debido. Ahora pueden — y la alternativa a construirla como es debido no es «nada», es la hoja de cálculo que ya existe y de la que nadie ha hecho copia de seguridad.

El contraargumento honesto

Cualquier directivo que lea lo anterior y estire la mano hacia una partida presupuestaria debería interiorizar antes esto, porque de aquí vendrán los fracasos:

La IA ha colapsado el coste del primer 80%. Apenas ha tocado el coste del último 20% y de los diez años siguientes.

El coste de vida útil de una herramienta interna no es escribirla. Es:

• estar de guardia por ella
• parchearla y perseguir la rotación de dependencias indefinidamente
• una ruta de copia de seguridad y restauración que se haya probado de verdad
• el factor autobús cuando la única persona que la entendía dimite
• documentación, incorporación de personal y control de accesos
• diez años de pequeños cambios, cada uno individualmente trivial

La IA reduce el coste de escritura en algo así como cinco a diez veces. Reduce el coste de mantenimiento considerablemente menos — aunque ayuda de verdad, sobre todo leyendo código desconocido, generando tests y machacando actualizaciones. Así que la línea de construir-o-comprar se mueve, pero se mueve menos de lo que sugiere la demo.

El fracaso predecible de los próximos dos años es el directivo que modela el desarrollo con la cifra del 80%, lanza cuatro herramientas internas en un trimestre y descubre en el segundo año que ha adquirido cuatro productos sin mantenimiento y sin propietario. Ese fracaso se le atribuirá a la IA. No será culpa de la IA.

La disciplina que lo evita no tiene glamur: construir menos cosas, poseerlas como es debido y tratar cada herramienta interna como un producto con un propietario con nombre, una batería de tests y una ruta de desmantelamiento documentada.

Aquí también hay un precedente de promesas excesivas que conviene recordar. A finales de los ochenta se vendieron las herramientas CASE y los 4GL como el fin de la programación. No lo fueron. Pero FORTRAN es la mejor analogía: el equipo de Backus sabía que la única forma de desplazar el ensamblador escrito a mano era demostrar que el código generado era competitivo. Al principio no lo era. Luego lo fue. Luego casi nadie volvió a escribir ensamblador — y quienes conservaron la habilidad fueron los que podían depurar el compilador. Esa es, más o menos, la posición en la que están ahora los ingenieros sénior, y es una posición fuerte, no una posición amenazada.

Qué hacer en los próximos noventa días

1. Inventaría tu SaaS por distorsión de procesos, no por coste. Para cada herramienta, dos preguntas: ¿qué hacemos de forma incómoda por su culpa? y la última vez que necesitamos un cambio, ¿cuánto tardó? Ordena por eso, no por la factura. Lo más alto de esa lista es tu conjunto de candidatas — y la mayoría seguirá alquilada, lo cual está bien. Buscas las dos o tres que de verdad te están costando más de lo que cobran.

2. Construye exactamente una cosa, e instrumenta el coste real. Elige pegamento interno, no una funcionalidad de producto. Lánzala. Después mide todo durante seis meses: incidencias, horas, cambios, quejas. Ahora tienes un coeficiente real para tu propia empresa, en lugar del de un proveedor o el de un tertuliano.

3. Invierte en el bucle de verificación antes que en la huella de agentes. CI, tests, staging, dry-run, rollback ensayado, observabilidad. Este es el multiplicador de cada euro en IA que gastes durante los próximos cinco años, y merece la pena aunque la IA se estanque por completo.

4. Deja por escrito la frontera asistente/agente como política. Qué sistemas exigen un humano en el bucle en cada paso, cuáles permiten un agente con revisión del diff. Nómbralos. En un entorno regulado esto no es opcional, y ponerlo por escrito es además la forma más rápida de descubrir que la mitad de tu equipo ha estado improvisando.

5. Forma a la gente que ya tienes. Un ingeniero sénior con IA es un salto mucho mayor que un júnior con IA, porque el cuello de botella se desplaza de producir a revisar — y revisar es una habilidad de criterio que lleva años. La IA eleva el valor de tu gente sénior. Presupuesta en consecuencia, y desconfía de cualquier plan que diga «contratemos más júniors, la IA cubrirá el hueco».

El suelo sigue siendo el suelo

Nada de esto es un alegato a favor de construir tu propio hipervisor, tu propio cortafuegos o tu propia pila de almacenamiento. Ese suelo se queda donde está, y el papel de la IA allí es hacer que un equipo pequeño sea drásticamente más eficaz operando el excelente software de otros: configuración más rápida, diagnóstico más rápido, mejor documentación, incidentes más cortos. Asistir, no reemplazar, y por razones estructurales.

El alegato trata de la capa de encima: las herramientas que codifican cómo funciona realmente tu negocio en particular. Esa capa se ha alquilado durante treinta años por una razón que era cierta y que cada trimestre lo es menos.

Las fábricas que se electrificaron en 1900 y conservaron el eje de transmisión no ganaron nada. Las que se dieron cuenta de que la restricción había desaparecido, arrancaron los ejes del techo y reconstruyeron la planta alrededor del trabajo — esas se llevaron el siglo por delante.

La pregunta que merece la pena plantear a tu equipo directivo este trimestre no es cómo adoptamos la IA. Es:

¿Qué estamos haciendo hoy de forma incómoda, solo porque construir la herramienta que encaja solía ser demasiado caro?

Todo lo estratégico se deriva de la respuesta.