Tento článok ti ukáže, čo nepísať umelej inteligencii, prečo je to riziko a hlavne – ako to anonymizovať tak, aby AI aj tak pomohla.
Predstav si, že AI je tvoj super-šikovný kolega. Rýchly, neúnavný, s pamäťou ako slon… len s jedným drobným detailom: nevieš presne, kde všade sa tvoje dáta môžu objaviť (logy, histórie, zdieľania v tíme, pluginy, preklepy, screenshoty, „len na chvíľu“). A potom príde pondelok a ty zistíš, že si do promptu omylom prilepil API token. Keď si prečítaš tento článok, zistíš čo nepísať umelej inteligencii.
Prečo je „čo nepísať umelej inteligencii“ vôbec téma?
AI je skvelá na analýzu, návrhy, refaktoring, troubleshooting a texty. O tom, akú AI použiť pre písanie, analýzu, … si môžeš pozrieť môj článok, kde porovnávam niekoľko AI služieb. Problém nastane, keď sa z promptu stane výpis z trezoru, nie otázka.
Zjednodušene:
- AI často nepotrebuje „tajomstvá“ na to, aby vyriešila problém.
- Tvoje tajomstvá (heslá, tokeny, interné mená) sú pre útočníka často hodnotnejšie než samotný kód.
1) Heslá, PINy, MFA kódy a odpovede na bezpečnostné otázky
Nikdy. Ani „len na test“.
Čo sem patrí
- heslá (aj staré)
- jednorazové kódy (SMS/Authenticator)
- recovery kódy
- odpovede typu „meno prvého psa“ (áno, aj to)
Bezpečná alternatíva
Namiesto reálneho hesla použi placeholder:
PASSWORD_PLACEHOLDERREDACTED***
2) API tokeny, session cookies, licenčné kľúče, privátne kľúče
Ak je heslo kľúč od bytu, tak API token je kľúč od serverovne.
Čo sem patrí
- API keys (OpenAI, Google, AWS, Azure, GitHub…)
- JWT tokeny, session cookies
- SSH private keys (
-----BEGIN PRIVATE KEY-----) - certifikátové privátne kľúče
- licenčné kľúče softvéru
Bezpečná alternatíva
AI stačí vedieť typ tokenu a kontext, nie hodnotu:
- „Používam JWT bearer token, exp 1h, podpis HS256“
- „Volám API cez Authorization header, dostávam 401“
3) Interné názvy, topológia siete a detaily infraštruktúry
Interné názvy sú ako mapa do dungeonu. Keď sa dostane von, niekto si nájde skratky.
Čo sem patrí
- názvy domén typu
corp.local,dc01,fileserver-hr - IP adresy (aj privátne rozsahy, ak odhalia topológiu)
- názvy projektov, interné kódy, názvy klientov
- presné verzie a zraniteľné konfigurácie, ak je to identifikovateľné
Bezpečná alternatíva
Zameniť za neutrálne aliasy:
DC01→DOMAIN_CONTROLLER_110.10.12.5→INTERNAL_HOST_Acorp.local→INTERNAL_DOMAIN
4) Osobné údaje (PII) – tvoje, kolegov, zákazníkov
Ak do AI dáš rodné číslo, tak to nie je prompt – to je „dátový incident speedrun“.
Čo sem patrí
- meno + priezvisko + e-mail + tel. (už je to identifikovateľné)
- rodné číslo, adresa, dátum narodenia
- čísla dokladov
- fotky ľudí, podpisy, skeny
Bezpečná alternatíva
Použi realistické náhrady:
USER_001,CUSTOMER_A[email protected]+421900000000
5) Firemné detaily: zmluvy, ceny, obchodné ponuky, incidenty
AI vie vygenerovať e-mail alebo šablónu aj bez toho, aby poznala tvoje reálne čísla a mená.
Čo sem patrí
- ceny a zľavy viazané na konkrétneho klienta
- interné SLA, obchodné podmienky, NDA texty
- detaily incidentu s identifikátorom firmy
Bezpečná alternatíva
Zovšeobecni:
- „zľava v rozsahu 10–20 %“
- „incident v prostredí s AD + M365 + VPN“
6) Citlivé prílohy: logy, exporty, databázy, screenshoty
Logy vyzerajú nevinne… až kým v nich nie je Authorization: Bearer ... alebo e-mailová komunikácia.
Čo sem patrí
- exporty z CRM/HR
- plné logy s identifikátormi
- screenshoty s menami, IP, URL tokenmi
Bezpečná alternatíva
- vyrež nerelevantné časti
- anonymizuj hodnoty
- nechaj štruktúru a chyby
Ako anonymizovať tak, aby AI stále pomohla
Zlaté pravidlo: nechaj štruktúru, odstráň identitu.
Rýchla anonymizácia (praktické pravidlá)
- mená →
USER_A,ADMIN_B - e-maily →
[email protected] - domény →
INTERNAL_DOMAIN - IP →
HOST_A,HOST_B(alebo10.0.X.Xbez významu) - tokeny →
TOKEN_REDACTED - cesty →
C:\Path\To\App - názvy projektov →
PROJECT_X
Zachovaj tieto veci (AI ich potrebuje)
- chybové hlášky (presne)
- časový sled udalostí
- verzie (ak neidentifikujú firmu)
- konfiguráciu v abstraktnej forme
- očakávané vs reálne správanie
Mini‑lab: problémový ticket → „risk“ prompt vs „safe“ prompt
Ticket (problém)
„Používateľ sa nevie prihlásiť do interného portálu po resetovaní hesla. Hlási 401 a v logu je chyba pri overovaní tokenu.“
1) RISK prompt (zlý príklad)
Ahoj, tu je náš interný portál https://portal.firma.sk, beží to na serveri dc01.firma.local (10.10.12.5). Používame JWT a tu je token: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9… Tu sú logy s emailom [email protected] a heslo po resete je: Novák2025! Vieš zistiť, prečo to hádže 401?
Prečo je to zle:
- obsahuje interné domény, IP
- obsahuje reálne PII
- obsahuje token + heslo
2) SAFE prompt (dobrý príklad)
Riešim problém s prihlásením do interného webu. Po resete hesla používateľ dostane 401. Používame JWT (HS256) a overovanie podpisu na backend-e. Príklad logu (anonymizované):
AUTH: token signature validation failed for USER_AHTTP 401 on /api/auth/refreshČo sú najčastejšie príčiny 401 po resete hesla pri JWT, a aké kroky diagnostiky odporúčaš (bez toho, aby som posielal tokeny alebo interné údaje)?
Prečo je to dobré:
- máš typ auth, symptóm, logy, endpointy
- nič citlivé
- AI vie navrhnúť postup diagnostiky
Rýchly tip na koniec
Keď váhaš, či niečo do AI poslať, spýtaj sa sám seba: „Zničí mi tento prompt deň, ak sa omylom objaví na verejnosti?“ Ak áno – anonymizovať, skrátiť, alebo to radšej neposlať. Ak riešiš, čo nepísať umelej inteligencii, drž sa pravidla: problém áno, identita nie. Všetko, čo by si nedal do verejného GitHub issue alebo do ticketu bez prístupov, do AI tiež nelep.
Zdroje :
