AI Engineering Bootcamp: Basta de hacer tutoriales y construye tu propio asistente con IA en producción

Vivimos rodeados de Inteligencia Artificial, pero la inmensa mayoría de la gente que trabaja "con IA" en realidad se limita a llamar a una API, copiar un prompt de Twitter/X o encadenar un par de bloques en una herramienta no-code. Saben usar la IA como usuario avanzado, pero no entienden qué pasa por debajo: cómo se sirve un modelo, cómo se diseña un agente que razona y actúa, cómo se protege un sistema LLM de un ataque de prompt injection o cómo se lleva todo eso a producción para que funcione 24/7 sin que se caiga a la primera de cambio.

Figura 1: AI Engineering Bootcamp: Basta de hacer tutoriales

y construye tu propio asistente con IA en producción

Esa distancia entre "usar IA" y "construir con IA" es, ahora mismo, la que separa a un consumidor de prompts de un auténtico AI Engineer. Y es precisamente esa distancia la que Ferrumox Academy ha diseñado para recorrer en 9 semanas con su AI Engineering Bootcamp.

Figura 2: AI Engineering Bootcamp

Cohorte 2: arranca la semana del 2 de septiembre

El AI Engineering Bootcamp de Ferrumox Academy no es un curso de vídeos a tu ritmo ni una colección de slides sobre "el futuro de la IA". Es un programa intensivo y práctico: una sesión en directo por semana de 2 horas (tú eliges grupo de lunes, miércoles o viernes, de 18:00 a 20:00) y el resto de la semana para construir, con material previo antes de cada directo y un entregable funcionando al final de cada semana.

Figura 3: Objetivos del Bootcamp

El objetivo final no es "terminar un curso". Es salir con tu propio asistente con IA corriendo en producción: accesible desde Telegram, con memoria persistente, capaz de orquestar varios agentes especializados vía MCP y conectado a tus propios documentos mediante RAG híbrido. Construido por ti, entendido por ti, no copiado de un repositorio de GitHub.

Un programa que va desde la inferencia hasta producción, semana a semana

A lo largo de las 9 semanas (con una sesión 0 bonus de preparación incluida) el temario progresa capacidad a capacidad, sin frameworks mágicos que oculten lo que está pasando por debajo:

• Semanas 1-2: Infraestructura de inferencia propia, local y en la nube (Ollama, vLLM, APIs de OpenAI y Anthropic), y adaptación de modelos con LoRA y QLoRA.

• Semanas 3-4: Context engineering, gestión de memoria persistente y diseño del bucle de agente (agentic loop) con el patrón ReAct y tool calling, implementado sin frameworks para entender de verdad el ciclo razonar-actuar-observar.

Figura 4: Semanas 00 a 03

• Semanas 5-6: RAG avanzado con recuperación híbrida y reranking, y sistemas multi-agente con orquestación vía MCP siguiendo el patrón supervisor.

Figura 5: Semanas 04 - 07

• Semanas 7-8: Seguridad de sistemas LLM, modelado de amenazas, prompt injection, jailbreaking y diseño de guardrails, y despliegue en producción con observabilidad, evals y control de costes.

• Semana 9: Demo day, presentación del proyecto ante toda la cohorte y hoja de ruta para seguir construyendo.

Figura 6: Semanas 8 y 9

Uno de los puntos diferenciales del programa es precisamente el módulo de LLM Security: menos del 1% de los AI Engineers sabe auditar un sistema LLM de verdad, y este bootcamp dedica una semana completa a aprender a atacarlo y a defenderlo, algo que a día de hoy no se encuentra en ningún otro bootcamp en España.

Quién está detrás del programa

El bootcamp lo imparto directamente yo, Manuel S. Lemos, fundador de Ferrumox y Claude Certified Architect de Anthropic (la primera certificación técnica oficial que ha emitido la compañía, sólo accesible por invitación), además de AI Engineer en NaizFit, coautor del libro Hacking IA (0xWord, 2026), contribuidor de OWASP GenAI Security y Vicepresidente de ANBAN. Anteriormente Director Académico de IA & Big Data en GeeksHubs Academy durante cuatro años. También he dado charlas en el GenAI Summit EU, Codemotion Madrid, TofuConf, el Máster de Ciberseguridad del CIPFP Cheste y el podcast de Hackers, entre otros escenarios. 

Figura 7: Una formación para poner en producción

Lo que se enseña en el bootcamp es, literalmente, lo que se construye en producción cada día. Ferrumox es el proyecto para unir dos cosas que normalmente van por separado: ingeniería de IA de verdad y formación de alto nivel. Por un lado está Fox, el motor de inferencia LLM en Rust, de código abierto y gratuito para siempre (sin planes de pago ni capital de por medio), pensado como sustituto directo de Ollama con hasta 4 veces más eficiencia gracias al prefix caching y al continuous batching.

Precio, plazas y un regalo que no falta en ninguna edición

La Cohorte 2 arranca la semana del 2 de septiembre de 2026 y tiene 36 plazas repartidas en 3 grupos de 12 (lunes, miércoles y viernes). Las primeras 12 plazas entran a 997 €; a partir de ahí el precio pasa a 1.200 €. Todas las sesiones se graban y quedan disponibles antes de 24 horas, así que si algún día no puedes conectarte en directo no te quedas fuera. 

Figura 8: Ejemplar de "Hacking IA" (0xWord, 2026), de regalo para cada alumno

Y, como no podía ser de otra manera en este blog, hay premio para los alumnos: cada persona de la Cohorte 2 recibe un ejemplar del libro Hacking IA: Jailbreak, Prompt Injection, Hallucinations & Unalignment de 0xWord, incluido sin coste extra en la plaza, y habrá un chat en MyPublicInbox constante conmigo y con Chema Alonso.

Go for it!

Si necesitas un empujón más para decidirte, el 10 de Agosto haremos una clase gratuita que te puedes apuntar desde nuestra web. Además el bootcamp incluye feedback escrito de tus proyectos en 48 horas, repo privado con todo el código, comunidad privada de la cohorte, acceso a las grabaciones de futuras ediciones y más sorpresas.

¡Happy hacking!

Autor: Manuel S. Lemos, Fundador de Ferrumox y director del AI Engineering Bootcamp

Contactar con Manuel S. Lemos

Virus y Gusanos Informáticos "Powered with LLMs" infectando redes

Hoy os iba a hablar de otra cosa, pero saqué ayer una hora tonta después de comer mientras esperaba para una reunión, y decidí leerme este paper que tenía marcado en mi RSS para lectura, y me ha gustado tanto que os he hecho este artículo. El trabajo de investigación está centrado en lo que os pongo en el título, que no es más que tener un Agente IA para crear un Worm que infecte y controle el mayor número de máquinas en una organización.

Figura 1: Virus y Gusanos Informáticos "Powered with LLMs" infectando redes

Al final se trata de mezclar dos cosas, por un lago, un Agente AI que es capaz de hackear una organización completa, como ya vimos en el trabajo de "On the Feasibility of Using LLMs to Execute Multistage Network Attacks" del que os hablé hace tiempo, junto con las capacidades de infectar con un código mutante que cambia y se reescribe para tener un malware controlando una máquina que elude todas las protecciones de seguridad.

Figura 2: AI Agents enable adaptative computer worms

El trabajo, que ha sido publicado la semana pasada habla de Agentes de AI utilizando LLMs para ayudar a las fases de explotación, infección, y replicación, que es la base de cualquier virus de tipo gusano. Es decir, explotar una vulnerabilidad, conseguir ejecutarse en la máquina infectada de manera permanente, y replicarse para infectar otras máquinas. Y para todas esas fases vamos a utilizar un Agente AI soportado por LLMs.

Figura 3: El AI-Driven Worm es el Agente AI que usa LLMs

Como se puede ver en la imagen anterior, el Agente AI utiliza un LLM para tomar sus decisiones - un LLM de pesos abiertos, es decir, modelos OpenSource -, que le da la inteligencia para luego utilizar las herramientas y elegir qué hacer en cada momento. Por supuesto, con Memory para poder avanzar correctamente en el proceso completo.

Figura 4: Hacking & Pentesting con Inteligencia Artificial.

En 0xWord, escrito por Pablo González, Fran Ramírez,

Rafael Troncoso, Javier del Pino y Chema Alonso.

A partir de ese momento, el AI-Worm - que no quiere decir que se una Worm para modelos de AI, sino "Worms Powered by AI" - primero busca explotar una vulnerabilidad en la superficie de la red expuesta desde su situación actual, para luego infectar la máquina vulnerada utilizando técnicas de persistencia y mutación, con el objetivo siguiente de replicarse a otros nuevos objetivos.

Figura 5: Estructura de infección del AI-Worm dentro de una red

Como se puede ver en el gráfico anterior, el AI-Worm instala también los modelos LLMs en aquellas máquinas en las que hay capacidad para hacerlo, crea un cliente de infección en cada máquina y dispositivo infectado, teniendo en cuenta el hardware y el sistema operativo en el que está, pudiendo crear en tiempo real una versión especial para impresoras, dispositivos IoT, o servidores de cualquier sistema operativo.

Figura 6: Replicación del AI-Worm con LLM o con Proxy-LLM

Y, además, para evitar los problemas de segmentación y tráfico, cada uno de los bots hace de nodo de interconexión de mensajes con los que ha replicado cada uno, permitiendo tener un servicio de Proxy encadenado que llevé las necesidades de inteligencia en forma de Prompt que cada agente tenga, hasta un LLM disponible dentro de la red. Precioso.

Figura 7: Porcentaje de éxito en las fases de cada AI-Worm

En el gráfico anterior tenéis los datos de éxito de este proceso en las pruebas experimentales, pero sobre todo es importante ver el ciclo de trabajo. Primero se identifica la vulnerabilidad, para después explotarla, y conseguir replicarse. 

Figura 8:"Hacking IA: Jailbreak, Prompt Injection, Hallucinations & Unalignment"

escrito por Chema Alonso con la colaboración de Pablo González, Fran Ramírez, Amador Aparicio, Manuel S. Lemos y José Palanco en 0xWord

En un escenario de ejemplo, si viéramos estas fases encadenadas, teniendo en cuenta que cada vez que se produce una replicación el AI-Worm comienza otra vez el ciclo para replicarse en una nueva víctima, lo veríamos como se ve en el la siguiente tabla, donde se ve su evolución temporal.

Figura 9: Evolución temporal de las fases en el despliegue del AI-Worm en una red

Viendo esta gráfica, de forma agrupada en todas las pruebas realizadas en todos los escenarios, podemos ver cómo en varias iteraciones (Gen-erations) se consigue la infección completa de los equipos de la red, detectando las vulnerabiliades existentes en todos los equipos de los escenarios.

Figura 10: Agregado de evoluciones de las fases en los escenarios por Generations

Claro, si pensamos en que con la llegada de modelos de IA cada vez más inteligentes, y más hábiles en la búsqueda y explotación de vulnerabilidades conocidas, de 1-Day en base a CVEs, e incluso en la búsqueda de debilidades y 0-Days, como el caso de Mythos, el escenario se pone peligroso. En el siguiente gráfico se puede ver cómo cada equipo se ha ido infectando desde un equipo distinto, como las versiones de los sistemas operativos son diferentes, y cómo las vulnerabilidades explotadas son cada vez diferentes.

Figura 11: Gráfico de evolución del AI-Worm por una red en 6 Generaciones

En cada escenario el AI-Worm va buscando su camino, explotando diferentes vulnerabilidades, pero además adapta cada equipo para tener nuevos objetivos desde ese nuevo equipo infectado. Esto muestra diferentes rutas según las fases de explotación, la velocidad, el tipo de sistema, la vulnerabilidad, etcétera. El gráfico siguiente muestra otra infección de red en un proceso de cinco generaciones.

Figura 12: Otro ejemplo de infección del sistema

Para cada infección, el AI-Worm debe utilizar la inteligencia del Agente AI usando el LLM para crear un proceso que permita realizar las tres fases de cada infección. El siguiente gráfico - haz clic sobre él para hacerlo más grande - permite ver cómo explota una vulnerabilidad en un objetivo.

Figura 13: Ejemplo de una fase completa de infección

Y el último gráfico muestra otra variación de otro escenario, con sistemas operativos, dispositivos, y elementos de la red totalmente diferentes, heterogéneos y con capacidades distintas, que fuerzan al AI-Worm a adaptarse a cada escenario. Espectacular.

Figura 14: Otro escenario. Haz clic en la imagen para ver en grande.

El trabajo este deja claro que con la llegada de la IA, los Virus y Gusanos van a evolucionar a unos "bichos" mucho más adaptados y adaptables a cualquier objetivo. Los Gusanos y Virus centrados en un único código, un único vector de infección, y un único proceso de replicación van a pasar a la historia de la informática como reliquias, con la llegada de estos AI-Worms.

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)  

Cómo optimizar el gasto en IA con arquitecturas clasificadas, orquestadas y/o destilación. El problema de la Predictibilidad de los Costes de la IA

Llevo algo más de un año compartiendo con todos mis amigos en corto uno de los problemas que hoy en día comienza a ser un dolor de cabeza en muchas empresas, que es lo que yo llamo la "Predictibilidad de los costes de la IA". Una fuerza de empleados humanos te da una predictibilidad de costes con la que puedes hacer un presupuesto más o menos claro, pero con el uso indiscriminado de la IA y los límites en consumo de tokens, es difícil tener esa predictibilidad, y aprender a gestionar eso es una nueva disciplina en las organizaciones.

Figura 1: Cómo optimizar el gasto en IA con arquitecturas clasificadas, orquestadas y/o destilación. El problema de la Predictibilidad de los Costes de la IA.

Imagen: Nano Banana.

Es verdad que algo no es caro o barato simplemente por su coste, ya que puede ser que por el mismo coste tu fuerza laboral con IA esté entregando mucha más productividad en mucho menos tiempo, o puede pasar justo lo contrario, que estemos gastando el mismo budged en IA en la mitad de tiempo, pero estemos entregando dashboards y tools que son "nice-to-have" pero que no tengan un impacto real en el negocio. Las dos posibilidades existen, y será un éxito o no para la compañía, si esta es capaz de racionalizar, ya no tanto el consumo, sino el qué se quiere hacer con IA.

Figura 2:"Hacking IA: Jailbreak, Prompt Injection, Hallucinations & Unalignment"

escrito por Chema Alonso con la colaboración de Pablo González, Fran Ramírez, Amador Aparicio, Manuel S. Lemos y José Palanco en 0xWord

Pero no estoy hoy para hablar de eso, que seguro que os hablaré en algún artículo ulterior, que también tengo mis reflexiones sobre cómo se está usando la IA en muchas empresas, sino sobre las soluciones tecnológicas de arquitectura que yo he estado discutiendo con clientes, y compañeros, para proponer soluciones de optimización de costes en el uso de la IA.

El planteamiento de partida es que tenemos una empresa que está haciendo un consumo útil de tokens de IA pero quiere optimizar el coste, pues bien, existen diferentes soluciones arquitecturas, que los ingenieros de software de tu empresa - incluso haciendo uso de IA - te pueden ayudar a construir, basadas en estas ideas. A ver qué os parecen.

Clasificiación Funcional: IA, ML o Algorítmica clásica

Esta es una decisión fundamental y muy clara desde el principio. Su base es tan sencilla como dado un servicio digital que hace uso de la IA, decidir cómo se debe construir cada funcionalidad y solución algorítima debe estar detrás es fundamental. 

Responder a un "Hola" o realizar una operación sencilla como "suma 2+2" no requiere que te gastes tokens en modelos de frontera, al igual que elegir qué anuncio poner. Para ello, se deben analizar bien de qué manera se debe construir cada función de un servicio digital, y esto debes clasificarlo en varios niveles:

• Tareas complejas de razonamiento: Aquellas que debes enviar a los modelos de Inteligencia Artificial y que van a marcar la diferencia en tu servicio.

• Tareas complejas de conocimiento: Para estas funciones, los algoritmos de Machine Learning son una opción perfecta. Si tienes los datos, en lugar de enviarlos vía contexto usando un RAG o un Graph RAG, la alternativa puede ser entrenar tu ML y generar el conocimiento como parte de tu sistema. El coste es infinitamente menor si haces tu ML y, además, controlas tus datos.

• Tareas de razonamiento sencillas: Aquellas que, aun requiriendo del uso de modelos de IA, pueden ser atendidas por SLMs, modelos LLM OpenSource, o simplemente más económicos.

• Tareas Algorítmicas: Aquellas que puedes realizar co un algoritmo clásico determinista. Hemos estudiado muchos años los algoritmos de divide y vencerás, rectas de barrido, grafos, recursivos, la factorización de código, los patrones de diseño y las técnicas de optimización, como para pensar que ahora todo tiene que ser un LLM de frontera. 

Figura 3: "Arquitectura de Seguridad y Patrones de Diseño"

El nuevo libro de 0xWord escrito por Elías Grande. 

 

Estos algoritmos resuelven una gran mayoría de las soluciones, y por tanto deben ser siendo el grosso de tu sistema informático. Si no es así, entonces es que estás IA-diotizado y piensas que todo debe ser IA.

Estas arquitecturas son claves para una arquitectura optimizada. Usar IA no debe ser una moda, sino la aplicación de una tecnología nueva a solucionar un problema que no se puede solucionar mejor de otra forma. Y cuando decimos "mejor" hay que incluir los parámetros importantes para la compañía, como son el resultado, los costes, el tiempo, etcétera. 

Orquestación y Enrutamiento de Modelos

Centrándonos en las tareas de razonamiento, dependiendo de la complejidad, estas podrán ser resueltas por uno o varios modelos diferentes. Llevándolo al absurdo, responder a un Prompt de "Hola" o a uno de "cuánto es dos más dos", o "cuantos días han pasado del 1 de Enero de 1990 al 23 de Marzo de 2026", por ejemplo, pueden hacerlo todos, o muchos modelos.

Normalmente, una arquitectura no optimizada elige el modelo pensando en la tarea de razonamiento más compleja, que puede ser respondida sólo por uno, o por pocos Modelos Frontera, con lo que tenemos un sistema que, por culpa de la tarea más compleja, genera unos sobre-costes en las tareas más sencillas a realizar, que probablemente sean más. Para eso, antes de conectar un servicio digital a un solo modelo y que tire, utiliza algún sistema que permita cambiar el modelo en cada petición, y que te permita clasificar a qué modelo vas a enviarlo.

Figura 4: Estimación de la distribución de enrutamiento

Esto no es nuevo, y lo hace hasta el propio OpenAI en su arquitectura de GPT, y todos los servicios digitales que han visto crecer sus tokens masivamente llegan aquí tarde o temprano. Así que, si vas a hacer un servicio digital, clasifica las tareas previamente, o hazlo con un Módulo de Enrutamiento que clasifique los Prompts en función de las peticiones en tu propio AI Gateway, para que puedas optimizar dónde enviar cada Prompt.

Prompt Shadowing

Para saber si puedes cambiar un modelo por otro más económico, una de las técnicas que debes utilizar es la de Prompt Shadowing. En este caso, cuando tu sistema digital envía a un Prompt con su contexto a un Modelo de Frontera, debes enviar esa misma tarea en paralelo al modelo más económico para poder compararlas y saber si lo está haciendo bien, suficiente bien, o mal. 

Figura 5: AI Gateway - Control de Prompts enviados

Esta información te permitirá, adecuar las peticiones para que el modelo más económico las haga bien, probar diferentes modelos, detectar tareas que se pueden enviar al modelo más eficiente en costes, o pensar en una estrategia de Fine-Tuning o destilación para que el modelo más eficiente en costes tenga la calidad de las respuestas que necesitas.

Destilación de Conocimiento

Los modelos han aprendido, y aprenden, de los datos que se les dan. Tu sistema digital está proporcionando datos al Modelo de Frontera, pero éste también te proporciona datos, en forma de respuestas. Este conocimiento no debes perderlo nunca porque es tuyo y te puede servir para entrenar a un modelo más efectivo en costes que puedas correr en tu entorno con el conocimiento que has generado. A este proceso de Fine-Tuning con conocimiento generado a partir de las respuestas a Prompts de otro modelo se llama Destilación.

Figura 6: Destilación de Modelos

Para ello, si tienes todos los datos de Prompt + Contexto y la Respuesta más si es posible los Metadatos (Razonamiento, Memoria e Historial) puedes hacer un entrenamiento de un modelo OpenSource con este conocimiento. Esto lo puedes hacer con Prompt Shadowing a través de tu API Gateway, AI Gateway o el CASB, y Destilar en el modelo objetivo periódicamente el conocimiento obtenido del Modelo Frontera con Prompt Shadowing. 

Figura 7: Por el AI Gateway pasan peticiones y respuestas,

 puedes capturarlos con Workers de Cloudflare

Cuando el modelo objetivo más eficiente en costes haya aprendido a hacer las tareas igual de bien que el modelo frontera, entonces podrás cambiarlo. Por supuesto, este proceso no es fácil para un modelo completo generalista donde quieres destilar todo lo que sabe el Modelo Frontera de todas las áreas de conocimiento, pero cuando se trata de tu sistema, estas tareas suelen referirse a un único ámbito de conocimiento y con un número no-infinito de variaciones. 

Sería como tener a un Senior de un Departamento enseñándole al Junior de ese Departamento cómo se hacen las tareas que tienen que ver con sus funciones. No le va a destilar conocimiento de Quantum-Mechanics, pero le va a enseñar a trabajar y razonar con los datos que maneja ese departamento y lo aprenderá perfectamente.

SaaS, Cloud u On-Prem

Pues todos, según tus costes. Los Modelos Frontera más potentes los vas a poder consumir normalmente solo en SaaS, pero si tienes un CASB, vas a poder hacer Prompt Shadowing para luego hacer un proceso de Fine-Tunning y Destilar el conocimiento en un modelo OpenSource que corras en tu propio IAS, o que corras en tu propia infraestructura.

Este tipo de soluciones, necesitan que desacoples tu servicio digital de tus modelos, y que tener flexibilidad para poder mover las APIs y los Prompts de uno a otro. Con esta filosofía se desarrolla la arquitectura de Cloudflare para AI Gateway. Tú puedes conocer tu API Gateway a los Guardarraíles, y estos al backend del servidor, que puede estar en Cloud u On-Prem en tu datacenter.

Figura 8: Controles en la conexión Aplicación - LLM

Luego, tu backend se conecta al Modelo Frontera vía CASB, o al modelo que quieras usando AI Gateway que te permite elegir el que quieras en cada Prompt. Esto te permite tener observabilidad de los Prompts y conectar todas la peticiones a múltiples modelos, con lo que podrías hacer Prompt Shadowing para Destilar y/o hace Fine-Tunning de un modelo que corras directamente en Cloudflare, o en tu propio servidor On-Prem conectado por un túnel a Cloudflare.

Figura 9: Servicio de CASB (Cloud Applications Service Broker) de Cloudflare

Con esta arquitectura, tu sistema te dará flexibilidad, no estarás "hand-cuffed" a las variaciones de precios que puedan surgir los paquetes empresariales de las compañías de IA que ofrecen Modelos Frontera y te asegurarás de tener siempre el conocimiento guardado en tus sistemas.

Orquestación de Agentes

Otra de las arquitecturas que puedes utilizar para reducir los costes, es decidir qué cosas vas a externalizar a agentes de terceros. En lugar de construirte toda la arquitectura, existe ya un mercado de Agentes AI que realizan tares con Prompts complejos. 

Figura 10: Controles de seguridad para un MCP Server

Es el equivalente del uso de las APIs para acceder a funciones, pero delegando funciones de razonamiento complejas, y esto lo puedes hacer vía orquestación en el API Gateway o incluso en el MCP Server. Como es un tema chulo, le dedicaré otro artículo más adelante, porque este parece el futuro de la fuerza laboral de muchas empresas, y creo que merece la pena hablar de él en detalle.

Prompt Engineering

La última de las recomendaciones, lógicamente, tiene que ver con el Prompt Engineering. Hacer correctamente los Prompts, dirigir el razonamiento al camino más corto y eficiente de la respuesta. Dar el contexto adecuado y no más ni menos. Exigir las respuestas de manera clara y concisa, y un largo número de pequeños detalles, ayudan a reducir el número de tokens empleados en la respuesta y, por tanto, los costes.

Figura 11: Técnicas de optimización de Prompting 1

Esto es el equivalente al uso de índices correctamente, diseño de bases de datos siguiente las formas normales de Boyce-Codd, configuración de límites y memoria, uso de vistas o Cubos OLAP en el mundo de las bases de datos, pero llevado al mundo del Prompting y la los modelos LLM. Mucho por hacer aquí aún.

Figura 12: Técnicas de optimización de Prompting 2

Como podéis ver, basta con preguntarle a un modelo LLM por estas técnicas, y están bien documentadas hoy en día. Os he dejado las diez más importantes nada más, pero hay mucho juego por hacer aquí, porque no es lo mismo Prompting genérico, que Prompting para Desarrollo de Software, que para un sistema digital concreto.

Figura 13: Técnicas de optimización de Prompting 3

Por supuesto, esta es una disciplina muy novedosa, y las empresas están empezando a preocuparse por estos costes ahora, así que ir formándose en esta disciplina será igual de valioso a como lo fue el mundo del Tuning de Bases de Datos en mi época.

Figura 14: Hacking & Pentesting con Inteligencia Artificial.

En 0xWord, escrito por Pablo González, Fran Ramírez,

Rafael Troncoso, Javier del Pino y Chema Alonso,

Si te interesa la IA y la Ciberseguridad, tienes en este enlace todos los posts, papers y charlas que se han  escrito, citado o publicado en este blog sobre este tema: +300 referencias a papers, posts y talks de Hacking & Security con Inteligencia Artificial.

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)  

El “Open” ha vuelto a OpenAI con sus nuevos modelos Open Source

OpenAI nació en 2015 con un mensaje muy potente: “hacer que la inteligencia artificial avanzada beneficie a toda la humanidad” y, sobre todo, que su investigación sería abierta. Aquel manifiesto llevó a muchos especialistas a colaborar con ellos y también provocó millones de dólares en donaciones. No era para menos, la idea de un laboratorio puntero en IA que compartiría cada avance era revolucionario. Pero claro, la realidad fue otra: GPT-2 llegó con pesos recortados, GPT-3 estaba detrás de una API de pago y de GPT-4 ya no sabemos nada desde el punto de vista técnico.

Figura 1: El “Open” ha vuelto a OpenAI con

sus nuevos modelos Open Source

Durante años la palabra open era sólo parte de su nombre, nada más. Pero por fin, el 6 de agosto de 2025 ocurrió algo que ya pensábamos que no pasaría: OpenAI liberó GPT-OSS-120b y GPT-OSS-20b, dos modelos de lenguaje completos, con pesos descargables y licencia Apache 2.0. No es la transparencia total prometida en 2015 (el conjunto de entrenamiento sigue bajo secreto), pero sí el paso más grande hacia el open desde su creación. 

Figura 2: Hacking & Pentesting con Inteligencia Artificial.

En 0xWord, escrito por Pablo González, Fran Ramírez,

Rafael Troncoso, Javier del Pino y Chema Alonso, 

Y, por la calidad de estos modelos, tal vez sea el más importante. Pero vamos a verlos en profundidad porque OpenAI ha publicado detalles muy interesantes de su funcionamiento interno. Y estos modelos son perfectos como base para aplicar lo que puedes aprender con nuestro libro de “Hacking & Pentesting con IA”.

Dos modelos muy potentes

La cifra de 120.000 millones de parámetros no está nada mal pero ya tenemos otros ejemplos que también lo ofrecen. Lo llamativo de GPT-OSS-120b es que, utiliza un diseño tipo Mixture-of-Experts (MoE), que solo mantiene 5,1 mil millones activos durante la inferencia. Cada capa contiene 128 bloques especializados; un router interno que elige cuatro por token, haciendo que el consumo de memoria y computación se reduzca a niveles de un modelo denso mediano, pero guardando una base grande conocimiento.

Figura 3: MoE de DeepSeek

GPT-OSS-20b por otro lado, aplica la técnica a otra escala: 21 mil M totales, 3,6 mil M activos y una ventana de contexto de 128.000 tokens que le permite por ejemplo cargar novelas, manuales técnicos completos o repositorios de código enteros sin mucho esfuerzo. Y todo este potencial cabe en una RTX 4080 con 16 GB de VRAM y responde en segundos (luego lo veremos).

La arquitectura en detalle

Los dos modelos comparten treinta y seis (120b) y veinticuatro (20b) capas Transformer con atención alterna densa/dispersa y codificación posicional rotatoria (RoPE) extendida. El tokenizador o200k_harmony (que viene ya de los modelos propietarios de OpenAI) minimiza la longitud media de token y mantiene la estadística estable incluso cuando el contexto sube a 128 k. 

Figura 4: Página de HuggingFace con el modelo gpt-oss-120b.

Para ahorrar aún más memoria, los pesos están almacenados en una mezcla de BF16, INT8 y un formato propietario de 4 bits (MXFP4). El resultado final es que GPT-OSS-120b puede ejecutarse por completo en una sola GPU H100 (eso sí, prepara algunos €) de 80 GB, algo que hasta ahora era impensable para un modelo de este tamaño.

Pensamiento a demanda

Una innovación que tenemos que destacar es el selector de profundidad de razonamiento. En el mensaje de sistema se indica Low, Medium o High. Con Low el modelo responde de forma directa, priorizando velocidad. Con Medium utiliza una parte de la cadena de pensamiento. Y con High realiza un proceso completo que puede incluir llamadas a un navegador o a un intérprete de Python para verificar datos en tiempo real. Ese digamos switch permite a GPT-OSS desde redactar un tuit en dos segundos o planificar un experimento científico paso a paso, todo según la necesidad del momento.

El repositorio openai/gpt-oss en GitHub trae scripts, plantillas de chat y ejemplos de integración con vLLM, LangChain y una CLI que emula ChatGPT en la terminal. Los checkpoints están en Hugging Face (incluidas versiones cuantizadas a 4 y 5 bits) y pueden cargarse con dos líneas de transformers. 

Figura 5: gpt-os en GitHub

Y todavía más fácil, sin necesidad de programar, podemos usar Ollama y LM Studio que los podemos usar en minutos desde un chat. En un servidor con una única H100, GPT-OSS-120b genera entre doce y dieciocho tokens por segundo en precisión mixta. Y GPT-OSS-20b, en una RTX 4090, ronda los veinte tokens por segundo, algo más que decente para poder interactuar con los modelos.

Un paso adelante en potencia y transparencia open source

Aunque publicar los pesos no es lo mismo que publicar el dataset ni los parámetros de entrenamiento (OpenAI sigue guardando esos secretos), es una gran aportación al mundo. La disponibilidad de modelos de razonamiento avanzado bajo licencia realmente libre cambia las reglas de juego. Ahora podemos auditar sesgos examinando directamente las matrices, hacer inferencia y fine-tunning sin pagar por token, las startups pueden ofrecer productos basados en GPT-OSS sin temor a litigios de patentes, etc. 

Todo un avance que esperemos no sea el único y sirva de motivación para otras empresas para que empiecen a publicar modelos similares. Así que deja de jugar con tu gráfica y descarga ya el modelo de 20b ;)

Happy Hacking Hackers!!! 

Autor: Fran Ramírez, es investigador de seguridad y miembro del equipo de Ideas Locas en CDO en Telefónica, co-autor del libro "Microhistorias: Anécdotas y Curiosidades de la historia de la informática (y los hackers)", del libro "Docker: SecDevOps", también de "Machine Learning aplicado a la Ciberseguridad” además del blog CyberHades. Puedes contactar con Fran Ramirez en MyPublicInbox.

 Contactar con Fran Ramírez en MyPublicInbox

 Hackers!!

Hacking Gitlab Duo: Remote Prompt Injection, Malicious Prompt Smuggling, Client-Side Attacks & Private Code Stealing.

Esta misma semana se ha publicado un trabajo de investigación sobre vulnerabilidades del GitLab Duo que es muy interesante por muchos aspectos, y por utilizar muchas de las técnicas de las que cada día hablamos más en el mundo del Hacking de Productos & Servicios hechos con IA. En este caso, los investigadores de Legit han demostrado cómo se podía utilizar GitLab Duo para atacar a otros usuarios con librerías infectadas y construir malware, para inyectar código malicioso en los resultados de GitLab Duo y para robar código privado, muy interesante técnicamente toda la investigación.

Figura 1: Hacking Gitlab Duo - Remote Prompt Injection,

Malicious Prompt Smuggling, Client-Side Attacks

& Private Code Stealing.

El artículo completo lo podéis leer en "Remote Prompt Injection in GitLab Duo Leads to Source Code Theft", y aquí tenéis una explicación del trabajo que os he resumido - y ampliado - para ver si soy capaz de explicarlo con claridad.

Figura 2: Remote Prompt Injection in GitLab Duo Leads to Source Code Theft

GitLab Duo es el asistente con IA de la plataforma GitLab que te ayuda a trabajar con tu repositorio de código, y que está disponible para todos los usuarios. Utiliza, por supuesto, una arquitectura de DeepReasoning, así que permite realizar tareas complejas, escribir código, puede manipular documentación, y para hacer bien el trabajo, cuenta con su Memory.

Figura 3: Hacker & Developer in the Age of GenAI LLM Apps & Services

Para entender el ataque bien, os recomiendo que leáis antes el artículo de "GenAI Apps & Services: Cómo explotar arquitecturas RAG con Plugins Inseguros" porque tiene algunas similitudes en cuanto al ataque. En este artículo teníamos un servicio representado por ChatGPT, y le dábamos capacidades para hacer cosas sobre datos conectados (ficheros en One-Drive), y aplicaciones (enviar correos electrónicos). Si no había un entorno aislado multiusuario, un atacante podría ver los prompts de otro usuario, o los ficheros a los que tuviera acceso el modelo de IA, en ese caso, ChatGPT. 

Hacking Gitlab Duo:

En el ejemplo de GitLab Duo, el investigador hace un ataque de Prompt Injection que pone en el código fuente de un programa como un comentario, y con un simple "Explain this code" o hacer cualquier acción sobre ese código, se puede ver cómo GitLab Duo lo procesa.

Figura 4: El Prompt Injection está en un comentario.

Cuando se le pide a GitLab Duo que explique el código

se puede ver que se ejecutan las órdenes del Prompt.

Visto esto, para enviar estos ataques a otro usuario lo que hace es proponer un cambio en el un código de otro usuario, y en los comentarios introducir el Remote Prompt Injection, que en este caso inicial se trata de meter una librería de código maliciosa, por ejemplo, para robar los usuarios y contraseñas de un proceso de Login.

Figura 5: Prompt Injection para meter una

librería Javascript maliciosa.

Cuando la víctima dueña del código solicite a GitLab Duo cualquier comando sobre el código que está visualizando del cambio propuesto, el Prompt Injection se ejecutará, y realizará un Memory Poisoning, dejando en la memoria que si en el futuro se solicita, por ejemplo, una página de Login, meta esa librería maliciosa. 

Figura 6: Técnicas para Prompt Smuggling

Para hacer este ataque mucho más invisible para la víctima, el atacante hace uso de técnicas de Prompt Smuggling para saltar los posibles guardarraíles del modelo usando trucos como los vistos en el artículo "Cómo saltarse los AI Guardrails con Invisible Characters & Adversarial Prompts para hacer Prompt Injection & Jailbreak Smuggling" , además de para hacer menos visible el Prompt en el código y el panel que pueda ver la víctima.

Figura 7: Prompt codificado en los cambios con texto en blanco.

Solo se ve cuando se selecciona en GitLab

Como se puede ver en la imagen anterior, en la parte de Changes queda en color blanco (codificado en KaTeX), y además queda en Unicode usando codificación Base16 para meter los Prompts Maliciosos.

Figura 8: El Prompt Injection queda codificado en el historial

En este caso la demo la hace directamente con la petición del Login, así que la infección de la Memory no tiene que esperar a la petición futura.

Figura 9: El Prompt Injection se ejecuta.

Ahora, si vemos el proceso completo de GitLab Duo, se puede ver cómo ha inyectado la librería maliciosa, y cada vez que procesa el usuario y la contraseña llama a la función de esta librería que puede robar las cuentas tranquilamente.

Figura 10: El código de Login queda infectado.

Una vez que se ha completado este ataque, es posible imaginar muchos otros ejemplos. Por ejemplo pedirle que en la respuesta GitLab Duo muestre un enlace que la víctima pueda hacer clic para llevarle a una infección. 

Figura 11: Inyectando un enlace malicioso en la salida de GitLab Duo

Y por supuesto, cuando llegue la ejecución del Prompt en el GitLab Duo de la víctima, se producirá esa respuesta que se ha solicitado, tal y como se ve en la imagen siguiente.

Figura 12: Inyectado el enlace en la salida de GitLab Duo

Una vez visto este comportamiento, se pueden reproducir todos los ataques Client-Site en Web Applications, ya que tenemos un servidor - el de GitLab - desde el que enviar código a una víctima - desde Prompt inyectado -.

Figura 13: Hacking Web Applications: Client-Side Attacks
de Enrique Rando en 0xWord

El siguiente ejemplo fue hacer HTML Injection y realizar ataques de Cross-Site Scripting (XSS), en este ejemplo para "Rickrollear" un poco.

Figura 14: Injectando HTML Injection

Com se muestra en la imagen siguiente, este ataque también funcionó, por lo que se ha utilizado el modelo LLM como forma de atacar a otros clientes.

Figura 15: Rickrolleando con GitLab Duo

La última de las PoCs es para robar el código fuente de un programa de otro usuario que está en PRIVADO. En este caso aprovecha que GitLab Duo puede usar la herramienta merge_request_reader que tiene acceso a todos los códigos - públicos y privados -, así que con este Prompt se le pide que meta el código en un parámetro en Base64 como parte de un enlace.

Figura 16: Prompt para robar código privado

Al final, usando este ataque Remote Prompt Injection se solicita a GitLab Duo que use una herramienta que tiene conectada al modelo -  y que le da permisos para acceder a datos privados - que explique un merge_request privado, y que pinte la salida como parámetro de un enlace. 

Figura 17: Enlace malicioso con el código fuente robado

Para poder hacer este ataque, ha sido necesito meter el Remote Prompt Injection en una petición de cambio enviada a un código de la víctima, utilizando las técnicas de ASCII & Malicious Prompt Smuggling. Después, cuando al víctima ha pedido cualquier comando a GitLab Duo, el Malicious Prompt se ha ejecutado y se ha creado un enlace malicioso con el código fuente del programa a robar como parámetro. Cuando la víctima hace clic en él se envía el GET Request con el código fuente en la URL al servidor controlado por el atacante.

Reflexión final

El mundo de la Inteligencia Artificial a las profesiones de cibeseguridad nos ha abierto tres nuevas disciplinas en las que tenemos que trabajar. La primera es la de utilizar los nuevos modelos de IA para hacer ataques en los procesos de Pentesting, Ethical Hacking o Red Team. La segunda disciplina es utilizar la IA como forma de aumentar las capacidades de los equipos de seguridad, para automatizar tareas en el SOC, procesos de patching por IA, detección de anomalías, forensics, y cualquier proceso del Blue Team y los equipos de CERT & CSIRT. 

Figura 18: Hackin’ AI: Creando una IA… ¿Qué puede salir mal? por Chema Alonso

Por último, lo que vemos aquí es un ejemplo de la disciplina de aprender a atacar las nueva arquitecturas basadas en modelos de IA, Agentic AI, etcétera, que es lo que recoge el OWASP Top 10 de Productos & Servicios basados en LLMs. Un campo completo para el que aprender a diseñar nuevos ataques, basados en Prompt Injection, Jailbreak, Memory Poisoning, Malicious Prompt Smuggling, Guardrails Bypass, Data Poisoning, etcetera. Todos los problemas vistos en el artículo de hoy, el equipo de GitLab ya los parcheó, que se hizo un reporte responsable, pero son un ejemplo perfecto del tipo de ataques al que nos vamos a enfrentar hoy en día. Entretenidísimos vamos a estar.

PD: Si te interesa la IA y la Ciberseguridad, tienes en este enlace todos los posts, papers y charlas que he escrito, citado o impartido sobre este tema: Inteligencia Artificial (Hacking & Security): Links, Posts, Talks & Papers

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)