Состязательное тестирование ИИ-моделей
Модель, которая хорошо отвечает на подготовленных вопросах, почти всегда ломается на подготовленных атаках. Мы ищем эти поломки до релиза: обход встроенных ограничений, инъекции в промпт через документ или письмо, выдачу чужих данных, уверенный ответ там, где модель обязана была отказаться. Работа заканчивается не оценкой «безопасно», а списком воспроизводимых сценариев с шагами повторения — чтобы разработчик мог их закрыть и потом проверить, что закрыл.
Что проверяется при тестировании безопасности модели?
Проверяем не абстрактную «этичность», а конкретные способы заставить систему сделать то, чего она делать не должна. Основных направлений пять: обход встроенных ограничений, инъекции инструкций через входящие данные, утечка служебной информации и чужих записей, уверенная выдумка вместо отказа и устойчивость к тем же атакам на других языках и в переформулировках.
Обход ограничений
Попытки получить запрещённый ответ через ролевые формулировки, разбиение запроса и подмену контекста.
Инъекции в промпт
Инструкции, спрятанные во входящем документе, письме или карточке товара, которые система принимает за команду.
Утечка данных
Проверка, можно ли вытащить системную инструкцию, содержимое чужих документов или фрагменты обучающей выборки.
Выдумка вместо отказа
Ситуации, где ответа в источниках нет, а модель уверенно отвечает вместо того, чтобы сказать об этом.
Устойчивость формулировок
Тот же запрет проверяется на переформулировках, других языках и опечатках — обходы часто живут именно там.
Права и границы
Может ли пользователь через диалог получить данные или действие, на которые у него нет прав.
Как проходит проект по тестированию модели?
Сначала договариваемся, что для вашей системы считается недопустимым ответом — без этого тестирование превращается в спор о вкусах. Дальше собираем атаки под ваш домен, прогоняем их и фиксируем каждую находку с точными шагами воспроизведения. После ваших исправлений проводим повторный прогон: он показывает, что дыра закрыта и что рядом не открылась новая.
Что вы получаете по итогам тестирования?
Отчёт, в котором каждая находка — это не наблюдение, а инструкция: исходный запрос, полученный ответ, шаги повторения и оценка последствий. Отдельным файлом отдаём набор атак в JSONL, чтобы вы могли гонять его в своём пайплайне после каждой правки модели. Итоговая сводка пишется так, чтобы её можно было показать и разработчику, и службе безопасности.
Почему находкам можно верить?
Главная беда такого тестирования — красивый отчёт с находками, которые никто не может повторить. Поэтому каждая наша находка проходит независимое воспроизведение вторым специалистом, а те, что не повторились, помечаются как нестабильные, а не выдаются за уязвимость. Мы также отделяем то, что реально может сделать пользователь, от того, что достижимо только при полном доступе к системе.
Независимое повторение
Находку повторяет второй специалист по описанию; неповторившееся помечается как нестабильное.
Разделение по доступу
Отдельно то, что доступно обычному пользователю, и то, что требует прав администратора.
Оценка последствий
Каждая находка сопровождается тем, что произойдёт на практике, а не общей шкалой критичности.
Без накрутки числом
Двадцать вариантов одного обхода — это одна находка, а не двадцать; отчёт не раздувается.
Проверка после правок
Повторный прогон подтверждает, что исправление закрыло сценарий, а не сместило его на шаг.
Доступ и NDA
NDA подписывается до передачи доступа, работа ведётся на инфраструктуре в РФ, действия журналируются.
Сколько стоит тестирование безопасности модели?
Считаем по часам экспертной работы — от 320 ₽ за час. На стоимость влияют глубина проверки, число сценариев и требуемая квалификация: атаки на медицинскую или юридическую систему готовит специалист с этим доменом. Повторный прогон после ваших исправлений оцениваем отдельно. Калькулятор ниже даёт ориентир, точную смету называем после разбора системы.
Кому нужно тестировать модель до релиза?
Тем, у кого ответ системы виден клиенту или влияет на решение о деньгах, здоровье и правах. В финансах цена ошибки считается прямо, в медицине — тем более. Общее правило простое: если вы не можете позволить себе объяснять последствия неверного ответа постфактум, дешевле найти этот ответ заранее самим.
Пример проекта
Проверка корпоративного ассистента на утечку чужих документов
Ассистент отвечал по базе знаний с разграничением доступа. Тестирование строилось вокруг одного вопроса: можно ли через формулировку запроса получить фрагмент документа, к которому у пользователя нет прав. Каждая находка воспроизводилась вторым специалистом, после исправлений проводился повторный прогон. Показатели — типовой сценарий проекта такого класса, не кейс конкретного клиента.
Ключевые факты
Частые вопросы о тестировании безопасности моделей
Чем это отличается от обычного пентеста?
Пентест ищет уязвимости инфраструктуры: сервера, сети, прав доступа. Здесь объект другой — поведение самой модели. Систему не взламывают в техническом смысле, её уговаривают: формулировкой запроса, спрятанной в документе инструкцией, подменой контекста. Инфраструктура при этом может быть настроена безупречно, а система всё равно выдаст то, что не должна.
Вы гарантируете, что после исправлений модель безопасна?
Нет, и никто честно не может. Мы находим и воспроизводим конкретные сценарии, вы их закрываете, мы проверяем повторным прогоном, что закрыто именно это. Утверждать, что не осталось необнаруженных способов, было бы обещанием, которое нечем подтвердить. Поэтому в отчёте пишем, что именно проверялось и что осталось за границей проверки.
Нужен ли вам доступ к весам модели?
Обычно нет: большинство проверок делается через тот же интерфейс, которым пользуется клиент, — так честнее, потому что именно этот путь доступен реальному пользователю. Доступ к системной инструкции и настройкам ускоряет работу и позволяет проверить больше, но это отдельная договорённость, и она фиксируется в NDA до начала.
Что делать, если находок окажется много?
Это нормальный результат первого прогона, особенно если систему до этого не проверяли. Поэтому отчёт сортируется не по количеству, а по последствиям: что реально может сделать обычный пользователь и во что это выльется. Закрывать всё сразу не требуется — с этого списка начинается план, а повторный прогон показывает движение.
Почему вы делаете эту страницу, если спроса в поиске нет?
Потому что направление уже стало нормой на мировом рынке, а в российском сегменте его не продаёт никто из 78 проверенных нами компаний. Мы говорим об этом прямо: страница сделана на опережение. Если сегодня вам достаточно обычной проверки качества ответов — так и скажем, а тестирование предложим тогда, когда система пойдёт к реальным пользователям.
Проверим модель до того, как её проверят пользователи
Опишите систему и то, какой ответ для вас недопустим, — вернёмся с планом проверки и оценкой в течение 1 рабочего дня.
Не любите формы — напишите на info@datamarkup.ru