Агентний ШІ та розробка баз даних: що змінюється, коли ШІ справді може виконувати запити

Останні кілька років розробка баз даних за допомогою ШІ відбувалася за доволі звичною схемою. Розробник описує вимогу. ШІ генерує SQL-код. Розробник читає його, виправляє те, що здається неправильним, і вирішує, чи виконувати його.

Такий робочий процес зберігав одну важливу межу: ШІ може запропонувати дію, але рішення про те, чи виконувати її в базі даних, ухвалює людина.

Однак із появою агентного ШІ ця межа починає зникати. Сьогодні системи ШІ можуть аналізувати схеми, виконувати запити, інтерпретувати результати й вирішувати, що робити далі. Згідно з нещодавнім опитуванням, 62% організацій уже експериментують з агентами ШІ, а 23% повідомили, що масштабують агентну систему в певній частині підприємства.

Тож командам, які працюють із базами даних, уже зараз потрібно відповісти на важливе архітектурне запитання. Не на те, чи може ШІ виконувати SQL-запити. Може. Справжнє запитання полягає в тому, що змінюється, коли помічник перестає пропонувати код і починає діяти безпосередньо в базі даних, а також наскільки жорстко слід контролювати цю автономність.

Від рекомендацій до дій

Простий приклад із вибором індексу показує, чому ця зміна важлива.

Агент виявляє повільний запит, переглядає схему, визначає, що може допомогти індекс, створює його, повторно запускає робоче навантаження й перевіряє результат.

Він може виконати щось цілком звичайне, наприклад:

CREATE INDEX IX_Orders_CustomerId
ON Orders(CustomerId);

У цьому запиті немає нічого незвичного. Помічник на основі ШІ міг би запропонувати те саме. Різниця лише в тому, хто ухвалює остаточне рішення.

Коли йдеться про помічника, розробник перевіряє рекомендацію, тестує її й вирішує, чи виконувати її. ШІ радить, а діє людина. Якщо ж агент має права на виконання, система може ухвалити це рішення самостійно й продовжити роботу, не чекаючи на схвалення.

Якщо рішення правильне, робочий процес пришвидшується. Але агенти не завжди бачать усю картину. Вони можуть не врахувати залежності в застосунках, бізнес-правила, закономірності робочого навантаження, вікна технічного обслуговування або інші обставини, очевидні для людей, які підтримують систему.

Тож агент може ухвалити рішення, яке з технічного погляду здається обґрунтованим, але не підходить для середовища, де він діє, з огляду на конкретні обмеження й вимоги.

Небезпека зростає, коли дії починають утворювати ланцюжок. Невдалий SELECT може просто повільно виконуватися. Невдалий UPDATE може заблокувати велику таблицю або вплинути на набагато більше рядків, ніж передбачалося. Індекс, використаний для одного запиту, може бути зайвим, але створювати додаткове навантаження під час виконання інших запитів. Зміна схеми може порушити роботу залежного від неї компонента, про який агент не знав, адже йому може бракувати повного операційного контексту, а перевірити кожен можливий варіант використання він не здатен.

Проблема не в тому, що агенти не можуть ухвалювати вдалі рішення щодо баз даних. Часто вони на це здатні. Проблема в тому, що щойно їм дозволяють діяти відповідно до цих рішень, командам потрібно чіткіше визначити межі повноважень агента, доступний йому контекст і випадки, коли має втрутитися людина, а також з’ясувати, хто відповідатиме за результат.

За прогнозом Gartner, до кінця 2027 року буде скасовано понад 40% проєктів із агентним ШІ, зокрема через недостатній контроль ризиків. Для команд, які працюють із базами даних, висновок досить простий: спершу потрібно запровадити засоби контролю, а вже потім надавати права на виконання.

Що можна безпечно доручити агенту?

Деякі завдання, пов’язані з базами даних, значно безпечніше доручати агенту, ніж інші.

Аналіз запитів — вдалий приклад. Агент може переглядати статистику запитів, отримувати плани виконання, перевіряти індекси й структуру таблиць та пропонувати ймовірні способи усунення проблем, не змінюючи даних у робочій базі.

Він може виявити запит, який знову й знову сканує велику Orders таблицю:

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

Далі він може пояснити причину сканування, запропонувати індекс і згенерувати DDL. Щоб бути корисним, йому не потрібен дозвіл на виконання CREATE INDEX щоб бути корисним.

Те саме стосується таких завдань:

• Опис планів виконання;
• Виявлення відсутніх або зайвих індексів;
• Виявлення SELECT * запитів або несаргабельних предикатів;
• Перевірка просування операцій з’єднання та фільтрації до джерела даних;
• Перевірка залежностей і схем;
• Усунення помилок SQL;
• Оптимізація SQL-скриптів.

Практичний принцип простий: надайте агенту достатньо доступу, щоб зрозуміти проблему, але не давайте йому автоматично достатньо прав, щоб змінювати базу даних. Широкий доступ до перегляду може бути корисним, але широкі права на виконання — це вже окреме рішення.

Де людський контроль досі важливий

Деякі рішення щодо баз даних і досі потребують участі людини. Уявімо, що агент знаходить AuditLog таблицю із сотнями мільйонів рядків і вирішує, що старі записи слід видалити:

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

SQL-запит може бути цілком коректним, а рішення — вкрай невдалим.

Можливо, нормативні вимоги передбачають зберігання даних протягом семи років. Можливо, від цих записів залежить робота певного застосунку. Можливо, видаляти дані слід пакетами, щоб уникнути надмірного зростання журналу транзакцій. Можливо, перед видаленням записи потрібно архівувати.

Жодна з цих вимог не обов’язково має бути зафіксована в схемі.

Це одне з обмежень підходу, за якого роботу з базами даних зводять до генерування коду. Бази даних мають технічну структуру, але рішення щодо них часто є бізнес-рішеннями, які реалізують за допомогою технічних операцій. Такої самої обережності слід дотримуватися під час виконання таких операцій:

• DROP і руйнівних ALTER операторів;
• виробничих UPDATE і DELETE операцій;
• масштабних міграцій даних;
• змін ролей і дозволів;
• змін обмежень;
• змін, що впливають на реплікацію або доступність;
• розгортання збережених процедур, що містять бізнес-логіку.

Технічно правильна дія не обов’язково є доречною. Тому схвалення людиною не слід вважати незручним обмеженням агентного ШІ. Для важливих операцій із базами даних воно є частиною архітектури.

Агентам ШІ також потрібні мінімально необхідні привілеї

Командам, які працюють із базами даних, варто уникати одного спрощеного рішення — дозволяти агенту користуватися обліковими даними розробника. Це зручно, але тоді агент отримує всі права доступу, які вже має цей розробник.

Безпечніший підхід такий самий, як і для користувачів та служб: надавати лише мінімально необхідні привілеї. Microsoft рекомендує надавати тільки дозволи, потрібні для виконання завдання, і відстежувати дії з підвищеними привілеями.

Наприклад, агенту для аналізу продуктивності можуть знадобитися:

CONNECT
SELECT
VIEW DATABASE STATE
VIEW DEFINITION

Йому, ймовірно, не потрібні:

ALTER ANY TABLE
CONTROL DATABASE
db_owner
sysadmin

Різним агентам можна також призначити різні облікові записи. Агент для звітності може отримати SELECT доступ до кількох схем. Агент міграції може працювати лише в середовищі розробки або тестування. Агент для виробничого середовища може мати суворо обмежені дозволи, і перед виконанням операції йому все одно може знадобитися схвалення.

OWASP рекомендує дотримуватися такого самого базового підходу до агентів ШІ: розділяти доступ для читання й запису, обмежувати доступні інструменти та ресурси, а для чутливих дій вимагати явного дозволу.

Правило просте: надавайте агенту дозволи, потрібні для його завдання, а не ті, які має людина, що його запустила.

Вбудуйте участь людини в робочий процес

Краща модель агентної роботи з базами даних — це контрольований робочий процес:

Спостереження → Аналіз → Пропозиція → Перевірка → Виконання → Перевірка результату → Фіксація

Припустімо, агент досліджує причину повільної роботи кінцевої точки API. Він знаходить пов’язаний із нею SQL-запит, перевіряє план виконання та статистику таблиць, виявляє ймовірну відсутність індексу й готує скрипт міграції.

Спочатку цей скрипт можна запустити в тестовому середовищі. Агент повторно запускає робоче навантаження, перевіряє результат і готує зміну для виробничого середовища.

Після цього він зупиняється.

Розробник або адміністратор бази даних перевіряє міграцію, аналізує залежності та вплив на бізнес і схвалює її, перш ніж будь-що потрапить у виробниче середовище.

Агент і далі може виконувати значну частину рутинної роботи. Але остаточна відповідальність за важливу зміну залишається за людиною.

Додатковий рівень безпеки можуть забезпечити засоби керування транзакціями. Наприклад, точки збереження в PostgreSQL дають змогу скасувати частину транзакції, не відкидаючи всього, що було виконано раніше. Це може допомогти під час автоматизованих змін із тісно пов’язаними операціями, хоча можливість відкату не замінює належних дозволів і схвалення.

У цей робочий процес органічно вписуються й такі інструменти, як dbForge AI Assistant. Він може використовувати контекст схеми для генерування та пояснення SQL-запитів, усунення помилок, порівняння DDL, виявлення неефективних індексів і підготовки скриптів оптимізації, залишаючи згенерований SQL видимим для перевірки розробником.

Мета — автоматизувати рутинну роботу, залишивши важливі рішення за людиною.

Справжня мета — контрольована автономність

Агентний ШІ не означає, що потрібно вибирати лише між варіантами «ШІ тільки пропонує» і «ШІ керує базою даних». Між ними є чимало можливостей.

Команди можуть почати з завдань із нижчим рівнем ризику, як-от пояснення SQL, перевірка схем і виконання операцій лише для читання. Далі агенти можуть поступово брати на себе більше роботи в середовищах розробки й тестування.

Доступ на запис слід надавати значно пізніше, чітко обмеживши кількість рядків, яких може торкнутися зміна, і визначивши правила для транзакцій, відкату, моніторингу та схвалення. Повністю автономні зміни у виробничому середовищі мають бути рідкістю.

Це також узгоджується з рекомендаціями Deloitte: починати з робочих процесів із нижчим рівнем ризику та некритичних даних, залучати людей до процесу й посилювати управління в міру розширення можливостей агентів.

Мета — не абсолютна автономність. Агенту слід надати достатньо свободи, щоб він міг допомагати, але не більше доступу, ніж йому потрібно.

Висновок: розробка баз даних і далі потребує зважених рішень

Агенти ШІ можуть значно скоротити обсяг рутинної роботи під час розробки баз даних. Вони можуть аналізувати навантаження й запити, зіставляти схеми, плани, помилки та дані про продуктивність, а також діяти на основі побаченого.

Але щойно система ШІ отримує змогу змінювати стан бази даних, проблема набуває іншого характеру. Командам потрібні чіткі правила щодо ідентифікації, дозволів, меж транзакцій, погоджень, спостережуваності, відкату змін і журналів аудиту.

Саме тому серед 88% організацій, які використовували ШІ у 2025 році, лише 7% заявили, що повністю масштабували його використання в усій організації. Складніше завдання — зробити ШІ достатньо надійним для роботи в масштабах організації.

Розробка баз даних рухається в тому самому напрямку. Найкориснішим буде не агент, якому дозволено робити найбільше, а той, чиї повноваження чітко визначені й контрольовані.

Питання вже не в тому, чи здатен ШІ виконувати завдання з базами даних, а в тому, які саме завдання ми готові йому довірити і за яких обмежень.