Наиболее эффективный способ предотвратить утечку конфиденциальных данных от ИИ-оператора службы поддержки клиентов — это убедиться, что модель никогда не получает, не извлекает и не может обрабатывать больше данных, чем требуется для текущего запроса клиента. Не полагайтесь на системное сообщение типа «никогда не разглашайте личную информацию». Внедрите детерминированные средства контроля над моделью: минимизируйте и редактируйте входные данные, разрешайте каждый поиск данных вне LLM, предоставляйте инструментам минимальные привилегии, изолируйте данные каждого клиента, проверяйте ответы перед отправкой и отслеживайте весь процесс.
Такая конструкция соответствует направлению текущих рекомендаций по безопасности. Профиль генеративного ИИ NIST (NIST AI 600-1) , опубликованный в 2024 году и обновленный NIST в 2026 году, рассматривает конфиденциальность, безопасность, мониторинг и управление рисками как проблемы жизненного цикла. В списке OWASP Top 10 для приложений LLM и генеративного ИИ выделены такие риски, как внедрение подсказок, раскрытие конфиденциальной информации, ненадлежащая обработка выходных данных, чрезмерная свобода действий и утечка системных подсказок. Практическое следствие простое: безопасному агенту службы поддержки клиентов необходимы несколько независимых средств контроля, а не одна хитрая подсказка.
Прежде чем выбирать модель или добавлять дополнительный текст, ограничивающий доступ, проследите путь, по которому данные о клиенте проходят через вашу систему. Типичный сотрудник службы поддержки может получить сообщение, получить записи из CRM, выполнить поиск в базе знаний, обратиться к API заказа или выставления счетов, сгенерировать ответ, записать журналы и сохранить память о переписке. Утечка конфиденциальных данных может произойти на любом из этих этапов.
Для простого бота для часто задаваемых вопросов, который никогда не получает доступ к данным конкретных клиентов, основной риск заключается в том, что клиенты вводят в чат и что при этом регистрируется. Для помощника по отслеживанию статуса заказа критически важны авторизация и фильтрация на уровне полей. Для агента, который может оформлять возвраты, изменять адреса или отменять услуги, права доступа к инструментам и подтверждение транзакций так же важны, как и фильтрация ответов.
Минимизация данных — это наиболее эффективный первый этап контроля, поскольку информация, которую модель никогда не получает, не может быть воспроизведена в её ответе. Рекомендации Федеральной торговой комиссии (FTC) по безопасности данных советуют собирать только необходимую информацию, обеспечивать её безопасность и безопасно утилизировать. Примените эту идею непосредственно к построению контекста для ИИ.
Предположим, клиент спрашивает: «Где мой заказ?» Обычно модели не требуется полный номер платежной карты клиента, налоговый идентификатор, дата рождения, полная история адресов или внутренние данные о мошенничестве. Ваше приложение может аутентифицировать клиента, обратиться в службу обработки заказов и передать модели только узкий набор данных, таких как номер заказа, статус доставки, предполагаемое время доставки и подтвержденные данные службы поддержки.
Точный список зависит от вашего бизнеса и юридических обязательств, но обычно в него входят платежные данные, секретные ключи аутентификации, государственные идентификаторы, медицинская информация, полные номера финансовых счетов, частные адреса, внутренние заметки по безопасности и конфиденциальные деловые данные. По возможности используйте детерминированные детекторы и поддерживайте специфические для вашей области шаблоны для собственных идентификаторов.
Не следует предполагать, что маскировки видимой части чата достаточно. Применяйте ту же политику к полученным документам, ответам инструментов, черновикам агентов, сводкам разговоров, событиям аналитики, трассировкам и журналам ошибок.
Модель искусственного интеллекта никогда не должна решать, разрешено ли клиенту А читать запись о клиенте Б. Авторизация должна происходить в детерминированном коде приложения или службе контроля доступа, прежде чем данные будут возвращены агенту.
Это соответствует принципу, лежащему в основе стандарта NIST SP 800-207 «Архитектура нулевого доверия» : доступ к ресурсам предоставляется на основе аутентифицированных и авторизованных идентификаторов, а не на основе неявного доверия. Для агента ИИ тот же подход означает, что каждый запрос в CRM, заявка, заказ или счет должны содержать подтвержденную личность пользователя и проверяться на соответствие запрашиваемому ресурсу.
Безопасный поиск заказа может быть реализован как «получение статуса заказа для authenticated_customer_id и order_id», при этом бэкэнд подтверждает право собственности, прежде чем вернуть небольшой ответ с указанием разрешенных элементов. Опасный подход — это «поиск по всем записям клиентов», а затем доверие к модели в выборе правильной записи.
Агенты, использующие встроенные инструменты, особенно рискованны, поскольку быстрая инъекция или ошибка модели могут привести к действию против реальной системы. В рекомендациях OWASP по избыточной активности агентов чрезмерная функциональность, чрезмерные разрешения и чрезмерная автономность определены как основные причины деструктивного поведения агентов.
Не следует предоставлять одному сотруднику службы поддержки универсальные учетные данные CRM с доступом на чтение/запись ко всем записям. Разделите возможности в зависимости от назначения. Сотруднику службы поддержки может потребоваться доступ только для чтения к утвержденному справочному контенту. Инструмент отслеживания статуса заказа может возвращать только поля, относящиеся к доставке. Инструмент возврата средств может потребовать отдельной области разрешений, ограничения количества транзакций и подтверждения от человека или клиента перед выполнением операции.
Для действий, оказывающих существенное влияние, необходимо внедрять бизнес-правила в бэкэнд-код. Модель может предложить «заказ на возврат 123», но приложение должно самостоятельно проверить подлинность клиента, право на возврат, сумму, валюту, статус транзакции и требования к утверждению.
Внедрение подсказок не ограничивается вводом клиентом фразы «игнорируйте ваши инструкции». В руководстве OWASP по внедрению подсказок отмечается, что косвенные инструкции могут также поступать через документы, веб-страницы, результаты работы инструментов, изображения или другой контент, обрабатываемый моделью.
В сфере обслуживания клиентов это важно, поскольку операторы часто получают доступ к истории обращений, переписке по электронной почте, загруженным документам, страницам товаров или заметкам из CRM-системы. Вредоносная инструкция, скрытая в одном из этих источников, должна оставаться данными, а не давать оператору власть над ним.
Используйте список разрешенных источников получения данных, отделяйте доверенные инструкции от недоверенного контента, очищайте или преобразуйте полученные материалы, где это практически возможно, и размещайте проверки авторизации на границе инструмента. Когда полученный документ запрашивает секреты, учетные данные, несвязанные записи или действия инструмента, окружающее приложение должно блокировать эти операции независимо от решения модели.
Четкое системное уведомление по-прежнему ценно. Оно может указывать агенту не разглашать секретную информацию, не раскрывать данные другого клиента, запрашивать подтверждение при необходимости и передавать неясные случаи на более высокий уровень. Но его следует рассматривать как руководство к модели, а не как механизм защиты данных.
В рекомендациях OWASP по утечке информации из системных запросов прямо указывается на недопустимость размещения учетных данных, строк подключения, конфиденциальных структур разрешений или других секретных данных в системных запросах. Также рекомендуется внедрять критически важные механизмы контроля, такие как авторизация и разделение привилегий, вне LLM.
Предположим, что модель может иногда генерировать то, чего не должна. Создайте выходной шлюз, который проверяет ответы на наличие шаблонов конфиденциальных данных, идентификаторов разных клиентов, секретных данных, неподдерживаемых ссылок, опасной разметки или значений, нарушающих вашу бизнес-политику, прежде чем доставлять их.
Рекомендации OWASP по некорректной обработке выходных данных советуют рассматривать выходные данные модели как ненадежные и проверять или очищать их перед передачей компонентам, работающим с моделью. В сфере обслуживания клиентов это относится как к тексту, отображаемому пользователю, так и к структурированным выходным данным, используемым для вызовов API.
Например, если модель генерирует JSON-запрос для изменения почтового адреса, проверки схемы, аутентификации клиента, подтверждения принадлежности целевой учетной записи к сессии, отклонения неожиданных полей и запроса подтверждения, если действие является конфиденциальным, никогда не выполняйте созданные моделью SQL-запросы, команды оболочки, URL-адреса или идентификаторы базы данных только потому, что выходные данные «выглядят структурированными».
Утечка данных между клиентами часто происходит из-за проблем с извлечением информации или управлением состоянием, а не из-за самой базовой модели. Система обслуживания клиентов, которая использует общие векторные индексы, кэши диалогов, долговременную память или результаты поиска для разных пользователей, требует строгой фильтрации перед извлечением данных.
Перед возвратом документов в модель необходимо выполнить авторизацию арендатора и пользователя. Не следует запрашивать у LLM широкий набор записей и просить его отбросить те, которые ему не нужны. Модель должна получать только те записи, к которым текущий авторизованный пользователь имеет доступ.
Используйте отдельные пространства имен, политики на уровне строк, списки контроля доступа к документам или эквивалентную изоляцию, обеспечиваемую уровнем данных. Протестируйте негативные сценарии: Клиент А ищет адрес электронной почты Клиента Б, идентификатор заказа, номер заявки в службу поддержки и часть номера счета. Правильный результат — отсутствие несанкционированных документов в контексте модели.
Ведение журналов необходимо для реагирования на инциденты, но журналы могут стать еще одной копией конфиденциальных данных, которые вы пытались защитить. Записывайте достаточно контекста для расследования принятых решений, одновременно маскируя или токенизируя конфиденциальные поля. Ограничьте доступ к журналам, определите сроки хранения и по умолчанию избегайте перехвата необработанных запросов и полезных нагрузок инструментов, если они содержат секретные данные клиентов.
Стандарт NIST SP 800-53 Revision 5.1 включает в себя средства аудита и контроля, которые подчеркивают важность выбора и анализа типов событий, имеющих отношение к безопасности, для проведения расследования инцидентов. Для системы поддержки ИИ полезными событиями являются отказ в доступе к данным, срабатывание триггеров редактирования, необычный объем запросов, повторные попытки внедрения подсказок, заблокированные вызовы инструментов, сбои авторизации между арендаторами и нарушения политики вывода.
Перед запуском и после существенных изменений в запросах, моделях, инструментах, индексах поиска, политиках доступа или поведении памяти запустите повторяемый набор тестов безопасности. Включите в него прямое внедрение запросов, косвенное внедрение в полученные документы, запросы данных другого клиента, закодированные или обфусцированные идентификаторы, неправильное использование инструментов, многоэтапные попытки обойти политику и попытки заставить агента раскрыть свой внутренний контекст.
| Тип агента | Контроль наивысшего приоритета | Почему |
|---|---|---|
| Бот для публичных часто задаваемых вопросов | Минимизация входных данных, безопасное ведение журналов, фильтрация внедрения подсказок, проверка выходных данных. | Для этого вообще не должны потребоваться личные данные клиентов. |
| помощник по отслеживанию статуса заказа | Надежная аутентификация, проверка прав собственности, ответы API на уровне полей, изоляция арендаторов. | Для этого требуются некоторые данные о клиенте, но только для подтвержденного пользователя и текущего заказа. |
| Агент службы поддержки учетных записей | Инструменты CRM с минимальными привилегиями, редактирование персональных данных, DLP-фильтрация выходных данных, изоляция памяти, эскалация. | Она обрабатывает более сложные персональные данные и может получать доступ к нескольким системам. |
| Агент по возврату или отмене заказа | Всё вышеперечисленное, а также детерминированные бизнес-правила, лимиты транзакций, подтверждение и журналы аудита. | Агент может изменять реальное состояние мира, поэтому утечка информации и несанкционированные действия имеют значение. |
| Платформа поддержки многопользовательских предприятий | Поиск с учетом арендаторов, идентификаторы служб с ограниченным доступом, обеспечение соблюдения ACL для документов, ведение журналов для каждого арендатора. | Одна-единственная ошибка при извлечении данных может привести к тому, что данные одной организации станут доступны другой. |
Не следует оценивать безопасность только по тому, как часто чат-бот вежливо отклоняет подозрительные запросы. Необходимо оценить, предотвратила ли базовая система попадание конфиденциальных данных в контекст модели или их выход через ответ или действие инструмента.
Полезные инженерные метрики включают в себя процент запросов к конфиденциальным данным, заблокированных до их получения, сбои авторизации между арендаторами, точность редактирования известных тестовых случаев, блокировки конфиденциальных выходных данных, несанкционированные попытки вызова инструментов, процент действий высокого риска, требующих подтверждения, и время от обнаружения до расследования. Используйте синтетические или надлежащим образом управляемые наборы тестовых данных, чтобы ваша оценка безопасности не создала новую проблему конфиденциальности.
Самый безопасный ИИ-агент для обслуживания клиентов — это не тот, у которого самый длинный запрос на подтверждение безопасности. Это тот, который работает в узком, подлежащем аудиту потоке данных. Предоставляйте ему только записи, необходимые для текущего подтвержденного клиента, только инструменты, необходимые для текущей задачи, и только разрешения, необходимые для вызова этого инструмента. Фильтруйте данные перед выводом, проверяйте результаты после вывода и обеспечивайте идентификацию и авторизацию независимо от модели.
Используйте инструкции на уровне модели как один из уровней защиты, а не как последний барьер. Когда конфиденциальные данные защищены детерминированным контролем доступа, минимизированным контекстом, инструментами с минимальными привилегиями, изоляцией арендаторов, проверкой выходных данных, безопасным ведением журналов и непрерывным тестированием, вероятность того, что внезапная инъекция или ошибка модели приведут к утечке данных клиентов, значительно снижается.
Создайте локальный рабочий процесс Ollama, который будет генерировать структурированные SEO-заголовки и метаописания в пакетном режиме, проверять результаты и помечать их для проверки человеком.
Use this free modern real estate listing presentation PowerPoint blueprint to organize pricing, marketing, property prep, agent value, and seller next steps.
Создайте в Excel шаблон сметы строительных работ, который можно распечатать, с четким указанием трудозатрат, материалов, формул, наценки, исключений и готовыми к печати итоговыми суммами для клиента.
Создавайте более эффективные видеоподсказки для Luma Dream Machine с помощью практичной формулы кинематографического освещения, многоразовых рецептов, примеров и быстрого контрольного списка для устранения неполадок.
Создайте минималистичную презентацию для инвесторов технологического стартапа в PowerPoint, используя правильный порядок слайдов, четкие правила дизайна, показатели эффективности и готовое к использованию приложение.
Предотвратите преобразование кодов, идентификаторов и дробей в даты в Excel. Используйте текстовый формат, апострофы, элементы управления импортом и текущие параметры Microsoft 365.
Ускорьте рендеринг ComfyUI SDXL за счет сокращения объема работы по сэмплированию, контроля разрешения и размера пакета, упрощения узлов, использования кэширования, а также безопасной настройки видеопамяти и механизма внимания.
Создайте в Excel практичную систему учета доходов и расходов от сдачи недвижимости в аренду, включающую четкие категории, формулы, ежемесячные сводки и рекомендации по ведению налоговой отчетности.
Создайте частную локальную базу знаний по искусственному интеллекту с помощью Ollama, AnythingLLM, локальных эмбеддингов и RAG. Изучите четырехэтапную настройку, проверки конфиденциальности, тестирование и резервное копирование.
Исправьте ошибки контекстного окна при анализе длинных документов, обрезав входные данные, разделив файлы, используя поиск и убедившись, что окончательный ответ охватывает исходный текст.
