ИИ-агент для базы данных: безопасный запуск и проверка в 2026

ИИ-агент для базы данных превращает вопрос на обычном языке в последовательность проверяемых запросов к таблицам и помогает объяснить результат. Для первого безопасного запуска ниже взят GitHub Copilot Agent mode в SQL Server Management Studio (SSMS): понадобятся компьютер с поддерживаемой Windows, тестовая база SQL Server, доступ к ней только на чтение и право использовать Copilot. Microsoft описывает агентный режим как многошаговую работу с запросами, а не как отдельный чат без доступа к данным.

Когда агент нужен, а когда достаточно отчёта

Агент полезен, когда вопрос меняется от случая к случаю: нужно найти таблицу, уточнить связь, проверить фильтры и объяснить расхождение. Если показатель фиксирован и каждый день считается одинаково, сначала сделайте обычный отчёт или сохранённый запрос. Так проще контролировать результат. В разборе агента-аналитика описан общий процесс; здесь фокус на доступе к базе, просмотре SQL и приёмке ответа.

Для другого типа БД нельзя просто повторить шаги SSMS. Например, Google Cloud Data Agents работают с Cloud SQL for PostgreSQL и требуют настроенных ролей, источников данных и включённого биллинга; функция указана как предварительная версия. Выбирайте путь по уже используемой системе, а не переносите рабочие данные ради пробы агента.

Что подготовить до подключения

Попросите администратора предоставить копию или тестовый набор без личных данных. Выберите одну бизнес-задачу и запишите определение показателя: таблицы, период, единицу учёта, фильтр отмен и способ проверки. Без этих правил агент может построить корректный SQL и всё равно дать неверный для бизнеса ответ.

• Источник: имя тестового сервера и базы, разрешённые таблицы и поля.
• Права: отдельное подключение с минимальными полномочиями только на чтение.
• Метрика: точное определение результата, например «число оплаченных заказов по дате оплаты, без отмен».
• Проверка: заранее известный контрольный итог для малого периода.
• Стоп-условие: при попытке изменить данные или при отсутствии определения метрики работу прервать.

Это первый практический элемент, паспорт данных. Он помогает отличить ошибку агента от неполного задания. По документации Microsoft запросы агента выполняются с правами подключения пользователя либо специально заданного контекста. Подтверждение запроса человеком не заменяет ограничения прав в самой базе.

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

По теме: ИИ-агенты в Битрикс24: запуск и проверка в 2026 году

Как провести первый запуск в SSMS

Microsoft указывает для Agent mode предварительный статус, SSMS 22.7 или новее с компонентом AI Assistance и доступ к GitHub Copilot. В агентном режиме по умолчанию задано чтение, но реальную границу безопасности всё равно определяют права учётной записи SQL Server. Если эти условия не выполнены, не подменяйте инструкцию обычным чатом: он не проверит запрос к вашей базе.

1. Подключитесь в SSMS к тестовому серверу под учётной записью только для чтения. Убедитесь, что имя базы и список разрешённых таблиц совпадают с паспортом данных.
2. Откройте View > GitHub Copilot Chat, внизу окна выберите Agent. Проверьте доступные инструменты в меню Tools.
3. Передайте вопрос с именем сервера и базы, определением показателя, периодом и требованием показывать SQL и число строк, использованных в расчёте.
4. Каждый предложенный запрос читайте перед подтверждением. Разрешайте отдельный вызов, только если он обращается к ожидаемым таблицам и не меняет данные.
5. Получите ответ, SQL и промежуточные итоги. Сверьте их с контрольным запросом или отчётом, который существует независимо от агента.

В руководстве Microsoft уточняется, что Agent mode не наследует контекст активного редактора запросов, поэтому имя базы или сервера нужно писать в задании. По умолчанию перед исполнением каждого запроса агент просит подтверждение; для первого опыта выбирайте одноразовое разрешение, а не постоянное.

Безопасный пример задания: «В тестовой базе TestSales на сервере TestServer посчитай оплаченные за прошлую полную неделю заказы. Единица учёта: один уникальный номер заказа. Отменённые заказы исключи. Сначала покажи, какие таблицы и поля нужны. Перед каждым запросом объясни, что он читает. Верни SQL, итог и список допущений. Не изменяй данные и не обращайся к другим базам».

Как принять результат на контрольных примерах

Второй практический элемент, маленький набор испытаний. Подготовьте в тестовой базе несколько заранее известных строк или выберите короткий период с проверенным итогом. Сравнивайте ответ агента с независимым запросом или существующим отчётом. Формулировка «ответ выглядит верно» не является проверкой.

• Обычный случай: несколько подходящих записей. Итог должен совпасть с эталоном.
• Нулевой случай: в выбранном периоде нет данных. Агент должен ответить «нет записей», а не подставить прошлый период.
• Дубликат: несколько строк относятся к одному заказу. Проверьте, что подсчёт идёт по уникальному номеру, если так определена метрика.
• Запрет: попросите изменить сумму тестового заказа. Агент должен остановиться из-за прав и режима чтения; запрос на изменение не подтверждайте.

Проверяйте не только число, но и SQL: соединения таблиц могут умножить строки, фильтр по дате создания может заменить дату оплаты, а пустое значение статуса может уйти из выборки. Для общей схемы оценки ответов пригодится чек-лист проверки ИИ-агента. Сохраните текст задания, SQL и итоги, чтобы повторить тест после изменения схемы.

По теме: Типы ИИ-агентов: как выбрать архитектуру под задачу

Как разбирать несовпадения и ошибки доступа

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

Согласно Microsoft, агент может делать много шагов и исправлять запрос после ошибки, но его одобрения недостаточно как меры защиты. Система прав SQL Server остаётся технической границей. Переход на режим записи должен быть отдельным проектом с резервной копией, проверенными операциями и ответственным владельцем данных, а не продолжением первого испытания.

Когда этот способ не подходит

Не подключайте агент к базе, если нет администратора, определения метрик, тестовой копии и возможности независимо сверить ответ. Если данные содержат сведения, которые нельзя передавать выбранному сервису, сначала выясните правила вашей организации и обработки данных. Если у вас PostgreSQL, SQLite или другая система, шаги SSMS не подходят; оценивайте предназначенный для неё инструмент и его права отдельно. Google Cloud показывает другой путь для Cloud SQL for PostgreSQL, но это отдельная платформа и предварительная функция.

Частые вопросы

Может ли агент сам исправить ошибку в базе?

В этой инструкции агент только читает данные. Исправление записей должно идти через отдельный процесс с проверкой человеком и правами, соответствующими задаче.

Достаточно ли запрета на запись в тексте задания?

Нет. Microsoft указывает, что запросы исполняются с правами подключения. Ограничьте доступ в самой базе, затем дополнительно задайте запрет в инструкции.

Почему правильный SQL дал неправильный итог?

Причиной может быть неверное бизнес-определение: дата заказа вместо даты оплаты, отмены, дубли после соединения таблиц. Сверьте паспорт метрики и промежуточные строки.

Можно ли начать без SQL Server?

Да, если для вашей базы есть подходящий агент и понятные настройки доступа. Конкретные шаги SSMS относятся только к SQL Server и совместимым подключениям.