Un responsable de logística que nunca ha escrito una línea de código monta una herramienta interna durante un fin de semana. Sigue los repartos, avisa a los clientes por correo y tiene un panel que le gusta al consejo. Lo que antes le llevaba a un equipo tres meses salió en dos días, y desde el punto de vista del negocio el resultado es muy bueno. Nadie ha preguntado qué hay dentro.
Parar el desarrollo con IA sería absurdo, y decirle a esta gente que vuelva a las hojas de cálculo también. Conocen su sector mejor que cualquier contratista, y estas herramientas les permiten actuar sobre ese conocimiento. El problema es más concreto: quien construyó la app ve la pantalla, y la pantalla funciona. El interior es otra cosa.
Qué hay dentro de la caja
Veracode probó más de 100 modelos de lenguaje en 80 tareas de programación y encontró que el 45% de las muestras de código no superó las pruebas de seguridad e introdujo vulnerabilidades del OWASP Top 10. Java fue el peor caso, con un 72% de fallos. La actualización de octubre de 2026 es la primera mejora apreciable desde 2025, y aun así solo sube la tasa media de aprobado del 56% al 62%. Los modelos mejoraron a la hora de escribir código que funciona. No mejoraron tanto a la hora de escribir código seguro.
Los fallos que llegan a producción suelen ser aburridos. En 2025 un investigador descubrió que las apps generadas con Lovable salían a menudo sin una política de seguridad a nivel de fila (Row Level Security) en sus bases de datos, lo que permitía a cualquiera, sin autenticarse, leer o escribir tablas. Se le asignó el CVE-2025-48757 (Lovable lo disputa y sostiene que cada cliente es dueño de la configuración de su app). El análisis del investigador contó 303 endpoints vulnerables en 170 proyectos, alrededor del 10% de los analizados.
En febrero de 2026, Wiz encontró abierta de par en par la base de datos de Moltbook, una red social para agentes de IA construida íntegramente a base de prompts. Una clave de Supabase estaba en el JavaScript del cliente y, sin políticas RLS, daba acceso completo a 1,5 millones de tokens de autenticación de API y 35.000 direcciones de correo. En julio de 2025, Wiz ya había mostrado que en Base44 bastaba un identificador de app no secreto para registrar una cuenta dentro de la app privada de otra persona. Base44 lo corrigió en menos de 24 horas, que es la forma correcta de gestionarlo, y también un recordatorio de que el fallo estuvo ahí hasta que alguien miró.
Ahora cualquiera puede lanzar un ataque
Las mismas herramientas rebajan el listón del otro lado. En agosto de 2025, Anthropic informó de un delincuente que usó Claude Code contra al menos 17 organizaciones, entre ellas centros sanitarios y organismos públicos, para robar datos y redactar las exigencias de rescate, que a veces superaron los 500.000 dólares. El mismo informe describe a un vendedor de ransomware con "solo conocimientos básicos de programación" que vendía malware construido con IA por entre 400 y 1.200 dólares.
Tres meses después, Anthropic describió una campaña respaldada por un Estado contra unos treinta objetivos en la que la IA hizo entre el 80 y el 90% del trabajo y los humanos se limitaron sobre todo a aprobar el siguiente paso. Tuvo éxito "en un pequeño número de casos". Es su propia herramienta la que se usó mal, y fue Anthropic quien lo contó.
El panorama general apunta en la misma dirección. El Global Threat Report 2026 de CrowdStrike registra un aumento interanual del 89% en las operaciones de adversarios con IA, un tiempo medio de propagación del cibercrimen de 29 minutos y un caso más rápido de 27 segundos. El M-Trends 2026 de Mandiant sitúa el tiempo medio de explotación en unos menos siete días, es decir, que la explotación empieza muchas veces antes de que exista un parche. El grupo de inteligencia de amenazas de Google informó de un zero-day (un bypass de doble factor) que cree desarrollado con IA, preparado para explotación masiva e interrumpido antes de que ocurriera. Y el estudio de brechas de IBM de 2026 concluye que una de cada cuatro brechas maliciosas fue posible con ayuda de IA, con un coste medio de 6 millones de dólares.
Y luego están los frigoríficos
El 11 de octubre de 2026, alguien se coló en los controladores de refrigeración de supermercados franceses. El ministro de Economía francés dijo que unos 700 de los 10.000 supermercados del país resultaron afectados, y las crónicas hablan de temperaturas de hasta 50 °C y de un ciclo de desescarche forzado. La alerta CERTFR-2026-ALE-012 del CERT-FR nombra los controladores Danfoss AK-SM y AK-SC y las consolas xweb de Copeland y Dixell, y su primera instrucción es desconectarlos o filtrar el acceso, porque tener una interfaz de administración en internet va contra las buenas prácticas.
El 2 de noviembre, NBC informó de una segunda oleada: comida echada a perder y subidas de temperatura en Suecia, Países Bajos, Bélgica, Irlanda, Luxemburgo y Estonia, con 13 tiendas SuperValu entre ellas. Según Cybersecurity Dive, Shadowserver seguía contando 1.173 instancias de Copeland XWEB Pro y Evo expuestas a internet días después.
Ninguna fuente fiable dice que la IA interviniera en estos ataques. Los traigo por lo que muestran. Un dispositivo del que nadie se encargaba de la seguridad, con una consola web que nadie recordaba que era accesible, en un sitio donde una brecha cuesta dinero real en cuestión de horas. Cambia el controlador por un panel de administración que tu responsable de logística generó el sábado pasado y la historia es la misma. Lo que ha cambiado es quién puede construir la pieza y quién puede encontrarla.
El fin del análisis de riesgos estático
Muchos proveedores venden ya la "evaluación dinámica de riesgos", y cada uno la define un poco distinto. El término no está normalizado en ciberseguridad. Viene de los servicios de emergencia y de la seguridad laboral (la formación de seguridad privada enseña la misma expresión a los vigilantes que tienen que juzgar el riesgo sobre la marcha según cambia la situación), donde significa evaluar el riesgo según cambian las condiciones, en lugar de rellenar un formulario antes. Las normas de seguridad describen la idea con otras palabras, y la mejor establecida es la monitorización continua del NIST. La SP 800-137 la define como "mantener un conocimiento continuo de la seguridad de la información, las vulnerabilidades y las amenazas para apoyar las decisiones de gestión de riesgos de la organización". Lo importante es la última parte: la monitorización existe para alimentar decisiones de riesgo. El Cybersecurity Framework 2.0 del NIST dice que gestionar el riesgo cibernético "debe ser un proceso continuo", y la SP 800-37 añade la autorización continua y la gestión del riesgo casi en tiempo real.
El enfoque clásico es un ejercicio de un momento concreto. Listas activos, amenazas y vulnerabilidades, puntúas probabilidad e impacto, decides qué tratar, y el resultado se queda en un registro hasta la siguiente revisión o hasta que cambia algo grande. El NIST es justo con su propio método. La SP 800-30 dice que las evaluaciones de riesgo "no son simplemente actividades puntuales", y el control RA-3 pide actualizarlas con la frecuencia que defina la organización o tras cambios significativos. En la práctica, el registro envejece mientras el sistema se mueve. La SP 800-37 plantea el contraste ella misma: llama a la reautorización "la determinación de riesgo estática, de un único momento" y dice que los sistemas pueden pasar "de un proceso de autorización estático y puntual a un proceso de autorización continua, dinámico y casi en tiempo real".
A eso me refiero con dinámico. Los activos, la exposición y las amenazas se reevalúan según cambian, idealmente en cada despliegue y con cada nueva pieza de inteligencia de amenazas, y el resultado alimenta decisiones (bloquear esta versión, aislar aquel servicio) en lugar de un informe. Incluye las apps de las que nadie en TI sabía nada.
Las agencias que escriben las guías dicen lo mismo. En junio de 2026, las agencias de ciberseguridad de los Five Eyes advirtieron de que las hipótesis de riesgo cibernético "pueden quedar obsoletas en meses, no en años" y de que los defensores deben usar IA igual que los adversarios. Cuando el tiempo medio de explotación es negativo y un proyecto de fin de semana puede estar en producción el lunes, un documento escrito en enero describe en marzo una organización que ya no existe.
También cambia quién hace la primera línea de defensa. Un SIEM recoge más de lo que un equipo humano puede leer. La encuesta de Vectra de 2023 a 2.000 analistas encontró SOC que recibían 4.484 alertas al día y no podían atender el 67%, y eso era antes de que los atacantes tuvieran agentes. Microsoft dice que procesa más de 165 billones de señales al día, y su Digital Defense Report 2026 es tajante sobre la consecuencia: "Los ataques ejecutados a velocidad de máquina solo podrán afrontarse con defensores que se muevan a la misma velocidad".
El documento de ENISA de julio de 2026 sobre la ciberseguridad en la era de la IA de frontera va más lejos. Dice que los SOC "deben adoptar más automatización" y recomienda un triaje asistido por IA con revisión humana, con el objetivo de detectar y responder en minutos de un solo dígito. Anthropic da el mismo consejo en su informe sobre la campaña de espionaje, donde pide a los equipos de seguridad que prueben la IA en la "automatización del Centro de Operaciones de Seguridad".
Yo lo leo como un reparto del trabajo, y lo llevaría más lejos. La IA debería ser la primera línea en las dos mitades del trabajo: llevar el SOC (clasificar, correlacionar, contener lo evidente) y mantener viva la evaluación de riesgos, reevaluando la exposición cada vez que un despliegue, un CVE nuevo o una alerta nueva cambian el panorama. Las personas no deberían leer el flujo. Deberían recibir una lista corta de hallazgos e incidencias, ya clasificados y explicados, y tomar las decisiones que exigen criterio: escalados, impacto en el negocio, el caso raro. Un SOC solo de personas con un registro de riesgos anual es una cola que los atacantes pueden dejar atrás.
Las piezas de código abierto ya están llegando. Los finalistas del AI Cyber Challenge de DARPA encontraron 54 de 63 vulnerabilidades sintéticas y corrigieron 43, y OpenSSF, de la Linux Foundation, aloja ahora OSS-CRS, un marco para encontrar y corregir errores con LLM que salió de esa competición. OCSF, el esquema común para alertas de seguridad, también es un proyecto de la Linux Foundation. Juntas son la fontanería de un SOC con IA al frente, y la primera línea en sí sigue siendo algo que cada equipo tiene que construir y afinar.
DevSecOps, STRIDE y código seguro por defecto
El sitio más barato para corregir una vulnerabilidad es antes de que exista. DevSecOps significa que el pipeline hace ese trabajo en cada commit: análisis estático, escaneo de dependencias y de secretos, y pruebas dinámicas contra una build en ejecución, con la publicación bloqueada si fallan. El principio Secure by Design de CISA lo resume en una línea: la ciberseguridad pertenece al diseño del producto, no a un parche posterior. El Secure Software Development Framework del NIST (SP 800-218) lo convierte en una lista de prácticas contra la que se puede auditar.
El modelado de amenazas te dice qué probar. STRIDE hace seis preguntas sobre cada componente y flujo de datos: si alguien puede suplantar una identidad, manipular datos, negar haber hecho algo, leer lo que no debe, tumbar el servicio u obtener privilegios que no le corresponden. Pásalo por una app generada típica. Una clave de Supabase en el navegador sin políticas por fila suspende en divulgación de información y en elevación de privilegios antes de que hayas mirado una línea de código. Lleva una hora y habría detectado lo de Moltbook.
Con agentes en el circuito, añade LLM06 de OWASP, Excessive Agency. Un agente con más funcionalidad, más permisos o más autonomía de la que su tarea necesita es un riesgo, la escriba quien la escriba.
Un sandbox para la IA, y otro para lo que construye
Trata a un agente de programación como a un contratista al que todavía no has comprobado. Se ejecuta con acceso limitado al sistema de archivos, una lista de redes permitidas y nada que pueda tocar más allá del proyecto. El sandboxing de Claude Code funciona así: el sistema operativo impone el límite alrededor de los comandos que ejecuta el agente, lo que acota qué puede leer o a qué hosts puede llamar un prompt manipulado.
Las apps que la gente construye con IA necesitan el mismo trato una vez que están en marcha. Parte de que el código tiene fallos y diseña el entorno para que un fallo no se convierta en una brecha. Zero trust, tal como lo define el NIST en la SP 800-207, significa que no hay confianza implícita por la posición en la red: cada petición se autentica y se autoriza, el acceso es de mínimo privilegio y la app solo alcanza lo que se le ha dado de forma explícita. Una herramienta interna hecha por alguien que no es desarrollador debería poder leer la tabla que necesita y nada más, y no debería ser accesible desde internet salvo que haya una razón.
La regulación va en la misma dirección. Las obligaciones de notificación del Reglamento de Ciberresiliencia de la UE, en su artículo 14 (alerta temprana en 24 horas, notificación en 72), se aplican desde el 11 de septiembre de 2026, y el resto del reglamento lo hará desde diciembre de 2027. Si vendes software con elementos digitales en la UE, "no sabíamos que era vulnerable" se está volviendo caro.
Atácate tú primero
Un atacante con un agente de IA necesita minutos, así que el defensor debería haber hecho ya el mismo ejercicio. Para ello usamos dos herramientas de código abierto.
Strix ejecuta agentes autónomos de pentesting contra tus aplicaciones. Hacen el reconocimiento, intentan la explotación y validan cada hallazgo con una prueba de concepto que funciona antes de reportarlo, lo que deja el informe en cosas que de verdad funcionan. Corre en local dentro de un sandbox de Docker con el modelo que elijas, de modo que la herramienta se queda en tu entorno (tu código sí llega al proveedor del modelo que elijas).
RedAmon cubre el lado del red team. Mapea la superficie de ataque en un grafo, la explota desde un sandbox Kali con puntos de aprobación humana entre pasos, y abre pull requests que corrigen lo que encuentra. Esos puntos de aprobación importan: la persona sigue decidiendo qué puede hacer el agente a continuación.
Ambas herramientas hacen daño real en las manos equivocadas, así que la regla es simple. Apúntalas solo a sistemas que sean tuyos o que estés autorizado a probar.
Los propios modelos son un obstáculo. Los comerciales están hechos para ser prudentes con este trabajo. Anthropic dice que sus modelos de disponibilidad general "tienen salvaguardas cibernéticas conservadoras que bloquean la mayor parte del trabajo de ciberseguridad", y su página de soporte añade que el análisis de malware o la validación de exploits "pueden verse interrumpidos por nuestros clasificadores de seguridad" (la revisión de código seguro y el modelado de amenazas siguen funcionando). Anthropic tiene un Cyber Verification Program con niveles para trabajo defensivo y de red team autorizado, pero el acceso es por solicitud, y las organizaciones inscritas tienen que permitir la retención de datos para que Anthropic vigile el uso indebido. OpenAI tiene un programa equivalente, Trusted Access for Cyber, que da a los usuarios verificados versiones de los modelos con menos fricción en el trabajo de seguridad de doble uso.
Con los casos de más arriba, son políticas razonables. También son una dependencia. Un pentest en mitad de un trabajo no debería pararse porque un clasificador no vio con buenos ojos un exploit, y el código y los hallazgos de un cliente no deberían tener que viajar a un tercero para empezar.
La alternativa es que el equipo de seguridad aloje su propio modelo. Nuestra recomendación es un Mac con mucha memoria unificada. Apple vende el Mac Studio con hasta 512 GB (M5 Ultra, 1,2 TB/s de ancho de banda de memoria) y el MacBook Pro con hasta 128 GB (M5 Max, 614 GB/s). La memoria decide qué modelo cabe, y el ancho de banda decide lo rápido que responde. Para dar una idea de escala, gpt-oss-120b de OpenAI funciona en una sola GPU de 80 GB, y gpt-oss-20b en 16 GB. La otra vía es una caja con GPU como la DGX Spark de NVIDIA, con 128 GB de memoria unificada, 273 GB/s de ancho de banda y la cifra de NVIDIA de modelos de hasta 200.000 millones de parámetros en una unidad. Es un buen equipo dedicado, pero el techo del Mac es más alto en memoria y en ancho de banda. También hay modelos abiertos entrenados para este trabajo, como Foundation-sec-8B de Cisco (Apache 2.0). Elijas lo que elijas, rige la misma regla: tú decides quién lo usa, qué se registra y adónde va el código.
Lo que hacemos en IBERANT
En IBERANT la seguridad es parte de la ingeniería, no una revisión al final. Construimos con DevSecOps y STRIDE en nuestros propios pipelines y escribimos código seguro por defecto. Alojamos aplicaciones en entornos protegidos zero trust, también en Claybridge Apps, la plataforma de código abierto que desplegamos sobre tu propia infraestructura. Hacemos pentesting y ejercicios de red team con IA, con Strix y RedAmon y con ingenieros sénior leyendo cada resultado. Y ayudamos a las empresas que ya tienen aplicaciones hechas con IA en producción: un inventario de lo que está corriendo, un plan de hardening y las correcciones.
Si alguien de tu empresa montó algo en un fin de semana y ahora guarda datos de clientes, hablemos.