Табыстар:
- Деректер ағып кету векторларын жедел, журнал, шығару және оқыту арқылы анықтау мүмкіндігі
- PII деректерін үлгіге жібермес бұрын редакциялау немесе таңбалау арқылы бүркемелеу мүмкіндігі
- Қауіпсіздік дизайнына деректерді нөлдік сақтау (ZDR) және деректер резиденттігі тұжырымдамаларын қосу мүмкіндігі
Ұйымның ең қымбат AI апаты әдетте әсем джейлбрейк емес, жаңа деректердің ағып кетуі болып табылады: қызметкер сезімтал тұтынушы файлын ассистентке қояды, бұл деректер провайдердің журналдарына түседі, содан кейін аудит «неліктен бұл деректер ұйымнан шықты?» Деп сұрайды. Сіз сұраққа тап боласыз: Бұл бөлімде біз ағып кетудің қайда болатынын, жеке деректерді (PII - Жеке сәйкестендіретін ақпарат, адамды анықтайтын деректер: аты-жөні, жеке куәлігі, электрондық поштасы, карта нөмірі) үлгіге жібермес бұрын және қандай корпоративтік қауіпсіздік шаралары (деректерді нөлдік сақтау, деректер резидентілігі) тәуекелді азайтатынын білеміз.
Ағып кету қайдан пайда болады? Төрт вектор
Қауіпсіздік немесе деректерді қорғау маманының психикалық картасы мынада: деректер ұйымнан тыс жерде немесе дұрыс емес адамдарға төрт жолмен жол таба алады:
- Шақыру арқылы: пайдаланушы құпия деректерді тікелей шақыруға қояды және ол деректер провайдеріне өтеді.
- Журнал арқылы: сұраулар мен жауаптар журналдарды жөндеу үшін өңделмеген түрде жазылады; Журналдарға рұқсаты бар кез келген адам деректерді көреді.
- Шығару арқылы: модель бір пайдаланушының деректерін басқа пайдаланушыға жібереді (әсіресе ортақ контексте немесе RAG).
- Жаттығу бойынша: Егер провайдер үлгіні үйрету үшін сіз жіберген деректерді пайдаланса, деректеріңіз болашақ жауаптарда көрсетілуі мүмкін.
Ескерту: Ең жиі еленбейтін вектор журнал болып табылады. Қолданба жақсы жұмыс істеп тұрса да, егер сізде өңделмеген сұрауды/жауапты тіркейтін кодтың бір жолы болса, PII деректерін өз жүйелеріңізге ағып жатырсыз.
Қадамдық: Маскировка құбыры (редакциялық құбыр)
- Анықтау. Мәтінді үлгіге жібермес бұрын PII өрістерін (regex, дайын PII детекторы немесе нысанды тану) табыңыз.
- Оны өзгертіңіз. Әрбір PII орнын толтырғышпен ауыстырыңыз: Ахмет Йылмаз → [AD_1], 12345678901 → [TCID_1].
- Картаны сақтаңыз. Толтырғышты ↔ нақты мәнді салыстыруды тек сіздің жағыңызда, уақытша және қауіпсіз картада сақтаңыз.
- Үлгіге маскаланған мәтінді жіберіңіз. Модель тек [AD_1] көреді, нақты деректерді ешқашан көреді.
- Регидратация. Модельдік жауап келгенде, толтырғыштарды картадағы нақты мәндермен ауыстырыңыз (ол рұқсат етілген пайдаланушыға көрсетілетін болса ғана).
Мұны токенизация деп те атайды: сезімтал мәнді қайтымды, бірақ мағынасыз таңбалауышпен ауыстыру. Редакция, керісінше, қайтарусыз толығымен жояды/көмескілендіреді — егер модельге нақты мән мүлде қажет болмаса, мұны таңдаған дұрыс.
Көшірілетін төрт үлгі
Шешімдерді жасыруға арналған қарапайым нұсқаулық:
Шешім қабылдау ережесі: Модельге өз жұмысын орындау үшін нақты PII КЕРЕК МА?- Жоқ (қорытындылау, жіктеу, тонды талдау) -> РЕДАКЦИЯ (қайтару жоқ)- Иә, бірақ тек бірізділік үшін (бір адамға бірдей сілтеме) -> ТОКЕНИЗАЦИЯ- Иә және нақты мән жасалады (жеке хат) -> маска, генерациялау, оның соңында толтыру
Түзету нұсқауы (егер код жағында детектор болмаса, кем дегенде үлгіге сәйкес):
Төмендегі мәтінді өңдеңіз. Жауапта қандай да бір жеке деректерді (аты-жөні, телефоны, электрондық поштасы, TR ID, IBAN, мекен-жайы) қайталамау керек. Оларға сілтеме жасау қажет болса, [PERSON], [PHONE], т.б. сияқты жалпы тегтерді пайдаланыңыз.<text>{{ entry }}</text>
Ағып кетуді тексеру сұрауы (өз журналдарыңызды сканерлеу үшін):
Төмендегі журналды тексеріңіз. Егер оның ішінде өңделмеген PII (TR ID: 11 сан, IBAN: TR-ден басталатын 26 таңба, электрондық пошта, карта нөмірі) болса, әрқайсысын өз түрімен санаңыз. Олардың ешқайсысын жауабыңызға көшірмеңіз; "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 күн бойы сақтайды және оны «қызмет көрсетуді жақсарту» үшін пайдалануға болады. Компания бұл тармақты қабылданбайды, себебі ол емделуші деректерін өңдейді; ZDR және деректер резиденттігіне кепілдік беретін 18% қымбатырақ провайдерді таңдаңыз. Кейінгі аудитте бұл шешім тәуекелді айтарлықтай төмендетті деп есептелді.
Жалпы қателер
- Модельге өңделмеген PII жіберу және шақыруда «сақтамау» деп теру арқылы қорғалған деп ойлау.
- Қолданбаны сақтау кезінде жөндеу журналдарындағы бастапқы шақыруды/жауапты ұмыту.
- Редакцияны токенизациямен шатастыру; бірізділік қажет жерде түзету және үлгіні жаңылыстырады.
- Толтырғыш ↔ қауіпті немесе тұрақты жерде нақты мән салыстыруды сақтайды.
- «Білім беруде пайдалану» кепілдігі мен «деректерді сақтау» кепілдігі бір нәрсе деп қателесу.
- Ешқашан деректердің резиденциясын сұрамайды (деректер қай елде өңделеді).
Қысқаша айтқанда
- Деректер төрт вектор арқылы ағып кетеді: жедел, журнал, шығыс және оқыту. Бұл көбінесе елеусіз қалатын журнал.
- Үлгіге жібермес бұрын PII маскасы: егер нақты мән қажет болмаса, редакциялау, консистенция қажет болса, токенизация.
- Толтырғышты ↔ нақты мәнді салыстыруды тек өзіңіз жақта, уақытша және қауіпсіз етіп сақтаңыз.
- ZDR (мәліметтерді нөлдік сақтау) және деректер резидентілігі жеткізушіні таңдаудағы шешуші корпоративтік кепілдіктер болып табылады.
- «Білім беру мақсатында пайдалану» және «деректерді сақтау» жеке кепілдіктер болып табылады; Келісімшартта екеуін де бөлек сұраңыз.
Қолданбалы тапсырма
Жеке AI құбыры арқылы өтетін нақты сұраудың бір мысалын алыңыз (сынақ деректерімен). Осы сұраудың (1) сұрауда, (2) журналда және (3) жауап беру кезеңдерінде қай PII көрсетілетінін белгілеңіз. Әрбір PII үшін «редакция, токенизация, жариялау мүлде жоқ па?» Шешім қабылдап, жаңа бетперде нұсқасын жазыңыз. Соңында, жоғарыдағы басқару шақыруымен журналдарда PII бар-жоғын тексеріңіз.
бақылау парағы
- [ ] Мен жүйемдегі ағып кетудің төрт векторын (шұғыл, журнал, шығыс, оқыту) салыстырдым.
- [ ] Үлгіге жібермес бұрын PII-ді бүркемелеймін (түзетемін/токенизациялаймын).
- [ ] Журналдарда PII жоқ; Тіркеу алдында тексеру жүргізіледі.
- [ ] Толтырғышты салыстыру уақытша және қауіпсіз сақталады.
- [ ] Мен келісім-шарт бойынша провайдерден ZDR және "білім беруде пайдаланбау" кепілдігін алдым.
- [ ] Деректер резиденциясына қойылатын талапты растадым (KVKK/GDPR).