Wyciek z Claude? Co się naprawdę stało z udostępnionymi czatami

W weekend social media zapłonęły od nagłówków o „wycieku z Claude”. Rozmowy z chatbotem Anthropic, w tym klucze do portfeli kryptowalut i poufne dane firmowe, miały trafić prosto do wyników Google. Brzmi jak włamanie stulecia. W rzeczywistości nie był to żaden wyciek, a cała sprawa opiera się na jednym błędzie technicznym, który popełnia więcej firm, niż myślisz, i który prawdopodobnie siedzi też na Twojej stronie.

Napisałem ten tekst z dwóch powodów. Po pierwsze, żeby wyjaśnić, co faktycznie się stało, bo większość relacji miesza fakty z domysłami i powiela dwie konkretne nieścisłości. Po drugie, bo pod tą historią kryje się lekcja technicznego SEO, która dotyczy każdego, kto zarządza własną stroną: różnica między zablokowaniem strony a jej usunięciem z wyszukiwarki. To nie to samo, a pomylenie tych dwóch rzeczy jest dokładnie tym, co wywołało całą aferę.

„To nie był wyciek ani włamanie. Użytkownicy sami udostępnili swoje rozmowy przyciskiem „Share”, który tworzy publiczną stronę w internecie. Te strony miały zabezpieczenie przed indeksacją, ale było ono ustawione w sposób, który je unieważniał: adres był jednocześnie zablokowany w pliku robots.txt, przez co robot Google nie mógł odczytać instrukcji „nie indeksuj”. W efekcie wyszukiwarka wylistowała adresy, których nigdy nie otworzyła. Anthropic szybko usunął wyniki, ale stare linki nadal działają, a to już czwarty taki incydent w branży AI w ciągu roku."

Co się faktycznie wydarzyło

Zacznijmy od faktów, bo tylko one się bronią.

W weekend 25 lipca 2026 użytkownik Reddita opublikował wątek pokazujący, że wpisanie w Google zapytania site:claude.ai/share zwraca cudze udostępnione rozmowy z Claude. Wątek w kilka godzin przekroczył 640 komentarzy, a społeczność zaczęła przeszukiwać wyniki. To, co znaleziono, wahało się od zabawnego po groźne: działający portfel kryptowalutowy z widocznymi kluczami i realnym saldem, sprawdzony przez dwie niezależne osoby, rozmowa prawnika o tym, czy musi sam zgłosić naruszenie etyki zawodowej, czyjeś CV z prawdziwymi danymi, fragmenty wewnętrznej pracy inżynierskiej dużej firmy technologicznej.

Następnego ranka pojawił się drugi wątek, pokazujący, że to samo działa z opublikowanymi artefaktami, czyli interaktywnymi elementami, które Claude potrafi generować: dashboardami, prototypami, dokumentami. Anthropic zareagował w ciągu nocy i wyniki zniknęły z Google.

Jedna rzecz od razu wymaga podkreślenia, bo przepada w większości relacji. To nie był wyciek. Nikt nie włamał się do systemów Anthropic, nikt nie uzyskał dostępu do prywatnych kont. Każda z tych rozmów została udostępniona świadomie przez jej właściciela, przyciskiem „Share”. Spór nie dotyczy tego, czy ktoś ukradł dane, tylko tego, czy użytkownicy rozumieli, że udostępnienie linku oznacza opublikowanie strony w internecie.

Jak działa przycisk „Share” i dlaczego to pułapka na ludzi

Mechanizm jest prosty, a jego konsekwencje nieoczywiste.

Rozmowy z Claude są domyślnie prywatne. Zmienia się to dopiero w momencie, gdy klikasz „Share”. Wtedy powstaje publiczna strona zawierająca całą rozmowę do tego momentu. Ta strona nie wymaga logowania. Każdy, kto ma jej adres, widzi wszystko.

I tu jest sedno problemu, które nie jest techniczne, tylko ludzkie. Użytkownik słyszy „udostępnij każdemu, kto ma link” i rozumie to jako „prywatne, ale wygodne”. System w rzeczywistości oznacza „opublikowane w otwartym internecie, ale trudne do znalezienia”. To dwie zupełnie różne sytuacje z punktu widzenia ryzyka, a przetrwaniu tej pierwszej nie sprzyja żaden współpracownik, który wkleja rzeczy do publicznych kanałów.

Wyobraź sobie typowy scenariusz w firmie. Ktoś z działu finansów prosi Claude o sprawdzenie umowy z dostawcą, wklejając ją w całości. Odpowiedź jest przydatna, więc udostępnia link koledze. Kolega wkleja go na firmowy Slack, żeby rozstrzygnąć dyskusję. Kanał jest publiczny. Nikt się nie włamał, żadna zasada nie została wprost złamana, a poufna umowa handlowa ma teraz publiczny adres, którego nie da się cofnąć, bo tylko osoba, która pierwotnie udostępniła, może to zrobić. Podstaw w to miejsce notatkę z postępowania dyscyplinarnego albo dane osobowe klienta, a obraz robi się poważny.

Warto dodać: udostępniona rozmowa pokazuje imię osoby, która ją udostępniła. To zamienia anonimowy przeciek w przeciek z nazwiskiem.

Nieścisłość pierwsza: Claude nie trzyma listy linków w mapie strony

Teraz prostuję dwie rzeczy, które krążą po sieci i są nieprawdziwe, bo bez tego cała analiza jest błędna.

Pierwsza wersja mówi, że „Claude trzyma listę udostępnionych plików w mapie strony dla robotów wyszukiwarek”. To nieprawda.

Adresy udostępnionych rozmów zawierają losowy identyfikator UUID. Nikt ich nie zgaduje, a Google nie zna ich z żadnej sitemapy. Jedyny sposób, w jaki taki link trafia do indeksu wyszukiwarki, to gdy ktoś opublikuje go w miejscu, które przemierza robot: na publicznym Slacku, Discordzie, w zgłoszeniu na GitHubie, we wpisie na X albo w komentarzu na LinkedIn. Użytkownik udostępnia link jednej osobie, ta wkleja go do publicznego kanału i prywatna rozmowa staje się publiczną stroną z adresem możliwym do znalezienia.

To istotne, bo przenosi ciężar zrozumienia problemu. Nie chodzi o to, że Anthropic aktywnie podsyłał te linki Google. Chodzi o to, że wystarczyło, by wyciekły do jednego publicznego miejsca, a reszta potoczyła się sama. Zresztą już w podobnym incydencie z 2025 roku Anthropic oświadczył, że nie udostępnia wyszukiwarkom katalogów ani map udostępnionych czatów, i to oświadczenie było prawdziwe. Ekspozycja i tak się wydarzyła, bo blokowanie sitemapy nigdy nie było mechanizmem, który by jej zapobiegł.

Nieścisłość druga: strony miały noindex, tylko nie działał

Druga wersja jest jeszcze częstsza: „udostępnione strony nie miały tagu noindex”. Prawda jest dokładnie odwrotna i znacznie ciekawsza, zwłaszcza jeśli zajmujesz się SEO.

Tu potrzebne jest krótkie wyjaśnienie dwóch mechanizmów, które ludzie notorycznie mylą.

Plik robots.txt mówi robotowi wyszukiwarki, których stron NIE MA CZYTAĆ. Reguła Disallow oznacza „nie wchodź na tę stronę”.

Tag noindex (w kodzie strony albo w nagłówku HTTP) mówi robotowi „możesz przeczytać tę stronę, ale nie umieszczaj jej w wynikach wyszukiwania”.

To są dwie różne instrukcje o dwóch różnych skutkach. I tu jest pułapka, w którą wpadł Anthropic, a którą Google opisuje w swojej dokumentacji czarno na białym.

Udostępnione rozmowy pod ścieżką /share/ MIAŁY instrukcję zakazującą indeksacji, w postaci nagłówka X-Robots-Tag: none (co jest równoważne z „noindex, nofollow”). Ale ta sama ścieżka była JEDNOCZEŚNIE zablokowana w pliku robots.txt regułą Disallow: /share/*. A skoro robot ma zakaz czytania tych stron, to nigdy nie dociera do nagłówka, który mówi mu „nie indeksuj”. Blokada czytania unieważnia instrukcję o nieindeksowaniu.

Cytując dokumentację Google wprost: żeby reguła noindex zadziałała, strona nie może być zablokowana w robots.txt i musi być dostępna dla robota. Jeśli jest zablokowana, robot nigdy nie zobaczy reguły noindex, a strona może się pojawić w wynikach, na przykład gdy linkują do niej inne strony.

Efekt jest paradoksalny. Google wylistował adresy udostępnionych rozmów, ale nigdy ich nie otworzył. Dlatego w wynikach pojawiały się linki bez opisów, wyglądające jak duplikaty, które trzeba było ręcznie rozwinąć. Wyszukiwarka znała adresy, ale nie znała treści, dopóki ktoś nie kliknął.

Najciekawsze jest porównanie z artefaktami. Ścieżka /public/artifacts/ NIE była zablokowana w robots.txt, za to miała czytelny tag noindex w kodzie strony. Czyli była skonfigurowana poprawnie. Ta ścieżka, która wyglądała na mniej zabezpieczoną, bo dostępna dla robota, w rzeczywistości była lepiej chroniona, bo robot mógł odczytać i uszanować instrukcję.

Lekcja SEO, która dotyczy Twojej strony

Zatrzymuję się tu, bo to jest fragment ważniejszy niż sama afera z Claude.

To, co przydarzyło się Anthropic, to jeden z najczęstszych błędów technicznego SEO, jakie widuję podczas audytów. Zespół chce usunąć jakąś sekcję z Google, więc dodaje regułę Disallow w robots.txt, wierząc, że to znaczy „trzymaj to z dala od wyszukiwarki”. A to znaczy tylko „nie czytaj tej strony”.

Pułapka polega na tym, że Disallow działa idealnie. Robot faktycznie nie czyta strony. Robi to tak skutecznie, że nie odczytuje też jedynej instrukcji, która naprawdę usunęłaby stronę z indeksu, czyli tagu noindex. Blokada, która miała pomóc, aktywnie szkodzi.

Zasada, którą trzeba zapamiętać, jest odwrotna od intuicji. Jeśli chcesz, żeby strona zniknęła z Google, musisz WPUŚCIĆ robota i dopiero wtedy kazać mu odejść. Wpuszczasz go (brak Disallow), on czyta stronę, widzi noindex i usuwa ją z wyników. Jeśli zablokujesz mu wejście, strona może wisieć w indeksie w nieskończoność, bo robot nigdy nie dostanie instrukcji, żeby ją usunąć.

Praktyczny wniosek do zastosowania u siebie: przejrzyj wszystkie ścieżki, które zablokowałeś w robots.txt, i sprawdź, czy któraś z nich ma jednocześnie noindex. Wszędzie tam, gdzie oba występują naraz, noindex jest martwy, a Ty możesz mieć w Google strony, o których myślisz, że są ukryte. Rozwiązanie: usuń blokadę i zostaw noindex.

Kwadrans kontroli: infografika do wydruku

Zebrałem najważniejsze kroki w jednym widoku – od cofnięcia udostępnionych czatów po rotację kluczy. Zajmie Ci to dosłownie kwadrans i zamyka bieżącą ekspozycję.

Dlaczego usunięcie z Google nie zakończyło sprawy

W kilka godzin od nagłośnienia wyniki zniknęły z Google i część osób ogłosiła, że problem rozwiązany. Nie został, i to z kilku powodów.

Usunięcie jest prawdopodobnie tymczasowe. Reguła Disallow nie usuwa stron, które już są w indeksie, więc coś innego wyczyściło je tak szybko. Najprawdopodobniej narzędzie do usuwania w Search Console, a te żądania działają przez około pół roku. To zawieszenie, nie skasowanie. Trwałe usunięcie wymaga tagu noindex na stronie, czyli dokładnie tej instrukcji, której blokada w robots.txt nie pozwala robotowi przeczytać. Dopóki konfiguracja się nie zmieni, zegar tyka.

Usunięcie dotyczy jednej wyszukiwarki. Po tym, jak Google wyczyścił wyniki, te same rozmowy nadal dawały się znaleźć w Bing i Brave. Żądanie usunięcia w Google nie robi nic w innych wyszukiwarkach.

Adresy nadal działają. Widoczność w wyszukiwarce i dostępność strony to dwie różne rzeczy. Każda z tych rozmów wciąż jest żywa pod swoim oryginalnym adresem dla każdego, kto ma albo kiedykolwiek miał link. Usunięcie strony z indeksu nie robi nic samej stronie.

Kopie już istnieją. Zanim wątek ucichł, jedna osoba zdążyła zescrapować 25 stron wyników do publicznego repozytorium na GitHubie, a zewnętrzny serwis już agregował opublikowane artefakty według tytułów. Gdy coś raz trafi do indeksu, nie negocjujesz już z wyszukiwarką. Negocjujesz z każdym, kto to zobaczył.

To już czwarty taki przypadek w ciągu roku

Najważniejsze, żeby nie traktować tego jako problemu Anthropic. To problem wzorca projektowego, który powtarza się w całej branży.

• →Lipiec 2025: udostępnione rozmowy z ChatGPT stały się wyszukiwalne, a OpenAI wycofał funkcję.
• →Sierpień 2025: setki tysięcy transkryptów z Groka trafiły do indeksu.
• →Wrzesień 2025: Forbes opisał kilkaset transkryptów Claude w Google.
• →Lipiec 2026: opisywany incydent.

Cztery incydenty, trzej dostawcy, dwanaście miesięcy. To nie jest wpadka jednej firmy. To właściwość funkcji „Share” w narzędziach AI, powtarzalna na tyle, że warto ją traktować jako stałą cechę, a nie jednorazowy błąd. Prawie każdy konsumencki chatbot AI, ChatGPT, Gemini, Grok, Perplexity, DeepSeek, ma funkcję udostępniania, która tworzy publiczny adres URL. Mechanizm jest wszędzie ten sam, więc i ryzyko jest wszędzie takie samo.

Co zrobić dzisiaj, zajmie kwadrans

Konkretne kroki, w kolejności ważności.

1. 1.Przejrzyj swoje udostępnione czaty i cofnij te wrażliwe. W Claude: Ustawienia, potem Prywatność, potem Udostępnione czaty. Zobaczysz listę wszystkiego, co kiedykolwiek udostępniłeś. Cofnij udostępnienie tego, czego nie chcesz mieć publicznie. To samo zrób w ChatGPT, Gemini i Copilot. To jedyny punkt z tej listy, który zamyka ekspozycję już istniejącą.
2. 2.Przejrzyj opublikowane artefakty. Dashboardy, modele finansowe, listy klientów, plany produktu. Cofnij publikację tych z danymi.
3. 3.Nie licz na to, że pracownicy sami się przyznają. Osoba, która udostępniła coś wrażliwego, jest ostatnią, która to zgłosi. Jeśli masz w firmie logi proxy, DNS albo systemu bezpieczeństwa, poszukaj żądań do claude.ai/share/, claude.ai/public/artifacts/ i chatgpt.com/share/. To pokaże, kto i mniej więcej kiedy udostępniał, bez zmuszania nikogo do samooskarżenia.
4. 4.Zrób rotację kluczy i haseł, jeśli kiedykolwiek trafiły do czatu. Tag noindex nie cofa tego, że klucz był przez jakiś czas publiczny. To dotyczy każdego narzędzia AI, nie tylko Claude.
5. 5.Sprawdź, czy możesz wyłączyć udostępnianie centralnie. Plany biznesowe i firmowe tych narzędzi często pozwalają administratorowi ograniczyć albo wyłączyć publiczne udostępnianie. Plany konsumenckie zwykle nie. Jeśli Twoi pracownicy używają do pracy kont prywatnych, nie masz nad tym żadnej kontroli, i to samo w sobie jest ustaleniem wartym uwagi.

Sedno jest głębsze niż kasowanie linków

Można przejść przez tę listę w kwadrans i zamknąć bieżącą ekspozycję. Ale prawdziwe pytanie jest trudniejsze: czy ktokolwiek w Twojej firmie wie, co wolno wkleić do modelu, a czego nie?

Jeśli odpowiedź brzmi „każdy robi po swojemu”, to nie jest problem narzędzia i żaden dostawca nie ustawi tego za Ciebie. Tag noindex chronił przed wyszukiwarką. Nie chronił przed tym, że ktoś wkleił klucz API do czatu, żeby dashboard w końcu zadziałał, a potem udostępnił rozmowę.

To jest sedno całej sprawy. Błąd był po stronie dostawcy, ale ryzyko było po stronie procesu. Anthropic naprawił konfigurację w jedną noc. Nawyku wklejania poufnych danych do publicznie udostępnianych rozmów nie naprawi żaden dostawca, bo to nie jest kwestia techniczna.

Warto tu przypomnieć, że art. 4 unijnego aktu o sztucznej inteligencji już wymaga, żeby osoby używające AI w imieniu firmy miały odpowiednie kompetencje w tym zakresie. Kasowanie linków po fakcie kompetencją nie jest. Kompetencją jest wiedza, czego do modelu nie wklejać, zanim się to zrobi.

Mój komentarz w sprawie „wycieku danych”

Cała ta historia zostanie zapomniana za dwa tygodnie, ale zostawia dwie rzeczy warte zapamiętania.

Pierwsza: przycisk „Share” to narzędzie do publikowania, nie do wysyłania wiadomości. Każda funkcja, która tworzy publiczny adres URL bez logowania, umieściła tę treść w otwartym internecie, a jedyne, co dzieli ją od obcej osoby, to czy adres wycieknie. Twoi pracownicy nie myślą o tym w ten sposób, a Twoje narzędzia bezpieczeństwa prawdopodobnie tego nie monitorują.

Druga, dla każdego kto zajmuje się stronami: Disallow i noindex to nie jest ten sam mechanizm, a ustawienie obu na jednej stronie po cichu wyłącza ten, który ma znaczenie. Anthropic zrobił to dobrze na artefaktach i źle na rozmowach, co jest dobrą ilustracją, jak łatwo te dwie rzeczy pomylić nawet ludziom, którzy wyraźnie wiedzą, co robią.

Zacznij od przejrzenia swoich udostępnionych czatów. Kosztuje to kwadrans, nie wymaga budżetu i jest jedynym działaniem, które zamyka ekspozycję już istniejącą. A potem potraktuj publiczny adres URL bez logowania tak, jak na to zasługuje: jak publikację w internecie, a nie jak wiadomość do jednej osoby.

TL;DR

• →To nie był wyciek ani włamanie. Użytkownicy sami udostępnili rozmowy przyciskiem „Share”, który tworzy publiczną stronę w internecie.
• →Rozmowy trafiały do Google tylko wtedy, gdy ktoś wkleił link w publiczne miejsce. Adresy mają losowy UUID i nie ma ich w żadnej sitemapie.
• →Strony MIAŁY zabezpieczenie noindex, ale było ono unieważnione przez blokadę w robots.txt: robot nie mógł przeczytać strony, więc nie widział instrukcji „nie indeksuj”.
• →Lekcja SEO: Disallow i noindex to nie to samo. Żeby usunąć stronę z Google, trzeba wpuścić robota i podać mu noindex, a nie blokować mu wejście.
• →Usunięcie z Google nie zakończyło sprawy: stare linki nadal działają, wyniki zostały tylko zawieszone na około pół roku, działały dalej w Bing i Brave, a kopie już krążą.
• →To czwarty taki incydent w ciągu roku (ChatGPT, Grok, Claude ×2). To właściwość funkcji „Share” w narzędziach AI, nie wpadka jednej firmy.
• →Co zrobić w kwadrans: przejrzyj udostępnione czaty i artefakty, cofnij wrażliwe, zrób rotację kluczy, sprawdź logi zamiast pytać pracowników, rozważ wyłączenie udostępniania centralnie.
• →Sedno jest głębsze niż kasowanie linków: publiczny URL bez logowania to publikacja, nie wiadomość. Prawdziwe pytanie brzmi, czy Twój zespół wie, co wolno wkleić do modelu.