Un sistema que no puedes evolucionar no es tuyo
Construir un sistema con IA es cada vez más rápido. Lo que decide si es tuyo es otra cosa: poder entenderlo, cambiarlo y evolucionarlo sin depender de nadie.
Un sistema nuevo llega casi siempre con una buena demo. Funciona, resuelve lo que se pidió y el equipo empieza a usarlo. Los problemas aparecen seis meses después, cuando la empresa necesita cambiar algo: un campo nuevo, otro proveedor, una regla distinta. Y la respuesta es que eso hay que pedirlo, presupuestarlo y esperar.
En ese momento se descubre algo que no estaba en el contrato: el sistema funciona, pero la empresa no lo controla.
Lo caro no es construir un sistema. Lo caro es no poder cambiarlo después.
Una predicción que conviene leer bien
El 29 de septiembre de 2026, Gartner publicó una predicción llamativa: en 2028, el 70 % de las empresas abandonará la IA agéntica construida por ingenieros desplazados del proveedor, atrapadas por costes crecientes e incapaces de evolucionarla por su cuenta.
Según la cobertura de DIGIT, el analista Mukul Saha lo resume así: el éxito empieza por estructurar bien el encargo, desde el alcance y los incentivos hasta la gobernanza, la propiedad y la salida.
La predicción habla de agentes de IA, pero el patrón es antiguo. Cuando un sistema solo lo entiende quien lo construyó, cada cambio pasa por esa persona. Y la IA no corrige ese patrón: lo acelera. Si construir es más rápido, también se acumula más rápido lo que nadie más entiende.
Depender de alguien no es el problema
Yo construyo sistemas para otras empresas y los acompaño después. Sería poco honesto decir que depender de quien conoce un sistema por dentro es malo: es justo lo que hace que los cambios salgan rápido y bien.
El problema es otro: que solo esa persona pueda entenderlo. La diferencia está en cómo se construye desde el primer día. Un sistema evolucionable tiene algunas propiedades que se pueden comprobar:
- Los datos viven en un sitio que la empresa controla, con un modelo que se entiende sin leer el código.
- Las piezas externas se pueden cambiar sin reescribir el resto: el proveedor de IA, el de correo, el de pagos.
- Lo que cambia a menudo es configuración, no código.
- Hay pruebas automáticas que avisan si un cambio rompe algo.
- Las decisiones están escritas, con su porqué.
Ninguna de estas cosas se ve en una demo. Todas se notan el primer día que hay que cambiar algo.
Tres decisiones que pagan después
Estos son tres sistemas donde esas propiedades se decidieron al principio, cuando aún no había nada que cambiar.
Rocio.com: la base de datos manda
Rocio.com tiene un asistente de IA sobre un archivo que arranca en 1992. La decisión de fondo fue que la base de datos es la única fuente de verdad, también para la IA. El índice vectorial es desechable: se reconstruye entero desde la base. El proveedor queda aislado tras un contrato interno, así que cambiarlo no toca el resto del sistema. Ningún identificador del proveedor vive dentro del contenido editorial.
Si mañana aparece un modelo mejor o más barato, cambiarlo es un trabajo acotado, no una migración.
Guía en Sevilla: contenido como datos
En Guía en Sevilla, las páginas viven en un registro central y reutilizan plantillas por tipo de página. Añadir una página es añadir una entrada, no crear un archivo nuevo. Los enlaces internos apuntan a identificadores: si una ruta cambia, se resuelven solos. Y hay tests que comprueban que cada ruta publicada resuelve en su idioma, que las imágenes existen y que las redirecciones llegan en un solo salto.
La web está en tres idiomas. Sin esas decisiones, cada cambio habría que hacerlo tres veces, y alguno se olvidaría.
Zentia: la marca es configuración
Zentia opera varias agencias inmobiliarias sobre un único núcleo. Colores, logo, tipografías y textos de cada agencia viven en datos. Una agencia nueva no necesita un despliegue nuevo: se crea o se clona desde un panel de superadministración.
Lo que más va a cambiar —las agencias y sus marcas— es justo lo que no requiere tocar código.
Qué preguntar antes de encargar un sistema
Da igual que lo construya un proveedor, un equipo interno o yo. Estas preguntas sirven para saber si lo que se va a construir será tuyo:
- ¿Dónde viven los datos y quién tiene acceso directo a ellos?
- Si cambia el proveedor de IA, de correo o de pagos, ¿qué hay que tocar?
- ¿Qué se podrá cambiar sin programar: textos, reglas, precios, marcas?
- ¿Qué pruebas automáticas protegen lo importante?
- ¿Dónde quedan escritas las decisiones y por qué se tomaron?
- Si mañana entra otra persona técnica, ¿cuánto tarda en entenderlo?
Si las respuestas son vagas, el sistema puede funcionar muy bien hoy y aun así no ser tuyo.
Un sistema es tuyo cuando puedes cambiarlo, no cuando lo has pagado.
Sobre por qué el coste se ha movido de escribir código a decidir y mantener, escribí qué ocurre cuando desarrollar software deja de ser caro. Si tu problema es un sistema que ya existe y nadie se atreve a tocar, en modernización de sistemas heredados explico qué se conserva, qué se aísla y qué se reconstruye. Y en evolución continua cuento cómo acompaño un sistema después del lanzamiento.