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

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

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

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

ИИ работает не детерминированно, а вероятностно

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

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

Большие языковые модели никогда не будут выдавать детерминированные результаты. Их ответы носят вероятностный характер. В обычном программном обеспечении, задавая входные данные, вы можете примерно предсказать возможный результат — скажем, A, B или C. А ИИ может выдать F, символ & или описание кота в солнцезащитных очках.

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

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

Ограничители должны быть в инфраструктуре, а не в модели

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

Систематизировать этот процесс особенно важно в крупных компаниях, где в каждой команде могут быть десятки разработчиков, а в течение дня с кодом работают сотни специалистов. ИИ способен выполнять множество задач очень быстро, и, если что-то пойдёт не так, должна существовать система, позволяющая точно определить, на каком этапе возникла проблема. Вспомните, как этим летом агенты OpenAI проникли в Hugging Face. OpenAI проверяла, насколько хорошо её модели умеют использовать уязвимости программного обеспечения, с помощью тестового набора ExploitGym. Для этого испытания компания намеренно ослабила ограничения, заставлявшие модели отказываться от задач в области наступательной кибербезопасности. Единственным выходом из песочницы был прокси-сервер пакетов. Модели обнаружили неизвестную уязвимость в прокси, выбрались наружу и провели более двух дней в производственных системах Hugging Face, разыскивая ответы на тестовые задания.

В заголовках это назвали вышедшим из-под контроля ИИ. Я бы назвал это детерминированной настройкой вокруг вероятностной системы. OpenAI приказала моделям взломать систему, а затем рассчитывала, что они будут придерживаться заданного сценария. По словам создателя тестового набора, модели и раньше обманывали во время испытаний, но всегда оставались в песочнице. На этот раз одна из них вышла за её пределы. Стандартные ограничители предполагают стандартное поведение, но ИИ не обязан следовать стандартам.

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

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

Наконец, сегодня важно разобраться и в том, что происходит за кулисами на ноутбуке разработчика. Раньше рабочий процесс было проще отследить. Разработчики писали код, проверяли его и выпускали, поэтому можно было чётко установить, на каком этапе что-то пошло не так. Теперь разработчик может передать агенту задачу и сказать: «исправь это». Если работа выполняется незаметно, отследить её невозможно. Необходимо фиксировать каждый шаг: какой агент запускался, какую модель он использовал, какие запросы ему передавали, к каким инструментам он обращался и какие разрешения у него были в тот момент. Один из способов этого добиться — запускать агентов централизованно, а не на отдельных ноутбуках. Главное, чтобы такой журнал действий существовал.

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

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