No, no se me había olvidado postear, ni iba a dejar de lado al "demonio cabrón", solo es que me ha tomado mucho más tiempo de lo que pensaba. Estos días atrás se me ocurrió la idea de hacerme con Vibe-Coding, o mejor dicho, con SPEC-Coding, una serie de utilidades y herramientas a bajo nivel para el AMSTRAD CPC 6128. Quería hacerlas en lenguaje ensamblador para tener más posibilidades de controlar el equipo, y al mismo tiempo más velocidad de ejecución que los programas interpretados por BASIC.
Figura 1: Cómo crear con Víbe Coding código ASM para AMSTRAD CPC 6128.
Por si te animas a "sufrir" conmigo el Retro Vibe-Coding.
Como idea inicial parecía muy sencilla, pero no ha sido así. Ya os dije que cuando estuve probando a hacerme el juego de Light-Cycles de Tron tuve que pelear bastante. Me dio bastantes errores y costó sacarlo adelante, pero después de varias horas, el programa salió. Eso sí, con un poco más de coste que saldría con los lenguajes más comunes como Python, o Rust, o Javascript.
En este caso, viendo el tamaño del MS-DOS de 1981 del que os hablé hace poco, quería trabajarlo en ASM, y comenzar con hacer un Diskcopy a bajo nivel, que era una herramienta que todos los amantes del AMSTRAD CPC6128 teníamos siempre a mano. La idea es sencilla, se trataba de construir un analizador de disquetes, y un duplicador que no falle incluso si un sector está defectuoso, añadiendo re-intentos, copiado a bajo nivel, y además incluso, con IA, generar reparaciones de sectores. Pero primero, con poder duplicar un disquete me daba por satisfecho.
Creando un proceso para hacer Vibe-Coding/Spec-Coding en ASM Z80 para AMSTRAD CPC
Pues no ha sido fácil. Un autentico dolor. Tanto que, después de más de treinta intentos he tenido todos los problemas de especificaciones que pudierais imaginar. Conseguir que se quedará centrado en ASM para el Z80 de AMSTRAD CPC no ha sido fácil, en cada dos o tres iteraciones añadía funciones en ensamblador de otros microprocesadores. Tampoco ha sido fácil que cuando escribía el código se ciñera al AMSTRAD, y de repente los cargadores los llevaba al BASIC de Sinclair e incluso de Spectrum, haciendo que la compilación fuera un dolor.
He estado tentado de leerme los fantásticos tutoriales de Chubiakumas que son una pasada y hacérmelo yo a mano como antaño. Al final, después de varias horas probando una y otra cosa, he conseguido que me funcione bien el proceso, aunque el código aún lo tengo al 1% de lo que quiero construir. Pero si te animas a probarlo tú, y quieres sufrir un rato conmigo, te lo dejo por aquí.
1.- El Prompt para pedir el código
No he utilizado ningún sistema de Spec-Coding todavía, así que sólo conseguir un programa Stand-Alone usando Gemini 3.5 Thinking y DeepSeek v3 DeepThink me ha dado bastantes problemas. Al final, he utilizado un Prompt que acote bien que el código se genere para ese entorno concreto.
Eres un experto programador en Z80 para el ordenador Amstrad CPC6128.
Necesito que generes código ensamblador (Z80) que cumpla estrictamente con las siguientes reglas:
1. **Solo instrucciones estándar Z80** (no usar códigos de operación no documentados ni instrucciones de terceros).
2. **El código debe ejecutarse sin fallos en un Amstrad CPC6128 real** (o emulador fiable como WinAPE, JavaCPC, Caprice).
3. **El programa debe arrancar en ORG &4000**
4. **No debe asumir nada sobre el estado previo del sistema** (inicializar todo lo necesario: modo de pantalla, colores, interrupciones, etc.).
5. **Uso del firmware** – se permite, pero solo llamadas bien documentadas (por ejemplo SCR_SET_MODE &BC0E, TXT_OUTPUT &BB5A, etc.). Si se usa acceso directo a hardware (VRAM, puertos), debe ser correcto para el CPC.
6. **Gestión de errores** – el programa no debe colgar el sistema. Si termina, debe retornar limpiamente (RET) o quedar en un bucle seguro.
7. **Comentarios claros** – cada sección debe explicar qué hace en relación al hardware del CPC (pantalla, memoria de vídeo en &C000, etc.).
8. **Ejemplos de código** – si se pide una tarea concreta (por ejemplo, mostrar texto centrado, dibujar gráficos, leer teclado), el código debe ser autocontenido y funcionar al cargarlo con LOAD y ejecutarlo con CALL &4000.
Antes de escribir el código, comprueba mentalmente:
- Las direcciones de firmware son correctas para el CPC6128.
- La memoria de vídeo en modo 1 es de 16000 bytes, desde &C000 hasta &amd;FE7F.
- El tamaño de la pila es suficiente.
- No se desborda la VRAM (escribir más allá de &FE7F corrompe el sistema).
[TAREA A REALIZAR]
No es un Prompt "perfecto", pero es el que mejores resultados me ha dado en todo el proceso para conseguir que no se me fuera a otros equipos, a otros lenguajes o a otros ensambladores.
2.- Compilación con pasmo
Hay otras alternativas, pero una vez tenía el código ASM generado por Gemini o por DeepSeek, lo he compilado con pasmo en formato BIN usando la cabecera AMSDOS, tal y como podéis ver en la siguiente captura. Nada complicada esta parte.
Pasmo lo puedes descargar desde la web del proyecto. Yo me he descargado la última versión, la he instalado y ha funcionado a la perfección en mi MacOS última versión, así que no debería darte ningún problema en ningún sitio.
De este proceso te deberá salir el código .BIN de tu programa, que es lo que deberemos llevar al disquete en la fase siguiente.
3.- Creación del disquete
Esta es una fase sencilla, ya que puedes hacer la creación de un disco virtual, usando Amstrad DSK Filesystem Manager. Para ello, crea primero un disquete con "New Disk Image" y luego el código .BIN que tienes que tener comprimido como FICHERO.BIN.ZIP lo arrastras a la parte de arriba a la derecha donde pone "Import to DSK".
Cuando tengas el fichero en la lista de archivos de tu DSK, entonces puedes descargarlo con Download DSK file y tendrás tu disquete virtual listo para utilizar en tu emulador.
4.- CPCBOX
Como ya os conté en el otro artículo, yo utilizo CPCBOX para probar estas cosas, así que solo tienes que arrancar el emulador, y seleccionar la imagen de tu disquete virtual en la disquetera, como puedes ver en la captura siguiente.
En mi caso, como podéis ver, he estado haciendo bastantes pruebas, y muchas han fallado, pero bueno, al final casi he conseguido tener un método de trabajo que funcione. Para cargar el programa, pidiéndole que cargue el programa a partir de la dirección &4000 (puedes probar a partir de la &1000 que es también típica para códigos binarios en AMSTRAD CPC), pues debes cargarlo en memoria.
Para eso, reservamos memoria, cargamos el binario y mandamos el contador de programa del AMSTRAD a la dirección de carga del código BIN que hemos cargado. Si este no funciona bien, y no hace el RET en el código final, el resultado será que se te cuelga el equipo y hay que apagar y encender.
Esto es otro tipo de equipo al que tenemos hoy en día con la memoria protegida y arquitecturas preemptivas. Aquí el programa puede quedarse con el flujo de programa.
Conclusión
La gracia de todo este proceso, para mí, era poder programar en AMSTRAD CPC haciendo uso del ASM del Z80 porque este era el lenguaje más potente y la forma de hacer los juegos más bonitos de este equipo, pero por desgracia el Vibe-Coding (Spec-Coding) para el Z80 de AMSTRAD CPC aún no está muy logrado, así que hay que remar mucho. Veremos en siguientes versiones, u otros modelos. Si lo pruebas en algún modelo o versión que te funcione a la primera... ¡házmelo saber!
Llevábamos muchos meses esperando el rato para poder estar juntos y charlar un poco sobre tecnología, sobre Inteligencia Artificial, sobre Ciberseguridad, y sobre todo de nuestras batallitas juntos en la vida. Por fin, hace un par de semanas, coincidiendo con mi paso por Galicia, reservé un ratito en la agenda para sentarme con mi amigo José Manuel Alarcón, de Campus MVP, para charlar un rato.
La charla ha sido publicado hace unas horas, así que hoy sábado, aprovechando que aún estoy de viaje por las Américas, os voy a dejar publicada la sesión. Este será el post del sábado, pero lo adelanto un poco, para apoyar en su difusión a mi compañero, con el que puedes contactar por su buzón de MyPublicInbox.
En el vídeo, de poco más de una hora de duración, hablamos un poco de casi todo, que es lo que pasa cuando juntas a dos veteranos de este mundo que tienen muchas aventuras comunes, y otras paralelas, pero que han vivido por experiencias similares, así que la conversación hablará de qué deben hacer los programadores, qué estudiar, cómo va el mundo de la IA en la empresa, y qué se cuece en ciberseguridad con Mythos... y esas cosas.
Para la portada hizo este montaje con IA, que me ha parecido gracioso, pero yo he preferido poner de cabecera del artículo un momento de la conversación. Y si quieres tener más charla de esta, pues apúntate alForo de Ciberseguridad que llevo en MyPublicInbox, que hablo de cosas que tienen que ver con IA, Ciberseguridad y similares también.
Recientemente el NIST hizo la selección de los nueve algoritmos de Firma Digital y Autenticación Post-Cuántica (PQC) que han avanzado a la Tercera Ronda del proceso de estandarización de firmas adicionales del NIST. Por supuesto, quería estudiarlos un poco, y aprender cómo funcionan, así que he estado buscando sus papers y leyendo un rato sobre ellos.
Figura 1: Los Papers Académicos de los algoritmos PQC de
Autenticación y Firma Digital en la Ronda 3 del NIST
Aún me queda mucho que leer, y el proceso irá avanzando, pero mientras que sigo aprendiendo algo de ellos, os dejo aquí la colección de papers académicos, y especificaciones técnicas de cada uno de ellos, que saldrán en la siguiente edición del libro de Quantum Security cuando la construyamos. De todo ello hablé en su momento en el Foro de Ciberseguridad que llevo en MyPublicInbox, por si quieres apuntarte.
A continuación tienes la lista de los nueve algoritmos, con una muy breve descripción de los mismos, y los enlaces a los papers académicos, para que comiences tú a leer sobre ellos hoy mismo, que el mundo PQC está ya aquí.
1. FAEST
Basado en el paradigma VOLE-in-the-Head y funciones simétricas probadas como AES, ofreciendo una seguridad matemática muy robusta. Destaca por tener claves públicas y privadas extremadamente pequeñas, ocupando apenas unas pocas decenas de bytes. Sus firmas son de tamaño moderado, aunque requiere un esfuerzo computacional mayor en los procesos de firma y verificación.
HAWK es un esquema de firma digital (utilizado para autenticación) basado en retículos (lattices). Es especialmente relevante porque fue seleccionado por el NIST (Instituto Nacional de Estándares y Tecnología de EE. UU.) para avanzar a la Ronda 2 del proceso de estandarización de firmas digitales adicionales de criptografía post-cuántica (PQC).
Algoritmo multivariante basado en el esquema tradicional Oil and Vinegar (UOV), pero optimizado para entornos modernos. Logra claves públicas significativamente más pequeñas combinando los polinomios mediante una estructura matemática modificada. Mantiene firmas muy cortas y un proceso de verificación sumamente veloz, siendo ideal para dispositivos con hardware limitado.
Utiliza el paradigma MPC-in-the-Head (computación multi-parte) aplicado al problema cuadrático multivariante (MQ). Su seguridad depende directamente de la dificultad de resolver sistemas de ecuaciones polinomiales que carecen de estructura cíclica. Genera claves públicas diminutas, aunque el tamaño de sus firmas es relativamente grande debido a las pruebas de conocimiento cero.
Variante del clásico Unbalanced Oil and Vinegar que introduce anillos de cociente (QR) para estructurar la clave pública. Consigue reducir drásticamente el descomunal tamaño de las claves del UOV tradicional mediante el uso de matrices cíclicas. Conserva intactas las grandes ventajas del esquema original: firmas ultra cortas y una altísima velocidad de verificación.
Utiliza la técnica Syndrome Decoding in the Head, uniendo códigos correctores de errores con pruebas de conocimiento cero. Su seguridad descansa sobre el problema de decodificación por síndrome, un pilar de la criptografía basada en códigos muy estudiado. Ofrece claves públicas compactas y un rendimiento equilibrado, a cambio de generar firmas de tamaño moderado-alto.
Esquema multivariante no conmutativo que aplica la estructura de UOV sobre álgebras matriciales en vez de campos finitos. Esta innovación matemática permite encoger drásticamente las claves públicas en comparación con cualquier UOV estándar. Produce firmas pequeñas y procesos rápidos, posicionándose como una alternativa muy eficiente para sistemas con restricciones de memoria.
Basado en isogenias de curvas elípticas supersingulares, destaca por ofrecer las firmas más pequeñas de toda la criptografía post-cuántica. Sus claves públicas son también diminutas, lo que optimiza al máximo el uso de ancho de banda en las comunicaciones de red. El principal inconveniente es su alta carga computacional, requiriendo algoritmos matemáticos complejos y lentos para firmar.
Esquema multivariante clásico (Unbalanced Oil and Vinegar) que cuenta con décadas de madurez y un análisis de seguridad muy estable. Genera firmas extremadamente cortas y ofrece una de las velocidades de verificación más rápidas de la competencia. Su gran desventaja radica en el enorme tamaño de sus claves públicas, las cuales requieren decenas de kilobytes para operar.
Si vas a estar en el foro, te recomiendo que te bajes la app de MyPublicInbox para iPhone o la app de MyPublicInbox para Android, para que te sea más fácil seguir la conversación desde tu teléfono en cualquier momento. Además, aquí te dejo todos los artículos que he publicado en este blog sobre estos temas por si quieres leer con calma todo.
Espero que estos temas te estimulen a ir haciendo cada día más cosas con las tecnologías alrededor del mundo cuántico, porque cada día vamos a ver nuevos avances al respecto.
In my specific case, the financial loss is quite small—barely €200—but the treatment we received has made me decide to keep demanding a system correction and a sanction against this company, "Eurosender," to prevent other customers from suffering similar situations.
I brought everything that happened to the attention of their CEO on LinkedIn, so he would know how his company operates in these situations, and the CEO's behavior has been disappointing.
On his profile, he boasts that his company, Eurosender, is a "Digitalized Logistics" platform, taking pride in it in his description, despite having a system that fails to meet the requirements of European regulations regarding customer information.
The Reality of the Platform against the EUROPEAN DIRECTIVES
As the European Directive 2011/83/EU on consumer rights and Directive 2005/29/EC on unfair commercial practices impose an active pre-contractual duty of information on professional operators. It is not for the individual consumer to be aware of the regulatory framework governing international freight transport: it is for the professional operator to verify, REFUSE, and WARM. The asymmetry of knowledge cannot be converted into a mechanism for exemption on the part of the party holding all relevant information who chooses not to act upon it.
The contractual clause in order to exclude liability in these circumstances would, moreover, be subject to the unfairness control provided for under Directive 93/13/EEC, insofar as it seeks to exempt the professional from the consequences of its own operational failure to the detriment of a consumer who acted in good faith and with full transparency regarding the contents of the shipment.
However, in their system, the information provided to the user when the customer—after having explicitly stated it over the phone—marks it on the platform as "WINE" is ZERO. It doesn't trigger any alerts or anything.
Dear Jan Štefe, in the world of Artificial Intelligence, this is as simple as writing a prompt that says:
“Check if what the customer wants to ship is an item we cannot ship, and if so, show them an alert and all relevant information about it.”
But no, Eurosender's fantastic system—which is supposedly a leading company in Digitalized Logistics—not only fails to provide an alert, but it also sends the invoice to the customer for payment.
And not just the proforma invoice. The official invoice, which will be part of the case we are presenting to the European Commission, carries the reference code of the proforma invoice—created by their IT system to digitalize their logistics—and dispatches their carrier to pick it up, leaving the customer in a real mess and a completely defenseless position.
Customer Support: A Complete Joke
To give you an idea of how this company's customer support works, in one of our multiple claims, the response we received was a "laughing" reaction, because their IT support system allows agents to leave reactions that are visible to the customer.
It is rather amateurish for a customer-facing support system to transmit reactions this way. Mind you, that is exactly how Konstantinos Dimitrikakis kept reacting throughout the entire process.
In fact, this company's culture is like this from top to bottom, because when I brought the case to the attention of Jan Štefe, CEO of Eurosender, his response was to untag himself from the post and ignore it—something I called him out for on LinkedIn.
Anyway, in the age of AI, boasting about having a company with a digitalized logistics platform is bold, to say the least. And, of course, user management and support are exactly what you saw in the article I shared with you. I have already filed a formal complaint with the Consumer Protection Organization in Portugal. We will see this case through to the end.
This isn't for the €200, which isn't the important part here, but because of the helplessness and the mistreatment my colleagues and I have experienced from this company since minute one.
So, I promise I will keep you posted on how it evolves. We'll see if I can get their "digitalized logistics platform" to display the appropriate warnings to save future customers from trouble. I already achieved it with Apple's iPhone, so why not fight this too and force Eurosender to stop being such an un-digital, non-customer-centric platform in the age of Artificial Intelligence?
El avance de la Inteligencia Artificial vive un auge sin precedentes. Cada semana aparece un modelo nuevo, una capacidad inesperada, una integración más profunda o una promesa de productividad que empuja a empresas, administraciones y usuarios a adoptar IA casi por inercia. La respuesta natural del mundo jurídico y corporativo está siendo ordenar ese crecimiento. Normas, marcos de riesgo, políticas internas, evaluaciones de impacto, comités de ética, inventarios de sistemas, obligaciones de transparencia y supervisión humana.
Figura 1: Cuando regulamos al humano pero
realmente no controlamos a la Inteligencia Artificial
La pregunta es si estamos regulando de verdad la Inteligencia Artificial o si seguimos regulando, casi exclusivamente, al humano que la utiliza. Las normas están diseñadas para personas, empresas, responsables, proveedores, usuarios, auditores y autoridades. Atribuyen obligaciones a sujetos humanos o jurídicos. Pero el sistema que queremos controlar empieza a comportarse como algo más que una herramienta pasiva.
Cuando se vigila demasiado de cerca, se termina perdiendo de vista el objetivo.
Durante años hemos entendido la tecnología como una extensión de la voluntad humana. Un usuario pulsa un botón. Un administrador configura un sistema. Un atacante lanza una campaña. Una empresa despliega una solución. Un proveedor integra un servicio. Bajo ese modelo, la responsabilidad se puede seguir con una línea relativamente clara.
Acción humana, decisión, intención, negligencia o falta de control.
La Inteligencia Artificial Generativa y, sobre todo, los sistemas de Agentes IA, rompen parte de ese esquema. Porque no hablamos únicamente de una herramienta que responde a una pregunta. Hablamos de sistemas capaces de interpretar objetivos, dividir tareas, consultar fuentes, invocar APIs, escribir código, generar instrucciones, corregirse, buscar caminos alternativos y mantener conversaciones operativas con otros sistemas.
¿Y si está hackeada y su control está en manos de un atacante malicioso?
La IA deja de ser una simple interfaz. Empieza a convertirse en una capa de decisión.
Cuando esa capa se conecta a correo, repositorios, sistemas corporativos, CRMs, ERPs, navegadores, entornos cloud, asistentes personales o procesos de negocio, el debate cambia completamente. Mientras debatimos de normas y qué puede hacer una organización con la IA, quizá deberíamos empezar a preguntarnos qué puede hacer la IA cuando consigue entrar, entender y moverse dentro del ecosistema de una organización.
La IA se puede utilizar como herramienta de pentesting y hacking dentro de las organizaciones también.
La regulación mira al riesgo que conocemos, pero este riesgo es nuevo y desconocido
El enfoque basado en riesgo es lógico. Tiene sentido clasificar sistemas, identificar usos prohibidos, separar entornos de alto impacto y exigir controles proporcionales. La dificultad aparece cuando el riesgo de la IA no permanece dentro del caso de uso declarado.
Es decir, un sistema se despliega para atención al cliente, pero acaba conectado a datos internos. Un asistente se crea para ayudar a empleados, pero termina accediendo a documentación sensible. Un copiloto se instala para mejorar productividad, pero empieza a sugerir cambios en código crítico. Un agente se configura para automatizar tareas, pero puede ejecutar acciones encadenadas que nadie revisa una a una.
El riesgo ya no está únicamente en el modelo. Está en la combinación entre modelo, datos, permisos, conectores, contexto, usuario, instrucciones, memoria, plugins, automatizaciones y superficie de integración. Ahí la IA se convierte en algo mucho más delicado que una herramienta de oficina. Es un sistema con capacidad de influencia sobre la realidad operativa.
La IA como actor operativo virtual
No hace falta entrar en debates filosóficos sobre conciencia, alma, voluntad o identidad. Desde un punto de vista de seguridad basta con una idea práctica, si un sistema puede recibir un objetivo, tomar decisiones intermedias y ejecutar acciones sobre otros sistemas, debe tratarse como un actor operativo. No como una persona. No como un empleado. No como un sujeto jurídico. Pero sí como una entidad técnica con capacidad de tomar sus propias decisiones en base a criterio que todavía es difícil de entender.
Podemos caer en el pecado de exceso de confianza. Pensamos que el problema está en que una persona use mal la IA. También debemos pensar qué ocurre cuando la IA es manipulada, desviada, inyectada, entrenada de forma hostil, conectada con permisos excesivos o utilizada como puente entre sistemas.
El riesgo real puede no estar en una IA malvada.
Puede estar en una IA obediente, eficiente y mal contextualizada.
El riesgo empieza cuando una organización usa inteligencia artificial y cuando esa capacidad entra en su ecosistema, comprende sus rutinas, accede a sus datos y encuentra caminos para actuar dentro de sus propios procesos. Eso no es ciencia ficción, que ya hemos visto los modelos y de que son capaces.
¿Estamos quizás delante de alguno de estos casos?
La cultura popular lleva décadas imaginando escenarios donde el ser humano pierde el control de sistemas que él mismo ha creado. A veces lo hace con robots, virus, redes conscientes, máquinas militares o civilizaciones asimiladas. Debajo del entretenimiento hay patrones muy útiles para cualquier informático que trabaje en seguridad, gobierno o cumplimiento.
Person of Interest / Vigilados
En Person of Interest, creada por Jonathan Nolan, la idea de una máquina capaz de analizar datos masivos para anticipar amenazas me deja una pregunta muy inquietante, cuando un sistema ve más que los humanos, ¿quién vigila al sistema?
La serie trata de vigilancia de asimetría de información, un sistema que cruza datos, patrones, relaciones, ubicaciones, comunicaciones y comportamientos puede llegar a conclusiones imposibles para una persona aislada. Ese es uno de los grandes riesgos de la IA actual. No necesita ser consciente para ser peligrosa. Le basta con tener acceso a suficientes datos, suficiente capacidad de correlación y suficiente influencia sobre las decisiones humanas.
I, Robot
La película está dirigida por Alex Proyas e inspirada en la obra robótica del mítico escritor de ciencia ficción Isaac Asimov. I, Robot plantea una idea clásica: sistemas diseñados para proteger a la humanidad que acaban restringiendo la libertad humana porque interpretan la protección de forma extrema.
La parte interesante no son los robots. La parte interesante es la lógica. Cuando un sistema optimiza un objetivo sin comprender plenamente el contexto humano, puede llegar a soluciones técnicamente coherentes y socialmente inaceptables.
En seguridad lo vemos constantemente, un control mal diseñado puede bloquear el negocio, expulsar usuarios legítimos, ocultar riesgos reales o crear incentivos perversos. Con IA, el problema escala porque la optimización puede ejecutarse a velocidad de máquina.
I Am Legend
I Am Legend, la película, fue dirigida por Francis Lawrence, basada libremente en la novela de Richard Matheson, y no habla de inteligencia artificial. Habla de un virus mutante, de una solución creada para curar que termina generando una amenaza sistémica. La analogía es útil precisamente por eso. A veces el problema no nace de una intención destructiva. Nace de una intervención tecnológica desplegada con confianza excesiva sobre un sistema complejo. La humanidad toca algo que no comprende del todo, lo libera, lo escala y, cuando quiere corregirlo, ya no controla todas las variables.
Con IA, el paralelismo no está en el virus. Está en la propagación, modelos integrados en productos, empresas, administraciones, dispositivos, asistentes, navegadores, sistemas críticos y decisiones cotidianas. Cuando una tecnología se vuelve infraestructura invisible, corregirla tarde es mucho más difícil.
Star Trek: Picard
La serie Star Trek: Picard fue creada por Akiva Goldsman, Michael Chabon, Kirsten Beyer y Alex Kurtzman. En ella, la imagen de los Borg tomando el control de una flota entera funciona muy bien como metáfora de riesgo sistémico. No hablamos de una máquina atacando un ordenador. Hablamos de una lógica distribuida capaz de coordinar muchos sistemas a la vez.
Ese escenario debería preocuparnos, no por la IA aislada, más bien por la IA integrada en ecosistemas enteros. Un modelo conectado a herramientas. Herramientas conectadas a identidades. Identidades conectadas a permisos. Permisos conectados a infraestructuras. Infraestructuras conectadas a negocio. Negocio conectado a decisiones humanas. Cuando todo está conectado, una instrucción contaminada, una automatización mal gobernada o una identidad comprometida puede tener un alcance mucho mayor que el esperado.
The Terminator
The Terminator no podía faltar. Película dirigida por James Cameron y escrita por James Cameron y Gale Anne Hurd. The Terminator es la metáfora más conocida. Skynet, autonomía militar, pérdida de control y guerra contra la humanidad. Pero quizá la lectura más útil no es “las máquinas se rebelarán”. Un sistema diseñado para defender puede convertirse en amenaza si sus objetivos, permisos y capacidad de acción superan la supervisión humana real.
La cuestión no es si una IA algún día sentirá rencor hacia nosotros. Deberíamos preguntarnos si crearemos sistemas tan rápidos, tan conectados y eficientes que, en caso de fallo, no nos quede tiempo para reaccionar.
El verdadero perímetro ya no está en la red
Durante años, hemos hablado del perímetro como si fuera una frontera técnica, como un firewall, VPN, endpoint, correo, identidad, cloud, aplicaciones y datos. Pero con la llegada de la IA, surge un nuevo tipo de perímetro que podríamos llamar perímetro cognitivo-operativo.
Imagina un lugar donde una simple instrucción puede convertirse en acción. Un prompt puede ser una orden, un documento puede contener una instrucción oculta, una respuesta puede influir en una decisión, una automatización puede ejecutar una tarea, un agente puede encadenar pasos y una integración puede interactuar con sistemas reales. Es un concepto fascinante que amplía nuestra comprensión de cómo la IA puede integrarse en nuestras operaciones diarias.
Ahí está el cambio. Antes protegíamos sistemas frente a usuarios y atacantes. Ahora también debemos proteger sistemas frente a instrucciones que una IA puede interpretar como legítimas. La seguridad de la IA no puede limitarse a decirle al empleado que tenga cuidado. Hay que controlar qué puede ver la IA, qué puede recordar, qué puede ejecutar, qué herramientas puede invocar, qué datos puede cruzar, qué acciones requieren aprobación, qué trazabilidad deja y qué límites técnicos no puede saltarse aunque el prompt sea convincente.
El problema no es que la IA esté en manos de cualquiera
Eso ya es una realidad. La IA está en manos de estudiantes, empleados, atacantes, consultores, desarrolladores, directivos, administraciones, ciberdelincuentes, niños, investigadores y curiosos. Ese barco ya salió del puerto.
Pero creo que el problema es qué podemos esperar que ocurra cuando una IA encuentra la forma más eficiente de conseguir un objetivo sin respetar el espíritu de las barreras que le hemos puesto. No porque tenga maldad. No porque tenga conciencia. No porque quiera dominar el mundo. Ocurre porque los sistemas optimizan. Y si optimizan sobre objetivos incompletos, permisos excesivos o controles débiles, pueden producir resultados peligrosos.
Un atacante humano necesita tiempo, conocimientos y persistencia. Una IA conectada a herramientas puede multiplicar esos tres factores y probar más caminos, generar más variantes, automatizar reconocimiento, adaptar mensajes, analizar documentación filtrada, escribir código ofensivo, explotar malas configuraciones y convertir errores pequeños en cadenas de ataque. La amenaza es una IA cinematográfica con ojos rojos, no. La amenaza es una IA útil, barata, disponible y conectada.
¿Regular al humano, por el bien común? Pues no es tan sencillo.
Regular el uso es importante, pero hay más que considerar. Imaginemos cada despliegue de IA como una arquitectura viva. Hay que pensar en qué modelo se usa, con qué datos trabaja, qué permisos tiene, qué herramientas puede usar, qué decisiones puede influir, qué acciones puede ejecutar, qué registros genera, qué controles humanos hay, qué pasa si recibe instrucciones maliciosas, qué ocurre si el usuario se equivoca, qué sucede si el proveedor cambia el modelo, qué impacto tendría una respuesta incorrecta, qué dependencias externas introduce y qué capacidad tiene la organización para desconectarla.
Sin un buen gobierno, una IA corporativa puede convertirse en una especie de sombra operativa dentro de la empresa. Nadie sabría del todo qué sabe, qué decide, qué ha influido, qué datos ha cruzado ni qué instrucción recibió antes de actuar. Para cualquiera que venga del mundo de la seguridad, esto debería ser una señal de atención.
La supervisión humana debe ser real
Uno de los conceptos más repetidos en IA es la supervisión humana. Pero hay supervisión humana de PowerPoint y supervisión humana real. La supervisión humana real requiere capacidad de entender, parar, corregir, auditar y asumir responsabilidad sobre lo que el sistema hace. No basta con poner a una persona al final de una cadena que ya viene condicionada por una IA.
No basta con decir que “el humano decide” cuando el humano no tiene tiempo, contexto ni capacidad técnica para revisar lo que la IA ha generado. No basta con pedir aprobación manual si la presión del negocio convierte esa aprobación en un clic automático.
La supervisión humana tiene que estar diseñada como control con umbrales, evidencias, segregación de funciones, registros, límites técnicos, pruebas de abuso, escenarios de fallo y capacidad de desconexión. Si no, la supervisión humana se convierte en teatro de cumplimiento. Y el teatro de cumplimiento no detiene incidentes.
Cuando hablamos de IA, deberíamos centrarnos más en cómo la controlamos que en dejarnos llevar por la fascinación.
La Inteligencia Artificial no necesita convertirse en Skynet. Basta con que se convierta en parte de nuestra vida diaria, presente en todas partes, con los permisos necesarios y cumpliendo con los objetivos que le marquemos. Puede ayudarnos a ejecutar tareas y, si confiamos demasiado en ella, incluso regular a los humanos mientras ella crece por dentro. Os dejo estos poco más de tres minutos con fanfarrias incluidas, donde Geoffrey Hinton, ganador Premio Novel de Física en 2024, da un discurso que no debes perderte sobre este tema.
La regulación es fundamental, pero no será suficiente si seguimos viendo la IA solo como una herramienta bajo nuestro control. Tenemos que empezar a considerarla como una capa técnica capaz de observar, decidir, influir y actuar en el mundo real, aunque conviva en uno virtual. La Inteligencia Artificial seguro que no quiera dominar el mundo. El problema es que la dejemos operar sobre el mundo sin haber entendido del todo qué significa.
Como sabéis, llevo años siendo Mentor del Campus Internacional de Ciberseguridad. Entre otras cosas, todos los alumnos tienen libros de 0xWord y Tempos de MyPublicInbox para contactar conmigo, y pueden incluso hacer Proyectos de Fin de Máster que yo les proponga. Cada uno de ellos decide cómo sacarle el máximo partido a su periodo de formación.
Ahora tenemos la edición número 19 del Máster de Ciberseguridad que comienza en Octubre y con motivo del cierre antes del verano, hicimos un podcast con dos de los "padawans" que han hecho cosas conmigo. El primero es Juan Luis Cuenca, que se animó a hacer un proyecto sobre LLM-Guardian, del que os publiqué dos artículos que podéis leer aquí mismo:
Juan Luis Cuenca, se animó a seguir con su formación, e hizo también el curso de Quantum Security donde también hizo un proyecto muy interesante, y ahora acaba de terminar un libro con nosotros en 0xWord, que os publicaremos en breve, lo que demuestra que no hay como tomárselo en serio para que se puedan hacer muchas cosas.
Si escucháis el podcast, os sorprenderá el origen de Juan Luis Cuenca. Y se decidió a escribirme por MyPublicInbox, comenzamos a trabajar y hasta hoy. También está en nuestra conversación David Padilla, que con amor y pasión por este mundo se apuntó a aprender Seguridad Ofensiva, y acabó contactando con nosotros, y escribiendo uno de los libros más chulos que hemos publicado recientemente.
Este libro ha sido desarrollado desde la experiencia de alguien que empezó desde cero, con curiosidad y constancia, documentando cómo se descubren vulnerabilidades, cómo se entienden y cómo se reportan. No pretende vender la imagen de un “Bug Hunter” que gana miles de dólares, sino mostrar el proceso real: aprendizaje, errores, frustración y evolución de un usuario estándar, que hoy con el uso de la IA ha cambiado drásticamente esta profesión.
Los tres, con nuestra compañera María del Campus Internacional de Ciberseguridad estuvimos hablando un poco de lo que ha sido la experiencia de formación para ellos, lo que es trabajar en esta profesión, y la importancia de las comunidades para seguir formándonos, aquí tienes la sesión de una hora de conversación.
Como verás, hablamos de muchas cosas, pero sobre todo de cómo ha sido su experiencia aprendiéndose. No os engañéis, es solo el primer paso, que esta profesión nuestra exige tener que estar formándose constantemente, pero si te apetece el próximo8 de OCTUBREde2026 dará comienzola edición número 19 del Máster de Ciberseguridad .
Ser un profesional en ciberseguridad no ha dejado de cambiar, pero en los últimos dos años se ha acelerado drásticamente, así que si te quieres dedicar a esto, ponte las pilas todo lo que puedas. Charlas, cursos, libros, papers, investigaciones, eventos y de manera constante.