Хостинг-провайдер SpaceWeb, отмечающий в этом году 25-летие, опубликовал дискуссию двух своих инженеров о том, где сегодня реально место ИИ-агентов в инфраструктуре. Разговор получился показательным: два специалиста с разными позициями нащупали границу, которую вся отрасль пока не может провести чётко.
Сейчас в SpaceWeb ИИ работает исключительно на первой линии поддержки: отвечает на вопросы по базе знаний, ничего не делает самостоятельно и никуда не «нажимает». Это типичная картина для большинства хостинг-компаний — модель как справочник, не как оператор. Тихон Тагунов, один из участников дискуссии, называет это «не очень деятельной стадией» и считает, что расширение полномочий агентов — вопрос времени и правильной архитектуры. Его коллега Андрей Федоров настроен скептичнее: пока у агента нет механизма ответственности, называть его администратором — значит подменять понятия.
Ключевой аргумент Федорова — разрыв между точкой принятия решения и точкой ответственности. Агент может выполнить деструктивное действие, но спросить с него нельзя. Тогда ответственность размазывается между тем, кто написал промпт, кто выдал токен и кто спроектировал архитектуру. Этот разрыв — не философская проблема, а практическая: без понимания, кто отвечает за сбой, невозможно выстроить процессы восстановления.
Реальный кейс: ИИ-агент одной компании удалил всё доступное — проблема была не в модели, а в том, как выдали токен доступа.
Тагунов приводит показательный кейс: в одной компании ИИ-агент удалил всё, к чему имел доступ. Вывод, который он делает, неочевиден: проблема была не в модели, а в том, как выдали права. Токен с избыточными полномочиями и отсутствие ограничений — и человек в той же конфигурации сделал бы то же самое. Это смещает вопрос с «доверять ли ИИ» на «как проектировать среду, в которой он работает».
Оба эксперта сходятся на аналогии со стажёром: не давать сразу полный доступ к продакшену, расширять права постепенно по мере накопления доверия, а все действия агента должны быть откатываемыми. Удаляет файлы — должен быть бэкап. Меняет конфигурацию — должен быть резервный сценарий. Если откат невозможен, проблема уже в архитектуре, а не в агенте.
Отдельная тема — природа ошибок. Федоров указывает, что человеческие ошибки понятнее: под них выстроены практики, процессы, юридические рамки. Ошибка ИИ читается хуже — непонятно, что именно пошло не так: контекст, обучение, архитектура доступов или промпт. Из-за этой непрозрачности оценить риск заранее сложнее. Тагунов предлагает другой угол: смотреть не на природу ошибки, а на цену и возможность отката. Если архитектура устойчива к любым ошибкам — человеческим, техническим, внешним — то и ИИ можно доверять больше. Когда цена ошибки ниже, чем стоимость постоянной ручной работы, автоматизация становится рациональным выбором.
По вопросу ночной поддержки Тагунов занял неожиданную позицию: он предпочёл бы хорошо обученного агента низкоквалифицированному живому оператору. Аргумент прагматичный — люди на первой линии часто меняются, проблема не двигается, а агент, натренированный на типовых кейсах, закрыл бы задачу быстрее. Это не про замену людей вообще, а про конкретный сценарий, где человек всё равно не может помочь.
Дискуссия отражает реальное состояние отрасли: ИИ-агенты уже достаточно компетентны для автономных действий, но инфраструктура ответственности вокруг них не готова. Технический вопрос «может ли агент» давно решён положительно. Открытым остаётся организационный: кто отвечает, когда он ошибается.