O czym jest ten film
- Większość firm chroni niewłaściwą rzecz: skupia się na bazie danych i dokumentach, a nie na sposobie działania.
- Prawdziwym aktywem są skille, procedury i pętle operacyjne — „przepis na sukces” firmy.
- Korzystanie z chmurowego AI oznacza, że ten przepis może opuścić granice organizacji — nawet przy wyłączonym trenowaniu na danych.
- Autor wprost zastrzega: nie twierdzi, że każdy dostawca trenuje na każdym promptcie. Chodzi o szerszy mechanizm.
- Zapis „nie trenujemy na twoich danych” nie mówi nic o tym, co jeszcze wolno zrobić z danymi.
- Regulaminy zawierają liczne wyjątki: feedback, podejrzenie naruszenia warunków, ocena ryzyka — każdy z nich otwiera dostęp do treści rozmów.
- Google jest wskazany jako firma z relatywnie jaśniejszymi warunkami, ale przejrzystość to nie to samo co bezpieczeństwo.
- Lokalne AI nie jest automatycznie bezpieczne — zależy od konfiguracji, wtyczek i wywoływanych narzędzi.
- Lokalne AI nie służy oszczędzaniu pieniędzy; jego wartość to stabilność i suwerenność.
- Rekomendacja to model hybrydowy: lokalnie tyle, ile się da, w chmurze to, czego inaczej nie da się zrobić.
Redakcyjne tłumaczenie
Chronimy nie to, co trzeba
Większość ludzi i większość firm popełnia dokładnie ten sam błąd. Uważają, że ich baza danych, ich drugi mózg, ich wiedza, ich dokumenty, dane ich klientów — że to jest najważniejsze aktywo i najważniejsze dane. Że właśnie to trzeba chronić.
To ważne, owszem, ale to nie wszystko i to nie jest wasze prawdziwe aktywo. Te dane rzeczywiście trzeba chronić ze względu na prywatność, ale to nie one stanowią majątek firmy. Majątkiem firmy jest sposób, w jaki działacie: wasze umiejętności, wasze przepisy, wasze pętle. To właśnie wymaga ochrony.
(Informacja dodatkowa: „pętle” — w żargonie autora powtarzalne cykle pracy z AI, czyli ustalone sekwencje kroków, promptów i narzędzi, które doprowadzają zadanie do końca. „Skille” to spakowane instrukcje i pliki opisujące, jak wykonać konkretny rodzaj zadania).
W momencie, w którym udostępniacie te dane w sieci chmurowemu AI, oddajecie korporacjom przepis na swój sukces. Tak właśnie uczą się, jak pracujecie.
Precyzyjne postawienie sprawy
Chcę być tutaj precyzyjny. Nie twierdzę, że każdy dostawca trenuje na każdym promptcie ani że kopiuje workflow każdej firmy. Moja teza jest szersza: skill — jego plik, jego narzędzia, jego uprawnienia oraz ślad jego wykonania — może przekroczyć granicę dostawcy nawet wtedy, gdy trenowanie modelu jest wyłączone. Szczegóły zależą od dostawcy i od produktu. Pełne zestawienie linkuję w artykule na Substacku.
Zależy to od tego, jaką macie subskrypcję, czy korzystacie z API, a każda firma ma inne warunki i regulaminy. W większości z nich przeczytacie: „Twoje dane nie będą wykorzystywane do trenowania”. Albo: „Musisz się wypisać, jeśli nie chcesz, by twoje dane były wykorzystywane do trenowania”. W kontach firmowych i enterprise ta rezygnacja jest domyślna. W API również powinna być domyślna.
Ale kiedy mówią wam jedno — „twoje dane nie posłużą do trenowania” — to nie wyjaśnia, co jeszcze mogą z tymi danymi zrobić. Te regulaminy są skrajnie nieprecyzyjne.
Firmą, która pisze warunki nieco jaśniej, jest Google. Google stawia sprawę dość otwarcie: „Będziemy trenować na twoich danych”. A jeśli się wypiszesz, część funkcji przestanie być dostępna. Tyle że przejrzystość nie oznacza, że system jest lepszy. Oznacza tylko, że częściowo wiecie, co robią.
Wypisanie się nie wystarczy.
Drugi mózg lokalnie — i dlaczego to dopiero pierwszy krok
Jak sobie z tym radzić? Zakładam, że pierwszy krok macie już za sobą: wasz drugi mózg działa lokalnie, na waszej maszynie, tak jak u mnie. Od miesięcy powtarzam, że to najważniejszy pierwszy krok.
Ale nie chodzi wyłącznie o to, że w tym drugim mózgu są wasze dane. Chodzi o to, że z takiego systemu da się wyekstrahować sposób, w jaki myślicie. Da się wyekstrahować wasze skille, wasze pętle i tak dalej. Właśnie dlatego trzeba go chronić.
To nie jest wyłącznie kwestia prywatności. Nie chodzi tylko o „nie chcę, żeby dane moich klientów trafiły do tych korporacji”. Albo o to, że obowiązują was regulacje zabraniające dzielenia się danymi klientów z kimkolwiek, więc dane muszą zostać u was. To są słuszne powody. I w takim wypadku jedynym rozwiązaniem jest lokalne AI.
Tyle że nawet lokalne AI nie oznacza stuprocentowego bezpieczeństwa. Wszystko zależy od tego, jak go używacie, jak je skonfigurujecie, jakiego rodzaju narzędzia wywołujecie. W chwili, gdy sięgacie po pewne narzędzia i wtyczki, możecie udostępniać na zewnątrz swoje skille, swoją wiedzę i swoje prywatne dane.
Praca z AI — lokalnym czy chmurowym — jest więc czynnością, którą musimy w pełni rozumieć. To droga do zbudowania systemu suwerennego: takiego, którego działaniu możemy ufać, w którym dane są chronione, w którym dane naszych klientów są chronione, w którym najważniejsze aktywo firmy — pętle i skille — zostaje w naszych murach, w naszym systemie, a nasza wiedza, nasze myślenie, nasz drugi mózg nie trafiają do nikogo innego. To wymaga uwagi i zrozumienia.
Co naprawdę mówi zdanie „nie trenujemy na twoich danych”
Kiedy czytacie „nie będziemy trenować na twoich danych”, to zdanie nic nie znaczy. To regulamin, to język prawników. To sposób, żeby powiedzieć: „Czuj się bezpiecznie, dziel się wszystkim, bo nie potrzebujemy twoich surowych danych. Potrzebujemy danych przetworzonych”.
I jest mnóstwo zastrzeżeń. W chwili, gdy zostawiacie feedback, pobieramy całą rozmowę, bo musimy sprawdzić, dlaczego oceniliście ją pozytywnie albo negatywnie. W chwili, gdy uznamy, że możecie naruszać regulamin, musimy wziąć wasze dane i je sprawdzić. W chwili, gdy uznamy, że stanowicie jakieś zagrożenie albo ryzyko, musimy zatrzymać wszystkie wasze dane i je przeanalizować.
W tych regulaminach jest więc mnóstwo zapisów, które — jeśli je przeczytacie — mówią wprost, że gdy tylko zrobicie coś więcej niż „cześć, jak się masz”, prawdopodobnie sprawdzą wszystko, co powiedzieliście. Na takim jesteśmy poziomie.
Mówię to na kanale, bo nikt tego nie wie — wiedzą tylko oni, bo nie ma przejrzystości. Nie wiemy, co faktycznie robią z naszymi danymi. Musimy im po prostu zaufać.
Kiedy kupować sprzęt pod lokalne AI
Jest jeszcze kilka rzeczy, o których chcę powiedzieć, i dotyczą uruchamiania lokalnego AI. Pytanie brzmi: czy w ogóle coś kupować i kiedy jest właściwy moment?
Przede wszystkim zrozumcie, że lokalne AI nigdy nie było i prawdopodobnie nigdy nie będzie sposobem na oszczędzanie pieniędzy. Sprzęt, prąd, inwestycja — to wszystko przechodzi na waszą stronę. To dość drogie. Pójście w chmurę oznacza korzystanie z systemu, który jest optymalizowany i skalowany, więc cena zawsze będzie niższa, a działanie prawdopodobnie szybsze. Owszem, są przypadki, w których u siebie uruchomicie coś znacznie szybciej, ale to rzadkość i wymaga specjalistycznego sprzętu. Jeśli więc myślicie „kupuję lokalnie, żeby oszczędzić”, tej tezy trudno bronić.
Ale jeśli myślicie o stabilnym systemie, który nie zmienia się z dnia na dzień, bo ktoś właśnie przeprowadza optymalizację albo koryguje modele — taką stabilność uzyskacie wyłącznie na własnej maszynie.
Drugim elementem jest to, o czym mówimy dzisiaj: prywatność waszych danych i suwerenność waszego aktywa, czyli pętli, skilli i przepisów.
Hybryda, nie fanatyzm
Nie namawiam do przejścia w stu procentach na lokalne rozwiązania — po pierwsze jest to drogie, a po drugie czasem po prostu niewykonalne. Szukajcie rozwiązania hybrydowego: lokalnie tyle, ile się da, na najlepszym modelu, na jaki was stać. Dziś mamy modele, które chodzą nawet na telefonie. Każdy więc może mieć lokalne AI, choćby po to, żeby zacząć eksperymentować, zrozumieć je i znaleźć jego granice.
Krąży bowiem dużo propagandy, że jeśli nie macie najpotężniejszego modelu frontierowego, to nic nie zdziałacie. W rzeczywistości wiemy już, że modele frontierowe od Anthropic, OpenAI czy Google są w pewien sposób ograniczone — mają guardraile. Guardraile to systemy trzymające AI w wyznaczonych ramach. Jeśli zadacie konkretne pytanie, model wam nie odpowie albo zostanie zdegradowany, przez co dostaniecie mniej inteligentną odpowiedź. Jeśli zajmujecie się badaniami w biologii albo pracujecie w cyberbezpieczeństwie, modele frontierowe wam nie odpowiedzą.
Chmura nie zawsze oznacza więc „lepiej”. Owszem, to potężniejszy model. Owszem, czasem naprawdę przydatny. Czasem to jedyny sposób, żeby ruszyć do przodu — ale musimy rozumieć koszt. Prawdziwy koszt jest znacznie, znacznie większy, niż się wydaje.
(Informacja dodatkowa: autor prowadzi też społeczność na Discordzie oraz publikuje pogłębiony artykuł na Substacku, do którego odsyła w opisie filmu).
10 najważniejszych takeaways — z kontekstem zastosowania
1.Odróżnij dane od sposobu pracy
Na czym polega: Baza wiedzy i dokumenty to jedno, a metoda działania — pętle, skille, procedury — to drugie. Autor twierdzi, że to ta druga warstwa jest rzeczywistym aktywem firmy.
Jak stosować: Zrób inwentaryzację w dwóch kolumnach: „dane” i „sposób działania”. Do drugiej kolumny wpisz szablony promptów, definicje skilli, konfiguracje narzędzi i opisy powtarzalnych procesów. Dopiero na tej podstawie decyduj, co gdzie może trafić.
Na co uważać: To rozróżnienie łatwo przecenić. Sam prompt bez wiedzy dziedzinowej i bez ludzi, którzy go stosują, rzadko jest kompletną przewagą — nie traktuj każdego szablonu jak tajemnicy państwowej.
2.„Nie trenujemy na twoich danych” to węższa obietnica, niż się wydaje
Na czym polega: Zdanie o braku trenowania nie opisuje pozostałych zastosowań danych: logowania, przeglądu bezpieczeństwa, analizy nadużyć.
Jak stosować: Czytając regulamin, szukaj nie deklaracji o trenowaniu, lecz sekcji o retencji, o dostępie personelu i o wyjątkach bezpieczeństwa. To one określają realny poziom ekspozycji.
Na co uważać: Autor sam zaznacza, że mówi o mechanizmie ogólnym, a nie o konkretnym dostawcy. Nie przenoś jego opisu na wybraną firmę bez sprawdzenia jej aktualnych warunków — te się zmieniają.
3.Feedback i flagi bezpieczeństwa otwierają dostęp do rozmowy
Na czym polega: Kliknięcie kciuka w górę lub w dół, podejrzenie naruszenia regulaminu albo ocena ryzyka mogą uruchomić przegląd całej konwersacji.
Jak stosować: Wprowadź prostą zasadę w zespole: nie oceniamy odpowiedzi w rozmowach zawierających dane wrażliwe. To zerokosztowa zmiana nawyku.
Na co uważać: Nie wyciągaj z tego wniosku, że ktoś czyta wszystko na bieżąco — to mechanizmy warunkowe, uruchamiane zdarzeniem.
4.Przejrzystość regulaminu to nie to samo co bezpieczeństwo
Na czym polega: Google jest w materiale wskazany jako firma pisząca warunki wyraźniej, ale wyraźniej znaczy tylko: wiesz więcej, a nie: jesteś bezpieczniejszy.
Jak stosować: Oceniaj dostawców po tym, co faktycznie robią z danymi, a nie po czytelności dokumentu. Czytelny regulamin ułatwia decyzję, ale jej nie zastępuje.
Na co uważać: Wypisanie się z trenowania bywa okupione utratą funkcji — sprawdź, czy to, co wyłączasz, nie jest właśnie tym, po co sięgnąłeś po narzędzie.
5.Lokalne AI nie jest bezpieczne z definicji
Na czym polega: Bezpieczeństwo zależy od konfiguracji, wtyczek i wywoływanych narzędzi. Lokalny model wywołujący zdalne narzędzie wysyła dane na zewnątrz.
Jak stosować: Zrób audyt każdego narzędzia i konektora podpiętego do lokalnego setupu: co wychodzi poza maszynę i dokąd. Domyślnie odcinaj, potem selektywnie dopuszczaj.
Na co uważać: Największe wycieki w takim układzie są niewidoczne w interfejsie — dzieją się w warstwie narzędzi, nie w oknie czatu.
6.Uzasadnieniem lokalnego AI jest stabilność, nie cena
Na czym polega: Sprzęt i prąd przenoszą koszt na twoją stronę, a chmura jest zoptymalizowana i skalowana, więc tańsza i zwykle szybsza.
Jak stosować: Jeśli budujesz biznes case, opieraj go na stabilności, suwerenności i zgodności z regulacjami. Argument oszczędnościowy nie obroni się przed działem finansowym.
Na co uważać: Wyjątki od tej reguły istnieją, ale — jak zaznacza autor — są rzadkie i wymagają wyspecjalizowanego sprzętu. Nie planuj wokół wyjątku.
7.Stabilność wersji modelu to realna przewaga operacyjna
Na czym polega: Modele w chmurze bywają korygowane i optymalizowane bez twojej wiedzy. Model na twojej maszynie zachowuje się jutro tak samo jak dziś.
Jak stosować: Trzymaj lokalnie te procesy, w których liczy się powtarzalność wyniku — walidacje, klasyfikacje, procesy audytowalne.
Na co uważać: Zamrożona wersja to również brak poprawek. Zaplanuj świadomy cykl aktualizacji, zamiast trwać na jednej wersji w nieskończoność.
8.Hybryda zamiast doktryny „wszystko lokalnie”
Na czym polega: Rekomendacja autora brzmi: lokalnie tyle, ile się da, na najlepszym modelu, na jaki cię stać; chmura tam, gdzie inaczej się nie da.
Jak stosować: Podziel zadania na trzy koszyki: wyłącznie lokalne (dane klientów, opisy procesów), dowolne (praca na tekstach publicznych) i chmurowe (zadania wymagające maksymalnej zdolności modelu).
Na co uważać: Granica koszyków rozmywa się w praktyce — najczęściej przez wklejanie fragmentów wrażliwych danych do „niewinnej” rozmowy w chmurze.
9.Zacznij eksperymentować nawet na małym modelu
Na czym polega: Modele działają dziś nawet na telefonie, więc próg wejścia do lokalnego AI jest praktycznie zerowy.
Jak stosować: Uruchom mały model lokalnie i celowo szukaj jego granic na własnych zadaniach. Zdobędziesz dane do decyzji o zakupie sprzętu, zamiast zgadywać.
Na co uważać: Nie generalizuj wyników małego modelu na całą kategorię — sprawdzasz, co jest wystarczające dla twoich zadań, a nie ile warte jest lokalne AI w ogóle.
10.Guardraile jako argument techniczny, nie tylko ideologiczny
Na czym polega: Autor wskazuje, że modele frontierowe odmawiają lub udzielają słabszych odpowiedzi w niektórych dziedzinach, wymieniając biologię i cyberbezpieczeństwo.
Jak stosować: Jeśli pracujesz w takiej dziedzinie, przetestuj swoje realne zapytania na obu ścieżkach, zanim zbudujesz proces wokół jednej z nich.
Na co uważać: To najbardziej dyskusyjna teza materiału — teza o „degradacji modelu” to obserwacja autora, nie potwierdzony mechanizm. Model bez guardraili nie jest też automatycznie lepszy merytorycznie; bywa jedynie mniej powściągliwy.