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