Agentowa AI wkracza do tworzenia baz danych: co się zmienia, gdy AI może naprawdę wykonywać zapytania

Przez ostatnich kilka lat tworzenie baz danych wspomagane przez AI opierało się na dość wygodnym modelu. Programista opisuje wymaganie. AI generuje kod SQL. Programista go czyta, poprawia to, co wygląda na błędne, i decyduje, czy go uruchomić.

Ten sposób pracy pozwalał zachować jedną ważną granicę: AI może zasugerować działanie, ale to człowiek nadal decyduje, czy zostanie ono wykonane na bazie danych.

Ta granica zaczyna jednak znikać wraz z rozwojem agentowej AI. Obecnie systemy AI potrafią analizować schematy, wykonywać zapytania, interpretować wyniki i decydować, jakie działanie podjąć w następnej kolejności. Według niedawnego badania 62% organizacji już eksperymentuje z agentami AI, a 23% zadeklarowało wdrożenie systemu agentowego na większą skalę w którymś obszarze przedsiębiorstwa.

Zespoły odpowiedzialne za bazy danych muszą więc dość pilnie odpowiedzieć na ważne pytanie architektoniczne. Nie chodzi o to, czy AI potrafi wykonywać kod SQL. Potrafi. Prawdziwe pytanie brzmi: co się zmienia, gdy asystent przestaje podpowiadać kod, a zaczyna działać na bazie danych, i jak ściśle należy kontrolować jego autonomię.

Od sugestii do działania

Prosta decyzja dotycząca indeksowania pokazuje, dlaczego ta zmiana ma znaczenie.

Agent zauważa wolne zapytanie, sprawdza schemat, ustala, że indeks może pomóc, tworzy go, ponownie uruchamia obciążenie i sprawdza wynik.

Może wykonać coś tak zwyczajnego jak:

CREATE INDEX IX_Orders_CustomerId
ON Orders(CustomerId);

To polecenie nie jest niczym niezwykłym. Asystent AI mógłby zasugerować dokładnie to samo. Różnica polega na tym, kto podejmuje ostateczną decyzję.

W przypadku asystenta programista sprawdza rekomendację, testuje ją i decyduje, czy ją uruchomić. AI doradza, ale działa człowiek. Agent z uprawnieniami do wykonywania poleceń może sam podjąć tę decyzję i przejść dalej bez czekania na zatwierdzenie.

Jeśli decyzja jest trafna, praca przebiega szybciej. Agenci nie zawsze jednak dysponują pełnym obrazem sytuacji. Mogą nie uwzględnić zależności w aplikacji, reguł biznesowych, charakterystyki obciążenia, okien serwisowych ani innych uwarunkowań oczywistych dla osób zarządzających systemem.

Agent może więc podjąć decyzję, która wydaje się technicznie uzasadniona, a mimo to jest niewłaściwa w środowisku, w którym działa, ze względu na jego konkretne ograniczenia i wymagania.

Niebezpieczeństwo rośnie, gdy działania zaczynają następować jedno po drugim. Błędne SELECT może po prostu działać wolno. Błędne UPDATE może zablokować całą dużą tabelę albo wpłynąć na znacznie więcej wierszy, niż zamierzano. Indeks używany przez jedno zapytanie może być zbędny, a jednocześnie zwiększać obciążenie związane z innymi zapytaniami. Zmiana schematu może spowodować awarię czegoś, co od niej zależy, ale o czym agent nie wiedział, ponieważ może nie mieć pełnego kontekstu operacyjnego i nie jest w stanie przetestować każdego możliwego przypadku użycia.

Problem nie polega więc na tym, że agenci nie potrafią podejmować dobrych decyzji dotyczących baz danych. Często potrafią. Chodzi o to, że gdy otrzymują pozwolenie na działanie zgodnie z tymi decyzjami, zespoły muszą znacznie precyzyjniej określić zakres ich uprawnień, dostępny im kontekst, sytuacje, w których nadal musi interweniować człowiek, oraz to, kto ponosi odpowiedzialność za wynik.

Gartner przewiduje, że do końca 2027 roku zostanie anulowanych ponad 40% projektów agentowej AI, częściowo z powodu niewystarczających mechanizmów kontroli ryzyka. Wniosek dla zespołów odpowiedzialnych za bazy danych jest dość prosty: uprawnienia do wykonywania działań należy przyznawać dopiero po wdrożeniu mechanizmów kontroli, a nie wcześniej.

Co można bezpiecznie powierzyć agentowi?

Niektóre zadania związane z bazami danych można bezpieczniej powierzyć agentowi niż inne.

Dobrym przykładem jest analiza zapytań. Agent może sprawdzać statystyki zapytań, pobierać plany wykonania, analizować indeksy i struktury tabel oraz proponować prawdopodobne rozwiązania bez wprowadzania zmian w danych produkcyjnych.

Może zauważyć, że takie zapytanie wielokrotnie skanuje dużą Orders tabelę:

SELECT OrderId, OrderDate, Total
FROM Orders
WHERE CustomerId = @CustomerId
ORDER BY OrderDate DESC;

Następnie może wyjaśnić przyczynę skanowania, zasugerować indeks i wygenerować instrukcję DDL. Nie musi mieć uprawnień do jej wykonania CREATE INDEX , aby być przydatny.

To samo dotyczy takich zadań jak:

• opisywanie planów wykonania;
• wskazywanie brakujących lub zbędnych indeksów;
• wykrywanie SELECT * zapytań lub predykatów niesargowalnych;
• analizowanie operacji łączenia i przesuwania filtrów;
• analizowanie zależności i schematów;
• diagnozowanie błędów SQL;
• optymalizowanie skryptów SQL.

Praktyczny podział jest prosty: zapewnij agentowi dostęp wystarczający do zrozumienia problemu, ale niekoniecznie taki, który pozwoli mu zmieniać bazę danych. Szeroki dostęp do informacji może być przydatny, ale przyznanie szerokich uprawnień do wykonywania działań to odrębna decyzja.

Gdzie nadal potrzebna jest kontrola człowieka

Niektóre decyzje dotyczące baz danych nadal wymagają udziału człowieka. Załóżmy, że agent znajduje AuditLog tabelę zawierającą setki milionów wierszy i uznaje, że należy usunąć stare rekordy:

DELETE FROM AuditLog
WHERE CreatedAt < DATEADD(year, -2, GETDATE());

Kod SQL może być całkowicie poprawny, a decyzja mimo to fatalna.

Być może przepisy wymagają przechowywania danych przez siedem lat. Może jakaś aplikacja korzysta z tych rekordów. Być może usuwanie należy przeprowadzać partiami, aby uniknąć wzrostu dziennika transakcji. Możliwe też, że przed usunięciem rekordy trzeba zarchiwizować.

Żadne z tych wymagań nie musi być określone w schemacie.

To jedno z ograniczeń podejścia, w którym pracę z bazą danych traktuje się jako problem generowania kodu. Bazy danych obejmują struktury techniczne, ale związane z nimi decyzje często są decyzjami biznesowymi wyrażonymi za pomocą operacji technicznych. Tę samą ostrożność należy zachować w przypadku takich operacji jak:

• DROP i destrukcyjne ALTER instrukcje;
• produkcyjne UPDATE i DELETE operacje;
• duże migracje danych;
• zmiany ról i uprawnień;
• modyfikacje ograniczeń;
• zmiany wpływające na replikację lub dostępność;
• wdrażanie procedur składowanych zawierających logikę biznesową.

Działanie poprawne pod względem technicznym nie musi być działaniem właściwym. Dlatego akceptacji człowieka nie należy postrzegać jako uciążliwego ograniczenia agentowej sztucznej inteligencji. W przypadku operacji na bazach danych o dużym wpływie na ich działanie jest ona częścią architektury.

Agenci AI również potrzebują minimalnych uprawnień

Jednym ze skrótów, których zespoły bazodanowe powinny unikać, jest pozwalanie agentowi na korzystanie z istniejących poświadczeń programisty. To proste rozwiązanie, ale daje agentowi taki sam dostęp, jaki ma ten programista.

Bezpieczniejsze podejście jest takie samo jak w przypadku użytkowników i usług: zasada najmniejszych uprawnień. Microsoft zaleca przyznawanie wyłącznie uprawnień wymaganych do wykonania zadania oraz monitorowanie działań uprzywilejowanych.

Agent analizujący wydajność może na przykład potrzebować:

CONNECT
SELECT
VIEW DATABASE STATE
VIEW DEFINITION

Prawdopodobnie nie potrzebuje:

ALTER ANY TABLE
CONTROL DATABASE
db_owner
sysadmin

Poszczególni agenci mogą też mieć różne tożsamości. Agent raportujący mógłby otrzymać SELECT dostęp do kilku schematów. Agent migracyjny mógłby pracować wyłącznie w środowisku deweloperskim lub testowym. Agent produkcyjny mógłby mieć ściśle ograniczone uprawnienia, a mimo to wymagać zatwierdzenia przed wykonaniem operacji.

OWASP zaleca stosowanie tej samej podstawowej zasady w przypadku agentów AI: oddzielanie dostępu do odczytu od dostępu do zapisu, ograniczanie liczby narzędzi i zasobów oraz wymaganie wyraźnego upoważnienia do wykonywania wrażliwych działań.

Zasada jest prosta: przyznaj agentowi uprawnienia niezbędne do wykonywania jego zadań, a nie uprawnienia osoby, która go uruchomiła.

Uwzględnij człowieka w procesie pracy

Lepszym modelem pracy agentowej z bazami danych jest kontrolowany proces:

Obserwuj → Analizuj → Zaproponuj → Zweryfikuj → Wykonaj → Sprawdź → Zapisz

Załóżmy, że agent bada powolny punkt końcowy API. Znajduje obsługujące go zapytanie SQL, sprawdza plan wykonania i statystyki tabel, zauważa prawdopodobny brak indeksu i przygotowuje skrypt migracyjny.

Skrypt można najpierw uruchomić w środowisku testowym. Agent ponownie uruchamia obciążenie, sprawdza wynik i przygotowuje zmianę produkcyjną.

Następnie się zatrzymuje.

Programista lub administrator baz danych sprawdza migrację, analizuje zależności i wpływ na działalność firmy, a następnie ją zatwierdza, zanim jakakolwiek zmiana trafi do środowiska produkcyjnego.

Agent nadal może wykonać wiele powtarzalnych zadań. Ostateczna odpowiedzialność za zmianę o dużym wpływie pozostaje jednak po stronie człowieka.

Mechanizmy kontroli transakcji mogą zapewnić dodatkową warstwę bezpieczeństwa. Na przykład punkty zapisu w PostgreSQL pozwalają wycofać część transakcji bez odrzucania wszystkiego, co wykonano wcześniej. Może to pomóc w przypadku ściśle powiązanych zmian automatycznych, ale możliwość wycofania zmian nie zastępuje odpowiednich uprawnień i zatwierdzenia.

W tym miejscu dobrze sprawdzają się też narzędzia takie jak dbForge AI Assistant. Mogą wykorzystywać kontekst schematu do generowania i objaśniania zapytań SQL, diagnozowania błędów, porównywania DDL, wykrywania nieefektywnych indeksów oraz przygotowywania skryptów optymalizacyjnych, a jednocześnie pozostawiać wygenerowany kod SQL widoczny do sprawdzenia przez programistę.

Celem jest automatyzacja rutynowych zadań przy zachowaniu ludzkiej kontroli nad ważnymi decyzjami.

Prawdziwym celem jest kontrolowana autonomia

Agentowa sztuczna inteligencja nie musi oznaczać wyboru między „AI tylko podpowiada” a „AI obsługuje bazę danych”. Istnieje wiele możliwości pośrednich.

Zespoły mogą zacząć od zadań o niższym ryzyku, takich jak objaśnianie SQL, przeglądanie schematów i przeprowadzanie kontroli wyłącznie z dostępem do odczytu. Następnie mogą stopniowo powierzać agentom więcej zadań w środowiskach deweloperskich i testowych.

Dostęp do zapisu należy przyznawać znacznie później, z jasno określonymi ograniczeniami dotyczącymi liczby zmienianych wierszy, transakcji, wycofywania zmian, monitorowania i zatwierdzania. W pełni autonomiczne zmiany w środowisku produkcyjnym powinny być rzadkością.

Podobne zalecenia przedstawia Deloitte: zaczynać od procesów o niższym ryzyku i danych niekrytycznych, angażować ludzi oraz wzmacniać nadzór w miarę rozszerzania możliwości agentów.

Celem nie jest pełna autonomia. Chodzi o zapewnienie agentowi wystarczającej swobody, by mógł pomagać, ale bez przyznawania mu większego dostępu, niż potrzebuje.

Wniosek: Rozwój baz danych nadal wymaga trafnej oceny

Agenci AI mogą przejąć wiele powtarzalnych zadań związanych z inżynierią baz danych. Mogą obserwować obciążenia, analizować zapytania, korelować schematy, plany, błędy i dane o wydajności, a następnie podejmować działania na podstawie tych obserwacji.

Gdy jednak system AI może zmieniać stan bazy danych, problem staje się inny. Zespoły potrzebują jasnych zasad dotyczących tożsamości, uprawnień, granic transakcji, zatwierdzania, obserwowalności, wycofywania zmian i ścieżek audytu.

Dlatego spośród 88% organizacji korzystających z AI w 2025 r. tylko 7% stwierdziło, że wdrożyło ją w pełni w całej organizacji. Trudniejszym wyzwaniem jest zapewnienie AI niezawodności wystarczającej do działania na dużą skalę.

Rozwój baz danych zmierza w tym samym kierunku. Najbardziej użyteczny agent to nie ten, któremu pozwala się na najwięcej, lecz ten, którego zakres uprawnień jest jasno określony i kontrolowany.

Pytanie nie brzmi już, czy AI może wykonywać zadania związane z bazami danych, lecz którym zadaniom powinniśmy powierzyć jej wykonanie i na jakich warunkach.