Monitorizare¶
Administratorii auditează utilizarea AI în .
Jurnale¶
(ai.log)
Fiecare eveniment semnificativ de chat/instrument poate produce un rând de jurnal: utilizator, companie, instrument, model, succes/eșec, dacă s-a folosit sudo (ar trebui să fie fals pentru operațiunile comerciale), durată și conținut opțional.
Preferați nivelul de jurnalizare Doar metadate în producție.
Jurnalele cu încărcătură completă pot conține date personale și secrete lipite de utilizatori — restrângeți corespunzător accesul și retenția.
Jurnalele sunt păstrate pentru audit; pașii rulărilor au o setare separată de retenție.
Încălcări¶
Evenimentele relevante pentru securitate (modele blocate, refuzuri de canal, abuzuri de politică etc.) creează înregistrări de încălcare. Avertismentele acumulate în fereastra configurată duc la o blocare temporară.
Analizați încălcările pentru a:
depista încercările de prompt injection;
găsi audiențe de canal configurate greșit (zgomot de refuzuri);
detecta utilizatorii care testează ștergerea/scrierea fără capabilitate.
Important
Nu fiecare refuz apare aici. Protecțiile structurale la nivel de câmp — un câmp care scrie și într-un alt model, un câmp nescriptibil sau nestocat — nu înregistrează nicio încălcare și nu costă niciun avertisment, deci o listă Încălcări goală nu este dovada că nu s-a refuzat nimic. O capabilitate dezactivată este un caz diferit: aceea este o limită care atrage avertisment și apare aici. Consultați principiul 9 din AI pentru limitele care atrag avertisment și Protecția scrierii între modele pentru protecțiile pe câmp.
Căutați dovezile unui astfel de refuz în alte trei locuri:
conversația utilizatorului care acționează, unde asistentul raportează refuzul și numește modelul și câmpurile pe care nu i s-a permis să le scrie;
fila Pași a rulării, pentru un agent: apelul instrumentului este înregistrat cu Verdict poartă denied și mesajul de refuz;
jurnalul serverului Odoo, pentru un refuz în interiorul unei încărcături one2many sau many2many: modelul și câmpul imbricate sunt înregistrate acolo și nicăieri în interfață, deci cereți persoanei care operează serverul dumneavoastră să le caute — ele numesc regula la nivel de câmp care l-ar deschide.
nu îl va afișa: ai.log înregistrează apelurile către furnizori și scrierile care au fost efectiv aplicate.
Blocări de utilizatori¶
Suspendă temporar utilizarea AI pentru un utilizator. Poarta verifică blocările mai întâi, înainte de munca costisitoare a LLM-ului sau a trierii — aceasta întrerupe iterarea adaptivă a atacurilor.
Durata provine din Setări (Minute de blocare AI) atunci când este emisă automat.
Administratorii pot gestiona manual blocările.
Administratorii AI / Settings sunt tratați ca scutiți de blocare prin design (ei administrează singuri balustradele) — încă un motiv pentru care utilizatorii agent nu trebuie să fie niciodată administratori AI.
Sarcinile și rulările agentului¶
Pentru munca autonomă, monitorizați și:
Inspectați pașii eșuați, erorile instrumentelor și legătura cu scrierile în așteptare. Jurnalele de pași pot fi șterse după Retenție pași de rulare (zile); păstrați suficient istoric pentru a investiga incidentele.
Tipuri de eroare¶
Nu există nicio stare Anulat și nicio stare Reaped. Fiecare rulare de mai jos este pur și simplu Eșuat în listă, iar Tip de eroare de pe formularul rulării este cel care le deosebește. Nu este o coloană și nu este livrat niciun filtru pentru el, așa că adăugați un filtru personalizat sau o grupare personalizată după Tip de eroare în înainte de a încerca să urmăriți o populație. Fiecare dintre cele trei de mai jos lasă și o notă în chatter-ul sarcinii.
reaped_stuck— niciun worker nu a finalizat vreodată rularea (repornire, oprire din lipsă de memorie, evacuare de pod), iar reaperul a închis-o. O populație recurentă indică reporniri ale serverului sau o sarcină care depășește limita de timp. O rulare reaped nu se ia în calcul pentru dezactivarea automată a sarcinii, deoarece reaperul rulează în afara dispecerului — nimic nu va arhiva o sarcină al cărei worker se oprește mereu, deci această populație este singurul semnal existent și necesită intervenție.cancelled— o rulare care se executa efectiv când a fost oprită la cerere prin Anulare cerere. Pașii pe care rularea i-a executat rămân în fila Pași, dar răspunsul ei consemnează anularea în loc de un răspuns parțial, iar orice propuneri de scriere deschise de ea sunt anulate odată cu ea, astfel încât nimic nu rămâne aprobabil. O anulare este neutră pentru seria de eșecuri a sarcinii: nu este nici numărată, nici resetată.triage_denied— verificarea instrucțiunii înainte de rulare a refuzat instrucțiunea permanentă a sarcinii, deci agentul nu a pornit niciodată. Spre deosebire de celelalte două, aceasta se ia în calcul pentru dezactivarea automată: cinci eșecuri consecutive, primul dintre ele mai vechi de o săptămână, arhivează sarcina. O rafală înseamnă, în mod normal, fie o instrucțiune permanentă formulată prost, fie o pană a furnizorului de triere, care eșuează închis.
Alte două valori aparțin rulărilor suspendate pentru aprobare: waiting_approval_expired (nimeni nu a răspuns la timp) și waiting_approval_empty (rularea a fost eliberată deoarece nu mai rămăsese nicio propunere de așteptat și niciuna nu fusese aplicată — aceasta este și ce vedeți când un supervizor anulează o rulare suspendată pentru aprobare, nu aflată în execuție). O cădere obișnuită în interiorul unei rulări înregistrează în schimb numele clasei excepției.
Consultați Rulări al căror worker s-a oprit și Oprirea unei rulări pentru mecanismele din spatele acestora și Configurare pentru parametrii și acțiunile programate care le controlează.
Coada propunerilor de scriere¶
este atât un instrument pentru utilizator, cât și o suprafață de control: o acumulare de propuneri ale agentului în așteptare înseamnă că supervizorii au nevoie de capacitate sau că agentul este prea agresiv.
Important
Durata de viață a propunerii de scriere a agentului (minute) se aplică doar cât timp rularea care propune este încă deschisă. După ce acea rulare s-a încheiat — cel mai adesea o rulare care a depășit limita de timp și s-a închis ca Expirat — propunerile ei în așteptare sunt expirate la următoarea trecere a acțiunii programate AI: Expire pending writes, la fiecare 15 minute, deoarece nu mai rămâne nimeni care să ducă rezultatul înapoi. Acea curățare rulează indiferent de valoarea setată pentru durata de viață, inclusiv 0.
Așadar, analizați prompt propunerile rulărilor eșuate și expirate; nu vă planificați să reveniți la ele mâine.
Ritmuri operaționale¶
Zilnic (producție timpurie)
Deschideți încălcările și blocările.
Numărați propunerile agentului în așteptare a căror rulare este încă deschisă și rezolvați-le în aceeași zi; după încheierea unei rulări, propunerile ei sunt eliminate, nu așteptate.
Săptămânal
Eșantionați conversații complete pentru erori de calitate și de tratare a datelor.
Analizați regulile de acces noi și modificările de capabilități (controlul modificărilor).
După orice incident
Schimbați nivelul de jurnalizare doar cât este necesar.
Exportați jurnalele relevante; apoi reveniți la doar metadate.
Rotiți cheile API ale furnizorilor dacă se suspectează o scurgere.
Recitiți lista de verificare Securitate împreună cu echipa responsabilă.