Swordfish Security publica las ponencias de PRO DevSecOps Conf 2026 sobre protección de sistemas de IA

Tres semanas después de la conferencia, Swordfish Security ha abierto las grabaciones de PRO DevSecOps Conf 2026. El evento se celebró el 22 de septiembre y es el foro anual del grupo de empresas sobre desarrollo seguro e IA protegida. Los vídeos están disponibles en una lista de reproducción de RUTUBE; el anuncio se publicó en Habr el 13 de octubre. Los organizadores plantean su motivación sin rodeos: la IA llega a producción más rápido de lo que los equipos logran construir su protección. A ello se suma el contexto regulatorio: según ellos, en Rusia ya está en vigor la ley 243-ФЗ sobre IA y los requisitos de desarrollo seguro van en aumento.

Qué se sabe del evento

El anuncio es breve. No incluye la lista de ponentes ni de temas, así que resumir las charlas sería inventar. Esto es lo que confirma el texto:

• organizador: el grupo de empresas Swordfish Security;
• formato: la conferencia anual PRO DevSecOps Conf, edición de 2026;
• fecha: 22 de septiembre;
• temas: desarrollo seguro (DevSecOps) e IA protegida;
• dónde verla: lista de reproducción en RUTUBE, con enlace en la publicación de Habr;
• contexto regulatorio: la 243-ФЗ sobre IA, como la llaman los organizadores.

Que ambos temas compartan programa refleja cómo cambia la agenda profesional. Antes, los equipos de seguridad miraban el código y las dependencias. Ahora el perímetro incluye también modelos, datasets, prompts y agentes.

Por qué la IA complica el pipeline de desarrollo

El DevSecOps clásico se construye en torno a artefactos bien conocidos: código fuente, contenedores, bibliotecas e infraestructura como código. Para ellos existen análisis estático y dinámico, escáneres de dependencias y SBOM. Los componentes de IA añaden nuevas superficies de ataque.

La primera es la prompt injection. Una aplicación basada en LLM recibe texto de fuentes no confiables, ya sean correos, páginas web o documentos en RAG. El modelo no distingue los datos de las instrucciones como lo hace un parser, así que una orden maliciosa puede ejecutarse. OWASP mantiene una lista aparte de riesgos para aplicaciones LLM, y las inyecciones siguen entre los principales.

La segunda es la cadena de suministro de modelos. Los pesos se descargan de repositorios públicos, y algunos formatos de serialización, como pickle, pueden ejecutar código al cargarse. Es el mismo riesgo que supone una biblioteca desconocida, pero se revisa con bastante menos frecuencia.

La tercera son los agentes. Cuando el modelo obtiene acceso a herramientas, al correo, a una base de datos o al CI, un error o un ataque deja de ser una respuesta incorrecta y se convierte en una acción real con permisos reales.

La regulación como acelerador

Los organizadores mencionan la 243-ФЗ sobre IA. El anuncio no detalla qué exige exactamente la ley a los desarrolladores, y conviene consultar las normas concretas en la fuente original, no en resúmenes. La lógica, en cambio, es clara: cuando los sistemas de IA quedan sujetos a requisitos formales, la seguridad deja de ser una iniciativa de entusiastas dentro del equipo y pasa a ser un punto de verificación. Para las empresas que operan en Rusia y ya cumplen requisitos de desarrollo seguro, esto implica tener que describir cómo comprueban también la parte de IA de su producto.

Por dónde empezar en un equipo

Las grabaciones de la conferencia sirven de pretexto para hacer una revisión interna. Este es un conjunto mínimo de pasos, no ligado a ninguna ponencia concreta:

• elaborar un registro de todos los componentes de IA: API externas, modelos locales, bases RAG, agentes y sus permisos;
• ampliar el inventario de dependencias a modelos y datasets: origen, versión, formato, suma de verificación;
• prohibir la carga de pesos en formatos inseguros sin una comprobación aislada;
• añadir al CI pruebas de prompt injection y de fuga de contexto, como una clase de verificaciones independiente;
• dar a los agentes los permisos mínimos y registrar cada acción con herramientas;
• designar a un responsable que contraste los requisitos de la 243-ФЗ con los procesos actuales.

Después, conviene abrir la lista de reproducción y elegir las ponencias que encajen con el propio stack. Mientras el programa no se publique como lista aparte, habrá que guiarse por los títulos de los vídeos en RUTUBE.