AI Connector w Datasentinel 2026.10: co naprawdę widzi zewnętrzny LLM, gdy pytasz o wolną bazę PostgreSQL

Datasentinel 2026.10, komercyjna platforma do monitoringu i troubleshootingu PostgreSQL, wprowadza dodatek AI Connector. Producent ogłosił wydanie 15 listopada 2026 na liście newsów postgresql.org. Rozwiązanie opiera się na serwerze MCP oraz mechanizmie Skill i pozwala zadawać pytania w języku naturalnym asystentom takim jak Claude, ChatGPT, Gemini, Microsoft Copilot czy GitHub Copilot — model wybiera użytkownik. AI Connector jest opcją licencyjną, nie częścią podstawowego pakietu.

Sprawa dotyczy każdego zespołu utrzymującego PostgreSQL, który rozważa włączenie dodatku do monitoringu. Istota problemu nie leży w samym asystencie, lecz w granicy zaufania: producent deklaruje, że asystent nigdy nie łączy się z bazą, ale jednocześnie wprost przyznaje, że metryki, tekst SQL, plany wykonania i nazwy obiektów trafiają do asystenta oraz do wybranego modelu językowego. To oznacza, że dane diagnostyczne — często wystarczająco szczegółowe, by odtworzyć strukturę systemu — opuszczają infrastrukturę klienta. Dla organizacji objętych RODO, NIS2 lub wewnętrznymi reżimami bezpieczeństwa to pytanie o zgodę, retencję i odpowiedzialność, a nie o wygodę interfejsu.

Co dokładnie ogłoszono

Wydanie 2026.10 to nowa wersja platformy Datasentinel. Poza AI Connector producent wymienia zmiany w raportach PDF (bardziej kompaktowy układ, profil obciążenia, top wait events, scenariusze blokad, zebrane parametry, więcej szczegółów tabel i indeksów, mniejsze zużycie pamięci i szybsze generowanie na dużych flotach), nową opcjonalną funkcję datasentinel_analytics dającą read-only dostęp do statystyk planisty i planów wykonania (wymaga Agent v4.0.0 lub nowszego), automatyczne czyszczenie nieaktywnych instancji, wspólne filtry monitoringu zapytań dla instancji agentless oraz aktualizację zależności zewnętrznych w celu usunięcia znanych podatności.

Dostępny jest publiczny sandbox ze współdzielonym kontem read-only oraz okres próbny na własnych instancjach. To ważne z punktu widzenia weryfikacji: sandbox pozwala obejrzeć interfejs i sposób formułowania odpowiedzi, ale nie odpowiada na pytania o politykę retencji po stronie dostawcy modelu ani o to, jak dokładnie wygląda przepływ danych w środowisku produkcyjnym.

Deklaracje producenta a niezależne obserwacje

Materiał dowodowy to oficjalny wpis producenta. Nie zawiera niezależnych testów, audytu ani wyników pomiarów. Wszystko, co dotyczy modelu bezpieczeństwa, uprawnień i zakresu danych, jest deklaracją dostawcy. W tej analizie oddzielamy ją od tego, co da się wywnioskować z architektury opisanej we wpisie. Nie przypisujemy produktowi właściwości, których producent nie potwierdza, i nie zakładamy, że deklaracje są nieprawdziwe — przyjmujemy, że są niezweryfikowane.

Tło techniczne prostym językiem

Datasentinel zbiera dane o pracy serwera PostgreSQL: metryki wydajności, informacje o zapytaniach, blokadach, sesjach, planach wykonania. Te dane trafiają do bazy metryk platformy. AI Connector udostępnia je asystentowi przez serwer MCP — protokół, który pozwala modelowi wywoływać zdefiniowane wcześniej narzędzia i pobierać dane w ustrukturyzowanej formie. Drugi element, Skill, to zestaw instrukcji, który podpowiada asystentowi, jak prowadzić analizę: od czego zacząć, jakie wnioski wyciągać, w jakiej kolejności porządkować wyniki.

Użytkownik zadaje pytanie w języku naturalnym, np. „dlaczego baza orders była wolna dziś o 9:00?”. Asystent za pośrednictwem MCP pobiera z platformy odpowiednie metryki i plan zapytania, analizuje je zgodnie ze Skill i formułuje odpowiedź z uzasadnieniem oraz rekomendacją. Odpowiedź może być dostosowana do odbiorcy — techniczna dla eksperta, prostsza dla mniej wtajemniczonego czytelnika, w języku użytkownika.

Kluczowe rozróżnienie: asystent nie wykonuje zapytań na bazie produkcyjnej. Sprawdzenia „na żywo” przechodzą przez agenta Datasentinel i są read-only. Plany wykonania są szacowane bez uruchamiania zapytania. To ogranicza ryzyko przypadkowego obciążenia bazy, ale nie zmienia faktu, że dane o bazie — w tym tekst SQL i nazwy obiektów — są przekazywane dalej.

Gdzie leży granica zaufania

Granica zaufania przebiega między infrastrukturą klienta a dostawcą modelu językowego. Producent kontroluje platformę, agenta i serwer MCP. Nie kontroluje tego, co wybrany model robi z otrzymanymi danymi: czy są przechowywane, jak długo, czy są wykorzystywane do trenowania, w jakiej jurysdykcji są przetwarzane. To zależy od warunków konkretnego dostawcy modelu, a nie od Datasentinel. Wybór modelu jest po stronie użytkownika — i to on ponosi konsekwencje tego wyboru.

Jakie dane opuszczają infrastrukturę

Producent wymienia cztery kategorie: metryki, tekst SQL, plany wykonania i nazwy obiektów. To zestaw, który w praktyce pozwala odtworzyć znaczną część obrazu systemu.

Kategoria danych	Co może ujawniać	Poziom wrażliwości
Metryki wydajności	Rozmiar i charakter obciążenia, godziny szczytu, liczbę połączeń, wzorce dostępu	Średni — pozwala profilować działalność
Tekst SQL	Strukturę zapytań, nazwy tabel i kolumn, czasem wartości w warunkach WHERE	Wysoki — może ujawniać model danych i dane osobowe
Plany wykonania	Indeksy, strategię dostępu, szacowaną liczbę wierszy, koszty	Wysoki — ujawnia architekturę i skalę
Nazwy obiektów	Nazwy baz, schematów, tabel, kolumn, funkcji	Wysoki — sama nomenklatura bywa informacją biznesową

Największe ryzyko wiąże się z tekstem SQL. Zapytania często zawierają wartości literalne w klauzulach WHERE — identyfikatory, adresy e-mail, numery zamówień. To, czy takie wartości trafiają do modelu, zależy od tego, jak platforma przygotowuje dane do wysyłki. Materiał dowodowy tego nie precyzuje. Producent nie deklaruje, że tekst SQL jest anonimizowany, maskowany ani normalizowany przed przekazaniem. Brak takiej deklaracji należy traktować jako brak gwarancji, nie jako potwierdzenie, że dane są wysyłane w postaci surowej.

Model uprawnień: co deklaruje producent

Producent opisuje model bezpieczeństwa w pięciu punktach. Logowanie odbywa się na stronie Datasentinel przez OAuth 2.1; asystent otrzymuje token, nigdy hasło ani dane logowania do bazy. Uprawnienia użytkownika w asystencie odpowiadają uprawnieniom w interfejsie web — użytkownik widzi tylko te instancje, na które pozwala jego rola. Analiza live wymaga dedykowanego przywileju. Asystent nie łączy się bezpośrednio z bazą; sprawdzenia live są read-only i przechodzą przez agenta, a plany są szacowane bez uruchamiania zapytania. Skrypty i zadania cykliczne używają tokenów dostępowych, które można w każdej chwili unieważnić; logowania i zdarzenia tokenów są rejestrowane.

To spójny model na poziomie deklaracji. Warto jednak zauważyć, czego nie rozstrzyga. Po pierwsze, OAuth 2.1 chroni dostęp do platformy, ale nie reguluje przepływu danych z platformy do modelu — token jest ważny dla MCP, a nie dla dostawcy LLM. Po drugie, „te same prawa co w interfejsie web” oznacza, że każda osoba z dostępem do szerokiego zakresu instancji może przez asystenta uzyskać równie szeroki wgląd w dane diagnostyczne, tylko w innej formie. Po trzecie, dedykowany przywilej dla analizy live ogranicza krąg osób, ale nie ogranicza zakresu danych wysyłanych do modelu przez osoby, które ten przywilej mają.

Tokeny i audyt — co realnie dają

Możliwość unieważnienia tokenu w dowolnym momencie to dobra praktyka, szczególnie dla skryptów i zadań cyklicznych. Rejestrowanie logowań i zdarzeń tokenów daje podstawę do wykrywania nietypowej aktywności. Nie zastępuje jednak audytu tego, jakie konkretnie dane zostały wysłane do modelu i co dostawca modelu z nimi zrobił. Materiał dowodowy nie mówi, czy platforma rejestruje treść zapytań kierowanych do LLM ani czy udostępnia taki log klientowi.

Realne konsekwencje dla organizacji

Włączenie AI Connectora zmienia charakter przetwarzania danych. Dotychczas monitoring pozostawał w infrastrukturze klienta lub u dostawcy platformy w ramach umowy powierzenia. Po włączeniu dodatku do procesu wchodzi trzeci podmiot — dostawca modelu językowego — którego warunki mogą być inne niż warunki Datasentinel. To wymaga przeglądu umów, oceny skutków dla ochrony danych i ustalenia, kto odpowiada za wybór modelu.

Drugi skutek dotyczy bezpieczeństwa informacji. Nazwy obiektów i tekst SQL ujawniają strukturę systemu. Dla osoby atakującej to materiał wywiadowczy: pozwala poznać nazwy tabel, zależności między nimi, indeksy i wzorce dostępu. Nie jest to bezpośredni wektor ataku, ale informacja, która obniża koszt rozpoznania. W środowiskach o podwyższonym ryzyku należy to uwzględnić w ocenie zagrożeń.

Trzeci skutek jest organizacyjny. Asystent odpowiada w języku naturalnym, z rekomendacjami. Rekomendacja dotycząca indeksu czy konfiguracji może zostać wykonana bez pełnej weryfikacji, bo brzmi przekonująco i ma uzasadnienie. To ryzyko operacyjne: model może zaproponować zmianę, która w danym kontekście jest nieoptymalna lub wręcz szkodliwa. Producent deklaruje, że odpowiedzi zawierają dowody i konkretny następny krok, ale nie deklaruje, że rekomendacje są walidowane przed przedstawieniem.

Scenariusze ryzyka

Scenariusz 1: wyciek struktury przez nazwy i SQL

Zespół włącza dodatek, by przyspieszyć diagnozę. Analitycy zadają pytania o konkretne zapytania. Tekst SQL z wartościami w klauzulach WHERE trafia do modelu. Jeśli dostawca modelu przechowuje zapytania lub wykorzystuje je do doskonalenia usług, dane mogą pozostać poza kontrolą organizacji. Prawdopodobieństwo zależy od wybranego dostawcy i konfiguracji; skutek — od charakteru danych w zapytaniach.

Scenariusz 2: nadmierny zakres uprawnień

Użytkownik ma w interfejsie web szeroki dostęp do wielu instancji. Po włączeniu dodatku ten sam zakres przenosi się na asystenta. Osoba, która wcześniej rzadko korzystała z platformy, może teraz jednym pytaniem uzyskać przekrojowy obraz floty. To nie eskalacja uprawnień w sensie technicznym — to eskalacja wygody, która zwiększa prawdopodobieństwo nieuprawnionego ujawnienia.

Scenariusz 3: przejęty token

Token dla skryptu lub zadania cyklicznego wycieka. Producent deklaruje możliwość unieważnienia w każdej chwili i rejestrowanie zdarzeń tokenów. To ogranicza okno ekspozycji, ale nie eliminuje go. Kluczowe jest, jak szybko organizacja wykryje nietypowe użycie i czy log zdarzeń tokenów jest monitorowany.

Scenariusz 4: błędna rekomendacja

Asystent sugeruje dodanie indeksu lub zmianę parametru. Rekomendacja opiera się na metrykach, ale nie uwzględnia kontekstu, którego nie ma w danych — np. nadchodzącego wdrożenia albo ograniczeń sprzętowych. Wdrożenie bez weryfikacji może pogorszyć wydajność. To ryzyko typowe dla każdego asystenta analitycznego, ale w monitoringu produkcyjnym ma bezpośrednie przełożenie na dostępność.

Jak sprawdzić, czy problem dotyczy Twojej organizacji

1. Ustal, czy platforma Datasentinel jest w użyciu i czy AI Connector jest włączony jako opcja licencyjna. Dodatek nie działa domyślnie — wymaga świadomej decyzji.
2. Sprawdź, jakie instancje są monitorowane i jakie dane o zapytaniach są zbierane. Jeśli w bazie metryk znajdują się teksty SQL z danymi osobowymi, ryzyko jest wyższe.
3. Ustal, kto ma dostęp do platformy i jakie role posiada. Porównaj to z listą osób, które powinny widzieć dane diagnostyczne.
4. Sprawdź, czy w organizacji istnieje polityka dotycząca wysyłania danych do zewnętrznych modeli językowych. Jeśli nie, jej brak jest sam w sobie problemem.
5. Zweryfikuj umowy z dostawcami modeli, które mają być używane. Sprawdź warunki retencji, wykorzystania danych do trenowania i jurysdykcji.
6. Ustal, kto odpowiada za wybór modelu. Jeśli decyzja należy do zespołu technicznego bez konsultacji z działem prawnym lub bezpieczeństwa, zakres odpowiedzialności jest niejasny.

Plan reakcji krok po kroku

1. Inwentaryzacja. Zbierz listę instancji, rodzajów zbieranych danych i osób z dostępem. Uwzględnij skrypty i zadania cykliczne korzystające z tokenów.
2. Klasyfikacja danych. Oceń, czy tekst SQL i nazwy obiektów mogą zawierać dane wrażliwe. Jeśli tak, rozważ ograniczenie zbierania tekstu zapytań lub normalizację przed wysyłką — o ile platforma to umożliwia.
3. Wybór modelu. Ustal, który dostawca modelu spełnia wymagania organizacji w zakresie retencji i przetwarzania. Udokumentuj decyzję i kryteria.
4. Ograniczenie uprawnień. Nadaj dedykowany przywilej analizy live tylko osobom, które realnie go potrzebują. Ogranicz role w interfejsie web do minimum.
5. Tokeny. Dla skryptów i zadań cyklicznych ustal okres ważności tokenów, procedurę rotacji i sposób monitorowania zdarzeń tokenów.
6. Próbny okres. Uruchom dodatek na wybranej instancji nieprodukcyjnej lub w sandboxie. Oceń, jakie dane są wysyłane i jak wyglądają odpowiedzi.
7. Przegląd prawny. Zweryfikuj umowy i podstawy przetwarzania. Uwzględnij dostawcę platformy i dostawcę modelu jako odrębne podmioty.
8. Komunikacja. Poinformuj zespół o zasadach korzystania z asystenta: jakie pytania są dozwolone, jakie dane można w nich umieszczać, jak weryfikować rekomendacje.
9. Monitoring. Ustal, kto i jak często przegląda logi logowań i zdarzeń tokenów. Zdefiniuj progi alarmowe.
10. Decyzja o zakresie. Rozważ włączenie dodatku tylko dla wybranych instancji lub zespołów, zamiast globalnie.

Typowe błędy

• Traktowanie deklaracji producenta jako audytu. Wpis na stronie to materiał marketingowy. Nie zastępuje testu ani oceny skutków dla ochrony danych.
• Założenie, że „asystent nie łączy się z bazą” oznacza brak przepływu danych. Dane trafiają do modelu przez MCP — to inna droga, ale ten sam skutek.
• Pomijanie skryptów i zadań cyklicznych. Tokeny dla automatyzacji są często zapominane w inwentaryzacji, a to one mają najdłuższy okres ważności.
• Brak właściciela decyzji o modelu. Wybór dostawcy LLM bywa pozostawiony zespołowi technicznemu bez konsultacji prawnej.
• Wdrażanie rekomendacji bez weryfikacji. Asystent nie zna kontekstu organizacji; jego sugestie wymagają oceny przez człowieka.
• Ignorowanie nazw obiektów. Nomenklatura baz i tabel bywa traktowana jako nieistotna, a ujawnia strukturę systemu.
• Zakładanie, że sandbox odzwierciedla produkcję. Współdzielone konto read-only w sandboxie nie pokazuje polityki retencji ani przepływu danych w środowisku klienta.

Działania krótkoterminowe

W perspektywie dni i tygodni warto skupić się na ograniczeniu ekspozycji. Ogranicz liczbę osób z dedykowanym przywilejem analizy live. Ustal listę pytań, które wolno zadawać asystentowi, i tych, których zadawać nie wolno — np. dotyczących danych osobowych. Zweryfikuj, czy platforma pozwala ograniczyć zbieranie tekstu SQL. Przejrzyj tokeny skryptów i unieważnij te, które nie są potrzebne. Uruchom dodatek na jednej instancji nieprodukcyjnej i oceń, jakie dane są wysyłane.

Działania długoterminowe

W perspektywie kwartałów warto wbudować korzystanie z asystenta w procesy zarządzania zmianą i bezpieczeństwa. Zdefiniuj politykę wysyłania danych do zewnętrznych modeli, obejmującą klasy danych, dopuszczalnych dostawców i wymogi retencji. Wprowadź przegląd rekomendacji asystenta przed wdrożeniem, podobny do przeglądu kodu. Uwzględnij dostawcę modelu w rejestrze podmiotów przetwarzających i w ocenie skutków dla ochrony danych. Zaplanuj okresowy przegląd uprawnień i tokenów. Rozważ, czy monitoring metryk i tekstów SQL nie powinien być rozdzielony — np. asystent widzi metryki, ale nie pełny tekst zapytań.

Checklista przed włączeniem AI Connectora

• Czy wiem, jakie kategorie danych trafiają do modelu (metryki, SQL, plany, nazwy obiektów)?
• Czy ustaliłem, który dostawca modelu będzie używany i na jakich warunkach?
• Czy zweryfikowałem politykę retencji i wykorzystania danych przez dostawcę modelu?
• Czy mam zgodę lub podstawę prawną na przekazywanie danych diagnostycznych poza organizację?
• Czy ograniczyłem dedykowany przywilej analizy live do niezbędnego kręgu osób?
• Czy przejrzałem role w interfejsie web i zakres widocznych instancji?
• Czy skrypty i zadania cykliczne mają tokeny o ograniczonym okresie ważności?
• Czy wiem, kto monitoruje logi logowań i zdarzeń tokenów?
• Czy zespół wie, jak weryfikować rekomendacje asystenta przed wdrożeniem?
• Czy przetestowałem dodatek na instancji nieprodukcyjnej?
• Czy ustaliłem, kto odpowiada za decyzję o wyborze modelu?
• Czy uwzględniłem dostawcę modelu w dokumentacji zgodności?

Co powinien zrobić właściciel firmy / administrator

Właściciel firmy powinien przede wszystkim ustalić, kto podejmuje decyzję o włączeniu dodatku i na jakiej podstawie. AI Connector to opcja licencyjna — włączenie jest świadomą decyzją biznesową, nie domyślnym ustawieniem. Właściciel powinien wymagać od zespołu technicznego krótkiego uzasadnienia: jakie dane będą wysyłane, do jakiego dostawcy, na jakich warunkach i jaki jest plan ograniczenia ekspozycji. Powinien też upewnić się, że decyzja została skonsultowana z osobą odpowiedzialną za ochronę danych i bezpieczeństwo informacji. Warto ustalić zasadę, że rekomendacje asystenta nie są wdrażane bez przeglądu przez człowieka — szczególnie gdy dotyczą konfiguracji produkcyjnej.

Administrator powinien zacząć od inwentaryzacji: lista instancji, rodzaje zbieranych danych, osoby z dostępem, skrypty i tokeny. Następnie powinien ograniczyć uprawnienia do minimum, nadać dedykowany przywilej analizy live tylko wybranym osobom i ustalić procedurę rotacji tokenów. Powinien zweryfikować, czy platforma pozwala ograniczyć zbieranie tekstu SQL, i jeśli tak — rozważyć włączenie takiego ograniczenia. Powinien też ustalić, gdzie trafiają logi logowań i zdarzeń tokenów, kto je przegląda i jakie zdarzenia powinny wywoływać reakcję. Przed włączeniem dodatku w produkcji warto przeprowadzić test na instancji nieprodukcyjnej i udokumentować obserwacje — w tym to, jakie dane faktycznie trafiają do modelu i jak wyglądają odpowiedzi.

Administrator powinien również pamiętać o zmianach towarzyszących: nowa funkcja datasentinel_analytics daje read-only dostęp do statystyk planisty i planów wykonania i wymaga Agent v4.0.0 lub nowszego. To osobny element, który warto uwzględnić w planie wdrożenia, ponieważ rozszerza zakres danych dostępnych w platformie. Automatyczne czyszczenie nieaktywnych instancji i wspólne filtry dla instancji agentless to zmiany porządkowe, ale ich wpływ na retencję danych warto zweryfikować przed wdrożeniem.

Najważniejsze pytanie nie brzmi „czy asystent jest bezpieczny”, lecz „co dokładnie opuszcza naszą infrastrukturę i kto za to odpowiada”. Producent odpowiada na pierwsze pytanie deklaracjami. Na drugie musi odpowiedzieć organizacja, która dodatek włącza.

Podsumowanie

Datasentinel 2026.10 to wydanie komercyjnej platformy monitoringu PostgreSQL z dodatkiem AI Connector opartym na MCP i Skill. Producent deklaruje model bezpieczeństwa oparty na OAuth 2.1, rolach zgodnych z interfejsem web, dedykowanym przywileju dla analizy live, braku bezpośredniego dostępu do bazy i szacowaniu planów bez uruchamiania zapytań. Jednocześnie wprost przyznaje, że metryki, tekst SQL, plany wykonania i nazwy obiektów trafiają do asystenta i wybranego modelu. To deklaracja, nie audyt. Dla organizacji oznacza to potrzebę przeglądu prawnego, ograniczenia uprawnień, wyboru dostawcy modelu ze świadomością jego warunków retencji oraz weryfikacji rekomendacji przed wdrożeniem. Sandbox i okres próbny pozwalają obejrzeć produkt, ale nie zastępują oceny przepływu danych w środowisku produkcyjnym.

Źródła i materiały do dalszej weryfikacji

Artykuł jest autorskim opracowaniem przygotowanym na podstawie poniższych materiałów. Linki prowadzą do publikacji źródłowych.

1. Datasentinel 2026.10 released with AI Connector (www.postgresql.org)

Zdjęcie wyróżniające: AS Photography / Pexels.