Agentní AI a vývoj databází: Co se změní, když AI dokáže skutečně spouštět dotazy

Vývoj databází s pomocí AI se v posledních několika letech řídil poměrně pohodlným modelem. Vývojář popíše požadavek. AI vygeneruje SQL. Vývojář si ho přečte, upraví, co mu připadá nesprávné, a rozhodne, zda ho spustí.

Tento postup zachovával jednu důležitou hranici: AI může navrhnout akci, ale o tom, zda se skutečně provede v databázi, stále rozhoduje člověk.

S nástupem agentní AI však tato hranice začíná mizet. Dnešní systémy AI dokážou prozkoumat schémata, spouštět dotazy, interpretovat výsledky a rozhodovat, jaký krok podniknout dál. Podle nedávného průzkumu už 62 % organizací experimentuje s agenty AI, zatímco 23 % uvedlo, že někde v podniku rozšiřuje nasazení agentního systému.

Databázové týmy proto musí poměrně bezodkladně vyřešit jednu architektonickou otázku. Nejde o to, zda AI dokáže spouštět SQL. Dokáže. Skutečnou otázkou je, co se změní, když asistent přestane navrhovat kód a začne jednat přímo v databázi, a jak přísně je třeba tuto autonomii řídit.

Od návrhů k akcím

Proč je tato změna důležitá, ukazuje jednoduché rozhodnutí týkající se indexování.

Agent zaznamená pomalý dotaz, vyhledá informace o schématu, zjistí, že by mohl pomoci index, vytvoří ho, znovu spustí úlohu a zkontroluje výsledek.

Může například spustit něco tak běžného, jako je:

CREATE INDEX IX_Orders_CustomerId
ON Orders(CustomerId);

Na tomto příkazu není nic neobvyklého. Asistent AI mohl navrhnout přesně totéž. Rozdíl spočívá v tom, kdo učiní konečné rozhodnutí.

U asistenta doporučení zkontroluje a otestuje vývojář a rozhodne, zda ho spustí. AI radí, ale jedná člověk. Agent s oprávněním ke spouštění může toto rozhodnutí učinit sám a pokračovat bez čekání na schválení.

Pokud je rozhodnutí správné, práce postupuje rychleji. Agenti ale nemají vždy k dispozici úplný obraz. Mohou přehlédnout závislosti aplikací, obchodní pravidla, vzorce zatížení, servisní okna nebo další souvislosti, které jsou lidem spravujícím systém zřejmé.

Agent tedy může dospět k rozhodnutí, které se z technického hlediska jeví jako rozumné, a přesto může být pro prostředí, v němž jedná, vzhledem k jeho konkrétním omezením a požadavkům nesprávné.

Nebezpečí roste, když se jednotlivé akce začnou řetězit. Špatný dotaz SELECT může jen běžet pomalu. Špatný příkaz UPDATE může zamknout celou velkou tabulku nebo zasáhnout mnohem více řádků, než bylo zamýšleno. Index použitý pro jeden dotaz může být zbytečný a zároveň zpomalovat ostatní dotazy. Změna schématu může narušit něco, co na něm závisí, aniž by o tom agent věděl, protože nemusí mít úplný provozní kontext a nedokáže otestovat všechny možné případy použití.

Problém tedy nespočívá v tom, že by agenti nedokázali správně rozhodovat o databázích. Často to dokážou. Jakmile jim ale dovolíme podle těchto rozhodnutí jednat, musí si týmy mnohem jasněji stanovit, kam až tato pravomoc sahá, jaké souvislosti agent vidí, v jakých případech musí stále zasáhnout člověk a kdo nese odpovědnost za výsledek.

Gartner očekává, že do konce roku 2027 bude zrušeno více než 40 % projektů agentní AI, mimo jiné kvůli nedostatečným kontrolám rizik. Pro databázové týmy z toho plyne jednoduché poučení: oprávnění ke spouštění mají přijít až po zavedení kontrol, nikoli před nimi.

Co lze bezpečně svěřit agentům?

Některé databázové úkoly lze svěřit mnohem bezpečněji než jiné.

Analýza dotazů je dobrým příkladem. Agent může prozkoumat statistiky dotazů, získat plány provádění, zkontrolovat indexy a struktury tabulek a navrhnout pravděpodobná řešení, aniž by měnil produkční data.

Mohl by například opakovaně zaznamenat dotaz, který prohledává rozsáhlou Orders tabulku:

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

Poté může vysvětlit, proč k prohledávání dochází, navrhnout index a vygenerovat příkaz DDL. K tomu, aby byl užitečný, nepotřebuje oprávnění spouštět CREATE INDEX aby byla užitečná.

Totéž platí pro úkoly, jako jsou:

• Popis plánů provádění;
• Vyhledávání chybějících nebo zbytečných indexů;
• Upozorňování na SELECT * dotazy nebo predikáty, které nelze efektivně obsloužit pomocí indexu;
• Kontrola posouvání spojení a filtrů;
• Kontrola závislostí a schémat;
• Řešení problémů s chybami SQL;
• Optimalizace skriptů SQL.

Praktické rozdělení je jednoduché: agentovi poskytněte dostatečný přístup, aby mohl problém pochopit, ale ne automaticky takový přístup, který mu umožní měnit databázi. Široký přístup k informacím může být užitečný, ale udělit rozsáhlá oprávnění ke spouštění je jiné rozhodnutí.

Kde je lidský dohled stále důležitý

Některá rozhodnutí týkající se databází stále vyžadují zapojení člověka. Představme si, že agent najde AuditLog tabulku se stovkami milionů řádků a rozhodne, že staré záznamy je třeba odstranit:

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

SQL může být naprosto platné, a přesto může jít o hrozné rozhodnutí.

Možná předpisy vyžadují uchovávání po dobu sedmi let. Možná na těchto záznamech závisí nějaká aplikace. Možná by se měly mazat po dávkách, aby se zabránilo růstu transakčního protokolu. Možná je před odstraněním nutné záznamy archivovat.

Žádný z těchto požadavků nemusí být ve schématu vůbec uveden.

To je jedno z omezení přístupu, který chápe práci s databází jako problém generování kódu. Databáze obsahují technické struktury, ale rozhodnutí, která se jich týkají, jsou často obchodními rozhodnutími vyjádřenými prostřednictvím technických operací. Stejnou opatrnost je třeba uplatňovat i při operacích, jako jsou:

• DROP a destruktivní ALTER příkazy;
• produkční UPDATE a DELETE operace;
• rozsáhlé migrace dat;
• změny rolí a oprávnění;
• úpravy omezení;
• změny ovlivňující replikaci nebo dostupnost;
• nasazení uložených procedur obsahujících obchodní logiku.

Technicky správný úkon nemusí být nutně vhodný. Lidské schválení by proto nemělo být vnímáno jako nepříjemné omezení agentní AI. U databázových operací s velkým dopadem je součástí architektury.

Agenti AI také potřebují nejnižší možná oprávnění

Jednou z možností, které by se databázové týmy měly vyhnout, je nechat agenta používat stávající přihlašovací údaje vývojáře. Je to snadné, ale agentovi to poskytne veškerý přístup, který daný vývojář už má.

Bezpečnější přístup je stejný jako u uživatelů a služeb: princip nejnižších oprávnění. Microsoft doporučuje udělovat pouze oprávnění potřebná k danému úkolu a monitorovat privilegované činnosti.

Agent pro analýzu výkonu může například potřebovat:

CONNECT
SELECT
VIEW DATABASE STATE
VIEW DEFINITION

Pravděpodobně nepotřebuje:

ALTER ANY TABLE
CONTROL DATABASE
db_owner
sysadmin

Různí agenti mohou mít také různé identity. Agent pro vytváření sestav může získat SELECT přístup k několika schématům. Agent pro migraci může pracovat pouze ve vývojovém nebo testovacím prostředí. Produkční agent může mít přísně vymezená oprávnění a přesto před spuštěním potřebovat schválení.

OWASP doporučuje stejný základní postup i pro agenty AI: oddělit přístup pro čtení a zápis, omezit nástroje a zdroje a vyžadovat výslovné oprávnění k citlivým akcím.

Pravidlo je jednoduché: udělte agentovi oprávnění potřebná k jeho práci, nikoli oprávnění osoby, která ho spustila.

Zapojte člověka do pracovního postupu

Lepším modelem pro agentní práci s databázemi je řízený pracovní postup:

Pozorovat → Analyzovat → Navrhnout → Zkontrolovat → Provést → Ověřit → Zaznamenat

Představme si, že agent prověřuje pomalý koncový bod API. Najde SQL dotaz, který za ním stojí, zkontroluje plán vykonávání a statistiky tabulek, odhalí pravděpodobně chybějící index a připraví migrační skript.

Skript lze nejprve spustit v testovacím prostředí. Agent znovu spustí úlohu, zkontroluje výsledek a připraví změnu pro produkční prostředí.

Pak se zastaví.

Vývojář nebo správce databáze migraci zkontroluje, prověří závislosti i dopad na podnikání a schválí ji dříve, než se cokoli dostane do produkčního prostředí.

Agent může stále zvládat mnoho opakujících se úkolů. Konečná odpovědnost za změnu s velkým dopadem však zůstává na člověku.

Další vrstvu bezpečnosti mohou přidat transakční mechanismy. Záchytné body v PostgreSQL například umožňují vrátit zpět část transakce, aniž by se zahodilo vše, co jí předcházelo. To může pomoci u úzce vymezených automatizovaných změn, ale možnost vrácení změn nenahrazuje řádná oprávnění a schválení.

Sem přirozeně zapadají také nástroje, jako je dbForge AI Assistant. Může využívat kontext schématu k vytváření a vysvětlování SQL, řešení chyb, porovnávání DDL, odhalování neefektivních indexů a přípravě optimalizačních skriptů, přičemž výsledné SQL zůstává viditelné pro kontrolu vývojářem.

Cílem je automatizovat rutinní práci a zároveň ponechat důležitá rozhodnutí lidem.

Skutečným cílem je řízená autonomie

Agentní AI nemusí znamenat volbu mezi „AI pouze navrhuje“ a „AI spravuje databázi“. Existuje mnoho možností mezi těmito dvěma krajními přístupy.

Týmy mohou začít úkoly s nižším rizikem, jako je vysvětlování SQL, kontrola schémat a provádění kontrol pouze pro čtení. Poté mohou agenti postupně přebírat více práce ve vývojovém a testovacím prostředí.

Přístup pro zápis by měl přijít mnohem později a měl by být jasně omezen z hlediska počtu ovlivněných řádků, transakcí, vracení změn, monitorování a schvalování. Plně autonomní změny v produkčním prostředí by měly být vzácné.

Podobný přístup doporučuje i Deloitte: začít pracovními postupy s nižším rizikem a nekritickými daty, zapojit lidi do procesu a posilovat správu a řízení, jak agenti získávají více pravomocí.

Cílem není absolutní autonomie. Jde o to poskytnout agentovi dostatek volnosti, aby mohl pomáhat, ale ne více přístupu, než potřebuje.

Závěr: Vývoj databází se stále neobejde bez úsudku

AI agenti mohou z databázového inženýrství odstranit velkou část opakující se práce. Dokážou sledovat pracovní zátěže, analyzovat dotazy, dávat do souvislosti schémata, plány, chyby a údaje o výkonu a jednat na základě toho, co zjistí.

Jakmile však systém AI dokáže měnit stav databáze, situace se mění. Týmy potřebují jasná pravidla pro identitu, oprávnění, hranice transakcí, schvalování, observabilitu, vrácení změn a auditní záznamy.

Proto z 88 % organizací, které v roce 2025 využívaly AI, uvedlo pouze 7 %, že ji plně zavedly v celé organizaci. Obtížnější je zajistit, aby AI byla dostatečně spolehlivá a mohla fungovat ve velkém měřítku.

Vývoj databází se ubírá stejným směrem. Nejužitečnější agent nebude ten, kterému bude dovoleno dělat nejvíc, ale ten, jehož pravomoci budou jasně vymezené a pod kontrolou.

Otázkou už není, zda AI dokáže provádět úkoly spojené s databázemi, ale kterým úkolům bychom měli svěřit a za jakých omezení jejich provádění.