Hace cinco meses que no pasaba por aquí. En junio, en Resiliencia en la era de la IA, les conté cómo estaba deconstruyendo un monolito con agentes y les prometí compartir lo que íbamos aprendiendo con SETI-Spec, el marco de trabajo basado en especificaciones que construimos en el CoE de SETI. No cumplí a tiempo, y lo reconozco. La razón es la de siempre: estaba en la trinchera, orquestando agentes en proyectos reales, y entre una entrega y otra el blog se quedó esperando.

Vuelvo con una lección que no esperaba y que me tocó aprender en carne propia: tener la solución no es usarla. Y la inteligencia artificial no cambia eso; lo amplifica.

La caja de herramientas que nadie abría

Durante este tiempo, en el CoE nos dedicamos a resolver los problemas difíciles para que los equipos no tuvieran que hacerlo. Armamos plantillas, reglas de calidad, instrucciones probadas para los agentes y las «tuberías» automáticas que llevan el código hasta producción, todo documentado paso a paso. Hasta ahí, todo lógico: si la solución existe y está a la mano, la gente la adopta. ¿O no?

En SETI tenemos la costumbre de medirnos con rigor, aun cuando el resultado no sea el que esperamos. Y al medirnos descubrimos algo que nos cambió la perspectiva: la parte técnica estaba resuelta, pero llevarla al día a día de cada proyecto iba más lento de lo que imaginábamos. La solución existía y estaba documentada; lo que faltaba era que se volviera costumbre. El reto no era técnico, era de adopción.

Esa lección cambió la forma en que acompañamos a los equipos. Publicar un estándar no basta: hay que caminarlo con la gente, proyecto a proyecto, hasta que deja de ser «lo que dice el CoE» y se vuelve «como trabajamos aquí». También nos enseñó algo sobre los agentes. Donde un proceso no está claro, la IA no lo inventa; sigue generando, y lo que no estaba bien se acumula más rápido. Por eso digo que la IA no transforma: acelera lo que ya hay, incluido el desorden. Con un proceso claro, los agentes lo hacen volar; sin él, ayudan a equivocarse más rápido y con más confianza.

El síndrome de la membresía del gimnasio

Pensé que era un problema de nuestro gremio, hasta que leí el estudio IA: la brecha de la preparación de CINTEL, hecho con 165 mipymes colombianas. Su hallazgo más fuerte es que las empresas con mayor integración tecnológica tienen 4,5 veces más probabilidad de usar inteligencia artificial que las que tienen sus procesos poco digitalizados. La conclusión de CINTEL coincide con lo que yo vi adentro: la adopción de IA no es un problema de actitud, es un problema de preparación. Las empresas no fallan porque no quieran la herramienta; fallan porque no tienen dónde ponerla a trabajar.

Todo esto me recuerda a esos primeros días de enero en que pagamos la membresía del gimnasio convencidos de que el cambio ya empezó. Pagarla no nos pone en forma, y tener la mejor máquina del lugar tampoco: lo que cambia el cuerpo es la rutina. Con la IA estamos haciendo exactamente lo mismo. Compramos licencias, copilotos y plataformas de agentes, y después nos sorprende que los procesos, los datos y la forma de trabajar de la gente sigan iguales.

Antes de pagar la próxima membresía

Por eso les propongo cinco preguntas antes de comprar otra herramienta. Si no pueden responder dos o más, su próxima inversión no es una licencia: es ordenar la casa.

1. ¿Qué proceso mejora y quién es su dueño? Si nadie responde por el proceso, no hay proyecto: hay una compra.
2. ¿Ese proceso está documentado? Si no se puede explicar en una página, la herramienta va a adivinar.
3. ¿De dónde salen los datos y quién los mantiene? Los datos sin responsable se dañan en silencio.
4. ¿Con qué se integra? Una herramienta que no habla con sus sistemas es otra isla, y según CINTEL la integración es justo lo que multiplica el uso de la IA.
5. ¿Cuál es el costo mensual total? Licencia, nube, soporte y las horas de su gente para adoptarla. Esa última casi nunca aparece en la cotización.

Ahora, no quiero que esto se lea como un «no compren nada». Hay casos en los que probar primero sí tiene sentido: un piloto pequeño, barato y con fecha de apagado es una forma legítima de descubrir qué preguntas hacerse. El riesgo no está en probar, sino en confundir el piloto con la transformación y dejarlo encendido, pagando, sin que nadie sepa si sirvió. Si van a hacer uno, escriban antes cuál es la meta y qué harán si no se cumple.

Termino con la deuda pendiente. En junio les prometí contar lo que aprendimos con SETI-Spec, y esta es apenas la primera entrega de esa historia. A partir de hoy vuelvo con una entrega por semana mientras pueda sostenerla; prefiero eso a prometerles un calendario y volver a quedarles mal. Lo siguiente será el desarrollo guiado por especificaciones (SDD) en la práctica: los retos reales de trabajar con especificaciones y agentes.

¿Les ha pasado tener la solución en la mano y no usarla? ¿Cuál de las cinco preguntas les cuesta más responder? Los leo en los comentarios.