Добивки:
- Способност да се дизајнира минимална шема за ревизорска патека доволна за реконструкција на настанот
- Способност да се спречи дневникот да биде извор на истекување со маскирање на известувањето/одговорот
- Способност да се воспостават проверливи логови со корелациски идентитет, непроменливост и период на задржување
Во систем со вештачка интелигенција, еден ден сигурно ќе се постави прашањето: „Зошто оваа одлука беше донесена на овој начин, што точно се случи тој ден?“ Ова прашање може да го постави клиент, ревизор, регулатор или суд. Вашиот одговор ќе биде или проверлива ревизорска трага или „не знаеме“. Последново е неприфатливо во корпоративна средина. Во оваа единица, ќе научиме што треба и што не треба да се евидентира специфично за вештачката интелигенција, како да се воспостави ревизорска трага и како да се одржуваат дневници во рамнотежа со безбедноста и приватноста.
Зошто евиденцијата е различна во вештачката интелигенција?
Во класичниот софтвер, „кој направи што“ е логиран. Во вештачката интелигенција, на ова се додадени три нови димензии: кој модел/верзија е користен, каков потсетник е испратен и каков одговор е произведен. Кога ќе се појави грешка или жалба, не можете да го реконструирате инцидентот без овие три. Но, оваа брза/одговор може да содржи PII, како што видовме во единицата 2 - што значи дека самиот дневник може да стане извор на протекување. Ова е уметност на рамнотежа.
Внимание: логирањето не е „пријавете сè“. Премногу сеча создава ризик за приватност, а премалата евиденција создава недостаток на докази. Целта е да се задржи доволно PII за да се реконструира настанот со негово маскирање.
Што треба да се евидентира? Шема на патека за ревизија
Солидна патека за ревизија на вештачката интелигенција вклучува, минимум:
- Кој: Кориснички ID и улога (или ID на услуга).
- Кога: Временски печат (додадете само ако е можно).
- Што: посакувана акција и повикани алатки.
- Кој модел: Име и верзија на моделот (на пр. claude-opus-4-8), критични параметри како температура.
- Дигест за влез/излез: маскирана верзија или дигест/хаш на барањето и одговорот.
- Одлука: Дали се обработуваше автоматски, отиде кај човек, дали беше одобрено или одбиено?
- Резултат: Дали операцијата е успешна или е грешка, кој ресурс е засегнат?
Чекор по чекор: Воспоставување на патека за ревизија
- Поставете цел. Кој ќе ги чита овие дневници и зошто? (Одговор на инцидент, ревизија на усогласеност, дебагирање.) Целта одредува што ќе чувате.
- Спроведување на политиката за PII. Маскирајте го известувањето/одговорот пред да се најавите (единица 2).
- Обезбедете непроменливост. Нека критичните логови се само за додатоци; Никој не треба да може тивко да го избрише минатото.
- Дефинирајте период на задржување. Одредете го времетраењето според билансот на законските барања и доверливоста; Автоматско бришење кога ќе истече времето.
- Ограничете го пристапот. Пристапот до дневниците исто така треба да биде заштитен со RBAC; Треба да се евидентира и читање на дневникот.
- Додадете корелација ID (трага ID). Поврзете ги сите чекори на барањето (влез, повик на алатка, верификација, излез) со единствен идентитет.
Четири шаблони за копирање
Шема за евиденција за ревизија (JSON):
{ "trace_id": "...", "time": "YYYY-MM-DDThh:mm:ssZ", "user": "...", "role": "...", "model": "claude-opus-4-8", "parameters": { "temperature": 0 }, "request_summary:": "<ma. "<masked>", "tools": ["tool_a", "tool_b"], "decision": "auto|human_approval", "oproval": "одобрено|отфрлено|нема", "резултат": "успешно|грешка", "погоден_ресурс": "..."}
Контролно известување за PII за евиденција:
Проверете ги примерите на дневниците подолу. Дали се комплетирани полињата потребни за ревизорската патека (кој, кога, модел, одлука, резултат)? Исто така, дали протекоа необработени PII? За секој ред, пријавете го како: „нема доволно / недостасува простор: ... /ПИИ протекување: ...“ <logs>{{ примери }}</logs>
Промоција за обнова на настанот:
Следниве ревизорски записи припаѓаат на еден trace_id. Претворете го настанот во наратив по хронолошки редослед: што сакал корисникот, што направил моделот, какви валидации биле извршени, како била донесена одлуката, каков бил исходот? Означете дека недостасуваат или неконзистентни чекори.<records>{{ trace_registers }}</records>
Правило за одлука за политика за задржување:
За секој тип на дневник, одреди: - Дали има законска обврска за задржување? (минимален период доколку има)- Дали содржи PII? (ако е вклучено, скратете го времетраењето, стеснете го пристапот) - Доказ за безбедносен инцидент? (продавницата не може да се промени) Резултат: „зачувај N дена + само за додавање mi + ниво на пристап“.
Слаба навестување / Силен навестување
лош пристап
Силен пристап
Воопшто не се најавува („не треба“)
Пријавување на минималното множество за реконструкција на настанот
Пријавување на необработено известување/одговор како што е
Маскирано резиме + евиденција за идентификација на трага
Чувајте ги дневниците неограничено
Период на задржување со биланс на правни + приватност
Секој може да ги избрише дневниците
Критичните дневници се само за додатоци, пристапот е контролиран
Три мини футроли
Случај 1 - Trace ID ја намали дневната истрага на 15 минути. „Мојата апликација беше неправедно одбиена“, му рекол клиент на асистентот за предевалуација на кредитот во банка. Благодарение на корелацијата ID, тимот го реконструираше внесувањето на таа апликација, проверките на вработените и одлуката за 15 минути; покажа дека грешката е предизвикана од неточен праг во валидацијата на правилата и ја поправи.
Случај 2 - Откриена е прекумерна сеча во ревизијата. Компанија за е-трговија ги пишуваше сите барања/одговори на необработени дневници за дебагирање. За време на годишната ревизија, беше забележано дека овие дневници содржат адреси на клиенти и телефонски броеви и се чуваат 2 години. Наодот беше затворен со префрлување на политика за маскирање + 90-дневно задржување; Функцијата на ревизорската патека беше зачувана.
Случај 3 - Дневникот само за додатоци откри внатрешна злоупотреба. Вработен во еден провајдер се обидел да ги избрише дневниците за да скрие погрешна серија што ја направил. Бидејќи дневниците се само за додавање и обидите за читање/бришење на дневниците се снимаат, обидот беше веднаш видлив; Инцидентот резултираше со дисциплинска и процесна корекција.
Совет: Доделете ID на корелација (ID на трага) на секое барање и спроведете го низ сите чекори. Кога ќе се појави проблем, можноста да се собере „сè за тоа барање“ со едно барање е најголемиот забрзувач на одговорот на инцидентот.
Вообичаени грешки
- Воопшто не се најавувате или се најавувате толку малку што не можете да го реконструирате настанот.
- Пријавување на необработеното барање/одговор без маска и претворање на дневникот во извор на истекување.
- Не евидентирано име/верзија и одлука на моделот (автоматско/човечко).
- Складирањето дневници на неограничен временски период го зголемува ризикот за приватност.
- Оставањето на критичните дневници предмет на промена; Не се најавува пристап до дневникот.
- Не може да се поврзат чекорите заедно бидејќи не користи корелација ID (trace ID).
Сумирано
- Вклучувањето на вештачката интелигенција додава три димензии на „кој што направил“: кој модел/верзија, кој потсетник, кој одговор.
- Целта е да се задржи PII доволно минимален за да се реконструира настанот со негово маскирање - ни повеќе, ни помалку.
- Ревизорската патека треба да вклучува полиња кој/кога/што/кој модел/одлука/резултат.
- Критичните дневници треба да бидат само додадени, пристапот треба да биде ограничен, а пристапот во дневникот исто така треба да се евидентира.
- Корелација ID (trace ID) ги поврзува сите чекори на барањето и ја забрзува истрагата за инцидентот.
Задача за апликација
Изберете барање од вашиот сопствен тек на вештачка интелигенција и напишете ја идеалната трага за ревизија за него со шемата JSON погоре. Потоа направете два теста: (1) Дали можете да ја раскажете приказната од почеток до крај само со оваа снимка? (2) Дали има необработени PII во записот? Ако недостасува поле, додадете го, ако има PII, маскирајте го. Конечно, поставете период на задржување и ниво на пристап.
листа за проверка
- [ ] Ревизорската патека вклучува полиња кој/кога/што/шаблон/одлука/резултат.
- [ ] Промптот/одговорот е маскиран пред дневниците (нема PII).
- [ ] На секое барање се доделува корелација ID (trace ID).
- [ ] Критичните дневници се само за додатоци и пристапот е контролиран.
- [ ] Периодот на складирање е дефиниран со правното + салдо за доверливост и се брише на крајот на периодот.
- [ ] Со дневници можам да реконструирам настан за помалку од 30 минути.