La IA no se atora por floja ni por miedo. Se atora sin un dueño del proceso.

1. "Ya usamos IA" no significa lo que crees

Un experimento de campo con 66 empresas y 7,137 trabajadores dio acceso a IA integrada en el correo y midió qué cambiaba. El tiempo que la gente pasaba escribiendo correos bajó. Lo que no cambió fue la composición de las tareas: nada que requiriera coordinar con otras personas se movió solo porque cada quien ahorrara tiempo por su cuenta. McKinsey encontró algo parecido desde otro ángulo, en su análisis anual sobre adopción de IA: el rediseño de flujos de trabajo es, de 25 variables medidas, la que más se relaciona con impacto real en resultados de negocio, pero solo el 21% de las organizaciones que ya usan IA reportó haber rediseñado a fondo al menos algunos de sus procesos.

Vale la pena separar cuatro cosas que la frase "ya usamos IA" mezcla sin querer: curiosidad (alguien vio una demo y se entusiasmó), uso asistido (alguien puede usarla mientras otra persona resuelve dudas y corrige el contexto), uso autónomo (alguien produce un resultado correcto sin depender de quien lo guio) y capacidad institucional (el equipo comparte reglas, responsables, insumos y continuidad, sin depender de una sola persona). La mayoría de las empresas que dicen haber adoptado IA están en el segundo estado. Muy pocas llegan al cuarto.

2. El mando medio no es un puesto. Es una función que alguien tiene que sostener

El liderazgo puede autorizar el cambio y proteger el presupuesto, pero no puede ejecutar el rediseño desde arriba. Necesita una capa que traduzca la intención en reglas concretas, permisos, prioridades y carga de trabajo real. En una empresa grande, esa capa suele llamarse mando medio. Datos de BCG muestran la brecha: solo 51% de los trabajadores de primera línea usa IA con regularidad, frente a más de tres cuartas partes de líderes y gerentes; y la actitud positiva hacia la IA sube de 15% a 55% cuando hay apoyo fuerte y visible del liderazgo, sobre todo cuando viene acompañado de al menos cinco horas de capacitación con acompañamiento presencial.

Hace un par de meses había llegado a una sospecha parecida sin poder probarla del todo: que la resistencia a la IA rara vez viene de arriba o de abajo, viene del nivel intermedio, porque ahí es donde vive el control de la información y la aprobación de procesos que la IA amenaza con redistribuir. Lo que me faltaba entonces es lo que armando sistemas de IA para negocios he terminado de confirmar: en una empresa chica no hay mando medio con ese nombre, pero la función existe igual, aunque esté repartida entre dos o tres personas sin título de gerente. Alguien tiene que decidir el criterio, mantener las reglas, resolver excepciones, aprobar la salida y traducir lo que el equipo necesita en cambios al sistema. Llamarlo "mando medio" o llamarlo "dueño del proceso" es lo de menos. Lo que importa es que exista, con nombre y apellido, no como responsabilidad difusa de todos.

3. La resistencia no es miedo al cambio. Es no querer responder por algo que no controlas

La explicación fácil trata la resistencia como cobardía. Vale la pena preguntarse qué protege en concreto. En los proyectos de sistemas de IA que he armado para negocios he visto rechazarse una solución de copiar y pegar porque nunca llegaba a un borrador que alguien pudiera revisar con confianza. He visto mantenerse manual un envío a un tercero porque la persona quería conservar la última palabra mientras el proceso nuevo todavía no estaba probado. He visto cuestionarse la automatización de una tarea creativa no por apego a lo viejo, sino porque su variabilidad era real y no un pretexto. Y he visto frenarse integraciones hasta validar seguridad y cumplimiento, con toda razón.

Ninguno de esos casos es miedo al cambio. Es gente a la que se le pide responder por un resultado sobre un sistema que no controla del todo. Esa es la pregunta que la narrativa original nunca hace: cuando el flujo se rediseña, ¿quién pierde autonomía, visibilidad o margen para corregir a tiempo? La resistencia casi siempre aparece justo ahí.

4. Una regla que solo vive en la memoria de la IA no es una regla

Un error de calidad que se repite una y otra vez casi nunca es un fallo de atención. Es un fallo de arquitectura: la corrección se guardó como memoria de conversación en vez de como regla del sistema, y la memoria se pierde de forma intermitente. La solución no es pedirle a la gente que revise mejor. Es separar dos capas: las reglas duras (checklist, criterios fijos, validaciones automáticas) que no dependen de que alguien las recuerde, y el contexto blando (preferencias, ejemplos, antecedentes) que sí puede cambiar de una sesión a otra. Después, cada corrección sigue un ciclo simple: se observa, se clasifica, se incorpora a la regla o a la memoria según toque, se prueba y se revisa. Sin ese ciclo, cada persona termina enseñándole a la IA las mismas reglas cada vez, y el sistema nunca acumula.

5. Automatizar no quita criterio. Lo concentra donde más importa

El diseño que mejor aguanta separa lo predecible de las decisiones de alto impacto: la herramienta hace lo repetible, la persona interviene donde importan el contexto, el riesgo y la consecuencia. No es una concesión temporal a la resistencia humana. Es la arquitectura correcta. Y tiene una consecuencia que casi nadie presupuesta: el primer beneficio de automatizar casi nunca es producir más. Es mover el trabajo humano de ejecutar tareas repetitivas a revisar resultados y diseñar reglas para las excepciones. Si esa carga nueva no se contempla desde el inicio, el proyecto parece estar fallando justo cuando está funcionando como debería.

6. Cuando "la IA no sirve", el problema casi nunca es la IA

Distintos síntomas se sienten idénticos para quien los vive ("la IA no recuerda", "no encuentra mis archivos", "no responde") pero tienen causas completamente distintas: un fallo del modelo, un error de configuración, un permiso mal otorgado o un paso del proceso que nadie definió. Tratar los cuatro como si fueran el mismo problema es la forma más común de perder semanas.

La infraestructura no es una nota técnica al pie. Es parte del producto. Una gobernanza mínima que funcione no necesita ser un documento extenso: necesita un inventario de qué herramientas y datos están permitidos, un dueño por cada flujo, un punto humano de aprobación, un registro de errores, una métrica de calidad y continuidad, y un plan B para cuando el proveedor falla. Lo más importante no es que exista el documento. Es que se perciba como algo que ayuda, no como vigilancia. Cuando la gobernanza se siente como control desde arriba, la gente se sale del sistema oficial y usa lo que tiene a la mano sin decírselo a nadie. Ese fenómeno ya tiene nombre: IA en la sombra (Shadow AI, en inglés), el uso de herramientas de IA sin aprobación ni supervisión del área responsable. IBM lo documenta con cifras concretas: 38% de los empleados comparte información sensible con herramientas de IA sin autorización de su empresa, y una de cada cinco organizaciones en el Reino Unido reportó una fuga de datos originada por IA generativa. La adopción de IA generativa entre empleados de empresa pasó de 74% a 96% en apenas un año, mucho más rápido de lo que la mayoría de las organizaciones logró construir una política clara para gobernarla. La IA en la sombra no aparece porque la gente quiera romper reglas. Aparece donde la regla oficial no resuelve el problema tan rápido como la herramienta que ya tienen a la mano.

7. No preguntes si ya lo adoptaron. Pide un resultado sin ayuda

Preguntar "¿ya adoptaron la IA?" produce respuestas de intención. Pedir un resultado pequeño y verificable produce evidencia. La adopción real se prueba, no se declara: alguien nuevo completa una tarea de principio a fin sin que nadie la resuelva por él, el sistema funciona con un caso real y no solo en la demo, el equipo sabe qué hacer cuando la salida falla, las correcciones se convierten en reglas reutilizables y existe una alternativa cuando el proveedor no está disponible. Ninguna licencia activa ni número de conversaciones generadas demuestra eso.

8. El primer beneficio no es hacer más. Es dejar de hacerlo tú

Las tecnologías de propósito general suelen tardar en dar retorno visible porque exigen inversiones que no se ven de inmediato: rediseñar procesos, entrenar gente, construir gobernanza. Es lo que la literatura llama la curva en J (J-curve): el resultado agregado baja o se estanca antes de subir, porque el costo de aprender llega primero que la ganancia. Parte de ese valle tiene una explicación simple y poco glamurosa: durante la transición, la empresa tiene que operar dos sistemas al mismo tiempo, el viejo mientras se valida el nuevo. Ese doble trabajo es temporal, pero mientras dura, cuesta tiempo real, no solo paciencia.