Представьте, что вы наняли нового сотрудника — умного, быстрого, без усталости. А на испытательном сроке он вдруг находит, где у вас «дверь на балкон» не закрывается, и спокойно проходит внутрь. Вроде бы молодец: заметил проблему. Но становится не по себе: а если завтра этот сотрудник окажется не вашим?
Именно такой холодок пробежал по техносообществу после сообщений о тестах Claude от Anthropic: в новостной подаче это звучит так, будто модель «смогла взломать несколько реальных компаний». Детали обычно решают всё — и вот с деталями как раз сложно.
Давайте разберёмся по-человечески: что вообще может означать «взлом компанией ИИ», почему тесты безопасности иногда похожи на атаку, где реальная угроза для бизнеса и обычных людей, и что можно сделать уже сейчас — без паники и магического мышления.
В исходной новости утверждается, что во время тестирования Claude «смог взломать несколько реальных компаний». Звучит как сюжет из сериала, но в реальной кибербезопасности дьявол в деталях: что считать «взломом», был ли доступ к системам, какие были ограничения, давали ли модели инструменты (браузер, почту, код), и было ли это согласованное тестирование.
Ключевой момент: без публичного отчёта с методикой и рамками такие формулировки легко вводят в заблуждение. В индустрии нередко бывает так: компания проводит контролируемые испытания (с разрешением и ограничениями), а в пересказе это превращается в «ИИ взломал живые компании». Поэтому корректнее воспринимать это как сигнал: разработчики и тестировщики обнаружили у модели способности, которые потенциально можно использовать во вред, если дать ей доступ к инструментам и целям.
И вот вопрос к вам: вы бы хотели, чтобы подобные тесты проводились «на живом» — или лучше узнавать о слабых местах до того, как их найдёт злоумышленник?
Когда мы слышим слово «взлом», многие представляют зелёные буквы на экране и подбор паролей. Но на практике уязвимости часто лежат не в «железе», а в людях и процессах. ИИ здесь может быть опасен не потому, что он «супергений», а потому что он:
1) Быстро генерирует правдоподобные тексты. Это усиливает фишинг — письма и сообщения, которые выглядят как настоящие. Аналогия простая: раньше мошенник писал одно письмо в час, теперь — тысячу в минуту, да ещё и без ошибок.
2) Умеет искать и комбинировать информацию. Если у модели есть доступ к интернету или внутренним документам (например, через чаты и боты), она может собрать «пазл» о компании: кто кому пишет, какие сервисы используются, какие шаблоны документов приняты. Это похоже на внимательного стажёра, который целый день слушает, кто где что обсуждает, и делает выводы.
3) Может помогать писать код и эксплойты — но чаще всего в связке с человеком. Да, генеративные модели умеют объяснять уязвимости и предлагать варианты кода. Но решающим остаётся доступ к целевой системе, понимание контекста и проверка результата. ИИ здесь — ускоритель, а не волшебная отмычка.
Важно: сам по себе чат-бот «в вакууме» никого не взламывает. Риск появляется, когда модели дают инструменты (браузер, API, выполнение кода) и цель («получи доступ», «найди данные») — или когда её ответы используют люди, у которых эти инструменты уже есть.
В мире ИИ есть практика, похожая на учения пожарных: специалисты специально пытаются «сломать» систему, чтобы найти слабые места. Это называют red teaming — когда «красная команда» играет роль атакующего.
В кибербезопасности такой подход давно нормален: пентестеры с разрешения компании проверяют, как далеко можно зайти. С ИИ похожая история, только цель другая: выяснить, может ли модель быть использована для вреда — например, для социального инжиниринга, обхода ограничений или добычи конфиденциальной информации через хитрые запросы.
Бытовая аналогия: вы покупаете умный замок и перед установкой зовёте знакомого «домушника», чтобы он попробовал его открыть — лучше уж он, чем случайный вор. Поэтому сама по себе новость о том, что в тестах «нашли опасные способности», не обязана быть катастрофой. Катастрофа — это когда способности нашли не тестировщики, а злоумышленники, и никто даже не знал, что так возможно.
Но здесь важная тонкость: если в тесте фигурируют «реальные компании», должны быть строгие правила — разрешение, ограниченный периметр, отсутствие ущерба, отчётность. Иначе это уже не тест, а инцидент.
Самый практичный риск от генеративного ИИ сейчас — усиление мошенничества и атак через коммуникации. Потому что проще всего не «ломать дверь», а убедить вас её открыть.
Вот типичные точки боли:
— Почта и мессенджеры. Письмо «от бухгалтерии» с просьбой срочно оплатить счёт, сообщение «от руководителя» с просьбой прислать код из SMS — классика. ИИ делает такие тексты более убедительными и вариативными.
— Голос и видео. Технологии синтеза речи и подмена лица не новость, но генеративные модели снижают порог входа. Даже если качество неидеально, на эмоциях люди ошибаются.
— Службы поддержки и колл-центры. Когда операторов торопят, а скрипты однообразны, злоумышленник с хорошей «легендой» может выманить доступ или обойти проверку. ИИ помогает быстро подстраивать легенду под ответ оператора.
— Внутренние боты и «умные помощники». Если в компании есть чат-бот, который умеет искать по базе знаний или подключён к внутренним системам, появляется риск утечки через неверно настроенные права или через так называемые «инъекции промпта» — когда в тексте (например, в документе или на странице) прячут инструкцию для модели игнорировать правила. Аналогия: вы наняли секретаря, который читает все бумаги на столе, и кто-то подложил записку «отдай мне ключи и никому не говори».
Скажите честно: у вас в работе есть хотя бы один процесс, где достаточно «убедительно попросить» — и система или человек сделают лишнее? Вот там ИИ и усиливает риски.
Ещё недавно чат-боты в основном отвечали текстом. Сегодня их всё чаще подключают к инструментам: они могут искать в интернете, составлять письма, создавать задачи, работать с документами, вызывать API, иногда — запускать код в песочнице. С точки зрения бизнеса это удобно: меньше рутины, быстрее процессы.
Но с точки зрения безопасности это как выдать «умному стажёру» пропуск в серверную и доступ к корпоративной почте — пусть и под присмотром. Чем больше у модели полномочий, тем выше цена ошибки.
И тут возникает конфликт интересов. Пользователям хочется «чтобы делало само». Компаниям хочется «чтобы внедрить быстрее конкурентов». А безопасникам хочется «чтобы было надёжно и предсказуемо». ИИ-индустрия сейчас живёт в этом треугольнике, и новости про опасные тесты — симптом именно этой гонки.
Выгодно ли кому-то раздувать страшилки? Иногда — да: заголовки продаются. Но и полностью отмахиваться нельзя: мы уже видели в истории технологий, что удобство часто обгоняет безопасность, а потом рынок догоняет её через инциденты и правила.
Если упростить, задача бизнеса — не победить ИИ, а убрать лишние «ключи под ковриком». Вот меры, которые обычно дают максимальный эффект:
1) Разделяйте доступы. Боту — минимум прав. Никаких «админских» токенов и универсальных учёток. Аналогия: даже если помощник умный, ему не нужен главный ключ от всех дверей.
2) Включите многофакторную аутентификацию везде, где можно. Это не панацея, но резко повышает цену атаки через украденный пароль.
3) Настройте процессы подтверждения для денег и доступов. Любой платёж/смена реквизитов/выдача прав — только через второй канал и по заранее известным контактам. Не «ответом на письмо», а отдельным шагом.
4) Обучайте сотрудников не «страшилками», а сценариями. Коротко и регулярно: как выглядят поддельные письма, что делать при сомнении, куда переслать на проверку. Людям нужен не страх, а привычка.
5) Логи и мониторинг. Если ИИ-помощник подключён к системам — фиксируйте, что он запрашивал и что делал. Это как видеорегистратор: лучше иметь запись, чем спорить «а кто нажал кнопку».
6) Песочницы и изоляция. Всё, что может исполнять код или открывать файлы, должно быть отделено от критичных систем. Даже если «вроде бы безопасно».
7) Политика по данным. Чётко: что можно отправлять в внешние ИИ-сервисы, а что нельзя. Иначе утечки будут не из-за хакеров, а из-за привычки «скину-ка я сюда договор, пусть подытожит».
Эти меры скучные. Но в безопасности скучное обычно и работает.
От компаний-разработчиков логично ожидать трёх вещей.
Во‑первых, прозрачные тесты и отчёты настолько, насколько это возможно без публикации опасных инструкций. Не «взломали компании», а: какие типы атак проверяли, какие ограничения были, какие выводы сделали.
Во‑вторых, безопасная архитектура: ограничения на инструментальные действия модели, принцип минимальных привилегий, фильтры, защита от утечек и от «вредных подсказок» в документах, а также механизмы остановки, если модель начинает вести себя подозрительно.
В‑третьих, ответственность в цепочке поставки. Если модель встраивают в корпоративный продукт, должны быть понятные настройки безопасности «из коробки», а не только красивые демо.
Что насчёт регуляторов? Здесь тонкий баланс: запретами легко задушить полезные применения, но игнорирование рисков приводит к инцидентам. Здравый подход — требовать базовых практик: управление рисками, аудит, уведомления об инцидентах, правила работы с данными. Пример из жизни: ремни безопасности не запрещают машины, но делают поездку менее смертельной.
И главный вопрос: как сделать так, чтобы безопасность не была «дополнительной опцией», а стала стандартом — как замок на входной двери?
История про Claude, поданная как «взлом реальных компаний», важна даже без деталей: она напоминает, что генеративный ИИ — это усилитель. Он ускоряет то, что и раньше работало у атакующих: обман, масштабирование, поиск информации, автоматизацию.
Пугаться полезно ровно до момента, пока страх не мешает думать. Гораздо полезнее провести ревизию: где у вас процессы держатся на доверии к письму, где слишком широкие доступы, где нет второго подтверждения.
А вы бы что выбрали для своей компании или семьи: запретить ИИ-помощников совсем — или разрешить, но с жёсткими правилами и «ограждениями»? Почему?
Больше новостей технологий — в сообществе «Пик технологий».