Евидентирање, ревизијски траг и доказљивост

Добици:

• Способност да се дизајнира минимална шема ревизорског трага довољна да се реконструише догађај
• Способност да се спречи да дневник буде извор цурења маскирањем упита/одговора
• Способност успостављања проверљивих евиденција са корелационим идентитетом, непроменљивошћу и периодом задржавања

У систему вештачке интелигенције једног дана ће се сигурно поставити питање: „Зашто је ова одлука донета на овај начин, шта се тачно догодило тог дана?“ Ово питање може поставити купац, ревизор, регулатор или суд. Ваш одговор ће бити или проверљиви ревизорски траг или „не знамо“. Ово последње је неприхватљиво у корпоративном окружењу. У овој јединици ћемо научити шта треба, а шта не треба да се евидентира посебно за АИ, како успоставити ревизијски траг и како одржавати евиденцију у равнотежи са безбедношћу и приватношћу.

Зашто се евидентирање разликује у АИ?

У класичном софтверу се евидентира „ко је шта урадио“. У АИ, три нове димензије су додате овоме: који модел/верзија је коришћен, који упит је послат и какав је одговор произведен. Када дође до грешке или жалбе, не можете реконструисати инцидент без ова три. Али овај веома брз/одговор може садржати ПИИ, као што смо видели у јединици 2 - што значи да сам дневник може постати извор цурења. Ово је уметност равнотеже.

Опрез: Евидентирање није „све евидентирати“. Превише евидентирања ствара ризик за приватност, а премало евидентирања ствара недостатак доказа. Циљ је да се задржи довољно ПИИ да би се догађај реконструисао маскирањем.

Шта треба да се евидентира? Шема ревизијске стазе

Чврсти АИ ревизорски траг укључује, у најмању руку:

• Ко: ИД корисника и улога (или ИД услуге).
• Када: Временска ознака (додавање само ако је могуће).
• Шта: Жељена акција и позвани алати.
• Који модел: назив модела и верзија (нпр. Цлауде-опус-4-8), критични параметри као што је температура.
• Улазно/излазни сажетак: маскирана верзија или сажетак/хеш захтева и одговора.
• Одлука: Да ли је обрађена аутоматски, отишла код човека, да ли је одобрена или одбијена?
• Резултат: Да ли је операција успешна или грешка, који ресурс је погођен?

Корак по корак: Успостављање ревизорског трага

1. Поставите циљ. Ко ће читати ове дневнике и зашто? (Реакција на инциденте, ревизија усклађености, отклањање грешака.) Сврха одређује шта ћете задржати.
2. Спроведите политику која може да открије идентитет. Маскирајте промпт/одговор пре евидентирања (јединица 2).
3. Обезбедите непроменљивост. Нека критични дневники буду само додаци; Нико не би требало да буде у стању да тихо избрише прошлост.
4. Дефинишите период задржавања. Одредити трајање у складу са равнотежом законских захтева и поверљивости; Аутоматски избришите када време истекне.
5. Ограничите приступ. Приступ евиденцијама такође треба да буде заштићен РБАЦ-ом; Читање дневника такође треба да се евидентира.
6. Додајте ИД корелације (ИД трага). Повежите све кораке захтева (унос, позив алата, верификација, излаз) са једним идентитетом.

Четири шаблона за копирање

Шема евиденције ревизије (ЈСОН):

{ "траце_ид": "...", "тиме": "ГГГГ-ММ-ДДТхх:мм:ссЗ", "усер": "...", "роле": "...", "модел": "цлауде-опус-4-8", "параметерс": { "температуре": 0 }, "рекуест_ресскерид": "мм": "мм" "<маскиран>", "алати": ["тоол_а", "тоол_б"], "одлука": "ауто|хуман_аппровал", "одобрење": "одобрено|одбијено|ништа", "резултат": "успех|грешка", "захваћени_ресурс": "..."}

Упути за контролу ПИИ:

Погледајте примере дневника у наставку. Да ли су поља потребна за ревизијски траг (ко, када, модел, одлука, резултат) попуњена? Да ли је такође процурела необрађена ПИИ? За сваки ред, пријавите као: „недовољно / недостаје простора: ... /ПИИ цурење: ...“ <логс>{{ екамплес }}</логс>

Упит за поновну изградњу догађаја:

Следећи записи ревизије припадају једном траце_ид. Претворите догађај у наратив хронолошким редоследом: шта је корисник желео, шта је модел урадио, које су провере спроведене, како је донета одлука, какав је био исход? Означите недостајуће или недоследне кораке.<рецордс>{{ траце_регистерс }}</рецордс>

Правило одлуке о политици задржавања:

За сваки тип дневника одредите: - Да ли постоји законска обавеза задржавања? (минимални период ако постоји) – Да ли садржи ПИИ? (ако је укључено, скратити трајање, сузити приступ) - Докази о безбедносном инциденту? (продавница се не може променити) Резултат: „продавница Н дана + само додавање ми + ниво приступа“.

Слаба порука / јака промпт

лош приступ

Снажан приступ

Уопште се не евидентира („не треба“)

Евидентирање минималног скупа за реконструкцију догађаја

Евидентирање необрађеног упита/одговора какав јесте

Маскирани резиме + евидентирање ИД-а трага

Чувајте дневнике неограничено

Период задржавања са балансом права + приватност

Свако може да избрише евиденцију

Критичне евиденције се само додају, приступ контролисан

Три мини кућишта

Случај 1 — Траце ИД је смањио једнодневну истрагу на 15 минута. „Моја пријава је неправедно одбијена“, рекао је клијент помоћнику банке за претходну процену кредита. Захваљујући ИД-у корелације, тим је реконструисао унос те апликације, верификације запослених и одлуку за 15 минута; је показао да је грешка узрокована нетачним прагом у валидацији правила и поправио је.

Случај 2 — У ревизији је откривено прекомерно евидентирање. Компанија за е-трговину је писала све упите/одговоре у необрађене дневнике за отклањање грешака. Током годишње ревизије уочено је да ови дневници садрже адресе и бројеве телефона купаца и да су чувани 2 године. Налаз је затворен преласком на политику маскирања + 90-дневно задржавање; Сачувана је функција ревизорског трага.

Случај 3 — Дневник само за додавање открио је интерну злоупотребу. Запослени код једног провајдера покушао је да избрише евиденцију како би сакрио погрешну групу коју је направио. Пошто се евиденције само додају и покушаји читања/брисања дневника се снимају, покушај је одмах био видљив; Инцидент је резултирао дисциплинским и процесним поправком.

Савет: Доделите ИД корелације (ИД праћења) сваком захтеву и проведите га кроз све кораке. Када дође до проблема, могућност прикупљања „све у вези са тим захтевом“ са једним упитом је највећи акцелератор одговора на инцидент.

Уобичајене грешке

• Уопште се не евидентира, или се бележи толико мало да не можете да реконструишете догађај.
• Евидентирање необрађеног захтева/одговора без маске и претварање дневника у извор цурења.
• Не евидентира се име/верзија модела и одлука (аутоматски/људски).
• Чување дневника на неограничени временски период повећава ризик приватности.
• Остављање критичних дневника подложним променама; Не евидентира приступ дневнику.
• Није у могућности да повеже кораке заједно јер не користи ИД корелације (ИД трага).

Укратко

• АИ евидентирање додаје три димензије „ко је шта урадио“: који модел/верзија, који упит, који одговор.
• Циљ је да се ПИИ одржи довољно минималним да се реконструише догађај маскирањем – ни више, ни мање.
• Ревизорски траг треба да садржи поља ко/када/шта/који модел/одлука/резултат.
• Критичне евиденције треба да се додају само, приступ треба да буде ограничен, а приступ евиденцији такође треба да се евидентира.
• ИД корелације (ИД трага) повезује све кораке захтева и убрзава истрагу инцидента.

Задатак апликације

Изаберите захтев из сопственог тока вештачке интелигенције и напишите идеалан ревизорски траг за њега помоћу ЈСОН шеме изнад. Затим урадите два теста: (1) Можете ли испричати причу од почетка до краја само овим снимком? (2) Да ли у евиденцији постоји необрађена особа која открива идентитет? Ако недостаје поље, додајте га, ако постоји ПИИ, маскирајте га. На крају, подесите период задржавања и ниво приступа.

контролна листа

• [ ] Ревизорски траг укључује поља ко/када/шта/образац/одлука/резултат.
• [ ] Промпт/одговор је маскиран пре евиденције (без ПИИ).
• [ ] Сваком захтеву се додељује ИД корелације (ИД трага).
• [ ] Критичне евиденције се само додају и контролишу приступ.
• [ ] Период складиштења је дефинисан равнотежом правних и поверљивих података и брише се на крају периода.
• [ ] Са евиденцијама могу да реконструишем догађај за мање од 30 минута.