La IA no arregla el caos. Lo acelera

1. El orden importa: ordena, automatiza, IA

Hoy todo el mundo vende software con IA, apps con IA y automatizaciones con IA. El problema no es la etiqueta: es que la mayoría de esas soluciones son parches rápidos colocados encima de procesos que nadie ha ordenado antes. Y un parche rápido no escala — se rompe justo cuando el negocio crece.

La secuencia que funciona es aburrida y siempre la misma: primero ordena el proceso, luego automatízalo, y solo entonces mete IA. Si te saltas el primer paso, lo único que consigues es generar el mismo desorden a mayor velocidad.

La prueba más sencilla: si no puedes explicar el proceso en una servilleta, no está listo para automatizarse. Y si no está listo para automatizarse, desde luego no está listo para la IA.

Un ejemplo de casa. Lo primero que automatizamos en mi estudio no fue nada vistoso: fue el registro de horas. Antes de tocar una línea de código tuvimos que decidir cosas que no habíamos decidido nunca —qué cuenta como hora facturable, a qué proyecto va cada tarea, qué pasa cuando alguien se olvida de apuntar tres días—. Ese trabajo, que no es de software, es el que hizo posible lo demás. Si hubiéramos empezado poniendo un agente encima del caos, habríamos automatizado el caos.

Lo veo constantemente en empresas que llegan pidiendo "un chatbot que responda a los clientes". Casi siempre, cuando abres el capó, la documentación que debería alimentar a ese chatbot no existe, está desactualizada o vive en la cabeza de dos personas. El proyecto no es el chatbot: el proyecto es ordenar ese conocimiento. El chatbot viene después y entonces sale casi solo.

2. Base sólida antes que parche rápido

La IA es la capa final sobre una ingeniería seria, no un atajo para saltársela. Cuando una empresa monta un agente sobre datos desordenados, integraciones frágiles y procesos que solo entiende una persona, el agente no falla por culpa del modelo: falla porque debajo no había nada donde apoyarse.

Por eso el trabajo de verdad casi nunca empieza con IA. Empieza con preguntas incómodas: dónde vive el dato, quién decide qué, qué pasa cuando alguien se va de vacaciones. Eso no es glamuroso y es exactamente lo que determina si el proyecto funcionará dentro de dos años.

Hay una señal que delata a un proyecto mal planteado: cuando la conversación empieza por la herramienta. "Queremos implantar tal plataforma", "nos han dicho que con tal modelo se puede hacer". La herramienta es la última decisión, no la primera, y elegirla antes de entender el proceso es la forma más cara de descubrir que no encajaba.

El checklist que paso antes de meter IA

Con el tiempo he acabado con cinco preguntas que hago siempre antes de aceptar un proyecto de IA. Si tres de las cinco se responden mal, el proyecto no es de IA todavía:

• ¿Puedes explicar el proceso de principio a fin? Si hacen falta tres personas para reconstruirlo, no está listo.
• ¿Cuántas veces al mes ocurre? Automatizar algo que pasa tres veces al año no se recupera nunca.
• ¿Dónde vive el dato y quién lo mantiene? Un agente es tan bueno como la información que le das.
• ¿Qué pasa si se equivoca? Si el error es caro o irreversible, hace falta supervisión humana desde el diseño, no como parche.
• ¿Quién lo va a operar cuando nos vayamos? Si la respuesta es "vosotros", no hemos construido una solución: hemos creado una dependencia.

3. La IA acelera, las personas deciden

La IA no quita trabajo: quita lo repetitivo. Lo que no quita —y no debería— es el criterio. Qué decidir, qué contarle a un cliente, qué callar, cuándo un proyecto no encaja: eso sigue siendo humano y conviene que lo siga siendo.

En la práctica esto se traduce en una regla operativa que aplicamos siempre: los agentes redactan, proponen y ejecutan lo mecánico; una persona aprueba. En cuanto rompes esa regla, la calidad se cae — y normalmente te enteras por un cliente.

Lo curioso es que el miedo que llega en las reuniones —"esto va a dejar sin trabajo al equipo"— casi nunca se cumple, y el efecto real es el contrario. Cuando automatizas la parte mecánica, la gente pasa a hacer aquello por lo que la contrataste. En mi estudio, quitar de encima los informes mensuales no eliminó el puesto de nadie: liberó horas que se fueron a diseño y desarrollo, que es donde aportamos.

4. Hacerlo bien cuesta lo que cuesta

¿Un software a medida por novecientos euros en una semana? Eso no existe. Lo que existe es un producto que parece funcionar hasta que lo usa gente de verdad, y una segunda factura para rehacerlo.

Bueno, bonito y barato: elige dos. Lo caro no es pagar más — es pagarlo dos veces. Prefiero decir esto en voz alta y que quien busque el precio más bajo se ahorre la llamada, porque no vamos a llegar a ninguna parte juntos.

Y hay un matiz que se pasa por alto: en IA, el coste de hacerlo mal no es solo la factura repetida. Es que un agente mal planteado toca clientes, correos y datos reales — y cuando se equivoca lo hace a escala y con tu marca delante. Rehacer una web mala cuesta dinero; rehacer la confianza de un cliente al que un agente contestó una barbaridad cuesta bastante más.

Predico lo que uso

Todo esto sería palabrería si no lo tuviera funcionando en mi propia empresa. La operativa de Truman corre sobre nuestro propio stack de IA: informes de cliente que se generan y entregan solos de madrugada, contenido que se produce en varios idiomas con revisión humana, y control de horas que se completa y avisa sin que nadie persiga a nadie.

Enseñar la pantalla a las 3:12 de la mañana con un informe ya generado convence más que cualquier promesa. Y me obliga a mantener la coherencia: si algo no sobrevive a nuestro propio día a día —con sus prisas y sus excepciones— no sale por la puerta.

Ese stack acabó teniendo empresa propia: Seahaven.