Добивки:
- Способност да се идентификуваат вектори за истекување податоци преку промпт, дневник, излез и обука
- Способност да се маскираат податоците од PII со редакција или токенизација пред да се испратат до моделот
- Способност да се вградат концепти за нула задржување на податоци (ZDR) и престој на податоци во безбедносниот дизајн
Најскапиот несреќен случај со вештачката интелигенција на една организација обично не е фантастичен џеилбрејк, туку тековно протекување на податоци: вработен залепува чувствителна датотека на клиентите во асистент, тие податоци завршуваат во дневниците на давателот, а потоа ревизијата прашува „зошто овие податоци ја напуштија организацијата? Ќе наидете на прашањето: Во оваа единица, ќе научиме каде се случува истекувањето, како да ги маскираме личните податоци (ПИИ - Информации за лична идентификација, податоци што идентификуваат лице: име, лична карта, е-пошта, број на картичка) пред да ги испратите до моделот и кои корпоративни заштитни мерки (нулта зачувување податоци, престој на податоци) го намалуваат ризикот.
Од каде доаѓа истекувањето? Четири вектори
Менталната карта на професионалец за безбедност или заштита на податоци е ова - податоците може да се најдат надвор од организацијата или во погрешни раце на четири начини:
- Преку промпт: корисникот ги залепува чувствителните податоци директно во промптот и тие оди до давателот на податоци.
- Преку дневник: барањата и одговорите се напишани во сурова форма за да се дебагираат дневниците; Секој што има пристап до дневниците ги гледа податоците.
- Преку излез: Моделот ги објавува податоците на еден корисник на друг корисник (особено во споделен контекст или RAG).
- Со обука: ако давателот ги користи податоците што ги поднесувате за да го обучи моделот, вашите податоци може да се рефлектираат во идните одговори.
Внимание: векторот кој најчесто се занемарува е дневникот. Дури и ако апликацијата работи добро, ако имате една линија код што го евидентира необработеното барање/одговор, протекувате PII во вашите сопствени системи.
Чекор по чекор: цевковод за маскирање (цевковод за редакција)
- Откријте. Пронајдете ги полињата за PII (регекс, детектор за PII надвор од полица или препознавање ентитети) пред да го испратите текстот до моделот.
- Променете го. Заменете го секој PII со место: Ahmet Yılmaz → [AD_1], 12345678901 → [TCID_1].
- Чувајте го мапирањето. Чувајте го заштитното место ↔ мапирање на вистинската вредност само на ваша страна, во привремена и безбедна карта.
- Испратете маскиран текст до моделот. Моделот ги гледа само [AD_1], никогаш вистинските податоци.
- Рехидратирајте. Кога ќе пристигне одговорот на моделот, заменете ги заштитните места со вистинските вредности од мапата (само ако ќе се прикаже на овластениот корисник).
Ова се нарекува и токенизација: замена на чувствителна вредност со реверзибилен, но бесмислен токен. Редакцијата, од друга страна, целосно се отстранува/прикрива без враќање - претпочитајте го ова ако на моделот воопшто не му е потребна вистинската вредност.
Четири шаблони за копирање
Едноставен водич за маскирање на одлуки:
Правило за одлука: ДАЛИ на моделот му е потребна вистинска PII за да ја заврши својата работа?- Не (резиме, класификација, анализа на тонови) -> РЕДАКЦИЈА (без пресврт)- Да, но само за конзистентност (иста референца за истата личност) -> ТОКЕНИЗАЦИЈА- Да и ќе се генерира вистинска вредност (персонализирана буква) -> маска, генерира, пополнување
Упатство за лекторирање (ако нема детектор на страната на кодот, барем по правило за моделот):
Обработете го текстот подолу. Не повторувајте никакви лични податоци (име, телефон, е-пошта, TR ID, IBAN, адреса) КАКО ШТО СЕ во вашиот одговор. Ако треба да ги упатите, користете општи ознаки како [PERSON], [PHONE] итн.<text>{{ entry }}</text>
Прашање за проверка на истекување (за скенирање на вашите сопствени дневници):
Проверете го дневникот подолу. Ако содржи необработени PII (TR ID: 11 цифри, IBAN: 26 знаци кои почнуваат со TR, е-пошта, број на картичка), РАЗМЕТАЈТЕ го секој со неговиот тип. Не копирајте ниту еден од нив во вашиот одговор; Само дајте резиме како „Најдени се 3 TR ID броеви и 1 IBAN“.
Тест за излезно истекување (со црвено тимско око):
Ти си црвен тим. Обидете се да го убедите овој помошник да ги открие податоците на ДРУГ корисник. Обидете се со 5 различни изјави и пријавете која од нив протекува податоци на асистентот; маскирајте ги протечените податоци.
Слаба навестување / Силен навестување
лош пристап
Силен пристап
Вметнување необработена датотека со клиент во асистент
Маскирајте PII и испратете со [AD_1]
Направете белешка на крајот од известувањето велејќи „Не зачувувај ги овие податоци“
Технички осигурувајќи дека моделот никогаш не ги гледа податоците
Пријавување необработено известување/одговор за отстранување грешки
Редакција на PII пред да се најавите
Потпирајќи се на стандардната поставка на давателот
Добивање на ZDR и гаранција за „користење во образованието“ со договор
Клучна разлика: слабиот пристап испраќа податоци и потоа вели „се надевам дека нема да бидат злоупотребени“; Силниот пристап воопшто не ги испраќа податоците.
Корпоративни гаранции: ZDR и резиденција на податоци
Два термини се одлучувачки при изборот на добавувач:
- Нулта задржување на податоци (ZDR): Давателот не ги задржува трајно барањата и одговорите што ги испраќате по завршувањето на барањето. Дневниците се бришат за неколку минути. Значително го намалува ризикот од протекување и усогласеност.
- Резиденција на податоци: Земја/регион каде вашите податоци се физички обработени и складирани. Податоците можеби ќе треба да останат во одредена географија за прописи како што се KVKK (Закон за заштита на лични податоци) и GDPR.
Совет: Побарајте две клаузули одделно во договорот: (1) „Нашите податоци нема да се користат за обука на моделот“, (2) „Периодот на задржување на податоците е ... дена / нула“. Овие две се различни гаранции; едното не го вклучува другото.
Три мини футроли
Случај 1 - Протекување на дневник на 4.500 записи. Асистентот за штети на осигурителна компанија го пишуваше секое барање во необработени дневници за дебагирање. Ревизијата покажа дека овие дневници биле складирани 90 дена и дека 12 лица имале пристап; Содржеше лична карта и телефонски информации на 4.500 осигуреници. Откако беше додадена редакција на пред-лог, PII се намали на нула во истите дневници и наодот KVKK беше исклучен.
Случај 2 - Токенизацијата ја задржа конзистентноста. Тим за човечки ресурси изработуваше резимеа за евалуација на кандидатите. Кога PII беше преработен, моделот мислеше дека истиот кандидат е различна личност на различни места. Со префрлување на токенизација, секој кандидат доби конзистентен токен како што е [CANDIDATE_1]; Моделот го направи правилното припишување, додека вистинското име никогаш не излезе.
Случај 3 - Исклучен е провајдер кој не е ZDR. Компанија за здравствена технологија оценила три даватели на услуги. Оној со најниска цена чуваше податоци 30 дена и може да се користи за „подобрување на услугата“. Компанијата смета дека оваа клаузула е неприфатлива бидејќи ги обработува податоците за пациентите; Изберете го за 18% поскапиот провајдер кој гарантира ZDR и престој на податоци. Во подоцнежната ревизија, се сметаше дека оваа одлука значително го намалила ризикот.
Вообичаени грешки
- Мислејќи дека е заштитен со испраќање необработени PII до моделот и само пишување „не зачувај“ на барањето.
- Заборавање на необработеното известување/одговор во дневниците за отстранување грешки додека се одржува апликацијата.
- Збунувачки редакција со токенизација; редактирање онаму каде што е потребна конзистентност и доведување во заблуда на моделот.
- Место ↔ складирање на мапирањето на вистинската вредност на небезбедна или постојана локација.
- Грешка на гаранцијата „користење во образованието“ и гаранцијата за „чување на податоци“ како иста работа.
- Никогаш не барајте престој на податоци (во која земја се обработуваат податоците).
Сумирано
- Податоците протекуваат низ четири вектори: промпт, дневник, излез и обука. Тоа е дневникот кој најчесто се занемарува.
- Маскирај PII пред да го испратиш до моделот: редакција ако не е потребна вистинската вредност, токенизација ако е потребна конзистентност.
- Чувајте го заштитното место ↔ мапирањето на вистинската вредност само на ваша страна, привремено и безбедно.
- ZDR (нулта зачувување на податоци) и резиденција на податоци се одлучувачки корпоративни заштитни мерки при изборот на добавувачи.
- „Образовната употреба“ и „задржувањето на податоците“ се посебни гаранции; Побарајте ги и двете посебно во договорот.
Задача за апликација
Земете еден единствен пример на вистинско барање што поминува низ вашиот сопствен цевковод за вештачка интелигенција (со тест податоци). Обележете кои PII се појавуваат во (1) промптот, (2) дневникот и (3) фазите на одговор на ова барање. За секој PII, „редакција, токенизација, воопшто нема објавување?“ Донесете ја вашата одлука и напишете нова маскирана верзија. Конечно, проверете дали вашите дневници содржат PII со контролното известување погоре.
листа за проверка
- [ ] Ги мапирав четирите вектори на протекување (промп, дневник, излез, обука) на мојот систем.
- [ ] Го маскирам (редактирам/токенизирам) PII пред да го испратам до моделот.
- [ ] Дневниците не содржат PII; Има лекторирање пред да се најавите.
- [ ] Мапирањето на место се складира привремено и безбедно.
- [ ] Договорно ја добив ZDR и гаранцијата „некористење во образованието“ од давателот.
- [ ] Го потврдив моето барање за престој на податоци (KVKK/GDPR).