Лидеры мнений

Агентный ИИ приходит в разработку баз данных: что меняется, когда ИИ действительно может выполнять запросы

Опубликовано 21 октября 2026

Victor Horlenko, Руководитель инноваций в области ИИ, Devart

Добавьте Unite.AI в избранные источники в Google

В последние несколько лет разработка баз данных с помощью ИИ строилась по достаточно удобной схеме. Разработчик описывает задачу. ИИ генерирует 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% заявили, что ИИ был полностью внедрён во всей организации. Главная трудность — сделать ИИ достаточно надёжным для работы в масштабах всей организации.

Разработка баз данных движется в том же направлении. Самым полезным будет не агент, которому разрешено делать как можно больше, а тот, чьи полномочия чётко определены и контролируются.

Вопрос уже не в том, способен ли ИИ выполнять задачи по работе с базами данных, а в том, какие задачи ему можно доверить и при каких ограничениях.