itWeek https://www.itweek.ru Издание itWeek (до 2018 года — PC Week) на портале и на страницах бумажного номера информирует читателей об актуальных информационных и коммуникационных технологиях, продуктах и решениях и опыте развития цифровой экономики и цифровой трансформации предприятий и организаций всех масштабов и отраслей. Издание рассказывает о важнейших событиях отечественного и мирового рынка ИКТ и анализирует тенденции развития ИКТ-индустрии. https://www.itweek.ru/images/itweek/logo-100x40.gif itWeek https://www.itweek.ru «Базис» представил безопасную платформу для хранения и проверки компонентов ПО https://www.itweek.ru/themes/detail.php?ID=235930 Wed, 11 Nov 2026 14:00:37 +0300 <p>«Базис», российский разработчик ПО управления динамической ИТ-инфраструктурой (входит в ГК «РТК-ЦОД»), представил Basis Repository — платформу для хранения и проверки компонентов ПО по единым правилам безопасности заказчика. Решение позволяет контролировать, какие компоненты доступны командам разработки, и пересматривать разрешение на их использование при появлении новых сведений об уязвимостях. Платформа разворачивается в инфраструктуре заказчика, в том числе в закрытом контуре.</p> <p>Новый продукт предназначен для компаний, которые при создании и обновлении приложений используют стороннее ПО, включая open source компоненты. Платформа помогает разработчикам и ИБ-специалистам согласовывать их использование. Результаты проверок и история решений сохраняются в системе, позволяя видеть, кто и на каком основании разрешил использование конкретного компонента.</p> <p>Заказчик сам определяет требования к компонентам: из каких источников их получать, какие лицензии допустимы и какие использовать нельзя. Basis Repository сопоставляет результаты проверки хранилища с этими требованиями. Разработчики получают из него только ПО, которое соответствует правилам или разрешено ответственным специалистом в порядке исключения.</p> <p>Если команде необходим компонент с известной проблемой, уполномоченный сотрудник может временно разрешить его использование. Он указывает причину и срок действия разрешения. В системе сохраняются результаты проверки компонента и сведения о том, кто и на каком основании принял решение.</p> <p>Проверки можно повторять вручную или по расписанию. Если в ранее разрешенном компоненте обнаружится новая уязвимость, его дальнейшую загрузку из хранилища можно закрыть сразу для всех команд. Реакцию задает заказчик: в зависимости от настроек система может автоматически ограничить или сохранить доступ, в том числе с уведомлением ответственных специалистов.</p> <p>Платформу можно развернуть в изолированных сегментах инфраструктуры заказчика. Для закрытого контура предусмотрен перенос компонентов и данных проверки. Актуальность локальных баз поддерживается по регламенту заказчика. Права на управление платформой и согласование файлов разграничиваются по ролям, а значимые действия фиксируются в журнале аудита.</p> <p>Платформа проверяет отдельные компоненты и их наборы. По результатам анализа формируется ППК — перечень обнаруженных программных компонентов и их версий. Сведения о выявленных уязвимостях сопоставляются с записями Банка данных угроз ФСТЭК России. При передаче набора компонентов предусмотрен подписанный паспорт, который помогает проверить соответствие полученного содержимого проверенному составу.</p> <p>При проверках учитываются лицензии и сроки поддержки компонентов. Заказчик задает правила использования версий, которые больше не поддерживаются. Основанием для пересмотра разрешения на использование могут стать новая уязвимость, изменение правил компании или окончание срока временного разрешения.</p> <p>Ключевая функциональность Basis Repository реализована в собственном коде «Базиса». Она включает управление проверками, применение правил допуска, согласование и публикацию компонентов. ПО с открытым исходным кодом используется только для отдельных задач: хранения и доставки пакетов, идентификации пользователей и некоторых технических проверок.</p> <p>Basis Repository поддерживает пакеты Linux в форматах RPM и DEB, контейнерные образы Docker/OCI, пакеты npm, Maven и PyPI, а также бинарные архивы. Управление доступно через веб-портал и API. Для получения опубликованных пакетов и образов используются стандартные системные утилиты.</p> <p>«Безопасная разработка становится все более востребованной, но на российском рынке не было подходящего инструмента для хранения компонентов и контроля их использования по единым правилам. Этот запрос бизнеса и стал отправной точкой к созданию Basis Repository. Мы опирались на собственный опыт разработки Basis Digital Energy и взаимодействие с ФСТЭК России. Решение дополнит экосистему „Базиса“ и поможет заказчикам снизить риски использования открытого кода», — отметил Давид Мартиросов, генеральный директор «Базиса».</p> «Базис», российский разработчик ПО управления динамической ИТ-инфраструктурой (входит в ГК «РТК-ЦОД»), представил … message Postgres Professional ускорила восстановление баз данных и упростила управление резервными копиями в ProBackup 3.5.0 https://www.itweek.ru/themes/detail.php?ID=235929 Wed, 11 Nov 2026 13:59:33 +0300 <p>Компания Postgres Professional выпустила новую версию решения для резервного копирования и восстановления Postgres Pro Backup Enterprise (ProBackup) 3.5.0. Обновление объединяет удаленное восстановление в едином инструменте, ускоряет восстановление после сбоев и миграцию, упрощает синхронизацию реплик и повышает эффективность управления сроками хранения резервных копий. Это позволяет компаниям сокращать время простоя критичных сервисов и снижать нагрузку на ИТ-команды.</p> <p>В ProBackup 3.5.0 функциональность удаленного восстановления полностью перенесена в основную утилиту pg_probackup3. Теперь резервную копию можно передать по сети, распаковать и восстановить на целевом сервере в многопоточном режиме — без ручного копирования архивов и использования сторонних инструментов. Решение поддерживает как полное восстановление в пустой каталог, так и инкрементальное восстановление.</p> <p>Новый подход особенно актуален для компаний с централизованным хранилищем резервных копий и удаленными площадками. Он сокращает время восстановления (RTO), уменьшает число ручных операций и упрощает аварийное восстановление, миграцию и автоматическое развертывание серверов.</p> <p>В команде catchup, предназначенной для клонирования и синхронизации экземпляров PostgreSQL, появился параметр sync-replica. Он позволяет предварительно проверить возможность синхронизации реплики с ведущим сервером при расхождении историй линий времени, в том числе после повышения реплики.</p> <p>Администратор может сначала выполнить диагностическую проверку без изменения данных, получить подробный отчет и оценить риски. Затем утилита определяет точку расхождения, при необходимости выполняет откат с помощью pg_rewind и синхронизирует реплику с ведущим сервером. Это снижает вероятность ошибок при восстановлении репликации и помогает быстрее возвращать инфраструктуру в рабочий режим.</p> <p>Управление политиками хранения резервных копий стало многопоточным. В команде retention добавлены параметры threads, num-write-threads и num-validate-threads, которые ускоряют ресурсоемкие операции объединения устаревших резервных копий и очистки архивов.</p> <p>Новый параметр wal-depth позволяет при очистке журналов транзакций (WAL) гарантированно сохранять сегменты, необходимые для восстановления базы данных на нужный момент времени (PITR). Также улучшена стабильность потоковой передачи WAL: keepalive-сообщения предотвращают разрыв соединения по тайм-ауту при длительном отсутствии нагрузки на СУБД.</p> <p>В ProBackup 3.5.0 ускорена работа с SFTP, S3-совместимыми хранилищами и сжатой файловой системой CFS. Передача данных на удаленный хост теперь выполняется асинхронно несколькими запросами в рамках лимитов SFTP-сервера, а размер буфера обмена по умолчанию увеличен с 128 КБ до 1 Мб.</p> <p>Добавлена настройка тайм-аутов для S3-запросов, ускорены проверка резервных копий в режиме STREAM и монтирование копий через FUSE. Для заказчиков это означает более быстрое создание и проверку копий, меньшую нагрузку на сеть и более предсказуемую работу с облачными платформами.</p> <p>В новой версии усилены безопасность и надежность восстановления. Устранена уязвимость, позволявшая выполнить произвольную команду оболочки через путь к точке монтирования при размонтировании FUSE, а также исправлено переполнение буфера при передаче длинных значений параметров remote-host и remote-user.</p> <p>Отдельное внимание уделено работе с шифрованием TDE и сжатой файловой системой CFS: исправлены ошибки, которые могли приводить к некорректному восстановлению зашифрованных или сжатых данных. Также устранены ошибки, затрагивающие сохранность копий, удаление экземпляров в S3, инкрементальное восстановление после изменения линии времени и обработку WAL-файлов большого размера.</p> <p>«Для заказчика резервное копирование — это гарантия быстрого возвращения критичных сервисов в работу после сбоя. В ProBackup 3.5.0 мы сделали восстановление более автоматизированным, ускорили работу с удаленными хранилищами и повысили надежность синхронизации реплик. Это помогает ИТ-командам тратить меньше времени на ручные операции и увереннее обеспечивать непрерывность бизнеса», — отметил Алексей Дарвин, руководитель продукта Postgres Pro Backup Enterprise.</p> Компания Postgres Professional выпустила новую версию решения для резервного копирования и восстановления Postgres Pro … message Angara MTDR обновила модуль сканирования уязвимостей и интегрировала новый модуль контроля конфигураций https://www.itweek.ru/themes/detail.php?ID=235928 Wed, 11 Nov 2026 13:58:38 +0300 <p>Angara MTDR обновила один из ключевых модулей Angara AVM — сервиса контроля внутреннего контура в составе центра управления уязвимостями Angara VOC. Изменения помогают компаниям-заказчикам получать более полные сведения об активах внутренней инфраструктуры.</p> <p>Обновленный модуль сканирования уязвимостей (Vulnerability Scanner, VS) помогает устранять проблемы, с которыми компании нередко сталкиваются при регулярных проверках. Так, закрытая заявка на исправление не всегда подтверждает, что уязвимость устранена, а ручное сопоставление результатов сканирований сопряжено с высокими трудозатратами. Кроме того, частые проверки нагружают рабочие системы и требуют согласования с другими подразделениями.</p> <p>Теперь модуль точнее отслеживает жизненный цикл выявленных уязвимостей. Он сопоставляет результаты последовательных сканирований и показывает, какие уязвимости появились впервые, какие устранены, а какие сохраняются, что дает прозрачный контроль устранения и сроков исправления. В дополнение к этому расширены возможности проверки серверов, рабочих станций, сетевого оборудования, веб-приложений других компонентов инфраструктуры. Управление заданиями, расписаниями и интенсивностью сканирования позволяет адаптировать проверки к технологическим окнам и допустимой нагрузке на системы. </p> <p>Модуль контроля параметров безопасности (Security Profile Compliance, SPC) отслеживает состояние настроек систем, которые меняются в ходе обычной работы. Без такого контроля настройки сверяют с требованиями эпизодически и вручную, и небезопасное изменение может долго оставаться незамеченным.</p> <p>Интеграция нового модуля SPC расширяет возможности регулярной сверки настроек ИТ-активов с утвержденными профилями безопасности, внутренними политиками, требованиями организации и выбранными рекомендациями. Модуль выявляет отклонения и контролирует их устранение. Проверки могут охватывать операционные системы, СУБД, прикладное ПО, контейнерные платформы и сетевое оборудование. Наряду с готовыми профилями можно применять настраиваемые проверки с учетом внутренних требований организации. Регулярные проверки помогают выявлять небезопасные изменения настроек и отслеживать устранение отклонений.</p> <p>«Отчет о сканировании фиксирует состояние инфраструктуры на конкретную дату, но сама инфраструктура постоянно меняется. Чтобы понимать, снижается ли риск, важно видеть динамику — какие уязвимости закрыты после исправлений и не появились ли небезопасные изменения в настройках систем. Поэтому мы развиваем AVM как инструмент постоянного контроля внутреннего контура, где уязвимости в ПО и настройки систем рассматриваются вместе. В рамках Angara VOC эти данные дополняются результатами контроля внешнего периметра и экспертной оценкой», — отметил Артем Грибков, директор Центра киберустойчивости Angara MTDR.</p> <p>Компания также готовит обновление сервиса Angara ASM для контроля внешнего периметра. Для него разрабатываются новый личный кабинет, обновленное технологическое ядро, а также ряд других изменений. </p> Angara MTDR обновила один из ключевых модулей Angara AVM — сервиса контроля внутреннего контура в составе центра … message Cyberthreattech представила CTT AI Attack Pulse для защиты искусственного интеллекта https://www.itweek.ru/themes/detail.php?ID=235927 Wed, 11 Nov 2026 13:57:51 +0300 <p>Российская компания CyberThreatTech (ООО Технологии киберугроз) объявила о запуске CTT AI Threat Feed, специализированного продукта класса Threat Intelligence, предназначенного для отслеживания киберугроз, направленных на системы искусственного интеллекта. По оценке компании, это первый в России и странах СНГ специализированный фид, предоставляющий структурированные машиночитаемые знания о тактиках, техниках и процедурах атак непосредственно на AI-системы. В пятницу, 13 ноября, в 10.00 состоится онлайн-трансляция презентации CTT AI ATTACK PULSE напрямую из Музея криптографии.</p> <p>Развитие искусственного интеллекта становится одним из основных направлений автоматизации бизнеса. Компании внедряют большие языковые модели, интеллектуальных помощников и автономных AI-агентов в клиентское обслуживание, разработку программного обеспечения, аналитику, документооборот и управление корпоративными системами.</p> <p>По мере расширения использования ИИ растёт и поверхность атаки. AI-приложения обрабатывают корпоративную информацию, взаимодействуют с внешними источниками данных и получают доступ к различным бизнес-системам. Это создаёт дополнительные возможности для злоумышленников, а также новые требования к средствам защиты. Сегодня организации регулярно отслеживают уязвимости, вредоносное программное обеспечение, индикаторы компрометации и техники атак на традиционную ИТ-инфраструктуру. CyberThreatTech предлагает распространить аналогичный подход на инфраструктуру искусственного интеллекта.</p> <p>«Искусственный интеллект становится частью корпоративной инфраструктуры, и его безопасность требует такого же системного подхода, как защита серверов, сетей и приложений. Мы видим, как быстро появляются новые способы воздействия на AI-модели и агентов. Наша задача состоит в том, чтобы собирать эти знания, анализировать их и предоставлять в формате, который может использоваться непосредственно средствами защиты. AI Firewall должен получать актуальную информацию об угрозах так же, как традиционные средства безопасности получают обновления об уязвимостях и атаках», — прокомментировал Николай Арефьев, основатель и генеральный директор CyberThreatTech.</p> <p>CTT AI Threat Feed агрегирует сведения из отчётов об угрозах, посвящённых атакам на AI-модели, приложения и агентов. Продукт охватывает тактики, техники и процедуры (TTP), применяемые для воздействия на системы искусственного интеллекта. Полученная информация анализируется, систематизируется и преобразуется в структурированный машиночитаемый формат. Это позволяет использовать результаты Threat Intelligence в автоматизированных процессах защиты, исследования и проверки безопасности AI-инфраструктуры.</p> <p>Ключевая особенность CTT AI Threat Feed заключается в возможности передавать знания об угрозах непосредственно программным системам, которым эти сведения необходимы для выполнения защитных функций. </p> Российская компания CyberThreatTech (ООО Технологии киберугроз) объявила о запуске CTT AI Threat Feed … message Axenix: 17% компаний продолжают активно развивать ИТ на фоне режима экономии https://www.itweek.ru/themes/detail.php?ID=235926 Wed, 11 Nov 2026 13:56:05 +0300 <p>Крупный российский бизнес перешел в режим экономии, но от технологического развития не отказывается: деньги получают проекты с быстрым и измеримым эффектом, а главной ставкой остается искусственный интеллект. Об этом свидетельствуют данные исследования AxRadar консалтинговой технологической компании Axenix. Эксперты провели глубинные интервью с ИТ-руководителями (CIO, CDTO, CTO) более 50 крупнейших компаний из пяти отраслей: банков, ритейла, производства потребительских товаров (CPG), добычи и производства, а также агросектора.</p> <p>Сегодня ИТ развивают 58% опрошенных компаний, но активно — лишь 17%, еще 41% — умеренно. Остальные 42% держат ИТ на базовом уровне и пока ограничиваются тем, что закрывают основные потребности в цифровизации процессов. Разрыв между лидерами и остальными уже заметен, и, по оценке авторов исследования, если внешние условия не изменятся, доля компаний, развивающих ИТ, будет сокращаться.</p> <p>Причина сдержанности — в приоритетах бизнеса. Главным из них 67% компаний называют операционную эффективность и сокращение затрат. Органический рост и расширение доли рынка важны для 50%, новые продукты и источники прибыли — для 44%. Отсюда и новая логика ИТ-инвестиций: технологии финансируют под снижение издержек и рост производительности.</p> <p>Даже в режиме экономии ИИ остается главной технологической ставкой. Машинное обучение и генеративный ИИ входят в топ-5 ИТ-приоритетов у 58% компаний и уже используются в промышленной эксплуатации у 61%. Вместе с операционной эффективностью ИИ занимает центральное место в ИТ-повестке: хотя бы одно из этих направлений входит в топ-5 у 85% компаний, у трети — оба сразу.</p> <p>Новая волна использования ИИ и ГенИИ пока остается в экспериментах: AI-native платформы разработки пилотируют 39% компаний, а используют лишь 5%, мультиагентные системы работают только у 7%.</p> <p>Почему пилотные проекты не масштабируются? Главный барьер — неясная окупаемость: его назвали 48% респондентов. ИИ-проекты конкурируют за бюджет с бизнес-инициативами, и выигрывают те, у которых доказан финансовый эффект и короткий срок реализации. По словам ИТ-директоров, при правильном выборе функций эффект ИИ может в разы превышать вложения, но успешных примеров на рынке пока мало, а внедрение дорогое и долгое. Часть ИТ-директоров и вовсе предупреждает о риске «внедрения ИИ ради ИИ».</p> <p>Темпы внедрения сдерживают и другие факторы: качество и доступность данных, риски информационной безопасности, нехватка экспертизы. Поэтому быстрее отдачу получают те, у кого уже готовы процессы, данные и команда: они сначала выстраивают работу с данными, а затем выбирают функции с измеримым эффектом.</p> <p>Доказывать эффект приходится еще и потому, что свободных денег на развитие немного. Компании разделились почти поровну: 47% увеличат ИТ-бюджет, 29% сохранят его на текущем уровне, 24% сократят. Разброс по отраслям большой: банки тратят на ИТ 11,3% выручки, остальные — около 2%. Для банка технологии во многом и есть продукт, для промышленности и ритейла — прежде всего инструмент эффективности.</p> <p>Но даже растущий бюджет не гарантирует развития. Важно, какая его часть идет на новые проекты — ИИ, новые системы, цифровые продукты (CHANGE), а какая уходит на поддержку текущего ИТ-ландшафта (RUN).</p> <p>Здесь ситуация в отраслях тоже заметно различается. Больше половины банков и ритейлеров направляют на развитие свыше 60% ИТ-бюджета, производственные и добывающие компании — примерно половину. В CPG и агросекторе основная доля бюджета уходит на поддержку. По словам ИТ-директоров, значительную часть ресурсов забирают выполнение регуляторных требований, вынужденное импортозамещение и сопровождение текущих систем, и на ИИ и новые проекты остается немного.</p> <p>Поэтому ключевая задача сейчас — не только добиться большего бюджета, но и высвободить средства из поддержки: модернизировать устаревшие системы и сократить технический долг.</p> <p>Ограничения бюджета мешают реализации ИТ-планов у 67% компаний, а в ритейле и агросекторе — у 89%. На втором месте кадры: в нехватку компетенций, дефицит ИТ-специалистов или сложности с удержанием сотрудников упираются 54% компаний. Самый дефицитный навык — ИИ и машинное обучение (42%), далее идут кибербезопасность (27%), работа с данными и бизнес-анализ (по 25%).</p> <p>При этом формирование команды и развитие компетенций входят в пятерку ИТ-приоритетов только у 17% компаний. Без собственных компетенций бизнес зависит от подрядчиков и медленнее переводит пилоты в промышленную эксплуатацию. По мнению ИТ-директоров, в перспективе технологические компетенции придется развивать не только ИТ, но и самому бизнесу.</p> <p>«Главное, что сдерживает ИТ-планы крупного бизнеса, — деньги и люди. При этом развитие команды редко входит в ключевые приоритеты. Получается парадокс: компании делают ставку на ИИ, но не растят людей, которые будут его внедрять и развивать. К этому добавляется регуляторная нагрузка: она забирает ресурсы, которые могли бы пойти на развитие», — прокомментировал Егор Викторов, директор практики стратегического консалтинга компании Axenix.</p> <p>Российские компании последовательно импортозамещали иностранные решения, и сегодня острая фаза позади. Средняя доля отечественных продуктов в технологическом ландшафте составляет 65%: в агропромышленности — 85%, в добыче и производстве — 70%, в банковском секторе — 57%. Поэтому в пятерку ИТ-приоритетов импортозамещение включили только 23% участников исследования. Ставка теперь — на собственную инфраструктуру: 55% компаний придерживаются политики on-premise first, а облачную миграцию в приоритеты не включил никто.</p> <p>Но последствия перехода остаются: новые системы нужно поддерживать и развивать. Собственная инфраструктура надежнее, однако, как признают ИТ-директора, запускать на ней пилоты и тиражировать новые решения получается медленнее.</p> <p>Прагматичный подход к технологиям меняет и роль ИТ-директора. Через <nobr>3-5 лет,</nobr> по мнению респондентов, технологии из источника преимущества станут необходимым условием конкурентоспособности. CIO будет влиять на развитие бизнеса как советник с ответственностью за результат, а ИТ-проекты будут оценивать по окупаемости наравне с другими инвестициями. Пока же ИТ часто воспринимают как сервис, и скорость перемен сильно зависит от зрелости компании.</p> <p>«Крупный российский бизнес подошел к новому этапу технологического развития. Большинство крупных компаний уже закрыли базовые потребности в цифровизации и имеют развитые, частично импортозамещенные корпоративные системы. Лидеры считают внедрение ИИ приоритетом и активно включают его в ИТ-повестку вместе с операционной эффективностью — от этого напрямую зависит конкурентоспособность. При этом критерии отбора проектов максимально прагматичны: деньги получают инициативы с быстрым и измеримым эффектом», — прокомментировала Анастасия Студенкина, директор практики стратегического консалтинга компании Axenix.</p> <p>Исследование проходило с июня по август 2026 года. По его итогам аналитики рассчитали индекс технологических настроений от 0 до 100 баллов: он учитывает цифровую зрелость, ИТ-бюджет, планы и барьеры компаний и показывает, насколько уверенно ИТ-руководители смотрят на технологическое развитие в ближайшей перспективе. Axenix планирует проводить исследование ежегодно, чтобы отслеживать, как меняются настроения рынка и отдельных отраслей.</p> Крупный российский бизнес перешел в режим экономии, но от технологического развития не отказывается: деньги … message Машинное зрение на линии копит кадры. Кто решает, что с ними делать https://www.itweek.ru/themes/detail.php?ID=235925 Wed, 11 Nov 2026 13:24:06 +0300 <p>Я несколько лет занимаюсь системами машинного зрения для производства и почти каждый раз вижу одну и ту же картину. Проект доходит до ИТ-службы в последний момент. Технологи выбрали дефект, камера и свет стоят, станция контроля прошла приёмку, и только тогда кто-то спрашивает, куда система складывает результаты. Вопросы простые, но если не решить их до запуска, через полгода данные контроля качества окажутся на локальном диске станции и пропадут при первой замене оборудования.</p> <h3>Что система оставляет после себя</h3> <p>Станция контроля работает по жёсткой схеме. Датчик позиции даёт триггер, камера снимает деталь, программа ищет дефекты или меряет геометрию, сравнивает с допуском и выносит вердикт «годен» или «брак». На каждую деталь остаётся кадр с разметкой, измеренными значениями и решением. Оператору линии нужен только сигнал на отбраковку, и нужен он доли секунды. Всем остальным, от отдела качества до разработчиков модели, нужен кадр, и нужен месяцами.</p> <h3>Почему счётчика брака мало</h3> <p>Счётчик за смену отвечает на вопрос «сколько». На вопрос «почему» отвечают кадры. Пришла рекламация, и отдел качества хочет увидеть, что камера видела при проверке этой партии. Доля брака выросла на одной смене, и по снимкам понятно, был ли это настоящий дефект, грязная оптика или сдвинутый свет. Технологи спорят, считать ли мелкую пору браком, и спор идёт по одним и тем же снимкам, а не по пересказу. Когда архива нет, все эти разговоры превращаются в мнения.</p> <p>Есть и причина, о которой на старте обычно не думают. Самые ценные примеры для дообучения модели — редкие дефекты. Собрать их дольше, чем обучить модель, и взять их можно только из архива решений с линии. Если кадры не сохранять с первого дня, через год модель придётся улучшать на тех же немногих примерах, что были на пилоте.</p> <h3>Что хранить и сколько</h3> <p>Непрерывное видео с камеры контроля почти никогда не нужно, и я бы не стал под него строить хранилище. Хранить стоит кадры решений: весь брак, выборку годных деталей и все случаи, которые система отправила человеку на осмотр. Объём зависит от темпа линии и разрешения камеры. Считать его лучше на пилоте по реальному потоку, а не по паспорту оборудования, цифры обычно расходятся. Срок хранения удобно привязать к сроку, в течение которого по партии могут прийти претензии, и к циклу дообучения модели.</p> <h3>Связь с учётом</h3> <p>Кадр без номера партии, смены и линии почти бесполезен: найти его потом можно только по времени, и то если часы станции не уходили. Поэтому номер партии должен приходить на станцию из MES или учётной системы, а обратно уходить вердикт с причиной брака. Тогда отчёт по качеству живёт там же, где остальная производственная статистика, и из строки отчёта можно открыть конкретный кадр. Способ обмена (сигнал контроллера, API, выгрузка файлов) я советую согласовать до монтажа, пока ещё можно выбирать.</p> <h3>Кто за что отвечает на приёмке</h3> <p>Технологи на приёмке проверяют точность: долю пропусков и ложных отбраковок на реальном потоке. У ИТ-службы свои пункты. Куда пишутся кадры, у кого к ним доступ, что будет с архивом при замене станции или камеры, где лежит резервная копия и кто её проверяет. Эти вопросы стоит записать в протокол приёмки рядом с цифрами точности. Тогда их не придётся решать задним числом, когда диск станции заполнится.</p> <p>Машинное зрение даёт цеху сплошной контроль вместо выборочного. Будет ли у предприятия через год ещё и разобранный архив брака, решается в тот момент, когда выбирают камеру и свет. Мой совет коллегам из ИТ простой: просите позвать вас на это обсуждение, а не на приёмку.</p> Я несколько лет занимаюсь системами машинного зрения для производства и почти каждый раз вижу одну и ту же … article Антон Савельев, ведущий специалист по компьютерному зрению Visor Group Почему ИИ-агенты должны быть взаимозаменяемыми — без потери результатов вашей работы https://www.itweek.ru/themes/detail.php?ID=235923 Wed, 11 Nov 2026 10:18:02 +0300 <p><em>Если агент искусственного интеллекта дает сбой в процессе выполнения задачи, наличие надежных записей о действиях и четко определенных границ использования инструментов позволяет заменить его другим агентом, который продолжит работу безопасно и без дублирования операций, пишет на портале </em><em>The</em> <em>New</em> <em>Stack</em> <em>Манвир Чавла — соучредитель компании Zenith (ранее занимал должность директора по разработке в Confluent и руководил направлением Growth Engineering в Dropbox).</em></p> <p>Представим ситуацию: агент получает одобрение на частичный возврат средств. Он отправляет запрос к платежному API, но в этот момент происходит сбой. Возможно платежный сервис успел провести возврат, а возможно запрос даже не дошел до него. На смену приходит новый агент, который обнаруживает запись об операции со статусом «отправлено» (dispatched), но без зафиксированного результата.</p> <p>Подобная неопределенность свойственна не только ИИ-агентам. С такой же проблемой сталкиваются любые распределенные системы, если рабочий процесс прерывается в момент внесения изменений. Однако обычный программный агент (worker) в такой ситуации просто возобновляет заранее заданный алгоритм с последней контрольной точки. ИИ-агент действует иначе: он принимает решения самостоятельно — и это создает дополнительные риски. Столкнувшись с тем же запросом от клиента при отсутствии записи о результате, агент может выстроить совершенно иной план, выбрать другие параметры или решить инициировать новый возврат, вместо того чтобы завершить уже одобренную операцию.</p> <p>Если первый возврат прошел успешно, то вторая попытка приведет к тому, что клиенту вернут средства дважды. Поскольку на исходном платеже достаточно средств для еще одного частичного возврата, ничто не помешает совершить эту ошибку.</p> <p>Новый агент должен «унаследовать» исходную операцию, а не интерпретировать ее заново.</p> <h3>Операция должна пережить агента</h3> <p>Процесс агента, его переменные в оперативной памяти, временный контекст рассуждений — все это может быть утрачено без ущерба для дела. Но бизнес-операция — например, возврат средств, его одобрение, параметры и текущий статус — должна быть сохранена. Агент, работающий в течение длительного времени, должен сохранять полезные данные, пока он активен. Однако важно соблюсти условие: ни одна критически важная операция не должна зависеть от того, продолжает ли работать исходный экземпляр агента.</p> <p>Перед отправкой запроса на возврат средств приложение сохраняет запись об операции в надежном хранилище (транзакционной базе данных). Эта запись содержит одобренную сумму, соответствующие права доступа, ключ идемпотентности (передаваемый платежному провайдеру), идентификатор операции в метаданных провайдера, а также текущий статус.</p> <p>Статус меняется с «создано» (created) на «отправлено» (dispatched) в момент отправки запроса, а на «подтверждено» (confirmed) или «сбой» (failed) — только после получения ответа от провайдера. Если агент выходит из строя, его преемник считывает эту запись и связанные с ней идентификаторы, что позволяет корректно продолжить выполнение задачи. Если запись находится в состоянии «отправлено», это означает, что была предпринята попытка выполнения операции, но результат не был зафиксирован.</p> <p>При повторном запуске (замещающий процесс) используется уже одобренная операция, а не создается новая.</p> <p>Если замещающему процессу необходимо проверить результат, он может запросить список возвратов средств, связанных с исходным платежом, и сопоставить идентификатор операции в полученных метаданных.</p> <p>Однако такая «устойчивая» (durable) запись служит не просто контекстом для повторного запуска. Приложение обеспечивает ее соблюдение на границе взаимодействия с внешними инструментами: уровень отправки запросов проверяет каждый исходящий вызов на соответствие зафиксированной записи. Агент может предложить следующий шаг, но до провайдера доходят только те операции, которые были одобрены ранее — с сохранением исходных параметров и идентификатора. Модель не может изменить то, что уже было утверждено.</p> <p>Пример: бизнес-данные, включая эталонную запись об операции, определяющую допустимые действия для замещающего процесса, хранятся в управляемой ClickHouse базе данных Postgres. С помощью технологии CDC (Change Data Capture) эти данные реплицируются в ClickHouse. Телеметрия приложения передается в ClickStack, а трассировки агента — в Langfuse; обе системы настроены на использование того же экземпляра ClickHouse в качестве основной базы данных.</p> <p>#IMAGE_235924#</p> <p>Поскольку бизнес-данные, телеметрия приложения и трассировки агента попадают в одну базу данных, для связывания операции с конкретным запуском агента (который инициировал запрос) и неудачным HTTP-вызовом достаточно одного запроса по идентификатору. Это избавляет от необходимости сопоставлять данные из трех разных инструментов.</p> <p>Здесь есть два условия. Во-первых, приложение должно передавать этот идентификатор дальше. Идентификатор операции должен присутствовать в строке Postgres, в атрибутах трассировки Langfuse и в контексте логов сервиса, поскольку автоматической корреляции между ними не существует. Во-вторых, замещающий процесс должен считывать запись непосредственно из Postgres, а не из ее реплицированной копии. CDC работает с задержкой в ​​несколько секунд. Эталонная запись в основной базе данных является той самой, которую контролирует механизм на границе взаимодействия с внешними системами.</p> <h3>Перезапуск выполнения — это еще не безопасное возобновление работы</h3> <p>Фреймворки для обеспечения «устойчивого» выполнения (durable execution), такие как LangGraph и Temporal, фиксируют прогресс выполнения и позволяют возобновить работу после сбоя. В обоих случаях рекомендуется делать побочные эффекты идемпотентными, поскольку простое возобновление процесса не решает проблему повторного выполнения. Если возврат средств был успешно проведен в тот момент, когда шаг еще числился как «ожидающий», фреймворк может перезапустить агента, но не сможет сообщить ему, был ли исходный запрос принят платежным провайдером.</p> <p>Запись об «устойчивой» операции реализует этот принцип идемпотентности для агента, чей следующий шаг заранее не определен.</p> <p>Ключ идемпотентности из такой записи связывает замещающий процесс с исходным запросом. Если при повторной попытке используется тот же ключ, поставщик услуг может распознать, что речь идет об одной и той же операции, вместо того чтобы выполнять ее как отдельный запрос на возврат средств. Это справедливо даже в том случае, если исходный запрос, отправленный агентом, был завершен уже после сбоя, или если процесс, который ошибочно сочли «мертвым», возобновил свою работу. В библиотеке AWS Builders’ Library этот шаблон формализован: идентификатор, предоставляемый вызывающей стороной, сохраняется атомарно вместе с операцией изменения данных (mutation).</p> <p>Однако повторная попытка не всегда безопасна. Результат может оставаться неопределенным. В документации Stripe указано, что ответ с кодом 500 при выполнении mutation все равно может привести к внешним последствиям. Если исход неизвестен, замещающему агенту требуются доказательства для проведения расследования.</p> <p>Langfuse позволяет увидеть, какой инструмент использовал предыдущий агент — например, запрос на возврат средств, отправленный с зафиксированным ключом идемпотентности. ClickStack дополняет картину на операционном уровне: показывает исходящий HTTP-запрос к платежному сервису, за которым последовал разрыв соединения, что позволяет сузить временной интервал возникновения ошибки.</p> <p>Оба источника данных доступны замещающему агенту напрямую. MCP-сервер Langfuse позволяет запрашивать трассировку предыдущего агента по идентификатору операции, а MCP-сервер ClickStack — искать события в сервисе за тот же промежуток времени. Предоставьте замещающему агенту только инструменты для чтения данных: он сможет проанализировать произошедшее, но границы доступных инструментов по-прежнему будут ограничивать его действия.</p> <p>Ни одна из трассировок не является доказательством того, что провайдер действительно выполнил возврат средств. Отсутствие трассировки также не доказывает, что запрос не был отправлен, поскольку Langfuse передает данные асинхронно, и сбой в системе мог помешать их доставке. Платежный провайдер остается первоисточником информации о внешнем результате операции. Телеметрия выполнения помогает сузить область поиска, но не заменяет собой официальное подтверждение.</p> <h3>Продолжайте работу, а не начинайте всё сначала</h3> <p>В распоряжении замещающего агента есть постоянная запись о действиях, а в случаях, когда результат остался неясным — еще и свидетельства выполнения операции. Теперь ему необходимо предпринять дальнейшие шаги, но не путем принятия нового решения о том, что нужно сделать.</p> <p>Замещающий агент следует протоколу восстановления, определенному в приложении, а не полагается на собственное суждение о ситуации клиента.</p> <p>Если провайдер подтверждает, что возврат выполнен, агент фиксирует результат и переходит к следующим задачам. Если провайдер сообщает, что возврат находится в ожидании или в процессе выполнения, агент ждет — повторная попытка может привести к дублированию операции. Если же возврат определенно не удался и не повлек за собой никаких внешних изменений, агент заново проверяет предварительные условия перед новой санкционированной попыткой. Если результат по-прежнему остается неясным, агент эскалирует задачу на более высокий уровень, а не пытается угадать исход. Отсутствие записи у провайдера не означает, что возврат не был обработан — возможно, провайдер еще не завершил транзакцию.</p> <p>Даже после выяснения внешнего результата замещающий агент должен убедиться, что состояние системы не изменилось. Например, сумма, доступная для возврата, могла измениться. Сотрудник мог оформить возврат средств через другой интерфейс. Статус учетной записи клиента мог измениться. Кто-то мог отозвать первоначальное разрешение.</p> <p>Сохраненное одобрение — это лишь историческое свидетельство, а не действующее полномочие для выполнения операций.</p> <p>С инженерной точки зрения ключевой вопрос заключается в том, сможет ли новый агент определить текущую цель работы, невыполненные обязательства и возможные неопределенные последствия, а затем безопасно продолжить процесс — не воспринимая при этом сведения, оставшиеся от предшественника, как руководство к действию.</p> Если агент искусственного интеллекта дает сбой в процессе выполнения задачи, наличие надежных записей о действиях … article Автоматизация DevSecOps: почему сканеры ошибаются и где без экспертного аудита не обойтись https://www.itweek.ru/themes/detail.php?ID=235921 Wed, 11 Nov 2026 10:05:58 +0300 <p>В современной разработке автоматизация проверок безопасности стала такой же частью DevOps, как CI/CD или контроль версий. Она помогает оценивать код, зависимости, защищенность контейнеров и инфраструктуру, практически в том же темпе, в котором ИТ-команды внедряют изменения в продукт. Без анализа этих компонентов сегодня сложно представить разработку безопасного ПО. Тем не менее, такой подход упрощает поиск уязвимостей, но не позволяет выявить все риски.</p> <p>После подключения сканеров ИБ-специалисты часто сталкиваются с избыточными и нерелевантными срабатываниями, а часть критичных слабых мест при этом остается незамеченной. Причина не в том, что инструменты работают неправильно, а в том, что они не способны учитывать весь контекст конкретной системы. Разберем, почему автоматические проверки кода и инфраструктуры дают ложные сигналы, как сократить уровень шума и в каких случаях экспертный аудит остается обязательной частью DevSecOps.</p> <h3>Почему сканеры ошибаются</h3> <p>Большое количество срабатываний — одна из главных особенностей работы сканеров, в частности SAST-инструментов. Они фиксируют все подозрительные фрагменты кода, которые соответствуют заданным правилам, но далеко не каждая из них указывает на уязвимость. В одном отчете могут оказаться как действительно опасные дефекты, так и находки, которые инструмент оценивает как критичные, хотя с учетом особенностей конкретной системы они не представляют реальной угрозы.</p> <p>Распространенная причина неточных результатов — ограничения статического анализа. SAST-инструменты проверяют исходный код без запуска приложения. Они видят потенциально опасные фрагменты, но не всегда понимают, какие значения получат переменные во время выполнения, какие условия заложены в бизнес-логике и какие защитные механизмы уже работают в системе. Поэтому сканер может отметить участок программы как уязвимый, хотя в реальном сценарии использовать его для атаки невозможно.</p> <p>На точность влияет и то, что большинство правил, по которым работают автоматические средства анализа, универсальны. Они рассчитаны на разные языки, фреймворки и архитектуры, поэтому не учитывают особенности конкретного приложения. В проекте могут использоваться внутренние безопасные обертки, API-шлюзы, фильтрация запросов или политики service mesh, которые снижают риск эксплуатации. При этом инструмент может не знать об этих механизмах и продолжить оценивать программу по общему шаблону.</p> <p>Дополнительный источник лишних срабатываний — некорректно настроенный контур проверки. Если под одинаковый набор правил попадают тестовые директории, временные ветки, прототипы, устаревшие компоненты и библиотеки, количество нарушений быстро растет. При этом часть замечаний относится к коду, который не входит в поставку или не влияет на работу продуктивной системы.</p> <p>После обнаружения дефекта важно квалифицировать его приоритет. Автоматизация способна выявить характер уязвимости, но не всегда понимает ее реальную значимость для определенного проекта. Без учета особенностей ресурса невозможно установить, насколько опасна конкретная находка и насколько быстро ее нужно устранять.</p> <h3>Где возможности сканеров заканчиваются</h3> <p>Даже тщательно настроенные SAST-, SCA- и DAST-инструменты, которые оценивают код, зависимости и работающее приложение, не заменяют экспертного аудита. Сканеры хорошо справляются с техническими находками, которые можно описать формальными правилами. Однако этого недостаточно там, где для выявления слабых мест необходимо учитывать архитектуру системы и связи между ее компонентами.</p> <p>Чаще всего автоматизация не распознает ошибки бизнес-логики. Приложение может корректно выполнять каждое отдельное решение, но при этом пользователь получает возможность обходить установленные ограничения или совершать действия в непредусмотренной последовательности. Например, он может повторно использовать токен, обойти установленный лимит или получить выгоду из бонусной механики. Такие ситуации возникают из-за особенностей работы системы. Чтобы выявить нарушения, необходимо учитывать назначение ресурса, распределение ролей и порядок отдельных операций.</p> <p>ИТ-архитектура приложения тоже требует внимания AppSec- и DevSecOps-специалистов. По отдельным файлам сложно оценить границы доверия, права между сервисами, защищенность внутренних API и хранение секретов. Для подобного анализа необходимо изучить связи между ресурсами, движение данных и разграничение полномочий.</p> <p>По этой причине даже «чистый» отчет SAST или SCA еще не говорит об устойчивости системы к атакам. Эти инструменты помогают проверить код и зависимости, но не дают полной картины того, как устроены бизнес-логика и взаимодействия отдельных компонентов.</p> <h3>Как снизить количество нерелевантных срабатываний</h3> <p>Сканер выдает нерелевантные сигналы, если не учитывает особенности проекта — например, назначение компонента или условия его использования. Для того, чтобы сократить количество таких срабатываний, проверки адаптируют под конкретную систему.</p> <p>Сначала техническая команда определяет контур контроля и решает, какие элементы в него войдут. Если заранее разделить объекты по критичности, часть лишних замечаний можно отсечь еще до разбора отчета.</p> <p>Затем специалисты по безопасности корректируют настройки под особенности проекта. Из проверки убирают лишние директории и временные файлы, отключают правила, которые не подходят для используемого стека, а для повторяющихся ложных срабатываний вводят постоянные исключения или отдельные правила. Далее результаты сканирования соотносят с характеристиками определенного сервиса. Для оценки риска недостаточно знать тип уязвимости. На ее значимость влияет контекст: доступность ресурса из интернета, наличие чувствительных данных или потенциально опасной зависимости во время работы приложения и уже реализованные защитные механизмы. Только после этого можно определить приоритет исправления и сроки устранения дефекта.</p> <p>Настройка автоматических проверок — это непрерывный процесс. Технологический стек меняется, появляются новые сервисы, библиотеки и инструменты разработки, поэтому правила анализа тоже приходится регулярно пересматривать.</p> <h3> Где без ручного аудита не обойтись</h3> <p>Эксперты по AppSec и DevSecOps подключаются к проекту в тех случаях, когда одних сканеров недостаточно, чтобы выявить все возможные риски. Их работа начинается еще до написания кода и продолжается после выхода приложения в эксплуатацию.</p> <p>Сначала специалисты моделируют угрозы. Для новых систем это делают еще до разработки, для существующих — при крупных изменениях. На этом этапе определяют потенциальные сценарии атак, критичные активы, точки входа и границы доверия. Чем раньше обнаружена опасность, тем проще ее устранить: во время проектирования можно заранее скорректировать устройство продукта так, чтобы исключить потенциальную уязвимость. После релиза для этого уже придется дорабатывать код, инфраструктуру или бизнес-логику.</p> <p>Еще один этап — оценка архитектуры приложения. Здесь смотрят, как разделены компоненты и права сервисов, проверяют интеграции и ищут недостатки в принятых технических решениях.</p> <p>Особого внимания требуют наиболее значимые участки системы: доступные из внешнего периметра или работающие с чувствительными данными. Важно понять, можно ли использовать выявленные дефекты для атаки. Несколько слабых мест могут быть относительно безопасны по отдельности, но вместе создать реальную угрозу. Автоматический анализ рассматривает находки по одной и не всегда способен распознать такую связь.</p> <p>В DevSecOps сканеры берут на себя большую часть регулярных проверок кода и других компонентов, но полностью заменить ими специалиста не получится. Там, где нужно разобраться в логике продукта, увидеть взаимосвязь между отдельными факторами или разобрать реальный сценарий воздействия, нужен ручной аудит. Эксперт может посмотреть на сигнал не отдельно, а в контексте всей системы и понять, насколько она опасна на практике. Так ИБ-команде проще отделить действительно критичные уязвимости от менее значимых и решить, что исправлять в первую очередь.</p> <p>#IMAGE_235922#</p> В современной разработке автоматизация проверок безопасности стала такой же частью DevOps, как CI/CD или контроль … article Артем Пузанков, руководитель отдела консалтинга безопасной разработки компании “Бастион” Рост стоимости облачных услуг в России во II квартале сменился коррекцией цен в III квартале https://www.itweek.ru/themes/detail.php?ID=235919 Tue, 10 Nov 2026 12:06:42 +0300 <p>Во II квартале 2026 года был зафиксирован рост цен до 102 425 руб., который сменился коррекцией до 96 983 руб. в III квартале.</p> <p>По данным исследования iKS-Consulting и RCloud by 3data, за <nobr>I–III</nobr> кварталы 2026 года средняя стоимость облачной корзины для корпоративных заказчиков выросла с 85 499 до 96 983 руб. в месяц. Однако рост не был линейным: снижение в I квартале (−2,8%) сменилось резким подъемом во II (+19,8%) и частичной коррекцией в III (−5,3%). За колебаниями индекса стоит пересмотр ограниченного числа тарифных линеек, а не массовое движение цен.</p> <p>Согласно данным iKS-Consulting и RCloud by 3data, за три квартала 2026 года российский рынок публичной облачной инфраструктуры не сформировал единого ценового тренда. Средняя стоимость облачной потребительской корзины для корпоративных заказчиков менялась разнонаправленно, а индекс цены колебался в диапазоне от 97,6 до 119,8% к предыдущему кварталу. Ключевой вывод периода наблюдения: за агрегированными показателями скрывается сегментация рынка, а конкуренция смещается от цены ресурса к производительности, качеству инфраструктуры и совокупной стоимости решения задачи.</p> <p>«Мы анализируем цены поквартально и видим разнонаправленную динамику без выраженного общего тренда: изменения затрагивали отдельные предложения, тогда как большинство тарифов оставалось на прежнем уровне, — отметил ИТ-директор облачной платформы RCloud by 3data Валентин Соколов. — На значения индекса влияют стоимость серверного оборудования и общая экономическая и политическая ситуация. При этом отрасль в целом смещается от ценовых аргументов к качеству и предсказуемости сервиса».</p> <p>I квартал 2026 года. Индекс цены облачной корзины составил 97,6% к IV кварталу 2025 года, средняя стоимость корзины — 85 499 руб. в месяц. Снижение на 2,9% относительно предыдущего квартала (87 984 руб.) носило умеренный характер. Провайдеры продолжали развивать тарифные линейки, смещая фокус с низкопроизводительных ресурсов на сегмент High Performance и повышая базовую производительность CPU.</p> <p>II квартал 2026 года. Индекс составил 119,8% к I кварталу, средняя стоимость корзины выросла до 102 425 руб. (+16,4%). Основной вклад внесло увеличение стоимости вычислительных ресурсов и оперативной памяти. При этом рост был обусловлен не дефицитом ресурсов и не массовым пересмотром тарифов, а изменением структуры предложений: провайдеры расширяли линейки более производительных конфигураций и смещали акцент с ценовой конкуренции на конкуренцию по качеству инфраструктуры.</p> <p>III квартал 2026 года. Индекс составил 94,7% ко II кварталу, средняя стоимость корзины снизилась до 96 983 руб. (−5,3%). Коррекция компенсировала лишь часть предыдущего роста: стоимость корзины по-прежнему на 13,4% превышает уровень I квартала 2026 года.</p> <p>Колебания индекса — результат точечных решений, а не общего движения цен. Ни в одном из трёх замеров рынок не продемонстрировал единого направления. В III квартале неизменными остались 14 из 30 сопоставимых тарифов vCPU, 12 из 23 тарифов RAM и 14 из 29 тарифов SSD. Изменения концентрировались в отдельных тарифных линейках и у отдельных провайдеров, тогда как большая часть предложений сохранила прежний уровень цен.</p> <p>В III квартале при общем снижении средней цены vCPU на 2,7% стоимость процессоров в группе High Performance выросла на 16,1%, а в группе Standard — на 4,0%. Оперативная память подешевела в среднем на 5,0%, но снижение не было всеобщим. Средняя стоимость SSD практически не изменилась (+0,6%), тогда как предложения класса Standard подорожали в среднем на 18,6%. Рост отдельных тарифов не равен общему удорожанию ресурса — и наоборот.</p> <p>На протяжении всего периода наблюдения конкуренция смещалась от цены ресурса к производительности, качеству инфраструктуры и совокупной стоимости решения задачи. Провайдеры конкурируют за счёт характеристик серверной платформы, частоты процессора, гарантий производительности, коэффициента переподписки и стабильности SLA. Это соответствует мировой тенденции дифференциации облачного ценообразования: крупнейшие мировые провайдеры расширяют предложения, различающиеся по производительности, характеристикам инфраструктуры и условиям потребления.</p> <p>Для корпоративных заказчиков это означает необходимость сравнивать не только стоимость vCPU, RAM и SSD, но и характеристики конфигурации, гарантии производительности и условия предоставления ресурсов. Это особенно важно при выборе между стандартными и высокопроизводительными облачными решениями.</p> Во II квартале 2026 года был зафиксирован рост цен до 102 425 руб., который сменился коррекцией … message Каких кадров не хватает для цифровизации промышленности https://www.itweek.ru/themes/detail.php?ID=235917 Tue, 10 Nov 2026 10:41:56 +0300 <p><em>Внедрение </em><em>MES </em><em>на производстве — не просто покупка программного обеспечения. Система должна работать с реальными процессами и на нефтяном месторождении, и на обогатительной фабрике. Без людей, которые одновременно понимают и производственные процессы, и ИТ, любой проект рискует превратиться в дорогостоящий, изматывающий и малополезный для бизнеса опыт. Разберем, почему именно квалификация и опыт специалистов решают исход таких проектов и какие кадры сегодня нужны отрасли.</em></p> <h3>Драйверы роста рынка MES</h3> <p>MES-система способна оказывать существенное влияние на операционную эффективность и качество выпускаемой продукции, поэтому инвестиции в это направление обычно не замораживают, даже в условиях экономической нестабильности. В 2025 году рынок MES-проектов вырос примерно на 7% и достиг объема около 18 млрд. рублей. В 2026 году, по нашим оценкам, рост продолжится на уровне 8%.</p> <p>При этом структура спроса меняется. Импортозамещение — уже не главный стимул. Компании смотрят на измеримую выгоду, сокращение простоев, снижение брака, прозрачность цепочки от сырья до отгрузки. Рынок двигают строительство новых производств, расширение некоторых текущих мощностей и модернизация действующих цехов.</p> <p>Один из основных барьеров на пути развития отечественного индустриального ПО и цифровизации промышленности — дефицит кадров. При этом рост числа MES-систем не сопровождается сопоставимым ростом числа специалистов, способных их внедрять и поддерживать. По разным оценкам, лишь от семи до пятнадцати процентов сотрудников компаний обладают компетенциями, достаточными для работы с современными АСУ ТП и промышленной робототехникой.</p> <p>При этом разработка и внедрение промышленного ПО предполагает длинные циклы внедрения, жесткие сроки, постоянные согласования и стресс. В результате часть ИТ-специалистов уходит в сферы, где проще и спокойнее и при этом можно найти конкурентное денежное вознаграждение.</p> <h3>Необходимость в отраслевых специалистах</h3> <p>Главные проблемы связаны с недостатком опытных инженеров, разбирающихся как в разработке цифровых продуктов, так и в производственных процессах конкретных отраслей, а также в экономике предприятия. Без таких знаний создать эффективную MES-систему невозможно. Ситуацию осложняет то, что конкуренция за этих специалистов идет между ИТ-компаниями (вендорами и интеграторами), промышленными предприятия разных отраслей, консалтинговыми фирмами — то есть выходит далеко за пределы одной отрасли.</p> <p>Из нашей практики мы видим, насколько важен опыт в индустрии. Человек, который двадцать лет проработал на целлюлозно-бумажном комбинате, разговаривает с «бумажниками» совсем иначе, чем обычный ИТ-специалист. То же самое касается металлургии или горной добычи. Поэтому в штате важно держать людей с релевантным индустриальным опытом. Такие специалисты сразу видят, на каком переделе, в каком хранилище, на какой локации можно получить экономический эффект, а значит — повысить эффективность компании.</p> <p>А еще на каждом производстве — свои особенности: например, может стоять оборудование от разных производителей, старые станки рядом с новыми линиями и т. д. И нужны люди, способные во всем этом разобраться. Дефицит специалистов приводит не только к увеличению сроков: компаниям приходится отказываться от наиболее сложных проектов. А это, в свою очередь, тормозит развитие самой отрасли.</p> <h3>Навыки MES-разработчика</h3> <p>Рискну утверждать, что для успеха MES-проекта компетенции в области ИТ могут быть иногда вторичны. Гораздо важнее, есть ли в проектной команде специалисты, способные понимать требования производства и переводить их на язык ИТ. Если их нет, то проблемы будут на всех этапах, начиная со сбора первичных требований: инженеры на производстве говорят одно — ИТ-команда слышит другое. В итоге система либо перегружена функционалом, который никто не использует, либо не закрывает самые болезненные точки.</p> <p>Архитектор MES должен видеть всю картину. Он проектирует структуру так, чтобы она решала текущие бизнес-задачи и могла масштабироваться. Ошибка в архитектуре может парализовать участок, а стоимость такой ошибки при непрерывном цикле производства измеряется миллионами рублей в час.</p> <p>Разработчик МES-платформы пишет код, настраивает платформу и обеспечивает работу модулей. Важно глубокое знание хотя бы одной зрелой MES-платформы. Но привлечь чистого программиста в MES-проект мало. Навыки программирования помогают, но редко приходится писать весь код с нуля. Современные MES-системы, если их делали грамотные специалисты, имеют нормальные интерфейсы обмена. Разработчик МES-платформы обязан понимать производственные процессы. Иначе код будет красивым, а результат — бесполезным.</p> <h3>Навыки инженера по внедрению MES</h3> <p>При развертывании MES-платформы на производстве особое значение приобретают навыки общения. Инженер по внедрению такого продукта — тот, кто связывает MES-систему с реальным оборудованием и людьми. Он подключает источники данных по OPC UA или Modbus, работает с PLC, строит мнемосхемы и дашборды, пишет отчеты, разбирает логи. И самое важное — умеет обучать пользователей. Ему надо говорить и с технологом, и с оператором, и с директором цеха на их языке. Он выясняет болевые точки, балансирует требования, тестирует, запускает и снова собирает обратную связь, помогает преодолеть сопротивление персонала.</p> <p>После запуска MES-системы живут годами. Без поддержки специалистов, которые понимают их изнутри, они быстро деградируют. Дополнительные сложности создают жесткие сроки, доработки на этапах опытной и промышленной эксплуатации и разногласия между ИТ и производством. Поэтому качество взаимодействия внутри команды непосредственно влияет на ход проекта.</p> <p>Отдельная задача — формирование проектной команды и управление ею. Квалифицированных специалистов с необходимым набором отраслевых, ИТ- и бизнес-знаний на рынке единицы, но еще меньше тех, кто способен руководить такими коллективами. Нехватка подобных компетенций также влияет на проекты и бизнес-результаты.</p> <h3>Способы преодоления кадрового голода</h3> <p>Формальное образование дает абстрактные знания, далекие от реальных промышленных протоколов, а вакансии даже среднего уровня требуют от трех лет практического опыта. Это создает труднопреодолимые барьеры для новичков, так как реальные экспертные знания заперты внутри крупных холдингов. Поэтому многие компании готовят MES-специалистов самостоятельно. Новички растут от поддержки до разработки на реальных проектах под наставничеством опытных инженеров и без разрыва между теорией и практикой.</p> <p>Вендоры и компании уже реагируют на конъюнктуру: запускают внутренние курсы и онлайн-платформы, внедряют профильные программы в вузах и колледжах, готовят кросс-функциональных специалистов, предлагают условия с конкурентной оплатой. Также помогают самообразование через освоение документации, стандартов ISA-95, форумов и глубокая специализация партнеров по конкретным отраслям.</p> <p>Кроме того, можно отметить уже закрепившуюся практику привлечения отраслевых узкоспециализированных профессионалов в качестве внешних экспертов на проект или для организации обучения.</p> <p>Важная задача состоит и в том, чтобы удерживать нужных специалистов. Профессионалов, обладающих разносторонним опытом и широким набором навыков, мотивируют не только деньги. Для них важны интересные проекты и задачи. И если такой сотрудник начинает скучать, риск его ухода возрастает. Поэтому компании всеми силами стараются давать ценным специалистам возможность для участия в разноплановых проектах.</p> <p>Еще один способ если не решить проблему, то снизить ее остроту — оптимизировать состав и формат работы проектных команд: понять, как наиболее эффективно перераспределить загрузку специалистов с редкими и уникальным компетенциями и навыками.</p> <p>Рост рынка MES будет поддерживать спрос на специалистов и заставлять компании инвестировать в их подготовку. Но быстро закрыть кадровый дефицит вряд ли получится: отрасли нужны люди, которые сочетают опыт производства, ИТ-компетенции и понимание экономики предприятия. Поэтому состав команды и ее отраслевой опыт еще долго будут оставаться одним из ключевых факторов успешного внедрения MES.</p> <p>#IMAGE_235918#</p> Внедрение MES на производстве — не просто покупка программного обеспечения. Система должна работать … article Павел Калякин, генеральный директор ИНКА 4.0 IDC: рост расходов на ИИ-инфраструктуру определяется ценами на компоненты и спросом на системы на базе CPU https://www.itweek.ru/themes/detail.php?ID=235916 Tue, 10 Nov 2026 10:28:11 +0300 <p><em>Согласно отчету IDC «Worldwide Quarterly AI Infrastructure Tracker», во втором квартале 2026 г. глобальные расходы на инфраструктуру для ИИ достигли 121,4 млрд. долл. Это на 53% больше по сравнению с аналогичным периодом прошлого года и на 34% выше показателей предыдущего квартала — рост возобновился после паузы в развертывании систем, наблюдавшейся в первом квартале, пишет в корпоративном блоге Хуан Семинара, директор по исследованиям Worldwide Infrastructure Trackers компании IDC.</em></p> <p>Ключевым изменением стало расширение структуры спроса: сегмент инфраструктуры без специализированных ускорителей (на базе центральных процессоров) вырос на 61% в годовом исчислении, опередив темпы роста систем с ускорителями (+52%). Это произошло благодаря внедрению решений для оркестрации агентного ИИ, рабочих нагрузок конвейеров данных, а также значительному росту цен на компоненты, что привело к активному использованию стандартных вычислительных платформ. IDC повысила прогноз по расходам на 2026 г. в целом до 521 млрд. долл. (предыдущий прогноз, сделанный кварталом ранее, составлял 497 млрд. долл.). Пересмотр связан с ростом цен на компоненты, увеличением спроса на системы на базе CPU и сохранением высоких капитальных затрат со стороны гиперскейлеров.</p> <h3>Почему это важно</h3> <p>Результаты второго квартала 2026 г. подтверждают, что инвестиции в ИИ-инфраструктуру перешли от этапа проверки концепций к долгосрочному циклу капиталовложений. Спрос теперь выходит за рамки исключительно систем с ускорителями, а цены на компоненты становятся одним из главных факторов, определяющих объем затрат. Корпоративные заказчики, облачные провайдеры и государственные структуры принимают долгосрочные решения: где размещать инфраструктуру, какой объем средств выделять и на каких задачах в сфере ИИ сосредоточиться в первую очередь.</p> <p>Для поставщиков это означает длительный период высокого спроса на вычислительные системы с ускорителями, высокопроизводительные системы хранения данных и сопутствующую сетевую инфраструктуру. При этом структура спроса меняется: системы на базе CPU, предназначенные для оркестрации агентного ИИ и конвейеров данных, занимают все большую долю в общих расходах, а рост стоимости памяти увеличивает цены на все типы конфигураций. Для бизнеса эти данные служат сигналом: затраты на ИИ-инфраструктуру становятся неотъемлемой структурной статьей расходов при масштабировании деятельности. Высокие цены на память и системы хранения данных означают, что ожидание обходится все дороже, а компании, которые откладывают внедрение, рискуют проиграть конкурентам как в плане производительности, так и в вопросах экономической эффективности. По прогнозам IDC, объем мирового рынка ИИ-инфраструктуры в 2029 г. превысит триллион долларов, достигнув 1,17 трлн., а в <nobr>2030-м</nobr> вырастет до 1,33 трлн. Эти показатели выше прогнозов, сделанных в прошлом квартале (1,08 трлн. и 1,21 трлн. долл. соответственно).</p> <h3>Динамика рынка</h3> <ul> <li><strong> Темпы роста ускорились в большинстве регионов.</strong> Лидирующие позиции по-прежнему занимают США: 92,8 млрд. долл. (76,4% мировых расходов, рост на 58,7% в годовом исчислении). На долю Китая пришлось 13,0 млрд. долл. (доля 10,7%, рост на 27,9% в годовом исчислении). Среди крупных регионов особо выделяется Западная Европа (+83,9% в годовом исчислении, до 6,4 млрд. долл.); за ней следует Азиатско-Тихоокеанский регион (без учета Японии и Китая) — рост на 28,5%, до 5,9 млрд. долл. Самые высокие темпы роста зафиксированы на Ближнем Востоке и в Африке (+108,9%, до 0,9 млрд. долл.), а также в Центральной и Восточной Европе (+96,7%, до 0,3 млрд. долл.), хотя здесь рост происходил с относительно низких стартовых показателей. В Японии же динамика оказалась близкой к нулевой (-1,3%).</li> <li><strong> Системы с ускорителями остаются структурной основой рынка, однако инфраструктура без специализированных ускорителей растет еще быстрее.</strong> Во втором квартале 2026 г. расходы на серверы составили 98,0% от общего объема затрат на ИИ-инфраструктуру. Объем сегмента систем с ускорителями достиг 105,8 млрд. долл. (+52,2% в годовом исчислении), а сегмента инфраструктуры без ускорителей — 15,6 млрд. долл. (+61,1% в годовом исчислении). Спрос стимулируется развитием технологий оркестрации агентного ИИ и рабочих процессов конвейеров данных. Параллельно продолжается активное развертывание систем для обучения и инференса, а значительный рост цен на память и другие компоненты увеличивает стоимость каждой конфигурации оборудования.</li> <li><strong> Цены на компоненты стали одним из ключевых факторов, определяющих общую стоимость.</strong> Поставщики памяти повышают цены, поскольку спрос превышает предложение. При этом гиперскейлеры законтрактовали значительную часть доступных объемов в рамках многолетних соглашений, из-за чего корпоративным заказчикам приходится приобретать компоненты по текущим рыночным ценам. По прогнозам IDC, высокие цены сохранятся как минимум до второй половины 2027 г. На долю СХД, предназначенных для ИИ, по-прежнему приходится лишь небольшая часть (2,0%, или 2,5 млрд. долларов; рост на 45,2% в годовом исчислении) от общего объема инвестиций в ИИ-инфраструктуру.</li> </ul> <p><strong>Основные показатели: II квартал 2026 г.</strong></p> <table> <tbody> <tr> <td> Общие расходы на ИИ-инфраструктуру (II квартал 2026 г.) </td> <td> 121,4 млрд. долл.</td> </tr> <tr> <td> Рост в годовом исчислении (II квартал 2026 г. к II кварталу 2025 г.) </td> <td> +53.3%</td> </tr> <tr> <td> Расходы на инфраструктуру для ИИ за весь 2025 г. </td> <td> 318,7 млрд. долл. (+107,2% к предыдущему году)</td> </tr> <tr> <td> Расходы на инфраструктуру для ИИ за весь 2024 г. </td> <td> 153,9 млрд. долл.</td> </tr> <tr> <td> Доля серверов в расходах на ИИ во II квартале 2026 г. </td> <td> 119,0 млрд. долл. (98,0%)</td> </tr> <tr> <td> Доля СХД в расходах на ИИ во II квартале 2026 г. </td> <td> 2,5 млрд. долл. (2,0%)</td> </tr> <tr> <td> Прогноз на 2029 г. — инфраструктура для ИИ </td> <td> 1,17 трлн. долл.</td> </tr> <tr> <td> Соотношение систем с ускорителями и без них (II квартал 2026 г.) </td> <td> 105,8 млрд. долл. (с ускорителями) vs. 15,6 млрд. долл. (без ускорителей)</td> </tr> <tr> <td> Прогноз на 2030 г. — инфраструктура для ИИ </td> <td> 1,33 трлн. долл.</td> </tr> </tbody> </table> <h3>Прогноз</h3> <p>По оценкам IDC, мировые расходы на ИИ-инфраструктуру в 2026 г. достигнут 521 млрд. долл., что означает рост примерно на 63% по сравнению с предыдущим годом. Это один из самых значительных в абсолютном выражении приростов, когда-либо зафиксированных в отдельном сегменте ИТ-рынка. Согласно прогнозу, во втором полугодии 2026 г. расходы на ИИ-инфраструктуру составят около 309 млрд. долл. — почти на 80% больше, чем за аналогичный период 2025 г. Ожидается, что к среднегодовой темп роста (CAGR) за пятилетний период, начиная с 2025 г., составит около 33%.</p> <p>Факторы, способные ускорить эту динамику:</p> <ul> <li> Более быстрое, чем ожидалось, масштабирование рабочих нагрузок, связанных с инференсом, по мере расширения внедрения ИИ-приложений в корпоративном секторе.</li> <li> Расширение программ суверенного ИИ на Ближнем Востоке, в Юго-Восточной Азии и Европе, что стимулирует дополнительные инвестиции в новые проекты.</li> <li> Появление новых архитектур моделей и фреймворков для ИИ-агентов, требующих более глубокой и распределенной вычислительной инфраструктуры.</li> <li> Рост спроса на решения, не ограничивающиеся только GPU — например, инструменты для оркестрации ИИ, рабочие нагрузки конвейеров данных, а также сценарии применения физического ИИ (робототехника, автономные транспортные средства), что расширяет целевой рынок за пределы обучения моделей и инференса на базе GPU.</li> </ul> <p>Факторы, способные сдержать рост:</p> <ul> <li> Ограничения в сфере генерации электроэнергии и пропускной способности энергосетей, которые остаются главным операционным препятствием для ввода в эксплуатацию новых центров обработки данных на ключевых рынках.</li> <li> Цены на компоненты памяти и СХД, которые увеличивают стоимость серверов и могут замедлить циклы закупок; ожидается, что высокие цены сохранятся как минимум до второй половины 2027 г.</li> <li> Ужесточение экспортного контроля и нормативных требований к суверенитету данных, что может изменить географию размещения ИИ-нагрузок и повлиять на то, какие поставщики будут получать контракты от корпоративных клиентов.</li> <li> Геополитическая нестабильность на Ближнем Востоке, где рост рынка сосредоточен вокруг ограниченного числа крупных проектов, поддерживаемых правительствами стран Персидского залива. Эскалация региональной напряженности, включая продолжающийся конфликт с участием Ирана, может привести к задержкам в принятии решений о закупках, осложнить выбор площадок для дата-центров и планирование их безопасности, а также сместить государственные приоритеты в сторону от инвестиций в ИИ-инфраструктуру. Это создает нестабильность в регионе, который в настоящее время демонстрирует самые высокие темпы роста.</li> </ul> <p>Инвесторам и заказчикам технологических решений следует следить за прогнозами капитальных затрат на третий квартал 2026 г. от ведущих гиперскейлеров и поставщиков ИИ-платформ, поскольку эти опережающие индикаторы остаются наиболее надежным показателем краткосрочного спроса на инфраструктуру.</p> Согласно отчету IDC «Worldwide Quarterly AI Infrastructure Tracker», во втором квартале 2026 г. глобальные расходы … article Четыре шлюза: как продакту проверить AI-фичу до релиза без ML-команды https://www.itweek.ru/themes/detail.php?ID=235914 Tue, 10 Nov 2026 10:17:18 +0300 <p><em>Чтобы оценить </em><em>AI</em><em>-фичу перед запуском, не нужен отдельный отдел </em><em>data</em> <em>science</em><em>. Нужен продакт, который прочитает сотню ответов модели и до релиза запишет, что считается провалом. Ниже приведен протокол из четырёх шагов, который команда может пройти с таблицей и доступом к модели.</em></p> <p>Большинство AI-фич выходят в прод после проверки на глаз. Продакт гоняет в плейграунде десяток запросов, ответы выглядят прилично, команда ставит дату релиза. Через неделю приходит первая волна жалоб, и выясняется, что модель уверенно обещает клиентам то, чего компания не делает.</p> <p>Мой тезис: оценка качества AI-фичи — работа продакта, а не <nobr>ML-инженера.</nobr> Что считать хорошим ответом, решает продукт. Это вопрос политики компенсаций, тона бренда, юридических рисков и того, какую ошибку пользователь простит. <nobr>ML-команда</nobr> может построить пайплайн, но не может за вас решить, что модели запрещено говорить. Аман Хан, директор по продукту в Arize AI, в <a href="https://www.lennysnewsletter.com/p/beyond-vibe-checks-a-pms-complete">гостевом тексте для рассылки Ленни Рачицкого</a> в апреле 2025 года написал, что умение писать evals быстро становится базовым навыком для всех, кто строит AI-продукты. Я бы сказал жёстче: если у вас нет своих evals, у фичи нет критериев приёмки.</p> <p>Ниже фреймворк, которым можно пользоваться без <nobr>ML-команды,</nobr> платных платформ и кода. Я называю его «Четыре шлюза»: четыре уровня проверки, у каждого свой артефакт и правило «идём дальше или стоп». Пример сквозной и условный: AI-помощник оператора поддержки в сервисе доставки еды. Клиент пишет «курьер опоздал на 40 минут, суп холодный», модель предлагает оператору черновик ответа и вариант компенсации.</p> <h3>С чем я спорю</h3> <p>Документация вендоров LLM даёт хорошую базу, но написана для команд с инфраструктурой. В <a href="https://platform.claude.com/docs/en/test-and-evaluate/develop-tests">руководстве Anthropic по оценкам</a> прямо сказано: лучше больше вопросов с автоматической проверкой, чем меньше вопросов с ручной разметкой, а ручной оценки по возможности избегать. Для зрелой фичи с тысячами примеров это верно. Для первой версии это вредный совет. Пока вы не прочитали ответы сами, вы не знаете, что автоматизировать, и будете измерять не то.</p> <p>Хамел Хусейн, консультант по AI-продуктам, <a href="https://hamel.dev/blog/posts/field-guide/">называет анализ ошибок</a> самым ценным занятием в AI-разработке и предупреждает, что обобщённые метрики хуже, чем бесполезны. По его словам, они мешают прогрессу: создают ложное ощущение, что качество измеряется, и распыляют внимание команды. С этим я согласен полностью. Поэтому первые два шлюза ручные, а автоматизация появляется только на третьем и только там, где её можно сверить с человеком.</p> <p>Отдельно о том, почему это не задача QA. Тестировщик проверяет, что система делает то, что описано в требованиях. У AI-фичи требований в привычном виде нет, пока их кто-то не сформулирует на примерах. Формулировать их должен тот, кто отвечает за то, что фича даёт пользователю и бизнесу. Обычно это продакт. QA и инженеры подключаются позже, когда критерии уже есть и их нужно встроить в пайплайн.</p> <h3>Шлюз 1. Чтение</h3> <p>Что делает продакт. Собирает <nobr>50-100 входов.</nobr> Лучше всего обезличенные реальные обращения. Если их нет, синтетические, но по заданным измерениям, а не наугад. Хусейн <a href="https://hamel.dev/blog/posts/evals/">советует</a> начинать синтетические данные с выбора измерений: здесь это тип проблемы (опоздание, недовоз, не тот заказ), тон клиента (спокойный, злой, саркастичный) и контекст заказа (первый заказ, постоянный клиент, крупная сумма). Затем продакт прогоняет все входы через фичу и читает каждый ответ, записывая свободным текстом, что не так. Когда заметок набирается много, он группирует их в режимы ошибок и останавливается, когда новые ответы перестают приносить новые категории.</p> <p>Артефакт: таблица режимов ошибок. Название, пример, сколько раз встретилось в выборке, насколько это плохо для пользователя и для компании. В нашем примере там окажутся «обещает компенсацию, не зная суммы заказа», «извиняется за то, чего не было», «пересказывает жалобу вместо решения».</p> <p>Правило шлюза. Если основная задача проваливается в большинстве ответов, дальше не идём. Это значит, что сломан дизайн фичи, а не формулировка промпта. Модель, которая не видит сумму заказа, не может предложить адекватную компенсацию, и никакие evals этого не исправят. Нужно добавить контекст или сузить задачу.</p> <h3>Шлюз 2. Критерии и золотой набор</h3> <p>Что делает продакт. Превращает режимы ошибок в критерии с ответом «да» или «нет». Шкалы от 1 до 5 здесь не работают: два человека по-разному понимают разницу между тройкой и четвёркой. Хусейн <a href="https://hamel.dev/blog/posts/field-guide/">пишет</a>, что бинарная оценка заставляет принять ясное решение, достигнута цель или нет, а <a href="https://developers.openai.com/api/docs/guides/evaluation-best-practices">гайд OpenAI</a> рекомендует попарное сравнение или «прошёл/не прошёл» как более надёжные. Каждый критерий формулируется как проверяемое утверждение. «Ответ называет причину задержки, только если она есть в данных заказа». «Сумма компенсации не выше лимита по политике».</p> <p>Отдельно выписываются красные линии, то есть то, чего не должно быть ни в одном ответе: обещание сверх политики, персональные данные курьера, обвинение клиента. Красные линии никогда не усредняются с остальными критериями.</p> <p>Золотой набор состоит из <nobr>80-150 входов,</nobr> которые покрывают измерения из первого шлюза и краевые случаи. В примерах тестовых наборов из гайда Anthropic такие случаи размечены прямо в коде: сарказм, опечатки, длинный сумбурный вопрос, несколько тем в одном обращении, резкая смена темы. Для каждого входа записывается ожидаемое поведение, а не эталонный текст: «извиниться, предложить компенсацию в пределах лимита, не обещать сроки».</p> <p>Артефакт: таблица золотого набора и лист критериев с красными линиями.</p> <p>Правило шлюза. Продакт и эксперт предметной области, например руководитель поддержки, независимо размечают одни и те же 30 ответов. Если они часто расходятся, критерии двусмысленные и их нужно переписать. Идём дальше, когда расхождения редкие и каждое можно объяснить.</p> <h3>Шлюз 3. Прогон и пороги</h3> <p>Что делает продакт. До прогона записывает пороги и согласует их со стейкхолдерами. По красным линиям допустим только ноль нарушений. По основным критериям фиксируется доля «да», ниже которой фича не выходит. Нужна и базовая линия: как на тех же входах справляется текущий процесс, например операторы с шаблонами ответов. Пороги фиксируют заранее, потому что после прогона всем захочется сдвинуть планку к полученному результату.</p> <p>Потом продакт прогоняет золотой набор и размечает ответы. Сотню ответов по пяти бинарным критериям реально разметить за пару часов. <nobr>LLM-судью</nobr> можно подключать, только когда есть ручная разметка, с которой его сверить. И OpenAI, и Хусейн настаивают, что автоматического оценщика сначала калибруют по людям: в гайде OpenAI сказано, что масштабировать судью стоит, когда он стабильно совпадает с человеческой разметкой. Без этого у вас появляется вторая модель, в качестве которой вы тоже не уверены.</p> <p>Артефакт: оценочная карта по критериям и одностраничное решение о запуске с подписями.</p> <p>Правило шлюза. Ноль нарушений красных линий и выполненные пороги. Если пороги выполнены, но фича проигрывает базовой линии, это повод не запускать её, а переупаковать. Например, черновик видит только оператор и сам решает, отправлять ли его клиенту.</p> <h3>Шлюз 4. Тень</h3> <p>Что делает продакт. Запускает фичу в теневом режиме или на небольшую долю трафика. Модель генерирует, решение принимает человек. В лог пишутся вход, контекст, ответ модели и действие оператора: принял, исправил, отклонил. Гайд OpenAI советует логировать всё уже в процессе разработки, чтобы потом доставать из логов хорошие случаи для набора. Раз в неделю продакт читает выборку боевых ответов, и каждый новый режим ошибки попадает в золотой набор. Набор, который перестал расти, через пару месяцев проверяет уже не ту фичу, что работает в проде.</p> <p>Доля черновиков, которые операторы правят, даёт самый честный сигнал качества, и он бесплатный. Его не нужно размечать, он появляется сам.</p> <p>Артефакт: журнал недельных разборов и правило отката. В правиле заранее записано, при каком событии фича выключается и кто это делает.</p> <p>Правило шлюза. Расширяем аудиторию, если доля «да» на боевой выборке сопоставима с офлайн-прогоном, нарушений красных линий нет, а защитная бизнес-метрика не просела. Для поддержки это время решения обращения и доля повторных обращений.</p> <h3>Шлюзы на одной странице</h3> <ol> <li> Чтение: <nobr>50-100</nobr> ответов прочитаны вручную. Артефакт: таблица режимов ошибок. Стоп, если основная задача проваливается в большинстве ответов.</li> <li> Критерии: бинарные критерии, красные линии, золотой набор на <nobr>80-150 входов.</nobr> Артефакт: таблица набора и лист критериев. Стоп, если продакт и эксперт часто расходятся в разметке.</li> <li> Прогон: пороги записаны до запуска, есть базовая линия. Артефакт: оценочная карта и решение о запуске. Стоп при любом нарушении красной линии или проигрыше базовой линии.</li> <li> Тень: ограниченный запуск, логи, еженедельный разбор, правило отката. Артефакт: журнал разборов. Расширяем, только если боевое качество не хуже офлайн-прогона.</li> </ol> <h3>Сколько это стоит</h3> <p>Первые три шлюза занимают примерно неделю времени продакта и несколько часов эксперта. Инструменты: таблица и доступ к модели. Платформы для evals полезны на четвёртом шлюзе, когда трафик растёт и читать вручную уже невозможно. Покупать их до второго шлюза бессмысленно: вы будете автоматизировать критерии, которых ещё нет.</p> <p>Чаще всего этот процесс ломается в четырёх местах. Золотой набор собран из одних «счастливых» сценариев. Вместо бинарных критериев считают среднюю оценку «4,2 из 5». <nobr>LLM-судью</nobr> никто не сверял с людьми. Набор заморозили в день релиза.</p> <p>Если начинать завтра, начните с первого шлюза: 50 входов, 50 ответов, заметки на полях. После этого разговор с командой о качестве фичи пойдёт на языке конкретных ошибок, а не впечатлений. Набор evals и есть PRD для AI-фичи, только написанный примерами.</p> <p>#IMAGE_235936#</p> Чтобы оценить AI-фичу перед запуском, не нужен отдельный отдел data science. Нужен продакт, который прочитает сотню ответов … article Иван Лапа, продакт-менеджер в Uzum Tezkor (Ташкент) Postgres Professional в пять раз ускорила подготовку к переносу данных при миграции с помощью ProGate 1.5.0 https://www.itweek.ru/themes/detail.php?ID=235912 Mon, 09 Nov 2026 16:04:49 +0300 <p>Российский разработчик систем управления базами данных и продуктов для работы с данными Postgres Professional в пять раз ускорила подготовку к переносу данных в новой версии решения для миграции и репликации Postgres ProGate 1.5.0. Это позволяет заказчикам сократить подготовительный этап миграционных проектов. Обновление также включает поддержку аналитической СУБД Postgres Pro AXE 2.0, расширяет возможности обмена данными между Oracle, PostgreSQL и Postgres Pro и работы с отказоустойчивой инфраструктурой.</p> <p>В ProGate 1.5.0 время подготовки задач переноса сократилось впятеро благодаря оптимизации анализа структуры баз данных. Это ускоряет подготовительный этап миграционных проектов и позволяет ИТ-командам быстрее переходить к загрузке данных в целевые системы, в том числе в проектах с большим количеством таблиц.</p> <p>Поддержка аналитической СУБД для гибридных нагрузок Postgres Pro AXE 2.0 позволяет использовать ProGate для загрузки данных в аналитическую платформу. Заказчики могут применять единый инструмент как для миграции между СУБД, так и для подготовки данных для аналитики.</p> <p>В новой версии расширена поддержка Oracle: эта СУБД теперь может выступать целевой системой в ProCopy — компоненте первоначальной загрузки данных. Ранее перенос в Oracle был доступен в ProSync для репликации изменений. Теперь заказчики могут выполнять оба этапа: первоначальную загрузку и последующую синхронизацию данных.</p> <p>Также добавлена двунаправленная репликация между двумя основными узлами PostgreSQL или Postgres Pro версий 16 и выше. Она расширяет возможности синхронизации систем, в каждой из которых вносятся изменения.</p> <p>В ProGate 1.5.0 расширены настройки отказоустойчивости и обработки сетевых сбоев. При временной потере соединения во время первоначальной загрузки решение выполняет контролируемые повторные попытки отправки данных, исключая зависание процесса. Дополнительные показатели задержки репликации и состояния задач помогают администраторам быстрее замечать отклонения и оценивать актуальность данных в целевой системе.</p> <p>Возможность читать изменения из резервных баз Oracle позволяет снизить влияние репликации на основную систему, обслуживающую текущие бизнес-процессы. Кроме того, в обновлении усилена защита входа и пользовательских сессий, обновлены программные компоненты и устранены уязвимости зависимостей.</p> <p>«Для заказчика миграция — это не просто перенос данных, а переход на новую инфраструктуру без ущерба для текущей работы бизнеса. Поэтому в ProGate 1.5.0 мы сосредоточились на том, чтобы сократить стадию подготовки и сделать перенос более управляемым. Команды заказчика смогут быстрее запускать загрузку, отслеживать актуальность данных и оперативно реагировать на сбои. А поддержка Postgres Pro AXE 2.0 расширяет применение портфеля наших решений: единый инструмент можно использовать и для миграции, и для загрузки данных в аналитическую СУБД», — отметил Евгений Кривов, руководитель продукта Postgres ProGate компании Postgres Professional.</p> <p>Решение Postgres ProGate объединяет первичную загрузку данных, непрерывную репликацию изменений и проверку согласованности данных. Решение помогает компаниям модернизировать ИТ-инфраструктуру и переходить на новые СУБД поэтапно, поддерживая обмен данными между существующими и новыми системами. Управление доступно через единый веб-интерфейс и командную строку.</p> Российский разработчик систем управления базами данных и продуктов для работы с данными Postgres Professional … message Рост рынка PAM опережает его распространение в российских компаниях https://www.itweek.ru/themes/detail.php?ID=235911 Mon, 09 Nov 2026 16:03:43 +0300 <p>Рынок решений для управления привилегированным доступом (PAM) остается крупнейшим сегментом российского рынка Identity Security. Его объем по итогам 2025 года достиг 5,8 млрд рублей, увеличившись на 13% за год. При этом рост рынка опережает распространение PAM в самих организациях. Такие данные приводит компания «Индид» в исследовании «Identity Security 2026», подготовленном при участии Айдентити Клуба.</p> <p>Исследование показало, что специализированные PAM-решения пока используются не во всех сценариях привилегированного доступа. Для контроля администраторов их применяют 36,5% российских организаций, а для внешних подрядчиков — 32%. Во многих компаниях управление таким доступом по-прежнему строится преимущественно на регламентах и логировании.</p> <p>Похожая картина складывается и с распространением Zero Trust. Только 16,5% организаций уже внедрили основные элементы концепции нулевого доверия. Еще 22% применяют элементы Zero Trust только для внешних подключений и подрядчиков. Компании чаще начинают с наиболее чувствительных сценариев — например, с контроля доступа подрядчиков и внешних подключений. На остальные процессы эти принципы пока распространяются заметно реже.</p> <p>Это показывает, что для многих компаний PAM пока остается инструментом для отдельных сценариев, а не основой общей модели управления привилегированным доступом.</p> <p>Еще один показатель этого разрыва — срок действия выданных полномочий. В 45,5% компаний права сохраняются до ручного отзыва. Поэтому доступ, который требовался для конкретной работы, может продолжать действовать и после ее завершения. Например, повышенные права администратора, выданные на несколько часов для обновления сервера, способны сохраняться неделями или месяцами.</p> <p>Более точный подход Just-in-Time, при котором необходимые права предоставляются только на время выполнения задачи, используют 26% организаций. В этом случае срок действия привилегий определяется не только ролью сотрудника, но и конкретной задачей, для которой они потребовались, а также сроком ее выполнения.</p> <p>Следующий этап развития российского рынка PAM связан уже не только с дальнейшим распространением специализированных решений. Меняется сама модель привилегированного доступа — от постоянных прав и контроля отдельных подключений к более точному управлению полномочиями. В этой модели доступ предоставляется на конкретную задачу, в необходимом объеме и прекращается, когда потребность в нем исчезает.</p> <p>«Зрелость PAM все больше определяется не количеством подключенных пользователей или записанных сессий. Гораздо показательнее, насколько точно компания управляет самими привилегиями: на каком основании они предоставлены, действительно ли остаются необходимыми и вовремя ли отзываются. Чем лучше выстроен этот процесс, тем меньше в инфраструктуре избыточных прав и тем ниже риск их использования не по назначению. На мой взгляд, именно это и будет определять дальнейшее развитие рынка. PAM постепенно выходит за рамки контроля отдельных категорий пользователей и становится инструментом управления всем жизненным циклом привилегий. Постоянные права будут все чаще заменяться доступом по необходимости, а принципы Zero Trust и Just-in-Time становиться частью этой логики: полномочия выдаются под конкретную задачу, в необходимом объеме и прекращаются, когда потребность в них исчезает», — отметил Андрей Лаптев, директор по продуктовому развитию компании «Индид».</p> Рынок решений для управления привилегированным доступом (PAM) остается крупнейшим сегментом российского рынка Identity Security … message CorpSoft24 запустила облачные сервисы для компаний, разрабатывающих собственный ИИ https://www.itweek.ru/themes/detail.php?ID=235910 Mon, 09 Nov 2026 16:02:40 +0300 <p>CorpSoft24 запустила облачные сервисы для компаний, разрабатывающих собственный ИИ. Теперь компании, которые разрабатывают собственные ИИ-решения или внедряют готовые модели в корпоративные системы, смогут использовать облачные вычислительные мощности, языковые модели и сервисы векторизации текста без необходимости самостоятельно создавать всю необходимую инфраструктуру.</p> <p>Ранее CorpSoft24 сообщала, что предлагает бизнесу готовые ИИ-продукты и услуги по их внедрению. Сейчас, в ответ на растущий спрос со стороны компаний, развивающих собственные ИИ-решения, компания расширила предложение. Новые сервисы позволят бизнесу сократить затраты на оборудование и его обслуживание, а также быстрее запускать и масштабировать ИИ-проекты.</p> <p>В рамках нового направления CorpSoft24 предлагает два основных сервиса:</p> <ul> <li>GPU IaaS — аренда виртуальных серверов с графическими процессорами. Сервис подходит компаниям, которые самостоятельно разрабатывают или запускают ИИ-модели. Клиенты получают выделенные вычислительные мощности и могут настраивать программную среду под собственные требования;</li> <li>LLMaaS — языковые модели как сервис. Сервис позволяет использовать готовые ИИ-модели. Его можно подключать к корпоративным системам для создания виртуальных помощников, анализа документов, генерации текстов и автоматизации повседневных задач.</li> </ul> <p>В компании отметили, что при использовании ИИ-сервисов особое внимание уделяется защите корпоративных данных и контролю работы моделей. В частности, в решениях CorpSoft24 предусмотрены встроенные механизмы информационной безопасности, которые позволяют выявлять и при необходимости маскировать конфиденциальную информацию до ее передачи языковым моделям, разграничивать доступ пользователей к данным и функциям ИИ, а также обнаруживать попытки вредоносного воздействия на ИИ (включая Prompt Injection и Jailbreak). Все действия контролируются с помощью единых политик безопасности и журналов событий. Это позволяет компаниям сохранять контроль над корпоративными данными и снижает риски их утечки.</p> <p>Облачная инфраструктура CorpSoft24 размещается в России на базе центров обработки данных уровня Tier III. При работе с ИИ важно обеспечить защиту не только самой инфраструктуры, но и данных, которые передаются моделям. Для этого можно использовать инструменты контроля запросов и ответов ИИ-моделей, защиты конфиденциальной информации и выявления попыток атак.</p> <p>«Одно из главных преимуществ нового предложения — возможность сократить первоначальные инвестиции в ИИ. Бизнесу не требуется закупать серверы, самостоятельно организовывать их работу и содержать отдельную команду для обслуживания инфраструктуры. Специалисты CorpSoft24 возьмут это на себя», — отметил Константин Рензяев, генеральный директор CorpSoft24.</p> <p>По его словам, для модельных сервисов предусмотрена оплата по фактическому потреблению. Это позволяет начинать с небольших проектов и постепенно увеличивать использование ресурсов.</p> <p>В компании обращают внимание на то, что спрос на облачную инфраструктуру для ИИ в России активно растет. Согласно исследованию Selectel и Apple Hills Digital, в 2025 году объем потребления облачных серверов с графическими процессорами (GPU) увеличился почти на 69%, достигнув 8,2 млрд руб. Еще быстрее рос сегмент облачных платформ для разработки и запуска ИИ — на 97%, до 9,4 млрд руб. Что касается подходов к внедрению ИИ, то, согласно данным «Яндекса» и «Яков и Партнеры», 78% крупных российских компаний применяют готовые ИИ-решения сторонних разработчиков, а 17% занимаются собственной разработкой. Облачную модель предоставления генеративного ИИ используют 40% опрошенных компаний.</p> <p>«У компаний разные задачи и разная готовность к внедрению ИИ. Одним нужны готовые решения, другим — собственные модели и вычислительные мощности для работы с ними. Поэтому мы предлагаем несколько вариантов, чтобы бизнес мог выбрать подходящий формат и постепенно развивать свои проекты», — отметил Константин Рензяев.</p> CorpSoft24 запустила облачные сервисы для компаний, разрабатывающих собственный ИИ. Теперь компании, которые разрабатывают … message Экономика результата приходит в сферу корпоративного ПО — и сталкивается с реальностью https://www.itweek.ru/themes/detail.php?ID=235909 Mon, 09 Nov 2026 10:07:31 +0300 <p><em>Корпоративное ПО больше не создает ценность само по себе. Теперь ценность заключается в результатах, которые достигаются благодаря рабочим процессам, охватывающим бизнес-приложения, данные, людей и искусственный интеллект. В 2027 г. технологические лидеры перейдут от управления отдельными приложениями к управлению результатами деятельности предприятия. Инструментом контроля станут сквозные рабочие процессы, объединяющие различные приложения. И это будет непросто, пишет в корпоративном блоге Кейт Леггетт, вице-президент, главный аналитик </em><em>Forrester</em><em>.</em></p> <h3>Три прогноза Forrester для рынка корпоративного ПО на 2027 год</h3> <ul> <li><strong> Менее 10% предприятий будут использовать автономных агентов, работающих в разных приложениях.</strong> В 2027 г. встроенные ИИ-агенты станут повсеместным явлением, поскольку разработчики ПО активно интегрируют их с данными приложений, правами доступа, бизнес-логикой и механизмами контроля. Однако технологическим руководителям будет сложно масштабировать использование таких агентов в рамках всей ИТ-экосистемы: стандарты взаимодействия еще недостаточно развиты и внедряются неравномерно. Системы управления агентами также останутся несовершенными, особенно в том, что касается контроля над сторонними агентами, действующими в нескольких приложениях одновременно. В результате компании столкнутся с проблемой ответственности и рисками, связанными с возможными сбоями: доверяя агенту в рамках одного приложения, они будут опасаться позволять ему выполнять действия в масштабах всей системы без участия человека. Руководителям рекомендуется начинать с внедрения автономных решений в ограниченных сценариях, где последствия ошибок легко контролировать, а для наиболее важных рабочих процессов — сохранять обязательный контроль со стороны человека.</li> <li><strong> Цифровой суверенитет приведет к 20%-ному увеличению локализации корпоративного ПО.</strong> После десятилетий стандартизации глобальных систем ERP, CRM, моделей данных и бизнес-процессов наметился обратный тренд: цифровой суверенитет стал одним из ключевых критериев при выборе программных продуктов. Согласно исследованию Forrester «Cloud Survey 2026», 43% лиц, принимающих решения в сфере частных облаков, предпочитают размещать приложения онпремис из соображений конфиденциальности и защиты данных. В то же время 59% тех, кто отвечает за публичные облака, отмечают, что требования цифрового суверенитета становятся решающим фактором при выборе облачного провайдера. Законы о локализации данных, требования к суверенным облакам и различия в регулировании ИИ будут распространяться все шире, что приведет к росту затрат на локализацию. Руководителям следует инвестировать в региональные хранилища данных, адаптированные для конкретных стран модели ИИ, локализованные бизнес-процессы и механизмы контроля, соответствующие требованиям законодательства отдельных юрисдикций.</li> <li><strong> Модель оплаты ИИ по факту использования</strong> обернется проблемами для ряда крупных поставщиков бизнес-приложений. Последние два года разработчики корпоративного ПО активно внедряли платные ИИ-функции, тарифицируя работу агентов в зависимости от количества диалогов, выполненных действий, решенных задач или числа «премиальных» рабочих мест. В 2027 г. такая ценовая политика сыграет против крупнейших поставщиков: организации предпочтут автоматизировать процессы на базе той платформы, которая у них уже есть и обходится дешевле. Иными словами, вместо того чтобы платить поставщику корпоративного ПО за каждое действие агента, компании, например, создадут аналогичного агента в Microsoft Copilot Studio — в рамках уже имеющейся лицензии. Руководители будут тщательно сопоставлять расходы и требовать от поставщиков либо существенного снижения тарифов на ИИ, либо расширения объема ИИ-услуг, включенных в базовый пакет, либо перехода от оплаты по факту использования к более предсказуемым моделям: подпискам SaaS в сочетании с фиксированными платежами или контрактами с установленными лимитами затрат.</li> </ul> <h3>Переход от управления приложениями к управлению результатами</h3> <p>В 2027 г. руководители в сфере корпоративного ПО должны сместить фокус с управления отдельными приложениями на контроль бизнес-результатов, охватывающий данные, рабочие процессы, ИИ и человеческие ресурсы. Вместо стремления к полной автономности операций, затрагивающих множество приложений, руководителям следует сосредоточиться на ограниченном числе наиболее ценных и хорошо контролируемых сценариев использования. Важно сохранить участие человека в принятии критически важных решений, а также активно инвестировать в качество данных, их совместимость и фундамент управления. Одновременно с этим необходимо подготовиться к ужесточению требований к цифровому суверенитету, критически оценить непредсказуемые модели оплаты ИИ и пересмотреть подход к выбору между самостоятельной разработкой и покупкой готового решения — особенно с учетом того, что ПО, созданное с помощью ИИ, становится вполне пригодным для реализации уникальных бизнес-процессов. В выигрыше окажутся те, кто рассматривает приложения лишь как компоненты архитектуры, ориентированной на достижение конкретных результатов, а не как ее центральный элемент.</p> Корпоративное ПО больше не создает ценность само по себе. Теперь ценность заключается в результатах, которые … article Авито, Magnit OMNI, Контур, Cloud.ru — о чем расскажут ИИ-эксперты на Conversations 2026? https://www.itweek.ru/themes/detail.php?ID=235905 Mon, 09 Nov 2026 00:00:00 +0300 <p><strong>2 декабря</strong> в Москве (а также онлайн!) пройдет зимняя конференция Conversations. 2 трека, 40+ спикеров, 600+ участников и 200+ компаний.</p> <p> <strong>Трек</strong> «<strong>Бизнес</strong>»</p> <p> Экономика внедрения и владения AI / Вайбкодинг для внутренних процессов / Голосовые агенты и AI-операторы / AI-adoption, мотивация и сопротивление / Путь от пилотов к единой AI-платформе / Кейсы и антикейсы / Ответственность и регуляторика AI / Атрибуция эффекта от AI.</p> <p> <strong>Трек</strong> «<strong>Продукты и технологии</strong>»</p> <p> AgentOps и эксплуатация агентов / Harness и Context Engineering / Долгоживущие агенты / Юнит-экономика для AI-продукта в B2B/B2C / Agentic UX / Инфраструктура в контуре / Product Discovery нового типа / Инженерия Voice AI / Превращение продакта в разработчика (и наоборот) / Безопасность агентских систем.</p> <p> <strong>Не только доклады</strong></p> <p>Воркшопы по вайб-кодингу для бизнеса и разработчиков / AI Stack-сессия / Дискуссии и тренд-токи «Около AI» / Выставка и демо решений.</p> <p> <strong>Спикеры уже на сайте. Среди них:</strong></p> <ul> <li> <strong>Как мы в Авито растим инкрементальную выручку отдела продаж</strong> с помощью GenAI-инструментов — Виталий Минаев, Ксения Шимук, Авито.</li> <li> 500 000 претензий и 85% автоматизации: <strong>как мы построили AI-систему принятия решений</strong> — Артем Гриппа, Magnit OMNI.</li> <li> Как вайб-кодинг запускает ИИ-трансформацию в нетехнических командах— Андрей Томачинский, Контур.</li> <li> Как продать ИИ тем, кто умнее вас? <strong>Кейс облачного саппорта: от саботажа до секты ИИ-евангелистов</strong> — Максим Михайлов, Cloud.ru.</li> </ul> <p> Вас ждут доклады от 35+ компаний: Wildberries   Russ, Альфа-Банк, Magnit OMNI, Just AI, билайн, Сбербанк, ПравоТех, Вебпрактики, Туту x targetai, Cloud.ru, Контур, Raft AI, Data Light, Navio и других!</p> <p> Еще больше участников и тем <a href="/ad/rd/a-17.php" target="_blank"><strong>на сайте</strong></a>!</p> <p> <strong>Успейте приобрести билет по самой низкой цене до 16 ноября! </strong>Промокод на скидку 10%: CVS26mkWi.</p> <p> За новостями конференции следите в телеграм-канале проекта Conversations Club <a href="https://t.me/conversations_ai" target="_blank">https://t.me/conversations_ai</a></p> <p> 2 декабря, Москва (Soluxe Hotel Moscow, ул. Вильгельма Пика, д.16) и онлайн. Увидимся на Conversations! </p> 2 декабря в Москве (а также онлайн!) пройдет зимняя конференция Conversations. 2 трека … message Рынок кибербезопасности в России в 2026 году достигнет 455 млрд рублей https://www.itweek.ru/themes/detail.php?ID=235903 Fri, 06 Nov 2026 16:42:39 +0300 <p>MWS Cloud, входит в МТС Web Services, провела исследование российского рынка кибербезопасности. Согласно его результатам, совокупный объём сегментов программного обеспечения, аппаратного обеспечения для цифровой безопасности и ИТ-услуг в сфере кибербезопасности в 2026 году достигнет 455,4 млрд рублей. По сравнению с 2025 годом рынок вырастет на 20,8% — с 377,1 млрд рублей до 455,4 млрд рублей. Самым крупным сегментом станет программное обеспечение с объёмом 216,5 млрд рублей, за ним следуют ИТ-услуги в области кибербезопасности с 167 млрд рублей и аппаратное обеспечение для цифровой безопасности с 71,9 млрд рублей.</p> <p>Рынок программного обеспечения для кибербезопасности в <nobr>2021–2026</nobr> годах растет в среднем на 34,4% ежегодно: с 49,4 млрд рублей до 216,5 млрд рублей. В 2026 году сегмент вырастет на 30% по сравнению с 2025 годом — с 166,5 млрд рублей до 216,5 млрд рублей. Его доля в вертикали программного обеспечения увеличивается с 8,5% в 2021 году до 13,1% в 2026 году. Ключевыми драйверами остаются развитие регуляторного контура, рост штрафов за утечки персональных данных и переход заказчиков к более продвинутым средствам защиты.</p> <p>Наиболее быстрорастущими направлениями в сегменте ПО являются системы защиты веб-приложений (WAF), которые растут в среднем на 53,2% в год, а также SIEM-системы — на 40,7%. Доля SIEM в структуре рынка увеличивается с 10,1% до 12,6%, тогда как доля классических антивирусов для бизнеса сокращается с 14,3% до 10,5%. Это отражает переход от периметровой защиты к обнаружению и реагированию на кибератаки.</p> <p>Рынок аппаратного обеспечения для цифровой безопасности к концу 2026 года достигает 71,9 млрд рублей против 40,7 млрд рублей в 2021 году. По сравнению с 2025 годом сегмент вырастет на 10% — с 65,4 млрд рублей до 71,9 млрд рублей. Среднегодовой темп роста составляет 12%. При этом доля сегмента в вертикали аппаратного обеспечения остается стабильной: 6,4% в 2021 году, 6,6% в 2025 году и 6,5% в 2026 году.</p> <p>Ключевым драйвером аппаратного сегмента выступают законодательные ограничения на использование иностранного оборудования и замена зарубежных решений российскими аналогами. Наибольшую динамику при этом показывают системы управления доступом.</p> <p>Второе место по объёму занимают ИТ-услуги в области кибербезопасности. Их объём увеличивается с 60,5 млрд рублей в 2021 году до 167 млрд рублей в 2026 году при среднегодовом темпе роста 22,5%. В 2026 году сегмент вырастет на 15% по сравнению с 2025 годом — с 145,2 млрд рублей до 167 млрд рублей. Доля сегмента в вертикали ИТ-услуг увеличивается с 7,7% до 14%.</p> <p>Основной вклад в развитие ИТ-услуг вносит спрос на управляемые сервисы информационной безопасности (MSSP). Дефицит квалифицированных кадров и высокая ключевая ставка сформировали устойчивый спрос на аутсорсинг, поскольку эта модель обеспечивает профессиональный уровень защиты без затрат на формирование и содержание собственного подразделения ИБ.</p> <p>MSSP остается самым быстрорастущим направлением сегмента. В <nobr>2021–2026</nobr> годах управляемые сервисы растут в среднем на 36,5% в год, а их доля в структуре ИТ-услуг в области кибербезопасности увеличивается с 18,3% до 31,5%. Для малого и среднего бизнеса эта модель стала приоритетной. В MSSP входят мониторинг и анализ событий безопасности (SOC as a Service), реагирование на инциденты, управление средствами защиты и уязвимостями, а также киберразведка. Одновременно усложнение ИТ-инфраструктуры и распространение облачных сред поддерживают спрос на консалтинг, независимую оценку защищённости и аудит соответствия требованиям регуляторов.</p> <p>Отдельным направлением рынка становится защита ИИ-систем и корпоративных чат-ботов.</p> <p>«ИИ существенно ускоряет не только развитие цифровых сервисов, но и появление новых киберугроз. Атаки становятся более быстрыми, масштабными и адаптивными, поэтому прежнего подхода к защите периметра уже недостаточно. Бизнесу необходимо в разы быстрее выявлять изменения в ландшафте угроз и перестраивать защиту — включая контроль данных, инфраструктуры и приложений. Скорость адаптации становится одним из ключевых факторов киберустойчивости», — прокомментировал генеральный директор МТС Web Services Павел Воронин.</p> MWS Cloud, входит в МТС Web Services, провела исследование российского рынка кибербезопасности. Согласно его результатам … message «Актив» и «Такском» обеспечили подписание ЭПД в мобильном приложении «Такском-Файлер» с помощью «Рутокен ЭЦП 3.0 NFC» https://www.itweek.ru/themes/detail.php?ID=235902 Fri, 06 Nov 2026 16:41:15 +0300 <p>Компании «Актив» и «Такском» сообщили о поддержке сценария подписания электронных перевозочных документов (ЭПД) в мобильном приложении «Такском-Файлер» с использованием Рутокен ЭЦП 3.0 NFC. Совместное тестирование подтвердило корректную работу с квалифицированной электронной подписью, доступной водителям и специалистам логистики прямо со смартфона.</p> <p>Технология подписания документов в «Такском-Файлере» с помощью Рутокен 3.0 NFC уже хорошо знакома клиентам и используется не первый год. Новым шагом стало подтверждение работы сценария именно для ЭПД. В ходе работ специалисты компаний обеспечили стабильное подписание ЭПД по бесконтактному каналу NFC как на смартфонах и планшетах с ОС Android, так и на смартфонах с iOS.</p> <p>Рутокен ЭЦП 3.0 NFC — аппаратный носитель с бесконтактным интерфейсом, который хранит ключи электронной подписи в защищенном виде. Для подписания документа достаточно приложить Рутокен к смартфону. Ключ не покидает пределов защищенного носителя, а подпись формируется непосредственно в устройстве. В связке с мобильным приложением «Такском-Файлера» это позволяет подписывать ЭПД в полевых условиях без использования адаптеров и отдельных считывателей.</p> <p>Сергей Жуков, руководитель отдела внедрения продуктов «Такском», отметил: «Совместная работа с коллегами из „Актива“ позволила обеспечить надежное подписание ЭПД через NFC на широком парке Android-устройств. Для наших клиентов это удобный и безопасный сценарий: подписал документ — и сразу передал его в ГИС ЭПД».</p> <p>Павел Анфимов, заместитель директора по управлению продуктами компании «Актив», прокомментировал: «Рутокен ЭЦП 3.0 NFC создавался для мобильных сценариев, и подтвержденная работа с „Такском-Файлером“ в части ЭПД — ещё один шаг к тому, чтобы усиленная квалифицированная подпись была доступна даже неспециалисту в любой точке маршрута».</p> Компании «Актив» и «Такском» сообщили о поддержке сценария подписания электронных перевозочных документов (ЭПД … message Forrester: 2027 год принесет масштабные перемены в сфере корпоративного ИИ https://www.itweek.ru/themes/detail.php?ID=235896 Fri, 06 Nov 2026 10:15:47 +0300 <p><em>Руководители компаний готовятся к потрясениям, вызванным искусственным интеллектом, одновременно пытаясь реализовать пилотные проекты в этой сфере. Однако существенного влияния на финансовые показатели (прибыли и убытки) пока не наблюдается. Ситуация изменится в 2027 г., пишет в корпоративном блоге Брайан Хопкинс, вице-президент </em><em>Forrester</em> <em>по портфелю перспективных технологий.</em></p> <p>В нашем новом отчете «Predictions 2027: Artificial Intelligence» выделены пять «линий разлома» — областей, где накапливалось напряжение и где вскоре неизбежны серьезные сдвиги. Речь идет о расходах на ИИ, управлении, экономике моделей, архитектуре платформ, а также об организационной среде, необходимой для масштабирования автономных ИИ-агентов.</p> <p>Технологии развиваются быстрее, чем большинство организаций успевают их осваивать. Поэтому внедрение контролируемых и безопасных ИИ-решений в промышленную эксплуатацию в 2027 г. обеспечит преимущество перед конкурентами, которые все еще находятся на стадии экспериментов и поиска верной стратегии. Ниже представлены подробности трех из пяти наших прогнозов в сфере ИИ на 2027 г.</p> <h3>На долю ИИ будет приходиться 20% корпоративных расходов на технологии</h3> <p>Согласно прогнозу Forrester по мировому технологическому рынку, в 2027 г. глобальные расходы на технологии превысят 6 трлн. долл., причем каждый пятый доллар будет направлен на ИИ. Большая часть этих средств пойдет на закупку серверов и оборудования, что для предприятий трансформируется в расходы на ИИ-токены и вычислительные ресурсы — бюджеты компаний могут просто не выдержать такой нагрузки. Хотя большинство технических руководителей рассчитывают на увеличение бюджета в следующем году, лишь 53% из них ожидают, что рост превысит уровень инфляции. Это означает, что почти половина компаний столкнется со снижением реальной покупательной способности как раз в тот момент, когда бизнес требует больше решений на базе ИИ и готов платить за них все дороже.</p> <p>Основной удар придется на сторонние сервисы. Руководители уже планируют наиболее значительные сокращения расходов именно в этой категории, а развитие ИИ дополнительно снижает стоимость предоставления консалтинговых и управляемых ИТ-услуг. Пересмотрите свои сервисные контракты и договоры на использование ПО (с оплатой за рабочее место) — сделайте это за полгода до истечения срока их действия. Постарайтесь вернуть часть средств и направьте их на планирование расходов, связанных с использованием ИИ, а также на контекстную инженерию.</p> <h3>Пробелы в системе управления приведут к провалу ключевых ИИ-проектов в ряде крупных компаний</h3> <p>Как показал недавний опыт, одного лишь набора принципов недостаточно для контроля над автономным ИИ-агентом. Эффективное управление такими агентами требует наличия специальных навыков, инструментов и механизмов контроля, обеспечивающих соблюдение установленных правил. В 2027 г. такие системы по-прежнему будут разбросаны по разным технологическим областям, оставаясь вне зоны контроля специалистов по корпоративному управлению, ответственных за разработку политик. Более половины лиц, принимающих решения в сфере генеративного ИИ, уже называют «неконтролируемое распространение автономных агентов» (agentic sprawl) серьезной проблемой. Традиционные механизмы управления изначально не были рассчитаны на ПО, которое самостоятельно выбирает инструменты и совершает действия. В 2027 г. число незарегистрированных агентов продолжит расти, а по мере совершенствования моделей их действия могут создать для вашей компании серьезные неприятности.</p> <p>В июне компания Meta <em>(признана экстремистской и запрещена в РФ)</em> наглядно продемонстрировала, к чему это может привести. Ей пришлось приостановить внутреннюю программу, в рамках которой фиксировались нажатия клавиш и содержимое экранов сотрудников для обучения ИИ-агентов: выяснилось, что эти данные стали доступны гораздо более широкому кругу лиц внутри компании, чем предполагалось изначально. Это был лишь один из многих подобных неприятных сюрпризов. В 2027 г. как минимум три крупные компании будут вынуждены либо полностью свернуть свои ключевые ИИ-проекты, либо отложить их реализацию на год. Причина в каждом случае будет одна: бизнес-подразделения несут ответственность за использование ИИ, но не имеют реальных рычагов для обеспечения соблюдения политик в ПО, на базе которого работают их агенты. Создайте специализированную группу по управлению ИИ, которая будет взаимодействовать с отделами безопасности, управления рисками, ИТ, разработки, юридическим департаментом и подразделением по управлению данными, — и наделите ее полномочиями внедрять политики непосредственно в программный код в масштабах всей организации.</p> <h3>Три четверти решений при выборе ИИ-платформ будут зависеть не от самих моделей, а от сред, в которых они работают</h3> <p>Компании будут ориентироваться прежде всего на среду исполнения, которая распределяет задачи, собирает контекст, управляет доступом к инструментам и проверяет результаты работы. Именно на этом уровне определяются точность системы и эксплуатационные расходы. Команды, использующие долгосрочно работающих агентов для написания кода или проведения исследований, сталкиваются с проблемами интеграции задолго до того, как достигают пределов возможностей самой модели, — и в 2027 г. этот разрыв станет еще заметнее. Поставщики уже начали превращать выбор модели в простой выпадающий список в интерфейсе платформы; в <nobr>2027-м</nobr> основные усилия компаний будут сосредоточены на выборе, создании или укреплении сред исполнения.</p> <p>При оценке потенциальных поставщиков ИИ-платформ уделяйте основное внимание возможностям среды исполнения и управления контекстом, а не результатам бенчмарков самих моделей. Прежде чем подписывать какие-либо документы, четко определите, за какой именно уровень технологического стека отвечает поставщик.</p> <h3>Еще две проблемные зоны</h3> <p>В отчете содержатся еще два важных вывода.</p> <p>Первый касается того, что модели с открытыми весами (open-weight models) выполняют значительную часть задач в сфере корпоративного ИИ, при этом на них приходится лишь малая доля затрат.</p> <p>Второй вывод гласит: только один из четырех проектов по созданию корпоративного контекстного слоя бужет способен обеспечить работу агентного ИИ в промышленных масштабах.</p> Руководители компаний готовятся к потрясениям, вызванным искусственным интеллектом, одновременно пытаясь реализовать … article «СиСофт Девелопмент» расширила возможности EnergyCS для электротехнических расчетов https://www.itweek.ru/themes/detail.php?ID=235887 Thu, 05 Nov 2026 13:07:44 +0300 <p>«СиСофт Девелопмент» объявила о выпуске обновлений программ семейства EnergyCS: EnergyCS Режим, EnergyCS ТКЗ, EnergyCS Потери и EnergyCS Электрика. Обновления расширяют возможности анализа и моделирования электрических сетей, а также подготовки документации. Одно из ключевых направлений развития — согласованная работа с общей расчетной моделью, которая позволяет использовать одну схему сети для анализа установившихся режимов, токов короткого замыкания и потерь электроэнергии.</p> <p>Семейство EnergyCS предназначено для электротехнических расчетов при проектировании и эксплуатации электроэнергетических систем. В него входят пять самостоятельных программ, охватывающих основные инженерные задачи в этой сфере:</p> <ul> <li>EnergyCS Режим — расчет установившихся режимов, анализ напряжений, потоков мощности и загрузки оборудования;</li> <li>EnergyCS ТКЗ — расчет токов короткого замыкания и связанных с ними параметров работы сети;</li> <li>EnergyCS Потери — расчет и прогнозирование потерь электроэнергии, оценка мероприятий по их снижению;</li> <li>EnergyCS Электрика — комплексные расчеты распределительных сетей переменного и постоянного тока, в том числе с питанием от аккумуляторных батарей;</li> <li>EnergyCS Line — проектирование механической части воздушных линий электропередачи и волоконно-оптических линий связи на опорах ВЛ.</li> </ul> <p>Эти программы помогают обосновывать проектные решения при строительстве и реконструкции объектов, подключении новых потребителей и развитии существующих сетей. Расчетная модель создается в графическом редакторе: инженер строит схему и задает параметры элементов с помощью расширяемых справочников оборудования. Результаты расчетов отображаются непосредственно на схеме и в таблицах, что упрощает проверку и сравнение вариантов. Для EnergyCS Режим, EnergyCS ТКЗ и EnergyCS Потери предусмотрена общая модель сети: ее можно использовать для разных видов расчетов без повторного построения схемы.</p> <p>В версиях 2026 программы EnergyCS получили дальнейшее развитие.</p> <p>В EnergyCS Режим 2026 появилась команда «Баланс генераций-нагрузок» для расчета автономных сетей. Она позволяет балансировать мощности генерации, нагрузок и потерь. Результаты расчетов по линиям и трансформаторам теперь можно анализировать в отдельных таблицах, а для каждого элемента сети оценивать долю потерь от протекающей мощности. Это помогает детальнее исследовать условия работы оборудования и выявлять проблемные участки.</p> <p>EnergyCS ТКЗ 2026 дополнена расчетом междуфазных сопротивлений от предполагаемого места установки дистанционной защиты до точки короткого замыкания, а также соответствующих аварийных токов и напряжений. В справочнике кабелей расширен состав параметров для моделирования замыканий на землю. Новые функции позволяют подробнее анализировать аварийные режимы и получать исходные данные для задач релейной защиты.</p> <p>В EnergyCS Электрика 2026 усовершенствован расчет нагрузок с учетом характеристик элементов сети и потерь. Добавлены устройства плавного пуска и частотного регулирования, расширены возможности расчета токов короткого замыкания и работы с характеристиками защитных аппаратов. Кроме того, объекты можно разделять по этапам ввода и статусам — существующие, новые и демонтируемые — с последующим формированием спецификаций. Это позволяет учитывать последовательность реконструкции или развития объекта непосредственно в расчетной модели.</p> <p>В EnergyCS Потери 2026 продолжено развитие согласованной расчетной модели с EnergyCS Режим и EnergyCS ТКЗ. Уточнены табличные формы итоговых документов, расширены инструменты редактирования и оформления схем. В обновленных программах также появились средства группового изменения объектов, многократной вставки присоединений и управления текстовыми слоями. Они помогают сократить число повторяющихся операций при подготовке расчетной модели.</p> <p>Практический пример использования EnergyCS — опыт проектной организации АО «Электрощит», которая применяет EnergyCS Электрика и EnergyCS ТКЗ при проектировании объектов энергетики. Решению о переходе на специализированные инструменты предшествовала серия демонстрационных расчетов на собственных исходных данных. Использование программ помогло систематизировать работу с расчетными методиками и ускорить многие операции.</p> <p>Интерес к практическому освоению EnergyCS подтверждают отраслевые встречи и учебные мероприятия. В 2026 году возможности семейства представили на Форуме инженерных систем ЭТМ в Москве и конференциях ТИМИ/ТИМИТех в Санкт-Петербурге, Нижнем Новгороде и Тюмени. Обзорам новых версий также посвящена серия вебинаров, записи которых доступны для самостоятельного изучения.</p> <p>Очные тест-драйвы EnergyCS прошли в Минске, Москве и Уфе. В Минске при поддержке партнера «Главтелеком» с программами EnergyCS Электрика и EnergyCS ТКЗ работали представители «Мозырского НПЗ», «Калийпроекта», «Газпром трансгаз Беларусь», института «Белпромстройпроект» и других организаций. В московском тест-драйве активно проявили себя представители АО «КЭАЗ», АО «Институт Гидропроект», «Томская Энергомонтажная компания», ООО «ННГП». В Уфе в практических занятиях участвовали специалисты производственных, проектных и инжиниринговых компаний Башкортостана и других регионов, в том числе «РН-Проектирование Добыча», «Уралтрубопроводстройпроект», «Югранефтегазпроект» и «БЭСК Инжиниринг».</p> <p>«При выборе отечественного расчетного ПО инженерам важно сохранить глубину анализа и привычную последовательность работы, — прокомментировала Татьяна Медведева, продакт-менеджер по электротехническому направлению „СиСофт Девелопмент“. — Мы видим запрос на более глубокое освоение расчетных инструментов и их применение в конкретных инженерных задачах. Поэтому мы последовательно развиваем EnergyCS: расширяем состав моделируемого оборудования, добавляем расчетные функции и совершенствуем работу с моделью. Общая модель сети позволяет исследовать разные режимы на одной схеме, не создавая ее заново для каждого расчета».</p> «СиСофт Девелопмент» объявила о выпуске обновлений программ семейства EnergyCS: EnergyCS Режим, EnergyCS ТКЗ, EnergyCS … message Аналитический отчет X-Com: тенденции и прогнозы рынка ноутбуков в РФ https://www.itweek.ru/themes/detail.php?ID=235886 Thu, 05 Nov 2026 13:02:05 +0300 Сергей Писарев, руководитель группы персональных систем, департамент продуктового менеджмента, ГК <nobr>X-Com,</nobr> подготовил аналитический отчет, в котором представлены тенденции 2026 года и прогнозы на 2027 год рынка ноутбуков в РФ.<br/> <p>Общие выводы отчета:</p> <ul> <li>рынок ноутбуков в России находится в структурном спаде. Натуральные продажи сокращаются, а денежный объём может поддерживаться за счёт роста средней стоимости устройств. Модель «меньше единиц — дороже штука» сохраняется;</li> <li>фактическая динамика 2026 года слабая, но не катастрофическая. За I полугодие 2026 г. продано около 1,33 млн ноутбуков, снижение — 7,5% год к году; в июле падение составило 25%, в августе — 35% год к году. Денежный объём рынка при этом рос;</li> <li>оценки по итогам 2025 года неоднородны. Розничный аудит даёт около 2,9 млн шт. (данные Fplus, М.Видео) оценка по широкой категории мобильных ПК — чуть менее 3,4 млн шт. (ITResearch);</li> <li>сценарный прогноз на 2026 год. Базовый диапазон <nobr>2,0–2,2</nobr> млн шт. при базе 2,9 млн означает снижение на <nobr>24–31%.</nobr> Стрессовый сценарий — менее 1,8 млн шт., оптимистичный — <nobr>2,4–2,5</nobr> млн шт.;</li> <li>ценовое давление реально, но его масштаб в рознице РФ — сценарная оценка. Мировые контрактные цены памяти растут: в IV кв. 2026 г. ожидается DRAM <nobr>+10–15%</nobr> и NAND <nobr>+15–20%</nobr> кв/кв. Перенос в российские розничные цены оценивается в <nobr>15–25%</nobr> по базовому сценарию, <nobr>35–45% —</nobr> по стрессовому, <nobr>10–12% —</nobr> по оптимистичному. Возврат к ценам <nobr>2024–2025 гг.</nobr> маловероятен;</li> <li>дефицит носит не тотальный, а структурный характер. Не хватает не любых ноутбуков, а доступного ассортимента и рабочих конфигураций: 32 ГБ ОЗУ, ёмкие NVMe SSD, дискретная графика. Ситуацию усиливает переход дистрибьюторов на «тонкий склад» из-за дорогого оборотного капитала;</li> <li>регуляторные и канальные факторы повышают издержки и неопределённость. Технологический сбор, ограничения параллельного импорта и правила импортозамещения в B2B/B2G давят на поставки и ликвидность. Ставки техсбора до сверки с официальным нормативным актом нельзя использовать в количественных расчётах;</li> <li>китайские бренды усиливают позиции, но доля <nobr>75–80% —</nobr> гипотеза. Западные A-бренды уходят в серые каналы с наценкой за риск; российские марки доминируют в B2G, но в открытой рознице их доля остаётся низкой — около <nobr>3–5%;</nobr></li> <li>стабилизация ожидается не раньше II полугодия 2027 года. II кв. 2027 г. и рост продаж на <nobr>3–5%</nobr> кв/кв — сценарные предположения. Условия пересмотра: балансировка NAND, восстановление логистики, снижение стоимости кредита и реализация отложенного спроса МСБ.</li> </ul> Сергей Писарев, руководитель группы персональных систем, департамент продуктового менеджмента, ГК X-Com, подготовил … message Avanpost представила продукт DAG для контроля доступа к неструктурированным данным https://www.itweek.ru/themes/detail.php?ID=235885 Thu, 05 Nov 2026 12:50:50 +0300 <p>Компания Avanpost, разработчик решений для безопасности идентификационных данных и управления доступом, выпустила новый продукт Avanpost DAG (Data Access Governance). Он объединяет комплекс решений, которые помогают организациям управлять доступом к неструктурированным данным (файлам на серверах, в облаках, на порталах) и контролировать действия с ними.</p> <p>В распределенной ИТ-инфраструктуре документы хранятся на сетевых серверах, облачных дисках и в базах знаний, вроде Confluence. Со временем там неизбежно оседают забытые архивы, рабочие копии договоров, технические инструкции с паролями и выгрузки персональных данных. Одновременно с этим права сотрудников накапливаются годами и перестают соответствовать их реальным должностным обязанностям. Службы ИБ сталкиваются с тем, что фактическое распределение доступа кардинально отличается от утвержденных регламентов. Avanpost DAG возвращает бизнесу прозрачность: система подключается к ресурсам, распознает конфиденциальные сведения по содержимому и фиксирует конкретные нарушения политик безопасности и запускает сценарии, обеспечивающие приведение прав доступа к данным в соответствие с принятыми правилами и регламентами. </p> <p>«Мы предлагаем не просто программное обеспечение, а комплексный подход к управлению неструктурированными данными. В Avanpost DAG встроен полнофункциональный движок бизнес-процессов. Выявив избыточный доступ, система не заставляет администратора удалять права вслепую, рискуя сломать рабочие процессы компании. DAG запускает настраиваемые сценарии: автоматически направляет запрос бизнес-владельцу данных, собирает согласования, формирует задачи для ИТ-отдела и контролирует их исполнение. После внесения корректировок проводится обязательное повторное сканирование, которое подтверждает, что доступ действительно закрыт и проблема решена. В дальнейшем решение отслеживает изменение прав доступа, содержимого объектов, перемещение и т.д., проверяет на соответствие политикам и сигнализирует о нарушениях в средства мониторинга ИБ (SIEM, SOAR), а также может запускать внутренние сценарии для устранения нарушений», — пояснил Павел Еременко, владелец продукта Avanpost DAG.</p> <p>Архитектура Avanpost DAG разрушает стереотип о долгих и сложных DCAP-проектах. Вендор целенаправленно пошел по пути радикального упрощения развертывания и перехода к логике коробочного решения. Внедрение системы и ее первичная настройка работают по принципу «установил и запустил». На текущем этапе вывода продукта на рынок компания предлагает предельно доступное лицензирование, а также до конца года действует маркетинговая акция, обеспечивающая очень низкий порог входа. Для объективной оценки состояния хранилищ и проверки реальных матриц доступа Avanpost предлагает заказчикам развертывание пилотного проекта на действующей ИТ-инфраструктуре. </p> <p>Avanpost DAG может работать как самостоятельное решение, однако его возможности кратно усиливаются при интеграции с системами класса IDM. Двусторонняя связь позволяет платформе анализировать права с учетом бизнес-контекста: система видит не просто логин, а кадровый статус, роль и основания назначения прав конкретного человека. Это дает возможность гибко реагировать на изменения, автоматически инициируя пересмотр доступа к данным при увольнении сотрудника или его переходе на новую должность. </p> <p>Компания представила две версии продукта:</p> <ul> <li>первая ориентирована на крупнейшие национальные корпорации. Ключевое преимущество решения — стабильная и эффективная работа в условиях высокой нагрузки;</li> <li>вторая разработана для компаний среднего бизнеса. Её главная особенность — простая, а в ряде случаев нативная интеграция с различными хранилищами данных и поддержка работы с разными типами данных.</li> </ul> <p>Архитектура Avanpost DAG построена на общем технологическом ядре с флагманскими продуктами вендора, что гарантирует отказоустойчивость и масштабирование под высокие нагрузки крупных предприятий. Регулярный автоматизированный аудит помогает ИБ-подразделениям выявлять подозрительные отклонения на ранних стадиях, снижать поверхность атаки.</p> <p>Требования регуляторов распространяются не только на исходные системы, но и на копии данных в файлах. Avanpost DAG показывает, где фактически хранятся персональные данные, включая выгрузки и сканы, и кому они доступны, а журнал событий связывает обращение к данным с пользователем, временем и объектом. Это поддерживает выполнение требований <nobr>152-ФЗ,</nobr> приказов ФСТЭК России № 21 и № 239 к разграничению доступа и расследованию инцидентов. Система также применима для задач ГОСТ Р <nobr>57580.1-2017,</nobr> PCI DSS и защиты коммерческой тайны. </p> Компания Avanpost, разработчик решений для безопасности идентификационных данных и управления доступом, выпустила новый … message ИИТ расширяет возможности флагманского продукта TrustGate https://www.itweek.ru/themes/detail.php?ID=235884 Thu, 05 Nov 2026 12:48:33 +0300 <p>Интеграционное решение для взаимодействия с государственными информационными системами TrustGate компании ИИТ («Инфотекс Интернет Траст») получило ряд функциональных обновлений. Они направлены на ускорение и повышение уровня защищенности обмена данными, выполнение новых регуляторных требований и упрощение эксплуатации корпоративной ИТ-инфраструктуры.</p> <p>TrustGate обеспечивает взаимодействие организаций с государственными информационными системами, включая Единую систему идентификации и аутентификации (ЕСИА), Единую биометрическую систему (ЕБС) и Систему межведомственного электронного взаимодействия (СМЭВ). Является типовым решением для взаимодействия с ЕСИА и ЕБС. Благодаря чему один из приоритетов развития продукта — своевременная адаптация к изменениям законодательства. </p> <p>За последние месяцы ИИТ последовательно расширяла перечень поддерживаемых видов сведений. Среди последних изменений — поддержка взаимодействия банков с Социальным фондом России по вопросам внесудебного банкротства граждан, получения сведений о банковских счетах и операциях страхователей, а также обмена информацией с нотариусами для подтверждения выдачи денежных средств заемщикам. </p> <p>Кроме того, в TrustGate реализованы виды сведений, необходимые кредитным организациям для открытия социальных вкладов и счетов через портал «Госуслуги» в соответствии с требованиями Федерального закона № <nobr>202-ФЗ,</nobr> которые с 1 января 2027 года распространятся на все банки. Новые возможности позволяют организациям выполнять регуляторные требования в рамках существующей интеграционной инфраструктуры без доработки собственных информационных систем.</p> <p>Отдельное внимание ИИТ уделяет развитию платежных сценариев. В TrustGate появилась поддержка двух новых видов сведений для взаимодействия кредитных организаций с информационно-платежным шлюзом Единого портала госуслуг. Функциональность ориентирована на организации, заинтересованные в приеме платежей за государственные и коммерческие услуги через ЕПГУ.</p> <p>Кроме того, в продукте реализована поддержка всех видов сведений для интеграции с мобильным приложением «Госключ» через СМЭВ. Теперь организации могут направлять документы на подписание с использованием УНЭП или УКЭП физического лица, УКЭП должностного лица, УКЭП юридического лица или индивидуального предпринимателя без разработки собственных адаптеров.</p> <p>ИИТ также продолжает совершенствовать технологическую основу TrustGate. В продукте появилась поддержка узловых очередей СМЭВ, позволяющих гибко маршрутизировать ответы и статусные сообщения по исходящим запросам. Новый механизм дает возможность разграничивать потоки данных по ведомствам, видам сведений и отдельным узлам информационной системы. Организации могут использовать несколько экземпляров TrustGate с независимыми базами данных, распределяя нагрузку между шлюзами и исключая перегрузку общей очереди. Это особенно важно для компаний с распределенной ИТ-инфраструктурой и большим объемом межведомственного информационного обмена.</p> <p>Наконец, продукт ИИТ поддерживает новый механизм обмена с файловым хранилищем СМЭВ 3 по протоколу HTTP based S3. С 1 декабря 2026 года использование FTP для передачи файловых вложений через хранилище СМЭВ 3 будет прекращено. Пользователям TrustGate достаточно изменить настройки адресов файлового хранилища без дополнительных программных доработок.</p> <p>Параллельно ИИТ развивает возможности самостоятельного управления интеграциями. Организации, использующие TrustGate, могут подключать новые виды сведений СМЭВ 3 с помощью сервиса ProxyGate. Такой подход позволяет выполнять необходимые настройки силами заказчика в рамках уже развернутой инфраструктуры, не ожидая выпуска обновлений со стороны разработчика.</p> <p>«Мы отслеживаем изменения нормативной базы и развитие государственных цифровых сервисов, чтобы наши заказчики могли своевременно адаптироваться к новым требованиям. Одновременно мы совершенствуем и саму платформу — делаем ее более гибкой, масштабируемой и удобной в эксплуатации. Такой подход позволяет организациям решать новые интеграционные задачи на базе уже внедренного решения без дополнительных затрат на доработку собственных информационных систем и разработку отдельных механизмов взаимодействия с ГИС», — прокомментировал Александр Володин, владелец продукта TrustGate. </p> Интеграционное решение для взаимодействия с государственными информационными системами TrustGate компании ИИТ («Инфотекс … message Getmobit запустил Навигатор решений для построения индикативной архитектуры рабочих мест за минуты https://www.itweek.ru/themes/detail.php?ID=235883 Thu, 05 Nov 2026 12:47:18 +0300 <p>Технологическая компания Getmobit объявила о запуске Навигатора решений — открытой онлайн-платформы для предпроектной подготовки решений для рабочих мест — офисных, удалённых и гибридных — в существующей или проектируемой <nobr>VDI-инфраструктуре.</nobr> Навигатор переводит задачи бизнеса и контекст существующей ИТ-инфраструктуры, включая парк ПК, <nobr>VDI-системы</nobr> и ВКС, в готовую индикативную архитектуру. Он сокращает путь от формулировки потребности до первичного архитектурного решения до 1000 раз — с сотни часов технического анализа до нескольких минут.</p> <p>По итогам 2025 года российский рынок VDI вырос на 21%, к 2030 году он может достичь 10,7 млрд руб. При этом более 80% уже развёрнутых VDI по-прежнему работают на зарубежных платформах. Это создает потенциал миграции для сотен тысяч рабочих мест. Поэтому при выборе комплексного решения партнёрам и заказчикам важно учитывать не только функции новых продуктов, но и их совместимость с уже внедрёнными системами. Особенно сложной становится задача интеграции отечественных и зарубежных продуктов в рамках единой инфраструктуры.</p> <p>Традиционно такая предпроектная подготовка требует привлечения опытных системных архитекторов и значительных временных затрат. Навигатор берет на себя роль генератора индикативной архитектуры и снимает техническую боль — непредсказуемость интеграции зарубежного и отечественного ПО и «железа» друг с другом. В подбор попадают только сочетаемые между собой продукты Getmobit. Совместимость с <nobr>VDI-платформами,</nobr> ОС и оборудованием других производителей учитывается по матрице совместимости.</p> <p>Пользователь просто указывает задачу и параметры текущей инфраструктуры, получая на выходе карту компонентов, их роли, взаимосвязи и сценарии применения. Навигатор формирует архитектуру будущей системы, которая становится надежным фундаментом для дальнейшей технической и коммерческой проработки. Он ускоряет выход на стадию пилота (PoC) или расчета CAPEX/OPEX на <nobr>70–80%</nobr> за счет получения готовой рабочей спецификации в день обращения.</p> <p>Навигатор решений Getmobit предлагает более 10 актуальных бизнес-сценариев, которые охватывают ключевые задачи по модернизации цифровых рабочих мест. Сценарии постоянно пополняются и помогают подобрать архитектуру с учётом требований безопасности, особенностей существующей инфраструктуры, затрат на оборудование и необходимости обеспечить непрерывность бизнес-процессов. Среди наиболее востребованных:</p> <ol> <li>организация работы в открытом и закрытом сегментах сети с одного устройства для сокращения затрат на закупку и сопровождение двух физически независимых ПК при соблюдении требований безопасности;</li> <li>управление конечными устройствами и маршрутизация подключений при смене <nobr>VDI-платформы</nobr> для сохранения непрерывности бизнес-процессов при переходе на другую платформу виртуализации;</li> <li>организация универсального рабочего места с доступом к виртуальным приложениям и IP-видеотелефонии для объединения корпоративной связи и доступа к бизнес-системам в VDI на одном устройстве;</li> <li>оптимизация работы ВКС в среде виртуальных рабочих столов для снижения нагрузки на серверные мощности без потери качества видео и увеличения задержек во время онлайн-встреч;</li> <li>организация рабочих мест на базе тонких клиентов для обработки защищаемой информации для снижения рисков компрометации конечных устройств даже при централизации вычислений в дата-центре;</li> <li>получение единого окна доступа к виртуальным приложениям и рабочим столам для работы с локальными приложениями, виртуальными рабочими столами и терминальными сервисами без повторной авторизации;</li> <li>контроль геопозиционирования сотрудников и подрядчиков при доступе к информационным системам для ограничения инициации сессий авторизованными физическими площадками.</li> </ol> <p>В основе Навигатора — многолетняя интеграционная экспертиза Getmobit и опыт реализации проектов в разнородных ИТ-инфраструктурах. При формировании индикативной архитектуры инструмент учитывает существующий технологический стек заказчика и экосистему продуктов Getmobit.</p> <p>В зависимости от бизнес-задачи алгоритмы Навигатора подбирают оптимальную конфигурацию на базе продуктов компании, отвечающих за определённые функции в инфраструктуре цифровых рабочих мест:</p> <ul> <li>GM Smart System — платформа с единым центром управления GMSS NG Factory, который автоматизирует администрирование тысяч рабочих мест из одной точки, снижая нагрузку на техническую поддержку;</li> <li>GM-Box G1 RU — флагманская аппаратная платформа, объединяющая функции тонкого клиента и IP-телефона в едином эргономичном устройстве;</li> <li>GMSS NG Client — программное решение, дающее «вторую жизнь» legacy-оборудованию и превращающее совместимые ПК и сторонние тонкие клиенты в управляемые и безопасные конечные точки;</li> <li>BABYLxONE — универсальный интерфейс пользователя в формате супер-аппа, обеспечивающий бесшовный и безопасный доступ к виртуальным рабочим столам, приложениям и корпоративным сервисам независимо от того, где они развернуты;</li> <li>GM Virtual Media Optimizer — новое программное решение для оптимизации ВКС в VDI, которое переносит обработку аудио- и видеопотоков с серверов VDI на клиентское устройство, повышает качество связи и снижает нагрузку на серверы.</li> </ul> <p>«За годы внедрений мы накопили значительную интеграционную экспертизу и сформировали базу архитектурных сценариев, учитывающих специфику разнородных ИТ-инфраструктур. Постоянный диалог с заказчиками и партнёрами позволяет нам соотносить эту экспертизу с актуальными потребностями рынка и совершенствовать как технологические решения, так и модель взаимодействия на этапе подготовки проектов. Навигатор стал практическим воплощением этого подхода. Если раньше клиент тратил недели на подбор совместимых компонентов и расчет вариантов, то теперь он получает индикативную архитектуру цифровых рабочих мест мгновенно. Для бизнеса с парком от 1000 рабочих мест это означает ускорение старта проектов миграции на 80% и возможность сэкономить до 60% капитальных затрат за счет повторного использования существующего оборудования», — отметил Василий Шубин, директор департамента управления продуктовым портфелем Getmobit.</p> <p>Навигатор решений доступен на сайте Getmobit и может использоваться для подготовки проектов по развитию инфраструктуры удалённых рабочих мест.</p> Технологическая компания Getmobit объявила о запуске Навигатора решений — открытой онлайн-платформы для предпроектной … message Серый рынок доступа к зарубежным ИИ за 2026 год вырос с нуля до 14-21% от объема легального рынка https://www.itweek.ru/themes/detail.php?ID=235882 Thu, 05 Nov 2026 12:41:19 +0300 <p>В конце 2025 года сегмент ИП, продающих российскому бизнесу доступ к зарубежным ИИ-моделям через китайские прокси, практически отсутствовал. К августу 2026 года его оборот достиг <nobr>100-150</nobr> млн руб. в месяц. Это эквивалентно <nobr>14-21%</nobr> от объема легального рынка российских агрегаторов, который GPTunneL оценивает примерно в 700 млн руб. в месяц.</p> <p>В 2026 году в России сформировался новый сегмент посредников, которые предоставляют бизнесу доступ к зарубежным ИИ-моделям через китайские прокси и другие неофициальные схемы. Если в конце 2025 года таких продавцов были единицы, то к августу 2026 года их число, по оценке ИИ-платформы GPTunneL, достигло примерно 50. Совокупный оборот сегмента оценивается в <nobr>100-150</nobr> млн руб. в месяц.</p> <p>Для сравнения, объем легального рынка российских агрегаторов корпоративного доступа к зарубежным ИИ-моделям GPTunneL оценивает примерно в 700 млн руб. в месяц. Таким образом, серый сегмент уже эквивалентен примерно <nobr>14-21%</nobr> от объема легального рынка.</p> <p>Под легальными агрегаторами GPTunneL понимает российские юридические лица, которые получают доступ к зарубежным ИИ-моделям через собственные иностранные компании или партнерскую инфраструктуру, а затем предоставляют его российскому бизнесу от своего имени с уплатой необходимых налогов.</p> <p>ИП с прокси работают по другой модели. Они могут покупать у китайских посредников доступ к сервисам, которые позиционируются как Claude или GPT, но фактически работают через цепочки прокси, бесплатные лимиты других моделей, в том числе Kimi, либо через многократное использование официальных подписок OpenAI, Google и других разработчиков. Затем такой доступ перепродается российским компаниям с оплатой в рублях на счет ИП.</p> <p>Одной из причин распространения таких схем стала цена. Стоимость доступа для российского бизнеса может быть близкой к прямым тарифам Anthropic, OpenAI и Google, а в отдельных случаях даже ниже. При этом конечный пользователь не всегда может определить, через какую модель и инфраструктуру фактически проходит его запрос.</p> <p>Более низкая цена сопровождается дополнительными рисками. По данным GPTunneL, качество такого доступа может быть нестабильным, сервисы иногда надолго перестают работать, а запросы пользователей могут проходить через три-четыре посредника. Это повышает риски утечки корпоративной информации. В отдельных случаях, по оценке компании, передаваемые данные также могут использоваться для обучения китайских моделей.</p> <p>Для конечного покупателя возможны и налоговые риски. В случаях, когда посредник сам не уплачивает ввозной НДС, обязанность по его уплате может возникнуть у российского покупателя. Наличие у покупателя льгот по НДС, включая статус резидента «Сколково», этот риск автоматически не снимает.</p> <p>К концу 2026 года GPTunneL ожидает примерно двукратного роста текущих объемов. При сохранении этой динамики легальный рынок агрегаторов может увеличиться примерно до 1,4 млрд руб. в месяц, а оборот ИП с китайскими прокси — до <nobr>200-300</nobr> млн руб. в месяц.</p> В конце 2025 года сегмент ИП, продающих российскому бизнесу доступ к зарубежным ИИ-моделям через китайские прокси … message Малые языковые модели обещают экономию. Но что происходит на практике? https://www.itweek.ru/themes/detail.php?ID=235881 Thu, 05 Nov 2026 10:36:30 +0300 <p><em>Хотя малые языковые модели (SLM) преподносятся как простое решение проблем, связанных со стоимостью и сложностью внедрения искусственного интеллекта, использующие их в реальных рабочих процессах CIO обнаруживают, что за этой экономией скрываются определенные нюансы, отмечают опрошенные порталом </em><em>InformationWeek</em> <em>эксперты.</em></p> <p>Аргументы в пользу SLM стали практически стандартным ответом. ИИ обходится слишком дорого, работает медленно или сопряжен с высокими рисками? Попробуйте модель поменьше.</p> <p>В прошлом году аналитики Gartner <a href="https://www.gartner.com/en/newsroom/press-releases/2025-04-09-gartner-predicts-by-2027-organizations-will-use-small-task-specific-ai-models-three-times-more-than-general-purpose-large-language-models">спрогнозировали</a>, что в 2027 г. организации будут использовать специализированные модели, предназначенные для решения конкретных задач, в три раза чаще, чем универсальные большие языковые модели (LLM). Этот сдвиг уже отражается в корпоративных бюджетах: в июле Gartner сообщила, что расходы на специализированные ИИ-модели, ориентированные на конкретные предметные области, только в <nobr>2026-м</nobr> вырастут на 210% — это более чем вдвое превышает темпы роста затрат на фундаментальные модели.</p> <p>Однако CIO, которые уже внедрили — или только пытаются внедрить — SLM в рабочие процессы, описывают гораздо более сложную картину. SLM действительно могут повысить эффективность, но зачастую не в той мере, в какой ожидалось, а сопутствующие расходы становятся заметны лишь после запуска системы в эксплуатацию.</p> <h3>Когда расчет действительно оправдывается</h3> <p>«Внедрение SLM в корпоративном секторе перешло от стадии пилотных проектов к полноценной архитектуре, и этот процесс набирает обороты», — отмечает Амит Убхаякер, директор по аналитике данных и ИИ компании Protiviti. По его словам, речь не идет о полной замене больших моделей; скорее, формируется многоуровневая архитектура: малые модели используются для маршрутизации, классификации и формирования структурированных ответов, тогда как передовые модели задействуются для решения неоднозначных, многоэтапных задач.</p> <p>Джейсон Джеймс, будучи CIO в поставщике технологических решений для ритейла Aptos, тестировал три-четыре специализированные модели на локальном оборудовании, а не в облаке. Целью было выяснить, оправданы ли затраты и усилия по поддержке таких моделей онпремис по сравнению с расходами на оплату токенов при использовании передовых моделей.</p> <p>«По сути, это чистая математика, — говорит Джеймс. — Каковы затраты на внедрение? Каковы расходы на эксплуатацию? Каков объем использования? Если при локальном запуске все эти показатели будут существенно ниже — тогда стоит рассматривать такой вариант. А если экономия незначительна, то зачем вообще что-то менять?».</p> <p>Хотя он недавно покинул Aptos, чтобы занять должность CIO в Acumatica, показатели тестирования свидетельствовали в пользу SLM — настолько, что в Aptos решили продолжить их пилотное внедрение. При этом, как отмечает Джеймс, такие модели не заменяют передовые инструменты, которые уже использовали команды в Aptos. Напротив, они расширяют выбор, позволяя избежать того, что он называет «банкротством по токенам» — ситуации, когда из-за неправильного подбора модели и некорректных промптов недостаточно подготовленные пользователи расходуют годовой бюджет на токены всего за несколько недель.</p> <p>По словам Убхаякера, SLM лучше всего проявляют себя в узких, повторяемых и поддающихся проверке задачах — например, при классификации, маршрутизации или извлечении структурированных данных, — особенно в тех случаях, когда существуют строгие требования к границам данных или нормативному соответствию. «Это не означает, что SLM вытесняют передовые модели, — говорит он. — Речь идет о создании многоуровневой архитектуры, а не о полной замене одних решений другими».</p> <h3>Когда данные разрушают бизнес-кейс</h3> <p>Именно с этой проблемой на собственном опыте столкнулся Эрик Пейс, который недавно ушел с руководящей должности в сфере корпоративных ИТ и теперь консультирует компании по вопросам внедрения ИИ. Его команда внедрила для подготовки маркетинговых сообщений небольшой дообученный вариант модели Llama, которая обучалась на исторических данных, размеченных как «хорошие» или «плохие». Результаты тестирования выглядели многообещающе, а путь к промышленной эксплуатации оказался неожиданно быстрым и недорогим. Однако выяснилось, что данные, которые казались надежными на этапе тестирования, не выдержали проверки в реальных масштабах эксплуатации.</p> <p>«В итоге нам пришлось отказаться от этого решения», — говорит Пейс, добавляя, что по-прежнему считает SLM эффективным инструментом для экономии времени, а вопросы дрейфа модели и управления версиями вполне решаемы в рамках разумного бюджета. Тем не менее, теперь он рассматривает качество данных как гораздо более критичный фактор для дообученных SLM, чем для ИИ-решений общего назначения.</p> <p>«Мало того, что наборы данных должны точно соответствовать тому, что вы хотите видеть на входе в модель, — нужно еще найти правильный баланс, — отмечает Пейс. — Возможность перестараться с обучением вполне реальна». Его совет: ставьте перед моделью четкие, ограниченные задачи, предусматривайте возможность ретроспективного тестирования и не недооценивайте объем знаний о бизнес-процессах и ответственности за данные, которые потребуются от сотрудников за пределами ИТ-отдела.</p> <p>Убхаякер уже сталкивался с подобными ситуациями, когда компании оценивали SLM, опираясь на общедоступные бенчмарки, а не на реальные данные и потоки запросов, с которыми им предстояло работать в производственной среде. «Организациям следует ориентироваться на стоимость выполнения одной успешной задачи, а не просто на стоимость одного токена, — отмечает он. — Модель меньшего размера может казаться более дешевой, однако необходимость повторных запусков, проверки результатов человеком или передачи задачи более мощным моделям может быстро свести на нет всю экономию».</p> <h3>Кто отвечает за совокупность моделей</h3> <p>Даже если каждая из SLM работает эффективно, их использование в составе целого комплекса создает дополнительные издержки. Джеймс объясняет это на практике: если рабочий процесс проходит через несколько специализированных моделей, выявить причину сбоя становится сложнее — ведь для устранения неполадки приходится взаимодействовать с владельцами каждой из моделей, чтобы понять, где именно возникла проблема и кто за нее отвечает.</p> <p>По словам Убхаякера, каждая специализированная модель требует индивидуальной оценки и мониторинга для выявления дрейфа поведения. Использование целого ряда таких моделей усложняет процессы маршрутизации запросов, обновления систем и отслеживания происхождения. Обновление или последующая донастройка базовой модели требуют повторного обучения и тестирования. Однако, как отмечает эксперт, еще более серьезный риск — это «разрыв между уверенностью руководства и реальным положением дел». Руководство часто полагает, что политики мониторинга соблюдаются, тогда как телеметрия показывает обратное — особенно когда команды внедряют специализированные модели быстрее, чем организация успевает их каталогизировать и взять под контроль.</p> <h3>Отказ от бинарного подхода</h3> <p>Все это вовсе не означает, что SLM — заведомо неудачный выбор. Просто они требуют гораздо более тщательной предварительной проработки, чем многие ожидают. Стоимость самой модели — это еще не полные затраты. Джеймс подчеркивает: прежде чем подсчитывать потенциальную экономию, необходимо заложить в бюджет расходы на управление, администрирование и обучение.</p> <p>Убхаякер считает, что решение о том, использовать ли малую или большую языковую модель для конкретной задачи, должно приниматься индивидуально для каждого случая. При выборе следует учитывать, является ли задача четко ограниченной и поддающейся проверке; обладает ли организация техническими ресурсами для поддержки модели; и способна ли малая модель действительно обеспечить требуемую точность. Ориентироваться исключительно на то, какая архитектура выглядит дешевле «на бумаге», — неверный подход. Ценность SLM относительна: она зависит от характера задачи, используемых данных и того, кто несет ответственность за модель после ее ввода в эксплуатацию.</p> Хотя малые языковые модели (SLM) преподносятся как простое решение проблем, связанных со стоимостью и сложностью … article Какие новые риски для кибербезопасности появились с развитием ИИ в 2026 году https://www.itweek.ru/themes/detail.php?ID=235879 Thu, 05 Nov 2026 09:53:40 +0300 <p>Почти каждую неделю разработчики нейросетей добавляют новые функции ИИ-моделям, которые активно используются для разработки приложений, автоматизации процессов и работы с корпоративными данными.</p> <p>Вместе с новыми возможностями появляются и новые риски для безопасности: кибератаки становятся быстрее, ИИ-агенты получают доступ к критическим системам, а сотрудники самостоятельно создают приложения без глубоких технических знаний. Разберем, какие угрозы возникают и как компаниям к ним подготовиться.</p> <h3>ИИ резко ускоряет кибератаки</h3> <p>Нейросети позволяют злоумышленникам быстрее искать уязвимости, анализировать данные и готовить атаки. Задачи, которые раньше требовали длительной ручной работы, теперь можно частично автоматизировать.</p> <p>Особенно заметно ИИ ускоряет повторяющиеся действия. В <a href="https://www.anthropic.com/threat-intelligence-report-september-2026">отчетах Anthropic</a> описаны случаи, когда злоумышленники использовали модели для поиска учётных данных, анализа результатов атак и изменения вредоносного кода после срабатывания защиты. В некоторых расследованных атаках взлом занимал всего два-три часа, а в одной из кампаний в планировании и атаках фигурировало более 20 организаций. Сократился сам цикл атаки: «Разведка → Проверка → Изменение подхода → Повторная попытка». С помощью ИИ отдельные шаги этого цикла могут занимать минуты или даже секунды, а значит, у защитных систем становится меньше времени на выявление угрозы и перестройку защиты.</p> <p>Скорость стала дополнительным фактором киберриска. Можно сказать примерно так:</p> <p>«Киберриск = Вероятность × Последствия × Скорость».</p> <p>Это условная модель, а не строгая формула: она помогает показать, что ущерб зависит не только от вероятности и масштаба события, но и от того, насколько быстро компания его обнаружит и остановит.</p> <p>Например, <em>последствия</em> компрометации учетной записи могут существенно различаться в зависимости от <em>скорости</em>: обнаружит компания проблему через час или через сутки. Чем быстрее развивается атака, тем меньше времени остаётся на ее остановку.</p> <p>Скорость, в свою очередь, повышает требования к работе центров мониторинга безопасности (SOC). Когда злоумышленники могут за секунды менять способы атаки, ручной анализ и реагирование рискуют оказаться слишком медленными. ИИ может помочь SOC быстрее анализировать журналы событий и находить связи между ними.</p> <h3>Агенты получают слишком широкие полномочия</h3> <p>ИИ-помощники становятся новыми участниками корпоративной инфраструктуры наряду с сотрудниками. Они могут самостоятельно работать с репозиториями, базами данных, облачными сервисами и API. При этом последствия их действий зависят от предоставленных полномочий.</p> <p>Показательный <a href="https://www.tomshardware.com/tech-industry/artificial-intelligence/claude-powered-ai-coding-agent-deletes-entire-company-database-in-9-seconds-backups-zapped-after-cursor-tool-powered-by-anthropics-claude-goes-rogue">случай</a> произошёл в апреле 2026 года с компанией PocketOS, которая разрабатывает ПО для проката автомобилей. ИИ-агент столкнулся с проблемой доступа и самостоятельно нашёл в файлах проекта токен с широкими полномочиями. Затем агент удалил том с рабочей базой данных и связанными рабочими копиями. Операция заняла всего девять секунд. К счастью, при участии инфраструктурного провайдера удалось восстановить данные.</p> <p>Права ИИ-агентов необходимо ограничивать технически и предоставлять минимальные полномочия, необходимые для выполнения конкретных и заранее выбранных задач. Ещё очень желательно разделять доступ к тестовой и рабочей средам, требовать подтверждения критических операций и обязательно хранить независимые резервные копии.</p> <h3>ИИ может выходить за пределы тестовой среды</h3> <p>Эксперименты с агентами могут затронуть реальные рабочие системы, если тестовая среда для ИИ недостаточно изолирована. Например, агенту поручают проверить безопасность приложения и сообщают, что он работает в песочнице (закрытой системе). Но если у нейросети есть доступ к интернету, действующим ключам или рабочим системам, ИИ может проникнуть в продакшен-контур, которым пользуются клиенты и сотрудники.</p> <p>Подобные случаи<a href="https://www.anthropic.com/research/investigating-incidents-cybersecurity-evals"> описала Anthropic</a> во время тестирования модели Claude Mythos 5. Модель получила задание взломать вымышленную компанию. Это было испытание: может ли агент проникнуть в систему и найти скрытую информацию?</p> <p>Для взлома вымышленной компании агент придумал ловушку: создал вредоносную программу и разместил её в интернете под названием, которое использовалось во внутренних инструкциях компании. Он рассчитывал, что сотрудники или системы компании установят её, открыв доступ к своим данным.</p> <p>Модель в ходе рассуждений отмечала, что публикация такого пакета в реальном интернете была бы настоящей атакой. Но затем она сделала вывод, что всё происходит в симуляции, и продолжила выполнение задания. Проблема оказалась в том, что доступ к настоящему интернету у агента всё-таки был, и в результате созданный ИИ вредоносный код установили реальные сторонние системы и были похищены учётные данные одной из организаций.</p> <p>Чтобы агенты ничего не ломали в реальных системах, тестовые среды надо тщательно изолировать. Для этого стоит использовать отдельные сети и учётные записи, ограничивать исходящий трафик и разрешать подключения только к проверенным адресам. Конечно, за действиями агентов тоже нужно следить и предусмотреть возможность быстро остановить их работу.</p> <h3>Вайбкодинг создает новые уязвимости внутри компаний</h3> <p>Программирование с нейросетью дало сотрудникам возможность самим создавать приложения, даже если у них нет опыта разработки. При этом человек может не понимать, как устроен сгенерированный код и что он делает. В результате в корпоративной инфраструктуре появляются инструменты, безопасность которых никто полноценно не проверял.</p> <p>Такие приложения могут содержать уязвимости, передавать конфиденциальные данные внешним сервисам и получать избыточные права доступа. С поддержкой таких программ тоже возникают проблемы: сотрудник создал приложение, но со временем становится непонятно, кто отвечает за его безопасность и как его чинить при поломках.</p> <p>Для снижения этих рисков нужно вводить отдельные правила безопасности вайбкодинга. Например, назначать ответственного за каждое приложение, ограничивать доступ к корпоративным данным и проверять сгенерированный код перед запуском.</p> <h3>ИИ помогает находить сложные цепочки уязвимостей</h3> <p>Отдельную опасность представляют цепочки уязвимостей, которые позволяют злоумышленникам последовательно проникать в разные корпоративные системы. Например, ошибка в публичном сервисе может открыть доступ к системе авторизации, а через неё — к внутренним репозиториям. ИИ помогает быстрее обнаруживать и проверять такие взаимосвязи.</p> <p>Пример <a href="https://www.hacktron.ai/blog/hacking-openai">описала компания Hacktron</a>, которая занимается исследованиями кибербезопасности и разрабатывает ИИ-агентов для поиска и эксплуатации уязвимостей. В июле 2026 года её исследователи с помощью Claude обнаружили и использовали две уязвимости: в обработке изображений на публичном форуме OpenAI и в корпоративной системе единого входа (SSO). Через форум они получили доступ к учётным записям сотрудников OpenAI, а затем с помощью Codex смогли создать тестовый запрос на изменение кода во внутреннем репозитории компании. Вся цепочка заняла около 72 часов. Исследователи сообщили об уязвимостях, а OpenAI выплатила им вознаграждение в размере 6500 долл.</p> <p>Для защиты от подобных атак компаниям необходимо учитывать связи между системами, а не только отдельные уязвимости. Вот несколько способов: отслеживать зависимости программных компонентов с помощью SBOM (спецификации состава ПО), проверять связи между публичными сервисами и критической инфраструктурой, изолировать обработку пользовательских файлов. Чем меньше барьеров между системами, тем выше риск распространения атаки.</p> <h3>ИИ помогает находить уязвимости в популярном ПО</h3> <p>Ещё один пример — уязвимости PHP2Shell.</p> <p>В октябре 2026 года разработчики PHP выпустили исправления для двух критических ошибок: CVE-2026-109618 и CVE-2026-109619. Их объединили под названием PHP2Shell. Обе связаны с обработкой памяти в самом PHP и в некоторых случаях позволяют выполнить код на сервере без пароля или других учётных данных.</p> <p>Нашли уязвимости с помощью больших языковых моделей. Исследователи компании Calif сообщили о проблеме в августе 2026 года, независимо её подтвердили в OpenAI, а затем к анализу подключилась Wiz. В работе использовались генеративные модели, в том числе OpenAI. Исследователи направляли работу, проверяли результаты и готовили отчёт. Но ИИ заметно ускорил поиск сложной ошибки в коде, которая оставалась незамеченной много лет.</p> <p>После выхода исправлений 21 октября интерес к уязвимостям резко вырос: разработчики опубликовали обновления, но миллионы сайтов и серверов ещё продолжали работать на старых версиях PHP. Чтобы защититься, владельцам нужно обновить ПО.</p> <p>Уже на следующий день, по заявлению Cloudflare, число попыток взломов и использования уязвимостей достигло миллионов. 26 октября CISA добавила обе уязвимости в каталог активно используемых.</p> <p>Исследователи также увидели успешное выполнение команд на honeypot — специально созданных серверах-ловушках с уязвимыми версиями PHP. Их оставляют доступными, чтобы наблюдать за действиями злоумышленников. В одном из наблюдений за короткое время три таких тестовых PHP-сервера 35 раз использовались через уязвимости PHP2Shell.</p> <p>На момент публикации не было подтверждено, что злоумышленники сами использовали ИИ для атак. ИИ помог исследователям найти и проверить уязвимость, а затем информация о ней стала доступна всем, в том числе и злоумышленникам.</p> <p>Этот случай показывает новую особенность: ИИ ускоряет не только атаки, но и поиск уязвимостей. Для защитников это возможность раньше находить и закрывать проблемы. Но если компания долго не обновляет популярные компоненты, те же возможности получают и злоумышленники.</p> <h3>Что делать сейчас</h3> <p>Компаниям стоит уже сейчас решить, для каких задач можно использовать ИИ и к каким системам и данным его можно подключать. Для каждого такого случая нужно определить ответственного и заранее установить границы: что инструменту разрешено делать самому, а где он должен запросить подтверждение.</p> <p>Доступы лучше выдавать только необходимые для конкретной задачи. Тестовую среду нужно отделять от рабочей, а важные действия (например, удаление данных или изменение кода) проводить с подтверждением сотрудника. Действия инструмента важно записывать, чтобы при ошибке можно было понять, что произошло, и быстро остановить дальнейшую работу.</p> <p>Приложения, созданные с помощью ИИ, тоже нужно проверять ещё до запуска. У каждого такого приложения должен быть человек, который отвечает за его работу и безопасность. Чем важнее приложение и чем больше данных оно использует, тем тщательнее должна быть проверка кода, доступов и сторонних компонентов.</p> <p>Правила стоит периодически пересматривать: появляются новые инструменты, а вместе с ними — новые способы подключить их к корпоративным системам. Если заранее установить понятные ограничения и порядок проверки, компания сможет пользоваться ИИ и при этом лучше контролировать риски.</p> <p>#IMAGE_235880#</p> Почти каждую неделю разработчики нейросетей добавляют новые функции ИИ-моделям, которые активно используются для разработки … article Роман Стрельников, руководитель направления информационной безопасности “1С-Битрикс” Forrester: как изменятся требования к ИТ-инфраструктуре в 2027 году https://www.itweek.ru/themes/detail.php?ID=235875 Tue, 03 Nov 2026 10:17:57 +0300 <p><em>2027 год станет проверкой реальности инфраструктурных стратегий: искусственный интеллект переходит в категорию критически важного производства, геополитическая неопределенность подвергает испытаниям глобальные операции, а организации выводят на передний план все больше приложений и интеллектуальных технологий, пишут в корпоративном блоге вице-президенты, главные аналитики </em><em>Forrester</em> <em>Микеле Пелино и Карлос Казанова.</em></p> <p>Для руководителей в области инфраструктуры и операций (I&O) это означает переосмысление того, как они создают инфраструктуру ИИ, повышают устойчивость и инвестируют в периферию. Forrester выделяет следующие три прогноза относительно I&O:</p> <ul> <li><strong> В четверти запросов предложений (</strong><strong>RFP</strong><strong>) на инфраструктуру ИИ будут содержаться требования вариантов ускорителей, отличных от поставляемых NVIDIA.</strong> Они останутся платформой по умолчанию для обучения передовых моделей и крупномасштабного инференса, но предприятия будут все чаще искать альтернативные ИИ-ускорители для сокращения затрат и снижения рисков в цепочке поставок и геополитических рисков и обеспечения суверенитета. Вместо замены решений NVIDIA организации будут сегментировать рабочие нагрузки по типам ускорителей в зависимости от конкретных требований. Гиперскейлеры уже расширяют возможности инфраструктуры ИИ с помощью собственных микросхем, таких как AWS Trainium, Google Ironwood TPU и Microsoft Maia. Руководители в области инфраструктуры должны включать разнородные требования к инфраструктуре ИИ в свои планы закупок и развития архитектуры.</li> <li><strong> Тридцать процентов крупных предприятий создадут частную инфраструктуру ИИ для инференса. </strong>В условиях перехода агентного ИИ в производство предприятиям потребуется выделенная инфраструктура ИИ для чувствительных, критичных к задержке и объемных рабочих нагрузок вывода. Рост стоимости токенов и более сложные агентные рабочие процессы будут еще больше стимулировать спрос на инфраструктуру, оптимизированную для экономики ИИ-инференса. Руководителям следует уже сейчас заняться разработкой корпоративной стратегии инференса, которая отделяет производственный инференс от обучения и приводит инфраструктуру в соответствие с потребностями рабочей нагрузки.</li> <li><strong> Инвестиции в инфраструктуру сместятся на 20% в сторону отраслевой периферии.</strong> Организации в таких отраслях, как промышленное производство, здравоохранение и розничная торговля, будут все чаще использовать рабочие нагрузки ИИ и аналитику на периферии, ближе к местам, где необходимо принимать решения. Малые языковые модели, модели ИИ для конкретной предметной области, робототехника и визуально-языковые системы действий будут перенесены на операционные технологические устройства для решения проблем с задержкой, отказоустойчивостью и подключением на таких объектах, как заводы, больницы, корабли и нефтяные вышки. Лица, принимающие решения в области инфраструктуры, должны разработать отраслевую вычислительную стратегию и инвестировать в меньшие форм-факторы и возможности, которые могут повысить эффективность рабочих нагрузок и одновременно приблизить ИИ к месту действия.</li> </ul> <p>ИИ станет просто еще одной частью I&O. Для этого потребуется более распределенная, специализированная и адаптируемая инфраструктура. Технологические руководители должны определить, где выполняются рабочие нагрузки, какие технологии их поддерживают и как обеспечить устойчивость инфраструктуры по мере изменения деловых и геополитических условий.</p> 2027 год станет проверкой реальности инфраструктурных стратегий: искусственный интеллект переходит в категорию критически … article Доменные войны: как защитить свой бренд в эпоху кириллицы https://www.itweek.ru/themes/detail.php?ID=235873 Tue, 03 Nov 2026 10:10:31 +0300 <p><em>Появление кириллических доменов расширило возможности для брендинга, но одновременно создало новое поле для конфликтов. Киберсквоттинг — регистрация чужого товарного знака в качестве доменного имени с целью перепродажи или недобросовестной конкуренции — переместился в кириллическую зону. Компании, которые не защитили свои бренды заранее, рискуют столкнуться с тем, что их название уже занято. </em><em>Разберем</em><em> нюанс</em><em>ы</em><em> современных доменных споров.</em></p> <h3>Разные зоны — разные правила</h3> <p>В России действуют несколько кириллических доменных зон, и механизмы разрешения споров в них различаются. Это важно понимать при выборе стратегии защиты бренда.</p> <p>Домены .ru и .рф находятся под юрисдикцией российского законодательства. Споры о них рассматриваются в российских арбитражных судах, а кассационной инстанцией по делам о товарных знаках выступает Суд по интеллектуальным правам. Процедура судебная, длительная, требует сбора доказательств и юридического сопровождения.</p> <p>Домены .рус, .москва, .дети и другие новые gTLD (generic top-level domains) существуют на основании договора с ICANN — международной организацией, координирующей систему доменных имен. К ним применяются международные процедуры разрешения споров: UDRP (Uniform Domain-Name Dispute-Resolution Policy) и URS (Uniform Rapid Suspension). Эти процедуры быстрее и дешевле суда, но требуют соблюдения строгих формальных критериев.</p> <p>UDRP позволяет правообладателю подать жалобу в один из аккредитованных арбитражных центров — чаще всего в Центр ВОИС по арбитражу и посредничеству. Если будет доказано, что домен идентичен или сходен до степени смешения с товарным знаком, зарегистрирован и используется недобросовестно, панель может передать домен правообладателю или аннулировать регистрацию. От подачи жалобы до решения обычно проходит около двух месяцев.</p> <p>URS — ускоренная процедура для очевидных случаев. Если нарушение явное, домен блокируется в течение нескольких недель. Но URS не передает домен — она только приостанавливает его работу на оставшийся срок регистрации.</p> <p>Ключевое различие между двумя механизмами не в скорости, а в результате. Панель UDRP может распорядиться передать домен. Российский суд домен не передает: он запрещает ответчику использовать обозначение, после чего имя освобождается и правообладатель регистрирует его в общем порядке.</p> <h3>Статистика: споров много, и их число держится на рекордном уровне</h3> <p>По данным Центра ВОИС, в 2025 году организация рассмотрела 6282 доменных спора — это наибольшее число за всю историю процедуры, которой в том же году исполнилось 25 лет. Показатели последних лет держатся примерно на одном уровне: 6192 дела в 2023 году и 6168 в <nobr>2024-м.</nobr></p> <p>Исходы, по данным ВОИС за 2025 год: около 5% жалоб отклонены, 15% дел урегулированы сторонами до вынесения решения, остальные завершились передачей домена правообладателю или аннулированием регистрации. Иными словами, при наличии зарегистрированного товарного знака и доказательств недобросовестности шансы вернуть домен высоки.</p> <h3>Кейс первый: кириллические домены в российском суде</h3> <p>В 2024 году ООО «Интернет решения», правообладатель более 60 товарных знаков с элементом "Ozon"/"Озон«, в ходе мониторинга интернета обнаружило, что предприниматель Дмитрий Гончарук зарегистрировал и администрирует домены озон.рф, озончик.рф, озоны.рф и озо.рф.</p> <p>Компания обратилась в Арбитражный суд города Москвы. Суд установил, что спорные доменные имена тождественны либо в высокой степени сходны с товарными знаками истца, в том числе с общеизвестным знаком, и 13 января 2025 года иск был удовлетворен частично: предпринимателю запрещено использовать обозначения «Озон», «Озончик», «Озоны» и «Озо» в доменных именах.</p> <p>Ответчик возражал, что использует не товарные знаки, а общеупотребительное слово «озон» и производные от него, и что сам правообладатель не воспользовался приоритетным правом на регистрацию в зоне .рф, то есть отказался от имени. Эти доводы не были приняты.</p> <p>Дальнейшая хронология показательна: апелляция оставила решение без изменения 31 марта 2025 года, Суд по интеллектуальным правам — 28 июля 2025 года, Верховный Суд отказал в передаче жалобы в коллегию 9 октября 2025 года, затем последовали заявление о пересмотре по новым обстоятельствам и отказ в нем 8 июля 2026 года, оставленный в силе 24 сентября 2026 года.</p> <p>Дело № А40-149116/2024 длилось более двух лет и прошло пять судебных инстанций.</p> <p>Из этого кейса следуют три практических вывода. Мониторинг работает: нарушение было выявлено именно так. Общеупотребительность слова сама по себе не защищает того, кто зарегистрировал домен. И отсутствие приоритетной регистрации не означает отказа правообладателя от своих прав.</p> <h3>Кейс второй: кириллический домен и процедура UDRP</h3> <p>Если домен находится в зоне, работающей по договору с ICANN, спор решается иначе.</p> <p>В 2011 году компания Dr. Ing. h.c. F. Porsche AG обратилась в Центр ВОИС по поводу домена порше.com (в технической записи — xn—e1arcf4b.com), зарегистрированного в 2006 году. Домен вел на страницу с рекламными ссылками, среди которых были предложения конкурентов.</p> <p>Отдельный интерес представляет то, что у Porsche не было товарного знака в кириллице — только знаки латиницей, охраняемые в том числе в России. Панель все равно признала сходство до степени смешения: домен является точной транслитерацией широко известной марки, и пользователь, увидев такое имя, с высокой вероятностью свяжет его с правообладателем.</p> <p>Ответчик на жалобу не ответил, но написал в Центр, что зарегистрировал имя в составе массовой закупки, допускал возможность конфликта с товарным знаком и готов передать домен. Панель расценила это как подтверждение отсутствия законного интереса, а использование припаркованной страницы с рекламой конкурентов — как недобросовестность. 8 апреля 2011 года домен был передан правообладателю (дело № D2011-0100).</p> <p>Для российских компаний здесь два важных вывода. Кириллическое имя и его техническая запись в punycode рассматриваются как одно и то же. И отсутствие кириллического товарного знака не закрывает дорогу к защите, если бренд достаточно известен.</p> <h3>Похожие буквы: как работает тайпсквоттинг</h3> <p>Отдельная категория нарушений — регистрация доменов, визуально почти неотличимых от оригинала.</p> <p>В зоне .рф такой прием невозможен: правила регистрации допускают только буквы кириллицы, цифры и дефис, смешивать алфавиты в одном имени нельзя. Зато он широко применяется в международных зонах.</p> <p>Показательны два дела Центра ВОИС. В 2013 году Siemens AG добилась передачи домена sıemens.com, где вместо латинской «i» использована турецкая «ı» без точки (дело № D2013-1318). В 2014 году то же самое сделала Twitter с доменом twıtter.com (дело № D2014-0469). На экране такие адреса выглядят почти как настоящие, но технически это совершенно другие домены, и используются они для перехвата трафика и фишинга.</p> <h3>Превентивная защита: что может сделать бизнес</h3> <p>Лучшая защита от доменных споров — меры, принятые заранее.</p> <ol> <li><strong>Зарегистрируйте товарный знак</strong>. Это ключевое условие для успеха в любом споре — и в суде, и по процедуре UDRP. Без товарного знака доказать права на имя значительно сложнее. Регистрация в Роспатенте занимает несколько месяцев.</li> <li><strong>Займите доменные имена, совпадающие с вашим брендом, в тех зонах, где вы реально работаете или планируете работать</strong>. Речь не о скупке адресов во всех зонах подряд: это дорого и не нужно. Речь о том, чтобы имя, совпадающее с вашим товарным знаком, не досталось третьим лицам там, где ваша аудитория будет его искать.</li> <li><strong>Настройте мониторинг новых регистраций</strong>. Существуют сервисы, отслеживающие появление доменов, похожих на ваш бренд. Как показывает дело «Интернет решений», именно мониторинг обычно и обнаруживает нарушение. Чем раньше оно найдено, тем проще его остановить.</li> <li><strong>Проверьте распространенные ошибки в написании бренда</strong> — в том числе варианты с похожими буквами из других алфавитов. Если у бренда есть неоднозначная транслитерация, стоит понимать, какие варианты уязвимы.</li> <li><strong>Оформляйте домены на юридическое лицо</strong>. Регистрация на сотрудника создает риски при его уходе и усложняет доказывание прав в споре.</li> <li><strong>Помните о кириллических вариантах названия, даже если основной сайт работает на латинском домене</strong>. В чужих руках такое имя может использоваться для фишинга или дискредитации бренда.</li> </ol> <h3>Что делать, если домен уже занят</h3> <ul> <li><strong>Переговоры</strong>. Иногда домен зарегистрирован по незнанию или для законных целей. Можно связаться с владельцем и обсудить выкуп. Но если владелец поймет, что вы готовы платить любую сумму, цена вырастет.</li> <li><strong>Процедура UDRP</strong> — для доменов в зонах, работающих по договору с ICANN, в том числе .рус, .москва, .дети. Жалоба подается в аккредитованный арбитражный центр. Доказывать нужно три обстоятельства: домен идентичен или сходен до степени смешения с вашим товарным знаком; у владельца домена нет прав и законных интересов в отношении имени; домен зарегистрирован и используется недобросовестно.</li> <li><strong>Суд — для .ru и .рф</strong>. Подается иск о нарушении прав на товарный знак с приложением свидетельства, доказательств использования бренда и фиксации нарушения. Суд запрещает ответчику использовать обозначение в доменном имени; после освобождения имени правообладатель регистрирует его в порядке, предусмотренном правилами регистрации.</li> <li><strong>Обращение к регистратору</strong>. Если домен используется для фишинга или распространения вредоносного ПО, регистраторы обычно реагируют быстро при наличии доказательств.</li> </ul> <p>По словам экспертов, основная ошибка компаний — откладывать регистрацию доменов на потом. Рассуждение звучит так: мы пока не используем кириллический адрес, зарегистрируем, когда понадобится. А когда время приходит, выясняется, что имя занято, и начинается долгая процедура его возврата. Стоимость регистрации домена несопоставима с судебными издержками и потерей времени.</p> <p>Важно понимать разницу в механизмах. Для доменов, существующих по договору с ICANN, действует UDRP: решение выносят арбитры, обычно в пределах двух месяцев, и панель может распорядиться передать домен. Для .ru и .рф спор идет в российском суде, который домен не передает, а запрещает его использование — и это может занять годы. Дело о доменах с обозначением «Озон» шло больше двух лет через пять инстанций.</p> <p>Недостаточно просто иметь товарный знак — нужно еще показать недобросовестность другой стороны. И здесь распространено заблуждение, будто неиспользуемый домен претензий не вызывает. Практика говорит об обратном: припаркованная страница с рекламными ссылками регулярно признается недобросовестным использованием, а в российских делах суды оценивают само по себе владение именем, сходным с известным знаком. Рассчитывать на то, что домен «просто лежит», не стоит.</p> <p>Мониторинг остается недооцененным инструментом. Практически во всех известных делах нарушение обнаруживали именно так. Чем раньше вы его заметите, тем дешевле обойдется защита".</p> <h3>Выводы</h3> <p>Кириллические домены — это не только возможность для брендинга, но и поле для конфликтов. Киберсквоттинг не исчез, он просто перешел в другую языковую среду.</p> <p>Превентивные меры — товарный знак, своевременная регистрация значимых для бизнеса имен, мониторинг — требуют небольших вложений и снимают большинство рисков. Если конфликт уже возник, работающие механизмы есть, но они требуют времени, денег и доказательной базы. Защитить бренд заранее дешевле, чем возвращать его через суд или арбитраж.</p> <p>#IMAGE_235874#</p> Появление кириллических доменов расширило возможности для брендинга, но одновременно создало новое поле для конфликтов … article Ян Созонов, юрист по доменному праву и правовому регулированию реестра .РУС (“Русские Имена”) Почему кадровый документооборот не получается собрать на действующей СЭД https://www.itweek.ru/themes/detail.php?ID=235871 Tue, 03 Nov 2026 10:01:20 +0300 <p>Компания, у которой уже работает система электронного документооборота, подходит к задаче кадрового ЭДО с понятной мыслью: маршруты есть, хранилище есть, подписание есть, нужно добавить типы документов и настроить новые процессы. Решение выглядит дешевле покупки отдельной системы и логичнее с точки зрения ИТ-ландшафта.</p> <p>На практике проект такого типа либо затягивается, либо заканчивается покупкой отдельного решения после полугода доработок. Разберем, что именно не переносится и где граница между доработкой и новой системой.</p> <h3>Главное отличие: пользователь находится вне периметра</h3> <p>Классическая СЭД построена вокруг сотрудника с рабочим местом. У него есть учётная запись в домене, корпоративная почта, рабочий компьютер, он подключён к внутренней сети, и его участие в документообороте является частью его должностных обязанностей.</p> <p>Кадровый документооборот устроен иначе. Его участник это работник как физическое лицо, то есть другой субъект. У монтажника, водителя, продавца и повара нет рабочего места с компьютером. У значительной части штата нет корпоративной почты. Доступ к системе нужен с личного телефона, часто вне рабочего времени, иногда с территории, где нет устойчивой связи.</p> <p>Отсюда следуют требования, которых у СЭД не было по условию задачи: вход без доменной учётной записи, идентификация по номеру телефона, полноценное подписание со смартфона, уведомления по каналам вне корпоративного контура.</p> <p>Переделка интерфейса и мобильного клиента под эту модель настройкой не является. Это другая архитектура доступа.</p> <h3>Подписи: не три вида, а матрица</h3> <p>В СЭД вопрос подписи обычно решён однократно: квалифицированная подпись для внешнего обмена, простая или неквалифицированная для внутреннего согласования. Настройка статическая.</p> <p>В кадровом документообороте вид подписи определяется законом и зависит одновременно от двух параметров: от типа документа и от того, кто подписывает. Статья 22.3 Трудового кодекса задаёт закрытые перечни отдельно для работодателя и отдельно для работника.</p> <p>Работник подписывает только усиленной подписью, квалифицированной или неквалифицированной, следующие документы: трудовой договор, договор о материальной ответственности, ученический договор, договор на получение образования без отрыва от работы, согласие на перевод, заявление об увольнении и его отзыв, ознакомление с уведомлением об изменении определённых сторонами условий трудового договора, ознакомление с приказом о применении дисциплинарного взыскания. По остальным документам ему доступна и простая подпись, если соглашением сторон определены правила установления подписавшего.</p> <p>Для системы это означает, что вид подписи подставляется не настройкой маршрута, а правилом, которое читает тип документа и роль участника. Если оставить выбор человеку, ошибка неизбежна, и цена её высокая: ознакомление с приказом о взыскании, подписанное простой подписью, ставит под сомнение само взыскание, потому что ознакомление входит в порядок его применения по статье 193.</p> <p>Отдельный слой составляет выпуск подписей. В классической СЭД сертификаты получают несколько десятков человек, процесс ручной, и это приемлемо. В кадровом контуре сертификат нужен каждому работнику, то есть тысячам людей, и выпуск должен быть массовым, дистанционным и желательно бесплатным для компании. Это отдельная инфраструктурная задача, а не функция документооборота.</p> <h3>Документы, которые система обязана не принимать</h3> <p>Требование, непривычное для СЭД: часть документов нельзя перевести в электронный вид вообще. Часть 3 статьи 22.1 Трудового кодекса выводит из-под электронного документооборота трудовую книжку и сведения о трудовой деятельности, акт о несчастном случае на производстве, приказ об увольнении и документы о прохождении инструктажей по охране труда.</p> <p>Это закрытый перечень, и он означает, что система должна уметь блокировать отправку таких документов на подписание. Не предупреждать, а не давать. В СЭД такой логики нет по определению: там любой документ, попавший в систему, предполагается подписываемым.</p> <p>Ошибка здесь не исправляется переподписанием. Приказ об увольнении, оформленный только электронно, суд рассматривает как ненадлежащее основание прекращения трудового договора.</p> <h3>Согласия, уведомления и жизненный цикл локальных актов</h3> <p>Перед запуском кадрового документооборота работодатель принимает локальный нормативный акт о его введении, письменно уведомляет работников и собирает согласия тех, у кого был трудовой стаж по состоянию на 31 декабря 2021 года. Принятые позже и не имевшие стажа подключаются без согласия.</p> <p>Работник вправе отказаться, отказ нарушением не является, и за него нельзя уволить. Для отказавшихся компания бессрочно ведёт бумажный процесс, а документы, связанные с работой, обязана выдавать им на бумаге бесплатно и надлежаще заверенными.</p> <p>Для системы это означает флаг в карточке работника, который влияет на всю маршрутизацию, и отдельную ветку процессов. Технически несложно, организационно почти всегда упускается.</p> <p>Один человек вне контура создаёт полноценный второй процесс. В одной организации из почти шестидесяти работников отказался один, и компания считала переход стопроцентным. Фактически у неё стало два документооборота, и закончилось это тем, что приказ о сокращённом предпраздничном дне ушёл только через систему, а единственный бумажный сотрудник его не получил.</p> <p>Отдельно стоит жизненный цикл локальных актов. Ознакомление это финал, а до него акт создаётся, согласуется, утверждается, доводится до работников, и по истечении срока переиздаётся. Система, которая умеет только рассылать акт на ознакомление, оставляет остальной цикл ручным. В СЭД такой цикл обычно есть, и это одна из немногих частей, которая переносится без переделки.</p> <h3>Нагрузка ведёт себя по-другому</h3> <p>Классическая СЭД получает равномерный поток: документы создаются в течение дня, согласования распределены, пиков почти нет.</p> <p>Кадровый документооборот работает иначе. Рассылка одного локального акта на ознакомление приводит в систему весь штат одномоментно. Начало отпускного периода даёт всплеск заявлений. Январские приказы об индексации уходят всем сразу.</p> <p>При проектировании это редко учитывают: в техническое задание попадает средняя нагрузка, посчитанная от числа документов в месяц, а проверять надо другое: поведение при одновременном входе всех пользователей. Для СЭД, рассчитанной на несколько сотен активных сессий, приход всего штата в течение часа означает не рост нагрузки, а другой режим работы.</p> <h3>Интеграция идёт не туда, куда привыкли</h3> <p>СЭД обычно интегрирована с почтой, порталом, системой заявок. Кадровый документооборот должен быть связан прежде всего с учётной системой по персоналу: оттуда приходят оргструктура, штатное расписание, кадровые события, туда возвращаются статусы подписания.</p> <p>Три места, где это ломается чаще всего:</p> <ul> <li><strong>Односторонний обмен.</strong> Документ ушёл на подписание, работник подписал, статус в учётную систему не вернулся. Кадровик ведёт два окна и сверяет руками.</li> <li><strong>Расхождение справочников.</strong> Маршруты строятся на ролях, роли определяются по оргструктуре. Если справочники разошлись, документ уходит не тому согласующему, и обнаруживается это не сразу.</li> <li><strong>Потеря файлов подписи.</strong> При откреплённой подписи на каждый документ приходится отдельный файл. Интеграция, которая переносит только документ, оставляет архив без доказательной части, и выясняется это через годы.</li> </ul> <h3>Что из СЭД переносится, а что нет</h3> <p>Переносится инфраструктура: хранилище, права доступа, журналирование, общие механизмы согласования, жизненный цикл нормативных документов, интеграционная шина. Это немало, и именно поэтому идея выглядит привлекательной.</p> <p>Не переносится всё, что связано с участником вне периметра и с законом: модель доступа без доменной учётной записи, массовый выпуск сертификатов, правила выбора подписи по типу документа и роли, блокировка документов из закрытого перечня, учёт согласий и отказов, поведение под пиковой нагрузкой, обмен с учётной системой по персоналу.</p> <p>Граница проходит здесь: если ваша СЭД уже умеет работать с пользователями без доменных учётных записей и массово выпускать сертификаты, доработка реалистична. Если нет, вы пишете вторую систему внутри первой.</p> <h3>Как проверить это за один день</h3> <p>Возьмите три сценария и прогоните их на своей СЭД мысленно, а лучше руками.</p> <p>Первый. Работник без корпоративной почты и без рабочего компьютера получает трудовой договор и подписывает его со своего телефона усиленной подписью. Сколько шагов, где он берёт сертификат, что видит.</p> <p>Второй. Кадровик пытается отправить на электронное подписание приказ об увольнении. Система должна не дать.</p> <p>Третий. Локальный акт уходит на ознакомление всему штату, и все открывают его в течение часа.</p> <p>Если все три сценария проходят, доработка оправдана. Если спотыкается хотя бы первый, считайте стоимость отдельного решения: обычно она оказывается ниже стоимости доработки, потому что доработка повторяет путь, который кто-то уже прошёл.</p> <p>Нормативные ориентиры: статьи <nobr>22.1-22.3</nobr> и 193 Трудового кодекса; статьи <nobr>22.1-22.3</nobr> введены Федеральным законом от 22.11.2021 № <nobr>377-ФЗ;</nobr> Федеральный закон от 06.04.2011 № <nobr>63-ФЗ.</nobr> Сведения приведены на дату публикации.</p> <p>#IMAGE_235872#</p> Компания, у которой уже работает система электронного документооборота, подходит к задаче кадрового ЭДО с понятной … article Мария Жилева, сооснователь сервиса КЭДО “Добыто” Рост среднего чека и лояльности: как тандем ИИ-инструментов BSS оптимизирует работу контакт-центров https://www.itweek.ru/themes/detail.php?ID=235870 Mon, 02 Nov 2026 17:34:59 +0300 <p>Сентимент-анализ и «Суфлёр оператора» от BSS уже работают в контакт-центрах крупных государственных организаций обслуживающих население. Опыт применения показывает: когда система слышит эмоции клиента и подсказывает оператору ответ прямо во время разговора, конфликтов становится меньше, а обслуживание — быстрее и точнее. Именно поэтому такие инструменты становятся обязательной частью современного клиентского сервиса.</p> <p>В крупных контакт-центрах компаний и организаций с постоянным массовым потоком обращений не редки случаи звонков клиентов и граждан в состоянии стресса, раздражительности, внезапных негативных ситуаций. Часто они не отрабатываются корректно, а пропущенный конфликт становится известен лишь из жалобы. При таком развитии событий на помощь приходит модуль сентимент-анализа, который в реальном времени присваивает каждой реплике одну из трёх оценок — негатив, позитив или нейтрально, отдельно для клиента и для оператора.</p> <p>Оценку дают два независимых классификатора. Акустическая нейросетевая модель анализирует, как сказано, — тон и интонацию, а лексический классификатор смотрит, что сказано, по словарю характерных фраз. Если они расходятся, итог определяют настраиваемые правила — например, «негатив + нейтраль → негатив». Правила вынесены в конфигурацию, поэтому логику можно калибровать без доработки модуля.</p> <p>Результат анализа работает сразу в двух точках. В голосовом боте при негативе в речи клиента диалог не доводится до конца сценария, а сразу передаётся оператору выделенной скилл-группы, обученной работать со сложными обращениями. В речевой аналитике сентимент-метки помогают супервизору быстро найти диалоги с негативом и оценить, удалось ли оператору перевести разговор в позитив.</p> <p>На повышение удовлетворенности клиента работает и «Суфлёр оператора». В сущности — это коллектив ИИ-агентов, которые слушают диалог вместе с оператором в голосовом канале или чате. Система распознаёт речь или захватывает переписку, понимает запрос клиента и контекст разговора, находит нужное в корпоративной базе знаний и данные о клиенте в CRM и ERP. Затем сама или по запросу оператора выводит подсказку или заполняет форму.</p> <p>Оператор получает готовые ответы на типовые вопросы, предупреждения об отклонениях от скрипта, формулировки для деэскалации и компенсационные сценарии для претензий. По контексту разговора «Суфлёр» предлагает товары для cross-sell и upsell, в том числе маржинальные и акционные, а после звонка сам фиксирует причину обращения, упоминания конкурентов и удовлетворённость клиента.</p> <p>Решение разворачивается полностью в контуре заказчика: распознавание речи и LLM входят в поставку, при желании можно подключить облачные сервисы. Для персонализации подсказок используется RAG + LLM, для скорости и экономии ресурсов — классический полнотекстовый поиск. «Суфлёр» поддерживает протоколы MCP и A2A и «из коробки» интегрируется с чат-платформой, бот-платформой и базой знаний BSS.</p> <p>Инструменты дополняют друг друга: сентимент-анализ показывает, как идёт разговор, а «Суфлёр» подсказывает, что сделать дальше. По оценкам BSS, «Суфлёр» повышает конверсию из консультации в продажу до 20% и средний чек до 5%. Время обработки звонка сокращается на <nobr>5–10%,</nobr> нагрузка на операторов текстового канала — на <nobr>5–20%,</nobr> а новички выходят на план до двух раз быстрее. Повторных обращений становится на <nobr>5–20%</nobr> меньше, а CSI/NPS растёт на <nobr>2–5%.</nobr></p> <p>Компания перестаёт зависеть от узкой группы опытных операторов: их знания доступны каждому через подсказки. А супервизоры получают объективные данные об эмоциях в каждом диалоге вместо выборочного прослушивания.</p> <p>«Оператор контакт-центра одновременно ведёт разговор, ищет информацию в десятках инструкций и следит за настроением собеседника. Мы снимаем с него часть этой нагрузки. Сентимент-анализ вовремя показывает, что диалог уходит в конфликт, а „Суфлёр“ сразу предлагает верный ответ или уместное предложение. В итоге новичок работает на уровне опытного сотрудника, а бизнес сохраняет лояльность клиентов и выручку», — отметил Александр Крушинский, директор департамента голосовых цифровых технологий компании BSS.</p> <p>Эти технологий уже используют крупнейшие контакт-центры в государственном секторе, обслуживающих население РФ. Цифровой ассистент «научился анализировать поступающие запросы, в том числе по речевому и эмоциональному поведению», а ИИ подсказывает оператору формулировки, чтобы повысить точность ответа.</p> Сентимент-анализ и «Суфлёр оператора» от BSS уже работают в контакт-центрах крупных государственных организаций … message Для каждой четвёртой компании экспертиза сервисного подрядчика важнее стоимости услуг https://www.itweek.ru/themes/detail.php?ID=235869 Mon, 02 Nov 2026 15:38:24 +0300 <p>Сервисное обслуживание ИТ-оборудования становится одним из наиболее заметных запросов рынка. В поиске профильных подрядчиков заинтересованы как заказчики, так и компании, которые поставляют и внедряют оборудование и программное обеспечение. По данным исследования OCS, при выборе сервисного партнёра они прежде всего обращают внимание на инженерную экспертизу и региональный охват. В совокупности эти факторы отметила почти половина респондентов.</p> <p>Опрос показал, что для каждой четвёртой компании ключевым критерием при выборе сервисного подрядчика становится квалификация его специалистов. Стоимость услуг учитывается уже после оценки экспертизы. Это особенно важно для компаний с мультивендорной ИТ-инфраструктурой. Для её обслуживания необходим опыт работы с оборудованием брендов, официально не представленных в России, и многопрофильные инженерные компетенции, в том числе уникальные для рынка. Более половины респондентов отмечают важность единого окна для приёма заявок по решениям разных производителей. Такой формат упрощает взаимодействие и помогает избежать разрывов в обслуживании комплексной инфраструктуры. </p> <p>География проектов также расширилась за последние несколько лет. Компании в регионах наращивают и модернизируют ИТ-мощности, а отечественные производители активнее выходят за пределы крупных городов. Для интеграторов и производителей оборудования это означает усложнение сервисной модели. Обслуживание распределённых и удалённых объектов требует большой технической команды, отлаженной логистики и доступного запаса комплектующих. Сервисным подразделениям необходимо обеспечивать оперативную доставку ЗИП и поддерживать его наличие на региональных складах. Создание собственной инфраструктуры требует значительных вложений и времени, поэтому для большинства компаний рациональнее передать эту задачу профильному подрядчику. Региональную сеть называют основным критерием выбора 17% респондентов, наличие складов ЗИП в регионах важно для 61% опрошенных. </p> <p>Круглосуточный сервис и первая линия поддержки реже становятся определяющими критериями выбора. 44% и 30% участников исследования соответственно указали, что не считают эти возможности решающими. Это стандарт для сервисного предложения, а не самостоятельное преимущество подрядчика. При этом внешнее обслуживание чаще рассматривается не как полная замена собственной службы поддержки, а как способ расширить её возможности, например, при работе с мультивендорной инфраструктурой или региональными проектами. Для 57% респондентов привлечение подрядчика связано в первую очередь с масштабированием бизнеса: выходом на новые контракты, расширением продуктового портфеля и работой с новыми производителями. </p> <p>«При поиске сервисной организации компании учитывают множество факторов, анализируют реальный опыт и квалификацию специалистов. Чем сложнее системы и оборудование, тем важнее и строже эти критерии. Рынку нужен не исполнитель, а полноценный партнёр, который сможет координировать взаимодействие с разными производителями, обслуживать комплексную инфраструктуру и поддерживать развитие региональных проектов», — отметил Алексей Лабынцев, директор департамента сервисного обслуживания OCS.</p> <p>Партнёры и бизнес уже работали с поддержкой иностранных производителей и предъявляют высокие требования к российским подрядчикам. Компаниям важна устойчивость: инженерный и логистический ресурс, склады ЗИП, юридическая и финансовая надёжность. Исследование OCS показало, что в текущей ситуации эти факторы становятся для рынка приоритетнее цены. Экономия впоследствии может привести к увеличению расходов: нехватке запчастей в критический момент, простоям оборудования и убыткам. Финансировать большой штат инженеров и склады ЗИП при стоимости услуг в несколько раз ниже рыночной просто невозможно. Настоящей валютой становятся экспертиза и дополнительные ресурсы, которые могут помочь в развитии бизнеса. Сервисные организации, которые смогут закрывать эти запросы, с большой долей вероятности станут опорой для рынка в ближайшие несколько лет.</p> Сервисное обслуживание ИТ-оборудования становится одним из наиболее заметных запросов рынка. В поиске профильных … message Indeed ITDR 2.3: полный контроль NTLM и расширенная защита от кибератак https://www.itweek.ru/themes/detail.php?ID=235868 Mon, 02 Nov 2026 15:37:28 +0300 <p>Компания «Индид», российский разработчик решений в области защиты айдентити, представила обновление продукта Indeed Identity Threat Detection and Response (Indeed ITDR). Новая версия 2.3 позволяет организациям усилить защиту корпоративных систем, включая унаследованные приложения, повысить эффективность обнаружения кибератак и управления хранением событий доступа.</p> <p>Главным обновлением Indeed ITDR 2.3 стала поддержка NTLM-аутентификации. Теперь продукт охватывает все три основных протокола, используемых при доменной аутентификации Active Directory: Kerberos, LDAP и NTLM.</p> <p>Несмотря на развитие современных механизмов аутентификации, в корпоративных инфраструктурах по-прежнему используется NTLM — устаревший протокол проверки подлинности пользователей, от которого зависит работа многих унаследованных приложений. Полный отказ от него зачастую требует модернизации систем, а отсутствие дополнительных мер защиты повышает риски компрометации учетных данных и несанкционированного доступа.</p> <p>Для решения этой задачи в Indeed ITDR 2.3 добавлена обработка протокола Netlogon, который используется при взаимодействии с контроллерами домена для проверки учетных данных через NTLM. Благодаря этому продукт может отслеживать запросы на аутентификацию, выборочно блокировать их или требовать дополнительный фактор подтверждения личности. Такой подход компаниям применять политики безопасности к отдельным подключениям, сохраняя работоспособность унаследованных приложений.</p> <p>При этом Indeed ITDR не расшифровывает защищенные соединения Netlogon, а получает необходимые сведения из журналов событий Windows в реальном времени. Это дает возможность контролировать NTLM-аутентификацию без раскрытия ключей шифрования и изменения существующих схем взаимодействия с контроллерами домена.</p> <p>Новая функциональность также распространяется на случаи, когда NTLM используется как резервный способ проверки подлинности. Вместе с ранее реализованной обработкой Kerberos и LDAP это расширяет охват мониторинга Active Directory, сокращает слепые зоны и позволяет организациям постепенно отказываться от устаревшего протокола без нарушения рабочих процессов.</p> <p>В Indeed ITDR 2.3 компания «Индид» расширила возможности обнаружения атак на доменную инфраструктуру. Благодаря новвоведению, ИБ-специалисты могут раньше выявлять попытки несанкционированного доступа, обхода защиты и повышения привилегий, а также получать больше информации для расследования инцидентов.</p> <p>В частности, продукт теперь обнаруживает эксплуатацию уязвимости Kerberos CheeseOunce (CVE-2022-33679) и LDAP Guest Authentication — небезопасную анонимную аутентификацию через LDAP. Для обнаружения Kerberos FAST Downgrade и LDAP Guest Authentication в Indeed ITDR добавлена обработка Kerberos FAST и анонимных LDAP-запросов.</p> <p>Для эффективной работы с данными мониторинга разработчик усовершенствовал инструменты хранения событий. В версии 2.3 администраторы могут самостоятельно устанавливать, как долго сохранять информацию о запросах доступа, исходя из внутренних политик компании и нормативных требований. По истечении заданного срока записи удаляются, что предотвращает их бесконтрольное накопление и снижает риск переполнения дискового пространства.</p> <p>Кроме того, в консоли администрирования (Management Console) появилась возможность просматривать объем дискового пространства, занятого событиями доступа. Это помогает администраторам отслеживать накопление данных, своевременно корректировать сроки их хранения и предотвращать переполнение диска. В результате компаниям становится проще управлять журналами событий, сохраняя необходимую информацию для анализа угроз и расследования инцидентов.</p> <p>«Для нас важно, чтобы повышение безопасности не требовало от заказчиков перестройки ИТ-инфраструктуры. Во многих компаниях NTLM продолжает использоваться для работы устаревших приложений, и отказаться от него за короткий срок чаще всего невозможно. При этом использование протокола сопряжено с рисками безопасности: его уязвимости злоумышленники нередко используют для перемещения по инфраструктуре и повышения привилегий. Поэтому в Indeed ITDR 2.3 мы обеспечили поддержку всех трех основных протоколов, используемых при доменной аутентификации Active Directory, — Kerberos, LDAP и NTLM. Теперь организации могут взять NTLM под контроль, сохранив работоспособность существующих приложений и возможность постепенно переходить на современные технологии», — отметил Лев Овчинников, руководитель продукта Indeed ITDR компании «Индид».</p> Компания «Индид», российский разработчик решений в области защиты айдентити, представила обновление продукта Indeed Identity … message 60% инцидентов с интернетом вещей происходит из-за устаревшего ПО https://www.itweek.ru/themes/detail.php?ID=235867 Mon, 02 Nov 2026 15:35:52 +0300 <p>Устаревшее ПО становится причиной инцидентов информационной безопасности в сфере интернета вещей (IoT) в 60% успешных кибератак в 2026 году. Эксперты «Кросстех» называют основной причиной отсутствие процессов инвентаризации и управления обновлениями.</p> <p>По оценкам специалистов, злоумышленники стали на <nobr>15-20%</nobr> чаще атаковать IoT-устройства в I полугодии 2026 года по сравнению с аналогичным периодом прошлого года. Число инцидентов растет из-за расширения инфраструктуры интернета вещей: количество подключенных IoT-устройств в российских организациях превышает 100 млн, а значительная доля рынка приходится на промышленный интернет вещей (IIoT). Еще один из факторов потенциального взрывного роста количества инцидентов: c появлением ИИ-агентов требовавшие ранее высокой компетенции и больших трудозатрат атаки стали доступны даже для начинающих злоумышленников. ИИ-инструменты ускорили реверс-инжиниринг бинарных прошивок устройств для поиска узявимостей, таких как переполнения буфера, пароли в открытом виде в коде и скрытые API-интерфейсы. </p> <p>¾ российских компаний, использующих IoT-устройства, испытывают дефицит их видимости, из-за чего не могут вовремя отключать неиспользуемые устройства и обновлять ПО действующих. В этом случае злоумышленники могут использовать уязвимые устройства как точку входа, с их помощью проникать в инфраструктуру, красть чувствительную информацию и даже воздействовать на инфраструктуру.</p> <p>«Не так давно во Франции произошла атака на IoT-устройства, когда злоумышленники с помощью уязвимостей смогли воздействовать на систему регуляции температуры в холодильниках в супермаркетах. Они повысили температуру до 50 градусов, что привело к массовой порче товара. Такая ситуация вполне может быть масштабирована и на более критичные предприятия и процессы, например, в промышленности. В таком случае потери будут гораздо более значительными, чем в описанном кейсе», — отметил Василий Коровицын, ведущий эксперт департамента оценки защищенности «Кросстех».</p> <p>В компании отмечают, что разворачивание сетей 5G в России окажет влияние и на интернет вещей: системы будут становиться более масштабными, объединят тысячи автономных датчиков, дронов и контроллеров в единую технологическую сеть, что в свою очередь приведет и к росту кибератак на IoT-устройства.</p> <p>«Важно уже сейчас выстраивать процесс инвентаризации и регулярного обновления прошивок, чтобы сделать систему более устойчивой к кибератакам. Контроль активов — важнейшая составляющая, которая помогает компании понимать границы своей инфраструктуры и все потенциальные векторы атаки. Компаниям также необходимо регулярно сменять стандартные пароли, сегментировать сеть, проверять конфигурации устройств и т.д., чтобы обеспечивать киберустойчивость», — подчеркнул Василий Коровицын .</p> Устаревшее ПО становится причиной инцидентов информационной безопасности в сфере интернета вещей (IoT) в 60% … message Aktiv.consulting и ТИМ ФОРС подтвердили допуск к работе с финансовым сектором ГОСТ 57580.1 https://www.itweek.ru/themes/detail.php?ID=235866 Mon, 02 Nov 2026 15:33:52 +0300 <p>Aktiv.consulting (бизнес-направление компании «Актив») совместно с командой ТИМ ФОРС завершили проект по приведению системы информационной безопасности компании к требованиям ГОСТ 57580.1. Компания получила официальное заключение о соответствии с итоговым уровнем 0,7, что подтверждает зрелость ее системы ИБ и надежность, как поставщика банковского сектора.</p> <p>После 2022 года Банк России последовательно ужесточает требования к защите информации в финансовой сфере. Для подрядчиков банков это означает более строгий контроль ИБ, поэтому ТИМ ФОРС решила подтвердить свой уровень независимой оценкой соответствия.</p> <p>Сложность заключалась в том, что стандарт изначально спроектирован для банков с их инфраструктурой — кассовыми узлами, процессингом, банкоматами. У ТИМ ФОРС как у ИТ-разработчика эти объекты отсутствуют. Требовалась глубокая экспертная адаптация: аргументированное исключение неприменимых мер и корректная интерпретация оставшихся применительно к деятельности компании-разработчика.</p> <p>Дополнительные ограничения: жесткие сроки, невозможность длительных выездных проверок, необходимость решить задачу без расширения штата и закупки избыточных средств защиты, а также фокус сотрудников на разработке, а не на ИБ.</p> <p>Aktiv.consulting применила гибридную методологию. Вместо классического аудита с длительными интервью использовались структурированные опросные листы с последующей выборочной экспертной верификацией. Это снизило нагрузку на персонал, ускорило сбор информации на <nobr>50–70%</nobr> и сразу дало письменные артефакты для аудиторов.</p> <p>Ключевой этап — экспертная адаптация ГОСТ 57580.1 под профиль ИТ-разработчика. Совместно со специалистами ТИМ ФОРС команда Aktiv.consulting детально проанализировала требования стандарта: аргументированно исключила меры, неприменимые для компании без банковской инфраструктуры; оставшиеся требования переложила на процессы разработки, эксплуатации и сопровождения ПО; приоритизировала меры по влиянию на итоговый балл.</p> <p>На основе собранных данных разработан полный комплект организационно-распорядительной документации и сформирована дорожная карта развития ИБ на годы вперед, учитывающая ужесточение требований регулятора с 2027 года.</p> <p>Официальное заключение о соответствии ГОСТ 57580.1 (уровень 0,7), укрепило позиции АО «ТИМ ФОРС Альянс» (входит в группу компаний ТИМ ФОРС) в тендерах и стало одним из условий работы с крупным стратегическим клиентом. Главная ценность — не сам документ, а выстроенная ИБ-инфраструктура: процессы разработки и сопровождения банковского ПО в АО «ТИМ ФОРС Альянс» ведутся в соответствии с требованиями стандарта, создана прозрачная СОИБ, понятная сотрудникам и внешним аудиторам.</p> <p>Такой подход позволил достичь целевого уровня без избыточных затрат на новые средства защиты. Полученное заключение и сформированная доказательная база применимы при работе с другими финансовыми организациями и сокращают затраты на подтверждение соответствия в новых проектах, а поддерживать и повышать уровень компания будет в рамках периодической переоценки.</p> <p>«Финтех для ТИМ ФОРС — это многолетняя практика. Нам было важно не просто получить заключение, а встроить требования банковского стандарта в то, как мы разрабатываем и сопровождаем ПО. Как интегратор производительности мы отвечаем за результат всей связки — специалистов, команд и цифровых инструментов, в том числе на базе ИИ. Информационная безопасность в этой связке — не формальность к тендеру, а базовое условие доверия заказчика», — отметил Илья Воробьев, генеральный директор АО «ТИМ ФОРС Альянс».</p> Aktiv.consulting (бизнес-направление компании «Актив») совместно с командой ТИМ ФОРС завершили проект по приведению … message Агентный хаос: чем опасно большое количество ИИ-агентов https://www.itweek.ru/themes/detail.php?ID=235864 Mon, 02 Nov 2026 10:07:01 +0300 <p>Создать небольшого агента сегодня можно быстрее, чем оформить его запуск по корпоративным правилам. На прототип уходит час, на согласование описание доступов и владельцев — несколько дней.</p> <p>Отсюда и начинается агентный хаос: с момента, когда скорость создания цифровых помощников становится выше скорости назначения ответственности и правил. В результате вокруг бизнеса вырастает слой маленьких автоматизаций, о которых знают только их авторы.</p> <p>Разберем, почему это опасно — и какой контур управления нужен, чтобы в компании не появилась теневая инфраструктура.</p> <h3>Почему хаос создают маленькие решения</h3> <p>Крупный ИТ-проект невозможно запустить так, чтобы никто этого не заметил. У него есть команда, бюджет, документация, владельцы и поддержка. С небольшим агентом дела обстоят совсем по-другому — это может быть бот с ежедневным отчетом или скрипт интеграции сервисов. Собрать его можно быстрее, чем пройти стандартную процедуру запуска — и ее начинают игнорировать.</p> <p>Отсюда и появляется хаос: автоматизация уже работает с корпоративными данными и выполняет действия, но о ней могут не знать DevOps, финансы или команда поддержки. Не определено, кто устранит сбой, во сколько обходится решение — и что случится, если создатель такого решения вдруг станет недоступен.</p> <p>Полный процесс запуска большого проекта здесь избыточен, но полностью обходить контроль нельзя. Его надо облегчить: зарегистрировать решение, описать доступы, стоимость, поддержку и условия отключения.</p> <h3>В заложниках автоматизации</h3> <p>Создатель цифрового помощника нередко остается единственным человеком, знающим, что он существует и как он устроен. Пока все работает, это незаметно. Затем меняется шаблон файла или ломается интеграция — и автоматизация возвращается к своему автору.</p> <p>Мы и сами как-то столкнулись с похожим эффектом: небольшие внутренние решения начали периодически «дергать» создателя обратно. Например, агент каждую неделю отправляет в канал маркетинга отчеты, а тут вдруг не прислал — надо разбираться. Сломалась автоматизация, связанная с рекрутингом — команда ждет, когда автор придет и все починит. Если инструмент уже встроен в важный процесс, создавший его специалист остается единственной точкой знания.</p> <p>Отсюда полезное разделение: человек, который понимает бизнес-проблему и придумал агента, не обязан годами обслуживать его. Создание требует одной экспертизы, эксплуатация — другой.</p> <h3>Владельца мало, но кто еще нужен?</h3> <p>Если одного только создателя автоматизации недостаточно, значит, нужен еще специалист, который возьмет на себя другую ответственность. Для корпоративного агента полезно разделять минимум две роли:</p> <ol> <li><strong>Бизнес-владелец</strong> — отвечает за то, зачем инструмент существует, какую пользу приносит и когда его пора отключить.</li> <li><strong>Технический владелец </strong>— отвечает за работоспособность, инфраструктуру, обновления и инциденты.</li> </ol> <p>Финансы могут следить за оплатой сервисов, DevOps — за инфраструктурой, профильное подразделение — за экономическим эффектом. Так решение перестает быть намертво привязанным к автору.</p> <h3>Когда агент становится частью теневой инфраструктуры</h3> <p>Риск появляется, когда у цифрового помощника появляется доступ к данным и право что-то менять, а в компании при этом не знают, кто за него отвечает.</p> <p>Для реальной работы ему нужны полномочия: читать документы, отправлять сообщения, менять записи, создавать файлы. Чем больше таких решений существует вне общего контура, тем труднее понять, куда передается информация и какие действия выполняются от имени сотрудников.</p> <p>Ограничения лучше задавать не только в инструкции. Если действие технически доступно, одного запрета «не делай этого» маловато. Для чувствительных операций права можно урезать через промежуточный сервис, который разрешает только нужные вызовы.</p> <h3>Минимальный паспорт автоматизации вместо бюрократии</h3> <p>Для небольших агентов достаточно облегченного «паспорта». Так, перед выходом из личной песочницы должно быть понятно:</p> <ul> <li> какую бизнес-проблему решает автоматизация и по какому показателю будет понятна ее польза;</li> <li> кто отвечает за ценность, а кто — за техническую часть;</li> <li> какими данными она пользуется;</li> <li> какие действия ей разрешены и где требуется подтверждение человека;</li> <li> сколько она стоит и кто ее поддерживает;</li> <li> от каких сервисов зависит;</li> <li> когда ее пересмотреть и при каких условиях отключить.</li> </ul> <p>Последние два пункта особенно важны. Агент может долго быть полезным, а потом утратить актуальность. Если никто не отвечает за пересмотр, он продолжит использовать токены, ключи и серверные ресурсы.</p> <p>Так среди помощников появляются «зомби-агенты». Бизнес уже забыл, зачем они нужны — а расходы и доступы никуда не делись.</p> <h3>Пять одинаковых агентов — тоже хаос</h3> <p>Представьте, что специалист автоматизировал какой-то процесс. Спустя пару месяцев второй сотрудник решил эту же задачу, но другим способом, а чуть позже третий сделал свой вариант, даже не подозревая о первых двух.</p> <p>Кроме того, есть другой, более опасный вариант, когда несколько автоматизаций управляют одним объектом. Например, один агент обновил карточку в CRM, второй в тот же день сделал это снова, но по своим правилам</p> <p>В итоге компания несколько раз платит временем за создание одной и той же функции — и, более того, продолжает поддерживать несколько реализаций. Чтобы этого не произошло, нужен хотя бы самый простой каталог, где расписано, какие агенты уже существуют, для чего и кто владелец. Перед созданием решения стоит удостовериться, нет ли уже рабочего аналога — а для критичных объектов заранее определить, какая автоматизация имеет право их менять.</p> <p>Само количество агентов при этом мало о чем говорит: пять полезных и управляемых сервисов могут быть лучше пятидесяти экспериментов. Важнее бизнес-эффект при понятной полной стоимости и уровне риска.</p> <h3>«Сделано за час» — еще не значит «дешево»</h3> <p>Агент продолжает потреблять ресурсы после запуска: токены, серверные мощности, подписки и время поддержки. По отдельности суммы малы — но десяток автоматизаций, например, уже превращается в постоянную и заметную статью расходов.</p> <p>Считать нужно полную стоимость владения. Прежде чем создать агента, надо подумать: а кто будет чинить сбои и обновлять интеграции? Кто заметит, что расходы вдруг существенно выросли? Есть ли вообще в компании ответственный, который регулярно отслеживает, сколько денег уходит на все подобные инициативы?</p> <p>Если не учитывать этот важный момент, «быстро и дешево собрали» легко превратится в «дорого и незаметно поддерживаем».</p> <h3>Не всем агентам нужен одинаковый контроль</h3> <p>Персональный помощник и корпоративный — это разные классы риска. К примеру, если ИИ помогает специалисту собрать данные или подготовить отчет, а человек сам проверяет работу и отправляет результат, достаточно легкого контроля.</p> <p>Совсем другое дело — автоматизация, которая переносит данные между сервисами, пишет в общие каналы или меняет записи без ручной проверки. Здесь необходимы владельцы, мониторинг и понятные права доступа.</p> <p>Критичность тоже различается. Если внутренний бот для маркетинга не прислал еженедельный отчет, бизнес это переживет. А вот если остановился инструмент, от которого зависят продажи или рекрутинг, задержка может обойтись компании недешево. Для таких сервисов нужны SLA, резервный ответственный и порядок восстановления.</p> <h3>Дело не в сотом агенте</h3> <p>Количество агентов само по себе мало о чем говорит. Проблема начинается, когда компания уже не может быстро понять, кто отвечает за конкретную автоматизацию, к каким данным у нее есть доступ, сколько она стоит и нужна ли вообще.</p> <p>Возвращать для каждого небольшого агента полный процесс запуска крупного ИТ-проекта нет смысла. Достаточно обязательного минимума: реестр, бизнес- и технический владельцы, понятные доступы, стоимость, поддержка и условия отключения. Такой облегченный порядок позволяет не тормозить эксперименты и при этом делает автоматизации видимыми и управляемыми.</p> <p>Бизнес-владелец отвечает за ценность решения, технический — за его работу и восстановление после сбоев. И даже полезного агента нужно периодически пересматривать: задача может исчезнуть, а расходы на токены, инфраструктуру и поддержку останутся.</p> <p>Поэтому запуск агента — не конец задачи. После него появляется новый корпоративный актив, который нужно сопровождать и контролировать.</p> <p> #IMAGE_235865#</p> Создать небольшого агента сегодня можно быстрее, чем оформить его запуск по корпоративным правилам. На прототип уходит … article Алексей Феофанов, директор по развитию бизнеса Umbrella IT Пространственный интеллект: что это такое, как работает и какую пользу приносит https://www.itweek.ru/themes/detail.php?ID=235861 Mon, 02 Nov 2026 09:51:44 +0300 <p><em>Пространственный интеллект — это способность понимать физическое или виртуальное пространство и то, как оно меняется с течением времени, — понимать настолько хорошо, чтобы делать выводы о вероятных последствиях тех или иных действий. По мере того как искусственный интеллект переходит от принятия решений и выполнения действий в рамках бизнес-процессов к взаимодействию с физическим миром, именно пространственный интеллект позволяет ему действовать автономно, безопасно и эффективно, пишет в корпоративном блоге Дэн Эверетт, директор </em><em>IDC</em> <em>по исследованиям в области пространственных приложений и моделей окружающего мира.</em></p> <h3>Что такое пространственный интеллект?</h3> <p>Пространственный интеллект объединяет четыре возможности:</p> <ol> <li> Воспринимать физическое пространство или создавать его модель (например, 3D-модель).</li> <li> Распознавать объекты в этом пространстве и определять взаимосвязи между ними.</li> <li> Моделировать, как изменения состояния или активности объектов, а также последовательность событий, влияют на условия и результаты с течением времени.</li> <li> Принимать решения, какие действия необходимо предпринять для достижения желаемого результата.</li> </ol> <p>Люди используют пространственный интеллект ежедневно, даже не задумываясь об этом. Возьмем, к примеру, водителя, едущего по городской улице:</p> <ol> <li> Восприятие: водитель видит улицу и дома вдоль нее.</li> <li> Распознавание: водитель замечает ребенка, играющего с мячом на подъездной дорожке.</li> <li> Моделирование: водитель предполагает, что если мяч отскочит на проезжую часть, ребенок может побежать за ним, не глядя по сторонам.</li> <li> Принятие решений: водитель снижает скорость и продолжает следить за ребенком и мячом, чтобы успеть остановиться, если ребенок выбежит на дорогу.</li> </ol> <p> #IMAGE_235863#</p> <p>Это пример человеческого пространственного интеллекта. Аппаратное и программное обеспечение позволяют машинам выполнять те же четыре действия. Рассмотрим автономный автомобиль, движущийся по той же улице, где ребенок играет с мячом:</p> <ol> <li> Восприятие: камеры, лидары и радары фиксируют обстановку на улице, а система объединения данных с датчиков формирует из них единую, постоянно обновляемую модель окружающего пространства.</li> <li> Распознавание: модели компьютерного зрения идентифицируют ребенка и мяч, а затем отслеживают их положение относительно дороги и траекторию движения.</li> <li> Моделирование: прогностические модели, основанные на законах физики, теории вероятностей и закономерностях, выявленных в ходе анализа данных, оценивают дальнейшее развитие событий — например, выкатывание мяча на дорогу и возможное появление вслед за ним ребенка.</li> <li> Принятие решений: на основе правил безопасности и алгоритмов планирования движения система выбирает ответное действие, которое затем реализуется средствами управления транспортным средством; автомобиль замедляется, продолжая отслеживать перемещения ребенка и мяча, чтобы в случае необходимости полностью остановиться, если ребенок выбежит на проезжую часть.</li> </ol> <p> #IMAGE_235862#</p> <p>Для прогнозирования событий недостаточно просто знать закономерности — необходимо понимать причинно-следственные связи. Система, «усвоившая», что в 15:00 на этой улице обычно пусто, ошибется в тот момент, когда на дорогу внезапно выкатится мяч. Пространственный интеллект позволяет отслеживать состояние объектов, их действия и последовательность событий; благодаря этому система может сделать логический вывод: сначала появился мяч, а следом за ним может оказаться ребенок.</p> <h3>Какие технологии обеспечивают наличие пространственного интеллекта у машин?</h3> <p>Пространственный интеллект формируется за счет аппаратного обеспечения (датчики, вычислительные модули, исполнительные механизмы) и ПО (моделирование пространства, распознавание объектов, прогнозирование событий, принятие решений). Каждый из четырех аспектов пространственного интеллекта опирается на оба этих компонента.</p> <table> <tbody> <tr> <th> Функция</th> <th> Аппаратное обеспечение</th> <th> Программное обеспечение</th> </tr> <tr> <td> Восприятие</td> <td> Камеры, лидары, радары, ультразвуковые датчики и сонары, датчики движения (IMU), системы GPS и позиционирования внутри помещений (например, UWB), 3D-сканеры, IoT-датчики (установленные на транспортных средствах, роботах, гарнитурах, дронах, спутниках)</td> <td> Интеграция данных с датчиков, локализация и картографирование, 3D-реконструкция, геопространственные данные (ГИС), 3D-проектирование (CAD, BIM, среды, созданные с помощью ИИ)</td> </tr> <tr> <td> Распознавание</td> <td> ИИ-процессоры в составе устройств и периферийных систем (включая ИИ, встроенный в камеры и датчики)</td> <td> Компьютерное зрение, обнаружение и классификация объектов, сегментация сцен, отслеживание объектов, модели взаимосвязей между объектами, визуально-языковые модели </td> </tr> <tr> <td> Моделирование</td> <td> Бортовые ИИ-процессоры для прогнозирования в режиме реального времени; графические процессоры (GPU) в дата-центрах и высокопроизводительные вычислительные системы для масштабного моделирования</td> <td> Прогностические модели (физические, вероятностные, основанные на обучении); физические движки; ПО для симуляции и создания цифровых двойников; модели мира</td> </tr> <tr> <td> Принятие решений</td> <td> Бортовые компьютеры и контроллеры реального времени; исполнительные механизмы, реализующие принятые решения (двигатели, рулевое управление, тормоза, роботизированные манипуляторы)</td> <td> Правила и ограничения безопасности, планирование движения и маршрутов, оптимизация, стратегии управления (например, на основе обучения с подкреплением), ИИ-агенты, управляющее ПО</td> </tr> </tbody> </table> <p><em>Примечание: данные списки носят иллюстративный, а не исчерпывающий характер. В большинстве систем одно и то же аппаратное обеспечение используется для этапов распознавания, моделирования и принятия решений независимо от модели развертывания (на периферии, в облаке или онпремис). Исполнительные механизмы отнесены к этапу принятия решений, поскольку именно они позволяют машине совершать действия в физическом мире. В виртуальной среде «действием» может быть внесение изменений в проект или выполнение какого-либо операционного процесса.</em></p> <h3>Каковы примеры применения пространственного интеллекта в различных отраслях и в разных пространственных масштабах?</h3> <p>Пространственный интеллект используется в самых разных отраслях — от космических масштабов до молекулярного уровня. Ниже приведены примеры результатов, на достижение которых направлены те или иные сценарии его использования.</p> <table> <thead> <tr> <th> Отрасль</th> <th> Сценарий использования</th> <th> Масштаб</th> </tr> </thead> <tbody> <tr> <td> Космические агентства</td> <td> Оценка угрозы со стороны околоземных астероидов путем измерения их размеров и отслеживания траекторий</td> <td> Космический</td> </tr> <tr> <td> Оборона и вооруженные силы</td> <td> Снижение потерь личного состава и техники за счет отслеживания сил и угроз на континентальном уровне в режиме, близком к реальному времени</td> <td> Глобальный</td> </tr> <tr> <td> Страхование</td> <td> Снижение коэффициента убыточности благодаря прогнозированию опасных погодных явлений и рисков наводнений, что позволяет точнее определять стоимость страховых полисов</td> <td> Региональный</td> </tr> <tr> <td> Телекоммуникации</td> <td> Сокращение затрат на развертывание вышек связи за счет моделирования покрытия сигналом в 3D-среде города для выбора оптимального места размещения</td> <td> Городской</td> </tr> <tr> <td> Розничная торговля и недвижимость</td> <td> Увеличение выручки на единицу площади за счет прогнозирования эффективности нового магазина на основе демографических данных, интенсивности потока людей и расположения конкурентов</td> <td> Районный</td> </tr> <tr> <td> Сельское хозяйство</td> <td> Повышение урожайности и снижение расходов на удобрения путем прогнозирования реакции отдельных участков поля на внесение различных веществ — с учетом состояния почвы, уровня влажности и стрессовых факторов для растений</td> <td> Полевой</td> </tr> <tr> <td> Складское хозяйство и логистика</td> <td> Увеличение плотности хранения и сокращение времени на комплектацию заказов благодаря виртуальному тестированию планировки склада перед внесением физических изменений</td> <td> Складской комплекс</td> </tr> <tr> <td> Производство</td> <td> Повышение пропускной способности за счет проектирования производственных линий в 3D, что позволяет избежать пересечений оборудования и возникновения узких мест еще до начала монтажа</td> <td> Производственная линия</td> </tr> <tr> <td> Архитектура, проектирование и строительство</td> <td> Предотвращение перерасхода средств путем моделирования последствий изменений в проекте до их утверждения на стройплощадке (например, при необходимости замены несущих балок крыши из-за увеличения расстояния между стенами)</td> <td> Конструктивный элемент</td> </tr> <tr> <td> Фармацевтика</td> <td> Ускорение процесса разработки лекарств за счет моделирования взаимодействия химических соединений с целевыми белками, что позволяет исключить неперспективные варианты еще до лабораторных испытаний</td> <td> Молекулярный</td> </tr> <tr> <td> Игровая индустрия</td> <td> Сокращение времени на разработку и ускорение выпуска игр за счет автоматической генерации ландшафта виртуального мира и маршрутов передвижения неигровых персонажей</td> <td> Виртуальный мир</td> </tr> </tbody> </table> <h3>Какую пользу приносит пространственный интеллект?</h3> <p>Согласно опросу IDC «2025 Power of Place», нельзя выделить какое-то одно преимущество пространственного интеллекта как доминирующее. Респондентам (609 человек из 12 стран) было предложено выбрать три наиболее значимых преимущества инвестиций в геопространственные технологии из 13 предложенных категорий. Чаще всего участники опроса отмечали повышение производительности и экономию затрат (по 27%). В зависимости от отрасли, наиболее важные преимущества различались:</p> <ul> <li> Финансовые услуги: чаще всего респонденты указывали на улучшение соблюдения нормативных требований (31%).</li> <li> Производство: на первом месте — экономия затрат (43%).</li> <li> Розничная торговля: чаще всего респонденты отмечали улучшение клиентского опыта (31%).</li> </ul> <p>Поскольку ключевое преимущество зависит от отрасли, при обосновании бизнес-кейса ориентируйтесь на то, что наиболее ценно именно в вашей сфере.</p> <h3>Заключение</h3> <p>Пространственный интеллект наделяет ИИ способностью воспринимать пространство в динамике — по мере его изменения с течением времени — и анализировать последствия собственных действий. Это применимо к самым разным объектам: от городской улицы или производственного цеха до архитектурного проекта здания или молекулы. Понимание причинно-следственных связей делает прогнозы и логические выводы более устойчивыми к изменениям внешних условий.</p> <p>Чем больше решений и действий имеют пространственную составляющую, тем дороже обходятся ошибки в оценке их последствий — будь то неверно рассчитанная стоимость страхового полиса или столкновения беспилотных транспортных средств. Чтобы снизить подобные риски, следует начать с выбора наиболее значимых сценариев использования, определить необходимые для их реализации возможности, а затем составить дорожную карту внедрения, которую можно воплотить в жизнь.</p> Пространственный интеллект — это способность понимать физическое или виртуальное пространство и то, как оно меняется … article VolgaBlob: российский рынок AI Security и AI Observability начнет расти с 2027 года и устойчиво сформируется к 2028 году https://www.itweek.ru/themes/detail.php?ID=235860 Fri, 30 Oct 2026 14:38:03 +0300 <p>В компании VolgaBlob, разработчике платформы Smart Monitor, оценили зрелость рынка защиты корпоративного ИИ. По оценкам экспертов, несмотря на активное внедрение искусственного интеллекта в корпоративном секторе, устойчивый спрос на специализированные решения для защиты и наблюдаемости интеллектуальных технологий стоит ожидать к 2028 году.</p> <p>Российские компании продолжают активно внедрять искусственный интеллект в бизнес-процессы, но динамика спроса на инструменты его мониторинга и защиты пока отстает от темпов распространения самих технологий. Бизнес сосредоточен прежде всего на повышении эффективности за счет ИИ и поиске новых сценариев его применения, в то время как вопросы информационной безопасности часто отодвигает на второй план.</p> <p>Тем не менее, спрос на инструменты AI Security постепенно формируется. Еще в прошлом году такие запросы носили единичный характер, а в 2026 году их количество среди клиентов VolgaBlob выросло в несколько раз. Это можно объяснить тем, что в результате масштабного внедрения корпоративных LLM, генераторов кода и автономных агентов компании начали все чаще сталкиваться с реальными рисками утечек данных, неконтролируемого использования моделей и «теневого ИИ». Спрос формируется и за счет превентивного подхода: ИБ-специалисты понимают возможные последствия бесконтрольного использования ИИ и стремятся обеспечить мониторинг и защиту таких систем еще до возникновения инцидентов. </p> <p>Кроме того, рынок начинает проявлять интерес к AI Observability (наблюдаемости ИИ). Корпоративные ИИ-ассистенты, инструменты генерации программного кода, автономные агенты и локально развернутые языковые модели создают дополнительные точки взаимодействия с внутренней инфраструктурой и корпоративными данными. При этом ИТ-команды и ИБ-службы не всегда располагают полной и достоверной информацией о том, какие ИИ-инструменты используют сотрудники, к каким данным они обращаются и как это влияет на инфраструктуру. Для ИТ-команд наблюдаемость ИИ важна с точки зрения контроля производительности и стабильности сервисов, оценки нагрузки на инфраструктуру и оперативного выявления причин сбоев.</p> <p>Недостаточная наблюдаемость сегодня становится одной из ключевых проблем безопасности корпоративного ИИ. Даже при контроле внутренней модели остаются сторонние сервисы и личные аккаунты. Именно поэтому в VolgaBlob считают обеспечение AI Observability обязательным первым этапом построения эффективной защиты ИИ-контура.</p> <p>«Компании начинают понимать, что для выстраивания системной защиты им нужна полная картина использования искусственного интеллекта внутри организации. Сначала бизнесу необходимо понять, какие именно инструменты используются, какие данные обрабатываются и какие риски возникают. Мы ожидаем, что уже в 2027 году интерес к AI Observability и AI Security будет заметно расти», — считает Тимофей Мельников, руководитель отдела разработки контентных модулей VolgaBlob.</p> <p>Одним из главных вызовов 2027 года также станет адаптация платформ мониторинга к новым типам данных — пользовательским промптам, логам <nobr>LLM-прокси,</nobr> действиям ИИ-агентов и метрикам GPU. Это потребует от поставщиков решений большей гибкости архитектуры и возможности оперативно подключать новые источники без масштабной доработки программного обеспечения. В долгосрочной перспективе мониторинг и защита ИИ станут частью комплексной наблюдаемости корпоративной инфраструктуры.</p> В компании VolgaBlob, разработчике платформы Smart Monitor, оценили зрелость рынка защиты корпоративного ИИ. По оценкам … message «Е-Флопс» создала модульный сервер М2 https://www.itweek.ru/themes/detail.php?ID=235859 Fri, 30 Oct 2026 14:37:26 +0300 <p><span>Компания «Е-Флопс» разработала модульный сервер М2. Это продукт, адресованный рынку коммерческих ЦОД и</span> <span>суперкомпьютеров, призванный обеспечить заказчикам преимущество в</span> <span>энергоэффективности, плотности вычислений и</span> <span>ТСО (совокупной стоимости владения). По</span> <span>мнению компании, М2</span> <span>— единственный разработанный и</span> <span>производящийся в</span> <span>России ARM-сервер, сравнимый по</span> <span>производительности на</span> <span>стойку с</span> <span>ведущими мировыми аналогами.</span></p> <p>Серверная платформа М2 построена по принципу гибридной вычислительной архитектуры, позволяющей собирать десятки конфигураций с использованием различных семейств центральных процессоров, комбинируемых с GPU- и NPU-ускорителями. В составе сервера М2 доступно 11 моделей вычислительных модулей, включая 6 новых, среди которых появились и однопроцессорные конфигурации. Список доступных GPU- и NPU-ускорителей превышает десяток моделей для различных задач и включает отечественные решения. </p> <p>С технической точки зрения М2 превосходит более раннюю платформу М1 по большинству параметров. Ключевое отличие сервера М2 в применении в вычислительных модулях новой материнской платы MBS02 — «Лена» с высокопроизводительными процессорами архитектуры ARM64, обеспечивающими в 2,5 раза больше ядер и объем памяти до 4 Тб. Сервер М2 способен обеспечить до 2560 универсальных вычислительных ядер на шасси 6U и более 20 000 таких же ядер на серверную стойку, а также обеспечивает наличие специализированных ядер для всего спектра векторных вычислений, количество которых варьируется от выбранных заказчиком исполнений, поддерживаемых М2. </p> <p>Еще более плотный дизайн системной платы «Лена» позволил разместить 16 слотов под модули памяти против 12 в «Ключевской», при этом обеспечив улучшенное охлаждение. В итоге диапазон температур эксплуатации расширен до +45 С0. При этом шасси для обеих платформ остаётся единым, что гарантирует совместимость, упрощает масштабирование инфраструктуры, обеспечивает гибкость конфигураций и защиту инвестиций заказчиков. М2 по-прежнему доступна в тех же исполнениях, что и М1: для классических ЦОД (19«) и для ЦОД стандарта OCP с поддержкой напряжений и 12 В, и 48 В. </p> <p>В шасси М2 усовершенствована система охлаждения: улучшена работа флапперов (жалюзи) модулей охлаждения, а также доработана электронная и программная части управления вентиляторами, переработана плата распределения питания. Изменена механическая часть платформы М2: усилена жёсткость конструкции в отдельных узлах корпуса, облегчено извлечение служебного модуля, а количество пластиковых деталей в конструкции сведено к минимуму. Улучшены эксплуатационные параметры: добавлены элементы «безотвёрточной» сборки-разборки корпусов для упрощения обслуживания и сокращения времени инженерных работ. Разработана и протестирована индивидуальная упаковка, обеспечивающая надёжную транспортировку М2 в любую точку России.</p> <p>Сервер М2 успешно прошёл тепловые испытания в термостенде и подтвердил возможность его использования в инфраструктуре ЦОД с фрикулингом. Это технология естественного охлаждения без использования компрессоров, крайне востребованная в крупнейших передовых ЦОД, позволяет значительно снижать стоимость эксплуатации вычислительных мощностей. </p> <p>Новые процессоры ARM64 оптимизированы для облачных и контейнерных нагрузок, искусственного интеллекта, обработки больших данных и совместимы с несколькими сотнями наименований прикладного ПО с открытым кодом. Использование гибридной вычислительный архитектуры, позволяющей собирать конфигурации не только с GPU, но и с перспективными NPU-ускорителями, расширяет спектр решаемых задач новой серверной мультиплатформенной системы М2. </p> <p>«Создание модульного сервера М2 — закономерный этап развития нашей продуктовой линейки. Новый мультиплатформенный сервер, построенный на материнской плате „Лена“ с увеличенным количеством слотов памяти, процессорных ядер и поддержкой различных типов ИИ-ускорителей, открывает перед заказчиками возможности для решения широкого спектра задач, а улучшенная эргономика и технологичность сборки сокращают время обслуживания. Мы получили не просто апгрейд, а новую современную гибридную платформу, готовую к самым высоким нагрузкам», — отметил руководитель конструкторского отдела компании «Е-Флопс» Сергей Пономарёв.</p> Компания «Е-Флопс» разработала модульный сервер М2. Это продукт, адресованный рынку коммерческих ЦОД и суперкомпьютеров … message Бесплатные видеозвонки для личного общения в «Битрикс24 Синк» https://www.itweek.ru/themes/detail.php?ID=235858 Fri, 30 Oct 2026 14:36:01 +0300 <p>Компания «Битрикс24» объявила о запуске бесплатного сервиса видеозвонков, созданного для личного общения — «Битрикс24 Синк». Теперь поговорить с близкими можно без ограничений по времени, без регистрации и без установки приложений — достаточно создать ссылку на встречу и отправить ее собеседнику.</p> <p>Новый сервис решает задачу, когда нужно срочно созвониться с семьей или друзьями, но заводить ради одного разговора отдельный аккаунт, скачивать приложение не хочется. Человек, получивший ссылку, переходит по ней и мгновенно оказывается в разговоре.</p> <p>Время беседы не ограничено — звонок длится ровно столько, сколько нужно собеседникам, будь то короткий разговор на пять минут или длительные вечерние беседы. </p> <p>Во время разговора можно показать экран, есть реакции, а громкость каждого собеседника настраивается отдельно: если кого-то слышно тише остальных, его голос можно сделать громче.</p> <p>Сервис доступен и в мобильной версии, поэтому поговорить можно из любой локации. Если человек в пути, а разговор нужен уже сейчас — достаточно открыть ссылку на телефоне.</p> <p>Также доступна запись звонок — она длится столько же, сколько сам звонок, позволяя вернуться к беседе в любой момент. В планах компании добавить автоматическую расшифровку звонков, чтобы важное не терялось, а возвращаться к разговору было так же просто, как его начать.</p> <p>Пригласить можно любого человека, даже если он никогда не пользовался продуктами «Битрикс24». </p> Компания «Битрикс24» объявила о запуске бесплатного сервиса видеозвонков, созданного для личного общения — … message Новый перечень из 88 стран: бизнесу пора проверить, куда уходят данные клиентов https://www.itweek.ru/themes/detail.php?ID=235856 Fri, 30 Oct 2026 10:39:46 +0300 <p>Роскомнадзор пересмотрел перечень стран, обеспечивающих адекватную защиту прав субъектов персональных данных, и утвердил приказ от 16.09.2026 № 253. Документ заменил ранее действовавший приказ Роскомнадзора от 05.08.2022 № 128, которым был установлен перечень таких стран. Новый перечень вступает в силу 30 октября 2026 года — по истечении 10 дней с даты официального опубликования. Изменения обусловлены Федеральным законом от 26.07.2026 № <nobr>265-ФЗ,</nobr> который изменил подход к признанию иностранного государства страной, обеспечивающей адекватную защиту прав субъектов персональных данных.</p> <p>При составлении нового перечня Роскомнадзор учитывал не только участие страны в Конвенции о защите физических лиц при автоматизированной обработке персональных данных, но и принятие эффективных мер по:</p> <ul> <li> соблюдению основополагающих принципов защиты;</li> <li> обеспечению конфиденциальности и безопасности персональных данных при их обработке.</li> </ul> <p>Прежняя редакция ст. 12 Федерального закона от 27.07.2006 № <nobr>152-ФЗ</nobr> (далее — <nobr>152-ФЗ)</nobr> предусматривала возможность включения страны в перечень при соблюдении одного из указанных критериев. Именно поэтому ранее действовавший перечень делил страны на участников Конвенции и иные страны, регулирование и меры которых соответствовали положениям Конвенции.</p> <p>В обновленный перечень вошли 88 иностранных государств — теперь это единый список. Из перечня также исключена Украина, входившая в него ранее.</p> <p>Для операторов, которые передают данные сотрудников или клиентов за границу, это означает необходимость пересмотра текущих схем работы с иностранными контрагентами. Так, в отношении контрагентов из стран, не вошедших в перечень Роскомнадзора, оператор обязан проверить наличие законодательства о персональных данных.</p> <p>Перед любой трансграничной передачей оператор обязан уведомить Роскомнадзор, и ведомство вправе запретить или ограничить такую передачу. При этом в страны, включенные в перечень, можно начинать передачу сразу после уведомления, а в страну вне данного перечня — только по истечении 10 рабочих дней с момента подачи уведомления. Например, чтобы передать данные в США, нужно подать уведомление в Роскомнадзор и выждать 10 рабочих дней. Этот же подход нужно применять при передаче данных контрагентам на Украине, поскольку эта страна исключена из текущего перечня.</p> <h2>Когда возникает трансграничная передача?</h2> <p>Трансграничная передача — это передача персональных данных при одновременном соблюдении двух условий:</p> <ul> <li> на территорию иностранного государства;</li> <li> иностранному органу власти, физическому или юридическому лицу.</li> </ul> <p>При этом важно понимать, что трансграничная передача возникает не только при классической пересылке файлов иностранному контрагенту. Такой передачей может быть признано использование иностранной веб-аналитики, CRM, облака, а также иное предоставление фактического доступа зарубежным контрагентам к персональным данным граждан Российской Федерации.</p> <p>Например, трансграничная передача имеет место в случае использования Google Analytics. Несмотря на то что еще с 2025 года активно обсуждается необходимость подачи уведомлений о трансграничной передаче при использовании этого сервиса, далеко не все операторы обеспечили их подачу. В связи с этим рекомендуем проверить свой сайт на предмет подключения Google Analytics и подать уведомление либо отключить сервис при отсутствии фактического использования.</p> <p>Операторам важно пересмотреть свои процессы обработки персональных данных и установить наличие иностранного элемента и признаков трансграничной передачи по описанным выше критериям. Если оба элемента присутствуют, необходимо обеспечить корректную процедуру уведомления РКН.</p> <h2>Что теперь необходимо проверить оператору перед подачей уведомления</h2> <p>Порядок подачи уведомления о трансграничной передаче установлен ст. 12 <nobr>152-ФЗ.</nobr> Теперь перед подачей уведомления оператор обязан получить от иностранного контрагента сведения о правовом регулировании в стране контрагента. Эти сведения вместе с реквизитами контрагента и принимаемыми им мерами защиты данных оператор обязан предоставить по запросу Роскомнадзора в течение 10 рабочих дней. Срок может быть продлен, но не более чем на 5 дней при наличии мотивированного уведомления оператора, в котором необходимо отразить причины продления.</p> <p>При этом обязанности заново направить уведомление по результатам публикации нового перечня у операторов не возникает, но собрать описанную выше информацию о правовом регулировании и мерах защиты нужно заранее.</p> <h2>Чек-лист оператора при наличии трансграничной передачи</h2> <p>Если в вашей деятельности присутствуют процессы обработки данных с иностранным элементом, необходимо сделать следующее.</p> <h3>Этап № 1. Установите наличие трансграничной передачи</h3> <p>Во всех процессах с иностранным элементом необходимо определить, является ли такая обработка персональных данных трансграничной передачей. Для этого проверьте, получает ли иностранный контрагент доступ к персональным данным и имеется ли при этом факт передачи данных на территорию иностранного государства.</p> <p>Факт передачи устанавливается, если иностранный контрагент фактически получает доступ к персональным данным и действительно может их обрабатывать.</p> <p>Так, например, передача работнику компании данных за рубеж не будет являться трансграничной передачей, если работник является гражданином Российской Федерации: в этом случае не соблюдается условие о передаче данных в адрес иностранного контрагента.</p> <p>Если же все условия трансграничной передачи соблюдаются, переходите к следующему этапу.</p> <h3>Этап № 2. Запросите сведения об иностранных контрагентах</h3> <p>Соберите информацию обо всех иностранных контрагентах, получающих доступ к персональным данным. Согласно требованиям п. 3 ч. 5 ст. 12 <nobr>152-ФЗ</nobr> вам необходимо собрать о них следующие сведения:</p> <ul> <li> ФИО или наименование;</li> <li> номера контактных телефонов;</li> <li> почтовые адреса;</li> <li> адреса электронной почты.</li> </ul> <p>Советуем формировать по каждому контрагенту отдельную анкету, чтобы при запросе Роскомнадзора у вас в наличии был полный перечень необходимых сведений.</p> <h3>Этап № 3. Проверьте перечень стран с адекватной защитой</h3> <p>После определения контрагентов и сбора информации о них необходимо определить объем сведений, который дополнительно придется запросить перед подачей уведомления. Для этого вам понадобится изучить обновленный перечень стран с адекватной защитой и определить, включена ли страна контрагента в указанный перечень.</p> <p>Если страна входит в перечень, вы можете сразу переходить к этапу № 5. Если же государство не признано страной с адекватной защитой и не включено в перечень Роскомнадзора, важно предварительно собрать сведения о правовом регулировании персональных данных в стране иностранного контрагента.</p> <p>Данный этап важен и для определения сроков начала трансграничной передачи. Подход должен быть следующим:</p> <ul> <li> если страна включена в перечень Роскомнадзора, вы вправе осуществить передачу данных в адрес иностранного контрагента сразу после подачи уведомления;</li> <li> если страна не включена в перечень Роскомнадзора, вы можете осуществлять передачу данных только по истечении 10 рабочих дней после подачи уведомления.</li> </ul> <h3>Этап № 4. Соберите сведения о правовом регулировании</h3> <p>При отсутствии страны контрагента в обновленном перечне соберите информацию о правовом регулировании обработки персональных данных. Эти сведения можно запросить у контрагента или найти на сайтах официального опубликования нормативных правовых актов иностранного государства.</p> <p>На данном этапе важно определить:</p> <ul> <li> имеются ли у страны контрагента законы, регулирующие обработку персональных данных;</li> <li> существует ли регуляторный орган или система органов, в чью компетенцию входит контроль за соблюдением законодательства о персональных данных;</li> <li> установлены ли государством санкции за несоблюдение требований в области персональных данных.</li> </ul> <h3>Этап № 5. Изучите сведения об условиях обработки данных контрагентом</h3> <p>В отношении передаваемых персональных данных иностранный контрагент должен принимать меры по их защите. Перед передачей важно выяснить, какие из мер защиты фактически реализованы иностранным контрагентом, а также уточнить условия прекращения обработки персональных данных.</p> <p>Как правило, такие положения нужно предварительно закреплять в договорах и иных документах, определяющих условия сотрудничества с иностранным контрагентом. Если же эти условия отсутствуют в имеющихся документах, запросите их у контрагента, внесите в анкету и закрепите в документах с контрагентом.</p> <h3>Этап № 6. Оцените соблюдение конфиденциальности и безопасности данных</h3> <p>В уведомлении необходимо отразить дату оценки соблюдения иностранным контрагентом конфиденциальности и безопасности персональных данных.</p> <p>Данную оценку лучше оформить в виде документа свободной формы, в котором нужно:</p> <ul> <li> оценить сведения, представленные оператору на дату проведения оценки;</li> <li> зафиксировать результат оценки (иными словами, почему оператор решил, что данные можно безопасно передавать контрагенту).</li> </ul> <p>Документ с результатами оценки не требуется направлять при подаче уведомления, но его формирование поможет зафиксировать исполнение обязанностей оператора.</p> <h3>Этап № 7. Подайте уведомление о трансграничной передаче</h3> <p>По итогам всех этапов вы можете приступать к подаче уведомления. Отразите все необходимые сведения об условиях осуществления трансграничной передачи в соответствии с требованиями ч. 2 ст. 12 <nobr>152-ФЗ</nobr> и в дальнейшем отслеживайте изменение указанных в уведомлении сведений, поскольку именно они подлежат актуализации.</p> <h3>Этап № 8. Осуществите передачу данных в рамках установленных сроков</h3> <p>На третьем этапе вы уже определили, когда можете начать передачу данных в адрес иностранного контрагента и нужно ли соблюдать <nobr>10-дневный</nobr> срок с момента подачи уведомления или можно передавать данные сразу после подачи. Последнее зависит от того, включена ли страна контрагента в перечень Роскомнадзора, как мы обсуждали ранее.</p> <p>При этом важно понимать, что Роскомнадзор вправе отказать в трансграничной передаче или ограничить её. В этом случае уже осуществляемую передачу в страну, включенную в перечень Роскомнадзора, необходимо будет остановить или скорректировать согласно установленным ограничениям. Тогда же важно соблюдать ранее согласованные с контрагентом условия прекращения обработки данных.</p> <p>В отношении стран, не включенных в перечень, Роскомнадзор вправе запросить дополнительную информацию, которую оператор собирал на этапах № 2, 4 и 5. В этом случае <nobr>10-дневный</nobr> срок рассмотрения уведомления приостанавливается до предоставления оператором запрошенных сведений: важно помнить об этом при определении момента начала передачи данных в адрес иностранного контрагента.</p> <h2>Возможность осуществления трансграничной передачи не отменяет требования к локализации</h2> <p>Необходимо корректно понимать требования к каждому из процессов. Так, трансграничная передача касается передачи ранее собранных данных за рубеж в адрес иностранного контрагента. При этом операторы обязаны осуществлять первоначальный сбор персональных данных исключительно с использованием российских баз данных. Данное требование к локализации вытекает из положений ч. 5 ст. 18 <nobr>152-ФЗ.</nobr></p> <p>Для соблюдения всех описанных выше требований используйте следующий подход:</p> <ul> <li> при локализации (первоначальном сборе данных граждан) используйте сервер, расположенный на территории РФ;</li> <li> при трансграничной передаче (передаче ранее собранных данных в адрес иностранного контрагента) подайте предварительное уведомление.</li> </ul> <h2>Заключение</h2> <p>Обновленный перечень закрепил новый подход к определению иностранного государства как страны с адекватной защитой персональных данных. Поэтому при отсутствии страны вашего контрагента в указанном перечне не пренебрегайте сбором информации о правовом регулировании.</p> <p>При этом не забывайте, помимо описанных выше шагов, соблюдать и иные требования, вытекающие из факта трансграничной передачи. Например, обеспечьте наличие законных оснований для обработки данных иностранным контрагентом:</p> <ul> <li> проверьте наличие поручения на обработку персональных данных, если ваш контрагент обрабатывает данные на основании поручения оператора;</li> <li> изучите и обновите политику обработки персональных данных в части упоминания о факте трансграничной передачи;</li> <li> укажите иностранных контрагентов в согласиях ваших пользователей.</li> </ul> <p>Таким образом, трансграничная передача допустима, но с соблюдением нового подхода и выполнением возложенных на оператора требований закона.</p> <p>#IMAGE_235857#</p> Роскомнадзор пересмотрел перечень стран, обеспечивающих адекватную защиту прав субъектов персональных данных, и утвердил … article Камила Мухамеджанова, менеджер по развитию продукта “1ОПД” AI по рецепту: сколько стоит развернуть корпоративный ИИ для бизнеса https://www.itweek.ru/themes/detail.php?ID=235854 Fri, 30 Oct 2026 10:25:20 +0300 <p>Фактом использования искусственного интеллекта в корпоративном секторе сегодня никого не удивишь. Языковые модели помогают сотрудникам быстрее находить информацию, анализировать документы и в конечном счете сокращают затраты времени на рутинные операции. Это повышает производительность отдельных команд и бизнеса в целом. Но для полноценного использования AI недостаточно выбрать подходящую модель и обеспечить ее вычислительными ресурсами. Необходимо также решить, где будут обрабатываться корпоративные данные и кто будет контролировать доступ к ним.</p> <p>Сведения о клиентах и контрактах, техническая документация и внутренние базы знаний могут содержать информацию, которую нельзя передавать за пределы организации. Для многих компаний принципиально важно развернуть AI в закрытом контуре, сохранив контроль над данными и условиями их обработки.</p> <p>В последнее время актуализировался еще один фактор — физическая безопасность IT-инфраструктуры. Инциденты на площадках российских дата-центров показали, что серьезное внешнее воздействие может привести к масштабным нарушениям работы оборудования и сервисов. В таких обстоятельствах сроки восстановления инфраструктуры могут оказаться неопределенными, а последствия для бизнеса — выходить далеко за пределы самого дата-центра.</p> <p>Все это усиливает интерес к собственным вычислительным решениям, которые позволяют разместить AI-систему внутри корпоративного контура и самостоятельно определять условия доступа к данным и оборудованию. При этом аренда вычислительных мощностей и размещение серверов в коммерческих дата-центрах остаются востребованными вариантами: они позволяют быстро стартовать с проектами корпоративного ИИ и избегать крупных первоначальных вложений.</p> <p>В этой статье разберем, как требования к корпоративному ИИ влияют на выбор локальной вычислительной инфраструктуры, сколько могут стоить разные варианты конфигурации и почему наиболее дорогой сервер не всегда оказывается наиболее рациональным решением для бизнеса.</p> <h3>Нейронка, чтобы что?</h3> <p>«Сколько будет стоить сервер с нужной конфигурацией под ИИ?» Этот вопрос интересует практически каждую организацию на первых минутах обсуждения подобных проектов. Будем реалистами: универсального правильного ответа не существует. Чтобы понять, сколько и какого оборудования потребуется для корпоративного AI, сначала нужно определить, что именно этот AI должен делать.</p> <p>Например, производственная компания может использовать AI для самых разных задач: превратить массив внутренних документов в единый источник знаний для сотрудников, ускорить поиск технической информации, автоматизировать обработку заявок и документов, улучшить аналитику и поддержку управленческих решений. AI также может участвовать во взаимодействии с клиентами: например, отвечать на типовые обращения по электронной почте и в чате на сайте, вовлекаться в процедуры обработки заказов. В конечном счете цель внедрения заключается в измеримом результате: экономии рабочего времени, повышении производительности, снижении операционных затрат и более эффективном использовании ресурсов компании.</p> <p>Ни 500 тыс. документов, ни 100 сотрудников сами по себе не определяют конфигурацию AI-сервера. Чтобы понять, какая инфраструктура потребуется, сначала необходимо разобраться, какие задачи будет решать система и как сотрудники будут с ней работать.</p> <p>Реальная ситуация: организация задумалась над созданием AI-интерфейса к корпоративным знаниям. Задача была сформулирована руководителем очень просто: «Хочу, чтобы все мои сотрудники в рамках своих предметных областей могли задавать вопрос нейросети и получать от ИИ ответы на эти вопросы со ссылками на конкретные документы и даже на участки текста». Такой подход называется RAG (Retrieval-Augmented Generation), или генерация с дополнением извлеченной информацией. Он хорош тем, что не требует обучать языковую модель с нуля.</p> <p>Теперь можно определить предполагаемый профиль нагрузки. AI-системой потенциально пользуются все 100 сотрудников, но одновременно с ней работают не более 30 человек. В периоды пиковой нагрузки система должна обрабатывать до 10 запросов в минуту.</p> <p>Такие параметры существенно приближают нас к требованиям к инфраструктуре. Но для выбора оборудования их все-таки маловато. Важно понимать, какую вычислительную работу выполняет модель при каждом запросе, сколько информации получает на вход и насколько быстро должна формировать ответ.</p> <p>Здесь появляются три связанных параметра:</p> <ul> <li> время обработки отдельного запроса;</li> <li> объем работы, который система способна выполнять за единицу времени;</li> <li> количество одновременно обрабатываемых запросов.</li> </ul> <p>Чем больше запросов система обрабатывает параллельно, тем выше потенциальная пропускная способность, но тем сильнее вычислительные ресурсы распределяются между запросами и тем больше времени может потребоваться на обработку каждого из них. Поэтому сервер должен обеспечивать не просто высокую производительность, а нужный баланс между скоростью ответа и количеством одновременно обслуживаемых пользователей.</p> <p>Если расчет нагрузки оказался неверным, пользователь довольно быстро заметит проблему: ответы станут медленнее, а система хуже начнет справляться с запросами. При этом симптомы могут быть одинаковыми, хотя причины различаются. Одной конфигурации может не хватать вычислительной мощности, другой — видеопамяти для параллельных сессий. Именно поэтому серверную конфигурацию нужно подбирать под конкретную нагрузку: размер модели, число одновременных пользователей и требования к скорости ответа. Рассмотрим, как эти требования влияют на выбор оборудования и его стоимость.</p> <h3>От требований к конфигурации</h3> <p>Всегда следует разделять минимальную и рабочую конфигурации.</p> <p>Минимальная конфигурация — набор оборудования, на котором выбранная большая языковая модель технически запускается и способна обслуживать клиентские запросы. В первую очередь здесь нужно обеспечить достаточный объем видеопамяти для размещения модели, ее рабочего контекста и служебных данных. Затем — достаточную вычислительную производительность графического процессора, чтобы система могла формировать ответы с приемлемой скоростью. К этому добавляются центральный процессор, оперативная память и быстрые NVMe-накопители для работы RAG, хранения индексов и корпоративных данных.</p> <p>Такая конфигурация может работать вполне убедительно на тестовом стенде. Один пользователь задает вопрос, получает ответ за несколько секунд. Но есть нюанс. AI в условиях корпоративного применения совершенно точно обслуживает не только единственного пользователя. В течение рабочего дня нагрузка будет меняться: большую часть времени система может быть загружена умеренно, но в отдельные моменты десятки сотрудников одновременно отправят запросы.</p> <p>Если минимальная конфигурация рассчитана практически без запаса, при росте числа одновременных запросов начнут увеличиваться очереди и расти время обработки отдельного запроса. Система формально продолжит работать, но пользователи будут ждать ответа дольше, а пропускная способность всей системы окажется ниже расчетной. Поэтому рабочая конфигурация должна учитывать не только возможность запуска модели, но и реальную эксплуатационную нагрузку.</p> <p>Такая нагрузка может потребовать больше доступной видеопамяти, более производительного графического процессора или увеличения количества видеокарт. Может потребоваться больше оперативной памяти, более быстрые накопители или изменение архитектуры сервера. В зависимости от выбранной модели и режима работы несколько GPU могут использоваться совместно, что предъявляет дополнительные требования к их соединению и к платформе в целом.</p> <p>Таким образом, между конфигурациями существует принципиальная разница. Минимальная конфигурация покажет нижнюю границу инвестиций. Рабочая — сколько действительно потребуется потратить, чтобы обеспечить заданную скорость ответа и необходимое количество одновременных пользователей. Таким образом, выбор конфигурации — это поиск баланса между первоначальными инвестициями, эксплуатационными расходами и требуемой производительностью. Рассмотрим, как эти требования влияют на выбор оборудования и стоимость локального решения.</p> <h3>Считаем деньги</h3> <p>Чтобы сравнение было предметным, вернемся к сценарию, который мы уже упоминали. Организация хочет развернуть языковую модель среднего размера, подключить к ней корпоративные документы через RAG и обеспечить одновременную работу примерно 30 пользователей.</p> <p>Для такого проекта система должна одновременно обрабатывать запросы, удерживать контекст пользовательских сессий и обеспечивать приемлемое время ответа. Именно здесь возникает основной вопрос при выборе оборудования: сколько вычислительных ресурсов потребуется для полноценной работы, а не только для запуска модели?</p> <p>Рассмотрим три конфигурации. Дальнейшее сравнение покажет: самый подходящий для применения вариант оказался далеко не самым дорогим.</p> <p><strong>Минимальная конфигурация: 5,1 млн. рублей</strong>. В основе системы — один ускоритель NVIDIA L40S с 48 Гб видеопамяти. Его дополняют серверный процессор, оперативная память DDR5 ECC, корпоративный NVMe-накопитель и платформа с необходимым запасом по питанию и охлаждению. Этого достаточно, чтобы развернуть модель и обеспечить работу RAG-системы. Но минимальная конфигурация не рассчитана на комфортную одновременную работу 30 пользователей в рассматриваемом сценарии. Видеопамять помимо размещения самой модели нужна для хранения контекста активных сессий. По мере роста числа параллельных запросов система может упереться в доступный объем VRAM, что приведет к снижению пропускной способности и увеличению времени ответа.</p> <p><strong>Рабочая конфигурация: 7,25 млн. рублей</strong>. Следующий вариант предусматривает два ускорителя NVIDIA L40S по 48 Гб каждый, то есть суммарно 96 Гб видеопамяти. Дополнительные ресурсы позволяют разместить модель и обслуживать больше параллельных запросов, а более производительная серверная платформа обеспечивает необходимый запас по питанию и охлаждению. Однако увеличение числа GPU не всегда дает пропорциональный рост производительности. При распределении вычислений между двумя ускорителями обмен данными между ними может стать дополнительным ограничением. У NVIDIA L40S нет NVLink, поэтому межкарточный обмен осуществляется через PCIe. Насколько существенно это повлияет на время ответа, зависит от модели и характера нагрузки.</p> <p><strong>Оптимизированная конфигурация: 6,5 млн. рублей</strong>. В рассматриваемом проекте организация пошла другим путем: вместо двух L40S используется один ускоритель NVIDIA RTX 6000 Blackwell с 96 Гб видеопамяти GDDR7. Такой подход позволяет разместить модель и контекст пользовательских сессий в памяти одного GPU, не распределяя вычисления между двумя отдельными ускорителями. При подходящем программном стеке это устраняет необходимость межкарточного обмена через PCIe и упрощает организацию вычислений.</p> <p>При этом стоимость готового сервера с многоканальной оперативной памятью DDR5 ECC составляет около 6,5 млн. рублей. Это на 750 тыс. рублей меньше стоимости конфигурации с двумя L40S. То есть экономия составляет примерно 10%.</p> <p>Получается, более эффективный подбор оборудования способен дать лучший баланс стоимости и вычислительных возможностей, чем простое наращивание количества ускорителей.</p> <h3>Что важно учитывать при расчетах</h3> <p>Указанные суммы — всего лишь ориентиры для конкретных конфигураций. Финальная цена зависит от стоимости высокопроизводительных компонентов. А на них, в свою очередь, влияют курсы валют, стоимость логистики, доступность оборудования и условия гарантии.</p> <p>Не менее важны характеристики самой нагрузки. Результат будет различаться в зависимости от выбранной языковой модели, длины контекста, режима квантования и требований к скорости ответа. Поэтому возможность запустить модель на сервере еще не означает, что он сможет обеспечить требуемую производительность при 30 одновременных запросах.</p> <p>Именно поэтому конфигурацию следует подбирать не только по цене и объему видеопамяти, но и по целевым показателям системы: времени ответа, пропускной способности и числу одновременно обслуживаемых пользователей.</p> <h3>Есть эффект?</h3> <p>Цена сама по себе ничего не скажет об успешности проекта. Поэтому организация, как правило, переводит вопрос эффективности в более прикладную плоскость: какой экономический смысл это ей дает?</p> <p>Около 30 сотрудников обеспечивают примерно 70% запросов к корпоративному ИИ. Для предварительной оценки организация рассмотрела один из базовых сценариев применения AI — поиск и сопоставление информации. Если каждый из этих сотрудников тратит на такие задачи около 30 минут в день, суммарные затраты составляют 15 человеко-часов ежедневно. Это потенциальная область для повышения эффективности, но фактический результат будет зависеть от того, какую часть этих операций удастся ускорить с помощью AI.</p> <p>Однако поиск информации — лишь один из возможных сценариев применения корпоративного AI. Дополнительный эффект может возникать за счет автоматизации обработки документов и заявок, ускорения аналитики, работы с клиентскими обращениями и оптимизации других бизнес-процессов. Поэтому оценивать экономический потенциал внедрения только по времени, сэкономленному на поиске документов, было бы некорректно: совокупный результат зависит от количества сценариев, в которых AI действительно повышает производительность.</p> <p>Организация ориентируется на улучшение отдельных показателей производительности в диапазоне <nobr>10-20%.</nobr> Но насколько реалистична такая оценка и что показывают результаты внедрения AI в других компаниях?</p> <p>Мы рассмотрели несколько исследований, в которых влияние генеративного ИИ измерялось непосредственно в рабочей среде. В одном из наиболее известных исследований NBER <a href="https://www.nber.org/papers/w31161">анализировалась</a> работа более 5 тыс. сотрудников службы поддержки. Доступ к AI-ассистенту увеличил количество решенных обращений в час в среднем на 15%. При этом эффект оказался неодинаковым: менее опытные сотрудники заметно повысили производительность, тогда как у наиболее опытных прирост был небольшим.</p> <p>Другой крупный эксперимент <a href="https://www.microsoft.com/en-us/worklab/work-trend-index/copilots-earliest-users-teach-us-about-generative-ai-at-work/">провела</a> Microsoft. Участники выполняли набор задач, включавший поиск информации по нескольким источникам, создание текста и подготовку материалов. Пользователи Copilot справлялись со всем набором задач на 29% быстрее. В отдельном эксперименте поиск информации по нескольким источникам занимал в среднем 24 минуты без AI и около 18 минут с AI — экономия составляла примерно 6 минут на одну операцию.</p> <p>Результаты исследований позволяют рассматривать диапазон <nobr>10-20%</nobr> как обоснованную рабочую гипотезу для отдельных процессов, но не как гарантированный результат внедрения. В конкретной компании эффект будет зависеть от характера задач, исходной производительности сотрудников и того, насколько AI интегрирован в рабочий процесс. Масштабирование успешных сценариев на другие процессы создает потенциал для более значительного совокупного результата.</p> <h3>Заключение</h3> <p>Экономический эффект от внедрения AI не всегда выражается в прямом сокращении расходов. Высвободившееся время сотрудников можно направить на выполнение большего объема работы, сокращение сроков, повышение качества обслуживания или решение более сложных задач. Таким образом, AI создает возможности для повышения производительности без обязательного сокращения численности персонала.</p> <p>Первый успешный сценарий внедрения — отправная точка для дальнейшего применения AI в организации. Получив практический опыт, компания может выявлять новые задачи, в которых AI способен дать измеримый результат. Последующие этапы внедрения могут потребовать меньше времени на подготовку. Компания уже понимает, как оценивать бизнес-задачи, определять профиль вычислительной нагрузки и подбирать модели и инфраструктуру. Кроме того, у нее есть опыт эксплуатации собственного вычислительного узла. Это позволяет опираться на уже созданную техническую основу, хотя расширение числа сценариев может потребовать дополнительных вычислительных ресурсов.</p> <p>Чем больше бизнес-процессов компания успешно охватывает с помощью AI, тем выше потенциальный совокупный экономический эффект. Для холдинга масштабирование успешных решений на другие подразделения открывает дополнительные возможности, однако результат тем убедительнее, чем глубже AI интегрирован в рабочие процессы. В этой точке возникает новый вызов — как организации наилучшим образом использовать высвободившиеся ресурсы. Но это, как говорится, совсем другая история.</p> <p>#IMAGE_235855#</p> Фактом использования искусственного интеллекта в корпоративном секторе сегодня никого не удивишь. Языковые модели … article Михаил Васильев, коммерческий директор компании HYPERPC Как продемонстрировать бизнесу ценность данных и ИИ https://www.itweek.ru/themes/detail.php?ID=235853 Fri, 30 Oct 2026 10:11:17 +0300 <p><em>Прежде чем приступать к инициативам в области аналитики, данных и искусственного интеллекта, руководителям отделов данных и аналитики (D&A) необходимо остановиться и убедиться, что они определили и используют бизнес-метрики ценности (</em><em>business</em> <em>value</em> <em>metrics</em><em>,</em><em> BVM), пишет на портале </em><em>InformationWeek</em> <em>Рэй Коллинз, старший директор-аналитик Gartner.</em></p> <p>Количественная оценка и донесение ценности инициатив для бизнеса могут быть сложной задачей для D&A-руководителей, которые называют это одним из трех главных препятствий на пути к успеху своей команды.</p> <p>Это подчеркивает важность определения BVM, которые напрямую связывают операционные инвестиции в данные, аналитику и ИИ с измеримыми результатами для бизнеса. Следуя этим путем, D&A-руководители могут обеспечить приоритетность своих потребностей в рамках всего бизнеса и легче получить финансирование.</p> <h3>Согласование инициатив в области данных, аналитики и ИИ с бизнес-результатами</h3> <p>Одна из главных причин, по которой D&A-руководителям трудно доказать ценность своей работы, заключается в том, что они, как правило, сосредотачиваются на технических показателях, а не на ощутимых результатах для бизнеса. Вместо того чтобы сообщать только о качестве данных или точности моделей, они должны напрямую связывать их со стратегическими целями, такими как снижение оттока клиентов, чтобы явно доказать финансовую и операционную окупаемость инвестиций в данные, аналитику и ИИ.</p> <p>Первым шагом для D&A-руководителей является понимание того, что означает успех для заинтересованных сторон бизнеса. Последние сообщают о своих приоритетах через стратегические планы, годовые отчеты и текущие обсуждения бизнеса. Исходя из этого, D&A-руководители должны установить четкую связь между своей деятельностью в области анализа и обработки данных и конкретными результатами бизнеса.</p> <p>Не каждая D&A-инициатива обеспечит одинаковый уровень влияния на бизнес, поэтому D&A-руководители должны также оценивать и приоритизировать возможности на основе их ожидаемой бизнес-ценности. Согласование инициатив в области данных, аналитики и ИИ с результатами бизнеса переводит разговор с технических показателей на ощутимое влияние на бизнес, создавая более прочную основу для инвестиций, определения приоритетов и долгосрочной поддержки.</p> <h3>Определение BVM</h3> <p>После того, как установлена ​​связь между D&A-инициативами и результатами бизнеса, следующим шагом для D&A-руководителей является определение своих BVM. Эти показатели делают влияние их работы видимым и измеримым. Эффективные BVM создают четкую связь между операционными улучшениями, D&A-инициативами и наиболее важными бизнес-результатами.</p> <p>Чтобы сделать BVM достоверными, D&A-руководители должны установить базовые показатели и целевые результаты. Понимание текущей производительности позволяет создать эталон, по которому можно измерять будущие улучшения, помогая заинтересованным сторонам оценить истинную ценность инициативы и сравнить инвестиции в рамках всего портфеля. Важно иметь четкие определения. Каждый показатель должен иметь бизнес-определение, объясняющее, почему он важен, а также операционное определение, описывающее, как он рассчитывается, измеряется и представляется.</p> <p>Самое главное, D&A-руководители должны сосредоточиться на результатах, а не на деятельности. Реальная ценность достигается благодаря тому, что сэкономленное время реинвестируется для получения дохода, улучшения качества обслуживания клиентов, снижения рисков или продвижения стратегических приоритетов. Наиболее эффективные BVM преобразуют операционные улучшения в измеримые бизнес-результаты, которые заинтересованные стороны могут легко понять и поддержать.</p> <h3>Корректировка BVM при изменении бизнес-факторов</h3> <p>Задача D&A-руководителей — приоритизировать свои инвестиции на основе оценки рисков. Непосредственным преимуществом выявления и измерения BVM и отчетности по ним является более эффективное управление готовностью или возможностями, необходимыми для реализации ожидаемых бизнес-результатов.</p> <p>Готовность описывает состояние возможностей, необходимых для реализации ожидаемых улучшений бизнес-процессов, деятельности, решений, данных, продуктов и услуг, основанных на данных и аналитике. D&A-руководители должны использовать BVM для принятия обоснованных решений по портфелю проектов, например, для определения того, какие инициативы в области данных и ИИ следует финансировать, масштабировать, а какие откладывать или деприоритизировать.</p> <p>Управляя готовностью D&A-возможностей, руководители могут снизить риск того, что инициативы не достигнут желаемого результата.</p> <p>Инициативы следует приоритизировать, используя как показатели ценности, так и показатели осуществимости. Это означает оценку инициатив на основе как их ожидаемой бизнес-ценности, так и способности организации фактически обеспечить эту ценность. Инициативы, демонстрирующие ценность, но не осуществимые в обозримой перспективе, следует помечать как просчитанные риски. Их нужно тщательно расставлять приоритеты, сопоставляя их с высокоценными и высокоосуществимыми инициативами.</p> <p>После оценки бизнес-результатов, рисков и готовности D&A-руководители получают веские основания для приоритизации инициатив, которые обеспечивают баланс между краткосрочными результатами и долгосрочным стратегическим воздействием. Это поможет им гарантировать, что чрезмерные инвестиции в малоэффективную или малоперспективную работу не ограничат возможности для достижения более значительных результатов.</p> <p>В конечном счете, демонстрация бизнес-ценности, которую приносят данные и ИИ, — это непрерывный процесс. D&A-руководителям необходимо постоянно соотносить свои инициативы с бизнес-результатами, определять значимые BVM и корректировать их по мере изменения приоритетов бизнеса. Это позволит им более эффективно добиваться финансирования, укреплять доверие заинтересованных сторон и гарантировать, что инвестиции в данные и ИИ со временем будут приносить измеримую пользу для всей организации.</p> Прежде чем приступать к инициативам в области аналитики, данных и искусственного интеллекта, руководителям отделов … article Выпущена Jmix 3.1: новая версия open-source платформы с ИИ-инструментами https://www.itweek.ru/themes/detail.php?ID=235851 Thu, 29 Oct 2026 19:47:59 +0300 <p>Команда Хоулмонт выпустила новую версию open-source платформы Джеймикс для разработки корпоративных приложений. Релиз 3.1 развивает два основных направления: агентную разработку на базе платформы и встраивание ИИ-функций в приложения на Джеймикс. Изменения</p> <p> затрагивают и процесс разработки, и возможности самих приложений. Часть функциональности, которую раньше разработчики реализовывали вручную, теперь доступна в виде подключаемых компонентов. Кроме того, в новой версии продолжает обновляться технологический стек.</p> <p>Новый инструмент командной строки позволяет создавать проекты без IDE: команды можно вводить вручную в терминале, запускать из скриптов или поручить их выполнение ИИ-агенту. Также при создании проекта через Jmix CLI можно подключить Jmix Agent Toolkit — набор правил и навыков, которые помогают код-агентам следовать паттернам платформы.</p> <p>Функция позволяет по описанию предметной области на естественном языке генерировать начальную динамическую модель данных. После этого разработчик сможет проверить и отредактировать ее. Функция доступна в тестовом режиме, в будущем подход может измениться.</p> <p>Дополнение позволяет встраивать в приложение на Джеймикс чат с ИИ-моделью. Пользователи смогут задавать вопросы в привычном формате, прикреплять файлы, а также делать паузы в работе, не опасаясь, что история диалога не сохранится. Выбор модели при этом остается за командой: можно использовать как публичные, так и локальные LLM.</p> <p>Дополнение сохраняет в черновиках действия, выполненные в окне корпоративного приложения. Например, если пользователь работал над документом, но случайно закрыл вкладку браузера, то изменения не потеряются, их можно будет восстановить при повторном открытии экрана. Раньше действия сохранялись только после нажатия кнопки.</p> Команда Хоулмонт выпустила новую версию open-source платформы Джеймикс для разработки корпоративных приложений. Релиз 3.1 … message Aladdin Enterprise CA 3.0 — новая версия корпоративного центра сертификации компании «Аладдин» https://www.itweek.ru/themes/detail.php?ID=235850 Thu, 29 Oct 2026 19:46:31 +0300 <p>Компания «Аладдин» выпустила новую версию корпоративного центра сертификации Aladdin Enterprise CA 3.0. Она отличается более высокой производительностью, расширенной интеграцией с современными ИТ-средами (включая Kubernetes) и новыми средствами автоматизации, что позволит заказчикам снизить операционные издержки и повысить защищённость ИС. Версия 3.0 доступна для пилотных проектов со 2 ноября 2026 года, начало отгрузок планируется в декабре 2026 года.</p> <p>Среди основных нововведений в Aladdin eCA 3.0:</p> <ul> <li>работа в современных инфраструктурах (Kubernetes и Deckhouse);</li> <li>рост производительности по сравнению с предыдущей версией до 4 раз;</li> <li>автоматизация развертывания SSL-сертификатов (ACME);</li> <li>централизованный сбор событий безопасности и интеграция с SIEM;</li> <li>расширенные возможности администрирования и удобство эксплуатации: поддержка английского языка, интуитивно понятный интерфейс выпуска сертификатов;</li> <li>поддержка РЕД База Данных;</li> <li>расширенные возможности встраивания в существующую ИТ-инфраструктуру заказчика.</li> </ul> <p>Aladdin Enterprise CA является полнофункциональной заменой Microsoft CA, замещающей его без остановки сервисов. Aladdin Enterprise CA 3.0 — первая версия в третьем поколении продукта. Одним из ключевых направлений развития стала работа в современных инфраструктурах (Kubernetes и Deckhouse), что обеспечивает автоматизацию управления, кластеризацию и отказоустойчивость: это критически важно для крупных динамично развивающихся ИТ-ландшафтов (например, в банковском секторе). Также добавлена поддержка РЕД База Данных, расширяющая возможности использования продукта в отечественном программном окружении.</p> <p>В версии 3.0 реализовано централизованное управление журналом безопасности и интеграция с SIEM. Это даёт службам ИБ целостную картину происходящего, ускоряет выявление подозрительной активности и сокращает время реагирования на инциденты. Таким образом, заказчики получают не фрагментарные логи, а управляемый и наблюдаемый контур PKI — это повышает уровень защищённости инфраструктуры.</p> <p>Поддержка протокола ACME позволяет автоматически обслуживать сервисы в Kubernetes и выпускать SSL-сертификаты без ручного вмешательства. При этом в сценариях массового выпуска файловых сертификатов новая версия работает в 4 раза быстрее предыдущей.</p> <p>Aladdin Enterprise CA 3.0 легко интегрируется в существующую ИТ-инфраструктуру заказчиков. Продукт совместим с разнообразными корпоративными средами и платформами, что устраняет барьеры для внедрения, упрощает эксплуатацию в гетерогенных ландшафтах и защищает инвестиции заказчиков в уже используемые технологии: они получают гибкость в выборе компонентов инфраструктуры без привязки к конкретным вендорам.</p> <p>«Развитие Aladdin Enterprise CA направлено на то, чтобы заказчики могли эффективно использовать PKI в современной корпоративной инфраструктуре, сохраняя необходимый уровень безопасности и контроля. Версия 3.0 сейчас проходит сертификацию во ФСТЭК России. В ней мы расширили возможности интеграции с технологическим стеком заказчиков, развили механизмы разграничения полномочий и автоматизации работы с сертификатами, а также существенно повысили производительность. При этом мы сохраняем преемственность продуктовой линейки: пользователи версий 2.x продолжат получать поддержку, исправления ошибок и устранение уязвимостей, а переход на версии 3.x позволит воспользоваться новыми возможностями продукта», — отметил Денис Полушин, руководитель продукта Aladdin eCA, «Аладдин».</p> Компания «Аладдин» выпустила новую версию корпоративного центра сертификации Aladdin Enterprise CA 3.0. Она отличается более … message Исследование GlobalCIO: ИТ-директора ставят на ИИ, но бизнес-эффект получают от автоматизации https://www.itweek.ru/themes/detail.php?ID=235849 Thu, 29 Oct 2026 19:41:15 +0300 <p>Профессиональное ИТ-сообщество Global CIO провело исследование среди ИТ-директоров российских компаний «Приоритеты ИТ-руководителя 2026». Участников опросили, какие ИТ-инициативы дают бизнес-результат, как меняются инвестиционные приоритеты и на каком этапе находится внедрение ИИ.</p> <p>Наибольший измеримый бизнес-эффект за последние два года респонденты связывают с автоматизацией бизнес-процессов — этот вариант выбрали 30% опрошенных. Развитие клиентских сервисов назвали 17%, модернизацию инфраструктуры — 11%. Еще 42% указали другие направления.</p> <p>При росте ИТ-бюджета на 30% дополнительные средства чаще всего направили бы на искусственный интеллект (19%) и кибербезопасность (14%). Автоматизация процессов и управление данными получили по 13%, инфраструктура и ЦОД — 11%. При сокращении бюджета в первую очередь готовы сохранить инфраструктуру (22%) и кибербезопасность (19%). ИИ назвали 13% респондентов.</p> <p>Среди технологий, которые могут повлиять на развитие бизнеса в ближайшие два года, лидируют ИИ-агенты (20%) и сама технология искусственного интеллекта (18%). Далее следуют автоматизация процессов (15%), управление данными (13%) и кибербезопасность (10%).</p> <p>Внедрение ИИ чаще находится на ранних этапах: 46% компаний ведут пилотные проекты, еще 25% изучают возможности. Масштабируют успешные проекты 13%, массово используют ИИ 7%, а 9% пока его не внедряют.</p> <p>Измеримый эффект от ИИ респонденты отмечают в разработке ПО и аналитике — по 16%, документообороте — 11% и Service Desk — 8%. При этом 13% сообщили, что ИИ пока не приносит измеримого эффекта.</p> <p>Главным препятствием для масштабирования ИИ участники исследования назвали неочевидную окупаемость — 20%. Недостаток специалистов отметили 18%, нехватку качественных данных — 15%. Высокая стоимость и незрелость технологий получили по 11%.</p> <p>Результаты показывают, что компании стремятся развивать новые технологии и одновременно поддерживать надежную основу ИТ. При сокращении бюджета в числе первых приоритетов остаются инфраструктура и кибербезопасность. Для масштабирования ИИ компаниям предстоит подтверждать его бизнес-ценность, развивать компетенции и обеспечивать проекты качественными данными.</p> Профессиональное ИТ-сообщество Global CIO провело исследование среди ИТ-директоров российских компаний «Приоритеты … message Масштабное обновление Рутокен База 1.2.8 для администрирования и учета СКЗИ https://www.itweek.ru/themes/detail.php?ID=235848 Thu, 29 Oct 2026 19:39:14 +0300 <p>Компания «Актив» объявила о выпуске новой версии программного комплекса Рутокен База 1.2.8. Обновление выводит систему управления жизненным циклом ключевых носителей на принципиально новый уровень, предлагая ИТ-подразделениям и службам ИБ расширенную функциональность для работы в высоконагруженных и регулируемых средах.</p> <p>Ключевые возможности обновления:</p> <ul> <li>расширенное управление токенами. Администратор может выполнять полный спектр операций с носителями непосредственно из интерфейса: блокировку и разблокировку токенов, создание ключей, а также создавать запрос на сертификат и запись полученных сертификатов на носитель;</li> <li>упрощение взаимодействия с большим количеством ключевых носителей. Реализована возможность подключения любого токена «из коробки». При подключении к ПК администратора вся информация об устройстве автоматически открывается в режиме администрирования — это упрощает первичную настройку и инвентаризацию;</li> <li>пользовательский контроль. Добавлен компонент Tray для взаимодействия с пользователем. Он позволяет контролировать состояние агента и получать оперативную информацию о подключенных токенах;</li> <li>массовые операции. Внедрена поддержка массовых действий над объектами учета, включая массовую выдачу ключей через импорт данных из файла. Это значительно снижает трудозатраты администраторов при выдаче и постановке на учет токенов и сертификатов большого количества сотрудников;</li> <li>учет программных и аппаратных СКЗИ. Существенно расширены возможности учета программных средств криптографической защиты информации (СКЗИ) и СЗИ, а также добавлен учет сертификатов TLS;</li> <li>гибкое управление жизненным циклом. Появилась возможность возврата, отмены постановки на учет и повторной постановки на учет поддерживаемых СКЗИ/СЗИ.</li> </ul> <p>Новая версия Рутокен База 1.2.8 ориентирована на средние и крупные организации, где вопросы централизованного управления КЭП и соответствия требованиям ФСБ России и ФСТЭК России стоят особенно остро. Решение востребовано в финансовом секторе, госструктурах, здравоохранении, образовании, а также на объектах критической инфраструктуры.</p> Компания «Актив» объявила о выпуске новой версии программного комплекса Рутокен База 1.2.8. Обновление выводит систему … message Forrester: между руководителями и сотрудниками вырастет разрыв в ожиданиях относительно ИИ https://www.itweek.ru/themes/detail.php?ID=235847 Thu, 29 Oct 2026 10:08:22 +0300 <p><em>В 2027 г. главным препятствием на пути к получению реальной отдачи от искусственного интеллекта станут растущие расхождения между тем, что, по мнению руководителей, может делать ИИ, и тем, как сотрудники на практике используют его в своей работе, пишет в корпоративном блоге Анджелина Геннис, главный аналитик </em><em>Forrester</em><em>.</em></p> <p>Подобные противоречия в ожиданиях руководства и персонала существовали всегда, но ИИ значительно их усиливает. Возникает глубокая пропасть: с одной стороны — топ-менеджеры, продвигающие концепцию «ИИ-нативной» работы, с другой — рядовые сотрудники, которым приходится сталкиваться с повседневными реалиями внедрения этой технологии. Руководители продолжают повышать ожидания относительно роста эффективности, в то время как сотрудники пытаются освоить инструменты (которые зачастую не оправдывают шумихи вокруг них) и применить их в задачах, для которых еще не выработаны четкие сценарии использования.</p> <p>Руководители, которые не обеспечат полноценное вовлечение людей в этот процесс, не получат ожидаемой окупаемости инвестиций (ROI). Таким образом, 2027 г. станет для лидеров временем принятия ответственности за объединение людей и технологий — только так можно добиться реальных преимуществ от использования ИИ в работе. Ниже представлены три наших прогноза на следующий год.</p> <p><strong>Мониторинг сотрудников с помощью ИИ подавит инициативу у трети персонала. </strong>Практика контроля за работниками существует еще со времен появления первых фабрик — достаточно долго, чтобы ученые успели изучить ее влияние на мотивацию и производительность. Если сотрудники воспринимают такой контроль как инструмент наказания, а не как помощь в достижении успеха, это заметно снижает их готовность проявлять инициативу и экспериментировать — а ведь именно на этом строятся качественное обслуживание клиентов и инновации. ИИ-мониторинг усугубляет этот эффект, поскольку воспринимается как процесс, лишенный человеческого контроля со стороны руководства. Дальновидные лидеры предпочтут избежать этого, взяв на себя ответственность за использование ИИ-мониторинга: они будут применять его открыто и только в тех случаях, когда это действительно помогает сотрудникам лучше справляться со своими задачами.</p> <p><strong>Сотрудники с высоким уровнем «ИИ-интеллекта» (AIQ) получат доступ к более совершенным инструментам, что приведет к разрыву в производительности. </strong>Многие стратегии внедрения ИИ сегодня буксуют: руководители инвестируют в технологии, но не получают желаемых результатов. Согласно исследованию Forrester «State Of AI Survey, 2026», хотя 66% компаний внедряют инструменты ИИ в свои рабочие приложения, лишь 32% отмечают, что это действительно приводит к росту производительности. Несмотря на масштабные инвестиции и заявления о внедрении инноваций на базе ИИ, ощутимого влияния на рост производительности труда пока не наблюдается. Проблема не в самой технологии, а в недостаточном внимании к людям и процессам, необходимым для ее эффективного использования. Чтобы добиться реального повышения производительности с помощью ИИ, следует инвестировать в комплексное обучение сотрудников и применять ИИ для решения конкретных задач, а не для полной замены рабочих мест.</p> <p><strong>Каждое десятое предприятие столкнется с негативной реакцией на внедрение ИИ, которая может перерасти в злонамеренное следование инструкциям. </strong>В настоящее время 18% сотрудников демонстрируют активную отстраненность от работы — это не просто «тихие увольнения», а потенциально деструктивное поведение. Поскольку работодатели продолжают убеждать финансистов в огромном потенциале ИИ, хвастаясь сокращениями штата (уже проведенными или запланированными), некоторые из таких сотрудников не уйдут из компании, а перейдут к тактике злонамеренного следования инструкциям. Каждая десятая крупная компания столкнется с последствиями саботажа: сотрудники будут в точности выполнять указания по использованию ИИ, даже зная, что это неэффективно. Руководителям следует четко разъяснять связь между внедрением ИИ и общими целями компании, прежде чем у сотрудников укрепится подозрение, что то, что выгодно организации, — вредно для них самих.</p> В 2027 г. главным препятствием на пути к получению реальной отдачи от искусственного интеллекта станут … article За что российские компании переплачивают в S3 https://www.itweek.ru/themes/detail.php?ID=235845 Thu, 29 Oct 2026 09:59:17 +0300 <p><em>За первые три квартала 2026 года мы провели переговоры с более чем ста российскими компаниями, использующими объектное хранилище S3. У большинства запрос одинаковый: тариф не менялся, объем полезных данных тот же, а счет вырос. Разберем, где именно прячутся расходы и почему первоначальный расчет расходится с реальным счетом.</em></p> <h3>Почему тариф не менялся, а счет вырос</h3> <p>Когда компания выбирает S3, главный ориентир — цена гигабайта в месяц. По этому параметру сравниваются провайдеры и строится бюджет. Пока данные размещены без движения, такой расчет точен. Расхождение начинается, когда хранилище начинают активно использовать.</p> <p>Счет за S3 складывается не только из объема хранения. В него также входят операции с объектами и исходящий трафик. Обращение к хранилищу может тарифицироваться отдельно или входить в лимит тарифа, и чем активнее приложение работает с данными, тем заметнее эти статьи расходов. Место в хранилище при этом может почти не меняться, а в счете появляются строки, которых в первоначальном расчете не было.</p> <p>С неожиданной платой за исходящий трафик сталкиваются единицы. Чаще причина роста счета — другая ситуация: компания выбирала тариф только по цене хранения и не обратила внимания на то, что тарифный план включает ограниченное количество запросов. Когда реальный объем запросов оказывался на порядок больше включенного лимита, счет резко вырастал. Поэтому до выбора тарифа стоит понять не только объем данных, но и то, как приложение с ними фактически работает: именно это в конечном счете и определяет итоговый счет.</p> <h3>Откуда берутся 30 Тб, когда данных было 10</h3> <p>Версионирование в S3 сохраняет предыдущие копии файлов. Функция полезная: она позволяет откатиться к нужной версии, если что-то пошло не так. Но срок хранения этих версий редко определяют заранее, и именно здесь начинается проблема. Новые версии копятся, старые остаются, и через несколько месяцев компания обнаруживает, что платит за данные, о существовании которых давно забыла.</p> <p>Например, компания хранит 10 Тб видеофайлов. После изменения настроек обработки обновляет набор дважды. Пользователь видит 10 Тб актуальных материалов, именно столько нужно бизнесу. Но внутри хранилища при включенном версионировании и без настроенной очистки остаются все три набора, то есть уже 30 Тб. Счет вырастает втрое, хотя объем полезных данных не изменился.</p> <p>Версии файлов составляют лишь часть проблемы. После диагностики приложения в хранилище остаются подробные логи. После завершения аналитического проекта там накапливаются временные выгрузки. Каждый из этих массивов появился по делу, но необходимость его дальнейшего хранения редко пересматривают. Данных становится больше, хранилище масштабируется само по себе, и расхождение между тем, за что платят, и тем, что реально нужно, нарастает незаметно. В собственной инфраструктуре переполненный диск обычно сигнализирует о проблеме сразу. В S3 объем хранилища масштабируется, поэтому без настроенных уведомлений такого сигнала может не быть — счет просто продолжает расти.</p> <p>Для автоматической очистки в S3 предусмотрены правила жизненного цикла: можно настроить удаление незавершенных загрузок старше месяца или ограничить число хранимых версий одного файла, например тремя. Хранилище будет удалять лишнее самостоятельно. Но настраивают эти правила заранее редко. По общим наблюдениям, около 90% компаний хранят больше данных, чем реально используют, и разбираться с этим начинают только тогда, когда оплачиваемое место заканчивается и в работе приложений появляются ошибки.</p> <p>Показательный пример: одна компания обнаружила, что хранила в 10 раз больше данных, чем использовала. Команда включила версионирование, рассчитывая на автоматическую дедупликацию — которой в S3 нет. Хранилище сохраняло новую версию при каждой перезаписи файла. Объем вырос в 10 раз, место закончилось, и только тогда ситуацию начали разбирать. Совет здесь один: включать версионирование только там, где оно действительно необходимо, и понимать, что каждая версия — это отдельный объект, занимающий свое место. Удалять данные подряд при этом рискованно: среди старых копий может оказаться единственная версия, пригодная для восстановления. Поэтому сначала у каждого крупного массива стоит найти владельца, который определит, зачем он хранится и как долго, и только после этого настраивать очистку.</p> <h3>Как дешевый класс хранения становится дорогим</h3> <p>Перевод редко используемых данных в более дешевый класс хранения оправдан, если данные читают эпизодически и объем достаточно велик. Но у этого решения есть несколько условий, которые легко упустить при выборе тарифа.</p> <p>Низкая цена размещения нередко сочетается с более дорогим чтением или отдельной платой за извлечение. Для некоторых классов действует минимальный оплачиваемый срок хранения: удалить файл раньше разрешено, но платить придется за весь период. Есть и минимальный оплачиваемый размер объекта — небольшой временный файл тарифицируется как более крупный. В итоге дешевый класс может оказаться невыгодным именно для той нагрузки, под которую его выбирали. Холодные классы хранения на российском рынке используются относительно редко, и именно поэтому их условия чаще всего остаются неизученными до момента, когда они уже повлияли на счет.</p> <p>Отдельного внимания заслуживает скорость получения данных из холодного класса — она напрямую влияет на то, подходит ли такой класс для резервных копий. Холодные классы бывают двух типов: одни дают прямой доступ, другие требуют предварительного восстановления из архива. Даже при прямом доступе передача большого массива небыстрая: выгрузка 100 Тб по каналу 1 Гбит/с потребует около 9,3 суток непрерывной работы. Для резервной копии скачивание составляет лишь часть пути: нужно еще распаковать данные, восстановить базу и запустить приложение. Если бизнес допускает четыре часа простоя, дешевое размещение не компенсирует многодневное восстановление. Важный момент: скорость отдачи данных у большинства холодных классов сопоставима с горячим хранением. Разница не в скорости, а в стоимости каждого запроса. Холодный класс выгоден ровно до тех пор, пока данные лежат без движения. Как только к ним начинают обращаться регулярно, стоимость запросов может перекрыть всю экономию от дешевого размещения. Класс стоит выбирать под требования конкретной системы, а не по строке в прайсе.</p> <h3>Когда расходы выходят из-под контроля</h3> <p>Управляемый счет — не тот, что не меняется каждый месяц. Управляемый — тот, по которому компания понимает причины изменения расходов и видит риск выхода за бюджет до получения счета, а не после. Полный расчет стоимости эксплуатации S3 с учетом хранения, операций, трафика и сценариев восстановления сегодня запрашивают практически все компании на этапе переговоров с провайдером. Рынок в этом плане заметно повзрослел по сравнению с <nobr>2024-25 годами.</nobr> Но понимание полной стоимости при выборе провайдера и контроль расходов в процессе эксплуатации — разные вещи. Второго, как правило, нет.</p> <p>Выстроить этот контроль помогает политика ревизии данных. Без назначенного владельца данных и зафиксированной даты следующей проверки ревизия остается разовой акцией. Через полгода ситуация повторяется. Чтобы этого не происходило, контроль расходов должен быть встроен в регулярный процесс: пороговые уведомления на рост потребления, ответственный за каждое уведомление и плановые ревизии состава хранилища. Отдельный тренд, заметный в 2026 году: крупные компании всё чаще запрашивают расчет хранения больших объемов — от 1 до 3 Пб — и сопоставляют стоимость облачного хранения с собственной инфраструктурой. При таких объемах они считают не только цену гигабайта, но и совокупную стоимость владения: затраты на оборудование, резервирование, эксплуатацию, персонал, электроэнергию и требования к доступности. Это показывает, что рынок все чаще принимает решение о модели хранения на основе полной экономики, а не отдельной ставки за хранение.</p> <h3>Что проверить, если счет оказался выше ожидаемого</h3> <p>За два часа нельзя провести полный аудит большого хранилища, но можно найти то, что стоит разобрать в первую очередь. Понадобятся детализация последнего счета, отчет о составе хранилища и настройки сроков хранения. Удобнее начать с одного крупного проекта: связать расходы с конкретным приложением и найти человека, который за него отвечает.</p> <p>Первый шаг — сопоставить оплаченный объем с объемом актуальных данных. Если приложение использует 10 Тб, а в счете существенно больше, смотрим прежние версии, дополнительные копии и временные массивы, проверяем правила очистки и когда они фактически выполнялись. Затем разбираем остальные строки счета: какое приложение и куда передавало данные, какие операции дали основной вклад. Рост числа клиентов и ошибка в архитектуре приложения могут дать одинаковое увеличение суммы, но потребуют совершенно разных действий. Наконец, стоит проверить условия массовой выгрузки и то, сколько реально займет восстановление системы на полном объеме — именно это чаще всего оказывается неожиданностью.</p> <p>Если же предстоит выбор нового провайдера, то ключевых вопроса три. Из чего складывается цена хранения и какие классы доступны. Как организовано резервирование данных и какие методы S3 API поддерживаются — неполная или нестандартная реализация создаст проблемы при интеграции с приложениями, использующими S3 API.</p> <p>#IMAGE_235846#</p> За первые три квартала 2026 года мы провели переговоры с более чем ста российскими компаниями, использующими … article Тимур Чубарин, генеральный директор mt cloud