En la sala falta quien responda después de la demo

10 min de lectura

Una herramienta no convierte el software en simple configuración

La reunión suele parecer perfectamente sensata. Los responsables del proceso explican el funcionamiento. Un proveedor presenta la plataforma. Alguien de TI pregunta por los permisos de acceso. Un jefe de proyecto mantiene el calendario. Un consultor convierte el desacuerdo en una dinámica de taller. Todos asienten ante el diagrama.

Entonces alguien pronuncia la frase fatal: «Esto es sobre todo configuración».

Esa frase ha costado cantidades absurdas de dinero a las empresas.

Suena modesta, práctica y poco técnica. Le dice a la dirección que el proyecto no es en realidad un esfuerzo de software. Es la implantación de una herramienta, la puesta en marcha de un flujo, una iniciativa de digitalización, un programa de automatización, una limpieza de documentación con un poco de IA en los márgenes.

Palabras bonitas. Modelo de riesgo equivocado.

Si el proyecto cambia cómo se hace el trabajo, canaliza decisiones, transforma datos, desencadena acciones, guarda estado, gestiona excepciones y se convierte en algo de lo que la gente depende cada día, es trabajo de software. Puede construirse con una plataforma. Puede configurarse mediante una interfaz gráfica. La IA puede acelerarlo. Puede que no tenga un equipo de desarrollo tradicional alrededor. Nada de eso cambia la realidad subyacente.

Alguien sigue decidiendo el comportamiento.

Alguien sigue codificando supuestos.

Alguien sigue creando modos de fallo.

La pregunta es si alguien en la sala sabe qué aspecto tendrán esos fallos antes de que el negocio empiece a depender del sistema.

La vieja promesa siempre vuelve

La creencia actual de que las herramientas de automatización y la IA permiten a personas no técnicas construir sistemas empresariales fiables no es nueva. Es una vieja promesa con mejores demos.

COBOL se diseñó para hacer la programación empresarial más legible y accesible. No fue una tontería. Fue un intento serio de acercar el lenguaje del negocio a la computación. Pero no eliminó la necesidad de criterio técnico. Produjo sistemas enormes que ejecutaron durante décadas nóminas, banca, seguros, logística y operaciones gubernamentales. Muchos todavía funcionan porque la lógica de negocio, una vez incrustada, se convierte en infraestructura.

Visual Basic llevó una promesa parecida a la era del escritorio. Construir formularios. Conectar datos. Automatizar trabajo de oficina. Permitir que quienes estaban cerca del negocio crearan aplicaciones sin todo el peso ceremonial del desarrollo de software empresarial. De nuevo, útil. De nuevo, no era magia. Una aplicación de VB que funcionaba bien dejaba de ser una pequeña ayuda y se convertía en un sistema del que la gente dependía.

Excel con VBA hizo lo mismo en silencio y en todas partes. Una hoja de cálculo resolvía un proceso molesto. Luego otro. Después adquiría macros, botones, hojas ocultas, fórmulas copiadas, exportaciones pegadas y una persona en finanzas que era «la única que entiende cómo funciona». Años más tarde, la empresa descubre que un proceso crítico depende de un archivo que nadie puede modificar con seguridad.

VBA legado con IA y el Modelo del Queso Suizo plantea lo mismo. La parte difícil no es traducir sintaxis vieja a sintaxis nueva. Es descubrir qué hace realmente el sistema, demostrar que el reemplazo conserva el comportamiento importante y crear suficientes capas de validación para que «casi correcto» no se convierta en un fracaso para el negocio.

La IA es la versión más reciente y potente de este patrón. Reduce el coste de crear cosas con forma de software. Eso es útil. También significa que una idea floja puede convertirse en una demo funcional antes de que alguien formule las preguntas que un desarrollador con experiencia en producción haría durante la primera hora.

¿Qué ocurre cuando el proveedor no responde a tiempo?

¿Quién responde por los datos después de que cambie el proceso?

¿Qué queda registrado?

¿Qué se puede reproducir?

¿Cómo se vuelve atrás?

¿Qué reglas son política, cuáles son costumbre y cuáles son simple folclore?

La herramienta no plantea esas preguntas con suficiente insistencia. Un profesional serio sí.

La documentación no sustituye el criterio

La documentación es el compromiso favorito cuando nadie quiere admitir que en la sala falta criterio técnico.

Escribe el proceso. Dibuja el flujo. Documenta los requisitos. Crea la tabla de excepciones. Produce el manual de operación. Parece seguro porque la documentación es visible, revisable y políticamente neutral. Nadie tiene que decir lo incómodo: el proceso documentado puede estar ya lleno de contradicciones, atajos ocultos, malos incentivos y reglas que nadie sigue en realidad.

Automatizar eso produce confusión ejecutable.

Por eso la configuración pura decepciona tan a menudo. La configuración no es neutral. Cada lista desplegable, correspondencia, disparador, condición, permiso y regla de escalamiento es una decisión de diseño. Que esté dentro de la herramienta de un proveedor no hace que sea menos una decisión de arquitectura. Solo vuelve la arquitectura más difícil de ver.

Lo mismo ocurre con las herramientas generadas mediante IA. La primera versión puede parecer milagrosa. Aparece un formulario. Aparece una tabla de base de datos. Aparece un flujo de aprobación. Aparece un panel. Todos se impresionan porque la parte visible llegó rápido.

Pero el software fiable está compuesto sobre todo por la parte invisible.

Validación. Pruebas. Auditabilidad. Migración de datos. Recuperación ante errores. Límites entre roles. Disciplina de despliegue. Observabilidad. Historial de cambios. Responsabilidad operativa. La maquinaria aburrida que permite al sistema sobrevivir cuando se apaga el brillo de la demo.

El vibe coding no es desarrollo de software: un prompt puede crear código, pero no puede transferir responsabilidad. Quien responde por el trabajo todavía debe saber qué significa «bueno» cuando el caso ideal ya no basta.

Lo que aporta la experiencia en producción

Quienes tienen experiencia en producción no se distinguen por conocer más herramientas. Son útiles porque ya vieron el mismo fallo disfrazado con distintos trajes.

Han visto hojas de cálculo «temporales» convertirse en sistemas oficiales de referencia. Han visto crecer la configuración de un proveedor hasta transformarse en lógica de negocio imposible de probar. Han depurado flujos de aprobación cuyo propósito real era evitar responsabilidades. Han heredado código escrito por alguien que pensó que la documentación bastaría. Han entregado bajo presión, roto algo, arreglado el daño, escrito la prueba después y recordado el golpe.

Esa experiencia cambia las preguntas que hacen.

No preguntan solo si la herramienta puede hacerlo. Preguntan si la organización puede vivir con ello.

No preguntan solo si el flujo está documentado. Preguntan qué regla se discutirá la primera vez que haya dinero, cumplimiento normativo o clientes enfadados de por medio.

No preguntan solo si la IA generó el código. Preguntan quién puede leerlo, probarlo, desplegarlo, revertirlo y explicarlo cuando la abstracción generada se filtre en las operaciones.

No preguntan solo si el proveedor tiene una función. Preguntan qué ocurre cuando esa función no encaja del todo con el proceso real de la empresa, porque en ese «no del todo» crecerá el costoso apaño.

Por eso resulta interesante el título de moda «Forward Deployed Software Engineer». Palantir lo usa para personas que trabajan dentro de los equipos de sus clientes y configuran y amplían software para problemas operativos difíciles. La etiqueta es suya; la necesidad es más amplia. Lo valioso no es el título. Es la postura: alguien lo bastante cerca del negocio para comprender el problema real y con suficiente capacidad técnica para construir pensando en las consecuencias operativas.

En 2026, una persona así puede avanzar muy rápido con IA. Para muchas herramientas internas hablamos de días, no de meses. Pero la velocidad solo importa porque el criterio guía el trabajo. Sin él, esa misma velocidad produce una versión más bonita de la vieja trampa de las macros de Excel.

La sala está mal configurada

En las reuniones de digitalización suele haber muchas personas con autoridad legítima y ninguna con la experiencia que importa para este riesgo.

El responsable del proceso sabe cómo se supone que debe funcionar el trabajo. El proveedor conoce el producto. El consultor sabe cómo mantener el programa en movimiento. El jefe de proyecto conoce el calendario. El patrocinador ejecutivo conoce el presupuesto y las implicaciones políticas.

Todo útil.

Todavía insuficiente.

Falta quien pueda decir, pronto y con calma: «Están creando un sistema de software. Aquí es donde fallará. Esto es lo que debemos demostrar antes de que alguien dependa de él. Esta es la versión fiable más pequeña que podemos construir primero. Esto debería seguir siendo manual hasta que entendamos la excepción. Esta es la prueba que nos obligará a ser honestos».

Esa persona suele quedar fuera porque no encaja en la categoría de compra. Demasiado técnica para la sala de estrategia. Demasiado amplia para el puesto. Demasiado práctica para el taller de transformación. Demasiado honesta para fingir que la configuración es inocua.

Así que la organización compra herramientas, escribe documentación, configura flujos, celebra el piloto y descubre más tarde que creó software sin los hábitos que mantienen vivo el software.

La lección no es rechazar las herramientas de automatización. Úsalas. La lección es dejar de confundir herramientas con capacidad.

La prueba para la dirección

Antes de iniciar el próximo proyecto de digitalización, plantea una pregunta incómoda:

¿Quién en la sala ha sido responsable del software después de la demo?

No quién seleccionó una plataforma. No quién gestionó un proveedor. No quién escribió requisitos. No quién facilitó un taller.

¿Quién convivió con el sistema después de que los usuarios encontraran los casos límite?

¿Quién vio una pequeña automatización convertirse en infraestructura crítica?

¿Quién se ocupó de un despliegue fallido, una mala migración, un error de seguridad, una integración rota, una escalada de soporte o una regla de negocio que resultó equivocada en producción?

Si esa persona no está en la sala, el proyecto vuela a ciegas, pero con mejores diapositivas.

La IA hace que esto sea más urgente, no menos. La primera versión funcional puede aparecer antes de que la empresa haya conseguido siquiera poner fecha al comité de dirección. Solo es una ventaja cuando alguien con experiencia en producción está lo bastante cerca para darle forma. De lo contrario, la organización recibe otra vez la vieja promesa: desarrollo de software fácil para personas que todavía no han aprendido por qué se volvió difícil.

La persona que falta no es otro experto en herramientas.

No es otro responsable de documentación.

No es otro consultor de marcos de trabajo.

Es alguien que puede construir, verificar, simplificar y decir que no antes de que la empresa convierta una demo en una dependencia.

Ahí aparece el valor real.