Код ИБ Екатеринбург 2026: тезисы, записи и презентации

Сергей Марков (ПАО Сбербанк) подчёркивает: ИИ — это область науки и технологий для автоматизации интеллектуальных задач, и сама технология нейтральна. Как молотком можно заколачивать гвозди или разбивать головы, так и ИИ в кибербезопасности может использоваться и защищающимися, и атакующими. Автоматизированные системы для атак, аудита, выявления уязвимостей и защиты применяются очень давно, поэтому прогресс не стоит воспринимать как мгновенный скачок: часто агентные системы просто проверяют то, до чего у людей не доходили руки.

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

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

Интерес проявляют и промышленность, и малый-средний бизнес, но есть опасения: многие уже «накололись» на красивые обещания разработчиков и ищут доверенный контур. Ассоциация совместно с федеральным центром компетенции Минпромторга собирает верифицированные кейсы — их более ста, в том числе в каталоге Минцифры. Через региональные центры компетенций (РЦК) при правительствах ассоциация помогает пройти бесплатный аудит и определить процессы для автоматизации; если готового решения нет, задача передаётся разработчикам.

Евгений Зеваков (Zevakov Labs) отмечает: экономические сложности диктуют первоочередные задачи — секретарские функции, документооборот и всё, что с ними связано. Но хайп вокруг агентов приводит к запросам от руководителей: почему часть работы до сих пор делают люди? Если полгода назад звучало «заменим 5 секретарей на 2», то сейчас спрашивают: «у нас 10 инженеров-экологов, можем ли оставить 3 и сделать систему, которая сама готовит экологическую экспертизу?»

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

На вопрос о готовых решениях Вячеслав Касимов ответил, что есть два пути. Первый — найти готовое решение: интеграторы уже предлагают «AI-файрволы», у кого-то они работают, у кого-то нет. Второй — сделать самому. В любом случае нужно понимать особенности своей инфраструктуры и использования ИИ. Если речь о внешних моделях, крайне нежелательно, чтобы в них попадала чувствительная информация, поэтому нужен шлюз. Но если обращение идёт через веб, разницы с обычным уходом на Google Диск может не быть: в компании и так должен работать DLP. Не нужно выращивать из ИИ «могучую химеру» — это такое же приложение, просто с другими алгоритмами. Можно переиспользовать накопленные процессы защиты.

Евгений Зеваков добавляет: организационные меры сами по себе бесполезны, нужны технические. Его команда планирует выпустить в open source библиотеку для обезличивания данных и юридического оформления, включая ведение реестра по требованиям Роскомнадзора. Внешних готовых решений мало; часто это допиленное решение Microsoft, адаптированное под российские данные, но есть риск пропустить важное из-за особенностей русского языка. Своё решение вполне реально.

Для объектов КИИ, где обрабатываются персональные данные, действует мультипликатор ответственности: контроль идёт и по линии ФСТЭК (187-ФЗ), и по 152-ФЗ. Если ИСПДн является ещё и объектом КИИ, будьте готовы, что на вас направят взор сразу два регулятора.

Речь о требованиях 127-го и 1119-го постановлений Правительства и приказе ФСТЭК № 21. Ответственность есть как по КоАП, так и по Уголовному кодексу. Лица, работающие с такими объектами, больше подвержены рискам, чем ответственные за обработку данных в базовой ИСПДн, где речь идёт только о 152-ФЗ и КоАП.

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

Поручение по части 3 статьи 6 закона о персональных данных должно обеспечивать защиту данных по статье 19, и рекомендуется фактически проверять защищённость: на практике виновным признавали оператора, когда вход в его ИСПДн был возможен через уязвимость подрядчика. То же с облачными решениями: при использовании, например, облачного решения 1С по кадрам отвечает оператор, а контрагент — только перед ним.

Ключевой вектор надзора Роскомнадзора — мероприятия по контролю без взаимодействия с контролируемым лицом. Они регулируются постановлением № 1046, а не 248-м ФЗ, и проводятся без уведомления: о проверке оператор узнаёт из требования об устранении нарушения со сроком 10 рабочих дней. Неисполнение грозит ответственностью, чаще всего по части 1 статьи 13.11 КоАП.

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

Также выявляется отсутствие политики обработки персональных данных и избыточные сроки: согласие на 75 лет избыточно, к тому же при передаче документов в архив действие 152-ФЗ прекращается. Для распространения данных нужно отдельное согласие по приказу Роскомнадзора № 18.

Строгое требование части 5 статьи 18 закона о персональных данных: при сборе персональных данных хранение и последующая обработка должны обеспечиваться с использованием баз данных на территории Российской Федерации. Любое иное решение — автоматический триггер для выявления нарушения и основание для дела по части 8 статьи 13.11 КоАП, где штраф для юрлиц измеряется в миллионах.

Отдельно стоит вопрос Google форм: их использование формально не запрещено, но хранение идёт на иностранных серверах (данные из России отправляются на сервер в Ирландии), то есть фактически используется иностранная база данных. Это также триггер для дела по части 8 статьи 13.11 КоАП.

Требования 149-го федерального закона по способам авторизации на сайте уже действуют, и таких способов четыре: номер телефона, госуслуги, единая биометрическая система либо российская информационная система. Вход через иностранные сервисы — Apple ID, аккаунты Google — под запретом.

За это введён состав по статье 13.55 КоАП. В отличие от статьи 13.11 здесь есть различие по процедуре: протокол также составляет Роскомнадзор, но рассматривает материалы старший государственный инспектор — должностное лицо Роскомнадзора.

Сценарий игры — собирательный, из реальных инцидентов. Вы управляете кризисным штабом вымышленного сервиса, принимающего заказы в приложении и на сайте, а подрядчик сервиса поддерживает портал обратной связи и выгрузку данных. В 9:00 появляется сообщение о продаже клиентской базы: в открытом доступе образец на 200 строк с персональными данными, и он совпадает с частью клиентских обращений.

Штабу нужно ограничить доступ к данным, сохранить доказательства и определить безопасный режим работы бизнеса, указав конкретный ограничиваемый доступ и способ проверки результата. Инцидент считается выявленным в 9:00.

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

Второй принцип — не смешивать установленный факт и оценку. К 12:00 в журнале 48 тысяч строк, но подтверждены лишь 200 строк образца, а сколько людей затронуто — неизвестно. Именно от этого разделения зависит объём проверки, который запускает штаб.

Штабу нужно подготовить сообщение объёмом до 60 слов, определить канал публикации, подписанта и следующую контрольную точку, учесть обращения клиентов и риск мошеннических сообщений. В игре клиенту приходит SMS со ссылкой на оплату и фразой про «компенсацию за утечку»: клиент должен понимать, какой канал легитимный и куда переходить не стоит.

Команда, защищавшая решение, честно назвала принятый риск: частичная приостановка сервиса, изменение поведения пользователя, возможное падение числа заявок. Клиентам сообщили о сложностях, не став их обманывать.

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

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

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

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

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

Новая обязанность: если субъект КИИ получает информацию о компьютерных атаках и инцидентах, связанных с функционированием объектов КИИ другого субъекта, он обязан проинформировать НКЦКИ не позднее 12 часов с момента получения такой информации. Обмен с иностранными и международными организациями осуществляется через НКЦКИ, за исключением случаев, предусмотренных отдельными нормативно-правовыми актами и международными договорами Российской Федерации.

Приказ 547 определяет сроки направления материалов в НКЦКИ. Для субъектов КИИ при наличии значимых объектов КИИ срок направления информации о компьютерном инциденте — 3 часа. Для иных объектов КИИ — 24 часа. Срок направления информации о компьютерных атаках — 24 часа. Для руководителей государственных органов срок информирования о компьютерных атаках и инцидентах — 24 часа.

Если проектом плана реагирования предусмотрено привлечение подразделений и должностных лиц ФСБ России, проект плана и изменения направляются не в головное подразделение ФСБ России, а в Центр защиты информации и специальной связи ФСБ России. Если план не содержит необходимости привлечения сотрудников ФСБ, копия плана направляется в НКЦКИ в течение семи календарных дней после утверждения.

Приказ 548 устанавливает правила непрерывного взаимодействия с ГосСОПКА для субъектов КИИ, а также для руководителей государственных органов и организаций. Непрерывное взаимодействие осуществляется посредством подключения к технической инфраструктуре НКЦКИ. Субъекты КИИ, имеющие значимые объекты КИИ, а также государственные органы и организации обязаны подключиться к инфраструктуре НКЦКИ.

Ранее используемые каналы, такие как почтовые электронные адреса и обычная почта, используются только при наличии технических сбоев или отсутствии связи с личным кабинетом. Подключение осуществляется после заключения регламента взаимодействия; порядок описан на сайте ГосСОПКА.ру. Сейчас действует упрощенный порядок заключения регламента — посредством присоединения.

Понятия «событие ГосСОПКА» не существует; есть термины «компьютерная атака» и «компьютерный инцидент». На примере ДДОС-атаки на публичный сайт, когда ресурсы в локальной сети не пострадали, нужно уточнить, было ли нарушено функционирование сайта. Если да — это компьютерный инцидент, если нет — компьютерная атака. Если сайт или DNS-сервер является частью объекта КИИ, информация направляется в установленные сроки; если не является, обязанности нет, но НКЦКИ рекомендует направлять сведения для общей картины и предупреждения других субъектов.

СОК обнаружил 50 тысяч попыток эксплуатации уязвимости маршрутизаторов, но успешных эксплуатаций нет — это компьютерная атака. При наличии последствий событие становится компьютерным инцидентом. Уведомления о компьютерной атаке необходимо направить в НКЦКИ.

Моментом обнаружения компьютерного инцидента считается выявление последствий или начало мер реагирования. Если специалисты изначально обнаружили факты несанкционированного доступа или изменение конфигурации, но изменения не зафиксированы, моментом обнаружения считается выявление несанкционированного доступа. Если ресурсы на аутсорсинге у центра мониторинга ГосСОПКА и центр выявил атаку в 2 часа ночи, а сообщил в 8 утра, временем начала считается 2 часа ночи — время выявления центром ГосСОПКА.

Если вывод объектов из строя произошел по вине собственных сотрудников, уведомлять НКЦКИ нужно, но в форме следует указать, что инцидент произошел не в результате компьютерной атаки. По блокировке IP: блокировать можно и даже нужно, но НКЦКИ проверяет вовлеченность ресурсов; если при добавлении адресов отваливаются рабочие ресурсы, нужно проинформировать НКЦКИ и вместе принять решение. Для расследования могут понадобиться логи межсетевого оборудования, межсетевых экранов, контроллеров домена или другого оборудования; единого алгоритма нет.

9-е управление ФСТЭК России занимается учётом автоматизированных систем, включая государственные информационные системы. Создана и прошла проектную эксплуатацию информационно-аналитическая система «Кречет», к которой будут подключать всех субъектов КИИ со значимыми объектами и органы государственной власти. ФСТЭК уже рассылает рекомендации, в том числе обязательные в силу 250-го указа Президента, по устранению уязвимостей и работе с фишинговыми атаками. В 239-й приказ, скорее всего, со следующего года внесут изменения: субъекты КИИ будут в обязательном порядке предоставлять такие же сведения, какие сейчас по 117-му приказу предоставляют органы государственной власти.

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

Учётные записи с паролями должны соответствовать требованиям парольной политики. Каждое предприятие разрабатывает свою политику, но она должна соответствовать методикам, в том числе разработанным ФСТЭК. При проверке ФСТЭК смотрит, разработана ли политика, сверяет её с методическими документами; если она не соответствует показателю, присваивается ноль. В ходе контрольных мероприятий могут подойти к любому автоматизированному рабочему месту, подключённому к информационной системе, и проверить вход-выход по количеству знаков и выполнение требований парольной политики. Многофакторная аутентификация привилегированных пользователей и администраторов — слабое место на многих предприятиях: лучше всего требование выполняется в энергетике, хуже всего — в оборонно-промышленном комплексе. Предоставляются сведения о сервисных учётных записях, в том числе при привлечении подрядных организаций и аутсорсинге. При самооценке нужны подтверждающие документы; при контрольных мероприятиях ФСТЭК составляет таблицу, но по умолчанию считается, что всё проверено.

Организации могут привлекать сторонние компании для проверки и сканирования информационной системы. Предприятия непрерывного цикла могут сканировать уязвимости только после остановки работ; ФСТЭК обычно согласовывает такие работы с работодателем, но организация может и отказать. В силу 250-го указа Президента ФСТЭК рассылает рекомендации по уязвимостям; все субъекты со значимыми объектами учтены, а дополнительными запросами ФСТЭК получает сведения о наличии программного обеспечения и определяет, какая уязвимость по какому продукту опасна для предприятия. Проверяются межсетевые экраны на периметре и их настройки, средства антивирусной защиты со снимками экрана панели управления и централизованным управлением, защита от отказа в обслуживании и DDoS (при доступе к информационным системам должен быть договор). Централизованный сбор событий безопасности должен быть на всех устройствах; принимаются только CIM-системы.

Условная компания — один из крупнейших федеральных ритейлеров: 45 тысяч сотрудников, 750 магазинов, распределительная сеть комплексов. Склады заполнены, компания вложила много денег в маркетинговую акцию, до старта «чёрной пятницы» считанные часы. Потери от кибератаки могут составлять от 30 до 50 миллионов в час. Штабы включают ключевые роли: CEO, CISO, CIO, CTO, коммерческого директора и другие функции. В каждом штабе есть инсайдер, играющий на стороне конкурента; генеральный директор инсайдером быть не может. В трёх раундах штаб получает новую информацию и четыре варианта ответа, на обсуждение — 5 минут, финальное решение принимает генеральный директор. Затем нужно восстановить цепочку атаки по пяти вопросам и вычислить инсайдера.

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

Участники видели обращения к новым доменам, зарегистрированным менее суток назад и ранее не встречавшимся в инфраструктуре. EDR не реагировал и не классифицировал угрозы. Затем пять рабочих устройств начали с похожей периодичностью обращаться к неизвестным доменам, которые постоянно менялись. За 15 минут корпоративный сервер отправлял аномальное количество DNS-запросов к недавно появившимся доменам. В третьем раунде появились необычно длинные DNS-запросы с меняющимися поддоменами и неизвестный процесс на нескольких устройствах; одно устройство принадлежало сотруднику с доступом к конфиденциальной информации.

DGA (Domain Generation Algorithms) — технология автоматической генерации доменов для связи с C2-инфраструктурой. DNS-туннелирование почти не отличается от VPN- или TLS-туннелей, но отследить связь между хостами традиционными СЗИ не представляется возможным.

В сценарии вокруг настоящего инцидента были ложные следы. 80 000 DNS-запросов генерировал легитимный сервис веб-аналитики, а проблемы с корпоративным VPN были связаны с изменением парольной политики. Эти события выглядели как значимые аномалии и могли отвлечь штаб от главного сценария. Участникам предлагалось решить, что могло ложно отвлечь от фокуса главного сценария: обращение одного устройства к новым доменам, пять устройств с похожими обращениями, аномальное количество DNS-запросов корпоративного сервера или появление неизвестного процесса. Это подчёркивает необходимость отделять отвлекающие маневры от истинной причины атаки.

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

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

Резервное копирование защищает от аппаратных и программных сбоев, ошибок и злонамеренных действий персонала и от шифровальщиков, но спасает только данные, а не инфраструктуру. Рекомендуется подход 3-2-1: три копии на носителях двух разных типов, причём одна копия должна отчуждаться — храниться не там, где лежат основные данные.

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

В схеме полного резервирования Active-Active нет выделенной основной или резервной площадки: существует два или более ЦОДов, все информационные системы и приложения работают одновременно на всех площадках, данные синхронизируются в режиме реального времени. При аварии на одной из площадок балансировщик перераспределяет нагрузку на оставшиеся — перерыва в работе критичных систем не замечается.

Помимо отсутствия простоя, подход позволяет без деградации переносить пиковые нагрузки и проводить плановые работы без остановки систем.

Площадки должны быть надёжными и иметь сертификацию — как правило, рассматривается уровень Tier-3. Для локальных инцидентов — пожара, перебоев энергоснабжения, отказа сетевого узла — достаточно разнести основную и резервную площадки на 15–20 км; в каждом городе RTCloud обычно строит по две такие площадки: в Москве это Data Space и ЦОД Останкино, в Новосибирске — ЦОД в ЦИТ на Николаево и центр хранения данных на Менделеево.

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

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

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

За прошлый год увеличили штрафы, и появилось обязательство фактически для всех обработчиков персданных регистрироваться в реестре. Ужесточились требования уголовного законодательства в части защиты персданных. Действует требование локализации: базы данных и системы обработки должны располагаться в границах Российской Федерации. Согласие теперь нужно брать отдельно на каждый случай.

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

По практике с начала года большинство спотыкается на хранении данных: зарубежные хостинги постепенно уходят в прошлое, а сторонние сервисы-метрики и формы интеграции — нет. Был прецедент, когда претензии предъявили из-за того, что сайт организации обращался за шрифтами в Google: прямые ссылки на зарубежные сайты проверки Роскомнадзора выявляют автоматизированно. Штрафы серьёзные, а решение банально — изучить собственный сайт.

Обсуждается появление реестра ЦОД: Минцифра ведёт реестр ЦОД, применимых для размещения государственных информационных систем, в том числе КИИ. Есть мнение, что аналогичные рекомендации появятся и для персданных уровня защищённости 1 и 2, — владельцам медицинских систем и специальных категорий персданных стоит обратить на это внимание.

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

Многие компании пользуются аутсорсингом — бухгалтерией, кадрами, системами обучения. В этой схеме вы выступаете оператором, передающим персданные обработчику, поэтому таких контрагентов стоит проверить и указать им на недостатки, чтобы не получать жалоб от сотрудников и клиентов.

Отдельный момент — компании, ведущие большие акции и создающие много сайтов под них, особенно в ритейле: эти сайты тоже должны соответствовать требованиям, а рук часто не хватает. Можно добавить доменные имена в проверку и контролировать их регулярно. По уничтожению персданных профильных проверяющих решений на памяти спикера нет — обычно работает бюрократический подход: комиссия, указание систем, скриншоты об удалении, отчёты и акт уничтожения; техническая проверка возможна скорее со стороны ФСТЭК.

Помимо риска кибератак существует и нормативная база: различные указы и законы, среди которых спикер отдельно выделил 152-ФЗ, 187-ФЗ и приказ ФСТЭК России №117 — именно на последнем он остановился подробнее.

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

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

Второй уровень — базовый процесс повышения уровня осведомлённости: проводится обучение и тестирование, штат время от времени проверяют на то, насколько сотрудники ведутся на угрозы, фишинг и так далее.

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

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

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

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

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

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

Спикер также развёл функции обучения и контроля: обучение в идеале должно лежать на HR, имитация атак и планирование материалов — на ИБ, при этом само обучение входит и в зону ИБ, и в зону HR.

Модель, к которой спикер пришёл на опыте, делится на несколько уровней. Самый дешёвый — отказ: нейросети не используем, ноль затрат (но для автоматизации всё равно потребуется писать скрипты и код). Далее — публичные данные: их можно отправлять хоть в DeepSeek в браузере, например запрос «создай должностную инструкцию для IT-инженера». Следующий уровень — общий корпоративный чат с маскированием: туда не попадают API-ключи и персональные данные, маскирование выполняется на стороне Cloud.ru, а со Сбербанком компания прикрыта договором и NDA. Выше — локальная модель, поднятая на собственном GPU в облаке. Самый дорогой и сложный в разворачивании вариант — всё в собственном контуре, на своём сервере.

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

В компании около 1000 человек, прирост использования общего чата — порядка 150% в месяц. После добавления более сложных и дорогих моделей люди стали ходить в чат чаще, и один программист «насидел» 25 тысяч рублей за месяц, программируя через Opus. Никого не ругали, но договорились: программировать — в DeepSeek + VS Code (за свои деньги работает космически хорошо), а архитектуру писать в дорогих моделях небольшими контекстами и промптами.

Также внедрили шлюз и ограничение по токенам — 2,5 млн: «домохозяйка» с запросом про бухгалтерский документ этот лимит никогда не выберет, а программист, выбравший его, на этот месяц закончил работу. Для сравнения: пересчёт модели GLM5.3 через Cloud.ru дал бы 505 тысяч рублей в месяц на одного программиста, тогда как вся компания тратит около 20 долларов в день.

Сервер за миллион рублей с двумя видеокартами 40-90 работает почти три года: он development, но частично тянет и production; для секретного кода — разработки датчиков и программирования микроконтроллеров — его хватает 2–3 программистам. Перед покупкой дорогого железа (речь может идти о сервере за 16 миллионов) нужно считать загрузку. Пример: бухгалтерия работает 8 часов в день, из них 3 часа загружает PDF в локальную модель, то есть сервер отработает 3 часа из 24 — такой сервер не нужен, лучше пусть будет очередь на машину за миллион.

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

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

Сейчас компания строит собственную экосистему — ЦУП, центр управления «полётами» ИИ. Когда агентов много (один генерирует презентации, другой — юридический бот, третий занимается тендерами), зоопарк инструментов на серверах становится неуправляемым: нужно, чтобы в контуре всё было описано, где надо — ограничено и разграничено, посчитано, с метриками — кто использовал, как, зачем и сколько это стоило.

После выстрела ChatGPT в 2023 году в России появились так называемые ChatGPT-врапперы — сервисы, дающие доступ к ChatGPT с большим маркапом. Они сосредотачивались на коммерциализации доступа и не учитывали реальные запросы компаний: отказоустойчивость, интеграцию, безопасность персональных данных и информационную безопасность.

Всех волновал вопрос: поговорить с ChatGPT можно, а как применить это в компании? Ответом стал RAG (Retrieval Augmented Generation): нужная информация находится в документах компании и поставляется в контекстное окно, а ChatGPT начинает «думать», что знает про компанию, хотя отвечает лишь на основании переданных сведений. RAG стал манифестом, а главными вопросами — «под капотом RAG или не RAG» и избавляет ли RAG от галлюцинаций. Параллельно появились GPTs от OpenAI (сейчас проект закрыт) и всеобщее увлечение промпт-инжинирингом — вплоть до курсов и требований такого опыта в вакансиях.

Первый скачок 2024 года — мультимодальность: ChatGPT работал только с текстом, а новые модели научились распознавать изображения и голосовые, что важно для поддержки, куда клиенты часто присылают скриншоты ошибок.

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

Третье — агенты. В отличие от чат-бота, агент «дергает за ручки в реальном мире»: вызывает конкретную систему, передаёт ей параметры из диалога с клиентом и, например, отменяет заказ. Это резко повысило интерес компаний: у клиента «Печать в фототехниках» на новогодних пиках нанимали в 3–5 раз больше сотрудников, а 80% запросов были однотипным вопросом про статус заказа — их и закрывали агенты.

В конце 2024 года появился DeepSeek, и его феномен стоит разобрать отдельно. Модель была сопоставима с флагманской тогда GPT-4 — не лучше, по большинству параметров чуть хуже, — но её обучили в 15–20 раз дешевле. Уникальная методика обучения была раскрыта в пейпере. За счёт дешевизны DeepSeek смог демпингануть по ценам и «усадить» рынок: GPT-4 был очень дорогим, а новая модель оказалась в разы доступнее при сопоставимом качестве.

Модель выложили в открытый доступ, серверы обвалились, и в декабре–январе трафик пропускали частично. Затем выпустили и потребительский продукт, которым начали пользоваться все.

ИИ стал частью повседневной жизни — настолько, что его творения превратились в мемы, а это повод задуматься: точку невозврата, похоже, прошли. Показательный пример: в 2024 году на выставке по автоматизации контактных центров не было ни одного стенда с ИИ, а в 2025 году — все 10 из 10, 100% статистика.

Второй маркер — вайб-кодинг. Появился Claude Code, инструмент, позволявший программистам писать код; сначала они плевались, а сейчас это один из самых быстрорастущих продуктов рынка. Программисты больше не пишут код руками: в компании спикера его не пишут вручную уже полгода.

С распространением ИИ-агентов встал вопрос исполнения 152-ФЗ, и теперь его действительно нужно исполнять. Задачи, которые ставят агенты, очень интересные: начиная от опечаток и заканчивая PDF-ками, на которых могут быть персональные данные и которые могут быть скинуты в чат.

Дополнительный контекст — инцидент с проникновением модели OpenAI в Hugging Face. После него прозвучал призыв: «Возможно, нам стоит притормозить наше развитие». Эта тема сейчас активно дискутируется.

Спикер описывает «путь джедая». Начинается всё с простой задачи: подготовить персонифицированное коммерческое предложение на английском для партнёра конференции в Ташкенте — с Клодом КП было готово за 20 минут, и партнёр пришёл на конференцию.

Дальше — презентации и КП, затем очистка и корректировка баз данных, затем проектирование небольших программных инструментов под конкретные задачи, затем внедрение ИИ-ассистентов внутрь системы и, наконец, автоматизация процессов целиком. За три месяца спикер прошёл путь от чата до автоматизированных бизнес-процессов, в том числе у внешних клиентов. Совет: не бросаться сразу в большую тяжёлую задачу, а начинать с малого.

С мая спикер ведёт Task Tracker и фиксирует в нём все задачи, подключив туда Клода. Объём вырос примерно с 4 треков до 15–20 параллельных задач — и при этом ни одного инцидента.

Метод прост: как только Клод начинает «страдать фигней», работа останавливается и задача декомпозируется — разбирается, почему так вышло и как сделать, чтобы это не повторилось. Поначалу такие сессии ретро проводились раз в 2–3 дня, сейчас необходимости в них нет уже около полутора месяцев.

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

Для сравнения: при внедрении ERP-систем и миграции между учётными системами аналогичный объём в разных проектах занимал от полугода до двух лет — это всегда очень тяжёлый ручной труд. База здесь накоплена за 12–14 лет, и с нейронками её удалось полностью вычистить за три месяца; теперь выписка загружается автоматически. Клод подключался с ноутбука к корпоративному серверу с соблюдением требований безопасности — со стендом и резервными копиями.

На производстве больших агрегатов конструкторская документация — изделия, операции, спецификации, чертежи, подписи, материалы — создаётся в «Компасе». Один агрегат состоит примерно из 1400 позиций и 60–80 узлов, и всё это заносилось в систему производственного планирования вручную, с массой дублей.

С помощью Клода спикер разобрал бинарники «Компаса», их файлы и форматы, научился их читать и сделал прямой импорт из «Компаса» в Odoo. Раньше целый отдел заносил изделие неделями и с ошибками; теперь изделие залетает за 3 секунды, около 1,5% данных не проходит и разбирается вручную, а полный импорт занимает порядка двух часов.

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

В работе с контактной базой сегмент формируется вручную как выборка (сами данные нейросеткам не доверяются), затем запускается автоматизированный блок: агент по вторичным данным готовит рассылки, сегментирует и запускает их механизмами системы, не касаясь самих данных, и видит только итоги. Полностью построен и управленческий учёт: план аналитических счетов и автоматизированные распределения, при проведении документов автоматически собираются БДР, КБДСС и другая отчётность.

Разведка ускорилась: по картинке можно быстро найти местоположение, собрать профиль человека — интересы, контакты — и вести долгую переписку так, что он примет собеседника за знакомого или осведомлённое должностное лицо; конверсия от такой гиперперсонализации растёт.

По статистике Центрального банка, около 99,1% краж через интернет-банки происходит по результатам социальной инженерии. У Точка Банк картина похожая — больше 90%, при этом источник атаки в виде зловредов там уже убрали, зато социальной инженерии разных видов целая куча. Отдельный вектор — дипфейки: «кружочек» от имени акционера, учредителя или генерального директора, чтобы принудить бухгалтера к платежу; раньше дипфейки были никакущие, с ИИ история резко поднялась.

Полной замены аналитика в SOC не произошло, хотя на российском рынке есть как минимум один проект, где SOC якобы целиком реализован на ИИ. Обхода контроля одним промптом тоже не случилось: чтобы обойти, например, DLP, нужно влезть в исполняемые процессы и скорраптить логику на регулярках и жёстких правилах. Массовых атак агентов нет: во взломе Hugging Face агенты участвовали, но без людей не обошлось — атакующий эксперт нужен всегда. При этом среди MCP-серверов очень много троянов.

По итогам мы имеем очень шумную рутину: много шумных и совершенно бестолковых атак, на которые отвлекаются ресурсы.

Самый массовый — теневой ИИ: сотрудники пользуются внешними сервисами в обход компании, и жёсткие контроли не помогают, ведь рядом можно положить телефон или ноутбук. Второй — prompt injection: манипуляция языковой моделью, чтобы она что-то сделала или выдала доступные ей данные. Третий — data poisoning и галлюцинации: если не проверять то, что выдаёт ИИ, можно очень больно сделать организации.

Четвёртый — BEC-атаки (business email compromise), причём не только почта: телеграм и даже электронный документооборот — взламывают контрагента, от его имени приходит привычный счёт, и бухгалтер платит. Пятый — атаки на цепочку поставок: их количество и доля выросли примерно вдвое, потому что взломать банк сложно, а контрагента, поставляющего банку ПО, куда проще.

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

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

Вайп-кодинг и внешние LLM разрешили, но запретили отправлять туда конфиденциальное — клиентские данные, секреты, ключи, токены, пароли — и обязали разработчика отвечать за вернувшийся код как за свой. Все обращения к внешнему ИИ идут через корпоративную прокси, через неё же раздают подписки на Codex. Маскирование — сначала по регуляркам, затем через ML (плюс 8–9 секунд на стандартный текстовый код, файлы сразу уходят в ML), а по временным меткам видно, сколько прошло от обращения к внешней модели до реквеста в Git.

Вокруг внутренней большой LLM поставили AI-файрвол на базе маленькой модели LightLLM: входы и выходы — только через него, попытки prompt injection отслеживаются. Риски собрали из наработок OWASP Top-10 и свежих рекомендаций Банка России по ИИ — около 25 собственных, их митигацию планируют упаковать в фреймворк или SDK, чтобы разработчики не думали об этом, а обращения к ИИ были безопасными.

Евгений Зеваков с командой сформулировали пять требований к системе обезличивания. Она должна работать автоматически: спикер согласен с подходом через прокси-гейтвей и считает его самым правильным. Наружу нельзя пропускать чувствительные данные, прежде всего персональные.

Обезличивание не должно тормозить работу с LLM: в агентных сценариях скорость генерации токенов критична, а её низкое значение заметно ухудшает пользовательский опыт. Система должна работать буквально на любом железе — за ориентир взяли офисный компьютер с 4 ГБ оперативной памяти, процессором уровня i3 и без GPU. И обезличивание обязано быть обратимым: плейсхолдеры нужно корректно декодировать с сохранением контекста.

Спрос на обезличивание объясняется просто: сотрудники хотят работать с зарубежными моделями — они умнее и зачастую дешевле российских аналогов от крупных компаний. По закону данные должны храниться на территории РФ, а правила обезличивания и хранения таблиц соответствий описаны в приказе Роскомнадзора № 140.

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

Среди готовых решений спикер упоминает open-source разработку Microsoft и LM Guard, но у них есть нерешённые проблемы: прежде всего русский язык — например, фамилии в родительном падеже, — а также встроенные трансформеры, тянущие за собой огромные требования к железу. Из NER-моделей до финала дошли две: Gliner в мультиязычном режиме и «Наташа» — серия библиотек команды МФТИ, полностью обученная на русском. В тестах на ограниченной мощности и при требовании высокой скорости с большим отрывом победила «Наташа» версии 2.1.

Результат NER-модели нельзя использовать напрямую: спаны нужно чистить и определять их края. «Наташа» может отнести слово «самозанятый» к сущности «Иванов Илья Петрович», тогда как маскировать нужно только ФИО, поэтому выделение роли как фильтра повышает качество, а от перемаркировки — маркировки того, что маркировать не следует, — защищает механизм перепроверки.

Отдельная боль — падежи: примерно в 80% случаев модель удерживает контекст и помечает человека одним плейсхолдером, в остальных 20% один и тот же человек превращается в «Персону 1» и «Персону 2»; при декодировании пользователь видит одно ФИО, но LLM может решить, что людей двое. На собственном датасете команда дообучает «Наташу», чтобы таких ситуаций стало меньше.

Схема работы: исходный текст (документ или промт) обезличивается, вместо чувствительных данных во внешнюю LLM уходят плейсхолдеры, модель отвечает с их использованием, после чего данные восстанавливаются. Не все модели одинаково хорошо работают с такими ограничениями, но большинство современных флагманских справляются, если в системном промпте прописаны правила работы с плейсхолдерами: у Anthropic — все модели Opus вплоть до 4.5 и Sonnet последних конфигураций, у OpenAI — линейка Sol, Astra и Luna в версиях 5.6 и 6, у Google — модели после Gemini 3.5 Flash, а также DeepSeek и Qwen.

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

Для оценки качества команда отказалась от метрики F1: в обезличивании достаточно утечки одной структурной единицы информации, поэтому F1 к задаче неприменим. Вместо него используется leak rate — показатель, который, по словам спикера, гораздо качественнее отражает суть задачи.

По ресурсам: 15-страничный текст объёмом около 30 тысяч знаков система шифрует за 370 миллисекунд, столько же занимает дешифровка, а скорость шифрования и дешифрования — примерно 63 тысячи символов в секунду. По оперативной памяти 240 МБ — граница, от которой стоит начинать, увереннее система чувствует себя на 500 МБ; достаточно одного потока.

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

Отличие от других систем: DAST работает по заранее заложенным шаблонам ATT&CK и эмулирует их, BAS использует известные тактики матрицы MITRE, а Triadix строит сценарий на лету. Поэтому повторный прогон не даёт идентичного результата: сканер в 10 запусков покажет одно и то же, а здесь в одних сценариях нейронка добьётся эксплуатации, в других — нет, возможны флуктуации и новые находки. Каждая находка проходит верификацию и уходит в отчёт со своим статусом.

Ручной пентест долог и дорог, а людей, умеющих делать нормальный пентест, «днём с огнём не найдёшь»; проверять сразу всё может позволить себе не банк. При этом стек и код меняются постоянно — в том числе из-за вайб-кодинга и быстрой интеграции решений, не всегда проверенных на уязвимости. На этом фоне формируется новый принцип — Continuous Automated Red Teaming: постоянная автоматизированная система, которая выполняет роль Red Team и непрерывно или по триггеру проверяет инфраструктуру и код на всё новое.

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

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

Отдельно собираются секреты — ключи API, админские пароли и прочее, что нередко лежит в открытом доступе. Даже во внутренний периметр злоумышленник может зайти с флешкой или ноутбуком. После выполнения рекомендации можно запустить повторную проверку — модель проверит именно её и скажет, закрыта она или нет. В приведённом отчёте: 62 находки, 58 подтверждено, 4 не подтверждено, 211 собранных материалов.

В бенчмарке с похожим решением Пентаги платформа показала в два раза большую эффективность и в пять раз большую скорость. В её основу заложен выстраданный опыт пентест-команды, которая не один год работает и на стороне Red Team, и на стороне Blue Team. Хорошо работает модель DeepSeek: она хороша, особенно за свои деньги, и практически бесплатна — миллиард токенов стоит около 5 долларов, а 300 миллионов токенов — порядка 40 центов.

Помимо небольшой платы за платформу деньги уходят на токены, которых система потребляет много. Доступна платформа в виде облака с небольшой подпиской и в виде on-premise. Команда, делающая платформу, — часть вендора, который производит СХД Atlas, и Triadix встроен в их прошивку как слой, который контролирует СХД и защищает периметр.

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

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

Частая проблема B2B-компаний — низкая конверсия сайтов, чаще всего в районе 1–2%: это ключевая точка роста, от которой зависит результат любой рекламы. Маркетолог в такой задаче идёт в Яндекс.Метрику и другие системы аналитики, но там видно в лучшем случае, что человек делал на сайте, и не видно, почему он так поступает и почему не оставляет заявку: уходящие клиенты в большинстве случаев молчат и причину не рассказывают.

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

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

Отсюда практика — проверка моделями других семейств: одна собирает цитаты, другая проверяет её выводы, причём принципиально именно другое семейство, а не конкретная модель. В реальном прогоне из 18 выводов проверяющая модель подсветила потенциальные ошибки, которые затем отдельно прорабатывались. Разбор коммуникаций, который раньше занимал 3,5 часа (день-два работы специалистов), сейчас с проверками проходит примерно за 50 минут.

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

Часто забывают про явный канал связи — почту: от 30% обращений идёт через e-mail, а у одного из клиентов рекорд — 94%, при этом адрес в лучшем случае указан в шапке. Ещё одна проблема — экспертный язык: менеджеры говорят про столешницы и определённый вид пластика, а клиент не понимает, что это такое. Закупщик с перечнем позиций не станет забивать 30 позиций на сайте — он копирует e-mail и выходит.

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

Каталог по классике делается на основе 1С, но там есть максимум габаритные размеры мебели, а людям нужен набор конкретных характеристик: в итоге 15 категорий, по каждой — до 17 характеристик для 500 с лишним товаров, причём значительная часть есть только на чертежах, подгруженных в 1С.

Решение нашли на Gemini (на тот момент — 3 Flash): модель умела и читать изображения, и работать с текстом, и выдавать ответ строго в формате JSON. Задачу разбили: сначала по имеющейся информации относили продукцию к категории, затем вытаскивали характеристики только по ней. Итоговый прогон всего каталога обошёлся меньше 2 долларов, все эксперименты — около 5 долларов.

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

Через 30 дней после внедрения ассистента злоумышленник загрузил в ИИ-агента документ с вредоносной инструкцией; агент прочитал его и отправил данные 10 тысяч клиентов на внешний адрес. Ущерб от промпт-инъекции составил 2,5 миллиона рублей, но при внедрённом AI Gateway он уменьшается вдвое — до 1,25 миллиона. Второе событие — утечка через контекст с ущербом 1,5 миллиона рублей. Третьим стало предписание ФСТЭК: у компании нет AIBOM, нет журналов и доказательств контроля ЕС-системы, грозит штраф. Контроли (например, AIBOM, инвентаризация или юридическая поддержка) снижают ущерб, эффекты суммируются, а неизрасходованный резервный фонд позволяет покрыть часть потерь.

Участникам предложили 10 организационных и технических контролей: AI Gateway (прокси между сотрудниками и внешними сервисами, фильтрующий данные перед отправкой в модель, защищающий от утечек через контекст, передачи персональных данных и коммерческой тайны, а также от несанкционированных запросов к API), human in the loop (финальное решение остаётся за человеком, агенту не доверяется вся цепочка), юридическая поддержка, мониторинг теневого ИИ, DLP для ИИ-каналов, инвентаризация активов, обучение сотрудников, резервная инфраструктура и мониторинг аномалий ИИ. Важный нюанс: можно потратить не весь бюджет, а часть оставить в резерве на покрытие непредвиденного ущерба.

Евгений Попов уверен, что за инцидентами должны стоять более сильные меры — правильно выстроенная архитектура, которая стоит 0 рублей. Это, по его словам, просто «порядок»: ролевая модель, права доступа, политика минимальных прав, а также нулевое доверие между сервисами. В своём ритейле и у других игроков отрасли уже давно идёт внедрение ИИ-ассистента и построение Secure Proxy-слоя как до, так и после моделей. Фокус — на перестроении архитектуры по политикам минимальных прав и на контроле самой модели, её входных и выходных данных.

Урок игры, который участники назвали хорошо соотносящимся с реальностью: можно подготовиться к одному сценарию, закрыть основные «ворота» и получить инцидент на менее приоритетном направлении. Команда №3 предложила оценивать, насколько реален срыв бизнеса через ИИ по сравнению, например, с пожаром или затоплением серверной без резервного копирования. Сергей, опираясь на опыт работы с госструктурами и бизнесом, подчеркнул: реальный ущерб просчитать невозможно, а штрафы ФСТЭК могут закрыть весь базовый ущерб от потери персональных данных в 2–3 раза. По его мнению, обучение сотрудников надо ставить на первое место — 90% убытков по персональным данным идёт от людей.

Антон Наумов («Уральские локомотивы», холдинг Синары) рассказал, что упор сделан на внедрение ИИ: все процессы идут в автоматизацию, любая LLM будет локальной, без выхода в интернет, и самообучающейся — этим занимается уже имеющееся структурное подразделение. Контролируются входные и исходящие данные. Ставка — на суверенные и национальные модели, GigaChat и «Алису», импортное будет убрано. Дмитрий Южанин (агентство B2B-маркетинга «Сделано») обозначил дилемму небольших компаний: вкладываться в защиту или в каких-то ситуациях понадеяться на авось, поскольку дорогие решения могут перекрывать изначальную ценность внедрения. При этом точка преимущества небольших компаний — использовать передовые модели, чтобы обгонять более крупные.