Se está abaratando el Software, mientras se encarece el caos

Estamos celebrando que cada vez más personas dentro de una empresa puedan construir software.

Y quizá deberíamos preocuparnos un poco más por lo que estamos creando.

Retool encontró que 35% de los equipos encuestados ya había reemplazado al menos una funcionalidad SaaS con software construido internamente, 78% esperaba construir más herramientas propias durante 2026 y 60% había creado software fuera de la supervisión tradicional del área de Tecnología. McKinsey encontró, además, que 32% de las organizaciones ya decidió no comprar al menos un producto o funcionalidad porque podía construirlo internamente con herramientas de programación asistidas por IA.

La tendencia parece irresistible. Cada desarrollador, esté o no dentro de TI, puede tener acceso a ChatGPT, Claude, Lovable, Replit, n8n, Make o cualquiera de las nuevas herramientas que aparecen cada semana. Con ellas puede crear aplicaciones, agentes, automatizaciones y workflows en días.

Suena a democratización.

Pero la verdad, también puede terminar siendo una fábrica de Frankensteins.

No porque las soluciones sean necesariamente malas. Muchas probablemente serán excelentes. El problema es que cada una puede empezar a crecer con su propio contexto, su propia lógica, sus propias reglas, sus propias integraciones y su propia memoria. Y cuanto más fácil sea construir, más fácil será que distintas áreas resuelvan el mismo problema de formas diferentes sin siquiera saber que alguien más ya lo había resuelto.

Pero hay algo todavía más delicado: La velocidad de construcción puede superar la comprensión del riesgo.

Alguien puede exponer una API key sin entender completamente lo que acaba de hacer. Puede conectar una aplicación a información sensible de la empresa con permisos excesivos. Puede copiar datos confidenciales a un servicio externo sin tener claro dónde quedan almacenados. O puede desplegar una IA frente al cliente porque “funcionó bien en las pruebas” sin haber pensado qué ocurre cuando alucina.

Y una alucinación deja de ser un problema académico en el momento en que produce consecuencias reales.

Imagine un agente comercial con acceso suficiente para responder a un cliente, cotizar, negociar o aplicar descuentos. Si inventa una condición comercial, promete algo que la empresa nunca aprobó o ejecuta una acción incorrecta cientos o miles de veces, el problema ya no es que “la IA se equivocó”. El problema puede aparecer en márgenes, contratos, reclamos, reputación o pérdidas reales. En esos casos, el bolsillo de la empresa será quien responda seguramente.

Lo mismo ocurre con la seguridad. Una aplicación creada en una tarde puede terminar teniendo acceso a datos, credenciales y sistemas que durante años protegimos con controles muy costosos. Que algo sea fácil de construir no significa que sea seguro de operar.

Ahí empieza a encarecerse el caos.

Y el costo no aparece solamente en incidentes. También aparece silenciosamente en la duplicación.

Un equipo genera una respuesta que otro ya había producido. Un agente reconstruye contexto que ya existía en otra aplicación. Una decisión vuelve a analizarse desde cero porque el conocimiento quedó atrapado en el sistema que la tomó. El costo individual puede parecer trivial, pero a escala empresarial el patrón es preocupante: La organización termina pagando repetidamente por producir inteligencia que ya posee.

La economía de la IA suele discutirse en términos de precio por token, costo por licencia o productividad por empleado. Pero para una organización habrá otra pregunta mucho más incómoda: ¿Cuántas veces estamos pagando para volver a pensar algo que ya sabemos?

Y aún hay otra: ¿Cuántas veces estamos permitiendo que alguien vuelva a construir controles, integraciones y decisiones que deberían ser comunes para toda la empresa?

Retool ya muestra una señal preocupante: Mientras 75% de los builders trabaja bajo algún mandato relacionado con IA, 35% de las organizaciones todavía no tiene métricas de productividad de IA. Estamos aumentando la capacidad de producir antes de desarrollar una capacidad equivalente para medir, reutilizar, proteger y aprender de lo producido.

El problema no termina en el costo ni en la seguridad.

A medida que estas herramientas dejan de limitarse a generar texto y empiezan a actuar, aparece una pregunta todavía más importante: ¿Quién conserva el criterio común de la empresa?

Un agente puede tener acceso. Puede tener capacidad. Puede incluso producir una acción técnicamente correcta. Pero eso no significa que deba tener autoridad para ejecutarla. Si cada nueva aplicación o agente reconstruye también su propia interpretación de qué está permitido, entonces ya no estamos simplemente descentralizando software. Estamos descentralizando criterio institucional.

Ahí es donde el Frankenstein deja de ser una metáfora tecnológica y se convierte en un problema de gestión.

Una organización no debería tener que reaprender lo mismo porque cambió de aplicación. No debería perder conocimiento porque cambió de modelo. No debería reconstruir reglas porque cada equipo eligió una herramienta distinta. Tampoco debería descubrir después de un incidente que una aplicación tenía acceso a algo que nadie pensó que podía tocar.

La verdadera oportunidad no está en frenar esta democratización. Sería absurdo intentarlo.

Está en conseguir que toda esa nueva capacidad alimente una inteligencia institucional común, reutilice lo que ya sabemos y opere dentro de límites que la empresa comprenda y pueda controlar.

Porque el futuro probablemente no pertenecerá a las empresas que más software construyan.

Pertenecerá a las que consigan construir mucho sin multiplicar al mismo tiempo sus costos, sus vulnerabilidades y sus versiones de la verdad.

La IA está haciendo que crear software sea cada vez más barato.

El riesgo es que, mientras celebramos esa abundancia, terminemos construyendo una organización donde cada área tiene su propio Frankenstein… y nadie sabe exactamente qué sabe, a qué tiene acceso ni qué puede llegar a hacer.