Arhitectura de siguranță TAKpilot: Porți Aprobare/Respingere și jurnalul de audit al operatorului

Când un sistem AI generează apeluri API structurate din intrări în limbaj natural și le trimite la o Imagine Operațională Comună activă, costul unei acțiuni greșite nu este un fișier deplasat sau o valoare incorectă într-un tabel. Un marker ostil plasat la un caroiaj ocupat de o unitate prietenoasă, o misiune ștearsă care coordona o evacuare medicală, un canal curățat care distribuia fluxuri ISR unui element de recunoaștere activ — acestea nu se recuperează cu Control-Z. TAK Server nu dispune de anulare nativă pentru majoritatea operațiunilor de date. Ștergerea se execută, datele dispar, iar COP-ul pe care îl navighează fiecare operator din rețea reflectă eroarea până când cineva o observă și reconstruiește manual ceea ce s-a pierdut.

Acesta este contextul de siguranță în care TAKpilot — copilotul AI de chat pentru CloudTAK — a fost conceput. Arhitectura de siguranță a produsului nu este un set de avertismente consultative sau confirmări soft pe care operatorii le pot ignora în grabă. Este un set de constrângeri structurale rigide: carduri de instrumente în flux continuu care fac fiecare acțiune AI vizibilă înainte și în timpul execuției, porți obligatorii Aprobare/Respingere care interceptează toate operațiunile distructive la nivelul stratului de execuție înainte de a fi efectuat orice apel API, izolarea datelor per sesiune care limitează raza de acțiune a oricărei sesiuni, și un jurnal de audit complet cu marcă de timp care păstrează atribuirea operatorului pentru fiecare scriere asistată de AI. Acest articol explică în detaliu fiecare mecanism — cum este implementat, ce interceptează și care sunt limitele sale.

Mizele: de ce erorile AI într-un COP activ sunt categoric diferite

Un asistent AI integrat într-un instrument de productivitate — un editor de documente, un IDE de cod, o platformă de asistență clienți — operează într-un mediu în care erorile sunt recuperabile. Istoricul versiunilor, jurnalele de tranzacții și căile de corecție manuală există la fiecare nivel. Cel mai rău rezultat al unei comenzi în limbaj natural înțelese greșit este timp pierdut și un fișier care trebuie re-editat.

O Imagine Operațională Comună activă nu partajează aceste proprietăți de recuperare. CloudTAK și TAK Server sunt sisteme de stare partajată în timp real: fiecare scriere este imediat vizibilă pentru fiecare operator din rețea. Nu există mod schiță, niciun nivel de pregătire, niciun flux de lucru „propune modificarea pentru revizuire". Când TAKpilot apelează place_marker, markerul apare pe fiecare client conectat în câteva secunde. Când apelează delete_mission, misiunea dispare de pe fiecare client și din magazinul de misiuni al serverului simultan. O misiune de foc de artilerie ștearsă deoarece AI a înțeles greșit „actualizează starea" ca „șterge" nu este recuperabilă din interfața grafică — necesită restaurarea dintr-o copie de siguranță a bazei de date, ceea ce într-un context de desfășurare la margine înseamnă că efectiv nu este recuperabilă.

Arhitectura de siguranță TAKpilot a fost concepută conform acestor constrângeri de la zero, nu adaptată ulterior. Fiecare decizie de proiectare — formatul cardului de instrumente în flux continuu, implementarea porții, modelul de izolare a sesiunii, schema jurnalului de audit — urmărește cerința că nicio acțiune distructivă nu ajunge la CloudTAK fără autorizarea explicită a operatorului și că fiecare acțiune care ajunge la CloudTAK este pe deplin atribuibilă și auditabilă.

Carduri de instrumente în flux continuu: transparență totală înainte, în timpul și după execuție

Primul nivel al arhitecturii de siguranță TAKpilot este transparența: fiecare acțiune pe care o face AI trebuie să fie vizibilă pentru operator în timp real, cu suficient detaliu pentru ca operatorul să poată recunoaște dacă acțiunea corespunde intenției sale înainte ca efectul să se propage la COP. TAKpilot implementează aceasta prin carduri de instrumente în flux continuu — panouri UI retractabile care apar în interfața de chat pe măsură ce fiecare apel de funcție este inițiat și finalizat.

Un card de instrumente în flux continuu conține patru elemente. În primul rând, numele funcției în limbaj simplu — nu un identificator intern al API-ului, ci descrierea în limbaj uman din schema instrumentului: „Se creează misiunea" mai degrabă decât create_mission. În al doilea rând, setul complet de parametri de intrare redat ca JSON structurat — fiecare câmp, fiecare valoare, astfel încât operatorul să poată citi coordonatele exacte ale grilei, indicativul, tipul CoT sau numele misiunii care va fi scris. În al treilea rând, starea de execuție, care se transmite în timp real: în așteptare, în execuție, succes sau eșec cu detalii despre eroare. În al patrulea rând, latența de execuție de la trimitere până la răspunsul API CloudTAK, în milisecunde.

Pentru operațiunile cu mai mulți pași — în care modelul înlănțuiește mai multe apeluri de instrumente pentru a îndeplini o singură comandă în limbaj natural — fiecare pas generează propriul card, apărând în secvență pe măsură ce lanțul se execută. Un operator care trimite „creează o misiune logistică la caroiajul 37U DP 55555 44444 și notifică canalul LOG-NET" vede două carduri: unul pentru create_mission și unul pentru notify_channel, fiecare afișând parametrii și rezultatul execuției în mod independent.

Cardurile sunt restrânse implicit după finalizarea cu succes a operațiunii, reducând aglomerarea vizuală în sesiunile extinse. Sunt extinse implicit când operațiunea eșuează sau când operațiunea este blocată în așteptarea Aprobare/Respingere. Istoricul sesiunii de chat păstrează toate cardurile pe durata sesiunii, oferind o reconstituire completă operațiune cu operațiune a tot ceea ce TAKpilot a făcut și când.

Implementarea porții Aprobare/Respingere pentru operațiunile distructive

Cardurile de instrumente în flux continuu fac acțiunile AI transparente. Poarta Aprobare/Respingere impune ca acțiunile distructive să necesite autorizare explicită. Acestea sunt mecanisme separate care abordează moduri de eșec separate: cardurile de instrumente interceptează erorile de interpretare greșită pe care operatorul le poate recunoaște și întrerupe; poarta previne o clasă de acțiuni cu consecințe mari să se execute chiar dacă operatorul nu le observă la timp.

TAKpilot clasifică fiecare instrument din biblioteca sa ca adițional sau distructiv. Operațiunile aditive — place_marker, create_mission, subscribe_channel, create_data_package — creează sau îmbogățesc datele COP. Pot fi inversate cu o comandă ulterioară, care trece ea însăși prin poarta distructivă. Operațiunile distructive — delete_mission, remove_track, clear_channel, delete_data_package și operațiunile în bloc care afectează mai multe înregistrări — elimină sau modifică semnificativ datele COP în moduri care nu pot fi inversate trivial.

Clasificarea se află în config/gates.json și este verificată de stratul de execuție al TAKpilot înainte de a fi trimis orice apel API la CloudTAK. Când modelul returnează un apel de instrument pentru o operațiune distructivă, stratul de execuție îl interceptează și inițiază fluxul porții în loc să procedeze la API. Fluxul porții are patru pași:

1. Enumerarea domeniului — TAKpilot interoghează CloudTAK pentru a enumera exact ce va fi afectat de operațiune: pentru delete_mission cu un filtru de sector, aceasta înseamnă preluarea fiecărei misiuni din acel sector. Pentru clear_channel, aceasta înseamnă preluarea abonaților actuali ai canalului și a mesajelor în așteptare.
2. Redarea cardului porții — înregistrările enumerate sunt redate în chat ca un card de poartă. Fiecare înregistrare este afișată cu simbolul NATO acolo unde este aplicabil, cu numele, indicativul sau proprietarul atribuit și cu marca de timp a ultimei modificări. Operatorul vede înregistrările reale care vor fi afectate, nu un număr abstract precum „3 misiuni vor fi șterse".
3. Decizia operatorului — operatorul tastează „confirmare" sau face clic pe butonul Aprobare pentru a autoriza execuția, sau face clic pe Respingere pentru a refuza. Poarta nu are timeout. Dacă operatorul nu răspunde, operațiunea nu se execută niciodată. Închiderea cardului porții sau trimiterea unui mesaj diferit anulează operațiunea în așteptare.
4. Rutarea execuției sau a respingerii — la aprobare, apelul API este trimis și fluxul standard al cardului de instrumente în flux continuu se finalizează. La respingere, TAKpilot trimite respingerea înapoi modelului ca rezultat al instrumentului cu starea denied_by_operator. Modelul generează o urmărire care întreabă dacă să rafineze, să restrângă domeniul sau să anuleze cererea.

Poarta este implementată ca o interceptare rigidă pre-execuție — nu un aviz consultativ. Nu există niciun indicator de configurare care să o dezactiveze, nicio ocolire de administrator și nicio circumstanță în care o operațiune distructivă ajunge la API-ul CloudTAK fără o aprobare înregistrată a operatorului. Aceasta este intenționată: valoarea porții derivă în întregime din natura sa necondiționată. O poartă care poate fi ocolită sub presiunea timpului operațional este o poartă care va fi ocolită, iar întreaga proprietate de siguranță dispare.

Cum este gestionată o acțiune respinsă

Când un operator respinge o operațiune în așteptare, respingerea nu este doar o anulare — este un semnal de feedback care reintră în contextul modelului. TAKpilot trimite respingerea înapoi ca rezultat structurat al instrumentului: {"status": "denied_by_operator", "reason": "<textul operatorului dacă este furnizat>"}. Modelul primește acest rezultat ca parte a conversației în desfășurare și generează un răspuns care recunoaște respingerea și oferă alternative.

În practică, răspunsurile la respingere urmează tipare previzibile. Dacă operatorul respinge deoarece domeniul era prea larg („Nu am vrut să șterg toate misiunile, doar cele pentru Plutonul 2"), modelul folosește motivul respingerii pentru a restrânge domeniul și a prezenta un card de poartă revizuit. Dacă operatorul respinge deoarece operațiunea a fost declanșată de o comandă înțeleasă greșit, modelul solicită clarificări mai degrabă decât să reîncerce. Dacă nu este furnizat niciun motiv, modelul pune o singură întrebare: „Doriți să modificați domeniul acestei operațiuni sau să o anulați complet?"

Fiecare respingere este înregistrată în jurnalul de audit al sesiunii cu propria marcă de timp, parametrii operațiunii respinse și orice motiv furnizat de operator. Aceasta oferă o înregistrare completă nu doar a ceea ce a fost executat, ci și a ceea ce a fost propus și respins — ceea ce are valoare independentă în analiza post-acțiune a modului în care luarea deciziilor asistată de AI a afectat ritmul operațional.

Izolarea datelor per sesiune și modelul de identitate al operatorului

Arhitectura de sesiune a TAKpilot este concepută pentru a conține impactul acțiunilor oricărei sesiuni individuale și pentru a asigura că operațiunile asistate de AI sunt atribuite operatorului uman corect în fiecare sistem de audit care le înregistrează.

Fiecare sesiune de chat este izolată într-un sandbox per sesiune. Contextul sesiunii — istoricul conversației, rezultatele apelurilor de instrumente, orice conținut de fișier încărcat — este reținut în memorie și este șters la încheierea sesiunii. TAKpilot nu persistă istoricul conversației pe disc sau într-o bază de date. Nu există scurgere de context între sesiuni: o comandă emisă într-o sesiune nu poate face referire sau afecta datele din sesiunea altui operator. Pentru desfășurările CloudTAK cu mai mulți utilizatori, în care mai mulți operatori partajează un nod, izolarea sesiunii asigură că cardul de poartă în așteptare al Operatorului A nu este vizibil Operatorului B și că apelurile de instrumente ale Operatorului B nu apar în traseul de audit al Operatorului A.

Toate apelurile API CloudTAK sunt trimise folosind propriul token de sesiune al operatorului — nu un cont de serviciu, nu o identitate de bot, nu o acreditare partajată. Aceasta înseamnă că din perspectiva CloudTAK, fiecare scriere pe care TAKpilot o execută este indistinguibilă de o scriere pe care operatorul a făcut-o direct în interfața CloudTAK. Traseul de audit nativ al CloudTAK afișează numele de utilizator al operatorului pentru fiecare acțiune asistată de TAKpilot. Permisiunile de control al accesului ale operatorului se aplică: dacă operatorul nu are permisiunea de a șterge o misiune în modelul de permisiuni al CloudTAK, încercarea TAKpilot de a o șterge va primi un 403 de la API și operațiunea va eșua cu cardul de eroare corespunzător în chat.

Formatul și conținutul jurnalului de audit

TAKpilot menține un jurnal de audit structurat per sesiune care captează proveniența fiecărei acțiuni efectuate în timpul sesiunii. Formatul jurnalului este conceput atât pentru lizibilitatea umană în timpul sesiunii, cât și pentru exportul analizabil automat pentru sistemele de analiză post-acțiune.

Fiecare intrare în jurnal conține:

• Marcă de timp — ISO 8601 cu precizie de milisecunde (2026-05-30T14:32:17.441Z).
• Identitatea operatorului — numele de utilizator CloudTAK asociat tokenului de sesiune (sgt_kovalenko), nu o identitate de bot sau serviciu.
• Intrarea în limbaj natural — mesajul exact al operatorului care a declanșat acțiunea, păstrat verbatim, inclusiv artefactele de transcriere dictată, dacă este cazul.
• Instrumentul apelat — numele funcției (delete_mission).
• Parametrii de intrare — JSON-ul complet al parametrilor, trimis stratului de execuție.
• Starea porții — dacă operațiunea a fost executată automat (aditivă) sau a necesitat Aprobare/Respingere, și dacă a fost blocată de poartă, marca de timp a confirmării și orice înregistrare de respingere.
• Starea răspunsului HTTP — codul de răspuns de la API-ul CloudTAK (200, 403, 404).
• Latența de execuție — milisecunde de la trimiterea API la răspuns.

Jurnalul este accesibil în interfața de chat pe durata sesiunii. Operatorii care au nevoie de o înregistrare persistentă — pentru documentare formală post-acțiune, raportare de unitate sau investigarea unui incident — ar trebui să exporte jurnalul de sesiune înainte de a închide sesiunea. TAKpilot nu păstrează jurnalul după terminarea sesiunii prin design: modelul de izolare a sesiunii impune ca datele sesiunii să nu persiste dincolo de limita sesiunii.

Cum să revizuiți garanțiile de siguranță TAKpilot pentru desfășurarea dumneavoastră

Pașii următori descriu cum să verificați că arhitectura de siguranță TAKpilot este corect configurată pentru o desfășurare dată:

1. Revizuiți config/gates.json — confirmați că toate operațiunile distructive din biblioteca de instrumente sunt listate sub matricea gated. Orice instrumente personalizate adăugate la bibliotecă pentru desfășurarea dumneavoastră ar trebui clasificate explicit — omiterea unui instrument din clasificare are implicit valoarea aditivă (fără poartă).
2. Testați poarta cu o misiune de pregătire — într-un mediu CloudTAK non-producție, trimiteți o comandă de ștergere care vizează o misiune de test cunoscută. Verificați că apare un card de poartă, că enumerează înregistrarea corectă și că operațiunea nu se execută până când nu tastați „confirmare".
3. Testați fluxul de respingere — repetați cele de mai sus și respingeți operațiunea. Verificați că respingerea este înregistrată în jurnalul de sesiune și că modelul generează un răspuns de urmărire mai degrabă decât să reîncerce în tăcere.
4. Verificați identitatea operatorului în auditul CloudTAK — după executarea unei operațiuni blocate de poartă, verificați jurnalul de audit nativ al CloudTAK. Scrierea ar trebui să apară sub numele de utilizator al operatorului dumneavoastră, nu sub un cont de serviciu.
5. Verificați izolarea sesiunii — deschideți două sesiuni pe același nod cu acreditări de operator diferite. Confirmați că cardurile de instrumente și intrările din jurnalul de audit ale Sesiunii A nu apar în chat-ul Sesiunii B.
6. Revizuiți jurnalul de sesiune înainte de închidere — la sfârșitul unei sesiuni de test, revizuiți jurnalul de audit complet din chat și confirmați că fiecare acțiune, inclusiv respingerile, este înregistrată cu marcele de timp corecte și valorile parametrilor.
7. Documentați configurația modelului și a porții în SOP-ul unității dumneavoastră — înregistrați ce model este activ pe fiecare tip de nod, ce operațiuni sunt blocate de poartă și procedura pentru exportul jurnalelor de sesiune pentru analiza post-acțiune. Această documentație face parte din arhitectura de siguranță, nu este un plus opțional.

Întrebări frecvente

Lectură conexă: Pentru o prezentare generală a modului în care TAKpilot traduce limbajul natural în operațiuni CloudTAK de la un capăt la altul, consultați TAKpilot: controlul COP în limbaj natural pentru operatorii tactici CloudTAK. Pentru tipare API CloudTAK pe care se bazează biblioteca de instrumente TAKpilot, consultați Integrarea API CloudTAK: conectarea sistemelor externe la TAK Server. Pentru modul în care arhitecturile de agenți LLM gestionează apelurile de instrumente și siguranța cu operator uman în buclă, consultați Copilot AI pentru aplicații tactice: cum controlează agenții LLM COP-ul.