El taller de IA no entrega software

9 min de lectura

El colega brillante también necesita pruebas

La frase que desató la incomodidad fue la del «colega con CI de 500».

Es un anzuelo ejecutivo brillante: corto, impresionante y con un toque místico. Hace que la IA suene como una incorporación estelar que se suma discretamente al equipo y eleva a todos mediante pura potencia cognitiva.

El eslogan surgió en debates sobre modelos de madurez corporativa en IA. Nivel 0: acceso a modelos. Nivel 1: ganancias de capacidad mediante flujos optimizados. Nivel 2: herramientas de agentes en los equipos. Niveles superiores: cambios en el propio modelo de negocio. Ese es un marco serio.

Luego la metáfora se adueñó de la conversación: ¿qué rediseñaríamos si un colega increíblemente inteligente se uniera al equipo?

Como estímulo para dejar de tratar la IA como un buscador mejorado, resulta inofensivo. Tomado al pie de la letra, es un sinsentido. Los modelos no se convierten en colegas porque una diapositiva les asigne un número. No asumen responsabilidad, no entienden el contexto empresarial ni responden de las consecuencias. Dan la razón con demasiada facilidad, alucinan con plausibilidad y hablan con seguridad mientras se equivocan.

El peligro no es la ambición. El peligro es que la metáfora permite sonar estratégico mientras se elude la realidad operativa.

La conversación es demasiado cómoda

El problema no es la falta de voces inteligentes. Es el filtro.

Las personas a quienes se invita a explicar la IA a la dirección rara vez son quienes tendrán que sostener el resultado en producción. Son gestores del cambio, estrategas de recursos humanos, moderadores de innovación y consultores de conferencias que han descubierto que el mercado premia la confianza rápida.

Algunos aportan estructura. Otros ayudan a superar el miedo. Pero el peligro empieza cuando ese marco de adopción se convierte en toda la estrategia: mentalidad, alfabetización, capacitación, cultura.

No son temas ficticios. Son temas incompletos.

La adopción de IA solo es real cuando modifica un flujo de trabajo. Y un flujo de trabajo no es una diapositiva. Es el terreno desordenado donde la intención del negocio choca con la realidad del software: identidades, permisos, calidad de datos, sistemas heredados, excepciones, pistas de auditoría y compromisos no documentados.

Ahí es donde termina la inspiración y comienza el trabajo de software.

La adopción de IA es trabajo de software

La ficción ejecutiva habitual es que la transformación con IA consiste sobre todo en que las personas aprendan nuevos hábitos.

Aprender importa. Pero en el instante en que la IA interviene en un proceso operativo, las preguntas de software exigen respuestas:

• ¿Qué datos puede ver el modelo?
• ¿Qué decisiones puede influir y cuáles desencadenan acciones automatizadas?
• ¿Quién revisa el resultado?
• ¿Qué se registra, qué es reproducible y qué permite marcha atrás?
• ¿Qué fallo es una simple molestia y cuál constituye un incidente de negocio?
• ¿Quién mantiene el prompt, la integración o el agente cuando el equipo piloto se marcha?

Ese es el estándar mínimo de seriedad.

La IA no dirigirá su empresa por sí sola. La IA amplifica el sistema al que se conecta. Junto a flujos claros y despliegues disciplinados, aporta apalancamiento real. Junto a la confusión organizativa, produce confusión más rápida con mejor redacción.

La gestión del cambio ayuda a mover a las personas. La disciplina del software determina si el destino funciona.

El Forward Deployed Engineer como pista útil

Palantir popularizó la figura del Forward Deployed Software Engineer. La IA empresarial está rescatando ese patrón porque el valor nunca reside en la plataforma por sí sola. El valor aparece cuando profesionales experimentados se sitúan cerca del problema y adaptan el software a la operativa real.

Si eliminamos el misticismo, queda lo esencial: un profesional técnico que opera dentro del problema de negocio con autoridad suficiente para convertir intenciones difusas en software funcional.

Ese rol ocupa el centro productivo:

• lo bastante cerca de los usuarios para comprender los flujos reales
• lo bastante técnico para construir y guiar la implementación real
• con suficiente experiencia para rechazar una demo inviable en producción
• con la disciplina de dejar pruebas, rutas de despliegue y propiedad técnica clara

La dirección no necesita más visionarios que describan el potencial de la IA, ni desarrolladores aislados que reciban requisitos depurados con semanas de retraso. Necesita a alguien en el flujo de trabajo que defina qué software debe existir para que el cambio perdure.

La demo no es el sistema

Las demos de IA seducen porque la superficie visible se construye en días. Un chatbot responde sobre documentos, un agente redacta respuestas a clientes o un panel se actualiza en directo. La sala aplaude, los consultores hablan de escalar y la presentación anota un éxito rápido.

Luego la realidad empieza a cobrar por horas.

Los documentos internos se contradicen. Los permisos son demasiado amplios. El modelo cita políticas obsoletas. El agente ejecuta acciones irrepetibles. La gestión de errores de las API externas falla. Seguridad pregunta por accesos, legal por retención de datos y operaciones por a quién llamar a las dos de la madrugada.

Esta es la parte que el taller nunca entrega.

El vibe coding no es desarrollo de software, porque el software es la disciplina circundante que mantiene los resultados estables frente al tiempo, la escala y los fallos. Las demos se abarataron. Los sistemas robustos, no.

Lo que aporta el desarrollo real

Las prácticas fundamentales del desarrollo de software regresan con una sonrisa irónica. Los métodos antes desdeñados como preferencias técnicas son exactamente lo que permite desplegar IA con seguridad.

• TDD define el comportamiento esperado de forma explícita antes de que un modelo lo modifique.
• CI descubre roturas mientras el cambio sigue siendo lo bastante pequeño para entenderse.
• CD convierte los despliegues en una rutina previsible en lugar de una plegaria trimestral.
• Trunk-based development elimina ramas de larga duración donde el riesgo de integración se oculta.
• Especificaciones ejecutables dotan a las reglas de negocio de verificación real.
• Observabilidad muestra al CTO cómo se comporta el flujo de trabajo bajo tráfico real.

La IA genera más código, flujos y explicaciones plausibles de los que los ciclos de entrega tradicionales pueden absorber. Sin disciplina, se produce una inflación de artefactos: repositorios más grandes, mapas de procesos hinchados y mayor riesgo. Con disciplina, se obtiene apalancamiento genuino.

El Motor de la Entrega de Software Previsible nunca consistió en rendir culto al proceso. Trataba de ciclos de retroalimentación rápidos. La IA eleva el coste de no tenerlos.

La gobernanza sin entrega es burocracia

El cumplimiento no es negociable. El RGPD, la Ley de IA de la UE, la soberanía de datos y la auditabilidad son restricciones reales. Quien aconseje a las empresas avanzar rápido ignorando las normas vende una temeridad importada.

Sin embargo, la gobernanza tiene su propia trampa: sustituir la entrega por políticas.

Los comités redactan principios, matrices de riesgo y modelos operativos mientras el trabajo real se traslada a scripts descontrolados, automatizaciones SaaS y prompts improvisados. Eso es burocracia observando el crecimiento de la TI en la sombra.

Una gobernanza eficaz exige visibilidad de la entrega. Requiere saber qué sistemas existen, hacia dónde fluyen los datos, quién es responsable de cada componente y cómo se gestionan los incidentes.

El CTO debe liderar este diálogo, no para frenar el progreso, sino para que los compromisos sean operativamente honestos.

Preguntas que el CTO debe plantear

Cuando el entusiasmo domina la sala, el CTO no necesita fingir escepticismo. La postura más sólida consiste en formular preguntas operativas de forma constante:

• Muéstreme el flujo de trabajo exacto.
• ¿Qué datos se tocan y quién responde del resultado?
• ¿Dónde están las pruebas automatizadas?
• ¿Cuál es la ruta de marcha atrás cuando el modelo falle?
• ¿Cómo medimos si el resultado ha mejorado?
• ¿Quién despliega las correcciones y qué queda registrado?
• ¿Quién mantendrá este sistema cuando el equipo piloto se disuelva?

Estas preguntas disipan la abstracción. Los gestores del cambio pueden seguir aportando, los proveedores deben explicar su operativa y la dirección comprueba que el CTO no bloquea el progreso: define lo que el progreso debe resistir.

Eso no es estar contra la IA. Es estar contra el teatro.

Con el CTO, no a sus espaldas

Las iniciativas de IA más arriesgadas comienzan con inocencia: un piloto departamental, una solución empaquetada de un proveedor o un flujo creado al margen de TI porque supuestamente está saturada.

Eso genera responsabilidad sobre el software sin control técnico. Cuando por fin se recurre a TI, la herramienta ya cuenta con usuarios activos, peso político y riesgos acumulados que el CTO debe subsanar de repente.

El trabajo con IA compete al CTO desde el momento en que toca sistemas, datos o procesos de clientes.

Un socio externo útil refuerza esa responsabilidad en lugar de eludirla. Se integra junto al problema de negocio y el equipo de desarrollo para convertir la intención ejecutiva en software fiable.

Llámelo modelo Forward Deployed, alianza de entrega o criterio técnico senior sobre el terreno: la conclusión es idéntica. El taller no entrega, la presentación no se integra y el colega brillante no redactará el análisis de incidentes.

Alguien tiene que construir el sistema, asumir las consecuencias y saber dónde se rompe el software.