Короткий ответ: безопасный внутренний ИИ-помощник — это не только модель и хороший промпт. Нужны ограниченные источники, проверка прав на каждый запрос, защита от утечек и вредных инструкций, тестовый набор, журнал действий и понятный режим ручного подтверждения. Чем ближе помощник к реальным изменениям в системах, тем строже должны быть границы его действий.
Самая опасная ошибка — дать помощнику доступ ко всей корпоративной базе, а затем проверять, «как он себя поведёт». Безопасность проектируют до подключения данных и инструментов: сначала описывают роли и допустимые действия, потом строят поиск и только после этого решают, что можно автоматизировать.
1. Опишите границы помощника
Начните с карты доверия: какие пользователи обращаются к системе, какие источники им разрешены, какие действия выполняются только после подтверждения и что полностью запрещено. Внутренний статус документа не означает, что его можно показывать каждому сотруднику.
| Зона | Что зафиксировать | Пример ограничения |
|---|---|---|
| Пользователь | Роль, подразделение, контекст | Менеджер видит только свои заявки |
| Источники | Документы, версии, владелец | Не использовать архив без отметки актуальности |
| Ответ | Формат и обязательные ссылки | Показывать источник и дату обновления |
| Действие | Что можно вызвать из системы | Создание черновика, но не отправка без подтверждения |
| Эскалация | Когда передать человеку | Нет уверенного источника или конфликт правил |
Для внутренних систем полезно связать эту карту с проектированием веб-приложения: права, состояния, ошибки и аудит должны быть частью сценария, а не отдельной запиской после разработки.
Практический шаг: составьте список действий «читать / предлагать / изменять / отправлять» и назначьте для каждого роль, подтверждение и журналирование.
2. Разделите поиск и действие
Помощнику часто достаточно найти документ, выделить релевантный фрагмент и подготовить черновик. Доступ к изменяющим инструментам — CRM, почте, учёту или файлам — создаёт новый класс риска. Разделяйте режимы: поиск и ответ, рекомендация, черновик, действие после подтверждения.
- не передавайте модели больше данных, чем нужно для конкретного запроса;
- не смешивайте полномочия пользователя с полномочиями сервисного аккаунта;
- проверяйте права до поиска и до вызова инструмента;
- добавляйте подтверждение перед необратимыми действиями;
- ограничивайте частоту и объём операций;
3. Учитывайте prompt injection и вредные инструкции
Документ, письмо или веб-страница могут содержать текст, который пытается изменить поведение помощника. Для системы это данные, а не команда владельца. Поэтому инструкции из найденных источников нельзя автоматически считать приоритетными, особенно если они предлагают раскрыть секреты, обойти права или выполнить действие вне задачи.
OWASP GenAI Security Project относит prompt injection к ключевым рискам приложений на базе больших языковых моделей. В прикладной архитектуре это означает: отделять системные правила от внешнего контента, минимизировать полномочия, фильтровать ввод, проверять результат и тестировать злоупотребления до подключения боевых инструментов.
4. Подготовьте данные и источники
RAG-поиск или подключение корпоративной базы не делает ответы автоматически достоверными. Нужны владельцы документов, версии, правила удаления устаревшего, контроль доступа и понятное поведение при отсутствии источника. Если система не может подтвердить ответ, она должна честно остановиться или передать запрос сотруднику.
| Контроль | Вопрос для команды |
|---|---|
| Актуальность | Кто отвечает за обновление и архивирование? |
| Версия | Можно ли отличить действующий документ от черновика? |
| Доступ | Применяются ли права пользователя к найденным фрагментам? |
| Цитирование | Видит ли сотрудник источник и место в документе? |
| Отказ | Что происходит, если источник не найден? |
5. Введите тесты до запуска
Набор тестов должен включать не только обычные вопросы. Проверьте запросы на чужие документы, попытки выманить системные инструкции, конфликтующие версии, чувствительные данные, пустой поиск, длинный ввод и намерение выполнить запрещённое действие. Тесты нужно повторять после изменения модели, промпта, индекса или прав.
- тесты доступа между ролями и подразделениями;
- проверка утечки системных инструкций и секретов;
- вредные или конфликтующие инструкции в документах;
- галлюцинации при отсутствии источника;
- повторяемость ответа на одинаковых данных;
- корректный отказ и передача человеку;
- журналирование без записи паролей, токенов и лишних персональных данных;
6. Логируйте решение, а не секреты
Журнал нужен, чтобы разобрать ошибку: кто запросил, какой сценарий выполнялся, какие источники использовались, какой результат предложен, что исправил человек и какое действие было подтверждено. В журнале не должны появляться пароли, ключи, токены и полные чувствительные документы без необходимости. Срок хранения и доступ к логам тоже являются частью модели угроз.
7. Оставьте человека в контуре там, где это важно
Human-in-the-loop — не формальность. Сотрудник должен понимать, что предложено, на каких источниках это основано и что произойдёт после подтверждения. Для автоматического действия нужны отдельные критерии: качество на тестах, ограниченный объём полномочий, откат, мониторинг и ответственный владелец.
| Режим | Подходящий результат | Контроль |
|---|---|---|
| Поиск | Фрагменты и ссылки | Права и актуальность |
| Черновик | Проект ответа или записи | Проверка сотрудником |
| Рекомендация | Приоритет или следующий шаг | Правила и метрика качества |
| Действие | Изменение во внешней системе | Подтверждение, журнал, откат |
Чек-лист перед внутренним запуском
- Есть карта ролей, источников и разрешённых действий?
- Проверяются права пользователя до выдачи результата?
- Отдельно протестированы prompt injection и доступ к чужим данным?
- Система показывает источники и умеет отказываться?
- Необратимые действия требуют подтверждения?
- Логи не содержат секретов и лишних персональных данных?
- Есть владелец инцидента, способ отключения и план отката?
- Тесты повторяются после изменений в модели, индексе и промптах?
NIST AI RMF и профиль для генеративного ИИ полезны как рамка для управления, картирования, измерения и контроля рисков. OWASP Top 10 для LLM-приложений помогает дополнить её прикладными сценариями атак. Эти документы не заменяют threat modeling и проверку конкретной системы, но помогают не забыть важные классы проблем.
Как Paladin Engineering может помочь
Paladin Engineering может помочь спроектировать внутреннего ИИ-помощника вокруг реального процесса: описать роли, источники, границы инструментов, прототип поиска, тестовые сценарии и критерии приёмки. Безопасность здесь — не отдельная кнопка в конце проекта, а часть архитектуры и эксплуатации. Для обсуждения задачи используйте контакты Paladin Engineering.
До старта подготовьте: перечень источников, роли пользователей, список запрещённых действий, примеры корректных ответов и сценарии, в которых помощник обязан отказаться.
CTA: если нужно обсудить доступы, источники и сценарии отказа до подключения боевых данных, начните с аудита одного внутреннего процесса и тестового набора.
CTA: напишите нам и передайте список ролей, источников и запрещённых действий — это позволит оценить границы помощника до разработки интеграций и заявки.
FAQ: безопасность ИИ-помощника
Можно ли подключить помощника ко всей базе компании?
Техническая возможность не означает необходимость. Начинайте с ограниченного набора источников и применяйте права пользователя на уровне поиска и выдачи.
Достаточно ли запретить опасные слова в промпте?
Нет. Нужны минимальные полномочия, разделение данных и инструкций, проверка инструментов, тесты злоупотреблений и наблюдаемость.
Нужно ли показывать источники ответа?
Да, когда это возможно: сотруднику проще проверить результат, а команде — разобрать устаревший или неподходящий документ.
Какие действия нельзя отдавать ИИ сразу?
Необратимые изменения, отправку сообщений, финансовые операции и действия с правами доступа следует запускать только через явное подтверждение и контролируемый процесс.
Что делать при ошибочном ответе?
Зафиксировать запрос, источники и правку, передать случай владельцу процесса, проверить причину и обновить тестовый набор или правила.
Комментарии