Cuando un parche que falta convierte tu software en producto defectuoso: la nueva Directiva europea de responsabilidad por productos

Publicado el agosto 14, 2026 por Simon Roses

Tiempo de lectura: 13 minutos

TL;DR

El 9 de diciembre de 2026 — dentro de unos meses — la nueva Directiva de Responsabilidad por Productos Defectuosos ((UE) 2024/2853, «PLD») empieza a aplicarse a los productos introducidos en el mercado de la UE. Por primera vez, el software es explícitamente un producto sometido a responsabilidad objetiva: aplicaciones independientes, firmware, SaaS, sistemas de IA, incluso archivos de fabricación digital. Un producto es legalmente defectuoso si no ofrece la ciberseguridad que una persona tiene derecho a esperar — y la directiva dice sin rodeos que no publicar las actualizaciones de seguridad de una vulnerabilidad bajo tu control puede convertir tu producto en defectuoso. El daño indemnizable ahora incluye la destrucción o corrupción de tus datos personales (no profesionales) y el daño psicológico certificado médicamente, desaparece la antigua franquicia de 500 €, los tribunales pueden ordenarte revelar evidencia técnica, la defectuosidad se presume cuando el caso es demasiado complejo técnicamente para el demandante, y nada de esto se puede excluir en tu EULA. No existe equivalente en EE. UU.: allí la responsabilidad por productos sigue siendo derecho estatal de daños donde «¿es el software un producto?» sigue sin resolverse, y la Estrategia Cibernética estadounidense de 2026 revirtió explícitamente el plan de la administración anterior de trasladar la responsabilidad a los fabricantes de software. Los dos mayores mercados de software del planeta conducen ahora en direcciones opuestas — y si vendes en la UE, tu programa de gestión de vulnerabilidades acaba de convertirse en tu expediente de defensa legal. Aquí va mi lectura como profesional de seguridad.

El descargo de siempre, por partida doble: no soy abogado y esto no es asesoramiento jurídico — es un profesional de seguridad leyendo un régimen de responsabilidad como un atacante lee un diagrama de red, buscando dónde cae realmente la presión. Si vendes software en la UE, habla con abogados de verdad. Lo que sí puedo contarte es qué cambia operativamente para quienes construyen y aseguran productos, porque llevo más de veinte años viendo a la industria tratar la seguridad como una promesa de mejor esfuerzo respaldada por un descargo de responsabilidad. Esa era tiene fecha de caducidad en Europa, y la fecha es el 9 de diciembre de 2026.

Llevo tiempo dando vueltas a este tema en el blog — quién asume el riesgo cuando la IA escribe tu código, por qué las empresas no tienen estrategia de IA pero sí mucha exposición a la IA, qué pasa cuando nadie responde por las acciones de un agente. La PLD es la UE respondiendo a buena parte de esas preguntas con un instrumento contundente: alguien en la cadena de suministro siempre es responsable, y nunca es la víctima.

Este post tiene un complemento. Unas semanas después de escribirlo por primera vez, entró en vigor la mitad regulatoria del empuje europeo: la aplicación de la Ley de IA para modelos GPAI, en vigor desde el 2 de agosto. Un regulador que te multa y un tribunal que te pasa la factura son dos puertas distintas — aquel post es el regulador; este es el tribunal.

Qué ha cambiado: de 1985 a 2024

La antigua directiva de responsabilidad por productos es de 1985 — el año del Amiga y del C64 en su apogeo. Se escribió para tostadoras y cortacéspedes: productos físicos, daños físicos. El software se le escapaba casi por completo. Si el código era siquiera un «producto» se debatió durante cuatro décadas, la pérdida de datos pura no era daño indemnizable, había un umbral de 500 € para reclamaciones materiales, y probar que un defecto concreto en un sistema complejo causó tu daño era cosa tuya, solo, contra la ventaja informativa del fabricante.

La Directiva (UE) 2024/2853 sustituye todo eso para los productos introducidos en el mercado desde el 9 de diciembre de 2026 (lo que se comercializó antes sigue bajo las reglas de 1985 — un régimen dual de larga cola que conviene entender). Los Estados miembros deben transponerla a su derecho nacional para esa misma fecha, y van previsiblemente tarde: a mediados de 2026, Hungría ha transpuesto, unos pocos países (Croacia, Eslovaquia, Bulgaria) tienen borradores en marcha, y buena parte de la UE no ha publicado nada. Transponer tarde no salvará a nadie — el plazo y la dirección están fijados.

Los cambios de titular, vistos desde la silla de quien construye:

El software es un producto. Punto. Software independiente, firmware embebido, apps móviles, sistemas de IA, funcionalidad SaaS y en la nube, servicios digitales conexos integrados en un producto (piensa en el servicio de monitorización de salud detrás de los sensores de un wearable), e incluso archivos de fabricación digital (el CAD que imprime la pieza en 3D). Si lo introduces en el mercado de la UE, se aplica responsabilidad objetiva — sin culpa, sin necesidad de negligencia. El demandante necesita defecto, daño y nexo causal. No tu intención, no tu proceso, no tus disculpas.

Siempre hay alguien que responde. La responsabilidad cae en cascada: primero el fabricante (que incluye al desarrollador de software); para fabricantes de fuera de la UE, el importador o el representante autorizado; en su defecto, el proveedor de servicios logísticos; incluso distribuidores y marketplaces online si no identifican a quién tienen aguas arriba en el plazo de un mes. La UE ha cerrado deliberadamente la vía de escape de «el fabricante es una sociedad pantalla en otra jurisdicción». Si desarrollas desde fuera de la UE y vendes dentro, tu representante europeo sostiene tu responsabilidad.

02-liability-cascade-graph

Figura 1. La cascada: la responsabilidad fluye del fabricante → importador / representante autorizado → proveedor de servicios logísticos → distribuidor / marketplace hasta caer en alguien alcanzable en la UE. Las sociedades pantalla de fuera de la UE no rompen la cadena, y nada de esto se puede excluir por contrato.

No puedes pactarlo fuera. La responsabilidad frente al perjudicado no puede excluirse ni limitarse. ¿El bloque en mayúsculas AS IS, WITHOUT WARRANTY OF ANY KIND al final de la licencia? En este régimen, decorativo.

La parte de seguridad: la defectuosidad ahora habla CVE

Esta es la sección por la que escribí este post. La directiva no trata la seguridad como un añadido; la incrusta en la definición legal de «defectuoso».

Un producto es defectuoso cuando no ofrece la seguridad que una persona tiene derecho a esperar, y la evaluación incluye explícitamente, entre otros factores, los requisitos pertinentes de ciberseguridad y la capacidad del producto de resistir acciones previsibles de terceros — es decir, ataques. Léelo otra vez: un ataque previsible que explota una debilidad que deberías haber corregido forma parte del análisis del defecto. El exploit no te exculpa; su previsibilidad te acusa.

01-defectiveness-tree

Figura 2. Lo que un demandante debe alinear para la responsabilidad objetiva — defecto Y daño Y causalidad — y los fallos de seguridad que vuelven el software «defectuoso»: ciberseguridad ausente, actualizaciones no publicadas, una debilidad previsible explotada o el incumplimiento de la CRA/NIS2. El daño ahora incluye datos destruidos y daño psicológico; la causalidad puede presumirse.

Tres consecuencias que pondría en la pared de cualquier equipo de producto:

1. Las vulnerabilidades sin parchear son ahora una categoría legal, no solo un elemento del backlog. La directiva responsabiliza a los fabricantes de los productos después de venderlos, en la medida en que el producto siga bajo su control — actualizaciones de software, upgrades, comportamiento en la nube y cambios derivados de machine learning cuentan. No suministrar las actualizaciones de seguridad necesarias para mantener la seguridad puede convertir por sí mismo el producto en defectuoso. El modelo mental pasa de «lanzamos, el usuario asume el riesgo» a «el producto lleva un deber de cuidado continuo mientras podamos empujarle código».

2. Tu postura de cumplimiento alimenta el análisis del defecto. La PLD encaja con la Cyber Resilience Act, NIS2 y normas sectoriales como el Reglamento de Productos Sanitarios. Incumplir requisitos obligatorios de seguridad ya no trae solo multas regulatorias — se convierte en evidencia de defectuosidad en una demanda privada de daños, y el incumplimiento de requisitos obligatorios de seguridad puede activar una presunción de defecto. La CRA te dice cómo construir y mantener; la PLD es con lo que el demandante te golpea cuando no lo hiciste. Cumplimiento regulatorio y responsabilidad civil eran carriles separados. Acaban de fusionarse.

3. La defensa de los riesgos del desarrollo tiene un agujero con forma de software. Los fabricantes conservan la clásica defensa del «estado de los conocimientos científicos y técnicos» — el defecto era incognoscible cuando lo lanzamos. Pero no te rescata de defectos que emergen de actualizaciones de software o comportamiento evolutivo de ML bajo tu control tras la venta. Y la «modificación sustancial» de un producto — que una actualización mayor puede ser — reinicia el reloj de la responsabilidad. Para un SaaS de despliegue continuo con un modelo que aprende en el bucle, el tope de 10 años es menos una línea de meta y más una cinta de correr.

La parte de privacidad: la pérdida de datos ya es daño

Aquí está la disposición durmiente. El daño indemnizable bajo la nueva PLD incluye la destrucción o corrupción de datos no usados con fines profesionales. Junto a muerte, lesiones personales — ahora incluyendo daño psicológico certificado médicamente — y daños materiales, con la franquicia de 500 € eliminada.

Piensa en lo que eso cubre en la práctica:

  • Un ransomware arrasa un NAS doméstico por una vulnerabilidad conocida y sin parchear en su firmware → las fotos familiares que cifró son daño indemnizable en una reclamación de responsabilidad objetiva contra el fabricante.
  • Un cliente de sincronización defectuoso corrompe una década de documentos personales → daño.
  • Una actualización de un hub IoT deja los dispositivos inservibles y borra los datos locales → daño.

Y esto se acumula junto al RGPD, no lo sustituye. El artículo 82 del RGPD ya da indemnización por tratamiento ilícito; la PLD añade una vía paralela donde la reclamación no es «trataste mis datos ilícitamente» sino «tu producto defectuoso destruyó mis datos«. Otra teoría del demandado, sin necesidad de probar una infracción del RGPD, responsabilidad objetiva en vez del baile de la accountability del responsable del tratamiento — y las organizaciones de consumidores pueden llevarlo como acciones colectivas. Un incidente masivo causado por un producto con cadencia de parcheo negligente ya no es solo un problema de relaciones públicas y una posible multa de la agencia de protección de datos; es una responsabilidad con forma de demanda colectiva y daños por usuario que ahora incluyen los propios datos.

La maquinaria probatoria es lo que le da mordiente. Los tribunales pueden ordenar la exhibición de documentación técnica y evidencia — logs, análisis de riesgos, informes internos de vulnerabilidades — presentada de forma accesible; si te niegas, la defectuosidad se presume. Y cuando el demandante afronta dificultades excesivas para probar el defecto o la causalidad por complejidad técnica o científica — lo que describe esencialmente a todo sistema de IA y a la mayoría del software distribuido — los tribunales también pueden presumir esos elementos. La asimetría de información que protegió silenciosamente a los fabricantes de software durante cuarenta años era un fallo de diseño, y la UE lo ha parcheado.

Un matiz más para mi rincón de la industria: la Directiva de Responsabilidad en IA está muerta — la Comisión anunció su retirada a principios de 2025 y la descartó formalmente más adelante ese año. Así que para los sistemas de IA en la UE, la pila de responsabilidad en 2026 es exactamente esta PLD (los sistemas de IA son software, el software es un producto) más los deberes regulatorios de la Ley de IA más las reglas nacionales basadas en culpa. La presunción por complejidad de la PLD se escribió prácticamente pensando en «explíquele a un juez la cadena de decisión de su modelo».

¿Hay equivalente en EE. UU.? No — y cada vez es menos equivalente

Respuesta corta: no. Respuesta larga: EE. UU. tiene responsabilidad por productos, pero nada como esto, y la brecha se ensancha a propósito.

La responsabilidad por productos en EE. UU. es derecho estatal de daños — responsabilidad objetiva, negligencia y teorías de garantía, moldeadas por el Restatement of Torts §402A y un mosaico de cincuenta variaciones estatales. No hay ley federal de responsabilidad por productos, no hay régimen armonizado al estilo europeo. Y críticamente para nosotros:

  • Si el software es siquiera un «producto» sigue sin resolverse. La tradición de responsabilidad objetiva del Restatement cubre bienes tangibles; los tribunales siguen divididos sobre apps, plataformas y algoritmos, y los fabricantes alegan que el software es un servicio precisamente para quedar fuera del terreno de products liability. La UE zanjó por ley en 2024 la cuestión que los tribunales estadounidenses siguen litigando caso a caso.
  • La doctrina de la pérdida económica bloquea casi todo lo que la PLD acaba de abrir. En la mayoría de estados, si un producto defectuoso solo se daña a sí mismo o causa daño puramente económico o de datos, la vía de daños está cerrada — te empujan al contrato, donde te espera el EULA.
  • Y el EULA funciona. Las licencias de software estadounidenses viven de descargos y límites de responsabilidad ampliamente ejecutables. El instrumento exacto que la PLD anula es el muro de carga del modelo de riesgo de la industria del software estadounidense.

Lo que EE. UU. sí tiene es un mosaico de presión: la aplicación de la Sección 5 de la FTC contra empresas con seguridad descuidada, leyes estatales de seguridad IoT como la SB-327 de California, ciberseguridad premercado de la FDA para productos sanitarios, la etiqueta voluntaria Cyber Trust Mark. Real, pero disperso, mayormente regulatorio en vez de responsabilidad privada, y nada que le dé a un consumidor una reclamación de responsabilidad objetiva por un disco duro destruido.

La trayectoria es la parte interesante. La Estrategia Nacional de Ciberseguridad de EE. UU. de 2023 (Pilar 3) proponía exactamente el movimiento europeo: trasladar la responsabilidad a los fabricantes de software inseguro, con un safe harbor para quienes demostraran desarrollo seguro. Fue el lenguaje más audaz sobre responsabilidad del software que jamás salió de la Casa Blanca — y nunca se legisló. La Cyber Strategy for America de marzo de 2026 se apartó después explícitamente de ella: desregulación, «la ciberdefensa no debe reducirse a un checklist costoso», reducción de cargas de cumplimiento, sin traslado de responsabilidad, sin safe harbor.

Así que a mediados de 2026 la divergencia es política oficial en ambos lados: la UE convirtió el software inseguro en producto defectuoso; EE. UU. decidió no hacerlo. Si vendes globalmente, construirás de todos modos al listón europeo — la misma lógica del efecto Bruselas que el RGPD — porque mantener dos posturas de seguridad es más caro que mantener una. Lo que significa que la PLD está fijando de facto el suelo global de la responsabilidad del software, desde Bruselas, sin que el Congreso de EE. UU. vote nunca.

Open source: casi a salvo, con un cable trampa comercial

La directiva excluye el software libre y de código abierto desarrollado o suministrado fuera de una actividad comercial. El mantenedor aficionado, el proyecto académico, la librería comunitaria en GitHub — fuera del ámbito, y con razón; responsabilidad objetiva sobre mantenedores no remunerados habría sido un evento de extinción para el procomún.

Pero el cable trampa es la palabra comercial. Cobra por el software, vende soporte alrededor, o monetiza datos personales más allá de lo necesario para seguridad/compatibilidad, y la exención se evapora. Y en el momento en que un componente OSS se integra en un producto comercial, el integrador asume la responsabilidad por él. El SBOM de tu producto es ahora un mapa de responsabilidad: cada dependencia que contiene es un componente por el que tú respondes en un tribunal europeo. Escribí sobre la trampa de las dependencias en código generado por IA — la PLD es ese post con un juzgado adjunto. «La vulnerabilidad estaba en una librería upstream» nunca fue gran excusa técnicamente; desde diciembre tampoco lo es legalmente.

Mi lectura: qué deberían hacer los equipos de seguridad

Quita la jerga legal y la PLD es una lista de exigencias operativas. La mayoría son cosas que los buenos equipos de seguridad ya predican; la diferencia es que «no nos dio tiempo» ahora tiene un precio con un tribunal adjunto.

1. Tu programa de gestión de vulnerabilidades es ahora tu expediente de defensa legal. Parcheo con SLA, decisiones de triaje documentadas, política de EOL y ventanas de soporte, gestión de divulgación coordinada — dejan de ser líneas de un modelo de madurez y se convierten en la evidencia que exhibirás bajo una orden de disclosure. Gestiona vulnerabilidades asumiendo que cada decisión puede leerse en voz alta ante un juez, porque bajo el régimen de exhibición, puede. Si no puedes demostrar por qué despriorizaste el bug que luego destruyó los datos de alguien, la maquinaria de presunciones hace el resto.

2. La capacidad de actualizar es una frontera de responsabilidad. «Bajo el control del fabricante» es la frase que sostiene toda la directiva. Si puedes empujar actualizaciones, cargas con el deber; cuánto tiempo prometes hacerlo es tu política de ciclo de vida de soporte. Defínela, publícala, cúmplela, y trata el fin de soporte como un evento formal, fechado y comunicado — no como un cese silencioso de parches. Y fíjate en el incentivo perverso que conviene diseñar fuera: habrá equipos tentados de reducir su capacidad de actualización para encoger la ventana de control. Respuesta equivocada — la CRA exige soporte de seguridad por su cuenta. La única salida es a través.

3. Los logs son ahora evidencia exculpatoria. La misma telemetría que llevo exigiendo para la seguridad de agentes hace doble servicio aquí: probar qué hizo tu producto, cuándo lo supiste y cómo de rápido actuaste es cómo se rebate una presunción de defecto. Un producto que no puede reconstruir su propio comportamiento no puede defenderse — ni en el SOC ni en el juzgado.

4. Los artefactos de cumplimiento cortan por los dos lados — mantenlos honestos. El trabajo de conformidad CRA, los análisis de riesgos, los modelos de amenazas: son tu defensa cuando son reales, y la Prueba A del demandante cuando son aspiracionales. Un modelo de amenazas que lista un riesgo que luego ignoraste demostrablemente es peor que no tener documento. Escribe lo que harás; haz lo que escribiste.

5. Si eres un fabricante estadounidense, no te relajes. Tu regulador doméstico acaba de retirarse, pero tu importador o representante autorizado en la UE sostiene tu responsabilidad objetiva, y te devolverá ese riesgo vía contratos, auditorías y requisitos de seguros. La cadena comercial transmitirá la presión de la PLD a través del Atlántico más rápido que cualquier regulación.

¿Y entonces qué?

Durante cuarenta años, el software ha sido la única disciplina de ingeniería de mercado masivo autorizada a vender al público productos defectuosos a sabiendas y descargar las consecuencias en un click-through. Los puentes no pueden hacerlo, los coches no pueden hacerlo, las tostadoras no pueden hacerlo. Desde el 9 de diciembre de 2026, en la UE, el software tampoco.

La lectura cínica es «más burocracia europea». No me la compro, y ya sabes que no soy un fan reflejo de la regulación. La responsabilidad objetiva no es un checklist — es lo contrario de uno. No te dice cómo construir; te dice que si lo que construyes hace daño a alguien, pagas, y te deja ingeniar tu propio camino hasta ese listón. Ese es el trato bajo el que ha operado cualquier otro campo de la ingeniería durante un siglo, y esos campos respondieron inventando la ingeniería de seguridad, no colapsando.

Mientras tanto, EE. UU. acaba de apostar en sentido contrario: que los incentivos de mercado sin responsabilidad producirán software seguro. Ese experimento lo llevamos ejecutando cuatro décadas. El resultado es la lista de CVE.

Los fabricantes que trataron la seguridad como ingeniería desde el principio tienen poco que temer de diciembre. Los que la trataron como un descargo de responsabilidad están a punto de descubrir que su EULA nunca fue un muro de carga. Parchea como si fuera un deber legal — porque en Europa, ahora lo es.

Mantente paranoico. Publica parches. Guarda tus logs.

Lecturas adicionales:

¿Preguntas o comentarios? Contacta vía:

¿Necesitas preparar tu producto para la era PLD/CRA? VULNEX ofrece:

  • Evaluaciones de seguridad de producto y aplicaciones (análisis de brechas secure-by-design, revisión de SBOM y cadena de suministro)
  • Diseño de programas de gestión de vulnerabilidades (parcheo con SLA, gestión de divulgación, política de ciclo de vida de soporte)
  • Evaluaciones de seguridad de sistemas de IA y modelado de amenazas consciente de la responsabilidad legal
  • Ejercicios de red team y automatización de seguridad

Para estrategia de seguridad en IA — donde el riesgo de modelos y agentes se cruza con las decisiones de consejo — visita vulnex.ai.

Contacto: info@vulnex.com

Publicado en AI, IA, Pentest, Seguridad, Tecnologia | Etiquetado , , , , , , , | Deja un comentario

El día que la Ley de IA sacó los dientes: entra en vigor la aplicación para modelos GPAI

Publicado el agosto 8, 2026 por Simon Roses

Tiempo de lectura: 13 minutos

TL;DR

El 2 de agosto de 2026, la parte de la Ley de IA de la UE que todo el mundo ignoraba en voz baja se volvió aplicable: la Oficina de IA ya puede multar a los proveedores de modelos de IA de uso general (GPAI) con hasta el 3% de la facturación anual global o 15 millones de euros, la cifra que sea mayor, y puede exigir tu documentación técnica, realizar sus propias evaluaciones de tu modelo, ordenarte que «adoptes medidas» y, en el peor de los casos, obligarte a restringir, retirar o recuperar el modelo del mercado de la UE. Las obligaciones en sí existen técnicamente desde el 2 de agosto de 2025 —documentación técnica, transparencia hacia clientes intermedios, una política de derechos de autor que respete robots.txt y las exclusiones voluntarias, un resumen público de los datos de entrenamiento— pero hasta ahora eran reglas sin árbitro. Eso cambió. Los modelos considerados de riesgo sistémico (entrenados por encima de 10^25 FLOP) arrastran deberes más pesados que parecen una lista de seguridad escrita por un regulador: evaluaciones del modelo, pruebas adversarias / red teaming, un marco de seguridad, notificación de incidentes graves a la Oficina de IA y protección de ciberseguridad de los propios pesos del modelo. El Código de Buenas Prácticas voluntario te compra un trato más suave, no inmunidad. Los modelos ya en el mercado antes del 2 de agosto de 2025 tienen hasta el 2 de agosto de 2027 para cumplir. Esta es la mitad regulatoria de una historia en dos partes —la mitad de responsabilidad civil, la nueva Directiva de Responsabilidad por Productos, es el artículo que publico justo después de este—. Leídas juntas, la UE ha construido una pinza: un regulador que te multa y un tribunal que te pasa la factura. Aquí va mi lectura como profesional de seguridad de la mandíbula regulatoria.

Las fechas que importan:

Fecha Qué ocurre
1 ago 2024 La Ley de IA entra en vigor
2 ago 2025 Comienzan las obligaciones para modelos GPAI (modelos colocados en el mercado tras esa fecha)
2 ago 2026 Se enciende la aplicación — la Oficina de IA / Comisión puede investigar, evaluar, ordenar medidas y multar
2 ago 2027 Fecha límite de cumplimiento para modelos GPAI ya en el mercado antes del 2 ago 2025

El descargo de responsabilidad de siempre: no soy abogado y esto no es asesoramiento legal —es un profesional de seguridad leyendo una regulación como leo una superficie de ataque, buscando dónde recae la presión de verdad y quién acaba sujetándola—. Si construyes o distribuyes modelos de IA en la UE, habla con un abogado de verdad. Lo que sí puedo contarte es qué cambia operativamente para quienes construyen, aseguran y despliegan estos modelos —porque bajo el lenguaje de cumplimiento hay una lista de cosas que llevo dos años exigiendo en este blog, ahora respaldadas por una multa.

Una nota sobre el enfoque antes de empezar. Este artículo es uno de un par. La UE está poniendo dientes a la IA en dos vías distintas a la vez, y muerden de forma diferente. Esta —las reglas de la Ley de IA para la IA de uso general (formalmente un Reglamento, el (UE) 2024/1689, aunque todos la llamemos «Ley de IA»)— es regulatoria: una autoridad pública, la Oficina de IA, con poder para investigarte y multarte. El artículo complementario, sobre la nueva Directiva de Responsabilidad por Productos, es civil: demandantes privados y tribunales, responsabilidad objetiva, indemnizaciones a la persona a la que tu software defectuoso causó un daño. Los publico uno detrás de otro a propósito, porque si solo sigues uno calcularás mal tu exposición. Que un regulador te multe y que un demandante te demande son dos puertas distintas, y tras este verano las dos están abiertas.

Llevo tiempo rondando la puerta regulatoria — por qué «usamos ChatGPT» no es una estrategia de IA, qué pasa cuando el propio modelo se convierte en el atacante, si todavía puedes distinguir un modelo abierto de uno frontera. El 2 de agosto es la UE respondiendo a una parte de esas preguntas con un presupuesto de aplicación adjunto.

Qué cambió realmente el 2 de agosto

Esta es la parte que confunde a la gente, así que déjame ser preciso: el 2 de agosto de 2026 no creó obligaciones nuevas. Las reglas sustantivas para los modelos GPAI entraron en vigor un año antes, el 2 de agosto de 2025. Lo que faltaba hasta ahora era la maquinaria de aplicación. Durante doce meses, el capítulo GPAI de la Ley de IA ha sido una ley que técnicamente podías incumplir sin que nadie pudiera hacer gran cosa al respecto.

Ese periodo de gracia terminó. Desde el 2 de agosto de 2026, la Oficina de IA, el órgano dedicado de aplicación de la Comisión, tiene cuatro poderes concretos que el 1 de agosto no tenía:

  1. Exigir tu documentación. Puede requerir a un proveedor GPAI que entregue la documentación técnica e información sobre el modelo.
  2. Evaluar tu modelo. Puede realizar sus propias evaluaciones del modelo para comprobar el cumplimiento e investigar el riesgo sistémico, incluida la solicitud de acceso.
  3. Ordenar medidas de cumplimiento. Puede exigirte que «adoptes las medidas apropiadas» para ajustar el modelo.
  4. Retirar el modelo. En el peor de los casos, puede obligarte a restringir su disponibilidad, retirarlo o recuperarlo del mercado de la UE.

Un punto de precisión que conviene tener claro, porque los abogados que lean esto lo harán: la Oficina de IA es el órgano operativo que investiga, evalúa y construye el caso, pero la decisión formal de multar bajo el artículo 101 es de la Comisión Europea. En la práctica tratas con la Oficina de IA; la firma de la sanción es de la Comisión.

Y detrás de los cuatro está la cifra que concentra la atención: multas de hasta el 3% de la facturación anual global o 15 millones de euros, la que sea mayor, según el artículo 101. Ojo: ese es el techo específico de GPAI; las multas de titular del 7% de la facturación son para el despliegue de prácticas de IA prohibidas, otro régimen distinto. Pero para un laboratorio frontera, el 3% de la facturación global es una cifra de las que se ven en un consejo de administración.

01-enforcement-tree

Figura 1. Cómo aterriza la aplicación de verdad: una brecha de incumplimiento que sobrevive a la escalada de la Oficina de IA —solicitud de documentación → evaluación del modelo → orden de cumplimiento— acaba en una multa de hasta el 3% de la facturación global o 15 M€ y, en el extremo, en restricción o retirada del mercado de la UE.

Así que nada sobre las obligaciones de tu modelo cambió esta semana. Lo que cambió es que ignorarlas ahora tiene un precio, un árbitro y un botón de parada.

Y aquí está la señal de que esta fecha va en serio. El Digital Omnibus de la UE —un paquete de simplificación que la industria presionó con fuerza para conseguir, presentado en noviembre de 2025 y acordado esta primavera— retrasó los plazos de alto riesgo de la Ley de IA, deslizando las obligaciones del Anexo III hasta diciembre de 2027 y los sistemas integrados hasta 2028. A la GPAI la dejó en paz. De todos los plazos que Bruselas tuvo presión para mover, el único que no movió es el de este artículo. Cuando un regulador parpadea en casi todo excepto en aquello sobre lo que escribes, eso es la prioridad.

A quién afecta esto de verdad

La Ley de IA es quisquillosa con los roles, y la letra pequeña importa. Las obligaciones GPAI recaen sobre el proveedor del modelo —el laboratorio que entrena y coloca el modelo de uso general en el mercado—. Piensa en los nombres frontera obvios, pero también en el creciente campo de laboratorios de modelos abiertos y, algo importante, en cualquiera que haga fine-tuning o modifique sustancialmente un modelo hasta convertirse, en la práctica, en su nuevo proveedor. La propia guía de la Comisión pone una línea aproximada: si modificas un modelo usando más de alrededor de un tercio del cómputo de entrenamiento original, se presume que te has convertido en proveedor, con las obligaciones que ello conlleva. Esa cláusula es la que arrastra al ámbito de aplicación a muchas empresas que se consideran meros «usuarios» sin darse cuenta.

Si eres un responsable del despliegue (deployer) —construyes un producto sobre el modelo de otro— la mayoría de estos deberes GPAI todavía no son directamente tuyos (tu turno llega más tarde, cuando muerdan las reglas de sistemas de alto riesgo —un calendario que el Digital Omnibus acaba de retrasar y condicionar a las normas técnicas—). Pero heredas las consecuencias: la información de transparencia que tu proveedor upstream ahora debe darte es exactamente el material del que dependen tu propio cumplimiento y tu propia revisión de seguridad. Que es el primer punto donde un profesional de seguridad debería aguzar el oído: la Ley está obligando a tu proveedor de modelos a contarte cosas que antes trataba como secreto comercial. Aprovéchalo.

La base: qué debe ahora todo proveedor GPAI

Para cada modelo de uso general en el mercado de la UE, sea del tamaño que sea, cuatro deberes:

Documentación técnica. Un expediente detallado y mantenido del modelo —arquitectura, proceso de entrenamiento, usos previstos y excluidos, consumo energético—, conservado durante diez años y entregado a la Oficina de IA a requerimiento. Este es el archivo que se lee en voz alta en una investigación.

Transparencia hacia clientes intermedios. Debes publicar datos de contacto y responder a las solicitudes de los proveedores intermedios con la información que necesitan para integrar el modelo de forma responsable —la guía de transparencia del Código de Buenas Prácticas apunta a una ventana de respuesta corta, de pocos días (lecturas de despachos citan en torno a 14 días)— protegiendo aún la PI y los secretos comerciales legítimos. La era del «todo es propietario, apáñate tú» en la integración de modelos se acaba.

Una política de derechos de autor con mecánica real. No un párrafo de intenciones: una política funcional que respete las medidas tecnológicas de protección, excluya fuentes conocidas de piratería, honre robots.txt y las señales de exclusión voluntaria legibles por máquina, y dé a los titulares de derechos un contacto y una vía de reclamación. Esta es la disposición de la que colgarán los pleitos por datos de entrenamiento.

Un resumen público de los datos de entrenamiento. Una plantilla de la Oficina de IA rellenada que resuma con qué se entrenó el modelo. No el conjunto de datos, pero sí resumen suficiente para que la caja negra lleve una etiqueta.

Nada de esto es exótico para quien haya dirigido un equipo de ingeniería maduro. Lo nuevo es que es obligatorio, exigible y descubrible.

Riesgo sistémico: cuando la regulación empieza a hablar mi idioma

Aquí está la sección que me hizo querer escribir este artículo. Un subconjunto de modelos —los de «capacidades de alto impacto», presumidas cuando el cómputo de entrenamiento supera los 10^25 FLOP, y cualesquiera otros que la Comisión designe— se clasifican como de riesgo sistémico. Y las obligaciones que se les adhieren podrían haber salido directamente de una de mis propias listas de trabajo:

  • Un marco de seguridad (los detalles de plazos aquí provienen del capítulo de seguridad del Código de Buenas Prácticas), montado en semanas tras la notificación y finalizado antes de que el modelo se despliegue.
  • Evaluaciones del modelo y pruebas adversarias —la Ley dice red teaming con todas las letras—. La evaluación de vanguardia de las capacidades peligrosas del modelo es ahora un deber legal, no un «estaría bien» por el que tu equipo de seguridad pelea el presupuesto.
  • Evaluación y mitigación del riesgo sistémico a lo largo del ciclo de vida: filtrado, monitorización, controles de entrada/salida.
  • Notificación de incidentes graves a la Oficina de IA y a las autoridades nacionales en plazos escalonados —una obligación real de respuesta a incidentes para modelos—.
  • Protección de ciberseguridad del modelo y de su infraestructura física —es decir, protege los pesos—. La exfiltración de pesos es ahora un fallo de cumplimiento, no solo un titular embarazoso.
  • Retención de documentación durante diez años, y un informe de seguridad que incluya los hallazgos de evaluadores externos.

Una nota justa sobre las fuentes: la propia Ley fija estos deberes a nivel de principio (artículo 55); varios de los detalles concretos anteriores —los plazos del marco, la forma exacta del informe de seguridad— provienen del capítulo de seguridad del Código de Buenas Prácticas, que es la carretera asfaltada para demostrar que alcanzaste el listón legal. El deber es ley; parte del detalle es el Código.

Lee esa lista y luego relee lo que escribí tras el incidente de evaluación de modelos de Hugging Face / OpenAI: la mayoría de los defensores tienen cero telemetría en la capa de modelo y de agente, y las herramientas para ejecutar una intrusión completa a velocidad de máquina son ahora algo que puedes disparar por accidente durante tus propias pruebas de seguridad. La Ley de IA acaba de convertir la telemetría, la evaluación y la notificación de incidentes de esa misma capa en una obligación regulada para los modelos de riesgo sistémico. No me encanta cada línea de esta Ley, pero no voy a fingir que exigir pruebas adversarias y seguridad de pesos para los modelos más capaces del planeta sea la parte de la que quejarse. Es la parte que llevo pidiendo.

Hay también un punto sutil de economía de la seguridad. Las pruebas adversarias solo son tan buenas como el adversario. Una regulación que exige red teaming sin definir el rigor invita a la versión de casilla marcada —un equipo interno amable, un fin de semana, un informe en verde—. Los laboratorios que traten esto como trabajo ofensivo real (externo, adaptativo, incentivado para romper el modelo de verdad) producirán evidencia de seguridad con valor real; los que lo traten como un artefacto de cumplimiento producirán un documento que se ve genial hasta que alguien lo lea en una investigación. La misma lección de todo régimen de cumplimiento en el que he trabajado: el artefacto vale lo que la honestidad que hay detrás.

El matiz de los modelos abiertos

Aquí es donde mi tesis sobre los modelos abiertos choca con la Ley, y es el nudo más interesante de todo el asunto. La Ley de IA da a los modelos GPAI abiertos un respiro parcial: los modelos publicados bajo una licencia realmente libre y abierta, con sus parámetros y arquitectura públicos, quedan exentos de algunas de las obligaciones base —la documentación técnica y los deberes de transparencia hacia clientes intermedios—, aunque no de la política de derechos de autor ni del resumen público de datos de entrenamiento, que todo proveedor debe cumplir igualmente. La lógica refleja la exención de código abierto que describí en el artículo de responsabilidad: no quieres aplastar el procomún bajo el papeleo.

Pero —y es el mismo pero que en todas partes en el derecho tecnológico de la UE— la exención se evapora en cuanto el modelo conlleva riesgo sistémico. Cruza el umbral de cómputo y ser abierto no te salva de ninguno de los deberes pesados: sigues debiendo evaluaciones, pruebas adversarias, notificación de incidentes y seguridad de los pesos. Lo que aterriza en un punto peculiar dado hacia dónde va la frontera. Como escribí el mes pasado, los laboratorios chinos están sacando modelos abiertos de billones de parámetros que se miden de tú a tú con los sistemas frontera de EE. UU., NVIDIA y Meta también publican en abierto, y en VULNEX ya ejecutamos nuestro propio agente ofensivo sobre un modelo abierto. La estructura de la Ley implica que los modelos abiertos más capaces —precisamente los que más ilusionan al argumento de la soberanía— heredan el mayor peso regulatorio. La apertura te compra un trato más suave solo hasta que tu modelo se vuelve lo bastante bueno como para importar.

Para las empresas que ejecutan modelos abiertos en su propio hardware, hay una implicación más callada que señalo: si haces fine-tuning de un modelo abierto lo bastante lejos, puedes convertirte en proveedor a ojos de la Ley y heredar obligaciones que dabas por hechas del laboratorio del que descargaste. «Solo lo ejecutamos en local» no es el campo de fuerza que la gente cree.

El Código de Buenas Prácticas: un trato más suave, no un escudo

La Comisión publicó un Código de Buenas Prácticas para GPAI (finalizado en 2025, con capítulos sobre transparencia, derechos de autor y seguridad) como ruta voluntaria para demostrar el cumplimiento. Firmarlo te gana lo que la Oficina de IA llama mayor confianza —una aplicación centrada en tu adhesión al Código en lugar de auditorías abiertas, y los firmantes de buena fe no van a recibir un golpe en cuanto suene la campana si están implementando de forma visible—.

Dos cosas que no hay que malinterpretar. Primera: el Código no es jurídicamente vinculante ni es un puerto seguro —la adhesión no te inmuniza de multas, solo se pondera a tu favor cuando la Oficina de IA calcule una—. Segunda: si no lo firmas, no escapas de las obligaciones; simplemente tienes que demostrar el cumplimiento de otra forma y explicar tu método al regulador, lo que es más trabajo, no menos. El Código es la carretera asfaltada. Puedes ir campo a través, pero aún tienes que llegar al mismo destino y mostrar tu ruta.

¿Hay un equivalente en EE. UU.? La misma respuesta que la última vez: no

Si leíste el artículo de responsabilidad, esto te sonará, porque la divergencia tiene la misma forma. No hay equivalente federal estadounidense al régimen GPAI de la Ley de IA. El empuje federal de la era 2023 hacia obligaciones de seguridad en IA se revirtió; la postura de 2026 es desreguladora, apoyándose en compromisos voluntarios y autoridades sectoriales existentes en vez de en una ley horizontal con un ejecutor dedicado y multas basadas en facturación. Algunos estados de EE. UU. se mueven por su cuenta, pero no hay nada que otorgue a un regulador el poder de exigir la documentación de un laboratorio frontera, evaluar su modelo y retirarlo del mercado.

Así que aplica la misma lógica del efecto Bruselas que con el RGPD y la PLD: un laboratorio global no va a mantener un modelo para Europa y otro más laxo para el resto. Es más barato construir al listón de la UE una vez. Lo que significa que la Ley de IA está fijando en silencio el suelo global de cómo se documentan y aseguran los modelos más capaces —decidido en Bruselas, exportado por la economía, sin que EE. UU. tenga que votar—. Entre esto, la Directiva de Responsabilidad por Productos y los deberes de secure-by-design del Reglamento de Ciberresiliencia (CRA), la UE ha pasado 2026 convirtiéndose en el órgano de estándares de facto para la seguridad del software y la IA, y EE. UU. ha pasado 2026 rechazando explícitamente el puesto.

Mi lectura: qué deberían hacer de verdad los equipos de seguridad e IA

Quita el vocabulario de cumplimiento y el 2 de agosto es una lista de tareas operativas. La mayoría es lo que un programa serio de seguridad de IA ya debería estar haciendo; la diferencia es que «ya lo haremos» ahora lleva un regulador adjunto.

1. Conoce tu rol antes de que la Oficina de IA lo decida por ti. Proveedor, proveedor intermedio o responsable del despliegue lo cambia todo respecto a lo que debes. Y vigila el disparador del fine-tuning: modifica un modelo lo suficiente y te conviertes en proveedor. Mapea cada modelo de tu stack —incluido el modelo abierto que corre en una caja en el armario del equipo de investigación— a un rol, por escrito, ya. Esto es el Vacío de Estrategia de IA hecho concreto: no puedes gobernar modelos que no has inventariado.

2. Trata el red teaming y la evaluación como evidencia, no como teatro. Si tocas un modelo de riesgo sistémico, las pruebas adversarias son ahora un deber legal —así que haz la versión de verdad—. Externa, adaptativa, con adversario incentivado, documentada. El informe que generas es a la vez tu evidencia de seguridad y, algún día, una prueba judicial. Un artefacto de red team que enumera una capacidad que luego desplegaste igualmente es peor que ninguno.

3. La seguridad de los pesos es cumplimiento ahora —protege las joyas de la corona como tal—. La Ley nombra la protección de ciberseguridad del modelo y su infraestructura. Modela explícitamente la amenaza de exfiltración de pesos: controles de acceso, monitorización del tráfico de salida, riesgo de amenaza interna, la cadena de suministro alrededor de tu infraestructura de entrenamiento y servicio. El incidente del modelo-como-atacante mostró qué pasa en esa capa sin telemetría. Instruméntala.

4. Construye el músculo de notificación de incidentes antes de necesitarlo. La notificación de incidentes graves a la Oficina de IA va en plazos escalonados. Eso significa que necesitas detección, clasificación y un runbook de notificación para incidentes de modelo —no solo tu SOC de TI clásico—. Si no sabes cuándo tu modelo hizo algo notificable, no puedes notificarlo a tiempo.

5. Usa los nuevos deberes de transparencia de tu proveedor upstream. Si eres responsable del despliegue, tu proveedor de modelo ahora te debe información de integración y de riesgo en días. Eso no es solo papeleo —es la materia prima para tu propia revisión de seguridad de un modelo que no entrenaste—. Pídela. Por escrito.

6. Firma el Código de Buenas Prácticas con los ojos abiertos. Para proveedores, es la vía de menor fricción y cuenta a tu favor. Solo no lo confundas con un escudo, y no firmes capítulos que no puedas implementar de verdad —un compromiso incumplido es peor que un honesto «lo hacemos a nuestra manera»—.

7. Si eres un proveedor de EE. UU., no leas la desregulación de casa como protección. Que tu gobierno dé un paso atrás en las reglas de IA reduce tu exposición en la UE exactamente en cero: coloca un modelo en el mercado de la UE y la Oficina de IA todavía puede exigir su documentación, evaluarlo, multarte y retirarlo. La misma lógica del efecto Bruselas que en el artículo de responsabilidad —el listón de la UE es el que acabas construyendo, decida lo que decida Washington—.

En resumen

Durante una década, «vamos a por todas con la IA» ha sido una diapositiva, no un sistema. La Ley de IA es la UE decidiendo que si colocas los modelos más capaces del planeta en un mercado de 450 millones de personas, los vas a documentar, probar adversariamente, asegurar sus pesos, notificar cuando fallen y responder ante alguien con poder para multarte y desenchufarte. Eso no es burocracia. Es el trato que todos los demás campos de ingeniería de alta consecuencia aceptaron hace mucho, llegando —tarde, imperfecto, pero llegando— a la IA.

He dedicado este blog a argumentar que la capa de modelo y de agente está poco asegurada y apenas instrumentada. Es extraño ver aparecer a un regulador y ordenar una parte de exactamente eso. Me quedo con la victoria y guardo mi escepticismo para la aplicación —porque una regla es tan real como la primera multa, y estamos a punto de averiguar cuán en serio va la Oficina de IA—.

Y recuerda que esto es solo la primera mandíbula. El regulador puede multarte; la Directiva de Responsabilidad por Productos permite que la persona a la que dañaste te demande, sin culpa que probar, con las cláusulas de exención del EULA anuladas, en diciembre. Un verano, dos puertas, ambas abiertas ya. Construye para las dos.

02-pincer-graph

Figura 2. La pinza — un producto de IA inseguro o no conforme alcanza la responsabilidad por dos vías convergentes: la mandíbula regulatoria de la Ley de IA (la Oficina de IA, desde el 2 de agosto) y la mandíbula civil de la Directiva de Responsabilidad por Productos (responsabilidad objetiva, desde diciembre).

Mantente paranoico. Haz red teaming de verdad. Protege tus pesos.

Lecturas adicionales:

¿Preguntas o comentarios? Contacta a través de:

¿Necesitas ayuda para preparar tus modelos y sistemas de IA para la era de la Ley de IA? VULNEX ofrece:

  • Evaluaciones de seguridad de sistemas y modelos de IA (evaluación, pruebas adversarias / AI red teaming, modelado de amenazas de modelos abiertos)
  • Mapeo de roles GPAI y análisis de brechas de gobernanza (proveedor vs. responsable del despliegue, exposición por fine-tuning, inventario de modelos)
  • Preparación de respuesta a incidentes de IA y diseño de telemetría en la capa de modelo
  • Revisión secure-by-design para productos impulsados por IA y sistemas agénticos

Para estrategia de seguridad en IA —donde el riesgo de modelos y agentes se encuentra con las decisiones a nivel de consejo— visita vulnex.ai.

Contacto: info@vulnex.com

Publicado en AI, IA, Privacidad, Seguridad, Tecnologia | Etiquetado , , , | Deja un comentario

El Futuro de la Seguridad del Vibe Coding (Parte 10)

Publicado el julio 30, 2026 por Simon Roses

Serie Seguridad del Vibe Coding

  1. ¿Qué es la Seguridad del Vibe Coding? Una Guía de Campo para 2026
  2. El OWASP Top 10 para Aplicaciones Vibe-Coded
  3. Anatomía de una Brecha de Vibe Coding: Lecciones de los Peores Incidentes de 2026
  4. La Trampa de las Dependencias: Riesgos en la Cadena de Suministro del Código Generado por IA
  5. Autenticación y Secretos: Lo Que la IA Siempre Hace Mal
  6. Escaneando Aplicaciones Vibe-Coded: Por Qué el SAST/DAST Tradicional Se Queda Corto
  7. Prompt Engineering para Código Seguro
  8. El Checklist de Seguridad del Fundador
  9. Securizando el Pipeline de Codificación con IA
  10. El Futuro de la Seguridad del Vibe Coding (estás aquí)

Tiempo de lectura: 26 minutos

TL;DR

El panorama de la seguridad del vibe coding se está bifurcando en dos direcciones simultáneamente. Por un lado: la regulación está llegando (las obligaciones de notificación de vulnerabilidades del EU Cyber Resilience Act comienzan en septiembre de 2026, las aseguradoras están excluyendo el código generado por IA de las coberturas), los agentes autónomos están creando superficies de ataque que aún no hemos mapeado (cero de los 2.000 servidores MCP analizados tenía autenticación), y el envenenamiento de modelos significa que la propia IA podría estar comprometida antes de que escribas tu primer prompt. Por el otro: la defensa impulsada por IA está empezando a ponerse al día (los sistemas híbridos IA+SAST eliminan el 94-98% de falsos positivos, la detección de vulnerabilidades con IA detecta el doble de vulnerabilidades que las herramientas tradicionales pasan por alto), existen nuevos marcos de gobernanza de agentes, y la industria está construyendo la infraestructura de certificación y estándares que el vibe coding necesitaba. Este artículo final de la serie analiza ambas trayectorias y te da una hoja de ruta práctica para 2027.

Dónde Hemos Estado: La Serie en Retrospectiva

Cuando empecé esta serie en abril, un fundador me acababa de enseñar una app construida enteramente con prompts de IA. Funcionaba. También tenía inyección SQL en el formulario de login, credenciales de base de datos codificadas en el JavaScript del cliente, y un panel de administración accesible para cualquiera que adivinara la URL. Esa app — y las docenas como ella que había estado viendo en VULNEX — se convirtieron en la razón para escribir diez artículos sobre un problema que la mayor parte de la industria aún trataba como una novedad.

El arco de esta serie trazó el ciclo de vida de la inseguridad del vibe coding:

La Parte 1 definió el campo. El ochenta y cuatro por ciento de los desarrolladores usan o planean usar asistentes de codificación con IA, pero la conversación sobre seguridad no había seguido el ritmo de la curva de adopción. La Parte 2 mapeó cómo el OWASP Top 10 se manifiesta de forma diferente en el código generado por IA — las mismas categorías de vulnerabilidad, pero patrones diferentes y mayor densidad. La Parte 3 mostró qué pasa cuando esas vulnerabilidades llegan a producción a través de casos reales de brechas.

Después profundizamos en superficies de ataque específicas. La Parte 4 cubrió la cadena de suministro de dependencias — paquetes alucinados, dependencias fantasma, slopsquatting. La Parte 5 documentó cómo la IA falla sistemáticamente en autenticación y gestión de secretos. La Parte 6 explicó por qué las herramientas de escaneo tradicionales no detectan los patrones de vulnerabilidad específicos de la IA.

La recta final se centró en la defensa. La Parte 7 mostró cómo diseñar prompts que produzcan código más seguro. La Parte 8 dio a los fundadores un checklist previo al lanzamiento. La Parte 9 cubrió la cadena de herramientas en sí — cada etapa desde el modelo hasta producción, y los ataques dirigidos a cada una.

Siendo sincero sobre lo que me sorprendió: cuando empecé la Parte 1, pensaba que el envenenamiento de dependencias y los paquetes alucinados eran la amenaza más urgente. Para la Parte 9, estaba claro que la superficie de ataque de la cadena de herramientas — servidores MCP, extensiones del IDE, ficheros de configuración de IA — estaba evolucionando más rápido que cualquier otra cosa en el campo. Las vulnerabilidades en el código eran graves. Las vulnerabilidades en las herramientas que producen el código eran peores. Esa constatación reformuló la segunda mitad de esta serie y es el hilo conductor de lo que cubriré en este artículo final.

Eso era el presente. Este artículo trata sobre lo que viene después.

La Oleada Regulatoria

La UE Se Mueve Primero

Dos piezas legislativas de la UE están a punto de reformar cómo las organizaciones manejan el código generado por IA, y ninguna menciona «vibe coding» por su nombre.

El EU AI Act entró en vigor en agosto de 2024, con una aplicación gradual. Las normas para IA de propósito general entraron en vigor en agosto de 2025. El 2 de agosto de 2026, se activan las obligaciones de transparencia del Artículo 50 y los poderes sancionadores — con multas máximas de 15 millones de euros o el 3% de la facturación global, lo que sea mayor. Las herramientas de codificación con IA no se han clasificado como de alto riesgo bajo la Ley, pero las disposiciones sobre IA de propósito general siguen aplicándose a los modelos fundacionales que las alimentan.

Más trascendente para los equipos de desarrollo es el EU Cyber Resilience Act. Entró en vigor en diciembre de 2024, y no distingue entre código escrito por humanos y código generado por IA. Las obligaciones de notificación de vulnerabilidades comienzan el 11 de septiembre de 2026 — dentro de dos meses. Los fabricantes deben notificar las vulnerabilidades explotadas activamente en un plazo de 24 horas. El cumplimiento completo se exige para diciembre de 2027. Si tu app vibe-coded se distribuye a clientes de la UE, el CRA aplica independientemente de cómo se produjo el código.

En Estados Unidos, el enfoque ha sido más ligero. La orden ejecutiva del 2 de junio de 2026, «Promoting Advanced AI Innovation and Security,» estableció un marco voluntario para la revisión gubernamental de modelos de IA de frontera y ordenó a las agencias desarrollar benchmarks de ciberseguridad de IA. Creó un «centro de intercambio de ciberseguridad de IA» pero no llegó a imponer requisitos obligatorios para el código generado por IA. Ninguna ley federal apunta específicamente a las herramientas de codificación con IA como categoría diferenciada.

La Industria Aseguradora Se Retira

Mientras los gobiernos debaten la regulación, las aseguradoras ya están tomando decisiones con la cartera. En enero de 2026, la Insurance Services Office introdujo una exclusión de IA generativa en las pólizas de responsabilidad civil general comercial, excluyendo la cobertura por lesiones corporales, daños materiales y perjuicios personales derivados de la IA generativa. La Asociación de Ginebra señaló a finales de 2025 que los datos de siniestros limitados y la asimetría de información hacen que el riesgo de IA sea «técnicamente irresoluble con los datos actuales.»

Traducción: si tu código generado por IA causa daños, tu seguro podría no cubrirlo. La cobertura se está fragmentando entre líneas de ciberseguridad, Tech E&O, D&O y EPLI, creando un riesgo de brecha que K&L Gates identificó como «la próxima oleada de litigios.»

No se han reportado públicamente demandas específicamente sobre vulnerabilidades en código generado por IA hasta mediados de 2026. El plazo de transposición de la Directiva de Responsabilidad de Productos de la UE — diciembre de 2026 — extenderá la responsabilidad objetiva al software, incluyendo los sistemas de IA. Cuando empiecen los litigios, empezarán rápido.

Estándares y Certificación Se Ponen al Día

La infraestructura de estándares está empezando a ponerse al día. El 17 de febrero de 2026, el Centro para los Estándares y la Innovación en IA del NIST (CAISI) lanzó la AI Agent Standards Initiative — el primer esfuerzo federal para establecer estándares de interoperabilidad, seguridad e identidad para agentes autónomos de IA que escriben y ejecutan código. Se espera un Perfil de Interoperabilidad de Agentes IA para el cuarto trimestre de 2026.

El mismo día, CompTIA lanzó SecAI+ (examen CY0-001), su primera certificación en la intersección de IA y ciberseguridad. Cuatro dominios: Conceptos Básicos de IA (17%), Securización de Sistemas de IA (40%), Seguridad Asistida por IA (24%), y Gobernanza, Riesgo y Cumplimiento de IA (19%). No es lo bastante profunda para trabajo de seguridad ofensiva, pero señala que la industria reconoce la brecha de competencias.

La Era de los Agentes

Todos los Servidores MCP Suspenden el Mismo Test

En la Parte 9, cubrí las vulnerabilidades de MCP — los CVEs, el envenenamiento de herramientas, los ataques de auto-ejecución. Eso era el presente. El futuro es peor.

Knostic realizó un escaneo de seguridad de aproximadamente 2.000 servidores MCP. Ninguno tenía autenticación. No la mayoría. No una parte significativa. Todos. El protocolo que conecta los modelos de IA con herramientas, bases de datos y APIs a través del ecosistema de desarrollo tiene cero autenticación como estado predeterminado.

Dos protocolos compiten ahora por definir cómo se comunican los agentes: el MCP (Model Context Protocol) de Anthropic y el A2A (Agent-to-Agent) de Google, anunciado en abril de 2025 con más de 50 socios de la industria. Ambos compiten por la adopción. Ninguno ha resuelto el problema fundamental de autenticación a nivel de protocolo.

Un artículo de marzo de 2026 propuso AIP — Agent Identity Protocol — para cadenas de delegación criptográfica entre MCP y A2A. El consenso emergente entre investigadores es que mutual TLS, tarjetas de agente firmadas e identidades respaldadas por PKI son la solución mínima viable. Los tokens OAuth por sí solos son insuficientes porque no fueron diseñados para cadenas de delegación máquina a máquina donde el «usuario» es en sí mismo un agente actuando en nombre de otro agente.

Desplegando Sin Permiso

El informe «State of AI Agent Security 2026» de Gravitee encuestó a equipos técnicos sobre la preparación para el despliegue de agentes. Los resultados cuentan una historia conocida: el 80,9% de los equipos han pasado de la planificación a pruebas activas o despliegue en producción de agentes IA. Solo el 14,4% reporta que los agentes entran en producción con la aprobación completa de seguridad e IT. El 81% siente presión para desplegar agentes antes de que los marcos de gobernanza estén listos.

Esto es el patrón de la migración a la nube otra vez — adopta primero, securiza después — excepto que los agentes tienen un acceso más amplio a los sistemas que las instancias en la nube jamás tuvieron. Un agente IA con acceso MCP puede leer tus ficheros, consultar tus bases de datos, ejecutar comandos, enviar mensajes y desplegar código. Una instancia EC2 mal configurada no puede hacer la mayoría de eso.

La Respuesta de OWASP

OWASP publicó su Top 10 para Aplicaciones Agénticas en diciembre de 2025, reconociendo que el Top 10 original para LLMs no cubría adecuadamente los riesgos de los agentes autónomos. El riesgo número uno: Secuestro de Objetivo del Agente — manipular a un agente para que persiga objetivos que benefician al atacante en lugar del usuario. Esto es la inyección de prompts aplicada a agentes que pueden ejecutar acciones, no solo generar texto. La lista completa también incluye Envenenamiento de Memoria y Contexto, Fallos en Cascada en sistemas multi-agente y Agentes Rogue que operan fuera de sus límites previstos — cada uno una clase de riesgo diferenciada que no existía hace dieciocho meses.

La respuesta de Microsoft llegó en abril de 2026: el Agent Governance Toolkit, publicado bajo licencia MIT. Es el primer framework de código abierto que aborda los 10 riesgos agénticos de OWASP con aplicación determinista de políticas en menos de un milisegundo. Se integra con LangChain, CrewAI, Google ADK y el Agents SDK de OpenAI. Es un comienzo — pero un toolkit solo es útil si los equipos realmente lo adoptan, y las cifras de Gravitee sugieren que la mayoría no están esperando a la gobernanza.

La escala del problema sigue creciendo. Los investigadores de Google midieron un aumento del 32% en payloads de inyección de prompts maliciosos incrustados en contenido web entre noviembre de 2025 y febrero de 2026. Cada página web que un agente navega, cada documento que lee, cada respuesta de API que procesa es un vector de inyección potencial. A medida que los agentes se vuelven más autónomos, la superficie de ataque no crece linealmente — crece de forma combinatoria.

Cuando los Agentes Encuentran Zero-Days

En abril de 2026, Anthropic reveló Claude Mythos Preview — un modelo de frontera capaz de identificar y explotar vulnerabilidades de día cero de forma autónoma. A través de Project Glasswing, Mythos escaneó más de 1.000 proyectos de código abierto e identificó 23.019 problemas, incluyendo 6.202 de severidad alta o crítica. Para mayo de 2026, se habían divulgado 1.596 hallazgos a través de programas de divulgación coordinada de vulnerabilidades.

Este es un punto de inflexión. La misma capacidad autónoma que encuentra vulnerabilidades para los defensores puede encontrarlas para los atacantes. Anthropic eligió la divulgación coordinada. Un actor estatal con capacidad equivalente no lo haría. La asimetría entre ataque y defensa que ha definido la ciberseguridad durante décadas está a punto de acelerarse.

Google DeepMind respondió con un «AI Control Roadmap» en junio de 2026 para la gestión de defensa en profundidad de agentes potencialmente desalineados. Anthropic, OpenAI y Block cofundaron la Agentic AI Foundation bajo la Linux Foundation a finales de 2025, reconociendo que la seguridad de los agentes es un problema compartido que ninguna empresa puede resolver sola.

Mientras tanto, Google DeepMind, Schmidt Sciences, la Cooperative AI Foundation y ARIA anunciaron una iniciativa de financiación de 10 millones de dólares el 11 de junio de 2026, dirigida a la investigación en seguridad de IA multi-agente. El foco: los riesgos emergentes a nivel poblacional cuando agentes de diferentes organizaciones interactúan en entornos compartidos.

IA contra IA: La Defensa Evoluciona

Encontrando Lo Que los Humanos No Ven

El mapa de las herramientas de seguridad está pasando de «la IA genera código, los humanos lo revisan» a «la IA genera código, la IA encuentra los fallos, los humanos toman las decisiones.»

IRIS, presentado en ICLR 2025, demostró cómo es esto en la práctica. Es un sistema neurosimbólico que combina LLMs con el análisis estático de CodeQL. Usando GPT-4, IRIS detectó 55 vulnerabilidades en proyectos Java reales — un 103,7% más que CodeQL por sí solo — reduciendo la tasa de falsos descubrimientos un 5,21%. También descubrió cuatro vulnerabilidades previamente desconocidas. El sistema es de código abierto.

SAST-Genius, presentado en IEEE S&P 2025, adopta el enfoque complementario: usar LLMs para filtrar los falsos positivos de SAST. Las configuraciones híbridas eliminan el 94-98% de los falsos positivos. Esto importa porque la fatiga por alertas — el problema que describí en la Parte 6 y la Parte 9 — es la razón por la que el 40% de las alertas de seguridad quedan sin investigar. Si la IA puede separar de forma fiable las vulnerabilidades reales del ruido, los revisores humanos pueden centrarse en lo que realmente importa.

Los Copilotos de Seguridad Llegan a la Empresa

Microsoft Security Copilot comenzó a desplegarse para todos los clientes M365 E5 en noviembre de 2025, con más de 40 agentes que cubren Defender, Entra, Intune y Purview. No es una interfaz de chat que responde preguntas de seguridad — es una capa de orquestación donde agentes IA especializados manejan la clasificación, investigación y respuesta a través del stack de seguridad de Microsoft.

Google lanzó AI Threat Defense el 27 de mayo de 2026, integrando Wiz (mapeo de exposición en la nube), CodeMender (reparación de código con IA), Gemini (razonamiento) y Mandiant (inteligencia de amenazas) en una plataforma de defensa unificada. Agentes especializados manejan la Ingeniería de Detección y la Caza de Amenazas como flujos de trabajo diferenciados.

CrowdStrike presentó Charlotte Agentic SOAR en noviembre de 2025, reemplazando la orquestación de seguridad legacy con agentes IA que toman decisiones en tiempo real en siete roles especializados.

El patrón común en los tres: la seguridad está pasando de investigación conducida por humanos asistida por herramientas a investigación conducida por IA supervisada por humanos. Dropzone AI informa que la caza de amenazas aumentada por IA comprime investigaciones manuales de 40 horas a aproximadamente una hora. Las organizaciones que despliegan IA y automatización en operaciones de seguridad redujeron la identificación y contención de brechas en una media de 80 días.

Reparación Automatizada de Código

CodeMender de Google DeepMind, anunciado en octubre de 2025, usa modelos Gemini Deep Think combinados con análisis estático, análisis dinámico, fuzzing y resolvedores SMT para encontrar y corregir vulnerabilidades de seguridad automáticamente. En sus primeros seis meses, contribuyó 72 correcciones de seguridad a proyectos de código abierto — algunos con bases de código que superan los 4,5 millones de líneas. Todos los parches pasan por revisión humana antes de fusionarse.

Esta es la pieza que faltaba en el pipeline de seguridad del vibe coding. Hoy, la IA genera código vulnerable, los humanos lo encuentran, y los humanos lo corrigen. Mañana: la IA genera código, la IA encuentra las vulnerabilidades, la IA propone correcciones, y los humanos aprueban. El rol humano pasa de hacer el trabajo a gobernar el proceso.

Las Amenazas Que Aún No Hemos Visto

Envenenando los Propios Modelos

Todo en esta serie asumía que el propio modelo era de confianza — defectuoso en su salida, sin duda, pero no deliberadamente comprometido. Esa suposición tiene fecha de caducidad.

Investigaciones afiliadas a Anthropic demostraron que aproximadamente 250 muestras maliciosas pueden envenenar un modelo fundacional independientemente del tamaño total del conjunto de datos — menos del 0,1% de los datos de preentrenamiento. Las puertas traseras sobreviven al fine-tuning y a la alineación de seguridad. Un artículo llamado «BackdoorLLM,» aceptado en NeurIPS 2025, formalizó el ataque. Una variante más insidiosa llamada «Turn-Based Structural Triggers» (enero de 2026) mostró cómo incrustar puertas traseras que solo se activan en patrones específicos de conversación multi-turno — exactamente el tipo de interacciones que los desarrolladores mantienen con los asistentes de codificación.

La implicación práctica: un atacante que pueda influir en los datos de entrenamiento no necesita comprometer tus extensiones del IDE, tus servidores MCP ni tu pipeline CI/CD. Puede comprometer el propio modelo, y el modelo generará código vulnerable que pasa cada revisión porque la vulnerabilidad fue diseñada para parecer una decisión de implementación razonable.

Una subtendencia lo empeora: el envenenamiento de adaptadores LoRA. Adaptadores de fine-tuning pequeños — del tipo usado para personalizar modelos para tareas de codificación específicas — pueden introducir puertas traseras difíciles de distinguir del fine-tuning legítimo. Si tu organización hace fine-tuning de un modelo con código interno y un atacante puede influir en ese corpus de entrenamiento, la puerta trasera se propaga a cada desarrollador que use el modelo ajustado.

Desarrolladores Sintéticos

Operadores norcoreanos han construido identidades de desarrolladores sintéticas con historiales fabricados en LinkedIn y fotos de perfil generadas por IA para infiltrarse en empresas tecnológicas como contratistas remotos. Google Threat Intelligence documentó el grupo de amenazas UNC1069 transitando hacia campañas impulsadas por IA dirigidas a desarrolladores en exchanges de criptomonedas y empresas financieras usando personas generadas por IA.

Combina esto con el modelo de contribución de código abierto: un perfil de desarrollador sintético, respaldado por meses de historial de commits de apariencia legítima (que a su vez es generado por IA), envía pull requests a repositorios populares. Un estudio de Carnegie Mellon de 2026 encontró 6 millones de estrellas falsas en más de 18.600 repositorios de GitHub, siendo los proyectos de IA y LLM la categoría más manipulada.

En abril de 2026, la campaña «prt-scan» abrió 475 pull requests maliciosos en repositorios en solo 26 horas. En julio de 2026, los investigadores revelaron que los commits verificados de GitHub pueden reescribirse en nuevos hashes sin romper las firmas — lo que significa que incluso los commits firmados podrían no demostrar lo que aparentan.

La infraestructura de confianza en la que se apoya el código abierto — reputación de contribuidores, historial de commits, verificación de firmas — no fue diseñada para un mundo en el que la IA puede fabricar todo eso a escala. Y los vibe coders están desproporcionadamente expuestos: los asistentes de codificación con IA extraen dependencias, sugieren librerías y recomiendan patrones de código de estos repositorios de forma automática. Un desarrollador que evalúa una librería manualmente podría detectar un perfil de contribuidor sospechoso. Un asistente de IA que sugiere import paquete-comprometido en respuesta a un prompt no lo hará.

El Déficit de Cripto-Agilidad

El NIST finalizó los estándares criptográficos post-cuánticos (CRYSTALS-Kyber, CRYSTALS-Dilithium) en 2024. La transición a la criptografía post-cuántica ya es un reto para las bases de código escritas por humanos. Para el código generado por IA, es potencialmente catastrófica.

Los asistentes de codificación con IA tienden a codificar las opciones de cifrado directamente en el código. Cuando cubrí la autenticación en la Parte 5, los ejemplos mostraban la IA recurriendo a MD5 y SHA-1 — algoritmos que llevan años deprecados. El mismo patrón se aplica a la selección de librerías criptográficas: el modelo genera lo que era común en sus datos de entrenamiento, no lo que es actual.

El resultado es un déficit de cripto-agilidad. La mayoría de los pipelines CI/CD tienen algoritmos criptográficos legacy profundamente integrados que requieren una refactorización masiva para la migración post-cuántica. El código generado por IA acelera este problema porque genera más de lo mismo — opciones de algoritmos codificadas directamente, sin capas de abstracción, sin patrones de diseño de cripto-agilidad. Cuando llegue la transición cuántica, las aplicaciones vibe-coded serán desproporcionadamente difíciles de migrar.

QuickNote: Dos Años Después

Proyectemos QuickNote — la app deliberadamente vulnerable de esta serie — dos años hacia adelante. Maya, la desarrolladora de la Parte 9, ha aprendido de sus errores. Así podría ser su flujo de trabajo en 2028 — si construimos la infraestructura que necesita:

El modelo que usa ha cambiado. El asistente de codificación de Maya funciona a través de un proxy corporativo que elimina las configuraciones MCP de los repositorios clonados y valida las descripciones de herramientas contra un registro de confianza. El modelo está ajustado con el código interno de su empresa, pero el pipeline de fine-tuning incluye pruebas adversariales para la inserción de puertas traseras.

Su IDE aplica guardarraíles. Los ficheros de configuración de IA se tratan como código ejecutable — se requieren diffs, el Unicode oculto dispara un fallo de CI, y los ficheros de reglas están firmados por mantenedores aprobados. Las extensiones que ejecuta fueron auditadas por un servicio externo que monitoriza cambios de comportamiento post-instalación.

Los agentes trabajan en sandboxes. Los agentes IA de Maya operan dentro de contenedores con políticas de red, restricciones de sistema de ficheros y alcance de credenciales. Ningún agente hereda su entorno completo. Los servidores MCP se autentican con mutual TLS e identidades de agente firmadas — el protocolo maduró después de la crisis de autenticación de 2026.

La IA revisa a la IA. Su pipeline de pull requests ejecuta CodeMender para sugerencias de reparación automatizada, IRIS para detección híbrida de vulnerabilidades, y SAST-Genius para filtrado de falsos positivos. La revisión humana se centra en decisiones de arquitectura y lógica de negocio, no en la caza mecánica de vulnerabilidades que la IA maneja mejor.

El cumplimiento está automatizado. Su pipeline CI/CD genera un inventario de materiales de software que rastrea qué porciones del código fueron generadas por IA, qué versión del modelo las produjo, y qué escaneos de seguridad se aplicaron. Cuando llega la auditoría del CRA de la UE, puede demostrar el cumplimiento sin prisas.

El seguro está resuelto. La empresa de Maya tiene una cláusula adicional de responsabilidad por código IA dedicada que solo estuvo disponible porque pudieron demostrar un proceso de gobernanza de IA documentado y auditable.

¿Es ambicioso? Sin duda. Algunos de estos componentes existen hoy; otros están en desarrollo temprano. Mutual TLS para MCP sigue siendo una propuesta. La procedencia de código IA en los SBOMs es incipiente. Las pruebas adversariales para puertas traseras de fine-tuning siguen siendo investigación. Pero la trayectoria es clara, y cada pieza que he descrito tiene equipos trabajando en ella ahora mismo. La cuestión no es si el 2028 de Maya es posible — es si la industria lo construye lo bastante rápido para que importe.

Una Hoja de Ruta Práctica para 2027

Esto es lo que deberías estar construyendo o adquiriendo en los próximos doce meses, organizado por urgencia.

Hacer Ahora (T3-T4 2026)

Prepárate para el EU Cyber Resilience Act. Si distribuyes software a clientes de la UE, las obligaciones de notificación de vulnerabilidades comienzan el 11 de septiembre de 2026. El CRA no distingue entre código escrito por humanos y código generado por IA, así que esto aplica a tus componentes vibe-coded por igual. En concreto: designa un punto de contacto único para la divulgación coordinada de vulnerabilidades, establece una base de datos interna de vulnerabilidades que rastree los componentes de código generado por IA, construye un flujo de notificación a ENISA y al CSIRT nacional correspondiente a través de la Plataforma Única de Notificación en 24 horas para vulnerabilidades explotadas activamente, y documenta el periodo de soporte de seguridad de cada producto que distribuyas. Si no tienes esto en marcha para septiembre, estarás incumpliendo desde el primer día.

Inventaría los permisos de tus agentes IA. Los datos de Gravitee muestran que el 81% de los equipos están desplegando agentes sin gobernanza. Realiza una auditoría: ¿qué agentes tienen acceso a qué sistemas? ¿Qué credenciales heredan? ¿Qué acciones pueden ejecutar sin aprobación humana? Usa el Top 10 de Aplicaciones Agénticas de OWASP como marco de evaluación.

Adopta el Agent Governance Toolkit de Microsoft o construye una aplicación de políticas equivalente. Las comprobaciones de políticas en menos de un milisegundo sobre las acciones de los agentes son la defensa mínima viable. Si tus agentes pueden desplegar código, modificar infraestructura o acceder a datos de clientes, guardarraíles deterministas — no el comportamiento probabilístico del modelo — deben restringirlos.

Construir en T1-T2 2027

Integra escaneo de seguridad impulsado por IA. Los enfoques híbridos como IRIS (LLM + CodeQL) y SAST-Genius (filtrado de falsos positivos con LLM) representan la próxima generación de detección de vulnerabilidades. Evalúalos para tu stack. La reducción de falsos positivos por sí sola justifica la inversión — tu equipo de seguridad se está ahogando en alertas sobre las que no puede actuar.

Implementa rastreo de procedencia del código IA. Rastrea qué porciones de tu base de código fueron generadas por IA, por qué modelo, y en qué versión. Es un requisito de cumplimiento bajo las disposiciones de transparencia del EU AI Act y una defensa de responsabilidad cuando las cosas van mal. Las herramientas para esto son incipientes pero se están desarrollando — empieza con metadatos en mensajes de commit y avanza hacia el rastreo automatizado.

Forma a tu equipo. SecAI+ de CompTIA es un punto de partida. SANS, ISC2 y AWS ofrecen formación en seguridad de IA ahora. La brecha de competencias entre «desarrolladores que usan IA» y «desarrolladores que securizan IA» es donde la mayoría de las organizaciones son más vulnerables.

Planificar para S2 2027

Prepárate para la migración post-cuántica. Audita tus bases de código generadas por IA en busca de opciones criptográficas codificadas directamente. Implementa patrones de cripto-agilidad — capas de abstracción que permitan la sustitución de algoritmos sin reescribir la lógica de la aplicación. Los estándares del NIST están finalizados; la migración es cuestión de cuándo, no de si.

Evalúa seguros de responsabilidad por código IA. El mercado de seguros aún se está formando, pero los que se mueven primero y pueden demostrar procesos de gobernanza de IA están consiguiendo cobertura. Las empresas sin prácticas documentadas de seguridad de IA encontrarán cada vez más caro — o imposible — asegurar sus bases de código generadas por IA.

Contribuye a los estándares de seguridad de agentes. Se espera el Perfil de Interoperabilidad de Agentes IA del NIST para el cuarto trimestre de 2026. El mapa de estándares se está dibujando ahora mismo. Si operas a escala con agentes IA, tu experiencia debería contribuir a dar forma a estos estándares en lugar de reaccionar a ellos.

La Brecha Entre Dos Listas Top 10

OWASP mantiene ahora dos marcos de seguridad de IA separados: el LLM Top 10 (centrado en el comportamiento del modelo — inyección de prompts, envenenamiento de datos de entrenamiento, manejo de salidas) y el Top 10 Agéntico (centrado en la acción autónoma — secuestro de objetivos, manipulación de herramientas, control de acceso insuficiente). Los principales riesgos agénticos los cubrí en la sección anterior porque ahí está la amenaza activa. Pero la brecha entre estas dos listas importa más que cualquiera de ellas por separado.

El LLM Top 10 asume que un humano está en el bucle — leyendo la salida, decidiendo si actuar. El Top 10 Agéntico asume que la IA es la que actúa. La mayoría de los sistemas reales en 2026 están en algún punto intermedio: agentes semi-autónomos que a veces piden aprobación y a veces no, dependiendo de cómo se configuraron. El modelo de seguridad para este terreno intermedio apenas existe. Los marcos de OWASP abordan los dos extremos pero no el continuo.

Aquí es donde vivirá la próxima generación de exploits. Los atacantes no apuntarán al chatbot completamente supervisado (poco rentable) ni al agente completamente autónomo (mejor defendido con el tiempo). Apuntarán al agente medio supervisado con límites difusos — el que pide permiso para desplegar código pero no para modificar la configuración de despliegue. Hemos pasado 2025-2026 aprendiendo a securizar las salidas del modelo. Pasaremos 2027-2028 aprendiendo a securizar las acciones del modelo. Lo más difícil serán los sistemas que hacen ambas cosas.

El Arco de Esta Serie

Escribí el primer artículo de esta serie porque la industria de la seguridad no estaba siguiendo el ritmo de lo que estaba pasando sobre el terreno. Los desarrolladores estaban construyendo aplicaciones de producción con código generado por IA, distribuyéndolas a usuarios reales, y nadie estaba documentando sistemáticamente qué salía mal — ni cómo prevenirlo.

Diez artículos después, la situación ha cambiado. Cuando escribí la Parte 1, MCP era un protocolo del que la mayoría de los profesionales de seguridad no habían oído hablar. Para la Parte 9, la NSA había publicado guías sobre él. Cuando escribí la Parte 2, mapear los riesgos de OWASP a las aplicaciones vibe-coded era un ejercicio novedoso. Para mediados de 2026, OWASP había publicado listas de top 10 separadas tanto para aplicaciones LLM como para aplicaciones agénticas. Cuando escribí la Parte 4 sobre riesgos de la cadena de suministro, el slopsquatting era un hallazgo de investigación emergente. Ahora es un vector de ataque documentado con explotación activa en producción.

Los datos cuentan la historia. El Vibe Security Radar de Georgia Tech rastreó 6 CVEs atribuidos a código generado por IA en enero de 2026. Para marzo, eran 35. Los commits asistidos por IA exponen secretos codificados a una tasa del 3,2% — más del doble de la tasa base del 1,5% para código escrito por humanos. Apiiro encontró que el código generado por IA crea un 322% más de rutas de escalada de privilegios que el código escrito por humanos. La confianza de los desarrolladores en la salida de la IA cayó 11 puntos porcentuales en un solo año — solo el 29% confía ahora en el código generado por IA, frente al 40% en 2024.

La industria ya no está ignorando el problema. Lo que aún no ha hecho es resolverlo.

Hacia Dónde Vamos

El mercado de asistentes de codificación con IA fue de 7.370 millones de dólares en 2025 y se proyecta que alcance los 26.000 millones para 2030. Solo GitHub Copilot tiene aproximadamente 20 millones de usuarios desplegados en el 90% del Fortune 100. Esta tecnología no va a desaparecer. La pregunta nunca fue «¿deberíamos usar IA para escribir código?» — siempre fue «¿cómo lo hacemos sin quemar la casa?»

Después de diez artículos, mi respuesta es lo mismo que le diría a cualquier cliente que me pregunta: la tecnología es potente, los riesgos son reales, y el camino hacia adelante es ingeniería disciplinada, no miedo.

Trata el código generado por IA como entrada no confiable — siempre, sin excepción. Construye puertas de seguridad que no dependan solo de la vigilancia humana. Adopta herramientas de defensa impulsadas por IA que puedan seguir el ritmo del volumen generado por IA. Prepárate para la regulación que llega estés listo o no. E invierte en las personas: los desarrolladores que necesitan entender qué hace mal la IA, los ingenieros de seguridad que necesitan auditar pipelines aumentados con IA, y los líderes que necesitan gobernar un proceso que va más rápido de lo que cualquier humano puede revisar manualmente.

La revolución del vibe coding dio a los desarrolladores un apalancamiento extraordinario. El reto de seguridad de los próximos dos años es hacer que ese apalancamiento sea seguro de usar. En VULNEX, lo vemos cada semana — equipos que lanzan rápido con código generado por IA, descubren la deuda de seguridad después, y corren a cerrar brechas que no sabían que existían. Las herramientas y los marcos están mejorando, pero solo funcionan si los adoptas antes de la brecha, no después.

Si has estado leyendo esta serie, te pido algo: no dejes que se quede en lo teórico. Elige un punto de la hoja de ruta de arriba e impleméntalo este trimestre. Audita los permisos de tus servidores MCP. Monta un flujo de notificación de vulnerabilidades en 24 horas. Ejecuta un escáner impulsado por IA junto con tu SAST actual. Un paso concreto importa más que diez artículos guardados en favoritos. Y si encuentras algo interesante — un nuevo patrón de ataque, una herramienta que funciona, un vacío regulatorio del que nadie habla — compártelo. Menciónalo. La comunidad de seguridad se fortalece cuando los profesionales publican lo que aprenden.

Como siempre: no te fíes de nada, verifica todo.

Ha sido un privilegio escribir esta serie. Espero que haya sido útil.

Lectura Adicional

Referencias

Publicado en AI, IA, Privacidad, Seguridad, Tecnologia | Etiquetado , , , , , , | Deja un comentario