https://www.itweek.ru Издание itWeek (до 2018 года — PC Week) на портале и на страницах бумажного номера информирует читателей об актуальных информационных и коммуникационных технологиях, продуктах и решениях и опыте развития цифровой экономики и цифровой трансформации предприятий и организаций всех масштабов и отраслей. Издание рассказывает о важнейших событиях отечественного и мирового рынка ИКТ и анализирует тенденции развития ИКТ-индустрии. https://www.itweek.ru/images/itweek/logo-100x40.gif https://www.itweek.ru https://www.itweek.ru/themes/detail.php?ID=235783 Wed, 21 Oct 2026 15:34:02 +0300 <p>Кибериспытания в 2026 году стали одной из наиболее востребованных услуг по информационной безопасности. По оценке специалистов «Кросстех», порядка 80% ИБ-команд заказчиков в полной мере не справляются с противодействием команде атакующих.</p> <p>Неудачей по результатам Red Teaming считается нулевая или околонулевая детектируемость, когда защищающиеся не выявляют активность в инфраструктуре и позволяют пентестерам реализовывать сценарии, приводящие к недопустимым событиям. К признакам неэффективной работы команды защиты также относятся несвоевременное реагирование на инциденты, отсутствие скоординированных действий, а также применение мер реагирования, приводящих к нарушению работы критически важных сервисов. При этом сам факт проникновения не всегда считается неудачей ИБ-команды, так как вредоносные действия могли быть реализованы не из-за ошибок, а из-за архитектурных особенностей инфраструктуры компании.</p> <p>Чаще всего синие команды сталкиваются с трудностями при распознавании скрытых и бесшумных атак с использованием легитимных инструментов. Дополнительные сложности возникают при корреляции событий из большого количества разных источников, из-за ошибок в анализе данных и задержек при выявлении взаимосвязанных действий: защитникам сложно своевременно обнаружить развивающийся инцидент. Еще один вызов для команд — высокая нагрузка на системы мониторинга из-за большого количества ложных срабатываний, на фоне которых реальная угроза может остаться незамеченной.</p> <p>Отдельным вектором атак, который зачастую позволяет красной команде достигать поставленных целей, остается социальная инженерия. ИБ-команда не может вовремя зафиксировать факт компрометации учетных данных на раннем этапе, вследствие чего атакующие получают дополнительное время для развития атаки и продвижения по инфраструктуре.</p> <p>При этом, эксперты по анализу защищенности «Кросстех» указывают, что уровень подготовки ИБ-команд постепенно растет — среди команд, которые проходят повторные кибериспытания, порядка 50% улучшают свои показатели. Это связано как с развитием компетенций специалистов за счет обучения и привлечения новых сотрудников, так и с совершенствованием технических и организационных процессов: настройкой сбора и корреляции событий, расширением покрытия средствами мониторинга и повышением качества выявления атак.</p> <p>«Киберучения и кибериспытания крайне востребованы, потому что помогают увидеть реальный уровень готовности ИБ-команд и эффективности работы системы информационной безопасности у заказчика. Важно понимать, что если синие и допустили проникновение и реализацию недопустимого события, это не означает их полную неготовность к атаке. Важно учитывать, что уровень навыков профессиональных пентестеров значительно выше, чем средний уровень хакеров, особенно в последнее время с учетом снижение порога входа в киберпреступную деятельность из-за искусственного интеллекта и распространения платформ Cybercrime-as-a-Service», — отметила Анастасия Мельникова, руководитель департамента оценки защищенности «Кросстех».</p> Кибериспытания в 2026 году стали одной из наиболее востребованных услуг по информационной безопасности … message https://www.itweek.ru/themes/detail.php?ID=235782 Wed, 21 Oct 2026 15:33:08 +0300 <p>Компания «Хи-Квадрат» реализовала в платформе XSQUARE поддержку СУБД MySQL — одной из наиболее распространенных баз данных в мире. Ранее с MySQL не работала ни одна из российских low-code-платформ. Теперь компании, в том числе использующие эту СУБД, могут разрабатывать сайты и корпоративные приложения на стеке, аналогичном международному стандарту LAMP, где прикладной слой обеспечивает отечественная платформа.</p> <p>LAMP — это связка из операционной системы Linux, веб-сервера Apache, базы данных MySQL и языка PHP. Все четыре компонента бесплатны и открыты, поэтому собрать на них работающий сайт или сервис могла компания любого размера, не покупая лицензий. До середины <nobr>2010-х</nobr> такая связка оставалась фактическим стандартом веб-разработки — на ней построена значительная часть публичных сайтов и клиентских личных кабинетов, созданных до <nobr>2010–2015 годов.</nobr> Многие из этих систем эксплуатируются до сих пор. </p> <p>В стеке на базе XSQUARE каждому элементу классической связки соответствует своя альтернатива. Операционной системой выступает Debian, вместо веб-сервера Apache используется NGINX, базы данных MySQL — MariaDB, а прикладного слоя на PHP — сама платформа XSQUARE. Первые компоненты остаются международными открытыми продуктами, российским в этой конструкции является прикладной слой — уровень, на котором выстраивается бизнес-логика.</p> <p>Переход на отечественный прикладной слой позволяет бизнесу сократить затраты на разработку. В классическом стеке LAMP разработчику необходимо владеть несколькими технологиями сразу: PHP на стороне сервера, JavaScript на стороне клиента и языком запросов SQL. На XSQUARE достаточно знания SQL, а сама разработка ведется преимущественно визуальными средствами, без ручного написания кода. По расчетам компании, задача, для которой на LAMP требуется команда из трех разработчиков, закрывается силами одного, а с учетом скорости разработки стоимость сопоставимого объема работ снижается более чем на 80%.</p> <p>Воспользоваться этим преимуществом до сих пор не могли компании, которые использовали MySQL, поскольку для замены прикладного слоя требовалась платформа, совместимая с этой СУБД. По данным аналитического сервиса 6sense, MySQL занимает первое место среди реляционных СУБД по числу использующих ее компаний — то есть речь шла о значительной части бизнеса. Поддержка MySQL платформой XSQUARE снимает это ограничение. Компании могут перейти на новый технологический стек, начиная с прикладного ПО, и затем постепенно переносить данные в новую СУБД. </p> <p>Целевой базой данных в стеке «Хи-Квадрат» выступает MariaDB — форк MySQL, созданный командой его основателей. Технически это тот же MySQL, но полностью открытый и без коммерческой составляющей, тогда как MySQL принадлежит корпорации Oracle и, несмотря на открытую версию, развивается в первую очередь как коммерческий enterprise-продукт. </p> <p>«Мировой стек веб-разработки долгое время держался на связке открытых компонентов и одного языка программирования. На российском рынке отечественной альтернативы прикладному слою этого стека не было — сейчас она появилась. Наша платформа позволяет создавать внутренние корпоративные системы, публичные сайты, а также работать с MySQL. По сути, мы собрали отечественный аналог LAMP для тех же задач», — подчеркнул технический директор «Хи-Квадрат» Константин Ващенков. </p> Компания «Хи-Квадрат» реализовала в платформе XSQUARE поддержку СУБД MySQL — одной из наиболее распространенных … message https://www.itweek.ru/themes/detail.php?ID=235781 Wed, 21 Oct 2026 15:32:12 +0300 <p>Сбер представил GreenWAM — модель искусственного интеллекта, которая умеет формировать команды для робота и предсказывать, как изменится окружающая сцена после его движений. Разработка объединяет две способности: моделирование происходящего и управление действиями. Её проверили в виртуальных средах и на человекоподобном роботе Грине.</p> <p>GreenWAM продолжает направление исследований Сбера в области искусственного интеллекта для роботов, к которому относится и Green-VLA. В новой работе акцент сделан на предсказании последствий действий: модель одновременно учится управлять роботом при выполнении задания и предсказывать, как изменится мир в результате его действий. И в прогнозе, и в управлении GreenWAM показала результаты на уровне ведущих мировых разработок, причём одна способность усиливает другую.</p> <p>Эксперты Сбера обучили GreenWAM на данных 20 семейств роботов — от двуруких манипуляторов до антропоморфных роботов с кистями. Для этого действия всех роботов описали в едином представлении, а в архитектуру добавили отдельный модуль, отвечающий за выбор действий.</p> <p>По заданным действиям робота GreenWAM способна предсказать до минуты видео. В международном тесте WorldArena 1.0 модель показала второй результат среди 128 моделей рейтинга по сходству прогноза с реальной записью и точнее воспроизвела геометрию сцены, чем модели мира NVIDIA, Стэнфордского университета и AgiBot.</p> <p>В управлении роботом GreenWAM выступает на уровне лучших мировых моделей и опережает большинство из них, включая π0.5 от Physical Intelligence. В тесте RoboTwin 2.0 доля успешно выполненных задач составила 67,5% против 58,4% у π0.5, а в знакомых для модели условиях — 87%: выше этого результата в официальном рейтинге лишь две модели. В тесте LIBERO-plus, где у робота меняют освещение, положение камер, фон и формулировку команды, GreenWAM без дополнительного обучения выполнила 86,8% задач — больше, чем π0.5 и аналогичные модели NVIDIA и AgiBot.</p> <p>Модель также испытали на человекоподобном роботе Грине, которого создал Сбер. По сравнению с моделью NVIDIA Cosmos 3 Edge, обученной на тех же данных, доля успешно выполненных задач выросла с 88,9% до 95,6% в знакомых для модели условиях. В новых условиях этот показатель повысился с 80% до 84%.</p> <p>Эксперименты показали, что две способности модели усиливают друг друга. Обучение на данных роботов сделало прогноз модели точнее и одновременно повысило долю успешно выполненных задач — как в виртуальных тестах, так и на реальном роботе. А если при обучении управлению сохранить у модели умение предсказывать изменения мира, она заметно чаще справляется с задачами в незнакомых условиях. Большинство ошибок в таких условиях возникает, когда модель неверно представляет себе изменившуюся сцену.</p> <p>Для работы в реальном времени разработчики создали ускоренную версию модели. Она работает в 12,3 раза быстрее исходной, а доля успешно выполненных задач на роботе при этом снизилась лишь с 95,6% до 91,1%. Это важно, когда робот должен быстро реагировать на изменения обстановки.</p> <p>Андрей Белевцев, старший вице-президент, руководитель блока «Технологическое развитие» Сбербанка, отметил: «Для практического применения роботов искусственный интеллект должен распознавать окружающие объекты, выполнять команды и прогнозировать последствия своих действий. Особенно это важно в меняющихся условиях, когда роботу нужно оценивать новую обстановку и корректировать свои движения. В GreenWAM мы объединили эти возможности в одной модели. Дополнительное обучение на робототехнических данных помогло улучшить и прогнозирование, и качество управления. Результаты испытаний показывают, что такой подход эффективен не только в виртуальной среде, но и при управлении реальным роботом».</p> Сбер представил GreenWAM — модель искусственного интеллекта, которая умеет формировать команды для робота … message https://www.itweek.ru/themes/detail.php?ID=235780 Wed, 21 Oct 2026 15:30:35 +0300 <p>Компания «Лаборатория Виртуализации» выпустила версию 3.1.0 платформы Inscale — российского решения для серверной виртуализации и инфраструктуры виртуальных рабочих столов (VDI). В релизе четыре крупных блока: отказоустойчивые хранилища Fibre Channel, встроенное управление сертификатами, оверлейные сети VXLAN и веб-версия панели управления.</p> <p>Хранилища Fibre Channel с резервированием путей. Платформа распознаёт несколько физических подключений к одному FC LUN и объединяет их в одно отказоустойчивое multipath-устройство. Хранилища типа FC-multipath создаются из интерфейса, включая монтирование блочных устройств и развёртывание файловой системы. Состояние дисков и путей непрерывно опрашивается на каждом сервере кластера, а при сбое подключение восстанавливается автоматически или вручную через инструмент Datastore Doctor.</p> <p>Встроенная инфраструктура открытых ключей. При развёртывании создаётся корневой сертификат инсталляции, сертификаты узлов выпускаются автоматически при добавлении сервера в кластер и удаляются при его выводе. Сертификаты обновляются до истечения срока действия без участия администратора. Для шлюзов подключения выпускаются персональные сертификаты с привязкой к сетевым адресам.</p> <p>Оверлейные сети VXLAN. Администратор создаёт подсети с произвольным идентификатором VNI и настраиваемым MTU, назначает интерфейсы серверов в качестве VTEP, а туннели и правила OpenFlow формируются автоматически при подключении групп портов. Поддерживается взаимодействие с внешним сетевым оборудованием и сторонними VTEP, а служебные интерфейсы серверов можно размещать в VXLAN-сетях для изоляции технологического трафика.</p> <p>Веб-версия панели управления. Управление виртуализацией доступно через стандартный браузер по HTTPS, без установки отдельного приложения администратора.</p> <p>Обновлён клиент VDI: состояние клавиш NumLock и CapsLock синхронизируется с виртуальной машиной, комбинация Ctrl+Alt+Ins передаётся внутрь машины как Ctrl+Alt+Del, кнопки панели инструментов получили подписи, клиент запоминает размер и положение окна. В панели администратора появился поиск по пользователям, а ресурсы, на которые у пользователя нет прав, больше не показываются в списках и навигации. Закрыты 24 ошибки в панели администратора, виджетах, средстве просмотра рабочих столов, синхронизации каталога и работе RADIUS со шлюзами.</p> <p>Обновление устанавливается через Центр обновлений платформы. Полный список изменений: https://docs.inscale.ru/rn-2026/ . Новость на сайте разработчика: https://inscale.ru/inscale-3-1-0/</p> <p>Inscale — платформа серверной виртуализации и VDI на ядре KVM с собственным протоколом доставки рабочего стола. Гипервизор устанавливается на «голое железо», серверы и рабочие места управляются из единой консоли. Платформа применяется для замещения VMware, Citrix и Microsoft Hyper-V и поставляется через сеть авторизованных партнёров и дистрибьюторов.</p> Компания «Лаборатория Виртуализации» выпустила версию 3.1.0 платформы Inscale — российского решения для серверной … message https://www.itweek.ru/themes/detail.php?ID=235775 Wed, 21 Oct 2026 11:51:36 +0300 <p><em>Команды, создающие платформу разработки с нуля, гораздо чаще сообщают об отсутствии четкой стратегии. Поскольку искусственный интеллект упрощает создание платформы, обоснование подхода имеет большее значение, чем когда-либо, пишет на портале The New Stack Шарлотта Флеминг, исследователь индустрии разработки в Octopus Deploy.</em></p> <p>Выбор между созданием и покупкой обычно рассматривается как инженерный компромисс, где время разработчиков сопоставляется с затратами на интеграцию и миграцию, а также с контролем и бременем обслуживания индивидуальной сборки. Когда мы готовили <a href="https://i.octopus.com/whitepapers/2026-future-of-platform-engineering.pdf">отчет</a> «2026 Future of Platform Engineering», мы не пытались разрешить этот компромисс; мы пытались выяснить, раскрывают ли решения о выборе поставщиков функций платформы что-либо о команде, работающей над платформой. Оказывается, раскрывают. На основе ответов 379 специалистов по платформам мы обнаружили, что команды, преимущественно создающие платформу с нуля, реже имеют четкую стратегию и достигают меньшего количества целей, поставленных перед платформой.</p> <p>Этот выбор значительно изменился с появлением ИИ. Агенты сделали создание платформы проще, чем когда-либо; внутренний инструмент, на создание которого раньше уходили месяцы, теперь можно собрать за один день. Но ИИ избавляет от необходимости писать код, а не от работы по его управлению. Поддержка, обновления и контроль, связанные с функцией, созданной с нуля, остаются, в то время как объем изменений, проходящих через конвейер, увеличивается. Это делает вопрос «создать или купить» более актуальным, чем когда-либо.</p> <p>Мы спросили платформенные команды, как они поддерживают каждую функцию, которой владеют: созданную с нуля, созданную на основе существующего шаблона или приобретенную в качестве базового инструмента. Команды, чей основной подход — создание с нуля, гораздо чаще сообщают об отсутствии четкой стратегии для своей платформы. Эта взаимосвязь выражена ярко, однако ситуация не сводится к простой формуле: «разработка с нуля означает отсутствие плана».</p> <h3>Большинство команд покупают и выбирают осознанно</h3> <p>Мы обнаружили, что использование базового инструмента является наиболее распространенным среди функций, которыми владеют платформенные команды,: 51,3% респондентов заявили, что это их основной подход, далее следуют создание на основе существующего шаблона (31,2%) и создание с нуля (17,5%). Высокоэффективные команды чаще используют инструменты (58,8%), чем создают решения на основе шаблонов (47,8%) или с нуля (33,3%). Это может отражать более широкую тенденцию достижения зрелости: по мере того, как архитектурные решения в области платформенной инженерии становятся более четкими, команды все чаще стандартизируют инструменты, а не поддерживают собственные. Дэвид Туит <a href="https://roadie.io/blog/platform-engineering-in-2026-why-diy-is-dead/">описал</a> эту альтернативу как «ловушку создать или купить», когда команды, вынужденные поддерживать пользовательские интерфейсы, тратят от 6 до 18 месяцев на обновления и операционные издержки вместо того, чтобы приносить пользу.</p> <p>#IMAGE_235776#</p> <p>Исключения — вот где начинается самое интересное. Локальные среды разработки, проекты, создаваемые в один клик, и временные (эфемерные) среды чаще используют шаблоны, чем инструменты, поскольку они привязаны к определенному технологическому стеку и «золотым путям», которые редко предоставляют готовые инструменты. Временные среды заслуживают внимания, поскольку они также показывают, где ИИ хорошо себя зарекомендовал. Команды, чьи платформы предоставляют такие возможности, гораздо чаще сообщали о положительном влиянии ИИ на скорость и стабильность разработки ПО; то же самое касалось покрытия кода и контроля затрат. Среди команд, сообщивших об исключительно положительном эффекте, более трех четвертей имели временные среды разработки.</p> <p>Эта взаимосвязь, вероятно, отражает скорее особенности платформы, чем саму функцию. Команды с временными средами разработки, как правило, работают на широких платформах с различными возможностями автоматизированной разработки, и эта широта сама по себе коррелирует с положительным влиянием ИИ на разработку. Таким образом, временные среды разработки могут быть признаком достаточно зрелой платформы, способной поглощать объем и изменения, генерируемые ИИ, без потери стабильности. Это согласуется с результатами отчета DORA «2025 State of AI-assisted Software Development», согласно которым выгоды для организаций от ИИ зависят от качества платформы: сильные платформы усиливают эффект, а более слабые — ослабляют его.</p> <p>#IMAGE_235777#</p> <p>Функции, которые нарушают эту закономерность, отражают скорее соответствие шаблону, чем нежелание покупать, и доводы, стоящие за этими решениями, подтверждают это. Когда респондентов попросили объяснить логику выбора между созданием и покупкой, наиболее распространенным ответом был анализ затрат и выгод (29,6%), за которым следовали предпочтение открытого исходного кода (28,6%), оценка соответствия требованиям (22,4%), предпочтение коммерческих инструментов (22,4%) и разработка для обеспечения ключевой дифференциации (16,3%). Как резюмировал один из респондентов: «Создавайте то, что делает вас уникальными, покупайте или адаптируйте то, что является стандартом, и всегда учитывайте долгосрочные затраты и привязку к поставщику». Это та же центральная идея, что и в предметно-ориентированном проектировании, которое выделяет основную область, где заказная разработка создает конкурентное преимущество, от вспомогательных и общих областей, где она в основном добавляет сложность и обслуживание тому, что можно было бы купить.</p> <p>#IMAGE_235778#</p> <h3>Подход «создание с нуля»</h3> <p>Учитывая, насколько взвешенно большинство команд подходит к выбору, вопрос формирования стратегии представляет особый интерес. Если классифицировать команды по преобладающему методу, то те, кто создает решения с нуля, примерно в 3,5 раза чаще называют препятствием отсутствие четкой стратегии (57,9%), чем команды, использующие шаблоны (15,6%) или готовые базовые инструменты (16,7%).</p> <p>Здесь также прослеживается связь с использованием ИИ: команды, предпочитающие создание с нуля, чаще применяют ИИ (умеренно или активно) для модернизации унаследованных систем и миграции на другие языки программирования. Налицо четкая закономерность: именно создатели собственных решений активнее всего полагаются на ИИ при их последующем сопровождении. Дело не в том, что они в целом используют ИИ чаще: показатели внедрения, реального влияния и ожидаемых результатов у них такие же, как и у остальных. Разница заключается именно в задачах, возникающих после создания кастомного функционала.</p> <p>#IMAGE_235779#</p> <h3> Сначала создание, решение — потом </h3> <p>Одно из возможных объяснений таково: сначала определяется стратегия, а затем принимается решение о покупке или создании. У команды без четкого вектора развития нет оснований для выбора готового продукта, поэтому она по умолчанию выбирает путь создания. Другая точка зрения гласит, что создание и есть стратегия, а не признак ее отсутствия. Процесс создания помогает выявить проблему и продемонстрировать прогресс еще до того, как команда окончательно определится с назначением платформы.</p> <p>Это интересная трактовка, однако имеющиеся данные не позволяют однозначно сказать, какой подход верен. В <a href="https://www.cio.com/article/196094/an-introduction-to-wardley-value-chain-mapping.html">работе</a> Саймона Уордли, посвященной картированию (mapping), описывается схожая закономерность: команды, не осведомленные о существующих инструментах, склонны создавать собственные решения для проблем, которые уже были более эффективно решены другими.</p> <p>С появлением ИИ разрыв между возникновением идеи и получением работающего инструмента практически исчез. Теперь ИИ-агент может создать специализированный инструмент для управления инцидентами еще до того, как кто-либо вообще задастся вопросом о его необходимости. Создавать стало проще, но вот поддерживать созданные решения — нет. Исследование DORA объясняет, почему это важно: качественные платформы предоставляют определенные возможности и одновременно задают границы их использования — и в условиях разработки с применением ИИ эти границы могут играть решающую роль. В готовые инструменты такие ограничения уже заложены, тогда как платформа, собранная из отдельных компонентов, обладает лишь теми ограничениями, которые кто-то догадался предусмотреть.</p> <p>В любом случае эта закономерность сохраняется. Проблема не в самом создании с нуля. Стратегический просчет возникает тогда, когда создание с нуля выбирается по умолчанию, без веских на то оснований.</p> <h3>Более важный вопрос, чем «создавать или покупать»</h3> <p>Речь не идет о том, чтобы покупать абсолютно всё: мы выяснили, что некоторые функции необходимо создавать с учетом специфики конкретной организации. Важен осознанный подход к покупке. Если команда создает решение с нуля, на это должна быть причина. Когда же команды приобретают готовый инструмент, причина обычно очевидна: практически все покупают решения для четко определенных компонентов платформы, и по мере того, как ИИ-агенты пишут всё больше кода, ценность инструментов, эффективно решающих подобные задачи, только возрастает.</p> Команды, создающие платформу разработки с нуля, гораздо чаще сообщают об отсутствии четкой стратегии. Поскольку … article https://www.itweek.ru/themes/detail.php?ID=235773 Wed, 21 Oct 2026 11:13:51 +0300 <p>Обновление платформы виртуализации часто планируют как небольшую аварию: назначают ночное окно, предупреждают пользователей и надеются к утру вернуть всё в рабочее состояние. Для инфраструктуры, на которой держатся приложения и рабочие места, это слишком высокая цена за обычную эксплуатационную задачу. Стоит стремиться к другому сценарию: службы обновляются по очереди, виртуальные машины продолжают работать, а при ошибке платформа сама возвращается в рабочее состояние. Администратору остаётся устранить причину и повторить попытку.</p> <p>Такое поведение нужно закладывать в архитектуру. Микросервисы позволяют уменьшить масштаб изменений, проверки и автоматический откат ограничивают последствия ошибки. За результат отвечают и разработчик платформы, и тот, кто её эксплуатирует.</p> <h3>Обновлять службы по отдельности</h3> <p>Если любое изменение требует обновить платформу целиком, даже небольшое исправление затрагивает компоненты, которые исправно работают. Возникает желание отложить обновление. Исправления копятся, разрыв между версиями растёт, и следующий переход становится ещё сложнее.</p> <p>Микросервисная архитектура помогает разорвать этот круг. Консоль управления, планировщик, брокер подключений, агенты на узлах выполняют разные задачи. Если их жизненные циклы разделены, можно обновить конкретную службу и проверить результат, прежде чем переходить к следующей. Чем меньше компонентов меняется одновременно, тем проще найти причину ошибки.</p> <p>Но одного деления на микросервисы мало. Вендор должен обеспечить совместимость компонентов на время перехода и возврат к предыдущей версии. Особенно чувствительны изменения конфигурации и базы данных: новая служба не должна лишать старую возможности продолжить работу после отката. Разбирать эти зависимости во время обновления администратор не должен.</p> <p>Обновление по службам сочетается с обновлением по узлам. Сначала меняется ограниченная часть кластера, затем система проверяет её состояние и продолжает. Работа на разных версиях должна быть предусмотрена разработчиком. Возможность безопасно остановиться между шагами здесь важнее скорости установки.</p> <h3>Что происходит с работающими машинами</h3> <p>Для пользователя главный вопрос прост: продолжит ли работать приложение? Ответ зависит от того, какой компонент обновляется и участвует ли он в выполнении уже запущенной виртуальной машины.</p> <p>При разделении управления кластером и выполнения ВМ перезапуск управляющей службы не останавливает гостевую операционную систему. На время могут стать недоступны создание машины или изменение её параметров. Доступность новых подключений тоже нужно проверять отдельно: она может зависеть от обновляемого шлюза.</p> <p>Некоторые компоненты можно обновить, сохранив для работающих ВМ прежние процессы. Новая версия начнёт использоваться при новом запуске процесса машины; обычной перезагрузки гостевой ОС для этого может быть недостаточно. Пользователь продолжает сессию, а администратор видит, что обновление установлено, но ещё не применено ко всей нагрузке.</p> <p>Сеть, хранилище и ядро требуют отдельного подхода. Если перезапуск компонента разрывает путь к дискам или останавливает ВМ, наличие микросервисов не спасёт. Перед обновлением узла может потребоваться живая миграция машин на соседние серверы. Для неё нужны совместимые узлы, доступные данные и запас ресурсов; допустимость краткой паузы при переключении зависит от приложения. Если безопасный перенос невозможен, нужен согласованный перерыв.</p> <h3>Сначала подготовка и проверка</h3> <p>Большую часть работы можно выполнить до переключения версий: доставить и распаковать пакет, проверить целостность, совместимость и доступное место. Затем убедиться, что серверы отвечают, кластер работоспособен, а текущие операции не конфликтуют с обновлением.</p> <p>Пробный прогон сокращает риск, но не гарантирует, что через минуту не пропадёт связь. Он дополняет защиту во время обновления. Если проблема найдена заранее, система сохраняет текущую версию и объясняет, что мешает начать.</p> <p>Администратору важно видеть, какие службы уже переключены, какой сервер обрабатывается и где возникла ошибка. При остановке должно быть понятно, можно ли продолжить после устранения причины. Сообщение «задача завершилась неуспешно» без этой информации оставляет основную работу человеку.</p> <h3>Если сервер перестал отвечать</h3> <p>Если сервер перестал отвечать, возможно, отказало оборудование. А возможно, оборвалась только связь с управлением, и виртуальные машины продолжают работать. Обновлять остальные узлы без проверки опасно: проблема может распространиться, а состояние кластера станет ещё труднее определить.</p> <p>Платформа должна обнаружить потерю связи, остановить дальнейшие изменения и запустить предусмотренный для этого сценария откат. Его задача — вернуть службы и конфигурацию в согласованное рабочее состояние. Для этого нужны журнал действий и проверенные способы их отмены. Некоторые изменения нельзя обратить установкой старого пакета; такие ограничения обязан учитывать разработчик.</p> <p>Команда отката не может немедленно исполниться на выключенном или полностью недоступном сервере. Система должна обработать доступную часть кластера и показать, где возврат подтверждён, а где нужно восстановить связь или вмешаться вручную. Статус «откат завершён» требует проверки результата.</p> <p>Откат относится к изменениям платформы. Он не возвращает гостевые диски в прошлое и не отменяет операции приложений. Резервное копирование остаётся необходимым. Сам процесс обновления управляющих служб нужно строить так, чтобы он не требовал возврата пользовательских данных.</p> <h3>Как откат сработал на демонстрации</h3> <p>Во время демонстрации на одном мероприятии произошёл сбой, который хорошо показал работу отката. На стенде запустили обновление серверного компонента: выбрали пакет, создали задачу, прошли подготовку и пробный прогон. Во время переключения один из серверов перестал отвечать по сети.</p> <p>Платформа остановила задачу и автоматически запустила возврат. Изменения были отменены, система осталась на прежней версии. Виртуальные машины продолжали работать, кластер сохранил работоспособность, доступ к хранилищу не прервался. Консоль показала ошибку и проблемный сервер. Оставалось проверить сеть и повторить обновление.</p> <p>Слушателей интересовало, что увидит пользователь. В этом сценарии его сессия продолжалась: обновляемые компоненты не требовали остановки машин, а изменения, связанные с их новым запуском, могли подождать.</p> <p>Успешная установка на подготовленном стенде ещё мало говорит о восстановлении. Здесь ошибка возникла на глазах у аудитории, и стало видно, какую часть работы система берёт на себя и что остаётся администратору.</p> <h3>Когда автоматического возврата недостаточно</h3> <p>В практике встречались обновления, которые не применялись на отдельных аппаратных конфигурациях. Платформа откатывала изменения, работа продолжалась на прежней версии. Затем выходил патч, учитывающий особенности оборудования, и повторное обновление проходило успешно. Именно такой цикл и нужен администратору: сохранить рабочую среду, получить исправление и продолжить.</p> <p>Границу возможностей автоматики разберём на условном примере. Во время обновления отказал системный диск, узел больше не загружается, штатный механизм возврата на нём запустить невозможно. Сначала потребуется восстановить оборудование и загрузку сервера, затем вернуть узел в согласованное с кластером состояние. Сам откат физическую неисправность не устранит.</p> <p>Для подобных ситуаций нужны актуальная копия конфигурации и управляющих компонентов, проверенная инструкция ручного восстановления. Вендор обязан описать процедуру, обеспечить диагностику и помочь её пройти. Администратору должно быть понятно, какие действия безопасны, чтобы не перезапускать службы наугад в надежде вернуть кластер к жизни.</p> <h3>Как разделить ответственность</h3> <p>Разработчик отвечает за поведение продукта: какие изменения применяются отдельно, как проверяется совместимость, что произойдёт при потере связи и как вернётся работоспособность. Если ошибка возникла в поддерживаемом сценарии, заказчик не должен восстанавливать систему в одиночку. Вендор должен предусмотреть автоматический возврат, а за его пределами обеспечить процедуру восстановления и инженерную помощь. Тогда администратор сможет устранить исходную проблему и продолжить обновление.</p> <p>Пользователь отвечает за условия эксплуатации: поддерживаемую конфигурацию, исправную сеть и хранилище, резервные копии, свободные ресурсы и соблюдение порядка обновления. Начинать стоит со стенда с нагрузкой, похожей на рабочую, затем переходить к ограниченной части производственной среды. Расширять обновление можно после проверки результата. Запас мощности для миграции нужен до начала работ.</p> <p>Если исправление безопасности требует нового запуска ВМ или перезапуска узла, отсрочка может сохранять уязвимость. Срок применения нужно выбирать с учётом риска, согласовывать с владельцами приложений и заранее сообщать пользователям. Установленный пакет ещё не означает, что защита уже действует.</p> <p>У поставщика стоит просить показать весь процесс: подготовку, переключение службы, потерю связи с узлом и восстановление. Проверить, что происходит с приложениями, что видно в консоли и что потребуется от администратора. Это делает границы ответственности конкретными до первой нештатной ситуации.</p> <p>Для критичной инфраструктуры обновление без прерывания сервиса должно стать требованием к архитектуре и эксплуатации. Микросервисы позволяют менять платформу небольшими частями, автоматический откат возвращает её в рабочее состояние при предусмотренных сбоях. А согласованные процедуры и участие вендора помогают сохранить контроль там, где автоматика закончилась.</p> <p>#IMAGE_235774#</p> Обновление платформы виртуализации часто планируют как небольшую аварию: назначают ночное окно, предупреждают пользователей … article Линар Ихсанов, директор по продукту “Лаборатории Виртуализации” https://www.itweek.ru/themes/detail.php?ID=235771 Tue, 20 Oct 2026 16:34:58 +0300 <p>Институт статистических исследований и экономики знаний (ИСИЭЗ) НИУ ВШЭ проанализировал на основе данных Росстата по итогам 2025 года, как организации распределяют затраты на инновационную деятельность.</p> <p>В 2025 г. крупные и средние российские организации продолжили активно инвестировать в инновации: объем таких затрат достиг 4,5 трлн руб. Их интенсивность (отношение к общему объему продаж) составила 2,7% — выше, чем в большинстве европейских стран: например, в Финляндии она равна 2,1%, во Франции — 2%, в Австрии и Норвегии — 1,9%, в Италии — 0,9%.</p> <p>Затраты на инновации в 2025 г. почти поровну распределились между сферой услуг (49,7%) и промышленным производством (48,4%); на сельское хозяйство и строительство пришлось чуть менее 2%. Среди отраслей сферы услуг по объему инвестиций лидируют научные исследования и разработки (19,5% всех затрат на инновации) и телекоммуникации и ИТ (19%). Среди обрабатывающих отраслей выделяются производители компьютеров, электронных и оптических изделий (6,3%), химических веществ и продуктов (5,9%), кокса и нефтепродуктов (5,8%) и др.</p> <p>В целом крупные и средние организации прежде всего закупают машины и оборудование (38,8% затрат на инновации); на исследования и разработки приходится 29,2% средств. Обратное соотношение — в высокотехнологичных отраслях обрабатывающей промышленности и сфере услуг: здесь на научную деятельность направляют 44,7% и 36,2% затрат соответственно, а на обновление материально-технической базы — менее 30%.</p> <p>Собственные средства организаций остаются главным источником финансирования инноваций: в 2025 г. на них пришлось 62,4% затрат (в промышленном производстве — 67,9%). Бюджетные средства обеспечивают свыше пятой части затрат: 20% поступает из федерального бюджета, еще 2,6% — из региональных и местных бюджетов. Кредиты и займы покрыли 9,2% расходов на инновации. Вклад остальных источников минимален.</p> <p>Несмотря на сохраняющийся высокий уровень затрат на инновации, финансовые ограничения остаются одним из главных препятствий для дальнейшего расширения инновационной деятельности крупных и средних организаций. Высокую стоимость нововведений и нехватку собственных средств назвали значимыми сдерживающими факторами более трети организаций. Трудности с привлечением внешнего финансирования — государственной поддержки и заемных средств — компании отмечали заметно реже.</p> Институт статистических исследований и экономики знаний (ИСИЭЗ) НИУ ВШЭ проанализировал на основе данных Росстата … message https://www.itweek.ru/themes/detail.php?ID=235770 Tue, 20 Oct 2026 10:06:06 +0300 <p><em>На виртуальном аналитическом саммите, проведенном 8 октября Linux Foundation под эгидой ценности технологий, Фонд объединил токеномику, FinOps, управление ИТ-активами (ITAM) и открытую спецификацию затрат и использования FinOps (FinOps Open Cost and Usage Specification, FOCUS) вокруг более масштабного вопроса: как предприятия могут связать стоимость искусственного интеллекта с создаваемой им бизнес-ценностью? Кевин Огунсуа, главный аналитик </em><em>Forrester</em><em>, выделяет в корпоративном блоге семь обсуждавшихся тем.</em></p> <h3>1. TCA может стать преемником TCO для ИИ</h3> <p>Возможно, наиболее полезным новым термином, введенном на саммите, является TCA (Total Cost of AI, общая стоимость ИИ). Ключевая идея заключается в том, что токены составляют лишь от 10 до 25% от общих затрат на ИИ, если учитывать более широкий спектр затрат. TCA расширяет общий знаменатель до инфраструктуры, энергии, капитала, ПО и лицензирования, рабочей силы и других затрат, необходимых для производства и потребления ИИ.</p> <p>На протяжении десятилетий технологические лидеры полагались на TCO (Total Cost of Ownership, общая стоимость владения). Однако TCA может стать более актуальной концепцией для ИИ, поскольку ИИ — это не просто актив, которым можно владеть. Это динамичная система производства и потребления, экономика которой охватывает инфраструктуру, интеллект, людей и результаты.</p> <p>Более того, дискуссия перекочевывает в кабинет финансового директора. Организаторы мероприятия отметили растущее участие CFO в руководстве направления токеномики Фонда и усиление акцента на преобразовании потребления технологий в результаты, которые можно представить в финансовом выражении. Кроме того, Фонд объявил, что предстоящий форум для финансовых директоров будет проходить 8 декабря по правилу Чатем-Хауса (Chatham House Rule), он предоставит важную площадку для финансовых лидеров, чтобы обсудить вопросы распределения затрат, доходов и ценности ИИ.</p> <h3>2. Токеномика — это производство, потребление и ценность, а не только токены</h3> <p>Формирующееся определение токеномики ИИ охватывает все этапы: от преобразования энергии и капитала в возможности ИИ, через потребление этого интеллекта, до получения измеримой бизнес-ценности. Таким образом, инфраструктура, центры обработки данных, ПО, рабочая сила и результаты — все это находится внутри этой экономической системы.</p> <h3>3. У ИИ проблема скорее с ценностью, чем со стоимостью</h3> <p>В <a href="https://www.tokeneconomics.com/state-of-tokenomics/">исследовании</a> «The State of Tokenomics, 2026» приняли участие 472 респондента из 11 отраслей, их суммарная выручка составила 4,6 трлн. долл. Что еще важнее, главный вопрос исследования заключается в том, могут ли предприятия связать потребление и инвестиции в ИИ с измеримыми бизнес-результатами.</p> <p>Это меняет тему обсуждения с «Насколько дешево мы можем использовать ИИ?» на «Какую бизнес-ценность приносят инвестиции?»</p> <h3>4. Мультимодельный ИИ превращает экономику в архитектурное решение</h3> <p>Предприятия больше не используют ИИ через один канал. Фактически, согласно опросу, 96% используют передовые модели, 87% — облачных провайдеров, а 64% — ИИ, встроенный в существующие продукты, причем половина работает как минимум по четырем из шести каналов ИИ.</p> <p>По мере фрагментации ИИ выбор модели, маршрутизация, архитектура, производительность и экономика все чаще становятся неотъемлемой частью принятия правильного архитектурного решения, оптимизирующего инициативу.</p> <h3>5. Маршрутизация моделей становится рычагом повышения ценности</h3> <p>Маршрутизация моделей обеспечивает механизм сопоставления рабочих нагрузок с соответствующими моделями, а не автоматическую отправку каждой задачи наиболее эффективному или дорогому варианту. Соответственно, согласно материалам саммита, 86% компаний оценивают или используют маршрутизаторы моделей.</p> <p>Открывающаяся возможность заключается в динамической оптимизации по показателям стоимости, производительности, риска и ценности.</p> <h3>6. FinOps, управление ИТ-финансами и токеномика сближаются</h3> <p>ИИ выходит за рамки традиционных границ управления технологиями. В частности, FinOps рассматривает потребление и оптимизацию; ITAM включает в себя активы, контракты, лицензии и права; управление ИТ-финансами (ITFM) связывает экономику технологий с финансовым менеджментом; токеномика расширяет взгляд на производство, потребление и ценность ИИ. В результате дискуссия расширяется до управления ценностью технологий, а не заменяет одну дисциплину другой.</p> <h3>7. FOCUS становится финансовым уровнем данных для ИИ</h3> <p>Управлению затратами и ценностью необходимы нормализованные данные. В этом контексте FOCUS — это открытая спецификация, унифицирующая биллинговые данные в сферах ИИ, облачных технологий, дата-центров и решений различных вендоров, что позволяет снизить сложность и обеспечить единый подход к оценке ценности технологий. Она обеспечивает важную основу для связи затрат, использования, ценообразования, атрибуции и, в конечном итоге, финансовой подотчетности. Однако следующая задача — перевести эти данные на язык, понятный финансовому отделу: бизнес-единицы, центры затрат, продукты, правила распределения, план счетов и, в конечном итоге, главная книга. На саммите был явно поднят вопрос о сопоставлении общих прямых и косвенных затрат с главной книгой и планом счетов для сокращения ручного распределения в конце месяца.</p> <h3>Итог: цель — управление ценностью ИИ</h3> <p>В конечном счете, главный посыл саммита выходит за рамки токеномики. Компаниям необходимо связать воедино этапы производства и потребления, а также показатели затрат и ценности. Методология TCA позволяет использовать более полный знаменатель для расчетов, в то время как стандарт FOCUS помогает унифицировать исходные данные. Такие дисциплины, как FinOps, ITAM, ITFM и токеномика, служат важными дополнениями к этому подходу. Наконец, вовлечение финансового директора обеспечивает финансовую подотчетность.</p> <p>Таким образом, следующим рубежом становится управление ценностью ИИ — связывание совокупных затрат на ИИ с измеримой ценностью, которую он создает.</p> На виртуальном аналитическом саммите, проведенном 8 октября Linux Foundation под эгидой ценности технологий, Фонд … article https://www.itweek.ru/themes/detail.php?ID=235768 Tue, 20 Oct 2026 09:45:21 +0300 <p>Мы живем в интересное время. С одной стороны, российские компании ускоренно мигрируют с SAP, Microsoft Dynamics и других западных платформ на «1С», «Галактику» и нишевые отечественные решения. С другой — спор о том, стоит ли менять и когда менять, не утихает. По<a href="https://www.tadviser.ru/a/56070" title="https://www.tadviser.ru/a/56070"> данным</a> TAdviser, в сегменте крупных коммерческих предприятий значительную долю занимают ERP-решения от SAP и Microsoft. Это означает, что больше половины компаний по-прежнему работают на «недружественных» платформах. Но арифметика миграции сложнее, чем кажется.</p> <h3>Почему импортозамещение ERP буксует</h3> <p>После разговора с рядом экспертов и ИТ-руководителей картина становится ясной. Главный тормоз — не технологическая неспособность, а отсутствие четкой бизнес-цели на старте. Если заказчик приходит и говорит: «Сделайте нам как в SAP, только на „1С“» — проект почти гарантированно выходит за бюджет в полтора раза и за календарь — минимум на треть. Миграция без бизнес-цели умирает еще на старте, просто этого никто не замечает до середины проекта.</p> <p>Проблема глубже, чем кажется. Многие компании привыкли идти за платформой: работая на SAP, они пытались адаптировать бизнес под его стандартные процессы, хоть это почти никогда не получалось, ведь по статистике каждое корпоративное внедрение SAP кастомизировано на десятки процентов по сравнению с типовым решением. Переходя на «1С», компании пытаются заставить платформу имитировать «старую». Повторить SAP на «1С» невозможно. SAP — процессно-ориентированная система, «1С» — объектно-ориентированная. Попытка копирования дает результат, который не похож ни на SAP, ни на «1С». Платформы разные, и пытаться воспроизвести старую систему на новой — нерационально, бессмысленно.</p> <p>Еще одна ловушка — тотальный перенос исторических данных. Иллюзия, что все данные за десять лет пригодятся в новой системе, не оправдывается статистикой потребления. По моему опыту, используется от силы <nobr>10-20%.</nobr> Разумная альтернатива — упаковать старую систему в режим архивного чтения и открывать ее по мере необходимости. Полная миграция истории — это десятки миллионов рублей и месяцы работы, которые почти никогда не окупаются.</p> <p>Отдельная история — архитектура. Если привлекать моновендорных подрядчиков, ориентированных только на «1С», они построят архитектуру, привязанную к конкретному технологическому партнеру. Это работает до первого серьезного изменения регуляторики или бизнес-модели. Выход — работать либо с крупным интегратором, умеющим строить корпоративную архитектуру без привязки к одной платформе, либо с командой из профессионального консалтинга. Но думать об этом нужно до старта, а не в момент, когда идет приемка результатов проекта.</p> <h3>Кейс, который сработал</h3> <p>Приведу пример успешной миграции. Крупная транспортная компания, оказывающая услуги производственного характера, вынужденно уходила с SAP. Проект стартовал «в огне», с болью и слезами у бизнеса. Однако менее чем за год был обеспечен перевод регламентированного периметра так, чтобы вести учет уже в новой системе. Еще примерно полгода у компании ушло на стабилизацию и дообогащение нереализованными в «старой» системе бизнес-процессами. Ключевое решение — параллельно с миграцией был сформирован собственный центр компетенций. Логика простая — ИТ-директор понимал, что нельзя полагаться только на команду интегратора. Подрядчик должен уйти, а система — не упасть.</p> <p>Другой пример — «Ригла», сеть из более чем 7000 аптек. Компания <a href="https://www.retail.ru/cases/10-tysyach-tochek-za-3-dnya-rigla-sokratila-srok-zakrytiya-rsbu/" title="https://www.retail.ru/cases/10-tysyach-tochek-za-3-dnya-rigla-sokratila-srok-zakrytiya-rsbu/">мигрировала</a> с Microsoft Navision на «1С», но не стала просто переносить систему. Вместо этого был спроектирован единый информационный ландшафт. Шесть разрозненных баз «1С» свели в одну, интегрировали обмен с операционными системами. Результат — закрытие месяца сократилось с 15 рабочих дней до 6, с целевым показателем в 3 дня. Численность финансовой команды не выросла, хотя сеть продолжала расти.</p> <h3>Почему привычная модель расчета ТСО не работает</h3> <p>Теперь о деньгах. Традиционно проекты миграции оценивают через TCO (совокупную стоимость владения). Метод полезный, но у него есть фундаментальный изъян: он считает только затраты, но не считает ценность. TCO отвечает на вопрос: «Сколько будет стоить переход?», но не отвечает на вопрос: «Что мы потеряем, если не перейдем?».</p> <p>Приведу конкретный пример: кассовое решение, написанное на устаревшем стеке. Вендоров нет, компаний, поддерживающих решение, — тоже нет. Чтобы оно продолжало функционировать, нужен штат разработчиков и сопровождения. При этом с 1 сентября вышло требование поддержать мессенджер MAX как средство авторизации в программе лояльности на кассе. До этого — маркировка, еще раньше — <nobr>54-ФЗ,</nobr> <nobr>152-ФЗ,</nobr> ТТТ. Каждое регуляторное изменение — это новые человеко-часы. Если посчитать суммарно, вендорское решение, пусть и с vendor lock, оказывается дешевле в этом узком сегменте. Поддержка включена в лицензионный контракт, а регуляторные изменения приходят «в коробке».</p> <p>Есть и формула для такого расчета. Риск наступления критического события умножается на вероятность и на сумму вероятных потерь. Полученная цифра становится обоснованием инвестиций. В текущих условиях вероятность реализации инфраструктурных рисков выросла кратно, поэтому защищать проекты модернизации стало проще. TCO в такой логике считается более агрессивно. Нужно учитывать влияние госорганов, скорость выпуска изменений, риски, связанные с текущим временем.</p> <p>Но остается вопрос — как учитывать в TCO недополученную прибыль из-за того, что бизнес не успевает за изменениями? Однозначного ответа нет. Это та зона, где цифры заканчиваются и начинается управленческое суждение.</p> <h3>TVO как альтернатива ТСО</h3> <p>Как мы видим TCO — это серьезное упрощение. Если менеджер живет только по логике TCO, он упускает стратегическую перспективу. Давайте попробуем рассмотреть понятие Total Value of Opportunity (TVO). Это методология оценки ИТ-проектов, разработанная Gartner в начале <nobr>2000-х.</nobr> Она оценивает проект по пяти измерениям — стратегическое соответствие, влияние на бизнес-процессы, прямая финансовая отдача, архитектурное соответствие и риск. TVO не пытается свести все к одной цифре. Оно создает структуру для разговора между бизнесом и ИТ, где обе стороны говорят на одном языке.</p> <p>Ключевое отличие TVO от TCO — оно допускает, что ценность у разных компаний разная. Для сети магазинов это может быть рост продаж за счет точности пополнения полок. Для фармкомпании — высвобождение людей за счет сокращения времени подготовки регуляторной отчетности. TCO оперирует одним числом. TVO позволяет обсуждать несколько чисел, включая те, что не поддаются немедленной квантификации, но стратегически критичны.</p> <p>Конечно, можно жить в парадигме «пока не припрет — не надо импортозамещаться». Стратегия — это зона компетенции менеджера, но это и ставка. Ты видишь образ будущего и ставишь на него репутацию, карьеру, деньги. Модель «ждать, пока петух клюнет» — самая комфортная для менеджера, но самая невыгодная для бизнеса.</p> <h3>Цена ожидания</h3> <p>Бесспорно, стратегия подождать — это тоже решение, и у него есть своя цена. Она не видна в TCO, потому что не отражена в бюджете. Но она проявляется в трех плоскостях.</p> <p>Первая — регуляторная. Каждый год выходят новые требования. Старая система либо адаптируется (это дорого), либо компания работает вне закона (это риск). Вторая — кадровая. По рыночным оценкам, в России более 300 тыс. «1С»-специалистов, но на рынке их не найти. Когда компания решает мигрировать, ей нужны не просто «1С»-специалисты, а архитекторы, способные спроектировать корпоративный ландшафт. Таких людей на рынке единицы, и они уже заняты. Третья — рыночная. Пока компания ждет, конкуренты перестраивают процессы, сокращают издержки, ускоряют отчетность. Разрыв накапливается.</p> <p>Не надо забывать, что помимо замещения нужно очень быстро бежать, хотя бы для того, чтобы оставаться на месте. Потому что нас нагоняют новые технологии, новые изменения регуляторов, бизнес-процессов и всего остального.</p> <h3>Что делать</h3> <p>Инвестировать нужно не в покупку софта, а в выращивание собственных специалистов, которые будут хотеть работать с вами и смогут аккумулировать знания так, чтобы они использовались повторно. Формировать центр компетенций параллельно с проектом миграции, а не после. Считать не только TCO, но и TVO — особенно когда речь идет о стратегических решениях, где цена ошибки выше цены экономии. При выборе подрядчика смотреть не на бренд и список проектов, а на конкретные ФИО, которые участвовали в этих проектах. Отраслевая экспертиза в любой отрасли приходит с конкретными физическими лицами из компании в компанию.</p> <p>И главное — определять бизнес-цель до старта проекта. Не перейти на «1С», потому что SAP ушел, а сократить закрытие месяца до трех дней или обеспечить бесперебойную работу касс при смене регуляторных требований. Без этого любая миграция — просто смена вывески.</p> <p>Но остается открытым вопрос: если рынок отраслевого софта еще не сформирован и сам вынужден трансформироваться под влиянием искусственного интеллекта, может ли компания вообще позволить себе ждать, пока этот стандарт появится?</p> <p>#IMAGE_235769#</p> Мы живем в интересное время. С одной стороны, российские компании ускоренно мигрируют с SAP, Microsoft … article Алексей Стоянов, руководитель практики “1С” компании “Рексофт” https://www.itweek.ru/themes/detail.php?ID=235765 Mon, 19 Oct 2026 16:01:31 +0300 <p>СберТех расширил функциональность своей флагманской системы управления базами данных (СУБД) Platform V Pangolin DB с учетом потребностей крупного бизнеса. В решении реализован новый механизм хранения данных, который позволяет сократить занимаемый объём на серверах до двух раз, а использование дискового пространства под журнал фиксации транзакций — от пяти до двадцати раз.</p> <p>Обновление актуально для компаний, строящих ИТ-инфраструктуру на базе PostgreSQL-совместимых СУБД. Новый способ хранения снижает объём обращений к диску и объём хранения за счёт исключения дублирования данных и индексов, выноса неактуальных версий строк в отдельный журнал. Это позволяет эффективнее использовать установленное серверное оборудование, формировать запас производительности для пиковых нагрузок и ускоряет восстановление системы после сбоя.</p> <p>Максим Тятюшев, генеральный директор СберТеха, отметил: «С новой функциональностью Platform V Pangolin DB отлично подойдет для оптимизации массивов корпоративных данных на предприятиях из разных отраслей промышленности, ОПК, госсектора, финансов, телекоммуникаций, ретейла и онлайн-торговли. Решение помогает высвободить внутренние ресурсы для хранения растущих объемов информации и повышения производительности систем. На базе СУБД компании смогут развивать свой ИТ-ландшафт без избыточных ресурсозатрат на расширение и обслуживание серверного парка».</p> <p>Platform V Pangolin DB — реляционная СУБД для высоконагруженных систем с повышенными требованиями к безопасности и надёжности, входит в продуктовый портфель СберТеха по работе с данными. Решение разработано на основе PostgreSQL и содержит ряд важных доработок, позволяющих его использовать в масштабах корпораций. СУБД внесена в реестр российского ПО, сертифицирована ФСТЭК и уже доказала свою эффективность работой в ряде крупнейших компаний России. Более 150 тысяч инсталляций Platform V Pangolin DB успешно эксплуатируются в составе сервисов и приложений с различным уровнем нагрузки и критичности.</p> СберТех расширил функциональность своей флагманской системы управления базами данных (СУБД) Platform V Pangolin … message https://www.itweek.ru/themes/detail.php?ID=235764 Mon, 19 Oct 2026 16:00:17 +0300 <p>Эксперты STAQ, российской платформы для цифровизации бизнес-процессов, выделили пять ошибок при выборе платформенных решений в 2026 году, которые могут увеличить расходы, затянуть внедрение и снизить эффект автоматизации. В их число вошли выбор по списку функций, недостаточная проверка интеграций, оценка только начальной стоимости, завышенные ожидания от ИИ и невнимание к условиям внедрения и поддержки.</p> <p>Выбор платформы затрагивает работу ряда подразделений. Производству нужно обслуживать оборудование, сервисной службе — распределять заявки и курировать сроки, руководству — видеть результаты и затраты. ИТ-команда отвечает за совместимость с системами и устойчивость инфраструктуры. Если все требования не согласовать до покупки, ограничения могут обнаружиться после запуска, и устранение потребует дополнительных ресурсов.</p> <p>Первая ошибка — сравнивать возможности продуктов, не определив, какой процесс нужно улучшить. Наличие мобильного приложения, аналитики или конструктора процессов не объясняет, как изменится работа сотрудников. Например, предприятие выбирает платформу для ускорения ремонта, но оценивает только удобство регистрации заявок. Основное время уходит на согласование работ и поиск запчастей. После внедрения обращения создаются быстрее, но длительность простоя остается прежней. Для избежания такой ситуации, нужно заранее описать путь задачи от возникновения до выполнения, найти причины задержек, выбрать показатели для оценки результата.</p> <p>Вторая ошибка — откладывать проверку интеграций до начала внедрения. Заявленную возможность подключения к ERP, сервис-деску или оборудованию необходимо проверить в условиях заказчика. Значение имеют версии систем, состав передаваемых данных, права доступа и порядок работы при потере связи. Если эти вопросы остаются без внимания, могут возникнуть дубли заявок, расхождения в статусах и задержки уведомлений. Сотрудникам придётся перепроверять информацию вручную, а ИТ-службе — выполнять незапланированные доработки. До покупки важно проверить полный сценарий: от поступления события из внешней системы до назначения исполнителя и передачи результата выполненной работы. </p> <p>Третья ошибка — оценивать решение только по начальной стоимости. При сравнении предложений компания может ориентироваться на цену лицензии, не учитывая перенос данных, настройку интеграций, обучение и сопровождение. Дополнительные расходы становятся особенно заметны при подключении новых подразделений и площадок. Проект, который укладывался в бюджет на старте, требует новых вложений, а его расширение приходится откладывать. Снизить этот риск помогает расчёт полной стоимости владения за одинаковый период для всех рассматриваемых решений. </p> <p>Четвёртая ошибка — выбирать платформу ради ИИ, не оценив готовность собственных данных. Интеллектуальный помощник может классифицировать обращения, находить похожие инциденты и предлагать дальнейшие действия. Для этого ему нужны корректные сведения об объектах, история заявок и результаты работ. Если информация неполна или противоречива, сотрудники будут тратить время на исправление маршрутизации и проверку рекомендаций. До выбора решения следует определить задачу для ИИ и проверить её выполнение на данных компании. Оценивать нужно правильность обработки обращений, число ручных исправлений и изменение сроков работы. </p> <p>Пятая ошибка — недостаточно оценивать команду, которая будет внедрять и сопровождать платформу. Для запуска необходимо обследовать процессы, подготовить данные и обучить пользователей. Если обязанности заказчика, вендора и интегратора не распределены, часть работ может остаться без ответственного. Это приводит к переносу сроков, спорам при приёмке и дополнительной нагрузке на внутреннюю ИТ-службу после запуска. При выборе поставщика важно оценить его опыт в похожих проектах, доступность специалистов и готовность помочь с проработкой требований. </p> <p>Причины таких ошибок связаны с нехваткой времени на подготовку, недостаточным опытом внедрения и разным представлением участников о будущем процессе. Каждое подразделение хорошо знает собственный участок, но может не учитывать, какие сведения и действия нужны коллегам. </p> <p>STAQ рекомендует начинать выбор с формирования рабочей группы, в которую входят владелец процесса, представители ИТ, информационной безопасности и будущие пользователи. Вместе с поставщиком они должны определить границы проекта, интеграции, ожидаемый результат и порядок его проверки. </p> <p>Следующий этап — пилот на одном объекте. До запуска фиксируют исходные показатели, потом оценивают изменения при сопоставимой нагрузке: время обработки задач, соблюдение сроков, объём ручной работы и затраты. </p> <p>«Я бы предложил заказчику проверить, как платформа поведёт себя, когда привычный порядок работы изменится: сменится подрядчик, появится новая площадка или потребуется пересмотреть правила обслуживания. В этот момент станет понятно, насколько компания свободна в развитии своего решения и сколько ей будет стоить следующий шаг. Задача вендора — заранее объяснить эти условия, включая ограничения продукта. Заказчик должен понимать, какие изменения он сможет провести своими силами и где ему потребуется наша помощь», — прокомментировал Евгений Гусев, генеральный директор STAQ.</p> Эксперты STAQ, российской платформы для цифровизации бизнес-процессов, выделили пять ошибок при выборе платформенных решений … message https://www.itweek.ru/themes/detail.php?ID=235762 Mon, 19 Oct 2026 10:29:47 +0300 <p><em>Использование искусственного интеллекта в государственном секторе расширяется, однако проблемы с данными, устаревшими системами и механизмами управления сдерживают эффективное масштабирование этой технологии, отмечают опрошенные порталом </em><em>AI</em> <em>Business</em> <em>эксперты.</em></p> <p>Государственные структуры переходят от экспериментов с ИИ к его полномасштабному внедрению, отчасти под давлением общественного запроса на более оперативное оказание услуг и ощутимые результаты — запроса, темпы роста которого опережают возможности самих ведомств.</p> <p>Согласно недавнему глобальному <a href="https://www.capgemini.com/wp-content/uploads/2026/09/CRI_Data-and-AI-in-Public-Sector_Research-Brief.pdf">исследованию</a> Capgemini Research Institute «Data and AI in government», охватившему 600 руководителей высшего звена организаций госсектора, чуть более половины государственных организаций изучают возможности, проводят пилотные проекты или уже внедряют агентный ИИ (системы, способные самостоятельно принимать решения и выполнять действия).</p> <p>Тем не менее, темпы внедрения зачастую опережают развитие систем управления и контроля, необходимых для регулирования работы таких ИИ-агентов: менее четверти респондентов заявили, что их практики ответственного использования ИИ успевают за скоростью развертывания этих инструментов.</p> <p>Марк Рейнхардт, руководитель глобального направления по работе с государственным сектором компании Capgemini, отмечает, что корни этой проблемы уходят в давние трудности, связанные с государственными технологическими системами. «Организации госсектора годами сталкиваются с проблемами устаревшей инфраструктуры, использованием унаследованных систем, сложностями обеспечения совместимости и вопросами управления, — поясняет он. — С появлением ИИ, и в особенности агентного ИИ, решение этих задач стало критически важным».</p> <h3>Управление агентным ИИ</h3> <p>По словам Рейнхардта, главным препятствием является отсутствие надлежащего фундамента данных. В случае с агентным ИИ эта проблема может усугубляться, поскольку таким системам требуется доступ к широкому спектру информации и других систем.</p> <p>Лора Гилберт, руководитель программы " AI for Government" в лондонском Tony Blair Institute for Global Change, соглашается с тем, что проблема кроется в данных, лежащих в основе моделей. «По моему опыту, правительства сдерживает вовсе не сама технология, — отметила она. — Настоящий разрыв наблюдается на уровне фундаментальных основ».</p> <p>Она также указывает на проблему нехватки компетенций и неуверенности в собственных силах: «Многие правительства передали значительную часть своих технических функций на аутсорсинг, из-за чего им трудно оценить, что реально осуществимо, что безопасно, а что им навязывают с преувеличенными обещаниями. Никто точно не знает, как решить вопрос ответственности при использовании агентного ИИ: кто отвечает за действия, совершенные ПО? У государственных служащих отсутствуют стимулы идти на риск и внедрять инновации». Поэтому ведомствам необходимо внедрить адресные механизмы контроля, ограничивающие сферу действия ИИ-агентов и снижающие риски, но не препятствующие их эффективному использованию. На практике это означает, что государственные органы должны четко определить, какие решения агент может принимать самостоятельно, к каким данным и системам он имеет доступ и в каких случаях управление необходимо передать человеку.</p> <p>«Правительствам следует сосредоточиться на создании систем управления данными, механизмов контроля и подотчетности, которые позволят ответственно масштабировать технологии ИИ и обеспечивать ощутимую пользу для общества, — считает Рейнхардт. — Кроме того, разумеется, необходимо модернизировать устаревшие системы — особенно те, архитектура которых изначально не предусматривала взаимодействия через API и, следовательно, интеграции с агентами».</p> <h3>Сферы внедрения ИИ-агентов в госсекторе</h3> <p>На данном этапе наиболее подходящими сферами применения могут стать задачи, где агенты способны автоматизировать повторяющиеся процессы с большими объемами данных, не принимая при этом решений, способных существенно повлиять на жизнь граждан.</p> <p>В качестве примеров таких задач Рейнхардт называет административные процедуры, обработку документов, ведение дел, внутренние ИТ-процессы, а также выполнение рутинных рабочих операций и согласование документов.</p> <p>Гилберт также высказывается в пользу начала работы с процессов, характеризующихся низким уровнем риска и большими объемами операций. По ее словам, такие внутренние задачи, как обработка корреспонденции, первичная сортировка дел или обобщение доказательной базы, отлично подходят для получения необходимого опыта, «поскольку ошибки здесь можно исправить, а экономия времени очевидна».</p> <p>Это позволит сформировать необходимую уверенность и доказательную базу для перехода к более ответственным задачам, непосредственно затрагивающим интересы граждан. «На начальном этапе важно понять разницу между ситуациями, которые можно сравнить с дверью, открывающейся в обе стороны (ошибки обратимы), и ситуациями, напоминающими дверь, открывающуюся только в одну сторону (ошибки необратимы)», — поясняет Гилберт.</p> <p>Однако уровень риска существенно варьируется в зависимости от сценария использования, а сохранение доверия общественности является для государственных органов ключевой задачей. «Ошибки ИИ, затрагивающие жизнь и благополучие граждан, подрывают доверие к государственным институтам и службам и, вероятно, могут затормозить дальнейшее внедрение этой важнейшей технологии, помогающей административным органам справляться с высокой нагрузкой», — подчеркивает Рейнхардт.</p> <p>Следовательно, меры контроля должны соответствовать уровню риска: степень надзора должна зависеть от масштаба последствий и критической важности конкретной задачи, а также — что особенно важно — от потенциальных рисков для граждан.</p> <p>Гилберт выделяет, помимо начала работы с малых и низкорисковых задач, еще один важный приоритет: формирование собственных компетенций внутри организации. «Вам не нужна армия специалистов, — говорит она, — но вам необходима ключевая команда людей, способных создавать, тестировать и подвергать критическому анализу, а также работающих в непосредственной близости от тех, кто принимает решения».</p> Использование искусственного интеллекта в государственном секторе расширяется, однако проблемы с данными, устаревшими … article https://www.itweek.ru/themes/detail.php?ID=235760 Mon, 19 Oct 2026 10:11:36 +0300 <p>Руководитель поручил ИИ-агенту запустить рекламную кампанию. Через минуту получил ответ: «Готово». Возникают вопросы: в каком кабинете появилась кампания, какой бюджет установлен, начались ли показы и где посмотреть подтверждение? При передаче работы человеку эти детали обычно входят в постановку задачи и приёмку. Для ИИ они столь же важны.</p> <p>Агент может быстро прочитать отчёты, подготовить варианты объявлений и выполнить доступные ему операции. Вместе с доступом он получает возможность ошибиться в выборе объекта, неверно понять поручение или повторить действие после сбоя. Уверенный тон ответа ничего из этого не исключает. Контроль целесообразно выстроить вокруг пяти проверок.</p> <h3>1. Определите, что именно вы поручили</h3> <p>Фраза «займись рекламой» оставляет слишком много решений открытыми. Человеку приходится уточнять продукт, бюджет и цель; агенту тоже нужны эти условия. Запишите результат в одной фразе: например, «подготовить три варианта объявления для согласования» или «возобновить одну ранее настроенную кампанию с сохранением её бюджета».</p> <p>Следом укажите границы: какие кабинеты разрешены, какие действия доступны, какие параметры сохраняются и в какой момент работа должна остановиться. Для первого знакомства достаточно анализа и подготовки предложений. Доступ к изменениям можно расширять по мере проверки рабочих сценариев.</p> <p>Такая запись полезна и для команды. Маркетолог понимает, какой результат принимает, технический специалист видит требования к доступам, а руководитель знает, за какие решения отвечает сам.</p> <h3>2. Сверьте кабинет и объект</h3> <p>У агентства могут быть десятки клиентов с похожими названиями кампаний. Вчера помощник работал с одним магазином, сегодня получил поручение по другому. Даже правильное действие в чужом кабинете создаёт проблему.</p> <p>До изменения попросите показать название клиента, конкретную кампанию и её текущее состояние. Название стоит дополнить устойчивым идентификатором из системы. Для руководителя это может выглядеть как короткая карточка: «клиент, кабинет, кампания, действие, бюджет».</p> <p>Важна свежесть сведений. За время подготовки коллега мог изменить настройки. Поэтому окончательная проверка объекта выполняется непосредственно перед действием. Если состояние отличается от согласованного, дальнейший шаг требует уточнения.</p> <h3> 3. Сделайте пределы измеримыми </h3> <p><strong>«</strong>Сильно бюджет не повышать» каждый понимает по-своему. У поручения должны быть конкретные числовые границы и период, к которому они относятся. Отдельно фиксируются доступные операции: подготовка, запуск, остановка, изменение параметров.</p> <p>Условный пример: разрешено подготовить новую кампанию, сохранить её без запуска и показать варианты объявлений. Следующая стадия начнётся после проверки посадочной страницы, целей и суммы расходов. Такой порядок позволяет принять каждую часть работы отдельно.</p> <p>Письменное поручение желательно подкрепить настройками самого подключения: выдать нужные роли, ограничить доступные действия и сохранить журнал. Инструкция в чате помогает объяснить правило, а технические настройки определяют, какие операции действительно доступны.</p> <h3>4. Принимайте результат по фактам</h3> <p>Сообщение агента об успехе полезно как краткая сводка. Для приёмки нужны данные из системы после выполнения. Попросите показать объект, время проверки и изменившиеся параметры. По рекламной кампании это может быть состояние запуска, установленный бюджет и отсутствие лишних изменений.</p> <p>Операцию и её деловой результат стоит проверять отдельно. Кампания может быть создана и при этом ожидать модерации. Разрешённый запуск также не подтверждает получение заявок. Для каждого этапа нужен свой признак: настройки сохранены, показы начались, обращения поступили, качество обращений проверено.</p> <p>Удобный отчёт занимает несколько строк: «что было поручено, что выполнено, чем подтверждено, что ещё ожидается». Если система недоступна, это тоже должно остаться в отчёте. Пробел в проверке важнее красивого завершения разговора.</p> <h3>5. Заранее договоритесь о действиях при сбое</h3> <p>Самая опасная ситуация возникает, когда связь оборвалась в момент изменения. Запрос мог выполниться, хотя ответ до агента не дошёл. Повторная попытка способна создать второй объект или повторить операцию.</p> <p>Поэтому для каждого поручения полезно различать три исхода: выполнение подтверждено, действие точно не выполнено, результат пока неизвестен. В третьем случае сначала проверяют систему и журнал операций. Продолжение зависит от найденного фактического состояния.</p> <p>Для восстановления сохраните исходные параметры и сведения об изменениях. Назначьте человека, который принимает решение при спорном результате, и укажите, как остановить автоматическую работу. Это стоит обсудить до первой операции в рабочем кабинете.</p> <h3>Как начать в своей компании</h3> <p>Выберите один повторяющийся сценарий с понятным результатом. Например, подготовку вариантов объявлений, сбор еженедельной сводки или проверку настроек одной кампании. Описывайте доступы и ожидаемый итог так, чтобы работу мог принять другой сотрудник.</p> <p>На первом этапе сравните результат агента с ручной проверкой. Зафиксируйте, где потребовалось уточнение и сколько времени заняли подготовка, выполнение и приёмка. Расширение доступа имеет смысл после нескольких воспроизводимых рабочих прогонов.</p> <p>Пять вопросов для итоговой проверки: какая задача поручена, в каком объекте выполняется, какие пределы установлены, где подтверждение результата и как действовать при сбое. Ответы превращают работу ИИ в управляемый процесс и помогают команде понимать, где заканчиваются полномочия помощника.</p> <p>#IMAGE_235761#</p> Руководитель поручил ИИ-агенту запустить рекламную кампанию. Через минуту получил ответ: «Готово». Возникают вопросы … article Дмитрий Лукашов, эксперт по искусственному интеллекту Русской школы управления https://www.itweek.ru/themes/detail.php?ID=235757 Fri, 16 Oct 2026 16:45:09 +0300 <p>Институт статистических исследований и экономики знаний (ИСИЭЗ) НИУ ВШЭ проанализировал приоритеты и особенности инновационной деятельности в России и европейских странах по итогам 2025 г.</p> <p>В России уровень инновационной активности определяется преимущественно продуктовыми инновациями — более масштабными и дорогостоящими нововведениями, связанными непосредственно с выпуском новых видов товаров и услуг. Расходы на них в 2,4 раза превышают затраты на процессные инновации, направленные на усовершенствование в основном текущих бизнес-процессов.</p> <p>В европейских странах, напротив, высокий уровень инновационной активности зачастую связан с активной реализацией процессных инноваций, требующих гораздо меньших капитальных вложений. Так, в Германии и Хорватии доля организаций, осуществлявших процессные инновации, практически вдвое выше реализовывавших продуктовые (в Польше — в 2,5 раза, Австрии, Бельгии, Италии — в 1,6, Испании — в 1,5, Финляндии — в 1,3 раза).</p> <p>Интенсификация процессных инноваций может рассматриваться как резерв для роста инновационной активности в отечественной экономике. В России доля организаций, реализующих различные их типы, в <nobr>1,3–2,6</nobr> раза отстает от среднего показателя по ЕС.</p> <p>Приоритеты отечественных и зарубежных организаций при реализации процессных инноваций несколько различаются. В России наиболее распространены нововведения, связанные с разработкой и внедрением новых или усовершенствованных методов обработки и передачи информации в части поддержания и обеспечения информационных и коммуникационных систем (33,3% организаций, имевших завершенные инновации); производства товаров и услуг (31,6%); ведения бизнеса, корпоративного управления, бухгалтерского и финансового учета (24,9%).</p> <p>В среднем по странам ЕС эти типы инноваций также популярны, однако здесь гораздо чаще, чем в России, востребованы и менее затратные типы процессных инноваций — направленные на реализацию организационных и маркетинговых нововведений. Так, новые методы управления трудовыми ресурсами в среднем по странам ЕС внедряли 40,9% организаций, имевших завершенные инновации (против 17,2% в России); маркетинговые методы продвижения, представления и ценообразования товаров — 32,6% (в России — 12,7%); практики деловых отношений и внешних связей — 30,5% (в России — 11,6%).</p> <p>Потенциал развития процессных инноваций в России связан прежде всего с более широким внедрением логистических методов. С учетом географических и климатических особенностей страны это направление особенно актуально, однако такие методы применяют лишь 13,8% инноваторов против 23,2% в среднем по ЕС.</p> <p>Инновационная деятельность в России отличается стремлением к более крупным продуктовым инновациям, обеспечивающим скорейшее обновление выпускаемой продукции и повышение технологической независимости страны. В то же время устойчивый рост инновационной активности во многом зависит и от реализации процессных инноваций. Более интенсивное их внедрение — прежде всего в части логистики и маркетинга — позволило бы значительно поднять общий уровень инновационной активности отечественных организаций.</p> Институт статистических исследований и экономики знаний (ИСИЭЗ) НИУ ВШЭ проанализировал приоритеты и особенности … message https://www.itweek.ru/themes/detail.php?ID=235756 Fri, 16 Oct 2026 16:43:47 +0300 <p>Сбер на конференции ГигаКонф для инженеров объявил об обновлении агентного конвейера GitVerse — в него добавили около 20 новых востребованных разработчиками функций. Агентный конвейер реализован внутри интерфейса GitVerse и поддерживает модель Bring Your Own Key (BYOK). Благодаря ей снижается порог входа в разработку: к новой функциональности получают доступ частные лица и небольшие команды. Теперь они могут вести проекты, используя те же профессиональные инструменты, что и крупный бизнес.</p> <p>Агентный конвейер позволяет автоматизировать цикл разработки с помощью ИИ. Ранее продукт был доступен только крупным организациям в локальной версии (on-premise). Теперь он появился в облачной версии и для физических лиц в формате раннего доступа, который уже знаком пользователям платформы. Для запуска им нужен только API-ключ от моделей. </p> <p>В рамках функционального обновления GitVerse повысилась прозрачность при работе с кодом. Помимо автономного решения задач, появилась интерактивная поддержка агентных сессий. Пользователям видят структуру файлов, с которыми взаимодействует агент, могут загрузить документы или изображения, чтобы, например, строить интерфейсы по макетам. Также предусмотрен выбор нужной <nobr>LLM-модели</nobr> из набора под конкретную задачу.</p> <p>Андрей Белевцев, старший вице-президент, руководитель блока «Технологическое развитие» Сбербанка, отметил: «Рынок разработки меняется стремительно: возможности моделей растут, а требования к скорости выпуска продуктов постоянно повышаются. Наша задача как продуктовой команды — делать технологии максимально удобными и полезными для пользователей — от крупных компаний до стартапов и индивидуальных разработчиков. Агентный конвейер GitVerse предоставляет всем единый набор надёжных инструментов, помогая быстрее создавать, проверять и выпускать качественные продукты».</p> <p>Чтобы начать работу с агентным конвейером, необходимо зайти в раздел задач, выбрать нужный проект и ветку, после чего можно назначить исполнителем не человека, а ИИ-агента — сессия запустится автоматически. Инструменты агента интегрированы во все основные потоки работы: от написания кода и исправления ошибок до запуска приложений и сквозного (end-to-end) тестирования. Сессию с агентом также можно открыть через привычный чат или CI/CD-воркфлоу. </p> <p>Одновременно с конвейером улучшилась работа с задачами. В обновленном трекере стали доступны: управление проектами и досками, настройка статусов и порядка выполнения задач, контрольные вехи с едиными сроками и целями. Появились публичное API задач, обновленная система меток, массовые операции, улучшенные связи между задачами, работа с файлами в комментариях и выгрузка списка задач в табличном виде.</p> Сбер на конференции ГигаКонф для инженеров объявил об обновлении агентного конвейера GitVerse — в него … message https://www.itweek.ru/themes/detail.php?ID=235755 Fri, 16 Oct 2026 16:41:36 +0300 <p>На крупнейшем мероприятии для профессионалов розничной торговли BSS провела секцию, где лидеры ритейла — Спортмастер, SELA, РОЛЬФ и другие — поделились своими кейсами применения ИИ. Эксперты BSS продемонстрировали ИИ-платформу по управлению клиентским опытом, которая находит скрытые сигналы клиентов и превращает их в выручку.</p> <p><nobr>7–8</nobr> октября на Коннектед Ритейл Форуме около 2 000 представителей ритейла, e-commerce и FMCG-брендов обсудили, как выделяться на рынке в 2026 году, привлекать новых покупателей и удерживать существующих.</p> <p>На эти вопросы команда BSS предложила посмотреть через призму ИИ-технологий: оба дня форума на нашем стенде гости знакомились с <nobr>CX-платформой —</nobr> эксперты BSS демонстрировали, как она помогает превращать сигналы клиентов в конкретные действия для роста продаж, удержания и лояльности. </p> <p>Подробнее о том, как устроена работа <nobr>CX-платформы,</nobr> рассказала руководитель направления по развитию голосовых цифровых технологий BSS Валерия Учайкина на секции, организованной совместно с BSS, «ИИ-студия: сквозная ИИ-стратегия в ритейле и на маркетплейсах».</p> <p>Представим: покупатель спрашивает, где его заказ. Звучит как рядовое обращение, которое можно закрыть простым ответом, но <nobr>CX-платформа</nobr> видит и другие сигналы — например, клиент несколько раз заходил в раздел отмены заказа, бросил корзину и после задержки доставки стал реже пользоваться приложением. В совокупности эти признаки могут указывать на риск оттока.</p> <p>Платформа связывает данные из разных каналов, находит закономерности и предлагает действия: например, кому из клиентов стоит позвонить сегодня, кому предложить компенсацию, а кому — персональную скидку на следующую покупку. Она помогает сотрудникам отрабатывать новые сценарии с помощью ИИ-суфлера и агент-тренера, а затем оценивает, изменилось ли поведение покупателей после принятых мер. Часть задач могут выполнять ИИ-агенты, оставляя сотрудникам контроль над важными решениями и работу со сложными случаями.</p> <p>Доклад Валерии стал частью дискуссии, на которой лидеры ритейла из разных сегментов рынка делились опытом применения ИИ. Модератором выступил заместитель генерального директора BSS Василий Жилов — вместе с участниками он обсудил, как внедрять технологии так, чтобы они помогали и бизнесу, и клиентам. </p> <p>Среди представленных кейсов — ИИ-аватары и автоматизация маркетинга, динамическая персонализация ценовых предложений, умные примерочные, онлайн-анализ состояния кожи для подбора косметики, сортировка сырья с помощью компьютерного зрения. Своим опытом поделились представители «Спортмастера», ГК «РОЛЬФ», SELA, 11i Professional, Openface. </p> <p>Компания BSS благодарит коллег за интересные кейсы и всех гостей форума — за продуктивное общение, готовность делиться опытом и интерес к инновациям. Именно так разговоры об ИИ превращаются в конкретные проекты, которые уже повышают продажи и лояльность покупателей!</p> На крупнейшем мероприятии для профессионалов розничной торговли BSS провела секцию, где лидеры ритейла — Спортмастер … message https://www.itweek.ru/themes/detail.php?ID=235754 Fri, 16 Oct 2026 14:30:11 +0300 <p>На ГигаКонф для инженеров Сбер представил единый дистрибутив среды разработки GigaIDE, сделав востребованную функциональность доступной для индивидуальных разработчиков и небольших команд.</p> <p>Благодаря единому дистрибутиву легко переключаться между режимами Pro и Community: достаточно активировать trial или подписку — и среда мгновенно получает Pro-функциональность без переустановки. Корпоративные пользователи могут гибко управлять затратами: инженер для повседневной работы остаётся в Community, а для отладки нагруженного модуля переключается в режим Pro.</p> <p>До выпуска единого дистрибутива GigaIDE предлагалась в двух обособленных форматах. Режим Community давал только базовую поддержку Java, Python и JavaScript и работу с базами данных. Он подходил для повседневного кодинга, пет-проектов и обучения, но продвинутые инструменты были доступны только в Pro-лицензии. Pro-режим, включающий интеграцию с корпоративными контурами безопасности, локальным и облачным хранением кода, маркетплейсом проверенных плагинов и расширенными средствами для СУБД, в свою очередь, был открыт исключительно для корпоративных клиентов. </p> <p>Андрей Белевцев, старший вице-президент, руководитель блока «Технологическое развитие» Сбербанка, отметил: «GigaIDE объединяет персональную и корпоративную разработку в единой среде. Разработчик или студент получает те же базовые возможности для отладки, тестирования и контроля безопасности, что и команды крупных компаний. Это упрощает повседневную работу: не нужно отдельно настраивать окружение, подбирать инструменты и вручную выстраивать процессы проверки кода. В результате больше времени остаётся на саму задачу, а начинающие специалисты и небольшие команды получают возможность работать по тем же практикам, что используются в промышленной разработке».</p> <p>Единый дистрибутив размещён на ИИ-платформе GitVerse. Pro-функциональность для физических лиц будет разворачиваться постепенно и станет доступна в полном объёме до конца 2026 года. Уже сейчас индивидуальным пользователям доступны готовые инструменты для Java, фреймворк для сайтов на Python (Django), всё необходимое для работы с веб-интерфейсами, встроенный редактор запросов к базам данных и расширения для них.</p> На ГигаКонф для инженеров Сбер представил единый дистрибутив среды разработки GigaIDE, сделав востребованную … message https://www.itweek.ru/themes/detail.php?ID=235753 Fri, 16 Oct 2026 14:27:03 +0300 <p>Positive Technologies представила коммерческую версию PT Security Lakehouse, решения для хранения и анализа больших данных, на котором два года работают собственные продукты компании. Заказчики смогут развернуть его в своей инфраструктуре. Платформа собирает в одном месте данные из разных средств защиты и дает работать с ними аналитикам SOC, разработчикам и ИИ-моделям.</p> <p>В большинстве компаний данные ИБ разнесены по разным системам: у каждого средства защиты своя база, а в SIEM могут попадать не все события. Из-за этого сложно увидеть атаку, которая проявляется на стыке сегментов. Например, когда программа на рабочей станции устанавливает сетевое соединение по нехарактерному для нее протоколу, заметить это можно, только если одновременно видеть поведение на устройстве и сетевую активность. Та же разрозненность ограничивает ИИ-агентов: чтобы самостоятельно расследовать инцидент, агенту нужен доступ к полной истории событий из всех источников, а не к выборке из одной системы.</p> <p>«Данные ИБ в компаниях живут в отдельных системах, и каждая видит только свой участок. Именно в это упираются и расследование атак, которые проходят через несколько сегментов, и работа ИИ-агентов. Два года Security Lakehouse уже работает внутри компании с нашими продуктами, и теперь заказчики смогут развернуть ту же платформу у себя», — рассказал Олег Кочергин, директор департамента управления данными Positive Technologies.</p> <p>Внутри Positive Technologies платформа принимает в пике до миллиона событий в секунду, в сутки в нее поступает более 50 млрд обезличенных записей. На ее данных работают PT AF Cloud, облачные детекты PT NAD. На этой же платформе компания строит следующее поколение продуктов, включая MaxPatrol O2.</p> <p>PT Security Lakehouse рассчитана на крупные компании с собственными центрами мониторинга и на провайдеров ИБ-услуг, которым нужно хранить и анализировать большие объемы событий за длительный период. Первые пилотные проекты уже идут в нефтегазовой отрасли, металлургии и банковском секторе.</p> <p>PT Security Lakehouse построена на открытой архитектуре. Данные хранятся в S3-совместимом хранилище в открытых форматах, поэтому заказчик не привязан к вендору и может подключать к ним собственные аналитические инструменты. Вычисления отделены от хранения, что позволяет изолировать нагрузку от разных систем и пользователей, а также эластично масштабироваться под растущее число запросов от ИИ-агентов. Платформа устанавливается в инфраструктуре заказчика и работает как на собственных серверах, так и в частных, публичных и гибридных облаках. Она поддерживает ролевые и атрибутные политики доступа и разграничение доступа на уровне отдельных строк и колонок. С продуктами Positive Technologies у нее есть встроенные возможности интеграции, сторонние средства защиты подключаются через открытые протоколы.</p> Positive Technologies представила коммерческую версию PT Security Lakehouse, решения для хранения и анализа больших … message https://www.itweek.ru/themes/detail.php?ID=235752 Fri, 16 Oct 2026 14:25:33 +0300 <p>46% крупнейших российских компаний стремятся уйти от закупок впрок и выжимать максимум из имеющегося оборудования на фоне ужесточения требований к окупаемости ИТ-проектов. Об этом говорят результаты совместного исследования аналитического портала «ИТ-инфраструктура» и разработчика ПО Orion soft, которое представили на ИТ-конференции «Большая игра».</p> <p>В исследовании приняли участие ИТ-руководители 120 российских компаний с выручкой от 2 млрд рублей из нефтегазовой, промышленной, финансовой, телекоммуникационной отраслей, ритейла. Был проведен анализ более 3000 открытых тендеров в области ИТ-инфраструктуры, а также 14 глубинных интервью CIO, CTO и директоров по инфраструктуре крупнейших компаний.</p> <p>Основным вызовом развития инфраструктуры в 2026 году стала средняя стоимость вычислительного оборудования, которая с 2022 по 2025 годы повысилась на 209%. Кратный рост вызван общим удорожанием компонентов, дефицитом отдельных деталей и переходом на российские серверы, которые в среднем на <nobr>30–50%</nobr> дороже зарубежных аналогов. Темпы роста цен на «железо» опередили увеличение бюджетов: сегодня компании могут закупить на 35% меньше оборудования по сравнению с 2020 годом.</p> <p>Значимым фактором подорожания оборудования стал бум внедрения ИИ. Отдельный бюджет на него есть у 44% компаний, выделенная инфраструктура — у 34%. При этом с каждым новым поколением GPU стоимость ИИ-серверов увеличивается, а устаревающие модели не всегда подходят под новые нагрузки и большие языковые модели. Это приводит к постоянно растущему спросу на все более дорогостоящие модели оборудования.</p> <p>Основной задачей Enterprise-сегмента в сложившейся ситуации становится переход от наращивания мощностей к более эффективному управлению ими. 43% технических лидеров считают, что самый перспективный способ сократить затраты на «железо» — повышение утилизации уже имеющегося парка оборудования. Средний уровень утилизации среди компаний-участников исследования составил 54%: половина их ресурсов простаивает без полезной нагрузки. </p> <p>Наиболее экономически эффективной является утилизация на уровне <nobr>80-85%,</nobr> которая достижима при автоматическом перераспределении ресурсов. При этом 69% компаний не отслеживают утилизацию системно или делают это крайне редко, раз в <nobr>9-12 месяцев,</nobr> а те, кто делает это, зачастую используют неэффективные методы, например, вручную рассчитывают утилизацию в Excel или проводят разовые поиски неудаленных ресурсов.</p> <p>Максимальное использование имеющегося оборудования стало основной стратегией рынка в «годы эффективности» — 46% компаний пытаются повысить утилизацию и продлить срок службы текущего парка серверов. Второй по популярности стратегией стала более строгая приоритизация ИТ-проектов — 26% компаний замораживают или отменяют проекты с низким ROI или высокой капиталоемкостью. Помимо них в топ-5 стратегий эффективного управления инфраструктурой вошли гибкие модели закупок и ставка на HaaS-инфраструктуру, использование инфраструктурных платформ для автоматизации управления ресурсами, а также дифференциация требований к надежности и мощности под разные типы систем.</p> <p>Основным инструментом объединения всех пяти стратегий и управления ими стало частное облако — оно является ключевой платформой для 38% крупнейших компаний с выручкой больше 500 млрд рублей. Ключевые преимущества его внедрения, по мнению технологических лидеров, — повышение управляемости и безопасности инфраструктуры, стандартизация конфигурации и окружений, повышение утилизации существующего парка оборудования. </p> <p>«В 2026 году частное облако становится инструментом повышения экономической эффективности инфраструктуры. Оно централизует управление мощностями, и становится понятно, кто, как и чем пользуется. Биллинг становится одним из стимулов не тратить лишнее, а когда новую инфраструктуру можно быстро создать, ненужный ресурс становится проще выключить или удалить. Это все приводит к тому, что оборудование утилизируется эффективнее. Целевая утилизация зависит от конкретной системы, но, например, в наших кейсах мы приходили к уровню <nobr>80–85%», —</nobr> рассказал Сергей Мерещенко, руководитель направления Orion Private Cloud Orion soft.</p> <p>«В год оптимизации бюджетов главный вопрос — как получать максимальную отдачу от уже сделанных инвестиций: в управлении инфраструктурой, в распределении мощностей и ресурсов. Для этого нужны прозрачные метрики и стандартизированные процессы: вложения следует оценивать через четкие KPI и измеримые критерии отдачи, чтобы бизнес мог принимать обоснованные решения», — подчеркнула Елена Ляховицкая, советник по развитию АНО «Исследовательский центр «ИТ-Атлас». </p> 46% крупнейших российских компаний стремятся уйти от закупок впрок и выжимать максимум из имеющегося оборудования … message https://www.itweek.ru/themes/detail.php?ID=235751 Fri, 16 Oct 2026 14:21:14 +0300 <p>Провайдер решений в области кибербезопасности и доставки контента CURATOR представил систему управления безопасным доступом (IdP) CURATOR.IDENTITY. Решение разработано совместно с российским разработчиком систем аутентификации и управления доступом Avanpost и встроено в облачную экосистему CURATOR. Клиенты могут управлять DDoS-защитой, безопасностью веб-приложений, поиском уязвимостей и защищённым доступом к корпоративным системам в едином личном кабинете.</p> <p>CURATOR.IDENTITY позволяет компаниям-клиентам облачной экосистемы CURATOR быстро запускать многофакторную аутентификацию (MFA) и единый вход (SSO), усиливать контроль устройств и пользовательских сессий, а также последовательно выстраивать архитектуру защищённого доступа — от базовой MFA до зрелых сценариев Zero Trust. Решение защищает доступ к веб-приложениям, VPN, корпоративным порталам, инфраструктурным сервисам, а также desktop- и legacy-приложениям. Централизованные политики аутентификации и доступа помогают снизить риски компрометации учётных записей, кражи пользовательских сессий и несанкционированного доступа к критически важным системам.</p> <p>Современные атаки все чаще начинаются не с классического взлома внешнего периметра: украденные логины и пароли, скомпрометированные токены, cookie или перехваченные сессии позволяют злоумышленнику получить доступ к системам под видом легитимного пользователя. В результате даже компании с выстроенной сетевой защитой, WAF и мониторингом остаются уязвимы: злоумышленник может войти в систему как обычный сотрудник, подрядчик или администратор. CURATOR.IDENTITY закрывает подобный риск за счёт централизованного управления доступом, усиленной аутентификации, единого входа, контроля сессий и учёта контекста входа — пользователя, группы, IP-адреса, устройства и сценария доступа.</p> <p>Решение CURATOR.IDENTITY работает по модели облачного SaaS: оно подключается из облака CURATOR и не требует развёртывания отдельной инфраструктуры на стороне клиента. Для безопасного подключения внутренних систем может использоваться компонент Access Bridge, который связывает облачную платформу с инфраструктурой клиента без публикации внутренних сервисов в интернете. CURATOR.IDENTITY поддерживает стандартные протоколы и сценарии интеграции с корпоративной инфраструктурой, включая OpenID Connect, SAML, RADIUS и LDAP, а также работу с ADFS и Keycloak.</p> <p>«Объединение экспертизы Avanpost в управлении доступом и аутентификации с облачной инфраструктурой CURATOR даёт клиентам возможность запустить MFA и SSO без тяжёлого on-premise проекта и постепенно двигаться к модели Zero Trust. Для бизнеса это означает более быстрый результат и меньшую нагрузку на ИТ-команду», — отметила Алина Куракина, генеральный директор Avanpost.</p> <p>«Периметр перестал быть единственной точкой входа для атакующих. Даже хорошо защищённая инфраструктура остаётся уязвимой, если злоумышленник получает возможность войти в неё с легитимной учётной записью. Партнёрство с Avanpost расширяет наш подход к обеспечению безопасности: наши клиенты получают не только защиту от DDoS-атак и уязвимостей на периметре, но и контроль над тем, кто и как получает доступ к их корпоративным системам», — прокомментировал Дмитрий Ткачёв, генеральный директор CURATOR. </p> Провайдер решений в области кибербезопасности и доставки контента CURATOR представил систему управления безопасным … message https://www.itweek.ru/themes/detail.php?ID=235750 Fri, 16 Oct 2026 14:19:32 +0300 <p>Компания Avanpost, российский разработчик решений для управления доступом и защиты цифровых идентичностей, объявила о запуске в коммерческую эксплуатацию Avanpost Identity Cloud, облачного сервиса для защищенного доступа корпоративных ресурсов для сотрудников и подрядчиков на базе безопасной облачной архитектуры. До этого сервис проходил тестирование с 1 июня по 1 октября 2026 года. </p> <p>Avanpost Identity Cloud представлен для MSSP-партнеров в двух вариантах: сервис-провайдер и реселлер. Модель «сервис-провайдер» предусматривает развертывание автоматизированного комплекса Avanpost Identity Cloud в экосистеме партнера: он осуществляет эксплуатацию, администрирование и работу с заказчиками с помощью готовых бизнес-инструментов (личного кабинет, биллинга) и технологических решений (независимого тенанта для каждого клиента, архитектурного компонента Access Bridge). Партнер может продавать сервисы под своим брендом, все технологические и административные инструменты предоставляются партнеру в пакете. Эта модель позволяет компаниям, для которых сфера информационной безопасности не является профильным бизнесом, работать на этом рынке с минимальными вложениями, повышая монетизацию существующей клиентской базы. Для Avanpost такой формат сотрудничества охватает новые, более массовые сегменты корпоративного рынка и открывает путь к клиентам, которых объединяет экосистема бренда партнера. Вторая программа, реселлер, подразумевает продажу лицензий сервисов, развернутых непосредственно в облаке Avanpost Identity Cloud. </p> <p>Avanpost Identity Cloud cоздан на базе решений Avanpost IAM (Identity Access Management), которым доверяют более 150 крупнейших компаний России с геораспределенной инфраструктурой и высокими требованиями к кибербезопасности и отказоустойчивости. Возможности и архитектурные принципы корпоративного решения перенесены в облако без потери уровня защиты. Для каждого клиента разворачивается независимый тенант: отдельный контур, база данных и политики доступа. Инциденты, ошибки конфигурации или пиковые нагрузки у одного клиента не влияют на других. Архитектурный компонент Access Bridge обеспечивает простую и защищённую интеграцию платформы Avanpost Identity Cloud с корпоративными системами заказчика, сохраняя полный контроль над данными и периметром безопасности. Для непрерывной работы при сбоях связи реализована офлайн-аутентификация. Сервисные учетные записи и инфраструктурные секреты не требуют публикации наружу и остаются внутри контролируемого контура. </p> <p>C Avanpost Identity Cloud IAM-решения стали доступнее для массового сегмента бизнеса. Благодаря облачной модели для организации снимаются барьеры по внедрению IAM-проекта: отсутствие ресурсов, сложные интеграции и высокие цены на внедрение. При этом, безопасность соответствует enterprise-практикам. Сам сервис построен как ступенчатая модель: любая компания может стартовать с защиты второго фактора для ключевых приложений и без смены платформы дорастать до Zero Trust подхода по мере зрелости и появления новых задач бизнеса. Стоимость подписки на Avanpost Identity Cloud составляет от 168 рублей в месяц за одного пользователя, а время на подключение составляет от 15 минут. </p> <p>Провайдер решений в области кибербезопасности и доставки контента CURATOR оценил потенциал Avanpost Identity Cloud как драйвера рынка защиты identity и развернул в своей облачной инфраструктуре решение под брендом CURATOR IDENTITY для управления безопасным доступом и аутентификацией (IdP) как дополнительный сервис для своих клиентов. </p> <p>Ключевые архитектурные особенности сервиса Avanpost Identity Cloud</p> <ul> <li>изоляция тенантов. Для каждого клиента разворачивается независимый tenant: отдельный контур, база данных и политики доступа. Инциденты, ошибки конфигурации или пиковые нагрузки у одного клиента не влияют на других. Уровень изоляции сопоставим с выделенным on-premise решением, но без затрат на собственную инфраструктуру;</li> <li>компонент Access Bridge обеспечивает защищённую интеграцию Avanpost Identity Cloud с корпоративными системами заказчика, сохраняя полный контроль над данными и периметром безопасности;</li> <li>гибкость развёртывания. Решение отличается гибкостью развертывания и адаптируется под любую архитектуру — от централизованной до распределённой в изолированных сегментах;</li> <li>непрерывность бизнеса. Поддержка офлайн-аутентификации гарантирует непрерывность бизнес-процессов даже при сбоях связи, а централизованное управление из единой административной консоли значительно упрощает внедрение и эксплуатацию;</li> <li>простота внедрения. Централизованное управление через единую административную консоль реализует принцип plug-and-play, исключая необходимость ручной настройки локальных компонентов и значительно упрощая внедрение;</li> <li>безопасность. Критически важные секреты приложений (LDAP, RADIUS) обрабатываются исключительно внутри контура заказчика и не передаются за его пределы, обеспечивая высокий уровень безопасности.</li> </ul> <div><br/> </div> Компания Avanpost, российский разработчик решений для управления доступом и защиты цифровых идентичностей, объявила … message https://www.itweek.ru/themes/detail.php?ID=235746 Fri, 16 Oct 2026 12:42:07 +0300 <p><em>Новые западные модели с открытыми весами могут предоставить предприятиям альтернативу китайскому и проприетарному ИИ, но больший контроль также влечет за собой новую ответственность, считают опрошенные порталом </em><em>AI</em> <em>Business</em> <em>эксперты.</em></p> <p>Предприятиям, стремящимся размещать, настраивать и управлять собственным ИИ, все чаще приходится сопоставлять гибкость моделей с открытыми весами от китайских компаний с проприетарными западными моделями, которые предоставляют поставщикам больший контроль над разработкой и развертыванием моделей.</p> <p>Но этот выбор начал расширяться. Компания Reflection AI, поддерживаемая Nvidia, недавно запустила свою модель Beam с открытыми весами, а французская ИИ-лаборатория Mistral представила свою новую модель Large 4, предоставив предприятиям новые западные варианты на рынке моделей с открытыми весами.</p> <p>Для предприятий важность этих запусков выходит за рамки того, как модели показывают себя в бенчмарках. Если модели окажутся достаточно эффективными, они могут предоставить организациям, которые избегали китайских систем из-за вопросов безопасности, обработки данных, происхождения, юрисдикции или соответствия нормативным требованиям, западную альтернативу для рабочих нагрузок, которые они хотят запускать на основе моделей с открытыми весами.</p> <p>«Главное изменение заключается в том, что модели с открытыми весами становятся реальным вариантом закупок для западных предприятий, а не просто чем-то, с чем экспериментируют исследовательские группы, — говорит Джит Паттанаик, основатель и технический директор Glokal AI, поставщика решений для корпоративного ИИ. — Это смещает вопрос с того, могут ли предприятия использовать модели с открытыми весами, на то, какие рабочие нагрузки им следует на них запускать».</p> <p>По его словам, до сих пор самые сильные модели с открытыми весами были в основном китайскими, что создавало проблемы для таких организаций, как банки, страховые компании и государственные органы, которые сталкиваются с ограничениями, связанными с происхождением моделей и соответствием нормативным требованиям.</p> <h3>Лидерство Китая в области открытых моделей не будет вечным</h3> <p>Китайские компании заняли лидирующие позиции в области ИИ с открытыми весами, при этом модели от Alibaba, DeepSeek, Moonshot и Z.ai набирают популярность благодаря своим возможностям и относительно низким операционным расходам.</p> <p>Counterpoint Research <a href="https://counterpointresearch.com/ins...et-q3-2024/insights/Moonshot-AI-Kimi-K3-shockwave-chinese-dominate-open-frontier-models">определила</a> китайские модели, включая Kimi и GLM, как одни из лучших систем с открытыми весами на рынке.</p> <p>Принс Коли, президент и генеральный директор Sauce Labs, облачной платформы для тестирования ПО, работающей с поставщиками моделей с открытыми весами, считает, что раннее лидерство китайских разработчиков отчасти обусловлено необходимостью. Ограниченность ресурсов подтолкнула их к снижению затрат и повышению эффективности оборудования, в то время как западные компании, занимающиеся ИИ, сосредоточили больше ресурсов на производительности передовых моделей.</p> <p>«Это дало китайским разработчикам ранний старт и, следовательно, преимущество в соотношении цены и производительности, а также в экспериментах с моделями с открытыми весами», — отмечает Коли.</p> <p>Он ожидает, что разрыв между западными и китайскими моделями будет сокращаться по мере того, как все больше инженерных ресурсов западных стран будет направляться на оптимизацию. «Ничто принципиально не мешает западным разработчикам вносить те же улучшения в снижение затрат и производительность оборудования, которые дали китайским моделям раннее преимущество», — считает Коли.</p> <p>Хотя модели с открытыми весами по-прежнему нуждаются в независимом тестировании, им не обязательно лидировать во всех бенчмарках, чтобы быть полезными для предприятий. «Они должны быть достаточно производительными для конкретных рабочих нагрузок и предлагать жизнеспособную альтернативу проприетарным моделям», — отмечает Коли.</p> <p>Для предприятий значение моделей с открытыми весами выходит за рамки производительности. Речь также идет о том, что они могут делать с моделью после ее развертывания.</p> <h3>Контроль важнее стоимости</h3> <p>Для предприятий привлекательность открытого ИИ часто заключается в большей автономии, а не в снижении стоимости. С моделью с открытыми весами компания может запускать систему в своей собственной среде, хранить конфиденциальные данные в этой среде и решать, когда обновлять модель до новой версии. Она также может дорабатывать модель, используя собственные данные.</p> <p>Коли отмечает, что самостоятельное развертывание особенно важно, поскольку оно дает предприятиям больший контроль над своими данными, что может быть критически важно в оборонном, государственном и высокорегулируемых секторах. «Тонкая настройка позволяет предприятиям адаптировать модели, используя частные, специфические для предметной области данные, создавая возможности ИИ, которые они могут контролировать как интеллектуальную собственность», — говорит он. Организации также могут устанавливать собственные политики обновления и вывода моделей из эксплуатации, снижая риски внезапных изменений производительности или качества.</p> <p>Стоимость по-прежнему может иметь значение при больших и стабильных объемах, но, как отмечает Паттанаик, если предприятия учитывают расходы на графические процессоры, персонал и оценку, модели с открытыми весами не обязательно дешевле для небольших рабочих нагрузок.</p> <p>Главный вопрос заключается в том, насколько самостоятельно предприятия могут управлять частью стека ИИ, что также делает важным аспект переносимости. «Устранение зависимости приложений, промптов и логики ИИ от какого-либо одного поставщика моделей упрощает переключение между моделями при изменении потребностей», — говорит Паттанаик.</p> <p>По его словам, предприятия также могут использовать разные модели для разных задач: меньшую открытую модель для больших объемов рутинных рабочих нагрузок и проприетарную передовую модель для задач, требующих более сложных рассуждений.</p> <p>Но больший контроль также означает большую ответственность. Открытые веса — в отличие от общедоступных данных обучения, предлагаемых системами с полностью открытым исходным кодом — не обязательно обеспечивают прозрачность того, как была обучена модель или какие данные использовались для ее создания. Компания может контролировать, где работает модель, но не иметь возможности полностью проверить, что находится внутри модели.</p> <p>Лицензирование также различается, поэтому условия, регулирующие коммерческое использование, модификацию и распространение, становятся важной частью оценки модели предприятием. Организации, использующие собственные модели, также берут на себя больше ответственности за безопасность, оценку производительности, обновления и управление.</p> <p>«Вы не можете проверить вероятность, поэтому элементы управления должны находиться вне модели, независимо от того, открыта она или закрыта», — говорит Паттанаик.</p> <p>Таким образом, открытые веса не являются кратчайшим путем для обеспечения управления ИИ. Предприятиям по-прежнему необходимы элементы контроля модели для обеспечения безопасности, оценки, обновлений и других процессов управления.</p> <h3> Истинной проверкой является внедрение на предприятии </h3> <p>Reflection AI и Mistral не обязательно должны постоянно обгонять китайских разработчиков, чтобы предприятия могли извлечь выгоду из более сильного западного открытого рынка. Их успех будет зависеть от того, найдут ли предприятия модели достаточно производительными, надежными и заслуживающими доверия для реальных рабочих нагрузок.</p> <p>Это может изменить подход предприятий к закупкам моделей. Вместо того, чтобы выбирать между проприетарными западными моделями и китайскими моделями с открытыми весами, организации могут использовать более широкий набор моделей в зависимости от рабочей нагрузки, нормативных требований и необходимого им уровня контроля.</p> <p>Коли ожидает, что по мере сближения возможностей западных и китайских моделей, более важную роль во внедрении будут играть другие факторы, включая качество, надежность, стоимость и доверие. По его словам, как только стоимость токенов станет достаточно близкой, у предприятий будет больше оснований оценивать, насколько стабильно работают модели и могут ли они полагаться на политику поставщика и происхождение данных.</p> <p>«Предприятиям нужны предсказуемые результаты, высокая производительность в сложных сценариях использования и гибкость выбора модели, а не привязка к одному поставщику, — говорит Коли. — Кроме того, они должны доверять источнику данных и политике поставщика».</p> Новые западные модели с открытыми весами могут предоставить предприятиям альтернативу китайскому … article https://www.itweek.ru/themes/detail.php?ID=235744 Fri, 16 Oct 2026 11:55:15 +0300 <p><em>ИИ в кибербезопасности может быть не только <a href="https://www.itweek.ru/security/article/detail.php?ID=235359">мечом</a>, но и щитом. Рассмотрим, как именно он помогает защищать инфраструктуру, приложения и данные.</em></p> <h3>Хайпа нет, полет нормальный</h3> <p>Искусственный интеллект вошел в арсенал информационной безопасности не вчера и не сегодня. Пока защита самих ИИ-систем становится отдельным направлением рынка, а использование ИИ злоумышленниками активно обсуждается, машинное обучение в средствах защиты давно стало привычным инструментом. Модель в продукте сама по себе уже мало кого удивляет. Заказчику важнее не то, используется ли внутри ИИ, а какую задачу он решает: помогает ли быстрее обнаруживать угрозы, снижать нагрузку на аналитиков или точнее выделять подозрительную активность. И отсутствие ажиотажа здесь скорее хороший знак. На первый план выходит результат, который можно измерить.</p> <p>Особенно заметен этот эффект там, где приходится работать с большими потоками событий. Например, SIEM собирает и сопоставляет данные из разных источников, а NGFW анализирует сетевой трафик и применяет политики безопасности. Модели машинного обучения могут дополнять традиционные правила: выявлять аномалии, находить нетипичные последовательности действий и помогать расставлять приоритеты среди срабатываний. Но обещать, что одна только модель автоматически повысит и скорость, и точность, было бы неправильно. Результат зависит от качества данных, выбранного сценария и того, как модель встроена в продукт. Сильный эффект появляется тогда, когда аналитик тратит меньше времени на шум и больше — на действительно значимые события.</p> <p>Еще одно направление — безопасность приложений. Инструменты статического анализа исходного кода (SAST) могут выдавать много находок, которые требуют дополнительной проверки. Здесь ИИ полезен для первичного разбора: он помогает группировать схожие результаты, учитывать контекст кода, предполагать вероятность ложного срабатывания и формировать очередь для проверки специалистом. Вместо неструктурированного перечня из сотен находок команда получает более понятную картину рисков. Важная оговорка: низкий приоритет не означает, что уязвимости точно нет. Поэтому автоматически отбрасывать результаты только на основании вывода модели нельзя, особенно когда речь идет о критичных приложениях.</p> <p>Отдельная тема — ложные срабатывания. Иногда можно услышать, что ИИ обязательно делает детектирование менее предсказуемым, но и обратное обещание, будто модель сама устранит весь шум, столь же неверно. Ложные срабатывания и пропущенные угрозы возможны как у правил, так и у моделей. Их соотношение зависит от данных, порогов детектирования, условий эксплуатации и регулярной проверки качества. Поэтому оценивать ИИ нужно не по красивой демонстрации, а по метрикам в реальной среде: сколько полезных сигналов он выделил, сколько ложных тревог добавил и что мог пропустить.</p> <h3>Сначала — цель, потом — внедрение</h3> <p>Несмотря на зрелость отдельных сценариев машинного обучения в киберзащите, внедрение ИИ не гарантирует улучшения продукта. Модель может решить действительно дорогую для заказчика задачу, а может добавить задержки, стоимость эксплуатации, новые зависимости и риски без заметной пользы. Поэтому начинать нужно с простого вопроса: какую именно проблему мы собираемся решить? А уже затем выбирать технологию и определять, как измерим результат.</p> <p>На практике обычно сталкиваются два подхода. Первый — внедрить ИИ, потому что он уже есть у конкурентов. Второй — увидеть конкретную проблему: например, аналитики слишком долго разбирают однотипные срабатывания, а разработчики теряют время на ручную сортировку находок. И только после этого проверить, поможет ли здесь модель. Причем иногда достаточно правил, статистических методов или давно проверенных алгоритмов машинного обучения. Большая языковая модель (LLM) нужна далеко не в каждом сценарии: для детектирования аномалий и для понятного объяснения срабатывания пользователю могут потребоваться совершенно разные решения.</p> <p>Именно на этой развилке продуктовые команды часто ошибаются. Если добавлять LLM ради самого факта ее наличия, легко получить усложнение архитектуры, рост стоимости и задержек, а также дополнительные требования к безопасности и контролю качества ответов. У ИИ может быть и вспомогательная роль, и самостоятельная продуктовая функция. Вопрос в другом: становится ли защита лучше для конкретного пользователя? Если мы можем показать, что сократилось время расследования, улучшилась приоритизация уязвимостей или снизилась доля бесполезных срабатываний без неприемлемого роста пропусков, внедрение имеет смысл. Если таких результатов нет, самая современная модель остается лишь дорогой галочкой в списке возможностей продукта.</p> <p>#IMAGE_235745#</p> ИИ в кибербезопасности может быть не только мечом, но и щитом. Рассмотрим, как именно он помогает … article Светлана Газизова, владелец продукта по безопасности ИИ в компании UserGate https://www.itweek.ru/themes/detail.php?ID=235741 Thu, 15 Oct 2026 15:44:23 +0300 <p>Институт статистических исследований и экономики знаний (ИСИЭЗ) НИУ ВШЭ продолжает изучать практики применения ИИ в ключевых отраслях промышленности и связанные с этим эффекты, в частности для кадровой политики. Как показал анализ, в химической промышленности ключевую роль играет безопасность: ИИ применяют чаще всего на отдельных участках производства в рамках четких ограничений, а системно развивают кадровый потенциал в области ИИ лишь немногие предприятия.</p> <p>Наиболее востребованы на предприятиях химпрома ИИ-решения для обработки визуальных данных и текста (их используют 10,7% и 10,5% обследованных организаций соответственно). Заметно реже применяют передовые решения, к которым относятся большие языковые / генеративные модели (6%) и ИИ-агенты (1,6%). Среди организаций, планирующих внедрение ИИ или считающих его перспективным, наибольший потенциал видят в приложениях для интеллектуальной поддержки принятия решений и управления (32,7%).</p> <p>В химической промышленности ИИ применяют главным образом для моделирования продукции и процессов (более 40% организаций, использующих ИИ) и управления оборудованием <nobr>(28–33%).</nobr> В отраслевом разрезе общий профиль применения сходен, но есть и некоторые отличия: промышленная безопасность входит в число наиболее распространенных задач применения ИИ производителей химических веществ и продуктов (28,2%), а логистика и хранение — производителей резиновых и пластмассовых изделий (27,9%). Среди потенциальных областей применения ИИ чаще всего называют диагностику оборудования и предупреждение поломок (58,2 %). Эти задачи относятся к предиктивной аналитике — одному из наиболее быстрорастущих направлений мировой химической промышленности.</p> <p>К моменту проведения обследования эффекты от применения ИИ получили почти четверть предприятий химпрома, использующих технологию. Из основных результатов — улучшение качества и потребительских характеристик продукции, включая возможность адаптировать ее с учетом географии поставок, запросов потребителей, регуляторных норм и других требований. Каждое пятое предприятие-пользователь отметило снижение потребления ресурсов, в том числе энергетических. В ближайшие годы более двух третей предприятий рассчитывают с помощью ИИ сократить брак и число поломок, снизить аварийность и повысить производительность оборудования.</p> <p>К наиболее быстро проявляющимся кадровым эффектам от внедрения ИИ в химической промышленности относятся экономия времени работников и автоматизация рутинных задач: их отметили около четверти обследованных организаций-пользователей ИИ. Усиления этих эффектов в среднесрочной перспективе ожидают три из пяти предприятий, начавших внедрение ИИ. Предприятий, прогнозирующих рост численности персонала под влиянием ИИ, вдвое больше ожидающих сокращения штатов. Крупные организации реже других видят в ИИ угрозу занятости, в отраслевом разрезе такую оценку реже всего дают производители лекарственных средств и материалов, применяемых в медицинских целях и ветеринарии. Наиболее благоприятная ситуация на рынке труда химической промышленности, ожидаемо, складывается для специалистов по ИКТ и занятых непосредственно в производстве и разработке продукции. Наиболее пессимистично организации оценивают перспективы служащих, занятых подготовкой и оформлением документации, учетом и обслуживанием.</p> <p>У трети предприятий химпрома, использующих ИИ, есть собственные разработчики ИИ-приложений и аналитики ПО. Однако численность таких специалистов, как правило, недостаточна. Политику по развитию кадрового потенциала в области ИИ проводит лишь небольшая часть компаний химпрома. Только каждая пятая поощряет использование ИИ на рабочем месте. Еще более редкая практика — взаимодействие с образовательными учреждениями, готовящими специалистов с навыками работы с ИИ.</p> <p>Для предприятий химической промышленности важна не только ожидаемая отдача от ИИ, но и возможность безопасно встроить его в сложные и зачастую опасные производственные процессы. Почти две трети организаций, уже использующих ИИ, считают безопасность ИИ-систем критически важным условием расширения их применения. Она предполагает, в частности, стабильность работы систем и их устойчивость к внешним воздействиям. В общей выборке обследованных организаций химпрома почти четверть отмечают среди условий внедрения появление инструментов обеспечения безопасности ИИ-систем и оценки их соответствия установленным требованиям (например, сертификацию решений); около трети — повышение рентабельности основной деятельности.</p> Институт статистических исследований и экономики знаний (ИСИЭЗ) НИУ ВШЭ продолжает изучать практики применения ИИ … message https://www.itweek.ru/themes/detail.php?ID=235740 Thu, 15 Oct 2026 15:40:33 +0300 <p>Cloud.ru, провайдер облачных сервисов и ИИ-технологий, представил RepoWiki — новую функцию в составе сервиса Evolution Repo, которая автоматически анализирует кодовую базу и формирует структурированную документацию проекта.</p> <p>Evolution Repo — облачный сервис для хранения репозиториев кода, <nobr>ML-моделей</nobr> и датасетов. Сервис хранит модели и датасеты в одном хранилище и помогает управлять большими файлами через Git LFS, версионировать <nobr>ML-модели</nobr> и просматривать файлы-тензоры. Синхронизация и обмен артефактами работает через API, совместимое с популярной библиотекой моделей Hugging Face.</p> <p>RepoWiki встроен непосредственно в облачный репозиторий. Разработчикам больше не нужно переносить код в сторонний ИИ-сервис: репозиторий, документация и работа с кодовой базой теперь собраны в едином пространстве. Сервис работает на базе Evolution ManagedRAG и AI Agents. Перед генерацией самой документации пользователю на согласование отправляется предварительный список разделов и страниц, который можно редактировать. </p> <p>Обычно, приступая к новой задаче, разработчику или ИИ-агенту необходимо погрузиться в контекст: понять, что делает проект, как устроена архитектура, где находится нужный код. Если проект не подготовлен заранее, возникают ограничения: агент видит отдельные файлы, но не понимает их роль в системе, не осознает неявные зависимости, а контекстное окно не позволяет охватить кодовую базу целиком.</p> <p>RepoWiki устраняет эти ограничения: система самостоятельно анализирует структуру проекта, выявляет взаимосвязи между модулями и генерирует документацию, которая отражает реальное устройство кодовой базы. При использовании RepoWiki ручная работа с документацией сокращается в среднем на 30% (по результатам тестов на реальных проектах).</p> <p>С технической точки зрения, RepoWiki использует мультиагентный подход к созданию документации. Внутри системы анализ кода разбивается на последовательные этапы: планирование, анализ архитектуры, написание и верификация содержимого. Это помогает обрабатывать проекты масштаба крупных корпоративных репозиториев, где единовременный анализ всей кодовой базы невозможен из-за ограничений контекстного окна. Решение поддерживает инкрементные обновления: при изменении кода документация обновляется, а не создается заново.</p> <p>Функция поможет разработчикам, изучающим незнакомые модули или подключающимся к существующим проектам: RepoWiki сокращает время входа в контекст и рабочую нагрузку. Техническим лидерам и руководителям, организующим передачу знаний функция поможет для управления знаниями, снижения риски ухода ключевых сотрудников и ускорения адаптации команды.</p> <p>«С RepoWiki вместо того, чтобы вручную описывать модули, поддерживать актуальность файлов и собирать знания по крупицам из комментариев и переписок, ИТ-команда получает автоматически сгенерированное описание проекта. Разработчик может задавать вопросы по кодовой базе в чате вместо изучения десятков разрозненных файлов. Это особенно ценно при работе с незнакомыми модулями, при подключении к существующим проектам и при разборе legacy-кода, где документация либо отсутствует, либо давно устарела», — сказала директор блока разработки платформы Cloud.ru Evolution Анастасия Тафеенко.</p> Cloud.ru, провайдер облачных сервисов и ИИ-технологий, представил RepoWiki — новую функцию в составе сервиса … message https://www.itweek.ru/themes/detail.php?ID=235739 Thu, 15 Oct 2026 10:40:24 +0300 <p><em>На октябрьской конференции Open Source Summit Europe 2026 в Праге неоднократно звучал один и тот же тезис: организации и правительства, которые просто используют </em><em>Open</em> <em>Source</em><em>, остаются зависимыми от других в формировании своего будущего. Те, кто управляет, поддерживает, обеспечивает безопасность и развивает экосистемы </em><em>Open</em> <em>Source</em><em>, получают влияние, устойчивость, суверенитет и стратегическое преимущество. Дискуссия о суверенитете развивается как внутри, так и за пределами сообщества </em><em>Open</em> <em>Source</em><em>: вопрос не в том, как защитить себя от внешней зависимости, а в том, как стать незаменимым участником экосистем, от которых зависит цифровое будущее, пишет в корпоративном блоге Дарио Маисто, главный аналитик </em><em>Forrester</em><em>.</em></p> <h3>Open Source стал критически важной инфраструктурой</h3> <p>Open Source больше не является просто моделью разработки. Он лежит в основе облачных платформ, систем искусственного интеллекта, инструментов кибербезопасности и цифровых государственных услуг. Тем не менее, многие проекты, поддерживающие цифровую экономику, по-прежнему зависят от небольших групп разработчиков, которые сталкиваются с растущим давлением со стороны угроз кибербезопасности, управления уязвимостями, необходимости соответствия нормативным требованиям и ожиданий сообщества.</p> <p>Одной из повторяющихся проблем, отмеченных на саммите, была устойчивость работы сопровождающих проектов (мейнтейнеров). Нагрузка на безопасность продолжает расти, в то время как многим проектам не хватает достаточной поддержки. Документация стала важной проблемой. Мейнтейнеры неоднократно отмечали, что улучшенная документация снижает трудозатраты, повышает уровень внедрения проектов и позволяет сосредоточить ограниченные ресурсы на более ценной работе.</p> <p>Если Open Source является критически важной инфраструктурой, его поддержка должна стать общей ответственностью, а не бременем нескольких добровольцев.</p> <h3>Суверенитет требует участия, а не изоляции</h3> <p>Саммит подтвердил тезис, который Forrester распространяет уже довольно давно: суверенитет не достигается изоляцией. Сильные нации и организации не уходят из экосистем. Они вносят в них свой вклад, формируют их и помогают управлять ими. Другими словами, влияние имеет такое же значение, как и контроль.</p> <p>Одна из наиболее убедительных концепций, представленных на саммите, описывает четыре составляющих суверенитета:</p> <ol> <li><strong>целостность:</strong> защита данных и обеспечение доверия;</li> <li><strong>устойчивость:</strong> сокращение уязвимостей и укрепление операций;</li> <li><strong>непрерывность:</strong> поддержание контроля над инфраструктурой и цепочками поставок;</li> <li><strong>взаимозависимость:</strong> укрепление внутренних сильных сторон при участии в глобальных экосистемах в качестве равноправного партнера.</li> </ol> <p>Основные выводы о суверенитете и Open Source:</p> <ul> <li><strong> Вклад без управления создает разрыв.</strong> Вот статистика, которая нашла отклик на протяжении всего мероприятия: Европа вносит примерно 40% вклада в деятельность Open Source-проектов, оставаясь при этом недостаточно представленной в структурах управления и лидерства. Это расхождение имеет значение. Вклад в код ценен, но управление определяет направление проекта, приоритеты финансирования, инвестиции в безопасность и долгосрочные планы развития.</li> <li><strong> Активное участие обеспечивает умножение отдачи.</strong> Организации, стремящиеся к большему цифровому суверенитету, должны измерять не только то, сколько открытого исходного кода они потребляют или в который вносят вклад, но и то, участвуют ли они в фондах, руководящих комитетах, программах поддержки и инициативах по лидерству в экосистеме. Активное участие обеспечивает умножение отдачи. Оно создает влияние, которое выходит за рамки строк кода и становится источником рычага воздействия.</li> <li><strong> Поддержка апстрима создает бóльшую ценность, чем поддержка частных форков.</strong> Докладчики неоднократно подчеркивали, что организации не могут пассивно обеспечивать безопасность цепочек поставок ПО. Внесение исправлений, финансирование разработчиков, улучшение документации и участие в управлении укрепляют экосистему для всех. В отличие от этого, поддержка изолированных частных форков может быть дорогостоящей: по оценкам одного из докладчиков, поддержание частного форка может стоить до 250 тыс. евро.</li> <li> <strong>Open</strong> <strong>Source</strong> <strong>не устраняет зависимость автоматически.</strong> Open Source-лицензия может обеспечить прозрачность и переносимость, но она не устраняет зависимость автоматически. Проекты, в которых доминирует один поставщик, по-прежнему могут создавать риск концентрации из-за контроля со стороны управления, влияния на дорожную карту или доминирования в экосистеме. Поэтому технологические лидеры должны оценивать не только лицензии, но и разнообразие участников, модели управления, надзор со стороны фондов и долгосрочную устойчивость.</li> <li> <strong>Open</strong> <strong>Source</strong> <strong>— это стратегическая зависимость, которой необходимо активно управлять.</strong> Цифровой суверенитет теперь является приоритетом на уровне совета директоров, в то время как Open Source-компоненты интегрированы во все современные технологические стеки. Организациям необходима прозрачность в отношении ПО, от которого они зависят, сообществ, которые его поддерживают, и рисков, связанных с критически важными зависимостями.</li> </ul> <h3>Будущее суверенитета в сфере Open Source — за влиянием на экосистему</h3> <p>Появление крупных альянсов в области ИИ, инициатив под эгидой профильных фондов и технологий, ориентированных на работу с ИИ-агентами, указывает на то, что в эпоху ИИ активное участие станет еще более важным. Организации, участвующие в создании, управлении и развитии этих экосистем, получат больше возможностей влиять на стандарты, инновации и вектор развития рынка. Главный вывод конференции Open Source Summit Europe 2026 прост: цифровой суверенитет для Open Source-сообщества определяется тем, что его участники помогают формировать, а не только тем, что они способны контролировать. Будущее принадлежит не тем, кто просто использует Open Source, а тем, кто активно способствует его успеху.</p> На октябрьской конференции Open Source Summit Europe 2026 в Праге неоднократно звучал один и тот же тезис … article https://www.itweek.ru/themes/detail.php?ID=235735 Thu, 15 Oct 2026 10:28:38 +0300 <p><em>С осени 2025 года у Apache Flink есть подпроект Flink Agents, который встраивает нейросети прямо в потоковую обработку данных. Что это меняет и сможет ли нейросеть заменить дежурного инженера?</em></p> <h3>Проблема, которую все знают, но терпят</h3> <p>Типичная ситуация: ночью срабатывает алерт — дежурный инженер должен устранить неполадки. Чтобы добраться до проблемы, ему нужно проснуться, войти во внутреннюю сеть компании, открыть графики и логи, понять, какое приложение сломалось и почему. На это уходит много времени.</p> <p>Решение при этом чаще всего простое: перезапустить приложение, выделить ему больше ресурсов или откатить на предыдущую версию. Почти всё время тратится на подход к исправлению, а не на само решение. На проблему, которую можно было решить за секунды, тратятся десятки минут, иногда дольше.</p> <p>Системы усложняются с каждым годом, связей между приложениями становится больше, и сбой в одном месте всё чаще тянет за собой проблемы в другом. Индустрия вкладывает много сил в отказоустойчивость: системы дублируют и разносят по разным площадкам. А вот реакция на аварию почти не изменилась: дежурный по-прежнему смотрит на проблему своими глазами, разбирается и действует. В такой ситуации он становится «узким местом». Аварии случаются под нагрузкой, когда каждая минута простоя стоит дороже всего. После такой ночи инженер не высыпается и на следующий день работает хуже, поэтому одна авария обходится компании дважды.</p> <h3>Инструкции устаревают быстрее, чем их пишут</h3> <p>Чаще всего дежурному помогают плейбуки. Идея понятная: записать опыт один раз, чтобы им воспользовался любой инженер. Однако плейбук устаревает почти сразу: системы меняются каждую неделю, а инструкции в лучшем случае правят раз в год. Несколькими плейбуками современную систему не покрыть: нужна целая энциклопедия, которую никто не успевает поддерживать.</p> <p>Я не помню, когда последний раз вообще видел плейбуки, но точно знаю: системы, для которых их писали, были гораздо проще и менялись гораздо реже, чем нынешние. На вопрос «А где же ваши плейбуки?» сегодня нередко можно услышать, что их либо нет, либо те, что есть, безнадёжно устарели.</p> <p>Логичный следующий шаг — прикладывать к каждому алерту пояснение, что он означает и что делать. Но на практике этот подход быстро упирается в противоречие:</p> <ul> <li><strong> Узкие алерты</strong> привязаны к конкретной причине. Представим кластер Flink, на котором работают десятки джоб. Каждая может упасть по-своему: ошибка в пользовательском коде, некорректное сообщение в Kafka, потеря соединения с базой данных, нехватка ресурсов, сбой Kubernetes, ошибка JVM. Под каждую причину легко написать инструкцию, но такие ошибки часто приходят группой, и одна проблема — джоба перестала обрабатывать данные — превращается в пять алертов. Внимание дежурного размазывается, и главное теряется в шуме.</li> <li><strong> Общие алерты</strong> описывают симптом, а не причину, например «джоба не обрабатывает данные». На одну проблему приходит один алерт, и дежурный сразу видит, что сломалось. Но к такому алерту уже не напишешь инструкцию: у симптома может быть десяток причин.</li> </ul> <p>Поэтому многие команды в итоге переходят на общие алерты: внимание дежурного не размазывается, а одна проблема — это один сигнал. От формальных инструкций при этом приходится отказаться, и новых дежурных учат через наставничество. Решение неидеальное, но на практике оно работает лучше остальных. Но главная беда никуда не девается: чтобы понять, что случилось, по-прежнему нужно много времени.</p> <h3>Что изменилось</h3> <p>Данных для разбора аварии у инженеров обычно достаточно. Логи приложений стекаются в единую систему передачи сообщений, например Kafka. К ней подключают потоковый обработчик — джобу на Apache Flink, которая читает логи в реальном времени.</p> <p>Раньше такой обработчик выполнял только заранее прописанные реакции: например, если за минуту пришло больше ста ошибок нехватки памяти, перезапусти приложение. Это тот же плейбук, только в коде. Он быстрее бумажного, потому что убирает человека из цепочки, но устаревает так же: система меняется, а правила остаются.</p> <p>Теперь в тот же поток можно встроить языковую модель и дать ей инструменты через MCP (Model Context Protocol) — стандартный протокол, через который модель обращается к внешним системам. Модель понимает текст ошибки, сама запрашивает метрики, историю релизов, состояние приложения в Kubernetes и по ним предлагает, что делать. В этом и состоит сильная сторона нейросетей: они быстро собирают разнородные данные в одну картину.</p> <p>Время реакции сокращается с десятков минут примерно до минуты. Большую часть этого времени занимает накопление событий перед отправкой в модель. Ответ модели и пара обращений к инструментам занимают секунды.</p> <h3>Как это устроено</h3> <p>Разберём на примере <a href="https://flink.apache.org/2026/06/19/apache-flink-agents-0.3.0-release-announcement/">Apache Flink Agents</a> — подпроекта Flink, в котором агент становится обычным шагом потоковой обработки.</p> <p>Если упростить, конвейер состоит из трёх ступеней:</p> <p> #IMAGE_235737#</p> <p><strong>1. Дешёвый предфильтр без модели.</strong> Предфильтр группирует логи из Kafka по приложению и накапливает их в окне на <nobr>30-60 секунд.</nobr> Он сворачивает одинаковые ошибки в одну, считает их частоту, сохраняет начало и конец сообщения об ошибке. В модель уходит одно «происшествие» на приложение вместо тысячи строк лога. Это главный способ сэкономить деньги и время: модель не видит шум, который обычный код отсекает.</p> <p><strong>2. Агент.</strong> Агент состоит из событий и действий. Событие — сигнал, что что-то произошло, например пришло новое происшествие. Действие — небольшой фрагмент логики, который запускается на определённое событие и порождает новое. Для типовых шагов есть готовые события: вход, запрос к модели, ответ модели и выход. Если модели нужны инструменты, фреймворк сам вызывает их и возвращает результат, пока у модели не будет готового ответа.</p> <p>Разработчик описывает всё, чем агент пользуется, отдельно от логики, как набор ресурсов: какая модель, какой промпт, какие инструменты, какие MCP-серверы. Ресурсы выносят в конфигурационный файл и, например, меняют поставщика модели, не трогая код.</p> <p>Фреймворк поддерживает два стиля: workflow-агент, где маршрут задаёт разработчик, и ReAct-агент, где модель сама решает, какой инструмент вызвать следующим. Для аварий удобнее первый: каркас жёсткий, а свободу выбирать инструменты модель получает только на шаге диагностики.</p> <p>Здесь важны три вещи.</p> <ul> <li><strong> Модель сама ничего не меняет.</strong> Ей доступны только инструменты на чтение. Исправление выполняет наш собственный код, и только если предложенное действие есть в белом списке, а лимит не исчерпан. Модель советует, код действует.</li> <li><strong> Ответ модели — в строгом формате.</strong> Модель возвращает заранее описанную структуру: что случилось и какое действие она предлагает. Всё, что код не смог разобрать, автоматически уходит человеку.</li> <li><strong> Действие не выполнится дважды.</strong> Flink Agents запоминает результат действия во внешнем хранилище (Kafka или Apache Fluss), поэтому, если джоба упадёт и восстановится, повторного перезапуска не будет. Для самого неприятного случая, когда перезапуск уже выполнен, а записать результат система не успела, можно задать отдельную проверку: при восстановлении фреймворк сначала спросит у Kubernetes, в каком состоянии приложение.</li> </ul> <p><strong>3. Выход.</strong> Агент отправляет результат в отдельный топик Kafka, а оттуда он попадает в систему оповещений и в тикет. Если агент справился сам, в журнале появляется запись. Если нет, дежурный получает алерт с приложенными метриками, последними релизами и гипотезой модели о том, что случилось.</p> <h3>Где граница доверия?</h3> <p>У этого подхода есть обратная сторона: доверие к нейросети. Очевидный ответ такой: машине отдаём только то, что безопасно и легко откатить, всё остальное она готовит, а решает человек. Нейросеть заменяет рутину инженера. Самого инженера она заменить не может. Границу удобно описать таблицей прав (цифры приведены для примера):</p> <table> <tbody> <tr> <th>Действие</th> <th>Кто выполняет</th> <th>Ограничения</th> </tr> <tr> <td> Сбор данных: метрики, логи, релизы, состояние в Kubernetes</td> <td> Агент сам</td> <td> Только MCP-сервер на чтение, отдельная служебная учётная запись</td> </tr> <tr> <td> Перезапуск приложения</td> <td> Агент сам</td> <td> Не чаще 2 раз в час на приложение; не помогло — зовём человека</td> </tr> <tr> <td> Масштабирование</td> <td> Агент сам</td> <td> В пределах квоты, например не больше чем +50% копий приложения</td> </tr> <tr> <td> Откат релиза</td> <td> Агент в узких рамках, иначе человек</td> <td> Только на предыдущую версию и только для свежего релиза</td> </tr> <tr> <td> Конфигурация, базы данных, сеть, удаление ресурсов</td> <td> Только человек</td> <td> Агент прикладывает собранные данные и предложение</td> </tr> </tbody> </table> <p>Чтобы эта схема работала, нужно несколько вещей.</p> <ul> <li><strong>Права ограничиваются в инфраструктуре.</strong> Flink Agents автоматически подтягивает все инструменты подключённого MCP-сервера. Список в настройках определяет, какие из них увидит модель, но это одна строчка, в которой легко ошибиться. Надёжнее, когда опасных операций на сервере нет вообще, а служебная учётная запись имеет права только на чтение.</li> <li><strong>Лимиты против зацикливания.</strong> Если перезапуск не помог, второй и третий, скорее всего, тоже не помогут, зато замаскируют настоящую проблему. Поэтому поток хранит счётчик действий по каждому приложению в своём состоянии, и при превышении лимита агент обязан позвать человека.</li> <li><strong>Маленькие модели.</strong> Если отправлять каждое событие в самую мощную модель, мы либо разоримся, либо будем подолгу ждать ответа. Поэтому здесь обычно работают небольшие модели: большой контекст им не нужен, но и доверить им можно далеко не всё.</li> <li><strong>Уверенность модели не равна вероятности.</strong> Если попросить обычную языковую модель оценить свою уверенность, она вернёт число, которое, по сути, сама и придумала. Поэтому решение «чинить самому или звать человека» стоит строить на белом списке и лимитах, а не на такой оценке. Здесь интересен новый класс моделей, которые не пишут текст, а выбирают из заданных вариантов. Пример — <a href="https://www.llmreference.com/model/jev/typesafe-ai">Jev от TypeSafe AI</a>, вышедшая 15 сентября 2026 года. Ей передают собранные данные и варианты вроде «перезапустить», «добавить ресурсов», «позвать человека», а она возвращает выбор с вероятностью, которую разработчик называет калиброванной, причём, <a href="https://thursdai.news/companies/typesafe-ai">по его данным</a>, за <nobr>70-500 мс.</nobr> Сама за данными Jev не ходит, так что собирает их по-прежнему языковая модель с инструментами, а Jev достаётся только выбор действия. Ограничения: не больше 255 вариантов и <a href="https://www.trendingtopics.eu/jev-warum-dieses-neuartige-ki-modell-gerade-entwickerinnen-begeistert/">никакого текстового объяснения</a>. Сейчас готовой интеграции в выпущенных версиях Flink Agents нет, а цифры скорости и калибровки пока в основном от самого разработчика, но сама концепция многообещающая.</li> <li><strong>Теневой режим.</strong> Начинать стоит с режима, в котором агент предлагает, а действует человек. Пару недель мы сравниваем решения агента с решениями дежурных и только потом включаем автоматику по одному типу действий, начиная с самого безопасного.</li> </ul> <p>Главное правило: никаких неограниченных прав. Иначе однажды мы проснёмся и узнаем, что нейросеть сочла проблемой всю нашу систему и аккуратно её устранила. Это шутка, но с долей правды: агент может ровно то, что ему разрешили.</p> <h3>Плейбук, который пишет себя сам</h3> <p>Вернёмся к ночи из начала. В логах одного из сервисов начинают сыпаться ошибки. Предфильтр сворачивает их в одно происшествие. Агент запрашивает метрики, видит, что потребление памяти дошло до лимита, а новых релизов за сутки не было, и предлагает перезапуск. Перезапуск есть в белом списке, лимит не исчерпан, поэтому код выполняет его сам. С первой ошибки проходит около минуты, и дежурный даже не просыпается.</p> <p>Утром инженер видит отметку «авария устранена» и полный след решения: что пришло на вход, какие инструменты вызвал агент и что они вернули, почему он выбрал перезапуск. Flink Agents пишет каждое событие, включая обращения к модели и инструментам, в журнал, который с версии 0.3 по умолчанию виден в веб-интерфейсе Flink. Длинные записи в нём по умолчанию сокращаются, поэтому для полного следа нужен подробный режим.</p> <p>Это плейбук нового типа. Инструкция выполняется в момент проблемы и смотрит на систему в реальном времени, а документ поддерживать не нужно.</p> <p>Поддерживать что-то всё-таки придётся: короткий список разрешённых действий, лимиты и промпт. Энциклопедия на сотни страниц не нужна. Такой список легко проверять на ревью, хранить в git и прогонять на записанных прошлых инцидентах.</p> <h3>Сколько подъёмов на самом деле требовали человека?</h3> <p>Нейросети уже забрали у инженеров много шума — работы, которая требует много сил, но даёт мало результата: тесты, документацию, мелкие исправления. Дежурство — тоже шум, только дорогой. Каждая такая ночь стоит компании денег, а инженеру — сил.</p> <p>Проверить, сколько такого шума, просто. Откроем историю инцидентов за последний квартал и посчитаем, сколько из них закончились перезапуском, масштабированием или откатом. Это и есть доля ночей, в которых человек был нужен только для того, чтобы нажать кнопку.</p> <p>Речь не о том, чтобы убрать дежурного, а о том, чтобы изменить его работу. Базовые случаи может закрывать сама система, а человеку остаётся то, что действительно требует опыта, и проектирование системы, которая реагирует сама. Это интереснее, чем вставать в три часа ночи ради одной команды.</p> <p> #IMAGE_235736#</p> С осени 2025 года у Apache Flink есть подпроект Flink Agents, который встраивает нейросети прямо в потоковую … article Алексей Перминов, технический лидер в Exness https://www.itweek.ru/themes/detail.php?ID=235734 Wed, 14 Oct 2026 16:18:42 +0300 <p>Автономная некоммерческая организация «Национальный центр компетенций по информационным системам управления холдингом» (АНО «НЦК ИСУ») проанализировала практики крупнейших российских корпораций и выявила ключевой тренд в области применения генеративного искусственного интеллекта в ИТ-разработке. Им стал переход от «вайб-кодинга» (vibe-coding) как индивидуального инструмента сотрудника к созданию корпоративных агентских платформ, которые снизят стоимость разработки в 10 раз в перспективе нескольких лет, и мультиагентных команд. Тренды применения ИИ в корпоративной ИТ-разработке были представлены на сессии «Эффекты применения ИИ в системах управления ресурсами: метрики, кейсы, масштабирование», которую организовала «НЦК ИСУ» в рамках форума «Цифровые решения».</p> <p>По мнению корпоративных заказчиков, стратегия простого предоставления сотрудникам доступа к <nobr>LLM-инструментам</nobr> не дает ожидаемого эффекта в промышленных масштабах: выдача сотен доступов приводит лишь к росту затрат без значимого прироста эффективности. В отраслевой практике происходит разграничение: «вайб-кодинг» позиционируется как инструмент непрофессиональной разработки, тогда как «агентская разработка» становится дисциплиной для профессиональных команд, в которой ИИ-агенты выполняют исполнительские функции, а человек отвечает за архитектуру и постановку задач.</p> <p>Ключевым сдвигом становится использование агентных платформ корпоративного уровня во внутреннем контуре, позволяющих автономно охватить весь процесс разработки — от постановки задачи до поддержки готового решения. Такой подход демонстрирует потенциал существенного снижения себестоимости доработки корпоративных информационных систем. Если ранее на это требовались месяцы, сотни миллионов рублей и большие ИТ-команды, то сегодня развивать системы можно за недели и силами двух-трех высокоуровневых ИТ-специалистов и <nobr>25–30 ИИ-агентов.</nobr> Целевой ориентир корпораций — снижение себестоимости разработки ИТ-решений от 2 до 10 раз к 2030 году.</p> <p>Меняется и операционная модель ИТ-разработки. На смену традиционным ролям разработчика, аналитика, архитектора и тестировщика приходит фигура «соло-инженера» — специалиста, который проектирует систему, формулирует техническое задание и проверяет качество сгенерированного кода. К концу десятилетия классические роли в разработке могут исчезнуть, а весь ландшафт корпоративных систем будет переведен на агентские платформы вплоть до полного отказа от написания кода вручную.</p> <p>Трансформация затрагивает не только ИТ-подразделения, но и бизнес. Бизнес-заказчики получают возможность самостоятельно создавать работающие прототипы с помощью «вайб-кодинга» и приходить в ИТ-команду не просто с техническим заданием, а с полуготовым решением. Это меняет культуру взаимодействия: сотрудников учат «нанимать» цифровых сотрудников, ставить им задачи, контролировать их и объединять в сквозные процессы. Ожидаемый эффект — автоматизация непроизводственных функций с помощью ИИ-агентов с потенциалом роста производительности труда от 15% до 70% в зависимости от функции.</p> <p>Однако не все участники рынка видят мгновенный бизнес-эффект. На масштабе крупной компании значимого прироста в time-to-market пока нет. Главное достижение — резкое снижение стоимости экспериментов, что позволяет многократно тестировать гипотезы. Стоимость токенов становится значимой статьей бюджета. Кроме того, остаются барьеры в виде регуляторики и сертификации, а также сложности с переписыванием legacy-систем.</p> <p>«Корпоративная ИТ-разработка сегодня требует наличия платформы, которая позволяет автоматизировать с помощью ИИ-агентов весь процесс. Несколько инженеров, управляющие агентами, уже переписывают системы, на которые раньше уходили годы и сотни миллионов рублей. При этом ключевым становится не код, а инженерная экспертиза. Мы видим рождение новой роли инженера, управляющего мультиагентной командой. Через несколько лет такие специалисты полностью изменят ландшафт корпоративной разработки», — отметила заместитель генерального директора АНО «НЦК ИСУ» Екатерина Хитрова.</p> Автономная некоммерческая организация «Национальный центр компетенций по информационным системам управления холдингом» (АНО … message https://www.itweek.ru/themes/detail.php?ID=235732 Wed, 14 Oct 2026 10:06:37 +0300 <p><em>Примерно шесть из десяти организаций заявляют, что их стратегия в области искусственного интеллекта трансформирует бизнес, однако исследование IDC «</em><em>MaturityScape</em> <em>Benchmark</em><em>: </em><em>AI</em><em>-</em><em>Fueled</em> <em>Organization</em> <em>Worldwide</em><em>, 2026» показывает, что лишь 15,1% из них обладают соответствующими возможностями. Райан Смит, директор по контент-маркетингу IDC, рассказывает в корпоративном блоге, как компания измеряла этот разрыв, и предлагает четыре вопроса для проверки вашей организации перед тем, как сделать следующий шаг по шкале зрелости внедрения ИИ.</em></p> <p>Исследование IDC было направлено на то, чтобы выяснить, соответствуют ли реальные возможности заявлениям организаций; оказалось, что у примерно пяти из шести организаций такого соответствия пока нет.</p> <h3> Как IDC оценивала зрелость внедрения ИИ </h3> <p>Опрос, проведенный в мае 2026 г., охватил 1900 организаций на 20 рынках и включал вопросы двух типов.</p> <p>Первый тип — это самооценка организацией своего подхода к ИИ; на основе этих данных IDC разделила респондентов на две группы:</p> <ul> <li> «Выживающие» (Survivors): находящиеся в ситуации, когда либо отсутствует общекорпоративная стратегия ИИ (проекты ведутся разрозненными командами), либо стратегия ограничена лишь отдельными функциями или сферами бизнеса. Их описания соответствуют первым трем стадиям зрелости.</li> <li> «Преуспевающие» (Thrivers): имеют общекорпоративную стратегию, которая либо внедряет ИИ во все сферы бизнеса для трансформации операционной модели, либо развивает сценарии использования ИИ для переосмысления продуктов и услуг. Их описания соответствуют двум высшим стадиям зрелости.</li> </ul> <p>Второй тип — это детальные вопросы о возможностях организации в четырех аспектах: стратегия, управление, персонал и технологии. IDC оценила ответы, чтобы определить, на какой из пяти стадий зрелости находится каждая организация.</p> <p>Сравнение результатов по этим двум типам вопросов показывает, насколько заявления руководителей соответствуют реальным возможностям их организаций.</p> <h3>Каковы пять стадий зрелости внедрения ИИ</h3> <p>Стадии варьируются от «ситуативного подхода» (Ad hoc) до «оптимизации» (Optimized); высшую стадию IDC называет «организацией, работающей на основе ИИ» (AI-fueled organization).</p> <ul> <li> Ситуативность (Ad hoc): разрозненные пилотные проекты, отсутствие общекорпоративной стратегии или централизованного руководителя направления ИИ.</li> <li> Фрагментированность (Opportunistic): неформальная группа кураторов формирует стратегию вокруг нескольких сценариев использования, обещающих высокую отдачу.</li> <li> Воспроизводимость (Repeatable): центр компетенций с назначенным руководителем по ИИ разрабатывает дорожную карту для всей организации, а процессы управления формализуются.</li> <li> Управляемость (Managed): ИИ трансформирует операционную модель; появляются новые продукты и источники дохода, основанные на технологиях ИИ.</li> <li> Оптимизированность (Optimized): широкое распространение получают автономные агенты, а контроль и управление осуществляются в режиме реального времени.</li> </ul> <h3>На каком этапе модели зрелости ИИ находится большинство организаций</h3> <p>Половина организаций находится на этапе использования возможностей, а 61,3% — на двух начальных этапах с наименьшей зрелостью. Лишь 12,8% достигли двух наиболее зрелых этапов: 3,1% находятся на этапе оптимизации, а 9,7% — на этапе управляемости.</p> <p>За средним показателем скрывается неоднородность ситуации. Среднемировой показатель вырос с 2,39 до 2,43, при этом доля организаций на этапе оптимизации увеличилась с 0,4 до 3,1% — почти в восемь раз. IDC расценивает это как признак того, что группа лидеров начинает отрываться от основной массы, в то время как «широкая середина» движется вперед медленно.</p> <p>Что происходит при сопоставлении самооценки с результатами анализа</p> <p>Из 1149 организаций, отнесших себя к категории «процветающих» — что составляет около 60% выборки, — лишь 15,1% по результатам оценки попали на этапы управляемости или оптимизированности. По оценке IDC, это означает, что примерно пять из шести таких компаний по-прежнему действуют как «выживающие»: остальные 84,9% оказались на этапах ситуативности, фрагментированности или воспроизводимости.</p> <p>Тем не менее, самооценка не лишена смысла. Вероятность достижения двух высших этапов зрелости у «процветающих» примерно в 1,5 раза выше, чем у «выживающих»; IDC связывает это с наличием скоординированной корпоративной стратегии. Впрочем, абсолютные показатели в обеих группах невелики, а уверенность в себе и реальные возможности коррелируют слабо: 10,1% «выживающих» все же достигают двух высших этапов.</p> <h3>Почему амбиции в сфере ИИ опережают реальные возможности</h3> <p>Согласно анализу IDC, стратегию проще всего декларировать, но сложнее всего реализовать в масштабах всей организации. Разрыв между желаемым и действительным проявляется в тех аспектах, которые труднее всего переоценить или приукрасить. IDC выделяет следующие проблемы:</p> <ul> <li> отсутствие формализованных механизмов управления, которые можно было бы реально применять на практике;</li> <li> недостаточно надежные фундаменты данных и платформ, не способные обеспечить работу в промышленных масштабах;</li> <li> персонал, не прошедший необходимую переподготовку и адаптацию к изменениям.</li> </ul> <p>В результате организация может позиционировать себя «работающей на основе ИИ», но на деле ее деятельность все еще соответствует лишь стадии фрагментированности.</p> <p>Оценки по отдельным направлениям подтверждают эту картину. Технологический аспект характеризуется наименьшей зрелостью: 66,5% организаций находятся на двух начальных стадиях развития в этой сфере. Зрелость персонала чаще всего соответствует стадии фрагментированности (51,2%). Наибольший прогресс наблюдается в сфере управления — именно здесь наиболее «процветающие» вырываются вперед: 20,1% из них достигают двух высших стадий зрелости управления, тогда как среди «выживающих» этот показатель составляет 12,2%. Тем не менее, 57,2% всех организаций по-прежнему остаются на двух начальных стадиях развития в области ИИ.</p> <p>Андреа Сивьеро, вице-президент IDC по стратегиям развития бизнеса на базе ИИ, характеризует эту ситуацию как разрыв, при котором стратегия опережает практическую реализацию, а главным препятствием становится нехватка квалифицированных кадров.</p> <h3>Как продвигаться по модели зрелости в сфере ИИ</h3> <p>Начните с оценки своей организации по четырем ключевым направлениям:</p> <ul> <li> Кто на уровне совета директоров отвечает за ИИ и как часто предоставляются отчеты?</li> <li> Какие механизмы управления и контроля реально работают в вашей компании уже сегодня?</li> <li> Позволяют ли ваши данные и платформы внедрить в промышленную эксплуатацию следующий сценарий использования ИИ?</li> <li> Какая доля сотрудников прошла переобучение для работы с технологиями ИИ?</li> </ul> Примерно шесть из десяти организаций заявляют, что их стратегия в области искусственного интеллекта трансформирует … article https://www.itweek.ru/themes/detail.php?ID=235730 Wed, 14 Oct 2026 09:54:17 +0300 <p>По данным OWASP, инъекция промптов (prompt injection) уже несколько лет стабильно занимает первую строчку в списке угроз для <nobr>LLM-приложений.</nobr> И это неудивительно: в 2026 году ИИ-агенты — это уже не просто чат-боты, а полноценные участники бизнес-процессов с доступом к корпоративным API, базам данных и внутренним сервисам.</p> <p>Если вы уже задумались о защите или даже выбрали решение — отлично. Но внедрить ограничительные барьеры (guardrail) — это только первый шаг. Гораздо важнее понять, насколько они действительно эффективны: какие атаки пропускают, насколько замедляют работу моделей и как быстро адаптируются к новым техникам обхода.</p> <p>Классические метрики информационной безопасности здесь работают не всегда. Количество заблокированных угроз или время отклика — привычные ориентиры, но в мире ИИ-агентов картина сложнее. Модель генерирует текст на естественном языке, атака может быть замаскирована под обычный запрос, а задержка в 200 мс, незаметная для веб-приложения, способна заметно повлиять на пользовательский опыт в диалоговом интерфейсе.</p> <p>Чтобы оценить защиту ИИ-агентов по достоинству, стоит смотреть на другие цифры. Вот пять метрик, которые помогут быстро и системно разобраться в возможностях решения.</p> <h3>Метрика 1: качество детекции с детализацией ошибок</h3> <p>Оценивать защиту только по абстрактной «точности» — не самый надёжный путь. Гораздо информативнее смотреть сразу на два показателя:</p> <p><strong>ASR (Attack Success Rate)</strong> — доля атак, которые защита пропустила.</p> <p><strong>FPR (False Positive Rate)</strong> — доля обычных запросов, которые защита заблокировала по ошибке.</p> <p>В корпоративных сценариях важно, чтобы инъекции не проходили — ASR должен стремиться к нулю. Но если защита при этом блокирует каждый третий легитимный запрос, сотрудники быстро найдут способ ее обойти. Задача — найти баланс, при котором защита надежна, но не мешает работе.</p> <h3>Метрика 2: инференс-задержка</h3> <p>Это время, которое защитный шлюз тратит на анализ контента. В диалоговых сценариях счёт идёт на миллисекунды, и здесь ключевой показатель — TTFT (Time to First Token), то есть время до появления первого токена ответа модели.</p> <p>Защитный прокси не должен заметно замедлять стриминг ответа. При этом важно смотреть не только на средние значения, но и на P95/P99 — как ведёт себя решение под пиковой нагрузкой, когда в очередь выстраиваются сотни запросов. Именно эти хвосты распределения показывают, сохранится ли комфортный пользовательский опыт в часы максимальной активности.</p> <h3>Метрика 3: пропускная способность и масштабируемость</h3> <p>Решение должно горизонтально масштабироваться под рост числа одновременных сессий — без потерь во времени отклика и без потери контекста запросов.</p> <p>Особенно это важно в агентных сценариях, когда один запрос пользователя запускает цепочку внутренних вызовов между моделями и инструментами (tool calling). Если на каждом из нескольких шагов срабатывает проверка guardrail, задержка суммируется. Хорошее решение учитывает эту специфику и не превращает пятисекундную задачу агента в заметно более долгую из-за накладных расходов на безопасность.</p> <h3>Метрика 4: кросс-языковое и мультимодальное покрытие</h3> <p>Уязвимости часто эксплуатируются через низкоресурсные языки, транслитерацию, смену кодировок (Base64, циклические сдвиги), гомоглифы или встраивание инструкций в изображения и аудио.</p> <p>Инструмент защиты должен покрывать всё входное пространство модальностей, доступное целевой модели. Если фильтр безопасности работает только с английским текстом, а модель принимает другие языки или изображения, — защита получается неполной. Удобный ориентир здесь — процент покрытия модальностей и методов обфускации: защита должна видеть то же самое, что и сама модель.</p> <h3>Метрика 5: скорость адаптации к новым векторам атак</h3> <p>Jailbreak-техники эволюционируют ежедневно. Ключевой индикатор зрелости решения — время от появления новой техники обхода до момента, когда защита начинает её распознавать.</p> <p>Стоит уточнить у вендора, как именно обновляется guardrail: доставляются новые сигнатуры, обновляются правила или пересобирается классификатор, отсекающий опасные запросы. И главное — происходит ли это без остановки сервиса. Если обновление правил занимает недели или требует простоя, это сигнал пересмотреть подход.</p> <h3>Как применить это на практике для безопасности ИИ-агентов</h3> <p>Эти пять метрик — готовый чек-лист для диалога с вендорами и внутренней оценки. Их можно заложить в требования к PoC, сравнить несколько решений между собой или провести аудит уже работающей защиты.</p> <p>Рынок AI Security только формируется, и у компаний сейчас отличная возможность выстроить архитектуру защиты ИИ-агентов правильно с самого начала. Те, кто уже сегодня начнут применять системный подход и измерять эффективность защиты конкретными цифрами, через год получат не только снижение рисков, но и реальное конкурентное преимущество — ведь в эпоху автономных ИИ-систем выигрывает тот, кто умеет ими безопасно управлять.</p> <p> #IMAGE_235731#</p> По данным OWASP, инъекция промптов (prompt injection) уже несколько лет стабильно занимает первую строчку в списке … article Максим Горшков, технический директор “СофтМедиаЛаб” https://www.itweek.ru/themes/detail.php?ID=235728 Tue, 13 Oct 2026 18:12:48 +0300 <p><nobr>18-19</nobr> сентября в Москве прошёл форум ProcessTech 2026, организованный компанией «Инфомаксимум». Форум был посвящен актуальным аспектам технологий процессной аналитики (Process Mining) и майнинга задач (Task Mining) и собрал более 550 участников.</p> <p>Главным трендом года в данной области, по мнению организаторов форума, стал переход от преимущественно ретроспективного анализа процессов к опережающему управлению ими: мониторингу процессов в реальном времени, оценке рисков возможных отклонений от запланированных сценариев и предложению действий до превращения рисков в убытки. Данные Process Mining, использующего журналы событий корпоративных систем, и Task Mining, анализирующего действия сотрудников за ПК, становятся контекстом для LLM и ИИ-агентов, а на смену традиционным дашбордам приходят мультиагентные ИИ-системы, выдающие гипотезы на естественном языке. Потенциал использования такого подхода «Инфомаксимум» оценивает в <nobr>2,5-3 трлн.</nobr> руб. в год.</p> <p>Рассказывая о фирменной платформе Proceset, генеральный директор компании «Инфомаксимум» Александр Бочкин подчеркнул, что единицей автоматизации должна быть не операция, а бизнес-результат, например оформление заказа или урегулирование претензии. «Цифровой сотрудник» сам предлагает варианты автоматизации с обоснованием, к примеру, подготовить черновик заказа в системе «1С» после анализа 18,5 тыс. заявок и задаёт условия передачи кейса человеку, например при противоречии в данных, юридических рисках или низкой уверенности модели в результате.</p> <p>По его словам, ИИ это трактор, которому нужен маршрут, задаваемый контекстом бизнес-процессов: фактические последовательности выполнения процессов восстанавливаются с помощью Process Mining, действия сотрудников анализируются с помощью Task Mining, а теперь используются также регламенты и пары «документы на входе и на выходе» для реверс-инжиниринга процессов. Набор специализированных инструментов-вызовов для нейросетей сокращает разработку в <nobr>5-10 раз,</nobr> а система диспетчеризации ИИ-агентов с «верификатором» и «судьёй» доводит многонедельный план до реализации без участия людей.</p> <p>Как рассказал представитель «Билайна» Расул Булатов, в его компании вопрос «как автоматизировать то, что делает человек» заменили вопросом «должна ли такая работа вообще существовать». Там, где есть цифровой след, Process Mining строит модель фактического выполнения процесса и находит лишние согласования; где следа недостаточно, Task Mining помогает выявить ручные этапы, такие как переключение между окнами, копирование данных, использование Excel. Детерминированную рутину можно передавать роботам RPA и другим средствам автоматизации, а ситуации, требующие дополнительного контекста или решения, нужно оставлять за человеком. За полтора года в «Билайне» проведен редизайн более 35 процессов, годовой эффект от этого превысил 80 млн. руб., time-to-market сокращён на <nobr>10-50%,</nobr> выявлено 45 тыс. часов рутины.</p> <p>Как сообщил Рамазан Абакаров («РусГидро ИТ сервис»), в его компании применили Process Mining к закупкам на пятилетних данных SAP и системы документооборота LanDocs — от заявок до исполнения договора и оплаты. Процессы связали с бизнес-результатом: модель выявляет нарушения сроков поставок и оплаты, расхождения плановых и фактических объёмов закупок, незакрытые обязательства (например, 20,5% счетов-фактур регистрируются с задержкой более недели). Task Mining в общем центре обслуживания позволяет сопоставить фактическую длительность операций с нормативами.</p> <p>В планах — наблюдение за процессами в реальном времени: использование данных Process Mining и Task Mining как контекста для ИИ, оценка вероятности нарушения сроков и выбор реагирования. Пока это только направление развития, в котором ИИ, как подчеркнул Рамазан Абакаров, должен оставаться помощником человека.</p> <p>Павел Лабазнов (ФНС России) рассказал, что из 354 ключевых процессов в ФНС процесс-майнингом сегодня охвачено 100 (28,2%). До 90% трудозатрат уходит на подготовку данных. Чтобы ускориться, в Службе дописали к базовой платформе собственные модули.</p> <p>Гибридная аналитика, сопоставляя события Task Mining с журналом Process Mining, нашла жалобы, по которым проект решения пересылается в Word и перепечатывается. Имитационное моделирование «в два-три клика» показало, что автоматизация одного шага сократит процесс по упрощенной системе налогообложения с 5 дней 17 часов до 5 дней 6 часов. Анализ корневых причин автоматически ранжирует атрибуты, статистически связанные с длительностью процесса, а матрица отклонений выявляет редкие, зацикленные и нерегламентные события.</p> <p>С созданием 13 центров компетенций число гипотез выросло с 798 в 2024 г. до 3898 в <nobr>2026-м.</nobr> В планах создание «магазина цифровых следов», машиночитаемого регламента, приёмки проекта анализа вместе с новым ПО и подсказчика в будущей АИС «Налог-4».</p> <h3>Актуальные проблемы и тренды Process Mining и Task Mining</h3> <p>Одна из актуальных проблем процессной аналитики — качество и разрозненность данных: логи из разных систем не согласуются между собой, часть процессов вообще не оставляет логов. По словам Александра Бочкина, проблема сохраняется, но возможности исследовать фактическую работу у компаний расширились. Системные логи фиксируют только часть происходящего. Например, между регистрацией заявки и её согласованием сотрудник может сверять сведения в нескольких программах, переносить их в таблицу, исправлять ошибки. В журнале событий будут видны начало и конец этапа, а работа между ними — нет.</p> <p>«Мы решаем эту задачу с помощью Task Mining, которая автоматически выявляет бизнес-операции на основе действий сотрудников за компьютером. Система находит повторяющиеся последовательности, показывает, сколько времени занимает работа и какие затраты с ней связаны. При этом компания может обнаружить операции, которые заранее не описала, — сказал Александр Бочкин. — Конечно, Task Mining не отменяет проверки качества данных. Заказы, платежи и другие объекты по-прежнему нужно корректно связывать между системами, а офлайн-активность — дополнительно исследовать. Но отсутствие логов уже не означает, что эту часть работы нельзя изучить».</p> <p>Есть и другая причина, по которой проекты не дают ожидаемого результата: компания увидела потери, но ничего не изменила. По словам Александра Бочкина, чтобы внедрить автоматизацию, ей ещё нужно подготовить задание, найти разработчиков, дождаться реализации. «Мы сокращаем этот путь: данные о фактической работе становятся основой задания для ИИ, который создает автоматизацию, — отметил он. — При этом сначала нужно определить, какие операции можно автоматизировать и где это экономически оправданно. Ускорение редкой операции с небольшими трудозатратами может не окупить даже стоимость разработки».</p> <p>Другая проблема: как обеспечить условия для самостоятельного выполнения ИИ-агентами рабочих процессов? По словам Александра Бочкина, прежде всего агентам не хватает контекста конкретной компании. «Регламенты помогают далеко не всегда: реальная работа отличается от описаний и меняется быстрее, чем их успевают обновлять. Если передать ИИ устаревший регламент, можно быстро получить автоматизацию, которая воспроизводит ненужные действия или пропускает важные, — сказал он. — Process Mining и Task Mining помогают восстановить фактический порядок работы. Это дает основу для разработки, но цели и допустимые правила по-прежнему определяет человек».</p> <p>Как отметил Александр Бочкин, даже при наличии точных данных модель может ошибиться или пропустить обязательный шаг. «Поэтому мы разделяем создание автоматизации и её исполнение. ИИ помогает разрабатывать приложения и скрипты, взаимодействующие с корпоративными системами через API. Затем работа выполняется по заранее заданному и проверенному сценарию. К нейросети обращаются на тех этапах, где нужны её возможности. Это ограничивает влияние ошибок ИИ на выполнение процесса», — пояснил он.</p> <p>Task Mining предполагает наблюдение за работой персонала. Как индустрия балансирует между глубиной аналитики и доверием людей, действия которых подвергаются анализу? «Доверие зависит от того, какую задачу ставит руководство и что происходит после анализа. Людям важно заранее объяснить, зачем собирают данные, какие действия изучают и какие решения будут принимать. Обещание повысить эффективность слишком абстрактно. Гораздо понятнее конкретная задача: выяснить, почему при обработке одного обращения сотрудник трижды вводит одни и те же сведения», — отметил Александр Бочкин.</p> <p>По его словам, количество кликов ничего не говорит о пользе сотрудника: один обрабатывает типовые обращения, другой разбирается со сложными случаями. Поэтому результаты нужно обсуждать с участниками процесса — они могут объяснить причины действий, которые в данных выглядят лишними.</p> <p>«Не менее важно, чтобы сотрудники увидели результат исследования в своей работе: исчез двойной ввод, сократилась подготовка документов, стало меньше ручных проверок. Это даёт понятный ответ на вопрос, зачем проводился анализ, — сказал Александр Бочкин. — При этом польза от анализа не оправдывает сбор любых данных. Собирать нужно только то, что требуется для задачи: без личных сведений, с защитой чувствительной информации, ограниченным доступом и сроком хранения. Если достаточно данных по операции или подразделению, оценивать отдельных сотрудников незачем».</p> <p>Объектно-ориентированный процессный майнинг (OCPM, одновременное отслеживание и увязывание множества разных объектов) рассматривают как следующий шаг эволюции направления. Насколько это актуальный тренд?<strong> «</strong>Я ожидаю постепенного распространения этой модели. В первую очередь она полезна компаниям, которым для решения конкретных задач уже недостаточно анализа отдельных процессов. Например, один заказ исполняется несколькими поставками, а один платёж закрывает несколько счетов. Объектно-ориентированный подход позволяет сохранить эти связи и исследовать, как задержка одной части работы отражается на других», — считает Александр Бочкин.</p> <p>По его словам, практическую пользу анализа таких связей показывает проект hh.ru: с помощью мультипроцессной аналитики компания объединила пять бизнес-процессов из трёх информационных систем, охватив <nobr>5,3-5,4 млн.</nobr> кейсов. Единого идентификатора в системах не было, поэтому события сопоставляли по косвенным признакам — датам, идентификаторам клиентов и исполнителей. Это позволило измерить время между этапами в разных системах и долю ручных операций. Подготовленный дашборд сократил предварительное исследование процесса с месяца до двух—пяти дней.</p> <p>«Готовность здесь определяется качеством данных и самой задачей. Недостаточно связать объекты из разных систем — нужно понимать, какие решения компания сможет принимать на основе такого анализа. Если ради дополнительной детализации приходится усложнять модель, а практической пользы от неё нет, затраты не окупятся. Поэтому даже внутри одной компании такой подход имеет смысл сначала проверить на конкретной задаче, оценить результат и затем решать, где ещё его применять» — полагает Александр Бочкин.</p> Параллельно развивается и аналитика операций: уже применяется Multi Task Mining, который объединяет отдельные операции в сквозные процессы и позволяет оценить затраты на каждом этапе. Компания может увидеть, во сколько ей обходится весь процесс и где сосредоточена самая дорогая ручная работа. «Сейчас бизнес ищет, где сократить расходы без потери качества и объемов работы. Для этого нужно понимать, из чего складывается стоимость процесса и какие затраты можно убрать. Такая аналитика помогает обосновать конкретные изменения: что упростить, что автоматизировать и какую экономию это даст», — пояснил Александр Бочкин. 18-19 сентября в Москве прошёл форум ProcessTech 2026, организованный компанией «Инфомаксимум». Форум был посвящен … message Валерий Васильев https://www.itweek.ru/themes/detail.php?ID=235723 Tue, 13 Oct 2026 14:35:45 +0300 <p>Сбер представил GigaPlatform AI Studio — бесплатный сервис для тех, кто хочет попробовать ИИ на своих задачах и собрать собственного агента без программирования. Студия создана для частных пользователей и подходит как для личных дел, так и для работы. В ней можно расшифровать запись лекции, озвучить текст или разобраться в сложной теме. Можно также проверить идею для рабочего проекта или собрать помощника, который отвечает по загруженным документам. В одном интерфейсе собраны модели GigaChat, инструменты для их настройки, работа с голосом и документами и визуальный конструктор агентов из готовых блоков. Путь от идеи до рабочего прототипа занимает часы вместо недель разработки.</p> <p>В AI Studio доступны все актуальные версии ИИ-моделей Сбера, включая флагманскую GigaChat 3.5 Reasoning. В будущем разработчики смогут прямо в студии получить собственный ключ доступа к текстовым моделям GigaChat и бесплатно попробовать их в своих проектах через API.</p> <p>Проверка ИИ-гипотезы обычно занимает недели и требует привлечения программистов: для каждой технологии нужно писать код, а предпросмотра будущего решения, как правило, нет. Из-за этого путь от идеи до первой версии растягивается на месяцы, а инструменты приходится тестировать в разных средах. GigaPlatform AI Studio решает эти сложности. Например, в ней можно самостоятельно проверить жизнеспособность рабочей идеи — теперь это займет один день вместо недель или месяцев. Визуальный конструктор ИИ-агентов подойдёт тем, кто только знакомится с технологией и пока не знает, как сформулировать задачу в чате, чтобы агент выполнил её правильно. Сервис доступен бесплатно, вход — по Сбер ID. </p> <p>Антон Фролов, старший вице-президент, руководитель блока «Развитие генеративного ИИ» Сбербанка, отметил: «Лучше всех свою задачу знает тот, кто сталкивается с ней каждый день: студент перед сессией, менеджер, который тонет в почте, автор подкаста, которому нужен второй голос. Раньше, чтобы поручить такую задачу ИИ, нужно было уметь программировать или привлечь профессионала. В GigaPlatform AI Studio человек может сам попробовать разные модели, собрать своего помощника из готовых блоков и сразу проверить его в деле. Мы хотим, чтобы путь от идеи до работающего решения занимал один вечер, а ИИ стал таким же привычным инструментом, как текстовый редактор или таблицы».</p> <p>В GigaPlatform AI Studio доступны модели семейства GigaChat и инструменты для их настройки: можно одновременно отправить один запрос разным версиям модели и сравнить ответы, задать системные инструкции, изменить параметры генерации и проверить результат в чате. К модели можно подключить свои документы или собственную базу знаний — тогда она будет отвечать с опорой на эти материалы, например, в роли HR-консультанта, техподдержки первой линии или помощника отдела продаж. </p> <p>Для сложных исследовательских задач есть режим Deep Research — он изучает открытые источники, сопоставляет данные и собирает структурированный отчёт со ссылками. Можно задать или исключить определенные источники, загрузить собственные файлы и сохранить результат в PDF, HTML или Markdown. Диалог с моделью и ее настройки можно выгрузить в формате JSON — поделиться с коллегами или использовать как контекст для других ИИ-сервисов.</p> <p>Отдельное направление — работа с голосом: модели распознают речь и озвучивают текст с настройкой пауз, ударений и интонации, а специальная разметка позволяет создавать диалоги с разными голосами, например, в формате подкаста. Агента можно собрать без кода и запустить прямо в студии. Для этого в визуальном конструкторе достаточно соединить блоки: модель, базу знаний, голосовые настройки и сценарии диалога, а затем сразу протестировать и запустить. В студии можно создать агентов для работы с данными и таблицами, генерацией изображений, проверки почты, синтеза речи и других задач. Начинающие пользователи могут взять один из готовых шаблонов или собрать из блоков или при помощи ИИ-ассистента.</p> <p>В AI Studio есть встроенный помощник: он объясняет, что происходит на экране, и анализирует загруженные файлы. Для разбора документа достаточно загрузить его и нажать «Проанализировать» — помощник подготовит краткое содержание и ответит на вопросы. Ещё один инструмент студии — бесплатное приложение для компьютера, которое помогает со встречами. Оно распознаёт начало звонка, предлагает записать разговор, расшифровывает его и подводит итоги, причём ничего не отправляет в облако.</p> <p>Какие задачи можно решить в GigaPlatform AI Studio:</p> <ul> <li>работать с разными моделями без технической подготовки: задавать вопросы на интересные темы, визуализировать код, озвучивать тексты и расшифровывать аудио;</li> <li>снять с себя рабочую рутину без привлечения разработчиков: например, создать HR-консультанта, первую линию техподдержки или помощника по продажам на основе своей базы знаний;</li> <li>быстро проверить гипотезу, прежде чем писать код: собрать рабочий прототип, протестировать промпты и параметры перед интеграцией;</li> <li>познакомиться с технологиями Сбера: сравнить ответы разных версий GigaChat, попробовать голосовые модели и собрать первого агента из готового шаблона.</li> </ul> Сбер представил GigaPlatform AI Studio — бесплатный сервис для тех, кто хочет попробовать ИИ на своих задачах … message https://www.itweek.ru/themes/detail.php?ID=235722 Tue, 13 Oct 2026 14:29:57 +0300 <p>Институт статистических исследований и экономики знаний (ИСИЭЗ) НИУ ВШЭ изучает распространение практик применения ИИ в машиностроении. Как показали результаты анализа, предприятия отрасли демонстрируют прагматичный подход к внедрению технологии в производственной деятельности: используют ее для решения конкретных задач, умеренно оценивают текущие и ожидаемые эффекты и прогнозируют рост спроса на цифровые и производственные компетенции работников.</p> <p>Среди наиболее распространенных в машиностроении технологий — решения для обработки визуальных данных и текста, в том числе чат-боты и виртуальные ассистенты, помогающие экономить время на рутинных операциях в производственных и бизнес-процессах. К 2027 г. почти два из пяти обследованных предприятий планируют внедрить или считают перспективными технологии интеллектуальной поддержки принятия решений и управления, а каждое третье — ИИ-агентов.</p> <p>Предприятия машиностроения чаще всего применяют ИИ для моделирования продукции и процессов, проведения исследований и испытаний (37,8% организаций, использующих ИИ), диагностики оборудования (29,2%), планирования и контроля работ (26,7%). Более половины предприятий считают перспективным внедрение ИИ для контроля выполнения требований безопасности, управления промышленной безопасностью и работы с документацией.</p> <p>Эффекты от применения ИИ в машиностроении пока больше ожидают, чем фиксируют: к моменту проведения обследования в 2025 г. те или иные эффекты отметило примерно каждое пятое предприятие, использующее ИИ; в <nobr>2026–2027 гг.</nobr> получить эффекты рассчитывают более половины таких предприятий. Среди основных уже полученных результатов — снижение брака (18,8%) и сокращение времени операций с ростом производительности оборудования (17,6%). Ожидаемые эффекты чаще всего связывают с оптимизацией ИКТ-инфраструктуры (61%), а также снижением аварийности и повышением безопасности труда (60,7%).</p> <p>Большинство организаций отрасли, использующих ИИ, не ожидают, что внедрение технологии приведет к радикальному изменению общей потребности в работниках, в частности к сокращению персонала. При этом они прогнозируют рост спроса на цифровые и производственные компетенции, а также на работников всех категорий, кроме занятых рутинными административными функциями. Наиболее позитивные прогнозы касаются специалистов по ИКТ и квалифицированных рабочих.</p> <p>В каждой пятой обследованной организации машиностроения есть специалисты по работе с ИИ. Более 80% организаций-пользователей, в которых работают такие специалисты, испытывают дефицит этой категории кадров. Примерно каждая седьмая организация машиностроения (15%) поощряет сотрудников применять ИИ, а 9% взаимодействуют с образовательными организациями для подготовки специалистов с соответствующими навыками. Масштабы поддержки зависят от размера компании и отраслевой специфики.</p> <p>Ключевые технические требования к решениям на основе ИИ в машиностроении — безопасность, объяснимость (интерпретируемость) рекомендаций, выдаваемых ИИ-системой, и их точность. К числу условий расширения использования ИИ почти четверть обследованных предприятий относят регуляторную определенность в отношении применения ИИ и повышение рентабельности бизнеса. Для дальнейшего внедрения и применения ИИ необходима планомерная технологическая модернизация отрасли, которая возможна только в условиях расширения внутреннего спроса на отечественные машины и оборудование.</p> Институт статистических исследований и экономики знаний (ИСИЭЗ) НИУ ВШЭ изучает распространение практик применения ИИ … message https://www.itweek.ru/themes/detail.php?ID=235721 Tue, 13 Oct 2026 14:25:34 +0300 <p>Аналитика данных стала стратегическим приоритетом для большинства российских компаний. Однако используемые ими аналитические решения и СУБД для хранения данных не всегда обеспечивают необходимую производительность и масштабируемость при приемлемых затратах. Это один из ключевых выводов исследования рынка аналитических решений, проведённого компанией Postgres Professional среди более 300 представителей российских компаний из ИТ и разработки, финансового сектора, телекома, промышленности, ритейла и e-commerce, нефтегаза, энергетики и других отраслей.</p> <p>Согласно исследованию, 92% компаний уже рассматривают аналитику как стратегический ИТ-актив либо целенаправленно развивают её в этом качестве. При этом 80% респондентов продолжают использовать зарубежные аналитические решения — активно или для отдельных задач.</p> <p>Рост бюджетов на аналитику выводит на первый план внедрение и поддержку. </p> <p>Аналитика стала одним из драйверов ИТ-инвестиций: 36% опрошенных компаний увеличили бюджеты на нее за последние два года. При выборе решений компании учитывают не только стоимость лицензий, но и совокупную стоимость владения аналитическим стеком.</p> <p>«Сегодня компании всё внимательнее считают полную стоимость владения аналитического стека: помимо лицензий, она включает внедрение, интеграцию, масштабирование, поддержку и работу смежных команд. Поэтому при выборе аналитической СУБД на первый план выходит способность решения ускорять работу с данными и одновременно делать эксплуатацию более простой и предсказуемой. Именно этот запрос мы положили в основу развития наших аналитических продуктов», — комментирует Эльмира Рахматулина, руководитель продукта Postgres Pro AXE.</p> <p>Переход к новым аналитическим платформам определяется не только задачами импортозамещения. 47% участников исследования называют производительность на больших объёмах данных главным триггером для перехода на новую аналитическую СУБД.</p> <p>Компании оценивают аналитические СУБД по практическому эффекту: способность работать с растущими объёмами данных, встраиваться в действующий ИТ-контур, масштабироваться без остановки процессов и обеспечивать прогнозируемую стоимость эксплуатации — всё это становится весомее абстрактных технических характеристик при выборе решения. </p> <p> </p> Аналитика данных стала стратегическим приоритетом для большинства российских компаний. Однако используемые ими аналитические … message https://www.itweek.ru/themes/detail.php?ID=235720 Tue, 13 Oct 2026 10:40:54 +0300 <p><em>Искусственный интеллект берет на себя все больше задач начального уровня, заставляя организации переосмыслить то, как младшие сотрудники получают опыт и профессиональные навыки, необходимые для перехода на старшие должности, сообщает портал </em><em>AI</em> <em>Business</em><em>.</em></p> <p>Компании рассчитывают, что ИИ возьмет на себя значительную часть работы, которую раньше выполняли люди. Однако именно в процессе выполнения этих задач сотрудники зачастую и учатся своей профессии.</p> <p>Проблема становится все более актуальной по мере того, как ИИ начинает выполнять задачи, традиционно поручаемые младшим специалистам. Если ИИ способен справляться с рутинной работой быстрее или дешевле, компаниям может потребоваться меньше персонала для ее выполнения.</p> <p>Но у работы начального уровня есть и другая цель: она позволяет сотрудникам набраться опыта и развить профессиональные навыки, прежде чем перейти на более высокие должности.</p> <p>Финансовый директор компании Teikametrics Брайан Бопре посвятил первые десять лет своей карьеры построению финансовых моделей и изучению цифр, лежащих в основе ключевых бизнес-решений. Сегодня, по его словам, значительную часть этой работы может выполнять ИИ. Его беспокоит, что молодые сотрудники могут лишиться того опыта преодоления трудностей, который учил предыдущие поколения распознавать ошибочные решения.</p> <p>Схожие перемены могут ожидать и сферу кибербезопасности. Опрос сотрудников центров мониторинга и реагирования на инциденты (SOC) Swimlane «The New SOC Career Ladder» показал, что ИИ, вероятно, приведет к сокращению ряда должностей начального уровня в этих подразделениях, одновременно открыв возможности для перехода специалистов на более стратегические позиции.</p> <p>Это ставит перед работодателями сложную задачу: как готовить сотрудников к выполнению стратегических задач в условиях, когда исчезает работа, ранее обеспечивавшая необходимый для этого опыт?</p> <p>Навыки работы с ИИ становятся еще одним фактором, разделяющим рабочую силу. Новый опрос PwC «Global Workforce Hopes and Fears Survey 2026», проведенный среди почти 50 000 работников, показал, что 56% из них относятся к категории, которую компания назвала «машинным отделением» (engine room): это сотрудники, не обладающие специализированными навыками и не продвинувшиеся в изучении ИИ. Лишь половина из них уверена в стабильности своей занятости; кроме того, представители этой группы (одной из четырех, выделенных PwC) реже всего заявляли о готовности к адаптации.</p> <p>Разрыв может усугубиться из-за различий в оплате труда.</p> <p>Недавний отчет компании Payscale показал, что 61% работодателей пересматривают должностные инструкции из-за внедрения ИИ, однако менее половины из них заявили, что системы оплаты труда меняются соответствующим образом. Исследователи предупреждают о риске «мины замедленного действия» в вопросе удержания персонала: это может произойти, если компании будут предлагать более высокую зарплату новым сотрудникам с навыками работы с ИИ, не поощряя при этом должным образом действующих сотрудников, которые также осваивают эти компетенции. В совокупности всё это — не просто признаки того, что ИИ меняет характер работы. Эти факты указывают на более фундаментальную проблему для компаний: им придется пересмотреть подходы к профессиональному развитию сотрудников.</p> <p>Долгие годы корпоративная карьерная лестница строилась на принципе обучения в процессе работы. Начинающие специалисты выполняли задачи начального уровня, приобретали профессиональные навыки и учились принимать решения, постепенно беря на себя всё большую ответственность. Если же ИИ начнет выполнять значительную часть таких задач, компаниям придется искать иные способы обеспечения необходимого опыта.</p> <p>Некоторые компании уже предпринимают такие попытки. Например, Бопре объединяет в пары опытных сотрудников и новичков, которые лучше владеют инструментами ИИ. Старшие сотрудники объясняют логику принятия решений, а молодые специалисты помогают им работать с технологиями ИИ. Цель такого подхода — сохранить те элементы профессионального обучения, которые могли бы быть утрачены, если бы ИИ просто выдавал готовый результат.</p> <p>Однако этот переход не произойдет сам собой. Если компании исключат задачи начального уровня, не предложив сотрудникам альтернативных путей обучения, они рискуют лишиться возможностей для подготовки опытных специалистов, которые в конечном счете им понадобятся.</p> ИИ, возможно, и не уничтожит корпоративную карьерную лестницу, но вполне может устранить многие из тех ступеней, по которым люди традиционно Искусственный интеллект берет на себя все больше задач начального уровня, заставляя организации переосмыслить то, как … article https://www.itweek.ru/themes/detail.php?ID=235718 Tue, 13 Oct 2026 10:20:55 +0300 <p>На рынке труда сложилась странная на первый взгляд картина: компании продолжают сокращать целые команды, но при этом говорят о дефиците кадров и месяцами ищут специалистов. На самом деле никакого противоречия здесь нет.</p> <p>PwC в «Global AI Jobs Barometer 2026» <a href="https://www.pwc.com/gx/en/services/ai/ai-jobs-barometer.html">пишет</a>, что джуниор-роли, на которые сильнее всего повлиял ИИ, в семь раз чаще требуют навыков, прежде считавшихся сеньорскими — лидерства, стратегического мышления, способности принимать решения.</p> <p>Бизнес больше не хочет нанимать людей, чью работу можно поручить модели, а вот специалистов, которые умеют управлять процессом получения результата этой работы, ценит высоко. Рассмотрим, что делать компаниям и какие они — сотрудники, которым сейчас будут рады почти везде.</p> <h3>Дефицит кадров стал точнее</h3> <p>Раньше кадровый дефицит в ИТ описывали довольно широко: не хватает разработчиков, аналитиков, тестировщиков, DevOps’ов. Компании нанимали джунов, устраивали стажировки, чтобы вырастить людей внутри — и закрывали потребность в нужных специалистах.</p> <p>Сейчас эта схема работает хуже. Искусственный интеллект забирает часть задач, которые прежде считались входом в профессию: написать простой модуль, собрать черновой тест, подготовить документацию, найти типовую ошибку, предложить вариант реализации.</p> <p>Из-за этого изменилась сама ценность специалиста. На рынке может быть много свободных разработчиков и одновременно мало тех, кто действительно нужен компаниям. Дефицит все меньше проходит по грейдам и больше — по способности принимать инженерные решения.</p> <h3>Кто оказывается в зоне риска</h3> <p>Сильнее всего ИИ давит на роли, где много повторяемой работы и мало самостоятельных решений. Такие задачи обычно помогают человеку расти. Например, джун пишет код, получает замечания на ревью, видит последствия ошибок — и постепенно учится думать как инженер.</p> <p>Часть этого пути сокращается, когда агент пишет типовые фрагменты или находит баги вместо сотрудника. Но специалист должен понимать, что именно происходит внутри машины.</p> <p>Из-за этого в зоне риска оказываются те члены команды, которые не переходят от исполнения к управлению сложностью — не джуны как класс и не мидлы как уровень. Условный мидл, который просто хорошо пишет код, теперь конкурирует не только со специалистами, но и с ИИ-инструментами.</p> <h3>Нужный майндсет — какой он?</h3> <p>Пользоваться ИИ сейчас умеют многие, поэтому просто знать, как с ним работать, мало — нужно понимать, как продукт работает и где он может ошибиться. Для этого необходим подходящий майндсет, то есть тип мышления и восприятия.</p> <p>Он складывается из нескольких вещей:</p> <ul> <li> понимание архитектуры и взаимодействия компонентов;</li> <li> умение отличать рабочий результат от качественного;</li> <li> привычка проверять ограничения, а не только функциональность;</li> <li> способность задавать правила для ИИ-инструментов;</li> <li> ответственность за сопровождение результата;</li> <li> готовность разбираться, а не механически выполнять инструкцию.</li> </ul> <p>Разница проявляется еще до начала работы. Инженер сперва определяет стек, архитектуру, ограничения и правила проверки — и только потом подключает нейросети. Человек без такой базы сначала выполняет задачу, а затем уже разбирает, что у него вышло.</p> <p>Представьте сотрудника, который потратил недельный лимит токенов за один день — это как раз пример из второй категории. Он получил нужный результат, но использовал слишком дорогие модели. Где-то хватило бы более простых, а часть задач вообще стоило передать другим инструментам.</p> <p>Это похоже на попытку забить гвоздь микроскопом. Да, лучше, чем лбом — но инструмент все равно используется неправильно.</p> <h3>Почему вайбкодеры не заменят инженеров</h3> <p>Люди, которые еще вчера не умели писать код, а сегодня с помощью нейросетей запускают приложения, создают много шума. Это они чаще всего кричат, что разработчики больше не нужны — ведь у них-то получилось сделать рабочий сервис. И для бизнеса такая скорость тоже полезна: можно быстро проверять гипотезы и закрывать часть задач, не перегружая команду.</p> <p>На самом деле достаточно задать простой вопрос: «Если собрать таким же образом автопилот для самолета, вы полетите на нем?» В этот момент становится четко видно различие между прототипом и рабочим продуктом.</p> <p>Вайбкодинг может дать рабочий результат. Однако он быстро превращается в риск, если его нужно защищать, масштабировать, развивать и встраивать в рабочий контур без инженерной культуры.</p> <h3>Новых сеньоров сложнее растить</h3> <p>Самая большая кадровая проблема компаний — не в сокращениях джунов. Просто через несколько лет можно обнаружить, что не из кого растить сеньоров. Долгие годы путь был понятным: человек приходит на младшую позицию, много пишет сам, работает в ограничениях, получает замечания на ревью, видит последствия плохих решений — и только потом усиливается с помощью ИИ-инструментов.</p> <p>Теперь представьте, что человек с минимальным опытом сразу приходит в компанию и получает в распоряжение нейросеть. Получится ли у него увидеть, что технология предлагает рабочее, но в перспективе опасное решение? Едва ли.</p> <p>Пока рынок спасает кадровый запас инженеров, которые успели нарастить опыт до массового внедрения ИИ. Но этот резерв конечен. Если перестать пополнять его, поиск подходящего сотрудника станет сложнее.</p> <p>World Economic Forum в «Future of Jobs Report 2025» отмечает, что 63% работодателей уже <a href="https://www.weforum.org/press/2025/01/future-of-jobs-report-2025-78-million-new-job-opportunities-by-2030-but-urgent-upskilling-needed-to-prepare-workforces/">считают</a> дефицит навыков главным барьером для трансформации бизнеса, а 59% работников к 2030 году будут нуждаться в переобучении или повышении квалификации.</p> <h3>Сеньоры становятся бутылочным горлышком</h3> <p>В новой модели сеньор или тимлид управляет инженерной рамкой, в которой работают специалисты и ИИ-агенты. Он задает архитектурные правила, контролирует качество, понимает, какие задачи можно автоматизировать, а какие требуют человека.</p> <p>Раньше тимлид видел плохое решение на код-ревью и объяснял разработчику, как его исправить. Сейчас часть этой работы происходит раньше: руководитель группы задает правила агентам, чтобы они сразу работали по нужным стандартам и в нужной архитектуре.</p> <p>Следующий слой специалистов тоже выращивают именно сеньоры и тимлиды. Но здесь возникают сложности:</p> <ul> <li> некоторые сотрудники в какой-то момент понимают, что, занимаясь обучением, они снижают собственную уникальность на рынке и повышают конкуренцию. На этом их энтузиазм обычно и заканчивается;</li> <li> хороший инженер не значит хороший наставник. Уметь делать самому и учить этому других — разные навыки, и не у всех есть способности педагога. К тому же обучать чему-то взрослых людей куда сложнее, чем школьников.</li> </ul> <p>Если бизнес хочет растить людей новой формации, это должно стать частью системы — с выделенным временем и нормальной управленческой поддержкой.</p> <h3>Кадровый резерв не пополняется автоматически</h3> <p>Сократить входные позиции проще всего, ведь часть типовой работы уже и правда автоматизирована. Но с этой работой исчезают задачи, на которых прежде росли будущие сильные инженеры.</p> <p>Возникает отсроченная проблема. Сегодня бизнес экономит на исполнении — завтра столкнется с еще более явным дефицитом людей, способных принимать решения и управлять работой ИИ.</p> <p>Новая технология изменила саму экономику труда. Типовые задачи дешевеют, а все, что связано с контролем, архитектурой и сопровождением, дорожает. Поэтому рынок жестче разделяет специалистов по умению работать со сложностью — и те, кто не способен учиться и перестраиваться, по итогу начнут выпадать из сильных команд.</p> <h3>Что делать компаниям: памятка</h3> <p>Главная ошибка — одним махом сократить джунов и думать, что это решило проблему. В моменте такое решение может дать экономию, но в долгую разрушит кадровую воронку.</p> <p>Как можно действовать:</p> <ul> <li> менять формат развития джунов вместо того, чтобы отказываться от них полностью;</li> <li> давать младшим специалистам задачи на понимание кода и не ограничиваться только генерацией;</li> <li> учить работать с ИИ через ограничения и правила;</li> <li> закреплять за сеньорами и тимлидами наставничество как полноценную часть их ролей;</li> <li> оценивать способность сопровождать результат, а не только скорость выполнения задач;</li> <li> создавать внутренние правила использования ИИ-инструментов;</li> <li> развивать у сотрудников инженерное мышление и не учить их просто писать промпты.</li> </ul> <p>Развитие кадров в эпоху искусственного интеллекта не ограничивается разовой программой обучения. Это управляемая система, где у человека есть причина расти и понятные требования — и где он постоянно получает поддержку.</p> <h3>Подведем итоги</h3> <p>Сокращения и дефицит кадров могут происходить одновременно, ведь бизнес избавляется не от профессий — от старых ожиданий к ним. Работа, которую можно автоматизировать, становится нужна меньше, зато растет потребность в людях, способных управлять результатом этой автоматизации.</p> <p>Людей, которые умеют пользоваться нейросетями, уже много — и будет еще больше. В дефиците окажутся специалисты, которые понимают архитектуру, качество, риски и сопровождение, умеют задавать правила для ИИ и отвечать за итоговый продукт.</p> <p>Поэтому сегодня не так важно, сколько джунов можно заменить агентами. Важнее понять, из кого за несколько лет вырастет сеньор, способный этими агентами управлять.</p> <p>#IMAGE_235719#</p> На рынке труда сложилась странная на первый взгляд картина: компании продолжают сокращать целые команды, но при … article Константин Попандопуло, технический директор Umbrella IT https://www.itweek.ru/themes/detail.php?ID=235717 Mon, 12 Oct 2026 14:48:14 +0300 <p>Компания Security Vision представила обновление пятой версии своей Low-code/No-code платформы автоматизации процессов обеспечения информационной безопасности — Security Vision 5 (SV5). Новая версия помогает командам ИБ экономнее использовать хранилище событий, быстрее получать контекст при разборе алертов и сокращать объём работ по настройке платформы. Обновление также расширяет возможности визуализации данных и упрощает работу со связанными объектами.</p> <p>Для событий определённых типов в SV5 добавлено сжатие при хранении: стандартное с использованием LZ4 или максимальное с использованием zlib. Это позволяет уменьшить объём данных на диске и сдерживать потребность в дополнительном пространстве для хранения по мере роста потока событий. Кроме того, фильтрацию и сортировку в типе события теперь можно включать и выключать без реиндексации хранилища. Администратору не требуется перестраивать индекс ради изменения этих настроек — плановые изменения можно выполнять с меньшими затратами времени и ресурсов.</p> <p>При разборе алерта аналитик теперь видит в его карточке информацию о хосте, с которым связаны исходные события. Для свойств «Ссылка на объект» и «Ссылка на справочник» можно открыть краткую карточку связанного объекта, не закрывая текущий объект или представление. Специалисту проще проверить сведения, необходимые для оценки срабатывания, не теряя контекст и не возвращаясь к уже открытым карточкам.</p> <p>В графе появились правила отображения по свойствам и колонкам справочника, указанным в связях других правил. Также добавлены сохранение и поиск в графе, обновлена панель инструментов. Это помогает находить нужные элементы в схеме связей и использовать её при анализе данных. В аналитических виджетах «Таблица», «Текст с параметрами» и «Последовательность» теперь можно настраивать формы вывода значений, чтобы показатели было удобнее считывать и сравнивать в повседневной работе.</p> <p>Обновление затронуло и формы ввода. Для свойства «Да/Нет» добавлена форма «Иконка», позволяющая компактно разместить поле в карточке и обозначить его значение визуально. Многострочное поле «Строка» автоматически расширяется при вводе до заданного количества строк: пользователь видит больше текста и тратит меньше времени на прокрутку при заполнении длинных описаний.</p> <p>Обновлён интерфейс расписаний запуска рабочих процессов, создания отчётов и запуска коннекторов. В разделе организационной структуры переработаны оформление и расположение элементов меню. Администраторам проще ориентироваться в настройках регулярных запусков и находить нужные элементы — это особенно важно, когда количество настроенных процессов и задач увеличивается.</p> <p>Обновление SV5 объединяет изменения, которые помогают командам ИБ в повседневной работе: экономнее хранить события, получать нужный контекст при разборе алертов и настраивать платформу без лишних операций.</p> Компания Security Vision представила обновление пятой версии своей Low-code/No-code платформы автоматизации процессов обеспечения … message https://www.itweek.ru/themes/detail.php?ID=235716 Mon, 12 Oct 2026 10:33:03 +0300 <p><em>Угрозы со стороны искусственного интеллекта требуют наступательного подхода к безопасности. Хаим Мазаль, </em><em>CISO</em> <em>компании GitLab, рассказывает на портале </em><em>The</em> <em>New</em> <em>Stack</em> <em>о том, как команды, возглавляемые инженерами, используют проактивную автоматизацию для остановки киберпреступников.</em></p> <p>В июне Five Eyes («Пять глаз», разведывательный альянс пяти англоязычных стран<strong>:</strong> Австралии, Канады, Новой Зеландии, Великобритании и США) выпустил редкое совместное <a href="https://www.cisa.gov/news-events/news/five-eyes-cyber-security-agencies-statement">заявление</a>. Они предупредили, что передовые модели ИИ, как ожидается, «превзойдут текущие отраслевые ожидания, коренным образом трансформируя как наступательные, так и оборонительные возможности кибербезопасности».</p> <p>Это не теория; злоумышленники доказали свою способность обходить средства защиты. Уровень сложности для неискушенных злоумышленников, желающих осуществлять все более изощренные атаки, будет продолжать снижаться.</p> <p>Для защитников предупреждение «Пяти глаз» сигнализирует о том, что существующие подходы к безопасности не соответствуют экспоненциальному росту скорости и масштабов действий злоумышленников. В этой среде защита поверхностей атаки не сработает. Нужно переходить в наступление.</p> <h3>Лучшая защита — это хорошее нападение</h3> <p>Специалисты по безопасности инстинктивно воспринимают появление мощных моделей как сугубо плохую новость. Но переживания по поводу темпов развития возможностей ИИ ничего не изменят в программе обеспечения безопасности. Практически все средства защиты изначально создавались как инструменты эксплуатации уязвимостей, и команды безопасности перепрофилировали их для защиты. Логика, лежащая в основе большинства используемых сегодня коммерческих инструментов безопасности, применима и здесь, и защитники также имеют право на использование передовых технологий.</p> <p>Если злоумышленники теперь могут использовать ИИ для анализа активов организации и совершения атак на каждую уязвимость, защитникам необходим образ мышления, который заставит их сначала проанализировать свою собственную среду, используя ту же технологию. Этот инстинкт естественным образом вытекает из профессионального опыта, а не из осознанного выбора или метода.</p> <h3>Разные пути, разные подходы</h3> <p>CISO занимают свои должности несколькими разными путями. Некоторые приходят из отделов управления, рисков и соответствия требованиям, которые уже отвечают за риски. Некоторые приходят из ИТ-отделов, унаследовав безопасность вместе с остальной технологической инфраструктурой. Некоторые — из области архитектуры безопасности, они понимают, как фактически создавались системы. В последнее время всё большее число таких специалистов приходит из инженерных специальностей. Каждый путь формирует своё мировоззрение.</p> <p>Опыт в сфере соответствия нормативным требованиям или ИТ, как правило, формирует оборонительное мышление: ждать, пока логирование, мониторинг или инцидент покажут, куда инвестировать. Инженерный опыт, особенно в компаниях-разработчиках ПО, как правило, формирует наступательно мышление: активный поиск уязвимостей во всей программе, подобно злоумышленнику.</p> <p>Именно такое мышление нам сейчас нужно.</p> <h3>Мыслить как злоумышленник</h3> <p>Команды с наступательным мышлением видят себя создателями масштабируемых решений, которые автоматизируют результаты для бизнеса, постоянно выявляя потенциальные недостатки в программе, ландшафте угроз, инфраструктуре и каталоге активов.</p> <p>Для этого требуется настоящая любознательность; понимание того, как всё устроено, почему всё устроено именно так и что может пойти не так. Это основа исследований в области безопасности в целом: огромное любопытство к тому, как всё работает, как должно себя вести и как можно получить результаты, выходящие за рамки предполагаемых пользовательских кейсов.</p> <p>Изменения, которые я внес в свои команды, приближают нас к функциям, ориентированным на результат и управляемым инженерами. Каждая команда поддерживает автоматизированных агентов, которые выявляют риски, оценивают их, устраняют и сообщают о них в соответствии с конкретным бизнес-результатом. Безопасность приложений фокусируется на обеспечении инженерной поддержки, создании агентов, которые выполняют задачи от начала до конца на протяжении всего жизненного цикла разработки ПО. Команды по управлению и рискам становятся командами по обеспечению доверия и устойчивости бизнеса, ориентированными на постоянное подтверждение безопасности организации.</p> <h3>Создание правильного преимущества ИИ</h3> <p>Чтобы это работало, сосредоточьтесь на двух практических шагах.</p> <p>Во-первых, нейтральность относительно моделей. Создавайте рабочие процессы, которые не привязаны к одной модели или поставщику, поскольку лучшие сегодня модели и инструменты ИИ могут оказаться неподходящими через шесть месяцев. Нейтральность относительно модели также означает нейтральность относительно развертывания, что дает командам по безопасности возможность запускать модели в изолированных или самостоятельно управляемых средах, когда этого требуют условия размещения данных или защита интеллектуальной собственности, а не только возможность смены поставщика.</p> <p>Во-вторых, фокусировка. Делайте задачи агентов узкими и четко определенными. Если вы дадите агенту большую, расплывчатую задачу, он будет хорошо работать некоторое время, а затем потеряет ориентир и начнет генерировать все, что, по его мнению, удовлетворит запрос. Дайте ему конкретную задачу и уделите приоритетное внимание заблаговременному предоставлению правильного контекста, чтобы он мог более стабильно добиваться успеха. Именно так вы оркестрируете интеллектуальные результаты, не жертвуя точностью.</p> <p>Не каждая программа готова с первого же дня перестроиться на работу с агентами, и это нормально. Если программа находится на начальном этапе этого пути, не стоит усложнять задачу: проанализируйте каждое ключевое направление, определите желаемый конкретный результат и двигайтесь в обратном направлении, используя уже имеющиеся инструменты, — не нужно сразу полагать, что вам необходим совершенно новый технологический стек.</p> <h3>Пришло время переосмыслить подход</h3> <p>Самый большой риск на данном этапе — это «паралич анализа». Планка, которую нужно преодолеть злоумышленникам, постоянно снижается, тогда как требования к защите, напротив, растут. Мы больше не можем позволить себе роскошь ждать инцидента или выпуска патча от вендора. Наши системы безопасности должны соответствовать вызовам времени, если мы не хотим стать жертвами того, что наши противники меняют тактику и методы атак.</p> Угрозы со стороны искусственного интеллекта требуют наступательного подхода к безопасности. Хаим Мазаль, CISO компании … article https://www.itweek.ru/themes/detail.php?ID=235714 Mon, 12 Oct 2026 10:23:49 +0300 <p>Написать эту заметку меня сподвигли собственные опыты онбординга: программа лояльности крупной сети АЗС, приложения оператора домашнего интернета и опыт перехода на нового мобильного оператора. Может показаться, что сравнивать их с банковскими приложениями некорректно, но эта грань давно стерлась. Все они закрывают какую-то боль, а-ка потребность. И каждый лишний экран, лишнее поле или сломанный сценарий отваливает тех, кто не готов вписывать одно и то же по кругу.</p> <h3>Первая конверсия: из установки в клиента</h3> <p>76% россиян активно пользуются банковскими приложениями, и это уже не новость. Новость в другом: у 28% таких приложений два, у 26% три, у 17% четыре, а 15% держат пять и больше. Банк конкурирует не с отделением за углом, а с соседней иконкой на том же экране. И проигрыш выглядит не как жалоба, а как тишина: человек просто перестает заходить. Поэтому удобство для меня не излишество, а метрика, которая конвертируется в деньги.</p> <p>Онбординг решает не за дни, а за минуты. Главный показатель, который я бы смотрел, это время до первой ценности: сколько проходит от открытия приложения до момента, когда человек увидел то, ради чего пришел. Все, что стоит на этом пути, работает против вас.</p> <p>Мой пример. Я хотел получить QR-код программы лояльности на АЗС. После регистрации с подтверждением телефона потребовалось подтвердить еще и почту, экран подтверждения не закрывался, а код так и не пришел. Итог: к программе я не подключился и ни одного бонуса не накопил.</p> <p>Прямой банковской статистики по тому, сколько людей не дотерпело до решения своей задачи, публично почти нет, зато есть смежная. В электронной коммерции 17% покупателей бросают оформление из-за того, что процесс слишком длинный и сложный, и еще 18% уходят, когда их заставляют регистрироваться. Оценка потенциала простая: устранение трения и желания бросить телефон об пол дает около трети прироста конверсии.</p> <p>В банке поля так просто не выкинешь, здесь KYC и требования регулятора. Но переупаковать путь можно почти всегда: подтянуть данные из государственных сервисов вместо ручного ввода, разбить анкету на понятные шаги с прогрессом, объяснить, зачем нужно каждое поле, не требовать полной регистрации до того, как человек увидел продукт и условия.</p> <h3>Вторая конверсия: из нового в постоянного</h3> <p>Установка это не победа. Настоящая проверка начинается на втором и десятом входе. И здесь выигрывает не тот, у кого ярче витрина продуктов, а тот, у кого быстрее решаются рутинные задачи: найти нужное, перевести, оплатить, скачать справку, получить напоминание о платеже, настроить автопополнение.</p> <p>Отдельно выделю то, что называю эмпатичным интерфейсом.</p> <p>Круто, когда:</p> <ul> <li> видно сколько ты заработал процентов сразу на экране продукта;</li> <li> под полем для ввода чего либо есть подстрочник, объясняющий, зачем оно нужно;</li> <li> если выскакивает ошибка (это уже хорошо), но круто, если не просто сообщает «упс, что-то отвалилось», а поясняет, что именно пошло не так и что с этим делать.</li> </ul> <p>Не круто, когда:</p> <ul> <li> главный экран перегружен, как новогодняя елка;</li> <li> интерфейс выглядит как школьный сайт из 2006 года;</li> <li> подписка, подключенная автоматом по схеме «первый месяц бесплатно», нигде не подсвечена, и непонятно, как ее отключить;</li> <li> ИИ в поддержке не понимает твой запрос, предлагает одно и то же по кругу и не зовет оператора;</li> <li> непонятно почему такой процент по накопительному счету и как он получился, а особенно если не виден трек-рекорд выполнения условий по надбавкам.</li> </ul> <p>В сбережениях это особенно заметно. Клиент возвращается не ради баннера с новым вкладом, а чтобы проверить, когда придут проценты, продлится ли вклад автоматически, сколько накопилось за месяц или за день. Если на эти вопросы приложение отвечает за два касания, человек остается. Если ради справки, шаблона платежа или суммы начисленных процентов или чтобы разобраться как получить максимальный процент по накопительному счету — нужно писать в чат и ждать сутки, он откроет вклад или накоп там, где все это видно сразу.</p> <p>Оговорюсь: есть вещи, которые перебивают даже отсутствие приложения. При ставке заметно выше рынка терпимость клиента резко растет, а кому-то приложение просто и не нужно. Но и у цены есть границы: ради лишних 0,5% вряд ли кто-то останется там, где дейли-банкинг сделан плохо. Хотя исключения будут: тому, кто годами хранит сбережения в одном месте, нужен очень сильный стимул для финансового переезда.</p> <h3>Почему плохой UX живет годами</h3> <p>Главная причина не в дизайнерах и не в продактах. Клиентский путь фрагментирован: привлечение у маркетинга, продукт у продуктовой команды, свой онбординг в отделениях у сети. У каждого свои метрики и задачи. Добавлю наблюдение: приложение растущего банка быстро обрастает сервисами и допуслугами, и удержать его понятным при этом получается далеко не всегда. Отсюда знакомое чувство, когда заходишь на главный экран и не понимаешь, куда нажать, чтобы найти то, за чем пришел.</p> <p>Вторая причина — это подмена понятий. Регулярно вместо устранения трения делают редизайн: меняют цвета и иконки, а количество шагов и логика группировки сервисов остаются прежними.</p> <p>Третья причина, комплаенс как универсальное алиби. Требования регулятора действительно жесткие, но они описывают, что нужно собрать, а не в каком порядке и каким текстом об этом спрашивать.</p> <p>Четвертая причина, старое доброе «зачем менять то, что и так работает». Ведь 85% как-то разобрались, и ладно. А сколько из них испытали негатив и просто дотерпели, никто не считал.</p> <h3>Чек-лист: аудит своего приложения за один вечер</h3> <ul> <li> <strong>Пройдите путь сами.</strong> Возьмите чистое устройство и зарегистрируйтесь как новый клиент. Засеките время до первой ценности и посчитайте количество экранов.</li> <li><strong>Посчитайте поля.</strong> Выпишите все, что клиент вводит руками. Каждое поле должно быть обосновано требованием закона или продуктовой логикой, остальные можно убирать.</li> <li><strong>Прочитайте свои ошибки.</strong> Экран отказа и текст ошибки это момент максимального раздражения. Если там написано «произошла ошибка, попробуйте позже», вы теряете клиента именно здесь.</li> <li><strong>Проверьте второй день.</strong> Что человек видит при втором входе и что получает в уведомлениях. Если только продажи, возвращаться незачем.</li> <li><strong>Дайте приложение родителям.</strong> Самый честный тест. Там, где они надолго замирают, у вас дыра в конверсии.</li> <li><strong>Сравните с соседней иконкой.</strong> Откройте тот же сценарий в приложении конкурента и засеките время. Клиент делает ровно это, только молча.</li> </ul> <p>#IMAGE_235715#</p> Написать эту заметку меня сподвигли собственные опыты онбординга: программа лояльности крупной сети АЗС, приложения оператора … article Вадим Копылов, руководитель направления по развитию сберегательных и инвестиционных продуктов Инго Банка https://www.itweek.ru/themes/detail.php?ID=235710 Fri, 09 Oct 2026 14:57:11 +0300 <p><br/> KVADRA, бренд персональных устройств YADRO (входит в ИКС Холдинг), представила kvadraOS Desktop — операционную систему для персональных компьютеров. ОС предназначена для корпоративных и государственных клиентов и позволяет поэтапно переводить рабочие места на российское программное обеспечение с сохранением привычных пользовательских сценариев и части существующего ПО. kvadraOS Desktop поддерживает приложения для Windows, Linux и Android, интеграцию с корпоративной инфраструктурой и набор механизмов защиты рабочего места. </p> <p>Одним из приоритетов при разработке kvadraOS Desktop стала совместимость с существующей ИТ-инфраструктурой клиентов. ОС позволяет одновременно работать с веб-, Linux- и Android-приложениями. Windows-приложения из перечня совместимого ПО, включая Microsoft Office 2016, можно запускать через интегрированный слой совместимости. Для сценариев, которым требуется полноценная среда Windows, предусмотрено подключение к инфраструктуре виртуальных рабочих столов.</p> <p>Такой подход позволяет организациям переходить на российскую ОС поэтапно, сохраняя используемое программное обеспечение и привычные рабочие процессы. Поддержка существующих приложений сокращает необходимость их адаптации или замены, а знакомая логика интерфейса позволяет снизить затраты на переобучение сотрудников. kvadraOS Desktop также предусматривает возможность кастомизации под задачи конкретного клиента.</p> <p>Операционная система интегрируется в существующую корпоративную инфраструктуру: поддерживает подключение к домену Microsoft Active Directory и вход с доменной учетной записью, работу с VPN, сетевыми ресурсами, печать и подключение периферийных устройств. Обновления могут поступать с серверов KVADRA, также предусмотрены тиражирование подготовленного образа ОС и возврат устройства к исходным настройкам. </p> <p>Отдельное внимание в kvadraOS Desktop уделено безопасности рабочего места. Системная область доступна только для чтения, среды исполнения приложений изолированы друг от друга, а запуск системы защищен механизмом доверенной загрузки. ОС поддерживает шифрование пользовательских данных, TPM 2.0, ГОСТ-криптографию на базе КриптоПро, многофакторную аутентификацию, российские корневые сертификаты, а также сценарии входа с помощью Рутокен и JaCarta в проверенной версии продукта.</p> <p>kvadraOS Desktop разрабатывается как часть единой платформы клиентских устройств KVADRA — персональных компьютеров, ноутбуков и моноблоков — и программного обеспечения. Операционная система, оборудование и базовая система ввода-вывода (BIOS) разрабатываются и тестируются с учетом их совместной работы. Это позволяет заранее проверять совместимость компонентов, поставлять устройства с предустановленной ОС и сокращать объем работ по развертыванию и настройке рабочих мест.</p> <p>«При переходе на российскую операционную систему для клиентов критично сохранить работающие бизнес-процессы и не превращать миграцию в одновременную замену всего программного обеспечения и парка устройств. Поэтому при разработке kvadraOS Desktop основной фокус сделан на совместимости с существующей корпоративной инфраструктурой и привычными приложениями. Это позволяет переводить рабочие места на новую ОС последовательно, выбирая темп перехода с учетом задач конкретной организации», — отметил Дмитрий Черкасов, генеральный директор KVADRA.</p> <p>kvadraOS Desktop развивает линейку программного обеспечения KVADRA, в которую также входит мобильная операционная система kvadraOS Mobile для планшетов KVADRA. Обе ОС поддерживают приложения Android и интеграцию с корпоративной инфраструктурой. В kvadraOS Mobile предусмотрены режим киоска для специализированных рабочих сценариев, в том числе для полевых сотрудников, и совместимость с российскими и зарубежными системами управления мобильными устройствами (MDM).</p> <p>Возможности обеих операционных систем дополняют новые экосистемные сервисы KVADRA, также представленные на мероприятии. Корпоративное хранилище KVADRA позволяет загружать файлы, обмениваться ими и предоставлять к ним доступ: сервис интегрирован непосредственно в файловую систему kvadraOS Desktop и kvadraOS Mobile. KVADRA Hello обеспечивает вход в kvadraOS Desktop по распознаванию лица на совместимом оборудовании. Менеджер паролей KVADRA предназначен для безопасного хранения корпоративных паролей и управления ими. Сервис поддерживает разграничение доступа на основе ролей, генерацию паролей по политикам организации, шифрование данных, хранение сертификатов и интеграцию с корпоративными системами.</p> KVADRA, бренд персональных устройств YADRO (входит в ИКС Холдинг), представила kvadraOS Desktop — операционную … message https://www.itweek.ru/themes/detail.php?ID=235709 Fri, 09 Oct 2026 14:55:07 +0300 <p>Компания «Индид», российский разработчик решений в области защиты айдентити, представила ряд значимых функциональных улучшений сервиса многофакторной аутентификации Indeed MFA. Обновление включило в себя: резервный сценарий подтверждения входа с помощью одноразового кода, расширенные возможности предварительной аутентификации и новые инструменты для администраторов при управлении сервисом.</p> <p>Push-уведомления позволяют подтвердить вход одним действием в мобильном приложении и остаются одним из наиболее удобных способов второго фактора. При этом доставка сообщения может зависеть от внешних сервисов, качества интернет-соединения и настроек мобильного устройства. Если уведомление не дошло или пользователь не успел его подтвердить, процесс аутентификации может быть прерван.</p> <p>В обновленной версии Indeed MFA предусмотрен резервный сценарий. Компания «Индид» добавила возможность продолжить аутентификацию, если пользователь не подтвердил push-запрос в мобильном приложении Indeed Key. В этом случае система может предложить ввести одноразовый код вручную. Такой сценарий позволяет сохранить привычный способ входа через push и одновременно предусмотреть альтернативный вариант подтверждения.</p> <p>Функция доступна при интеграции сервиса через Indeed-агенты. Для сценариев с использованием RADIUS клиентское приложение должно поддерживать технологию Challenge-Response — последовательный обмен запросами и ответами в рамках одной процедуры аутентификации.</p> <p>Еще одно важное улучшение касается правил предварительной аутентификации. В Indeed MFA появилась возможность создавать их на основе GUID Keycloak и использовать для построения цепочек nFactor. Это позволяет точнее определять как должен проходить запрос аутентификации и при каких условиях пользователю необходимо перейти ко второму фактору. Таким образом, организации получают больше возможностей выстраивать разные сценарии проверки в зависимости от используемых систем, пользователей и требований к доступу.</p> <p>Кроме этого, в обновленном сервисе Indeed MFA расширены возможности администрирования. Теперь можно настраивать список операторов, которые будут получать системные уведомления, заранее предупреждать администраторов об окончании срока действия сертификата доступа к push-прокси и задавать период, в течение которого пользователь с выданным, но еще не активированным токеном сможет работать без второго фактора. Также разработчик доработал логику биллинга при переходе аккаунта из тестового режима в продуктивный.</p> <p>«Мы продолжаем развивать Indeed MFA в сторону более гибких и устойчивых сценариев аутентификации. Благодаря новому функционалу сервиса пользователь может перейти к резервному способу подтверждения, если push-запрос не был подтвержден, а администраторы получили больше возможностей управлять логикой перехода ко второму фактору. Это позволяет адаптировать многофакторную аутентификацию под разные инфраструктуры наших заказчиков и при этом сохранять удобный для пользователя процесс входа», — отметил Галуст Шахбазян, коммерческий директор Индид Облако".</p> Компания «Индид», российский разработчик решений в области защиты айдентити, представила ряд значимых функциональных … message https://www.itweek.ru/themes/detail.php?ID=235708 Fri, 09 Oct 2026 14:37:26 +0300 <p>Редакция IT Channel News подвела итоги рейтинга «Лучшие российские ИТ-дистрибьюторы» и назвала победителей. Опрос респондентов проводился с конца июня по середину сентября 2026 г. при помощи электронной почты, а также в форме личных и телефонных интервью. При формировании базы опроса за основу были взяты базы подписчиков IT Channel News и компаний, зарегистрированных в каталоге на сайте издания. На просьбу оценить работу дистрибьюторов и стать респондентами опроса откликнулись представители 325 ИТ-компаний из 72 населенных пунктов. П </p> <p>Лучшие ИТ-дистрибьюторы объявлены в 4 номинациях:</p> <ul> <li>«Лучший ИТ-Дистрибьютор для сборщика» (компании перечислены в алфавитном порядке): 3Logic Group, MERLION, NETLAB, OCS (первое место), Treolan;</li> <li>«Лучший ИТ-Дистрибьютор для системного интегратора» вошли следующие компании (перечислены в алфавитном порядке): MERLION, NETLAB, OCS (первое место), PROWAY, Treolan;</li> <li>«Лучший ИТ-Дистрибьютор систем информационной безопасности» (компании перечислены в алфавитном порядке): Axoft (первое место), MERLION, MONT, OCS, PROWAY;</li> <li>«Лучший ИТ-Дистрибьютор ПО» (компании перечислены в алфавитном порядке): Axoft (первое место), MERLION, MONT, OCS, Treolan.</li> </ul> <p>В этот раз, как и в предыдущем рейтинге, деятельность дистрибьюторов оценивалась по 13 критериям: «Цены»; «Программы формирования прибыли»; «Широта ассортимента»; «Наличие продукта на складе»; «Наличие системы B2В»; «Наличие четких стандартов (формализованных правил, процедур) в работе с партнерами»; «Гибкость, индивидуальный подход к партнерам»; «Способность решать проблемы»; «Управление отношениями с вендором»; «Финансовая поддержка»; «Консультации, помощь в разработке проектов»; «Маркетинговая поддержка», «Антикризисная поддержка». </p> Редакция IT Channel News подвела итоги рейтинга «Лучшие российские ИТ-дистрибьюторы» и назвала победителей. Опрос … message https://www.itweek.ru/themes/detail.php?ID=235706 Fri, 09 Oct 2026 10:48:22 +0300 <p><em>Десятилетиями производители конкурировали за счет масштаба, использования разницы в стоимости рабочей силы (арбитража) и оптимизации глобальных производственных сетей. Однако введение торговых пошлин, геополитическая фрагментация, нехватка кадров, волатильность цен на энергоносители и растущие ожидания клиентов вынуждают их переосмыслить процессы создания ценности. Программно-управляемое производство, промышленный искусственный интеллект, автоматизация и взаимосвязанные производственные процессы открывают новый путь к повышению конкурентоспособности, гибкости и устойчивости предприятий. Компании, которые добьются успеха в период до 2030 г., не просто будут инвестировать в технологии — они станут использовать технологии «умного» производства для фундаментальной трансформации своей операционной деятельности, подходов к инновациям и методов реагирования на изменения, пишут в корпоративном блоге Джордж Лоури, вице-президент и ведущий аналитик </em><em>Forrester</em><em>, и Майкл О’Грейди, аналитик </em><em>Forrester</em> <em>по прогнозированию.</em></p> <h3>Производственный сектор стоит на пороге перезагрузки показателей производительности</h3> <p>Производственный сектор сохраняет высокую эффективность, однако во многих регионах темпы роста замедлились. Например, производительность труда в промышленности США сегодня ниже уровня 2017 г., несмотря на значительные инвестиции в технологии, в то время как демографические проблемы и дефицит кадров сокращают доступность рабочей силы в крупнейших индустриальных экономиках.</p> <h3>Производителям необходимо создавать больше ценности, задействуя меньше персонала</h3> <p>Нехватка кадров создает критически важную проблему: производители должны создавать больше ценности, имея в распоряжении меньше работников. Раньше компании решали эту задачу путем переноса мощностей в регионы с более низкой стоимостью рабочей силы. Теперь же они все чаще обращаются к ПО, автоматизации и ИИ, чтобы повысить пропускную способность и гибкость, оптимизировать использование активов и снизить зависимость от трудоемких процессов. В результате происходит переход от производительности, зависящей от человеческого труда, к производительности, определяемой программными решениями.</p> <p>#IMAGE_235707#</p> <h3>ПО становится новым фактором конкурентного преимущества на производстве</h3> <p>Традиционно промышленное ПО рассматривалось как элемент инфраструктуры: необходимый, но редко играющий стратегическую роль. Forrester прогнозирует, что к 2030 г. ПО станет самой быстрорастущей категорией производственных технологий и займет значительно большую долю в общем объеме технологических расходов. Промышленный ИИ, аналитика, промышленный Интернет вещей (IIoT) и программно-управляемые производственные процессы превращают ПО из вспомогательного инструмента в фактор, обеспечивающий конкурентное преимущество.</p> <h3>Программно-управляемые заводы адаптируются к нестабильному спросу</h3> <p>Развитие программно-управляемого производства позволяет заводам становиться более гибкими и адаптивными. Вместо того чтобы ориентироваться на выпуск одного продукта в максимально возможных объемах, производители все чаще переходят к выпуску широкого ассортимента изделий, быстрее перенастраивают производство и оперативнее реагируют на изменения спроса. Гибкость критически важна, поскольку именно колебания спроса, а не ограничения производственных мощностей, зачастую становятся главным препятствием для полной загрузки предприятий.</p> <h3>ИИ меняет организацию производственных процессов</h3> <p>Применение ИИ в промышленности переходит от стадии экспериментов к практическому внедрению. Ведущие производители уже используют ИИ в таких сферах, как проектирование, разработка ПО, операционная деятельность, техническое обслуживание и управление цепочками поставок, чтобы ускорить создание продуктов, повысить надежность оборудования, оптимизировать планирование производства и сократить издержки.</p> <h3>Осторожность производителей сдерживает внедрение автономных агентов</h3> <p>Внедрение ИИ в производственном секторе находится на начальном этапе. Данные указывают на планы по расширению использования ИИ, однако опасения, связанные с кибербезопасностью, защитой интеллектуальной собственности и операционными рисками, сдерживают интерес к автономным ИИ-агентам. Для минимизации рисков производителям необходимо сочетать инновации со строгими принципами управления, эффективной работой с данными и контролем со стороны человека.</p> <h3>Проблема нехватки кадров сохраняется</h3> <p>Производственный сектор сталкивается со структурной проблемой нехватки рабочей силы. По оценкам Forrester, за последнее десятилетие численность занятых в мировом производстве сократилась примерно на 25 млн. человек. Старение населения, демографические изменения и дефицит квалифицированных кадров трансформируют рынки труда в Северной Америке, Европе, Японии и Китае. Одной лишь автоматизацией эту проблему не решить. Производителям требуется больше инженеров, техников, специалистов по ПО и работе с данными, экспертов по техобслуживанию, а также линейных сотрудников, владеющих цифровыми инструментами. Кроме того, необходимо переобучать действующих сотрудников для эффективной работы в связке с системами на базе ИИ и передовыми средствами автоматизации. В будущем конкурентное преимущество будет определяться не столько численностью персонала, сколько способностью использовать цифровые технологии.</p> <h3>Региональные стратегии в сфере производства все больше различаются</h3> <p>Производство остается глобальным, но производственные стратегии становятся все более региональными:</p> <ul> <li> США отдают приоритет передовому производству, производству полупроводников и переносу производства.</li> <li> Китай ускоренно развивает промышленную автоматизацию, робототехнику, полупроводниковую самодостаточность и секторы производства с более высокой добавленной стоимостью.</li> <li> Европа уделяет особое внимание промышленной автоматизации, инвестициям в энергетический переход, оборонному производству и устойчивости цепочек поставок.</li> <li> Мексика извлекает выгоду из ниаршоринга, регионализации цепочек поставок в Северной Америке и роста экспорта дорогостоящих промышленных товаров.</li> <li> Япония борется с демографическим спадом посредством автоматизации производства, применения робототехники и перехода к производству с более высокой добавленной стоимостью.</li> </ul> <p>Хотя приоритеты различаются, общая тема ясна: каждый регион инвестирует в технологии, чтобы компенсировать нагрузку на рабочую силу и повысить устойчивость.</p> <h3>Конкуренция за адаптивность, а не за стоимость</h3> <p>Возможно, самый важный урок для лидеров промышленных предприятий заключается в том, что конкурентоспособность производства будет все больше зависеть от адаптивности, а не от преимущества в затратах. Поскольку производители вынуждены реагировать на сбои в цепочках поставок, нехватку рабочей силы и регионализацию, интеллектуальное производство, автоматизация и ПО станут критически важными для операционной устойчивости.</p> <p>Наиболее успешные производители будут:</p> <ul> <li> Создавать программно-определяемые заводы, обеспечивающие гибкое и адаптируемое производство.</li> <li> Модернизировать системы управления производством, управление жизненным циклом продукции и платформы промышленных данных.</li> <li> Обеспечивать надежную интеграцию ИT-OT во все производственные операции.</li> <li>Инвестировать в промышленный ИИ, автоматизацию производства и передовую аналитику.</li> <li> Укреплять производственную кибербезопасность, управление и эксплуатационную устойчивость.</li> <li> Заниматься переподготовкой работников для все более цифровых производственных операций с использованием ИИ.</li> </ul> <p>Другими словами, трансформация производства требует организационных изменений, сопровождающих инвестиции в технологии.</p> <h3>Переход к интеллектуальным решениям с новой производственной архитектурой</h3> <p>Историческая ориентация на преимущества в затратах на рабочую силу и масштабе производства уступает место современному программно-определяемому производству, которое обеспечивает превосходную гибкость и устойчивость. Производители, которые сочетают промышленный ИИ, программно-определяемые операции, интеграцию ИТ-ОТ, трансформацию рабочей силы и эффективное управление, будут превосходить своих конкурентов до конца десятилетия. Те, кто рассматривает технологии как отдельную инвестицию, а не как основу новых операционных моделей производства, рискуют отстать.</p> <p>Следующее поколение лидеров промышленных предприятий выиграет не потому, что они производят продукцию дешевле, а потому, что смогут адаптироваться быстрее, чем все остальные.</p> Десятилетиями производители конкурировали за счет масштаба, использования разницы в стоимости рабочей силы (арбитража … article https://www.itweek.ru/themes/detail.php?ID=235704 Fri, 09 Oct 2026 10:38:51 +0300 <p><em>Ранее я</em><em> <a href="https://www.itweek.ru/security/article/detail.php?ID=235359">рассказала</a> об ИИ как возможном орудии атаки. Но есть и зеркальный риск: сами ИИ-системы становятся новой мишенью. </em><em>Рассмотрим</em><em>, где возникают уязвимости и как снижать эти риски.</em></p> <h3>Почему защита ИИ стала вызовом для отрасли</h3> <p>Чем активнее компании внедряют искусственный интеллект, тем заметнее разрыв между скоростью внедрения и готовностью защищать новые системы. Рынок инструментов AI Security пока находится на ранней стадии: отдельные решения уже появляются, но единых критериев эффективности и устоявшихся практик еще нет. Ситуация напоминает раннюю историю AppSec. В конце <nobr>2010-х</nobr> многим казалось, что достаточно защищать периметр и сеть, а код, библиотеки и pipeline можно оставить разработчикам. Довольно быстро выяснилось, что этого недостаточно. С ИИ происходит похожая трансформация: безопасность смещается от защиты инфраструктуры к контролю данных, моделей, агентов и всего процесса создания и использования ИИ-систем.</p> <p>Практическое следствие этого разрыва — потеря видимости. Не каждый руководитель по безопасности или архитектор может быстро ответить, где именно внутри компании используется ИИ, какие модели подключены и к каким данным они имеют доступ. Теневые сервисы сложно обнаруживать, число команд, работающих с моделями, растет, а способы тестирования пока не унифицированы. Управлять безопасностью того, чего компания не видит, невозможно. В итоге отсутствие контроля начинает тормозить уже само внедрение ИИ.</p> <p>Ситуация постепенно меняется. В России и за рубежом появляются AI gateway, guardrails, средства контроля данных, инструменты red teaming и оценки моделей. Но пока это отдельные классы решений, которые не складываются в единый зрелый процесс. Классическая защита сети остается необходимой, но она не отвечает на вопросы о происхождении модели, безопасности данных, поведении агента и допустимости его действий. Пока этот разрыв не закрыт, ИИ-система сама может стать точкой входа для атаки.</p> <h3>Основные векторы атаки на ИИ</h3> <p>Чтобы понять, где злоумышленник может атаковать ИИ-систему, угрозы нужно разложить по уровням. В упрощенной модели можно выделить три основных вектора: данные, цепочку поставок и взаимодействие с моделью через запросы и внешний контент.</p> <p>Первый вектор связан с данными. При развертывании ИИ внутри компании появляются датасеты, базы знаний, системные инструкции и история взаимодействия с моделью. Их могут пытаться извлечь, подменить или использовать для изменения поведения системы. История вокруг DeepSeek показала, что вопросы происхождения обучающих данных, защиты моделей и возможного извлечения знаний становятся предметом отдельного внимания отрасли. Для обычной компании риск еще практичнее: атака на данные бьет по основанию, на котором строится работа модели.</p> <p>Второй вектор затрагивает AI Supply Chain. В классической разработке уже существуют SCA, SBOM и практики проверки сторонних компонентов. С готовой ИИ-моделью все сложнее. Компании нужно понимать, откуда она получена, кто ее обновлял, какие зависимости входят в поставку и не изменилось ли ее поведение после обновления. Базовые способы проверки файлов и окружения есть, но поставить оценку самой модели на поток пока сложно. Поэтому безопасность цепочки поставок ИИ становится отдельным классом задач, а не расширением обычной проверки библиотек.</p> <p>Третий вектор — prompt injection. Он встречается в чат-ботах, ассистентах, корпоративном поиске и агентных системах. Инструкция может прийти не только от пользователя, но и из документа, веб-страницы или изображения, которое модель обрабатывает как часть контекста. Средства обнаружения и фильтрации таких атак уже существуют, хотя и работают неидеально. Но сложность защиты определяется не только самим запросом. Главное — какие права получила модель и что она может сделать после обработки вредоносной инструкции. Ошибка чат-бота заканчивается плохим ответом, а ошибка агента с доступом к почте, коду или корпоративным системам уже может стать полноценным инцидентом.</p> <h3>Защита через архитектуру</h3> <p>Первый уровень защиты закладывается не в фильтр перед моделью, а в архитектуру системы. Еще до внедрения нужно определить, с какими данными работает ИИ, какие инструменты он может вызывать, где требуется подтверждение человека и как фиксируются его действия. Исправлять эти ограничения после запуска обычно дороже и сложнее.</p> <p>Принцип минимальных привилегий должен применяться не только к сотрудникам, но и к ИИ-агентам. Если права пользователя не проверяются при обращении к данным через ИИ-помощника, разработчик может получить сведения о зарплатах, а маркетолог — доступ к юридическим документам. Модель в таком случае не ломает систему, она просто использует слишком широкие полномочия, которые ей выдали. Опереться при проектировании можно на формирующиеся стандарты и рекомендации, включая российские инициативы в этой области. Параллельно нужно обучать сотрудников: запрет без безопасной альтернативы почти гарантированно создает теневое использование внешних сервисов.</p> <p>Специальные средства защиты тоже необходимы, и их разработка уже идет как у российских вендоров, так и в open source. Но рынок пока фрагментирован: один продукт контролирует запросы, другой ищет утечки, третий тестирует модель. Поэтому рассчитывать на одну коробку, которая закроет весь класс рисков, пока рано.</p> <p>Минимальный практический шаг для компании — получить видимость собственного ИИ-ландшафта. Нужно понимать, какие публичные и внутренние сервисы используются, какие данные туда передаются, кто владеет системой и какие действия разрешены модели или агенту. Для этого придется честно признать, что сотрудники уже пользуются открытыми LLM, даже если формально компания их не внедряла. После этого можно разделять допустимые и рискованные сценарии, а не запрещать все подряд.</p> <p>В итоге защита ИИ строится из нескольких слоев: видимость, безопасная архитектура, управление доступом, обучение людей и специальные инструменты контроля. Здесь нет универсального порядка, в котором технология всегда должна стоять последней. Одних инструментов недостаточно, но без них невозможно контролировать данные, запросы и действия агентов в реальном времени. Главная задача — увидеть собственный ИИ-ландшафт и задать для него понятные границы. Тогда ИИ перестает быть слепой зоной и становится управляемым объектом риска.</p> <p>#IMAGE_235705#</p> Ранее я рассказала об ИИ как возможном орудии атаки. Но есть и зеркальный риск: сами ИИ-системы становятся … article Светлана Газизова, владелец продукта по безопасности ИИ компании UserGate https://www.itweek.ru/themes/detail.php?ID=235703 Thu, 08 Oct 2026 17:31:46 +0300 <p>Независимая аналитическая компания Apple Hills Digital при поддержке Selectel опубликовала результаты исследования «Облачные сервисы для ИИ: серверы с GPU и AI/ML-платформы». В отчёте представлен анализ и динамика российского рынка инфраструктурных и платформенных облачных решений для задач искусственного интеллекта по трём ключевым сегментам: виртуальные серверы с GPU (Virtual Server), выделенные серверы с GPU (Bare Metal) и AI/ML-платформы класса PaaS в 2022 — 2025 годах, а также сценарии развития до 2030 года.</p> <p>Совокупное потребление облачных серверов с GPU и AI/ML-платформ в России в 2025 году составило 65,5 млрд рублей. Почти две трети этой суммы, 40,8 млрд рублей (62%), приходится на внутреннее потребление — крупные финансовые и телеком-группы размещают ИИ-нагрузки у собственных провайдеров.</p> <p>Рыночное потребление, то есть затраты внешних заказчиков, составило 24,7 млрд рублей. Из них 17,6 млрд рублей (71%) пришлось на публичное облако:</p> <ul> <li>серверы с GPU. Рыночное потребление — 15 млрд рублей, из них 8,2 млрд рублей — в публичном облаке. Этот сегмент вырос к 2024 году на 68,7%;</li> <li>AI/ML-платформы. Рыночное потребление — 9,7 млрд рублей, из них 9,4 млрд рублей — в публичном облаке. Платформы уже обогнали публичный рынок серверов с GPU;</li> <li>частное облако. На него приходится 45% рыночного потребления серверов с GPU против 27% в IaaS в целом. Банки, госсектор и субъекты КИИ держат ИИ-нагрузки с чувствительными данными в выделенном контуре. AI/ML-платформы, напротив, почти полностью потребляются из публичного облака (97%).</li> </ul> <p>В <nobr>2022–2025</nobr> годах рынок серверов с GPU в публичном облаке рос в среднем на 48,4% в год, рынок AI/ML-платформ — на 41,9% в год. Данные за первое полугодие 2026 года говорят о замедлении рынка, хотя по неполному периоду пока нельзя точно определить среднесрочную траекторию. Прогноз построен в двух сценариях: «Продолжение тренда», при котором торможение 2026 года временное, и «Замедление роста», при котором оно закрепляется.</p> <p>К 2030 году рынок серверов с GPU в публичном облаке составит от 21,2 до 36,5 млрд рублей (среднегодовой рост <nobr>20,9–34,8%),</nobr> рынок AI/ML-платформ — от 25,9 до 40,7 млрд рублей <nobr>(22,4–34%).</nobr> В сумме это <nobr>47–77</nobr> млрд рублей против 17,6 млрд рублей в 2025 году.</p> <p>ИИ остается одним из приоритетов новых ИТ-бюджетов. Рост сегмента серверов с GPU в публичном облаке будет определять не только спрос, но и доступность вычислительных ресурсов. Официальные поставки GPU в Россию прекращены, дефицит энергомощностей в Московском регионе смещает ввод новых площадок в регионы. Высокая ключевая ставка и дорогое оборудование, а также требования к безопасности и локализации данных делают облачные GPU выгодной альтернативой созданию собственной ИИ-инфраструктуры и поддерживают выбор модели аренды вместо покупки. </p> <p>В то же время рост объема сегмента AI/ML-платформы уже больше сегмента серверов с GPU в публичном облаке и даже в сценарии прогноза «Замедление роста» растут в среднем на 22,4% в год до 2030 года. Заказчики все чаще приходят за готовой средой и моделями, а не за сервером.</p> <p>24% компаний уже используют ИИ в облаке, еще 18% планируют начать в течение 2026 года и 4% проводят пилоты. Всего это 46% опрошенных. </p> <p>Главные причины идти в облако с ИИ — готовые модели и сервисы (36%), и ускорение экспериментов (32%).</p> <p>При выборе провайдера заказчики чаще называют предобученные модели (23%) и интеграцию с данными и аналитикой (23%), чем GPU-оборудование (17%) и стоимость (16%).</p> <p>Как вариант развертывания ИИ лидирует open-source ИИ в облаке (37%); облачные ИИ-агенты и дообученные LLM используют по 27%.</p> <p>41% компаний работают с ИИ самостоятельно, а провайдер для них остается только поставщиком инфраструктуры.</p> <p>«Сегодня потребление облачных инфраструктурных и платформенных сервисов для создания ИИ решений внутри экосистем крупнейших финансовых и телекоммуникационных компаний превосходит рыночное потребление подобных сервисов. Организации и предприятия готовы арендовать GPU, но часто ограничены внутренними политиками, финансами и отсутствием приемлемых предложений от провайдеров. Рынок облачных сервисов для ИИ в России сейчас ограничен скорее предложением, чем спросом. Переход от простой аренды серверов к среде разработки и эксплуатации ИИ решений также будет поддерживать спрос на облачные сервисы. Сегмент AI/ML-платформ уже обогнал рынок инфраструктуры с GPU и сохраняет потенциал роста», — отметила Елена Семеновская, аналитик Apple Hills Digital.</p> <p>«Провайдеры ИТ-инфраструктуры значительно ускоряют внедрение искусственного интеллекта в бизнес за счет совокупности факторов: предоставления серверного оборудования с GPU по модели аренды, сформированного безопасного контура и аттестованной инфраструктуры, а также экспертизы в работе с искусственным интеллектом. За 9 месяцев 2026 года мы зафиксировали увеличение потребления серверов с GPU в 2,6 раза по отношению к аналогичному периоду прошлого года. Основной спрос приходится на представителей крупного бизнеса», — отметил Константин Ансимов, директор по продуктам Selectel.</p> Независимая аналитическая компания Apple Hills Digital при поддержке Selectel опубликовала результаты исследования «Облачные … message https://www.itweek.ru/themes/detail.php?ID=235702 Thu, 08 Oct 2026 17:29:13 +0300 <p>В первом полугодии 2026 года российский рынок персональных систем столкнулся с заметными изменениями. Нехватка комплектующих отразилась на стоимости готовых устройств, а игроки в то же время адаптировались к новым требованиям: обязательной маркировке и ужесточению правил ввоза техники. На этом фоне компании пересматривали планы обновления оборудования. Аналитики OCS совместно с экспертами ИТ-бренда Nerpa изучили структуру спроса в корпоративном секторе и сравнили её с данными первого полугодия 2025 года.</p> <p>По наблюдениям специалистов OCS, компании выбирают компьютерную технику со сбалансированными техническими характеристиками. Модели, которые раньше относились к бюджетным, из-за роста стоимости комплектующих переместились в более высокий ценовой сегмент. В результате фокус бизнеса постепенно смещается с минимально достаточных конфигураций на более универсальные решения с большим сроком актуальности.</p> <p>Например, в сегменте ноутбуков увеличился спрос на устройства с оперативной памятью 16 ГБ и SSD объёмом 512 ГБ. По сравнению с первым полугодием 2025 года продажи таких моделей выросли почти на 20% и превысили 50% рынка. Интерес к решениям с ОЗУ 8 ГБ и SSD 256 ГБ при этом снизился до 5% от общих закупок компаний. Такие характеристики по-прежнему подходят для базовых офисных сценариев, однако возможности устройств заметно ограничены при многозадачной работе. В условиях роста цен компании чаще выбирают конфигурацию ноутбука с оперативной памятью 16 ГБ и SSD 512 ГБ как более универсальную для типового корпоративного ПО и одновременной работы с несколькими приложениями. </p> <p>Схожая тенденция сложилась и в сегменте системных блоков. Сочетание оперативной памяти 16 ГБ и SSD объёмом 512 ГБ становится базовой конфигурацией для компаний. По данным OCS и Nerpa, в первом полугодии 2026 года на такие устройства пришлось 73% продаж в анализируемой категории, тогда как год назад их доля не превышала 30%. Одновременно снижается спрос на системные блоки с накопителями объёмом 256 ГБ: при сравнительно небольшой разнице в стоимости конфигурация с SSD 512 ГБ даёт больше возможностей на весь срок эксплуатации устройства. При этом компании реже приобретают избыточные для типовых рабочих мест объёмы оперативной памяти. Доля решений с ОЗУ 32 ГБ и более по сравнению с 2025 годом сократилась с 20% до 5%: такие устройства приобретают преимущественно для узкоспециализированных задач.</p> <p>В сегменте рабочих станций, напротив, растут требования к производительности и объёму оперативной памяти. В 2025 году наиболее популярными были модели с ОЗУ 32 ГБ, но теперь спрос смещается в сторону конфигураций с 64 ГБ и более. В первом полугодии на такие решения пришлось больше половины всех проданных устройств. Это связано со спецификой применения рабочих станций: программное обеспечение для моделирования, проектирования и сложных вычислений становится более ресурсоёмким. При этом в выборе накопителей спрос оказывается более полярным. Компании чаще приобретают рабочие станции с SSD на 1 ТБ, а для задач, где большой локальный объём хранения не требуется, сформировался отдельный, более бюджетный сегмент с SSD 256 ГБ.</p> <p>В разрезе производителей предпочтения корпоративных заказчиков меняются медленнее, чем конфигурации устройств. Например, около половины персональных систем, проданных в первой половине года, приходится на зарубежные бренды Acer и Lenovo. Особенно заметна эта тенденция в сегменте ноутбуков, где доля импортных решений достигла 80%. Эксперты связывают это в том числе с привычностью оборудования и накопленным опытом его эксплуатации в корпоративной инфраструктуре. При этом российские бренды укрепляют позиции в отдельных категориях: в сегменте системных блоков и рабочих станций отечественные решения уже занимают существенную долю.</p> <p>«Напряжённость на рынке памяти и накопителей сохраняется, поэтому подход компаний к конфигурациям вряд ли быстро изменится. Часть заказчиков, которые откладывали обновление парка оборудования, могут вернуться к закупкам в конце года, чтобы закрыть запланированные проекты и заменить устаревшую технику. На этом фоне ноутбуки и системные блоки с ОЗУ 16 ГБ и SSD 512 ГБ имеют все шансы укрепить позиции на рынке, заменив более простые решения», — отметила Наталья Гончарова, исполнительный директор ИТ-бренда Nerpa.</p> <p>Большие объёмы оперативной памяти и накопителей останутся востребованы там, где требуются высокие рабочие нагрузки: при работе с графикой, виртуальными машинами, сложными средами разработки и вычислительными задачами. Практика закупки оборудования со значительным запасом технических характеристик, напротив, станет менее распространённой: компании всё внимательнее соотносят стоимость устройства с реальным сценарием его использования.</p> <p>Консервативность сохранится и в выборе брендов. При росте стоимости техники ИТ-подразделения не готовы массово переводить сотрудников на новые для компании модели без предварительного тестирования. Поэтому в тех категориях, где российские и новые азиатские бренды ещё не получили широкого распространения, их внедрение будет идти через пилотные партии и сбор обратной связи. В сегменте системных блоков и рабочих станций этот процесс уже продвинулся заметно дальше, чем в ноутбуках. Российские решения продолжат набирать долю рынка, однако скорость замены брендов будет существенно зависеть от категорий оборудования и требований конкретных заказчиков.</p> В первом полугодии 2026 года российский рынок персональных систем столкнулся с заметными изменениями. Нехватка … message https://www.itweek.ru/themes/detail.php?ID=235701 Thu, 08 Oct 2026 17:28:11 +0300 <p>Крупный российский бизнес может потребить 912,5 трлн ИИ-токенов в 2026 году, что следует из сценарной оценки Orion soft. В денежном выражении такой объем потребления составляет около 237 млрд рублей.</p> <p>Открытой статистики по совокупному корпоративному потреблению токенов в России нет, поэтому Orion soft использовал сценарную оценку. В расчет вошли 2 тыс. крупнейших российских компаний с выручкой около 10 млрд рублей и выше. В базовом сценарии Orion soft предполагает, что одна такая компания в среднем обрабатывает около 500 тыс. запросов к большим языковым моделям в сутки при средней длине запроса 2,5 тыс. токенов. Это соответствует примерно 456 млрд токенов в год на одну компанию.</p> <p>В денежном выражении такой объем потребления соответствует примерно 237 млрд рублей в год. При расчетной средней стоимости 260 руб. за 1 млн токенов итоговая сумма составляет 237,25 млрд рублей. Оценка объединяет расходы на облачные модели и расчетную себестоимость инференса в собственной инфраструктуре и не включает затраты на внедрение ИИ, обучение моделей и содержание ИИ-команд, а также фактические расходы компаний, которые напрямую зависят от выбора моделей и загрузки инфраструктуры.</p> <p>Среднюю стоимость в Orion soft рассчитали с учетом предполагаемой доли каждого способа использования LLM в общем объеме токенов. В модели на локальные решения приходится 45% потребления при стоимости 180 руб. за 1 млн токенов, на модели Яндекса и Сбера через API — 25% при 350 руб., на Qwen, DeepSeek и другие модели через российские облачные платформы — 20% при 220 руб., на зарубежные API — 10% при 450 руб. Взвешенная стоимость составляет 257,5 руб. за 1 млн токенов и округляется до 260 руб. Доли и ставки являются допущениями сценарной модели, где для локальных решений используется оценка себестоимости, а для облачных — усредненной платы за использование моделей.</p> <p>Отдельным драйвером роста потребления становятся ИИ-агенты. В отличие от обычного ассистента, агент самостоятельно планирует последовательность действий и несколько раз обращается к модели в процессе выполнения одной задачи. По оценке Orion soft, обычный запрос в корпоративном чате требует около 2,5 тыс. токенов, тогда как агентская задача с шестью обращениями к модели — около 34 тыс., то есть примерно в 14 раз больше.</p> <p>По расчетам Orion soft, типовой ответ клиенту может стоить около 0,04 руб., поиск по корпоративной базе знаний — 0,19 руб., обработка документа — 0,73 руб., выполнение задачи ИИ-агентом — 1,78 руб., а сложная задача coding-агента — уже 114,77 руб. Расчеты основаны на тарифах используемых моделей на сентябрь 2026 года и учитывают только стоимость инференса без расходов на интеграцию, ИИ-команду и внутреннюю инфраструктуру.</p> <p>В сценарии на 2027 год потребление ИИ-токенов крупным российским бизнесом по оценке Orion soft может вырасти примерно на <nobr>25–50%,</nobr> до <nobr>1,14–1,37</nobr> квадриллиона токенов. Такой рост возможен, если при неизменном общем числе задач <nobr>2–4%</nobr> обычных запросов со средним потреблением 2,5 тыс. токенов будут заменены агентскими задачами по 34 тыс. токенов. Эта доля принята как сценарное допущение. При сохранении средней стоимости на уровне 260 руб. за 1 млн токенов денежный эквивалент потребления составит около <nobr>297–357</nobr> млрд руб. в год.</p> <p>Рост потребления ИИ ставит перед бизнесом новую задачу — управлять не только доступом к моделям, но и экономикой их использования. Один и тот же объем токенов может иметь принципиально разную стоимость и приносить разный бизнес-результат в зависимости от модели, сложности задачи, объема контекста и количества обращений к LLM.</p> <p>Никита Векессер, руководитель продуктов Nova AI и StarGuard AI Orion soft, отметил: «По мере масштабирования ИИ токены превращаются из технической метрики в заметную статью корпоративных расходов. Но само количество токенов ничего не говорит об эффективности: один и тот же объем вычислений может использоваться для ответа в корпоративном чате или для сложной задачи разработки и создавать совершенно разный бизнес-результат. Поэтому компаниям важно переходить от подсчета токенов к оценке стоимости завершенной ИИ-операции и полученного эффекта. С распространением агентов эта задача станет еще актуальнее: один пользовательский запрос превращается в цепочку обращений к модели, увеличивая нагрузку на инфраструктуру и стоимость эксплуатации ИИ».</p> Крупный российский бизнес может потребить 912,5 трлн ИИ-токенов в 2026 году, что следует из сценарной оценки Orion … message https://www.itweek.ru/themes/detail.php?ID=235700 Thu, 08 Oct 2026 17:27:15 +0300 <p>Институт статистических исследований и экономики знаний (ИСИЭЗ) НИУ ВШЭ оценил, какими навыками работы с искусственным интеллектом (ИИ) обладают пользователи сервисов на его основе, насколько им доверяют и какие функции готовы поручить ИИ.</p> <p>Притом что уже четыре из пяти российских интернет-пользователей применяют ИИ-сервисы в повседневной жизни, большинство пока ограничивается поверхностным использованием технологии, а отношение к ней в целом настороженное.</p> <p>Уровень ИИ-грамотности оценивали по самооценке 10 компетенций, сгруппированных в два блока: знаний принципов работы ИИ и умений применять его на практике. Как работает ИИ, понимают 52% пользователей, его возможности и ограничения осознают 40%, о разных типах ИИ знают 33%. Теоретическая осведомленность не всегда сопровождается критической оценкой и безопасным использованием: результаты работы сервисов регулярно проверяет примерно каждый четвертый, о том, какую информацию безопасно и допустимо передавать ИИ, задумываются 37% (35% это несвойственно). Дорабатывать ИИ-приложения под свои задачи умеют 24%, настраивать их для решения повторяющихся задач — 18%. Более продвинутые навыки из блока практических отмечают еще реже: проектировать ИИ-решения, например обучать модели, умеют 15%; выстраивать сложные сценарии работы с ИИ, включая создание агентов, — 14%.</p> <p>Уровень ИИ-грамотности прежде всего различается по возрасту, затем — по материальному положению. Среди пользователей младших возрастных групп — подростков <nobr>14–17</nobr> лет и молодежи <nobr>18–24</nobr> лет — хотя бы одной теоретической компетенцией обладают <nobr>83–84%,</nobr> а практическим навыком — <nobr>74–75%.</nobr> Среди обеспеченных респондентов соответствующие доли составляют 82% и 67%, в целом по выборке — 63% и 51%, а среди низкодоходных респондентов — 59% и 53%. Различия по полу и месту жительства слабее: минимум одну из десяти компетенций отметили 68% женщин и 75% мужчин.</p> <p>Отношение к ИИ у россиян остается настороженным: недоверие выражают 29%, тогда как полностью или скорее доверяют 22%. Доверие выше среди ежедневно обращающихся к ИИ-сервисам (43%) и людей с высоким уровнем ИИ-грамотности (51%); ИИ-скептиков в этих группах 12% и 10% соответственно. С большим доверием к ИИ относится молодежь <nobr>14–24</nobr> лет (35%); в старших группах показатель примерно вдвое ниже.</p> <p>Примерно треть респондентов готовы доверить ИИ повседневные задачи: планирование дня, выбор или заказ товаров. В сферах с высокой ценой ошибки, таких как выбор профессии, отбор кандидатов на работу, управление общественным транспортом или личными финансами, готов довериться решениям ИИ примерно каждый пятый. Еще реже ИИ готовы поручить подбор лекарств (16%), постановку диагноза (13%), вынесение судебных приговоров (12%) и выбор спутника жизни (11%).</p> <p>ИИ-сервисы уже вошли в повседневный обиход многих россиян, однако их широкое использование опережает формирование навыков эффективной и безопасной работы с технологией. ИИ-грамотность выше у молодых и обеспеченных пользователей, а доверие к ИИ чаще выражают ежедневные пользователи сервисов и люди с высоким уровнем цифровой грамотности. Эта связь позволяет предположить, что расширение опыта применения может укреплять доверие; важное условие — развитие ИИ-грамотности.</p> Институт статистических исследований и экономики знаний (ИСИЭЗ) НИУ ВШЭ оценил, какими навыками работы с искусственным … message https://www.itweek.ru/themes/detail.php?ID=235699 Thu, 08 Oct 2026 17:25:52 +0300 <p>Компании «Аладдин» и «Увеон — облачные технологии» (входит в «Группу Астра») подтвердили корректность совместного функционирования корпоративной системы централизованного управления JaCarta Management System 4LX (JMS 4LX) для Linux с платформой для управления инфраструктурой виртуальных рабочих мест Termidesk VDI.</p> <p>Совместимость решений подтверждена сертификатом, выданным по результатам соответствующих испытаний. Для заказчиков это означает возможность использовать JaCarta Management System 4LX для Linux и Termidesk VDI в составе единой ИТ-инфраструктуры на базе отечественных решений с подтвержденной корректностью взаимодействия компонентов. </p> <p>Совместное использование JMS 4LX и Termidesk VDI позволяет централизованно управлять средствами аутентификации и организовать доверенный доступ к виртуальной рабочей среде. Комплексное решение обеспечивает защищённый доступ как к виртуальным машинам, так и к отдельным приложениям, гарантируя соответствие требованиям Приказа № 117 ФСТЭК России.</p> <p>JaCarta Management System 4LX для Linux — это система централизованного управления средствами аутентификации и электронной подписи, защищёнными носителями информации, аппаратными OTP/U2F-токенами и программными аутентификаторами. В её состав входят высокопроизводительный сервер аутентификации JaCarta Authentication Server (JAS), сервис Aladdin 2FA и JaCarta Identity Provider (JIP) — провайдер аутентификации/авторизации в приложениях с поддержкой протоколов SAML и OIDC.</p> <p>Termidesk VDI — это мультиплатформенное решение для создания инфраструктуры виртуальных рабочих мест и организации безопасной удаленной работы сотрудников.</p> <p>«Заказчикам важно не только наличие отдельных средств защиты, но и возможность интегрировать их в единую ИТ-инфраструктуру. Подтверждение совместимости JaCarta Management System 4LX для Linux и Termidesk VDI позволяет объединить централизованное управление аутентификацией и инфраструктуру виртуальных рабочих мест, обеспечивая пользователям защищенный доступ к виртуальным ресурсам», — прокомментировал Станислав Винарский, менеджер по развитию бизнеса JMS/JAS/JIP, «Аладдин».</p> <p>«При внедрении VDI заказчику важно интегрироваться с уже работающими механизмами доступа, а не строить отдельную систему аутентификации только для виртуальных рабочих мест. Поэтому мы проверяли не один базовый сценарий входа, а разные сочетания Kerberos, PKI, Push и одноразовых кодов. Теперь у нас есть зафиксированный набор конфигураций, которые можно использовать при совместной работе Termidesk и JaCarta», — прокомментировал Сергей Халяпин, директор по развитию новых рынков и технологических альянсов «Увеон — облачные технологии».</p> Компании «Аладдин» и «Увеон — облачные технологии» (входит в «Группу Астра») подтвердили корректность совместного … message https://www.itweek.ru/themes/detail.php?ID=235698 Thu, 08 Oct 2026 14:45:07 +0300 <p>Компания «Клеверенс», разработчик программного обеспечения для автоматизации товарного учета по штрихкодам, и «Актив», крупнейший российский производитель аппаратных средств защиты информации, успешно завершили тестовые испытания на совместимость своих продуктов. По результатам был подписан официальный сертификат, подтверждающий корректную и стабильную работу устройств Рутокен с программным обеспечением «Фабрика 15» для терминалов сбора данных (ТСД).</p> <p>Испытания доказали полную технологическую совместимость мобильной платформы Mobile SMARTS со следующими ключевыми носителями:</p> <ul> <li>Рутокен ЭЦП 3.0 (включая модели с поддержкой NFC для беспроводной работы);</li> <li>Смарт-карта Рутокен ЭЦП 3.0.</li> </ul> <p>По итогам проверки устройства Рутокен официально внесены в список рекомендуемых ключевых носителей для работы с ПО «Клеверенс».</p> <p>Интеграция решений обеспечивает бесшовную и надежную авторизацию сотрудников, а также безопасную работу с квалифицированной электронной подписью (КЭП) на мобильных терминалах сбора данных. Использование USB-токенов и смарт-карт Рутокен позволяет защитить данные от несанкционированного доступа при выполнении складских, торговых и производственных операций без необходимости использования сложных сторонних надстроек, а также обеспечивает авторство и неизменность подписанных электронных документов.</p> <p>Партнерство компаний «Клеверенс» и «Актив» направлено на решение ключевых задач современного B2B-сегмента — сочетания высокой скорости бизнес-процессов с бескомпромиссным уровнем информационной безопасности.</p> <p>Что дает решение клиентам:</p> <ol> <li>соответствие требованиям законодательства. Легкая и юридически значимая работа с маркированными товарами, электронными накладными и документами, требующими сертификата КЭП прямо на складе или в торговой точке. Чтобы подписать документ при использовании Рутокен ЭЦП 3.0 NFC, в момент подписания потребуется приложить Рутокен к ТСД и подтвердить действие;</li> <li>строгий контроль доступа. Исключение рисков работы под чужими учетными записями за счет использования многофакторной аутентификации с применением устройств Рутокен;</li> <li>экономия ресурсов. Готовое, «из коробки», сертифицированное решение снижает затраты на внедрение, настройку и техническую поддержку ИТ-инфраструктуры.</li> </ol> <p>Николай Стариков, руководитель отдела продаж компании «Клеверенс», отметил: «В современных реалиях автоматизации производства, складов и ритейла безопасность данных уже не является отдельной задачей — она стала неотъемлемой частью базовых бизнес-процессов. Для нас важно, чтобы нашим пользователям на складе и в магазине было удобно работать с ТСД, а руководству компаний, автоматизирующих учет, была гарантирована полная защита операций и юридическая значимость подписываемых документов. Подтвержденная совместимость приложений „Клеверенса“ с устройствами Рутокен — это важный шаг в развитии нашего технологического и бизнес-партнерства с компанией „Актив“. Мы предлагаем рынку проверенное связующее решение, которое внедряется без „костылей“, обеспечивая заказчикам одновременно максимальную скорость мобильной сборки/приемки и высокий уровень информационной безопасности».</p> <p>Ксения Шаврова, руководитель отдела по работе с технологическими партнерами компании «Актив», прокомментировала: «Для нас этот кейс уникален — это первый в России сценарий применения мобильной электронной подписи с Рутокен непосредственно на складах, прямо на терминалах сбора данных. Мы рады дать рынку еще один удобный и надежный способ подписывать документы вне офиса, без потери юридической силы и скорости операций».</p> Компания «Клеверенс», разработчик программного обеспечения для автоматизации товарного учета по штрихкодам, и «Актив» … message