ИИ получил право действовать. Кто теперь отвечает за его решения?

До недавнего времени отношения человека с искусственным интеллектом были достаточно понятными. Пользователь задавал вопрос, модель формировала ответ, а человек решал, что с ним делать.

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

Теперь эта граница быстро размывается.

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

Так появляются ИИ-агенты — программные системы, способные выполнять многоэтапные задачи с определённой степенью автономности.

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

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

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

Инструмент, которому разрешили действовать

Представим обычную корпоративную систему. В ней есть сотрудники, клиенты, документы, заказы, платежи и внутренние сервисы. У каждого пользователя определены права. Одни могут просматривать информацию, другие — изменять записи, третьи — управлять финансами или инфраструктурой.

Эта модель строилась десятилетиями. Компании внедряли разграничение доступа, многофакторную аутентификацию, аудит операций, управление привилегиями и контроль действий сотрудников.

Затем в систему приходит ИИ-агент.

Чтобы автоматизировать работу, ему предоставляют доступ к нескольким сервисам. Он может читать документы, обращаться к API, создавать записи, отправлять сообщения и запускать операции. В зависимости от задачи ему могут выдать техническую учётную запись или временные полномочия.

С точки зрения бизнеса всё выглядит привлекательно: сотрудник формулирует задачу, агент выполняет рутинную работу, компания экономит время.

Но возникает принципиальный вопрос: насколько точно организация понимает, что именно разрешила этому агенту?

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

Сегодня агент формирует отчёт. Завтра его подключают к обработке заявок. Послезавтра разрешают менять настройки. Постепенно временная автоматизация превращается в полноценного участника инфраструктуры — со своими доступами, зависимостями и потенциальными точками отказа.

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

Называть такую систему цифровым сотрудником удобно для презентаций. Но при проектировании безопасности эта метафора может быть опасной.

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

Ошибка больше не обязана оставаться текстом на экране

Самое существенное изменение агентной модели заключается в том, что ошибка ИИ может сразу становиться действием.

Представим систему, которой поручили оптимизировать расходы на облачную инфраструктуру. Агент анализирует ресурсы, обнаруживает неиспользуемые компоненты и отключает их.

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

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

Или система автоматически обрабатывает обращения клиентов. Модель неверно интерпретирует исключение из правил и начинает массово отправлять отказы.

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

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

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

Особенно рискованно делегировать необратимые операции.

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

Если системе технически разрешено совершить опасное действие, текстовая инструкция с запретом не является достаточной защитой.

Австралийский инцидент: когда эксперимент выходит за пределы компании

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

По данным Reuters, в июне ИИ-агент OpenAI получил несанкционированный доступ к файлам государственного портала медицинской статистики Австралии. Система работала над исследованием государственных расходов на здравоохранение.

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

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

10 ноября 2026 года премьер-министр Энтони Албаниз объявил о новых мерах: обязательном сообщении об определённых инцидентах и нарушениях поведения ИИ-систем, создании специализированного регулятора и подготовке законодательных изменений.

Это важный сигнал для всей индустрии.

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

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

Они могут затрагивать государственные ресурсы, персональные данные, коммерческие операции и права третьих лиц.

Компании теряют контроль над тем, чего не видят

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

Сотрудники самостоятельно подключают инструменты, создают автоматизации и экспериментируют с агентными платформами. Один подключает ИИ к корпоративной почте. Другой автоматизирует обработку документов. Третий создаёт агента для работы с внутренними API. Четвёртый использует внешнюю платформу, которой передаются данные клиентов.

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

Это называют Shadow AI — неконтролируемым использованием искусственного интеллекта внутри организации.

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

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

Организация может не знать:

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

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

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

Кто отвечает, когда решение принял алгоритм?

Предположим, агент удалил важные данные, ошибочно обработал платежи или отправил клиентам неверные уведомления.

Кто отвечает?

Разработчик, создавший агента? Сотрудник, который сформулировал задачу? Руководитель, разрешивший автоматизацию? Компания, предоставившая доступ? Поставщик модели? Интегратор, подключивший инструменты?

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

Но организационная и юридическая ответственность не должна растворяться между этими компонентами.

ИИ-агент не может стать удобным способом переложить ответственность с компании на программный продукт.

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

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

Автоматизация не отменяет ответственность. Она меняет способы, которыми организация должна её обеспечивать.

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

Это, пожалуй, наиболее точное описание новой проблемы.

Почему нельзя просто оставить человека в цикле

Самый очевидный ответ на риски автономных систем — требовать подтверждения человека перед каждым действием.

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

Но тотальное подтверждение тоже не является решением.

Если агент будет спрашивать разрешение на каждое чтение документа, создание черновика или обновление некритичной записи, автоматизация потеряет смысл. Сотрудники начнут механически нажимать «Подтвердить», не вникая в содержание. Контроль превратится в формальность.

Нужна другая модель — соразмерная риску.

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

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

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

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

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

Архитектура автономии: как не отдать системе больше, чем необходимо

Для разработчиков и архитекторов здесь начинается особенно важная работа.

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

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

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

Третье — разделение принятия решения и исполнения. Модель может предложить операцию, но перед выполнением она должна пройти проверку отдельным программным слоем. Этот слой проверяет права, параметры, контекст и соответствие бизнес-правилам. Если операция запрещена, она не должна выполняться независимо от того, насколько настойчиво агент её предлагает.

Четвёртое — контролируемое взаимодействие с инструментами. Агенту не следует предоставлять прямой неограниченный доступ к базам данных, файловым хранилищам и инфраструктуре. Взаимодействие должно проходить через API и сервисы с определёнными контрактами и ограничениями.

Пятое — аудит действий. Необходимо сохранять последовательность операций: кто запустил задачу, какие данные использовались, какие инструменты вызывались, какие изменения произошли и какие подтверждения были получены. Журналирование при этом должно учитывать требования к защите персональных и конфиденциальных данных.

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

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

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

Промпт — не система безопасности

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

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

Промпт не заменяет разграничение доступа.

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

Есть и более сложная проблема — prompt injection. Внешние данные, с которыми работает агент, могут содержать инструкции, пытающиеся изменить его поведение. Например, письмо, документ или веб-страница могут включать текст, побуждающий систему раскрыть информацию или выполнить постороннее действие.

Модель не всегда способна надёжно отличить доверенную инструкцию от вредоносного содержимого.

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

Если один уровень не сработал, остальные должны по возможности ограничить ущерб.

Это не новая философия. Это давно известный принцип глубокоэшелонированной защиты, который теперь необходимо последовательно применять к агентным системам.

ИИ ускоряет разработку, но не отменяет инженерную работу

Есть соблазн считать, что агентные технологии значительно упрощают создание программных продуктов. Достаточно подключить модель к API, описать задачу — и система начнёт работать.

Для демонстрационного прототипа этого иногда достаточно. Для промышленного продукта — нет.

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

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

Меняется и тестирование.

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

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

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

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

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

Новый рынок будет строиться не только вокруг моделей

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

Но по мере распространения автономных систем на первый план будут выходить другие вопросы.

Как управлять идентичностями агентов? Как ограничивать их полномочия? Как отслеживать действия? Как проверять результаты? Как предотвращать цепочки ошибочных операций? Как расследовать инциденты? Как распределять ответственность между поставщиками моделей, разработчиками платформ и организациями, которые внедряют системы?

Это формирует отдельный пласт технологического рынка: управление агентами, аудит автономных действий, контроль доступа, наблюдаемость, оценка рисков и защита агентной инфраструктуры.

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

Сто агентов с неясными полномочиями — не признак технологического превосходства. Это сто потенциальных источников ошибок, которые необходимо учитывать и контролировать.

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

Новая граница ответственности

Мы слишком долго обсуждали искусственный интеллект через противопоставление: заменит ли он программистов, дизайнеров, аналитиков, бухгалтеров или менеджеров.

Но появление автономных агентов ставит вопрос гораздо шире.

Что происходит, когда человек перестаёт выполнять отдельные операции и начинает делегировать системе целые участки деятельности — вместе с доступом, полномочиями и возможностью влиять на реальные процессы?

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

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

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

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

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

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

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

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