Los intereses de cada actor en la adopción de la IA empresarial
CEO, CTO, desarrollador, mánager y usuario de negocio: lo que cada uno quiere, lo que gana y lo que pierde
*Artículo de lectura independiente agrupado en la serie “IA en la empresa: Expectativas vs. Realidad”*
Cuando una empresa decide adoptar inteligencia artificial, hay una tendencia a presentarlo como una decisión técnica y racional. Se habla de eficiencia, de automatización, de reducción de costes. Se presentan dashboards con proyecciones de ROI (retorno sobre la inversión) y se compara con lo que hacen los competidores.
Pero detrás de esa narrativa ordenada hay algo mucho más complicado: un conflicto de intereses entre personas con objetivos distintos, presiones distintas y definiciones distintas del éxito.
Un CEO y un desarrollador senior pueden estar en la misma reunión hablando de “usar IA en el proyecto” y estar entendiendo cosas completamente diferentes. No porque uno sea más listo o más informado, sino porque les afecta de maneras distintas y sus incentivos no están alineados.
Este artículo dibuja ese mapa. No para señalar culpables, sino para que cada lector pueda identificar desde qué posición está mirando el problema, y entender desde qué posición lo están mirando los demás.
Nota: recuerdo que es un artículo de opinión informada, los datos aquí dados provienen de mi entera opinión personal cuyos puntos por los que he dado tales valores expongo para tener un punto de partida, por lo que siente libre de añadir más o menos puntos a lo que tu opinión difiera o aporte.
Los cinco actores principales
En la mayoría de empresas tecnológicas, la adopción de IA implica a estos cinco perfiles con distintos niveles de poder e influencia:
Vamos con cada uno.
1. El CEO / Directivo: entre la presión competitiva y el ROI esquivo
Lo que dice en público: “Necesitamos ser una empresa data-driven (impulsada por datos). La IA es clave para nuestra competitividad.”
Lo que realmente le preocupa:
- Que la competencia se adelante. El miedo a quedar obsoleto es, en muchos casos, el motor principal de la adopción.
- Que las inversiones no se traduzcan en resultados. La brecha entre las promesas del proveedor de IA y el valor real entregado es una fuente de frustración constante.
- Que el consejo de administración o los inversores pregunten “¿y vosotros qué estáis haciendo con la IA?”
Lo que gana con una adopción bien hecha:
- Reducción real de costes en tareas repetitivas y de bajo valor.
- Ventaja competitiva en tiempo de lanzamiento al mercado (time-to-market).
- Capacidad de escalar operaciones sin escalar plantilla proporcionalmente.
Lo que pierde o arriesga:
- Inversión elevada con ROI incierto a corto plazo (más sobre esto en el artículo de costes).
- Riesgo reputacional si la IA produce errores visibles o problemas de privacidad.
- Dependencia de proveedores externos cuyas condiciones y precios pueden cambiar.
- Resistencia interna si la adopción se percibe como una amenaza al empleo.
El CEO más peligroso no es el que ignora la IA, sino el que la exige a todo precio sin entender sus límites. La presión de “usar más IA” sin una estrategia clara produce exactamente lo contrario de lo que se busca: coste sin valor.
2. El CTO / Arquitecto: entre el control técnico y la deuda cognitiva
Lo que dice en público: “Hay que adoptar la IA de forma responsable y progresiva.”
Lo que realmente le preocupa:
- La deuda cognitiva (cognitive debt): si el equipo deja de entender el código porque lo genera la IA, la empresa se vuelve frágil. Un fallo en producción a las 3 de la mañana no lo resuelve una IA; lo resuelve alguien que sabe lo que hace y por qué.
- El vendor lock-in (dependencia de proveedor): si toda la arquitectura se construye asumiendo que cierto proveedor de IA existirá siempre con las mismas condiciones, cualquier cambio de precios o API puede ser catastrófico.
- La seguridad: una IA que genera código de forma masiva también genera vulnerabilidades de seguridad de forma masiva, con la ventaja adicional de que son menos visibles porque nadie las escribió con intención.
Lo que gana con una adopción bien hecha:
- Reducción del tiempo en tareas mecánicas (generación de boilerplate, scripts, tests básicos).
- Capacidad de hacer más con los mismos recursos humanos.
- Prototipado rápido para validar ideas antes de comprometer tiempo de desarrollo.
Lo que pierde o arriesga:
- Know-how (conocimiento) crítico del equipo. Si los arquitectos pierden la práctica de tomar decisiones técnicas difíciles, pierden precisamente lo que los hace valiosos.
- Control sobre la calidad del código que entra al repositorio.
- La capacidad de explicar el sistema cuando algo falla.
La IA es “un becario superdotado, pero pésimo arquitecto” La IA hoy es excelente ejecutando tareas técnicas concretas y limitadas. Pero cuando se le pide que diseñe sistemas completos o tome decisiones estratégicas, produce soluciones “del promedio de internet”: técnicamente válidas, pero que no conocen la deuda técnica heredada de tu empresa, ni tus restricciones de presupuesto, ni tu cultura de equipo, ni el contexto legal de tu sector.
3. El desarrollador: entre la productividad y el miedo a la atrofia
Lo que dice en público: “La IA me ayuda a ser más productivo. Es una herramienta más.”
Lo que realmente le preocupa:
- La empleabilidad. ¿Seguirá necesitándose a alguien como yo en tres años? Esta pregunta, aunque raramente se hace en voz alta, está en la cabeza de muchos.
- La atrofia técnica. Si delego cada vez más a la IA, ¿seguiré siendo capaz de resolver los problemas difíciles? Un músico que no practica pierde técnica; un desarrollador que solo acepta sugerencias sin entenderlas pierde criterio.
- El trabajo con sentido. Los mejores desarrolladores no solo quieren terminar tareas: quieren entender sistemas, resolver problemas interesantes, crecer. Un entorno donde “todo lo hace la IA” puede convertirse en un trabajo de revisión rutinaria poco estimulante.
Lo que gana con una adopción bien hecha:
- Menos tiempo en tareas mecánicas y repetitivas (boilerplate, tests de cobertura, documentación).
- Capacidad de explorar prototipos en horas en lugar de días.
- Ayuda inmediata con código desconocido o en lenguajes con los que no está familiarizado.
Lo que pierde o arriesga:
- La curva de aprendizaje del junior que sube a senior. Si la IA hace las tareas básicas ¿Cómo se aprenden las bases? (Exploraremos esto más en el artículo técnico.)
- La autoría y comprensión del código que mantiene. “Lo generó la IA” no es una respuesta válida cuando el sistema de producción falla.
- El atractivo del trabajo si la empresa convierte al desarrollador en un aceptador/rechazador de sugerencias.
4. El mánager / PM: entre el control y las nuevas métricas
Lo que dice en público: “Con la IA el equipo será más ágil y entregará más rápido.”
Lo que realmente le preocupa:
- Visibilidad. Si la IA genera código automáticamente, ¿cómo sabe el mánager qué está haciendo su equipo y cuánto vale? Las métricas tradicionales (horas trabajadas, tickets cerrados) se vuelven menos fiables.
- Control de calidad. Un equipo que entrega más rápido con IA puede estar acumulando deuda técnica invisible que explote en el futuro.
- Su propio rol. Si la gestión del proyecto se puede automatizar parcialmente, ¿qué aporta un PM en ese contexto?
Lo que gana con una adopción bien hecha:
- Equipos con mayor capacidad de entrega en los mismos plazos.
- Menos tiempo del equipo en tareas de bajo valor, más en diseño y decisiones.
- Herramientas para generar reportes, resúmenes y estimaciones más rápido.
Lo que pierde o arriesga:
- La ilusión de control. La velocidad de entrega sube, pero la complejidad de lo que se entrega también puede subir, haciendo más difícil supervisar la calidad real.
- Métricas que ya no funcionan como indicadores de rendimiento del equipo.
5. El usuario de negocio: el más ignorado y el más determinante
Lo que dice en público: “Si me ahorra tiempo, bienvenido sea.”
Lo que realmente le preocupa:
- El cambio de rol. Si la IA automatiza partes de su trabajo, ¿qué hace él o ella? La respuesta no siempre es “algo más interesante”.
- La confianza en el output. ¿Puede fiarme de lo que dice la IA? ¿Quién es responsable si comete un error que afecta a un cliente?
- El aprendizaje. Aprender una herramienta nueva no es gratis en tiempo ni en energía.
Lo que gana:
- Menos tiempo en tareas repetitivas (generación de informes, clasificación de datos, resúmenes).
- Acceso rápido a información estructurada.
Lo que pierde o arriesga:
- Visibilidad y comprensión de su propio trabajo si delega demasiado en la IA.
- Responsabilidad sin control: si firma un informe generado por IA sin revisarlo a fondo, los errores son suyos.
El mapa de conflictos
No todos estos actores tienen los mismos intereses. El siguiente diagrama muestra las principales zonas de fricción:
Estas tensiones no son teóricas. Son conversaciones que ocurren en salas de reuniones cada semana. Y lo interesante es que nadie está equivocado: cada uno está viendo el problema desde su punto de vista legítimo.
Cuando los conflictos se materializan: el caso del tokenmaxxing
Los conflictos del diagrama anterior no son teóricos. En mayo de 2026, varios medios especializados documentaron lo que está ocurriendo en Amazon y que ha recibido el nombre de tokenmaxxing.
Amazon estableció un objetivo de que más del 80% de sus desarrolladores usasen herramientas de IA semanalmente, y comenzó a medir el consumo de tokens en leaderboards (clasificaciones) internos. Aunque la empresa afirmó oficialmente que las métricas no influirían en las evaluaciones de desempeño, los empleados reportaron que los managers sí las observaban y que generaban presión real.
La respuesta de parte del equipo fue racional dado el sistema de incentivos: usar MeshClaw (una herramienta interna de agentes de IA) para automatizar tareas innecesarias y así inflar el consumo de tokens, sin que eso representara productividad real (Más tokens consumidos = mejor posición en el ranking = menos presión del manager).
“Hay mucha presión para usar estas herramientas. Algunos simplemente maximizan su consumo de tokens.” — Empleado de Amazon, citado en The Decoder y TechSpot
El fenómeno no es exclusivo de Amazon: se han documentado comportamientos similares en Meta.
Lo que ilustra este caso en el contexto del mapa de actores:
- El CEO quiere métricas de adopción de IA elevadas.
- El manager las monitoriza porque recibe presión desde arriba.
- El developer optimiza para las métricas que se miden, no para el valor real que aporta.
- El resultado es que la empresa tiene estadísticas de adopción excelentes y productividad real inalterada o peor.
Es el ejemplo más claro de lo que ocurre cuando se fija un objetivo de uso de IA sin haber definido primero qué problema se está resolviendo y cómo se va a medir el impacto real.
La tabla de trade-offs por actor
| Actor | Principal ganancia con IA bien adoptada | Principal riesgo con IA mal adoptada |
|---|---|---|
| CEO | Competitividad, escala, eficiencia | Inversión sin ROI, dependencia de proveedores, escándalos de privacidad |
| CTO / Arquitecto | Productividad del equipo, prototipado rápido | Deuda cognitiva, código no comprensible, vendor lock-in |
| Desarrollador | Automatización de lo repetitivo, exploración rápida | Atrofia técnica, desaparición del trabajo con sentido, obsolescencia del junior |
| Mánager / PM | Equipos más veloces, reportes más rápidos | Pérdida de visibilidad, métricas rotas, deuda técnica oculta |
| Usuario de negocio | Menos tiempo en tareas mecánicas | Cambio de rol no gestionado, responsabilidad sin control, pérdida de comprensión del propio trabajo |
El radar: comparando los dos extremos
Para visualizar las consecuencias reales de las dos posiciones extremas, comparamos:
- Empresa Ultra-IA: adopción intensiva y no estratégica. IA en todo el ciclo, presión top-down (desde la dirección hacia abajo) para aumentar el uso, sin gobernanza sólida.
- Empresa Sin-IA: resistencia total a la adopción. Todo manual, sin asistentes, sin automatización.
Las dimensiones del análisis y su explicación:
Las 8 dimensiones
1. Velocidad de entrega (time-to-market): Qué tan rápido llegan las funcionalidades o productos al usuario final.
2. Calidad del output: Bugs, errores, consistencia y comprensibilidad del trabajo producido.
3. Eficiencia de costes (a medio plazo, 1-3 años): Cuánto cuesta producir lo mismo. Incluye salarios, herramientas, infraestructura y el coste oculto de los errores.
4. Resiliencia Capacidad de recuperarse cuando algo falla o cuando un sistema, herramienta o persona clave no está disponible.
5. Know-how interno (conocimiento propio de la empresa): Cuánto del conocimiento crítico de los sistemas reside en personas de la empresa vs. en herramientas externas.
6. Capacidad de innovación disruptiva: Capacidad de generar cambios de paradigma, no solo optimizar lo existente.
7. Atracción de talento: Qué tan atractiva es la empresa para los mejores perfiles del sector.
8. Riesgo legal y regulatorio: Exposición a multas, problemas de privacidad, incumplimiento del AI Act europeo o similar.
Nota sobre la escala: en las dimensiones “Eficiencia de costes” y “Riesgo legal”, una puntuación alta es mejor (mayor eficiencia, menor riesgo). Las puntuaciones son valoraciones cualitativas de tendencias (que he estimado según mi opinión), no medidas exactas.
Datos del radar
El por qué de cada puntuación
Velocidad de entrega: Ultra-IA 9 / Sin-IA 3 La diferencia más obvia. Con IA, el código de soporte (boilerplate), los tests, la documentación y los scripts de automatización se generan en minutos. Sin IA, todo es ritmo humano. El gap se agranda a medida que los competidores que sí usan IA llevan cada vez más ventaja en tiempo.
Calidad del output: Ultra-IA 4 / Sin-IA 7 Aquí la paradoja. Más velocidad no equivale a más calidad. La IA genera código que parece correcto pero puede contener errores sutiles de lógica, configuraciones de seguridad deficientes o soluciones que no escalan. Sin una revisión humana rigurosa —que la presión de velocidad a menudo elimina— la calidad sufre. La empresa sin IA es más lenta, pero el código que produce es más entendible por quienes lo mantienen.
Eficiencia de costes: Ultra-IA 5 / Sin-IA 7 Contraintuitivo pero real: a corto y medio plazo, la adopción intensiva de IA puede ser más cara que mantener un equipo humano equivalente. Licencias, tokens de API, infraestructura adicional, tiempo de formación y el coste de arreglar los errores que la IA introduce suman más de lo que muchos directivos calculan inicialmente. La empresa sin IA tiene costes de personal más predecibles. (Esto se desarrolla en el artículo sobre los costes de la IA y la promesa democrática del modelo enterprise.)
Resiliencia: Ultra-IA 3 / Sin-IA 8 ¿Qué ocurre cuando el proveedor de IA cambia sus precios, modifica su API o simplemente falla? Una empresa que ha construido su ciclo de desarrollo alrededor de una herramienta externa específica es frágil ante esos cambios. Además, si nadie entiende el código que la IA generó, cualquier incidente en producción se convierte en una crisis sin solución clara.
Know-how interno: Ultra-IA 2 / Sin-IA 9 La dimensión más crítica y la más ignorada. Una empresa que delega el diseño y la ejecución técnica a la IA acumula lo que podemos llamar “deuda cognitiva”: el código existe, funciona (mientras no falla), pero nadie de la empresa entiende realmente por qué hace lo que hace. Cuando algo explota, no hay nadie con el conocimiento para arreglarlo. El know-how es el seguro de vida de la empresa.
Innovación disruptiva: Ultra-IA 6 / Sin-IA 3 La IA es extraordinaria para optimizar lo que ya existe y para explorar variantes de lo conocido. Pero la innovación disruptiva —cambiar el modelo de negocio, inventar una categoría nueva, girar radicalmente ante un cambio de mercado— requiere juicio humano, intuición y la capacidad de romper patrones. La empresa Ultra-IA puede lanzar más rápido, pero no necesariamente en la dirección correcta. La empresa Sin-IA tiene más criterio pero menos capacidad de ejecutar a velocidad.
Atracción de talento: Ultra-IA 6 / Sin-IA 4 Los mejores desarrolladores quieren trabajar con herramientas modernas: la empresa sin IA se percibe como anticuada. Pero tampoco puntuamos alto a la Ultra-IA, porque los profesionales sénior huyen de entornos donde no hay aprendizaje real, donde “todo lo hace la IA” y ellos son meros validadores mecánicos. El talento de calidad busca un equilibrio: herramientas buenas, pero trabajo con sentido.
Riesgo legal y regulatorio: Ultra-IA 4 / Sin-IA 9 El AI Act europeo está en vigor. GDPR aplica a los datos que se envían a modelos externos. El uso de IA en decisiones que afectan a personas (contratación, crédito, servicios públicos) tiene restricciones específicas. La empresa que usa IA intensivamente sin una política de gobernanza está expuesta. La empresa sin IA simplemente no tiene estos riesgos. (Nota: 9/10 en Sin-IA no significa que no existan riesgos legales en general, sino que los específicamente asociados a la IA son prácticamente nulos.)
Dos lecturas que los extremos no muestran
La empresa Ultra-IA ideal no existe en estado puro. La mayoría de empresas que adoptan IA de forma agresiva tienen elementos de control que moderan las desventajas. Hemos mostrado el peor caso del extremo, no el promedio de los adoptadores entusiastas.
La empresa Sin-IA está perdiendo terreno cada mes. Aunque su perfil anterior no parece tan malo, hay una dimensión que no aparece: la velocidad de degradación competitiva. Una empresa que no adopta ninguna herramienta de IA en 2026 no está en la misma posición que una empresa que no lo hacía en 2022. El gap con los competidores que sí la usan crece cada vez más.
El punto ideal está en el centro, pero no en la media. No se trata de usar “algo de IA” para quedar en el medio del gráfico. Se trata de ser selectivo: maximizar las ventajas donde la IA genuinamente aporta (velocidad en tareas mecánicas, exploración, automatización) y proteger activamente las dimensiones críticas que el uso masivo erosiona (know-how, calidad, resiliencia).
La brecha competitiva se acumula con el tiempo
En el gráfico de radar anterior no muestra que la empresa Sin-IA no está parada: está perdiendo terreno de forma compuesta cada año que pasa.
- Línea superior: empresa con adopción estratégica de IA.
- Línea inferior: empresa sin adopción de IA. El crecimiento de la primera y el descenso de la segunda no son lineales: se aceleran porque la IA permite construir ventajas que a su vez generan más ventajas (mejores herramientas → más velocidad → más capacidad de invertir en mejores herramientas).
El objetivo no es la media: es la adopción selectiva
Una lectura incorrecta del gráfico de radar anterior sería concluir que “la posición ideal es el punto medio entre los dos extremos”. No lo es. La media de Ultra-IA y Sin-IA produce una empresa mediocre en todo.
El siguiente gráfico compara los tres perfiles en 4 dimensiones clave (los datos son aproximados por opinión, inventados, por visualizar un lo que estamos hablando y que no solo sea texto, es decir, una barra grande sería si te estuviese hablando directamente sería un “bastante” y una pequeña el típico “poco”).
Lo que el gráfico muestra:
- Ultra-IA 🔴 tiene la barra más alta en velocidad pero las más bajas en know-how y resiliencia.
- Sin-IA 🔵 tiene el patrón contrario: fuerte en know-how y resiliencia, débil en velocidad.
- La adopción selectiva 🟢 consigue puntuaciones altas en las cuatro dimensiones porque usa IA donde aporta velocidad (tareas mecánicas) y mantiene supervisión humana donde el know-how y la calidad son críticos. No es una posición intermedia: es una posición distinta.
Conclusión: el mapa existe para que cada uno sepa dónde está
La conversación sobre IA en la empresa suele fracasar porque cada participante habla desde su posición sin reconocer que los demás están en una posición diferente con intereses legítimamente distintos.
El CEO que exige más IA no está equivocado al querer competitividad. El desarrollador que advierte sobre la deuda cognitiva no está equivocado al defender la calidad. El arquitecto que pide gobernanza no está siendo un obstáculo: está protegiendo la resiliencia del sistema. Y el usuario de negocio que desconfía de los outputs de la IA no está siendo torpe: está ejerciendo exactamente la supervisión humana que debe existir.
El objetivo de este artículo no es decirte quién tiene razón. Es ayudarte a entender desde qué punto de vista estás mirando y desde cuál lo están mirando los demás. Con eso sobre la mesa, la conversación puede volverse más productiva.
En los siguientes artículos de la serie veremos la realidad técnica detrás de todo esto, los números reales de costes, y un framework práctico para tomar decisiones.
Fuentes citadas en este artículo:
- Caso tokenmaxxing en Amazon: The Decoder · TechSpot · Tom’s Hardware
- Caso tokenmaxxing en Amazon y Salesforce: Pymts
- Caso tokenmaxxing en Meta y Nvidia The Conversation.
- Ley de Goodhart aplicada a métricas de IA: PYMNTS — Enterprises Look Beyond Token Counts
- AI Act europeo (referencia regulatoria): EUR-Lex — Reglamento (UE) 2024/1689
Siguiente artículo: [Lo que la IA puede y no puede hacer hoy en el desarrollo de software]
