DEV Community

Gonzalo Terrones
Gonzalo Terrones

Posted on

Por qué fracasan los proyectos de IA en las empresas (spoiler: no es la tecnología)

Los proyectos de inteligencia artificial casi nunca fracasan por la tecnología. Fracasan en el último paso: el de incorporarla al trabajo de la gente.

Lo escribo después de una conversación con Mayra Regueira, Consultora Estratégica en Innovación & Negocios, que trabaja el lado humano de las organizaciones. Yo vengo del lado técnico — armo automatizaciones y agentes de IA — y ella me puso nombre a algo que veo seguido pero no había ordenado: el punto de quiebre no está en el modelo, ni en la integración, ni en el presupuesto. Está en el día después de la entrega.

El proyecto funciona y aun así no arranca

La secuencia es siempre parecida. Se define el proceso, se arma la automatización, se conecta con los sistemas que la empresa ya tiene, se prueba. La demo sale bien. Todos aplauden.

Y ahí empieza el problema de verdad, porque la herramienta entra en un equipo que tiene rutinas, jerarquías y una idea bastante clara de para qué está cada uno. La IA le toca eso a todos al mismo tiempo, y nadie preparó la conversación.

Una tecnología que funciona pero que nadie usa no es un problema técnico. Es un problema de trabajo no hecho.

Las tres preguntas que nadie prepara

Cuando el sistema queda andando, aparecen tres preguntas que rara vez están contestadas de antemano:

1. ¿Qué hace ahora la persona que antes hacía esa tarea?
Si alguien dedicaba dos horas diarias a cargar datos y esas dos horas ya no existen, esa persona necesita saber en qué las va a usar. Si no se lo dicen, la respuesta que se arma sola en su cabeza es "me están por echar". Y una persona que piensa eso no colabora con la implementación: la sabotea, aunque sea sin querer.

2. ¿Cómo cambia el trabajo del equipo cuando una parte la resuelve la IA?
No es solo la tarea que desaparece. Cambian los tiempos, cambia quién revisa qué, cambia de quién es la responsabilidad cuando algo sale mal. Un equipo que no tiene eso definido vuelve al método viejo a la primera duda, porque el método viejo tiene reglas conocidas.

3. ¿Quién se lo explica a la gente?
Esta es la que más me quedó de la charla con Mayra. Y la respuesta incómoda es que no le toca al proveedor de tecnología.

El rol del líder es la parte que no se puede tercerizar

Yo puedo dejar un flujo andando perfecto. Puedo documentarlo, capacitar, dejar el soporte abierto. Lo que no puedo hacer desde afuera es decirle a un equipo para qué está cada uno ahora.

Eso le toca al líder del grupo. Es quien tiene que reposicionar a su gente y redefinir las actividades de cada uno en la nueva dinámica entre personas e IA: qué queda del lado humano, qué pasa a la máquina, y sobre todo qué cosas nuevas ahora se pueden hacer con el tiempo que se liberó.

Es un trabajo de conducción, no de sistemas. Y es el que más se saltea, porque no aparece en ningún presupuesto ni en ningún cronograma de implementación.

Cuando ese trabajo no se hace pasa siempre lo mismo: la herramienta queda instalada, se usa dos semanas, y al mes el equipo volvió a la planilla de antes. El proyecto figura como entregado y nadie lo está usando.

Qué se puede hacer, en concreto

Nada de esto es abstracto. Son cuatro cosas bastante prácticas:

Contestar la pregunta del puesto antes de arrancar, no después. Antes de la primera línea de código, que cada persona afectada sepa qué va a estar haciendo cuando el sistema esté andando. Si la respuesta honesta es "todavía no lo sabemos", eso también hay que decirlo, pero decirlo.

Que el líder del equipo esté en el proyecto desde el principio. No como aprobador del presupuesto: como parte del diseño. Es quien conoce las rutinas reales, que casi nunca son las del manual.

Empezar por un proceso que le moleste al equipo, no al gerente. La adopción es mucho más fácil cuando lo primero que automatizás es la tarea que todos odian. Se gana confianza antes de tocar algo sensible.

Medir uso, no entrega. El indicador no es "el sistema está en producción". Es cuánta gente lo usó esta semana. Si ese número baja, hay una conversación pendiente con el equipo, no un bug.

Y una que digo siempre desde el lado técnico: no automatices un proceso que está roto. Primero ordenalo. Si no, automatizás el caos y lo hacés más rápido.

La parte que la industria vende poco

El mercado de la IA vende capacidades: modelos, agentes, integraciones. Es lo que se muestra fácil en una demo. La parte que casi nadie factura — y que decide si el proyecto sirvió para algo — es el acompañamiento del equipo que va a convivir con eso.

Por eso me pareció que valía la pena escribirlo. Yo puedo garantizar que la tecnología funcione. Que la empresa la use es una responsabilidad compartida, y la mitad de esa responsabilidad no es técnica.

Si estás por meter IA en tu empresa, hacete la pregunta antes de firmar nada: ¿ya sabés qué va a estar haciendo tu gente el día después de que esto funcione?


La conversación que originó este artículo fue con Mayra Regueira, Consultora Estratégica en Innovación & Negocios, que trabaja justamente el lado humano de estos procesos. Yo escribo sobre automatización con IA para empresas desde Varka, una consultora de IA enfocada en la trastienda operativa de los negocios. Si estás evaluando automatizar algo y querés una opinión sin humo, escribime.

Top comments (0)