Evaluación de seguridad y endurecimiento

Nuestro enfoque consiste en vulnerar los sistemas de IA del mismo modo que lo hacen los atacantes reales, para luego endurecerlos frente a las vías de ataque que descubre una evaluación — desde la extracción de modelos hasta el compromiso de la cadena de suministro. Las pruebas de penetración tradicionales cubren sus API, infraestructura y flujos de autenticación, pero nunca comprueban si un atacante puede robar su modelo ajustado, introducir una puerta trasera en su cadena de dependencias o secuestrar su canalización de RAG. Esa metodología de evaluación debe diseñarse específicamente para los modos en que fallan los sistemas de IA.

Superficies de ataque que su equipo de seguridad nunca ha probado

Las pruebas de penetración tradicionales cubren sus API, su infraestructura y sus flujos de autenticación. No evalúan si un atacante puede extraer su modelo ajustado mediante 50,000 consultas cuidadosamente estructuradas. No detectan si un adaptador LoRA en su cadena de dependencias de HuggingFace introdujo una puerta trasera hace tres meses. No evalúan si su canalización de RAG ejecutará instrucciones incrustadas en un documento recuperado. Estas son las vías de ataque que realmente comprometen los sistemas de IA en producción.

Estos no son riesgos teóricos de ponencias en conferencias. Protect AI descubrió 352,000 archivos sospechosos en 51,700 modelos en HuggingFace en abril de 2025. Los ataques habilitados por IA aumentaron un 89% interanual, con un 97% de las organizaciones vulneradas careciendo de controles de acceso básicos en sus sistemas de IA. El ataque a la cadena de suministro de Mercor a principios de 2026 comprometió a miles de empresas a través de una única dependencia de código abierto.

Qué probamos realmente — y qué pasan por alto la mayoría de las evaluaciones

Estructuramos las evaluaciones en torno al marco MITRE ATLAS , que ahora cataloga 84 técnicas en 16 tácticas dirigidas específicamente a sistemas de IA. Pero un marco es un mapa, no una prueba. Nuestra metodología está diseñada para ejecutar los ataques que cataloga, no solo para marcarlos en una lista de verificación.

Despliegues de LLM e inyección de prompts

Probamos la inyección indirecta de prompts a través de cada vía de ingesta: recuperación de RAG, salidas de herramientas, documentos cargados por usuarios y contenido de correo electrónico suministrado a los agentes. La inyección directa acapara los titulares, pero Anthropic descartó por completo su métrica de inyección directa en febrero de 2026 porque la inyección indirecta a través del contexto de recuperación es lo que realmente vulnera los sistemas en producción. También probamos la manipulación en múltiples turnos, la extracción de prompts del sistema y los modos de fallo específicos de cualquier pila de guardrails que tenga implementada.

Seguridad a nivel de modelo

Evaluamos el riesgo de extracción ejecutando campañas de consultas estructuradas contra su API y midiendo qué parte del comportamiento del modelo puede replicar un atacante. Evaluamos la robustez adversarial tanto con métodos basados en gradientes (cuando tenemos acceso al modelo) como con ataques de caja negra basados en transferencia (cómo operan los atacantes reales). Auditamos su canalización de entrenamiento en busca de vulnerabilidades de envenenamiento de datos, comprobando tanto sus datos de entrenamiento directos como las dependencias ascendentes que los alimentan (detallado en nuestra investigación sobre la protección de empresas frente al envenenamiento de modelos).

Integridad de la cadena de suministro

Rastreamos cada artefacto de modelo hasta su origen: pesos preentrenados, conjuntos de datos de ajuste fino, capas de adaptadores y versiones del marco de servicio. Comprobamos vulnerabilidades conocidas en su infraestructura de ML — PyTorch, vLLM y Triton Inference Server tuvieron CVE en 2025–2026 — y verificamos que la serialización de sus modelos utilice formatos seguros. Los $12 mil millones en pérdidas por modelos de ML comprometidos en 2025 procedieron abrumadoramente de ataques a la cadena de suministro, no de la explotación directa de modelos (consulte nuestra investigación sobre la seguridad del ciclo de vida de la cadena de suministro de ML).

Sistemas agénticos

Probamos la superficie de ataque que el Top 10 de IA agéntica de OWASP define: secuestro de objetivos, uso indebido de herramientas, abuso de identidad, envenenamiento de memoria y fallos en cascada en flujos de trabajo multiagente. La crisis de OpenClaw en 2026 — en la que 21,000+ instancias de un agente de IA con 135,000 estrellas quedaron expuestas a vulnerabilidades críticas — demostró lo que sucede cuando los agentes se entregan sin estas pruebas (detallado en nuestra investigación sobre la protección de la frontera humano-IA).

Endurecimiento que transforma cómo opera su sistema

Una evaluación sin remediación es un PDF costoso. Nuestro enfoque integra los controles de endurecimiento directamente en su sistema.

• Defensa en la capa de inferencia: detección de anomalías en consultas que identifica el tráfico con patrones de extracción — cobertura sistemática de entradas, sondeo de límites y barridos programáticos de paráfrasis — y lo distingue del uso legítimo. Las canalizaciones de validación de entradas se ajustan a su modelo de amenazas específico, no a filtros regex genéricos que pasan por alto ataques semánticos y bloquean consultas legítimas.
• Endurecimiento de la cadena de suministro: canalizaciones de verificación de modelos que comprueban la procedencia de artefactos, validan formatos de serialización, escanean en busca de patrones maliciosos conocidos y aplican requisitos de firma antes de que cualquier artefacto de modelo entre en su canalización de despliegue — además de una monitorización de dependencias que detecta paquetes ascendentes comprometidos antes de que lleguen a producción.
• Endurecimiento de sistemas agénticos: límites de privilegios en torno al acceso a herramientas, validación de salidas entre los pasos del agente y monitorización del comportamiento que detecta cuándo el patrón de ejecución de un agente difiere de su flujo de trabajo previsto.

Su SIEM fue diseñado para detectar anomalías en el comportamiento humano. Un agente que ejecuta 10,000 consultas en secuencia parece normal para esos sistemas, incluso cuando opera bajo el control de un atacante.

Cuándo no necesita esto

Si utiliza una API gestionada (OpenAI, Anthropic, Google) sin ajuste fino, sin RAG, sin uso de herramientas y sin datos sensibles en los prompts, su riesgo de seguridad se limita a la gestión de claves de API y el tratamiento de datos. Una revisión estándar de seguridad de aplicaciones cubre eso — no necesita una evaluación específica de IA.

Si su modelo es un clasificador simple que se ejecuta internamente sin una API orientada al exterior y sin una canalización de reentrenamiento, su superficie de ataque es limitada y una breve revisión del modelo de amenazas es proporcionada. Realizar pruebas completas de robustez adversarial en un clasificador de sentimientos interno detrás de un cortafuegos equivale a gastar $30,000 para proteger un riesgo de $500.

Decimos esto con total claridad porque la credibilidad importa más que los ingresos. Las organizaciones que necesitan este trabajo saben quiénes son: cualquiera que disponga de modelos ajustados, canalizaciones de RAG que procesen contenido externo, sistemas agénticos con acceso a herramientas, modelos en sectores regulados o sistemas de IA que tomen decisiones con consecuencias financieras o de seguridad.

La presión regulatoria es real y tiene plazos

La aplicación de la Ley de IA de la UE comienza en agosto de 2026. Los sistemas de IA de alto riesgo requieren una gestión de riesgos documentada, pruebas de robustez técnica y controles de gobernanza de datos. El incumplimiento conlleva multas de hasta el 7% de la facturación anual global o EUR 35 millones. El NIST publicó su Perfil del Marco de Ciberseguridad para IA en diciembre de 2025, asignando los riesgos específicos de la IA a los controles del CSF 2.0. Estos marcos ahora están apareciendo en los requisitos de adquisiciones y en las revisiones de riesgos a nivel de junta directiva.

El desafío es que ningún marco por sí solo cubre todo. Mapeamos los hallazgos de su evaluación a cualquier marco que sus reguladores, auditores y clientes requieran — generando evidencia que satisface los requisitos de cumplimiento porque proviene de pruebas reales, no de ejercicios de marcar casillas.

Herramientas de plataforma frente a evaluación personalizada

Las plataformas automatizadas de seguridad de IA (HiddenLayer, Mindgard, Giskard) ejecutan patrones de ataque conocidos a escala. Son útiles para pruebas continuas de regresión después de una evaluación inicial, pero no sustituyen a la evaluación inicial en sí misma. Un escáner no comprende su lógica de negocio, no sabe qué salidas del modelo conllevan consecuencias críticas para la seguridad y no puede evaluar si su modelo de amenazas coincide con su arquitectura de despliegue real.

Utilizamos estas herramientas donde aportan valor. El red teaming automatizado continuo pertenece a su canalización de CI/CD una vez que hemos establecido qué probar. Pero las vías de ataque más importantes en su sistema específico requieren a alguien que comprenda tanto los modos de fallo de la IA como su contexto operativo para encontrarlas.

Para las organizaciones que operan con múltiples proveedores de IA (OpenAI, Anthropic, Google, modelos de código abierto), evaluamos los límites de seguridad de cada proveedor de forma independiente y probamos los puntos de integración por donde fluyen los datos entre ellos. La superficie de ataque de una pila de múltiples proveedores no es la suma del riesgo de cada proveedor: es la capa de interacción, donde las suposiciones sobre las garantías de seguridad de un proveedor se desmoronan en el traspaso hacia otro.