Učebnica reakcie na incidenty AI: Čo robiť, keď citlivé údaje sú vložené do chatGPT, Claude, alebo Copilot

Zamestnanec práve vložil informácie o zákazníkoch, zdrojový kód, poverovacie listiny, zmluvu alebo iný citlivý dokument do služby AI.

Čo by mala organizácia robiť teraz?

Prvé pravidlo je jednoduché: nevolajte ho automaticky porušením údajov. Ale zaobchádzajte s ním ako s incidentom, ktorý treba posúdiť.

Zaslanie citlivých informácií ChatGPT, Claude, Copilot, Gemini, alebo iný systém AI môže spôsobiť incident s bezpečnosťou, súkromím, zmluvou alebo riadením. Či sa stane porušením právnych predpisov, ktoré sa dá oznamovať, závisí od toho, aké informácie sa týkali, ktorú službu dostala, aký účet sa použil, ako poskytovateľ spracováva a uchováva údaje, aké zmluvné záruky sa uplatňujú, či došlo k neoprávnenému zverejneniu alebo prístupu, k jurisdikciam a skutočnému riziku.

Tento playbook poskytuje praktický proces reakcie pre CISO, bezpečnostné operačné tímy, ÚOÚ, tímy pre ochranu súkromia, IT, dodržiavanie predpisov a právne.

Ak sa citlivé firemné informácie práve predložili službe AI:

1Zastavte ďalšie podania. Požiadajte zamestnanca, aby prestal používať postihnutú konverzáciu, pracovné postupy, konektor, alebo účet pre citlivú prácu, kým sa situácia posudzuje.

2Nezničte dôkazy okamžite. Zaznamenajte službu, užívateľa, účet, zariadenie, približný čas, konverzáciu alebo reláciu, a to, čo bolo predložené pred vymazaním čokoľvek.

3Určiť, aké údaje boli vystavené. Identifikovať, či rýchle alebo nahrávanie obsahoval osobné údaje, poverovacie listiny, zdrojový kód, informácie o zákazníkoch, zmluvy, regulované údaje, alebo interné duševné vlastníctvo.

4Identifikujte prostredie AI. Bolo to ChatGPT Enterprise, ChatgPT Business, osobný účet Chat GPT, Claude Enterprise, osobný Claude účet, Microsoft 365 Copilot, integrácia API, asistent IDE alebo iná služba?

5Skontrolujte, či sú uvedené údaje. Ak heslá, API kľúče, žetóny, certifikáty, súkromné kľúče, relácie tajomstvo, alebo iné poverovacie listiny boli zahrnuté, zrušiť alebo striedať okamžite.

6Zachovať minimálne potrebné dôkazy. Zachytiť metaúdaje, časové pečiatky, klasifikácia, identifikátory udalostí, príslušné screenshoty alebo vývoz, a presné dotknuté údaje, ak je to potrebné pre vyšetrovanie.

7Skontrolujte, či je možné zmazať konverzáciu, odstrániť nahrané súbory, použiť administrátora alebo rozhranie pre dodržiavanie súladu, alebo sa odvolať na špecifické kontroly uchovávania.

8Otvorte interný záznam incidentu. Nečakajte na právnu klasifikáciu pred dokumentovaním udalosti.

9Eskalovať na základe príslušných údajov. Osobné údaje by mali zahŕňať funkcie ochrany súkromia/DPO; poverovacie listiny by mali obsahovať bezpečnosť; zmluvy alebo privilegované informácie môžu vyžadovať právne; regulované informácie môžu požadovať tímy špecifické pre daný sektor.

10Neoznámte regulátorov alebo zákazníkov reflexívne. Najprv zistiť, či udalosť spĺňa príslušnú zákonnú alebo zmluvnú notifikačnú prahovú hodnotu.

Cieľom počas prvých desiatich minút je obmedzenie, uchovávanie dôkazov a klasifikácia.

Organizácie by mali rozlišovať tri pojmy.

Bezpečnostný incident je najširšia kategória, môže zahŕňať udalosť, ktorá ohrozuje dôvernosť, integritu, dostupnosť, poverovacie listiny, duševné vlastníctvo alebo bezpečnostnú politiku.

Zamestnanec, ktorý vloží výrobný kľúč API do AI chatbot, môže byť preto vážnym bezpečnostným incidentom aj v prípade, že sa do neho nezapájajú žiadne osobné údaje.

Podľa GDPR je porušenie ochrany osobných údajov konkrétne porušením bezpečnosti, ktoré vedie k náhodnému alebo protiprávnemu zničeniu, strate, zmene, neoprávnenému zverejneniu alebo prístupu k osobným údajom.

Táto definícia je dôležitá.

Skutočnosť, že osobné údaje boli predložené poskytovateľovi AI, sama osebe neodpovedá na každú otázku o tom, či udalosť predstavuje porušenie ochrany osobných údajov, ktoré si vyžaduje oznámenie. Organizácia musí preskúmať dojednania o spracovaní, povolenie, poskytovateľa/účtu, použitý zmluvný rámec, záruky a skutočné okolnosti zverejnenia alebo prístupu.

incident s riadením AI je užitočná prevádzková kategória pre udalosť, v ktorej sa AI používala v rozpore s organizačnou politikou alebo mimo schválených kontrol.

Napríklad:

dôverné informácie predložené prostredníctvom neschváleného osobného účtu AI;

údaje o zákazníkoch zaslané poskytovateľovi AI, ktorý neprešiel preskúmaním predajcu;

zdrojový kód nahraný napriek vnútornému obmedzeniu;

citlivé informácie zaslané prostredníctvom schválenej platformy AI, ale mimo povoleného obchodného použitia prípadu.

incident s riadením AI sa môže prekrývať s bezpečnostným incidentom alebo porušením osobných údajov, ale ani automaticky sa ním nestáva.

Pred rozhodnutím o závažnosti alebo oznámení použite nasledujúcu postupnosť.

Dôležité je, že klasifikácia by mala nasledovať po vyšetrovaní, nie pred ním.

Záchrana je na prvom mieste.

Požiadajte zamestnanca, aby prestal pridávať informácie do postihnutého konverzácie alebo pracovného postupu. Ak incident zahŕňa automatizovanú integráciu, konektor, AI agent, rozšírenie prehliadača, IDE asistent, alebo API potrubia, dočasne zakázať ovplyvnený tok dát v prípade potreby.

V závislosti od situácie môže obmedzenie zahŕňať:

pozastavenie integrácie AI;

odstránenie súboru zo zdieľaného pracovného priestoru AI;

obmedzenie prístupu používateľa k neschválenej službe AI;

dočasne blokovanie nahrávania;

vypnutie konektora;

odstránenie odhaleného úložiska;

zneplatnenie aktívnych sedení.

Vyhnite sa bežnej chybe: povedať zamestnancovi, aby okamžite vymazať všetko pred vyšetrovaním tím zaznamenal, čo sa stalo.

Vypustenie môže byť vhodným krokom na nápravu, ale najprv si uchovajte dostatok dôkazov na určenie rozsahu pôsobnosti.

Nevyšetrujte incident na základe opisu:

> "Niekto vložil dôverné údaje do ChatGPT."

Musíte presne vedieť, aké údaje boli v tom zahrnuté.

Určiť:

Aký text bol predložený?

Bola to jedna veta, zákaznícky záznam, celý export databázy alebo veľký dokument?

Boli súbory nahrané?

Zaznamenávať názvy súborov, typ, približnú veľkosť, klasifikáciu a príslušné hašé, ak sú k dispozícii.

Koľko záznamov bolo v tom zahrnutých?

E-mailová adresa jednej osoby predstavuje iný rizikový profil ako exportovaná CRM, ktorá obsahuje 100 000 zákazníkov.

Boli informácie už verejné?

Vnútorné klasifikačné značky nie vždy priamo zodpovedajú skutočnému utajeniu.

Boli citlivé informácie potrebné na túto úlohu?

To sa stáva dôležitým počas nápravy a preskúmania politiky.

"ChatGPT" alebo "Claude" nestačí.

Určiť presné prostredie.

Napríklad:

podnikovo spravovaný účet;

obchodné/tímové pracovné priestory;

osobný/voľný účet;

API;

desktopová aplikácia;

rozhranie prehliadača;

integrácia IDE;

žiadosť tretej strany s použitím podkladového modelu;

organizačný agent AI;

SaaS aplikácia s vloženým AI.

Rozlišovanie môže podstatne zmeniť posúdenie.

OpenAI napríklad uvádza, že obchodné produkty ako napríklad ChatGPT Business and Enterprise sú štandardne vylúčené z modelového vzdelávania, zatiaľ čo spotrebiteľské služby majú rôzne opatrenia na kontrolu údajov. Open AI Enterprise tiež podporuje organizačné kontroly uchovávania.

Preto "informácie boli predložené ChatGPT" nie sú dostatočné na určenie toho, čo sa stalo s údajmi.

V rámci prešetrovania by sa malo tiež určiť, či bol používateľ overený prostredníctvom podnikového SSO, či účet spravoval organizácia, či sa uplatňuje zmluva DPA alebo podnikov, a aká konfigurácia uchovávania bola v tom čase aktívna.

Typ informácie určuje, ktorá cesta odozvy sa má aktivovať.

Súčasne sa môže uplatňovať viacero kategórií.

Napríklad zdrojový kód môže obsahovať aj údaje API, mená zamestnancov, interné URL, identifikátory zákazníkov a proprietárne algoritmy.

Reakcia na incident sa stáva dramaticky ťažšou, keď organizácia nedokáže odpovedať na základné otázky o interakcii AI.

Pokúste sa stanoviť aspoň:

Uchovávanie dôkazov neznamená kopírovanie citlivých podnetov do systémov viacnásobného predaja lístkov.

Cieľom je zachovať dostatok dôkazov na rekonštrukciu udalosti bez zbytočného násobenia citlivých údajov.

Retail - zabezpečené nehnuteľným majetkom určeným na podnikanie

Ak zamestnanec vložil do systému AI ktorýkoľvek z týchto prvkov:

API kľúče;

heslá;

OAuth tokens;

databázové údaje,

súkromné kľúče;

cloudové oprávnenia;

cookies relácie;

prístupové žetóny;

certifikáty alebo tajomstvá;

predpokladať, že by sa už viac nemalo veriť dôvere.

Znova alebo otočte.

Potom určiť, či sa kredit používal po expozícii a aké systémy by mohol mať prístup.

Vymazanie rozhovoru AI nie je náhradou za otáčanie cedentálneho.

Rôzne služby AI poskytujú rôzne kontroly a dokonca aj ten istý poskytovateľ sa môže správať inak v závislosti od plánu a konfigurácie.

Nespoliehajte sa na predpoklady.

OpenAI v súčasnosti uvádza, že normálne chaty zostávajú až do vymazania alebo odstránenia v rámci uplatniteľnej politiky zachovania pracovného priestoru. Keď sa uložený chat odstráni, z pohľadu používateľa sa okamžite odstráni a plánuje sa trvalé vymazanie zo systémov OpenAI do 30 dní, s výhradou stanovených právnych, bezpečnostných alebo deidentifikačných výnimiek. Podnikové prostredie môže mať organizačné kontroly a schopnosti dodržiavania súladu.

Riadiaci administrátori chatGPT môžu mať tiež schopnosti na prístup, audit, export, uchovávanie alebo vymazanie údajov súvisiacich s riadenými organizačnými účtami v závislosti od produktu a konfigurácie.

Antropic je podnikové materiály opisujú organizačné kontroly uchovávania a Compliance API schopnosti, ktoré môžu poskytnúť podnikovým správcom údaje o používaní a selektívne vymazanie funkcie. Obchodné služby by mali byť odlíšené od spotrebiteľských účtov Claude, ktoré fungujú podľa rôznych podmienok a mechanizmy uchovávania.

Pre podporované služby Microsoft AI môže Microsoftu Purview uchovávať a objavovať údaje interakcie Copilot. Microsrosof tiež dokumentuje pracovné postupy pomocou eDiscovery a Microsopher Graph na vyhľadávanie a odstránenie podporovaných interakčných dát AI, vrátane reakcie na incidenty s štiepením dát.

Praktické poučenie je:

Skontrolujte konkrétneho poskytovateľa, produkt, predplatné, konfiguráciu nájomcu, zmluvu a pravidlá zachovania, ktoré sa uplatňovali v okamihu konania podujatia.

Schopnosť poskytovateľa sa časom mení. Incident runbooks by preto mal odkazovať na súčasnú dokumentáciu poskytovateľa, a nie na predpoklady pevného kódu.

Externé podávanie správ nie je prvým rozhodnutím o klasifikácii.

Najprv určiť, ako sa udalosť hodí na vlastné pravidlá vašej organizácie.

Otázky by mali zahŕňať:

Bola politika spoločnosti porušená?

Bol použitý neschválený poskytovateľ AI?

Použil sa osobný účet pre firemné údaje?

Boli údaje klasifikované ako dôverné alebo obmedzené?

Zlyhala technická kontrola?

Užívateľ obíde existujúce varovanie?

Nemala organizácia potrebnú kontrolu?

Bola tá akcia náhodná alebo úmyselná?

Deje sa to aj inde?

Aj keď externé oznamovanie nie je potrebné, táto udalosť môže odhaliť systémovú medzeru v riadení.

Nie každý incident potrebuje rovnaký zásahový tím.

Dôveryhodnosť a tajomstvo infraštruktúry si vo všeobecnosti vyžadujú zapojenie do bezpečnosti.

Osobné údaje si vo všeobecnosti vyžadujú posúdenie súkromia/DPO.

Zmluvy, privilegované informácie, obchodné tajomstvo a povinnosti dôvernosti môžu vyžadovať právne.

Finančné inštitúcie, zdravotnícke organizácie, verejné orgány a iné regulované subjekty môžu vyžadovať ďalších vlastníkov dodržiavania predpisov.

Zrelý pracovný postup vedie incident založený na type údajov a vplyve, a nie posielanie každej udalosti súvisiacej s AI do rovnakého generického frontu.

Nezačínajte s otázkou:

> "Máme 72 hodín?"

Začnite s:

> "Ktorý právny režim sa uplatňuje a spĺňa toto podujatie svoju definíciu a prahovú hodnotu na vykazovanie?"

Podľa článku 4 ods. 12 GDPR porušenie ochrany osobných údajov zahŕňa narušenie bezpečnosti, ktoré vedie k náhodnému alebo protiprávnemu zničeniu, strate, zmene, neoprávnenému zverejneniu alebo prístupu k osobným údajom.

Ak prevádzkovateľ zistí, že došlo k porušeniu ochrany osobných údajov, v článku 33 sa vyžaduje oznámenie príslušnému dozornému orgánu bez zbytočného odkladu a ak je to možné, do 72 hodín od jeho zistenia, pokiaľ je nepravdepodobné, že porušenie povedie k riziku pre práva a slobody jednotlivcov. Kontrolóri musia tiež zdokumentovať porušenia ochrany osobných údajov vrátane ich skutočností, účinkov a nápravných opatrení.

Komunikácia s dotknutými osobami je samostatným prahom: článok 34 sa uplatňuje, ak porušenie pravdepodobne povedie k vysokému riziku pre ich práva a slobody, s výhradou výnimiek uvedených v nariadení.

EDPB uverejňuje aj usmernenia založené na prípadoch, ktoré majú pomôcť kontrolórom posúdiť situácie porušenia predpisov a rozhodnutia o oznámení.

Preto:

Neusudzujte, že každé náhodné podanie AI vyžaduje oznámenie GDPR. Vykonávajte a dokumentujte skutočné porušenie a hodnotenie rizika.

NIS2 používa iný test.

V článku 23 sa vyžaduje, aby subjekty, ktoré sú v rozsahu pôsobnosti, nahlasovali incidenty, ktoré majú významný vplyv na poskytovanie svojich služieb.

Ak subjekt a incident patria do príslušného režimu NIS2 a spĺňajú významný prah, smernica stanovuje požiadavky na včasné hlásenie vrátane včasného varovania a následného oznámenia o incidente. Vnútroštátna transpozícia a príslušný orgán sa musia pred uplatnením postupu na konkrétny incident tiež skontrolovať.

Bežné porušenie politiky zamestnancov, ktoré zahŕňa AI chatbot, by preto nemalo byť automaticky opísané ako "NIS2-oznamujúca udalosť."

DORA uplatňuje na kryté finančné subjekty samostatný rámec riadenia incidentov.

Vymedzuje a vyžaduje si nahlasovanie závažných incidentov súvisiacich s IKT, pričom zároveň vyžaduje, aby finančné subjekty zaznamenávali incidenty súvisiace s IKT a udržiavali postupy na identifikáciu, klasifikáciu, manipuláciu, následné opatrenia, analýzu základných príčin, eskaláciu a nápravu.

V prípade incidentov, ktoré sa v rámci DORA skutočne kvalifikujú ako závažné incidenty súvisiace s IKT, sa v delegovanom nariadení Komisie (EÚ) 2025/301 stanovujú súčasné lehoty na podávanie správ vrátane počiatočného oznámenia čo najskôr a do štyroch hodín po klasifikácii ako závažné, pričom sa uplatňuje hranica mimo 24 hodín od informovanosti, po ktorých nasledujú prechodné a záverečné požiadavky na podávanie hlásení.

Tieto časové línie opäť závisia len od toho, či organizácia a incident spadajú do príslušných požiadaviek DORA.

Preto by mal viesť zoznam udalostí AI, ktorý by mal obsahovať samostatné rozhodovacie postupy pre:

Interný incident správy a riadenia AI -> bezpečnostný incident -> porušenie osobných údajov -> incident regulovaný sektorom/ incident, ktorý sa oznamuje.

Sú to príbuzné kategórie, nie synonymá.

Zatvorenie lístka, pretože rozhovor bol vymazaný, nestačí.

Dokument:

Opíšte túto udalosť fakticky.

Prečo sa to stalo? Bola politika AI nejasná? Bol schválený nástroj AI nepohodlný? Nebola tam technická kontrola? Bol zamestnanec informovaný o klasifikácii dát?

Čo znížilo riziko? Dôverné rotácie, konverzácie vymazanie, žiadosť poskytovateľa, obmedzenie účtu, maskovanie, aktualizácia politiky, alebo iné akcie.

Čo zostáva nevyriešené? Napríklad neschopnosť overiť vymazanie poskytovateľa.

Aká kontrola zabráni opakovaniu?

Silný záznam po skončení vyšetrovania by mal umožniť inému bezpečnostnému odborníkovi alebo audítorovi rekonštruovať udalosť aj reakciu.

Politiky odbornej prípravy a prijateľného využitia zostávajú užitočné, ale nemali by byť jedinou kontrolou.

Najsilnejší bod zásahu je predtým, než citlivé informácie opustia prostredie zamestnanca.

Pre podniky, ktoré používajú AI, môžu preventívne kontroly zahŕňať:

objavovanie, ktoré AI poskytuje zamestnancom v skutočnosti;

rozlišovanie podnikových účtov od osobných účtov;

identifikácia citlivého textu a nahrané súbory pred predložením;

varovať používateľov pred riskantnými opatreniami;

maskovanie vybraných citlivých informácií;

blokovanie zakázaných údajov;

uplatňovanie rôznych politík zo strany poskytovateľa AI, užívateľa, oddelenia alebo dátovej triedy;

vytvára dôkaz, že bola vykonaná kontrola.

Tu sedí agentka ID.

AgentID poskytuje predbežné kontroly v rámci používania AI zamestnancov vrátane viditeľnosti v službách AI, detekcie citlivých dát, maskovania alebo blokovania podľa organizačnej politiky a audítorských dôkazov týkajúcich sa výsledného rozhodnutia.

Cieľom nie je zabrániť zamestnancom používať AI.

Je to na premenu:

"O tri týždne sme zistili, že niekto vložil údaje o zákazníkoch do nástroja AI."

do:

"V 10:42 sa zamestnanec pokúsil poslať zákaznícke PII na neschválený účet AI. Zásady klasifikovali obsah ako obmedzený a zablokovaný podanie. Podujatie bolo zaznamenané bez zaslania chránených údajov."

Tento rozdiel zásadne mení reakciu na incidenty.

Najužitočnejším záznamom z vyšetrovania nie je často stály archív každého surového zamestnanca promptu.

Lepší model je často metaúdaje - prvý dôkaz.

Napríklad:

`event_id` `timestamp` `user_id` `device_id` `provider` `account_context` `data_classification` `policy_id` `policy_verdict` `masking_applied` `file_hash` `request_hash` `incident_reference`

Surový obsah sa potom môže zachytávať selektívne, ak to odôvodňujú politické, vyšetrovacie, právne povinnosti alebo dôkazné požiadavky.

To záleží na súkromí, ako aj bezpečnosti.

Zásada GDPR na minimalizáciu údajov vyžaduje, aby osobné údaje boli primerané, relevantné a obmedzené na to, čo je potrebné.

Systém riadenia AI, ktorý kopírovať každý citlivý podnet navždy môže preto vytvoriť druhý úložisko citlivých údajov a zároveň sa pokúšať riadiť prvý.

Dobrá správa vecí verejných sa pýta:

Aký dôkaz potrebujeme? Za akým účelom? Ako dlho? Kto môže mať prístup?

Retenčný systém by mal byť konfigurovateľný podľa triedy údajov, typu udalosti, potreby podniku, požiadavky na vyšetrovanie a uplatniteľného práva.

Zamestnanec používajúci osobný účet AI passuje tabuľku na podporu zákazníka, ktorá obsahuje mená, e-mailové adresy, čísla účtov a poznámky k prípadu do chatbota, aby generoval súhrn.

Vnímavou reakciou by bolo:

Minúta 0 - 10: zastavte ďalšie používanie, uchovajte základné dôkazy, stanovte poskytovateľa/účto a súbor údajov.

Okamžitá klasifikácia: je do nej zapojený klientsky PII, takže bezpečnosť a funkcia súkromia/DPO sú interne oznámené.

Kontajner: určiť, či konverzáciu a nahraný súbor možno odstrániť a aké podmienky uchovávania poskytovateľa platia.

Rozsah pôsobnosti: stanoviť počet zúčastnených zákazníkov a polí.

Hodnotenie: určiť, či zverejnenie bolo povolené v rámci mechanizmov organizácie na spracovanie a či okolnosti predstavujú porušenie ochrany osobných údajov podľa platných právnych predpisov.

Oprava: v prípade potreby vymažte alebo odstráňte obsah, zaznamenajte incident, preskúmajte politiku osobného účtu a zhodnoťte, či podobná činnosť existuje inde.

Prevencia: v prípade potreby si vyžadujú spravované účty AI a zavádzajú predpredkladanú detekciu alebo blokovanie údajov o zákazníkoch.

Čo by organizácia nemala robiť, je skočiť priamo z:

"PII bola vložená do AI"

do:

"Porušili sme právne oznamované údaje."

Prešetrovanie tento záver potvrdzuje.

Zastavte ďalšie vystavenie, presne určiť, čo bolo predložené, identifikovať účet a služby, ktoré sa týkajú, zachovať potrebné dôkazy, rotovať všetky osvedčenia, preskúmať poskytovateľa vymazanie a ponechanie možnosti, a spustiť udalosť prostredníctvom procesu bezpečnosti / privacy incidentu.

Nepredpokladajte, že sa incident dá z právneho hľadiska oznámiť automaticky.

Nie nevyhnutne.

Môže ísť o incident vnútornej bezpečnosti alebo riadenia, či ide o porušenie ochrany osobných údajov alebo o iný incident, ktorý je právne oznamovateľný, závisí od informácií, povolenia, kontextu účtu/poskytovateľa, zmluvných dojednaní, rozhodného práva, expozície a rizika.

Okamžite odštartujte alebo otočte kľúč.

Vymazanie rozhovoru neodstráni potrebu rotovať vierohodné. Preskúmať protokoly, aby sa zistilo, či vystavený kľúč bol následne použitý.

Zvyčajne by ste mali najprv zachovať dôkazy potrebné na pochopenie incidentu.

Po uchovaní dôkazov môže byť vymazanie alebo administratívne odstránenie vhodným krokom na obmedzenie rizika v závislosti od požiadaviek poskytovateľa a od požiadaviek na vyšetrovanie.

Žiadna služba AI spoločnosti neodstraňuje potrebu riadenia organizačných údajov.

Služby pre podniky môžu poskytovať dôležité súkromie, zmluvné, identifikačné, retenčné a administratívne kontroly. Napríklad OpenAI uvádza, že jeho obchodné produkty sa štandardne nepoužívajú na modelovanie.

Ale organizácie stále potrebujú určiť, ktoré informácie sú zamestnanci oprávnení predkladať, prostredníctvom ktorých účtov, podľa ktorých politík, a s akými dôkazmi.

Neexistuje žiadne všeobecné pravidlo "AI incident = 72 hodín."

Požiadavka GDPR na 72-hodinový dohľad nad porušením podmienok stanovených v článku 33 sa vzťahuje na porušenia osobných údajov, ktoré spĺňajú podmienky stanovené v NIS2 a DORA používajú rôzne koncepcie, prahové hodnoty, procesy a lehoty na podávanie správ.

Najprv uveďte uplatniteľný právny režim.

Nie nevyhnutne.

Plný obsah protokolovania môže pomôcť niektoré vyšetrovania, ale tiež vytvára ďalšie úložisko obsahujúce potenciálne citlivé informácie.

Prvý model metaúdajov s konfigurovateľným uchovávaním a selektívnym zachytávaním obsahu môže často poskytnúť užitočné dôkazy a zároveň znížiť nepotrebný zber údajov.

Keď sa citlivé údaje predkladajú systému AI, organizácie musia rýchlo odpovedať na päť otázok:

Čo bolo poslané? Kde bolo poslanie? Pod akým menom a zmluvným kontextom? Aké riziko to spôsobilo? Aké dôkazy a náprava existujú?

To je základom účinnej reakcie na incidenty s AI.

Dlhodobým cieľom by malo byť, aby sa tieto otázky presunuli skôr počas životného cyklu.

Namiesto objavenia citlivých informácií po tom, čo sa dostanú k službe AI, môžu podniky klasifikovať, maskovať, varovať, schvaľovať alebo blokovať rizikové interakcie pred predložením, pričom si ponechávajú dostatok dôkazov na preskúmanie toho, čo bolo bez vytvorenia ďalšieho nekontrolovaného archívu citlivých podnetov.