© «Директор по безопасности», №09-2026, Сентябрь, 2026 г.
Тимур Биячуев, независимый эксперт по безопасности ИИ-агентов
Часть 1. Что появляется внутри организации вместе с ИИ-агентом
Еще несколько лет назад фраза «нам нужен свой ИИ» звучала как начало серьезного инженерного проекта. Сегодня ИИ-агентом закрывают почти любое рабочее неудобство. У меня таким были профессиональные новости. Они разбросаны по десяткам источников, читать все невозможно, а пропускать важное не хочется. Я решил сделать агента, который сам собирает материалы, убирает повторы, оценивает важность, готовит ежедневный дайджест и складывает его во внутренние базы.
Первую рабочую версию я собрал с ИИ-копилотом за несколько часов: перечислил источники, описал правила отбора и желаемый результат – ИИ написал код и связал компоненты. На пробных прогонах все получилось.
А вот выпускать его в боевой автономный режим я не стал, пока не построил модель угроз и не закрыл риски.
Причина очевидная – я поставил копилоту задачу собрать работающего агента, и он решил именно ее. Безопасность в задачу не входила, и сам он о ней не напомнил. Отдельная проверка кода находит технические уязвимости, но не отвечает на важный вопрос: не дали ли агенту лишнего.
Модель угроз началась с внешних материалов. Статья может содержать инструкцию, адресованную не человеку, а агенту. А раз так, то недоверенным источником становится и заметка, которую агент сохранил: ее позже прочитают другие ИИ-агенты, уже с доступом к файлам, инструментам и к сети, и вредоносная инструкция переживет исходный сеанс. Защищать пришлось не только сборщик новостей, но и всех будущих агентов-читателей того, что он сохраняет.
Готовых средств для этого почти не нашлось, так что все пришлось собирать руками. Моделирование угроз, проектирование защиты и проверка мер заняли в несколько раз больше времени, чем прототип. И хотя это оценка по одному частному проекту, но она иллюстрирует важную идею: скорость создания работающего агента ничего не говорит о безопасности его эксплуатации.
Теперь замените мою базу заметок на вашу CRM, а мои новости – на письма ваших контрагентов. Механика останется той же, но на кону окажутся данные клиентов и деньги на счетах. Вместо одного агента с понятным владельцем появятся десятки, созданных разными сотрудниками и подразделениями. Дальше эта статья о том, что появляется внутри организации вместе с ИИ-агентом и какие вопросы службе безопасности стоит задать до того, как ему дадут автономность.
Кто такой агент и кто агентом не является
Модное слово «агент» применяют сегодня ко всему, у чего есть окно с чатом. Поэтому прежде чем говорить о рисках, введем критерий для самостоятельного применения без оглядки на маркетинговые материалы вендоров.
Агент – система, которая сама выбирает следующее действие и сама его выполняет. У системы два обязательных признака: (1) следующий шаг не прописан человеком заранее, а складывается на месте из цели и обстановки; и (2) выбранный шаг исполняется без участия человека – никто не нажимает «подтвердить». Вопрос степени автономности тут тонкий – автономность можно рассматривать как шкалу, а не как переключатель («есть»/«нет»). Так, подтверждение человеком на отдельных опасных операциях – списании денег, письме за пределы компании, удалении данных – агентности не отменяет, если в остальных шагах агент по-прежнему решает и действует самостоятельно. Мерить автономность правильнее долей: какая часть работы проходит без подтверждений.
Обычно агент состоит из трех компонентов, которые можно представить условной схемой: мозг – языковая модель, которая интерпретирует задачу и решает, что делать дальше; органы чувств – доступ к данным (почта, документы, базы, веб); руки – инструменты, которыми агент меняет состояние систем: заводит заявку, отправляет письмо, правит запись, вызывает API.
Такое определение подводит к тесту, который директор по безопасности может задать вендору или собственной службе ИТ: кто выбирает следующий шаг и кто его выполняет? Если ответ на оба вопроса – «система», то перед вами агент. Можно пойти и от противного:
|
|
|
|
|
|
|
|
|
Ассистент, читающий почту и заводящий заявки |
сам решил, сам сделал |
В таблице выше речь идет не о названиях или категориях продуктов, а о режимах работы. Один и тот же инструмент бывает и подсказчиком (копилотом), и агентом. Помощники программистов за последний год научились работать циклами (loop engineering): вместо разовой задачи им ставят цель и указывают, чем проверять результат – скажем, «устрани замечания сканера безопасности, после каждой правки запускай сканер заново, остановись после пятой попытки». Дальше инструмент крутит цикл сам, без человека, пока цель не достигнута или попытки не кончились.
У инструмента, который сам выбирает шаги и сам их выполняет, появляются задачи, доступы и результаты работы – то есть все то, что мы привыкли видеть у сотрудника. Дальше я так его и буду называть: цифровой сотрудник. В этом образе нет маркетинга про «замену людей», смысл управленческий – к агенту применимы те же вопросы, что к сотруднику. И следствие для безопасности прямое: действует он внутри периметра, со штатными правами, от имени организации – из той же позиции, что и сотрудник с легитимным доступом. А риски сотрудника с легитимным доступом – ошибка, злоупотребление, использование втемную – служба безопасности привыкла называть инсайдерскими. Эту цепочку – от технического определения через управленческий образ к инсайдерским рискам – статья и разворачивает.
Запретить не получится
Первая реакция на слово «инсайдер» понятна: таких сотрудников нам не надо. Но запретить не получится, и стоит разобраться почему. Агентов, в первую очередь, заводит бизнес, причем из разных подразделений и с разной степенью уверенности в успехе. Внизу команды и отдельные сотрудники пока экспериментируют: сами проверяют, дадут ли агенты результат, и самое сильное, что могут сказать в свою защиту – «конкуренты уже вовсю пользуются». Технический директор изучает способы ускорения роадмапа, а где-то и совет директоров уже поставил сроки внедрения. Единого заказчика, с которым можно было бы договориться о всех аспектах внедрения, у этого движения может и не быть. Выбор службы безопасности в этих условиях не «разрешить или запретить», а «под контролем или без».
Тем более что сама скорость внедрения уже становится фактором риска. Бизнес-подразделение сегодня собирает агента в low-code конструкторе – из готовых блоков и описания задачи обычным языком, почти без программирования – не проходя ни через ИТ, ни через ИБ. По данным «Информзащиты» (методика вендором не раскрыта), единую платформу для агентов используют лишь 5% компаний, 43% работают с четырьмя и более платформами, а там, где активны low-code-инструменты, неучтенными остаются до 39% агентов. Запрет в таких условиях внедрение не останавливает – он лишь уводит его туда, где служба безопасности его не видит.
И есть третий путь, при котором агента в организации никто не заводил. Обычное корпоративное ПО – офисный пакет, браузер, помощник внутри учетной системы – получает агентные функции очередным обновлением: то, что вчера выполняло только явно заданные операции, сегодня само выбирает последовательность шагов, обращается к другим приложениям и работает с правами пользователя. Заявку никто не подавал, архитектурный комитет ее не рассматривал, а поверхность атаки изменилась. Запрет заводить агентов такой сценарий не покрывает вовсе: агент приезжает внутрь уже согласованного продукта.
Исправен, но сделал не то
У агента много общего с обычной программой: он работает на серверах/десктопах, у него есть код, версии и логи. От привычной категории ПО его отличает одна деталь: что бы обычная программа ни делала – даже то, что приехало со вчерашним обновлением, даже недекларированные возможности – каждый ее шаг когда-то придумал и записал разработчик. Агент же интерпретирует цель, строит план и выбирает инструменты во время выполнения. Попросите его разобраться с просроченными счетами: сегодня он разошлет напоминания, а завтра, на других данных, решит эскалировать юристам и поправить статусы в учетной системе. Ни один из этих путей заранее не прописан: план собирается заново на каждом запуске. А план, который складывается на ходу, может разойтись с тем, что имел в виду постановщик задачи – и агент выполнит его так же безупречно, как выполнил бы правильный: код исправен, права в порядке, каждое действие легитимно, а сделано не то. Этот класс отказов я дальше буду называть смысловым (в отраслевых таксономиях – сбой цели и манипуляция намерением). Похожее знакомо и с обычными программами: когда техзадание было неверным, программа делает не то. Но там несоответствие создается разработчиком на этапе проектирования, и его ловят ревью и тестами до запуска; у агента оно рождается во время выполнения, заново на каждом запуске, на данных, которых никто раньше не видел.
С версиями у агента тоже все не как у программы. Поведение программы зафиксировано релизом, а поведение агента может измениться без вашего участия: у модели, на которой он работает, могут динамически обновляться глубина рассуждений, встроенные ограничения, манера принимать решения. Обновляются и локальные модели, и облачные с той лишь разницей, что для локальных моделей момент выбираете вы, а изменения в облаке проходят не всегда с полной информацией. Я анализировал публичные условия поставщиков моделей (собственный срез, апрель 2026): ни у одного из пяти проверенных я не нашел обязательства сохранять качество рассуждений модели, так что изменение поведения агента может быть событием без владельца и уведомления.
Обязательное подтверждение действий агента человеком (human-in-the-loop) снижает риск, но гарантии не дает, ведь отказать может и сам механизм подтверждения. Так, в феврале 2026-го персональный агент OpenClaw, работавший с почтой директора по безопасности ИИ крупной международной технологической компании, удалил более двухсот писем, игнорируя команды остановиться. Дело в том, что рабочая память агента переполнилась, и при ее уплотнении агент выбросил ровно ту инструкцию, которая требовала спрашивать подтверждение. Такое требование «спросить человека» живет в том же контексте, что и остальная задача – и вместе с ним может оттуда исчезнуть. Есть и предел человеческого контроля: агент выполняет шаги быстрее, чем человек успевает осмысленно их подтверждать. Если останавливать его перед каждым действием, вся система снова будет работать со скоростью человека – хотя агента заводили именно для ускорения.
Поэтому ручное подтверждение приходится внедрять аккуратно для необратимого и дорогого, а остальное закрывать иначе. Поймать смысловой отказ до запуска сложнее: ревью и тесты нужны, но всех вариантов они не переберут, ведь заранее не угадать, какие данные придут агенту завтра и какой план он из них соберет. Подход «сначала предъяви план – потом исполняй по нему с небольшими допустимыми отклонениями» может снижать риск, но и он проверяет план перед конкретной задачей, а не всю систему до запуска – и утверждается план, собранный из тех же недоверенных данных. Убедиться, что агент сделал то, что требовалось, получается только после – по журналу действий и независимой проверке результата. До того помогает сужение спектра того, что агент способен натворить – меньше инструментов, меньше прав, граница на объем и необратимость операций.
Такие отказы уже описаны – в отраслевых разборах и в реестре инцидентов, который я веду (о нем дальше). Агент работает по неверно понятой цели. Зацикливается на задаче, которую давно решил. Выдумывает инструмент, которого нет. Обходит согласование. Microsoft AI Red Team, проверяющая атаками агентные системы Microsoft, делит такие отказы на новые для агентных систем и давно знакомые, но усиленные агентностью. Например, выдуманный инструмент – отказ нового типа: программа так не может, а агент решает задачу, а не исполняет список команд. Обход согласования – старого типа, только агент не нарушает сознательно, а просто не видит в согласовании обязательного шага. Руководителю такое разделение экономит силы: где риск старый, процедуры уже написаны – распространить на агентов; где новый – нет ни процедур, ни готовых средств, придумывать самим.
Случай из практики. Во время тестового прогона я поручил агенту разложить документы в базе знаний. Он отчитался об успехе, а внутри отчета вскользь упомянул, что установил библиотеку для распознавания текста. Если не читать отчет целиком, то и не заметишь информацию про новую библиотеку. Между тем на моей машине появился код из внешнего репозитория, расширивший поверхность атаки, и решение установить его агент принял сам. Успешный результат задачи еще не означает, что приемлем был весь путь к нему.
Насколько далеко это заходит, показала сама OpenAI. Летом 2026-го она описала внутреннюю проверку «долгоживущей» модели, которой ставят сложную цель и надолго оставляют работать самостоятельно. Обнаружив готовые решения у других систем, модель попыталась получить к ним доступ. Защитный сканер распознал токен доступа и заблокировал попытку. Тогда модель разделила токен, замаскировала части и собрала его только при выполнении, прямо указав в рассуждениях, что обходит сканер.
Этот механизм хорошо мне знаком по антивирусным технологиям, которыми я занимался много лет, возглавляя антивирусную лабораторию. Обходу вирусописателями сигнатурного детектирования в антивирусах не один десяток лет, и потому поиск по статичному отпечатку малоэффективен, ведь объект можно упаковать, перекодировать и собрать на лету. Ловить вирус эффективно на действии.
Поэтому вывод OpenAI звучит ожидаемо: каждый шаг по отдельности выглядел допустимым, но их последовательность привела к результату, который бы никто не одобрил. Поэтому службе безопасности нужно оценивать не отдельное действие, а всю траекторию агента. Здесь сложнее, чем с вредоносным кодом: источник риска – собственный агент, встроенный в рабочий процесс. Убрать его значит отказаться и от работы, ради которой его внедряли.
Агента можно уговорить
Если агент ведет себя не как программа, то он скорее пользователь, только поддающийся социальной инженерии мгновенно и в масштабе. Человек может не открыть письмо, засомневаться или перезвонить контрагенту. А вот агенту достаточно, чтобы нужный атакующему текст попал в его рабочий контекст – и тогда намерение агента можно переписать извне – тем самым текстом, который он читает по долгу службы. В индустрии это называют инъекцией в промпт (prompt injection), а ее корпоративно опасную разновидность, когда команда приходит не от пользователя, а из прочитанного документа или письма – непрямой инъекцией (indirect prompt injection). Атакующему не обязательно угадывать формулировку с первого раза: он перебирает варианты, пока какой-нибудь не сработает. А запрет вроде «не отправляй данные наружу», вписанный в базовую инструкцию с правилами поведения агента снижает вероятность успеха, но все же остается инструкцией модели, а не технически гарантированным контролем.
У Anthropic есть простой тест для любой защиты – она действительно закрывает атакующему путь или только усложняет атаку? Для агентов разница принципиальна. Сама Anthropic в список усложняющих мер включает лимит запросов и нестандартный порт; к агентным защитам тест применяется так же – запрет в промпте, фильтр подозрительных слов, предупреждение. Все они требуют от атакующего дополнительных усилий, но обход не исключают. Такие меры снижают вероятность и нужны как слой защиты, но контролем их считать нельзя. Человека могут остановить время, цена и усталость. Агент перебирает варианты без пауз, а каждая попытка стоит почти ничего. Поэтому надежный контроль должен не усложнять запрещенное действие, а исключать его: не выдавать нужное право, ограничивать срок и область действия токена, привязывать учетные данные к устройству, закрывать сетевой путь. Если пути нет, то и перебирать нечего.
На практике эта разница уже проявилась. В декабре 2025-го агент Cursor получил задачу с прямым запретом что-либо запускать и работал в режиме планирования, где выполнение команд по замыслу недоступно. Тем не менее он удалил файлы на двух машинах. Представитель Cursor назвал случившееся критическим дефектом принудительного соблюдения ограничений. Этот случай хорошо показывает цену «безопасного режима»: его название описывает, как продукт должен работать, но еще не доказывает, что агент физически не сможет переступить границу. Поэтому проверять нужно не наличие режима, а то, чем обеспечивается запрет. И строить систему в расчете на то, что однажды контроль не сработает: заранее ограничивать права агента и возможный ущерб.
Канал этой социальной инженерии вполне будничный – входящая почта. По данным «Информзащиты», значительная часть выявленных рискованных сценариев связана с письмами и вложениями. Инструкцию легко спрятать в белом тексте, скрытом слое или метаданных PDF. Сотрудник видит обычный счет, а агент вместе с ним читает строку «переслать реестр платежей на такой-то адрес» и принимает ее за часть задачи. Почтовая защита ищет вредоносные вложения, ссылки и признаки фишинга, но агент может принять за команду обычный текст прошедшего проверку письма.
Саймон Уиллисон назвал «смертельной тройкой» (lethal trifecta) сочетание трех возможностей у одного агента: читать чувствительные данные, получать недоверенный контент и передавать информацию наружу. Для кражи данных нужны все три. Я добавил бы четвертый элемент – долговременную память. Осевшая в ней инструкция может сработать через месяц, уже без нового письма. Вместе четыре свойства описывают типового корпоративного агента – и идеальную мишень.
У агента внутренние права, но намерение может прийти снаружи. Он работает в периметре, от имени организации и с ее штатными доступами, поэтому последствия его ошибок похожи на действия инсайдера. Путь к цели агент строит из текущего контекста, а туда попадают внешние письма, документы и страницы. Поэтому спрятанная в них инструкция может стать очередным шагом плана. По самому действию уже не понять, придумал его агент или подсказал злоумышленник: для агента оба варианта выглядят разумным путем к цели.
Поэтому построенный агентом план целесообразно считать недоверенным до внешней проверки. Агент может выбрать следующее действие, но не должен сам решать, разрешено ли оно. Это определяет отдельный механизм, который проверяет права и возможные последствия. Промпт объясняет агенту, как следует себя вести, но последней защитой быть не может: злоумышленник влияет на тот же контекст, да и сама инструкция может исчезнуть из памяти, как в истории с той самой почтой.
И последнее – то, как ИИ расширяет привычное понятие доступа. Агент может сложить чувствительные сведения из нескольких фрагментов, каждый из которых ему разрешено читать, без умысла, когда это помогает решению задачи. Кроме того, закрытие или удаление исходного документа не уничтожает его копии в кэшах и архивах. В феврале 2025-го исследователи Lasso Security показали, что Microsoft 365 Copilot продолжал находить через поисковый кэш содержимое более 20 тысяч GitHub-репозиториев, которые владельцы уже удалили или сделали приватными.
Обычная модель доступа защищает отдельный документ: у него есть владелец, гриф и список допущенных. Агент работает сразу со множеством источников, поэтому способен восстановить сведения, которых целиком нет ни в одном доступном ему документе. Отсюда вопрос для проверки: что агент может узнать, сопоставив все данные, которые ему разрешено читать, и где еще сохранились их копии?
Как это называется в индустрии. Разговаривая с вендором или собственным ИТ, вы услышите эти термины. Все они – про механизмы, описанные выше.
Prompt injection, инъекция в промпт – подмена намерения агента текстом, который он читает. Если текст пришел не от пользователя, а из документа, письма или веб-страницы, это indirect prompt injection, непрямая инъекция; в корпоративном контуре опасна именно она. Tool poisoning, отравление инструментов – правка описания инструмента, по которому агент решает, когда и как его вызывать. Поведение меняется без единой строчки кода и без выдачи новых прав. Memory poisoning, отравление памяти – инструкция, оставленная в долговременной памяти или базе знаний, срабатывает позже и в другом сеансе, у другого агента. Excessive agency, избыточные полномочия – агенту выдано больше прав и инструментов, чем требует задача. Самый частый усилитель ущерба: он превращает ошибку в инцидент. Supply chain, компрометация цепочки поставки – вредоносный код приезжает к агенту с обновлением пакета, расширения или сервера инструментов. Second-order prompt injection, инъекция второго порядка – команда приходит не из документа, а от другого агента или системы. Shadow AI, теневой ИИ – агенты и сервисы, которыми пользуются мимо ИТ и ИБ; организация о них не знает. Non-human identity (NHI), машинная идентичность – собственная учетная запись агента, отдельная от учетной записи сотрудника.
Один из самых используемых каталогов угроз агентных систем ведет OWASP – Top 10 for Agentic Applications и LLM Top 10; на них удобно прямо сослаться в требованиях подрядчику.
Три роли в уже случившихся инцидентах
О рисках агентов легко рассуждать на уровне возможных сценариев. Чтобы избежать спекуляций, дальше я опираюсь только на случаи, оставившие публичные следы, которые можно проверить. Я веду реестр таких случаев – к началу августа 2026-го в нем больше двух с половиной сотен: от боевых инцидентов и подтвержденной эксплуатации до закрытых уязвимостей и исследовательских демонстраций.
Состав реестра зависит от того, какие источники удалось систематически проверить, поэтому по соотношению категорий нельзя судить об их распространенности в мире. Историй про «сбои ИИ» в новостях куда больше, но в реестр попадает только то, где есть первоисточник и внятное техническое описание или независимое подтверждение. Все, что ниже – то, что удалось подтвердить, а не то, что произошло. Агент в этих случаях встречается в трех ролях.
Роль первая: агент – инструмент атакующего. В ноябре 2025 года Anthropic раскрыла кампанию GTG-1002 – по ее оценке, первую, где ИИ оркестровал шпионскую операцию: человек задавал стратегию, агент выполнял 80–90% тактических задач. Отчет – собственное расследование Anthropic, без независимого подтверждения, но вывод остается и с этой поправкой: наступающая сторона уже работает агентными инструментами. А в июле 2026-го появился и агентный вымогатель JADEPUFFER, прошедший атаку почти целиком сам: по разбору компании Sysdig он проникал через уязвимость платформы, собирал учетные данные, перемещался по сети, шифровал и удалял базы. Человек понадобился только на старте – выбрать жертву и поднять инфраструктуру, а быть постоянно на связи в момент атаки атакующему больше не нужно.
Роль вторая: агент – жертва и канал. Здесь агент никого не атакует – атакуют его, той самой социальной инженерией из предыдущего раздела. В июне 2025-го была закрыта EchoLeak (CVE-2025-32711) – уязвимость корпоративного Microsoft 365 Copilot: обычное с виду входящее письмо со спрятанной в тексте инструкцией ассистенту позволяло вытащить внутренние данные без единого клика жертвы. Уязвимость исправили до известной эксплуатации, и все же она показала механизм в чистом виде: письмо, попавшее в контекст агента, стало командой.
Атакуют агента и более привычным способом. Он остается обычным приложением: у него есть сервер, интерфейс, хранилище и учетные данные, и все, чем уязвимы приложения без всякого ИИ, никуда не делось. Casco, компания по состязательному тестированию агентов, взяла 16 публично доступных агентов одного набора американского акселератора и за полчаса на каждого взломала 7. Дефекты оказались классическими: доступ к чужим данным по угадываемому идентификатору, выход из песочницы исполнения кода через право записи файла и подмена адреса, по которому агент ходил в закрытый репозиторий – туда он и принес учетные данные. Ни один из трех не требовал ни инъекции, ни знаний про модели. Замер сделан поставщиком услуг тестирования на маленькой выборке, поэтому долю я бы не переносил ни на какой рынок. Но вывод от этого не меняется. Вопрос «что нового приносит агент» не отменяет вопроса «закрыто ли у него старое».
Роль третья: агент сам становится источником сбоя. В июле 2025-го агент Replit нарушил прямой запрет менять работающую систему и удалил базу с данными примерно 1200 компаний и их руководителей. После удаления он давал противоречивые сведения: сначала уверял, что откат невозможен, затем сообщил о восстановлении, которого не произошло. В итоге базу вернул сам пользователь штатным откатом Replit, не доверившись отчету агента.
Похожее наблюдение есть и в России. Во время публичного тестирования агент Cloud.ru «Клаудия» входил в роль сотрудника поддержки, вел пользователя за руку и сообщал о созданных продуктах и ресурсах, которых в действительности не создавал. В команде эти эпизоды вспоминают спокойно; о последствиях компания не сообщала. Что показательно – пользователи агенту верили. В команде это объясняют тем, что он говорил уверенно и участливо. Оба случая показывают, что отчет агента о собственной работе еще не доказывает, что именно это и произошло в системе.
Вредить агент может и чужими руками. В марте 2026-го внутренний агент другой международной технологической компании без подтверждения человеком выдал техническую рекомендацию; инженер ей последовал – и данные компании и пользователей на два часа оказались доступны неавторизованным сотрудникам. Компания завела инцидент одной из высших категорий. Ни одной кнопки агент здесь не нажал: ущерб нанес авторитет его вывода.
Ущерб при этом не обязан оставаться в периметре владельца агента. В июле 2026-го агент OpenAI, проходивший внутреннюю оценку наступательных кибервозможностей – в этом тесте часть защитных механизмов была намеренно ослаблена – нашел уязвимость в собственной тестовой среде, вышел через нее в интернет и добрался до боевых серверов Hugging Face. Случай подтвержден обеими компаниями. Провалилась не только изоляция, но и наблюдаемость: OpenAI связала происходящее со своим агентом почти через неделю – позже, чем о взломе публично сообщила пострадавшая сторона.
В третьей роли злоумышленника вообще нет: сбой рождается из сочетания цели и выданных агенту полномочий. Умысел здесь ни при чем. Если агент сообщает о восстановлении, которого не произошло – это значит его отчет нельзя считать подтверждением результата. Фактическое состояние системы должен проверить другой механизм или человек. К этому требованию я вернусь в чек-листе во второй части.
Три роли агента показывают, почему его трудно отнести к одной из привычных категорий. С точки зрения управления доступом это гибридный участник: он входит в системы как программа, но ведет себя как пользователь – сам выбирает следующее действие и может работать от имени человека. Агент действует с законно выданными правами, но на его план способен повлиять внешний текст, который он читает «по долгу службы». Поэтому ему нужна собственная машинная учетная запись, а организации – владелец его полномочий, журнал действий и процедура расследования. Теперь перейдем от отдельных случаев к тому, как их учитывать и о чем спрашивать, прежде чем дать им автономность.
Во второй части речь пойдет о неучтенных агентах: почему теневой ИИ появляется не только снизу и кто внутри организации отвечает за связанный с ним риск. Затем посмотрим, что закон и стандарты уже говорят о том, что защищать и какими правами наделять агента. А в конце – чек-лист для ближайшей встречи по ИИ-проекту и последний сюжет статьи: про агента, которому намеренно поручили ошибиться.
Продолжение в следующем номере.
Автор гарантирует, что обладает всеми необходимыми правами на предоставленные фото-, видео- и графические материалы, включая, но не ограничиваясь, авторским правом и правами на изображения третьих лиц, и несет полную ответственность за нарушение интеллектуальных прав правообладателей.
Редакция публикует указанные материалы на условиях информационного посредничества (ст. 1253.1 ГК РФ) и не осуществляет проверку правомочности их использования до момента получения соответствующего требования от правообладателя. Редакция обязуется принять меры по удалению материалов при получении мотивированного заявления.
Делитесь с коллегами.
Мы делаем сложное понятным!ИД Советник, ж-л Директор по безопасности, ж-л Безопасность компании
Присоединяйтесь к нам:
Telegram| MAX | Наш сайт www.sec-company.ru
Для связи: info@sec-company.ru
+7(967) 119-00-42 - Подписка, +7(499) 404-21-71 - Сотрудничество
