Montar un servidor de IA local en la empresa solo compensa cuando se cumplen simultáneamente tres condiciones: un requisito duro de soberanía del dato, un volumen sostenido por encima de los 30-180 millones de tokens al mes, y capacidad técnica interna para mantenerlo. Si falta cualquiera de las tres, la API en la nube sigue siendo la opción con mejor retorno para la mayoría de organizaciones en 2026, incluso con la caída de precios del hardware. El debate real no es “local contra nube”, sino de arquitectura: quién decide en tu organización qué tarea va a qué motor.
Esta semana estoy cruzando dos ideas que me han ocurrido simultáneamente en los últimos dos días. Por un lado, estuve reunido con el CEO de una empresa que, al igual que muchas, me pedía poder automatizar más procesos para que el equipo fuera más rápido y llegara a producir el doble. Esto está bien, pero la siguiente pregunta que le hice lo dejó algo descolocado: “¿Has pensado en cómo será el crecimiento del equipo dentro de tres años cuando ya nadie recuerde cómo se trabajaba sin IA? O peor aún: ¿has pensado en cómo tu equipo tomará decisiones sobre información ya ‘cocinada’ por la IA?”
Lo segundo que me ha ocurrido es que ha llegado a mí un paper reciente (Gutoreva, Tsim y Papakonstantinou, aún en preprint) que viene a concluir que los sistemas de IA mal diseñados están optimizados para reducir fricción y esfuerzo, pero que es precisamente esa fricción la que produce el aprendizaje y el crecimiento. Es decir, lo que hace la IA fácil de usar es exactamente lo que impide que el equipo se desarrolle. En el paper lo llaman la paradoja del crecimiento frente al confort, y recoge una idea previa del investigador Giuseppe Riva.
La pregunta central de todo esto es la siguiente: ¿se puede conseguir automatización para incrementar la productividad a la vez que desarrollar equipos para el futuro? La respuesta es sí, y depende del diseño del sistema IA.
En junio de 2009, el avión de Air France 447, que voloba de Rió de Janeiro, a París se encontraba sobre el Atlántico cuando cruzaron una tormenta. La tormenta provocó que varios sensores del avión dejasen de funcionar lo que desactivó de forma automática el piloto automático del avión. A partir de ahí, todo se desmorona en minutos. El copiloto que toma los mandos tira del stick (volante del avión) hacia atrás, el avión empieza a perder velocidad y entra en pérdida. La alarma suena de forma repetida durante gran parte de la caída. Pero sin datos, ninguno de los tres pilotos reconoce lo que está pasando. En vez de bajar el morro para recuperar velocidad, al parecer la maniobra más básica que existe, el piloto sigue tirando del stick hacia atrás. A los cuatro minutos, el avión se estrella en el océano sin supervivientes.
La investigación oficial concluyó algo que sacudió a toda la industria: no fue un fallo técnico grave lo que mató a 228 personas (sólo fueron unos segundos sin piloto automático en un avión que seguía siendo perfectamente manejable a mano). Los pilotos habían acumulado miles de horas de vuelo, pero casi todas ellas gestionando la el piloto automático, no volando de verdad. Cuando la máquina les devolvió el control, no tenían las competencias esenciales dominadas para reconocer un stall tan básico y salir de él.
El mismo problema con otra herramienta
Puede ser que algo parecido a lo que ocurrió con el vuelo del Air France 447 lo que esté pasando con la Inteligencia Artificial (IA) y los LLM (Large Language Model). En una investigación liderada por Kosmyna titulada “Your Brain on ChatGPT”, 54 participantes divididos por grupos tenían que escribir distintos ensayos en tres jornadas de trabajo. Los grupos fueron sólo tres y tenían a su disposición diferentes herramientas: (1) Grupo sólo cerebro, sin herramientas de apoyo para escribir los ensayos; (2) Grupo de buscadores web, a los que sólo se les dió un buscador web en internet como ayuda; (3) Grupo IA, a los que se les dio Chat GPT como herramienta de apoyo para escribir.
Esta mañana estaba impartiendo una formación sobre agentes de IA para una empresa industrial de Castilla – La Mancha, y quiero compartir varios puntos que generan dudas.
En primer lugar:
➡️Un asistente de IA es por ejemplo un Gem de Gemini, y ayuda en tareas repetitivas. Trabajas un prompt y le añades conocimiento experto sobre el tema en cuestión, y lo utilizas cientos de veces. Ejemplo: Un Gem que te analiza propuestas de proveedores y las prioriza según tus criterios habituales.
➡️Una automatización es un conjunto de acciones que siempre ocurren de la misma forma dado un elemento que la dispare. Ejemplo: una alerta al Watsapp que te lanza la entrada de un email importante de un proveedor, y es urgente responder.
➡️Un sistema multi agente de IA es una automatización con uno o varios asistentes de IA. Por ejemplo: la subida de un proyecto de un proveedor a un directorio drive en particular actúa de disparador para que distintos agentes de IA analicen dicha propuesta desde diferentes enfoques (producto, costes, negocio, etc…)
Existe la falsa creencia generalizada de que el Reglamento Europeo de Inteligencia Artificial (AI Act) solo concierne a las compañías que desarrollan algoritmos. Sin embargo, la gran mayoría de las organizaciones no fabrican estos sistemas, sino que los integran y despliegan en sus operaciones cotidianas.
A partir del 2 de agosto, fecha en la que entra en pleno vigor el marco normativo para los sistemas de alto riesgo, aquellos que toman decisiones sobre personas en ámbitos como recursos humanos, créditos, seguros o servicios esenciales, la responsabilidad recae de forma directa sobre las empresas usuarias. Las sanciones por incumplimiento pueden alcanzar hasta los 15 millones de euros o el 3% de la facturación global, elevándose a 35 millones o el 7% en casos de prácticas prohibidas.
Las dos caras de la normativa: Desarrollador frente a Desplegador
El marco legal diferencia con claridad dos perfiles cuyas obligaciones difieren notablemente:
Empresa Desarrolladora: Fabrica el sistema y asume la carga técnica y documental más pesada (evaluaciones de conformidad, marcado CE y registros oficiales).
Empresa Desplegadora: Contrata y utiliza el sistema. Su responsabilidad se centra en una mochila operativa que incluye el uso conforme a las instrucciones del fabricante, la implantación de supervisión humana, la trazabilidad de los registros y la comunicación a los afectados.
El riesgo invisible de cruzar la frontera (Artículo 25)
Una organización puede convertirse en fabricante de forma involuntaria si incurre en alguna de estas tres situaciones:
Marca blanca (white label): Integrar un modelo de terceros dentro de un producto propio y ofrecerlo al mercado como solución corporativa.
Modificación sustancial: Aplicar procesos de fine-tuning agresivos con datos propios que alteren el comportamiento original del modelo.
Cambio de finalidad: Utilizar un sistema para un fin de alto riesgo para el cual el proveedor no lo diseñó (por ejemplo, emplear una herramienta de análisis de texto para realizar cribas de candidatos laborales).
Obligaciones clave para las empresas usuarias
1. Requisitos operativos para el desplegador
Formación de la plantilla: Obligatoria y proporcional al riesgo asociado al uso del sistema.
Supervisión humana real: Asignar personas con la formación, autoridad y tiempo necesarios para intervenir o contradecir al sistema.
Uso estrictamente previsto: Respetar los límites de finalidad definidos por el creador.
Transparencia: Informar de manera clara a los trabajadores y usuarios afectados, garantizando el derecho a una explicación en decisiones críticas.
Gestión de incidentes: Monitorear el rendimiento, suspender el funcionamiento ante fallos graves y notificar tanto al proveedor como a la autoridad competente (AESIA).
Conservación de registros (logs): Guardar la trazabilidad de las decisiones y pruebas de supervisión durante al menos seis meses.
Evaluación de impacto: Requisito indispensable en sectores regulados como banca, seguros y servicios públicos.
2. Requisitos documentales exigibles al proveedor antes de firmar
Instrucciones de uso técnicas y específicas (más allá del material comercial).
Declaración UE de conformidad y marcado CE visible.
Comprobante de registro verificado en la base de datos oficial de la UE (para sistemas de alto riesgo).
Protocolos claros de gestión y recuperación de registros.
Delimitación por escrito de qué constituye una modificación sustancial.
Métricas de precisión, mitigación de sesgos y ciberseguridad.
Canales formales de vigilancia posventa y notificación de incidencias.
Conclusión: Un desafío de arquitectura, no solo legal
El cumplimiento del AI Act no se resuelve únicamente mediante una revisión de cláusulas jurídicas en el departamento legal. Requiere diseñar una arquitectura de decisiones donde la empresa mantenga el criterio humano y evite la deuda cognitiva organizacional derivada de delegar decisiones críticas sin la debida supervisión.
Plan de acción inmediato
Auditoría de contratos: Identificar qué acuerdos sitúan a la empresa como cliente final y cuáles corren el riesgo de cruzar los límites del artículo 25.
Validación documental: Comprobar la existencia de las piezas técnicas y legales exigidas al proveedor.
Mapeo de supervisión: Asignar y documentar de manera nominal qué persona supervisa cada sistema automatizado dentro de los flujos de trabajo.
Las organizaciones actuales exigen a sus equipos agilidad e innovación entre otros, y para ello ven en la Inteligencia Artificial la herramienta perfecta para lograrlo. Es lógico que piensen esto, la IA es la herramienta cognitiva más potente jamás inventada, y bien utilizada puede lograr mayores tasas de innovación y mayor agilidad y productividad. Sin embargo, esto no es fácil, pues la IA mal utilizada fomenta la complaciencia intelectual.
La narrativa dominante (y por supuesto errónea) es que la IA es una especie de oráculo de la verdad de una única respuesta. Si a esta idea le sumas las conclusiones de numerosos estudios que indican que a mayor confianza en la IA menor es el esfuerzo y menor es el pensamiento crítico es cuando tenemos un problema de verdad.
No podemos delegar sin criterio en algoritmos cuya base fundamental es la estadística. El funcionamiento de nuestro cerebro se asimila al de cualquier otro músculo de nuestro cuerpo, y cuando delegamos el pensamiento en ella (la IA), ella gana inteligencia y nosotros reducimos la reducimos. Dicho de otra forma, si no utilizamos el pensamiento crítico, éste se atrofia.
Cuando una empresa inicia su primer piloto de Inteligencia Artificial, suele celebrar la velocidad y la eficiencia. Contratan talento joven, eligen un modelo (GPT-4, Claude o Gemini) y empiezan a ver resultados. Sin embargo, en ese mismo instante, la mayoría está cometiendo el error estructural más caro de la década: están regalando su activo más valioso sin darse cuenta.
No es un problema de datos. Es un problema de soberanía cognitiva.
El peligro invisible: Deuda Cognitiva Organizacional
Llevo tiempo hablando de la Deuda Cognitiva individual: ese conocimiento que dejas de aprender hoy por delegar tu pensamiento a la IA y que te hará falta mañana. Pero cuando este patrón se escala a toda una compañía, nace la Deuda Cognitiva Organizacional.
Ocurre cada vez que:
Un analista perfecciona sus prompts y enseña a un GPT cómo piensa su empresa sobre un cliente, pero ese conocimiento vive en los servidores de OpenAI, no en los de la empresa.
Un directivo externaliza su toma de decisiones compleja a Claude. El “ADN decisorio” de ese líder se queda en la nube de un tercero.
El conocimiento tácito de los empleados —lo que saben de tus clientes, tus procesos y tus fallos— se vierte en conversaciones efímeras que la empresa no puede auditar ni recuperar.
La Deuda Cognitiva Organizacional es lo que la empresa deja de retener por ceder su pensamiento colectivo a proveedores externos. Si mañana cambias de proveedor, ¿qué te queda? Si la respuesta es “nada”, tienes una dependencia crítica disfrazada de eficiencia.
Todo el mundo parece estar compitiendo por enseñarte a montar agentes de Inteligencia Artificial. Sin embargo, casi nadie te está contando la verdad incómoda: los agentes pueden ser tu mayor multiplicador o tu vía rápida hacia la irrelevancia profesional.
La mayoría de los profesionales están cayendo en el segundo grupo sin saberlo. En este post, vamos a clarificar la confusión entre asistentes, automatizaciones y agentes, y te daré la clave definitiva para delegar sin perder tu valor.
1. El Triángulo de la Confusión: Asistentes, Automatizaciones y Agentes
Para dominar la tecnología, primero hay que nombrarla correctamente. No todo lo que “hace cosas” es un agente.
Asistentes de IA (Ejecución): Sustituyen la ejecución puntual. Son los GPTs, las Gemas de Gemini o los Projects de Claude. Tú preguntas, ellos responden. Tú mantienes la responsabilidad total de qué hacer con esa respuesta.
Automatizaciones (Repetición): Sustituyen el trabajo repetitivo basado en reglas fijas (n8n, Make). “Si llega este email, mételo en el CRM”. No piensan, cumplen órdenes deterministas. Aquí el riesgo de pérdida de criterio es bajo porque las reglas las pones tú.
Agentes de IA (Decisión): Aquí es donde todo cambia. Un agente no recibe instrucciones, recibe un objetivo. Decide qué pasos dar, qué herramientas usar (web, código, bases de datos) y encadena decisiones sin que tú apruebes cada paso.
La diferencia es crítica: El asistente sustituye la ejecución; la automatización, la repetición; pero el agente sustituye el proceso de razonamiento.
¿Cuántas veces esta semana has cambiado de opinión solo porque la IA te llevó la contraria? O, quizás más inquietante: ¿has conseguido que la IA te lleve la contraria a ti en algún momento?
Muchos profesionales creen que están colaborando con la inteligencia artificial cuando, en realidad, se están rindiendo a ella. No es un problema de eficiencia, es un problema de gobierno cognitivo.
El Gap de Control: La ilusión de decidir
Un reciente informe del Human Clarity Institute (mayo 2026) arroja un dato que debería hacernos reflexionar: aunque el 74% de los profesionales siente que mantiene el control en la toma de decisiones, el 59% reconoce sentirse “empujado” por las sugerencias de la IA.
