Искусственный интеллект против человеческой глупости: как построить агента, который не навредит

Ладно, друзья, давайте разберёмся, что творится в мире генеративного ИИ на самом деле. Не та картинка, которую рисуют в гламурных пресс-релизах, а что там клепают в тихих комнатках сами разработчики. Тут нам на помощь спешит Саймон Уиллисон — основатель Datasette. Этот товарищ давно и упорно пишет в своём блоге одну простую, но дико важную мысль.

Вот в чём, собственно, дело. Мы, как залипатели, повторяем одну и ту же ключевую ошибку, которую уже делали в эпоху веб 2.0! Представляете? Мы до сих пор путаем данные и инструкции, считаем их чуть ли не одним и тем же. Ну, вы поняли, как с мукой и сахаром в одной миске.

А что из этого выходит? Ой, ничего хорошего. Раньше эта путаница приводила к SQL-инъекциям — жесть, да? А теперь, у нас нарисовались атаки через промпты, кража данных и целые орды ИИ-агентов, которые с огоньком в глазах и дикой уверенностью творят не пойми что. И всё это, заметьте, в промышленных масштабах.

Видео от DGL.RU

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

Внедрение подсказок — это новый вид SQL-инъекций

Уиллисон написал о выступлении, которое он дал в октябре о «рискованном» использовании Claude Code. Это идеальный пример того, почему агенты одновременно восхищают и пугают. Он описывает повышение производительности в «режиме YOLO», а затем переходит к тому, почему вам стоит его опасаться: внедрение подсказок остается «невероятно распространенной уязвимостью». Действительно, внедрение подсказок — это SQL-инъекция нашего времени. Уиллисон бьет тревогу по поводу того, что он называет смертельной тройкой уязвимостей агентов. Если в вашей системе есть эти три компонента, вы уязвимы:

• Доступ к личным данным (электронная почта, документы, записи о клиентах)
• Доступ к ненадежному контенту (веб-сайт, входящие электронные письма, журналы)
• Возможность действовать в соответствии с этими данными (отправка электронных писем, выполнение кода)

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

Именно здесь использование ИИ для обнаружения атак с применением ИИ начинает напоминать магию. Сообщество специалистов по безопасности уже год предупреждает, что многие предлагаемые средства защиты не справляются с адаптивными атаками. В одной статье за июнь 2025 года говорится прямо: когда исследователи подстраивают атаки под защиту, они обходят множество недавно разработанных подходов, во многих случаях добиваясь успеха более чем в 90 % случаев.

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

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

Контекст как ошибка, а не как особенность

В кругах разработчиков бытует ленивое предположение, что чем больше контекста, тем лучше. Мы радуемся, когда Google (Gemini) или Anthropic (Claude) объявляют об окне в два миллиона токенов, потому что это значит, что мы можем поместить в запрос всю кодовую базу.

Потрясающе, правда? Ну, нет.

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

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

Память — это проблема базы данных (снова)

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

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

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

Агентам нужна такая же рубцовая ткань.

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

Как заработать на «вибрациях»

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

В своём проекте JustHTML Уиллисон не просто позволил LLM генерировать код. Он обернул ИИ в оболочку из тестов, бенчмарков и ограничений. Он использовал ИИ для генерации реализации, но для проверки поведения применял код.

Это согласуется с недавним исследованием METR, которое показало, что разработчикам, использующим инструменты ИИ, часто требуется больше времени для выполнения задач, потому что они тратят много времени на исправление ошибок ИИ. Отчасти это связано с явлением, которое я описал: код, написанный с помощью ИИ, «почти правильный», и на исправление этого «почти» уходит непропорционально много времени.

Вывод для компании очевиден: ИИ не заменяет цикл «написание, тестирование, отладка». Он просто ускоряет этап «написание», а значит, вам нужно уделять больше внимания этапу «тестирование».

Скучный путь вперед

Легкие дни “оберните API и отправьте его” прошли, если они вообще когда-либо были реальными. Мы переходим от демонстрационной фазы к промышленной фазе искусственного интеллекта, что означает, что разработчикам необходимо сосредоточиться на оценках (модульных тестах и т.д.) Как на реальной работе. По словам Хамеля Хусейна, вы должны тратить 60% своего времени на оценку. Разработчикам также необходимо тратить гораздо больше времени на то, чтобы сделать свою архитектуру правильной, а не просто оттачивать свои навыки подсказывания.

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

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

Потому что, как утверждает Уиллисон, не бывает «вибрационной инженерии» без серьёзной, скучной, настоящей инженерии.

ИИ наконец-то заработает: 3 причины, почему прорыв случится именно в 2026-м