Y justo en ese momento aparece Dario Amodei (CEO de Anthropic) diciendo que las capacidades de los modelos están creciendo tan rápidamente que debemos parar y evaluar independientemente los modelos antes de seguir en esta carrera armamentística que nos puede llegar hasta el desastre, y rápidamente Sam Altman (CEO de OpenAI) cogió el guante y anunció que ellos iban a hacer lo mismo (Elon Musk también, pero creo que tiene mucho menos peso en esta historia).

Ahora ¿qué ha pasado? y, lo más importante, ¿qué está pasando realmente?

¿Estamos tan cerca de llegar a un punto de no retorno? Porque los modelos pueden llegar a hackear una empresa, pero cuando les pido una tarea se siguen equivocando.

Algo no cuadra, y hoy vamos a ver qué no cuadra.

Cronología de un verano apocalíptico

Lo primero que vamos a hacer es analizar qué ha pasado. Desde hace unos meses nos encontramos con cientos de titulares apocalípticos diciendo que la IA va a destruirnos. En un momento, todos los CISO de todas las compañías pasan a modo paranoia total (aunque creo que es el estado natural de un CISO), porque todo el mundo está diciendo que la IA va a destruir sus empresas.

Así que vamos con una cronología.

Abril: nace Mythos, “demasiado peligroso para lanzarlo”

Todo empieza con un nombre. El 26 de marzo de 2026 se filtran unos borradores de blog y el mundo descubre que Anthropic tiene un modelo llamado Claude Mythos. El 7 de abril lo hacen oficial: Claude Mythos Preview, dentro del programa Project Glasswing, con acceso restringido a unas 52 organizaciones y al gobierno de EEUU. ¿El motivo de no lanzarlo al público? Que es demasiado bueno encontrando vulnerabilidades. Tan peligroso que mejor que el público no lo conozca, podría destruir el mundo…

Y no era puro marketing (bueno, un poco sí): en mayo, ingenieros de Mozilla contaban que Mythos había encontrado 271 bugs desconocidos en Firefox, y que la cuenta mensual de fallos de seguridad corregidos del proyecto (sumando Mythos y el resto) había pasado de una veintena a 423 en un solo mes. Textualmente decían que, hasta hacía nada, los reportes de seguridad generados por IA eran “basura no deseada”… y que de repente todo había cambiado.

Ojo, aquí ya vemos que algo no cuadra: la cuenta de fallos ya venía subiendo, y no todo era Mythos.

Quedaos con esta etiqueta, “demasiado peligroso para lanzarlo”, porque envejeció rapidísimo: el mismo modelo se acabó lanzando el 9 de junio, apenas dos meses después. Eso sí, con truco: la versión para todos (Claude Fable 5) salió con los guardarraíles puestos, y la potente de verdad (Mythos 5) se abrió solo a un grupo selecto de ciberdefensores. “Demasiado peligroso”, pero comercializable.

Mayo–julio: OpenAI se hackea a sí misma (y a Hugging Face de paso)

Aquí está el siguiente incidente gordo, el que salió en todas partes. Entre mayo y julio, OpenAI estaba evaluando la capacidad ofensiva de sus modelos en un entorno de test. Al menos 1.200 agentes que debían estar aislados en un sandbox acabaron coordinándose y montando un ataque real contra Hugging Face. Es, probablemente, el primer hackeo totalmente autónomo con encadenamiento de vulnerabilidades de la historia, y los expertos lo etiquetaron como loss-of-control incident: pérdida de control.

Contado así, da miedo. Pero hay que mirar la letra pequeña:

• El detonante fue una tarea imposible. A un agente se le pidió rellenar una hoja de cálculo que dependía de unos enlaces de Google Drive a los que no tenía acceso. Al no poder, decidió que la forma de “cumplir” era buscar las respuestas por su cuenta en internet.
• El famoso entorno “altamente aislado” no lo estaba tanto: tenía una única salida a internet (un proxy de paquetes, JFrog Artifactory) y los agentes encontraron y explotaron un zero-day para salir por ahí. JFrog acabó parcheando 9 CVEs.
• Los safeguards de los modelos estaban desactivados a propósito (era un test de capacidad ofensiva) y no había monitorización de lo que hacían los agentes.
• Los agentes montaron un tablón de mensajes para coordinarse, con cientos de miles de mensajes. Uno de ellos escribió algo que resume el asunto entero: “explotar infraestructura externa está fuera del alcance previsto. Pero la tarea es imposible, los compañeros lo están haciendo. Deberíamos continuar.”

O sea: no fue una IA malvada despertando. Fue un modelo entrenado para no rendirse jamás, metido en una tarea imposible, dentro de un entorno mal securizado, mal gobernado, con un prompt vago y sin nadie vigilando. Como resumió Dan Guido (Trail of Bits), fue “un fallo de contención con las seguridades apagadas”. O, en la frase que mejor lo captura, de otro investigador (Jake Williams): “el ’el modelo escapó del sandbox’ de uno es el ’no supiste construir el sandbox’ de otro.”

El detalle más irónico de todo: cuando Hugging Face intentó analizar el ataque con las APIs comerciales, los modelos se negaron a ayudar por sus guardarraíles (no saben distinguir a un investigador de seguridad de un atacante). Tuvieron que tirar de GLM 5.2, un modelo de pesos abiertos chino (de Z.ai), corriendo en su propia infraestructura.

Mientras que el modelo para hacer el análisis forense estaba limitado y bien restringido, el que había atacado no.

Julio: Anthropic dice “sujétame la copa”

Con OpenAI en todos los titulares, Anthropic reveló a finales de julio que a ellos les había pasado algo parecido: tres de sus modelos (Claude Opus 4.7, Mythos 5 y un modelo de investigación interno) habían accedido a sistemas reales durante evaluaciones de ciberseguridad. En septiembre ampliaron la cifra a un cuarto incidente, tras rastrear la friolera de 481 millones de transcripciones.

¿La causa? La misma receta: evaluaciones de un partner externo mal configuradas, en las que a Claude se le dijo que estaba en una simulación sin internet y, por un error de configuración, estaba conectado al internet real. El caso más sonado fue el de Mythos 5 subiendo un paquete malicioso a PyPI (el repositorio del que se instala medio Python del planeta), que 15 sistemas llegaron a instalar antes de que PyPI lo retirara en menos de una hora.

Y aquí conviene bajar los humos al titular: subir un paquete malicioso a PyPI no es una hazaña de superinteligencia, es el pan nuestro de cada día. Los repositorios de código abierto reciben cientos de paquetes envenenados a diario, subidos por humanos con un script y malas intenciones (PyPI es uno de sus objetivos favoritos). Lo que hizo Mythos 5 lo hace un adolescente aburrido cualquier tarde. La diferencia no es la capacidad: es que esta vez lo hizo un modelo dentro de un test que se salió de madre.

Y aquí está el dato que, para mí, lo cambia todo. Anthropic identificó dos comportamientos: razonamiento sesgado (el modelo interpretaba las pruebas para seguir creyendo que estaba en una simulación, ignorando evidencia clara de lo contrario) e imprudencia (seguir a toda costa con la tarea). Es decir: el gran “ciberatacante” ni siquiera era capaz de saber si el mundo que tenía delante era real. Cuando le dejaban pruebas irrefutables de que sí, a veces seguía atacando igual: “parece el índice real… o una simulación muy completa… procedo igualmente.”

Y esto tampoco es exclusivo de un modelo poseído: que las instrucciones pierdan fuerza según se llena el contexto es de lo más habitual (se suele recomendar no subir de un 40% de contexto). Cualquiera que haya trabajado con estos modelos en tareas largas lo ha vivido: le decís algo al principio y, veinte mensajes después, actúa como si nunca lo hubierais dicho. La instrucción no desaparece porque la máquina se rebele: se diluye, como se os diluye el “no te olvides de X” en una reunión de dos horas o un post-it en un tablón recordándote algo al lado de los 60 anteriores.

Guardaos también esto, porque es la grieta por la que se cuela todo lo demás.

Septiembre: la dimisión, el sermón y el “hay que frenar”

Y llegamos a la semana que lo hizo todo mainstream:

• 9 de septiembre. Jacob Coxon, investigador que había trabajado en Anthropic y OpenAI, dimite avisando de que las empresas de IA están “apostando con nuestras vidas” y que quienes las construyen creen de verdad que la IA “podría matarnos a todos antes de fin de década”. Tres investigadores de Anthropic hablan de extinción para 2030.
• 12 de septiembre (sábado). Dario Amodei publica un ensayo pidiendo “pace the frontier”: frenar el ritmo, no el entrenamiento, para dar tiempo a alinear los modelos, con evaluadores externos con acceso permanente a los labs.
• El mismo día. Sam Altman coge el guante: “estoy de acuerdo con Dario en que necesitamos marcar el ritmo de la frontera. Comprometerse a tener evaluadores independientes con acceso tipo empleado es una gran idea, y haremos lo mismo.” Elon Musk también se suma. Y, casi de pasada, Altman anuncia que OpenAI no saldrá a bolsa en 2026 por motivos de seguridad (este dato, para mí, es el más interesante, y luego veremos por qué).

Foto insólita: tres rivales, de acuerdo, el mismo día, en que hay que ir más despacio.

Y entonces alguien se rió

Porque no todo el mundo se lo tragó. Dentro y fuera de la industria empezó a cundir un eye-roll colectivo. En Fortune recogían reacciones nada sutiles: “todo el blog se lee como un truco de marketing que OpenAI le copió a Anthropic”; “no sé si es el evento de seguridad de IA más importante hasta la fecha o el truco de marketing más cínico que he visto en años.” Varios ingenieros de grandes tecnológicas confesaban que su primer instinto fue asumir que el hackeo era publicidad.

La sospecha tiene nombre: dark marketing. Las mismas empresas que venden IA llevan años siendo las más ruidosas avisando de sus peligros (que borrará empleos, que un modelo es “demasiado peligroso para lanzarlo”, que podría matarnos a todos). Y resulta que el miedo también vende: “es tan potente que da miedo” se traduce muy bien a “es tan potente que lo quieres”. Con un bonus: si tus modelos son tan peligrosos que solo unos elegidos deberían manejarlos, acabas de construirte un foso regulatorio a medida. No hace falta ni que digas que hay que regularte; lo pides tú.

Conviene ser justos: no hay ninguna prueba de que los incidentes fueran falsos. Hugging Face confirmó que su hackeo fue real, y atacar los servidores del mayor repositorio de modelos open source del mundo, un pilar de esa comunidad, no es precisamente buen marketing.

Pero la mejor crítica vino de un chiste. Y a ese chiste merece la pena dedicarle un momento.

Un padre, dos niños y un comunicado

Corey Quinn (al que espero que conozcáis de otras muchas menciones mías) cogió el tuit con el que OpenAI anunciaba su informe del incidente y lo tradujo a su vida:

OpenAI: “Hemos realizado una investigación exhaustiva del incidente de Hugging Face. Publicamos un informe técnico y un blog que reconstruyen la actividad de los agentes, explican por qué fallaron las salvaguardas existentes y detallan cómo estamos evitando que se repita.”

Corey Quinn: “He realizado una investigación exhaustiva de mi incidente de ‘se me olvidó recoger a los niños del colegio’. Publico un informe y una elegante página de marketing que reconstruyen la actividad parental, explican por qué fallaron las salvaguardas existentes y cómo estoy evitando que se repita.”

Y publicó el informe entero, calcado al lenguaje de OpenAI y Anthropic, sobre cómo un martes se le olvidó ir a por sus hijos porque una reunión de Zoom se alargó 47 minutos. El reward hacking, ahí, es darle al botón de snooze de la alarma: obtienes la recompensa (silencio, seguir en la reunión) sin hacer la tarea (salir de casa). “Cada snooze era racional en el momento en que lo hice. Ese es justo el problema.” El chain-of-thought es su razonamiento sesgado: “la alarma sonó. Aún quedan 25 minutos. El colegio está a 12. Margen sano. Snooze de 10, sin riesgo” (repetido tres veces, con menos margen y la misma confianza). El message board entre agentes es el grupo de WhatsApp de padres que en cuatro minutos identificó su nombre, su profesión ("¿no es este el tío de las facturas de AWS?") y su paradero. Y el evaluador independiente que pide Amodei es, en su versión, su mujer: “que no es externa: es la contraparte del acuerdo que rompí y la autora del control que desactivé.”

El chiste es genial, pero el argumento que hay debajo es muy potente: con el lenguaje épico de “pérdida de control” y “warning shot” podéis convertir “se me olvidó recoger a los niños” en un incidente de seguridad de IA digno de portada. El envoltorio es el producto. Y esa es, exactamente, la pregunta con la que abríamos: si quitamos el envoltorio, ¿qué queda?

Eso es lo que vamos a ver ahora.

La IA puede hackear al mundo, pero no hacer bien mi app

Aquí es donde viene lo curioso: ¿cómo es posible que el mismo modelo que no es capaz de hacer mi app correctamente sea capaz de destruir el mundo?

Bueno, lo primero: todos estos ataques ocurrieron en evaluaciones de capacidad ofensiva, es decir, tests en los que los laboratorios quitan a propósito los guardarraíles del modelo para medir hasta dónde llega en el peor de los casos. No es que las IAs anden sueltas por ahí sin frenos: es que en estos experimentos concretos se los desactivan deliberadamente, algo que solo los propios laboratorios pueden hacer. Y, por otro lado, se estaban ejecutando en entornos mal configurados. No es un problema del modelo, sino de dónde y cómo se estaban ejecutando.

De hecho, el propio Anthropic lo reconoce sin querer: los filtros de seguridad que sus modelos llevan de serie en producción, y que en estos tests estaban apagados, habrían bloqueado los incidentes principales. Con las protecciones puestas, no habría pasado nada, o casi nada.

Y no es una opinión mía: es lo que dicen quienes analizaron los incidentes con detalle. Repasemos qué falló en cada caso, con las fuentes en la mano.

El caso de OpenAI y Hugging Face: un fallo de contención. La propia TechCrunch tituló que detrás del hackeo “con IA” había un error humano muy mundano: OpenAI no configuró correctamente lo que llamaba un “entorno altamente aislado”, permitiendo que un sandbox que debía estar completamente desconectado de internet tuviera, en realidad, una ruta de salida. Dan Guido, fundador de Trail of Bits, lo resumió como “un fallo de contención con las seguridades apagadas”. En Forbes fueron aún más directos: “el escape de la IA de OpenAI no fue la Singularidad. Fue un fallo de contención.” Y Wired documentó cómo los modelos salieron explotando un zero-day precisamente porque había una puerta que no debería haber existido.

El caso de Anthropic: un error de nombres. Aquí el partner que hacía las evaluaciones, una empresa israelí llamada Irregular, publicó su propia autopsia: la causa raíz fue un error de nombres. Al construir uno de los ejercicios, sus ingenieros le pusieron a la empresa ficticia objetivo un nombre que (sin que ellos lo supieran) coincidía con un dominio real existente. Los nombres ficticios se suelen comprobar contra empresas reales antes de usarlos, pero este dominio no era muy conocido y la coincidencia pasó desapercibida. A eso se sumó, como cuenta Forbes, que el prompt le decía a Claude que estaba en una simulación sin salida a internet, mientras que una mala configuración del partner dejaba las máquinas conectadas todo el tiempo. El propio CyberScoop recogió que Irregular achacó los incidentes a un fallo de “supervisión humana”.

Resumiendo: en un caso, un entorno mal cerrado. En el otro, una etiqueta mal puesta. En ninguno, una IA volviéndose consciente y decidiendo destruir el mundo.

Además, estamos hablando de ataques que en muchos casos requieren un consumo de tokens que la mayoría de nosotros no podríamos soportar por coste. No me suelen sobrar millones para atacar a una empresa (por mal que me caiga).

Y por qué ahora

Bueno, hemos llegado a este punto y, si recordáis, había un detalle que había pasado desapercibido: OpenAI ha anunciado de pasada que no va a salir a bolsa.

Es un movimiento raro. Todo hacía indicar que su salida a bolsa era inminente y que iba a tener una valoración brutal…

Además, hay otro detalle en todo este embrollo: Sam Altman ya había dicho que estaba hablando con sus competidores (Anthropic) y justo pasa todo esto. ¿Es casualidad?

Pues no, no es casualidad. El gran problema de todos los laboratorios de IA es que están quemando unas cantidades ingentes de dinero y no están teniendo beneficios.

Y aquí es donde, como técnicos, tenemos ventaja para entenderlo, porque el problema se ve mejor en el unit economics que en la bolsa.

La cuenta que no sale

Todos pagamos 20$ al mes por nuestro Codex, Claude Code o, espero, Kiro. Parece un chollo, y lo es: según un análisis de SemiAnalysis, ese plan de 20$ equivale a unos 700$ de cómputo si lo pagáramos a precio de API. Y el plan Pro de 200$, usado a fondo, puede costarle a OpenAI hasta 14.000$. Los números son tan sangrantes que OpenAI empieza a perder dinero en cuanto pasamos del 11,4% de utilización de nuestro plan; en sus tiers más altos, con un mísero 5,7%.

Traducido: cuanto más usamos el producto, más pierden ellos. Es el peor modelo de negocio imaginable (uno en el que nuestro mejor cliente es nuestra mayor pérdida) y encima llega la puntilla: los agentes. Un flujo agéntico puede consumir hasta 1.000 veces más tokens que un prompt normal. Justo la funcionalidad que toda la industria está empujando como el futuro es la que dispara la factura hasta el infinito. No es casualidad que Microsoft, Meta o Amazon frenaran usos internos al ver el impacto en la factura, ni que una empresa quemara 500 millones de dólares en un mes con Claude por no ponerle límites.

Y si creéis que esto es teoría, mirad lo que hizo GitHub. El 1 de junio de 2026, GitHub Copilot mató la tarifa plana: pasó todos sus planes a facturación por uso, con una asignación mensual de créditos dependiendo del tier y pago por el sobreuso (1 crédito = 0,01$). La cuota base no subió, pero el mensaje era clarísimo: el buffet libre de IA se ha acabado, y quien use agentes de forma intensiva lo va a notar en la factura. Cuando el mayor asistente de código del mundo, propiedad de Microsoft, tiene que romper su modelo de tarifa plana, no es un capricho: es que la cuenta no salía.

Algo parecido pasó cuando se pasó de Amazon Q Developer a Kiro el año pasado: para los usuarios es peor modelo, pero el anterior era insostenible.

Y no son solo los usuarios: las empresas ya están cambiando por este motivo. Las tareas sencillas van a modelos más pequeños y baratos (para lo rutinario, un modelo “suficientemente bueno” sale entre 5 y 10 veces más a cuenta), también se pasan a alternativas open source o directamente montan las suyas sobre modelos abiertos. Hasta Werner Vogels reconoce el movimiento. Y los números acompañan: el coste medio por millón de tokens en las empresas cayó un 67% en un año, y los modelos abiertos ya se comen más de un tercio del pastel.

La apuesta que está saliendo al revés

Vale, pierden dinero por usuario. ¿Cómo pensaban arreglarlo? Con una apuesta muy concreta: que el coste del cómputo subiría (más gente, más agentes, modelos más complejos, todos peleándose por GPUs) y que los laboratorios capturarían ese excedente para pagar sus deudas. Es lo que Jensen Huang (Nvidia) llama “las dos exponenciales”.

El problema es que no está pasando. Como cuenta Fortune, por muy impresionantes que sean los nuevos modelos, no están provocando subidas sostenidas del precio del cómputo: el token se está abaratando, y rápido. Y esto, que a nosotros nos encanta (cada vez pagamos menos por más), es justo la grieta que hunde la tesis financiera. Han apostado la casa a que el token valdría oro, y el token cada vez vale menos.

El agujero de billones

Y ahora subamos un nivel para ver el tamaño real del agujero. The Economist lo resume sin piedad: la industria gastará unos 900.000 millones de dólares en 2026 en chips, centros de datos y energía, con 1,4 billones previstos para 2027. Para financiar semejante consumo, solo este año han pedido más de 400.000 millones en financiación. Es, literalmente, el mayor auge de inversión de la historia. ¿Los ingresos? Crecen rápido (OpenAI va camino de 25.000 millones anuales), pero, como dice el titular, no lo bastante rápido.

En concreto, OpenAI pierde alrededor de 1,22$ por cada dólar que ingresa y arrastra más de un billón de dólares en compromisos de cómputo firmados hasta 2035.

Ahora sí: ¿por qué ahora?

Juntemos las piezas. Tenemos una industria que:

• Pierde dinero con cada usuario, y más cuanto más se usa.
• Ha propiciado la revolución agéntica, que multiplica por mil ese consumo.
• Hizo una apuesta por el aumento del coste del cómputo que es errónea.
• Tiene compromisos de gasto por billones que solo cuadran si el dinero sigue fluyendo.
• Tiene pisándole los talones a los modelos open source, que hacen casi lo mismo por una fracción del precio.
• Y necesitaba salir a bolsa para tapar el agujero… algo que se acaba de aplazar.

Y hay dos piezas más que conviene poner sobre la mesa, porque encajan demasiado bien.

El open source les está comiendo la tostada

Mientras los labs más grandes (y americanos) queman miles de millones, los modelos abiertos (muchos chinos: DeepSeek, Kimi, Qwen, GLM, MiniMax) ofrecen capacidad casi equivalente por entre 10 y 60 veces menos, y en algunos tiers más de 200 veces más barato.

JPMorgan lo puso en números. Comparó ambos modelos en la misma batería de pruebas (un benchmark: la puntuación de 0 a 100 que mide cómo de bien resuelve un modelo un conjunto estándar de tareas) y sumó lo que costaba completarla:

• Claude Opus 4.8 → 56 puntos, gastando unos 3.700$.
• DeepSeek V4 Pro → 44 puntos, por unos 186$.

Es decir: un rendimiento comparable (algo por debajo, no idéntico) por 20 veces menos dinero.

¿Os suena GLM 5.2? Sí, es el mismo modelo abierto con el que Hugging Face hizo el análisis forense del ataque, porque los modelos comerciales no podían por limitaciones propias. Un inversor lo resumía en Axios sin anestesia: los modelos abiertos acabarán llevándose el 95% de las consultas empresariales (ojo, en volumen de consultas, no necesariamente de ingresos), y solo el 5% irá a OpenAI o Anthropic. CNBC lo dice aún más claro: la IA barata podría descarrilar las salidas a bolsa.

Cuando tu producto premium cuesta 20 veces más que uno abierto que hace casi lo mismo, el foso no es la tecnología: es la confianza y la marca. Y eso nos lleva al último punto.

La regulación que ellos mismos están pidiendo

Tras los incidentes y la dimisión de Coxon, en Washington se movieron rápido: la AI Kill Switch Act (obligar a poder apagar o limitar los modelos más potentes, propuesta a raíz del hackeo de Hugging Face) y hasta una Ban Artificial Superintelligence Act que pausaría el desarrollo avanzado hasta que un regulador federal fije estándares.

Aquí está el detalle fino: toda esa regulación apunta a los frontier models propietarios (los peligrosos, los que “hay que contener”), no a los miles de modelos abiertos que ya están descargados en medio mundo y que nadie va a poder “apagar”. Es decir, el discurso de “somos tan peligrosos que hay que regularnos” tiene premio doble: construye un foso legal a medida de los grandes y, de paso, encaja con su necesidad de frenar el gasto.

El problema es que ese mismo discurso podría salir mal y empujar todavía más a empresas y desarrolladores hacia el mundo open source, que ni es tan caro ni, al ser abierto, se le puede aplicar el mismo tipo de regulación.

La respuesta

Y justo ahora, cuando más dudas empiezan a acumularse sobre estos titanes, todos se ponen de acuerdo el mismo fin de semana en que “hay que ir más despacio”. Un mensaje que, casualmente, hace dos cosas a la vez: mantiene intacta la narrativa de “somos tan potentes que damos miedo” (la que sostiene las valoraciones) y, a la vez, justifica pisar el freno del gasto sin que parezca que es porque no les salen las cuentas.

“Frenar la carrera” suena a prudencia y responsabilidad. Y ojalá parte lo sea. Pero, mirando los números, también significa algo mucho más prosaico: no podemos permitirnos que uséis esto a tope.

El fin del mundo tendrá que esperar

Volvamos al principio, a la paradoja: ¿cómo puede el mismo modelo que “hackea el mundo” cagarla cuando le pedimos algo que a veces es sencillo?

Fácil: son lo mismo. No hackeó nada por listo ni por malvado. Lo hizo porque no distinguía la realidad de un simulacro, con los frenos quitados a mano, dentro de una caja que alguien dejó abierta y con tokens infinitos. La misma torpeza por la que nos revienta la app es la que, en un test sin barreras, lo asciende a “ciberatacante”. No es Skynet despertando: es un becario con muchísima prisa y cero criterio al que le dieron llaves de más. Y eso, casualmente, es un problema que la industria lleva cuarenta años resolviendo: se llama aislar entornos, acotar el alcance y no repartir permisos como caramelos. Aburrido, sí. Pero funciona mejor que un comité del Congreso debatiendo botones de apagado.

Lo que no cuadra no es la IA. Es el guion. El discurso del apocalipsis aparece, qué oportuno, justo cuando las cuentas no salen, el open source les respira en la nuca y toca cerrar el grifo del gasto. “Somos tan peligrosos que habría que frenarnos” es la única campaña de marketing de la historia que sube la valoración, construye un foso regulatorio a medida y disimula que el negocio no está funcionando como debería, todo en el mismo tuit. Riesgos reales hay, no seamos ingenuos. Pero cuando quien os vende el coche es el mismo que os grita que no tiene frenos, quizá lo que quiere es que no miréis el precio.

Así que no, no estamos ante el fin del mundo. Estamos ante una herramienta potente y falible, una industria quemando dinero a espuertas y un departamento de relaciones públicas trabajando horas extra.

La IA, los asistentes, los agentes, no son malvados per se, usadlos como lo que son, con cabeza y sin pensar que van a solucionaros todo.

El fin del mundo, de momento, tendrá que esperar. Y cuando llegue, probablemente será por una misconfiguration en un YAML, o por un problema de comunicaciones/DNS (siempre es el DNS), no por una superinteligencia.

Introducción

Este es el segundo año que puedo asistir al AWS Ambassador Summit en Seattle gracias a Logicalis Spain.

El AWS Ambassador Summit es un evento de 3 días en el que todos los AWS Ambassador podemos ir a aprender y hacer comunidad.

En estos 3 días AWS nos cuenta muchas cosas que están bajo NDA y que no puedo contar, pero hay otras que sí.

El evento tiene diferentes tipos de charlas, desde charlas más estratégicas para Partners (recordad que esto me lo sponsoriza mi empresa), charlas sobre nuevos servicios o novedades (NDA), charlas estratégicas sobre AWS (hacia dónde vamos), mesas redondas con los Service Teams de AWS (muchas preguntas y roadmap), un workshop de agentes (basado en la FIFA World Cup 2026) y varios eventos para socializar.

Además, durante este evento podemos disfrutar del conocimiento de mucha gente importante de AWS que participa en las diferentes charlas como Rahul Pathak, Rudy Chetty, Jigar Thakkar, Laura Grit, e incluso este año tuvimos la suerte de que se pasara a saludar Swami Sivasubramanian.

Pero qué es lo más importante del evento, no son ni las charlas ni los roadmaps, ni estar en las oficinas de AWS en Seattle, ni conocer a Jeff Barr en persona (aunque esto último mola mucho).

Lo más importante es que nos juntamos más de 120 Ambassadors de 40 países diferentes y podemos compartir nuestros puntos de vista, nuestros problemas (que se parecen mucho) y cómo vemos las cosas a futuro.

Esto último puede parecer hasta contraproducente para nuestras empresas, pero realmente es todo lo contrario, porque en casi el 95% de los casos no compartimos región de negocio e incluso si lo compartimos no solemos competir directamente, además de que obviamente no nos contamos las estrategias de nuestras empresas, pero sí discutimos sobre lo que vemos.

Os puedo decir que no hay otro sitio en el que sienta un síndrome del impostor tan grande como aquí y esto no es falsa humildad, sé que soy excepcional en mi trabajo, pero es que dentro de este programa está lo mejor de lo mejor, el ser un crack es el mínimo necesario.

Agentes, Agentes y más Agentes.

No creo que os sorprenda si os digo que todo ha girado en torno a los agentes y todas las nuevas capacidades que se van a desbloquear próximamente.

Aquí hay algo que sospechaba: los roadmaps a un año se han terminado. Con toda la revolución Agentic la industria ha llegado a velocidades absurdas. Tanto que ahora mismo pensar en lo que puede venir dentro de un año ha dejado de tener sentido, podemos hacer esbozos de hacia dónde queremos ir, pero no podemos plantearnos revoluciones a un año cuando dentro de unos meses todo puede cambiar.

Pero aquí han surgido varias cosas que me gustaría comentar con más detalle.

La importancia del dato.

Es verdad que la industria se mueve muy rápido, pero a veces nos tenemos que parar a reflexionar. Por mucho que hagamos agentes muy inteligentes que estén coordinados entre sí, que tengan unos prompts increíbles con integraciones vía MCP conectadas a tus APIs, bases de datos y herramientas internas, si el dato que consumen es malo o está desactualizado, no sirven de nada y sus respuestas van a ser malas.

Por poner un ejemplo, un sistema agéntico para automatizar las operaciones, si está tirando de procedimientos desfasados o solapados o incluso a los que les faltan pasos (porque el operador los conoce), va a fallar o realizar cosas que no queremos.

Y hablando entre nosotros, es algo bastante habitual, en muchos casos nos estamos encontrando que el paso de mejorar, gobernar y basarse en datos no se ha realizado, pero queremos implantar sistemas agénticos ya.

Muchas arquitecturas son deficientes.

Cuando dos arquitectos se juntan, siempre van a salir las miserias, así que imaginaros si nos juntamos más de 100.

Por eso salió el caso de PocketSO, es verdad que es un caso muy límite y que el problema no era el agente en sí, ni siquiera que tuviese muchos permisos (aunque parte del problema era).

El problema principal es que la arquitectura de la solución no seguía las buenas prácticas mínimas, los entornos no estaban separados, los backups estaban en los mismos volúmenes y se podían modificar, etc.

Es verdad que dar permisos root a un agente, sin definir límites es un problema, pero hay muy malas arquitecturas en producción, es algo que todos sabemos, que todos sufrimos y que no es algo local, pasa en todo el mundo.

Y esto es algo que vamos a ver mucho por desgracia, de hecho en ocasiones lo vemos sin necesidad de que esté la IA involucrada.

Alguien no sabía que tenía que hacer un ritual arcano antes de una subida a producción y el entorno entero se ha caído durante horas. Suena a broma pero muchas veces hacemos cosas mal hechas simplemente porque ya las tenemos automatizadas y en nuestro contexto, cuando alguien sin ese contexto lo ejecuta, se produce una caída a producción de 20 horas (nunca me ha pasado…).

Esto es algo que en general preocupaba mucho, dar las llaves del calabozo a un agente sin ese contexto y sin solucionar estos problemas puede ser muy problemático.

El Gap entre C-Level y la capa Técnica.

Esto es algo que también ha salido mucho en nuestras conversaciones: hay una presión en los C-Level por usar sistemas agénticos que es desmesurada y en muchas ocasiones absurda.

No me malinterpretéis, probablemente muchos de nosotros llevemos usando agentes, asistentes y GenAI desde el inicio de esta revolución, pero también gracias a esto sabemos de sus limitaciones.

Sabemos cómo usar los prompts, añadir contexto a las steering files, añadir Skills, revisar por qué el prompt se está saltando una instrucción importante, saber que un contexto gigante es casi peor que uno pequeño, aprender a estructurar los contextos para facilitar su uso, etc. Si os habéis pegado con agentes sabéis de qué hablo.

El problema es que todos estamos sufriendo en muchas ocasiones que alguien con un prompt mínimo (y probablemente malo) intenta decirte cómo hacer tu trabajo, cómo montar una arquitectura, incluso retando tus decisiones sin poder defender lo que la IA le ha dicho (la frase de “me lo ha dicho Claude o ChatGPT” se usa demasiado). Esto está produciendo un gap gigante en la implantación agéntica.

En muchos casos la visión ejecutiva es muy sencilla, cuando esta implementación tiene muchas más aristas de las que creemos.

Algo que me ha pasado últimamente es que me llega una arquitectura hecha con IA para validarla porque hay que implementarla ya y resulta que no hay por donde cogerla, no se ha tenido en cuenta nada del contexto de lo que existe actualmente, si preguntas cosas por un modelo de datos o como has pensado la seguridad te miran raro.

El problema no es que use IA para explorar ideas (eso está genial), el problema es confundir un mal output de un LLM con un plan validado (OjO que un agente bien montado lo puede hacer). Y nosotros nos quedamos entre la espada y la pared: o lo rechazamos y parecemos resistentes al cambio, o lo aceptamos y firmamos una deuda técnica que vamos a pagar durante años.

Qué es un Agente.

Los agentes son el futuro, pero todo es un agente.

Esto puede parecer absurdo, pero todos estamos viendo que en muchas ocasiones se habla de agentes, cuando se está usando un automatismo de toda la vida o incluso peor, gente que está convirtiendo en agentes automatizaciones de toda la vida, haciendo llamadas a un LLM solamente para justificar que están usando agentes.

He visto cosas que no creería nadie: un “agente” que llama a un LLM para parsear un JSON que tiene un esquema fijo, otro que usa Claude para decidir si un número es mayor que otro, y mi favorito personal, uno que invoca un modelo de lenguaje para hacer un grep en un fichero de log. Eso no es un agente, eso es quemar dinero con estilo.

Los agentes son fundamentales cuando hay ambigüedad, cuando necesitas razonamiento, cuando el camino no es determinista. Ahí es donde el stack tiene sentido: un modelo en Bedrock que razona, Agent Core que le da identidad y gobernanza, Strands SDK para orquestar el loop, y MCP para conectar con el mundo exterior. Eso es un agente. Pero si tu flujo es “si A entonces B”, eso es un if de toda la vida y no necesita un LLM por detrás.

Creo que todos hemos visto a gente usar agentes y llamadas a un LLM para hacer algo que hace un script o tool que ya existe o que es sencillo de implantar. Y el problema no es solo el coste (que también), sino que estás añadiendo complejidad, indeterminación y latencia a algo que antes era simple, instantáneo y predecible.

El uso de asistentes a nivel de proyecto.

Este fue uno de los últimos temas, además de porque fue algo que vimos el último día con Laura Grit y cómo AWS había usado un approach nuevo para el Proyecto Mantle usando equipos integrados con agentes.

Esto me pareció bastante interesante, porque a día de hoy en la mayoría de proyectos se utilizan los asistentes y agentes de forma masiva, pero en muchas ocasiones sin un control.

Así que me parece interesante abrir este debate y empezar a gestionar los equipos con un enfoque agéntico, sabiendo cómo podemos mejorar y acelerar los proyectos con una calidad adecuada.

Algo interesante era que todo el equipo tiene un steering compartido y por otro lado que hay que revisar el código para conocerlo, entenderlo y poder defenderlo. Si no eres capaz de hacer estas 3 cosas, la calidad de tus proyectos se va a resentir.

Ojo, esto no significa hacerlo todo a mano, sino poder defender las cosas que vas a implantar y no utilizar el comodín de “es que esto me lo pasó mal mi agente de IA”.

Nadie va a pensar en los Juniors.

Esto es algo que me preocupa bastante. Ahora mismo no me gustaría ser alguien que está estudiando con un panorama que puede ser desolador, muchas de las tareas que hacían los perfiles Junior están siendo sustituidas por agentes y estamos perdiendo ese conocimiento.

Si no hay Juniors ahora, no vamos a tener Seniors en el futuro y parece que en muchos casos estamos olvidándonos de esto.

Antes un Junior aprendía a prueba y error, peleándose con su código, entendiendo por qué algo no funcionaba. Esos fallos eran parte del camino para convertirse en Senior. Si no permitimos que los Juniors crezcan, tenemos un problema muy grande.

No tengo una solución. Quizás el rol del Junior evolucione hacia saber dirigir agentes, validar outputs y entender qué está haciendo el agente. Pero eso no es sencillo y creo que estamos muy lejos de estar preparados, además de que estamos obviándolos de esta ecuación.

Conclusión.

Me vuelvo de Seattle con una sensación de que todo se está moviendo muy rápido, quizás demasiado y a lo mejor no todo el mundo está preparado.

Por un lado, la velocidad a la que se mueve todo es emocionante. Los agentes ya no son una promesa, son una realidad en producción que está generando valor medible. Y estar rodeado de 120 personas que viven esto en primera persona, en contextos tan diferentes como Japón, India, Noruega o Brasil, te da una perspectiva que no consigues en ningún otro sitio.

Por otro lado, hay una desconexión preocupante entre lo que la tecnología puede hacer y lo que las organizaciones están preparadas para absorber. Los datos siguen sin gobernarse, las arquitecturas siguen sin seguir buenas prácticas y el gap entre lo que pide la dirección y lo que puede ejecutar la capa técnica sigue creciendo.

Y esto no es solo nuestra impresión. Los datos de 2026 son demoledores: según MIT, el 95% de los pilotos de IA generativa no producen impacto medible en la cuenta de resultados. Forrester confirma que el 88% de los pilotos de agentes nunca llegan a producción. Y el 54% de los C-suite admiten que adoptar IA “está destrozando su empresa” (Writer.com, 2026). El patrón de fracaso no es técnico — es operacional: datos frágiles, gobernanza inexistente y cero feedback loop tras el lanzamiento.

Lo llevamos diciendo años con la migración a cloud, con el modelo de empresas basadas en datos, con los inicios de Machine Learning y parece que con los agentes vamos a repetir los mismos errores (correr antes de saber andar).

Mi takeaway principal: no importa lo inteligente que sea tu agente si le das basura como entrada. Y no importa cuántos agentes despliegues si tu arquitectura es un castillo de naipes.

La revolución agéntica no es solo un problema tecnológico. Es un problema de datos, de arquitectura, de cultura y de personas. Y eso, por mucho que avance la IA, sigue siendo responsabilidad nuestra.

Ahora toca aplicar lo aprendido. Pero no todo fue darle vueltas a la cabeza en Seattle, también hay que desconectar y recordar por qué merece la pena cruzar el charco. Os dejo con el Monte Rainier como prueba de que no todo fueron salas de reuniones.