Kde končia vaše dáta: bezpečnosť, súkromie a firemné tajomstvá pri AI

Bezpečnosť, súkromie a firemné tajomstvá pri používaní AI

Spotrebiteľské AI účty, firemné licencie, API, osobné údaje, zmluvy, zdrojový kód, retencia, tréning a ľudská kontrola

Najdôležitejšie pravidlo: „Platený účet“ automaticky neznamená firemný režim a „nepoužíva sa na tréning“ automaticky neznamená nulovú retenciu, nulový logging, nulový ľudský prístup ani nulový prenos k externým nástrojom. Pri bezpečnosti AI treba oddelene posudzovať tréning, uchovávanie, účel spracúvania, prístup ľudí, geografiu spracúvania, konektory a oprávnenia.

Najväčšie bezpečnostné nedorozumenie pri generatívnej AI vzniká z predstavy, že používateľ do nástroja vloží text, model ho „spracuje“ a dáta potom zmiznú. V reálnej službe existuje viacero samostatných vrstiev: dáta sa prenesú k poskytovateľovi, použijú sa na inferenciu, môžu sa zapísať do histórie alebo aplikačného stavu, môžu sa objaviť v bezpečnostných logoch, môžu prejsť cez konektor alebo externý nástroj a podľa produktu a nastavení môžu byť použité aj na zlepšovanie modelov. Tieto vrstvy majú odlišné pravidlá a odlišné retenčné lehoty. Bez ich rozlíšenia sa nedá kvalifikovane odpovedať ani na jednoduchú otázku „sú moje dáta v AI bezpečné?“. 126

Druhé nedorozumenie je delenie na „AI zadarmo“ a „AI platenú“. Cena nie je spoľahlivý indikátor dátového režimu. ChatGPT Plus alebo Pro je stále osobný spotrebiteľský workspace; Claude Pro alebo Max je stále spotrebiteľský produkt; GitHub Copilot Pro je individuálna licencia. Naopak ChatGPT Business alebo Enterprise, Claude for Work, Gemini v kvalifikovanom Google Workspace, Microsoft Copilot s pracovným účtom a komerčné API majú iné zmluvné a dátové záväzky. Pri bezpečnostnom posúdení je preto relevantný typ účtu, zmluvné podmienky, nastavenia, retenčné mechanizmy a konkrétna funkcia, nie logo ani mesačná cena. 381114

Tretie nedorozumenie je zamieňanie dôvernosti s GDPR. Dokument môže byť firemným tajomstvom bez toho, aby obsahoval jediný osobný údaj; osobný údaj môže byť z hľadiska firmy banálny, ale stále podlieha GDPR. Zdrojový kód môže obsahovať obchodné tajomstvo, bezpečnostné tajomstvá aj osobné údaje zároveň. Bezpečná AI politika preto musí chrániť minimálne štyri odlišné kategórie: osobné údaje, dôverné obchodné informácie, technické tajomstvá a prístupové údaje. Každá z nich má iný právny a bezpečnostný režim. 1819

1. Čo sa s dátami deje po odoslaní promptu

Po stlačení tlačidla Odoslať sa prompt spravidla šifrovaným prenosom dostane do infraštruktúry poskytovateľa. Model potrebuje obsah promptu spracovať, preto sa mu nedá súčasne poskytnúť konkrétny text a garantovať, že ho poskytovateľ technicky vôbec nespracuje. Bezpečnostná otázka teda nie je, či poskytovateľ obsah „uvidí“ v technickom zmysle, ale na aký účel ho spracúva, ako dlho ho drží, kto k nemu môže pristupovať, či ho používa na modelové zlepšovanie a či sa obsah posiela ďalej do iných služieb. Zmluvne i technicky treba odlíšiť inferenciu od sekundárneho využitia dát. 126

Inferencia je samotné vytvorenie odpovede modelom. Tréning alebo model improvement je samostatný následný proces, pri ktorom môže poskytovateľ vybrané dáta použiť na ďalší vývoj modelov. Retencia je ďalšia samostatná otázka: obsah môže byť dočasne uložený aj vtedy, keď sa nepoužíva na tréning. OpenAI napríklad pri API štandardne nevyužíva vstupy a výstupy na tréning, no abuse-monitoring logy môžu obsahovať zákaznícky obsah a štandardne sa uchovávajú do 30 dní; niektoré API funkcie ukladajú aj aplikačný stav potrebný na fungovanie služby. To je presný príklad, prečo veta „API dáta nejdú do tréningu“ nie je totožná s vetou „API nič neukladá“. 2

Ďalšou vrstvou je produktová história, pamäť, súbory a indexy. Chat, ktorý má byť dostupný zajtra, musí byť niekde uložený. Súbor používaný v projekte alebo znalostnej báze môže mať inú retenciu než jednorazový prompt. Konektor do Google Drive, SharePointu, GitHubu alebo externého MCP servera pridáva ďalšieho spracovateľa alebo dátový tok. Pri agentoch môže systém okrem čítania aj zapisovať, odosielať e-mail, upravovať CRM či spúšťať kód. Preto sa s rastom schopností AI neposúva iba kvalita výstupu, ale aj rozsah bezpečnostnej plochy, ktorú musí organizácia riadiť. 91217

2. Najdôležitejšie rozlíšenie: tréning, retencia, logging a ľudská kontrola

Štyri pojmy sa v praxi miešajú do jednej otázky, hoci znamenajú niečo iné. Tréning odpovedá na otázku, či sa obsah používa na zlepšovanie modelov. Retencia hovorí, ako dlho zostáva obsah alebo jeho časť uložená. Logging pokrýva prevádzkové, bezpečnostné a auditné záznamy. Ľudská kontrola znamená, či sa vybrané dáta môžu dostať k oprávnenému človeku napríklad pri hodnotení kvality, riešení bezpečnostného incidentu, podpore alebo spätnej väzbe. Služba môže mať tréning vypnutý a pritom stále legitímne uchovávať dáta pre bezpečnosť, účtovanie, audit alebo funkčnosť produktu. 246

Praktickým príkladom je spätná väzba. Pri komerčnom Claude Anthropic štandardne netrénuje na vstupoch a výstupoch, ale ak používateľ odošle thumbs up/down feedback, súvisiaca konverzácia môže byť uchovávaná až päť rokov a použitá na výskum a tréning v súlade s podmienkami. OpenAI pri business a API produktoch rovnako nevyužíva zákaznícke vstupy a výstupy na tréning štandardne, avšak organizácia sa môže explicitne rozhodnúť zdieľať feedback, eval dáta, fine-tuning dáta alebo API vstupy a výstupy. Jediný klik na feedback teda môže mať iný dátový režim než obyčajné používanie služby. 45

Google Gemini pre osobné účty ukazuje ďalšiu kombináciu. Ak je Keep Activity zapnuté, Google uvádza, že aktivitu používa na poskytovanie, vývoj a zlepšovanie služieb vrátane tréningu generatívnych modelov, pričom časť dát môže byť kontrolovaná ľuďmi; dáta poskytnuté servisným pracovníkom sú odpojené od účtu a môžu byť uchované tri roky. Ak je Keep Activity vypnuté, budúce chaty sa podľa Google nepoužívajú na tréning modelov, pokiaľ používateľ neposkytne feedback, no budúce chaty sa aj tak uchovávajú 72 hodín, aby služba fungovala a mohla riešiť bezpečnosť. 67

3. Bezplatný, platený spotrebiteľský a firemný účet nie sú to isté

Spotrebiteľský účet je navrhnutý primárne pre jednotlivca. Môže mať silné bezpečnostné mechanizmy a používateľské ovládacie prvky, ale spravidla nie je postavený ako centrálne riadené firemné prostredie s administrátorskými politikami, zmluvou o spracúvaní, auditom, SSO, riadením retencie, dátovou rezidenciou alebo DLP. Dôležité je, že platený spotrebiteľský plán nemusí meniť právny charakter služby. ChatGPT Plus/Pro, Claude Pro/Max alebo GitHub Copilot Pro nemožno automaticky zamieňať s business alebo enterprise licenciou. 3814

Firemný produkt zvyčajne mení najmä zmluvný a riadiaci rámec. OpenAI uvádza, že dáta z ChatGPT Business, Enterprise, Edu a API štandardne nepoužíva na tréning. Anthropic uvádza to isté pre Claude for Work a API. Google pri Gemini v kvalifikovanom Workspace uvádza, že obsah zostáva v organizácii, nepoužíva sa na tréning generatívnych modelov mimo domény bez povolenia a nie je ľudsky kontrolovaný na tento účel. Microsoft 365 Copilot uvádza, že prompty, odpovede a dáta z Microsoft Graph sa nepoužívajú na tréning základných LLM. 13811

Firemná licencia však nie je bezpečnostná mágia. Ak má používateľ prístup k príliš širokému množstvu dokumentov, AI môže pracovať aj s týmto nadmerne udeleným prístupom. Microsoft aj Google explicitne stavajú AI na existujúcich oprávneniach používateľa; zlé oprávnenia preto zostávajú zlými oprávneniami. Konektory a webové nástroje môžu mať vlastné podmienky. Retencia môže zostať zapnutá pre históriu a audit. Bezpečný firemný deployment preto vyžaduje nielen zakúpenie enterprise licencie, ale aj IAM, klasifikáciu dát, DLP, administrátorské politiky, minimálne oprávnenia a interné pravidlá používania. 111217

4. Porovnanie dátových režimov hlavných AI služieb k 8. 10. 2026

Nasledujúce porovnanie zachytáva predvolené alebo oficiálne deklarované režimy hlavných služieb podľa dokumentácie dostupnej k 8. októbru 2026. Nie je to univerzálny právny verdikt: konkrétne nastavenie môže ovplyvniť región, typ účtu, administrátor, zmluva, zapnuté funkcie, spätná väzba a používanie externých integrácií. Politiky sa navyše menia, preto treba pri citlivom nasadení overovať aktuálny stav priamo v podmienkach a administrácii konkrétneho účtu. 1-17

Najvýznamnejší rozdiel je medzi osobným a organizáciou riadeným kontextom. OpenAI pri osobných Free/Plus/Pro workspace uvádza, že zdieľanie dát na model improvement je zapnuté a používateľ ho môže vypnúť v Data Controls; business produkty a API sú z tréningu štandardne vylúčené. Anthropic pri spotrebiteľských účtoch používa chaty na zlepšovanie modelov v prípadoch, keď to používateľ dovolí, pri bezpečnostnom review alebo explicitnom opt-in; komerčné produkty sú štandardne mimo tréningu. Google Gemini osobný účet pri Keep Activity používa aktivitu aj na zlepšovanie a tréning, zatiaľ čo Gemini vo Workspace uplatňuje firemné záväzky. GitHub od 24. apríla 2026 používa interaction data z Copilot Free/Pro/Pro+ na tréning, pokiaľ sa používateľ neodhlási; Business a Enterprise dáta na tréning nepoužíva. 346814

Pri čítaní tabuľky treba sledovať aj retenciu. Claude API štandardne automaticky maže vstupy a výstupy zo svojho backendu do 30 dní s definovanými výnimkami. OpenAI API má štandardné abuse-monitoring logy do 30 dní a niektoré funkcie s aplikačným stavom. Gemini osobný účet s vypnutým Keep Activity stále drží budúce chaty 72 hodín. To sú odlišné mechanizmy a nie je správne z jedného údaja o tréningu odvodiť úplný životný cyklus dát. 269

Poznámka: tabuľka je pracovný prehľad, nie náhrada za kontrolu aktuálnych podmienok konkrétneho účtu, regiónu a funkcie. Stav k 8. 10. 2026.

5. GDPR: vloženie osobných údajov do AI je stále spracúvanie osobných údajov

Ak zamestnanec vloží do AI meno zákazníka, e-mail, pracovné hodnotenie, údaje zo životopisu, fakturačné údaje alebo iné informácie viazané na identifikovanú či identifikovateľnú osobu, z pohľadu GDPR nejde o „iba prompt“. Ide o ďalšiu operáciu spracúvania. Prevádzkovateľ musí vedieť, na akom právnom základe spracúvanie stojí, na aký účel sa údaje používajú, či je rozsah údajov nevyhnutný a či je zapojený dodávateľ v primeranom procesnom a zmluvnom režime. Článok 5 GDPR vyžaduje okrem zákonnosti a transparentnosti aj obmedzenie účelu a minimalizáciu údajov. 18

Pri firemnom AI nasadení je preto kľúčový vzťah prevádzkovateľ - sprostredkovateľ. Nie každý dodávateľ je v každom produkte v rovnakej úlohe, ale pri typickom komerčnom AI spracúvaní organizácia určuje účel a spôsob práce so svojimi dátami a poskytovateľ spracúva zákaznícky obsah podľa zmluvných podmienok. Anthropic napríklad explicitne uvádza pri Claude for Work zákazníka ako controller a seba ako processor; obchodné AI služby bežne ponúkajú DPA. Nestačí však mať DPA „niekde v zmluve“ - organizácia musí vedieť, ktoré produkty, subprocessory, regióny, retencie a funkcie skutočne používa. 820

Pri vysoko rizikovom spracúvaní môže vstúpiť do hry DPIA podľa článku 35 GDPR; pri zabezpečení článok 32 vyžaduje primerané technické a organizačné opatrenia. EDPB zároveň upozorňuje, že model vyvinutý na osobných údajoch nemožno automaticky považovať za anonymný a anonymita sa posudzuje prípad od prípadu. Pseudonymizácia - napríklad nahradenie mena kódom, keď existuje spätný kľúč - nie je anonymizácia. Praktická AI politika preto nemá pracovať s vetou „odstránime meno a GDPR je vyriešené“, ale s analýzou reidentifikačného rizika, účelu, nevyhnutnosti a právneho základu. 2021

6. Osobné údaje, osobitné kategórie a dokumenty, ktoré do bežného AI chatu nepatria

Nie všetky osobné údaje majú rovnaké riziko. Bežné identifikátory, zákaznícke kontakty či pracovné údaje podliehajú GDPR, ale osobitné kategórie podľa článku 9 - napríklad zdravotné údaje, biometrické údaje používané na jedinečnú identifikáciu, politické názory, náboženské presvedčenie alebo údaje o sexuálnom živote - majú prísnejší režim. Podobne citlivé sú údaje o trestných odsúdeniach podľa článku 10. Pri takýchto dátach nestačí iba vypnúť tréning; organizácia musí posúdiť právny základ, zmluvný režim, prístup, retenciu, bezpečnosť, lokalitu spracúvania a nevyhnutnosť samotného použitia AI. 18

Praktická chyba vzniká pri „anonymizovaní“ dokumentu ručným odstránením mena. Zmluva môže stále obsahovať e-mail, podpis, číslo účtu, identifikačné číslo, interné číslo prípadu alebo kombináciu dát, z ktorej sa osoba dá určiť. Životopis bez mena môže byť identifikovateľný cez kombináciu zamestnávateľa, pracovnej pozície a dátumov. Zdravotná správa bez rodného čísla môže byť stále osobným údajom. Preto je pri AI vhodnejšia dátová minimalizácia a účelová redakcia: model dostať len tie fragmenty, ktoré reálne potrebuje na úlohu. 1821

Pre bežnú kancelársku prax to znamená, že namiesto vloženia celej personálnej zložky na preformulovanie jednej vety sa vyberie iba relevantný odsek a odstránia sa všetky nepotrebné identifikátory. Namiesto nahrania databázy zákazníkov na vytvorenie segmentov sa môže najprv vykonať agregácia alebo pseudonymizácia v schválenom internom prostredí. Minimalizácia údajov nie je administratívna formalita; pri generatívnej AI priamo znižuje následky chybného zdieľania, kompromitácie účtu, chybného oprávnenia aj prompt injection útoku. 18

7. Obchodné tajomstvo: riziko nie je iba „či sa na tom bude trénovať“

Smernica (EÚ) 2016/943 definuje obchodné tajomstvo tromi kumulatívnymi prvkami: informácia nie je všeobecne známa alebo ľahko dostupná v príslušných kruhoch, má komerčnú hodnotu preto, že je tajná, a osoba, ktorá ju oprávnene kontroluje, prijala za daných okolností primerané kroky na zachovanie jej tajnosti. Do tejto kategórie môžu patriť cenotvorba, marže, obchodná stratégia, zákaznícke databázy, know-how, výrobné postupy, výskumné poznatky, algoritmy či technická dokumentácia. 19

Vloženie obchodného tajomstva do externého AI systému automaticky neznamená, že informácia prestala byť obchodným tajomstvom. Taký kategorický záver by bol právne nepresný. Môže však byť relevantné pri posudzovaní, či firma prijímala „primerané kroky“ na zachovanie tajnosti, a môže porušiť interné pravidlá, NDA, zákaznícku zmluvu alebo bezpečnostnú politiku. Riziko závisí od konkrétneho produktu, zmluvy, účelu, tréningových nastavení, retencie, prístupov, subprocesorov, geografického spracúvania a oprávnenia zamestnanca daný obsah tretej strane sprístupniť. 19

Preto je zlý bezpečnostný model založený iba na zozname „AI, do ktorej sa nesmú vkladať tajomstvá“. Firma potrebuje klasifikáciu informácií a mapu povolených systémov. Materiál označený Restricted môže byť zakázaný vo všetkých externých AI systémoch, zatiaľ čo Confidential môže byť povolený iba v konkrétnom enterprise workspaci s vypnutými externými konektormi a schválenou retenciou. Interné dáta nízkej citlivosti môžu byť prípustné aj v širšom režime. Takýto model je auditovateľný a lepšie zodpovedá požiadavke primeraných ochranných opatrení.

8. Zmluvy a dôverné dokumenty: najčastejší problém je oprávnenie na ďalšie sprístupnenie

Zmluva môže obsahovať osobné údaje, obchodné tajomstvá, ceny, bankové údaje, technické prílohy a osobitné povinnosti dôvernosti súčasne. Preto nie je možné povedať, že „zmluvy sa do AI môžu“ alebo „zmluvy sa do AI nesmú“. Najprv treba určiť, komu zmluva patrí, kto má právo ju spracovať, či je možné zapojiť subdodávateľa, či zmluva obmedzuje účel použitia a či interná politika dovoľuje daný AI systém. V niektorých vzťahoch môže byť problémom už samotné sprístupnenie tretej strane, aj keď táto tretia strana obsah nepoužíva na tréning.

Bezpečnejší workflow používa vrstvenú redakciu. Na jazykovú úpravu jednej klauzuly netreba posielať kompletnú zmluvu s prílohami. Na porovnanie dvoch verzií možno odstrániť osobné údaje a ekonomické údaje, ktoré s porovnávanou otázkou nesúvisia. Ak je potrebná plná dokumentová analýza, mala by prebiehať v schválenom business/enterprise alebo API prostredí, ktoré má zmluvné pokrytie, zodpovedajúce nastavenia a interné povolenie. Aj vtedy ostáva právne posúdenie zmluvy ľudskou zodpovednosťou.

Osobitne treba odlíšiť právne tajomstvo, profesijnú mlčanlivosť a advokátsku dôvernosť, ktoré sa riadia konkrétnym právnym poriadkom a profesijnými pravidlami. Nie je bezpečné predpokladať, že ak má AI dodávateľ dobrú privacy policy, automaticky tým zachová všetky právne režimy dôvernosti. Pri regulovaných alebo profesijne chránených dokumentoch musí organizácia posudzovať aj sektorové pravidlá, zmluvné záväzky a postavenie dodávateľa, nie iba marketingové tvrdenie o „enterprise security“.

9. Zdrojový kód: citlivé nie sú iba algoritmy, ale aj kontext okolo nich

Zdrojový kód môže obsahovať obchodné know-how, interné architektúry, názvy systémov, logiku autorizácie, endpointy, komentáre, mená zákazníkov, testovacie dáta alebo priamo prihlasovacie údaje. V praxi býva väčším rizikom než samotná funkcia v Pythone súbor .env, hard-coded API kľúč, interná URL, stack trace s tokenom alebo dump databázy, ktorý programátor prilepí spolu s chybou. Tajomstvá a prístupové tokeny sa do konverzačného AI nástroja nemajú vkladať vôbec; kompromitovaný kľúč treba považovať za kompromitovaný a rotovať ho.

Pri AI asistovanom programovaní treba kontrolovať dátový režim produktu. GitHub uvádza, že od 24. apríla 2026 môže interaction data z individuálnych Copilot Free, Pro a Pro+ účtov - prompty, výstupy, code snippets a súvisiaci kontext - používať na tréning, pokiaľ používateľ nevyužije opt-out. Copilot Business a Enterprise dáta podľa GitHubu na tréning nepoužíva. Rozdiel medzi individuálnym a firemným účtom je preto pri proprietárnom kóde podstatný. 1415

Ani business licencia však nenahrádza secure coding. AI môže navrhnúť zraniteľný kód, môže dostať nadmerný kontext z repozitára a agentický nástroj môže mať oprávnenie spúšťať shell príkazy. Preto treba oddeliť ochranu dôvernosti kódu od bezpečnosti vykonávania. Pre vývojárov má zmysel používať secret scanning, least-privilege credentials, izolované dev prostredia, review povinných zmien, branch protection a explicitné pravidlá, ktoré súbory alebo repozitáre sa nesmú odosielať do externých modelov.

10. Konektory, MCP a agenti menia otázku „čo som vložil“ na „k čomu má AI prístup“

Pri obyčajnom chate používateľ vedome vyberá text alebo súbor. Pri konektore do Drive, Gmailu, SharePointu, Slacku, CRM alebo GitHubu môže AI dynamicky vyhľadávať relevantný obsah. To výrazne zvyšuje produktivitu, ale mení bezpečnostný model. Riziko sa už nemeria iba podľa promptu, ale podľa množiny zdrojov, ktoré môže používateľ alebo agent prehľadať. Ak organizácia roky tolerovala nadmerné prístupy v SharePointe alebo Drive, AI tieto historické problémy nespôsobí, ale môže ich dramaticky zviditeľniť a zrýchliť ich využitie. 1112

MCP a ďalšie tool protokoly pridávajú nový dátový tok. OpenAI pri data residency výslovne upozorňuje, že dáta odoslané externým appkám, MCP serverom alebo webovým poskytovateľom podliehajú podmienkam týchto tretích strán a nemusia zostať v zvolenom regióne. Preto sa nedá vyhodnotiť iba hlavný AI provider a ignorovať nástrojový ekosystém. Každý konektor má vlastnú autentifikáciu, scope, logy, subprocesorov a retenčné správanie. 17

Agentické systémy navyše vykonávajú akcie. Read-only prístup ku kalendáru je iné riziko než právo odosielať e-maily, mazať súbory alebo spúšťať kód. Základom je least privilege, oddelenie čítania od zápisu, human confirmation pri citlivých akciách, allowlist nástrojov a auditné logy. Prompt injection treba považovať za dátovo-bezpečnostný problém: škodlivá inštrukcia vložená v dokumente alebo webovej stránke sa môže pokúsiť presvedčiť agenta, aby sprístupnil obsah, ku ktorému má oprávnenie. Čím viac dát agent vidí a čím viac akcií môže vykonať, tým prísnejšia musí byť hranica medzi dátami a dôveryhodnými inštrukciami.

11. „Vypol som tréning“ nie je synonymum pre „dáta sa neukladajú“

Toto je jedna z najdôležitejších viet celého článku. Vypnutie tréningu rieši sekundárne použitie obsahu na zlepšovanie modelov, nie nevyhnutne prevádzkovú retenciu. OpenAI API môže uchovávať abuse-monitoring logy do 30 dní. Claude API štandardne maže vstupy a výstupy do 30 dní, ale s výnimkami pre niektoré služby, dohodnutú inú retenciu, presadzovanie pravidiel alebo zákonné povinnosti. Gemini pri vypnutom Keep Activity uchováva budúce chaty 72 hodín. 269

Retencia sama osebe nie je automaticky bezpečnostná chyba. Bezpečnostná detekcia, riešenie zneužitia, obnoviteľnosť služby, audit a používateľská história často objektívne vyžadujú určitú dobu uchovania. Kritickou otázkou je, či organizácia vie, čo sa drží, prečo, ako dlho, kde a kto k tomu môže pristúpiť. Z pohľadu governance je lepšia známa 30-dňová retencia s jasným zmluvným rámcom než neurčitá predstava používateľov, že „AI si nič nepamätá“.

Pri citlivých prípadoch existujú režimy Zero Data Retention alebo modifikovaného abuse monitoringu, ale nebývajú dostupné automaticky pre každého a môžu mať produktové obmedzenia. Navyše extrémne schopné alebo osobitne klasifikované modely môžu mať bezpečnostné výnimky; Anthropic napríklad od júna 2026 pri označených covered models vyžaduje 30-dňovú retenciu promptov a výstupov na bezpečnostné účely aj na niektorých platformách so ZDR. Bezpečnostná architektúra preto musí pracovať s konkrétnym modelom a endpointom, nie iba s logom poskytovateľa. 10

12. Vymazanie chatu nemusí znamenať okamžité fyzické zmiznutie všetkých kópií

Používateľské tlačidlo Delete zvyčajne odstraňuje konverzáciu z používateľského rozhrania okamžite, ale backendové odstránenie môže mať oneskorenie. Anthropic pri spotrebiteľských účtoch uvádza, že zmazaná konverzácia je z histórie odstránená ihneď a z backend storage do 30 dní. Google pri osobnom Gemini upozorňuje, že dáta, ktoré už boli odpojené od účtu a poskytnuté servisným pracovníkom na review, sa odstránením aktivity nemusia odstrániť a môžu byť uchované do troch rokov. 69

Rovnako platí, že ak dáta už vstúpili do tréningového procesu, vypnutie budúceho tréningu nedokáže technicky „odtrénovať“ už dokončený model. Anthropic explicitne uvádza, že po vypnutí nastavenia prestane používať nové a predtým uložené chaty v budúcich tréningových behoch, ale dáta môžu zostať súčasťou tréningu, ktorý už začal, alebo už vytrénovaných modelov. Preto je správny čas na bezpečnostné rozhodnutie pred vložením dát, nie po ňom. 4

Organizácie by mali odlišovať tri procesy: používateľské vymazanie, backendové vymazanie a vypršanie zákonnej či bezpečnostnej retencie. Pri firemnom prostredí sa k tomu pridávajú retention policies, eDiscovery, auditné povinnosti a zálohy. Používateľ preto nemusí mať právo alebo technickú možnosť vymazať všetko sám; napríklad v Claude Team/Enterprise môže dátové exporty spravovať Primary Owner. Dátový lifecycle patrí do administrátorskej governance, nie do intuitívnych predstáv jednotlivca. 8

13. Data residency nie je to isté ako úplná lokalizácia všetkého spracúvania

Data residency zvyčajne znamená, kde je definovaný zákaznícky obsah uložený v pokoji. Inference residency rieši, kde fyzicky prebieha GPU inferencia. Tieto pojmy treba odlíšiť od lokalizácie všetkých systémových dát a pomocných procesov. OpenAI napríklad pri ChatGPT Enterprise/Edu uvádza európsku data residency aj inference residency pre oprávnených zákazníkov, ale zároveň vysvetľuje, že niektoré CPU procesy, autentifikácia, routing, analytika a externé integrácie môžu zostať mimo zvoleného regiónu. 17

Pri ChatGPT Business je režim odlišný: OpenAI v aktuálnej dokumentácii uvádza postupné zavádzanie data residency a upozorňuje, že safety a abuse-monitoring dáta zostávajú v USA; pri workspaci uloženom mimo USA sa môže kópia promptov a odpovedí držať v USA obmedzený čas na bezpečnostné účely. To je presný dôvod, prečo sa enterprise a business nemajú automaticky považovať za technicky identické. 16

Anthropic v júni 2026 uvádza, že pri komerčných službách môže traffic routovať cez viacero krajín a dáta sú štandardne uložené v USA, ak nie je dohodnutý alebo zvolený iný režim pre podporované služby. Google Workspace naopak integruje svoje data-region policies do Workspace a pri novších enterprise funkciách ponúka aj ďalšie možnosti regionálneho spracúvania. Pre GDPR a internú data sovereignty politiku je preto potrebné čítať presnú rezidenčnú dokumentáciu, subprocessor list a DPA konkrétneho produktu. 1322

14. Ľudská kontrola a feedback: malý detail, ktorý môže zmeniť dátový režim

Používatelia často venujú pozornosť tomu, či je model „trénovaný na chatoch“, ale prehliadajú mechanizmy feedbacku a bezpečnostného review. Google pri osobnom Gemini uvádza ľudskú kontrolu vybraných dát na zlepšovanie a bezpečnosť v režime Keep Activity. Anthropic pri spotrebiteľských produktoch môže používať označené konverzácie na safety review a pri feedbacku komerčných účtov uchovať súvisiacu konverzáciu až päť rokov. OpenAI pri business a API produktoch umožňuje explicitné opt-in zdieľanie rôznych dátových kategórií na zlepšovanie modelov. 568

Pre firemné prostredie z toho plynie jednoduché pravidlo: hodnotiace tlačidlá nie sú iba UX prvok. Ak organizácia pracuje s dôvernými dátami, má zmysel presne zistiť, čo feedback odosiela a či ho možno administrátorsky zakázať. Anthropic napríklad umožňuje vlastníkom Team/Enterprise vypnúť Rate chats. Pri API je vhodné mať data-sharing nastavenia centrálne pod kontrolou organizácie. 58

Rovnaký princíp platí pri support tickete. Ak používateľ skopíruje citlivú konverzáciu do zákazníckej podpory, môže ju presunúť do iného workflow s inou retenciou a iným personálnym prístupom. Bezpečnosť AI preto nie je iba vlastnosť model endpointu. Je to celý proces od zadania cez históriu, feedback, support, exporty, integrácie a audit až po vymazanie.

15. Praktická klasifikácia dát pre používanie AI

Najjednoduchší spôsob, ako zabrániť chaotickému rozhodovaniu používateľov, je klasifikovať dáta predtým, než sa začne riešiť konkrétny AI nástroj. Štyri úrovne - Public, Internal, Confidential a Restricted - sú praktickejšie než zoznam stovky zakázaných dokumentov. Každá úroveň sa následne prepojí s povolenými AI prostrediami. Klasifikácia musí vychádzať z reálneho dopadu úniku, zmluvných záväzkov, GDPR, bezpečnostných požiadaviek a obchodnej hodnoty informácie.

Public môže zahŕňať už zverejnený webový obsah, tlačové správy alebo verejné produktové informácie. Internal môže zahŕňať interné procesné materiály bez citlivých detailov. Confidential môže zahŕňať nezverejnené stratégie, klientsku komunikáciu, cenotvorbu alebo dokumenty obsahujúce bežné osobné údaje. Restricted by malo pokrývať prístupové údaje, heslá, API kľúče, citlivé osobné údaje, zdravotnú dokumentáciu, kľúčové obchodné tajomstvá, bezpečnostné incidenty, tajné zdrojové časti a dokumenty, pri ktorých zmluva alebo regulácia zakazuje sprístupnenie externému AI spracovateľovi.

Najdôležitejšie je, aby klasifikácia neurčovala iba „smie/nesmie do AI“, ale aj podmienky. Confidential môže byť povolené iba v schválenom managed workspace s DPA, vypnutým tréningom, povolenou retenciou, MFA, SSO a bez neautorizovaných konektorov. Restricted môže vyžadovať interný model, izolované API so ZDR a regionálnym spracovaním alebo úplný zákaz. Tým sa z bezpečnosti stáva riadený systém namiesto morálneho apelu typu „dávajte si pozor, čo píšete do ChatGPT“.

16. Riziková matica: čo je vhodné kam vkladať

Nasledujúca matica nie je právnou normou, ale praktickým bezpečnostným defaultom pre organizáciu, ktorá ešte nemá vlastný AI governance rámec. Je zámerne konzervatívna. Ak má firma prísnejšie zmluvné alebo sektorové povinnosti, tie majú prednosť. Ak má naopak formálne posúdený enterprise alebo API režim s dodatočnými kontrolami, môže niektoré prípady povoliť po bezpečnostnom a právnom schválení.

Najvyšším rizikom nie je bežný marketingový draft, ale kombinácia citlivého obsahu a neriadeného účtu. Zamestnanec môže mať firemný notebook, ale byť prihlásený do osobného AI účtu. Môže používať platený Pro plán, ale stále pod spotrebiteľskými podmienkami. Môže mať firemný enterprise účet, ale pripojiť k nemu neschválený MCP server. Preto musí politika pomenovať nielen poskytovateľa, ale aj typ účtu, tenant/workspace, povolené funkcie a hranice dát.

Klasifikácia má zmysel iba vtedy, ak je spojená s technickou kontrolou. Ideálne sa kombinuje školenie používateľov, SSO, managed accounts, DLP, browser controls, CASB/SSE, auditné logy, zákaz neautorizovaných rozšírení, secret scanning a monitoring aplikácií. Čisto textová smernica bez technickej podpory zlyháva presne vo chvíli, keď je používateľ pod časovým tlakom.

17. Firemná AI politika: čo musí obsahovať, aby nebola iba papier

Dobrá AI politika odpovedá na konkrétne otázky. Ktoré služby a plány sú schválené? Ktoré dátové triedy sa môžu v ktorom prostredí používať? Kto povoľuje nový konektor alebo agenta? Je povolené posielať spätnú väzbu? Aké účty musia byť spravované organizáciou? Kto kontroluje DPA, subprocessory a data residency? Ktoré rozhodnutia vyžadujú human review? Aká je reakcia pri omylom vloženom tajomstve alebo osobných údajoch? Bez týchto odpovedí zamestnanec improvizuje.

Politika musí rozlišovať generovanie od akcie. Iný risk profile má sumarizácia anonymizovaného textu a iný agent, ktorý môže načítať e-mailovú schránku a odosielať správy. Pre agentické workflow treba zvlášť riešiť scope oprávnení, schvaľovanie akcií, audit, tajomstvá, sandboxing a prompt injection. Rovnako treba rozlíšiť údaje vložené ručne od dát prístupných cez konektor - druhý režim môže sprístupniť omnoho väčší objem informácií bez toho, aby ich používateľ vedome kopíroval.

Napokon treba politiku pravidelne aktualizovať. V roku 2026 sa pravidlá spotrebiteľských účtov, retention možnosti, regionálne spracúvanie a agentické funkcie menia v intervaloch mesiacov. Organizácia by mala mať vlastníka AI governance, register schválených systémov, dátum posledného overenia podmienok a proces zmenového riadenia. Bez toho sa dokument po niekoľkých mesiacoch zmení na neaktuálny opis produktov, ktorý vytvára falošný pocit bezpečia.

18. Incident: čo urobiť, ak zamestnanec vloží citlivé dáta do nesprávnej AI

Prvá reakcia nemá byť panika ani predstieranie, že zmazanie chatu automaticky vyriešilo situáciu. Treba zaznamenať čo bolo vložené, do akej služby, akým účtom, v akom čase, aké nastavenia boli aktívne, či bol použitý konektor, či bola odoslaná spätná väzba a či sa obsah zdieľal verejným linkom. Následne treba podľa možností konverzáciu odstrániť, zrušiť verejné zdieľanie, odpojiť relevantné integrácie a pri kompromitovaných heslách alebo API kľúčoch okamžite vykonať rotáciu.

Druhým krokom je kvalifikácia incidentu. Ide o osobné údaje, obchodné tajomstvo, prístupové údaje, zmluvne dôverné informácie alebo ich kombináciu? Pri osobných údajoch sa posudzuje, či ide o porušenie ochrany osobných údajov a či vznikajú oznamovacie povinnosti podľa GDPR. Pri obchodnom tajomstve sa posudzuje dopad na utajenie a zmluvné záväzky. Pri credentials sa nerieši iba zmazanie promptu - tajomstvo sa musí zneplatniť. Pri zdrojovom kóde sa posudzuje aj bezpečnostný kontext a rozsah zverejnených informácií.

Tretím krokom je kontakt s poskytovateľom alebo správcom workspacu, ak je to relevantné. Firemné licencie môžu mať auditné alebo retenčné nástroje, ktoré používateľ sám nevidí. Organizácia by mala incident použiť na opravu procesu: zablokovať neschválený účet, doplniť DLP pravidlo, upraviť školenie, zmeniť prístupové práva alebo zaviesť schválený enterprise nástroj, aby ľudia nemuseli riešiť pracovnú úlohu v osobnom AI účte. Najhorším výsledkom incidentu je potrestať používateľa a ponechať systémovú príčinu nezmenenú.

19. Čo overiť pred nákupom alebo nasadením AI pre firmu

Pred nákupom AI nestačí porovnať kvalitu modelov a cenu za používateľa. Bezpečnostné due diligence má obsahovať aspoň: právny subjekt poskytovateľa, DPA, úlohu controller/processor, účel spracúvania, tréningové nastavenia, štandardnú a voliteľnú retenciu, možnosti ZDR, data residency, subprocessory, šifrovanie, SSO/MFA/SCIM, audit logy, DLP, eDiscovery, administráciu konektorov, možnosti exportu a vymazania a podmienky feedbacku. Pri API treba kontrolovať konkrétne endpointy, pretože rôzne funkcie môžu mať odlišnú retenciu. 217

Druhá polovica due diligence je interná. Ak firma nevie, kto má prístup k akým dátam, AI tento problém nevyrieši. Ak nemá klasifikáciu informácií, nevie určiť, čo sa smie posielať do externého modelu. Ak nemá vlastníka AI governance, nikto nezachytí zmenu podmienok. Ak zamestnanci používajú osobné účty, enterprise zmluva môže existovať na papieri a pritom reálne dáta prúdia inam. Bezpečný nákup preto zahŕňa aj migráciu používateľov do spravovaných tenantov a odstránenie shadow AI.

Tretia polovica je testovanie. Pred plošným nasadením treba vyskúšať, čo AI vidí pri rôznych rolách, či rešpektuje oprávnenia, aké dáta odosiela web search, čo sa deje s konektormi, či sa logujú citlivé hodnoty a ako sa správa pri prompt injection. Pri agentoch treba simulovať zneužitie nástrojov a overiť human gates. Bezpečnosť sa nedá kúpiť iba licenčným plánom; musí sa overiť v konkrétnej konfigurácii.

20. Minimálny bezpečnostný štandard pre bežného používateľa

Používateľ nemusí poznať celý GDPR ani subprocessor list každého poskytovateľa, ale musí rozlišovať osobný a firemný účet, vedieť identifikovať citlivý obsah a rozumieť tomu, že vypnutie tréningu neznamená nulovú retenciu. Musí vedieť, že heslá, API kľúče, autentifikačné cookies, privátne kľúče a recovery kódy nepatria do AI promptu. Musí vedieť, že kompletný dokument sa nevkladá vtedy, keď úloha vyžaduje iba jeho malý fragment.

Používateľ má pred odoslaním vedieť odpovedať na päť otázok: Som v správnom firemnom workspaci? Mám právo tieto dáta poskytnúť tomuto systému? Potrebuje AI celý obsah alebo iba časť? Obsahuje materiál osobné údaje, obchodné tajomstvo alebo secrets? Používam konektor či agenta, ktorý môže dáta poslať ďalej alebo vykonať akciu? Ak na niektorú otázku nevie odpovedať, správny postup je zastaviť sa a overiť pravidlá, nie spoliehať sa na značku poskytovateľa.

Najpraktickejšia zručnosť je redakcia a minimalizácia. Vymeniť reálne meno za rolu, odstrániť identifikátory, vložiť iba relevantnú klauzulu, zredukovať log na potrebný stack trace bez tokenov a nahradiť reálne čísla syntetickými, ak presné hodnoty nie sú potrebné. Tým sa znižuje riziko nezávisle od toho, aká kvalitná je zmluvná ochrana poskytovateľa.

21. Minimálny bezpečnostný štandard pre firmu

Firma potrebuje minimálne inventár používaných AI služieb, rozdelenie na schválené a neschválené produkty, klasifikáciu dát, pravidlá pre consumer a business účty, DPA pri spracúvaní osobných údajov, MFA/SSO pre spravované účty, pravidlá pre konektory a agentov, incident response a pravidelné školenie. Zamestnanci musia dostať použiteľnú alternatívu; zákaz bez schváleného nástroja často vytvára shadow AI namiesto bezpečnosti.

Pre citlivejšie prostredie treba pridať DLP, CASB/SSE, logovanie, retention policies, eDiscovery, secret scanning, pravidlá pre source code, samostatný proces schvaľovania agentických akcií a pravidelné revízie oprávnení. Ak organizácia požaduje európsku rezidenciu alebo spracúvanie, musí overiť rozdiel medzi data residency a inference residency a presne určiť, čo zostáva mimo zvoleného regiónu. 17

Napokon treba mať metriku kvality governance: percento používateľov v managed workspaci, počet neschválených AI aplikácií, počet incidentov s citlivými dátami, počet aktívnych konektorov, počet workspaces bez MFA, čas od zmeny vendor podmienok po internú revíziu a percento procesov s definovaným human gate. AI bezpečnosť sa stáva riaditeľnou až vtedy, keď sa dá merať.

22. Záver: najväčšie riziko AI nie je, že „model všetko ukradne“, ale že firma nevie, kam dáta posiela

Bezpečná práca s generatívnou AI nezačína zákazom ani slepou dôverou. Začína presným modelom dátového toku. Ktoré dáta vstupujú do systému, kto ich spracúva, na aký účel, ako dlho sa držia, či sa používajú na tréning, či sa k nim môže dostať človek, kde sa spracúvajú a ktoré externé nástroje sa do workflow zapájajú. Až potom sa dá rozhodnúť, či je daný use case primerane bezpečný.

Najpraktickejším pravidlom je prestať deliť AI na „zadarmo“ a „platenú“. Relevantné kategórie sú osobný spotrebiteľský účet, organizáciou riadený business/enterprise účet a API s konkrétnou konfiguráciou. Platený consumer plán môže mať spotrebiteľský dátový režim; business licencia môže mať nulový tréning, ale stále určitú retenciu; API môže mať ZDR, no externý MCP server môže dáta odviesť mimo pôvodný rámec. Bezpečnosť je vlastnosť celej architektúry, nie jedného checkboxu.

A napokon: najcitlivejší obsah by sa nemal vkladať do AI iba preto, že vendor sľubuje, že ho netrénuje. Rozhodujúca je nevyhnutnosť. Ak AI na úlohu nepotrebuje meno klienta, neposielajte ho. Ak nepotrebuje celú zmluvu, neposielajte ju. Ak nepotrebuje production secret, nikdy ho neposielajte. Dátová minimalizácia je pri AI najjednoduchšia ochrana, ktorá funguje naprieč poskytovateľmi, modelmi aj budúcimi zmenami podmienok.

23. Kontrolný zoznam pred vložením citlivého obsahu do AI

☐ Používam firemný, organizáciou schválený účet - nie osobný consumer workspace?

☐ Je tento konkrétny plán a funkcia vylúčená z modelového tréningu alebo mám správne nastavený opt-out?

☐ Viem, aká je retencia promptov, odpovedí, súborov, logov a feedbacku?

☐ Viem, či môžu byť dáta kontrolované človekom pri quality/safety review alebo podpore?

☐ Obsahuje vstup osobné údaje, osobitné kategórie údajov alebo údaje o trestných veciach?

☐ Obsahuje vstup obchodné tajomstvo, NDA obsah, nezverejnené ceny, stratégiu alebo know-how?

☐ Obsahuje vstup zdrojový kód, interné endpointy, stack trace, credentials alebo secrets?

☐ Potrebujem na túto úlohu celý dokument, alebo stačí minimálny fragment?

☐ Je AI poskytovateľ/sprostredkovateľ pokrytý DPA a interným vendor approval?

☐ Je data residency/inference residency požiadavkou a je naozaj zapnutá pre konkrétny workspace?

☐ Používam konektor, MCP, web search alebo agenta, ktorý môže dáta poslať ďalšej tretej strane?

☐ Má agent iba minimálne potrebné oprávnenia a vyžaduje citlivá akcia human confirmation?

☐ Viem, čo sa stane, ak omylom odošlem citlivé dáta a koho okamžite kontaktovať?

24. Odborné zdroje a primárna dokumentácia

Zdroje boli kontrolované podľa oficiálnej dokumentácie a právnych textov dostupných k 8. 10. 2026. Pri produkčnom nasadení treba pred rozhodnutím overiť aktuálne podmienky konkrétneho plánu, regiónu a funkcie.

1 OpenAI - Business data privacy, security, and compliance: https://openai.com/business-data/

2 OpenAI - Data controls in the OpenAI platform (API): https://developers.openai.com/api/docs/guides/your-data

3 OpenAI Help Center - Keep history on but disable model training / personal vs business data controls: https://help.openai.com/en/articles/8983130-what-if-i-want-to-keep-my-history-on-but-disable-model-training

4 Anthropic Privacy Center - Consumer model training and model improvement settings: https://privacy.claude.com/en/articles/10023580-is-my-data-used-for-model-training

5 OpenAI Help Center - Sharing feedback, evaluation, fine-tuning and API inputs/outputs: https://help.openai.com/en/articles/10306912-sharing-feedback-evaluation-and-fine-tuning-data-and-api-inputs-and-outputs-with-openai

6 Google - Gemini Apps Privacy Hub: https://support.google.com/gemini/answer/13594961

7 Google - Manage & delete your activity in Gemini Apps: https://support.google.com/gemini/answer/13278892

8 Anthropic Privacy Center - Commercial products: model training, feedback and controller/processor roles: https://privacy.claude.com/en/articles/7996868-is-my-data-used-for-model-training

9 Anthropic Privacy Center - Data retention for consumer and commercial products: https://privacy.claude.com/en/articles/10023548-how-long-do-you-store-my-data

10 Anthropic - Data retention practices for Covered Models: https://support.claude.com/en/articles/15425996-data-retention-practices-for-covered-models

11 Google Workspace - Generative AI in Google Workspace Privacy Hub: https://knowledge.workspace.google.com/admin/generative-ai/generative-ai-in-google-workspace-privacy-hub

12 Google Workspace - What controls Gemini’s access to Workspace data: https://support.google.com/a/users/answer/17010577

13 Anthropic Privacy Center - Server locations / routing and storage: https://privacy.claude.com/en/articles/7996890-where-are-your-servers-located-do-you-host-your-models-on-eu-servers

14 GitHub Copilot - Data usage for individual vs Business/Enterprise subscribers: https://github.com/features/copilot

15 GitHub Blog - Updates to Copilot interaction data usage policy, March 25 2026: https://github.blog/news-insights/company-news/updates-to-github-copilot-interaction-data-usage-policy/

16 OpenAI Help Center - Where ChatGPT Business content is stored: https://help.openai.com/en/articles/20001418-where-your-chatgpt-business-content-is-stored

17 OpenAI Help Center - Data residency and inference residency for ChatGPT: https://help.openai.com/en/articles/9903489-data-residency-for-chatgpt/

18 EUR-Lex - Nariadenie (EÚ) 2016/679 (GDPR), najmä čl. 5, 9, 10, 28, 32, 35: https://eur-lex.europa.eu/eli/reg/2016/679/oj?locale=sk

19 EUR-Lex - Smernica (EÚ) 2016/943 o ochrane obchodného tajomstva: https://eur-lex.europa.eu/legal-content/SK/TXT/?uri=CELEX:32016L0943

20 EDPB - Opinion 28/2024 on personal data in the context of AI models: https://www.edpb.europa.eu/documents/opinion-of-the-board-art-64/opinion-282024-on-certain-data-protection-aspects-related-to_en

21 EDPB - Zhrnutie stanoviska k AI modelom a anonymite: https://www.edpb.europa.eu/news/edpb-opinion-on-ai-models-gdpr-principles-support-responsible-ai_sk

22 Google Workspace - Workspace Intelligence security, permissions and data regions: https://workspace.google.com/blog/ai-and-machine-learning/spend-less-time-prompting-6-ways-workspace-intelligence-offers-personalized-help

23 Microsoft Learn - Data, Privacy, and Security for Microsoft Copilot: https://learn.microsoft.com/en-us/copilot/microsoft-365/microsoft-365-copilot-privacy

Právna poznámka: Článok je odborný vzdelávací materiál. Konkrétne povinnosti podľa GDPR, zmluvných doložiek, profesijnej mlčanlivosti a sektorovej regulácie sa musia posúdiť podľa reálneho use case, jurisdikcie, zmluvy a konfigurácie služby.

Súvisiace články

• Ako začať pracovať s ChatGPT a nastaviť si ho na profesionálnu prácu
• Kedy AI automatizovať a kedy ju nechať iba ako asistenta