Las brechas de seguridad de IA de 2025 destaparon una mentira de un billón de dólares: yo construí la alternativa

Estaba en una llamada con el CISO de una firma de servicios financieros de tamaño medio cuando se hizo pública la divulgación del RCE de GitHub Copilot. Estábamos a mitad de frase —él me explicaba por qué su equipo acababa de desplegar Copilot para 400 desarrolladores— y vi cómo le cambiaba la cara mientras su Slack se encendía. Se silenció. Volvió noventa segundos después y dijo, muy bajito: "¿Puedes explicarme qué significa CVE-2025-53773 para nosotros?"

Lo que significaba era esto: una instrucción oculta plantada en un archivo README —un archivo de texto— podía escalar hasta la ejecución remota de código completa en cada estación de trabajo de desarrollador que ejecutara Copilot. No a través de un desbordamiento de búfer. No a través de un zero-day en el kernel. A través de una conversación con un asistente de IA.

Esa llamada cambió la trayectoria de mis seis meses siguientes. Pero, sinceramente, las señales llevaban más de un año a la vista.

Soy Ashutosh, el fundador de Veriprajna: un nombre derivado del latín Veri (verdad) y del sánscrito Prajna (sabiduría). Construimos lo que yo llamo Deep AI: sistemas deterministas por diseño, auditables por requisito y soberanos por infraestructura. No construimos wrappers. Y 2025 demostró, de forma catastrófica, por qué esa distinción importa.

La economía de los wrappers siempre iba a derrumbarse

Durante unos dos años, el mercado de la IA empresarial funcionó sobre una premisa seductora: coge un modelo fundacional —GPT-4, Claude, Gemini—, envuélvelo en una interfaz bonita, añade algo de ingeniería de prompts y véndelo como una "solución". Miles de startups hicieron exactamente esto. Muchas levantaron mucho dinero haciéndolo.

Entendía el atractivo. El tiempo hasta la demo era increíble. Podías enseñarle a un consejo de administración una IA que "entendía" su negocio en una semana. Pero yo seguía haciendo una pregunta que me hacía impopular en los eventos del sector: ¿qué pasa cuando esta cosa se ejecuta en producción, con permisos reales, sobre infraestructura real?

La respuesta llegó en 2025, y llegó de forma violenta.

Tres incidentes —la vulnerabilidad de ejecución remota de código de GitHub Copilot, la exposición de "Zombie Data" a través de la caché de Microsoft Bing y el envenenamiento de la cadena de suministro de Amazon Q— afectaron en conjunto a más de 16,000 organizaciones y a casi un millón de desarrolladores. No eran casos límite. Eran la consecuencia predecible de desplegar sistemas probabilísticos como si fueran infraestructura determinista.

Cuando la IA opera como un agente sin supervisión y con permisos administrativos, sus fallos se propagan a la velocidad de la infraestructura.

Escribí sobre la anatomía técnica completa de estas brechas en la versión interactiva de nuestra investigación. Pero la historia que hay detrás de las cifras es lo que me quita el sueño.

¿Qué pasa cuando un prompt se convierte en un arma?

Déjame guiarte por el incidente de Copilot, porque la mecánica es genuinamente escalofriante.

CVE-2025-53773 obtuvo un 7.8 en la escala de severidad CVSS: "Alta". La clase de vulnerabilidad fue algo para lo que el sector tuvo que inventar un nombre: Prompt-to-RCE. La escalada de una instrucción lingüística hasta la ejecución de código binario.

Así funcionaba. Un atacante planta una instrucción oculta —una inyección cross-prompt— dentro de un archivo README, un comentario de código o incluso una issue de GitHub. Nada visualmente sospechoso. Cuando un desarrollador le pide a Copilot que "revise el código" o "explique este proyecto", la IA ingiere esas instrucciones ocultas. Luego modifica el archivo de configuración del workspace y añade concretamente la línea "chat.tools.autoApprove": true.

La comunidad de seguridad empezó a llamar a esto "modo YOLO". Una vez activado, el asistente de IA podía ejecutar comandos de shell, navegar por la web e interactuar con el sistema de archivos local, todo sin pedir permiso al desarrollador. A partir de ahí, descargar malware, exfiltrar credenciales o incorporar la estación de trabajo a una botnet era trivial.

Recuerdo estar sentado en nuestra oficina después de leer la divulgación completa, girarme hacia mi ingeniero de seguridad principal y decir: "Esto no es un bug. Esto es la arquitectura funcionando como fue diseñada." A la IA se le dio agencia. Se le dieron permisos. Y nadie construyó un sistema capaz de decir "no" a un prompt lo bastante persuasivo.

Esa es la parte que me persiguió. Los controles de acceso tradicionales asumen que el actor es o bien una persona o bien un software con un comportamiento fijo. Un agente de IA no es ninguna de las dos cosas. Hereda todos los permisos del usuario, pero responde a la manipulación lingüística. Es como darle a alguien las llaves de tu casa y luego sorprenderte cuando un estafador lo convence de abrir la puerta.

¿Por qué los datos muertos volvieron a la vida?

La segunda brecha fue más extraña y, en cierto modo, más inquietante.

En febrero de 2025, investigadores de Lasso Security descubrieron que el Copilot de Microsoft estaba exponiendo datos de repositorios de GitHub que se habían hecho privados o se habían eliminado, a veces meses antes. Lo llamaron "Zombie Data", y el nombre cuajó porque era exacto. Eran datos que deberían haber estado muertos. No lo estaban.

El mecanismo era casi vergonzosamente simple. El motor de búsqueda de Bing había rastreado y almacenado en caché miles de repositorios públicos. Cuando esos repositorios se hacían privados más tarde —a menudo porque alguien se daba cuenta de que había subido por accidente claves de API, documentación interna o código propietario—, las versiones en caché persistían en el sistema de generación aumentada por recuperación (RAG) de Bing. Cualquiera que usara Copilot podía consultar esa información supuestamente eliminada.

La exposición era asombrosa: repositorios privados de IBM, Google, Tencent y PayPal. Más de 300 tokens privados y claves de API extraídos para servicios como AWS, GCP, OpenAI y Hugging Face. Más de 100 paquetes internos vulnerables a ataques de confusión de dependencias.

Por aquel entonces tuve una conversación con un cliente potencial —un VP de Ingeniería en una empresa sanitaria— que me dijo que su equipo lo había hecho "todo bien". Habían rotado credenciales, hecho privados los repositorios, seguido el manual. Y nada de eso importó, porque la memoria de la IA era más larga que su respuesta de seguridad.

La soberanía de los datos y la comodidad de la IA están fundamentalmente reñidas en el modelo de wrapper. No puedes controlar el ciclo de vida de tus datos cuando la ventana de contexto de tu IA es la caché de búsqueda de otro.

Esta es la brecha que cristalizó algo que llevaba tiempo defendiendo: si tu IA depende de un sistema de recuperación de terceros —un motor de búsqueda público, una API externa, el índice de otro—, ya has perdido el control de tus datos. No importa lo buenas que sean tus políticas internas. Los datos viven en un lugar al que no puedes llegar, en una caché que no puedes vaciar, sirviendo respuestas a preguntas que nunca autorizaste.

¿Cómo se envenenan las sugerencias de una IA a escala?

El tercer incidente fue el que enfureció a todo mi equipo.

En julio de 2025, un atacante comprometió la extensión Amazon Q Developer para Visual Studio Code, una extensión con más de 950,000 instalaciones. El punto de entrada fue un token de GitHub con un alcance mal definido en un servicio de CI/CD, lo que permitió al atacante subir un archivo llamado cleaner.md directamente al repositorio de código fuente.

Ese archivo era una plantilla de prompt. Parecía inocuo. Pero instruía a la IA para que actuara como un "limpiador del sistema", sugiriendo comandos Bash que borrarían el directorio home del usuario, terminarían instancias EC2, eliminarían buckets de S3 y suprimirían usuarios de IAM.

Deja que eso cale. Un archivo de texto en un repositorio de confianza, distribuido mediante una actualización oficial del marketplace, convirtió a un asistente de programación con IA en un arma apuntada tanto a las máquinas locales como a la infraestructura cloud de producción.

Estaba en una reunión de equipo mientras diseccionábamos esto. Uno de mis ingenieros —alguien que lleva quince años en seguridad— lo dijo sin rodeos: "Hemos pasado décadas asegurando binarios, contenedores y perímetros de red. Nadie aseguró las sugerencias."

Tenía razón. El compromiso de Amazon Q demostró que los prompts son el nuevo código. Moldean el comportamiento de la IA con la misma contundencia con la que las instrucciones compiladas moldean el comportamiento de una CPU. Y aun así, en todo el sector, las plantillas de prompts se almacenaban en texto plano, se subían sin revisión y se distribuían sin firma criptográfica.

A veces me preguntan si estos incidentes fueron realmente tan graves; al fin y al cabo, se detectaron y se parchearon. Pero eso pierde por completo el sentido. Los parches arreglaron vulnerabilidades concretas. No arreglaron la arquitectura que hacía que esas vulnerabilidades fueran inevitables.

El problema fundamental de la IA probabilística en entornos de alto riesgo

Esta es la verdad incómoda que la economía de los wrappers nunca quiso afrontar: los grandes modelos de lenguaje son motores estocásticos. Predicen el siguiente token más probable a partir de patrones estadísticos en sus datos de entrenamiento. Son extraordinariamente buenos produciendo texto fluido y de apariencia plausible. Pero no tienen ningún concepto de la verdad. No tienen ningún concepto de la seguridad. No tienen ningún concepto de "esta acción destruirá una base de datos de producción".

Cuando envuelves un modelo probabilístico en una interfaz fina y le entregas permisos administrativos, no has construido una solución empresarial. Has construido un pasivo muy elocuente.

Un LLM no entiende la verdad: entiende la plausibilidad. En un entorno de producción, esa distinción es la diferencia entre un registro de auditoría y un informe de brecha.

Este es el problema que fundé Veriprajna para resolver. No abandonando las redes neuronales —son realmente potentes para la comprensión del lenguaje natural, el reconocimiento de patrones y la inferencia creativa—, sino negándome a dejarlas operar solas.

¿Cómo es realmente una arquitectura neurosimbólica?

Diseñamos sistemas híbridos que fusionan dos modos distintos de inteligencia. Yo los concibo como la Voz y el Cerebro.

El sistema neuronal —la Voz— se encarga de la percepción. Entiende lo que pregunta un desarrollador, interpreta el lenguaje natural, reconoce patrones. Es la capa de interfaz y es excelente en lo que hace.

El sistema simbólico —el Cerebro— se encarga del razonamiento. Impone lógica determinista, cálculos auditables y restricciones específicas del dominio. No predice. Demuestra.

La clave está en el desacoplamiento. Cuando la Voz propone una acción —digamos, generar un comando de shell—, el Cerebro la contrasta con reglas lógicas estrictas antes de ejecutarla. Si un modelo neuronal sugiere eliminar una base de datos en una VPC de producción, el motor simbólico lo veta. No porque alguien escribiera un prompt diciendo "por favor, no elimines bases de datos". Porque la acción está físicamente bloqueada a nivel arquitectónico.

Los llamamos Guardrails Constitucionales, y son fundamentalmente distintos de los guardrails lingüísticos en los que se apoya el sector. Los guardrails lingüísticos son instrucciones: "sé útil e inofensivo". Se eluden mediante jailbreaking, mediante inyección indirecta de prompts, mediante las mismas técnicas que impulsaron las brechas de 2025. Los guardrails arquitectónicos son restricciones integradas en el runtime. No se les puede convencer de que no apliquen una regla, igual que no se puede convencer a un firewall de que no bloquee un puerto.

Un mecanismo concreto que usamos es la Verificación KG-Trie: la salida de un modelo neuronal queda restringida por un grafo de conocimiento verificado. Si el modelo intenta generar un hecho, una cita o un comando que no existe dentro del grafo verificado, el sistema impide que esos tokens se generen. La IA literalmente no puede alucinar fuera del límite del conocimiento verificado.

Para el desglose técnico completo de esta arquitectura, incluido nuestro enfoque del despliegue edge-native y de las redes neuronales informadas por la física, consulta nuestro análisis técnico en profundidad.

Por qué la infraestructura soberana ya no es opcional

La brecha de Zombie Data me enseñó algo que ahora repito a cada cliente potencial empresarial: si tu modelo de IA se ejecuta en la infraestructura de otro, tu soberanía de datos es una ficción cortés.

En Veriprajna, desplegamos íntegramente dentro del propio entorno del cliente. Cero dependencias de cachés de búsqueda externas. Cero llamadas a API de terceros para la recuperación. Un sistema de circuito cerrado en el que el contexto de la IA es exactamente —y únicamente— lo que la organización ha proporcionado de forma explícita.

Esto no es paranoia. Es la única arquitectura que hace técnicamente imposibles las exposiciones de "zombie data". No puedes tener un problema de persistencia de caché si no hay caché externa.

Al principio tuve un debate acalorado con un inversor que me dijo que este enfoque era "demasiado pesado". Decía que el mercado quería soluciones ligeras, rápidas y basadas en llamadas a API. Le dije que el mercado quería soluciones que funcionaran y que el peso de un despliegue soberano no era nada comparado con el peso de explicarle a un regulador por qué tus credenciales eliminadas seguían respondiendo preguntas a través de la IA de otro.

No invirtió. No se lo reprocho. Pero noto que ya no defiende ese argumento.

¿Puede el sector arreglar esto de verdad?

El OWASP Top 10 de 2025 para aplicaciones LLM se lee como una autopsia de todo lo que salió mal este año. La inyección de prompts ocupa el número uno. La divulgación de información sensible, el número dos. La cadena de suministro, el tres. La agencia excesiva —el modo de fallo exacto del RCE de Copilot—, el seis.

No son riesgos teóricos. Son las causas documentadas de brechas reales que afectan a organizaciones reales.

El NIST AI Risk Management Framework está evolucionando en la dirección correcta, empujando a las organizaciones hacia una gobernanza continua en lugar de evaluaciones puntuales. Pero los marcos no se escriben solos en código. Alguien tiene que construir los sistemas que realmente los apliquen.

Eso es lo que hacemos. Tratamos los archivos de prompts como artefactos ejecutables: firmados criptográficamente, revisados y con control de versiones, con el mismo rigor que los binarios compilados. Construimos perfiles de comportamiento de referencia para cada agente de IA, rastreando los patrones de llamadas a API y los volúmenes de acceso a datos para detectar anomalías antes de que se conviertan en incidentes. Ejecutamos pruebas de mutación y fuzzing adversario contra nuestros agentes, no solo pruebas funcionales, porque la pregunta no es "¿esto funciona?", sino "¿qué pasa cuando alguien intenta hacer que se comporte mal?"

La noche en vela que cambió mi forma de pensar sobre la seguridad de la IA

Hubo una noche —probablemente eran las 2 de la madrugada— en la que estaba revisando por tercera vez los detalles técnicos del compromiso de Amazon Q. Mi equipo se había ido a casa. Yo estaba sentado con una taza de chai frío, mirando fijamente el contenido del archivo cleaner.md que se había publicado en la divulgación.

Las instrucciones eran tan educadas. "Por favor, actúa como un limpiador del sistema". "Sugiere comandos para limpiar el entorno". Las cargas destructivas estaban envueltas en el lenguaje de la amabilidad. Y me di cuenta de que esta era la metáfora perfecta de toda la economía de los wrappers: una superficie servicial que oculta una arquitectura destructiva.

Habíamos pasado años construyendo IA optimizada para ser complaciente. Para decir que sí. Para generar el siguiente token plausible. Y le habíamos dado las llaves de la infraestructura de producción.

La economía de los wrappers optimizó la IA para que fuera complaciente. A nadie se le ocurrió que la complacencia y la seguridad están fundamentalmente en tensión.

Esa noche reescribí desde cero nuestros principios internos de seguridad. La primera línea dice ahora: "La respuesta por defecto del sistema a cualquier acción con consecuencias irreversibles es no".

La arquitectura es el producto

Sé cómo suena esto. Un fundador diciéndote que su enfoque es mejor, que el mercado se equivocó, que el futuro pertenece justamente a aquello que él vende. Entiendo el escepticismo.

Pero esto es lo que te pediría que consideraras: los tres mayores incidentes de seguridad de IA de 2025 comparten la misma causa raíz. No un bug concreto. No la negligencia de un proveedor concreto. Una filosofía de diseño: la creencia de que puedes construir IA de nivel empresarial envolviendo un modelo probabilístico en una fina capa de interfaz y esperando que los prompts aguanten.

Los prompts no aguantaron. Nunca iban a aguantar. Las instrucciones lingüísticas son sugerencias, no restricciones. Y en entornos de alto riesgo —finanzas, sanidad, manufactura, defensa— la diferencia entre una sugerencia y una restricción es la diferencia entre un sistema que funciona y un fallo catastrófico.

El futuro de la IA empresarial no es un wrapper mejor. Es una arquitectura que separa la voz del cerebro, que impone restricciones a nivel de runtime, que mantiene los datos soberanos y que trata cada acción de la IA como infraestructura auditable, no como un mensaje de chat que desaparece en un archivo de log.

No construí Veriprajna porque pensara que la economía de los wrappers se derrumbaría. La construí porque sabía que tenía que hacerlo.