Azure SQL: asystent AI w SSMS bez klucza API

Większość rozmów o „AI dla SQL Servera” po cichu zakłada pudełkowy SQL Server stojący na maszynie, którą kontrolujesz. Sporo realnej pracy już tam nie mieszka. Mieszka w Azure SQL Database albo Azure SQL Managed Instance — z dostępem przez tożsamość zarządzaną, logowaniem kontem służbowym i regułami, których instancja on-prem nigdy nie miała. Asystent AI, który rozumie tylko przypadek on-prem, to asystent, którego nie użyjesz tam, gdzie faktycznie jest połowa Twoich baz.

SQL Sage dla SSMS to pair-DBA, który mieszka wewnątrz SQL Server Management Studio 22, i jest zbudowany tak, by na Azure SQL działać tak samo jak na pudełku — na Twoim własnym koncie AI, bez drugiego rachunku i bez nowego sekretu do pilnowania. Ten wpis jest o tym, co to znaczy w praktyce, i uczciwie powiemy, gdzie przebiega granica darmowego. Jeśli dopiero wybierasz narzędzie, ogólny przegląd asystentów AI do SSMS i kompromisów do sprawdzenia jest osobno — tu zostajemy przy Azure SQL.

Ujawnienie: ten blog publikuje LumaSoft (LUMA sp. z o.o.), a ja pracuję nad opisanym tu narzędziem.

Świadomy edycji: wie, z którym SQL Serverem rozmawia

SQL Server to nie jeden cel. Instancja pudełkowa, Azure SQL Database i Azure SQL Managed Instance różnią się tym, co udostępniają — najwyraźniej w tym, które DMV na poziomie serwera w ogóle istnieją. Narzędzie, które wszędzie zakłada powierzchnię on-prem, albo wysypie się na Azure, albo — gorzej — po cichu zaraportuje bzdury.

SQL Sage jest świadomy edycji (edition-aware). Rozpoznaje, czy jest podłączony do pudełkowego SQL Servera, Azure SQL Database czy Azure SQL Managed Instance, i degraduje się łagodnie tam, gdzie funkcja naprawdę nie istnieje — na przykład tam, gdzie zależy ona od DMV na poziomie serwera, którego Azure SQL Database nie oferuje. Nie dostajesz pewnej siebie odpowiedzi zbudowanej na danych, których nigdy nie było. Dostajesz możliwość, którą edycja faktycznie wspiera, i prosty rachunek z reszty.

Łączy się tak, jak już robi to Twoje okno zapytania

Na Azure to, jak się uwierzytelniasz, nie jest dodatkiem po fakcie — to cała bramka. SQL Sage łączy się tak, jak łączy się Twoje okno zapytania: SQL login, Microsoft Entra Password albo Service Principal. Czymkolwiek wchodzisz do bazy w SSMS, tego używa SQL Sage — więc Managed Instance, do którego sięgasz przez Entra, to Managed Instance, który SQL Sage potrafi odczytać.

Z tymi poświadczeniami obchodzi się ostrożnie. SQL Sage podpisuje własne sesje poświadczeniami Twojego okna zapytania, trzymanymi tylko w pamięci — nigdy w connection stringu ani w logu. Gdy odczyt schematu się nie uda, mówi dlaczego, zamiast zostawiać Cię ze zgadywaniem, a gdy serwer odrzuci zapytanie, pokazuje prawdziwy błąd z serwera, a nie wymyśloną teorię o Twoim logowaniu. Na bazie w chmurze, gdzie faktyczną przyczyną bywa granica uprawnień albo reguła firewalla, ta uczciwość to różnica między naprawą w minutę a godziną ludowych podań.

Na Twoim własnym koncie AI — bez klucza API, bez drugiego rachunku za tokeny

Część, która zaskakuje: po środku nie ma żadnego klucza LUMA, a klucza API nie trzeba w ogóle tworzyć. SQL Sage uruchamia asystenta na Twoim własnym koncie AI — Claude przez Claude Code CLI albo ChatGPT / OpenAI Codex przez Codex CLI. Gdy logujesz się przez Claude Code lub Codex, klucz API nie jest potrzebny (klucz Anthropic opcjonalnie, jeśli wolisz), nie ma naliczania per-token od LUMA, a zużycie AI idzie z Twojego własnego planu.

To ten sam bezkluczowy projekt, o którym pisaliśmy szczegółowo tutaj: jeden sekret mniej do przechowywania, rotowania i wycieku, i żadnej mierzonej faktury API doklejonej do subskrypcji, którą i tak już płacisz. Na Azure, gdzie kontrola kosztów to już dyscyplina, trzymanie wydatku na AI w koncie, które kontrolujesz, zamiast przepuszczania go przez dostawcę, to jedna rzecz mniej do uzgadniania.

Bezpieczny domyślnie — SELECT się wykonuje, zapisy czekają

Asystent, który może dotknąć produkcyjnej bazy na Azure, musi być bezpieczny, zanim będzie sprytny. SQL Sage jest bezpieczny domyślnie, co egzekwuje bramka ScriptDom, parsująca SQL, zanim cokolwiek się z nim stanie:

SELECT wykonuje się sam. Odczyt to szybka ścieżka.
DML i DDL zatrzymują się do jawnego potwierdzenia, z dokładnym SQL przed oczami, zanim się wykona. Zatwierdzasz instrukcję, którą możesz przeczytać, a nie jej streszczenie.
Zapytania sięgające poza bieżącą bazę — linked servers, OPENQUERY, OPENROWSET/BULK, OPENDATASOURCE — zawsze zatrzymują się do potwierdzenia, bo przekraczają granicę, którą powinieneś przekroczyć świadomie.
Run wykonuje tylko w nowym oknie zapytania i tylko po sprawdzeniu, że SQL, serwer i baza się zgadzają — więc instrukcja nigdy nie wystrzeli przypadkiem na złym połączeniu.
Czyta Twój schemat i DMV, prowadzi log audytu i nigdy nie wysyła wyników zapytań do modelu bez jawnej zgody per-sesja. Wyniki udostępnione jednemu dostawcy nie są wysyłane do innego po przełączeniu.

Tryb domyślny to Agent: AI może uruchamiać zapytania tylko do odczytu i własne narzędzia SQL Sage, a każdy zapis zawsze najpierw pyta. Jeśli chcesz jeszcze ostrzej, tryb Ask odpowiada wyłącznie z dołączonego zapytania i czatu — nie uruchamia nic. (Zasada „tylko do odczytu domyślnie” to miara, którą oceniamy każde narzędzie AI do SQL, w tym nasze.)

Mask names: Twoje identyfikatory nigdy nie jadą otwartym tekstem

Ugruntowanie AI w Twoim prawdziwym schemacie to to, co czyni ją trafną — a to, co w tym celu wysyłasz, zasługuje na uwagę, o czym piszemy w co AI naprawdę widzi. SQL Sage dokłada drugą warstwę na granicy „schemat, nie wiersze”: Mask names. Zamienia nazwy serwerów, baz, loginów, hostów i plików na stabilne zastępniki — <database2>, <login1> i tak dalej — we wszystkim, co trafia do AI: w wynikach narzędzi, w rozmowie i w Twoim systemowym prompcie. Zastępniki są spójne przez cały czat, więc model wciąż może rozumować o relacjach, nigdy nie dowiadując się, że <database2> to Twoja produkcyjna baza rozliczeń. Od 0.35.1 maskowane są też podpowiedzi inline: podpowiedź dostaje prawdziwe nazwy z powrotem na Twoim komputerze, a gdy SQL Sage nie może odczytać nazw z serwera, nie wysyła nic.

Jedno uczciwe zastrzeżenie: nazwy tabel i kolumn nie są maskowane. To zwykle struktura, której model potrzebuje, by pomóc, i jest to znacznie mniejsza powierzchnia niż nazwy serwerów i loginów — ale warto wiedzieć, gdzie przebiega granica. Twoja historia czatu jest z kolei szyfrowana na dysku (DPAPI), z retencją, którą ustawiasz, albo możesz wyłączyć zapis całkowicie.

Uczciwa część: co jest darmowe, a co wymaga licencji

Nie będziemy udawać, że AI jest darmowe na zawsze. SQL Sage ma 30-dniowy trial — wszystkie funkcje, bez karty — a zegar startuje od pierwszej odpowiedzi AI albo 14 dni po pierwszym otwarciu panelu, co nastąpi pierwsze.

Po trialu działa dalej jako SQL Sage Free: narzędzia edytora zostają, zero AI. Funkcje AI oraz warstwa Proven & Accountable wymagają licencji — kup raz od $39 albo subskrybuj od $29/rok. (Pełny cennik jest na stronie; sprawdź go tam, a nie ufaj liczbie z wpisu na blogu.)

Wnioski

Asystent AI dla SQL Servera jest przydatny tylko tam, gdzie faktycznie są Twoje bazy — a coraz częściej jest to Azure. SQL Sage dla SSMS jest świadomy edycji w pudełkowym SQL Serverze, Azure SQL Database i Azure SQL Managed Instance; łączy się tak, jak Twoje okno zapytania — SQL login, Entra albo Service Principal; działa na Twoim własnym koncie Claude lub ChatGPT, bez klucza API i bez rachunku za tokeny od nas; jest bezpieczny domyślnie, więc odczyty są szybkie, a zapisy czekają na Ciebie; a Mask names trzyma Twoje identyfikatory poza zasięgiem modelu. Zobacz go na stronie produktu SQL Sage dla SSMS.

SQL Sage tworzy LumaSoft (LUMA sp. z o.o.). Nie jest związany z Microsoftem, Anthropic ani OpenAI.