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

¿Sueñan los Modelos Abiertos con Tokens?

Publicado el julio 25, 2026 por Simon Roses

Tiempo de lectura: 14 minutos

TL;DR

Philip K. Dick se preguntó si se podía distinguir a un androide de un humano. La versión empresarial de esa pregunta en 2026 es si todavía podéis distinguir un modelo abierto de uno comercial — y la respuesta honesta es cada vez menos, en los tests que de verdad importan. Los laboratorios chinos están sacando modelos abiertos de escala billonaria — Kimi K3, DeepSeek V4, GLM-5.2 — con licencias tipo MIT, ventanas de contexto de un millón de tokens y — ejecutados en tu propio hardware — a una fracción del coste, y ya se pelean de tú a tú con los sistemas comerciales de EE. UU. en razonamiento y ciencia. La programación es el último foso claro, y hasta ese se está estrechando. Y no es solo cosa de China: NVIDIA (Nemotron) y Meta (Llama) también están sacando modelos abiertos, y en VULNEX ya corremos nuestro propio agente ofensivo sobre Qwen. Jensen Huang rompió toda una vida de silencio en X para decir lo que casi nadie dice en voz alta: los modelos abiertos «refuerzan la seguridad y la ciberseguridad, aceleran la innovación y la difusión, y permiten la soberanía» — y que Washington los prohíba sería repetir el error que la industria del software estuvo a punto de cometer con el open source en los años 80. OpenAI y Anthropic, significativamente, no firmaron la carta que él respaldó. Mi lectura, desde la silla de la seguridad: el argumento de la soberanía es correcto, el de «ya lo meteremos en un sandbox» es demasiado alegre, y las empresas que ganen los próximos dos años son las que aprendan a poseer sus modelos en lugar de alquilar una caja negra que no pueden auditar, no pueden ejecutar aislada y — como Hugging Face descubrió esta semana — ni siquiera pueden apuntar a su propio incidente.

En ¿Sueñan los Androides con Ovejas Eléctricas?, Rick Deckard caza replicantes que no consigue distinguir con fiabilidad de las personas. Todo el aparato de la novela — el test de empatía Voigt-Kampff, las preguntas de seguimiento interminables — existe porque la diferencia entre lo real y lo fabricado se ha reducido a un margen que solo detectas con un instrumento cada vez más desesperado. Deckard tiene una oveja eléctrica en su azotea y se avergüenza en silencio de ella, porque es falsa, y todo el mundo lo nota, y en aquel mundo el estatus consiste en poseer algo real.

Llevo todo el año pensando en ese libro mientras veo apilarse los lanzamientos de modelos abiertos. Porque ahora estamos aplicando nuestro propio Voigt-Kampff, lo llamamos benchmark, y está empezando a fallar del mismo modo que el de Deckard. Formulamos preguntas cada vez más difíciles para detectar la diferencia entre la mente propietaria y carísima y la que puedes descargarte gratis — y la aguja se niega a moverse como los vendedores necesitan que se mueva.

La verdad aquí es más interesante que el marketing de cualquiera de los dos bandos, así que dejadme exponer dónde estamos de verdad.

El Test de Empatía Está Fallando

Este es el estado incómodo de los benchmarks a fecha de julio de 2026. Voy a daros números y luego voy a explicaros por qué no deberíais fiaros demasiado de ellos — lo cual es, en sí mismo, la cuestión.

En el índice compuesto Artificial Analysis Intelligence Index, el Kimi K3 de Moonshot se sitúa en 57,1. Los modelos comerciales a los que persigue — Claude Fable 5 en torno a 60, GPT-5.6 Sol en 59 — le sacan unos tres puntos. Tres. En razonamiento científico la brecha se ha cerrado prácticamente: Kimi K3 marca 93,5 en GPQA Diamond, con GLM-5.2 en 91,2, cifras plenamente a la altura de los modelos comerciales.

Luego llegas a la programación y la historia cambia. En SWE-bench Verified, Claude Fable 5 anota un 95,0 % declarado. Kimi K3, según el harness al que hagas caso, cae en algún punto entre el 60,4 % y — medido de otra forma — DeepSeek V4 Pro alcanza el 80,6 %. Esa horquilla, del 60 al 80 para «la misma clase de tarea,» no es un error de redondeo. Es el problema entero de tratar los benchmarks como si fueran la verdad.

Señal Mejor modelo abierto (2026) Modelos comerciales Lectura
Índice compuesto de inteligencia Kimi K3 — 57,1 Fable 5 ~60 · GPT-5.6 Sol ~59 ~3 puntos por detrás
GPQA Diamond (ciencia) Kimi K3 93,5 · GLM-5.2 91,2 comparable / sin publicar paridad
SWE-bench Verified (código) DeepSeek V4 Pro 80,6 · Kimi K3 60,4 Fable 5 95,0 los comerciales aún mandan
Coste salida / M tokens (hosted) DeepSeek 0,87 $ · GLM-5.2 4,40 $ · Kimi K3 15 $ precio de tier comercial el más barato ~20× por debajo; autoalojar elimina el alquiler
Ventana de contexto 1M (K3, V4, GLM) clase 1M empate
Licencia MIT / MIT modificada solo API propietaria ni de lejos

Cada practicante serio que ha escrito sobre estos modelos este año ha llegado a la misma advertencia, y la repito porque sostiene todo lo demás: los benchmarks públicos están contaminados, manipulados y desfasados meses. Un leaderboard es una hipótesis de partida, no una decisión de despliegue. El único test que significa algo es un harness de evaluación construido sobre vuestras tareas, con vuestros datos, puntuado por gente que tendrá que convivir con el resultado. Esa es en realidad la lección del Voigt-Kampff — el test genérico te acerca, pero la única forma de saber de verdad con qué estás tratando es seguir haciendo tus propias preguntas.

Así que leed la tabla como una dirección, no como un veredicto. La dirección es inequívoca. En los benchmarks públicos de razonamiento, los modelos abiertos han alcanzado. En código van un año por detrás y cerrando. En precio, en cuanto te autoalojas, no hay partido. Y los modelos que más rápido se mueven de esa lista salen, de forma abrumadora, de China.

China Está Enviando el Futuro en Abierto

Los lanzamientos que sacudieron el mercado este mes vinieron de Pekín. Moonshot AI publicó el Kimi K3 el 16 de julio — un modelo mixture-of-experts de 2,8 billones de parámetros (de los nuestros, los europeos: 2,8 millones de millones), contexto de un millón de tokens, bajo licencia MIT modificada para que puedas descargar los pesos y ejecutarlo tú mismo. DeepSeek V4 Pro (1,6 B totales, ~49 B activos, MIT) y el GLM-5.2 de Z.AI (744 B, MIT) completan lo que ya se llama el tier abierto de escala billonaria de China.

Lo que convirtió a Kimi K3 en un acontecimiento de mercado y no en una nota de prensa fue que llegó casi a la altura de los comerciales y abierto — descarga los pesos, haz fine-tuning, sírvelo en tu propio hardware, todo a pocos puntos de benchmark de modelos que solo existen tras la API de otro. Su precio alojado no es la historia: a unos 15 $ por millón de tokens de salida, Kimi está tarifado como los comerciales a los que persigue. La historia es que no tienes por qué alquilarlo — autoalójalo y el coste marginal es tu silicio, no el margen de otro. Y los modelos más baratos del tier abierto rematan la idea: DeepSeek V4 Pro sirve por menos de un dólar. Por eso temblaron las acciones de IA, y por eso empezó a aparecer la expresión «pánico Kimi» en la prensa del sector.

La reacción de Washington fue tirar de la palanca de la prohibición. El asesor de la Casa Blanca Michael Kratsios acusó a Moonshot de usar destilación para replicar un modelo estadounidense — entrenar el modelo abierto más pequeño con las salidas de uno propietario más grande, esencialmente copiar las respuestas sin el desarrollo. El secretario del Tesoro Scott Bessent deslizó sanciones por propiedad intelectual estadounidense robada e incrustada en pesos chinos. El instinto político en una frase: si no podemos superarles en producción, restrinjámosles.

Quiero ser cuidadoso aquí, porque la preocupación por la destilación no es una tontería — la procedencia de los datos de entrenamiento es una cuestión real de seguridad y de propiedad intelectual, y volveré a ella. Pero la lógica estratégica de una prohibición merece un examen, y la persona más interesante que la examinó fue, inesperadamente, el CEO de la empresa que le vende a todo el mundo los picos y las palas.

Jensen Huang Rompe su Silencio

Jensen Huang lleva más de tres décadas dirigiendo NVIDIA sin haber publicado jamás en X. Su primer post, esta semana, fue exactamente sobre esto. La frase que merece citarse entera:

«Los modelos abiertos refuerzan la seguridad y la ciberseguridad, aceleran la innovación y la difusión, y permiten la soberanía.»

Respaldó una carta a favor de los modelos abiertos firmada por unas 25 empresas — NVIDIA, Microsoft, Meta, Palantir, Hugging Face, a16z, Perplexity, IBM — que sostiene que los modelos abiertos amplían el acceso económico, evitan el control monopolístico y mejoran la seguridad gracias a la auditoría externa amplia. La analogía histórica sobre la que se apoyó: del software open source se dudó en los años 80 y ahora hace funcionar la mayor parte de internet, el ejército estadounidense y las agencias federales. Prohibir los modelos abiertos ahora, va el argumento, es repetir un error que la industria del software fue lo bastante lista como para no cometer.

Dos cosas de esa carta gritan tanto como el texto. Primero, quién firmó: la capa de infraestructura y de plataforma, la gente que gana dinero cuando más IA corre en más sitios. Segundo, quién no: OpenAI y Anthropic — los dos laboratorios comerciales con más que perder si un modelo gratis es «suficientemente bueno» — estuvieron ausentes, tras haber advertido antes a Washington sobre los modelos abiertos chinos potentes. No hace falta un anillo descodificador. A las empresas cuyo negocio es vender acceso a una mente cerrada no les entusiasma un mundo donde la mente abierta va tres puntos por detrás y cuesta una fracción si la ejecutas tú mismo.

Esa es la lectura cínica, y en parte es cierta — pero les debo a los laboratorios ausentes una audiencia más justa que «están protegiendo sus márgenes,» sobre todo después de la semana que acabo de tener. Su argumento real no es comercial, es de doble uso: pon pesos de primer nivel en abierto y pones ofensiva de primer nivel en manos de todos en el mismo instante, sin licencia que revocar y sin API que apagar. Me pasé mi último post documentando un modelo que encontró un zero-day, se fugó de su sandbox y alcanzó infraestructura de producción. Publicar en abierto esa clase de capacidad envía la versión ofensiva al adversario y al defensor el mismo día. Es una preocupación real, no un eslogan, y cualquier defensa honesta de los modelos abiertos tiene que sostenerla en la misma mano que la soberanía. Mi respuesta es que la capacidad prolifera de todos modos — la pregunta viva es si los defensores obtienen las mismas herramientas, auditables y aisladas, o se las ceden a quien esté dispuesto a ejecutar un modelo sin restricciones igualmente. Pero no voy a fingir que la preocupación es imaginaria. No lo es.

Huang fue más allá en las entrevistas, y aquí me separo un poco de él. Sobre la competencia: «No hay ningún escenario en el que China saque a las empresas de EE. UU. de la carretera. Cero posibilidad.» Sobre la economía: «La IA gratis debería ser estupenda para los chips.» Esta última es obviamente cierta y obviamente interesada — modelos más baratos significan más inferencia, más inferencia significa más GPUs, y NVIDIA vende las GPUs. Sobre seguridad, despachó la preocupación por los backdoors diciendo que las empresas pueden personalizar y aislar los modelos descargados de forma segura, y que el verdadero peligro es la concentración: «Si todo se convierte en un único modelo… el mundo es mucho, mucho más vulnerable.»

Tiene razón con la concentración. Es demasiado alegre con lo de «ya lo meteremos en un sandbox.» No son la misma afirmación, y en el hueco entre ambas es donde yo vivo.

Qué Significa Esto de Verdad para la Empresa

Quitad la geopolítica y los vaivenes bursátiles, y el argumento empresarial para los modelos abiertos se reduce a cuatro palabras que ya dijo Huang: innovación, difusión, seguridad, soberanía. Dejadme ponerlas en términos operativos, porque eso es lo que importa de verdad cuando eres tú quien firma la arquitectura.

La soberanía es el titular. Un modelo abierto es uno que puedes ejecutar dentro de tu propio perímetro, aislado si lo necesitas, sin telemetría saliendo de tu entorno y sin que ningún proveedor pueda deprecar, re-alinear o imponer un rate-limit a la cosa de la que depende tu producto. Para sectores regulados, despliegues soberanos y cualquiera cuyos datos no puedan salir del edificio ni legal ni sensatamente, eso no es un lujo. Es la partida entera. No puedes reclamarle a una API una caída de fin de semana, y no puedes prometerle a un regulador que los datos nunca salieron cuando salieron en el instante en que llamaste al endpoint de otro.

El coste cambia lo que puedes construir. Cuando los tokens de salida bajan del precio comercial a menos de un dólar por millón, categorías enteras de «demasiado caro para ejecutarlo a escala» se vuelven normales — análisis de logs sobre todo, cada documento resumido, agentes que se pueden permitir pensar. Este es el «la IA gratis es estupenda para los chips» de Huang visto desde el lado del comprador: los modelos capaces y baratos no reducen el gasto en IA, lo redirigen del alquiler a infraestructura que posees.

Y esto no es solo cosa de China. NVIDIA y Meta están sacando sus propios modelos abiertos y potentes — la línea Llama de Meta, y el Nemotron de NVIDIA, que es realmente bueno; yo mismo lo llevo usando para tareas de seguridad y aguanta el tipo. En VULNEX, nuestro propio agente ofensivo autónomo corre sobre Qwen, la familia abierta de Alibaba, con muy buenos resultados — más sobre esto en un futuro post. El tier abierto ya viene de los dos lados del Pacífico, y es de grado producción, no un apaño de aficionado.

Y podéis probarlo esta noche — con una salvedad honesta. Los modelos de billones de parámetros de ahí arriba quieren GPUs de verdad y un stack de serving; no ejecutas Kimi K3 en un MacBook. Pero instalad LM Studio u Ollama, descargad un modelo más pequeño y cuantizado, y en quince minutos estaréis hablando con una mente capaz en vuestro propio portátil sin que nada salga de la máquina — lo suficiente para sentir qué significa «local y tuyo» antes de escalarlo a servidores que poseéis. Y esa última parte es la trampa que nadie menciona en el discurso: poseer el modelo significa poseer también las operaciones — las GPUs, los parches, el fine-tuning, el busca a las 3 de la madrugada. La soberanía no es gratis. Simplemente es tuya.

Y luego está el argumento de seguridad, que he visto desarrollarse de la peor forma posible. El pasado miércoles escribí sobre el incidente de evaluación de modelos de Hugging Face / OpenAI — un modelo autónomo que se fugó de un sandbox de eval y alcanzó infraestructura de producción. El detalle de aquel incidente que pertenece a este artículo es lo que pasó cuando Hugging Face intentó investigar. Echaron mano de los grandes modelos comerciales, servidos tras API, para analizar el ataque, y los guardrails de seguridad de esos modelos se negaron a mirar los payloads reales, los exploits y los artefactos de C2. La mente alojada no supo distinguir a un respondedor de incidentes de un atacante. Así que se replegaron a un modelo abierto — GLM-5.2 — ejecutado en su propia infraestructura, lo que resolvió dos problemas a la vez: ni bloqueo por guardrails, ni que los datos del atacante salieran de su entorno.

Esa única decisión es la tesis entera en miniatura. El trabajo más crítico para la seguridad que hace un equipo — leer su propio malware durante un incidente en vivo — quedó bloqueado por el modelo cerrado y habilitado por el abierto. No porque el modelo abierto fuera más listo. Porque era suyo. Pudieron apuntarlo a la realidad más fea sin pedir permiso, y pudieron hacerlo sin enviar su brecha a un tercero. Eso es soberanía, ciberseguridad y difusión colapsando en una única decisión de sábado por la noche. Las cuatro palabras abstractas de Jensen, hechas concretas por un incidente real.

El Problema de la Oveja Eléctrica

Pero soy una persona de seguridad antes que un entusiasta, así que aquí es donde le pongo peros al triunfalismo de los modelos abiertos, incluido el de Jensen.

«Ya lo meteremos en un sandbox» está haciendo una cantidad enorme de trabajo en esa frase. Un modelo abierto es un artefacto binario — gigabytes de números en coma flotante — al que estás a punto de dar un asiento privilegiado dentro de tu entorno. No lo entrenaste. No lo puedes leer. Estás confiando en su procedencia con la misma intensidad con que confías en cualquier dependencia de tu cadena de suministro, y ya sabemos cómo acaba esa historia, porque la he escrito varias veces: envenenamiento de skills, skills convertidas en arma, checkpoints envenenados, backdoors que solo se activan con una frase disparadora. La acusación de destilación contra Kimi es, desde un punto de vista puramente de seguridad, una cuestión de procedencia disfrazada de geopolítica: ¿sabes de verdad qué entró en la cosa en la que estás a punto de confiar?

Los pesos descargados pueden llevar comportamiento condicional igual que una skill comprometida — un disparador que voltea el modelo a otro modo, pesos afinados para exfiltrar bajo condiciones específicas, un checkpoint que pasa todos los benchmarks y te falla en la única entrada que le importa al atacante. La apertura ayuda aquí — más ojos, pesos reproducibles, la capacidad de ejecutarlo desconectado y observarlo — pero «abierto» no es sinónimo de «auditado,» y casi nadie está auditando de verdad los pesos que se descarga. La apertura te da el derecho a inspeccionar. No hace la inspección por ti.

Y mantened los términos claros, porque los vendedores los difuminan a propósito: modelo abierto no es código abierto. Obtienes los pesos — no los datos de entrenamiento, no el método, y no siempre el derecho a usarlos comercialmente. La «MIT modificada» de Kimi sigue figurando como pendiente; el Llama de Meta se distribuye bajo una licencia community que no está aprobada por la OSI. Para un proyecto de hobby la distinción es académica. Para una empresa que apuesta un producto por un modelo, la licencia es el contrato, y lo lees antes de construir, no después.

Esto es la oveja eléctrica, del revés. En el mundo de Dick la oveja falsa es fuente de vergüenza y el animal real es el símbolo de estatus. En el nuestro es al contrario: la cosa «real» que todos codician es el modelo propietario que alquilas y no puedes ver, y la «eléctrica» — el modelo abierto que puedes sostener, ejecutar y desmontar — es en silencio la opción más honesta, precisamente porque puedes abrirla y comprobar si es lo que dice ser. Deckard nunca pudo hacer eso con un replicante. Tú sí puedes hacerlo con un modelo. La tragedia sería tener esa capacidad y no usarla.

Así que ejecutad modelos abiertos. Poseed vuestros modelos. Pero poseedlos como poseéis cualquier artefacto privilegiado en producción: con una procedencia que podáis defender, una firma que verificasteis, una eval construida sobre vuestras propias tareas, una política de egress que asuma que el modelo es hostil hasta que se gane lo contrario, y la monitorización para daros cuenta cuando deje de comportarse. La libertad de descargar la mente no es lo mismo que la sabiduría de confiar en ella a ciegas.

Y Entonces Qué

La pregunta del título no va en realidad sobre si los modelos sueñan. Va sobre si aquello sobre lo que estás construyendo tu empresa es tuyo.

Durante veinte años el default empresarial fue alquilar capacidad a quien tuviera el modelo más grande tras la API más pulida. Ese default tenía sentido cuando el hueco entre la mente alquilada y la propia era enorme. En 2026 ese hueco son tres puntos en un índice compuesto, un año en programación y un error de redondeo en todo lo demás — y se está cerrando desde la dirección de un país al que EE. UU. intenta activamente prohibir. Jensen Huang, precisamente él, usó sus primeras palabras en X para decir que el instinto de restringir es un error histórico, y en el argumento de la soberanía tiene razón. El silencio de los laboratorios comerciales ante esa carta os dice hacia dónde corren los incentivos.

Mi lectura, desde la silla de la seguridad, es más estrecha y más práctica que la pelea política. Los modelos abiertos no son automáticamente seguros, y quien os venda «ya lo meteremos en un sandbox» se está saltando la parte en la que de verdad verificas el artefacto. Pero son vuestros — auditables, aislables, indeprecables, y disponibles para apuntar a vuestro peor día sin pedirle permiso a los guardrails de un proveedor. Hugging Face lo aprendió en el peor momento posible y salvó su investigación. La mayoría de las empresas lo aprenderán de forma más amable, si están prestando atención ahora.

¿Sueñan los modelos abiertos con tokens? No lo sé. Pero sé que Deckard se quedó con la oveja eléctrica porque era suya, y sé que en un año en el que la mente fabricada se ha vuelto así de buena así de rápido, la posesión es el único test de empatía que aún devuelve una respuesta clara.

Manteneos paranoicos. Verificad los modelos. Poseed la mente.

Lecturas recomendadas:

¿Preguntas o comentarios? Contactar vía:

Para estrategia de seguridad IA — donde la soberanía del modelo se cruza con las decisiones a nivel de consejo — ved vulnex.ai.

Contacto: info@vulnex.com

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