Прибыль:
- Способность выявлять векторы утечки данных с помощью подсказок, журналов, выходных данных и обучения.
- Возможность маскировать данные PII с помощью редактирования или токенизации перед отправкой их в модель.
- Возможность включения концепций нулевого хранения данных (ZDR) и резидентности данных в дизайн безопасности.
Самая дорогостоящая ошибка ИИ в организации обычно — это не причудливый побег из тюрьмы, а обычная утечка данных: сотрудник вставляет конфиденциальный файл клиента в помощник, эти данные попадают в журналы провайдера, а затем аудит спрашивает: «Почему эти данные покинули организацию?» Вы столкнетесь с вопросом: в этом модуле мы узнаем, где происходит утечка, как замаскировать личные данные (PII - Personal Identified Information, данные, которые идентифицируют человека: имя, идентификатор, адрес электронной почты, номер карты) перед отправкой их модели и какие корпоративные меры безопасности (нулевое сохранение данных, постоянное местонахождение данных) снижают риск.
Откуда берется утечка? Четыре вектора
Ментальная карта специалиста по безопасности или защите данных такова: данные могут попасть за пределы организации или попасть в чужие руки четырьмя способами:
- Через приглашение: пользователь вставляет конфиденциальные данные непосредственно в приглашение, и они передаются поставщику данных.
- Через журнал: запросы и ответы записываются в журналы отладки в необработанной форме; Любой, у кого есть доступ к журналам, видит данные.
- Через вывод: модель передает данные одного пользователя другому пользователю (особенно в общем контексте или RAG).
- Путем обучения. Если поставщик использует предоставленные вами данные для обучения модели, ваши данные могут быть отражены в будущих ответах.
Внимание: наиболее часто упускаемый из виду вектор — это журнал. Даже если приложение работает нормально, если у вас есть одна строка кода, которая регистрирует необработанный запрос/ответ, вы сливаете личные данные в свои собственные системы.
Шаг за шагом: конвейер маскировки (конвейер редактирования)
- Обнаружить. Найдите поля PII (регулярное выражение, готовый детектор PII или распознавание объектов) перед отправкой текста в модель.
- Измените это. Замените каждую идентификационную информацию заполнителем: Ахмет Йылмаз → [AD_1], 12345678901 → [TCID_1].
- Сохраните картографию. Храните сопоставление заполнителя ↔ фактического значения только на вашей стороне, на временной и безопасной карте.
- Отправьте замаскированный текст в модель. Модель видит только [AD_1] и никогда не видит фактические данные.
- Регидратируйте. Когда поступит ответ модели, замените заполнители фактическими значениями с карты (только если она будет отображаться авторизованному пользователю).
Это также называется токенизацией: замена конфиденциального значения обратимым, но бессмысленным токеном. Редактирование, с другой стороны, полностью удаляет/скрывает без возврата — предпочтите это, если модели вообще не требуется фактическое значение.
Четыре копируемых шаблона
Простое руководство по маскировке решений:
Правило принятия решения: НУЖНА ЛИ модели реальная PII для выполнения своей работы? - Нет (суммирование, классификация, тональный анализ) -> РЕДАКТИРОВАНИЕ (без отмены) - Да, но только для согласованности (одна и та же ссылка на одного и того же человека) -> ТОКЕНИЗАЦИЯ - Да, и будет сгенерирована реальная ценность (персонализированное письмо) -> маска, генерация, заполнение на конце
Инструкция по корректировке (если нет детектора на стороне кода, по крайней мере, как правило, на модели):
Обработайте текст ниже. Не повторяйте никакие личные данные (имя, телефон, адрес электронной почты, TR ID, IBAN, адрес) КАК ЕСТЬ в своем ответе. Если вам нужно сослаться на них, используйте общие теги, такие как [ЧЕЛОВЕК], [ТЕЛЕФОН] и т. д.<text>{{entry }}</text>
Запрос на проверку утечек (для сканирования собственных журналов):
Посмотрите журнал ниже. Если он содержит необработанные PII (идентификатор TR: 11 цифр, IBAN: 26 символов, начинающихся с TR, электронной почты, номера карты), ПОДСЧИТАЙТЕ каждый из них по его типу. Не копируйте ни одного из них в свой ответ; Просто дайте резюме типа «Найдено 3 номера TR ID и 1 IBAN».
Проверка утечки на выходе (с красным глазом):
Вы член красной команды. Попробуйте убедить этого помощника раскрыть данные ДРУГОГО пользователя. Попробуйте 5 разных операторов и сообщите, какой из них сливает данные ассистенту; замаскировать утекшие данные.
Слабая подсказка/Сильная подсказка
плохой подход
Сильный подход
Вставка необработанного файла клиента в помощник
Замаскируйте личные данные и отправьте их с помощью [AD_1]
Сделайте пометку в конце приглашения: «Не сохранять эти данные».
Технически гарантируя, что модель никогда не увидит данные
Регистрация необработанного запроса/ответа для отладки
Редактирование личных данных перед входом в систему
Использование настроек провайдера по умолчанию
Получение ЗДР и гарантии «использование в образовании» по договору
Ключевое отличие: слабый подход отправляет данные, а затем говорит: «Надеюсь, они не будут использованы неправильно»; Сильный подход вообще не отправляет данные.
Корпоративные гарантии: ZDR и резидентность данных
Два условия являются решающими при выборе поставщика:
- Нулевое сохранение данных (ZDR). Поставщик не сохраняет постоянно запросы и ответы, которые вы отправляете после завершения запроса. Журналы удаляются в течение нескольких минут. Значительно снижает риск утечек и соблюдения требований.
- Местонахождение данных: страна/регион, где ваши данные физически обрабатываются и хранятся. Возможно, данные должны оставаться в определенном регионе в соответствии с такими правилами, как KVKK (Закон о защите персональных данных) и GDPR.
Совет: Ищите в договоре отдельно два пункта: (1) «Наши данные не будут использоваться для обучения модели», (2) «Срок хранения данных составляет ... дней/ноль». Это две разные гарантии; одно не включает в себя другое.
Три мини-кейса
Случай 1. Утечка журнала из 4500 записей. Помощник страховой компании по урегулированию претензий записывал каждый запрос в необработанные журналы для отладки. Проверка показала, что эти журналы хранились 90 дней и доступ имели 12 человек; Он содержал удостоверения личности и телефонную информацию 4500 страхователей. После добавления предварительного редактирования журнала PII уменьшился до нуля в тех же журналах, а обнаружение KVKK было отключено.
Случай 2. Токенизация сохранила согласованность. Отдел кадров готовил резюме оценки кандидатов. Когда персональные данные были отредактированы, модель подумала, что один и тот же кандидат — это разные люди в разных местах. Перейдя на токенизацию, каждый кандидат получил согласованный токен, например [CANDIDATE_1]; Модель дала правильную атрибуцию, а настоящее имя так и не раскрылось.
Случай 3 — Исключение поставщика услуг, не сотрудничающего с ZDR. Фирма, занимающаяся технологиями здравоохранения, провела оценку трех поставщиков. Тот, у которого была самая низкая цена, хранил данные в течение 30 дней и мог быть использован для «улучшения обслуживания». Компания сочла этот пункт неприемлемым, поскольку она обрабатывает данные пациентов; Выберите поставщика, который на 18 % дороже и гарантирует ZDR и резидентность данных. В ходе последующего аудита было сочтено, что это решение значительно снизило риск.
Распространенные ошибки
- Думая, что он защищен отправкой необработанных PII в модель и простым вводом «не сохранять» в командной строке.
- Забывание необработанного запроса/ответа в журналах отладки при обслуживании приложения.
- Запутывающая редактирование с токенизацией; редактирование там, где необходима последовательность, и введение модели в заблуждение.
- Заполнитель ↔ сохранение фактического сопоставления значений в небезопасном или постоянном месте.
- Спутать гарантию «использования в образовании» и гарантию «хранения данных» как одно и то же.
- Никогда не запрашивайте место жительства данных (в какой стране обрабатываются данные).
В заключение
- Утечка данных осуществляется по четырем векторам: приглашение, журнал, вывод и обучение. Именно этот журнал чаще всего упускают из виду.
- Замаскируйте PII перед отправкой в модель: редактирование, если фактическое значение не требуется, токенизация, если необходима согласованность.
- Храните отображение заполнителя ↔ фактического значения только на вашей стороне, временно и безопасно.
- ZDR (нулевое сохранение данных) и постоянство данных являются решающими корпоративными гарантиями выбора поставщика.
- «Использование в образовательных целях» и «сохранение данных» являются отдельными гарантиями; Просите и то, и другое отдельно в договоре.
Задача приложения
Возьмите один пример реального запроса, проходящего через ваш собственный конвейер ИИ (с тестовыми данными). Отметьте, какой PII отображается на этапах (1) запроса, (2) журнала и (3) ответа этого запроса. Для каждой личной информации «редактирование, токенизация, отсутствие публикации вообще?» Примите решение и напишите новую замаскированную версию. Наконец, проверьте, содержат ли ваши журналы идентификационные данные, с помощью контрольной подсказки выше.
контрольный список
- [ ] Я сопоставил четыре вектора утечек (подсказка, журнал, выходные данные, обучение) в своей системе.
- [ ] Я маскирую (отредактирую/токенизирую) персональные данные перед отправкой их в модель.
- [ ] Журналы не содержат личных данных; Перед регистрацией проводится корректура.
- [ ] Сопоставление заполнителей сохраняется временно и надежно.
- [ ] По договору я получил от поставщика ZDR и гарантию «неиспользования в образовательных целях».
- [ ] Я подтвердил требования к месту жительства своих данных (KVKK/GDPR).