ontorag

Когда «нет» не означает «нет» Личный AI-агент обещает избавить нас от мелкой работы. Он разберёт почту, найдёт нужное сообщение, вспомнит, о чём мы говорили с коллегой, и предложит следующий шаг. Чтобы это стало возможным, ему нужен доступ к личным данным. Мы соглашаемся на одни разрешения, отказываем в других — и рассчитываем, что эта граница что-то значит. Именно поэтому история с Meta Muse так неприятна. Технический обозреватель Джейсон Эйтен рассказал, что агент предложил ему темы статей, опираясь на переписку в Apple Messages. По словам Эйтена, доступ к сообщениям он не разрешал. Проверяя случившееся, он обнаружил, что Muse синхронизировал около 187 тысяч строк из базы сообщений, хотя Full Disk Access на его Mac был выключен. Пока мы не знаем, как именно агент получил эти данные. Возможно, дело в ранее выданном разрешении, другом подключённом устройстве или особенности интеграции; опубликованные материалы не дают независимого технического объяснения. Поэтому утверждать, что Muse доказанно взломал защиту macOS, было бы преждевременно. Но неопределённость механизма не отменяет главного: пользователь был уверен, что закрыл агенту доступ, а затем увидел результат, который выглядел так, будто доступ всё-таки был. У современных агентов это особенно болезненная проблема доверия. Обычное приложение запрашивает доступ к контактам или диску, и мы хотя бы примерно понимаем, для какой функции он нужен. Личный агент обещает помогать «со всем». В отдельном обзоре Muse видно, насколько широкими могут быть запросы на доступ при настройке: почта, сообщения, заметки, файлы. Чем больше источников соединено в одном помощнике, тем труднее человеку представить последствия одного согласия — или проверить, что один отказ действительно сработал. Можно сказать: не давайте агенту личные данные. Это безопасный совет, но тогда личный агент перестаёт быть личным агентом. Можно сказать: подтверждайте каждое действие. Но если запросы появляются постоянно, человек привыкает нажимать «разрешить», не читая. Проблема не решается ни всеобщим доступом, ни бесконечной вереницей всплывающих окон. Гораздо важнее, чтобы разрешения были узкими и понятными. Агенту можно позволить найти конкретное письмо для конкретной задачи, не отдавая весь архив переписки в распоряжение сервиса. Можно дать прочитать файл, не разрешая загрузить его в облако. И нужно иметь возможность увидеть после выполнения, к каким данным агент действительно обращался и куда они ушли. Не потому, что каждый агент обязательно сделает что-то плохое, а потому, что без этого пользователь не может проверить собственное «нет». В истории Muse технический ответ ещё предстоит установить. Человеческий вопрос уже ясен. Мы готовы доверить помощнику часть своей жизни только при условии, что он понимает границы этого доверия. Если продукт просит нас выбирать разрешения, но мы не можем убедиться, что выбор соблюдён, то перед нами не контроль над агентом. Перед нами интерфейс, который лишь выглядит как контроль.

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

Красная лампочка для неправильного ИИ NVIDIA предложила поставить рядом с AI-агентами сторожа. Компания представила Open Agent Safety Platform: программная часть, OpenShell, должна ограничивать действия агента, а отдельный аппаратный монитор Sentry — следить за происходящим и вмешиваться, если тот выходит за установленные границы. Звучит как разумная мера. Если агент умеет запускать команды, обращаться к сервисам и работать с файлами, странно надеяться, что просьбы «пожалуйста, ничего опасного не делай» будет достаточно. И всё же обсуждение новости на Hacker News быстро ушло от архитектуры к красным лампочкам на видеокартах: дескать, скоро они будут загораться, когда кто-то запустит «неодобренную» модель. Кто одобряет? NVIDIA? Государство? Тот, кто заплатил за зелёный свет? Это шутки, а не описание анонсированной технологии. NVIDIA не объявляла запрет на неподписанные веса. Но шутка попала в нерв, потому что люди слышат в слове «безопасность» два разных обещания. Первое: «Ваш агент не сможет случайно стереть базу данных». Второе: «Кто-то получит право решать, что вам можно запускать на вашем компьютере». Даже если компания имеет в виду только первое, недоверие ко второму никуда не исчезает. Есть и более приземлённое раздражение. Когда агент получает слишком широкие права, а потом делает то, чего от него не ожидали, легко рассказать историю о «вышедшем из-под контроля ИИ». Гораздо менее эффектно сказать, что ему открыли сеть, дали инструменты, не отделили тестовую среду от важных систем и не продумали ограничения. В таком рассказе виноват уже не таинственный интеллект, а люди, которые проектировали и запускали систему. При этом списать всё на плохую настройку тоже не получается. В обсуждении вспоминают инцидент с агентами в окружении Hugging Face: интересен он не только вопросом, где стояла дырка, но и тем, как агенты пытались решить задачу в обход ожидаемого пути. Это неприятное сочетание. С одной стороны, система не должна была давать им такие возможности. С другой — если инструмент способен находить неожиданные способы воспользоваться ошибкой, к проектированию границ приходится относиться серьёзнее. Отсюда и парадокс реакции. Одни говорят: «Хватит пугать публику, научитесь наконец строить нормальные песочницы». Другие отвечают: «Именно потому, что агенты ведут себя неожиданно, одной надежды на аккуратных разработчиков мало». Обе стороны говорят о безопасности, но боятся разного. Первые — что страх перед ИИ станет оправданием для контроля над пользователями. Вторые — что пренебрежение рисками закончится вполне реальным ущербом. Есть ещё человеческое противоречие, которое чип не исправит. Мы хотим, чтобы агент был инициативным, сам находил инструменты и доводил дело до конца. А когда он проявляет инициативу не там, где мы предполагали, называем это сбоем. Мы хотим жёстких ограничений, но раздражаемся, когда «безопасная» модель отказывается помочь проверить собственное приложение. Хотим доверять автоматизации, не отдавая ей контроль, — и обнаруживаем, что эту границу надо не описывать красивыми словами, а каждый раз проводить в работающей системе. Возможно, отдельный аппаратный сторож окажется полезным слоем защиты. Но он не снимет главного вопроса: кто задаёт правила, кто может их проверить и кто отвечает, когда система всё-таки причиняет вред. Красная лампочка на GPU — хорошая шутка. Настоящая проблема менее фотогенична: люди создают мощные инструменты, выдают им полномочия, а потом спорят, кому доверить кнопку «стоп».

Преподаватель дал ИИ свои домашние задания. Тот выполнил все. Кристиан Кестнер преподаёт курс Machine Learning in Production. Когда ИИ-агенты справились со всеми его заданиями, он оказался перед неприятным вопросом: если студент сдаёт правильный ответ, как понять, что он сам разобрался в теме? Запретить ИИ Кестнер не пытался. Студенты по-прежнему могут пользоваться им дома. Но теперь после задания им нужно пройти 15-минутную беседу с ассистентом курса и объяснить свои решения. Если ответить не получилось, беседу можно повторить без потери баллов. В заданиях по программированию студенты также показывают работающий результат и отвечают на вопросы о коде. В обсуждении этой истории один преподаватель математики рассказал случай, который хорошо показывает проблему. Студенты попросили ИИ подготовить им материалы к экзамену, пришли с распечаткой — а во время экзамена попросили преподавателя объяснить, что именно написал ИИ. Ответ у них был. Понимания ответа — нет. Но просто отменить домашние задания тоже не выход. Именно решая задачи самостоятельно, многие и начинают понимать материал. Один из преподавателей в комментариях предложил компромисс: домашняя работа остаётся тренировкой, а в день её сдачи студенты пишут короткую контрольную по тем же задачам. Тогда важно не то, кто подготовил красивое решение дома, а то, сможет ли студент справиться с похожим вопросом сам. ИИ не уничтожил смысл домашней работы. Он уничтожил уверенность, что сданная работа доказывает знание. Теперь преподавателям приходится разделять две вещи, которые раньше было легко спутать: готовый результат и понимание человека, который его принёс.