Swordfish Security опубликовала доклады PRO DevSecOps Conf 2026 о защите ИИ-систем

Через три недели после конференции Swordfish Security открыла записи PRO DevSecOps Conf 2026. Мероприятие прошло 22 сентября, это ежегодный форум группы компаний о безопасной разработке и защищённом ИИ. Видео доступны в плейлисте на RUTUBE, анонс опубликован на Habr 13 октября. Мотивация организаторов сформулирована прямо: ИИ попадает в продакшен быстрее, чем команды успевают построить вокруг него защиту. К этому добавляется регуляторный фон: по их словам, в России уже действует 243-ФЗ об ИИ, а требования к безопасной разработке растут.

Что известно о событии

Анонс короткий. Списка докладчиков и тем в нём нет, поэтому пересказывать выступления было бы выдумкой. Зафиксируем то, что подтверждено текстом:

• организатор: ГК Swordfish Security;
• формат: ежегодная конференция PRO DevSecOps Conf, выпуск 2026 года;
• дата проведения: 22 сентября;
• темы: безопасная разработка (DevSecOps) и защищённый ИИ;
• где смотреть: плейлист на RUTUBE, ссылка в публикации на Habr;
• регуляторный контекст: 243-ФЗ об ИИ, как его называют организаторы.

Само объединение двух тем в одной программе показывает, как меняется профессиональная повестка. Раньше безопасники смотрели на код и зависимости. Теперь в периметре ещё и модели, датасеты, промпты и агенты.

Почему ИИ усложняет конвейер разработки

Классический DevSecOps строится вокруг понятных артефактов: исходники, контейнеры, библиотеки, инфраструктурный код. Для них есть статический и динамический анализ, сканеры зависимостей и SBOM. С ИИ-компонентами появляются новые поверхности атаки.

Первая: prompt injection. Приложение на базе LLM принимает текст из недоверенных источников, будь то письма, веб-страницы или документы в RAG. Модель не отличает данные от инструкций так, как это делает парсер, поэтому вредоносная команда может сработать. OWASP ведёт отдельный перечень рисков для LLM-приложений, и инъекции в нём остаются в числе ключевых.

Вторая: цепочка поставок моделей. Веса скачиваются из публичных репозиториев, а часть форматов сериализации, например pickle, способна исполнять код при загрузке. Это тот же риск, что и с неизвестной библиотекой, но проверяют его заметно реже.

Третья: агенты. Как только модель получает доступ к инструментам, почте, базе или CI, ошибка или атака превращается из неправильного ответа в реальное действие с реальными правами.

Регуляторика как ускоритель

Организаторы упоминают 243-ФЗ об ИИ. Что именно закон требует от разработчиков, в анонсе не раскрыто, и точные нормы стоит сверять по первоисточнику, а не по пересказам. Сама логика понятна: когда ИИ-системы попадают под формальные требования, безопасность перестаёт быть инициативой энтузиастов в команде и становится пунктом проверки. Для компаний, которые работают в России и уже подчиняются требованиям к безопасной разработке, это означает необходимость описать, как они проверяют и ИИ-часть продукта.

С чего начать команде

Записи конференции полезны как повод провести внутреннюю ревизию. Минимальный набор шагов, не привязанный к конкретным докладам:

• составить реестр всех ИИ-компонентов: внешние API, локальные модели, RAG-базы, агенты и их права;
• расширить учёт зависимостей на модели и датасеты: источник, версия, формат, контрольная сумма;
• запретить загрузку весов в небезопасных форматах без изолированной проверки;
• добавить в CI тесты на prompt injection и утечку контекста, как отдельный класс проверок;
• выдавать агентам минимальные права и журналировать каждое действие с инструментами;
• назначить владельца, который сопоставит требования 243-ФЗ с текущими процессами.

Дальше имеет смысл открыть плейлист и выбрать доклады под свой стек. Пока программа не опубликована отдельным списком, ориентироваться придётся по названиям видео на RUTUBE.