itWeek https://www.itweek.ru Издание itWeek (до 2018 года — PC Week) на портале и на страницах бумажного номера информирует читателей об актуальных информационных и коммуникационных технологиях, продуктах и решениях и опыте развития цифровой экономики и цифровой трансформации предприятий и организаций всех масштабов и отраслей. Издание рассказывает о важнейших событиях отечественного и мирового рынка ИКТ и анализирует тенденции развития ИКТ-индустрии. https://www.itweek.ru/images/itweek/logo-100x40.gif itWeek https://www.itweek.ru KVADRA представила операционную систему kvadraOS Desktop для корпоративных рабочих мест 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 Обновления Indeed MFA: больше сценариев аутентификации и гибкости в управлении доступом 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 IT Channel News подвел итоги рейтинга «Лучшие российские ИТ-дистрибьюторы — 2026» 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 Рынок облачных сервисов для ИИ в России в 2025 году достиг 65,5 млрд рублей и определяется не только спросом 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 Аналитика OCS и Nerpa: какая компьютерная техника становится базовой для бизнеса 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 Крупный российский бизнес в 2026 году может потребить 912,5 трлн ИИ-токенов 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 Подтверждена совместимость JaCarta Management System 4LX для Linux и платформы Termidesk VDI 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 «Клеверенс» и «Актив» подтвердили совместимость Рутокен ЭЦП 3.0 с ПО «Фабрика 15» для ТСД 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 СТД «Петрович» ускорил обслуживание в контакт-центре в 1,7 раза с помощью ИИ https://www.itweek.ru/themes/detail.php?ID=235697 Thu, 08 Oct 2026 14:37:49 +0300 <p>Российский разработчик BSS и ИТ-компания К2Тех внедрили голосового ИИ-помощника на первой линии контакт-центра строительного торгового дома «Петрович». Решение ежедневно обрабатывает более 8 тысяч звонков, самостоятельно определяет тему обращения, уточняет запрос и направляет клиента в нужную группу операторов. В результате время перевода на профильного специалиста сократилось в 1,7 раза, а доля успешной маршрутизации достигла 95%.</p> <p>До внедрения ИИ-помощника первую линию обслуживал аутсорсинговый контакт-центр. На фоне растущего потока обращений «Петрович» искал решение, способное стандартизировать прием звонков и ускорить перевод клиента к профильному специалисту. Голосовой ИИ-помощник BSS взял на себя первичную обработку обращений и их маршрутизацию, полностью заменив аутсорсинговый контакт-центр. Система интегрирована с корпоративной телефонией и автоматизированным рабочим местом (АРМ) оператора. Робот анализирует все входящие звонки, определяет тематику звонка, задает уточняющие вопросы, переводит клиента на нужного специалиста и передает в АРМ оператора контекст диалога и собранную информацию по запросу.</p> <p>В рамках проекта команда проанализировала массив клиентских обращений, выделила тематики звонков и настроила сценарии диалогов голосового помощника. Специалисты реализовали уточняющие вопросы для повышения точности маршрутизации, автоматическое распределение звонков между группами операторов, а также инструменты no-code-настройки, которые позволяют команде заказчика самостоятельно дообучать робота и создавать новые сценарии обслуживания без привлечения разработчиков.</p> <p>Отдельное внимание проектная команда уделила аналитике. Специалисты «Петровича» получили онлайн-мониторинг работы голосового помощника, детальную отчетность по каждому сценарию, а также инструмент для анализа диалогов и выявления нераспознанных либо новых причин обращений. Эти данные используются для последующей корректировки сценариев и дообучения модели.</p> <p>В результате внедрения голосового ИИ-помощника время перевода клиента на нужного специалиста контакт-центра сократилось в 1,7 раза — с 53 до 30 секунд, а успешная маршрутизация звонков достигла 95%. При объеме более 8 тысяч звонков в день даже сокращение одного этапа диалога дает заметный эффект для клиентского опыта. Посетитель быстрее попадает к сотруднику, способному решить его вопрос, а оператор начинает разговор уже с необходимым контекстом. Глубокая аналитика позволила дополнить карту клиентских запросов и точнее развивать сценарии обслуживания.</p> <p>Для ритейла скорость и точность первого контакта напрямую влияют на клиентский опыт, поскольку лишние переводы, повторные объяснения проблемы и некорректная маршрутизация создают риск потери заказа. Поэтому автоматизация первой линии контакт-центра становится не только инструментом оптимизации операционных процессов, но и способом управлять качеством сервиса.</p> <p>«Для нас было важно не просто автоматизировать прием звонков, а сделать так, чтобы каждый клиент сразу попадал к нужному специалисту без лишних переводов и повторных объяснений. Голосовой ИИ позволил стандартизировать этот процесс, а глубокая аналитика помогает нам анализировать характер клиентских обращений и быстрее адаптировать сервис под реальные запросы клиентов. Робот стал не только инструментом автоматизации, но и источником данных для дальнейшего развития клиентского сервиса», — рассказал Роман Северинов, руководитель проектов контакт-центра СТД «Петрович».</p> <p>Проект для СТД «Петрович» стал очередным этапом сотрудничества BSS и К2Тех, направленного на цифровую трансформацию клиентского опыта.</p> <p>«В проекте для СТД „Петрович“ мы объединили экспертизу BSS в области разговорного ИИ и опыт К2Тех по внедрению решений в контакт-центрах. Мы обеспечили бесшовную интеграцию голосового помощника с телефонией и АРМ оператора, чтобы автоматизация не создавала дополнительный контур, а стала частью действующего процесса обслуживания. Это позволяют команде заказчика самостоятельно развивать решение и постоянно улучшать качество клиентского сервиса по мере появления новых задач», — прокомментировал Дмитрий Песоцкий, руководитель практики по решениям для контактных центров К2Тех.</p> <p>«Следующим шагом в развитии проекта может стать внедрение интеллектуальной платформы управления клиентским опытом, которая позволит объединить все клиентские обращения и данные о взаимодействиях, чтобы быстрее понимать потребности клиентов и предлагать им персональные решения на каждом этапе обслуживания. Платформа поможет выявлять риски оттока, находить дополнительные возможности для продаж, рекомендовать сотрудникам оптимальное следующее действие и последовательно повышать качество сервиса на основе накапливаемых данных», — рассказал о дальнейших планах Артем Роменский, директор по развитию партнерских продаж компании BSS.</p> Российский разработчик BSS и ИТ-компания К2Тех внедрили голосового ИИ-помощника на первой линии контакт-центра … message Дизайн инфраструктуры ИИ следующего поколения начинается с эффективности https://www.itweek.ru/themes/detail.php?ID=235695 Thu, 08 Oct 2026 11:00:37 +0300 <p><em>Инфраструктура искусственного интеллекта требует системного подхода к проектированию, который интегрирует электропитание, охлаждение и вычислительные ресурсы для оптимизации эффективности, отказоустойчивости и адаптивности, а не только мощности, пишет на портале </em><em>Data</em> <em>Center</em> <em>Knowledge</em> <em>Крис Батлер, президент подразделения встроенного и критически важного электропитания компании Flex.</em></p> <p>В течение многих лет проектирование центров обработки данных определялось простой целью: создать достаточно мощностей для удовлетворения спроса. Такой подход имел смысл, когда рабочие нагрузки были более предсказуемыми, но ИИ меняет эту ситуацию.</p> <p>Современная инфраструктура должна поддерживать более высокую плотность динамических рабочих нагрузок, одновременно более эффективно используя электроэнергию и ресурсы. Такой сдвиг — это не просто эффективность ради эффективности. Более эффективное использование инфраструктуры может помочь снизить эксплуатационные расходы, повысить отказоустойчивость и упростить адаптацию по мере развития рабочих нагрузок.</p> <p>Учитывая, что только в США строится более 1500 дата-центров, у операторов есть возможность заложить эти преимущества в инфраструктуру с самого начала, а не пытаться модернизировать ее позже. Таким образом, следующее поколение инфраструктуры ИИ меньше связано со скоростью строительства или опорой на какую-либо одну технологию, и больше — с системным подходом, учитывающим электропитание, охлаждение, вычислительные ресурсы и эксплуатацию в совокупности.</p> <h3>Почему эффективность становится приоритетом при проектировании</h3> <p>Растущие рабочие нагрузки и меняющиеся требования к инфраструктуре усложняют проектирование и эксплуатацию дата-центров. Поскольку ИИ приводит к увеличению плотности рабочих нагрузок, каждое решение в области инфраструктуры может иметь последствия для других элементов системы.</p> <p>Например, изменение архитектуры электропитания может повлиять на требования к охлаждению. Решения по охлаждению могут влиять на потребление энергии и воды, а использование вычислительных ресурсов может изменить потребности в электроэнергии и охлаждении. Эти взаимозависимости означают, что эффективность не может быть обеспечена одной командой или дисциплиной изолированно.</p> <p>Команды должны координировать решения и учитывать последствия своих решений как для вышестоящих, так и для нижестоящих звеньев. Это поможет операторам сбалансировать потребность в новых мощностях с тем, насколько эффективно они используют существующую инфраструктуру.</p> <p>Это имеет прямые последствия как для стоимости, так и для отказоустойчивости. Более эффективное использование ресурсов может снизить эксплуатационные расходы, а проектирование систем, работающих совместно, уменьшает неэффективность и потенциальные точки отказа. Учет этих факторов на этапе проектирования также может снизить зависимость от дорогостоящей модернизации в дальнейшем.</p> <h3>Системный подход к эффективности</h3> <p>Показатель эффективности использования электроэнергии (PUE) долгое время был стандартным показателем эффективности дата-центров, но он не охватывает все аспекты современной инфраструктуры. Ожидания отрасли относительно того, что представляет собой эффективный объект, изменились. Средний показатель PUE улучшился с 2,50 в 2007 г. до 1,52 в <nobr>2026-м,</nobr> в то время как новые объекты обычно достигают PUE 1,3 или ниже. Уровень эффективности, который считался бы высоким два десятилетия назад, теперь значительно не соответствует ожиданиям от современных объектов.</p> <p>Этот прогресс показывает, почему операторам необходимо смотреть дальше одного показателя. Более низкий показатель PUE важен, но инфраструктура ИИ также должна учитывать потребление воды, выбросы углерода, использование вычислительных ресурсов, повторное использование энергии и взаимодействие с электросетью.</p> <p>Более широкая концепция может включать:</p> <ul> <li> Эффективность использования электроэнергии (PUE) во всех операциях.</li> <li> Эффективность потребления воды (WUE), связанного с операциями и охлаждением.</li> <li> Экологичность (CUE): углеродный след энергопотребления ИТ-оборудования.</li> <li> Эффективность повторного использования генерируемой/потребляемой энергии (ERE).</li> <li> Энергоэффективность вычислительных ресурсов (CPE).</li> <li> Синхронизация энергопотребления рабочих нагрузок с ограничениями и состоянием электросети (GAE).</li> </ul> <p>В совокупности эти показатели дают операторам более полное представление о компромиссах между мощностью, спросом и использованием.</p> <h3>Проектирование систем электропитания, охлаждения и вычислительных ресурсов с учетом реальных рабочих нагрузок</h3> <p>Ни одна система в одиночку не определяет эффективность инфраструктуры. Электропитание, охлаждение и вычислительные ресурсы должны работать вместе, особенно с учетом того, что высокоплотные рабочие нагрузки ИИ предъявляют новые требования к средам дата-центров.</p> <p>Чтобы это обеспечить, проектирования инфраструктуры должно учитывать то, как рабочие нагрузки ведут себя изо дня в день. Далее, интегрированные подходы к электропитанию и охлаждению могут повысить надежность развертывания и сделать масштабирование более эффективным, в то время как модульные подходы предоставляют операторам гибкость для адаптации по мере изменения требований.</p> <p>По мере развертывания инфраструктуры для ИИ такой подход будет способствовать созданию более гибкой цепочки поставок и укреплению сотрудничества между технологическими компаниями. Рост инвестиций в промышленное производство объединит инженерные, интеграционные и производственные возможности, позволив отрасли быстрее реагировать на меняющиеся потребности инфраструктуры.</p> <h3>Оценка эффективности на протяжении всего жизненного цикла инфраструктуры</h3> <p>Эффективность — это не разовое проектное решение; ее необходимо оценивать на всех этапах: от разработки и развертывания до текущей эксплуатации.</p> <p>Сбалансированный набор показателей позволяет операторам оценивать работу инфраструктуры и выявлять возможности для ее улучшения. В свою очередь, комплексное отслеживание таких параметров, как энергопотребление, расход воды, углеродный след, повторное использование энергии, загрузка вычислительных мощностей и взаимодействие с энергосетью, дает более полную картину, чем любой отдельный показатель.</p> <p>В условиях изменения рабочих нагрузок ИИ и требований к инфраструктуре постоянный мониторинг обеспечивает операторам необходимую видимость процессов, позволяя корректировать работу системы и поддерживать ее производительность на должном уровне.</p> <h3>Создание инфраструктуры с прицелом на будущее</h3> <p>Масштабы инфраструктуры для ИИ будут расти, однако одной лишь мощности будет недостаточно. Операторам необходимо с самого начала проектировать системы с учетом требований к эффективности, надежности и адаптивности.</p> <p>Применяя системный подход к вопросам энергоснабжения, охлаждения, вычислений и эксплуатации — а также согласовывая решения между различными техническими дисциплинами, — операторы смогут эффективнее использовать имеющиеся мощности, контролировать эксплуатационные расходы и создавать более устойчивую инфраструктуру.</p> <p>В конечном счете, критерием успеха инфраструктуры для ИИ станет не просто объем обеспечиваемой ею мощности, а то, насколько эффективно и надежно она способна поддерживать меняющиеся рабочие нагрузки.</p> Инфраструктура искусственного интеллекта требует системного подхода к проектированию, который интегрирует электропитание … article От ресурсов к результату: новая роль внешнего ИТ-интегратора https://www.itweek.ru/themes/detail.php?ID=235692 Thu, 08 Oct 2026 10:49:04 +0300 <p><em>Когда благодаря </em><em>искусственному интеллекту</em><em> ИТ-разработка становится все дешевле и доступнее, ценность интегратора все меньше определяется ресурсами разработки и все больше — способностью отвечать за результат, сквозной сценарий и управление изменениями. </em><em>Рассмотрим</em><em>, почему сегодня бизнесу нужен не подрядчик с набором специалистов, а партнер, способный отвечать за результат.</em></p> <h3>In-house или подрядчик: как меняются модели работы</h3> <p>Отношение бизнеса к внешней ИТ-экспертизе меняется. После нескольких лет активного наращивания собственных ИТ-команд компании продолжают развивать in-house, но одновременно возвращаются к подрядчикам — уже не за людьми, а за результатом.</p> <p>Сегодня на рынке вновь намечается тренд на создание in-house-команд. Но это уже не та практика <nobr>2024-2025 годов,</nobr> когда бизнес создавал собственные ИТ-компании, чтобы решать задачи HR-бренда, удержания специалистов или оптимизации налогов. Сейчас причина гораздо прозаичнее — необходимо существенно сокращать издержки. Многим кажется, что это можно сделать, отказываясь от внешнего аутсорса и накапливая экспертизу внутри.</p> <p>Хорошо это видно на примере компаний, которые пытаются полностью перевести ИТ в in-house. На практике быстро возникает вопрос: насколько эффективно внутренней командой управлять одновременно процессами Run и Change и есть ли смысл постоянно держать в штате все необходимые компетенции. Архитектор, DevOps или узкопрофильный эксперт могут быть критически важны для конкретного проекта, но не требоваться компании на постоянной основе. В результате для одних задач компания сохраняет собственную команду, а для других все равно привлекает внешнюю экспертизу.</p> <p>В результате бизнес приходит к смешанной модели: ключевую экспертизу и понимание своего продукта он оставляет внутри, а отдельные компетенции и задачи привлекает извне. Но здесь возникает следующий вопрос: что именно бизнес покупает у подрядчика — отдельных специалистов, их время или все-таки конкретный результат? И именно здесь, на мой взгляд, сегодня происходит главное изменение в модели работы с внешними командами.</p> <h3>Покупать не людей, а результат</h3> <p>Долгое время у бизнеса было два основных способа привлекать внешние ИТ-команды: либо набирать специалистов под конкретные задачи, либо передавать подрядчику проект целиком за фиксированную стоимость. В первом случае компания по факту просто покупала ресурсы, и конечного результата могло не быть, поскольку оставался вопрос, кто отвечает за его достижение. Во втором ответственность за проект была более очевидной, но и здесь возникали ограничения: подрядчика приходилось глубоко погружать во внутренний контур компании, при этом у него не всегда были полномочия продвигать необходимые изменения или самостоятельно принимать решения. В итоге в обоих случаях оставался один и тот же вопрос: кто отвечает за конечный результат?</p> <p>Поэтому сейчас рынок пришел к гибридным решениям. Компания по-прежнему может привлекать внешнюю команду, но отношения с ней строятся уже не вокруг количества специалистов и отработанных часов, а вокруг конкретного результата и ответственности за его достижение. Бизнес в такой модели формулирует цель и определяет, какого результата хочет добиться, а интегратор переводит эту цель в конкретную задачу, строит план реализации и отвечает за его выполнение. Это пока непростая модель, потому что нужно договориться, что именно считать результатом. Однако сам тренд уже очевиден.</p> <p>Он связан еще и с тем, что сегодня бизнес предпочитает двигаться короткими итерациями: сделали что-то за два-три месяца, получили результат, посмотрели, как он влияет на метрики (а лучше — еще и на финансовые показатели), и только после этого приняли решение развивать продукт дальше. Проектов, в которых компания тратит условные 200 млн. рублей, а результат получает только через полтора года, сегодня на рынке осталось очень мало.</p> <p>Если бизнес начинает покупать не ресурсы, а результат, меняется и сам подход к KPI. Раньше в фиксированных проектах большая часть требований была технической: производительность, безопасность, количество обрабатываемых SKU, RPS, допустимая нагрузка. Сейчас показатели все ощутимее уходят в сторону бизнес-метрик: продукт либо выстрелит, либо нет; он либо донесет ценность до аудитории, либо нет.</p> <p>Например, если компания отказывается от внешнего SaaS для работы с подарочными сертификатами и создаёт самописное решение, недостаточно просто запустить систему в срок и обеспечить её техническую стабильность. Результат можно считать достигнутым, если собственная разработка действительно позволила сократить расходы на внешний сервис и обеспечить запланированную экономию. Конечно, технические показатели остаются необходимым условием, но главным критерием успеха становится уже бизнес-эффект.</p> <h3>Что бизнесу стоит оставлять у себя</h3> <p>При этом есть задачи, которые бизнес может отдавать подрядчику, но полностью передавать их на сторону не стоит. В первую очередь это Discovery — проработка бизнес-сценария, требований и того, каким должен быть конечный результат.</p> <p>Представим, что ритейлеру нужно запустить доставку в e-commerce. На рынке много поставщиков логистики: можно подключить одного из них или построить собственную схему. И тут возникает целый набор бизнес-вопросов: как будут организованы возвраты? Сколько все это будет стоить? Можно ли будет купить товар онлайн и вернуть его офлайн? Будет ли примерка? Какие клиентские сценарии нужно реализовать?</p> <p>Это уже не шаблонная техническая задача. Здесь нужно одновременно учитывать клиентский опыт, бизнес-требования, стоимость решения и то, как оно будет работать внутри компании. Эту часть очень сложно полностью вынести за пределы бизнеса. Сначала нужно хорошо прицениться, разобраться в вариантах и понять, как все будет работать. После этого можно сформировать образ конечного результата, и только после этого переходить к реализации.</p> <p>Когда продуктовая команда полностью находится вовне, бизнесу сложнее сохранять контроль над приоритетами и развитием продукта. Поэтому самая рабочая модель, на мой взгляд — комбинированная: Discovery и продуктовая часть остаются на стороне клиента, а разработчики, аналитики, тестировщики и PM — на стороне подрядчика.</p> <h3>Главная серая зона — стык систем</h3> <p>Однако самая частая проблема в крупных проектах возникает не внутри отдельной системы. Она возникает на стыке систем. Интегратор отвечает за свой контур, заказчик — за остальные контуры, а их в крупном ИТ-ландшафте огромное количество. На бумаге все заняты, а в момент запуска выясняется, что никто не отвечает за сквозной сценарий — от витрины до чека.</p> <p>Можно идеально сделать отдельный кусок системы, но покупателю от этого не легче. Он не видит отдельные ИТ-контуры. Он видит свой сценарий: например, оформил заказ онлайн, дождался его, получил от курьера. За этим простым пользовательским сценарием стоит огромное количество ИТ-систем, людей, процессов и вариантов развития событий.</p> <p>И здесь проходит важная граница между обычным подрядчиком и правильным интегратором. Правильный интегратор берет ответственность не за разработку какой-то одной системы отдельно, а за сценарий. И буквально проводит его через весь ИТ-ландшафт, в том числе через внутренние системы заказчика.</p> <h3>Как управлять совместной работой и изменениями</h3> <p>Чтобы внутренняя команда и интегратор работали эффективно, нужен нормально выстроенный продуктовый процесс: обе стороны должны работать в единой парадигме.</p> <p>Есть стандартный процесс: бизнес-анализ, системный анализ, постановка задач, передача их в спринты, определенные метрики эффективности. Все это должно быть подкреплено процессами, системами и понятными правилами. Когда работа скатывается в хаос, даже очень умные люди не будут работать эффективно.</p> <p>И тут возникает вопрос, кто должен задавать эти правила. Внутри компании не всегда хватает экспертизы именно в построении таких процессов. Бизнес может отлично разбираться в своем продукте и операционной деятельности, но это не означает, что у него есть опыт разработки ИТ-продуктов. Поэтому на первый план выходит экспертиза самого интегратора или подрядчика: есть ли у него четко сформулированный фреймворк управления скоростью изменений, то есть понятный процесс, по которому инициатива бизнеса проходит путь от идеи до продакшена.</p> <p>У хорошего подрядчика такой фреймворк должен быть выстроен заранее и работать вместе с его ресурсами и командами. В таком случае заказчик передает ему ответственность за скорость изменений в живой системе, которая связана с большим количеством других систем внутри ИТ-ландшафта. И правильно этим управлять — отдельная и достаточно сложная экспертиза.</p> <p>И отдельная проблема — постоянно меняющееся ТЗ. Это не исключение, а нормальная часть работы над продуктом: бизнес получает новые данные, меняет приоритеты, видит реакцию пользователей и закономерно хочет корректировать решение. Задача ИТ — сделать так, чтобы бизнес понимал, где еще можно дожать, а где дополнительные изменения уже приведут к негативным последствиям. Поэтому здесь важны две вещи: прозрачный процесс и умение говорить с бизнесом на его языке. Хороший подрядчик должен уметь сказать: «Здесь можно, а здесь — нет», и грамотно подсветить риски.</p> <h3>Новая роль ИТ-интегратора</h3> <p>Понять, что перед вами действительно интегратор, а не продавец ИТ-услуг, проще всего по опыту реализации крупных проектов. Если подрядчик работает преимущественно с небольшими проектами, не стоит автоматически ожидать от него экспертизы в сложных продуктовых инициативах, где изменения проходят через десяток систем. Нужно смотреть, были ли крупные проекты, был ли опыт управления большим количеством команд, проектов и изменений в моменте. Есть ли архитекторы, бизнес-аналитики, есть ли описанный фреймворк управления. Если у компании есть опыт генподряда, это хороший сигнал: она уже умеет управлять сложной системой взаимодействий.</p> <p>Все эти изменения происходят на фоне важного фактора — удешевления и ускорения самой разработки благодаря ИИ. По мере того как он меняет подходы к созданию ИТ-продуктов, ценность смещается от собственно написания кода к бизнесовой и процессной экспертизе: умению управлять разработкой, перестраивать процессы и встраивать новые инструменты в работу компании.</p> <p>Если раньше интегратор приходил и говорил: «Давайте внедрим вам коробку, потому что с нуля будет дольше», то сейчас часть таких решений бизнес может собрать собственными командами с помощью ИИ-инструментов. Я уже вижу все больше историй, когда крупные и средние компании делают собственные мессенджеры, таск-трекеры, платформы для работы с LLM и другие внутренние продукты.</p> <p>Поэтому одной экспертизы в поставке коробочных решений со временем будет недостаточно. А вот умение прийти к заказчику, внедрить продукт и одновременно выстроить вокруг него процессы, в том числе автоматизировать с помощью LLM изменение этого продукта, будет гораздо более ценным.</p> <p>Получается интересная и в чем-то парадоксальная ситуация: чем дешевле и доступнее становится непосредственно разработка, тем важнее становится умение правильно организовать изменения. И именно поэтому будущая миссия интегратора — не в том, чтобы быть дополнительными руками для бизнеса. Его задача — помочь бизнесу пройти весь путь от идеи и Discovery до работающего сквозного сценария, взять на себя ответственность за delivery и скорость изменений, а самое главное — сделать так, чтобы в сложном ИТ-ландшафте всегда было понятно, кто отвечает за результат.</p> <p>#IMAGE_235694#</p> Когда благодаря искусственному интеллекту ИТ-разработка становится все дешевле и доступнее, ценность интегратора все меньше … article Станислав Пятецкий, директор по развитию ИТ-интегратора AWG Как превратить рекомендацию ИИ в решение компании https://www.itweek.ru/themes/detail.php?ID=235680 Thu, 08 Oct 2026 10:32:00 +0300 <p><em>Внедрение ИИ в управленческие процессы ставит перед компанией вопрос, который выходит за пределы качества машинного ответа. Система может собрать сведения, сравнить варианты и предложить убедительный вывод. Однако для использования этого вывода в работе нужно определить, кто проверяет его основания, какие условия допускают дальнейшее действие и кто вправе принять связанные с ним обязательства.</em></p> <p><em>Эти вопросы возникают в закупках, согласовании договоров, бюджетировании и других задачах, где информация становится основанием для решения. Разберём на примере выбора поставщика, как организовать этот переход: от исходных документов и рекомендации ИИ до согласования и исполнения заказа.</em></p> <p>ИИ может сопоставить предложения поставщиков и подготовить обоснование выбора. Но при каких условиях рекомендация получает силу разрешения действовать? Этот вопрос нужно решить до того, как компания начнёт оформлять заказы на основе машинных выводов.</p> <p>Представим условную закупку оборудования. Один поставщик предлагает меньшую цену, второй обещает более раннюю поставку, третий включает обслуживание. Условия распределены между коммерческими предложениями, приложениями и перепиской. Система сводит их в таблицу и рекомендует первый вариант. Руководитель видит готовый вывод, согласует его, и закупщик оформляет заказ.</p> <p>Теперь добавим деталь: в позднем письме первый поставщик связал срок отгрузки с поступлением комплектующих. Для компании задержка означает перенос запуска оборудования. Если это уточнение не попало в сравнение, формально безупречная таблица поддерживает решение, для которого не хватает существенного основания. Причина может быть в извлечении данных, доступе к письмам или порядке согласования. Замена модели сама по себе не устраняет весь этот набор проблем.</p> <p>Это учебный сценарий, а не описание конкретного внедрения. На его примере разберём путь от получения сведений до разрешения на закупку.</p> <h3>Из каких действий состоит выбор поставщика</h3> <p>В регламенте выбор поставщика может занимать три строки: собрать предложения, сравнить условия, согласовать выбор. Для проектирования работы с ИИ нужно восстановить несколько завершённых закупок по документам, переписке и действиям участников:</p> <ul> <li> Где появилось важное уточнение? </li> <li> Почему потребовалось повторное подтверждение? </li> <li> Что вернули на доработку? </li> </ul> <p>За строкой «сравнить условия» обнаружатся разные действия. Закупщик проверяет актуальность и комплектность предложений, приводит позиции к сопоставимому виду, уточняет потребность внутреннего заказчика. Затем рассчитывает стоимость и обосновывает выбор. В задании «проанализируй поставщиков» трудно увидеть, какую часть система выполнила и что осталось без внимания.</p> <p>В нашем сценарии необходимо выяснить, где сотрудник обычно узнаёт об изменении срока. Возможно, он возвращается к переписке перед согласованием, потому что коммерческое предложение редко обновляют. Эта повторная проверка компенсирует недостаток процесса. Убрав её ради скорости, компания потеряет способ обнаруживать изменения. Сначала стоит договориться, как актуальные условия попадут в материалы закупки и кто подтвердит, что собрана последняя версия.</p> <p>Существенные действия полезно описать через вход и выход. Из предложения и письма нужно извлечь срок, условия его соблюдения и вопросы для уточнения. Затем сопоставить эти сведения с потребностью компании. Так становится видно, где извлекают факт, где применяют правило, а где выносят профессиональное суждение.</p> <p>#IMAGE_235688#</p> <p>Подробность нужна до тех пор, пока она меняет выбор исполнителя, способ проверки или допустимый риск. Дальнейшее деление работы для первого эксперимента может оказаться избыточным.</p> <h3>Что поручить ИИ, программе и человеку</h3> <p>Извлечение условий из разнородных документов — кандидат для испытания ИИ на ограниченном наборе примеров. Система может собрать цену, состав поставки, срок, условия оплаты и обслуживания со ссылками на фрагменты источников. Пробелы и противоречия должны появиться в результате отдельными незакрытыми вопросами.</p> <p>Расчёт итоговой стоимости по утверждённой формуле целесообразно выполнять обычной программой, используя проверенные значения и явно заданные допущения. ИИ может извлечь исходные данные; арифметика с точным алгоритмом не требует генеративной модели. При этом правильный расчёт не исправит неполные входные данные. Пропущенная стоимость обслуживания останется пропущенной.</p> <p>Владелец потребности должен объяснить, какие ограничения обязательны. Если дата запуска обязательна, нужно определить последнюю допустимую дату получения оборудования с учётом монтажа. Обещания отгрузить его к этой дате недостаточно, а низкая цена не компенсирует опоздание. Пока компания не определила приоритеты, просьба к модели выбрать «лучшего» поставщика оставляет ей слишком много пространства для неявного выбора критериев.</p> <p>Специалист по закупкам рассматривает сопоставимые сведения, выясняет пробелы и формирует заключение. ИИ может предложить аргументы или показать, как изменится рекомендация при других допустимых условиях. Но решение о том, допустима ли отсрочка запуска ради экономии, затрагивает работу компании за пределами закупок. Его нужно передать тому, кто имеет право принять такие последствия.</p> <h3>На чём основана рекомендация ИИ</h3> <p>При передаче результата могут исчезнуть существенные оговорки. Закупщик работал с письмами и ограничениями, а руководитель получил итоговую оценку. Например, «поставщик подходит при подтверждении срока» превратилось в «поставщик подходит».</p> <p>Поэтому материал для согласования должен сохранять связь между существенным выводом и его основанием. Для срока поставки это документ или письмо, дата и точная формулировка условия. Для стоимости — проверенные исходные значения и формула. Для рекомендации — применённые критерии, выявленные ограничения и вопросы, на которые пока нет ответа. Получатель должен иметь возможность проверить важное утверждение без повторного поиска по всей истории закупки.</p> <p>#IMAGE_235689#</p> <p>Ссылка на документ полезна, но сама по себе не подтверждает вывод. В нашем примере раннее предложение тоже содержит срок, только позднее письмо меняет его смысл. Проверять приходится и содержание источника, и его актуальность. Если участники не договорились, какое подтверждение считается действующим, добавление ссылок лишь сделает неразрешённое противоречие заметнее.</p> <p>В интерфейсе вопрос о неподтверждённой дате должен быть виден рядом с рекомендацией. Руководителю важно понимать, что он согласует: окончательный выбор, продолжение переговоров или запрос подтверждения. Одинаковая кнопка «Одобрить» для этих действий создаёт неоднозначность, которую точность модели не устранит.</p> <h3>Кто и на каких условиях разрешает закупку</h3> <p>Утверждение закупки даёт основание расходовать ресурс или принимать обязательство от имени компании. При проектировании процесса нужно отдельно определить, кто и при каких условиях превращает информационный вывод в разрешённое действие.</p> <p>В условной закупке система готовит сравнение, закупщик проверяет факты и оформляет рекомендацию, уполномоченный руководитель одобряет выбор в пределах конкретных условий. После этого сотрудник или система выполняет разрешённое действие. Участники и программы должны различать эти состояния.</p> <p>Для автоматического исполнения границы особенно существенны. Компания может разрешить оформление стандартного заказа у уже допущенного поставщика в пределах установленного лимита, по согласованным условиям и при отсутствии незакрытых вопросов. Это организационное решение необходимо принять до запуска. Доступ системы к функции отправки заказа подтверждает техническую возможность, но ещё не определяет допустимые случаи её использования.</p> <p>Разрешение должно относиться к определённому действию и проверенному набору условий. Согласие продолжить переговоры нельзя использовать как согласие на заказ, а одобрение одной версии предложения — как одобрение любой следующей. Проверку лимитов и обязательных условий нужно выполнять перед отправкой заказа, вне генеративной модели. У модели не должно быть другого пути отправки, позволяющего обойти проверку.</p> <p>#IMAGE_235690#</p> <p>Нужно определить, кто отвечает за полноту материалов, подтверждает расчёт, принимает отклонение и останавливает исполнение при изменении условий. Запись «ответственный — руководитель закупок» мало помогает, если этот руководитель не видит исключений или не может повлиять на действие системы. Ответственность требует доступа к информации и средств вмешательства.</p> <p>В журнале нужно сохранить условия на момент выбора, вывод системы, подтверждения участников и разрешённое действие. Тогда при разборе эпизода можно будет отличить ошибку извлечения от неверного критерия или выхода за пределы согласования.</p> <h3>Как сотрудник будет проверять результат</h3> <p>Фраза «всё проверит человек» кажется достаточной защитой, пока не описана сама проверка. Что сотрудник должен подтвердить? Какие источники ему доступны? Сколько времени это занимает и что происходит при несогласии? Без ответов компания рассчитывает на внимательность человека в условиях, которые сама не определила.</p> <p>В нашем примере проверку стоит связать с последствиями ошибки. Неверно указанный срок может сорвать запуск оборудования, поэтому нужно проверить его основание и условия исполнения. Пропуск включённого обслуживания меняет сопоставимость стоимости. Неточность в формулировке краткого описания поставщика может иметь меньший вес, если она не влияет на выбор. Для каждого существенного поля должен быть понятен способ подтверждения, а не только общая отметка «просмотрено».</p> <p>Проверяющий должен уметь вернуть материал на уточнение, исправить ошибку и указать причину несогласия. Если интерфейс позволяет лишь принять готовый вывод, содержательная проверка превращается в обходной процесс: замечания уходят в сообщения, исправления остаются в отдельном файле. Затем следующему участнику приходится заново восстанавливать контекст, ради сохранения которого и меняли систему.</p> <p>Если каждый результат ИИ требует повторного чтения всех документов, работа может переместиться с подготовки на контроль без сокращения общих усилий. Проверяющему нужен способ увидеть пропущенное, а не только подтвердить написанное. Поэтому проверку полноты исходных сведений нужно выделить отдельно и учитывать её трудоёмкость.</p> <p>Для стандартных операций компания может рассмотреть выборочный контроль, обосновав его результатами на своём потоке, ценой ошибки и возможностью её обнаружить. Ни постоянное участие человека, ни отказ от ручных подтверждений сами по себе не определяют качество решения.</p> <h3>Что делать, если данных не хватает или условия не подходят</h3> <p>Вернёмся к письму об отгрузке. Система обнаружила, что срок зависит от комплектующих. Правильный результат на этом этапе может состоять в приостановке выбора и запросе подтверждения. Для компании это полезнее, чем принудительно завершённый рейтинг с первым местом, хотя в демонстрации такой ответ выглядит менее эффектно.</p> <p>Чтобы остановка не превратилась в потерянную заявку, у исключения должен быть адресат и следующий шаг. Закупщик уточняет условие у поставщика; владелец потребности оценивает допустимость переноса; руководитель с нужными полномочиями принимает решение об отклонении. До ответа система сохраняет незакрытый вопрос и блокирует только те дальнейшие действия, которые действительно от него зависят.</p> <p>Сотрудник должен знать, кому передать случай, для которого нет правила. Решение по нестандартной закупке нужно сохранить вместе с основанием. Делать из него общее правило можно лишь после отдельного рассмотрения.</p> <p>#IMAGE_235691#</p> <p>Стоит заранее проиграть и отказ системы: источник недоступен, документ не читается, обновление не получено. Отсутствие данных нельзя приравнивать к отсутствию проблемы. Нужно убедиться, что участники видят остановку и могут продолжить работу согласованным способом.</p> <h3>Как проверить весь процесс на реальных закупках</h3> <p>Для первого эксперимента я бы выбрал ограниченный класс закупок с доступными материалами. Сначала систему можно проверить на завершённых эпизодах, включая возвраты и противоречивые условия. Ей нужно давать сведения, доступные участникам на соответствующем этапе, без подсказки из последующей истории. Иначе проверка будет проще реальной работы.</p> <p>Оценивать стоит не только совпадение с прежним выбором. Сам прежний выбор тоже мог быть спорным. Важно установить, какие существенные факты найдены, что пропущено, какие вопросы система должна была оставить открытыми и можно ли проверить её вывод. Участникам нужно заранее договориться о критериях качества и о том, какие ошибки потребуют остановить эксперимент.</p> <p>Следующий шаг — ограниченная работа на текущих закупках с выбранным режимом контроля. Здесь становятся видны ожидание подтверждений, фактическая нагрузка проверяющих и действия при исключениях. Сравнивать нужно полное время получения пригодного для согласования результата, число возвратов и усилия всех участников. В расходы входят подготовка данных, проверка, исправления и поддержка решения. Скорость генерации таблицы показывает лишь небольшой фрагмент этой картины.</p> <p>Полезно сравнить новый порядок и с более простым улучшением: единым местом хранения актуальных предложений, подтверждением срока, шаблоном сравнения и обычным расчётом. Если задержка исчезает после наведения порядка в данных, это помогает определить дополнительный вклад ИИ и оценить, оправдывает ли он затраты.</p> <p>Высвободившееся время можно направить на дополнительные варианты или переговоры, определив, кто использует этот ресурс и что меняется в закупке. После адаптации сотрудников стоит повторно посмотреть на реальную работу: не появились ли новые перепроверки и не перенеслась ли нагрузка в соседнее подразделение.</p> <p>Перед расширением руководителю полезно попросить команду показать одну закупку целиком. Откуда взялось существенное условие? Кто подтвердил его актуальность? Почему выбран этот поставщик? Какое именно действие разрешено и что остановит его при изменении данных? Если ответы доступны только разработчику или требуют заново разбирать всю переписку, устройство работы ещё нуждается в доработке.</p> <p>В нашем примере итог может выглядеть так: цена первого поставщика ниже, но срок отгрузки зависит от комплектующих; соответствие дате запуска не подтверждено. Закупщик запрашивает уточнение, оформление заказа приостановлено. После ответа обновляется сравнение и на согласование передаётся конкретная версия условий. По этой записи понятно, что обнаружила система, что осталось неизвестным и какое действие разрешено.</p> <h3>Заключение</h3> <p>Таким образом, внедрение ИИ требует спроектировать весь путь от получения информации до исполнения решения. На каждом переходе должны сохраняться существенные условия: откуда взялись сведения, что проверено, какие вопросы открыты и какое действие разрешено. Если эти связи теряются, даже корректная рекомендация может привести к необоснованному действию.</p> <p>Для руководителя практический критерий готовности прост — команда должна уметь показать этот путь на конкретном рабочем эпизоде, включая ошибку, изменение условий и остановку исполнения. Такой разбор помогает понять, где ИИ действительно сокращает нагрузку, а где лишь переносит её на проверяющих. Расширять применение системы имеет смысл после проверки всей цепочки и её результата для компании.</p> <p>#IMAGE_235687#</p> Внедрение ИИ в управленческие процессы ставит перед компанией вопрос, который выходит за пределы качества … article Аскер Аскеров, архитектор ИИ-систем для руководителей и компаний ИСИЭЗ НИУ ВШЭ: как россияне пользуются сервисами с ИИ https://www.itweek.ru/themes/detail.php?ID=235679 Wed, 07 Oct 2026 14:52:36 +0300 <p>Институт статистических исследований и экономики знаний (ИСИЭЗ) НИУ ВШЭ в рамках новой волны Мониторинга цифровой трансформации общества проанализировал, для каких задач россияне обращаются к ИИ-сервисам и как эти практики менялись в последние годы.</p> <p>За последние три месяца к ИИ-сервисам обращались четыре из пяти интернет-пользователей (79%); порядка четверти — ежедневно (24%), более трети (37%) — несколько раз в неделю. Наиболее высока доля среди подростков <nobr>14–17</nobr> лет (93%) и молодежи <nobr>18–24</nobr> лет (92%). В городах показатель составляет 81%, в поселках городского типа — 78%, в селах и деревнях — 71%. При анализе пользовательских практик мужчин и женщин значимых различий не выявлено.</p> <p>Наиболее востребованы встроенные в привычную цифровую среду ИИ-решения — голосовые помощники (58%) и режим ИИ в интернет-браузерах (42%). Универсальные сервисы генеративного ИИ (ChatGPT, «Алиса AI», «ГигаЧат» и др.) используют более трети (34%) респондентов. К специализированным сервисам («Шедеврум», Midjourney, Synthesia и др.) обращался лишь каждый девятый.</p> <p>Результаты проведенного опроса свидетельствуют о трансформации практик поиска информации в Сети: вместо того чтобы самостоятельно переходить по многочисленным ссылкам, делегируют ИИ эту задачу более половины интернет-пользователей (52%). Довольно востребованы сервисы для генерации изображений (34%); другие творческие задачи, например, создание и редактирование видео и музыки, решают с помощью ИИ заметно реже (11%). Более четверти пользователей ИИ-сервисов доверяют им перевод текстов или написание и редактирование (28 и 27% соответственно).</p> <p>Каждый пятый привлекает ИИ к подготовке личных писем или сообщений, а также воспринимает как личного консультанта, в частости по вопросам физического здоровья (в группе респондентов 55+ доля выше: 28%). За психологической поддержкой к ИИ обращались 9%, среди 18—24-летних — почти вдвое чаще (17%). Реже всего с помощью ИИ генерируют программный код (5%). Эта задача является более специализированной и требует от пользователя общего понимания основ программирования. </p> <p>Не обращались к ИИ-сервисам за последние три месяца 21% интернет-пользователей. Самый распространенный мотив — отсутствие необходимости или желания (60%). Примечательно, что в группе респондентов 65+, которая обычно отличается консерватизмом в освоении инноваций, такую причину называли реже (45%), чем в среднем по выборке, причем по сравнению с 2024 г. эта доля снизилась, что указывает на рост интереса к ИИ-сервисам среди россиян старших возрастов.</p> <p>Недостаток необходимых навыков назвали препятствием 15% (в подгруппе 65+ более четверти (28%)), по сравнению с 2024 г. доля таких ответов снизилась на 9 п. п. Другие причины отказа от ИИ-сервисов называли еще реже: 12% респондентов им не доверяют, 11% — опасаются зависимости. Риск утечки данных сдерживает лишь 4% опрошенных в этой группе. Никогда не слышали об ИИ-сервисах только 1% не пользовавшихся ими респондентов, еще два года назад их доля составляла 18%. Ее резкое снижение показывает, насколько быстро ИИ входит в повседневную жизнь.</p> Институт статистических исследований и экономики знаний (ИСИЭЗ) НИУ ВШЭ в рамках новой волны Мониторинга цифровой … message «Индид»: российский рынок защиты учетных данных и контроля доступа достиг 17 млрд рублей https://www.itweek.ru/themes/detail.php?ID=235678 Wed, 07 Oct 2026 14:51:45 +0300 <p>Компания «Индид», разработчик решений в области безопасности айдентити, представила результаты исследования российского рынка Identity Security, подготовленное при участии Айдентити Клуба. Оно посвящено ключевым технологиям, практикам защиты учетных данных и подходам к управлению доступом в российских компаниях. Отчет был представлен на <nobr>III-ей</nobr> ежегодной конференции Айдентити Конф 2026.</p> <p>По итогам 2025 года российский рынок безопасности айдентити (Identity Security) достиг 17 млрд рублей. Крупнейшим сегментом остается управление привилегированным доступом (PAM) с долей 34,6%, а наиболее высокую динамику роста среди PAM, IdM и MFA показывает направление IdM/IGA — 16% за год. А 87,5% опрошенных компаний сталкивались с инцидентами вокруг учетных записей и прав доступа.</p> <p>Исследование охватило 200 организаций со штатом от 100 сотрудников, включая крупнейшие российские и международные компании численностью более 10 000 человек. В нем приняли участие представители ИТ, информационной безопасности, управления персоналом и генерального руководства.</p> <p>Полученные данные показывают, что Identity Security в России переходит от набора отдельных технологий к самостоятельному направлению информационной безопасности. Многофакторную аутентификацию (MFA) уже используют около 70% компаний, PAM формирует более трети рынка, а автоматизация управления учетными записями и правами доступа (IdM) становится одним из наиболее быстрорастущих направлений.</p> <p>При этом развитие технологий заметно опережает зрелость процессов: MFA распространяется на всех сотрудников и системы только в 36% организаций, а специализированная IdM внедрена пока только в каждой четвертой организации. При этом PAM пока используется далеко не во всех сценариях: для управления доступом администраторов такие системы применяют 36,5% организаций, тогда как 64,5% по-прежнему в основном полагаются на регламенты и логирование.</p> <p>«Identity Security — относительно молодое направление информационной безопасности, которое сейчас проходит этап активного формирования. Растет число цифровых идентичностей, усложняются инфраструктуры, появляются новые сценарии доступа и требования к их защите. Поэтому компаниям важно смотреть не только на отдельные технологии, но и на общую динамику рынка, реальные практики и зрелость процессов. Такая оценка позволяет увидеть, какие изменения уже становятся системными и куда движется рынок», — отметил Алексей Баранов, генеральный директор «Индид».</p> <p>PAM остается крупнейшим сегментом российского рынка защиты учетных данных и управления доступом. В 2025 году его объем составил 5,8 млрд рублей, что на 13% больше, чем годом ранее. Меняется модель предоставления прав. Компании постепенно отходят от постоянных полномочий в пользу более гибких сценариев, где учитываются срок доступа, конкретная задача и уровень риска.</p> <p>Для внешних подрядчиков компании чаще применяют временные и ограниченные сценарии доступа. 42% организаций выдают им временные учетные записи через IdM, 41% предоставляют доступ вручную под конкретную задачу, а 32% используют PAM. Это показывает стремление компаний точнее ограничивать срок и объем полномочий внешних пользователей.</p> <p>Такой подход позволяет точнее связывать полномочия с конкретной работой и сокращать период, в течение которого пользователю доступны корпоративные ресурсы. При этом временная модель пока не стала стандартом. В 45,5% организаций права по-прежнему выдаются на постоянной основе до момента их отзыва, а Just-in-Time-доступ, при котором полномочия предоставляются только на время выполнения конкретной задачи, используется значительно реже. Похожая ситуация и с Zero Trust: основные элементы подхода реализованы лишь в 16,5% компаний, еще в 22% они применяются только для внешних подключений и подрядчиков.</p> <p>Таким образом, рынок постепенно движется от постоянных прав к доступу под конкретную задачу и на ограниченный срок. Но пока этот переход находится на раннем этапе: бессрочные полномочия по-прежнему широко распространены. Для бизнеса развитие такой модели означает более прозрачное управление тем, кто, когда и на каком основании получает доступ к корпоративным ресурсам, а также снижение рисков, связанных с накоплением избыточных прав.</p> <p>Сохраняющиеся ручные процессы и расширение цифровой инфраструктуры увеличивают количество рисков, связанных с учетными записями. 87,5% опрошенных компаний сталкивались с инцидентами вокруг учетных записей и прав доступа. Наиболее распространенными стали ошибки при ручном назначении прав — их отметили 43,5% участников исследования.</p> <p>Среди других проблем — компрометация привилегированных учетных записей, действия сотрудников в обход политик безопасности и несанкционированная активность технических и сервисных аккаунтов. С последним сценарием сталкивались 35,5% компаний. На фоне роста числа машинных айдентити и усложнения инфраструктуры подобный риск приобретает высокое значение.</p> <p>Для бизнеса последствия таких инцидентов выходят за рамки информационной безопасности: ошибочно или избыточно выданные полномочия могут затрагивать конфиденциальные данные, критичные системы и непрерывность операционных процессов. Поэтому управление доступом все теснее связывается не только с предотвращением несанкционированного входа, но и с тем, что происходит с учетной записью после успешной аутентификации.</p> <p>В результате меняется и подход к защите айдентити. Многофакторная аутентификация остается одним из базовых механизмов защиты, но не закрывает все сценарии компрометации учетных данных. Поэтому компании постепенно дополняют проверку при входе анализом активности пользователя на протяжении всей сессии. Поведенческую аналитику в реальном времени сегодня применяют лишь 19% организаций. Значительно чаще аномалии обнаруживаются уже постфактум с помощью SIEM или DLP.</p> <p>На этом фоне развивается подход Identity Threat Detection and Response (ITDR), который объединяет данные об аутентификации, правах, конфигурациях и поведении и позволяет выявлять угрозы уже после успешного входа в систему и на протяжении всей пользовательской сессии.</p> <p>«Сегодня поведенческий анализ в реальном времени используют далеко не все компании, хотя он становится важной частью современного подхода к защите айдентити. При этом сам по себе этот механизм не решает задачу полностью — наибольший эффект достигается в сочетании с другими технологиями защиты. Аудит запросов доступа, минимизация разрешений, многофакторная аутентификация, обнаружение небезопасных конфигураций и анализ пользовательского поведения вместе формируют подход Identity Threat Detection and Response. В условиях, когда против бизнеса действуют организованные группы киберпреступников, отдельных мер защиты уже недостаточно: их сочетание позволяет оценивать риски в инфраструктуре айдентити, выявлять аномальную активность и своевременно реагировать на угрозы», — отмечает Лев Овчинников, руководитель продукта Indeed ITDR в Индид.</p> <p>Одним из наиболее заметных трендов становится появление автономных ИИ-агентов. Вместе с ними меняется и привычное представление о субъекте доступа: корпоративными ресурсами начинают пользоваться не только люди и сервисные учетные записи, но и системы — агенты, способные самостоятельно выполнять цепочки действий.</p> <p>Единого подхода к управлению такими айдентити пока нет. В частности, 20% компаний полностью запрещают сотрудникам использование ИИ-агентов, тогда как 19% практически не контролируют их применение.</p> <p>Это формирует новый класс задач для рынка: идентификация агента, выдача и отзыв полномочий, ограничение срока доступа, контроль действий и фиксация связи между агентом и человеком, от имени которого он действует. Среди перспективных инструментов защиты эксперты называют IAM/IGA для агентов, Credential Broker, AI-proxy, сквозное логирование и динамическую выдачу минимальных прав.</p> <p>Для бизнеса вопрос выходит за рамки контроля новой технологии. По мере того как ИИ-агенты включаются в корпоративные процессы и получают возможность самостоятельно обращаться к системам и данным, компаниям приходится определять владельца такой идентичности, границы ее полномочий и ответственность за совершенные действия.</p> <p>«ИИ-агентов нужно рассматривать как еще одного полноценного сотрудника. Чтобы робот мог обрабатывать или передавать данные в корпоративных системах, ему необходим доступ. На практике сотрудники нередко передают таким агентам свои личные учетные записи, исходя из логики, что робот просто имитирует их действия. Но это создает новые риски: агент работает значительно быстрее человека и при неверной настройке может, например, создать чрезмерную нагрузку на целевую систему», — прокомментировал Андрей Нуйкин, начальник отдела обеспечения безопасности информационных систем, «Евраз».</p> <p>Распространение технологий само по себе еще не означает зрелость рынка Identity Security. В исследовании выделены четыре уровня: начальный — с преимущественно ручным управлением доступом, базовый с отдельными средствами защиты и регламентами, стандартизированный с автоматизированными процессами, ролевой моделью и SSO, и стратегический с элементами Zero Trust и принятием решений на основе контекста. Практически половина респондентов — 46,5% организаций оценивают зрелость защиты учетных записей в своих организациях выше среднего. При этом предоставить новому сотруднику все необходимые права быстрее чем за рабочий день могут только 28,5% компаний.</p> <p>Этот разрыв показывает, что зрелость определяется не только наличием технологий, но и тем, насколько эффективно они встроены в процессы компании. Поэтому следующий этап развития рынка будет связан уже не только с внедрением новых решений, но и с глубиной их интеграции: автоматизацией выдачи и отзыва прав, регулярным пересмотром полномочий, сокращением ручных операций и переходом к непрерывному анализу рисков.</p> <p>Практики крупных организаций показывает высокий потенциал такого подхода. В одном из рассмотренных кейсов более 80% из сотен тысяч ежемесячных запросов на доступ удалось перевести в полностью автоматический режим. В масштабе крупной инфраструктуры это позволяет не только сократить объем ручных операций, но и обрабатывать растущее количество запросов без сопоставимого увеличения нагрузки на ИТ- и ИБ-команды.</p> <p>При этом эффект измеряется не только сокращением ручной работы. Скорость предоставления доступа напрямую влияет на то, как быстро сотрудник может приступить к своим задачам и насколько бесперебойно работают бизнес-процессы. Поэтому автоматизация управления учетными записями и правами постепенно становится не только задачей информационной безопасности, но и фактором операционной эффективности.</p> <p>«До внедрения IdM создание учетной записи в ИТ занимало до трех дней, и это было слишком долго. Операционный персонал на складах и в ПВЗ приходит на рабочее место в семь утра, в восемь часов они начинают собирать заказы. Для бизнеса приоритетны непрерывность процессов и скорость выхода сотрудника на работу, а задача ИБ — обеспечить, чтобы доступы не только оперативно предоставлялись, но и своевременно отзывались. Когда стало очевидным, что скорость выдачи доступов напрямую влияет на бизнес-процессы и, соответственно, результат, руководство поддержало инвестиции и выделило ресурсы на развитие системы. На первом этапе мы настроили базовые процессы создания и блокировки учетных записей. Тогда кастомных сценариев почти не было, а уже сегодня в системе работает около 400 кастомных процессов», — подчеркнул Илья Кулешов, руководитель отдела развития информационной безопасности «Ламода Тех».</p> <p>Ответственность за управление доступом при этом в большинстве организаций сосредоточена между двумя функциями: 40,5% компаний закрепили ее за ИБ, 39,5% — за ИТ. Эксперты отмечают эффективность модели, при которой ИБ определяет требования и методологию, а ИТ отвечает за их реализацию на уровне систем.</p> <p>При этом управление доступом все меньше остается исключительно технической задачей. Оно напрямую связано с кадровыми процессами, работой владельцев корпоративных систем и бизнес-подразделений: от качества исходных данных и скорости взаимодействия между ними зависит, насколько быстро сотрудник получит необходимые полномочия и будут ли они своевременно изменены или отозваны.</p> <p>Главным препятствием для повышения зрелости рынка защиты айдентити остается финансирование: 49,5% компаний называют недостаток бюджета основным барьером. Далее следуют сложность исторически сложившейся инфраструктуры, нехватка специалистов и организационное сопротивление изменениям.</p> <p>Затраты связаны не только с приобретением решений, но и с их дальнейшим масштабированием и эксплуатацией. По мере увеличения числа пользователей, систем и сценариев доступа растет инфраструктурная нагрузка, поэтому экономическая эффективность проекта все сильнее зависит от архитектуры, модели лицензирования и степени автоматизации процессов.</p> <p>«Первая проблема — стоимость. Например, по мере внедрения PAM растет не только стоимость инфраструктуры: при сессионной модели лицензирования увеличение числа одновременных подключений означает и необходимость регулярно докупать concurrent-лицензии. Вторая проблема — нагрузка на инфраструктуру. С ростом числа пользователей качественно и количественно выросла нагрузка на саму систему. Решение приходится масштабировать, а это снова означает дополнительные расходы и увеличение инфраструктуры, которую нужно поддерживать», — отметил Даниил Мирошник, руководитель направления SOC, «Домклик».</p> <p>Высокая стоимость остается и наиболее распространенной проблемой отечественных решений: ее отметили 48,5% респондентов.</p> <p>Несмотря на это, 57% участников исследования оценивают российские решения защиты айдентити на уровне зарубежных аналогов или выше. Это показывает, что дальнейшее развитие рынка будет зависеть уже не только от функциональности продуктов, но и от их способности масштабироваться вместе с инфраструктурой, встраиваться в существующие процессы и обеспечивать понятную экономику их эксплуатации.</p> <p>В результате рынок Identity Security входит в этап, когда его развитие определяется уже не только появлением новых технологий, но и способностью компаний связать их в единую систему управления айдентити. Рост числа учетных записей, машинных идентичностей и ИИ-агентов будет только усиливать этот запрос. На первый план выходят автоматизация, управляемость и экономическая эффективность — способность одновременно снижать риски, поддерживать непрерывность процессов и не создавать дополнительных ограничений для бизнеса.</p> Компания «Индид», разработчик решений в области безопасности айдентити, представила результаты исследования российского … message AppSec Solutions ускорили анализ мобильных приложений с помощью ИИ https://www.itweek.ru/themes/detail.php?ID=235677 Wed, 07 Oct 2026 14:49:44 +0300 <p>AppSec Solutions представила два обновления платформы анализа защищённости мобильных приложений Appsec.Sting: управление проверками через ИИ-агентов по протоколу MCP и поддержку виртуальных iPhone с iOS 26. Инженеры могут поручать агентам настройку проверок, прохождение пользовательских сценариев и разбор результатов, а для анализа iOS-приложений использовать стабильную виртуальную среду.</p> <p>Поддержка MCP открывает ИИ-агентам доступ к функциям AppSec.Sting. AppSec-инженер может поставить задачу на естественном языке: настроить правила поиска и профиль сканирования, проверить нужный сценарий, получить результаты и разобрать найденные проблемы. Агент выполняет действия в пределах прав пользователя, а специалист определяет цель проверки, верифицирует выводы и контролирует качество.</p> <p>«Одна из ключевых возможностей интеграции состоит в том, что агент взаимодействует с самим мобильным приложением: просматривает экран, нажимает на элементы интерфейса, выполняет свайпы и вводит текст. Инженер может поручить ему прохождение пользовательских сценариев, необходимых для динамического анализа, а затем разбор результатов. Это позволяет делегировать значительную часть работы с инструментом и уделять больше внимания полноте проверки и подтверждению найденных проблем», — рассказал директор по продукту Appsec.Sting Никита Пинаев.</p> <p>Для пользователя эти действия складываются в последовательный процесс: от настройки проверки до получения и разбора результатов. Проверки выполняют модули AppSec.Sting, а агент управляет процессом и помогает объяснять причины обнаруженных проблем и готовить рекомендации по исправлению. События взаимодействия через MCP журналируются при включённом аудите.</p> <p>По внутренним замерам AppSec Solutions, использование агента ускорило работу AppSec-инженера в <nobr>3–5</nobr> раз в протестированных сценариях. Эффект зависит от приложения, поставленной задачи и глубины проверки результатов специалистом. Для начала работы необходимо настроить подключение агента к AppSec.Sting.</p> <p>Второе обновление даёт пользователям AppSec.Sting стабильную среду динамического анализа на виртуальных iPhone с iOS 26. В неё перенесён полный функционал проверок на физических iPhone с iOS 16. Виртуальные устройства запускаются на компьютерах с Apple Silicon и не требуют подключения физического телефона. Для работы необходимо подключить виртуальную среду к AppSec.Sting.</p> <p>«Главная ценность для пользователя здесь в стабильной среде динамического анализа на свежей iOS. Инженеры могут исследовать поведение приложений на новой версии системы, сохраняя привычный набор возможностей анализа. Поддержка физических iPhone сохраняется, поэтому выбор среды зависит от задачи проверки», — подчеркнул Никита Пинаев.</p> <p>Виртуальная среда предоставляет root-права и работает в rootless-режиме. Инструментация приложения, позволяющая наблюдать за его работой во время анализа, реализована через твики без использования Frida.</p> <p>AppSec.Sting развивается на микросервисной архитектуре Kubernetes и сохраняет монолитную поставку. Работа через MCP доступна в обеих версиях, в том числе при развёртывании в инфраструктуре заказчика.</p> AppSec Solutions представила два обновления платформы анализа защищённости мобильных приложений Appsec.Sting: управление … message Унаследованные системы — это не обуза, а конкурентное преимущество в эпоху ИИ https://www.itweek.ru/themes/detail.php?ID=235676 Wed, 07 Oct 2026 09:59:29 +0300 <p><em>В погоне за максимальной эффективностью велик соблазн отказаться от унаследованных технологий, однако именно эти системы хранят уникальные данные и инсайты, которые невозможно воспроизвести конкурентам, пишет на портале </em><em>InformationWeek</em> <em>Джон Низли, директор по управлению ценностью ИИ-решений компании ABBYY.</em></p> <p>Спортивные команды с богатой историей не разрушают всё, что работает, лишь потому, что на арене появляются новые соперники. Ferrari продолжает побеждать в гонках — не отказываясь от накопленного десятилетиями инженерного опыта, а дополняя проверенную базу новыми талантами, технологиями и более совершенной аналитикой. Почему же в Кремниевой долине к унаследованным корпоративным системам относятся как к чему-то постыдному?</p> <p>На протяжении многих технологических циклов я наблюдаю один и тот же сценарий: вам говорят, что ваши основные системы, работающие десятилетиями, — это причина, по которой буксуют ваши цифровые амбиции. Совет всегда один: выбросить их, заменить и начать с чистого листа.</p> <p>Такой подход ошибочен. Унаследованные системы хранят многолетнюю историю транзакций, алгоритмы обработки нестандартных ситуаций и логику соблюдения нормативных требований — всё то, что не может синтезировать ни один стартап и что нелегко воспроизвести стороннему поставщику. Ваш опыт — это конкурентное преимущество, которое невозможно купить, а не якорь, тянущий вас на дно.</p> <p>Секрет успеха заключается в том, чтобы использовать эти активы в рамках вашей ИИ-стратегии и дать им новую жизнь, а не избавляться от них вовсе.</p> <h3>Проблема «последней мили», которую не могут решить универсальные LLM</h3> <p>Сложность в том, что эти ценные унаследованные активы зачастую еще не оптимизированы для использования в процессах ИИ. Ключевым фактором, определяющим успех или провал ИИ-проектов, становится последний неавтоматизированный участок корпоративного рабочего процесса — неструктурированные данные. Десятилетия договоров, претензий, счетов, медицинских карт и деловой переписки формируют накопленную историю деятельности вашего бизнеса. Однако эти данные хранятся в виде отсканированных PDF-файлов, факсов и форматов, предназначенных для чтения людьми, а не для обработки моделями ИИ.</p> <p>Кроме того, существует проблема перехода от пилотного проекта, где аналитик вручную проверяет несколько тысяч специально отобранных документов, к полномасштабному промышленному внедрению. На этом этапе часто выявляются проблемы, неочевидные в лабораторных условиях. Результаты извлечения данных могут варьироваться от запуска к запуску, а отсутствие сигнала неуверенности не позволяет вовремя направлять сомнительные случаи на проверку человеку. Сама по себе интеграция большой языковой модели (LLM) приводит к выдаче уверенных и правдоподобных, но зачастую неверных ответов, при этом у команд комплаенса отсутствует «аудиторский след», позволяющий проследить, как именно был сформирован результат. Возникающий в такой ситуации разрыв между пилотным проектом и промышленной эксплуатацией может иметь катастрофические последствия.</p> <p>Именно здесь критически важной становится проверенная корпоративная архитектура ИИ. Организациям вовсе не обязательно заставлять LLM «читать» каждое слово в документе; уже существуют специализированные ИИ-приложения, решающие подобные сложные задачи: они способны извлекать смысл из документов со сложной структурой, сохранять контекст и форматирование, а также подготавливать информацию для использования другими ИИ-системами. Предприятия, упорядочившие свои унаследованные данные, могут использовать LLM как дополнительный уровень обогащения информации, которая уже была извлечена и структурирована.</p> <p>В результате мы получаем более эффективный гибридный сценарий использования ИИ: точность повышается, расход токенов и затраты на обработку снижаются, а для каждой конкретной задачи подбирается наиболее подходящая технология.</p> <h3>Миф об окупаемости при полной замене систем</h3> <p>Также важно учитывать экономические аспекты стратегии «полной замены» (rip-and-replace) — распространенного подхода к модернизации устаревших технологий.</p> <p>Недавнее исследование компании Publicis Sapient показало, что 75% из 1550 опрошенных предприятий регулярно используют ИИ, однако лишь 10% считают его по-настоящему ключевым элементом своей деятельности. Это указывает на разрыв между наличием инструментов и их эффективным применением: компании обладают необходимыми средствами, но им сложно заставить уже имеющиеся системы и данные работать с максимальной отдачей.</p> <p>Замена проверенной в деле основной системы — это многомиллионные инвестиции с длительным сроком окупаемости и реальными операционными рисками. Речь идет не просто о смене ПО: приходится переобучать персонал, перестраивать интеграции и рисковать тем, что новый технологический стек сам станет проблемой в будущем.</p> <p>Именно поэтому я рекомендую итеративный подход к внедрению ИИ. Он предполагает альтернативный путь: наслоение специализированных интеллектуальных функций поверх систем, уже обеспечивающих работу бизнеса, что позволяет получить отдачу за месяцы, а не за годы. Это выбор не между унаследованными технологиями и ИИ, а выбор в пользу их наиболее эффективного сочетания. ИИ способен сократить объем ручной проверки при урегулировании страховых претензий, ускорить процесс онбординга клиентов за счет автоматической обработки документов, а также оптимизировать анализ договоров и обработку счетов в финансовом секторе. Каждый из этих сценариев использования обеспечивает измеримый возврат инвестиций (ROI), сохраняя при этом надежность и предсказуемость затрат, свойственные унаследованным протоколам.</p> <h3>Практическое руководство по извлечению выгоды из унаследованных систем</h3> <p><strong>«</strong>Унаследованное» не означает устаревшие подходы или ограниченные возможности. Это проверенные временем технологии, которые годами выдерживает аудиты, всплески нагрузки, пристальное внимание регуляторов и реальные запросы клиентов.</p> <p>Чтобы получить преимущество, нужно предпринять пять тактических шагов.</p> <ol> <li><strong> Начните с процессов, а не с продуктов.</strong> Мы любим приобретать технологии для решения проблем, но настоящим препятствием почти всегда становятся процессы и люди. Прежде чем что-либо автоматизировать, разберитесь в текущей операционной деятельности на уровне конкретных задач.</li> <li><strong> В первую очередь приведите в порядок фундамент данных.</strong> Целенаправленно структурируйте неструктурированные данные. Это инвестиция с самой высокой отдачей, которую можно сделать перед масштабированием ИИ.</li> <li><strong> Внедряйте ИИ там, где реально выполняется работа, а не там, где проводилась демонстрация.</strong> Выбирайте рабочие процессы, в которых ИИ приносит наибольшую пользу, и интегрируйте его именно туда. Сохраняйте системы, которые уже работают.</li> <li><strong> Оценивайте результаты в сравнении с процессом, который вы заменяете.</strong> ИИ, внедренный поверх существующей системы, создает динамическую базу для сравнения с исходным рабочим процессом, позволяя оценивать стоимость транзакции, длительность цикла и частоту возникновения исключительных ситуаций. Если вы не можете измерить показатели, вы не сможете их спрогнозировать или обосновать, а предсказуемость затрат имеет значение.</li> <li><strong> Четко понимайте, когда действительно необходима полная замена системы.</strong> Если платформа больше не поддерживается, поставщик ушел с рынка или требования регулятора невозможно выполнить ни на одном уровне поверх базовой системы — значит, пришло время двигаться дальше. Не привязывайтесь к конкретным технологиям; формируйте свой стек, выбирая лучшие инструменты для каждой задачи, а не ту платформу, на которую вас «подсадил» поставщик.</li> </ol> <h3>Перестаньте извиняться за то, что уже работает</h3> <p>Лидерами становятся не те компании, которые гонятся за каждой новой моделью. Побеждают те, кто понял, что проблема была вовсе не в модели, и решил заставить существующие системы работать эффективнее, быстрее и «умнее».</p> <p>Ваши унаследованные системы — доказательство того, что вы создали нечто надежное. Дополните этот фундамент целенаправленным, хорошо управляемым ИИ — и вы сможете добиться точности и скорости, недоступных конкурентам, пытающимся выстроить всё с нуля.</p> В погоне за максимальной эффективностью велик соблазн отказаться от унаследованных технологий, однако именно эти … article Как ИИ изменит мониторинг ИТ-систем к 2029 году https://www.itweek.ru/themes/detail.php?ID=235674 Wed, 07 Oct 2026 09:45:36 +0300 <p><em>Искусственный интеллект перейдёт от подсказок к действиям: агенты будут сами устранять типовые сбои и реагировать на угрозы, в ряде компаний возьмут на себя ночные смены целиком, а наблюдаемость станет главным способом контролировать код, который написал ИИ.</em></p> <p>Год назад я <a href="https://www.itweek.ru/management/article/detail.php?ID=232571">описывал</a> три слоя ИИ в наблюдаемости: динамическую норму и прогноз, корреляцию событий и диалог с моделью. Все три слоя сегодня есть в зрелых платформах, в том числе российских. Следующим шагом станет четвёртый — действие: ИИ перестанет быть «справочным окном» и начинает непосредственно выполнять работу.</p> <h3>От подсказки к действию</h3> <p>Уже сейчас агент умеет по инструкции на обычном русском языке провести проверку, сравнить результат с нормой и объяснить дежурному, что произошло. Через три года стандартом станет, что тот же агент ещё и устраняет проблему. Инструкции дежурной смены из внутренней базы знаний, которые никто не читает, особенно в три часа ночи, превратятся в исполняемые регламенты.</p> <h3>Системы, которые чинят себя сами</h3> <p>Типовые инциденты — переполненный диск, зависший сервис, исчерпанный пул соединений, неудачный выпуск новой версии — будут закрываться без участия человека. Большая часть ночных вызовов — это повторяющиеся ситуации с давно известным решением: надо просто что-то перезапустить, расширить, «откатить» или переключить нагрузку. Держать ради этого инженера на телефоне дорого и бессмысленно, ведь система, которая видит сбой, понимает причину и знает регламент, должна всё исправить сама, а человеку прислать отчёт, который тот прочитает утром.</p> <p>Важная деталь в том, что такие системы учатся. Разбор каждого инцидента превращается в урок, и в следующий раз агент действует быстрее. Опыт перестаёт уходить вместе с людьми, и это, пожалуй, главная ценность для компаний, где дежурные смены постоянно обновляются.</p> <h3>Агент — полноправный член дежурной смены</h3> <p>Уверен, что к 2029 году ИИ-агенты будут работать в дежурных сменах наравне с людьми: со своими полномочиями, зоной ответственности и журналом действий, причем где-то вообще полностью возьмут на себя ночные смены и выходные, а люди будут подключаться только по эскалации.</p> <p>Изменится и роль инженеров: из «пожарных» они станут теми, кто пишет регламенты, определяет границы полномочий агентов и разбирает нетиповые случаи. Агенту, как и новому сотруднику, доверие выдаётся ступенями: сначала он советует, потом действует с подтверждением, потом — сам в согласованных границах. И вопрос только в том, как быстро компании выстроят эти ступени.</p> <h3> Мониторинг и безопасность сходятся </h3> <p>На уровне телеметрии деградация сервиса и атака часто выглядят одинаково: всплеск запросов, необычная нагрузка, странное поведение процесса. Разводить эти задачи по разным командам и системам становится всё дороже, а агенты начнут реагировать на опережение и в рамках выданных полномочий: смогут изолировать подозрительный узел, ограничить аномальный трафик, приостановить учётную запись, а дальше передать данные специалистам по инфобезопасности.</p> <h3>Код, который никто не знает</h3> <p>Этот тренд самый недооценённый. Раньше хотя бы разработчик понимал, что происходит в его коде, а сегодня часть, которую пишут агенты, становится всё больше, и по-настоящему код не знает никто. При этом он всё равно попадёт в промышленную эксплуатацию после проверок, тестов и согласований, по итогам которых все будут уверены, что всё в порядке.</p> <p>Теперь единственный способ узнать, как такой код ведёт себя на самом деле, — наблюдать за ним в работе. Наблюдаемость из инструмента эксплуатации превращается в главный механизм контроля качества. Метрики, логи и трассировки становятся по сути документацией: они рассказывают, что делает код, лучше, чем любой человек в команде. Телеметрия будет закладываться в код уже при генерации.</p> <h3>Три условия</h3> <p>Есть три условия, без которых этот сценарий не сработает. Первое — качественные данные: агент, который не видит метрик, логов и трассировок, действует вслепую, как и человек, который смотрит на чужой код. Поэтому открытые стандарты вроде OpenTelemetry, о которых мы говорили год назад, из тренда превратились в фундамент.</p> <p>Второе — управляемость: каждое действие агента должно фиксироваться в журнале, а права — выдаваться и отзываться по регламенту, как у сотрудника. Регулятор движется в ту же сторону: в проекте изменений ФСТЭК России к требованиям по защите информации в государственных инфосистемах уже предусмотрен контроль прав доступа ИИ-агентов, в том числе автономных.</p> <p>Третье условие — суверенность. Для банков, промышленности и госсектора агент, который отправляет данные во внешнее облако, неприемлем. Всё должно работать внутри контура заказчика на российских или локальных моделях.</p> <p>#IMAGE_235675#</p> Искусственный интеллект перейдёт от подсказок к действиям: агенты будут сами устранять типовые сбои и реагировать … article Илья Захаров, директор департамента мониторинга “Группы Астра” Обновленная версия Машины искусственного интеллекта Скала^р позволяет повысить загрузку GPU-ускорителей до 85% https://www.itweek.ru/themes/detail.php?ID=235669 Tue, 06 Oct 2026 16:43:53 +0300 <p>Группа Rubytech расширила возможности Машины искусственного интеллекта Скала^р, включив в ее состав платформу управления ИИ-инфраструктурой Спектр ИИ — программный продукт собственной разработки. Решение позволяет увеличить загрузку уже приобретенных GPU-ускорителей с типичных <nobr>30–40%</nobr> до <nobr>70–85%</nobr> и сократить затраты на закупку нового оборудования.</p> <p>Машина искусственного интеллекта Скала^р МИИ — программно-аппаратный комплекс (ПАК), предназначенный для построения масштабируемой инфраструктуры разработки, обучения и исполнения моделей искусственного интеллекта с гарантированной производительностью. Это готовый технологический стек: полностью совместимое оборудование из реестра Минпромторга и программное обеспечение из реестра Минцифры. Ключевые системные компоненты — операционные системы и платформа контейнерной виртуализации — имеют сертификаты ФСТЭК России, что подтверждает защищенность решения. Такой состав упрощает и ускоряет аттестацию Машины в защищенных контурах, где она обязательна по требованиям регуляторов.</p> <p>Набор дополнительных инструментов позволяет пользователям ускорить развертывание ИИ-моделей, а также обеспечить мониторинг, безопасность и мультитенантность. Платформа Скала^р Спектр ИИ отвечает за централизованное управление ИИ-инфраструктурой, мониторинг и оптимальное распределение ресурсов GPU при работе с моделями машинного обучения (ML) и большими языковыми моделями (LLM), а также за гибкое развертывание и эксплуатацию моделей, ИИ-приложений, агентских систем и рабочих сред для Data Science-специалистов.</p> <p>На типовой инсталляции компаниям редко удается добиться утилизации GPU-ускорителей выше <nobr>30–40%,</nobr> поскольку вычислительные ресурсы используются разными подразделениями с разной степенью интенсивности. В результате больше половины уже оплаченных мощностей простаивает, а при росте числа задач приходится закупать новое оборудование. Спектр ИИ работает с GPU-узлами в рамках единого управляемого кластера и позволяет планировать и перераспределять нагрузку между командами. Встроенный планировщик управляет очередями и приоритетами задач, а разделение GPU на части обеспечивает мультитенантность. Утилизация ускорителей вырастает до <nobr>70–85%</nobr> без потери производительности, а расширение парка GPU при масштабировании можно отложить. </p> <p>Основные функции платформы Спектр ИИ:</p> <ul> <li>управление рабочими узлами с возможностью предварительной конфигурации; </li> <li>управление приоритетами выполнения ИИ-задач в кластере в соответствии с заданной конфигурацией очередей;</li> <li>создание контейнеров с аппаратным ускорением GPU для быстрого развертывания готовых решений и приложений, моделей, настроенных рабочих сред для задач ИИ;</li> <li>запуск и оркестрация контейнеров с ИИ-нагрузками на основе ролевой модели; </li> <li>распределение нагрузок как на целых GPU, так и на их частях;</li> <li>полный цикл управления сервисами: запуск, остановка, очистка ресурсов;</li> <li>управление корпоративным каталогом моделей и приложений, загружаемых как с внешних ресурсов (Hugging Face), так и из внутренних репозиториев; </li> <li>сбор и визуализация показателей нагрузки системы для выбранного узла;</li> <li>отображение данных о количестве токенов, потребляемых и генерируемых языковыми моделями;</li> <li>разграничение прав доступа к запускаемым языковым моделям;</li> <li>быстрая проверка развернутой модели в диалоговом режиме.</li> </ul> <p>Платформа Скала^р Спектр ИИ разворачивается на кластере под управлением Deckhouse Kubernetes Platform и работает на операционных системах «РЕД ОС» и Astra Linux. Управление ресурсами и очередями ведется из одного интерфейса по единой ролевой модели, с возможностью «бронирования» мощностей под критичные задачи. Решение поддерживает масштабирование до 32 узлов по 8 GPU в каждом. </p> <p>«Сегодня бизнес может по-разному использовать инфраструктуру ИИ: например, развернуть на ней локальную языковую модель, которая обрабатывает внутренние документы и предоставляет ответы на запросы сотрудников, или организовать одновременную работу нескольких команд ИИ-разработки на одном GPU-кластере. В любом случае компании необходима высокая производительность и надежность. Спектр ИИ предоставляет возможность создания каталога моделей компании, управляет инференсом, ограничивает доступ в соответствии с политиками безопасности, подсчитывает токены по пользователям и позволяет контролировать загрузку ресурсов GPU. Это решение, которое превращает дорогостоящие GPU-ускорители в гибко управляемый и прозрачно контролируемый ресурс, приносящий реальную эффективность», — прокомментировал Вадим Солдатов, директор по ИИ-продуктам Скала^р (Группа Rubytech).</p> Группа Rubytech расширила возможности Машины искусственного интеллекта Скала^р, включив в ее состав платформу … message YADRO представила ИИ-сервер с жидкостным охлаждением https://www.itweek.ru/themes/detail.php?ID=235668 Tue, 06 Oct 2026 16:42:07 +0300 <p>Технологическая компания YADRO (входит в ИКС Холдинг) представила сервер YADRO G4208P G3 с жидкостным охлаждением (СЖО) на форуме «Цифровые решения». Версия с СЖО продолжает развитие сервера с учетом роста мощности GPU, тепловой нагрузки и требований к размещению высокопроизводительного вычислительного оборудования в ЦОД.</p> <p>Современные ускорители обеспечивают все более высокую вычислительную производительность, одновременно повышая энергопотребление и требования к отводу тепла. Максимальную нагрузку формируют продолжительные вычислительные циклы — обучение и инференс ИИ-моделей, инженерное моделирование, научные расчеты, визуализация и другие задачи с высокой загрузкой GPU. По мере роста вычислительной плотности параметры охлаждения становятся одним из ключевых факторов при проектировании инфраструктуры ЦОД.</p> <p>YADRO G4208P G3 с СЖО использует жидкостное охлаждение процессоров и GPU — наиболее теплонагруженных компонентов вычислительной системы. В ходе испытаний при 100% загрузке температура GPU не превышала 60 °C при температуре окружающей среды <nobr>22–23</nobr> °C и 77 °C — при 39 °C. При существенном росте температуры на площадке тепловой режим ускорителей сохранялся предсказуемым. Для эксплуатации ИИ-инфраструктуры это снижает зависимость температурного режима GPU от внешних условий и уменьшает воздействие температурных перепадов — одного из факторов, влияющих на надежность и ресурс ускорителей.</p> <p>Надежность GPU напрямую влияет на непрерывность длительных ИИ-вычислений. В крупном исследовании процесса предобучения флагманской языковой модели Llama 3 с 405 млрд параметров анализировались причины незапланированных остановок вычислений. За <nobr>54-дневный</nobr> период неисправности GPU стали крупнейшей отдельной категорией и составили более 30%.</p> <p>YADRO G4208P G3 с жидкостным охлаждением размещается в стандартной серверной стойке и подключается к внешней системе отвода тепла. На площадках с действующим жидкостным контуром сервер интегрируется в существующую инфраструктуру охлаждения. Решение расширяет возможности внедрения жидкостного охлаждения в действующих ЦОД без комплексной перестройки инженерной инфраструктуры площадки.</p> <p>Жидкостное охлаждение входит в число направлений развития высоконагруженной вычислительной инфраструктуры YADRO. Ранее компания анонсировала комплексное решение для охлаждения ЦОД, включающее BOREY «Посейдон» — оборудование для подготовки и циркуляции теплоносителя и отвода тепла — и интегрированные вычислительные комплексы RACKSCALE. Вместе с серверами с жидкостным охлаждением решения формируют технологическую основу для проектов, где рост вычислительной мощности требует соответствующего развития систем охлаждения ЦОД.</p> <p>«С ростом мощности GPU требования к отводу тепла становятся одним из факторов, определяющих конфигурацию вычислительной инфраструктуры. Мы последовательно развиваем YADRO G4208P G3 с учетом новых классов ускорителей, тепловых нагрузок и условий размещения оборудования. Жидкостное охлаждение расширяет возможности дальнейшего развития сервера и подготовки вычислительных систем к следующему уровню требований рынка», — отметил Михаил Михеев, директор по серверным продуктам YADRO.</p> <p>YADRO G4208P G3 с жидкостным охлаждением представлен на форуме «Цифровые решения» в составе экспозиции решений компании на стенде ИКС Холдинга. Ранее, в сентябре, YADRO расширила возможности G4208P G3 для более мощных GPU-конфигураций. Версия с жидкостным охлаждением стала следующим этапом развития сервера вслед за ростом мощности ускорителей, тепловой нагрузки и изменением требований к инфраструктуре ЦОД.</p> Технологическая компания YADRO (входит в ИКС Холдинг) представила сервер YADRO G4208P G3 с жидкостным охлаждением (СЖО … message CICADA8: российские компании защищены всего на 6,7 баллов из 10 https://www.itweek.ru/themes/detail.php?ID=235667 Tue, 06 Oct 2026 16:41:04 +0300 <p>Организации с крупным внешним цифровым периметром чаще чем в три раза сталкиваются с критическими уязвимостями, чем организации с небольшим числом внешних активов, считают авторы исследования «Кибербезопасность российского бизнеса 2026» аналитики CICADA8.</p> <p>По результатам исследования эксперты пришли к выводу, что периметр российских компаний меняется, но медленно. Из более чем 20 тыс. организаций под непрерывным наблюдением в первом полугодии 2026 года свои позиции в рейтинге существенно улучшили 4,9%, ухудшили — 2,5%, у 92,6% они остались в прежнем диапазоне. Из компаний, у которых на начало года были критические уязвимости, их число сократили 30,8%, в том числе полностью устранили лишь 14,6%, у 53,5% состав критических уязвимостей не изменился.</p> <p>По абсолютному рейтингу, который отражает ситуацию с информационной безопасностью здесь и сейчас по совокупности объективных признаков, лидирует отрасль науки и образования с показателем 7,49 балла из 10. За ней следуют транспорт и логистика (6,84), ИТ и разработка ПО (6,83), здравоохранение (6,79) и медиа с рекламой (6,74). Больше нареканий вызывает ситуация в госсекторе и у НКО (6,46), в недвижимости (6,57), в торговле и e-commerce (6,59), в сфере профессиональных услуг и финансовом секторе (6,62), а также в строительстве и промышленности (6,65).</p> <p>Таким образом, средний балл защищенности внешнего периметра российских компаний составляет 6,7 балла. При этом, отраслевая принадлежность компании оказывается вторичной для оценки уровня защищенности конкретной организации — куда важнее зрелость подхода в управлении внешним периметром, а также необходимо учитывать его размеры — чем больше у компании внешних цифровых активов, тем ниже ее способность контролировать их. </p> <p>При оценке зрелости управления периметром с поправкой на его размер картина меняется. У организаций, где из интернета доступны 500 и более активов, средний рейтинг защищенности составляет 4,96 балла из 10, у компаний с <nobr>10–20</nobr> активами — 7,89. Критические уязвимости обнаружены у 77% компаний первой группы и у 24% — во второй. При сравнении компаний с организациями сопоставимого масштаба можно оценить не только объем и сетевую гигиену инфраструктуры в целом, но и качество работы с ней.</p> <p>Таким образом, с позиции отраслей лучше остальных со своими активами работают научные и образовательные организации, компании финансового сектора, а также в ИТ. Разница в оценке показательнее всего для финансового и государственного секторов. При общем сравнении в абсолютном рейтинге финансовые организации стоят на <nobr>11-м</nobr> месте, но при периметре вдвое больше среднего они удерживают защищенность выше ожидаемой для своего масштаба и поднимаются на <nobr>2-е</nobr> место рейтинга по зрелости. Та же ситуация с госсектором, у которого один из самых крупных периметров (медианное значение для отрасли — 70 активов). При сравнении с равными сегмент держится в середине таблицы по зрелости — <nobr>7-е</nobr> место.</p> <p>Эксперты CICADA8 также сформировали профиль риска компаний, который включает шесть аспектов внешней защищенности: уязвимости прикладного ПО, утечки учетных данных, репутация адресного пространства, доступность управляющих интерфейсов, состояние сертификатов и транспортного шифрования, конфигурация DNS. </p> <p>На уровне рынка фокус российских компаний в основном лежит в области защиты ПО (оценка 3,09 из 10, где 10 — максимальный уровень риска), а также снижения рисков утечек данных (2,68). Аналитики отмечают, что в подавляющем большинстве случаев утечки происходят не в самих компаниях: компрометации подвергаются сторонние сервисы, которыми пользуются сотрудники — от почтовых систем и мессенджеров до сервисов доставки и профессиональных сообществ. </p> <p>«Закрыть критическую уязвимость на внешнем сервисе — задача на несколько дней, а не проект трансформации. Несмотря на это, у подавляющего большинства компаний за полгода состояние периметра не изменилось. Как правило, причина лежит в том, что организации просто не видят, как их инфраструктура выглядит снаружи. Для заказчика здесь вывода два. Во-первых, оценивать нужно каждого конкретного подрядчика, а не делать обобщения по отрасли. Во-вторых, заказчикам придется становиться движущей силой и мотивировать своих контрагентов к лучшему контролю за своими цифровыми активами, потому что сами по себе найденные у поставщика проблемы не исчезнут, а риски для информационной безопасности лишь возрастут», — отметил Никита Котиков, владелец продукта CICADA8 CyberRating.</p> <p>В CICADA8 подчеркивают, что в текущих условиях регулярная независимая оценка уровня защищенности контрагентов становится одним из ключевых элементов системы управления рисками третьих сторон.</p> Организации с крупным внешним цифровым периметром чаще чем в три раза сталкиваются с критическими уязвимостями … message Как избежать вендорлока с помощью Open Source: взгляд разработчика https://www.itweek.ru/themes/detail.php?ID=235666 Tue, 06 Oct 2026 10:48:42 +0300 <p><em>Андреас Принс, руководитель направления решений для обеспечения суверенитета компании SUSE, рассказывает на портале </em><em>The</em> <em>New</em> <em>Stack</em> <em>о том, как открытый исходный код помогает разработчикам избежать привязки к поставщику (вендорлока), защитить цифровой суверенитет и поддерживать гибкую архитектуру ПО.</em></p> <p>Каждая команда, отвечающая за инфраструктуру, принимает решения, которые трудно отменить. В большинстве случаев они срабатывают. Иногда — нет.</p> <p>Вендорлок обычно начинается как разумный выбор, сделанный в условиях нехватки времени или бюджета, который решает реальную проблему на текущий момент. Управляемый сервис поставляется быстрее или модель развертывания лучше подходит в данный момент, но в конечном итоге возникают сложные ограничения.</p> <p>Когда условия ведения бизнеса неизбежно изменятся, эти накопленные решения и их последствия определят, сможет ли команда соответствующим образом перестроиться. Ограничения гибкости редко связаны с одним поставщиком; чаще они зависят от того, насколько обратимы прошлые решения команды.</p> <h3>Что такое вендорлок и как он может навредить вашему бизнесу</h3> <p>Риски вендорлока на самом деле не связаны с зависимостью от поставщиков, поскольку каждая производственная система зависит от поставщиков. Главная проблема — это зависимости, от которых становится слишком дорого или непрактично отказаться.</p> <p>Для платформенной команды эта зависимость накапливается в API, контрактах, планах развития и моделях данных. Она распространяется дальше на управляемые сервисы, шаблоны идентификации, конвейеры мониторинга и операционные инструменты. Каждый элемент, вероятно, представляет собой разумное проектное решение, но вместе они могут незаметно ограничивать ваши возможности и повышать стоимость перехода. Когда смена базы данных или плоскости управления означает переписывание множества интеграций, переобучение всего персонала или миграцию данных в неудобные сроки, вы теряете пространство для маневра.</p> <h3>Большие последствия небольших, невидимых и непродуманных решений</h3> <p>Не каждая зависимость автоматически является проблемой; некоторые понятны, локализованы и стоят того, чтобы пойти на компромисс. Реальный риск заключается в зависимостях, которые никто тщательно не изучал и которые могут оставаться невидимыми до тех пор, пока не начнут препятствовать развитию бизнеса.</p> <p>К сожалению, некоторые команды знакомы с этими невидимыми зависимостями. Управляемая база данных может использовать проприетарные расширения, которые затем начинает использовать код приложения. Среда Kubernetes может быть привязана к IAM, сети, хранилищу и балансировщику нагрузки одного облака. Конвейеры наблюдаемости и логирования могут быть ориентированы на форматы одного поставщика. Ни один из этих вариантов сам по себе не является безрассудным, но вместе они могут создавать значительные проблемы.</p> <h3>Препятствия на пути к изменениям и их скрытые издержки</h3> <p>Масштаб компромисса, основанного на зависимостях, иногда остается неизвестным до тех пор, пока не изменятся обстоятельства, такие как новые требования комплаенса или потребность клиентов в новой модели развертывания. Скрытые издержки в такие моменты часто растут поэтапно. Это может начаться с видимого нежелательного счета за миграцию, но расходы также могут проявиться в виде операционных задержек. Спешные миграции могут привести к дополнительным сбоям в работе сервисов позже. Рабочая нагрузка может быть недоступна для перемещения, что ограничивает доступ к сервисам для определенных клиентов. Когда вы привязаны к ритму выпуска конкретного поставщика, это может затруднить или даже сделать невозможным внедрение новых технологий.</p> <p>Риск концентрации усугубляет проблему, поскольку одно изменение от одного поставщика, влияющее на ценообразование, качество поддержки и дорожную карту, может распространиться по всей инфраструктуре. К тому моменту, когда становится необходимым переключение, затраты проявляются в виде сбоев в работе сервиса, сложной передачи данных и переобучения. Раннее выявление этих затрат предотвращает их неожиданное возникновение.</p> <p>В какой-то момент зависимость может накопить достаточно таких затрат, чтобы стать чем-то большим, чем просто архитектурной деталью. Поскольку это начинает влиять на бюджеты и сроки, руководство должно это учитывать, а команда должна быть готова это объяснить. Раннее выявление этих зависимостей дает всем время на планирование.</p> <h3>Open Source предлагает другой путь</h3> <p>Один из способов заблаговременного решения этой проблемы — более тщательно оценивать потенциальные зависимости. Например, прежде чем принимать решение о переходе на платформу или сервис, попытайтесь определить его обратимость. Другими словами, выясните, насколько сложно будет команде изменить свое мнение об инвестициях в будущем.</p> <p>Решения с открытым исходным кодом, как правило, хорошо справляются с этим тестом, поскольку они специально созданы для того, чтобы системы оставались проверяемыми, переносимыми, поддерживаемыми и заменяемыми. По своей сути, Open Source упрощает сохранение вариантов с течением времени. Однако это не гарантирует защиты от вендорлока, поскольку команда может построить тесные взаимосвязи и на открытой основе.</p> <h3>Что такое Open Source</h3> <p>Open Source описывает ПО, которое вы можете проверять, запускать, модифицировать, расширять, поддерживать и заменять с относительной лёгкостью по сравнению с проприетарными альтернативами. Исходный код ПО доступен, а лицензия предоставляет вам право использовать и изменять его. Следует отметить, что бесплатное ПО не обязательно является Open Source, особенно если оно не предоставляет такого уровня доступа и прав.</p> <p>В основе деятельности многих компаний лежат принципы Open Source, и ПО с открытым исходным кодом может быть чрезвычайно ценным в корпоративном контексте. Прозрачный код часто проще проверять, а открытые стандарты могут уменьшить трение при переходе между инструментами.</p> <h3>Open Source также меняет правила игры</h3> <p>Для разработчиков обратимость касается не только API и форматов данных. Она также касается того, может ли одна компания изменить условия, лежащие в основе базовой технологии. Ядро Linux — полезный пример. В документации ядра Linux отмечается, что передача авторских прав не требуется, поэтому объединенный код сохраняет свое первоначальное право собственности, и теперь у ядра тысячи владельцев. Это делает одностороннее перелицензирование ядра фактически нереальным.</p> <p>Kubernetes имеет другую юридическую структуру, но практическая защита аналогична. Проект лицензирован в соответствии с Apache 2.0 и управляется Cloud Native Computing Foundation. Лицензия предоставляет пользователям бессрочные права на существующий код, поэтому ни один поставщик не может задним числом отнять эти права на открытый исходный код у проекта в том виде, в котором он уже существует. Это важно, потому что платформа будет оставаться доступной, даже если конкретный поставщик изменит свою стратегию.</p> <p>Разветвление Terraform на OpenTofu показывает, почему это не просто теоретическое различие. В 2023 г. HashiCorp изменила лицензию Terraform с Mozilla Public License 2.0 на Business Source License 1.1. Сообщество отреагировало, создав форк последнего открытого исходного кода в OpenTofu, теперь это проект Linux Foundation, который остается под лицензией MPL 2.0. Урок для разработчиков заключается не в том, что каждый Open Source-проект застрахован от изменений в лицензировании. Он заключается в том, что открытое лицензирование и нейтральное управление могут сохранить жизнеспособный вариант выхода, когда поставщик меняет направление.</p> <h3> Open Source, подкрепленный корпоративной дисциплиной </h3> <p>Open Source в конечном итоге заслуживает своего места благодаря инженерной дисциплине. Доступность исходного кода имеет преимущества, но сама по себе не решает проблемы управления, исправления ошибок, управления жизненным циклом, документации, безопасности или интеграции. Проект сообщества может быть мощным и, тем не менее, существовать без операционных гарантий корпоративного уровня.</p> <p>Существуют Open Source-поставщики для предприятий, которые могут помочь восполнить этот пробел. Они поддерживают открытые фонды и добавляют поддержку, безопасность, обслуживание и дисциплину жизненного цикла, которые необходимы производственным средам. Цель этих компаний — не закрыть доступ к ПО с открытым исходным кодом, а сделать его надежным в корпоративном масштабе. Другими словами, открытый исходный код и операционная строгость могут сосуществовать. И предприятия должны ожидать и того, и другого от любого внешнего поставщика.</p> <h3>Цифровой суверенитет: Х-фактор, делающий Open Source еще более важным</h3> <p>Цифровой суверенитет определяет степень контроля организации над своими инфраструктурой, данными, операциями и выбором технологий. Суверенитет — это спектр, и архитектурные решения могут продвинуть организацию на шаг в любом направлении.</p> <p>Недавнее <a href="https://www.suse.com/news/98-of-enterprises-prioritize-digital-sovereignty-with-more-than-half-taking-action/">исследование</a> SUSE показывает, что почти все предприятия уделяют приоритетное внимание цифровому суверенитету, но только 52% активно предпринимают шаги в этом направлении. Этот разрыв в значительной степени является проблемой реализации, и большая его часть проявляется в повседневных решениях, касающихся платформы.</p> <p>Если ваша команда поддерживает регулируемые отрасли или развертывает системы в локальных или изолированных средах, вы, возможно, особенно знакомы с растущим давлением в отношении суверенитета.</p> <h3>Суверенитет устанавливает дедлайн для работы, которая и так уже стоила того, чтобы ее выполнить</h3> <p>Услышав термин «цифровой суверенитет», разработчики могут решить, что речь идет об отдельном направлении работ по обеспечению комплаенса, которое потребует дополнительных инженерных затрат. На практике же значительная часть этой работы сводится к тем же задачам, в которые уже вкладываются платформенные команды: обеспечению переносимости рабочих нагрузок, чистоте интерфейсов, автоматизированной проверке, воспроизводимости развертывания, проверяемости и возможности замены зависимостей без переписывания всей системы.</p> <p>Эти практики уже имеют экономическое обоснование. Они снижают затраты на миграцию, уменьшают операционные риски, делают изменения платформы менее разрушительными и сохраняют возможности при изменении цен, правил или бизнес-требований. Суверенитет не делает эту инженерную работу внезапно ценной. Он устанавливает дедлайн для работы, которая и так уже стоила того, чтобы ее выполнить.</p> <p>Такое изменение формулировки важно, потому что оно превращает суверенитет из наложения политики в свойство архитектуры. Важный вопрос заключается не просто в том, «во сколько дополнительной работы обойдется суверенитет». Вопрос звучит так: «Какие элементы нашего технологического стека уже не проходят проверки на переносимость, совместимость интерфейсов и возможность верификации, которые мы считаем важными?»</p> <h3>Как укрепить суверенитет с помощью Open Source</h3> <p>Суверенитет зависит от того, как команда проектирует, развертывает и эксплуатирует свои системы. Open Source не делает организацию суверенной автоматически, но может создать более благоприятные условия для обеспечения суверенитета.</p> <p>По сути, многие вопросы, позволяющие выявить проблему вендорлока, важны и для цифрового суверенитета. Каждый из приведенных ниже вопросов, касающихся возможности отказа от выбранного решения, имеет прямое отношение как к Open Source, так и к суверенитету:</p> <table> <tbody> <tr> <th> Вопрос обратимости </th> <th> Чем может помочь открытый исходный код </th> <th> Как укрепляется суверенитет </th> </tr> <tr> <td> Можно ли запустить эту рабочую нагрузку в другом месте? </td> <td> Решения с открытым исходным кодом обычно работают в локальных, облачных, гибридных и периферийных средах, а не только на платформе одного конкретного поставщика. </td> <td> Больше возможностей для контроля над тем, где выполняются рабочие нагрузки, включая выбор конкретных регионов и учет требований регулируемых отраслей.</td> </tr> <tr> <td> Можно ли понять принцип работы системы и провести её аудит? </td> <td> Доступность исходного кода и возможность его проверки сообществом обеспечивают лучшую прозрачность по сравнению с закрытыми решениями. </td> <td> Команды могут проверять поведение системы, оценивать риски и выполнять требования к надежности и безопасности.</td> </tr> <tr> <td> Можем ли мы перенести или повторно использовать наши данные?</td> <td> Открытые экосистемы отдают предпочтение открытым форматам и совместимым инструментам. </td> <td> Данные остаются более переносимыми, что улучшает контроль над их хранением и перемещением.</td> </tr> <tr> <td> Может ли обеспечить поддержку другая команда или партнер? </td> <td> Существуют различные варианты поддержки: от собственных команд до интеграторов и крупных поставщиков корпоративных решений. </td> <td> Снижается зависимость от ценовой политики, доступности или планов развития конкретного поставщика.</td> </tr> <tr> <td> Можно ли заменить один компонент, не переписывая всё заново? </td> <td> Открытые интерфейсы и модульная архитектура упрощают замену компонентов. </td> <td> Больше возможностей для управления архитектурой при изменении требований.</td> </tr> <tr> <td> Сможем ли мы продолжать работу, если поставщик сменит курс? </td> <td> Проекты с открытым исходным кодом могут пережить стратегию или условия лицензирования конкретного поставщика. </td> <td> Меньшая зависимость от решений, на которые команда не может повлиять.</td> </tr> <tr> <td> Можно ли развернуть решения ближе к данным? </td> <td> ПО с открытым исходным кодом может работать в частных дата-центрах, суверенных облаках, на периферии сети и в гибридных моделях. </td> <td> Управление конфиденциальными рабочими нагрузками, включая ИИ, может осуществляться ближе к данным.</td> </tr> </tbody> </table> <h3> Постоянная работа над обеспечением цифрового суверенитета </h3> <p>Суверенитет — это скорее непрерывный процесс, чем конечная цель. Для многих команд работа начинается с выявления существующих зависимостей, от которых особенно трудно избавиться. Также необходимо различать компромиссы, на которые стоит пойти, и те, что существенно ограничивают дальнейший выбор.</p> <p>В дальнейшем полезно отдавать приоритет открытым интерфейсам и переносимым подходам. При оценке новых сервисов или продуктов следует уделять первостепенное внимание жизненному циклу, поддержке и механизмам управления.</p> <p>В некоторых случаях задача обеспечения суверенитета может оказаться слишком сложной для выполнения силами только внутренней команды. Поставщики услуг могут помочь укрепить операционный уровень (включая безопасность и наблюдаемость), особенно в условиях масштабирования или использования гибридных сред.</p> <p>Автоматизированные проверки позволяют воплотить эти принципы на практике, обеспечивая непрерывное тестирование возможности пересборки, перемещения, аудита и восстановления рабочих нагрузок, не дожидаясь, пока миграция или проверка на комплаенс выявят имеющиеся пробелы.</p> <h3>Open Source позволяет взять под контроль вашу экосистему ПО</h3> <p>Ни одна корпоративная команда не может полностью избежать зависимостей — да и не стоит пытаться это делать. Определенная степень связанности компонентов вполне разумна, контролируема и оправдана. Полный отказ от использования сторонних поставщиков для крупного предприятия — цель нереалистичная. Реалистичная цель — умение отличать допустимые зависимости от опасных.</p> <p>Принцип обратимости дает конкретную основу для такого анализа, поскольку его можно разделить на возможности, которые команда способна определить, оценить и проверить:</p> <ul> <li><strong> Владение.</strong> Владение не означает, что всё нужно создавать самостоятельно. Это означает наличие реальной возможности выполнять, перемещать или передавать управление на каждом уровне вашего технологического стека. Проверка проста: если бы поставщик завтра исчез или получил предписание прекратить обслуживание, что из ваших систем продолжило бы работать в следующем месяце?</li> <li><strong> Возможность аудита.</strong> Вы должны иметь возможность самостоятельно (или с привлечением назначенного вами аудитора) проверять, как работает ваше ПО, а не просто принимать отчет поставщика как истину в последней инстанции. В случае с Open Source возможность проверки — это ваше неотъемлемое право. В случае с проприетарным ПО — это разрешение, которое вам предоставляют, но могут и отозвать.</li> <li><strong> Скорость выхода.</strong> План выхода без учета скорости — это просто документ. Скорость выхода показывает, как быстро рабочую нагрузку можно перенести с одной платформы на другую; этот показатель имеет смысл лишь тогда, когда вы проверяете его регулярно — подобно тому, как раньше проверяли системы аварийного восстановления.</li> <li><strong> Возможность маневра.</strong> Эта возможность критически важна при изменении условий: появлении новых нормативных требований, запросе клиента на иную модель развертывания или смене курса поставщиком. Команды, способные перенаправить рабочие нагрузки, действуют по собственному графику. Команды, лишенные такой возможности, вынуждены вести переговоры со слабой позиции.</li> </ul> <p>Риск вендорлока становится управляемым, если вы можете уверенно определить решения, которые трудно отменить, честно взвесить все «за» и «против» и сохранить для команды возможность внести изменения в будущем. Использование Open Source-решений усиливает каждый из этих аспектов, поскольку делает значительную часть системы доступной для анализа, переносимой и заменяемой.</p> <p>В реальную стоимость любой платформы входят и затраты на отказ от нее; командам следует осознавать эти издержки, прежде чем принимать окончательное решение о ее внедрении.</p> Андреас Принс, руководитель направления решений для обеспечения суверенитета компании SUSE, рассказывает на портале The New … article Обучение ИИ на открытых данных: почему бесплатно не значит без последствий https://www.itweek.ru/themes/detail.php?ID=235664 Tue, 06 Oct 2026 10:30:08 +0300 <p><em>На первый взгляд может показаться, что обучать ИИ на открытых данных — беспроигрышный вариант. В самом деле — тексты и изображения лежат в свободном доступе, то есть и результат принадлежит тому, кто обучил модель. На практике за этой простотой скрывается сразу несколько правовых ловушек. Рассмотрим, какие риски с ними связаны и почему общедоступное не равно ничье.</em></p> <h3> Ловушка непрозрачности </h3> <p>Прежде чем рассуждать о том, кто и как отвечает за обучение ИИ на чужих материалах, стоит разобраться с одним техническим обстоятельством — именно оно во многом определяет, почему тема вообще считается такой запутанной. Речь о принципиальной непрозрачности готовой модели. Когда обучение завершено, она представляет собой терабайты числовых коэффициентов, и ни один инструмент не позволяет вскрыть их и доказать, что вот этот конкретный роман или вот эта фотография участвовали в тренировке. Исходный текст не лежит внутри весов в виде, который можно предъявить как улику, — он растворен в статистике, и строго, математически подтвердить факт его использования после обучения невозможно.</p> <p>Отсюда рождается соблазнительный, но ошибочный вывод: раз доказать присутствие конкретного произведения в обученной модели нельзя, то и спрашивать не с кого. На деле непрозрачность модели вовсе не оставляет авторов беззащитными — она лишь смещает точку, в которой закон способен вмешаться. Проверить веса действительно не выйдет, но у любого обучения есть два наблюдаемых момента: то, что подается на вход, и то, что модель выдает на выходе. Именно на этих двух участках и работает правовая защита — причем в российском законодательстве она уже прописана, то есть изобретать новые нормы ради нейросетей даже не требуется.</p> <h3>Вход и выход</h3> <p>Любой обучающий набор, будь то коллекция текстов или изображений, с точки зрения права представляет собой базу данных, а у баз данных в российском законодательстве есть оговоренная защита. Статья 1334 ГК РФ закрепляет за их изготовителем смежные права. Это означает, что способ получения данных имеет значение сам по себе — еще до всякого обучения. Если разработчик датасета тайком выкачал закрытую библиотеку или коммерческую базу, чтобы затем скормить ее модели, нарушение произошло уже в этот момент — независимо от того, что потом получилось на выходе и можно ли это доказать. Никакой особой статьи про ИИ здесь не нужно: нарушены ровно те же нормы, которые защищают любую базу данных от несанкционированного копирования.</p> <p>Если же говорить о точке выхода, то сгенерированный результат считается самостоятельным произведением, но оно точно так же, как и данные на входе, не должно посягать на права других авторов. Если модель воспроизводит чужой текст дословно или выдает изображение, до степени смешения повторяющее оригинал, налицо прямое использование чужих авторских прав. В этом случае включается статья 1266 ГК РФ — она закрепляет право на неприкосновенность произведения, запрещая без согласия автора вносить в его текст или изображение любые изменения, искажения и дополнения. Показательно, что для оценки такого нарушения непрозрачность модели вообще не имеет значения. Спорный результат лежит перед глазами, его можно сравнить с оригиналом и оценить как любое другое заимствование.</p> <h3>Права никто не отменял</h3> <p>Главная проблема заключается в том, что точками входа и выхода риски не ограничиваются. Самая недооцененная сложность прячется там, где, казалось бы, никаких сложностей быть не должно, — в материалах, уже перешедших в общественное достояние. Классический роман или старинная картина, у которых давно истек срок исключительных прав, воспринимаются как безусловно бесплатный материал. Но исчезновение имущественных прав — это еще не полная свобода, и как раз здесь проходит граница, которую регулирование пока не замечает.</p> <p>Дело в том, что наряду с имущественными у автора есть личные неимущественные права, и они устроены принципиально иначе. Право на неприкосновенность произведения, закрепленное в статье 1266 ГК РФ, охраняется бессрочно и в общественное достояние само собой не переходит. Оно не растворяется вместе с истечением срока исключительных прав, а продолжает действовать вечно, и распоряжаться им можно только через отдельное урегулирование с наследниками, правообладателями и авторами — даже в тех случаях, когда автор в свое время отказался от прочих прав на произведение. То же касается и права на имя по статье 1265 ГК РФ. Формально свободный материал на поверку оказывается свободным лишь наполовину.</p> <p>Для ИИ это оборачивается вполне конкретным риском. Когда модель на выходе искажает классический текст, дописывает фразу в манере автора или дорисовывает недостающие элементы на старинном полотне, она вторгается ровно в ту зону, которую закон защищает без срока давности. И здесь становится видно, почему призывы ввести особый статус обучения бьют мимо цели. Такие поправки не разрешают конфликт личных неимущественных прав с генеративными технологиями, а попросту выносят его за скобки, оставляя без ответа. Именно в этом, а не в мнимой нехватке новых законов, и состоит настоящий подвох обучения ИИ на общедоступных материалах.</p> <p> #IMAGE_235665#</p> На первый взгляд может показаться, что обучать ИИ на открытых данных — беспроигрышный вариант. В самом … article Александр Киселев, патентный поверенный UserGate В I полугодии 2026 года рынок систем резервного копирования в России вырос на 18% https://www.itweek.ru/themes/detail.php?ID=235661 Mon, 05 Oct 2026 16:15:35 +0300 <p>Объем российского рынка систем резервного копирования (СРК) в первой половине 2026 года составил около 5,8 млрд руб., увеличившись примерно на 18% по сравнению с аналогичным периодом 2025 года, подсчитали эксперты компании «Системный софт». Они отмечают, что рынок перешел на новый этап развития: в приоритете у заказчиков технологическая зрелость решений, киберустойчивость и гарантированное восстановление данных.</p> <p>Основные факторы роста рынка СРК в 2026 году — импортозамещение, усиленное санкционным давлением, регуляторные требования к объектам КИИ и государственным структурам, рост киберугроз. Заметное влияние оказывает увеличение объемов корпоративных данных, требующее расширения емкости резервного хранения, автоматизации процессов и масштабирования инфраструктуры СРК. </p> <p>Еще одним важным драйвером роста стало развитие функциональности отечественных продуктов. СРК расширяют поддержку виртуальных сред, физических серверов, СУБД, Kubernetes и различных вариантов хранения, что позволяет использовать их в более широком спектре корпоративных проектов. На рынок также влияет развитие российской ИТ-инфраструктуры. Распространение отечественных ОС, платформ виртуализации, СУБД и систем хранения повышает спрос на СРК, совместимые с российским технологическим стеком.</p> <p>При этом спрос постепенно смещается от простого замещения зарубежных продуктов к комплексным проектам защиты данных. Заказчики обновляют инфраструктуру, переходят на российские платформы виртуализации и ОС и предъявляют более высокие требования к отказоустойчивости и гарантированному восстановлению данных. Больше внимания уделяется защите самих резервных копий от шифрования и удаления, соблюдению требований по восстановлению, скорости восстановления и работе СРК в сложных гибридных инфраструктурах. </p> <p>Также со стороны заказчиков выросли требования к совместимости и реальной эксплуатационной зрелости решений. СРК должна работать с российскими ОС, виртуализацией, СУБД, облаками и системами хранения, обеспечивать восстановление в заданные сроки. </p> <p>Эксперты «Системного софта» оценивают уровень зрелости российских СРК как достаточный для большинства корпоративных сценариев, но еще не полностью сопоставимый с зарубежными платформами по глубине экосистемы и количеству интеграций. Отечественные продукты закрывают основные задачи: резервное копирование физических и виртуальных сред, файловых и прикладных систем, СУБД, работу с ленточными библиотеками, шифрование, масштабирование и отказоустойчивость. </p> <p>Основное отставание пока связано не столько с базовой функциональностью, сколько с глубиной интеграций, разнообразием поддерживаемых конфигураций и накопленной практикой эксплуатации в сложных гетерогенных инфраструктурах. Это видно и по структуре рынка. По данным «Системного софта», в 2026 году около 70% крупных компаний все еще используют западные СРК. Однако российские продукты быстро развиваются: появляются новые интеграции с отечественной виртуализацией, контейнерными платформами и системами хранения, поэтому разрыв постепенно сокращается.</p> <p>Конкурентная среда среди отечественных разработчиков СРК становится более зрелой. Если на первом этапе главным преимуществом было само наличие российского продукта взамен ушедших зарубежных решений, то сейчас конкуренция смещается в сторону функциональности, совместимости и качества внедрения. При этом появляются новые игроки и продукты для отдельных сценариев, включая защиту виртуальной и контейнерной инфраструктуры.</p> <p>В дальнейшем компании будут конкурировать прежде всего за счет широты поддерживаемых платформ, интеграции с российской виртуализацией, СУБД, Kubernetes и системами хранения, масштабируемости и развития партнерской экосистемы. Одновременно растет значение референсов и способности вендора обеспечить полный цикл — от миграции и внедрения до технической поддержки. То есть рынок постепенно переходит от конкуренции «российский против зарубежного» к конкуренции между самими отечественными решениями за корпоративного заказчика. Вместе с этим растет и качество самих продуктов. </p> <p>При этом рынок еще далек от насыщения, а объемы данных и требования к их защите растут. Поэтому в ближайшие годы можно ожидать сохранения устойчивой динамики рынка — уже не только за счет миграции, но и за счет модернизации существующих систем, развития киберустойчивости и построения комплексных российских ИТ-ландшафтов.</p> <p>«По нашим оценкам, в <nobr>2026–2027</nobr> годах рынок российских систем резервного копирования может расти примерно на <nobr>15–20%</nobr> ежегодно. Мы ожидаем, что темпы будут постепенно стабилизироваться по сравнению с периодом активного импортозамещения, но рынок сохранит устойчивую положительную динамику. В целом можно говорить о новом этапе развития рынка СРК. Если в <nobr>2022–2025</nobr> годах его основным драйвером было импортозамещение, то сейчас заказчики уже не просто ищут замену зарубежным продуктам — они оценивают СРК как элемент комплексной инфраструктуры защиты данных и ожидают совместимости с российскими ОС, виртуализацией, СУБД, системами хранения и облачными платформами», — прокомментировал Тимур Бадретдинов, руководитель департамента инфраструктурного ПО.</p> Объем российского рынка систем резервного копирования (СРК) в первой половине 2026 года составил около 5,8 млрд руб … message Orion soft: более 80% крупных компаний готовят инфраструктуру к авариям, но без системного подхода https://www.itweek.ru/themes/detail.php?ID=235660 Mon, 05 Oct 2026 16:14:22 +0300 <p>86,9% российских Enterprise-компаний заявили о высоком уровне готовности к аварийным ситуациям, но на практике катастрофоустойчивость реализована фрагментарно. Об этом говорят результаты исследования, проведенного разработчиком инфраструктурного ПО Orion soft.</p> <p>В опросе приняли участие 93 представителя крупных Enterprise-компаний из нефтегазовой, энергетической, финансовой, промышленной, транспортной и других отраслей. </p> <p>74% компаний сталкиваются с аварийными сбоями не чаще одного-двух раз в год. Тем не менее построение катастрофоустойчивости — высокий приоритет в развитии инфраструктуры: 86,9% организаций имеют хотя бы частично спланированные сценарии Disaster Recovery (DR), а 91,3% внедряют средства репликации, в том числе DR-решения на уровне виртуализации и аппаратную репликацию на уровне систем хранения данных (СХД).</p> <p>Высокий уровень подготовки к авариям объясняется строгими требованиями к доступности инфраструктуры и непрерывности бизнес-процессов. Так, для 87,7% опрошенных время восстановления после сбоя (RTO) является строго регламентированным параметром. Для 41,5% целевой показатель RTO составляет до одного часа, что говорит о максимальном уровне критичности бизнес-процессов. Еще 46,2% допускают простой в несколько часов, и лишь 12,3% респондентов могут позволить себе восстановление в течение суток.</p> <p>При этом, несмотря на заявления о высоком уровне готовности к авариям, значительная часть компаний не обладает системным подходом к проверке планов восстановления в реальных условиях. Только 34,4% компаний проводят регулярные учения чаще двух раз в год. Около 37,6% вовсе не проводят проверок систем для аварийного восстановления либо протестировали их один раз при внедрении. Кроме того, даже при наличии DR-инструментов для 68,1% организаций основным методом аварийного восстановления остается резервное копирование и ручное возвращение виртуальных машин в строй.</p> <p>«Резервное копирование не гарантирует быстрого перезапуска сервисов, а ручное восстановление — это сложный список действий, в которых возможны ошибки на фоне человеческого фактора. Эти методы уже не обеспечивают непрерывность бизнеса в той мере, в которой это нужно Enterprise-компаниям со строгими требованиями к RTO. Там, где важно не только наличие бэкапа, но и предсказуемое время восстановления, внедряют инструменты для автоматизированного перезапуска. Полноценное DR-решение на уровне виртуализации обеспечивает переключение виртуальной инфраструктуры на резервную площадку в реальном времени при сбое. Применение такого инструмента гарантирует прогнозируемый RTO в диапазоне от 15 минут. Если в инфраструктуре есть высоконагруженные базы данных или файловые хранилища, то программную репликацию оптимально сочетать с репликацией на уровне СХД. Она позволяет добиться практически нулевой потери данных (RPO = 0) в случае сбоя за счет синхронного режима передачи данных на резервную площадку», — добавил Максим Березин, директор по развитию бизнеса Orion soft.</p> 86,9% российских Enterprise-компаний заявили о высоком уровне готовности к аварийным ситуациям … message Postgres Professional упростила работу с аналитическими данными в Postgres Pro AXE 2.0 https://www.itweek.ru/themes/detail.php?ID=235659 Mon, 05 Oct 2026 16:12:21 +0300 <p>Российский разработчик систем управления базами данных и продуктов для работы с данными Postgres Professional выпустил Postgres Pro AXE 2.0 — новую версию аналитической СУБД для построения корпоративных аналитических систем, хранилищ данных и Lakehouse-архитектур на базе PostgreSQL. Обновление упрощает работу с аналитическими данными и позволяет организациям развивать аналитический контур в привычной PostgreSQL-инфраструктуре.</p> <p>Postgres Pro AXE предназначена для обработки аналитических (OLAP) или гибридных (OLAP + OLTP) нагрузок и может использоваться как вычислительное ядро аналитической платформы или компонент корпоративного хранилища данных. Версия 2.0 делает работу с аналитическими таблицами более привычной для ИТ-команд: теперь они доступны через стандартный SQL-интерфейс и по принципам работы не отличаются от обычных таблиц в реляционной базе данных.</p> <p>Обновленный каталог метаданных помогает аналитической системе эффективнее работать по мере роста объема данных. Система получает информацию о содержимом файлов без необходимости открывать каждый из них, что ускоряет обработку запросов и упрощает масштабирование аналитического контура.</p> <p>В Postgres Pro AXE 2.0 управление правами доступа к аналитическим данным реализовано по тем же принципам, что и для обычных таблиц PostgreSQL. Это позволяет администраторам использовать единый подход к настройке доступа пользователей и приложений в операционном и аналитическом контурах.</p> <p>Аналитические данные в Postgres Pro AXE 2.0 хранятся в формате Parquet, а метаданные — в SQL-таблицах. Каталог метаданных поддерживает открытую спецификацию DuckLake. В совокупности это позволяет совместимым BI-инструментам и внешним системам при необходимости напрямую обращаться к данным и использовать их в аналитических сценариях.</p> <p>«Для компаний важно не только накапливать данные, но и использовать их в аналитических процессах без создания избыточных технологических слоев. В Postgres Pro AXE 2.0 работа с аналитическими данными строится по привычным для пользователей PostgreSQL принципам: аналитические данные доступны через стандартный SQL, а BI-системы и внешние приложения могут подключаться к СУБД с помощью уже используемых PostgreSQL-коннекторов. Это позволяет развивать аналитический контур на базе знакомых инструментов и эффективнее использовать существующую инфраструктуру, что может способствовать снижению совокупной стоимости владения», — отметила Эльмира Рахматулина, руководитель продукта Postgres Pro AXE в Postgres Professional.</p> <p>В обновление также вошли доработки, повышающие стабильность работы в сценариях, где в едином контуре используются операционные и аналитические данные, а также исправления при обработке специальных символов и конвертации типов данных.</p> Российский разработчик систем управления базами данных и продуктов для работы с данными Postgres Professional выпустил … message В 2026 году четверть российских компаний сокращает количество используемого инфраструктурного софта https://www.itweek.ru/themes/detail.php?ID=235658 Mon, 05 Oct 2026 16:10:12 +0300 <p>Каждая четвёртая компания в России проводит «чистку» инфраструктурного ПО в корпоративном контуре, следует из исследования OCS, представленного на «Софт Форуме 2026». Бизнес сокращает число платформ-дублей, чтобы повысить управляемость ИТ-инфраструктуры. На сегодняшний день у 30% организаций внедрены три и более платформ одного класса.</p> <p>Корпоративная инфраструктура российского бизнеса в 2026 году демонстрирует заметную перегруженность. В ИТ-ландшафте каждой второй компании (53%) встречаются по две инфраструктурные платформы одного класса, ещё у 30% — по три и более. Только 17% организаций во время опроса отметили, что имеют по одной платформе каждого типа.</p> <p>Многоплатформенность внутри класса усложняет контроль над корпоративным ИТ-ландшафтом. В 2026 году треть компаний (33%) управляют инфраструктурным стеком преимущественно вручную или вообще не делают этого. Частичная автоматизация реализована у 46% организаций. Результаты исследования OCS указывают на формирование разрыва между сложностью корпоративной ИТ-инфраструктуры и возможностями контроля входящих в неё систем. Однако несколько одноклассовых решений внутри контура не всегда говорят об архитектурных проблемах. «В крупных распределённых средах несколько решений одного класса могут быть осознанным выбором: для разных вариантов нагрузок, площадок, требований к отказоустойчивости или регуляторных контуров», — подчеркнула Ольга Скулова, директор департамента информационной безопасности и ПО OCS.</p> <p>Бизнес стремится повысить управляемость корпоративного программного обеспечения, показывают результаты опроса OCS. 27% компаний видят развитие ИТ-инфраструктуры в 2026 году как сокращение числа платформ-дублей. «Во многих направлениях ПО проект цифровизации теперь выглядит следующим образом: бизнес не добавляет ещё одну платформу, а пересматривает уже используемые решения. При этом для наведения порядка компании всё чаще обращаются к внешней экспертизе — почти треть бизнес-заказчиков опираются на помощь партнёров в проектировании ИТ-инфраструктуры», — рассказала во время выступления на «Софт Форуме» Ольга Скулова.</p> <p>Большая «чистка» инфраструктурного ПО — прямое следствие ключевых целей, которые бизнес установил на 2026 год в отношении инфраструктурного софта. Компании фокусируются на оптимизации затрат (40%) и упрощении управления (26%). Сокращение числа платформ-дублей позволяет решить обе задачи: уменьшить бюджет на поддержание внедрённых инфраструктурных систем, а также облегчить контроль над используемыми в организации решениями. «У половины компаний на инфраструктурный софт приходится значительная доля ИТ-бюджета — от 20 до 40%. При этом две трети организаций наблюдают рост расходов на инфраструктурный стек на протяжении 2026 года», — обращает внимание на финансовые факторы Ольга Скулова.</p> <p>Сегодня проект цифровизации выглядит скорее как сокращение числа систем внутри класса, а не добавление новых решений. Бизнес стремится оптимизировать расходы, а расчищение перегруженной ИТ-инфраструктуры помогает достижению цели в краткосрочной и среднесрочной перспективах: ликвидация платформ-дублей ведёт к сокращению текущих затрат на поддержание ПО, а также к более эффективному управлению инфраструктурным стеком. Вероятнее всего, компании продолжат фокусироваться на повышении управляемости ИТ-инфраструктуры и в 2027 году: работы над расчисткой инфраструктурного софта — это также подготовка к будущим проектам цифровизации бизнеса.</p> Каждая четвёртая компания в России проводит «чистку» инфраструктурного ПО в корпоративном контуре, следует … message Эпоха бесконечных заплаток: как ИИ меняет архитектурные решения в проектах https://www.itweek.ru/themes/detail.php?ID=235656 Mon, 05 Oct 2026 14:37:16 +0300 <p>Искусственный интеллект улучшает отдельные участки системы и одновременно делает сам продукт сложнее для будущих изменений. Это уже видно по реальным проектам.</p> <p>В июньском <a href="https://aisel.aisnet.org/ecis2026/isd_pm/isd_pm/7/">исследовании</a> ECIS 2026 о техническом долге авторы проанализировали 1091 открытый Python-проект. После внедрения генеративного ИИ малые и средние проекты начали быстрее накапливать кодовый долг. У крупных картина оказалась сложнее: архитектурный долг снижался — и одновременно рос долг на уровне проектных решений.</p> <p>На первый взгляд появляется противоречие. Если отдельные изменения вносятся легко и аккуратно, откуда берется проблема на уровне всей системы? Рассмотрим почему каждая следующая заплатка может быть вполне рациональной — и почему именно это превращается в новый архитектурный риск.</p> <h3>Каждая заплатка становится слишком хорошей сделкой</h3> <p>Представьте, что в продукт надо добавить новый сценарий. Можно пойти привычным путем: пересмотреть устройство модуля, разобрать накопленные зависимости и убрать старые ограничения. А можно добавить еще одно условие — и закрыть задачу прямо сегодня.</p> <p>Второй вариант всегда существовал, но раньше его стоимость была ощутимее, ведь разработчику все равно приходилось писать новую логику и встраивать ее в систему. Агентный ИИ сделал локальный путь гораздо привлекательнее: нужно дополнительное исключение — без проблем. Еще один обработчик — хорошо.</p> <p>Отчет GitClear <a href="https://www.gitclear.com/the_ai_code_quality_maintainability_gap">The Maintainability Gap</a> (2026) фиксирует это в цифрах: доля рефакторинга в коммитах упала с 21% в 2022 году до 3,8% в <nobr>2026-м,</nobr> дублирование блоков кода выросло на 81%, а изменения кода старше года сократились на 74%. Системные изменения не просто подорожали относительно локальных — фактически они исчезают из практики как класс</p> <p>Каждое решение по отдельности выглядит совершенно нормально. И вот тут возникает парадокс, потому что в совокупности они могут дать системно нерациональный результат. Это похоже на дом, где мебель переставить дешевле, чем менять планировку — и так можно жить годами. Но, когда понадобится перенести несущую стену, обнаружится проблема.</p> <h3>Проблема не обязательно в плохом коде</h3> <p>Важно не сводить все к формуле «просто ИИ генерирует плохой код». Свежие исследования показывают иную картину — более неоднозначную.</p> <p>В опубликованном в июне 2026 года <a href="https://link.springer.com/article/10.1007/s10664-026-10889-1">эксперименте</a> Empirical Software Engineering участвовал 151 человек, 95% из них — профессиональные разработчики. Исследователи не обнаружили систематического ухудшения сопровождаемости кода, созданного с помощью ИИ: другие разработчики впоследствии меняли его примерно с теми же затратами времени и без значимой разницы в качестве.</p> <p>Это дает понять, что риск появляется не внутри отдельного файла или даже отдельного изменения — проблема возникает между изменениями.</p> <p>Десять качественных локальных решений могут создать систему, в которой одна и та же бизнес-логика постепенно распределилась по нескольким компонентам, исключения начали зависеть друг от друга, а первоначальные границы модулей потеряли смысл. То есть каждая деталь исправна — но конструкция в целом становится хрупкой.</p> <h3>Архитектура перестала напоминать о себе каждый день</h3> <p>Архитектурные правила всегда давали разработчикам практическую выгоду: повторно использовать компонент было дешевле, читать чужой код благодаря понятной структуре — проще. Не накапливался бесконтрольно технический долг.</p> <p>Искусственный интеллект ослабляет эту мотивацию. Если агенту недорого создать еще один похожий блок, дублирование не так мешает. А если модель быстро разбирает запутанный фрагмент, плохая читабельность — уже не проблема. То есть технология не отменяет архитектуру вообще, но зато полностью убирает часть ситуаций, которые заставляли разработчиков о ней помнить.</p> <p>Есть и еще одна сложность. Каждая агентная задача получает локальный контекст: файлы, историю изменений. Этого хватает для конкретной задачи, но сумма контекстов не превращается автоматически в целостную картину системы.</p> <p>Через десятки итераций решения связаны исторически — и эта история нигде не существует в полном виде. Если изменения происходят быстрее, чем команда успевает их разбирать, человек постепенно теряет контроль.</p> <h3>Ловушка замедленного действия</h3> <p>Этот долг может долго не мешать, ведь еще один фильтр добавить легко, новый статус — тоже. Отдельную интеграцию можно быстро подстроить.</p> <p>Проблема появляется, когда бизнес хочет изменить процесс целиком, например объединить два продукта, перестроить клиентский путь, поменять модель тарификации или выйти в новый сегмент. В такие моменты обычно выясняется, что для этого нужно одновременно изменить десятки локальных решений, созданных независимо друг от друга.</p> <p>Получается система, которую дешево менять понемногу, но по-настоящему — уже дорого. Поэтому скорость выпуска функций сама по себе уже мало что говорит о способности продукта развиваться.</p> <h3>Architecture.md ничего не запрещает</h3> <p>Отказываться от агентной разработки из-за этого, конечно, не стоит — но архитектурные правила придется переносить из документов в реальные ограничения внутри процесса.</p> <p>Если правило записано только в architecture.md, помощник может его не увидеть, получить неполный контекст или выбрать решение, которое локально работает, но нарушает общую архитектуру. Поэтому нужны автоматические проверки.</p> <p>Контур непрерывной интеграции может отслеживать границы модулей, запрещенные зависимости, циклические связи и доступ к данным. Тесты и другие механизмы контроля помогают убедиться, что изменение соответствует ожидаемому поведению еще до попадания в основную ветку.</p> <p>В итоге архитектура перестает быть просто инструкцией «делайте так». Она становится набором ограничений, которые не дают провести изменение, если оно нарушает правила.</p> <h3>Главная метрика — цена следующего изменения</h3> <p>Если команда измеряет только количество закрытых задач и скорость разработки, локальная оптимизация почти всегда выглядит выигрышно. Но <a href="https://dora.dev/insights/balancing-ai-tensions/">исследование</a> DORA о применении искусственного интеллекта указывает на двойственность: более активное использование ИИ одновременно связано с ростом пропускной способности и увеличением нестабильности поставки. Авторы советуют не циклиться на объеме произведенного кода и смотреть на результат и состояние процесса.</p> <p>Для архитектуры полезен похожий сдвиг. Недостаточно измерять время текущей задачи — важен радиус ее последствий: сколько затронуто компонентов и возникло новых зависимостей, появились ли специальные исключения, усложнилась ли следующая доработка.</p> <p>Нельзя, чтобы каждая новая функция требовала вмешательства во все большую часть системы. Это означает, что продукт уже платит проценты по архитектурному долгу, даже если задачи и закрываются быстро.</p> <h3>Что корректировать в процессе</h3> <p>В агентной разработке человеку все меньше нужно контролировать каждое движение вручную. Гораздо важнее становится среда, в которой принимаются решения. Задача — заранее сделать часть плохих решений технически невозможными.</p> <p>Минимальный набор выглядит так:</p> <ul> <li> Архитектурные правила проверяются автоматически. Если между модулями запрещена определенная зависимость или доступ к данным должен идти только через подтвержденный интерфейс, это лучше фиксировать не только в документах, но и в проверках контура непрерывной интеграции.</li> <li> Тесты контролируют и функцию, и взаимодействие компонентов. Быстрая локальная доработка не должна менять поведение соседних частей системы или ломать критичные сценарии.</li> <li> Новые зависимости и исключения становятся наблюдаемыми. Команда должна видеть, где появляется очередной обходной путь или связь между компонентами, которой прежде не было.</li> <li> Команда отслеживает, как растет область изменений. Если для каждой новой бизнес-функции приходится затрагивать все больше модулей, это сигнал, что архитектурный долг уже начинает влиять на стоимость развития продукта.</li> <li> Локальная заплатка периодически сравнивается с ценой системного решения. В какой-то момент еще одно быстрое исправление становится дороже, чем устранение самой причины. Важно уметь заметить это до того, как крупная перемена потребует переделки половины системы.</li> </ul> <p>Так роль архитектора тоже меняется. Помимо схемы системы он проектирует коридор допустимых решений — набор ограничений и проверок, внутри которого люди и агенты могут работать быстро и не разрушать способность продукта меняться дальше.</p> <h3>Подведем итоги</h3> <p>Плохой фрагмент кода, сгенерированного ИИ, легко найти — гораздо сложнее заметить систему, в которой сотни локальных рабочих решений вдруг перестали складываться в единое целое. Это происходит, потому что искусственный интеллект сделал заплатку слишком выгодной и системное решение каждый раз откладывается на потом.</p> <p>Архитектура в такой среде нужна даже больше, чем раньше. Теперь ее задача — автоматически удерживать быстрые изменения внутри границ, за которыми сегодняшняя экономия превращается в завтрашнюю неспособность продукта меняться.</p> <p> #IMAGE_235657#</p> Искусственный интеллект улучшает отдельные участки системы и одновременно делает сам продукт сложнее для будущих изменений … article Султан Рамазанов, директор Umbrella IT по искусственному интеллекту Вытеснит ли ИИ корпоративных архитекторов? https://www.itweek.ru/themes/detail.php?ID=235655 Mon, 05 Oct 2026 10:08:55 +0300 <p><em>Каждые несколько лет сфера корпоративной архитектуры (</em><em>enterprise</em> <em>architecture</em><em>, EA) сталкивается с вопросом о своем существовании. Этот вопрос возникал в связи с методологией Agile, облачными вычислениями и продуктовыми операционными моделями. Теперь его вновь поднимает искусственный интеллект, пишут в корпоративном блоге Чарльз Бетц, вице-президент и ведущий аналитик </em><em>Forrester</em><em>, и Джозеф Скьявоне, ведущий аналитик </em><em>Forrester</em><em>.</em></p> <p>Поскольку генеративный ИИ и автономные агенты начинают интерпретировать требования, проектировать архитектуру, писать код, создавать документацию, разрабатывать стандарты и анализировать портфели проектов, руководители в области корпоративной архитектуры задаются вопросом: не происходит ли автоматизация самой профессии?</p> <p>Наша позиция однозначна: роль корпоративного архитектора не уменьшается, а возрастает. Однако меняется сама основа этой значимости.</p> <p>Поскольку агенты начинают участвовать в процессах выпуска ПО, ИТ-операциях, бизнес-процессах, взаимодействии с клиентами и аналитических рабочих процессах, механизмы управления больше не могут опираться исключительно на периодические проверки, поддерживаемые вручную стандарты и ретроспективный аудит. Темп операционной деятельности стал слишком высоким.</p> <p>А главной проблемой EA всегда были издержки, связанные с задержками. Основная трудность заключается не в том, что архитекторы предписывают командам разработки сменить курс — такие изменения происходят в порядке вещей. Проблема в том, что архитектурная работа исторически занимала слишком много времени. Мы неоднократно подтверждали этот вывод в ходе общения со многими ведущими EA-специалистами. Теперь, под влиянием внедрения агентов, традиционные модели EA становятся все менее жизнеспособными.</p> <p>Рассмотрим основные результаты работы традиционной EA-команды: репозитории, стандарты, диаграммы, дорожные карты целевого состояния, процедуры согласования и анализ портфелей. Большинство из них представляют собой информационные продукты, создаваемые благодаря узкоспециализированным знаниям и значительным затратам ручного труда. Экономика этих процессов стремительно меняется. ИИ уже способен создавать архитектурные диаграммы, обобщать данные по портфелям, готовить проекты стандартов, документировать системы, анализировать зависимости и отвечать на вопросы о сложных технологических ландшафтах. Качество результатов пока неоднородно, но направление развития очевидно: задачи, на выполнение которых раньше уходили недели, теперь все чаще решаются за считанные часы.</p> <p>Здесь уместно вспомнить экономическую теорию. Когда дефицитный продукт становится общедоступным, ценность смещается к следующему узкому месту (вспомним Джевонса и Голдратта). В мире, где ИИ все активнее создает архитектурные артефакты, возникает вопрос: где будут сосредоточены архитектурная экспертиза, ответственность и функции управления, когда создание самих артефактов перестанет быть дефицитным ресурсом?</p> <p>Мы давно утверждаем, что архитектурные репозитории, CMDB, хранилища метаданных и системы управления портфелем — это разные проявления одной и той же фундаментальной потребности: наличия единого источника достоверных корпоративных знаний. Организациям необходима авторитетная информация о возможностях, приложениях, технологиях, данных, зависимостях, политиках и истории принятия решений. </p> <p>Исторически эти системы создавались прежде всего для использования людьми. Однако это представление меняется. Платформы разработки, инженерные команды, ИИ-ассистенты, автономные агенты, системы управления и бизнес-пользователи все чаще выступают и как создатели, и как потребители одних и тех же базовых информационных активов. Репозиторий, предоставляющий контекст системам ИИ, теперь не просто документирует деятельность организации, но и непосредственно участвует в ее операционных процессах.</p> <p>Такое развитие событий меняет роль архитекторов. Они всегда создавали артефакты, но сами по себе артефакты никогда не были самоцелью. Диаграмма, дорожная карта или аналитический отчет служили свидетельством того, что их автор достаточно глубоко понимает устройство организации. Поскольку ИИ снижает затраты на создание подобных артефактов, дефицитным ресурсом становится именно то понимание организации, которое лежит в их основе. Говоря словами Джевонса: так как стоимость проведения архитектурного анализа существенно снизилась, мы будем заниматься им чаще, а не реже.</p> <p>Больше архитектурного анализа? Да. Но, возможно, мы даже не будем называть это так: процесс станет неотъемлемой, «невидимой» частью непрерывной поставки цифровых систем, превратившись в постоянный цикл обратной связи.</p> <p>Корпоративные архитекторы все чаще выступают в роли кураторов корпоративного контекста, хранителей архитектурных знаний, проектировщиков механизмов управления и советников, помогающих принимать решения с серьезными последствиями; они формируют плоскость управления для обеспечения контролируемой автономии. Ведь кто-то должен определять, что разрешено делать автономным системам, какие ограничения на них накладываются, как обеспечивается соблюдение этих ограничений и как организация сохраняет возможность отслеживать поведение таких систем.</p> <p>Архитекторы, которые в ближайшее десятилетие принесут наибольшую пользу, будут тратить меньше времени на ведение документации и больше — на вопросы полномочий, ответственности, прав принятия решений, качества данных и самих решений, соблюдения политик, допустимых рисков и поиска компромиссов внутри организации. Они будут тесно сотрудничать с командами платформенных инженеров, специалистами по безопасности и работе с данными, а также с бизнес-руководителями для формирования надежного корпоративного контекста, пригодного для эффективного использования как людьми, так и машинами.</p> <p>Они также помогут создать то, что может стать одним из важнейших активов современного предприятия: многократно используемый, постоянно действующий уровень корпоративного интеллекта. Он будет включать в себя знания, политики, стандарты, онтологии, историю принятия решений, сведения о взаимосвязях и бизнес-контекст — всё то, что можно применять вновь и вновь в системах ИИ и автономных рабочих процессах. Можно назвать это «контекстным графом».</p> <p>Мы уже наблюдаем признаки этой эволюции. Архитектурные команды используют ИИ для обогащения репозиториев, подготовки рекомендаций, отслеживания дрейфа реализации, анализа портфелей проектов и предоставления экспертной поддержки непосредственно в ходе рабочих процессов. Эта тенденция проявляется весьма устойчиво. Цель редко состоит в том, чтобы заменить архитекторов; задача — распространить влияние архитектуры на гораздо более широкий круг принимаемых решений.</p> <p>Каждый крупный технологический сдвиг за последние 20 лет заставлял сферу EA доказывать свою значимость. Эта профессия успешно преодолевала любые вызовы, поскольку ее истинным предназначением всегда было не создание артефактов, а помощь организациям в принятии более качественных решений, касающихся сложных систем.</p> Каждые несколько лет сфера корпоративной архитектуры (enterprise architecture, EA) сталкивается с вопросом о своем … article HYPERPC представила новую серию высокопроизводительных серверов Ampere XR https://www.itweek.ru/themes/detail.php?ID=235653 Fri, 02 Oct 2026 14:55:25 +0300 <p>Компания HYPERPC представила новую серию высокопроизводительных серверов Ampere XR. В линейку входит две модели: Ampere XR Pro и Ampere XR Ultra. Данные продукты предназначены для решения сложных вычислительных задач, требующих высокой производительности, масштабируемости и надежности. Важным достоинством моделей является возможность индивидуальной настройки под конкретные бизнес-задачи.</p> <p>В первую очередь, HYPERPC Ampere XR Pro и Ampere XR Ultra были созданы для решения задач в области машинного обучения и искусственного интеллекта. Серверы позволяют обучать большие языковые модели (LLM), а также нейросети с высокой пропускной способностью. Новые продукты могут также применяться для решения задач в области Data Science и предиктивной аналитики. Серверы могут быть полезны для анализа больших данных — системы оснащены NVMe-накопителями для быстрой обработки огромных массивов информации в реальном времени. Помимо этого, HYPERPC Ampere XR Pro и Ampere XR Ultra можно использовать для 3D-рендеринга и проведения научных исследований. </p> <p>В новых моделях используются два процессора CPU Socket E (LGA4677) c TDP до 350 Вт на сокет. Оперативная память продуктов доходит до 8 ТБ, что гарантирует высокую скорость обработки данных и плавную работу даже под самыми интенсивными нагрузками. В серверных системах такого уровня память также критически важна, чтобы минимизировать ошибки при длительных вычислениях. В моделях присутствует до 8 накопителей на передней панели (конфигурации 4NVMe + 4 SATA либо 8 SATA/SAS через контроллер), позволяющие достигнуть максимальной производительности. Подсистема питания включает до 6 блоков питания мощностью 3200 Вт каждый с поддержкой резервирования и возможностью горячей замены. </p> <p>Серверные платформы HYPERPC Ampere XR Pro и Ampere XR Ultra имеют уникальное свойство — поддержку до 16 видеокарт уровня RTX5090, 6000 PRO Blackwell и NVIDIA H200 в одном корпусе. Графический ускоритель NVIDIA H200 является мощным инструментом для сложных вычислительных задач и одним из ключевых преимуществ данных серверов. H200 обладает максимальным объемом памяти — 141 ГБ. Благодаря наличию H200, можно загружать крупные модели целиком, работать с большим объемом данных, не дробя модель. Высокая пропускная способность ускорителя обеспечивает быструю передачу данных между памятью и вычислительными блоками.</p> <p>Новые серверные платформы могут успешно использоваться в любой сфере, где требуются вычислительные мощности. Особенно полезны данные решения будут для таких отраслей, как IT и разработка ИИ, финансовый сектор, медиасфера и кинопроизводство, инжиниринг и промышленное проектирование, наука и исследования, а также медицина и биотехнологии. </p> <p>Компания HYPERPC обеспечивает профессиональную сборку каждого сервера, обязательное проведение стресс-теста, индивидуальный подход, позволяющий подобрать конфигурацию под конкретные задачи компании и бюджет, техническую поддержку на высоком уровне, а также выделяет персонального менеджера для каждой компании, использующей данные продукты. Авторизованные сервисные центры HYPERPC расположены во многих городах России, что делает техподдержку доступной. Специалисты компании могут помочь с диагностикой, настройкой, а также с комплексным техническим обслуживанием.</p> <p>«Мы делаем ставку не только на качество наших продуктов, но и на их ценовую доступность. Более того, каждого клиента сопровождает на всех этапах высококлассный инженер, который безукоризненно составит под задачи клиента нужную конфигурацию рабочей станции или сервера, а после покупки окажет постпродажное сопровождение», — отметил Михаил Васильев, коммерческий директор HYPERPC.</p> Компания HYPERPC представила новую серию высокопроизводительных серверов Ampere XR. В линейку входит две модели: Ampere … message Как защитить корпоративные данные, не жертвуя надежностью ИИ https://www.itweek.ru/themes/detail.php?ID=235652 Fri, 02 Oct 2026 10:54:50 +0300 <p><em>По мере того как организации инвестируют в искусственный интеллект, многие сталкиваются с новым узким местом: сложностью получения данных, которые были бы одновременно защищенными и полезными, пишет на портале </em><em>The</em> <em>New</em> <em>Stack</em> <em>Маянк Ахлувалия, старший менеджер по продуктам компании Perforce Delphix.</em></p> <p>Для проверки изменений, внесенных ИИ, обучения моделей, тестирования приложений и получения бизнес-инсайтов инженерным командам нужны реалистичные данные, максимально приближенные к производственным. Однако меры по обеспечению конфиденциальности иногда затрудняют доступ к таким данным, делают их менее репрезентативными или нарушают критически важные взаимосвязи между записями.</p> <p>Эта проблема подчеркивается в отчете Perforce Delphix «2026 State of AI and Data Privacy Report». 26% опрошенных организаций отмечают, что меры по защите конфиденциальности затрудняют получение данных производственного качества, 25% сталкиваются с трудностями при сохранении взаимосвязей между сущностями данных, а 51% указывают на проблемы с качеством данных.</p> <p>Защиты данных недостаточно, если они больше не могут обеспечивать работу зависящих от них систем. Для инженерных команд ключевой вопрос заключается в том, позволяют ли их стратегии защиты данных сохранить те качества, которые и делают эти данные ценными. Необходима комплексная стратегия работы с данными и инструменты, поддерживающие ссылочную целостность и взаимосвязи между различными средами.</p> <h3>Что эта статистика означает для специалистов-практиков</h3> <p>На первый взгляд, данные отчета — например, о том, что 51% предприятий сталкиваются с проблемами качества данных, — могут показаться вопросом, касающимся исключительно управления.</p> <p>На практике же это инженерные проблемы. Использование наборов данных низкого качества может привести к следующим последствиям:</p> <ul> <li> Неточная аналитика.</li> <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> Быть достаточно доступными для инженерных команд.</li> <li> Соответствовать требованиям регуляторов.</li> <li> Сохранять связи, обеспечивающие ссылочную целостность.</li> </ul> <p>В эпоху ИИ перед организациями стоит двойная задача: снизить риски раскрытия конфиденциальных данных и одновременно создать надежные данные, сохраняющие свою ценность после защиты. Слишком часто компании жертвуют соблюдением требований ради инноваций или скорости. Именно поэтому 84% респондентов, участвовавших в нашем исследовании, допускают исключения в правилах защиты конфиденциальности данных для сред, не используемых в промышленной эксплуатации.</p> <p>Организации могут развиваться со скоростью, требуемой для внедрения ИИ, только при наличии доступа к надежным данным, точно отражающим реальные операционные условия. Если меры по обеспечению конфиденциальности снижают качество, ограничивают реалистичность или доступ к репрезентативным наборам данных, уровень данных становится новым узким местом.</p> <h3>Почему ссылочная целостность важна как никогда</h3> <p>Многие дискуссии о конфиденциальности данных сводятся к маскированию конфиденциальных полей. Однако маскирование, нарушающее ссылочную целостность между сущностями, может создать риски иного рода.</p> <p>Запись о клиенте, заказе или платеже может быть сохранена, но если связи между этими записями будут нарушены в процессе защиты, данные перестанут соответствовать действительности. Возьмем, к примеру, проверку биллинговых данных. Для корректного формирования перечня продуктов или точного расчета начислений необходима ссылочная целостность, особенно когда информация о продуктах, сборах и счетах одного клиента распределена по нескольким таблицам базы данных.</p> <p>Нарушение связей представляет особую проблему для современных систем ИИ и аналитики. Аналитические конвейеры зависят от согласованности идентификаторов, позволяющих объединять информацию из разных источников. Процессы ИИ и машинного обучения требуют полного бизнес-контекста для выявления закономерностей и построения прогнозов. Тестирование ПО опирается на реалистичные связи между записями, что необходимо для точной проверки поведения приложений.</p> <p>При утрате ссылочной целостности:</p> <ul> <li> Аналитика может давать неполные или вводящие в заблуждение результаты.</li> <li> Модели ИИ могут обучаться на некорректных наборах данных.</li> <li> Тестовые среды могут не выявлять проблемы, возникающие в реальных операциях.</li> <li> Команды теряют доверие к защищенным наборам данных.</li> </ul> <p>Важно отметить, что подобные сбои зачастую трудно обнаружить. Конвейеры могут продолжать успешно работать, но при этом незаметно выдавать некачественные результаты, что может обернуться весьма дорогостоящей ошибкой.</p> <p>Это помогает объяснить, почему 25% опрошенных организаций назвали сохранение взаимосвязей между объектами данных серьезной проблемой. Для специалистов-практиков эта статистика служит предупреждением: меры по обеспечению конфиденциальности могут непреднамеренно снизить качество инициатив в области ИИ и аналитики, если при их внедрении не учитывается бизнес-контекст.</p> <p>Важно помнить, что не все решения по защите данных одинаковы: для сохранения взаимосвязей ключевое значение имеют алгоритмы маскирования корпоративного уровня. При их последовательном применении в масштабах всей организации одни и те же исходные данные преобразуются в идентичные маскированные результаты во всех системах и средах. Другие подходы к маскированию могут реализовываться фрагментарно, что приводит к нарушению взаимосвязей.</p> <h3>Что следует измерять инженерным командам</h3> <p>Многие организации оценивают эффективность мер по обеспечению конфиденциальности исключительно по показателям соответствия нормативным требованиям. Однако среды, использующие ИИ, требуют более широкого понимания успеха. Руководителям инженерных подразделений следует оценивать инициативы в области конфиденциальности по нескольким критериям:</p> <ul> <li><strong> Качество данных: </strong>точно ли защищенный набор данных отражает условия промышленной эксплуатации?</li> <li><strong> Реалистичность:</strong> могут ли разработчики, специалисты в области науки о данных и аналитики уверенно использовать эти данные по назначению?</li> <li><strong> Ссылочная целостность:</strong> сохраняется ли согласованность взаимосвязей между приложениями, таблицами, средами и источниками данных?</li> <li><strong> Доступность:</strong> могут ли команды получать данные, соответствующие требованиям, без задержек?</li> <li><strong> Скорость предоставления:</strong> как быстро можно получить надежные наборы данных при необходимости?</li> </ul> <p>Эти показатели помогают организациям определить, способствуют ли меры по обеспечению конфиденциальности достижению целей в сфере ИИ или создают новые препятствия.</p> <h3>Проектирование с учетом управления данными по умолчанию</h3> <p>По мере распространения ИИ обеспечение конфиденциальности не может оставаться отдельным процессом, запускаемым уже после начала разработки. Вместо этого организациям следует выстроить карту полного жизненного цикла данных: от запроса и обнаружения до повторного использования и вывода из эксплуатации.</p> <p>Такой подход позволяет встроить механизмы управления данными непосредственно в рабочие процессы, а не применять их как контрольный этап на поздней стадии. Это также обеспечивает более надежный аудит, снижает количество случаев отступления от нормативных требований и повышает уверенность команд в том, что защищенные наборы данных остаются пригодными для использования по назначению.</p> <p>Что особенно важно, это позволяет согласовать цели в области конфиденциальности с бизнес-результатами, вместо того чтобы рассматривать их как конкурирующие приоритеты.</p> <h3>Надежные данные станут конкурентным преимуществом</h3> <p>Потребность в тестовых данных — с точки зрения объема, охвата и масштаба — стремительно растет по мере развития технологий агентной разработки. ИИ также увеличивает объем изменений, генерируемых предприятиями, однако проблема проверки этих изменений остается нерешенной.</p> <p>Решение этой задачи по-прежнему зависит от данных. Организации, которые извлекут наибольшую пользу из внедрения ИИ, не обязательно будут обладать самыми совершенными моделями. Лидерами станут те, кто обеспечит наиболее надежную основу для работы с данными, применяя комплексный подход: сочетание виртуализации данных (для быстродействия), маскирования (для безопасности) и — при необходимости — синтетических данных (для обеспечения полноты охвата).</p> <p>Результаты исследования указывают на важный вывод: если меры по защите конфиденциальности позволяют сохранить реалистичность и качество данных, а также взаимосвязи между записями и доступ к репрезентативным наборам данных, они могут способствовать успеху внедрения ИИ.</p> <p>В условиях, когда компании продолжают инвестировать в технологии ИИ и обеспечение конфиденциальности данных, главной целью должно стать гармоничное сочетание безопасности и практической ценности. Ведь в эпоху ИИ именно надежные данные, а не высокая скорость получения результатов модели, могут стать решающим конкурентным преимуществом.</p> По мере того как организации инвестируют в искусственный интеллект, многие сталкиваются с новым узким местом … article Рынок публичных облаков в России достиг 383 млрд рублей и меняет темп роста https://www.itweek.ru/themes/detail.php?ID=235649 Thu, 01 Oct 2026 15:48:55 +0300 <p>Аналитическая компания Apple Hills Digital опубликовала результаты ежегодного исследования «Рынок облачных сервисов в РФ». В нем представлен анализ динамики сегментов IaaS, PaaS и SaaS в <nobr>2022–2025</nobr> годах и рассмотрены основные тренды. В отчёте также приведены оценки лидеров рынка — какие факторы определят развитие каждого сегмента до 2030 года. Отчёт также содержит практические выводы и рекомендации для облачных провайдеров и корпоративных заказчиков.</p> <p>В 2025 году суммарные расходы российских клиентов на облачные сервисы во всех типах развертывания — публичных, частных и локальных, включая внутреннее потребление в экосистемах, составили 487 млрд рублей. Рыночное потребление (без учета внутреннего потребления в экосистемах) составило 417 млрд рублей, из них 383 млрд рублей пришлось на рынок публичных облачных сервисов, детально рассмотренный в исследовании.</p> <p>В 2025 году рост рынка к 2024 году замедлился до 25% (против 30% годом ранее). С 2022 года по 2025 год рынок рос в среднем на 26% в год, увеличившись со 191 млрд рублей вдвое.</p> <p>Структура российского рынка публичных облачных сервисов в <nobr>2024–2025</nobr> годах не поменялась:</p> <ul> <li>сохраняется преобладание готовых приложений — на сегмент SaaS пришлось 65% рынка (248 млрд рублей, +23% к 2024 году);</li> <li>на IaaS — 25% (96 млрд рублей, +29% к 2024 году);</li> <li>на PaaS — только 10% (39 млрд рублей, +29% к 2024 году).</li> </ul> <p>Доли этих сегментов заметно отличаются от структуры мирового рынка, где доля PaaS примерно втрое выше — и это одна из точек роста для российских провайдеров на ближайшие годы. Внутри PaaS быстрее всего растут AI/ML-платформы и управляемые базы данных (DBaaS).</p> <p>Данные за первое полугодие 2026 года говорят о замедлении рынка, хотя по неполному периоду пока нельзя точно определить среднесрочную траекторию. Поэтому прогноз представлен в виде диапазона между двумя сценариями: «Продолжение тренда» и «Замедление роста».</p> <p>Сценарий «Продолжение тренда» предполагает среднегодовой рост рынка (CAGR) в <nobr>2025–2030</nobr> годах на уровне 19% с достижением 930 млрд рублей к 2030 году. Сценарий «Замедление роста», учитывающий признаки торможения рынка в 2026 году, даёт CAGR 12% и объём рынка в 666 млрд рублей к 2030 году.</p> <p>Прогнозы сегментов SaaS, IaaS и PaaS также приведены в двух сценариях:</p> <ul> <li>SaaS — от 420 млрд рублей (CAGR 11%) до 567 млрд рублей (CAGR 18%) к 2030 году;</li> <li>IaaS — от 165 млрд рублей (CAGR 11,5%) до 241 млрд рублей (CAGR 20%) к 2030 году;</li> <li>PaaS — от 81 млрд рублей (CAGR 16%) до 122 млрд рублей (CAGR 26%) к 2030 году.</li> </ul> <p>Исследование обобщает результаты масштабных опросов корпоративных заказчиков и ведущих провайдеров облачных сервисов, проведенных Apple Hills Digital. Среди факторов роста рынка — потребность в гибкости ресурсов на фоне дорогого заёмного капитала и неустойчивости развития бизнеса в разных отраслях, расширение использования ИИ, миграция с устаревающего оборудования и ПО иностранных вендоров. Сдерживают рынок ограниченная функциональная зрелость PaaS-экосистемы, сложные макроэкономические условия, ужесточение регулирования, рост пиратства ПО и осторожность бизнеса в условиях высокой стоимости капитала.</p> <p>Тарифы на облачные сервисы уже растут под давлением подорожания серверов и памяти, роста налоговой нагрузки, и в ближайшие годы эта тенденция, вероятно, сохранится. Однако собственное оборудование дорожает еще быстрее, поэтому облако остаётся способом экономии — при условии контроля расходов, внедрения FinOps и динамического управления ресурсами. Снизить риски помогут долгосрочные договоры с фиксацией цен, гибридные и мультиоблачные стратегии и заблаговременное резервирование мощностей, прежде всего серверов с GPU. При выборе провайдера всё важнее его соответствие требованиям регуляторов, отказоустойчивость архитектуры и возможность легко перенести нагрузку к другому провайдеру.</p> <p>Экономическая неопределённость, рост налоговой нагрузки и высокая ставка ЦБ повышают требования к окупаемости инвестиций. На фоне дефицита и подорожания GPU и памяти провайдеры делают ставку на эффективность использования оборудования, инференс и готовые ИИ-модели, в том числе российские, спрос на которые поддерживает законодательство и регулирование. Конкурентным преимуществом становятся предсказуемые тарифы, отраслевые решения для традиционных секторов, где проникновение облаков пока невысоко, а также соответствие растущим требованиям к безопасности и суверенитету данных.</p> <p>«Темп роста российского рынка облачных сервисов меняется: в первом полугодии 2026 года проявились признаки замедления той положительной динамики, которую мы наблюдаем уже много лет. С другой стороны, все более заметным драйвером в сегментах IaaS и PaaS становится запрос на инфраструктуру для ИИ, повышенным спросом также пользуются гибридные облачные среды и защищенная инфраструктура в публичном облаке. Возможное влияние этих разнонаправленных факторов на прогноз развития рынка мы рассматривали в этом исследовании, активное участие в подготовке которого приняли все ведущие российские провайдеры — лидеры облачного рынка», — отметил Василий Пименов, руководитель программ исследований Apple Hills Digital.</p> Аналитическая компания Apple Hills Digital опубликовала результаты ежегодного исследования «Рынок облачных сервисов в РФ» … message vStack выпустил vStack HCP 3.2 с NVMe Fabric и развитием Unified Storage https://www.itweek.ru/themes/detail.php?ID=235648 Thu, 01 Oct 2026 15:46:46 +0300 <p>Российский разработчик гиперконвергентных платформ vStack выпустил обновление платформы vStack HCP. Главным новшеством версии стало внедрение NVMe Fabric и развитие Unified Storage. Основные направления релиза — более гибкое размещение виртуальных машин, развитие встроенного хранилища и усиление защиты от сбоев.</p> <p>Одним из ключевых изменений стала технология NVMe Fabric. Раньше возможности запуска и восстановления виртуальной машины зависели от того, на каких серверах находились ее данные. Теперь хранилище доступно с разных узлов кластера, поэтому машину можно запустить или восстановить на любом подходящем сервере. При выборе сервера платформа учитывает доступные вычислительные ресурсы и расположение данных. Если один из серверов выходит из строя, его виртуальные машины могут быть распределены между несколькими оставшимися узлами. Это помогает эффективнее использовать оборудование и уменьшить объем простаивающей оперативной памяти, сохраняя необходимый резерв для восстановления нагрузки. </p> <p>Второе важное направление обновления — развитие Unified Storage. Одни и те же ресурсы хранения можно одновременно использовать для виртуальных машин vStack HCP и внешних систем. Подключение выполняется по NVMe-oF/TCP или iSCSI, для которого предусмотрена дополнительная защита доступа. Администратор может из единого интерфейса управлять подключениями, томами и настройками доступа, а также следить за нагрузкой на хранилище, скоростью работы, задержками и возникающими ошибками. В ряде случаев это позволяет использовать ресурсы vStack HCP вместо отдельной специализированной системы хранения данных. </p> <p>В версии 3.2 также автоматизирована работа с физическими дисками. Платформа обнаруживает установленные накопители, проверяет их состояние, выявляет признаки деградации, подбирает подходящий резервный диск и отслеживает восстановление данных. Благодаря этому многие аппаратные сбои могут обрабатываться без постоянного участия администратора, а информацию о состоянии дисков и хранилищ можно увидеть в интерфейсе управления. </p> <p>Дополнительную защиту получили конфигурации из двух серверов. При потере связи узел должен подтвердить право работать с данными, прежде чем продолжить работу. Это снижает риск ситуации, когда два сервера одновременно изменяют одни и те же данные. Для сетевых сервисов реализован автоматический переход на резервный узел менее чем за 10 секунд с сохранением активных TCP-соединений.</p> <p>Доработаны и кластеры, расположенные на разных площадках: улучшено их поведение при отключении и последующем возвращении серверов или целой площадки. Панель управления распределенной инфраструктурой теперь показывает в одном окне сводные данные о виртуальных машинах, виртуальных дата-центрах, сетях и сетевых шлюзах. Из нее также можно подключать кластеры и управлять пользователями и их правами. </p> <p>Для контроля действий в vStack HCP появился единый журнал безопасности на 49 типов событий, фиксирующий входы, смену настроек и действия с виртуальными машинами. Записи связаны между собой с помощью SHA-256, журнал поддерживает фильтрацию, экспорт данных и уведомления о критических инцидентах.</p> <p>На платформе доступны шесть готовых ролей, более 50 прав доступа и возможность создавать собственные роли. Администраторы могут гибко настраивать политики безопасности: блокировать учетные записи при переборе паролей, задавать требования к их сложности и запрещать повторное использование старых комбинаций. </p> <p>Всего в релиз вошло более 200 изменений, направленных на повышение стабильности и качества платформы. Они затронули работу виртуальных машин, хранилища и физических дисков, сетевые функции, управление доступом, интерфейс, API, сбор показателей и диагностику ошибок. </p> <p>«В vStack HCP 3.2 мы расширили возможности размещения и восстановления виртуальных машин, усилили защиту от сбоев и развили инструменты управления хранилищем. Заказчики могут гибче распределять нагрузку между серверами и использовать ресурсы хранения как для виртуальных машин vStack, так и для внешних систем. Это дает больше свободы при построении инфраструктуры и упрощает ее эксплуатацию», — сказал Евгений Карпов, генеральный директор vStack, корпорация ITG.</p> Российский разработчик гиперконвергентных платформ vStack выпустил обновление платформы vStack HCP. Главным новшеством версии … message OCS: у каждой четвёртой компании в России больше половины инфраструктурного ПО с техдолгом https://www.itweek.ru/themes/detail.php?ID=235647 Thu, 01 Oct 2026 15:44:51 +0300 <p>Экономическая ситуация в стране привела к остановке многих инвестиционных проектов, из-за чего цифровизация бизнеса часто стала сводиться к замене отдельных систем. В результате компании накапливают проблемы в коде и архитектуре — технические долги. В 2026 году у каждой четвёртой крупной организации техдолг затрагивает больше половины инфраструктурных платформ, следует из исследования OCS, представленного на «Софт Форуме 2026». При этом проблемы наблюдаются в наиболее критичных, по мнению бизнеса, классах — резервном копировании и аварийном восстановлении, а также операционных системах (ОС).</p> <p>Необходимость быстрого замещения ПО, ограничения в выборе решений и другие трудности поддержания и развития корпоративной ИТ-инфраструктуры последних лет привели к массовому накоплению технических долгов. Переход к точечному обновлению инфраструктурных платформ вместо комплексной цифровизации в <nobr>2025–2026 годах,</nobr> в свою очередь, усугубил проблему. Сегодня у 25% крупных компаний свыше половины инфраструктурного стека нуждается в обновлении или даже полном пересмотре. При этом каждая двенадцатая организация перешагнула критический рубеж в 75% инфраструктурных платформ с техдолгом.</p> <p>Технический долг накапливается преимущественно в базовом контуре эксплуатации — системах, отвечающих за повседневную устойчивость ИТ-ландшафта. Согласно опросу OCS, самыми «проблемными» оказались решения для резервного копирования и аварийного восстановления (27%), операционные системы (23%) и платформы для управления и мониторинга ИТ-сред (21%).</p> <p>Классы инфраструктурного ПО, где чаще всего встречается техдолг, совпадают с лидерами рейтинга наиболее критичного софта. По мнению бизнеса, ключевыми платформами в корпоративной ИТ-инфраструктуре в 2026 году являются операционные системы и ПО для управления и мониторинга ИТ-сред — такие ответы дали 38% и 28% респондентов. Решения для резервного копирования и аварийного восстановления также входят в пятёрку наиболее критичного инфраструктурного софта (26%).</p> <p>Значительный технический долг — затрагивающий больше половины инфраструктурного ПО — чаще встречается у представителей телекоммуникаций, химической промышленности и машиностроения: проблему отметили 30%, 29% и 28% игроков отраслей соответственно. Наименьшая доля зафиксирована в финансовом секторе: только у 16% компаний накопленные технические проблемы имеют такой масштаб. «Финансовый сектор выглядит как менее перегруженный техническим долгом. Вероятно, это связано с регулярным обновлением критичных платформ, поскольку в отрасли приняты более жёсткие внутренние стандарты, а также выше регуляторные требования», — отметила Ольга Скулова, директор департамента информационной безопасности и ПО OCS.</p> <p>Компании со значительным техническим долгом не всегда выделяют ресурс на его сокращение. «Для многих организаций в России технический долг стал скорее привычным состоянием ИТ-инфраструктуры, чем локальной проблемой отдельных классов ПО, — подчеркнула Ольга Скулова во время выступления на „Софт Форуме“. — Пока бизнес не готов к масштабной пересборке инфраструктурного стека. Наиболее распространённая стратегия на 2026 год — точечная модернизация». Согласно исследованию OCS, больше трети крупных организаций (35%) планируют бюджет на замену отдельных платформ. Масштабное обновление инфраструктуры входит в планы только 11% компаний.</p> <p>При этом точечная модернизация не всегда затрагивает решения с наиболее выраженным техническим долгом. Компании в первую очередь меняют те системы, где переход сопряжён с меньшими рисками для связанной инфраструктуры. Поэтому проблема, вероятно, сохранит актуальность для российского бизнеса и в 2027 году.</p> Экономическая ситуация в стране привела к остановке многих инвестиционных проектов, из-за чего цифровизация бизнеса … message InfoWatch Data Protector защитит данные и права доступа к ним https://www.itweek.ru/themes/detail.php?ID=235646 Thu, 01 Oct 2026 15:43:07 +0300 <p>Линейку продуктов по защите данных ГК InfoWatch дополнил InfoWatch Data Protector. Разработка предназначена для защиты учетных записей пользователей и администраторов, а также данных, хранящихся «в покое» на рабочих станциях пользователей и серверах компании. InfoWatch Data Protector был впервые представлен 29 сентября на XIX конференции по информационной безопасности BIS Summit 2026.</p> <p>InfoWatch Data Protector — это инструмент аудита прав и данных для ИБ-подразделений и администраторов служб каталогов. Для анализа содержимого данных продукт использует запатентованную технологию ГК InfoWatch — потоковую кластеризацию данных, которая позволяет проанализировать все данные в компании без предварительной настройки политик и обеспечивает недостижимую прежде стопроцентную видимость данных. Это позволяет локализовать хранение наиболее важных для компании данных и повысить эффективность управления рисками.</p> <p>Поскольку доступ к данным в ИТ-инфраструктурах предоставляется через службы каталогов, InfoWatch Data Protector проводит аудит доступа: система анализирует, кто имеет доступ к данным, кто администрирует системы и может менять права пользователям. Аудит опирается на несколько независимых источников и отслеживает все изменения в службе каталогов — включая те, что происходят на низком уровне и не видны в журналах событий. InfoWatch Data Protector выявляет неиспользуемые учетные записи и скомпрометированные пароли раньше злоумышленников, что снижает поверхность возможной кибератаки.</p> <p>Решение адаптировано для развертывания в корпоративных средах. InfoWatch Data Protector сканирует хранилища объемом в сотни терабайт с производительностью до 1 Тб в сутки на одной серверной ноде. Возможность горизонтального масштабирования позволяет адаптироваться под растущие объемы данных без перестройки архитектуры.</p> <p>InfoWatch Data Protector может быть развернут как самостоятельный инструмент, однако наибольшую эффективность показывает при совместном использовании с DLP-системой InfoWatch Traffic Monitor. В то время как DLP-система позволяет обеспечить контроль данных «в движении», InfoWatch Data Protector отслеживает данные «в покое» и делает прозрачной матрицу доступов.</p> <p>Внедрение InfoWatch Data Protector позволяет выполнить требования регуляторов и обеспечить соответствие ИТ-инфраструктуры федеральному закону № 152‑ФЗ «О персональных данных» и приказу ФСТЭК России № 21 «Об утверждении Состава и содержания организационных и технических мер по обеспечению безопасности персональных данных при их обработке в информационных системах персональных данных». Корректная обработка персональных данных и их защита снижают риски нарушений, а как следствие — претензий со стороны надзорных органов и штрафных санкций.</p> <p>«Ключевое преимущество InfoWatch Data Protector — сочетание двух функций в одном инструменте. Решение одновременно контролирует и данные, и доступ к ним, что исключает „слепые зоны“. Аудит опирается на поток изменений служб каталогов, а не на журналы событий, — источник, который нельзя отключить. Это кардинально отличает нашу разработку от решений, основанных на анализе журналов событий, которые сейчас преобладают на рынке. Data Protector интегрирован в единую платформу защиты данных от InfoWatch, что позволяет выстроить целостный контур безопасности от одного поставщика — без необходимости совмещать фрагментированные инструменты от разных вендоров», — рассказал ведущий менеджер по развитию продуктов для защиты данных ГК InfoWatch Александр Цветков.</p> Линейку продуктов по защите данных ГК InfoWatch дополнил InfoWatch Data Protector. Разработка предназначена для защиты … message Как бизнес-приложения становятся агентными https://www.itweek.ru/themes/detail.php?ID=235644 Thu, 01 Oct 2026 00:00:00 +0300 <p><em>Не стоит заблуждаться: мы имеем дело не просто с очередным этапом добавления новых функций в корпоративные приложения. Мы переживаем крупнейший сдвиг в сфере бизнес-ПО со времен появления облачных вычислений, пишет в корпоративном блоге Кейт Леггетт, вице-президент и ведущий аналитик </em><em>Forrester</em><em>.</em></p> <p>Десятилетиями такие приложения, как системы управления взаимоотношениями с клиентами (CRM), планирования ресурсов предприятия (ERP), управления человеческим капиталом (HCM) и цепочками поставок (SCM), функционировали как цифровые системы учета (systems of record). В них сотрудники перемещались по интерфейсам, выполняли задачи и вручную координировали работу, преодолевая барьеры между разрозненными подразделениями. ИИ коренным образом меняет эту модель. Теперь ИИ-агенты действуют в разных приложениях под контролем сотрудников. Формируется новая архитектура, в которой данные, рабочие процессы и ИИ совместно организуют деятельность для достижения бизнес-результатов. Мы называем эту новую операционную модель «агентной тканью бизнеса» (agentic business fabric).</p> <p>Последствия этих изменений выходят далеко за рамки технологий. Речь идет о трансформации организации труда, операционных моделей, систем управления и экономики ПО. ИИ-агенты будут все чаще выполнять, координировать и оптимизировать работу на стыке различных функциональных направлений, позволяя организациям ориентироваться на такие результаты, как рост выручки, оптимизация оборотного капитала и повышение продуктивности сотрудников. Традиционные границы между такими сферами, как продажи, маркетинг, обслуживание, финансы и операционная деятельность, начнут размываться, поскольку сквозные рабочие процессы придут на смену передаче задач между отделами. Одновременно с этим поставщики ПО будут отходить от лицензирования «на каждое рабочее место» в пользу моделей ценообразования, основанных на объеме потребления, количестве транзакций, числе решенных задач или достигнутых результатах.</p> <h3>Бизнес-приложения для фронт-офиса первыми переходят на агентную модель</h3> <p>Однако этот переход будет неравномерным. Платформы для фронт-офиса — такие как CRM, системы обслуживания клиентов и приложения для управления цифровым опытом — выступают первопроходцами, поскольку они непосредственно обеспечивают взаимодействие с клиентами и сотрудниками. Эти среды генерируют обширные данные о поведении и коммуникации, опираются на решения, требующие экспертной оценки, и позволяют измерять такие результаты, как конверсия, выручка, уровень удовлетворенности и доля успешно решенных задач. Возможность контроля со стороны человека позволяет исправлять ошибки, что делает эти системы подходящими для раннего внедрения ИИ-агентов. В результате эти системы стремительно эволюционируют из «систем взаимодействия» (systems of engagement) в «системы автономных действий» (systems of autonomous action).</p> <p>Для приложений бэк-офиса этот путь гораздо сложнее. Процессы ERP, SCM, закупок и многие аспекты HCM регулируются строгими финансовыми правилами, требованиями аудита, нормативными актами и стандартами ответственности. Ошибочная рекомендация в ходе общения с клиентом может доставить лишь неудобство. В то же время ошибка в расчете заработной платы, резервировании товарных запасов или проведении финансовой проводки может повлечь за собой юридические риски, сбои в операционной деятельности и серьезные финансовые потери. В связи с этим указанные сферы потребуют внедрения гораздо более надежных механизмов управления, средств обеспечения наблюдаемости и контроля соответствия нормативным требованиям, а также жестких детерминированных ограничений, прежде чем организации смогут полностью довериться автономному выполнению задач.</p> <p>Однако успех заключается не только во внедрении ИИ-агентов. Организациям необходимо четко разграничить области вероятностного принятия решений и детерминированного управления. Им предстоит интегрировать требования комплаенса непосредственно в рабочие процессы, а также усилить меры безопасности и системы управления. Кроме того, потребуется выработать новые подходы к оценке ценности, создаваемой ИИ, и подготовить сотрудников к существенным изменениям в организации труда. Главная задача — не просто внедрить агентов, а перестроить работу предприятия с учетом их возможностей.</p> <h3>Потенциал кросс-системных рабочих процессов</h3> <p>Что особенно важно, ИТ-руководителям следует смотреть шире рамок отдельных приложений. Зачастую наибольший потенциал кроется не в автоматизации задач внутри систем CRM, ERP или HCM, а в переосмыслении рабочих процессов, связывающих эти системы воедино. Лидерами следующего десятилетия станут не те организации, которые просто добавят агентов в существующее ПО, а те, кто использует их для координации деятельности всего предприятия, превращая разрозненные приложения в единую агентную ткань бизнеса, способную обеспечивать измеримые результаты в масштабах всей компании.</p> Не стоит заблуждаться: мы имеем дело не просто с очередным этапом добавления новых функций … article «Код Безопасности» выводит на рынок Secret Net EDR 1.3 с рейтингом доверия устройств https://www.itweek.ru/themes/detail.php?ID=235645 Wed, 30 Sep 2026 16:16:22 +0300 <p>Компания «Код Безопасности», российский разработчик сертифицированных средств защиты информации, объявила о выводе на рынок нового продукта — Secret Net EDR версии 1.3. Это система класса Endpoint Detection and Response, предназначенная для обнаружения атак на конечных точках и оперативного реагирования на инциденты информационной безопасности.</p> <p>Развитие решения ведется в соответствии с утвержденной дорожной картой, ближайшие этапы которой предусматривают расширение функционала в области поведенческого анализа и корреляции событий.</p> <p>Secret Net EDR 1.3 обеспечивает непрерывный мониторинг активностей на рабочих станциях и серверах, используя комбинированный подход к выявлению угроз. Продукт включает: </p> <ul> <li>поиск руткитов; </li> <li>YARA-сканирование файловой системы; </li> <li>контроль безопасной конфигурации узлов; </li> <li>сигнатурный анализ сетевого трафика для обнаружения подозрительной активности. </li> <li>настройка автоматических реакций при обнаружении аномалий или вредоносных действий.</li> </ul> <p>«Одна из ключевых особенностей новой версии — механизм рейтинга доверия компьютера, — рассказал коммерческий директор компании „Код Безопасности“ Дмитрий Шатсков. — Система на основании результатов сигнатурного анализа, сканирования YARA-правилами и поиска скрытых объектов присваивает каждому устройству один из трех статусов: „Доверенный“, „Приемлемый“ или „Недоверенный“. Изменение рейтинга фиксируется в операционном журнале, что дает службе безопасности прозрачную картину состояния всех конечных точек в любой момент времени. Этот рейтинг может использоваться как индикатор для принятия решений о доступе к корпоративным ресурсам».</p> <p>Кроме того, Secret Net EDR 1.3 уже на старте поддерживает сценарий совместной работы с решением «Континент ZTN Клиент» для удаленного доступа. При подключении пользователя к корпоративной сети сервер доступа может запросить у EDR-агента проведение комплексной проверки устройства; на основании полученных результатов формируется решение о предоставлении или блокировке доступа. </p> <p>В планах развития — углубление этой интеграции, а также реализация локального коррелятора, расширенного поиска (Investigation) и получение сертификата ФСТЭК России в версии 1.4, выход которой намечен на первый квартал 2027 года.</p> Компания «Код Безопасности», российский разработчик сертифицированных средств защиты информации, объявила о выводе … message Количество ИТ-субъектов в России ежегодно увеличивается в среднем на 8,3% https://www.itweek.ru/themes/detail.php?ID=235643 Wed, 30 Sep 2026 12:37:45 +0300 <p>На середину 2026 года число ИТ-субъектов достигло 273 тысяч — в эту категорию входят юридические лица и индивидуальные предприниматели. Ежегодно с 2020 года в России регистрировалось от 30 до 54 тысяч новых ИТ-субъектов. Количество ИТ-субъектов в России ежегодно увеличивается в среднем на 8,3%. Об этом говорится в исследовании «Точки роста: как устроен российский рынок ИТ-стартапов» ведущей российской консалтинговой компании Strategy Partners. Его результаты Сбер представил на международной технологической конференции — Московском стартап-саммите.</p> <p>При этом далеко не все новые ИТ-субъекты можно отнести к стартапам: в число новых регистраций, например, могут входить случаи юридической реструктуризации бизнеса и выделения внутренних ИТ-подразделений в отдельные юридические лица.</p> <p>Количество активных ИТ-стартапов в России оценивается в <nobr>1,5–2,5 тысячи.</nobr> В общей массе зарегистрированных ИТ-компаний и ИП их доля — около <nobr>0,5–1,5%.</nobr></p> <p>Как показало исследование, существующая инфраструктура поддержки стартапов закрывает весь жизненный цикл: от грантов на этапе идеи до подготовки к IPO. На стадии идеи и посева работают ФСИ и ФРИИ; на ранней — Сколково, технопарки и ИНТЦ, РВК; на стадии роста — Московский венчурный фонд, корпоративные венчурные фонды, МИК; на зрелой — МИК (путь к IPO), Мосбиржа, СПб Биржа и фонды поздних стадий.</p> <p>Однако высокая ключевая ставка не способствует росту венчурных инвесторов: они склонны выбирать менее рисковые депозиты и облигации. Ключевая ставка, достигавшая 21% в <nobr>2024–2025</nobr> годах и составляющая 14% на сентябрь 2026 года, делает депозиты и облигации куда привлекательнее венчурного риска. Дорогие деньги смещают спрос в сторону финансирования зрелых компаний.</p> <p>Одним из основных вызовов для развития стартапов остаётся дефицит финансирования. С 2026 года к нему добавилась повышенная налоговая нагрузка: рост НДС (исключая ПО из реестра российского ПО, которое освобождено от НДС) и отмена части льгот для ИТ-компаний.</p> <p>География рынка крайне неравномерна: совокупный балл Москвы в 18 раз выше второго города в этом рейтинге — Санкт-Петербурга. Экосистема умеет производить чемпионов, но в масштабе 273 тыс. зарегистрированных субъектов это единичные истории успеха.</p> <p>Эксперты Strategy Partners считают, что толчком для развития стартапов может стать создание региональных хабов по модели Иннополиса (стимулирование роста не только в центре, но и на периферии), стабилизация налогового режима, доступность финансирования и поддержка компаний на этапе pre-IPO. Рост за пределами центра уже виден в статистике Новосибирска, Казани и Томска (+2 позиции за год у каждого города в национальном рейтинге по версии StartupBlink). Участники рынка прямо связывают срывы сделок <nobr>2025–2026</nobr> годов с нестабильностью правил. Консенсус-прогноз предполагает снижение ключевой ставки к ~12% к концу 2027 года, что исторически совпадает с оживлением венчурной активности. Также важна поддержка на этапе pre-IPO — от программы «Путь к IPO» до специализированных фондов поздних стадий. И наконец, развитие частного посевного капитала — бизнес-ангелов и синдикатов: именно это сегодня является самым узким местом всей цепочки.</p> <p>Сергей Меламед, руководитель дивизиона «Малый и микробизнес» Сбербанка, отметил: «Исследование показало, что российский рынок ИТ-стартапов обладает значительным потенциалом, но для его реализации требуется решение системных вопросов, связанных с ценой капитала и предсказуемостью условий ведения бизнеса. Инфраструктура поддержки выстроена на всех этапах, но высокая ставка и налоговая нагрузка мешают работать в полную силу. Чтобы запустить следующий цикл роста, нужно сместить фокус на регионы, обеспечить стабильность налогового режима, доступность финансирования и поддержку на этапе pre-IPO».</p> На середину 2026 года число ИТ-субъектов достигло 273 тысяч — в эту категорию входят юридические лица … message Создание ценности в эпоху ИИ: опыт банковского CIO https://www.itweek.ru/themes/detail.php?ID=235641 Wed, 30 Sep 2026 10:00:52 +0300 <p><em>Гилл Хаус, </em><em>CIO</em> <em>Chase (подразделение JPMorgan Chase & Co, отвечающее за розничный банкинг), рассказал порталу </em><em>ZDNet</em> <em>о подходе Chase к внедрению искусственного интеллекта и о том, почему так важно заложить правильный фундамент.</em></p> <p>Опыт показывает, что извлечение реальной пользы из технологий ИИ — задача непростая. Поскольку 91% специалистов <a href="https://www.itweek.ru/ai/article/detail.php?ID=235443">признают</a>, что их компании пока не достигают желаемых результатов в этой сфере, руководителям и сотрудникам предстоит проделать большую работу, чтобы превратить экспериментальные проекты в полезные для бизнеса сервисы.</p> <p><a name="OLE_LINK3">По словам Хауса, он </a>осознал, что <a name="OLE_LINK5">создание ценности в эпоху ИИ </a>— это нечто большее, чем просто решение внедрить модную модель или сервис. «Заявить о стремлении к эффективности, поставив перед собой цель, — это одно, а переосмыслить бизнес-процессы через призму использования ИИ-агентов — совсем другое», — говорит он.</p> <p>Как отмечает Хаус, крайне важно понимать, что роли и обязанности сотрудников будут меняться: ИИ уже трансформирует характер работы персонала Chase — как в ИТ-департаменте, так и в других подразделениях. «Мы видим, что наш традиционный инженер, который раньше занимался написанием кода, теперь способен на большее, — говорит он. — А менеджер по продукту, который раньше лишь формулировал задачи (писал пользовательские истории), теперь может сам писать программный код».</p> <p>По мере того как ИИ-агенты становятся частью внутренней операционной среды, рабочее пространство превращается в пространство совместной деятельности людей и ИИ.</p> <p>Хаус отмечает, что в Chase эта трансформация уже заметна — особенно в процессах разработки и в том, как меняется роль инженеров. Влияние новых технологий проявляется неожиданным образом: еще полгода назад подобное показалось бы удивительным. «На самом деле теперь я не нанимаю инженеров для того, чтобы они писали код. Понимаю, это звучит странно, ведь именно этим инженеры и должны заниматься, — признается он. — Но сегодня я нанимаю инженеров, чтобы они разбирались, какой именно код нужно написать. И в этом огромная разница. Раньше — еще полгода назад — код приходилось писать вручную. Теперь же в этом нет необходимости, ведь на помощь приходит ИИ-агент. Благодаря этому исчезает рутина, которая раньше мешала инженерам заниматься тем, что им действительно нравится».</p> <p>Итак, уделяя пристальное внимание результатам, а не просто процессу выполнения задач, как именно Хаус обеспечивает правильный подход к внедрению ИИ? Ответ на этот вопрос строится на трех ключевых принципах: создании бесшовных сервисов, выпуске безопасных продуктов и обеспечении надежных результатов.</p> <h3>1. Создание бесшовных сервисов</h3> <p>По словам Хауса, в его организации уделяют особое внимание роли ИИ в операционной модели, а все сотрудники проходят обучение эффективному использованию этих инструментов.</p> <p>Важнейшим элементом этого подхода является LLM Suite — внутренняя платформа компании, использующая агентные технологии; с ее помощью сотрудники могут задавать вопросы, анализировать документы и составлять спецификации.</p> <p>Платформа LLM Suite была запущена летом 2024 г.; она предоставляет доступ к большим языковым моделям — как передовым проприетарным решениям, так и Open Source-моделям — в защищенной среде. «Это платформа, которой может пользоваться любой сотрудник организации, — рассказывает Хаус. — Мы рассматриваем весь процесс в целом и используем технологии, чтобы устранить препятствия и раскрыть потенциал наших команд по всей компании».</p> <p>По его словам, сотрудники используют эту агентную платформу и встроенные в нее модели для создания новых продуктов и услуг: «Если у нас есть определенный сценарий взаимодействия с клиентом и мы можем использовать технологии, чтобы сделать его лучше или персонализированнее, мы это делаем».</p> <p>В качестве примера Хаус приводит использование новейших технологий для улучшения качества обслуживания клиентов, обращающихся в банк по телефону. «Мы применяем машинное обучение для распознавания намерений клиента, чтобы быстро перенаправить его к нужному специалисту, — поясняет он. — Во время разговора мы используем аналогичные технологии, чтобы понять, какие действия клиент, вероятно, хочет совершить».</p> <p>По словам Хауса, залог успеха — в глубоком встраивании агентов и алгоритмов в операционные процессы, будь то работа сотрудника с внутренним интерфейсом или использование клиентом веб-сервиса либо мобильного приложения.</p> <p>Новейшие технологии доступны сотрудникам Chase, которые ежедневно работают с этими системами, однако для клиентов банка их внутренняя «механика» должна оставаться незаметной и работать бесшовно. «Настоящая магия заключается в том, чтобы упростить жизнь клиенту — так, чтобы он даже не осознавал, что качество обслуживания улучшилось, — говорит Хаус. — Для него всё просто работает».</p> <h3>2. Выпуск безопасных продуктов</h3> <p>Хотя качественное обслуживание клиентов с применением ИИ крайне важно, применяемые для этого продукты должны быть безопасными, а защите данных необходимо уделять первостепенное внимание. По словам Хауса, поскольку Chase работает в секторе с жестким регулированием, банк предъявляет высокие требования к новым технологиям: «Мы действуем взвешенно и придерживаемся уже отработанных подходов, позволяющих двигаться быстро, но ответственно».</p> <p>Защита данных, а также соблюдение требований конфиденциальности и получение согласия пользователей — обязательные условия. «Если мы используем данные для каких-либо целей, мы обязательно информируем об этом клиентов, — отмечает Хаус. — Мы никогда не станем использовать данные небезопасным образом или в нарушение наших внутренних политик и нормативных требований, касающихся конфиденциальности и соблюдения законодательства. Эти принципы критически важны независимо от того, идет ли речь о традиционных моделях машинного обучения или об агентных технологиях».</p> <p>Вопросы безопасности касаются не только взаимодействия с клиентами. Хаус добавляет, что ИИ помогает Chase и во внутренних процессах — в частности, обеспечивая быструю и эффективную разработку ПО.</p> <p>Он отмечает, что инструменты на базе ИИ помогают использующим их специалистам выявлять ошибки, предотвращать действия злоумышленников и повышать качество обслуживания клиентов. Для других специалистов и бизнес-руководителей главным принципом безопасной разработки ПО в эпоху ИИ становится проактивность. «Я считаю невероятно важным продолжать следить за тем, чтобы помимо того что мы делаем для обеспечения хорошей работы ИИ, мы всегда были сосредоточены на нашем периметре, гарантируя, что мы обновляем наше ПО и что мы работаем над своевременным устранением уязвимостей, — говорит Хаус. — Такой проактивный подход гарантирует, что мы сможем защищать наших клиентов по мере того, как меняется окружающий мир».</p> <h3>3. Обеспечение надежных результатов</h3> <p>В агентных технологиях модели выступают в роли механизма рассуждений, прогнозирующего следующее действие с наибольшей статистической вероятностью. К сожалению, агенты, подобно людям, действуют на вероятностной основе, и, по словам Хауса, такая природа этих систем может приводить к непредвиденным последствиям. «Вы не всегда будете получать один и тот же ответ, — отмечает он. — Это имеет меньшее значение, когда вы ищете рецепт. Хотя если у вас получится майонез другого типа, это может стать некоторой проблемой. Но когда вы хотите что-то сделать со своими финансами, результат должен быть правильным».</p> <p>Хаус считает, что бизнес-лидеры должны обеспечить защитные меры, оценки и результаты, которые укрепляют доверие и создают уверенность в том, что агентные технологии могут использоваться в больших масштабах. «Во многих случаях решение заключается в том, чтобы оставить человека в центре процесса, и в Chase реализовано немало подобных сценариев», — рассказывает он.</p> <p>Возвращаясь к теме разработки ПО и к своему утверждению о том, что Chase не нанимает инженеров для написания кода, Хаус поясняет, что в эпоху агентов практически любой человек — независимо от того, является ли он ИТ-специалистом, — может создать приложение с помощью инструментов для кодирования на базе ИИ. Поэтому ему нужны квалифицированные инженеры-эксперты, которые смогут определить, когда агенты работают эффективно и правдиво, и он советует другим бизнес-лидерам обратить на это внимание.</p> <p>«Продумать и внести ясность в отношении того, что должно быть правдой в результате создания ПО — от масштаба до компонентов, которые необходимо использовать, до того, как оно должно быть спроектировано — это самые сложные задачи», — говорит он.</p> <p>Chase стремится к тому, чтобы сотрудники использовали автономные ИИ-системы, однако для безопасного и эффективного масштабирования сервисов необходима надежная базовая архитектура. «Какие у нас шаблоны? Как мы можем гарантировать, что следуя этим шаблонам наши люди создавали ПО, обеспечивающее нужный им результат, а не просто получали что-то, что выдает модель и что не продумано целостно? Нам нужны ответы на эти вопросы, — говорит Хаус. — Это та часть, которую я считаю фундаментальной и которую нам необходимо уловить. И вы можете сделать это в своей организации иными способами, чем просто использовать своих талантливых инженеров для написания кода».</p> Гилл Хаус, CIO Chase (подразделение JPMorgan Chase   Co, отвечающее за розничный банкинг), рассказал порталу ZDNet … article Получен сертификат ФСТЭК России на средство многофакторной аутентификации MFA JaCarta-3 https://www.itweek.ru/themes/detail.php?ID=235640 Tue, 29 Sep 2026 16:44:55 +0300 <p>Компания «Аладдин» сообщила о получении сертификата ФСТЭК России № 5111 на средство многофакторной аутентификации MFA JaCarta-3. Срок действия сертификата — до 17 сентября 2031 года.</p> <p>Сертификат подтверждает, что MFA JaCarta-3 является программно-техническим средством многофакторной аутентификации и соответствует требованиям документа «Требования по безопасности информации, устанавливающие уровни доверия к средствам технической защиты информации и средствам обеспечения безопасности информационных технологий» (ФСТЭК России, 2020):</p> <ul> <li>по 2 уровню доверия (работа с гостайной, комплектация с Aladdin SecurLogon, устройствами аутентификации на аппаратной платформе JaCarta-3, «Единым Клиентом JaCarta», без использования биометрии);</li> <li>по 4 уровню доверия (комплектации с Aladdin SecurLogon, устройствами на аппаратных платформах JaCarta-2 и JaCarta-3, «Единым Клиентом JaCarta», с использованием биометрии).</li> </ul> <p>Назначение MFA JaCarta-3:</p> <ul> <li>многофакторная аутентификация при доступе к защищённым информационным ресурсам;</li> <li>безопасное хранение ключевой информации СКЗИ и цифровых сертификатов;</li> <li>применение в информационных системах персональных данных (ИСПДн) до 1 уровня защищённости;</li> <li>применение в автоматизированных системах (АС) классов защищённости 1Д, 1Г;</li> <li>применение в государственных информационных системах (ГИС) до 1 класса защищённости.</li> </ul> <p>Ключевые возможности:</p> <ul> <li>работа в корпоративных системах с развёрнутой инфраструктурой открытых ключей (PKI). При отсутствии инфраструктуры PKI: многофакторная аутентификация в Windows с помощью компонента JaCarta SecurLogon (в составе ПО «Единый Клиент JaCarta»), в Linux — с помощью Aladdin SecurLogon;</li> <li>штатная поддержка USB-токенов и смарт-карт JaCarta в продуктах мировых вендоров.</li> </ul> <p>В состав продукта входят PKI-клиент с поддержкой средств многофакторной аутентификации в Linux Aladdin SecurLogon, средство администрирования «Единый Клиент JaCarta», различные USB-токены и смарт-карты JaCarta, в том числе — новейшие JaCarta-3 ГОСТ и JaCarta-3 РКІ/ГОСТ, выполненные в металлических корпусах с разъёмами Type-A и Type-С. Также в составе решения — персональный USB-токен с биометрической идентификацией по отпечаткам пальцев JaCarta SecurBIO и биометрический смарт-карт ридер Enterprise-класса Aladdin SecurBIO Reader. </p> Компания «Аладдин» сообщила о получении сертификата ФСТЭК России № 5111 на средство многофакторной аутентификации … message Вышла новая версия Postgres Pro Enterprise Manager 2.10 с анализатором нагрузки Healthcheck Advisor https://www.itweek.ru/themes/detail.php?ID=235639 Tue, 29 Sep 2026 16:42:21 +0300 <p>Компания Postgres Professional объявила о выпуске новой версии платформы для управления и мониторинга баз данных — Postgres Pro Enterprise Manager (PPEM) 2.10. Главным нововведением релиза стал анализатор нагрузки Healthcheck Advisor, выявляющий отклонения в работе СУБД и формирующий рекомендации по их устранению. Также в версию вошли поддержка внешних хранилищ для истории активных сеансов, кастомизация дашбордов и графическое отображение топологии кластера.</p> <p>Ключевым изменением платформы стало внедрение модуля Healthcheck Advisor. Инструмент помогает администратору перейти от ручного анализа метрик к проактивному подходу и предметному разбору инцидентов: система автоматически проверяет телеметрию по заданному расписанию или по требованию. Механизм диагностирует широкий спектр проблем, включая длительные транзакции, взаимоблокировки, задержки репликации, сбои контрольных сумм и деградацию процессов autovacuum.</p> <p>Все обнаруженные события привязываются к конкретным экземплярам и метрикам, а также распределяются по уровням критичности: Critical, High, Medium и Low. В едином обзоре администратор сразу видит узлы с наибольшим числом рисков, а при переходе к деталям получает контекст: значение метрики, правило детекции, время фиксации и шаги по локализации сбоя. При необходимости периметр проверок и список анализируемых параметров можно гибко настраивать.</p> <p>«Развитие встроенных интеллектуальных механизмов — последовательный шаг в развитии продуктов Postgres Pro. Появление Healthcheck Advisor логично расширяет линейку наших инструментов с применением ИИ, где ранее уже был представлен интеллектуальный ассистент по СУБД. Мы планомерно усиливаем аналитические возможности платформы, помогая администраторам не просто фиксировать аномалии в телеметрии, а получать готовую контекстную экспертизу для быстрого принятия решений», — прокомментировал Борис Пищик, руководитель продукта Postgres Pro Enterprise Manager в компании Postgres Professional.</p> <p>В части работы с телеметрией в PPEM 2.10 реализована поддержка внешних хранилищ для данных Active Session History (ASH). Если ранее история сеансов сохранялась исключительно во встроенной базе репозитория, то теперь ее можно перенести во внешние БД, снизив нагрузку и утилизацию дискового пространства управляющего сервера. Пользователи могут прямо из веб-интерфейса регистрировать новые хранилища, назначать целевую базу по умолчанию и централизованно управлять параметрами подключений.</p> <p>Интерфейс платформы получил развитые средства персонализации и наглядного контроля. На странице обзора экземпляра теперь можно кастомизировать дашборд: добавлять, скрывать и переставлять виджеты таблиц, счетчиков и графиков с сохранением единой компоновки между сессиями. Кроме того, состав отказоустойчивых кластеров теперь доступен в виде наглядной топологической схемы, которая дополняет классические таблицы, а также упрощает визуализацию и навигацию по кластерным архитектурам. </p> <p>Платформа также получила ряд инфраструктурных и эксплуатационных доработок:</p> <ul> <li>в регламентах обслуживания репозитория появился лимит максимального времени исполнения правил («Rule execution timeout, sec»);</li> <li>при восстановлении базы из резервной копии добавлена возможность сразу указывать параметры конфигурации, пресеты настроек и имя службы systemd;</li> <li>включены готовые пресеты графиков WAL Usage и WAL Archiving для углубленного контроля за журналами предзаписи;</li> <li>оптимизированы внутренние конвейеры для бесперебойной обработки больших массивов объектов и обновлены нормы сайзинга ресурсов;</li> <li>исправлен пул уязвимостей безопасности (CVE), а системный стек Go обновлен до версии 1.27.</li> </ul> <p>Обновление Postgres Pro Enterprise Manager 2.10 уже доступно пользователям. Инструкции по переходу и подробный перечень изменений опубликованы в документации продукта.</p> Компания Postgres Professional объявила о выпуске новой версии платформы для управления и мониторинга баз данных — … message «Аладдин» запускает программу авторизованного обучения работе с Aladdin Enterprise CA в Академии АйТи fabricaONE.AI https://www.itweek.ru/themes/detail.php?ID=235638 Tue, 29 Sep 2026 13:01:17 +0300 <p>Компания «Аладдин» объявила о запуске программы авторизованного обучения технических специалистов работе с корпоративным центром сертификации Aladdin Enterprise CA. Курсы будут проходить в Академии АйТи (акционер — ГК Softline), которая стала первым партнёром «Аладдин» в области сертифицированного обучения продуктам компании. Дата начала курсов — 2 ноября.</p> <p>Программа сертификации разработана Центром компетенций «Аладдин». Первыми в неё вошли курсы по работе с корпоративным центром сертификации Aladdin Enterprise CA (Aladdin eCA) и технологиям инфраструктуры открытых ключей (PKI) — направлению, в котором «Аладдин» обладает одной из самых глубоких экспертиз на рынке. На старте слушателям доступны два курса.</p> <p>«Основы технологий PKI» (курс eCA 101) — вводный курс продолжительностью 8 академических часов. 2 ноября слушатели разберутся в целях, принципах и алгоритмах асимметричной криптографии, изучат шифрование, хеширование и электронную подпись, познакомятся с концепцией доверия и принципами работы центров сертификации, узнают о сертификатах открытого ключа и их жизненном цикле, а также познакомятся с особенностями работы с Aladdin Enterprise CA. Отдельный блок курса посвящён практике применения сертификатов открытого ключа в корпоративной среде — в задачах двухфакторной аутентификации, электронной подписи и электронного документооборота.</p> <p>«Внедрение Aladdin Enterprise CA в корпоративной среде» (курс eCA 102) — инженерный курс продолжительностью 24 академических часа с лабораторным практикумом. С 3 по 6 ноября слушатели получат практические навыки развёртывания инфраструктуры открытых ключей. В частности, они обучатся установке корневого и подчинённого удостоверяющих центров, их интеграции с операционными системами и службами каталогов, настройке двухфакторной аутентификации и многому другому.</p> <p>Оба курса ориентированы на инженеров ИТ и ИБ, участвующих во внедрении Aladdin Enterprise CA, а также на студентов профильных вузов. Обучение проходит в очном и онлайн-форматах.</p> <p>По итогам обучения и сдачи экзаменов по первым двум курсам выпускники получат статус сертифицированного специалиста Aladdin eCA (ACS-eCA), который подтверждает базовые знания в области Aladdin eCA и позволяет эффективнее внедрять продукт в системах заказчиков. В дальнейшем линейка курсов и сертификационных статусов будет расширена: в перспективе выпускники смогут претендовать на статусы сертифицированного инженера и сертифицированного архитектора Aladdin eCA, которые подтвердят готовность специалиста проектировать сложные корпоративные решения. Наличие в штате сертифицированных специалистов по Aladdin eCA даст компаниям возможность получить более высокий партнёрский статус «Аладдин».</p> <p>«Для корпоративной ИТ-инфраструктуры PKI — основа. „Аладдин“ последовательно проводит импортозамещение этих технологий, ранее представленных на российском рынке западными компаниями. Мы развиваем компетенции ИБ-специалистов, выстраивая вместе с партнёрами учебную базу. Академия АйТи стала нашим первым партнёром в этой области, но в ближайших планах — открытие центров компетенций на базе ведущих интеграторов. Чтобы поддержать эти центры, мы передаём лидерам корпоративного ИТ-образования необходимые курсы. Это непростая задача, так как до сих пор не существовало системного решения, которое объединяло бы знания и технологии и позволяло бы комплексно развивать компетенции российских ИБ-специалистов в построении PKI на основе национальных технологий», — прокомментировал Леонид Шапиро, руководитель Центра компетенций «Аладдин». </p> <p>«Информационная безопасность динамично развивается, и компании ежедневно сталкиваются с новыми вызовами: эволюцией кибератак, необходимостью импортозамещения и ростом требований к квалификации специалистов. Академия АйТи развивает многопрофильный портфель авторизованного обучения, предлагая рынку постоянно растущую линейку образовательных программ по продуктам российских вендоров. Запуск курсов по Aladdin eCA и PKI расширяет возможности комплексной подготовки ИБ-специалистов по работе с отечественными решениями, способствуя развитию корпоративной информационной безопасности на рынке в целом», — прокомментировал куратор направления «Информационная безопасность» Академии «АйТи» Михаил Шепелев.</p> Компания «Аладдин» объявила о запуске программы авторизованного обучения технических специалистов работе … message ИИ-помощник тимлида в закрытом контуре: что меняется в работе https://www.itweek.ru/themes/detail.php?ID=235636 Tue, 29 Sep 2026 10:10:08 +0300 <p><em>Если тимлид работает с внешними зарубежными моделями, ему нужно выбирать: либо давать ИИ только обезличенные данные, либо оставлять часть рабочих сценариев за пределами автоматизации.</em></p> <p><em>С появлением ИИ внутри закрытого корпоративного контура возможностей стало заметно больше. Рассмотрим, что именно поменялось и что это даёт бизнесу.</em></p> <h3>Ограничения облачных моделей</h3> <p>Проще всего использовать ИИ-агента в облачном контуре у провайдеров, которые уже зарекомендовали себя: чаще всего это OpenAI или Anthropic. Возможности этих моделей покрывают большую часть сценариев, которые нужны руководителю — анализ рисков, распределение задач, подготовку материалов для найма.</p> <p>При работе с зарубежными провайдерами есть важное ограничение: часть сценариев упирается в данные. Их нельзя просто передать внешней модели: по закону компании нужно соблюдать требования к обработке и трансграничной передаче данных, а также собственные правила информационной безопасности.</p> <p>Из-за работы с персональными данными информацию о сотрудниках приходится обезличивать и ограничивать доступ к рабочим системам. Поэтому ИИ в таком варианте не может участвовать в процессах напрямую.</p> <h3>Преимущества закрытого контура</h3> <p>Сейчас начинает набирать популярность другой вариант — использовать ИИ внутри корпоративного контура. Агент работает с актуальными данными портала и в правах конкретного пользователя: видит доступные задачи, проекты, оргструктуру и другие сущности.</p> <p>Закрытый контур снимает часть ручной работы вокруг ИИ: агент может обращаться к корпоративным данным непосредственно в системе и использовать их в доступных ему сценариях. За счёт этого ИИ постепенно встраивается в повседневные рабочие процессы.</p> <p>Ниже разберем несколько сценариев, где эта разница особенно заметна.</p> <h3>Тестовые задания при найме</h3> <p>С облачными провайдерами тимлид сам описывал стек, уровень позиции и типовые задачи команды. Получалось так, что тестовое задание строилось в основном по пересказу и требовало ручной доработки.</p> <p>В работе внутри инфраструктуры компании агент может опираться на реальные задачи отдела. За счёт этого тестовое задание ближе к тому, с чем кандидат действительно столкнётся в работе.</p> <h3>Распределение задач между сотрудниками</h3> <p>Раньше для работы с ИИ приходилось вручную составлять профили сотрудников: описывать сильные стороны, опыт, загрузку. Тогда модели понимали, кто сколько делает и кому какую задачу лучше отдать в зависимости от умений. Но такие профили устаревают, а обновлять их можно только вручную.</p> <p>В закрытом контуре агент сам может видеть актуальную информацию по каждому человеку, и это даёт более свежую картину загрузки. Хотя окончательное решение всё равно за руководителем: усталость, мотивацию и другие человеческие факторы компьютеры пока не понимают.</p> <h3>Анализ рисков и сроков</h3> <p>При использовании сторонних технологий ИИ оценивал реалистичность плана в основном по общим знаниям и тому контексту, который передал тимлид. В итоге выводы часто оставались достаточно общими.</p> <p>Если информация остаётся в компании, ИИ-инструмент получает возможность сопоставить оценку с историей конкретной команды и увидеть: сколько времени занимали похожие задачи? Где возникали задержки? Какие узкие места есть сейчас? Всё это уточняет прогнозы модели.</p> <p>При этом числовые показатели нужно рассчитывать на стороне API или кода, а ИИ использовать для анализа результатов и формулировки выводов.</p> <h3> Рефлексия — разбор управленческих решений </h3> <p>В этом сценарии тимлид использует ИИ как собеседника, чтобы разобрать собственное решение до того, как его принять.</p> <p>Вместо того чтобы отбирать контекст таких обсуждений, агентов закрытого контура можно подключить ко всем важным каналам информации. Если говорить о бизнес-портале, то такими источниками будут чаты и звонки, встречи и задачи, сотрудники, отделы, проекты, CRM, база знаний и завершённые сеансы работы с агентом. Причём все это собирается в пределах прав конкретного сотрудника.</p> <h3>Передача результата команде</h3> <p>Некоторые процессы при использовании зарубежных моделей для тимлида были невозможны совсем. Например, работа с внешней моделью в основном остаётся личным пространством тимлида: он отдельно готовит контекст, а полученный результат для сотрудников пересказывает или переносит в другие инструменты.</p> <p>Внутри одной экосистемы результат можно сразу вернуть в рабочую среду.</p> <h3>Работа с календарём команды</h3> <p>Внешний ИИ тоже можно подключить к календарю технически, но для рабочего календаря компании это ограничено из-за отсутствия доступа сторонней модели к данным сотрудников и требований безопасности.</p> <p>Если агент работает внутри контура и в правах пользователя, он может свободно обращаться к доступным календарям непосредственно на портале. Например, найти общий свободный слот нескольких сотрудников без ручной сверки расписаний.</p> <h3>Что в итоге меняется для тимлида</h3> <p>Закрытый контур делает работу с ИИ удобнее: агент становится частью постоянных рабочих процессов и может участвовать в повседневных задачах без постоянной ручной подготовки данных вокруг каждого запроса.</p> <p>Все управленческие решения остаются за человеком. ИИ помогает собрать факты и подготовить варианты, а тимлид учитывает то, чего нет в системе: состояние людей, отношения внутри команды и реальную сложность ситуации.</p> <p>#IMAGE_235637#</p> Если тимлид работает с внешними зарубежными моделями, ему нужно выбирать: либо давать ИИ только обезличенные данные … article Владимир Верхотуров, тимлид DevRel-команды ”Битрикс24” IDC: тренды индустрии робототехники 2026 года https://www.itweek.ru/themes/detail.php?ID=235635 Tue, 29 Sep 2026 10:03:48 +0300 <p><em>Навкендар Сингх, вице-президент IDC India по направлениям клиентских устройств и IPDS, рассказывает в корпоративном блоге о том, что показала Всемирная конференция по робототехнике (WRC) 2026 г. в плане перехода физического искусственного интеллекта (Physical AI) к практическому внедрению.</em></p> <p>WRC’ 2026 прошла в Пекине в августе под девизом «Симбиоз человека и машины: интеграция производства и спроса». В мероприятии приняли участие более 300 компаний, представивших свыше 2000 продуктов, включая более 150 новинок. Впервые в программу конференции был включен специальный «День закупок»: 49 китайских государственных предприятий выступили единым инновационным консорциумом, обозначив реальный промышленный спрос по 12 сценариям применения.</p> <p>Робототехника становится все более ориентированной на конкретные задачи, а изменения со стороны спроса теперь стимулируют масштабный рост отрасли. Статистика подтверждает эту тенденцию. По данным Министерства промышленности и информатизации КНР, выручка крупных предприятий робототехнической отрасли страны за период с января по май 2026 г. превысила 90 млрд. юаней (13,4 млрд. долл.), увеличившись на 26,9% по сравнению с аналогичным периодом прошлого года. Собственные данные IDC свидетельствуют о том, что в 2025 г. мировые поставки человекоподобных роботов достигли примерно 18 тыс. единиц, показав рост почти на 800% в годовом исчислении.</p> <p>Исследования IDC также показывают, что большинство предприятий, проводящих пилотные проекты с использованием роботов, наделенных воплощенным интеллектом (embodied intelligence), пока остаются на стадии проверки концепции. Между этапами проверки технологии и ее масштабного внедрения существует ряд реальных препятствий: вопросы стабильности работы, стоимости, окупаемости инвестиций (ROI), а также организации повседневной эксплуатации и технического обслуживания. </p> <p>Впрочем, экспозиция этого года продемонстрировала более высокий уровень развития технологий. Роботы выполняли задачи целиком, а не ограничивались отдельными действиями, причем некоторые из них работали в реальных производственных, а не в лабораторных условиях. Конкуренция в сфере физического ИИ теперь разворачивается не только в области технических характеристик, но и в возможностях промышленного внедрения. Четыре ключевых тренда, выявленных на конференции, наглядно иллюстрируют эту ситуацию.</p> <h3>Тренд первый: гонка моделей уступает место обучению в реальных условиях</h3> <p>За последний год произошел значительный прогресс в области больших моделей воплощенного интеллекта, моделей, объединяющих компьютерное зрение, обработку естественного языка и управление роботами (VLA, Vision-Language-Action) и моделей реальности (world models). Это позволило роботам выйти за рамки простого восприятия и понимания окружающей среды и перейти к принятию решений и выполнению сложных комплексных задач. В нынешнем году характер конкуренции меняется: теперь важнее не то, чья модель мощнее, а то, какой поставщик сможет заставить роботов работать и обучаться в реальных сценариях. Модели служат фундаментом возможностей физического ИИ, однако именно данные из реального мира и непрерывное обучение станут определяющими факторами успеха на следующем этапе развития.</p> <p>На конференции WRC’ 2026 неизменный интерес вызывали модели реальности, системы VLA, платформы для симуляции, полигоны для обучения роботов и технологии сбора данных. Объединение виртуальной и реальной сред становится важным способом получения данных: симуляция позволяет генерировать их в больших объемах, данные из реальных сценариев обеспечивают привязку к действительности, а их сочетание снижает затраты на метод проб и ошибок. Поступление операционных данных обратно в цикл обучения запускает своего рода маховик: восприятие — обучение — выполнение — получение обратной связи — непрерывное совершенствование.</p> <p>В Китае уже запланировано создание или ведется строительство более 40 полигонов для обучения роботов, охватывающих свыше 14 провинций и муниципалитетов. Наиболее развитые из них способны генерировать миллионы записей данных в год. Одновременно с этим постоянное совершенствование манипуляторов (роботизированных рук), датчиков усилия и других аппаратных компонентов расширяет возможности роботов по сбору более информативных данных о манипуляциях. Поскольку модели, данные, симуляции и аппаратное обеспечение начинают развиваться взаимосвязанно, конкуренция между компаниями все меньше зависит от того, чья модель показывает лучшие результаты в тестах, и все больше — от способности превратить операционные данные в эффективный цикл обучения.</p> <h3>Тренд второй: от демонстрации возможностей к масштабируемому внедрению</h3> <p>По мере того как роботы выходят в реальную бизнес-среду, меняются и критерии их оценки. На конференции этого года ряд поставщиков перешли от демонстрации отдельных действий к проверке комплексных рабочих процессов, включающих депаллетизацию, сортировку, доставку, уборку и инспекцию. Теперь они демонстрируют работоспособность полноценных процессов, а не разрозненных функций. Главная грань, разделяющая игроков в сфере робототехники, сместилась от технических демонстраций к обеспечению стабильной работы и внедрению решений.</p> <p>Под функциональными возможностями теперь понимается непрерывная работа, а не выполнение разовой операции: от роботов требуются автономное восприятие, планирование задач, непрерывное выполнение действий и способность самостоятельно справляться с нештатными ситуациями. Внедрение — это более серьезное испытание. Переход от этапа проверки концепции к реальной эксплуатации означает, что заказчики повышают требования к стабильности, эффективности развертывания, стоимости обслуживания и окупаемости инвестиций, а ключевыми полигонами для такой проверки становятся автомобильная промышленность, сектор 3C-электроники (компьютеры, телекоммуникационное оборудование и бытовая электроника) и складская логистика. Вместе с этим изменились и показатели, на которые реально ориентируются покупатели: это доля успешно выполненных задач, время непрерывной работы, стоимость выполнения одной задачи и срок окупаемости, а не технические характеристики, которые вендоры демонстрируют в ходе презентаций.</p> <p>Исследование IDC показывает, что более 20% пользователей уже перешли от этапа ознакомления с рынком к пилотным проектам, а темпы перехода от проверки концепции к полномасштабному внедрению растут. Стабильность работы, скорость развертывания, текущее обслуживание и коммерческая окупаемость — именно эти факторы станут критериями, по которым будут различаться вендоры в ближайшие два-три года.</p> <h3>Тренд третий: от прорывов в отдельных сценариях к поэтапному внедрению</h3> <p>Технологии физического ИИ не смогут масштабироваться сразу на все возможные сценарии. Различия в уровне технической зрелости, сложности рабочей среды и аспекты коммерческой окупаемости определяют поэтапный путь внедрения: в сфере коммерческих услуг идет этап изучения возможностей, в промышленности — этап расширения масштабов, а в сегменте бытового и потребительского использования закладывается фундамент для будущего развития.</p> <ul> <li><strong> Сфера коммерческих услуг находится на стадии глубокого изучения возможностей.</strong> В таких областях, как общественное питание, гостиничный бизнес и розничная торговля, существует четкий спрос на автоматизацию конкретных задач, однако рабочая среда здесь сложнее, чем на производстве. Это требует от роботов более совершенных систем автономной навигации, понимания окружающего пространства и обработки нестандартных ситуаций. Внедрение воплощенного интеллекта в этом секторе ускоряется, но происходит осторожно.</li> <li><strong> Промышленное производство станет лидером по темпам масштабирования. </strong>Такие отрасли, как автопром, 3C-электроника и складская логистика, характеризуются относительно упорядоченными процессами, четкими границами задач и высокой потребностью в снижении издержек и повышении эффективности. По данным IDC, объем китайского рынка промышленных роботов с воплощенным интеллектом в 2025 г. составил около 5,74 млрд. юаней (из них 3,62 млрд. пришлось на долю традиционных промышленных роботов, а 2,12 млрд. — на долю гуманоидных роботов). Именно здесь наблюдается наилучшее сочетание технической зрелости и коммерческой ценности.</li> <li><strong> Рынок бытовых и потребительских роботов обладает долгосрочным потенциалом.</strong> Домашняя среда отличается высокой степенью неструктурированности и разнообразием задач (в том числе редких и нестандартных), что предъявляет повышенные требования к способности робота к обобщению опыта, безопасности, навыкам взаимодействия и стоимости устройства. Тем не менее, потенциальная сфера применения достаточно широка, а возможности рынка в долгосрочной перспективе — значительны.</li> </ul> <p>Процесс внедрения роботов будет продвигаться от сред с высокой степенью упорядоченности к средам с умеренной, а затем и низкой структурированностью; при этом различные форм-факторы роботов будут все точнее подбираться под конкретные сценарии использования.</p> <h3>Тренд четвертый: конкуренция на уровне отдельных устройств уступает место конкуренции системных возможностей</h3> <p>По мере перехода физического ИИ к этапу промышленного внедрения цепочка создания стоимости в робототехнике расширяется: она перестает ограничиваться лишь аппаратной платформой и теперь одновременно включает в себя вычислительные мощности, модели, данные, ключевые компоненты и прикладные решения. В конференции этого года приняли активное участие компании из всей отраслевой цепочки (как китайские, так и зарубежные), а 49 государственных предприятий выступили единым инновационным консорциумом. Конкуренция смещается от поставок отдельных технологий к сотрудничеству в рамках отраслевой цепочки и совместной разработке сценариев применения; в результате границы конкурентной борьбы между предприятиями расширяются, охватывая вопросы взаимодействия аппаратного и программного обеспечения, а также построения экосистем.</p> <ul> <li><strong> Углубляется сотрудничество в рамках производственной цепочки: </strong>ускоряется взаимодействие между платформами для роботов и производителями ключевых компонентов, таких как чипы, датчики, редукторы, сервосистемы и системы захвата (роботизированные руки).</li> <li><strong> Происходит ускоренное сближение программных моделей и аппаратного обеспечения:</strong> разработчики больших моделей, производители роботов и научно-исследовательские институты совместно работают над созданием VLA-моделей, моделей реальности и систем управления движением.</li> <li><strong> Ускоряется формирование систем поддержки отрасли.</strong> По всему Китаю уже открыты десятки инновационных центров, специализирующихся на воплощенном интеллекте; их деятельность охватывает все этапы: от разработки технологий и пилотной проверки до обучения на данных и внедрения в реальных сценариях.</li> <li><strong> Расширяется круг участников международного сотрудничества:</strong> конференция привлекла 30 зарубежных организаций, представляющих сферы научных исследований, инжиниринга, промышленности и инвестиций.</li> </ul> <p>Наилучшие шансы на переход от локальных вариантов использования к масштабному коммерческому внедрению имеют компании, обладающие наиболее развитыми способностями к формированию экосистемы, а не просто те, у кого самый совершенный отдельный продукт.</p> <h3>Прогноз IDC</h3> <p>Технологии физического ИИ переходят от стадии демонстрации возможностей к этапу подтверждения их промышленной ценности. Ключевая конкурентоспособность робототехнических компаний будет зависеть не столько от технического совершенства решений, сколько от способности превратить эти технологии в надежные, тиражируемые продукты, обладающие реальной коммерческой ценностью. Физический ИИ вступает в фазу глубокой индустриализации, и на следующем этапе конкуренции в сфере робототехники основное внимание будет уделяться реальному спросу и реальной ценности.</p> <p>Ближайшие два-три года станут важным периодом перехода роботов с воплощенным интеллектом от стадии проверки технологий к этапу масштабного внедрения. В различных сферах применения будет наблюдаться поэтапный процесс развертывания: первыми возможности использования начнут осваивать сервисные сценарии, промышленный сектор станет ключевым направлением для масштабного внедрения, а рынок бытовых и потребительских решений будет обладать долгосрочным потенциалом развития. Одновременно с этим физический ИИ сместит акцент в отраслевой конкуренции с характеристик отдельных аппаратных средств на системные возможности, формируемые за счет интеграции моделей, данных, оборудования и прикладных решений.</p> Навкендар Сингх, вице-президент IDC India по направлениям клиентских устройств и IPDS, рассказывает … article Российский рынок DevOps as a Service достиг 16,2 млрд рублей https://www.itweek.ru/themes/detail.php?ID=235633 Mon, 28 Sep 2026 16:21:26 +0300 <p>Российский рынок услуг DevOps as a Service (DaaS) по итогам 2025 года предварительно оценивается в 16,2 млрд рублей — это 17,1 % от общих затрат на ИТ-аутсорсинг, объём которого составил около 95 млрд рублей. Таковы данные исследования «Российский рынок DevOps as a Service <nobr>2025–2030»</nobr> от «Квадрант Технологий», в котором приняли участие 200 организаций малого, среднего, крупного и крупнейшего бизнеса (выручка от 25 млрд рублей).</p> <p>Ключевой вывод исследования: рынок находится в состоянии системного противоречия. Спрос на управляемый сервис сформировался, но модель закупки за ним не поспевает — компании покупают набор работ там, где им нужна управляемая эксплуатация с явной ответственностью исполнителя за результат.</p> <p>Лидерами рынка по объёму выручки остаются универсальные системные интеграторы, у которых DevOps as a Service в большинстве проектов остаётся встроенной функцией, а не самостоятельным направлением закупки — его доля в бюджете, как правило, не превышает 10 %. Среди же специализированных DevOps-компаний наибольшую долю занимает «Флант».</p> <p>При инерционном сценарии среднегодовой рост рынка (CAGR) до 2030 года составит около 5 %, а объём затрат на услуги DaaS достигнет 22 млрд рублей. В ускоренном сценарии — при переходе к платформенным моделям и росте спроса на управляемые сервисы — рост может составить <nobr>15–25 %</nobr> в год.</p> <p>Заказчики пока склоняются к классическому ИТ-аутсорсингу: около 40 % всех затрат на аутсорсинг направляется на сервисы информационной безопасности, а DevOps as a Service ещё не имеет чёткого позиционирования среди целевой аудитории.</p> <p>Рынок DevOps as a Service находится на переходном этапе: модель потребления услуг пока отстаёт от уровня зрелости самой отрасли. Сформировавшийся спрос на управляемый сервис с ответственностью за результат ещё не в полной мере отражается в практике закупок, которая во многом опирается на привлечение отдельных специалистов и разовые работы.</p> <p>Это отражает общую тенденцию: отрасль постепенно смещается от модели аутстаффинга к сервисному и инженерному подходу. На первый план выходит запрос на качественное сопровождение production-систем (24/7, SLA, работа с инцидентами), предсказуемые модели оказания услуг и встроенные практики безопасной разработки.</p> <p>Проблема номер один для всех категорий респондентов — нехватка квалифицированных DevOps-специалистов (31,5 %), за ней следуют обеспечение безопасности (29,5 %) и сопровождение CI/CD (29 %). При этом сильнее всего дефицит компетенций ощущается в части DevSecОps и соответствия регламентам РБПО (35,5 %), DataOps (29 %) и observability (28,5 %).</p> <p>Показательно, что дефицит смещён не в сторону «модных» технологий, а в сторону критичных для стабильности и безопасности компетенций. Компании научились внедрять инструменты быстрее, чем формировать команды, способные их стабильно и безопасно эксплуатировать.</p> <p>По факту DevOps в большинстве организаций — это набор отдельных практик, а не целостная инженерная модель. Наиболее распространены базовые практики: observability (32,5 %), безопасная разработка (31,5 %) и Infrastructure as Code (31 %), тогда как DataOps используют лишь 21,5 %, а MLOps — всего 4,5 % опрошенных.</p> <p>Исключительно на аутсорсинг DevOps отдаёт лишь десятая часть всех респондентов. Основной моделью становится гибридный подход, сочетающий аутсорсинг с внутренними ресурсами: его используют 56 % компаний малого и среднего бизнеса (выручка 500 млн — 3 млрд рублей) и 42 % компаний крупного бизнеса. Большинство крупнейших организаций (59 %) пока предпочитают реализовывать всё самостоятельно, ссылаясь на наличие собственных ресурсов.</p> <p>Однако наличие собственной команды не устраняет дефицит компетенций, а лишь маскирует его. Рынок уже движется к сервисной модели, но пока не готов полностью отдать DevOps внешним провайдерам — при этом справляться своими силами получается всё хуже.</p> <p>В ближайшие <nobr>1–2</nobr> года компании ожидают перехода к более централизованной DevOps-модели с едиными стандартами и платформой (28 %) и развития DevOps как внутреннего сервиса (27,5 %). DataOps, observability и SRE постепенно становятся частью базового контура, а сама эволюция DevOps в сторону внутренней платформы и сервисной модели открывает рынок DevOps as a Service.</p> <p>Отдельная особенность рынка — характер принятия решений. DevOps as a Service остаётся «инициативой снизу, но покупкой сверху»: потребность формируют инженеры, но деньги и финальное решение — на уровне руководства. Сам выбор провайдера строится скорее на доверии и репутации, чем на формальных процедурах.</p> Российский рынок услуг DevOps as a Service (DaaS) по итогам 2025 года предварительно оценивается в 16,2 млрд … message iTPROTECT выпустил новую версию iTPROTECT Scout https://www.itweek.ru/themes/detail.php?ID=235632 Mon, 28 Sep 2026 16:18:51 +0300 <p>Команда iTPROTECT, специализированного интегратора в области информационной безопасности, обновила облачный сервис проверки защищённости внешнего ИТ-контура iTPROTECT Scout 2.0. Среди ключевых изменений — обновленная методика оценки рисков, разграничение прав доступа к персональным данным, проверка механизмов защиты почты от фишинга и встроенный искусственный интеллект (ИИ).</p> <p>Число киберугроз постоянно растет, но одновременно расширяется и цифровой периметр компаний. Новые онлайн-сервисы, клиентские платформы, домены и IP-адреса увеличивают число уязвимостей и точек входа, часть из них остается вне поля зрения служб информационной безопасности. Защита внешнего периметра требует непрерывного автоматизированного контроля с помощью инструментов класса EASM (External Attack Surface Management) или CPT (Continuous Penetration Testing), которые позволяют вовремя обнаружить и устранить уязвимости. </p> <p>В ответ на запрос рынка компания iTPROTECT в 2025 году вывела сервис непрерывного мониторинга и контроля защищенности внешнего ИТ-контура — iTPROTECT Scout. Сервис осуществляет 11 этапов проверки внешнего периметра: находит доступные извне активы, проверяет их на уязвимости с использованием 9 источников (включая БДУ ФСТЭК России, CISA KEV и National Vulnerability Database), считает и приоритизирует риски, а также формирует отчёты с оценкой влияния угроз на бизнес и рекомендациями по их устранению.</p> <p>За год команда разработчиков усовершенствовала инструмент, дополнив его рядом функций и новыми алгоритмами сканирования. В частности, благодаря его новой архитектуре скорость сканирования периметра по некоторым направлениям выросла более чем в <nobr>2-3 раза.</nobr> Это делает iTPROTECT Scout одним из самых производительных на рынке в этом классе решений. Также разработчики обновили личный кабинет, расширив возможности сортировки уязвимостей.</p> <p>iTPROTECT Scout 2.0 включает 58 функций. Центральным обновлением стала новая методика оценки рисков внешнего периметра. Проверка проводится по 6 направлениям: сетевая безопасность, безопасность веб-приложений, раскрытие информации (например, доступные извне файлы настроек), утечки данных, безопасность почты и DNS, управление поверхностью атаки. Для найденных уязвимостей отображается факт наличия готовых эксплойтов, это позволяет приоритизировать задачи по устранению угроз с высокими рисками.</p> <p>Также важным обновлением стала возможность многопользовательского доступа к личному кабинету с разграничением прав. Решение позволяет вести сразу несколько проектов мониторинга в филиальных сетях и открывает доступ к персональным данным из утечек только при наличии у пользователя прав. Не менее значимая модификация — проверка защищенности электронной почты (SPF, DKIM, DMARC) от фишинговых рассылок от имени компании.</p> <p>Часть функций в новой версии автоматизирована с помощью локальной модели ИИ (работает без подключения внешних источников). Например, она формирует чек-листы проверки эксплуатируемости обнаруженных уязвимостей и переводит их описание на русский язык. </p> <p>«Динамика киберугроз и изменение ИТ-ландшафта компаний создают риски все новых атак. Наш сервис позволяет выявлять устаревшее ПО, незакрытые тестовые среды и сервисы, ошибки конфигурации, фишинговые сайты, утечки учетных данных или слабые пароли. Эти проблемы требуют постоянного мониторинга. Пентеста, проводимого пару раз в год, недостаточно для непрерывной оценки защищенности организации. iTPROTECT Scout позволяет отслеживать все то, что происходит между этими проверками», — отметил Дмитрий Иняев, директор по развитию продуктов и услуг iTPROTECT.</p> <p>Сервис iTPROTECT Scout включен в Единый реестр отечественного программного обеспечения Минцифры России и его успели оценить более 80 российских организаций. </p> Команда iTPROTECT, специализированного интегратора в области информационной безопасности, обновила облачный сервис проверки … message Платформа InKnowledge возглавила рейтинг российских KMS-систем для крупного бизнеса по версии CNews https://www.itweek.ru/themes/detail.php?ID=235631 Mon, 28 Sep 2026 16:15:53 +0300 <p>CNews опубликовал первый рейтинг российских коробочных решений для управления знаниями, ориентированных на задачи крупного бизнеса. KMS-платформы (от англ. Knowledge Management System — системы управления корпоративными знаниями) оценивались по ключевым блокам: создание и управление контентом, поиск, ИИ-возможности, настройка оформления, поддержка.</p> <p>Главный вывод: базовый функционал — хранение, публикация, поиск, разграничение прав — уже закрыт большинством решений на рынке. Конкуренция смещается в сторону гибкости, адаптации под бизнес-процессы и задачи компании, интеграций, зрелости ИИ-сценариев и способности закрывать в едином контуре клиентский опыт (CX) и опыт сотрудников (EX).</p> <p>По большинству функциональных блоков InKnowledge (L2U, входит в группу компаний BSS) обошла конкурентов и заняла первую строчку. Платформа стала лидером по возможностям создания и управления контентом: поддерживает 22 типа готового контента «из коробки» — от статей и сценариев до BPMN-процессов и омниканальных материалов. Пользователи могут самостоятельно создавать новые типы контента и шаблоны, не обращаясь к вендору. </p> <p>InKnowledge — единственное решение в обзоре, которое предоставляет вариативность отображения результатов поиска: карточки, списки, таблицы, сниппеты. Кроме того, платформа отличается максимальной гибкостью в настройке оформления под разных пользователей и роли. В части ИИ: встроенная генерация ответов по базе знаний компании (RAG), собственная большая языковая модель (LLM) и возможность задавать отдельные инструкции для ИИ-модели по каждому сайту и разделу. </p> <p>«Как лидеры рынка, мы рады видеть развитие российских решений вместе с потребностями бизнеса — они становятся гибче, лучше адаптируются к разным корпоративным сценариям и помогают сотрудникам и клиентам в повседневных задачах. Такие платформы постепенно превращаются в надежный инструмент, который сопровождает ключевые процессы компании и делает работу со знаниями более эффективной», — прокомментировал Дмитрий Лактионов, директор продуктового направления Базы знаний компании BSS.</p> <p>В ходе исследования, эксперты обратили внимание на смену парадигмы. Во-первых, крупный бизнес всё чаще запрашивает не базу знаний для отдельного подразделения, а единую платформу, объединяющую разрозненные решения. Во-вторых, KMS закрывает сразу два направления — клиентский опыт (CX) и опыт сотрудников (EX). В-третьих, генеративный ИИ перестаёт быть только «умным поиском». Следующий шаг — ИИ-агенты, подключённые к базе знаний и способные выполнять цепочки действий с обращением к внешним системам. И наконец, усиливается тренд на контекстную подачу знаний. </p> <p>Для бизнеса это означает, что выбор современной системы управления знаниями (уровня InKnowledge) позволяет не просто «оцифровать регламенты», а получить инструмент, который снижает время на поиск информации, ускоряет адаптацию новых сотрудников и напрямую влияет на качество клиентского сервиса за счет мгновенной выдачи контекстных ответов. Инвестиции в платформы с поддержкой ИИ-агентов и оркестрации сегодня — это фундамент для снижения издержек и повышения конкурентоспособности в условиях, где скорость принятия решений играет ключевую роль.</p> CNews опубликовал первый рейтинг российских коробочных решений для управления знаниями, ориентированных на задачи крупного … message Доменные споры: судебная и внесудебная защита онлайн-актива бизнеса https://www.itweek.ru/themes/detail.php?ID=235628 Mon, 28 Sep 2026 11:55:30 +0300 <p><em>Ежегодно в мире регистрируются десятки тысяч новых доменов. И далеко не все — добросовестно. Кто-то использует чужой бренд для продажи контрафакта, кто-то — для перенаправления чужого трафика на себя. Бизнес теряет клиентов и репутацию. </em><em>Рассмотрим, к</em><em>ак защитить онлайн-актив, когда идти в российский суд, а когда — в международный арбитраж</em><em>,</em><em> и почему промедление грозит потерей домена</em><em>.</em></p> <p>Компания на протяжении длительного времени вкладывает ресурсы в развитие бренда, рекламу и поддержание репутации. При этом третьи лица могут зарегистрировать домен, включающий товарный знак этой компании, и использовать его для открытия собственной торговой площадки или для перехвата клиентского потока. Также возможен вариант, когда регистратор предлагает выкупить домен по завышенной цене. Отдельный риск — регистрация домена с последующим предложением правообладателю выкупить его по завышенной цене. В зависимости от обстоятельств такие действия могут квалифицироваться как недобросовестное использование доменного имени и служить основанием для судебного или внесудебного доменного спора.</p> <p>К недобросовестному использованию относятся:</p> <ul> <li> <strong>Киберсквоттинг</strong> — регистрация домена, включающего в себя чужой бренд, с целью перепродажи.</li> <li><strong>Тайпсквоттинг</strong> — регистрация домена с ошибкой в написании (например, nik.ru вместо nic.ru).</li> <li><strong>Использование чужого товарного знака в домене</strong> для привлечения трафика или продажи подделок.</li> <li><strong>Фишинг и иные мошеннические сценарии</strong> — использование похожего доменного имени для создания видимости официального ресурса правообладателя.</li> </ul> <p>При этом само по себе сходство доменного имени с брендом еще не означает нарушения. Для юриста важно оценить совокупность обстоятельств: права на обозначение, наличие у администратора самостоятельного законного интереса и признаки недобросовестной регистрации или использования домена.</p> <h2>Два показательных примера</h2> <h3>Кейс № 1: eBay подала жалобу сама на себя</h3> <p>Компания внесла свои товарные знаки в Trademark Clearinghouse, но забыла, что домены были зарегистрированы на уполномоченную компанию. Спустя время юристы eBay обнаружили «нарушение» и подали жалобу в WIPO (ВОИС, Всемирная организация интеллектуальной собственности). Арбитр, разобравшись, постановил передать домены в непосредственное управление eBay. Уполномоченная компания не возражала. История закончилась без конфликта, но с лишними затратами времени и денег.</p> <p>Вывод для юриста: доменный портфель нужно вести централизованно. В реестре должны быть указаны все домены компании, их администраторы, регистраторы, сроки продления, основания регистрации и лица, имеющие доступ к управлению. Иначе компания может потратить время и деньги на спор, которого можно было избежать внутренним аудитом.</p> <h3>Кейс № 2: ChatGPT (OpenAI) против администратора chatgpt.com</h3> <p>OpenAI долгое время использовала поддомен chat.openai.com, а заявку на товарный знак ChatGPT подала только 27 декабря 2022 года. Но 13 декабря некто зарегистрировал домен chatgpt.com. OpenAI обратилась в WIPO. Несмотря на то, что формально товарный знак был зарегистрирован позже, комиссия учла известность бренда по «общему праву» (common law rights) — к тому моменту сервис уже имел миллионы пользователей.</p> <p>Решение: домен передан OpenAI. Этот кейс показывает, что в UDRP имеет значение не только дата формальной регистрации товарного знака, но и доказательства фактического использования обозначения, его узнаваемости и риска смешения. Поэтому при подготовке жалобы важно собирать не только сведения о товарном знаке, но и подтверждения публичного использования бренда: публикации, рекламные материалы, данные об аудитории, скриншоты сайта и другие доказательства известности обозначения.</p> <h2>Два пути: российский суд и международный арбитраж</h2> <p>Восстановить свои права можно двумя способами. Они отличаются тем, в каких доменных зонах зарегистрировано имя.</p> <ul> <li><strong>Первый</strong> путь — российский суд. Это касается доменов в российских национальных зонах .ru, .рф, .su. В таких спорах ключевое значение имеют правильная формулировка требований, доказательство нарушения исключительного права и своевременное применение обеспечительных мер, чтобы спорный домен не был передан или аннулирован до окончания процесса.</li> <li><strong>Второй</strong> путь — внесудебная процедура UDRP. Когда домены в международных зонах .com, .org, .net, а также в новых доменных зонах верхнего уровня, например, .online, .shop, .tech и другие. Здесь действует Единая политика рассмотрения споров о доменных именах (UDRP), разработанная ICANN — международной некоммерческой организацией, отвечающей за координацию системы доменных имен. Это внесудебная процедура: жалоба подается в один из аккредитованных арбитражных центров: WIPO, ADR Forum, Чешский арбитражный центр, Азиатский центр ADNDRC (полный перечень доступен на сайте ICANN). Решение принимается в среднем за два месяца и обязательно для исполнения регистратором. Именно этот механизм используют крупные международные корпорации. Для правообладателя одно из преимуществ UDRP — формализованный предмет доказывания и сравнительно короткий срок рассмотрения спора.</li> </ul> <p>По <a href="https://cctld.ru/media/news/industry/39470/">статистике</a> WIPO, за 2025 год по процедуре UDRP поступило 6 282 жалобы. 90% из них касались доменов в зоне .com. В результате 79% споров завершились передачей домена истцу, 15% — урегулированы по соглашению сторон, 5% — отклонены, 1% — прекращены. Цифры наглядно демонстрируют эффективность внесудебного подхода.</p> <h2>Судебная процедура в России: пошаговый алгоритм</h2> <p>Если домен, нарушающий ваши права на товарный знак, зарегистрирован в зонах .ru, .рф или .su, нужно обращаться в российский суд. Процесс состоит из четырех этапов.</p> <h3>1. Досудебные ограничения (14 дней) для доменов .ru и .рф</h3> <p>Еще до подачи иска можно временно «заморозить» домен. Для доменов в .ru и .рф через <a href="https://cctld.ru/help/trademark/disputs/claim.php">веб-форму</a> Координационного центра .RU/.РФ правообладатель направляет регистратору заявление о нарушении. Регистратор обязан установить в реестре ограничения на 14 календарных дней. В этот период администратор домена не может передать его иному лицу, сменить регистратора или аннулировать.</p> <p>Этот механизм не решает спор по существу, но позволяет сохранить статус-кво и выиграть время для подготовки иска и ходатайства об обеспечительных мерах. Использовать его стоит сразу после обнаружения нарушения, особенно если есть риск быстрой передачи домена третьему лицу.</p> <h3>2. Подача иска и обеспечительные меры</h3> <p>Ключевой момент — правильная формулировка исковых требований. Типичная ошибка: просить просто запретить использование домена. Такого требования может оказаться недостаточно для последующей перерегистрации домена на правообладателя. Для последующей перерегистрации домена на правообладателя нужно заявить хотя бы одно из требований:</p> <ul> <li> запрет администратору использовать в доменном имени обозначение, права на которое принадлежат истцу;</li> <li> запрет администратору использовать соответствующее доменное имя;</li> <li> признание администрирования домена нарушением прав правообладателя.</li> </ul> <p>Одновременно с иском подавайте ходатайство об обеспечении иска. Суд может запретить администратору и регистратору любые действия по аннулированию регистрации домена, передаче прав администрирования домена иному лицу и передачу поддержки сведений о домене иному регистратору. Если суд по каким-то причинам откажет в обеспечении, есть запасной вариант: обратиться к регистратору с просьбой установить срочные ограничения на 90 дней (для доменов .ru и .рф) и на 60 дней (для доменов .su) на основании уже принятого к производству иска. Многие правообладатели не знают об этой возможности, а зря — домен может быть продан или переоформлен за считанные часы.</p> <p>Для корпоративного юриста это важный резервный инструмент: судебный процесс может занимать месяцы, тогда как передать домен другому администратору или изменить регистратора можно значительно быстрее.</p> <h3>3. Предмет взыскания</h3> <p>Сложность в том, что единой практики по доменным спорам в РФ нет. Суды опираются на статьи 1484 и 1252 ГК РФ, а также на принцип недопустимости недобросовестной конкуренции (статья 14.6 Закона о защите конкуренции). Ключевые обстоятельства, которые нужно доказать:</p> <ul> <li> доменное имя тождественно или сходно до степени смешения с товарным знаком;</li> <li> у администратора нет законного интереса в использовании этого домена;</li> <li> домен используется недобросовестно (например, предлагается к продаже, либо на сайте размещена реклама конкурентов).</li> </ul> <p>Доказательства стоит фиксировать сразу после обнаружения нарушения: сделать скриншоты сайта, сохранить предложения о продаже домена и переписку с администратором, зафиксировать редиректы, рекламу конкурентов, использование обозначения, продажу контрафакта или фишинговые формы. Чем раньше это сделано, тем ниже риск, что содержание сайта изменится еще до подачи иска.</p> <h3>4. Исполнение решения</h3> <p>Решение суда вступило в силу, иск удовлетворен. Теперь у вас есть 30 дней (для доменов .ru и .рф) и 60 дней (для доменов .su) на преимущественную регистрацию домена. Вы подаете регистратору заявление о реализации преимущественного права регистрации доменного имени, копию решения, ссылку на карточку дела. Регистратор обращается в Координационный центр .RU/.РФ за выдачей ключей для перерегистрации. Если пропустить этот срок, домен не переоформят. По его истечении регистратор обязан аннулировать регистрацию этого доменного имени.</p> <p>На практике часто возникают ситуации, когда правообладатели приходят через два месяца и пытаются оспорить отказ в суде — безуспешно. Второй вариант — отказаться от преимущественной регистрации и попросить аннулировать домен. Однако после аннулирования любой желающий может зарегистрировать тот же домен в ту же секунду, и вы потеряете актив навсегда либо вам предстоит еще один судебный процесс. Поэтому рекомендуем выбирать перерегистрацию на себя.</p> <h2>Внесудебная процедура UDRP: быстро и предсказуемо</h2> <p>Для международных доменов в зонах .com, .org, .net и других процедура принципиально иная. UDRP — это политика, которую администратор домена принимает автоматически при регистрации домена (условие прописано в оферте регистратора). Спор рассматривает арбитражная комиссия, а не национальный суд.</p> <p>Основания для подачи жалобы: три обязательных условия</p> <p>Для подачи жалобы в рамках процедуры доменного спора необходимо одновременное соблюдение трех условий:</p> <ul> <li> доменное имя идентично или сходно до степени смешения с товарным знаком истца;</li> <li> у администратора нет законного права или интереса в отношении домена;</li> <li> домен зарегистрирован и используется недобросовестно (киберсквоттинг, предложение о продаже, создание ложной ассоциации с брендом).</li> </ul> <p>Что по UDRP считается недобросовестным использованием? В первую очередь — киберсквоттинг: продажа, предложение о продаже товаров и услуг, предложение к продаже самого доменного имени. Также — размещение на сайте рекламы конкурентов, попытка перенаправить трафик на свой ресурс, использование домена для фишинга. При этом для заявителя недостаточно просто сослаться на наличие товарного знака. Нужно последовательно показать все три элемента UDRP, в том числе отсутствие у администратора прав или законного интереса и признаки недобросовестной регистрации и использования домена.</p> <h2>Механизм действия</h2> <p>Жалоба подается в один из аккредитованных арбитражных центров. Лидер по числу споров — <a href="https://www.wipo.int/amc/ru/domains/">WIPO</a>. Лучше использовать его: там есть русскоязычные арбитры, а форму и шаблоны можно заполнить онлайн на русском языке. Хотя окончательное решение и переписка ведутся на английском языке, но можно ходатайствовать о русском языке, если администратор и регистратор находятся в РФ. По состоянию на сентябрь пошлина WIPO по UDRP составляет $1500 для спора по <nobr>1-5</nobr> доменам при рассмотрении дела одним арбитром. Для <nobr>6-10</nobr> доменов — $2000, при коллегии из трех арбитров стоимость выше. За эту сумму можно включить в одну жалобу до пяти доменных имен, даже с разными администраторами.</p> <p>Арбитражная комиссия устанавливает администратора и накладывает ограничения на домен на весь срок рассмотрения спора. Решение выносится в среднем за два месяца. Исполнение — 10 рабочих дней. Регистратор обязан передать домен истцу или аннулировать его в зависимости от решения. Единственное, что может приостановить исполнение, — подача иска в национальный суд (пункт 4(k) UDRP). Но на практике таких случаев мало, если арбитраж признал недобросовестность, шансов выиграть в суде у администратора практически нет.</p> <h2>Рекомендации для защиты домена компании</h2> <p>Для минимизации рисков, связанных с недобросовестным использованием доменных имен, рекомендуется придерживаться следующего порядка действий.</p> <ul> <li><strong>Проведите аудит доменного портфеля. </strong>Убедитесь, что все ключевые домены (включая варианты с транслитерацией, дефисами, распространенными опечатками) зарегистрированы на саму компанию, а не на подрядчиков или сотрудников. Если самостоятельно это сделать сложно, обратитесь к регистратору. Например, в Руцентре специалисты проводят полноценный аудит доменного портфеля и в случае необходимости помогают консолидировать домены компании.</li> <li><strong>Зарегистрируйте товарный знак. </strong>Без него вы либо вовсе не сможете инициировать ни судебную процедуру, ни UDRP, либо сделать это будет ощутимо сложнее. Для международных споров важно заранее оценить, в каких юрисдикциях компании действительно требуется защита обозначения, и сформировать доказательства его фактического использования.</li> <li><strong>Внедрите мониторинг новых регистраций.</strong> Сервисы вроде Trademark Clearinghouse или просто регулярные проверки через WHOIS помогут вовремя заметить киберсквоттера. Отдельно имеет смысл отслеживать тайпо-домены, схожие обозначения и ресурсы, которые могут создавать у пользователей ложную ассоциацию с брендом.</li> <li><strong>Собирайте доказательства сразу после обнаружения нарушения.</strong> Зафиксируйте содержание сайта, дату проверки, редиректы, предложения о продаже домена, переписку и другие обстоятельства, которые впоследствии могут подтвердить недобросовестность администратора.</li> </ul> <p>При обнаружении нарушения — сразу действуйте по алгоритму:</p> <ul> <li><strong>Для зон .ru/.рф:</strong> подайте досудебное ограничение (на 14 дней) через форму Координационного центра .RU/.РФ. Одновременно готовьте иск с требованиями и ходатайство об обеспечении. В случае отказа в обеспечении — запросите у регистратора срочные ограничения на 90 дней (для доменов .ru и .рф) и на 60 дней (для доменов .su). После выигранного решения не пропустите <nobr>30-дневный</nobr> срок (для доменов .ru и .рф) и на <nobr>60-дневный</nobr> срок (для доменов .su) для обращения к регистратору за реализацией преимущественного права регистрации домена.</li> <li><strong>Для международных зон:</strong> соберите доказательства недобросовестности — скриншоты предложений о продаже, переписку, где администратор просит выкуп. Подайте жалобу в WIPO за 1 500 долларов (до 5 доменов).</li> <li><strong>Не соглашайтесь на аннулирование домена. </strong>Всегда требуйте регистрации на себя. Аннулированный домен может перерегистрировать кто угодно, и вы начнете борьбу заново.</li> </ul> <p>Доменные споры — объективная реальность для любого крупного и среднего бизнеса, имеющего онлайн-присутствие. Эта реальность требует системного подхода: от аудита портфеля до четкого понимания различий между судебной процедурой и внесудебной UDRP. Своевременное использование досудебных ограничений, правильная формулировка исковых требований и выбор правильной юрисдикции — залог того, что ваш онлайн-актив останется с вами. Не ждите, пока киберсквоттер предложит выкупить ваш же бренд. Действуйте на опережение.</p> <p>#IMAGE_235629#</p> Ежегодно в мире регистрируются десятки тысяч новых доменов. И далеко не все — добросовестно. Кто-то … article Наталья Туркина, руководитель отдела претензионной работы и судебного представительства группы “Рунити”