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

На панели сошлись, что ИИ уже встроен в бизнес-процессы. Руслан Поляков (Greenway Global) рассказал, что компания перестроила разработку: агенты помогают архитекторам, выполняют часть задач джунов, ускоряя работу на 30–40%, а на отдельных задачах до 70%. При этом ключевые решения остаются за командой. Дмитрий Бойко (ГК Lime Credit Group) видит плюс в обработке больших данных и прогнозах. Руслан Пермяков использует ИИ для транскрибации встреч и исследований через агентов. Полина Сазонова предупредила: ИИ должен ложиться на готовую инфраструктуру, данные, ERP и компетенции, иначе он добавит сумбур и ошибки вместо ускорения.

Руслан Поляков привёл кейс: информация об учебном проекте дрон-доставщика через 60 часов попала в украинские каналы, что показало скорость публичной утечки. Он подчеркнул: стратегические данные нельзя вываливать в нейросети, их нужно считать на защищённой инфраструктуре, а персональные данные требуют соответствия 152-ФЗ. Для безопасного использования ИИ он обозначил три варианта: локальное развёртывание, нейросеть в дата-центре с подписанным NDA или open-source-ресурсы. Задача IT и ИБ — определить, какие данные можно отдавать, а какие нельзя.

Руслан Пермяков отметил, что скорость производства атак выросла в разы: при новых уязвимостях счёт идёт на дни, выпуск Zero Day — на минуты, а сертификация длится месяцами. Дмитрий Бойко напомнил про атаки на дата-центры и давление на инфраструктуру: такие сценарии нужно закладывать в модель угроз. Если у компании два независимых дата-центра, важно понимать, как быстро собраться, переехать и развернуть сервисы на новой площадке. Он привёл пример резервных каналов: формально они были, но из-за низкой пропускной способности выкачивание резервных копий заняло две недели.

Руслан Пермяков рассказал, что разработка технологической документации и дрона-доставщика с нуля заняла 4 дня, 24 человеко-часа и около 600 тыс. рублей на токенах; уровень технологической готовности достиг 5–6. Аналогичный проект занял бы два месяца и соответствующий фонд оплаты труда. По его мнению, компаниям важно оценивать ИИ не через экономию, а через полученную прибыль и новые продукты; цель ускорения принятия бизнес-решений в 20 раз задаёт смысл, даже если не будет достигнута. Полина Сазонова добавила: иногда дешевле посадить джуна, чем использовать ИИ, а стоимость инфраструктуры растёт вместе с задачами.

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

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

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

12 апреля 2026 года директор ФСТЭК утвердил документ состава, содержания мероприятий и мер по защите информации. Спикер называет его «азбукой по защите информации от несанкционированного доступа». Объемом более 180 страниц, он содержит подробное описание реализации мероприятий и мер; изучив его, можно квалифицированно разобраться в теме.

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

Вышли изменения в 77 приказ. Аттестация остается обязательной только для государственных информационных систем. Владелец ГИС вправе выставлять требования по аттестации к подключаемым к нему иным информационным системам.

Для иных систем проводится контроль уровня защищенности, срок которого теперь совпадает со 117 приказом — раз в три года, с направлением результатов в управление ФСТЭК России. Детализировано, что при аттестационных работах лицензиату необходимо применять методические документы: по анализу уязвимости они открыты, по тестированию на проникновение имеют ограничительную пометку и предоставляются по запросу.

Непредставление сведений о показателе защищенности, а также непроведение мероприятия и ненаправление сведений влекут ответственность по статье 13.12.1: штраф для должностных лиц — 10 тысяч рублей, для юридических лиц — от 50 до 100 тысяч.

В управлении собрано более 800 оценок от различных организаций, в основном от органов власти, государственных учреждений и предприятий. При этом более 60% организаций не представляют подтверждающий материал — 8 снимков экрана, отчет сканера с разделами о подборе паролей и две выписки. Без подтверждающих документов по частному показателю присваивается нулевое значение: показатель может оказаться не 1, а, например, 0,15.

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

Для операторов информационных систем персональных данных ожидается приказ 235, вступающий в силу с 1 марта 2027 года, с требованием рассчитывать показатель, невыполнение которого повлечет административную ответственность. Планируется и глобальное изменение 239 приказа — для субъектов КИИ, касающееся и защищенности, и уровня зрелости.

По статистике (по итогам 4 квартала 2024 года) 50% атак на организации в целом приходится на социальную инженерию, а 88% атак на частные лица также связаны с социальной инженерией. Докладчик подчёркивает: эти цифры «плюс-минус соединены» и повторяются из года в год, как бы мы ни старались.

Причина в том, что мы обычно считаем: если периметр защищён — всё прекрасно. Но нет: внутренний инсайдер «со знаком минус» всегда найдётся. Регуляторика добавляет контекст: приказ ФСТЭК № 118 (пункты 56 и 57) говорит о необходимости повышать уровень осознанности сотрудников и постоянно это применять.

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

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

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

Внутри — конструктор своих курсов и редактирование готовых, свои фишинговые шаблоны (персонализированные и общие, домены 2–3 уровня, все сертификаты). Есть плагин: сотрудник, распознавший фишинг, может это отметить, и администратор видит. Работу можно настраивать на отложенные сроки — за один день реально выстроить программу на год вперёд.

Кейс из практики: крупная компания порядка 12 тысяч сотрудников управляет всей программой силами двух человек. Удержание клиентов — 90%, и показатели растут из года в год.

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

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

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

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

Функции разделяются: обучение и «прокаталировать», чтобы сотрудник обучился, — больше на HR; имитация атак — на ИБ, потому что именно ИБ лучше знает, как провести качественную атаку на свою организацию и где слабые точки. Материалы готовит ИБ — вряд ли HR штудирует приказ № 118. Пересекаются стороны на тренингах и в общей коммуникации, чтобы сотрудники не боялись обращаться и утаивать проблемы. Регламенты и план обучения обновляются ежегодно по актуальным приказам регуляторов, а обучающие мероприятия проводятся минимум раз в квартал.

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

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

Запись, систематизация, накопление, хранение, уточнение и извлечение персональных данных не должны происходить за пределами российских серверов. Типичное нарушение — зарубежный хостинг или зарубежный сервер, куда данные уходят, там анализируются и считаются, но без соответствующего уведомления о трансграничной передаче данных. Сюда же попадают аналитические инструменты вроде Google Analytics и Meta Pixel: их использование без необходимых уведомлений Роскомнадзору также считается нарушением. Решение — локализовать сбор и все операции, предусмотренные требованием локализации, и оформить трансграничную передачу данных.

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

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

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

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

Information Security Lab разработала сканер сайтов, который проводит тот же анализ по RU-сегменту, что и сканер регулятора, но по инициативе самой компании. Проверяются наличие компании в реестре, корректность политики, корректность форм сбора, наличие куки-механизмов, реальная возможность отказаться от обработки данных, используемые аналитические платформы и размещение сайта на сервере с учётом требований локализации. В отчёте некорректности подсвечиваются с указанием конкретных пунктов расхождений и рекомендаций по исправлению, а результат раскладывается на задачи для разных команд — разработки, ЦУИБ и других отделов. Сценарии использования: разовый аудит, регулярный мониторинг после релиза нового сайта или подключения новой формы, контроль подрядчиков и проверка большого числа доменов в крупной компании. При этом сканер закрывает только верхушку айсберга — точку соприкосновения с пользователями на сайте: сам процесс обработки персональных данных глубже и требует аудита процессов, разработки моделей угроз и документов силами внешнего подрядчика или собственными.

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

Работа строится так: специалисты погружаются в инфраструктуру заказчика, проводят оценку, настройку и донастройку, а при необходимости — замену. TS Solution входит в 20 крупнейших интеграторов России по информационной безопасности и имеет сертификаты ФСБ и ФСТЭК, что позволяет погружаться в проблематику заказчиков и партнёров. Компания основана в 2010 году, инженерная экспертиза изначально строилась на решениях Check Point. Скоро список поддерживаемых вендоров пополнится ещё двумя производителями — сертификаты получены, инженерный блок готов.

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

SpanCheck — «тяжёлая» штука на базе коммерческого продукта PT NAD. NAD разворачивается в инфраструктуре, требует огромного количества ресурсов, зато анализ трафика очень глубокий. Оба решения анализируют трафик как снаружи, так и внутри.

TSECO — новинка TS Solution. Это deception-платформа, которая расставляет внутри инфраструктуры ловушки, приманки и «файлы-канарейки». Её задача — найти злоумышленника, который уже проник в инфраструктуру и может находиться там месяцами, ничего не делая; как только он начнёт активность, «эхо» его поймает, потому что его софт реагирует на сигнатуры, и сотрудники ИБ это мгновенно видят. Любой контакт с ложной целью — стопроцентный индикатор атаки.

Для запуска нужен сервер управления под Linux, агенты-ловушки доставляются, требуются интеграции с NGFW, мессенджерами и SIEM. Управление — из единой панели безопасности. Настраивается автоблокировка злоумышленника через NGFW, запуск занимает от одного часа. Сейчас идут бесплатные пилоты.

Если на предприятии уже стоят продукты Positive Technologies, TS Solution готов их посмотреть, помочь донастроить, порекомендовать, где что подкрутить или заменить, какие галочки поставить и какие политики расставить. Схема рабочая: «трезвый взгляд» со стороны помогает найти то, что пропустили из-за замыленного глаза.

Отдельный практический момент по Check Point: самой компании в России нет, но есть её российское подразделение RusPoint с сертификатом ФСТЭК, хотя прошивки не самые актуальные. Ранее построенные в России инсталляции Check Point продолжают поддерживаться.

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

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

По международным практикам безопасного построения систем: Windows-сервер — около 550 настроек, влияющих на безопасность, Linux-дистрибутивы — 300–350, базы данных — 200–300. Суммарно на одном сервере набирается порядка 1000 настроек. Даже если взять только высокорисковые — 200–300 на хост, — для тысяч хостов это 300 тысяч настроек, а для крупных инфраструктур — миллионы.

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

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

Если со стороны ИБ этапы можно пропустить и смотреть на общую картину в красивом портале, то в IT отчёт прилетает администратору, у которого нет времени даже почитать его, не говоря уже о настройке. При этом отчёт не визуализирован: буквально PDF на 200 страниц с графой рекомендаций, куда сканеры копируют куски мануалов вендоров. Магического Ctrl+C, Ctrl+V не получится — приходится читать мануалы, искать, писать тестовые команды и скрипты, тестировать их на тестовом контуре и лишь потом переносить в продакшн.

Популярные сканеры (мировой референс — Nessus, российский — C-Max Quattro) изначально создавались под сетевое сканирование вендорских уязвимостей, а блок настроек добавился позже, поэтому анализ конфигов там ограничен матчами — «матч/не матч» для того, что взяли с хоста. Здесь написали движок, работающий именно с конфигами: сняли это ограничение и ускорили сканирование — один хост с любым количеством прикладного ПО проверяется примерно за 30 секунд.

Обычно сканер оставляет мегабайты отчётов — и дальше делай что хочешь. Здесь есть модуль, дающий администраторам из коробки готовые командные скрипты: поддержано больше 100 типов систем, а с учётом различий по версиям — практически 400. Для всех есть две типовые конфигурации из многократно протестированных команд, а нетиповую проверку можно кастомизировать прямо в интерфейсе без вендорских языков — загрузкой YAML/XML и с подсветкой синтаксиса родных систем (Bash для Linux, PowerShell для Windows, Cisco ACL для оборудования).

Это задача на стыке: владелец — информационная безопасность, а исполнитель — целиком IT, и она изначально конфликтная из-за объёма: просьба настроить 100 тысяч настроек ломает несколько спокойной жизни, тогда как лишний патч воспринимается проще. Работа ведётся с универсальным комбайном, покрывающим операционные системы, сетевые устройства, СУБД и приложения.

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

Решение агентское: Агент САКУРА собирает на рабочем месте более 200 параметров безопасности, сервер проверяет их по профилю и выдает вердикт. Контроль — не «проверка при подключении», а непрерывный: решение о доступе или его ограничении формируется на сервере и выполняется через шлюзы клиента. Комплекс САКУРА не привязан к конкретному вендору шлюза и работает с основными игроками рынка VPN.

Платформа помогает соответствовать требованиям регуляторов — приказам ФСТЭК России № 21, 117 и 239, положению Банка России № 382-П, ГОСТ Р 57580.1 — и развивается в сторону IRP, платформы реагирования на инциденты: помимо комплаенса система ведет инвентаризацию оборудования и ПО и выполняет гибкие сценарии реагирования — от уведомления до изоляции и автоматического приведения рабочего места в соответствие. У комплекса САКУРА собственный модуль двухфакторной аутентификации (приложение «САКУРА 2FA», RuStore и AppStore), развертывание — on-premise, в инфраструктуре клиента.

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

Агент работает на Windows, macOS, Astra Linux, РЕД ОС, ALT и SberOS; мобильные агенты — в разработке. Состав параметров — ОС, ПО, антивирус, процессы, местоположение, канал связи, оборудование — расширяется собственными проверками на Bash, PowerShell, Python и CMD. В двухфакторном режиме второй фактор подтверждается приложением «САКУРА 2FA» или Telegram, а при принятии решения учитываются данные о рабочем месте — в том числе его геолокация.

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

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

Опасность в том, что агент часто воспринимается как волшебная кнопка от всего. Если человек ошибается, он ошибается один раз; если ошибается агент, ошибка становится масштабной. Полина Сазонова приводит пример: агент запустили, чтобы помочь настроить инфраструктуру, он нашёл в базе пароли от прода, вышел на прод, завалил сервер и вернулся с отчётом. На вопрос «зачем завалил прод?» он ответил: «не подумал».

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

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

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

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

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

В системе Сергея Поздняка память разделена на слои. На ноутбуке — файловая память, где агент читает контекст проекта. На сервере — таск-трекер: вся деятельность раскладывается на проекты, задачи, подзадачи и вехи с ответственными, зависимостями, ТЗ, принятыми решениями и результатом. Агент, попадая в проектное пространство, сразу понимает, где он находится и что делает.

На сервере также ведется Вики, которая автоматически консолидируется по задачам. Она связана с задачами и подзадачами и спроецирована в векторную базу знаний с семантическим поиском. Это нужно, чтобы не засорять контекст: если нужная информация лежит двумя строками в файле на 20 тысяч строк, агент не должен впитывать весь файл. Нейросеть всегда учитывает весь контекст и склоняется туда, где контекста больше, поэтому лишние данные распыляют ответ. Оперативный слой на десктопе и в облаке хранится около трех месяцев, а на сервере — вечно, пока это нужно. Сергей фиксирует часы свои и агента: примерное соотношение — 1:6 или 1:7, то есть на каждый его час агент работает 6–7 часов.

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

В результате компания получила реальную картину и работающий управленческий учет. Сергей подчеркивает, что за всю практику ни разу не видел нормально построенного управленческого учета, и все понимают его по-своему. Эта задача была объемной, но решенной за небольшое время.

На производстве есть программа Компас, где хранятся чертежи и спецификации изделия, а также дерево продукта. Эти данные нужно перенести в систему производственного планирования и снабжения. Одно изделие содержит 1600 позиций, и три человека тратили на его заведение две недели. Сергей выяснил, что проприетарный формат Компаса можно разобрать: они раскрыли бинарник, извлекли чертежи и дерево продуктов и запихнули в систему производственного планирования.

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

Сергей Поздняк отдельно останавливается на безопасности использования ИИ-агента. Если пустить агента к данным и дать ему права чтения, записи и удаления, он может сделать с ними все что угодно. Нужно ограждать себя: один агент, например, деплоит и делает запись в папку на сервере, дальше штатная автоматизация подхватывает, третий агент заходит, смотрит, что получилось, и включает механизм. Это классический подход к безопасности использования ИИ-агента. Через MCP можно дать агенту сразу доступ к боевой инфраструктуре, поэтому во все инструменты надо вшивать ограничители.

Пример риска — инцидент с подготовкой КП: из-за рассинхронизации браузера и бэкенда запрос «сделай мне КП» повторился 32 тысячи раз. Без ограничений и контроля агент может уйти в неуправляемое повторение и создать финансовую или операционную проблему.

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

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

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

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

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

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

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

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

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

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

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

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

Ключевая ценность не в «магии» ИИ, а в организации технологического стека и бизнес-пайплайна. Нужно чётко понимать, что за чем идёт, какие данные и артефакты появляются в процессе и как они облегчают или усложняют работу нейросети. В проекте Git использовался как обязательная основа.

Параллельно был эксперимент с дроном. В мастерскую пришли высокие гости, радиозапись вовремя не выключили, и разговор не про дроны попал в RAG. Запись автоматически обработалась ИИ, после чего началась «эпическая история» про дроны, конечности и манипуляторы — система стала галлюцинировать.

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

В работе выделили три уровня. Первый — локальные дроны: скорее автоматизация, чем ИИ, с несколькими лёгкими нейронами; особых требований к локальному контуру не было. Второй — локальный ЦОД с 20–30 различными нейронами. Третий — недоверенный контур через open route к внешним моделям, в том числе зарубежным. Перекачивание информации контролировали гаджеты, проверявшие соответствие политике.

При извлечении решений все куски данных должны быть проклассифицированы. Автоматизация работала по словосочетаниям или по месту происхождения данных, а локальный ИИ имел правило маркировки. Локальные ИИ галлюцинируют меньше. В недоверенный контур ничего не ушло; из локального в доверенный потеряли примерно 5–7% данных. За 4 дня создали около 70 ГБ информации.

На уровне архитектуры формируются профили возможностей, контекст, мультимодальность и классификация потоков; используются тесты для проверки качества входящей и исходящей информации, адаптеры через локальные интерфейсы и внешние API. Отдельная политика переключает маршрутизацию по данным, задачам, соответствию, бюджету, доступности и срочности. API собрали примерно за 3 часа. Важен аудит: срок хранения запросов, ответов и транскриптов. Слишком длинная история мешает: проект меняется быстро, а агенты тянут старую историю и перестают соответствовать идее проекта.

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

На входе — полный текст судебного акта, который может занимать много страниц; уголовные решения нередко достигают 15–50 страниц. Модель обрабатывает неструктурированный текст, иногда в разных и нечитабельных форматах, проводит связывание, классификацию фактов и сущностей в нужные поля. На выходе получается краткий отчет: в чем заключался спор, позиции сторон и итог суда. Система выделяет срок, сумму, арест, возраст (совершеннолетний или несовершеннолетний, пенсионер), статью и другие значимые параметры. Чтобы понять, что речь идет именно о конкретном человеке, она привязывает незатертый кодексатор и смотрит, где он повторяется, связывая данные между собой.

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

Система позволяет отслеживать изменения, связанные с юридическими лицами: юридический адрес, смену директоров, налоговые и иные данные. Она может показывать задолженность по судебным приставам, нахождение компании в черном списке антимонопольной службы и другие негативные факторы. Это помогает предотвращать ущерб до заключения договора, а не разбираться с последствиями. Пример из выступления: человек зарегистрирован на территории Алтайского края, прописан в Новосибирске, а деятельность индивидуального предпринимателя ведет в Карачаево-Черкесии; потом с ним сложно что-то сделать. Если контракт на 11 миллионов уже заключен, арест возможен, но потребует времени, госпошлины и работы юриста, поэтому лучше работать на предупреждение.

На примере реестра компаний, которые производят ремонт исторических зданий, видно, что таких компаний в Новосибирской области всего около 30–40, и только они получают допуск для строительных монтажных работ на таких зданиях. Значит, в тендерах могут участвовать только они, а на практике часто фигурируют одна-две компании. Загрузка таких ресурсных систем помогает анализировать ситуацию и коррупционную составляющую. Кроме того, в открытых источниках много неструктурированной информации, базы пополняются, и ИИ помогает работать с этими данными.

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

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

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

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

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