https://www.itweek.ru Издание itWeek (до 2018 года — PC Week) на портале и на страницах бумажного номера информирует читателей об актуальных информационных и коммуникационных технологиях, продуктах и решениях и опыте развития цифровой экономики и цифровой трансформации предприятий и организаций всех масштабов и отраслей. Издание рассказывает о важнейших событиях отечественного и мирового рынка ИКТ и анализирует тенденции развития ИКТ-индустрии. https://www.itweek.ru/images/itweek/logo-100x40.gif https://www.itweek.ru https://www.itweek.ru/themes/detail.php?ID=235741 Thu, 15 Oct 2026 15:44:23 +0300 <p>Институт статистических исследований и экономики знаний (ИСИЭЗ) НИУ ВШЭ продолжает изучать практики применения ИИ в ключевых отраслях промышленности и связанные с этим эффекты, в частности для кадровой политики. Как показал анализ, в химической промышленности ключевую роль играет безопасность: ИИ применяют чаще всего на отдельных участках производства в рамках четких ограничений, а системно развивают кадровый потенциал в области ИИ лишь немногие предприятия.</p> <p>Наиболее востребованы на предприятиях химпрома ИИ-решения для обработки визуальных данных и текста (их используют 10,7% и 10,5% обследованных организаций соответственно). Заметно реже применяют передовые решения, к которым относятся большие языковые / генеративные модели (6%) и ИИ-агенты (1,6%). Среди организаций, планирующих внедрение ИИ или считающих его перспективным, наибольший потенциал видят в приложениях для интеллектуальной поддержки принятия решений и управления (32,7%).</p> <p>В химической промышленности ИИ применяют главным образом для моделирования продукции и процессов (более 40% организаций, использующих ИИ) и управления оборудованием <nobr>(28–33%).</nobr> В отраслевом разрезе общий профиль применения сходен, но есть и некоторые отличия: промышленная безопасность входит в число наиболее распространенных задач применения ИИ производителей химических веществ и продуктов (28,2%), а логистика и хранение — производителей резиновых и пластмассовых изделий (27,9%). Среди потенциальных областей применения ИИ чаще всего называют диагностику оборудования и предупреждение поломок (58,2 %). Эти задачи относятся к предиктивной аналитике — одному из наиболее быстрорастущих направлений мировой химической промышленности.</p> <p>К моменту проведения обследования эффекты от применения ИИ получили почти четверть предприятий химпрома, использующих технологию. Из основных результатов — улучшение качества и потребительских характеристик продукции, включая возможность адаптировать ее с учетом географии поставок, запросов потребителей, регуляторных норм и других требований. Каждое пятое предприятие-пользователь отметило снижение потребления ресурсов, в том числе энергетических. В ближайшие годы более двух третей предприятий рассчитывают с помощью ИИ сократить брак и число поломок, снизить аварийность и повысить производительность оборудования.</p> <p>К наиболее быстро проявляющимся кадровым эффектам от внедрения ИИ в химической промышленности относятся экономия времени работников и автоматизация рутинных задач: их отметили около четверти обследованных организаций-пользователей ИИ. Усиления этих эффектов в среднесрочной перспективе ожидают три из пяти предприятий, начавших внедрение ИИ. Предприятий, прогнозирующих рост численности персонала под влиянием ИИ, вдвое больше ожидающих сокращения штатов. Крупные организации реже других видят в ИИ угрозу занятости, в отраслевом разрезе такую оценку реже всего дают производители лекарственных средств и материалов, применяемых в медицинских целях и ветеринарии. Наиболее благоприятная ситуация на рынке труда химической промышленности, ожидаемо, складывается для специалистов по ИКТ и занятых непосредственно в производстве и разработке продукции. Наиболее пессимистично организации оценивают перспективы служащих, занятых подготовкой и оформлением документации, учетом и обслуживанием.</p> <p>У трети предприятий химпрома, использующих ИИ, есть собственные разработчики ИИ-приложений и аналитики ПО. Однако численность таких специалистов, как правило, недостаточна. Политику по развитию кадрового потенциала в области ИИ проводит лишь небольшая часть компаний химпрома. Только каждая пятая поощряет использование ИИ на рабочем месте. Еще более редкая практика — взаимодействие с образовательными учреждениями, готовящими специалистов с навыками работы с ИИ.</p> <p>Для предприятий химической промышленности важна не только ожидаемая отдача от ИИ, но и возможность безопасно встроить его в сложные и зачастую опасные производственные процессы. Почти две трети организаций, уже использующих ИИ, считают безопасность ИИ-систем критически важным условием расширения их применения. Она предполагает, в частности, стабильность работы систем и их устойчивость к внешним воздействиям. В общей выборке обследованных организаций химпрома почти четверть отмечают среди условий внедрения появление инструментов обеспечения безопасности ИИ-систем и оценки их соответствия установленным требованиям (например, сертификацию решений); около трети — повышение рентабельности основной деятельности.</p> Институт статистических исследований и экономики знаний (ИСИЭЗ) НИУ ВШЭ продолжает изучать практики применения ИИ … message https://www.itweek.ru/themes/detail.php?ID=235740 Thu, 15 Oct 2026 15:40:33 +0300 <p>Cloud.ru, провайдер облачных сервисов и ИИ-технологий, представил RepoWiki — новую функцию в составе сервиса Evolution Repo, которая автоматически анализирует кодовую базу и формирует структурированную документацию проекта.</p> <p>Evolution Repo — облачный сервис для хранения репозиториев кода, <nobr>ML-моделей</nobr> и датасетов. Сервис хранит модели и датасеты в одном хранилище и помогает управлять большими файлами через Git LFS, версионировать <nobr>ML-модели</nobr> и просматривать файлы-тензоры. Синхронизация и обмен артефактами работает через API, совместимое с популярной библиотекой моделей Hugging Face.</p> <p>RepoWiki встроен непосредственно в облачный репозиторий. Разработчикам больше не нужно переносить код в сторонний ИИ-сервис: репозиторий, документация и работа с кодовой базой теперь собраны в едином пространстве. Сервис работает на базе Evolution ManagedRAG и AI Agents. Перед генерацией самой документации пользователю на согласование отправляется предварительный список разделов и страниц, который можно редактировать. </p> <p>Обычно, приступая к новой задаче, разработчику или ИИ-агенту необходимо погрузиться в контекст: понять, что делает проект, как устроена архитектура, где находится нужный код. Если проект не подготовлен заранее, возникают ограничения: агент видит отдельные файлы, но не понимает их роль в системе, не осознает неявные зависимости, а контекстное окно не позволяет охватить кодовую базу целиком.</p> <p>RepoWiki устраняет эти ограничения: система самостоятельно анализирует структуру проекта, выявляет взаимосвязи между модулями и генерирует документацию, которая отражает реальное устройство кодовой базы. При использовании RepoWiki ручная работа с документацией сокращается в среднем на 30% (по результатам тестов на реальных проектах).</p> <p>С технической точки зрения, RepoWiki использует мультиагентный подход к созданию документации. Внутри системы анализ кода разбивается на последовательные этапы: планирование, анализ архитектуры, написание и верификация содержимого. Это помогает обрабатывать проекты масштаба крупных корпоративных репозиториев, где единовременный анализ всей кодовой базы невозможен из-за ограничений контекстного окна. Решение поддерживает инкрементные обновления: при изменении кода документация обновляется, а не создается заново.</p> <p>Функция поможет разработчикам, изучающим незнакомые модули или подключающимся к существующим проектам: RepoWiki сокращает время входа в контекст и рабочую нагрузку. Техническим лидерам и руководителям, организующим передачу знаний функция поможет для управления знаниями, снижения риски ухода ключевых сотрудников и ускорения адаптации команды.</p> <p>«С RepoWiki вместо того, чтобы вручную описывать модули, поддерживать актуальность файлов и собирать знания по крупицам из комментариев и переписок, ИТ-команда получает автоматически сгенерированное описание проекта. Разработчик может задавать вопросы по кодовой базе в чате вместо изучения десятков разрозненных файлов. Это особенно ценно при работе с незнакомыми модулями, при подключении к существующим проектам и при разборе legacy-кода, где документация либо отсутствует, либо давно устарела», — сказала директор блока разработки платформы Cloud.ru Evolution Анастасия Тафеенко.</p> Cloud.ru, провайдер облачных сервисов и ИИ-технологий, представил RepoWiki — новую функцию в составе сервиса … message https://www.itweek.ru/themes/detail.php?ID=235739 Thu, 15 Oct 2026 10:40:24 +0300 <p><em>На октябрьской конференции Open Source Summit Europe 2026 в Праге неоднократно звучал один и тот же тезис: организации и правительства, которые просто используют </em><em>Open</em> <em>Source</em><em>, остаются зависимыми от других в формировании своего будущего. Те, кто управляет, поддерживает, обеспечивает безопасность и развивает экосистемы </em><em>Open</em> <em>Source</em><em>, получают влияние, устойчивость, суверенитет и стратегическое преимущество. Дискуссия о суверенитете развивается как внутри, так и за пределами сообщества </em><em>Open</em> <em>Source</em><em>: вопрос не в том, как защитить себя от внешней зависимости, а в том, как стать незаменимым участником экосистем, от которых зависит цифровое будущее, пишет в корпоративном блоге Дарио Маисто, главный аналитик </em><em>Forrester</em><em>.</em></p> <h3>Open Source стал критически важной инфраструктурой</h3> <p>Open Source больше не является просто моделью разработки. Он лежит в основе облачных платформ, систем искусственного интеллекта, инструментов кибербезопасности и цифровых государственных услуг. Тем не менее, многие проекты, поддерживающие цифровую экономику, по-прежнему зависят от небольших групп разработчиков, которые сталкиваются с растущим давлением со стороны угроз кибербезопасности, управления уязвимостями, необходимости соответствия нормативным требованиям и ожиданий сообщества.</p> <p>Одной из повторяющихся проблем, отмеченных на саммите, была устойчивость работы сопровождающих проектов (мейнтейнеров). Нагрузка на безопасность продолжает расти, в то время как многим проектам не хватает достаточной поддержки. Документация стала важной проблемой. Мейнтейнеры неоднократно отмечали, что улучшенная документация снижает трудозатраты, повышает уровень внедрения проектов и позволяет сосредоточить ограниченные ресурсы на более ценной работе.</p> <p>Если Open Source является критически важной инфраструктурой, его поддержка должна стать общей ответственностью, а не бременем нескольких добровольцев.</p> <h3>Суверенитет требует участия, а не изоляции</h3> <p>Саммит подтвердил тезис, который Forrester распространяет уже довольно давно: суверенитет не достигается изоляцией. Сильные нации и организации не уходят из экосистем. Они вносят в них свой вклад, формируют их и помогают управлять ими. Другими словами, влияние имеет такое же значение, как и контроль.</p> <p>Одна из наиболее убедительных концепций, представленных на саммите, описывает четыре составляющих суверенитета:</p> <ol> <li><strong>целостность:</strong> защита данных и обеспечение доверия;</li> <li><strong>устойчивость:</strong> сокращение уязвимостей и укрепление операций;</li> <li><strong>непрерывность:</strong> поддержание контроля над инфраструктурой и цепочками поставок;</li> <li><strong>взаимозависимость:</strong> укрепление внутренних сильных сторон при участии в глобальных экосистемах в качестве равноправного партнера.</li> </ol> <p>Основные выводы о суверенитете и Open Source:</p> <ul> <li><strong> Вклад без управления создает разрыв.</strong> Вот статистика, которая нашла отклик на протяжении всего мероприятия: Европа вносит примерно 40% вклада в деятельность Open Source-проектов, оставаясь при этом недостаточно представленной в структурах управления и лидерства. Это расхождение имеет значение. Вклад в код ценен, но управление определяет направление проекта, приоритеты финансирования, инвестиции в безопасность и долгосрочные планы развития.</li> <li><strong> Активное участие обеспечивает умножение отдачи.</strong> Организации, стремящиеся к большему цифровому суверенитету, должны измерять не только то, сколько открытого исходного кода они потребляют или в который вносят вклад, но и то, участвуют ли они в фондах, руководящих комитетах, программах поддержки и инициативах по лидерству в экосистеме. Активное участие обеспечивает умножение отдачи. Оно создает влияние, которое выходит за рамки строк кода и становится источником рычага воздействия.</li> <li><strong> Поддержка апстрима создает бóльшую ценность, чем поддержка частных форков.</strong> Докладчики неоднократно подчеркивали, что организации не могут пассивно обеспечивать безопасность цепочек поставок ПО. Внесение исправлений, финансирование разработчиков, улучшение документации и участие в управлении укрепляют экосистему для всех. В отличие от этого, поддержка изолированных частных форков может быть дорогостоящей: по оценкам одного из докладчиков, поддержание частного форка может стоить до 250 тыс. евро.</li> <li> <strong>Open</strong> <strong>Source</strong> <strong>не устраняет зависимость автоматически.</strong> Open Source-лицензия может обеспечить прозрачность и переносимость, но она не устраняет зависимость автоматически. Проекты, в которых доминирует один поставщик, по-прежнему могут создавать риск концентрации из-за контроля со стороны управления, влияния на дорожную карту или доминирования в экосистеме. Поэтому технологические лидеры должны оценивать не только лицензии, но и разнообразие участников, модели управления, надзор со стороны фондов и долгосрочную устойчивость.</li> <li> <strong>Open</strong> <strong>Source</strong> <strong>— это стратегическая зависимость, которой необходимо активно управлять.</strong> Цифровой суверенитет теперь является приоритетом на уровне совета директоров, в то время как Open Source-компоненты интегрированы во все современные технологические стеки. Организациям необходима прозрачность в отношении ПО, от которого они зависят, сообществ, которые его поддерживают, и рисков, связанных с критически важными зависимостями.</li> </ul> <h3>Будущее суверенитета в сфере Open Source — за влиянием на экосистему</h3> <p>Появление крупных альянсов в области ИИ, инициатив под эгидой профильных фондов и технологий, ориентированных на работу с ИИ-агентами, указывает на то, что в эпоху ИИ активное участие станет еще более важным. Организации, участвующие в создании, управлении и развитии этих экосистем, получат больше возможностей влиять на стандарты, инновации и вектор развития рынка. Главный вывод конференции Open Source Summit Europe 2026 прост: цифровой суверенитет для Open Source-сообщества определяется тем, что его участники помогают формировать, а не только тем, что они способны контролировать. Будущее принадлежит не тем, кто просто использует Open Source, а тем, кто активно способствует его успеху.</p> На октябрьской конференции Open Source Summit Europe 2026 в Праге неоднократно звучал один и тот же тезис … article https://www.itweek.ru/themes/detail.php?ID=235735 Thu, 15 Oct 2026 10:28:38 +0300 <p><em>С осени 2025 года у Apache Flink есть подпроект Flink Agents, который встраивает нейросети прямо в потоковую обработку данных. Что это меняет и сможет ли нейросеть заменить дежурного инженера?</em></p> <h3>Проблема, которую все знают, но терпят</h3> <p>Типичная ситуация: ночью срабатывает алерт — дежурный инженер должен устранить неполадки. Чтобы добраться до проблемы, ему нужно проснуться, войти во внутреннюю сеть компании, открыть графики и логи, понять, какое приложение сломалось и почему. На это уходит много времени.</p> <p>Решение при этом чаще всего простое: перезапустить приложение, выделить ему больше ресурсов или откатить на предыдущую версию. Почти всё время тратится на подход к исправлению, а не на само решение. На проблему, которую можно было решить за секунды, тратятся десятки минут, иногда дольше.</p> <p>Системы усложняются с каждым годом, связей между приложениями становится больше, и сбой в одном месте всё чаще тянет за собой проблемы в другом. Индустрия вкладывает много сил в отказоустойчивость: системы дублируют и разносят по разным площадкам. А вот реакция на аварию почти не изменилась: дежурный по-прежнему смотрит на проблему своими глазами, разбирается и действует. В такой ситуации он становится «узким местом». Аварии случаются под нагрузкой, когда каждая минута простоя стоит дороже всего. После такой ночи инженер не высыпается и на следующий день работает хуже, поэтому одна авария обходится компании дважды.</p> <h3>Инструкции устаревают быстрее, чем их пишут</h3> <p>Чаще всего дежурному помогают плейбуки. Идея понятная: записать опыт один раз, чтобы им воспользовался любой инженер. Однако плейбук устаревает почти сразу: системы меняются каждую неделю, а инструкции в лучшем случае правят раз в год. Несколькими плейбуками современную систему не покрыть: нужна целая энциклопедия, которую никто не успевает поддерживать.</p> <p>Я не помню, когда последний раз вообще видел плейбуки, но точно знаю: системы, для которых их писали, были гораздо проще и менялись гораздо реже, чем нынешние. На вопрос «А где же ваши плейбуки?» сегодня нередко можно услышать, что их либо нет, либо те, что есть, безнадёжно устарели.</p> <p>Логичный следующий шаг — прикладывать к каждому алерту пояснение, что он означает и что делать. Но на практике этот подход быстро упирается в противоречие:</p> <ul> <li><strong> Узкие алерты</strong> привязаны к конкретной причине. Представим кластер Flink, на котором работают десятки джоб. Каждая может упасть по-своему: ошибка в пользовательском коде, некорректное сообщение в Kafka, потеря соединения с базой данных, нехватка ресурсов, сбой Kubernetes, ошибка JVM. Под каждую причину легко написать инструкцию, но такие ошибки часто приходят группой, и одна проблема — джоба перестала обрабатывать данные — превращается в пять алертов. Внимание дежурного размазывается, и главное теряется в шуме.</li> <li><strong> Общие алерты</strong> описывают симптом, а не причину, например «джоба не обрабатывает данные». На одну проблему приходит один алерт, и дежурный сразу видит, что сломалось. Но к такому алерту уже не напишешь инструкцию: у симптома может быть десяток причин.</li> </ul> <p>Поэтому многие команды в итоге переходят на общие алерты: внимание дежурного не размазывается, а одна проблема — это один сигнал. От формальных инструкций при этом приходится отказаться, и новых дежурных учат через наставничество. Решение неидеальное, но на практике оно работает лучше остальных. Но главная беда никуда не девается: чтобы понять, что случилось, по-прежнему нужно много времени.</p> <h3>Что изменилось</h3> <p>Данных для разбора аварии у инженеров обычно достаточно. Логи приложений стекаются в единую систему передачи сообщений, например Kafka. К ней подключают потоковый обработчик — джобу на Apache Flink, которая читает логи в реальном времени.</p> <p>Раньше такой обработчик выполнял только заранее прописанные реакции: например, если за минуту пришло больше ста ошибок нехватки памяти, перезапусти приложение. Это тот же плейбук, только в коде. Он быстрее бумажного, потому что убирает человека из цепочки, но устаревает так же: система меняется, а правила остаются.</p> <p>Теперь в тот же поток можно встроить языковую модель и дать ей инструменты через MCP (Model Context Protocol) — стандартный протокол, через который модель обращается к внешним системам. Модель понимает текст ошибки, сама запрашивает метрики, историю релизов, состояние приложения в Kubernetes и по ним предлагает, что делать. В этом и состоит сильная сторона нейросетей: они быстро собирают разнородные данные в одну картину.</p> <p>Время реакции сокращается с десятков минут примерно до минуты. Большую часть этого времени занимает накопление событий перед отправкой в модель. Ответ модели и пара обращений к инструментам занимают секунды.</p> <h3>Как это устроено</h3> <p>Разберём на примере <a href="https://flink.apache.org/2026/06/19/apache-flink-agents-0.3.0-release-announcement/">Apache Flink Agents</a> — подпроекта Flink, в котором агент становится обычным шагом потоковой обработки.</p> <p>Если упростить, конвейер состоит из трёх ступеней:</p> <p> #IMAGE_235737#</p> <p><strong>1. Дешёвый предфильтр без модели.</strong> Предфильтр группирует логи из Kafka по приложению и накапливает их в окне на <nobr>30-60 секунд.</nobr> Он сворачивает одинаковые ошибки в одну, считает их частоту, сохраняет начало и конец сообщения об ошибке. В модель уходит одно «происшествие» на приложение вместо тысячи строк лога. Это главный способ сэкономить деньги и время: модель не видит шум, который обычный код отсекает.</p> <p><strong>2. Агент.</strong> Агент состоит из событий и действий. Событие — сигнал, что что-то произошло, например пришло новое происшествие. Действие — небольшой фрагмент логики, который запускается на определённое событие и порождает новое. Для типовых шагов есть готовые события: вход, запрос к модели, ответ модели и выход. Если модели нужны инструменты, фреймворк сам вызывает их и возвращает результат, пока у модели не будет готового ответа.</p> <p>Разработчик описывает всё, чем агент пользуется, отдельно от логики, как набор ресурсов: какая модель, какой промпт, какие инструменты, какие MCP-серверы. Ресурсы выносят в конфигурационный файл и, например, меняют поставщика модели, не трогая код.</p> <p>Фреймворк поддерживает два стиля: workflow-агент, где маршрут задаёт разработчик, и ReAct-агент, где модель сама решает, какой инструмент вызвать следующим. Для аварий удобнее первый: каркас жёсткий, а свободу выбирать инструменты модель получает только на шаге диагностики.</p> <p>Здесь важны три вещи.</p> <ul> <li><strong> Модель сама ничего не меняет.</strong> Ей доступны только инструменты на чтение. Исправление выполняет наш собственный код, и только если предложенное действие есть в белом списке, а лимит не исчерпан. Модель советует, код действует.</li> <li><strong> Ответ модели — в строгом формате.</strong> Модель возвращает заранее описанную структуру: что случилось и какое действие она предлагает. Всё, что код не смог разобрать, автоматически уходит человеку.</li> <li><strong> Действие не выполнится дважды.</strong> Flink Agents запоминает результат действия во внешнем хранилище (Kafka или Apache Fluss), поэтому, если джоба упадёт и восстановится, повторного перезапуска не будет. Для самого неприятного случая, когда перезапуск уже выполнен, а записать результат система не успела, можно задать отдельную проверку: при восстановлении фреймворк сначала спросит у Kubernetes, в каком состоянии приложение.</li> </ul> <p><strong>3. Выход.</strong> Агент отправляет результат в отдельный топик Kafka, а оттуда он попадает в систему оповещений и в тикет. Если агент справился сам, в журнале появляется запись. Если нет, дежурный получает алерт с приложенными метриками, последними релизами и гипотезой модели о том, что случилось.</p> <h3>Где граница доверия?</h3> <p>У этого подхода есть обратная сторона: доверие к нейросети. Очевидный ответ такой: машине отдаём только то, что безопасно и легко откатить, всё остальное она готовит, а решает человек. Нейросеть заменяет рутину инженера. Самого инженера она заменить не может. Границу удобно описать таблицей прав (цифры приведены для примера):</p> <table> <tbody> <tr> <th>Действие</th> <th>Кто выполняет</th> <th>Ограничения</th> </tr> <tr> <td> Сбор данных: метрики, логи, релизы, состояние в Kubernetes</td> <td> Агент сам</td> <td> Только MCP-сервер на чтение, отдельная служебная учётная запись</td> </tr> <tr> <td> Перезапуск приложения</td> <td> Агент сам</td> <td> Не чаще 2 раз в час на приложение; не помогло — зовём человека</td> </tr> <tr> <td> Масштабирование</td> <td> Агент сам</td> <td> В пределах квоты, например не больше чем +50% копий приложения</td> </tr> <tr> <td> Откат релиза</td> <td> Агент в узких рамках, иначе человек</td> <td> Только на предыдущую версию и только для свежего релиза</td> </tr> <tr> <td> Конфигурация, базы данных, сеть, удаление ресурсов</td> <td> Только человек</td> <td> Агент прикладывает собранные данные и предложение</td> </tr> </tbody> </table> <p>Чтобы эта схема работала, нужно несколько вещей.</p> <ul> <li><strong>Права ограничиваются в инфраструктуре.</strong> Flink Agents автоматически подтягивает все инструменты подключённого MCP-сервера. Список в настройках определяет, какие из них увидит модель, но это одна строчка, в которой легко ошибиться. Надёжнее, когда опасных операций на сервере нет вообще, а служебная учётная запись имеет права только на чтение.</li> <li><strong>Лимиты против зацикливания.</strong> Если перезапуск не помог, второй и третий, скорее всего, тоже не помогут, зато замаскируют настоящую проблему. Поэтому поток хранит счётчик действий по каждому приложению в своём состоянии, и при превышении лимита агент обязан позвать человека.</li> <li><strong>Маленькие модели.</strong> Если отправлять каждое событие в самую мощную модель, мы либо разоримся, либо будем подолгу ждать ответа. Поэтому здесь обычно работают небольшие модели: большой контекст им не нужен, но и доверить им можно далеко не всё.</li> <li><strong>Уверенность модели не равна вероятности.</strong> Если попросить обычную языковую модель оценить свою уверенность, она вернёт число, которое, по сути, сама и придумала. Поэтому решение «чинить самому или звать человека» стоит строить на белом списке и лимитах, а не на такой оценке. Здесь интересен новый класс моделей, которые не пишут текст, а выбирают из заданных вариантов. Пример — <a href="https://www.llmreference.com/model/jev/typesafe-ai">Jev от TypeSafe AI</a>, вышедшая 15 сентября 2026 года. Ей передают собранные данные и варианты вроде «перезапустить», «добавить ресурсов», «позвать человека», а она возвращает выбор с вероятностью, которую разработчик называет калиброванной, причём, <a href="https://thursdai.news/companies/typesafe-ai">по его данным</a>, за <nobr>70-500 мс.</nobr> Сама за данными Jev не ходит, так что собирает их по-прежнему языковая модель с инструментами, а Jev достаётся только выбор действия. Ограничения: не больше 255 вариантов и <a href="https://www.trendingtopics.eu/jev-warum-dieses-neuartige-ki-modell-gerade-entwickerinnen-begeistert/">никакого текстового объяснения</a>. Сейчас готовой интеграции в выпущенных версиях Flink Agents нет, а цифры скорости и калибровки пока в основном от самого разработчика, но сама концепция многообещающая.</li> <li><strong>Теневой режим.</strong> Начинать стоит с режима, в котором агент предлагает, а действует человек. Пару недель мы сравниваем решения агента с решениями дежурных и только потом включаем автоматику по одному типу действий, начиная с самого безопасного.</li> </ul> <p>Главное правило: никаких неограниченных прав. Иначе однажды мы проснёмся и узнаем, что нейросеть сочла проблемой всю нашу систему и аккуратно её устранила. Это шутка, но с долей правды: агент может ровно то, что ему разрешили.</p> <h3>Плейбук, который пишет себя сам</h3> <p>Вернёмся к ночи из начала. В логах одного из сервисов начинают сыпаться ошибки. Предфильтр сворачивает их в одно происшествие. Агент запрашивает метрики, видит, что потребление памяти дошло до лимита, а новых релизов за сутки не было, и предлагает перезапуск. Перезапуск есть в белом списке, лимит не исчерпан, поэтому код выполняет его сам. С первой ошибки проходит около минуты, и дежурный даже не просыпается.</p> <p>Утром инженер видит отметку «авария устранена» и полный след решения: что пришло на вход, какие инструменты вызвал агент и что они вернули, почему он выбрал перезапуск. Flink Agents пишет каждое событие, включая обращения к модели и инструментам, в журнал, который с версии 0.3 по умолчанию виден в веб-интерфейсе Flink. Длинные записи в нём по умолчанию сокращаются, поэтому для полного следа нужен подробный режим.</p> <p>Это плейбук нового типа. Инструкция выполняется в момент проблемы и смотрит на систему в реальном времени, а документ поддерживать не нужно.</p> <p>Поддерживать что-то всё-таки придётся: короткий список разрешённых действий, лимиты и промпт. Энциклопедия на сотни страниц не нужна. Такой список легко проверять на ревью, хранить в git и прогонять на записанных прошлых инцидентах.</p> <h3>Сколько подъёмов на самом деле требовали человека?</h3> <p>Нейросети уже забрали у инженеров много шума — работы, которая требует много сил, но даёт мало результата: тесты, документацию, мелкие исправления. Дежурство — тоже шум, только дорогой. Каждая такая ночь стоит компании денег, а инженеру — сил.</p> <p>Проверить, сколько такого шума, просто. Откроем историю инцидентов за последний квартал и посчитаем, сколько из них закончились перезапуском, масштабированием или откатом. Это и есть доля ночей, в которых человек был нужен только для того, чтобы нажать кнопку.</p> <p>Речь не о том, чтобы убрать дежурного, а о том, чтобы изменить его работу. Базовые случаи может закрывать сама система, а человеку остаётся то, что действительно требует опыта, и проектирование системы, которая реагирует сама. Это интереснее, чем вставать в три часа ночи ради одной команды.</p> <p> #IMAGE_235736#</p> С осени 2025 года у Apache Flink есть подпроект Flink Agents, который встраивает нейросети прямо в потоковую … article Алексей Перминов, технический лидер в Exness https://www.itweek.ru/themes/detail.php?ID=235734 Wed, 14 Oct 2026 16:18:42 +0300 <p>Автономная некоммерческая организация «Национальный центр компетенций по информационным системам управления холдингом» (АНО «НЦК ИСУ») проанализировала практики крупнейших российских корпораций и выявила ключевой тренд в области применения генеративного искусственного интеллекта в ИТ-разработке. Им стал переход от «вайб-кодинга» (vibe-coding) как индивидуального инструмента сотрудника к созданию корпоративных агентских платформ, которые снизят стоимость разработки в 10 раз в перспективе нескольких лет, и мультиагентных команд. Тренды применения ИИ в корпоративной ИТ-разработке были представлены на сессии «Эффекты применения ИИ в системах управления ресурсами: метрики, кейсы, масштабирование», которую организовала «НЦК ИСУ» в рамках форума «Цифровые решения».</p> <p>По мнению корпоративных заказчиков, стратегия простого предоставления сотрудникам доступа к <nobr>LLM-инструментам</nobr> не дает ожидаемого эффекта в промышленных масштабах: выдача сотен доступов приводит лишь к росту затрат без значимого прироста эффективности. В отраслевой практике происходит разграничение: «вайб-кодинг» позиционируется как инструмент непрофессиональной разработки, тогда как «агентская разработка» становится дисциплиной для профессиональных команд, в которой ИИ-агенты выполняют исполнительские функции, а человек отвечает за архитектуру и постановку задач.</p> <p>Ключевым сдвигом становится использование агентных платформ корпоративного уровня во внутреннем контуре, позволяющих автономно охватить весь процесс разработки — от постановки задачи до поддержки готового решения. Такой подход демонстрирует потенциал существенного снижения себестоимости доработки корпоративных информационных систем. Если ранее на это требовались месяцы, сотни миллионов рублей и большие ИТ-команды, то сегодня развивать системы можно за недели и силами двух-трех высокоуровневых ИТ-специалистов и <nobr>25–30 ИИ-агентов.</nobr> Целевой ориентир корпораций — снижение себестоимости разработки ИТ-решений от 2 до 10 раз к 2030 году.</p> <p>Меняется и операционная модель ИТ-разработки. На смену традиционным ролям разработчика, аналитика, архитектора и тестировщика приходит фигура «соло-инженера» — специалиста, который проектирует систему, формулирует техническое задание и проверяет качество сгенерированного кода. К концу десятилетия классические роли в разработке могут исчезнуть, а весь ландшафт корпоративных систем будет переведен на агентские платформы вплоть до полного отказа от написания кода вручную.</p> <p>Трансформация затрагивает не только ИТ-подразделения, но и бизнес. Бизнес-заказчики получают возможность самостоятельно создавать работающие прототипы с помощью «вайб-кодинга» и приходить в ИТ-команду не просто с техническим заданием, а с полуготовым решением. Это меняет культуру взаимодействия: сотрудников учат «нанимать» цифровых сотрудников, ставить им задачи, контролировать их и объединять в сквозные процессы. Ожидаемый эффект — автоматизация непроизводственных функций с помощью ИИ-агентов с потенциалом роста производительности труда от 15% до 70% в зависимости от функции.</p> <p>Однако не все участники рынка видят мгновенный бизнес-эффект. На масштабе крупной компании значимого прироста в time-to-market пока нет. Главное достижение — резкое снижение стоимости экспериментов, что позволяет многократно тестировать гипотезы. Стоимость токенов становится значимой статьей бюджета. Кроме того, остаются барьеры в виде регуляторики и сертификации, а также сложности с переписыванием legacy-систем.</p> <p>«Корпоративная ИТ-разработка сегодня требует наличия платформы, которая позволяет автоматизировать с помощью ИИ-агентов весь процесс. Несколько инженеров, управляющие агентами, уже переписывают системы, на которые раньше уходили годы и сотни миллионов рублей. При этом ключевым становится не код, а инженерная экспертиза. Мы видим рождение новой роли инженера, управляющего мультиагентной командой. Через несколько лет такие специалисты полностью изменят ландшафт корпоративной разработки», — отметила заместитель генерального директора АНО «НЦК ИСУ» Екатерина Хитрова.</p> Автономная некоммерческая организация «Национальный центр компетенций по информационным системам управления холдингом» (АНО … message https://www.itweek.ru/themes/detail.php?ID=235732 Wed, 14 Oct 2026 10:06:37 +0300 <p><em>Примерно шесть из десяти организаций заявляют, что их стратегия в области искусственного интеллекта трансформирует бизнес, однако исследование IDC «</em><em>MaturityScape</em> <em>Benchmark</em><em>: </em><em>AI</em><em>-</em><em>Fueled</em> <em>Organization</em> <em>Worldwide</em><em>, 2026» показывает, что лишь 15,1% из них обладают соответствующими возможностями. Райан Смит, директор по контент-маркетингу IDC, рассказывает в корпоративном блоге, как компания измеряла этот разрыв, и предлагает четыре вопроса для проверки вашей организации перед тем, как сделать следующий шаг по шкале зрелости внедрения ИИ.</em></p> <p>Исследование IDC было направлено на то, чтобы выяснить, соответствуют ли реальные возможности заявлениям организаций; оказалось, что у примерно пяти из шести организаций такого соответствия пока нет.</p> <h3> Как IDC оценивала зрелость внедрения ИИ </h3> <p>Опрос, проведенный в мае 2026 г., охватил 1900 организаций на 20 рынках и включал вопросы двух типов.</p> <p>Первый тип — это самооценка организацией своего подхода к ИИ; на основе этих данных IDC разделила респондентов на две группы:</p> <ul> <li> «Выживающие» (Survivors): находящиеся в ситуации, когда либо отсутствует общекорпоративная стратегия ИИ (проекты ведутся разрозненными командами), либо стратегия ограничена лишь отдельными функциями или сферами бизнеса. Их описания соответствуют первым трем стадиям зрелости.</li> <li> «Преуспевающие» (Thrivers): имеют общекорпоративную стратегию, которая либо внедряет ИИ во все сферы бизнеса для трансформации операционной модели, либо развивает сценарии использования ИИ для переосмысления продуктов и услуг. Их описания соответствуют двум высшим стадиям зрелости.</li> </ul> <p>Второй тип — это детальные вопросы о возможностях организации в четырех аспектах: стратегия, управление, персонал и технологии. IDC оценила ответы, чтобы определить, на какой из пяти стадий зрелости находится каждая организация.</p> <p>Сравнение результатов по этим двум типам вопросов показывает, насколько заявления руководителей соответствуют реальным возможностям их организаций.</p> <h3>Каковы пять стадий зрелости внедрения ИИ</h3> <p>Стадии варьируются от «ситуативного подхода» (Ad hoc) до «оптимизации» (Optimized); высшую стадию IDC называет «организацией, работающей на основе ИИ» (AI-fueled organization).</p> <ul> <li> Ситуативность (Ad hoc): разрозненные пилотные проекты, отсутствие общекорпоративной стратегии или централизованного руководителя направления ИИ.</li> <li> Фрагментированность (Opportunistic): неформальная группа кураторов формирует стратегию вокруг нескольких сценариев использования, обещающих высокую отдачу.</li> <li> Воспроизводимость (Repeatable): центр компетенций с назначенным руководителем по ИИ разрабатывает дорожную карту для всей организации, а процессы управления формализуются.</li> <li> Управляемость (Managed): ИИ трансформирует операционную модель; появляются новые продукты и источники дохода, основанные на технологиях ИИ.</li> <li> Оптимизированность (Optimized): широкое распространение получают автономные агенты, а контроль и управление осуществляются в режиме реального времени.</li> </ul> <h3>На каком этапе модели зрелости ИИ находится большинство организаций</h3> <p>Половина организаций находится на этапе использования возможностей, а 61,3% — на двух начальных этапах с наименьшей зрелостью. Лишь 12,8% достигли двух наиболее зрелых этапов: 3,1% находятся на этапе оптимизации, а 9,7% — на этапе управляемости.</p> <p>За средним показателем скрывается неоднородность ситуации. Среднемировой показатель вырос с 2,39 до 2,43, при этом доля организаций на этапе оптимизации увеличилась с 0,4 до 3,1% — почти в восемь раз. IDC расценивает это как признак того, что группа лидеров начинает отрываться от основной массы, в то время как «широкая середина» движется вперед медленно.</p> <p>Что происходит при сопоставлении самооценки с результатами анализа</p> <p>Из 1149 организаций, отнесших себя к категории «процветающих» — что составляет около 60% выборки, — лишь 15,1% по результатам оценки попали на этапы управляемости или оптимизированности. По оценке IDC, это означает, что примерно пять из шести таких компаний по-прежнему действуют как «выживающие»: остальные 84,9% оказались на этапах ситуативности, фрагментированности или воспроизводимости.</p> <p>Тем не менее, самооценка не лишена смысла. Вероятность достижения двух высших этапов зрелости у «процветающих» примерно в 1,5 раза выше, чем у «выживающих»; IDC связывает это с наличием скоординированной корпоративной стратегии. Впрочем, абсолютные показатели в обеих группах невелики, а уверенность в себе и реальные возможности коррелируют слабо: 10,1% «выживающих» все же достигают двух высших этапов.</p> <h3>Почему амбиции в сфере ИИ опережают реальные возможности</h3> <p>Согласно анализу IDC, стратегию проще всего декларировать, но сложнее всего реализовать в масштабах всей организации. Разрыв между желаемым и действительным проявляется в тех аспектах, которые труднее всего переоценить или приукрасить. IDC выделяет следующие проблемы:</p> <ul> <li> отсутствие формализованных механизмов управления, которые можно было бы реально применять на практике;</li> <li> недостаточно надежные фундаменты данных и платформ, не способные обеспечить работу в промышленных масштабах;</li> <li> персонал, не прошедший необходимую переподготовку и адаптацию к изменениям.</li> </ul> <p>В результате организация может позиционировать себя «работающей на основе ИИ», но на деле ее деятельность все еще соответствует лишь стадии фрагментированности.</p> <p>Оценки по отдельным направлениям подтверждают эту картину. Технологический аспект характеризуется наименьшей зрелостью: 66,5% организаций находятся на двух начальных стадиях развития в этой сфере. Зрелость персонала чаще всего соответствует стадии фрагментированности (51,2%). Наибольший прогресс наблюдается в сфере управления — именно здесь наиболее «процветающие» вырываются вперед: 20,1% из них достигают двух высших стадий зрелости управления, тогда как среди «выживающих» этот показатель составляет 12,2%. Тем не менее, 57,2% всех организаций по-прежнему остаются на двух начальных стадиях развития в области ИИ.</p> <p>Андреа Сивьеро, вице-президент IDC по стратегиям развития бизнеса на базе ИИ, характеризует эту ситуацию как разрыв, при котором стратегия опережает практическую реализацию, а главным препятствием становится нехватка квалифицированных кадров.</p> <h3>Как продвигаться по модели зрелости в сфере ИИ</h3> <p>Начните с оценки своей организации по четырем ключевым направлениям:</p> <ul> <li> Кто на уровне совета директоров отвечает за ИИ и как часто предоставляются отчеты?</li> <li> Какие механизмы управления и контроля реально работают в вашей компании уже сегодня?</li> <li> Позволяют ли ваши данные и платформы внедрить в промышленную эксплуатацию следующий сценарий использования ИИ?</li> <li> Какая доля сотрудников прошла переобучение для работы с технологиями ИИ?</li> </ul> Примерно шесть из десяти организаций заявляют, что их стратегия в области искусственного интеллекта трансформирует … article https://www.itweek.ru/themes/detail.php?ID=235730 Wed, 14 Oct 2026 09:54:17 +0300 <p>По данным OWASP, инъекция промптов (prompt injection) уже несколько лет стабильно занимает первую строчку в списке угроз для <nobr>LLM-приложений.</nobr> И это неудивительно: в 2026 году ИИ-агенты — это уже не просто чат-боты, а полноценные участники бизнес-процессов с доступом к корпоративным API, базам данных и внутренним сервисам.</p> <p>Если вы уже задумались о защите или даже выбрали решение — отлично. Но внедрить ограничительные барьеры (guardrail) — это только первый шаг. Гораздо важнее понять, насколько они действительно эффективны: какие атаки пропускают, насколько замедляют работу моделей и как быстро адаптируются к новым техникам обхода.</p> <p>Классические метрики информационной безопасности здесь работают не всегда. Количество заблокированных угроз или время отклика — привычные ориентиры, но в мире ИИ-агентов картина сложнее. Модель генерирует текст на естественном языке, атака может быть замаскирована под обычный запрос, а задержка в 200 мс, незаметная для веб-приложения, способна заметно повлиять на пользовательский опыт в диалоговом интерфейсе.</p> <p>Чтобы оценить защиту ИИ-агентов по достоинству, стоит смотреть на другие цифры. Вот пять метрик, которые помогут быстро и системно разобраться в возможностях решения.</p> <h3>Метрика 1: качество детекции с детализацией ошибок</h3> <p>Оценивать защиту только по абстрактной «точности» — не самый надёжный путь. Гораздо информативнее смотреть сразу на два показателя:</p> <p><strong>ASR (Attack Success Rate)</strong> — доля атак, которые защита пропустила.</p> <p><strong>FPR (False Positive Rate)</strong> — доля обычных запросов, которые защита заблокировала по ошибке.</p> <p>В корпоративных сценариях важно, чтобы инъекции не проходили — ASR должен стремиться к нулю. Но если защита при этом блокирует каждый третий легитимный запрос, сотрудники быстро найдут способ ее обойти. Задача — найти баланс, при котором защита надежна, но не мешает работе.</p> <h3>Метрика 2: инференс-задержка</h3> <p>Это время, которое защитный шлюз тратит на анализ контента. В диалоговых сценариях счёт идёт на миллисекунды, и здесь ключевой показатель — TTFT (Time to First Token), то есть время до появления первого токена ответа модели.</p> <p>Защитный прокси не должен заметно замедлять стриминг ответа. При этом важно смотреть не только на средние значения, но и на P95/P99 — как ведёт себя решение под пиковой нагрузкой, когда в очередь выстраиваются сотни запросов. Именно эти хвосты распределения показывают, сохранится ли комфортный пользовательский опыт в часы максимальной активности.</p> <h3>Метрика 3: пропускная способность и масштабируемость</h3> <p>Решение должно горизонтально масштабироваться под рост числа одновременных сессий — без потерь во времени отклика и без потери контекста запросов.</p> <p>Особенно это важно в агентных сценариях, когда один запрос пользователя запускает цепочку внутренних вызовов между моделями и инструментами (tool calling). Если на каждом из нескольких шагов срабатывает проверка guardrail, задержка суммируется. Хорошее решение учитывает эту специфику и не превращает пятисекундную задачу агента в заметно более долгую из-за накладных расходов на безопасность.</p> <h3>Метрика 4: кросс-языковое и мультимодальное покрытие</h3> <p>Уязвимости часто эксплуатируются через низкоресурсные языки, транслитерацию, смену кодировок (Base64, циклические сдвиги), гомоглифы или встраивание инструкций в изображения и аудио.</p> <p>Инструмент защиты должен покрывать всё входное пространство модальностей, доступное целевой модели. Если фильтр безопасности работает только с английским текстом, а модель принимает другие языки или изображения, — защита получается неполной. Удобный ориентир здесь — процент покрытия модальностей и методов обфускации: защита должна видеть то же самое, что и сама модель.</p> <h3>Метрика 5: скорость адаптации к новым векторам атак</h3> <p>Jailbreak-техники эволюционируют ежедневно. Ключевой индикатор зрелости решения — время от появления новой техники обхода до момента, когда защита начинает её распознавать.</p> <p>Стоит уточнить у вендора, как именно обновляется guardrail: доставляются новые сигнатуры, обновляются правила или пересобирается классификатор, отсекающий опасные запросы. И главное — происходит ли это без остановки сервиса. Если обновление правил занимает недели или требует простоя, это сигнал пересмотреть подход.</p> <h3>Как применить это на практике для безопасности ИИ-агентов</h3> <p>Эти пять метрик — готовый чек-лист для диалога с вендорами и внутренней оценки. Их можно заложить в требования к PoC, сравнить несколько решений между собой или провести аудит уже работающей защиты.</p> <p>Рынок AI Security только формируется, и у компаний сейчас отличная возможность выстроить архитектуру защиты ИИ-агентов правильно с самого начала. Те, кто уже сегодня начнут применять системный подход и измерять эффективность защиты конкретными цифрами, через год получат не только снижение рисков, но и реальное конкурентное преимущество — ведь в эпоху автономных ИИ-систем выигрывает тот, кто умеет ими безопасно управлять.</p> <p> #IMAGE_235731#</p> По данным OWASP, инъекция промптов (prompt injection) уже несколько лет стабильно занимает первую строчку в списке … article Максим Горшков, технический директор “СофтМедиаЛаб” https://www.itweek.ru/themes/detail.php?ID=235728 Tue, 13 Oct 2026 18:12:48 +0300 <p><nobr>18-19</nobr> сентября в Москве прошёл форум ProcessTech 2026, организованный компанией «Инфомаксимум». Форум был посвящен актуальным аспектам технологий процессной аналитики (Process Mining) и майнинга задач (Task Mining) и собрал более 550 участников.</p> <p>Главным трендом года в данной области, по мнению организаторов форума, стал переход от преимущественно ретроспективного анализа процессов к опережающему управлению ими: мониторингу процессов в реальном времени, оценке рисков возможных отклонений от запланированных сценариев и предложению действий до превращения рисков в убытки. Данные Process Mining, использующего журналы событий корпоративных систем, и Task Mining, анализирующего действия сотрудников за ПК, становятся контекстом для LLM и ИИ-агентов, а на смену традиционным дашбордам приходят мультиагентные ИИ-системы, выдающие гипотезы на естественном языке. Потенциал использования такого подхода «Инфомаксимум» оценивает в <nobr>2,5-3 трлн.</nobr> руб. в год.</p> <p>Рассказывая о фирменной платформе Proceset, генеральный директор компании «Инфомаксимум» Александр Бочкин подчеркнул, что единицей автоматизации должна быть не операция, а бизнес-результат, например оформление заказа или урегулирование претензии. «Цифровой сотрудник» сам предлагает варианты автоматизации с обоснованием, к примеру, подготовить черновик заказа в системе «1С» после анализа 18,5 тыс. заявок и задаёт условия передачи кейса человеку, например при противоречии в данных, юридических рисках или низкой уверенности модели в результате.</p> <p>По его словам, ИИ это трактор, которому нужен маршрут, задаваемый контекстом бизнес-процессов: фактические последовательности выполнения процессов восстанавливаются с помощью Process Mining, действия сотрудников анализируются с помощью Task Mining, а теперь используются также регламенты и пары «документы на входе и на выходе» для реверс-инжиниринга процессов. Набор специализированных инструментов-вызовов для нейросетей сокращает разработку в <nobr>5-10 раз,</nobr> а система диспетчеризации ИИ-агентов с «верификатором» и «судьёй» доводит многонедельный план до реализации без участия людей.</p> <p>Как рассказал представитель «Билайна» Расул Булатов, в его компании вопрос «как автоматизировать то, что делает человек» заменили вопросом «должна ли такая работа вообще существовать». Там, где есть цифровой след, Process Mining строит модель фактического выполнения процесса и находит лишние согласования; где следа недостаточно, Task Mining помогает выявить ручные этапы, такие как переключение между окнами, копирование данных, использование Excel. Детерминированную рутину можно передавать роботам RPA и другим средствам автоматизации, а ситуации, требующие дополнительного контекста или решения, нужно оставлять за человеком. За полтора года в «Билайне» проведен редизайн более 35 процессов, годовой эффект от этого превысил 80 млн. руб., time-to-market сокращён на <nobr>10-50%,</nobr> выявлено 45 тыс. часов рутины.</p> <p>Как сообщил Рамазан Абакаров («РусГидро ИТ сервис»), в его компании применили Process Mining к закупкам на пятилетних данных SAP и системы документооборота LanDocs — от заявок до исполнения договора и оплаты. Процессы связали с бизнес-результатом: модель выявляет нарушения сроков поставок и оплаты, расхождения плановых и фактических объёмов закупок, незакрытые обязательства (например, 20,5% счетов-фактур регистрируются с задержкой более недели). Task Mining в общем центре обслуживания позволяет сопоставить фактическую длительность операций с нормативами.</p> <p>В планах — наблюдение за процессами в реальном времени: использование данных Process Mining и Task Mining как контекста для ИИ, оценка вероятности нарушения сроков и выбор реагирования. Пока это только направление развития, в котором ИИ, как подчеркнул Рамазан Абакаров, должен оставаться помощником человека.</p> <p>Павел Лабазнов (ФНС России) рассказал, что из 354 ключевых процессов в ФНС процесс-майнингом сегодня охвачено 100 (28,2%). До 90% трудозатрат уходит на подготовку данных. Чтобы ускориться, в Службе дописали к базовой платформе собственные модули.</p> <p>Гибридная аналитика, сопоставляя события Task Mining с журналом Process Mining, нашла жалобы, по которым проект решения пересылается в Word и перепечатывается. Имитационное моделирование «в два-три клика» показало, что автоматизация одного шага сократит процесс по упрощенной системе налогообложения с 5 дней 17 часов до 5 дней 6 часов. Анализ корневых причин автоматически ранжирует атрибуты, статистически связанные с длительностью процесса, а матрица отклонений выявляет редкие, зацикленные и нерегламентные события.</p> <p>С созданием 13 центров компетенций число гипотез выросло с 798 в 2024 г. до 3898 в <nobr>2026-м.</nobr> В планах создание «магазина цифровых следов», машиночитаемого регламента, приёмки проекта анализа вместе с новым ПО и подсказчика в будущей АИС «Налог-4».</p> <h3>Актуальные проблемы и тренды Process Mining и Task Mining</h3> <p>Одна из актуальных проблем процессной аналитики — качество и разрозненность данных: логи из разных систем не согласуются между собой, часть процессов вообще не оставляет логов. По словам Александра Бочкина, проблема сохраняется, но возможности исследовать фактическую работу у компаний расширились. Системные логи фиксируют только часть происходящего. Например, между регистрацией заявки и её согласованием сотрудник может сверять сведения в нескольких программах, переносить их в таблицу, исправлять ошибки. В журнале событий будут видны начало и конец этапа, а работа между ними — нет.</p> <p>«Мы решаем эту задачу с помощью Task Mining, которая автоматически выявляет бизнес-операции на основе действий сотрудников за компьютером. Система находит повторяющиеся последовательности, показывает, сколько времени занимает работа и какие затраты с ней связаны. При этом компания может обнаружить операции, которые заранее не описала, — сказал Александр Бочкин. — Конечно, Task Mining не отменяет проверки качества данных. Заказы, платежи и другие объекты по-прежнему нужно корректно связывать между системами, а офлайн-активность — дополнительно исследовать. Но отсутствие логов уже не означает, что эту часть работы нельзя изучить».</p> <p>Есть и другая причина, по которой проекты не дают ожидаемого результата: компания увидела потери, но ничего не изменила. По словам Александра Бочкина, чтобы внедрить автоматизацию, ей ещё нужно подготовить задание, найти разработчиков, дождаться реализации. «Мы сокращаем этот путь: данные о фактической работе становятся основой задания для ИИ, который создает автоматизацию, — отметил он. — При этом сначала нужно определить, какие операции можно автоматизировать и где это экономически оправданно. Ускорение редкой операции с небольшими трудозатратами может не окупить даже стоимость разработки».</p> <p>Другая проблема: как обеспечить условия для самостоятельного выполнения ИИ-агентами рабочих процессов? По словам Александра Бочкина, прежде всего агентам не хватает контекста конкретной компании. «Регламенты помогают далеко не всегда: реальная работа отличается от описаний и меняется быстрее, чем их успевают обновлять. Если передать ИИ устаревший регламент, можно быстро получить автоматизацию, которая воспроизводит ненужные действия или пропускает важные, — сказал он. — Process Mining и Task Mining помогают восстановить фактический порядок работы. Это дает основу для разработки, но цели и допустимые правила по-прежнему определяет человек».</p> <p>Как отметил Александр Бочкин, даже при наличии точных данных модель может ошибиться или пропустить обязательный шаг. «Поэтому мы разделяем создание автоматизации и её исполнение. ИИ помогает разрабатывать приложения и скрипты, взаимодействующие с корпоративными системами через API. Затем работа выполняется по заранее заданному и проверенному сценарию. К нейросети обращаются на тех этапах, где нужны её возможности. Это ограничивает влияние ошибок ИИ на выполнение процесса», — пояснил он.</p> <p>Task Mining предполагает наблюдение за работой персонала. Как индустрия балансирует между глубиной аналитики и доверием людей, действия которых подвергаются анализу? «Доверие зависит от того, какую задачу ставит руководство и что происходит после анализа. Людям важно заранее объяснить, зачем собирают данные, какие действия изучают и какие решения будут принимать. Обещание повысить эффективность слишком абстрактно. Гораздо понятнее конкретная задача: выяснить, почему при обработке одного обращения сотрудник трижды вводит одни и те же сведения», — отметил Александр Бочкин.</p> <p>По его словам, количество кликов ничего не говорит о пользе сотрудника: один обрабатывает типовые обращения, другой разбирается со сложными случаями. Поэтому результаты нужно обсуждать с участниками процесса — они могут объяснить причины действий, которые в данных выглядят лишними.</p> <p>«Не менее важно, чтобы сотрудники увидели результат исследования в своей работе: исчез двойной ввод, сократилась подготовка документов, стало меньше ручных проверок. Это даёт понятный ответ на вопрос, зачем проводился анализ, — сказал Александр Бочкин. — При этом польза от анализа не оправдывает сбор любых данных. Собирать нужно только то, что требуется для задачи: без личных сведений, с защитой чувствительной информации, ограниченным доступом и сроком хранения. Если достаточно данных по операции или подразделению, оценивать отдельных сотрудников незачем».</p> <p>Объектно-ориентированный процессный майнинг (OCPM, одновременное отслеживание и увязывание множества разных объектов) рассматривают как следующий шаг эволюции направления. Насколько это актуальный тренд?<strong> «</strong>Я ожидаю постепенного распространения этой модели. В первую очередь она полезна компаниям, которым для решения конкретных задач уже недостаточно анализа отдельных процессов. Например, один заказ исполняется несколькими поставками, а один платёж закрывает несколько счетов. Объектно-ориентированный подход позволяет сохранить эти связи и исследовать, как задержка одной части работы отражается на других», — считает Александр Бочкин.</p> <p>По его словам, практическую пользу анализа таких связей показывает проект hh.ru: с помощью мультипроцессной аналитики компания объединила пять бизнес-процессов из трёх информационных систем, охватив <nobr>5,3-5,4 млн.</nobr> кейсов. Единого идентификатора в системах не было, поэтому события сопоставляли по косвенным признакам — датам, идентификаторам клиентов и исполнителей. Это позволило измерить время между этапами в разных системах и долю ручных операций. Подготовленный дашборд сократил предварительное исследование процесса с месяца до двух—пяти дней.</p> <p>«Готовность здесь определяется качеством данных и самой задачей. Недостаточно связать объекты из разных систем — нужно понимать, какие решения компания сможет принимать на основе такого анализа. Если ради дополнительной детализации приходится усложнять модель, а практической пользы от неё нет, затраты не окупятся. Поэтому даже внутри одной компании такой подход имеет смысл сначала проверить на конкретной задаче, оценить результат и затем решать, где ещё его применять» — полагает Александр Бочкин.</p> Параллельно развивается и аналитика операций: уже применяется Multi Task Mining, который объединяет отдельные операции в сквозные процессы и позволяет оценить затраты на каждом этапе. Компания может увидеть, во сколько ей обходится весь процесс и где сосредоточена самая дорогая ручная работа. «Сейчас бизнес ищет, где сократить расходы без потери качества и объемов работы. Для этого нужно понимать, из чего складывается стоимость процесса и какие затраты можно убрать. Такая аналитика помогает обосновать конкретные изменения: что упростить, что автоматизировать и какую экономию это даст», — пояснил Александр Бочкин. 18-19 сентября в Москве прошёл форум ProcessTech 2026, организованный компанией «Инфомаксимум». Форум был посвящен … message Валерий Васильев https://www.itweek.ru/themes/detail.php?ID=235723 Tue, 13 Oct 2026 14:35:45 +0300 <p>Сбер представил GigaPlatform AI Studio — бесплатный сервис для тех, кто хочет попробовать ИИ на своих задачах и собрать собственного агента без программирования. Студия создана для частных пользователей и подходит как для личных дел, так и для работы. В ней можно расшифровать запись лекции, озвучить текст или разобраться в сложной теме. Можно также проверить идею для рабочего проекта или собрать помощника, который отвечает по загруженным документам. В одном интерфейсе собраны модели GigaChat, инструменты для их настройки, работа с голосом и документами и визуальный конструктор агентов из готовых блоков. Путь от идеи до рабочего прототипа занимает часы вместо недель разработки.</p> <p>В AI Studio доступны все актуальные версии ИИ-моделей Сбера, включая флагманскую GigaChat 3.5 Reasoning. В будущем разработчики смогут прямо в студии получить собственный ключ доступа к текстовым моделям GigaChat и бесплатно попробовать их в своих проектах через API.</p> <p>Проверка ИИ-гипотезы обычно занимает недели и требует привлечения программистов: для каждой технологии нужно писать код, а предпросмотра будущего решения, как правило, нет. Из-за этого путь от идеи до первой версии растягивается на месяцы, а инструменты приходится тестировать в разных средах. GigaPlatform AI Studio решает эти сложности. Например, в ней можно самостоятельно проверить жизнеспособность рабочей идеи — теперь это займет один день вместо недель или месяцев. Визуальный конструктор ИИ-агентов подойдёт тем, кто только знакомится с технологией и пока не знает, как сформулировать задачу в чате, чтобы агент выполнил её правильно. Сервис доступен бесплатно, вход — по Сбер ID. </p> <p>Антон Фролов, старший вице-президент, руководитель блока «Развитие генеративного ИИ» Сбербанка, отметил: «Лучше всех свою задачу знает тот, кто сталкивается с ней каждый день: студент перед сессией, менеджер, который тонет в почте, автор подкаста, которому нужен второй голос. Раньше, чтобы поручить такую задачу ИИ, нужно было уметь программировать или привлечь профессионала. В GigaPlatform AI Studio человек может сам попробовать разные модели, собрать своего помощника из готовых блоков и сразу проверить его в деле. Мы хотим, чтобы путь от идеи до работающего решения занимал один вечер, а ИИ стал таким же привычным инструментом, как текстовый редактор или таблицы».</p> <p>В GigaPlatform AI Studio доступны модели семейства GigaChat и инструменты для их настройки: можно одновременно отправить один запрос разным версиям модели и сравнить ответы, задать системные инструкции, изменить параметры генерации и проверить результат в чате. К модели можно подключить свои документы или собственную базу знаний — тогда она будет отвечать с опорой на эти материалы, например, в роли HR-консультанта, техподдержки первой линии или помощника отдела продаж. </p> <p>Для сложных исследовательских задач есть режим Deep Research — он изучает открытые источники, сопоставляет данные и собирает структурированный отчёт со ссылками. Можно задать или исключить определенные источники, загрузить собственные файлы и сохранить результат в PDF, HTML или Markdown. Диалог с моделью и ее настройки можно выгрузить в формате JSON — поделиться с коллегами или использовать как контекст для других ИИ-сервисов.</p> <p>Отдельное направление — работа с голосом: модели распознают речь и озвучивают текст с настройкой пауз, ударений и интонации, а специальная разметка позволяет создавать диалоги с разными голосами, например, в формате подкаста. Агента можно собрать без кода и запустить прямо в студии. Для этого в визуальном конструкторе достаточно соединить блоки: модель, базу знаний, голосовые настройки и сценарии диалога, а затем сразу протестировать и запустить. В студии можно создать агентов для работы с данными и таблицами, генерацией изображений, проверки почты, синтеза речи и других задач. Начинающие пользователи могут взять один из готовых шаблонов или собрать из блоков или при помощи ИИ-ассистента.</p> <p>В AI Studio есть встроенный помощник: он объясняет, что происходит на экране, и анализирует загруженные файлы. Для разбора документа достаточно загрузить его и нажать «Проанализировать» — помощник подготовит краткое содержание и ответит на вопросы. Ещё один инструмент студии — бесплатное приложение для компьютера, которое помогает со встречами. Оно распознаёт начало звонка, предлагает записать разговор, расшифровывает его и подводит итоги, причём ничего не отправляет в облако.</p> <p>Какие задачи можно решить в GigaPlatform AI Studio:</p> <ul> <li>работать с разными моделями без технической подготовки: задавать вопросы на интересные темы, визуализировать код, озвучивать тексты и расшифровывать аудио;</li> <li>снять с себя рабочую рутину без привлечения разработчиков: например, создать HR-консультанта, первую линию техподдержки или помощника по продажам на основе своей базы знаний;</li> <li>быстро проверить гипотезу, прежде чем писать код: собрать рабочий прототип, протестировать промпты и параметры перед интеграцией;</li> <li>познакомиться с технологиями Сбера: сравнить ответы разных версий GigaChat, попробовать голосовые модели и собрать первого агента из готового шаблона.</li> </ul> Сбер представил GigaPlatform AI Studio — бесплатный сервис для тех, кто хочет попробовать ИИ на своих задачах … message https://www.itweek.ru/themes/detail.php?ID=235722 Tue, 13 Oct 2026 14:29:57 +0300 <p>Институт статистических исследований и экономики знаний (ИСИЭЗ) НИУ ВШЭ изучает распространение практик применения ИИ в машиностроении. Как показали результаты анализа, предприятия отрасли демонстрируют прагматичный подход к внедрению технологии в производственной деятельности: используют ее для решения конкретных задач, умеренно оценивают текущие и ожидаемые эффекты и прогнозируют рост спроса на цифровые и производственные компетенции работников.</p> <p>Среди наиболее распространенных в машиностроении технологий — решения для обработки визуальных данных и текста, в том числе чат-боты и виртуальные ассистенты, помогающие экономить время на рутинных операциях в производственных и бизнес-процессах. К 2027 г. почти два из пяти обследованных предприятий планируют внедрить или считают перспективными технологии интеллектуальной поддержки принятия решений и управления, а каждое третье — ИИ-агентов.</p> <p>Предприятия машиностроения чаще всего применяют ИИ для моделирования продукции и процессов, проведения исследований и испытаний (37,8% организаций, использующих ИИ), диагностики оборудования (29,2%), планирования и контроля работ (26,7%). Более половины предприятий считают перспективным внедрение ИИ для контроля выполнения требований безопасности, управления промышленной безопасностью и работы с документацией.</p> <p>Эффекты от применения ИИ в машиностроении пока больше ожидают, чем фиксируют: к моменту проведения обследования в 2025 г. те или иные эффекты отметило примерно каждое пятое предприятие, использующее ИИ; в <nobr>2026–2027 гг.</nobr> получить эффекты рассчитывают более половины таких предприятий. Среди основных уже полученных результатов — снижение брака (18,8%) и сокращение времени операций с ростом производительности оборудования (17,6%). Ожидаемые эффекты чаще всего связывают с оптимизацией ИКТ-инфраструктуры (61%), а также снижением аварийности и повышением безопасности труда (60,7%).</p> <p>Большинство организаций отрасли, использующих ИИ, не ожидают, что внедрение технологии приведет к радикальному изменению общей потребности в работниках, в частности к сокращению персонала. При этом они прогнозируют рост спроса на цифровые и производственные компетенции, а также на работников всех категорий, кроме занятых рутинными административными функциями. Наиболее позитивные прогнозы касаются специалистов по ИКТ и квалифицированных рабочих.</p> <p>В каждой пятой обследованной организации машиностроения есть специалисты по работе с ИИ. Более 80% организаций-пользователей, в которых работают такие специалисты, испытывают дефицит этой категории кадров. Примерно каждая седьмая организация машиностроения (15%) поощряет сотрудников применять ИИ, а 9% взаимодействуют с образовательными организациями для подготовки специалистов с соответствующими навыками. Масштабы поддержки зависят от размера компании и отраслевой специфики.</p> <p>Ключевые технические требования к решениям на основе ИИ в машиностроении — безопасность, объяснимость (интерпретируемость) рекомендаций, выдаваемых ИИ-системой, и их точность. К числу условий расширения использования ИИ почти четверть обследованных предприятий относят регуляторную определенность в отношении применения ИИ и повышение рентабельности бизнеса. Для дальнейшего внедрения и применения ИИ необходима планомерная технологическая модернизация отрасли, которая возможна только в условиях расширения внутреннего спроса на отечественные машины и оборудование.</p> Институт статистических исследований и экономики знаний (ИСИЭЗ) НИУ ВШЭ изучает распространение практик применения ИИ … message https://www.itweek.ru/themes/detail.php?ID=235721 Tue, 13 Oct 2026 14:25:34 +0300 <p>Аналитика данных стала стратегическим приоритетом для большинства российских компаний. Однако используемые ими аналитические решения и СУБД для хранения данных не всегда обеспечивают необходимую производительность и масштабируемость при приемлемых затратах. Это один из ключевых выводов исследования рынка аналитических решений, проведённого компанией Postgres Professional среди более 300 представителей российских компаний из ИТ и разработки, финансового сектора, телекома, промышленности, ритейла и e-commerce, нефтегаза, энергетики и других отраслей.</p> <p>Согласно исследованию, 92% компаний уже рассматривают аналитику как стратегический ИТ-актив либо целенаправленно развивают её в этом качестве. При этом 80% респондентов продолжают использовать зарубежные аналитические решения — активно или для отдельных задач.</p> <p>Рост бюджетов на аналитику выводит на первый план внедрение и поддержку. </p> <p>Аналитика стала одним из драйверов ИТ-инвестиций: 36% опрошенных компаний увеличили бюджеты на нее за последние два года. При выборе решений компании учитывают не только стоимость лицензий, но и совокупную стоимость владения аналитическим стеком.</p> <p>«Сегодня компании всё внимательнее считают полную стоимость владения аналитического стека: помимо лицензий, она включает внедрение, интеграцию, масштабирование, поддержку и работу смежных команд. Поэтому при выборе аналитической СУБД на первый план выходит способность решения ускорять работу с данными и одновременно делать эксплуатацию более простой и предсказуемой. Именно этот запрос мы положили в основу развития наших аналитических продуктов», — комментирует Эльмира Рахматулина, руководитель продукта Postgres Pro AXE.</p> <p>Переход к новым аналитическим платформам определяется не только задачами импортозамещения. 47% участников исследования называют производительность на больших объёмах данных главным триггером для перехода на новую аналитическую СУБД.</p> <p>Компании оценивают аналитические СУБД по практическому эффекту: способность работать с растущими объёмами данных, встраиваться в действующий ИТ-контур, масштабироваться без остановки процессов и обеспечивать прогнозируемую стоимость эксплуатации — всё это становится весомее абстрактных технических характеристик при выборе решения. </p> <p> </p> Аналитика данных стала стратегическим приоритетом для большинства российских компаний. Однако используемые ими аналитические … message https://www.itweek.ru/themes/detail.php?ID=235720 Tue, 13 Oct 2026 10:40:54 +0300 <p><em>Искусственный интеллект берет на себя все больше задач начального уровня, заставляя организации переосмыслить то, как младшие сотрудники получают опыт и профессиональные навыки, необходимые для перехода на старшие должности, сообщает портал </em><em>AI</em> <em>Business</em><em>.</em></p> <p>Компании рассчитывают, что ИИ возьмет на себя значительную часть работы, которую раньше выполняли люди. Однако именно в процессе выполнения этих задач сотрудники зачастую и учатся своей профессии.</p> <p>Проблема становится все более актуальной по мере того, как ИИ начинает выполнять задачи, традиционно поручаемые младшим специалистам. Если ИИ способен справляться с рутинной работой быстрее или дешевле, компаниям может потребоваться меньше персонала для ее выполнения.</p> <p>Но у работы начального уровня есть и другая цель: она позволяет сотрудникам набраться опыта и развить профессиональные навыки, прежде чем перейти на более высокие должности.</p> <p>Финансовый директор компании Teikametrics Брайан Бопре посвятил первые десять лет своей карьеры построению финансовых моделей и изучению цифр, лежащих в основе ключевых бизнес-решений. Сегодня, по его словам, значительную часть этой работы может выполнять ИИ. Его беспокоит, что молодые сотрудники могут лишиться того опыта преодоления трудностей, который учил предыдущие поколения распознавать ошибочные решения.</p> <p>Схожие перемены могут ожидать и сферу кибербезопасности. Опрос сотрудников центров мониторинга и реагирования на инциденты (SOC) Swimlane «The New SOC Career Ladder» показал, что ИИ, вероятно, приведет к сокращению ряда должностей начального уровня в этих подразделениях, одновременно открыв возможности для перехода специалистов на более стратегические позиции.</p> <p>Это ставит перед работодателями сложную задачу: как готовить сотрудников к выполнению стратегических задач в условиях, когда исчезает работа, ранее обеспечивавшая необходимый для этого опыт?</p> <p>Навыки работы с ИИ становятся еще одним фактором, разделяющим рабочую силу. Новый опрос PwC «Global Workforce Hopes and Fears Survey 2026», проведенный среди почти 50 000 работников, показал, что 56% из них относятся к категории, которую компания назвала «машинным отделением» (engine room): это сотрудники, не обладающие специализированными навыками и не продвинувшиеся в изучении ИИ. Лишь половина из них уверена в стабильности своей занятости; кроме того, представители этой группы (одной из четырех, выделенных PwC) реже всего заявляли о готовности к адаптации.</p> <p>Разрыв может усугубиться из-за различий в оплате труда.</p> <p>Недавний отчет компании Payscale показал, что 61% работодателей пересматривают должностные инструкции из-за внедрения ИИ, однако менее половины из них заявили, что системы оплаты труда меняются соответствующим образом. Исследователи предупреждают о риске «мины замедленного действия» в вопросе удержания персонала: это может произойти, если компании будут предлагать более высокую зарплату новым сотрудникам с навыками работы с ИИ, не поощряя при этом должным образом действующих сотрудников, которые также осваивают эти компетенции. В совокупности всё это — не просто признаки того, что ИИ меняет характер работы. Эти факты указывают на более фундаментальную проблему для компаний: им придется пересмотреть подходы к профессиональному развитию сотрудников.</p> <p>Долгие годы корпоративная карьерная лестница строилась на принципе обучения в процессе работы. Начинающие специалисты выполняли задачи начального уровня, приобретали профессиональные навыки и учились принимать решения, постепенно беря на себя всё большую ответственность. Если же ИИ начнет выполнять значительную часть таких задач, компаниям придется искать иные способы обеспечения необходимого опыта.</p> <p>Некоторые компании уже предпринимают такие попытки. Например, Бопре объединяет в пары опытных сотрудников и новичков, которые лучше владеют инструментами ИИ. Старшие сотрудники объясняют логику принятия решений, а молодые специалисты помогают им работать с технологиями ИИ. Цель такого подхода — сохранить те элементы профессионального обучения, которые могли бы быть утрачены, если бы ИИ просто выдавал готовый результат.</p> <p>Однако этот переход не произойдет сам собой. Если компании исключат задачи начального уровня, не предложив сотрудникам альтернативных путей обучения, они рискуют лишиться возможностей для подготовки опытных специалистов, которые в конечном счете им понадобятся.</p> ИИ, возможно, и не уничтожит корпоративную карьерную лестницу, но вполне может устранить многие из тех ступеней, по которым люди традиционно Искусственный интеллект берет на себя все больше задач начального уровня, заставляя организации переосмыслить то, как … article https://www.itweek.ru/themes/detail.php?ID=235718 Tue, 13 Oct 2026 10:20:55 +0300 <p>На рынке труда сложилась странная на первый взгляд картина: компании продолжают сокращать целые команды, но при этом говорят о дефиците кадров и месяцами ищут специалистов. На самом деле никакого противоречия здесь нет.</p> <p>PwC в «Global AI Jobs Barometer 2026» <a href="https://www.pwc.com/gx/en/services/ai/ai-jobs-barometer.html">пишет</a>, что джуниор-роли, на которые сильнее всего повлиял ИИ, в семь раз чаще требуют навыков, прежде считавшихся сеньорскими — лидерства, стратегического мышления, способности принимать решения.</p> <p>Бизнес больше не хочет нанимать людей, чью работу можно поручить модели, а вот специалистов, которые умеют управлять процессом получения результата этой работы, ценит высоко. Рассмотрим, что делать компаниям и какие они — сотрудники, которым сейчас будут рады почти везде.</p> <h3>Дефицит кадров стал точнее</h3> <p>Раньше кадровый дефицит в ИТ описывали довольно широко: не хватает разработчиков, аналитиков, тестировщиков, DevOps’ов. Компании нанимали джунов, устраивали стажировки, чтобы вырастить людей внутри — и закрывали потребность в нужных специалистах.</p> <p>Сейчас эта схема работает хуже. Искусственный интеллект забирает часть задач, которые прежде считались входом в профессию: написать простой модуль, собрать черновой тест, подготовить документацию, найти типовую ошибку, предложить вариант реализации.</p> <p>Из-за этого изменилась сама ценность специалиста. На рынке может быть много свободных разработчиков и одновременно мало тех, кто действительно нужен компаниям. Дефицит все меньше проходит по грейдам и больше — по способности принимать инженерные решения.</p> <h3>Кто оказывается в зоне риска</h3> <p>Сильнее всего ИИ давит на роли, где много повторяемой работы и мало самостоятельных решений. Такие задачи обычно помогают человеку расти. Например, джун пишет код, получает замечания на ревью, видит последствия ошибок — и постепенно учится думать как инженер.</p> <p>Часть этого пути сокращается, когда агент пишет типовые фрагменты или находит баги вместо сотрудника. Но специалист должен понимать, что именно происходит внутри машины.</p> <p>Из-за этого в зоне риска оказываются те члены команды, которые не переходят от исполнения к управлению сложностью — не джуны как класс и не мидлы как уровень. Условный мидл, который просто хорошо пишет код, теперь конкурирует не только со специалистами, но и с ИИ-инструментами.</p> <h3>Нужный майндсет — какой он?</h3> <p>Пользоваться ИИ сейчас умеют многие, поэтому просто знать, как с ним работать, мало — нужно понимать, как продукт работает и где он может ошибиться. Для этого необходим подходящий майндсет, то есть тип мышления и восприятия.</p> <p>Он складывается из нескольких вещей:</p> <ul> <li> понимание архитектуры и взаимодействия компонентов;</li> <li> умение отличать рабочий результат от качественного;</li> <li> привычка проверять ограничения, а не только функциональность;</li> <li> способность задавать правила для ИИ-инструментов;</li> <li> ответственность за сопровождение результата;</li> <li> готовность разбираться, а не механически выполнять инструкцию.</li> </ul> <p>Разница проявляется еще до начала работы. Инженер сперва определяет стек, архитектуру, ограничения и правила проверки — и только потом подключает нейросети. Человек без такой базы сначала выполняет задачу, а затем уже разбирает, что у него вышло.</p> <p>Представьте сотрудника, который потратил недельный лимит токенов за один день — это как раз пример из второй категории. Он получил нужный результат, но использовал слишком дорогие модели. Где-то хватило бы более простых, а часть задач вообще стоило передать другим инструментам.</p> <p>Это похоже на попытку забить гвоздь микроскопом. Да, лучше, чем лбом — но инструмент все равно используется неправильно.</p> <h3>Почему вайбкодеры не заменят инженеров</h3> <p>Люди, которые еще вчера не умели писать код, а сегодня с помощью нейросетей запускают приложения, создают много шума. Это они чаще всего кричат, что разработчики больше не нужны — ведь у них-то получилось сделать рабочий сервис. И для бизнеса такая скорость тоже полезна: можно быстро проверять гипотезы и закрывать часть задач, не перегружая команду.</p> <p>На самом деле достаточно задать простой вопрос: «Если собрать таким же образом автопилот для самолета, вы полетите на нем?» В этот момент становится четко видно различие между прототипом и рабочим продуктом.</p> <p>Вайбкодинг может дать рабочий результат. Однако он быстро превращается в риск, если его нужно защищать, масштабировать, развивать и встраивать в рабочий контур без инженерной культуры.</p> <h3>Новых сеньоров сложнее растить</h3> <p>Самая большая кадровая проблема компаний — не в сокращениях джунов. Просто через несколько лет можно обнаружить, что не из кого растить сеньоров. Долгие годы путь был понятным: человек приходит на младшую позицию, много пишет сам, работает в ограничениях, получает замечания на ревью, видит последствия плохих решений — и только потом усиливается с помощью ИИ-инструментов.</p> <p>Теперь представьте, что человек с минимальным опытом сразу приходит в компанию и получает в распоряжение нейросеть. Получится ли у него увидеть, что технология предлагает рабочее, но в перспективе опасное решение? Едва ли.</p> <p>Пока рынок спасает кадровый запас инженеров, которые успели нарастить опыт до массового внедрения ИИ. Но этот резерв конечен. Если перестать пополнять его, поиск подходящего сотрудника станет сложнее.</p> <p>World Economic Forum в «Future of Jobs Report 2025» отмечает, что 63% работодателей уже <a href="https://www.weforum.org/press/2025/01/future-of-jobs-report-2025-78-million-new-job-opportunities-by-2030-but-urgent-upskilling-needed-to-prepare-workforces/">считают</a> дефицит навыков главным барьером для трансформации бизнеса, а 59% работников к 2030 году будут нуждаться в переобучении или повышении квалификации.</p> <h3>Сеньоры становятся бутылочным горлышком</h3> <p>В новой модели сеньор или тимлид управляет инженерной рамкой, в которой работают специалисты и ИИ-агенты. Он задает архитектурные правила, контролирует качество, понимает, какие задачи можно автоматизировать, а какие требуют человека.</p> <p>Раньше тимлид видел плохое решение на код-ревью и объяснял разработчику, как его исправить. Сейчас часть этой работы происходит раньше: руководитель группы задает правила агентам, чтобы они сразу работали по нужным стандартам и в нужной архитектуре.</p> <p>Следующий слой специалистов тоже выращивают именно сеньоры и тимлиды. Но здесь возникают сложности:</p> <ul> <li> некоторые сотрудники в какой-то момент понимают, что, занимаясь обучением, они снижают собственную уникальность на рынке и повышают конкуренцию. На этом их энтузиазм обычно и заканчивается;</li> <li> хороший инженер не значит хороший наставник. Уметь делать самому и учить этому других — разные навыки, и не у всех есть способности педагога. К тому же обучать чему-то взрослых людей куда сложнее, чем школьников.</li> </ul> <p>Если бизнес хочет растить людей новой формации, это должно стать частью системы — с выделенным временем и нормальной управленческой поддержкой.</p> <h3>Кадровый резерв не пополняется автоматически</h3> <p>Сократить входные позиции проще всего, ведь часть типовой работы уже и правда автоматизирована. Но с этой работой исчезают задачи, на которых прежде росли будущие сильные инженеры.</p> <p>Возникает отсроченная проблема. Сегодня бизнес экономит на исполнении — завтра столкнется с еще более явным дефицитом людей, способных принимать решения и управлять работой ИИ.</p> <p>Новая технология изменила саму экономику труда. Типовые задачи дешевеют, а все, что связано с контролем, архитектурой и сопровождением, дорожает. Поэтому рынок жестче разделяет специалистов по умению работать со сложностью — и те, кто не способен учиться и перестраиваться, по итогу начнут выпадать из сильных команд.</p> <h3>Что делать компаниям: памятка</h3> <p>Главная ошибка — одним махом сократить джунов и думать, что это решило проблему. В моменте такое решение может дать экономию, но в долгую разрушит кадровую воронку.</p> <p>Как можно действовать:</p> <ul> <li> менять формат развития джунов вместо того, чтобы отказываться от них полностью;</li> <li> давать младшим специалистам задачи на понимание кода и не ограничиваться только генерацией;</li> <li> учить работать с ИИ через ограничения и правила;</li> <li> закреплять за сеньорами и тимлидами наставничество как полноценную часть их ролей;</li> <li> оценивать способность сопровождать результат, а не только скорость выполнения задач;</li> <li> создавать внутренние правила использования ИИ-инструментов;</li> <li> развивать у сотрудников инженерное мышление и не учить их просто писать промпты.</li> </ul> <p>Развитие кадров в эпоху искусственного интеллекта не ограничивается разовой программой обучения. Это управляемая система, где у человека есть причина расти и понятные требования — и где он постоянно получает поддержку.</p> <h3>Подведем итоги</h3> <p>Сокращения и дефицит кадров могут происходить одновременно, ведь бизнес избавляется не от профессий — от старых ожиданий к ним. Работа, которую можно автоматизировать, становится нужна меньше, зато растет потребность в людях, способных управлять результатом этой автоматизации.</p> <p>Людей, которые умеют пользоваться нейросетями, уже много — и будет еще больше. В дефиците окажутся специалисты, которые понимают архитектуру, качество, риски и сопровождение, умеют задавать правила для ИИ и отвечать за итоговый продукт.</p> <p>Поэтому сегодня не так важно, сколько джунов можно заменить агентами. Важнее понять, из кого за несколько лет вырастет сеньор, способный этими агентами управлять.</p> <p>#IMAGE_235719#</p> На рынке труда сложилась странная на первый взгляд картина: компании продолжают сокращать целые команды, но при … article Константин Попандопуло, технический директор Umbrella IT https://www.itweek.ru/themes/detail.php?ID=235717 Mon, 12 Oct 2026 14:48:14 +0300 <p>Компания Security Vision представила обновление пятой версии своей Low-code/No-code платформы автоматизации процессов обеспечения информационной безопасности — Security Vision 5 (SV5). Новая версия помогает командам ИБ экономнее использовать хранилище событий, быстрее получать контекст при разборе алертов и сокращать объём работ по настройке платформы. Обновление также расширяет возможности визуализации данных и упрощает работу со связанными объектами.</p> <p>Для событий определённых типов в SV5 добавлено сжатие при хранении: стандартное с использованием LZ4 или максимальное с использованием zlib. Это позволяет уменьшить объём данных на диске и сдерживать потребность в дополнительном пространстве для хранения по мере роста потока событий. Кроме того, фильтрацию и сортировку в типе события теперь можно включать и выключать без реиндексации хранилища. Администратору не требуется перестраивать индекс ради изменения этих настроек — плановые изменения можно выполнять с меньшими затратами времени и ресурсов.</p> <p>При разборе алерта аналитик теперь видит в его карточке информацию о хосте, с которым связаны исходные события. Для свойств «Ссылка на объект» и «Ссылка на справочник» можно открыть краткую карточку связанного объекта, не закрывая текущий объект или представление. Специалисту проще проверить сведения, необходимые для оценки срабатывания, не теряя контекст и не возвращаясь к уже открытым карточкам.</p> <p>В графе появились правила отображения по свойствам и колонкам справочника, указанным в связях других правил. Также добавлены сохранение и поиск в графе, обновлена панель инструментов. Это помогает находить нужные элементы в схеме связей и использовать её при анализе данных. В аналитических виджетах «Таблица», «Текст с параметрами» и «Последовательность» теперь можно настраивать формы вывода значений, чтобы показатели было удобнее считывать и сравнивать в повседневной работе.</p> <p>Обновление затронуло и формы ввода. Для свойства «Да/Нет» добавлена форма «Иконка», позволяющая компактно разместить поле в карточке и обозначить его значение визуально. Многострочное поле «Строка» автоматически расширяется при вводе до заданного количества строк: пользователь видит больше текста и тратит меньше времени на прокрутку при заполнении длинных описаний.</p> <p>Обновлён интерфейс расписаний запуска рабочих процессов, создания отчётов и запуска коннекторов. В разделе организационной структуры переработаны оформление и расположение элементов меню. Администраторам проще ориентироваться в настройках регулярных запусков и находить нужные элементы — это особенно важно, когда количество настроенных процессов и задач увеличивается.</p> <p>Обновление SV5 объединяет изменения, которые помогают командам ИБ в повседневной работе: экономнее хранить события, получать нужный контекст при разборе алертов и настраивать платформу без лишних операций.</p> Компания Security Vision представила обновление пятой версии своей Low-code/No-code платформы автоматизации процессов обеспечения … message https://www.itweek.ru/themes/detail.php?ID=235716 Mon, 12 Oct 2026 10:33:03 +0300 <p><em>Угрозы со стороны искусственного интеллекта требуют наступательного подхода к безопасности. Хаим Мазаль, </em><em>CISO</em> <em>компании GitLab, рассказывает на портале </em><em>The</em> <em>New</em> <em>Stack</em> <em>о том, как команды, возглавляемые инженерами, используют проактивную автоматизацию для остановки киберпреступников.</em></p> <p>В июне Five Eyes («Пять глаз», разведывательный альянс пяти англоязычных стран<strong>:</strong> Австралии, Канады, Новой Зеландии, Великобритании и США) выпустил редкое совместное <a href="https://www.cisa.gov/news-events/news/five-eyes-cyber-security-agencies-statement">заявление</a>. Они предупредили, что передовые модели ИИ, как ожидается, «превзойдут текущие отраслевые ожидания, коренным образом трансформируя как наступательные, так и оборонительные возможности кибербезопасности».</p> <p>Это не теория; злоумышленники доказали свою способность обходить средства защиты. Уровень сложности для неискушенных злоумышленников, желающих осуществлять все более изощренные атаки, будет продолжать снижаться.</p> <p>Для защитников предупреждение «Пяти глаз» сигнализирует о том, что существующие подходы к безопасности не соответствуют экспоненциальному росту скорости и масштабов действий злоумышленников. В этой среде защита поверхностей атаки не сработает. Нужно переходить в наступление.</p> <h3>Лучшая защита — это хорошее нападение</h3> <p>Специалисты по безопасности инстинктивно воспринимают появление мощных моделей как сугубо плохую новость. Но переживания по поводу темпов развития возможностей ИИ ничего не изменят в программе обеспечения безопасности. Практически все средства защиты изначально создавались как инструменты эксплуатации уязвимостей, и команды безопасности перепрофилировали их для защиты. Логика, лежащая в основе большинства используемых сегодня коммерческих инструментов безопасности, применима и здесь, и защитники также имеют право на использование передовых технологий.</p> <p>Если злоумышленники теперь могут использовать ИИ для анализа активов организации и совершения атак на каждую уязвимость, защитникам необходим образ мышления, который заставит их сначала проанализировать свою собственную среду, используя ту же технологию. Этот инстинкт естественным образом вытекает из профессионального опыта, а не из осознанного выбора или метода.</p> <h3>Разные пути, разные подходы</h3> <p>CISO занимают свои должности несколькими разными путями. Некоторые приходят из отделов управления, рисков и соответствия требованиям, которые уже отвечают за риски. Некоторые приходят из ИТ-отделов, унаследовав безопасность вместе с остальной технологической инфраструктурой. Некоторые — из области архитектуры безопасности, они понимают, как фактически создавались системы. В последнее время всё большее число таких специалистов приходит из инженерных специальностей. Каждый путь формирует своё мировоззрение.</p> <p>Опыт в сфере соответствия нормативным требованиям или ИТ, как правило, формирует оборонительное мышление: ждать, пока логирование, мониторинг или инцидент покажут, куда инвестировать. Инженерный опыт, особенно в компаниях-разработчиках ПО, как правило, формирует наступательно мышление: активный поиск уязвимостей во всей программе, подобно злоумышленнику.</p> <p>Именно такое мышление нам сейчас нужно.</p> <h3>Мыслить как злоумышленник</h3> <p>Команды с наступательным мышлением видят себя создателями масштабируемых решений, которые автоматизируют результаты для бизнеса, постоянно выявляя потенциальные недостатки в программе, ландшафте угроз, инфраструктуре и каталоге активов.</p> <p>Для этого требуется настоящая любознательность; понимание того, как всё устроено, почему всё устроено именно так и что может пойти не так. Это основа исследований в области безопасности в целом: огромное любопытство к тому, как всё работает, как должно себя вести и как можно получить результаты, выходящие за рамки предполагаемых пользовательских кейсов.</p> <p>Изменения, которые я внес в свои команды, приближают нас к функциям, ориентированным на результат и управляемым инженерами. Каждая команда поддерживает автоматизированных агентов, которые выявляют риски, оценивают их, устраняют и сообщают о них в соответствии с конкретным бизнес-результатом. Безопасность приложений фокусируется на обеспечении инженерной поддержки, создании агентов, которые выполняют задачи от начала до конца на протяжении всего жизненного цикла разработки ПО. Команды по управлению и рискам становятся командами по обеспечению доверия и устойчивости бизнеса, ориентированными на постоянное подтверждение безопасности организации.</p> <h3>Создание правильного преимущества ИИ</h3> <p>Чтобы это работало, сосредоточьтесь на двух практических шагах.</p> <p>Во-первых, нейтральность относительно моделей. Создавайте рабочие процессы, которые не привязаны к одной модели или поставщику, поскольку лучшие сегодня модели и инструменты ИИ могут оказаться неподходящими через шесть месяцев. Нейтральность относительно модели также означает нейтральность относительно развертывания, что дает командам по безопасности возможность запускать модели в изолированных или самостоятельно управляемых средах, когда этого требуют условия размещения данных или защита интеллектуальной собственности, а не только возможность смены поставщика.</p> <p>Во-вторых, фокусировка. Делайте задачи агентов узкими и четко определенными. Если вы дадите агенту большую, расплывчатую задачу, он будет хорошо работать некоторое время, а затем потеряет ориентир и начнет генерировать все, что, по его мнению, удовлетворит запрос. Дайте ему конкретную задачу и уделите приоритетное внимание заблаговременному предоставлению правильного контекста, чтобы он мог более стабильно добиваться успеха. Именно так вы оркестрируете интеллектуальные результаты, не жертвуя точностью.</p> <p>Не каждая программа готова с первого же дня перестроиться на работу с агентами, и это нормально. Если программа находится на начальном этапе этого пути, не стоит усложнять задачу: проанализируйте каждое ключевое направление, определите желаемый конкретный результат и двигайтесь в обратном направлении, используя уже имеющиеся инструменты, — не нужно сразу полагать, что вам необходим совершенно новый технологический стек.</p> <h3>Пришло время переосмыслить подход</h3> <p>Самый большой риск на данном этапе — это «паралич анализа». Планка, которую нужно преодолеть злоумышленникам, постоянно снижается, тогда как требования к защите, напротив, растут. Мы больше не можем позволить себе роскошь ждать инцидента или выпуска патча от вендора. Наши системы безопасности должны соответствовать вызовам времени, если мы не хотим стать жертвами того, что наши противники меняют тактику и методы атак.</p> Угрозы со стороны искусственного интеллекта требуют наступательного подхода к безопасности. Хаим Мазаль, CISO компании … article https://www.itweek.ru/themes/detail.php?ID=235714 Mon, 12 Oct 2026 10:23:49 +0300 <p>Написать эту заметку меня сподвигли собственные опыты онбординга: программа лояльности крупной сети АЗС, приложения оператора домашнего интернета и опыт перехода на нового мобильного оператора. Может показаться, что сравнивать их с банковскими приложениями некорректно, но эта грань давно стерлась. Все они закрывают какую-то боль, а-ка потребность. И каждый лишний экран, лишнее поле или сломанный сценарий отваливает тех, кто не готов вписывать одно и то же по кругу.</p> <h3>Первая конверсия: из установки в клиента</h3> <p>76% россиян активно пользуются банковскими приложениями, и это уже не новость. Новость в другом: у 28% таких приложений два, у 26% три, у 17% четыре, а 15% держат пять и больше. Банк конкурирует не с отделением за углом, а с соседней иконкой на том же экране. И проигрыш выглядит не как жалоба, а как тишина: человек просто перестает заходить. Поэтому удобство для меня не излишество, а метрика, которая конвертируется в деньги.</p> <p>Онбординг решает не за дни, а за минуты. Главный показатель, который я бы смотрел, это время до первой ценности: сколько проходит от открытия приложения до момента, когда человек увидел то, ради чего пришел. Все, что стоит на этом пути, работает против вас.</p> <p>Мой пример. Я хотел получить QR-код программы лояльности на АЗС. После регистрации с подтверждением телефона потребовалось подтвердить еще и почту, экран подтверждения не закрывался, а код так и не пришел. Итог: к программе я не подключился и ни одного бонуса не накопил.</p> <p>Прямой банковской статистики по тому, сколько людей не дотерпело до решения своей задачи, публично почти нет, зато есть смежная. В электронной коммерции 17% покупателей бросают оформление из-за того, что процесс слишком длинный и сложный, и еще 18% уходят, когда их заставляют регистрироваться. Оценка потенциала простая: устранение трения и желания бросить телефон об пол дает около трети прироста конверсии.</p> <p>В банке поля так просто не выкинешь, здесь KYC и требования регулятора. Но переупаковать путь можно почти всегда: подтянуть данные из государственных сервисов вместо ручного ввода, разбить анкету на понятные шаги с прогрессом, объяснить, зачем нужно каждое поле, не требовать полной регистрации до того, как человек увидел продукт и условия.</p> <h3>Вторая конверсия: из нового в постоянного</h3> <p>Установка это не победа. Настоящая проверка начинается на втором и десятом входе. И здесь выигрывает не тот, у кого ярче витрина продуктов, а тот, у кого быстрее решаются рутинные задачи: найти нужное, перевести, оплатить, скачать справку, получить напоминание о платеже, настроить автопополнение.</p> <p>Отдельно выделю то, что называю эмпатичным интерфейсом.</p> <p>Круто, когда:</p> <ul> <li> видно сколько ты заработал процентов сразу на экране продукта;</li> <li> под полем для ввода чего либо есть подстрочник, объясняющий, зачем оно нужно;</li> <li> если выскакивает ошибка (это уже хорошо), но круто, если не просто сообщает «упс, что-то отвалилось», а поясняет, что именно пошло не так и что с этим делать.</li> </ul> <p>Не круто, когда:</p> <ul> <li> главный экран перегружен, как новогодняя елка;</li> <li> интерфейс выглядит как школьный сайт из 2006 года;</li> <li> подписка, подключенная автоматом по схеме «первый месяц бесплатно», нигде не подсвечена, и непонятно, как ее отключить;</li> <li> ИИ в поддержке не понимает твой запрос, предлагает одно и то же по кругу и не зовет оператора;</li> <li> непонятно почему такой процент по накопительному счету и как он получился, а особенно если не виден трек-рекорд выполнения условий по надбавкам.</li> </ul> <p>В сбережениях это особенно заметно. Клиент возвращается не ради баннера с новым вкладом, а чтобы проверить, когда придут проценты, продлится ли вклад автоматически, сколько накопилось за месяц или за день. Если на эти вопросы приложение отвечает за два касания, человек остается. Если ради справки, шаблона платежа или суммы начисленных процентов или чтобы разобраться как получить максимальный процент по накопительному счету — нужно писать в чат и ждать сутки, он откроет вклад или накоп там, где все это видно сразу.</p> <p>Оговорюсь: есть вещи, которые перебивают даже отсутствие приложения. При ставке заметно выше рынка терпимость клиента резко растет, а кому-то приложение просто и не нужно. Но и у цены есть границы: ради лишних 0,5% вряд ли кто-то останется там, где дейли-банкинг сделан плохо. Хотя исключения будут: тому, кто годами хранит сбережения в одном месте, нужен очень сильный стимул для финансового переезда.</p> <h3>Почему плохой UX живет годами</h3> <p>Главная причина не в дизайнерах и не в продактах. Клиентский путь фрагментирован: привлечение у маркетинга, продукт у продуктовой команды, свой онбординг в отделениях у сети. У каждого свои метрики и задачи. Добавлю наблюдение: приложение растущего банка быстро обрастает сервисами и допуслугами, и удержать его понятным при этом получается далеко не всегда. Отсюда знакомое чувство, когда заходишь на главный экран и не понимаешь, куда нажать, чтобы найти то, за чем пришел.</p> <p>Вторая причина — это подмена понятий. Регулярно вместо устранения трения делают редизайн: меняют цвета и иконки, а количество шагов и логика группировки сервисов остаются прежними.</p> <p>Третья причина, комплаенс как универсальное алиби. Требования регулятора действительно жесткие, но они описывают, что нужно собрать, а не в каком порядке и каким текстом об этом спрашивать.</p> <p>Четвертая причина, старое доброе «зачем менять то, что и так работает». Ведь 85% как-то разобрались, и ладно. А сколько из них испытали негатив и просто дотерпели, никто не считал.</p> <h3>Чек-лист: аудит своего приложения за один вечер</h3> <ul> <li> <strong>Пройдите путь сами.</strong> Возьмите чистое устройство и зарегистрируйтесь как новый клиент. Засеките время до первой ценности и посчитайте количество экранов.</li> <li><strong>Посчитайте поля.</strong> Выпишите все, что клиент вводит руками. Каждое поле должно быть обосновано требованием закона или продуктовой логикой, остальные можно убирать.</li> <li><strong>Прочитайте свои ошибки.</strong> Экран отказа и текст ошибки это момент максимального раздражения. Если там написано «произошла ошибка, попробуйте позже», вы теряете клиента именно здесь.</li> <li><strong>Проверьте второй день.</strong> Что человек видит при втором входе и что получает в уведомлениях. Если только продажи, возвращаться незачем.</li> <li><strong>Дайте приложение родителям.</strong> Самый честный тест. Там, где они надолго замирают, у вас дыра в конверсии.</li> <li><strong>Сравните с соседней иконкой.</strong> Откройте тот же сценарий в приложении конкурента и засеките время. Клиент делает ровно это, только молча.</li> </ul> <p>#IMAGE_235715#</p> Написать эту заметку меня сподвигли собственные опыты онбординга: программа лояльности крупной сети АЗС, приложения оператора … article Вадим Копылов, руководитель направления по развитию сберегательных и инвестиционных продуктов Инго Банка https://www.itweek.ru/themes/detail.php?ID=235710 Fri, 09 Oct 2026 14:57:11 +0300 <p><br/> KVADRA, бренд персональных устройств YADRO (входит в ИКС Холдинг), представила kvadraOS Desktop — операционную систему для персональных компьютеров. ОС предназначена для корпоративных и государственных клиентов и позволяет поэтапно переводить рабочие места на российское программное обеспечение с сохранением привычных пользовательских сценариев и части существующего ПО. kvadraOS Desktop поддерживает приложения для Windows, Linux и Android, интеграцию с корпоративной инфраструктурой и набор механизмов защиты рабочего места. </p> <p>Одним из приоритетов при разработке kvadraOS Desktop стала совместимость с существующей ИТ-инфраструктурой клиентов. ОС позволяет одновременно работать с веб-, Linux- и Android-приложениями. Windows-приложения из перечня совместимого ПО, включая Microsoft Office 2016, можно запускать через интегрированный слой совместимости. Для сценариев, которым требуется полноценная среда Windows, предусмотрено подключение к инфраструктуре виртуальных рабочих столов.</p> <p>Такой подход позволяет организациям переходить на российскую ОС поэтапно, сохраняя используемое программное обеспечение и привычные рабочие процессы. Поддержка существующих приложений сокращает необходимость их адаптации или замены, а знакомая логика интерфейса позволяет снизить затраты на переобучение сотрудников. kvadraOS Desktop также предусматривает возможность кастомизации под задачи конкретного клиента.</p> <p>Операционная система интегрируется в существующую корпоративную инфраструктуру: поддерживает подключение к домену Microsoft Active Directory и вход с доменной учетной записью, работу с VPN, сетевыми ресурсами, печать и подключение периферийных устройств. Обновления могут поступать с серверов KVADRA, также предусмотрены тиражирование подготовленного образа ОС и возврат устройства к исходным настройкам. </p> <p>Отдельное внимание в kvadraOS Desktop уделено безопасности рабочего места. Системная область доступна только для чтения, среды исполнения приложений изолированы друг от друга, а запуск системы защищен механизмом доверенной загрузки. ОС поддерживает шифрование пользовательских данных, TPM 2.0, ГОСТ-криптографию на базе КриптоПро, многофакторную аутентификацию, российские корневые сертификаты, а также сценарии входа с помощью Рутокен и JaCarta в проверенной версии продукта.</p> <p>kvadraOS Desktop разрабатывается как часть единой платформы клиентских устройств KVADRA — персональных компьютеров, ноутбуков и моноблоков — и программного обеспечения. Операционная система, оборудование и базовая система ввода-вывода (BIOS) разрабатываются и тестируются с учетом их совместной работы. Это позволяет заранее проверять совместимость компонентов, поставлять устройства с предустановленной ОС и сокращать объем работ по развертыванию и настройке рабочих мест.</p> <p>«При переходе на российскую операционную систему для клиентов критично сохранить работающие бизнес-процессы и не превращать миграцию в одновременную замену всего программного обеспечения и парка устройств. Поэтому при разработке kvadraOS Desktop основной фокус сделан на совместимости с существующей корпоративной инфраструктурой и привычными приложениями. Это позволяет переводить рабочие места на новую ОС последовательно, выбирая темп перехода с учетом задач конкретной организации», — отметил Дмитрий Черкасов, генеральный директор KVADRA.</p> <p>kvadraOS Desktop развивает линейку программного обеспечения KVADRA, в которую также входит мобильная операционная система kvadraOS Mobile для планшетов KVADRA. Обе ОС поддерживают приложения Android и интеграцию с корпоративной инфраструктурой. В kvadraOS Mobile предусмотрены режим киоска для специализированных рабочих сценариев, в том числе для полевых сотрудников, и совместимость с российскими и зарубежными системами управления мобильными устройствами (MDM).</p> <p>Возможности обеих операционных систем дополняют новые экосистемные сервисы KVADRA, также представленные на мероприятии. Корпоративное хранилище KVADRA позволяет загружать файлы, обмениваться ими и предоставлять к ним доступ: сервис интегрирован непосредственно в файловую систему kvadraOS Desktop и kvadraOS Mobile. KVADRA Hello обеспечивает вход в kvadraOS Desktop по распознаванию лица на совместимом оборудовании. Менеджер паролей KVADRA предназначен для безопасного хранения корпоративных паролей и управления ими. Сервис поддерживает разграничение доступа на основе ролей, генерацию паролей по политикам организации, шифрование данных, хранение сертификатов и интеграцию с корпоративными системами.</p> KVADRA, бренд персональных устройств YADRO (входит в ИКС Холдинг), представила kvadraOS Desktop — операционную … message https://www.itweek.ru/themes/detail.php?ID=235709 Fri, 09 Oct 2026 14:55:07 +0300 <p>Компания «Индид», российский разработчик решений в области защиты айдентити, представила ряд значимых функциональных улучшений сервиса многофакторной аутентификации Indeed MFA. Обновление включило в себя: резервный сценарий подтверждения входа с помощью одноразового кода, расширенные возможности предварительной аутентификации и новые инструменты для администраторов при управлении сервисом.</p> <p>Push-уведомления позволяют подтвердить вход одним действием в мобильном приложении и остаются одним из наиболее удобных способов второго фактора. При этом доставка сообщения может зависеть от внешних сервисов, качества интернет-соединения и настроек мобильного устройства. Если уведомление не дошло или пользователь не успел его подтвердить, процесс аутентификации может быть прерван.</p> <p>В обновленной версии Indeed MFA предусмотрен резервный сценарий. Компания «Индид» добавила возможность продолжить аутентификацию, если пользователь не подтвердил push-запрос в мобильном приложении Indeed Key. В этом случае система может предложить ввести одноразовый код вручную. Такой сценарий позволяет сохранить привычный способ входа через push и одновременно предусмотреть альтернативный вариант подтверждения.</p> <p>Функция доступна при интеграции сервиса через Indeed-агенты. Для сценариев с использованием RADIUS клиентское приложение должно поддерживать технологию Challenge-Response — последовательный обмен запросами и ответами в рамках одной процедуры аутентификации.</p> <p>Еще одно важное улучшение касается правил предварительной аутентификации. В Indeed MFA появилась возможность создавать их на основе GUID Keycloak и использовать для построения цепочек nFactor. Это позволяет точнее определять как должен проходить запрос аутентификации и при каких условиях пользователю необходимо перейти ко второму фактору. Таким образом, организации получают больше возможностей выстраивать разные сценарии проверки в зависимости от используемых систем, пользователей и требований к доступу.</p> <p>Кроме этого, в обновленном сервисе Indeed MFA расширены возможности администрирования. Теперь можно настраивать список операторов, которые будут получать системные уведомления, заранее предупреждать администраторов об окончании срока действия сертификата доступа к push-прокси и задавать период, в течение которого пользователь с выданным, но еще не активированным токеном сможет работать без второго фактора. Также разработчик доработал логику биллинга при переходе аккаунта из тестового режима в продуктивный.</p> <p>«Мы продолжаем развивать Indeed MFA в сторону более гибких и устойчивых сценариев аутентификации. Благодаря новому функционалу сервиса пользователь может перейти к резервному способу подтверждения, если push-запрос не был подтвержден, а администраторы получили больше возможностей управлять логикой перехода ко второму фактору. Это позволяет адаптировать многофакторную аутентификацию под разные инфраструктуры наших заказчиков и при этом сохранять удобный для пользователя процесс входа», — отметил Галуст Шахбазян, коммерческий директор Индид Облако".</p> Компания «Индид», российский разработчик решений в области защиты айдентити, представила ряд значимых функциональных … message https://www.itweek.ru/themes/detail.php?ID=235708 Fri, 09 Oct 2026 14:37:26 +0300 <p>Редакция IT Channel News подвела итоги рейтинга «Лучшие российские ИТ-дистрибьюторы» и назвала победителей. Опрос респондентов проводился с конца июня по середину сентября 2026 г. при помощи электронной почты, а также в форме личных и телефонных интервью. При формировании базы опроса за основу были взяты базы подписчиков IT Channel News и компаний, зарегистрированных в каталоге на сайте издания. На просьбу оценить работу дистрибьюторов и стать респондентами опроса откликнулись представители 325 ИТ-компаний из 72 населенных пунктов. П </p> <p>Лучшие ИТ-дистрибьюторы объявлены в 4 номинациях:</p> <ul> <li>«Лучший ИТ-Дистрибьютор для сборщика» (компании перечислены в алфавитном порядке): 3Logic Group, MERLION, NETLAB, OCS (первое место), Treolan;</li> <li>«Лучший ИТ-Дистрибьютор для системного интегратора» вошли следующие компании (перечислены в алфавитном порядке): MERLION, NETLAB, OCS (первое место), PROWAY, Treolan;</li> <li>«Лучший ИТ-Дистрибьютор систем информационной безопасности» (компании перечислены в алфавитном порядке): Axoft (первое место), MERLION, MONT, OCS, PROWAY;</li> <li>«Лучший ИТ-Дистрибьютор ПО» (компании перечислены в алфавитном порядке): Axoft (первое место), MERLION, MONT, OCS, Treolan.</li> </ul> <p>В этот раз, как и в предыдущем рейтинге, деятельность дистрибьюторов оценивалась по 13 критериям: «Цены»; «Программы формирования прибыли»; «Широта ассортимента»; «Наличие продукта на складе»; «Наличие системы B2В»; «Наличие четких стандартов (формализованных правил, процедур) в работе с партнерами»; «Гибкость, индивидуальный подход к партнерам»; «Способность решать проблемы»; «Управление отношениями с вендором»; «Финансовая поддержка»; «Консультации, помощь в разработке проектов»; «Маркетинговая поддержка», «Антикризисная поддержка». </p> Редакция IT Channel News подвела итоги рейтинга «Лучшие российские ИТ-дистрибьюторы» и назвала победителей. Опрос … message https://www.itweek.ru/themes/detail.php?ID=235706 Fri, 09 Oct 2026 10:48:22 +0300 <p><em>Десятилетиями производители конкурировали за счет масштаба, использования разницы в стоимости рабочей силы (арбитража) и оптимизации глобальных производственных сетей. Однако введение торговых пошлин, геополитическая фрагментация, нехватка кадров, волатильность цен на энергоносители и растущие ожидания клиентов вынуждают их переосмыслить процессы создания ценности. Программно-управляемое производство, промышленный искусственный интеллект, автоматизация и взаимосвязанные производственные процессы открывают новый путь к повышению конкурентоспособности, гибкости и устойчивости предприятий. Компании, которые добьются успеха в период до 2030 г., не просто будут инвестировать в технологии — они станут использовать технологии «умного» производства для фундаментальной трансформации своей операционной деятельности, подходов к инновациям и методов реагирования на изменения, пишут в корпоративном блоге Джордж Лоури, вице-президент и ведущий аналитик </em><em>Forrester</em><em>, и Майкл О’Грейди, аналитик </em><em>Forrester</em> <em>по прогнозированию.</em></p> <h3>Производственный сектор стоит на пороге перезагрузки показателей производительности</h3> <p>Производственный сектор сохраняет высокую эффективность, однако во многих регионах темпы роста замедлились. Например, производительность труда в промышленности США сегодня ниже уровня 2017 г., несмотря на значительные инвестиции в технологии, в то время как демографические проблемы и дефицит кадров сокращают доступность рабочей силы в крупнейших индустриальных экономиках.</p> <h3>Производителям необходимо создавать больше ценности, задействуя меньше персонала</h3> <p>Нехватка кадров создает критически важную проблему: производители должны создавать больше ценности, имея в распоряжении меньше работников. Раньше компании решали эту задачу путем переноса мощностей в регионы с более низкой стоимостью рабочей силы. Теперь же они все чаще обращаются к ПО, автоматизации и ИИ, чтобы повысить пропускную способность и гибкость, оптимизировать использование активов и снизить зависимость от трудоемких процессов. В результате происходит переход от производительности, зависящей от человеческого труда, к производительности, определяемой программными решениями.</p> <p>#IMAGE_235707#</p> <h3>ПО становится новым фактором конкурентного преимущества на производстве</h3> <p>Традиционно промышленное ПО рассматривалось как элемент инфраструктуры: необходимый, но редко играющий стратегическую роль. Forrester прогнозирует, что к 2030 г. ПО станет самой быстрорастущей категорией производственных технологий и займет значительно большую долю в общем объеме технологических расходов. Промышленный ИИ, аналитика, промышленный Интернет вещей (IIoT) и программно-управляемые производственные процессы превращают ПО из вспомогательного инструмента в фактор, обеспечивающий конкурентное преимущество.</p> <h3>Программно-управляемые заводы адаптируются к нестабильному спросу</h3> <p>Развитие программно-управляемого производства позволяет заводам становиться более гибкими и адаптивными. Вместо того чтобы ориентироваться на выпуск одного продукта в максимально возможных объемах, производители все чаще переходят к выпуску широкого ассортимента изделий, быстрее перенастраивают производство и оперативнее реагируют на изменения спроса. Гибкость критически важна, поскольку именно колебания спроса, а не ограничения производственных мощностей, зачастую становятся главным препятствием для полной загрузки предприятий.</p> <h3>ИИ меняет организацию производственных процессов</h3> <p>Применение ИИ в промышленности переходит от стадии экспериментов к практическому внедрению. Ведущие производители уже используют ИИ в таких сферах, как проектирование, разработка ПО, операционная деятельность, техническое обслуживание и управление цепочками поставок, чтобы ускорить создание продуктов, повысить надежность оборудования, оптимизировать планирование производства и сократить издержки.</p> <h3>Осторожность производителей сдерживает внедрение автономных агентов</h3> <p>Внедрение ИИ в производственном секторе находится на начальном этапе. Данные указывают на планы по расширению использования ИИ, однако опасения, связанные с кибербезопасностью, защитой интеллектуальной собственности и операционными рисками, сдерживают интерес к автономным ИИ-агентам. Для минимизации рисков производителям необходимо сочетать инновации со строгими принципами управления, эффективной работой с данными и контролем со стороны человека.</p> <h3>Проблема нехватки кадров сохраняется</h3> <p>Производственный сектор сталкивается со структурной проблемой нехватки рабочей силы. По оценкам Forrester, за последнее десятилетие численность занятых в мировом производстве сократилась примерно на 25 млн. человек. Старение населения, демографические изменения и дефицит квалифицированных кадров трансформируют рынки труда в Северной Америке, Европе, Японии и Китае. Одной лишь автоматизацией эту проблему не решить. Производителям требуется больше инженеров, техников, специалистов по ПО и работе с данными, экспертов по техобслуживанию, а также линейных сотрудников, владеющих цифровыми инструментами. Кроме того, необходимо переобучать действующих сотрудников для эффективной работы в связке с системами на базе ИИ и передовыми средствами автоматизации. В будущем конкурентное преимущество будет определяться не столько численностью персонала, сколько способностью использовать цифровые технологии.</p> <h3>Региональные стратегии в сфере производства все больше различаются</h3> <p>Производство остается глобальным, но производственные стратегии становятся все более региональными:</p> <ul> <li> США отдают приоритет передовому производству, производству полупроводников и переносу производства.</li> <li> Китай ускоренно развивает промышленную автоматизацию, робототехнику, полупроводниковую самодостаточность и секторы производства с более высокой добавленной стоимостью.</li> <li> Европа уделяет особое внимание промышленной автоматизации, инвестициям в энергетический переход, оборонному производству и устойчивости цепочек поставок.</li> <li> Мексика извлекает выгоду из ниаршоринга, регионализации цепочек поставок в Северной Америке и роста экспорта дорогостоящих промышленных товаров.</li> <li> Япония борется с демографическим спадом посредством автоматизации производства, применения робототехники и перехода к производству с более высокой добавленной стоимостью.</li> </ul> <p>Хотя приоритеты различаются, общая тема ясна: каждый регион инвестирует в технологии, чтобы компенсировать нагрузку на рабочую силу и повысить устойчивость.</p> <h3>Конкуренция за адаптивность, а не за стоимость</h3> <p>Возможно, самый важный урок для лидеров промышленных предприятий заключается в том, что конкурентоспособность производства будет все больше зависеть от адаптивности, а не от преимущества в затратах. Поскольку производители вынуждены реагировать на сбои в цепочках поставок, нехватку рабочей силы и регионализацию, интеллектуальное производство, автоматизация и ПО станут критически важными для операционной устойчивости.</p> <p>Наиболее успешные производители будут:</p> <ul> <li> Создавать программно-определяемые заводы, обеспечивающие гибкое и адаптируемое производство.</li> <li> Модернизировать системы управления производством, управление жизненным циклом продукции и платформы промышленных данных.</li> <li> Обеспечивать надежную интеграцию ИT-OT во все производственные операции.</li> <li>Инвестировать в промышленный ИИ, автоматизацию производства и передовую аналитику.</li> <li> Укреплять производственную кибербезопасность, управление и эксплуатационную устойчивость.</li> <li> Заниматься переподготовкой работников для все более цифровых производственных операций с использованием ИИ.</li> </ul> <p>Другими словами, трансформация производства требует организационных изменений, сопровождающих инвестиции в технологии.</p> <h3>Переход к интеллектуальным решениям с новой производственной архитектурой</h3> <p>Историческая ориентация на преимущества в затратах на рабочую силу и масштабе производства уступает место современному программно-определяемому производству, которое обеспечивает превосходную гибкость и устойчивость. Производители, которые сочетают промышленный ИИ, программно-определяемые операции, интеграцию ИТ-ОТ, трансформацию рабочей силы и эффективное управление, будут превосходить своих конкурентов до конца десятилетия. Те, кто рассматривает технологии как отдельную инвестицию, а не как основу новых операционных моделей производства, рискуют отстать.</p> <p>Следующее поколение лидеров промышленных предприятий выиграет не потому, что они производят продукцию дешевле, а потому, что смогут адаптироваться быстрее, чем все остальные.</p> Десятилетиями производители конкурировали за счет масштаба, использования разницы в стоимости рабочей силы (арбитража … article https://www.itweek.ru/themes/detail.php?ID=235704 Fri, 09 Oct 2026 10:38:51 +0300 <p><em>Ранее я</em><em> <a href="https://www.itweek.ru/security/article/detail.php?ID=235359">рассказала</a> об ИИ как возможном орудии атаки. Но есть и зеркальный риск: сами ИИ-системы становятся новой мишенью. </em><em>Рассмотрим</em><em>, где возникают уязвимости и как снижать эти риски.</em></p> <h3>Почему защита ИИ стала вызовом для отрасли</h3> <p>Чем активнее компании внедряют искусственный интеллект, тем заметнее разрыв между скоростью внедрения и готовностью защищать новые системы. Рынок инструментов AI Security пока находится на ранней стадии: отдельные решения уже появляются, но единых критериев эффективности и устоявшихся практик еще нет. Ситуация напоминает раннюю историю AppSec. В конце <nobr>2010-х</nobr> многим казалось, что достаточно защищать периметр и сеть, а код, библиотеки и pipeline можно оставить разработчикам. Довольно быстро выяснилось, что этого недостаточно. С ИИ происходит похожая трансформация: безопасность смещается от защиты инфраструктуры к контролю данных, моделей, агентов и всего процесса создания и использования ИИ-систем.</p> <p>Практическое следствие этого разрыва — потеря видимости. Не каждый руководитель по безопасности или архитектор может быстро ответить, где именно внутри компании используется ИИ, какие модели подключены и к каким данным они имеют доступ. Теневые сервисы сложно обнаруживать, число команд, работающих с моделями, растет, а способы тестирования пока не унифицированы. Управлять безопасностью того, чего компания не видит, невозможно. В итоге отсутствие контроля начинает тормозить уже само внедрение ИИ.</p> <p>Ситуация постепенно меняется. В России и за рубежом появляются AI gateway, guardrails, средства контроля данных, инструменты red teaming и оценки моделей. Но пока это отдельные классы решений, которые не складываются в единый зрелый процесс. Классическая защита сети остается необходимой, но она не отвечает на вопросы о происхождении модели, безопасности данных, поведении агента и допустимости его действий. Пока этот разрыв не закрыт, ИИ-система сама может стать точкой входа для атаки.</p> <h3>Основные векторы атаки на ИИ</h3> <p>Чтобы понять, где злоумышленник может атаковать ИИ-систему, угрозы нужно разложить по уровням. В упрощенной модели можно выделить три основных вектора: данные, цепочку поставок и взаимодействие с моделью через запросы и внешний контент.</p> <p>Первый вектор связан с данными. При развертывании ИИ внутри компании появляются датасеты, базы знаний, системные инструкции и история взаимодействия с моделью. Их могут пытаться извлечь, подменить или использовать для изменения поведения системы. История вокруг DeepSeek показала, что вопросы происхождения обучающих данных, защиты моделей и возможного извлечения знаний становятся предметом отдельного внимания отрасли. Для обычной компании риск еще практичнее: атака на данные бьет по основанию, на котором строится работа модели.</p> <p>Второй вектор затрагивает AI Supply Chain. В классической разработке уже существуют SCA, SBOM и практики проверки сторонних компонентов. С готовой ИИ-моделью все сложнее. Компании нужно понимать, откуда она получена, кто ее обновлял, какие зависимости входят в поставку и не изменилось ли ее поведение после обновления. Базовые способы проверки файлов и окружения есть, но поставить оценку самой модели на поток пока сложно. Поэтому безопасность цепочки поставок ИИ становится отдельным классом задач, а не расширением обычной проверки библиотек.</p> <p>Третий вектор — prompt injection. Он встречается в чат-ботах, ассистентах, корпоративном поиске и агентных системах. Инструкция может прийти не только от пользователя, но и из документа, веб-страницы или изображения, которое модель обрабатывает как часть контекста. Средства обнаружения и фильтрации таких атак уже существуют, хотя и работают неидеально. Но сложность защиты определяется не только самим запросом. Главное — какие права получила модель и что она может сделать после обработки вредоносной инструкции. Ошибка чат-бота заканчивается плохим ответом, а ошибка агента с доступом к почте, коду или корпоративным системам уже может стать полноценным инцидентом.</p> <h3>Защита через архитектуру</h3> <p>Первый уровень защиты закладывается не в фильтр перед моделью, а в архитектуру системы. Еще до внедрения нужно определить, с какими данными работает ИИ, какие инструменты он может вызывать, где требуется подтверждение человека и как фиксируются его действия. Исправлять эти ограничения после запуска обычно дороже и сложнее.</p> <p>Принцип минимальных привилегий должен применяться не только к сотрудникам, но и к ИИ-агентам. Если права пользователя не проверяются при обращении к данным через ИИ-помощника, разработчик может получить сведения о зарплатах, а маркетолог — доступ к юридическим документам. Модель в таком случае не ломает систему, она просто использует слишком широкие полномочия, которые ей выдали. Опереться при проектировании можно на формирующиеся стандарты и рекомендации, включая российские инициативы в этой области. Параллельно нужно обучать сотрудников: запрет без безопасной альтернативы почти гарантированно создает теневое использование внешних сервисов.</p> <p>Специальные средства защиты тоже необходимы, и их разработка уже идет как у российских вендоров, так и в open source. Но рынок пока фрагментирован: один продукт контролирует запросы, другой ищет утечки, третий тестирует модель. Поэтому рассчитывать на одну коробку, которая закроет весь класс рисков, пока рано.</p> <p>Минимальный практический шаг для компании — получить видимость собственного ИИ-ландшафта. Нужно понимать, какие публичные и внутренние сервисы используются, какие данные туда передаются, кто владеет системой и какие действия разрешены модели или агенту. Для этого придется честно признать, что сотрудники уже пользуются открытыми LLM, даже если формально компания их не внедряла. После этого можно разделять допустимые и рискованные сценарии, а не запрещать все подряд.</p> <p>В итоге защита ИИ строится из нескольких слоев: видимость, безопасная архитектура, управление доступом, обучение людей и специальные инструменты контроля. Здесь нет универсального порядка, в котором технология всегда должна стоять последней. Одних инструментов недостаточно, но без них невозможно контролировать данные, запросы и действия агентов в реальном времени. Главная задача — увидеть собственный ИИ-ландшафт и задать для него понятные границы. Тогда ИИ перестает быть слепой зоной и становится управляемым объектом риска.</p> <p>#IMAGE_235705#</p> Ранее я рассказала об ИИ как возможном орудии атаки. Но есть и зеркальный риск: сами ИИ-системы становятся … article Светлана Газизова, владелец продукта по безопасности ИИ компании UserGate https://www.itweek.ru/themes/detail.php?ID=235703 Thu, 08 Oct 2026 17:31:46 +0300 <p>Независимая аналитическая компания Apple Hills Digital при поддержке Selectel опубликовала результаты исследования «Облачные сервисы для ИИ: серверы с GPU и AI/ML-платформы». В отчёте представлен анализ и динамика российского рынка инфраструктурных и платформенных облачных решений для задач искусственного интеллекта по трём ключевым сегментам: виртуальные серверы с GPU (Virtual Server), выделенные серверы с GPU (Bare Metal) и AI/ML-платформы класса PaaS в 2022 — 2025 годах, а также сценарии развития до 2030 года.</p> <p>Совокупное потребление облачных серверов с GPU и AI/ML-платформ в России в 2025 году составило 65,5 млрд рублей. Почти две трети этой суммы, 40,8 млрд рублей (62%), приходится на внутреннее потребление — крупные финансовые и телеком-группы размещают ИИ-нагрузки у собственных провайдеров.</p> <p>Рыночное потребление, то есть затраты внешних заказчиков, составило 24,7 млрд рублей. Из них 17,6 млрд рублей (71%) пришлось на публичное облако:</p> <ul> <li>серверы с GPU. Рыночное потребление — 15 млрд рублей, из них 8,2 млрд рублей — в публичном облаке. Этот сегмент вырос к 2024 году на 68,7%;</li> <li>AI/ML-платформы. Рыночное потребление — 9,7 млрд рублей, из них 9,4 млрд рублей — в публичном облаке. Платформы уже обогнали публичный рынок серверов с GPU;</li> <li>частное облако. На него приходится 45% рыночного потребления серверов с GPU против 27% в IaaS в целом. Банки, госсектор и субъекты КИИ держат ИИ-нагрузки с чувствительными данными в выделенном контуре. AI/ML-платформы, напротив, почти полностью потребляются из публичного облака (97%).</li> </ul> <p>В <nobr>2022–2025</nobr> годах рынок серверов с GPU в публичном облаке рос в среднем на 48,4% в год, рынок AI/ML-платформ — на 41,9% в год. Данные за первое полугодие 2026 года говорят о замедлении рынка, хотя по неполному периоду пока нельзя точно определить среднесрочную траекторию. Прогноз построен в двух сценариях: «Продолжение тренда», при котором торможение 2026 года временное, и «Замедление роста», при котором оно закрепляется.</p> <p>К 2030 году рынок серверов с GPU в публичном облаке составит от 21,2 до 36,5 млрд рублей (среднегодовой рост <nobr>20,9–34,8%),</nobr> рынок AI/ML-платформ — от 25,9 до 40,7 млрд рублей <nobr>(22,4–34%).</nobr> В сумме это <nobr>47–77</nobr> млрд рублей против 17,6 млрд рублей в 2025 году.</p> <p>ИИ остается одним из приоритетов новых ИТ-бюджетов. Рост сегмента серверов с GPU в публичном облаке будет определять не только спрос, но и доступность вычислительных ресурсов. Официальные поставки GPU в Россию прекращены, дефицит энергомощностей в Московском регионе смещает ввод новых площадок в регионы. Высокая ключевая ставка и дорогое оборудование, а также требования к безопасности и локализации данных делают облачные GPU выгодной альтернативой созданию собственной ИИ-инфраструктуры и поддерживают выбор модели аренды вместо покупки. </p> <p>В то же время рост объема сегмента AI/ML-платформы уже больше сегмента серверов с GPU в публичном облаке и даже в сценарии прогноза «Замедление роста» растут в среднем на 22,4% в год до 2030 года. Заказчики все чаще приходят за готовой средой и моделями, а не за сервером.</p> <p>24% компаний уже используют ИИ в облаке, еще 18% планируют начать в течение 2026 года и 4% проводят пилоты. Всего это 46% опрошенных. </p> <p>Главные причины идти в облако с ИИ — готовые модели и сервисы (36%), и ускорение экспериментов (32%).</p> <p>При выборе провайдера заказчики чаще называют предобученные модели (23%) и интеграцию с данными и аналитикой (23%), чем GPU-оборудование (17%) и стоимость (16%).</p> <p>Как вариант развертывания ИИ лидирует open-source ИИ в облаке (37%); облачные ИИ-агенты и дообученные LLM используют по 27%.</p> <p>41% компаний работают с ИИ самостоятельно, а провайдер для них остается только поставщиком инфраструктуры.</p> <p>«Сегодня потребление облачных инфраструктурных и платформенных сервисов для создания ИИ решений внутри экосистем крупнейших финансовых и телекоммуникационных компаний превосходит рыночное потребление подобных сервисов. Организации и предприятия готовы арендовать GPU, но часто ограничены внутренними политиками, финансами и отсутствием приемлемых предложений от провайдеров. Рынок облачных сервисов для ИИ в России сейчас ограничен скорее предложением, чем спросом. Переход от простой аренды серверов к среде разработки и эксплуатации ИИ решений также будет поддерживать спрос на облачные сервисы. Сегмент AI/ML-платформ уже обогнал рынок инфраструктуры с GPU и сохраняет потенциал роста», — отметила Елена Семеновская, аналитик Apple Hills Digital.</p> <p>«Провайдеры ИТ-инфраструктуры значительно ускоряют внедрение искусственного интеллекта в бизнес за счет совокупности факторов: предоставления серверного оборудования с GPU по модели аренды, сформированного безопасного контура и аттестованной инфраструктуры, а также экспертизы в работе с искусственным интеллектом. За 9 месяцев 2026 года мы зафиксировали увеличение потребления серверов с GPU в 2,6 раза по отношению к аналогичному периоду прошлого года. Основной спрос приходится на представителей крупного бизнеса», — отметил Константин Ансимов, директор по продуктам Selectel.</p> Независимая аналитическая компания Apple Hills Digital при поддержке Selectel опубликовала результаты исследования «Облачные … message https://www.itweek.ru/themes/detail.php?ID=235702 Thu, 08 Oct 2026 17:29:13 +0300 <p>В первом полугодии 2026 года российский рынок персональных систем столкнулся с заметными изменениями. Нехватка комплектующих отразилась на стоимости готовых устройств, а игроки в то же время адаптировались к новым требованиям: обязательной маркировке и ужесточению правил ввоза техники. На этом фоне компании пересматривали планы обновления оборудования. Аналитики OCS совместно с экспертами ИТ-бренда Nerpa изучили структуру спроса в корпоративном секторе и сравнили её с данными первого полугодия 2025 года.</p> <p>По наблюдениям специалистов OCS, компании выбирают компьютерную технику со сбалансированными техническими характеристиками. Модели, которые раньше относились к бюджетным, из-за роста стоимости комплектующих переместились в более высокий ценовой сегмент. В результате фокус бизнеса постепенно смещается с минимально достаточных конфигураций на более универсальные решения с большим сроком актуальности.</p> <p>Например, в сегменте ноутбуков увеличился спрос на устройства с оперативной памятью 16 ГБ и SSD объёмом 512 ГБ. По сравнению с первым полугодием 2025 года продажи таких моделей выросли почти на 20% и превысили 50% рынка. Интерес к решениям с ОЗУ 8 ГБ и SSD 256 ГБ при этом снизился до 5% от общих закупок компаний. Такие характеристики по-прежнему подходят для базовых офисных сценариев, однако возможности устройств заметно ограничены при многозадачной работе. В условиях роста цен компании чаще выбирают конфигурацию ноутбука с оперативной памятью 16 ГБ и SSD 512 ГБ как более универсальную для типового корпоративного ПО и одновременной работы с несколькими приложениями. </p> <p>Схожая тенденция сложилась и в сегменте системных блоков. Сочетание оперативной памяти 16 ГБ и SSD объёмом 512 ГБ становится базовой конфигурацией для компаний. По данным OCS и Nerpa, в первом полугодии 2026 года на такие устройства пришлось 73% продаж в анализируемой категории, тогда как год назад их доля не превышала 30%. Одновременно снижается спрос на системные блоки с накопителями объёмом 256 ГБ: при сравнительно небольшой разнице в стоимости конфигурация с SSD 512 ГБ даёт больше возможностей на весь срок эксплуатации устройства. При этом компании реже приобретают избыточные для типовых рабочих мест объёмы оперативной памяти. Доля решений с ОЗУ 32 ГБ и более по сравнению с 2025 годом сократилась с 20% до 5%: такие устройства приобретают преимущественно для узкоспециализированных задач.</p> <p>В сегменте рабочих станций, напротив, растут требования к производительности и объёму оперативной памяти. В 2025 году наиболее популярными были модели с ОЗУ 32 ГБ, но теперь спрос смещается в сторону конфигураций с 64 ГБ и более. В первом полугодии на такие решения пришлось больше половины всех проданных устройств. Это связано со спецификой применения рабочих станций: программное обеспечение для моделирования, проектирования и сложных вычислений становится более ресурсоёмким. При этом в выборе накопителей спрос оказывается более полярным. Компании чаще приобретают рабочие станции с SSD на 1 ТБ, а для задач, где большой локальный объём хранения не требуется, сформировался отдельный, более бюджетный сегмент с SSD 256 ГБ.</p> <p>В разрезе производителей предпочтения корпоративных заказчиков меняются медленнее, чем конфигурации устройств. Например, около половины персональных систем, проданных в первой половине года, приходится на зарубежные бренды Acer и Lenovo. Особенно заметна эта тенденция в сегменте ноутбуков, где доля импортных решений достигла 80%. Эксперты связывают это в том числе с привычностью оборудования и накопленным опытом его эксплуатации в корпоративной инфраструктуре. При этом российские бренды укрепляют позиции в отдельных категориях: в сегменте системных блоков и рабочих станций отечественные решения уже занимают существенную долю.</p> <p>«Напряжённость на рынке памяти и накопителей сохраняется, поэтому подход компаний к конфигурациям вряд ли быстро изменится. Часть заказчиков, которые откладывали обновление парка оборудования, могут вернуться к закупкам в конце года, чтобы закрыть запланированные проекты и заменить устаревшую технику. На этом фоне ноутбуки и системные блоки с ОЗУ 16 ГБ и SSD 512 ГБ имеют все шансы укрепить позиции на рынке, заменив более простые решения», — отметила Наталья Гончарова, исполнительный директор ИТ-бренда Nerpa.</p> <p>Большие объёмы оперативной памяти и накопителей останутся востребованы там, где требуются высокие рабочие нагрузки: при работе с графикой, виртуальными машинами, сложными средами разработки и вычислительными задачами. Практика закупки оборудования со значительным запасом технических характеристик, напротив, станет менее распространённой: компании всё внимательнее соотносят стоимость устройства с реальным сценарием его использования.</p> <p>Консервативность сохранится и в выборе брендов. При росте стоимости техники ИТ-подразделения не готовы массово переводить сотрудников на новые для компании модели без предварительного тестирования. Поэтому в тех категориях, где российские и новые азиатские бренды ещё не получили широкого распространения, их внедрение будет идти через пилотные партии и сбор обратной связи. В сегменте системных блоков и рабочих станций этот процесс уже продвинулся заметно дальше, чем в ноутбуках. Российские решения продолжат набирать долю рынка, однако скорость замены брендов будет существенно зависеть от категорий оборудования и требований конкретных заказчиков.</p> В первом полугодии 2026 года российский рынок персональных систем столкнулся с заметными изменениями. Нехватка … message https://www.itweek.ru/themes/detail.php?ID=235701 Thu, 08 Oct 2026 17:28:11 +0300 <p>Крупный российский бизнес может потребить 912,5 трлн ИИ-токенов в 2026 году, что следует из сценарной оценки Orion soft. В денежном выражении такой объем потребления составляет около 237 млрд рублей.</p> <p>Открытой статистики по совокупному корпоративному потреблению токенов в России нет, поэтому Orion soft использовал сценарную оценку. В расчет вошли 2 тыс. крупнейших российских компаний с выручкой около 10 млрд рублей и выше. В базовом сценарии Orion soft предполагает, что одна такая компания в среднем обрабатывает около 500 тыс. запросов к большим языковым моделям в сутки при средней длине запроса 2,5 тыс. токенов. Это соответствует примерно 456 млрд токенов в год на одну компанию.</p> <p>В денежном выражении такой объем потребления соответствует примерно 237 млрд рублей в год. При расчетной средней стоимости 260 руб. за 1 млн токенов итоговая сумма составляет 237,25 млрд рублей. Оценка объединяет расходы на облачные модели и расчетную себестоимость инференса в собственной инфраструктуре и не включает затраты на внедрение ИИ, обучение моделей и содержание ИИ-команд, а также фактические расходы компаний, которые напрямую зависят от выбора моделей и загрузки инфраструктуры.</p> <p>Среднюю стоимость в Orion soft рассчитали с учетом предполагаемой доли каждого способа использования LLM в общем объеме токенов. В модели на локальные решения приходится 45% потребления при стоимости 180 руб. за 1 млн токенов, на модели Яндекса и Сбера через API — 25% при 350 руб., на Qwen, DeepSeek и другие модели через российские облачные платформы — 20% при 220 руб., на зарубежные API — 10% при 450 руб. Взвешенная стоимость составляет 257,5 руб. за 1 млн токенов и округляется до 260 руб. Доли и ставки являются допущениями сценарной модели, где для локальных решений используется оценка себестоимости, а для облачных — усредненной платы за использование моделей.</p> <p>Отдельным драйвером роста потребления становятся ИИ-агенты. В отличие от обычного ассистента, агент самостоятельно планирует последовательность действий и несколько раз обращается к модели в процессе выполнения одной задачи. По оценке Orion soft, обычный запрос в корпоративном чате требует около 2,5 тыс. токенов, тогда как агентская задача с шестью обращениями к модели — около 34 тыс., то есть примерно в 14 раз больше.</p> <p>По расчетам Orion soft, типовой ответ клиенту может стоить около 0,04 руб., поиск по корпоративной базе знаний — 0,19 руб., обработка документа — 0,73 руб., выполнение задачи ИИ-агентом — 1,78 руб., а сложная задача coding-агента — уже 114,77 руб. Расчеты основаны на тарифах используемых моделей на сентябрь 2026 года и учитывают только стоимость инференса без расходов на интеграцию, ИИ-команду и внутреннюю инфраструктуру.</p> <p>В сценарии на 2027 год потребление ИИ-токенов крупным российским бизнесом по оценке Orion soft может вырасти примерно на <nobr>25–50%,</nobr> до <nobr>1,14–1,37</nobr> квадриллиона токенов. Такой рост возможен, если при неизменном общем числе задач <nobr>2–4%</nobr> обычных запросов со средним потреблением 2,5 тыс. токенов будут заменены агентскими задачами по 34 тыс. токенов. Эта доля принята как сценарное допущение. При сохранении средней стоимости на уровне 260 руб. за 1 млн токенов денежный эквивалент потребления составит около <nobr>297–357</nobr> млрд руб. в год.</p> <p>Рост потребления ИИ ставит перед бизнесом новую задачу — управлять не только доступом к моделям, но и экономикой их использования. Один и тот же объем токенов может иметь принципиально разную стоимость и приносить разный бизнес-результат в зависимости от модели, сложности задачи, объема контекста и количества обращений к LLM.</p> <p>Никита Векессер, руководитель продуктов Nova AI и StarGuard AI Orion soft, отметил: «По мере масштабирования ИИ токены превращаются из технической метрики в заметную статью корпоративных расходов. Но само количество токенов ничего не говорит об эффективности: один и тот же объем вычислений может использоваться для ответа в корпоративном чате или для сложной задачи разработки и создавать совершенно разный бизнес-результат. Поэтому компаниям важно переходить от подсчета токенов к оценке стоимости завершенной ИИ-операции и полученного эффекта. С распространением агентов эта задача станет еще актуальнее: один пользовательский запрос превращается в цепочку обращений к модели, увеличивая нагрузку на инфраструктуру и стоимость эксплуатации ИИ».</p> Крупный российский бизнес может потребить 912,5 трлн ИИ-токенов в 2026 году, что следует из сценарной оценки Orion … message https://www.itweek.ru/themes/detail.php?ID=235700 Thu, 08 Oct 2026 17:27:15 +0300 <p>Институт статистических исследований и экономики знаний (ИСИЭЗ) НИУ ВШЭ оценил, какими навыками работы с искусственным интеллектом (ИИ) обладают пользователи сервисов на его основе, насколько им доверяют и какие функции готовы поручить ИИ.</p> <p>Притом что уже четыре из пяти российских интернет-пользователей применяют ИИ-сервисы в повседневной жизни, большинство пока ограничивается поверхностным использованием технологии, а отношение к ней в целом настороженное.</p> <p>Уровень ИИ-грамотности оценивали по самооценке 10 компетенций, сгруппированных в два блока: знаний принципов работы ИИ и умений применять его на практике. Как работает ИИ, понимают 52% пользователей, его возможности и ограничения осознают 40%, о разных типах ИИ знают 33%. Теоретическая осведомленность не всегда сопровождается критической оценкой и безопасным использованием: результаты работы сервисов регулярно проверяет примерно каждый четвертый, о том, какую информацию безопасно и допустимо передавать ИИ, задумываются 37% (35% это несвойственно). Дорабатывать ИИ-приложения под свои задачи умеют 24%, настраивать их для решения повторяющихся задач — 18%. Более продвинутые навыки из блока практических отмечают еще реже: проектировать ИИ-решения, например обучать модели, умеют 15%; выстраивать сложные сценарии работы с ИИ, включая создание агентов, — 14%.</p> <p>Уровень ИИ-грамотности прежде всего различается по возрасту, затем — по материальному положению. Среди пользователей младших возрастных групп — подростков <nobr>14–17</nobr> лет и молодежи <nobr>18–24</nobr> лет — хотя бы одной теоретической компетенцией обладают <nobr>83–84%,</nobr> а практическим навыком — <nobr>74–75%.</nobr> Среди обеспеченных респондентов соответствующие доли составляют 82% и 67%, в целом по выборке — 63% и 51%, а среди низкодоходных респондентов — 59% и 53%. Различия по полу и месту жительства слабее: минимум одну из десяти компетенций отметили 68% женщин и 75% мужчин.</p> <p>Отношение к ИИ у россиян остается настороженным: недоверие выражают 29%, тогда как полностью или скорее доверяют 22%. Доверие выше среди ежедневно обращающихся к ИИ-сервисам (43%) и людей с высоким уровнем ИИ-грамотности (51%); ИИ-скептиков в этих группах 12% и 10% соответственно. С большим доверием к ИИ относится молодежь <nobr>14–24</nobr> лет (35%); в старших группах показатель примерно вдвое ниже.</p> <p>Примерно треть респондентов готовы доверить ИИ повседневные задачи: планирование дня, выбор или заказ товаров. В сферах с высокой ценой ошибки, таких как выбор профессии, отбор кандидатов на работу, управление общественным транспортом или личными финансами, готов довериться решениям ИИ примерно каждый пятый. Еще реже ИИ готовы поручить подбор лекарств (16%), постановку диагноза (13%), вынесение судебных приговоров (12%) и выбор спутника жизни (11%).</p> <p>ИИ-сервисы уже вошли в повседневный обиход многих россиян, однако их широкое использование опережает формирование навыков эффективной и безопасной работы с технологией. ИИ-грамотность выше у молодых и обеспеченных пользователей, а доверие к ИИ чаще выражают ежедневные пользователи сервисов и люди с высоким уровнем цифровой грамотности. Эта связь позволяет предположить, что расширение опыта применения может укреплять доверие; важное условие — развитие ИИ-грамотности.</p> Институт статистических исследований и экономики знаний (ИСИЭЗ) НИУ ВШЭ оценил, какими навыками работы с искусственным … message https://www.itweek.ru/themes/detail.php?ID=235699 Thu, 08 Oct 2026 17:25:52 +0300 <p>Компании «Аладдин» и «Увеон — облачные технологии» (входит в «Группу Астра») подтвердили корректность совместного функционирования корпоративной системы централизованного управления JaCarta Management System 4LX (JMS 4LX) для Linux с платформой для управления инфраструктурой виртуальных рабочих мест Termidesk VDI.</p> <p>Совместимость решений подтверждена сертификатом, выданным по результатам соответствующих испытаний. Для заказчиков это означает возможность использовать JaCarta Management System 4LX для Linux и Termidesk VDI в составе единой ИТ-инфраструктуры на базе отечественных решений с подтвержденной корректностью взаимодействия компонентов. </p> <p>Совместное использование JMS 4LX и Termidesk VDI позволяет централизованно управлять средствами аутентификации и организовать доверенный доступ к виртуальной рабочей среде. Комплексное решение обеспечивает защищённый доступ как к виртуальным машинам, так и к отдельным приложениям, гарантируя соответствие требованиям Приказа № 117 ФСТЭК России.</p> <p>JaCarta Management System 4LX для Linux — это система централизованного управления средствами аутентификации и электронной подписи, защищёнными носителями информации, аппаратными OTP/U2F-токенами и программными аутентификаторами. В её состав входят высокопроизводительный сервер аутентификации JaCarta Authentication Server (JAS), сервис Aladdin 2FA и JaCarta Identity Provider (JIP) — провайдер аутентификации/авторизации в приложениях с поддержкой протоколов SAML и OIDC.</p> <p>Termidesk VDI — это мультиплатформенное решение для создания инфраструктуры виртуальных рабочих мест и организации безопасной удаленной работы сотрудников.</p> <p>«Заказчикам важно не только наличие отдельных средств защиты, но и возможность интегрировать их в единую ИТ-инфраструктуру. Подтверждение совместимости JaCarta Management System 4LX для Linux и Termidesk VDI позволяет объединить централизованное управление аутентификацией и инфраструктуру виртуальных рабочих мест, обеспечивая пользователям защищенный доступ к виртуальным ресурсам», — прокомментировал Станислав Винарский, менеджер по развитию бизнеса JMS/JAS/JIP, «Аладдин».</p> <p>«При внедрении VDI заказчику важно интегрироваться с уже работающими механизмами доступа, а не строить отдельную систему аутентификации только для виртуальных рабочих мест. Поэтому мы проверяли не один базовый сценарий входа, а разные сочетания Kerberos, PKI, Push и одноразовых кодов. Теперь у нас есть зафиксированный набор конфигураций, которые можно использовать при совместной работе Termidesk и JaCarta», — прокомментировал Сергей Халяпин, директор по развитию новых рынков и технологических альянсов «Увеон — облачные технологии».</p> Компании «Аладдин» и «Увеон — облачные технологии» (входит в «Группу Астра») подтвердили корректность совместного … message https://www.itweek.ru/themes/detail.php?ID=235698 Thu, 08 Oct 2026 14:45:07 +0300 <p>Компания «Клеверенс», разработчик программного обеспечения для автоматизации товарного учета по штрихкодам, и «Актив», крупнейший российский производитель аппаратных средств защиты информации, успешно завершили тестовые испытания на совместимость своих продуктов. По результатам был подписан официальный сертификат, подтверждающий корректную и стабильную работу устройств Рутокен с программным обеспечением «Фабрика 15» для терминалов сбора данных (ТСД).</p> <p>Испытания доказали полную технологическую совместимость мобильной платформы Mobile SMARTS со следующими ключевыми носителями:</p> <ul> <li>Рутокен ЭЦП 3.0 (включая модели с поддержкой NFC для беспроводной работы);</li> <li>Смарт-карта Рутокен ЭЦП 3.0.</li> </ul> <p>По итогам проверки устройства Рутокен официально внесены в список рекомендуемых ключевых носителей для работы с ПО «Клеверенс».</p> <p>Интеграция решений обеспечивает бесшовную и надежную авторизацию сотрудников, а также безопасную работу с квалифицированной электронной подписью (КЭП) на мобильных терминалах сбора данных. Использование USB-токенов и смарт-карт Рутокен позволяет защитить данные от несанкционированного доступа при выполнении складских, торговых и производственных операций без необходимости использования сложных сторонних надстроек, а также обеспечивает авторство и неизменность подписанных электронных документов.</p> <p>Партнерство компаний «Клеверенс» и «Актив» направлено на решение ключевых задач современного B2B-сегмента — сочетания высокой скорости бизнес-процессов с бескомпромиссным уровнем информационной безопасности.</p> <p>Что дает решение клиентам:</p> <ol> <li>соответствие требованиям законодательства. Легкая и юридически значимая работа с маркированными товарами, электронными накладными и документами, требующими сертификата КЭП прямо на складе или в торговой точке. Чтобы подписать документ при использовании Рутокен ЭЦП 3.0 NFC, в момент подписания потребуется приложить Рутокен к ТСД и подтвердить действие;</li> <li>строгий контроль доступа. Исключение рисков работы под чужими учетными записями за счет использования многофакторной аутентификации с применением устройств Рутокен;</li> <li>экономия ресурсов. Готовое, «из коробки», сертифицированное решение снижает затраты на внедрение, настройку и техническую поддержку ИТ-инфраструктуры.</li> </ol> <p>Николай Стариков, руководитель отдела продаж компании «Клеверенс», отметил: «В современных реалиях автоматизации производства, складов и ритейла безопасность данных уже не является отдельной задачей — она стала неотъемлемой частью базовых бизнес-процессов. Для нас важно, чтобы нашим пользователям на складе и в магазине было удобно работать с ТСД, а руководству компаний, автоматизирующих учет, была гарантирована полная защита операций и юридическая значимость подписываемых документов. Подтвержденная совместимость приложений „Клеверенса“ с устройствами Рутокен — это важный шаг в развитии нашего технологического и бизнес-партнерства с компанией „Актив“. Мы предлагаем рынку проверенное связующее решение, которое внедряется без „костылей“, обеспечивая заказчикам одновременно максимальную скорость мобильной сборки/приемки и высокий уровень информационной безопасности».</p> <p>Ксения Шаврова, руководитель отдела по работе с технологическими партнерами компании «Актив», прокомментировала: «Для нас этот кейс уникален — это первый в России сценарий применения мобильной электронной подписи с Рутокен непосредственно на складах, прямо на терминалах сбора данных. Мы рады дать рынку еще один удобный и надежный способ подписывать документы вне офиса, без потери юридической силы и скорости операций».</p> Компания «Клеверенс», разработчик программного обеспечения для автоматизации товарного учета по штрихкодам, и «Актив» … message 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 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 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 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 Илья Захаров, директор департамента мониторинга “Группы Астра” 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 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 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 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 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 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 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 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 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 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