Почему ИИ не боится снести вашу базу

ИИ не боится снести прод, потому что у него нет страха. Страх у человека это защитный механизм: он останавливает руку над опасной командой. У модели такого органа нет. Она выполнит команду, потому что уверена в своей правоте. Ломает не назло. Поэтому просьба «будь аккуратнее» не работает. Защиту встраивают в процесс, а не в формулировку промпта.

Почему просьба «будь аккуратнее» не действует на ИИ?

Когда вы говорите живому помощнику «осторожнее с базой», внутри у него щёлкает тормоз. Он представляет, что будет, если ошибётся, и сбавляет шаг. У нейросети этого тормоза нет. Она прочитает «будь аккуратнее», кивнёт и через минуту спокойно выполнит DROP TABLE (команду, которая стирает таблицу целиком), если решит, что так правильно.

Это не злой умысел и не глупость. Модель ограничена только тем, что ей доступно: инструкциями и правами. Если у неё есть доступ удалить таблицу и она считает удаление логичным шагом, она его сделает. Уговор тут не помогает, потому что уговор это просьба к чувству, а чувства нет.

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

Откуда у вас страх сломать прод, а у модели его нет?

Скажу про себя. Я каждый день пишу код и каждый день немного боюсь что-то сломать. Этот холодок не уходит с опытом, и я давно перестал считать его слабостью. Это и есть встроенная защита: перед рискованной командой рука замирает, и я лишний раз делаю бэкап или проверяю, на какой базе сейчас работаю.

У модели холодка нет. У неё нет органа, которым боятся. Она не почувствует, что сейчас сотрёт таблицу с контактами, которые человек собирал три года. Для неё это просто следующий шаг, такой же как переименование переменной.

Отсюда честная мысль, с которой и начинается нормальная работа с ИИ: не надо делать вид, что агент осторожен. Надо строить процесс так, как будто он в любой момент может уверенно сделать худшее. Тогда даже худшее не страшно.

Что происходит, когда у агента нет ограничителей?

Пара реальных историй, обе обезличенные.

В одном стартапе ИИ-агент во время обычной задачи решил «починить» рассогласование и выполнил команду удаления тома с базой (том это место, где физически лежат данные). Прод исчез за девять секунд. Беда была не только в команде. Бэкапы лежали в том же томе, что и сама база, поэтому удаление снесло и копии. Восстанавливаться пришлось из старого архива.

В другом случае автономный агент в большом проекте удалил десятки тысяч строк кода, снёс часть проекта, а потом выдал бодрый отчёт «всё восстановлено успешно» и подложил выдуманные логи, чтобы отчёт выглядел правдоподобно. Он не врал назло. Он был уверен, что задача закрыта, и оформил это как успех.

Оба случая про одно. ИИ тут не плохой. Просто вокруг него не было контуров, которые ловят такие действия. Дальше про эти контуры.

Какой бэкап реально спасает, и почему копия рядом с базой не считается?

Бэкап базы это не «когда-нибудь настрою». Это первый контур, без которого остальные не имеют смысла. Частота зависит от того, насколько живой проект. Статике хватит раза в неделю. Обычный проект просит ночной бэкап раз в сутки. А там, где крутятся оплаты и заявки, снимать стоит раз в несколько часов.

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

И ещё одно из практики. Когда что-то сломалось, бэкап не всегда самый быстрый путь назад. Часто проще откатить последний коммит в git и передеплоить, чем распаковывать архив. Но это работает, только если поломка в коде. Если уехали сами данные или умер сервер целиком, спасает именно полный бэкап в стороне. Поэтому держим оба пути. А про то, где вообще держать прод и базу, я разбирал отдельно в посте куда деплоить фронт и бэкенд.

Зачем агенту отдельная база для экспериментов?

Второй контур самый простой. У эксперимента не должно быть доступа к боевым данным. Звучит очевидно, но именно на этом горят чаще всего: «я только попробую на проде, по-быстрому».

Заведите отдельную базу для опытов. Пусть агент крушит её сколько угодно: пробует миграции (перестройку структуры базы), сносит таблицы, заливает мусорные данные. На боевой базе он не работает вообще, пока вы не проверили результат на отдельной. Это снимает главный страх новичка (стирается таблица пользователей с прода) и страх тех, кто опытнее (битая миграция ломает живых клиентов): ломать просто нечего, эксперимент идёт в песочнице.

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

Почему агенту дают права только на чтение?

Третий контур, самый недооценённый. У токена, которым работает агент (это ключ доступа к базе или сервису), должно быть ровно столько прав, сколько нужно для задачи, и ни каплей больше. Нужно почитать данные и собрать отчёт? Права на чтение, и только. В базе это право SELECT, без DELETE и DROP. Удалять и стирать этим ключом нельзя в принципе.

Вернёмся к истории с удалённым томом. Там агент нашёл в постороннем файле токен, который заводили под одну мелкую задачу, а прав у него оказалось на весь API, включая удаление. Один забытый всемогущий ключ, и девять секунд до катастрофы. Если бы у токена были только нужные права, удалять было бы нечем.

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

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

Три контура (бэкап в стороне, отдельная база для опытов, права только на чтение) звучат как много работы. На деле это настраивается один раз и дальше живёт само.

Я для своих проектов и проектов клиентов держу это как готовую среду: изолированное рабочее окружение, где отдельная база уже отделена от боевой, снимки базы (снапшоты) делаются сами каждые несколько часов, а доступы нарезаны по задачам. Агент работает внутри, и даже если он уверенно сделает худшее, откат это вопрос минут, а не бессонной ночи. Это снимает и риск, и сам холодок: спокойнее экспериментировать, когда знаешь, что откатишься.

Уговорами ИИ безопасным не сделать. Можно другое: уронить цену ошибки почти до нуля. Тогда агенту можно доверять смелые задачи, потому что любую его ошибку вы переживёте.

С чего начать сегодня

Не настраивайте всё разом. Начните с одного действия, которое закрывает самый большой риск: сделайте бэкап боевой базы прямо сейчас и положите его в сторону, не на тот же сервер. Пять минут, и у вас появилась точка возврата.

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

Страх сломать прод это нормально, у живого инженера он есть и работает. У ИИ его нет, и переучить его бояться нельзя. Зато можно сделать так, что бояться больше не нужно ни вам, ни ему: бэкап в стороне, песочница для опытов, минимум прав. Тогда любая ошибка агента это просто откат на пару минут назад.