Asystent AI do SQL domyślnie tylko do odczytu

Asystent AI, który pisze za Ciebie SQL, jest przydatny. Asystent AI, który ten SQL wykonuje na Twojej bazie bez pytania, to wypadek, który czeka, żeby się wydarzyć. Różnica między jednym a drugim to decyzja projektowa — i warto podjąć ją świadomie.

Ten artykuł jest właśnie o tej decyzji: dlaczego asystent AI do SQL powinien być domyślnie tylko do odczytu, dlaczego zapisy powinny wymagać jawnego potwierdzenia przez człowieka i jakie informacje powinny — a jakie nigdy nie powinny — opuszczać Twoją bazę i trafiać do modelu językowego.

Ujawnienie: pracuję przy SQL Sage, którego użyję dalej jako konkretnego przykładu. Zasady poniżej obowiązują niezależnie od tego, jakiego narzędzia używasz.

Dlaczego asystent AI do SQL powinien być domyślnie tylko do odczytu?

Bo koszt błędu jest niesymetryczny. Źle wygenerowany SELECT zwróci złe wiersze — irytujące, ale nieszkodliwe i odwracalne: patrzysz na wynik, widzisz, że się nie zgadza, i pytasz jeszcze raz. Źle wygenerowany UPDATE albo DELETE zmienia lub niszczy dane. Na systemie produkcyjnym może to być nieodwracalne bez odtworzenia z kopii.

Modele językowe są probabilistyczne. Są bardzo dobre w produkowaniu wiarygodnie wyglądającego SQL — a wiarygodny to nie to samo co poprawny. Zapytanie może być składniowo poprawne, wykonać się bez błędu i nadal znaczyć coś innego niż to, o co prosiłeś: złączenie, które zwielokrotnia wiersze, WHERE z pominiętym warunkiem, UPDATE bez filtra, który wydawał Ci się oczywisty. Kiedy jedyną rzeczą między wygenerowaną instrukcją a Twoimi danymi jest „model był pewny”, nie masz żadnego marginesu bezpieczeństwa.

Tryb read-only domyślnie zmienia domyślne zachowanie z działaj na zaproponuj. Asystent może swobodnie czytać — schemat, wyniki zapytań, plany wykonania — i wygenerować dowolną instrukcję, o jaką poprosisz. Ale instrukcja, która zmienia dane lub strukturę, nie wykonuje się w momencie wygenerowania. Czeka.

Czym różni się odczyt od zapisu i dlaczego granicę stawiać właśnie tam?

Granica przebiega między instrukcjami, które obserwują, a tymi, które modyfikują.

SELECT obserwuje. Może być wolny albo kosztowny, ale nie zmienia stanu bazy. (Przypadki brzegowe istnieją — SELECT wywołujący funkcję z efektami ubocznymi — ale jako kategoria odczyty są bezpieczne do uruchomienia.)

INSERT, UPDATE, DELETE, MERGE (DML) zmieniają dane. CREATE, ALTER, DROP, TRUNCATE (DDL) zmieniają strukturę, a część z nich jest katastrofalna i szybka: DROP TABLE i TRUNCATE nie pytają drugi raz i nie zapełniają loga transakcji, z którego dałoby się bezboleśnie wrócić.

Postawienie granicy bezpieczeństwa dokładnie na linii odczyt–zapis jest czyste, bo odwzorowuje coś, co sama baza już rozumie. Nie prosisz AI, żeby oceniła, czy instrukcja jest niebezpieczna — klasyfikujesz po typie instrukcji, a to jest deterministyczne. SELECT się wykonuje. Cała reszta zatrzymuje się i pyta.

Co „jawne potwierdzenie” oznacza w praktyce?

Oznacza, że człowiek widzi dokładną instrukcję, w całości, zanim się wykona — i wykonuje świadomy gest, żeby ją zatwierdzić. Nie checkbox schowany w ustawieniach, który odhaczyłeś raz i zapomniałeś. Bramka na każdą instrukcję z osobna.

Dobre potwierdzenie ma kilka cech:

Instrukcja jest pokazana dosłownie. Zatwierdzasz to, co się wykona, a nie streszczenie.
Domyślną odpowiedzią jest „nie”. Zamknięcie okna albo Escape nie może niczego wykonać.
Odczyty go nie wywołują. Jeśli każdy SELECT będzie Cię nagabywał, nauczysz się klikać „dalej” na wszystkim — łącznie z DELETE. Zmęczenie potwierdzeniami to realny tryb awarii; bramka musi być na tyle rzadka, żeby pozostała znacząca.

Istnieje mocniejszy wariant tego mechanizmu — na poziomie połączenia. Niektóre silniki baz pozwalają otworzyć sesję, która jest fizycznie tylko do odczytu — serwer sam odrzuca zapisy. Gdy to dostępne, jest lepsze niż kontrola na poziomie aplikacji, bo trzyma nawet wtedy, gdy aplikacja ma błąd. W SQL Sage for DBeaver na przykład tryb read-only jest wymuszany przez silnik na PostgreSQL, MySQL i MariaDB: zapis odrzuca baza, nie tylko interfejs. Na pozostałych silnikach i w dodatku do SSMS model pozostaje domyślnie tylko do odczytu, a DML/DDL wymaga Twojego potwierdzenia przed wykonaniem.

Czy używanie asystenta AI na produkcyjnej bazie jest bezpieczne?

Może być — jeśli spełnione są dwa warunki: zapisy nie mogą się wydarzyć bez Ciebie, a same dane nie są wysyłane do modelu.

Pierwszy warunek już omówiliśmy. Drugi to miejsce, w którym wiele narzędzi „AI dla Twojej bazy” jest mętnych — i to pytanie powinieneś zadać najmocniej.

Żeby napisać poprawny SQL, model musi znać kształt Twojej bazy: nazwy tabel, nazwy kolumn, typy, relacje, może kilka ograniczeń. To jest schemat — a czytanie go z żywej bazy zamiast zgadywania to osobny, równie ważny warunek poprawności. Schemat plus tekst SQL, nad którym pracujesz, w zupełności wystarczy, żeby model był naprawdę przydatny — żeby podpowiadał, tłumaczył zapytanie, sugerował złączenie, znajdował błąd w GROUP BY.

Model nie potrzebuje do tego zawartości Twoich wierszy. Adresy e-mail Twoich klientów, kwoty transakcji, dane osobowe użytkowników — nic z tego nie jest potrzebne do wygenerowania zapytania. Dlatego domyślnie nic z tego nie powinno opuszczać bazy. Schemat i tekst SQL: tak. Dane z wierszy: nie.

Jeśli kiedykolwiek zechcesz, żeby model zobaczył przykładowe wiersze — powiedzmy, żeby pomóc przy nieuporządkowanych danych — powinna to być jawna, świadoma zgoda na daną sesję, z pełną świadomością, że te wiersze trafiają teraz do zewnętrznego modelu. Nigdy nie powinno to być cichym domyślnym zachowaniem.

Co powinno, a co nie powinno trafiać do modelu?

Krótka, sprawdzalna lista:

Trafia do modelu (potrzebne, żeby pomóc):

Schemat: nazwy tabel i kolumn, typy danych, klucze i relacje
Tekst SQL, który piszesz lub o który pytasz
Struktura zapytania i komunikaty błędów, którymi sam zdecydujesz się podzielić

Nie trafia do modelu (niepotrzebne i wrażliwe):

Faktyczne wiersze zwracane przez Twoje zapytania
Jakiekolwiek dane osobowe, finansowe lub regulowane przechowywane w tych wierszach
Poświadczenia i sekrety połączenia

Jest też pytanie, czyj to model. Narzędzie AI do SQL, które przepuszcza Twój schemat przez własny backend, to kolejna strona w łańcuchu. Projekt bezkluczowy (keyless) — w którym narzędzie rozmawia bezpośrednio z Twoim własnym kontem AI (Twoim Claude albo ChatGPT), zamiast pośredniczyć przez dostawcę — trzyma dostawcę całkowicie poza ścieżką danych. SQL Sage działa właśnie tak: używa Twojego własnego konta, więc nie ma pośrednika trzymającego Twój schemat.

Wniosek

Model bezpieczeństwa AI przy bazie nie jest skomplikowany i nie polega na większym zaufaniu do modelu. Polega na domyślnych ustawieniach:

Domyślnie tylko do odczytu. Odczyty się wykonują; zapisy czekają.
Jawne potwierdzenie każdej instrukcji, która modyfikuje — najlepiej wymuszane przez silnik tam, gdzie baza to wspiera.
Schemat i SQL idą do modelu; wiersze nie — a wysłanie wierszy to świadoma zgoda, nie domyślne zachowanie.

Asystent AI, który trzyma się tych trzech zasad, może stać przy produkcyjnej bazie i być naprawdę pomocny, nie będąc nigdy w stanie po cichu jej uszkodzić ani wynieść z niej danych. Taki, który się ich nie trzyma, prosi Cię o zaufanie probabilistycznemu systemowi w kwestii nieodwracalnych działań — a tego zaufania nie powinieneś musieć udzielać.