Resumen ejecutivo
La seguridad de los modelos de frontera no es «la seguridad del chatbot»: es la defensa del sistema completo que convierte un modelo capaz en un producto seguro. Gustavo Venegas explica el cambio de pregunta que define la disciplina —de «¿el modelo contesta algo malo?» a «¿qué puede lograr un actor usando este sistema?»—, mapea la superficie de ataque real (prompts, datos, herramientas, cadena de suministro e infraestructura), muestra cómo trabajan los laboratorios líderes y cómo se ejecuta un red team de IA con método. Y cierra con lo que más falta en la región: una ruta concreta de profesionalización, con certificaciones, herramientas y un plan de 90 días para construir un portafolio defendible. Su regla más citable: certificación sin laboratorio es teoría; laboratorio sin reporte es un pasatiempo.
1. Qué es realmente AI Security
La definición se apoya en tres piezas. Un modelo de frontera es un sistema de IA con capacidades de punta: razonamiento avanzado y generación de código, integración con herramientas y APIs, multimodalidad y autonomía creciente. La seguridad del sistema abarca mucho más que el modelo: protección de datos, pesos y prompts; orquestación de agentes e infraestructura; monitoreo operacional y de APIs. Y el riesgo medible exige evaluación continua: modelado de amenazas, evaluaciones empíricas, red teaming y compuertas antes de escalar o desplegar.
La idea central: la seguridad de la IA se mide por comportamiento bajo presión, no solo por vulnerabilidades catalogadas. Un sistema puede no tener un solo CVE y aun así ser explotable por la vía del comportamiento.
Cuatro razones explican por qué esto importa ahora: la capacidad (el riesgo aparece cuando un modelo reduce las barreras técnicas para tareas complejas o peligrosas), la autonomía (agentes con memoria, herramientas y permisos ejecutan acciones fuera del texto visible), la escala (un fallo replicable en producción se multiplica en miles de sesiones y flujos) y la defensa, que debe operar en tres tiempos: evaluar antes, monitorear durante, responder después.
2. La superficie de ataque no es solo el modelo
El atacante busca cruzar límites de confianza, y esos límites están en cinco frentes:
| Frente | Amenazas |
|---|---|
| Prompts e instrucciones | Inyección de prompts, jailbreaks, contexto malicioso, instrucciones ocultas. |
| Datos y memoria | Exfiltración, envenenamiento, RAG contaminado, fugas de información sensible. |
| Herramientas y agentes | Permisos excesivos, abuso de herramientas, acciones no previstas, filtración de la cadena de razonamiento. |
| Modelo y cadena de suministro | Robo de modelo, dependencia de componentes, checkpoints y librerías vulnerables. |
| Infraestructura | APIs, límites de tasa, registros, secretos, hosting, salida de red y monitoreo insuficiente. |
Y no es teórico: la charla muestra casos de modelos de frontera vulnerados en la práctica, incluyendo jailbreaks públicos aplicados a lanzamientos recientes y trabajo propio de red team donde el abuso de herramientas mediante MCP terminó en exfiltración de datos.
3. Cómo trabaja un laboratorio de frontera
A partir de la lógica pública de los grandes laboratorios, Venegas ordena el flujo en cuatro etapas: medir capacidades (evaluaciones para estimar qué puede hacer el modelo en dominios de riesgo), modelar amenazas (taxonomías, modelos de amenaza y especificaciones de comportamiento), red team humano + IA (expertos externos combinados con pruebas automatizadas) y mitigar y decidir (salvaguardas, controles, fichas de sistema, monitoreo y compuertas de despliegue).
La observación estructural es que los equipos de preparación de estos laboratorios declaran dos ejes: medición de capacidades y mitigación de amenazas extremas. Es decir, la pregunta no es solo qué hace mal el modelo hoy, sino qué podría hacer si alguien lo empuja al límite.
4. Cómo se ejecuta un AI Red Team serio
Cuatro fases, y el orden importa: Scope —definir sistema, activos, permisos, datos sensibles y límites de prueba—; Attack —diseñar prompts, cadenas, abusos de herramientas, envenenamiento y evasión—; Evaluate —medir impacto, reproducibilidad, severidad, probabilidad y trazabilidad—; y Mitigate —controles, política, guardarraíles, permisos mínimos, registro y re-test.
La entrega profesional no es una lista de jailbreaks: es un informe de riesgos con evidencia, mitigaciones y criterio de aceptación para producción. Ese último punto —cuándo el sistema puede salir a producción— es lo que convierte el ejercicio en una decisión de negocio y no en una demostración de habilidad.
La comparación con el pentest tradicional deja clara la complementariedad. El pentest explota fallas técnicas conocidas, busca acceso, escalamiento y persistencia, se apoya en vulnerabilidades catalogadas y entrega hallazgos técnicos. El AI red teaming prueba comportamiento y abuso del sistema, ataca prompts, herramientas, datos y agentes, mide daño, evasión, agencia y reproducibilidad, y entrega riesgo técnico + seguridad del comportamiento + gobernanza. La práctica madura combina ambos.
5. Defensa en profundidad para un sistema de IA
La arquitectura de seguridad se organiza por capas del ciclo de vida: datos (dataset, RAG, registros), modelo (checkpoints, ajuste fino), aplicación (prompts, APIs, herramientas), evaluación (red team, benchmarks) y operación (monitoreo, respuesta a incidentes, gobernanza). Y sobre todo eso, controles transversales que valen para cualquier despliegue: identidad, permisos mínimos, control de salida de red, registro, evaluación continua, revisión humana y kill switch.
El principio es explícito: no confiar en una sola barrera. Ninguna capa —ni el mejor guardarraíl, ni el mejor filtro— sostiene el sistema por sí sola.
6. Cómo entrar profesionalmente a AI Security
Esta es la sección que más valor tiene para quien está evaluando dedicarse al área, y es notablemente concreta. No existe una licencia universal para ejercer: lo que pesa es experiencia verificable, laboratorio, dominio de frameworks y credenciales. Dos rutas posibles:
| Ruta AI Security | Ruta AI Governance | |
|---|---|---|
| Base | Security+, pentesting, nube, Python | GRC, privacidad, cumplimiento |
| Especialización | COASP, CAISP/CMPSE, GIAC | IAPP AIGP, implementador o auditor ISO/IEC 42001 |
| Evidencia | Laboratorios de inyección de prompts, abuso de herramientas, envenenamiento y extracción de modelo; implementación de guardarraíles | Registro de riesgos de IA, compuertas de política, auditoría de ciclo de vida |
El stack obligatorio es común a ambas: estándares (OWASP LLM Top 10, MITRE ATLAS, NIST AI RMF), herramientas (PyRIT, Garak, entornos de evaluación, registro, CI/CD, operaciones de modelos) y un portafolio de reportes reproducibles.
La regla práctica: certificación sin laboratorio = teoría; laboratorio sin reporte = pasatiempo. Lo que contrata una empresa no es el diploma ni el hallazgo aislado: es la capacidad demostrada de medir, documentar y mitigar.
7. La ruta de 90 días
Un plan concreto para pasar de cero a un portafolio defendible. Días 1 a 30 — fundación: OWASP LLM Top 10 (incluidas las secciones agénticas y de MCP), MITRE ATLAS, NIST AI RMF y Python básico para evaluaciones. Días 31 a 60 — laboratorio: montar una aplicación con modelo, RAG y herramientas; ejecutar pruebas manuales y automatizadas con PyRIT y Garak; trabajar evasión de guardarraíles mediante jailbreak e inyección. Días 61 a 90 — reporte: modelado de amenazas específico, matriz de riesgos y mitigaciones, proceso de re-test y resumen ejecutivo.
El producto final es lo que abre puertas: un informe público sanitizado que muestre metodología, evidencia y límites éticos.
8. Conclusiones
Tres ideas, en los términos del autor. AI Security es sistema: modelo, datos, herramientas, infraestructura y operaciones — proteger solo uno de esos elementos deja el resto expuesto. El red team debe medir: no basta con encontrar jailbreaks, hay que reproducirlos, puntuarlos y mitigarlos. Y la carrera se construye con evidencia: las credenciales ayudan, pero el portafolio de laboratorio es el que decide.
La pregunta que la charla deja abierta para la región: ¿qué puede hacer LATAM para formar talento en seguridad de IA y participar en la frontera? La respuesta implícita en la ruta de 90 días es alentadora — el material es público, las herramientas son abiertas y lo que falta no es acceso sino método y constancia.
Referencias
- Venegas, G. (2026). AI Security en Frontier Models [presentación]. I Congreso IA-LATAM. PDF de la charla.
- Venegas, G. (2026). AI Security Frontiers Models [video]. Canal de Comunidad IA LATAM en YouTube. youtube.com/watch?v=IH8JAv6YgMw.
- Marcos y estándares citados: OWASP Top 10 para LLM · MITRE ATLAS · NIST AI Risk Management Framework · ISO/IEC 42001.
- Herramientas de red teaming mencionadas: PyRIT · Garak · entornos de evaluación (eval harnesses).
- Certificaciones referenciadas: EC-Council COASP · Practical DevSecOps CAISP y CMPSE · GIAC · IAPP AIGP.
- Fuentes de práctica citadas: programas públicos de preparación y red teaming de laboratorios de frontera · Frontier Model Forum.
Sobre el autor
Gustavo Venegas es fundador y CEO de ARGORIX (Chile), empresa enfocada en seguridad, gobernanza y red teaming de inteligencia artificial para entornos empresariales. Fue líder de AI Security y AI Governance en LATAM Airlines, lidera la Comisión de AI Security & AI Governance de la Cámara Chilena de Inteligencia Artificial, es autor de investigaciones sobre gobernanza de IA y sistemas auditables y explicables, y participa en los tracks de gobernanza y seguridad del foro de investigación de OpenAI. LinkedIn
Artículo elaborado por la Comunidad IA LATAM a partir de la presentación oficial y la transcripción del video de la charla. Los casos de modelos vulnerados citados son públicos o corresponden a trabajo de red team divulgado por el autor. Este contenido se comparte con fines educativos y de seguridad defensiva: todo ejercicio adversarial requiere autorización previa del titular del sistema.