Безопасность ИИ-функции: чек-лист перед запуском

Большинство неприятностей с ИИ-функциями происходит не от того, что модель ошиблась, а от того, что вокруг неё чего-то не было: ключ лежал во фронтенде, у функции оказался лишний инструмент, никто не поставил предел расхода, а обрыв посреди работы посчитали успехом. Всё это проверяется до запуска и занимает вечер. Ниже — двадцать пунктов пятью группами, в том порядке, в котором их разумно проходить: от того, что ломается чаще всего, к тому, что обнаруживается позже. Каждый пункт со ссылкой на подробный разбор, если он у нас есть.

Ключи и доступ

Пять пунктов. Первый закрывает самую частую ошибку.

Ключ не в клиентском коде. Ни в браузере, ни в мобильной сборке. Всё, что попало на устройство пользователя, ему доступно — обфускация не спасает.

Ключ не в репозитории. И не в истории коммитов: удаление строки не удаляет прошлые версии.

Ключ в переменных окружения или хранилище секретов.

Отдельный ключ на каждый сценарий. Раздельный учёт расхода, локализация утечки, возможность отозвать один, не трогая остальные.

Предел расхода на ключе. Ошибка в цикле обнаруживается по счёту; предел превращает её в неприятность вместо катастрофы.

Подробно — как хранить API-ключи.

Права инструментов

Четыре пункта. Здесь определяется потолок ущерба.

Список инструментов минимален. Чего нет — то не будет вызвано. Самая надёжная мера из существующих.

Чтение отделено от записи. Разные наборы прав, а лучше разные ключи.

Нет универсальных инструментов. Функция, принимающая произвольный код или запрос к базе, отдаёт модели всё, к чему у неё есть доступ.

Необратимое подтверждает человек. Отправка, платёж, удаление, публикация.

Подробно — какие доступы давать агенту и как устроен вызов функций.

Данные

Четыре пункта. Их пропускают чаще всего, потому что последствия отложены.

Определено, что вообще отправляется. Не «всё подряд», а перечень: какие поля, какие документы, какие ящики.

Персональные данные обезличены до отправки. Для большинства задач настоящие имена и контакты не нужны — метки подставляются обратно вашим кодом.

В логах нет заголовков авторизации и тел запросов. Журнал уезжает в систему сбора, доступ к которой шире, чем к серверу.

Прочитан документ провайдера о хранении. У нас это llms.txt; у любого другого — до первого рабочего запроса, а не после.

Подробно — что уходит провайдеру.

Внешний текст

Три пункта, специфичных именно для этого класса функций.

Всё внешнее считается недоверенным вводом. Документ клиента, письмо, страница, результат инструмента, сообщение пользователя. Модель читает контекст однородно и не отличает данные от команд.

Чтение внешнего и право на действия разведены. Одна часть системы читает и извлекает, другая действует по подтверждённым данным.

Проверка результата в коде. Идентификаторы, суммы, адреса сверяются с вашей базой, а не принимаются на веру.

Подробно — как защититься от промпт-инъекции.

Отказы и деньги

Четыре пункта, которые обнаруживаются в проде, если их не сделать заранее.

Три исхода различаются в коде: ответ, отказ модели, техническая ошибка. Отказ приходит с успешным кодом и списанными токенами — проверка кода ответа его не ловит.

Повторы с паузой и предельным числом. Повтор при неверном ключе бесполезен, при превышении лимита без паузы делает хуже.

Состояние сохраняется между шагами. Для многошаговых сценариев: обрыв посередине не должен терять работу и не должен выглядеть как успех.

Длина ответа ограничена осознанно. Значение по умолчанию щедрее, чем нужно, и это одновременно счёт и задержка.

Подробно — коды, повторы и fallback, почему модель отказывается отвечать, новый класс отказов.

Что проверить после запуска

Три величины, которые меняются раньше, чем приходят жалобы. Все видны из своих логов.

Расход в пересчёте на запрос. Вырос при той же нагрузке — что-то изменилось: ставка, служебный контекст или ваш код стал отправлять больше.

Доля отказов. Ползёт вверх — вендор поменял правила или ваш поток изменился.

Поле model в ответе. Не совпадает с запрошенным — вас обслуживает другая модель. Две строки кода, и вы это видите — почему это важно.

Разумная периодичность — полчаса раз в месяц: сверить статусы используемых позиций и посмотреть на эти три числа. Каталог меняется быстро: за последние сутки в нашем число позиций сократилось, и такие изменения лучше замечать самому.

Три ошибки, которые повторяются чаще всего

По нашим наблюдениям и по разборам, которые мы писали в течение месяца.

Ключ в клиентской части. Браузер, мобильная сборка, публичная таблица. Обнаруживается по чужому расходу, а не по предупреждению.

Инструменты «на будущее». Подключили функцию, которой пока не пользуются, и забыли. Она продолжает уходить в модель при каждом обращении, стоить денег и расширять поверхность атаки.

Отказ, посчитанный успехом. Модель ответила текстом «не могу помочь», код 200, токены списаны — а ваш код записал это как результат и показал пользователю.

Все три чинятся за час и все три встречаются в проде регулярно.

Что не входит в чек-лист

Три вещи, которые важны, но решаются не здесь.

Качество ответов. Это выборка и замеры — как тестировать.

Выбор модели. Отдельная работа на своих задачах.

Юридическая сторона. Основания обработки данных, ответственность за автоматические решения — к вашему юристу.

Как пройти его быстро

Порядок на один вечер, если функция уже написана и вы проверяете существующее.

Полчаса на ключи. Поиск по репозиторию на характерные префиксы, проверка сборки фронтенда, взгляд на переменные окружения. Здесь обнаруживается больше всего.

Полчаса на инструменты. Выпишите список того, что модель может вызвать, и напротив каждого — что произойдёт в худшем случае. Пункты, где ответ неприятный, требуют подтверждения человеком.

Час на данные. Возьмите десять реальных запросов из логов и посмотрите глазами, что в них ушло. Обычно обнаруживается лишнее: документ целиком вместо абзаца, история переписки, тестовые данные с настоящими именами.

Полчаса на отказы. Сломайте ключ намеренно, отправьте несуществующую модель, оборвите запрос. Посмотрите, что увидит пользователь и что попадёт в логи.

Полчаса на деньги. Проверьте, есть ли предел на ключе и что произойдёт при его достижении.

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

Чего мы не утверждаем

Список не исчерпывающий. Он покрывает то, на чём ошибаются чаще всего; ваша архитектура может добавить своё.

Прохождение чек-листа не гарантирует безопасности. Оно ограничивает потолок ущерба, а не исключает происшествия.

Мы не даём юридических советов.

Цифры каталога — на дату. Состояние на 9 сентября 2026 года: 49 позиций в пятнадцати семействах.

Что нужно, чтобы пройти его на практике

Ключ заводится за минуту на keydealer.ru/login — почта и пароль, без документов и без зарубежной карты. Оплата российской картой в рублях.

Для чек-листа полезны две вещи из кабинета: отдельные ключи под сценарии с собственными пределами расхода и открытая выдача GET /v1/models, по которой видно статусы и возможности до запроса. Платные текстовые модели доступны сразу на приветственном бонусе — прогнать проверки на реальном сценарии можно без пополнения.

Отдельно про регулярность: чек-лист устаревает вместе с функцией. Каждый новый инструмент, новый источник внешних данных и каждая смена модели возвращают вас к тем же пяти группам. Разумная привычка — проходить его не по календарю, а по событию: что-то добавили в схему, значит прошли заново.

Что держать в голове

Порядок важен: ключи и права закрывают потолок ущерба, данные и внешний текст — вероятность инцидента, отказы и пределы — предсказуемость расхода.

И самый дешёвый пункт из всех — сокращение списка инструментов. Всё, чего модель не может сделать технически, не сделает ни ошибка, ни чужой текст в контексте.

Как мы проверяем факты и что храним из запросов — на странице о проекте и в llms.txt. Завести отдельный ключ с пределом: keydealer.ru/login.