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=235953 Fri, 13 Nov 2026 18:21:36 +0300 <p>Голосовые ИИ-агенты на базе новых моделей Yandex AI Studio смогут вести более естественный диалог с пользователями и самостоятельно решать больше задач без участия оператора. ИИ-агенты смогут менять интонацию в зависимости от контекста разговора, реагировать на перебивания и быстро выполнять многошаговые запросы клиентов. Благодаря новым моделям бизнес сможет в десятки раз увеличить долю обращений, которые решаются без участия человека.</p> <p>Компании могут создавать и настраивать голосовых агентов с помощью текстовых инструкций, подключать их к корпоративным системам и тестировать различные сценарии обслуживания клиентов прямо в интерфейсе платформы — без необходимости разрабатывать прототип с нуля.</p> <p>Модель TTS Live анализирует смысл текста и самостоятельно подбирает интонацию, расставляет акценты и паузы. Компании могут выбирать для агентов разные голоса и манеры речи — от уверенной для продаж до мягкой для клиентской поддержки и сдержанной для уведомлений. Также доступны специальные варианты для медицинских сценариев и аудиогидов.</p> <p>Обновленная модель Speech Realtime Max позволяет создавать голосовых агентов, способных решать несколько связанных задач за один звонок. Например, ИИ может перенести запись, рассчитать стоимость, применить скидку и отправить ссылку на оплату, обращаясь к корпоративным системам в реальном времени. Если клиент прерывает агента, то он останавливается и реагирует на новую реплику. При этом в истории диалога учитывается только фактически озвученная часть ответа, что предотвращает путаницу и дублирование информации.</p> <p>«В обычном разговоре люди часто перебивают друг друга и меняют тему. Поэтому важно, чтобы голосовой агент умел не только реагировать на новые реплики, но и понимал, что уже успел сказать, а что собеседник не дослушал. При этом речь агента должна звучать естественно — с правильными паузами и интонациями», — рассказала Елена Белоброва, руководитель направления развития бизнеса ML&AI сервисов Yandex B2B Tech.</p> <p>Речевые технологии Yandex SpeechKit используют компании из разных отраслей — от образования и туризма до ритейла и городского управления. Среди компаний сервисы «Литрес», «ДоДо Пицца», «Интернет-урок», МТС Exolve, ритейлер X5 Retail Group и другие.</p> Голосовые ИИ-агенты на базе новых моделей Yandex AI Studio смогут вести более естественный диалог с пользователями … message https://www.itweek.ru/themes/detail.php?ID=235952 Fri, 13 Nov 2026 18:20:53 +0300 <p>Институт статистических исследований и экономики знаний (ИСИЭЗ) НИУ ВШЭ изучил устройство масштабной программы K-Moonshot, запущенной в Республике Корея в 2026 году для консолидации инструментов научно-технологической политики и ускорения исследований и разработок в стране.</p> <p>Основную часть исследований и разработок в Республике Корее выполняют организации предпринимательского сектора (по данным ОЭСР, на его долю в 2024 г. приходилось 81,4% ВЗИР), и сектор науки страны в значительной мере ориентирован на прикладные задачи с коротким горизонтом планирования. Чтобы преодолеть этот дисбаланс, государство перешло от разрозненных мер поддержки к их консолидации в рамках единых научно-технологических приоритетов. Этот подход воплощает программа K-Moonshot, которую запустило Министерство науки и ИКТ (MSIT) в начале 2026 г.</p> <p>Программа K-Moonshot выстроена на основе 12 национальных миссий, сгруппированных по восьми стратегическим направлениям. Ключевым нововведением стало требование интеграции ИИ во все миссии, а также установление конкретных целевых показателей с горизонтом реализации до 2035 г. Ориентиры определены с учетом анализа передовых мировых научных достижений и технологических дорожных карт стран-конкурентов, прежде всего США (уровень развития стратегических технологий Республики Корея предполагается сократить до 85% от уровня США к 2030 г., в 2022 г. — 81,5%). При этом в расчеты закладывалось фундаментальное допущение, что интеграция ИИ должна как минимум удвоить исследовательскую продуктивность, и это позволит стране совершить «скачок», пропустив промежуточные этапы технологического развития и сформировав существенное стратегическое преимущество.</p> <p>Финансирование программы опирается на бюджетные ассигнования и частные вложения. В формате государственно-частного партнерства к программе уже присоединилась 161 компания: 88 фирм формируют технологическое ядро по трем направлениям — модели ИИ; вычисления и сети; данные. Еще 73 компании представляют отрасли, связанные с конкретными миссиями. Среди участников — Samsung, SK, LG и Hyundai Motor Group. В 2026 г. из национального бюджета по линии MSIT на K-Moonshot выделено 400 млрд вон (24,4 млрд руб.). Масштаб корпоративных вложений иллюстрирует план Hyundai Motor Group направить до 2030 г. около 125,2 трлн вон (7,6 трлн руб.) на развитие робототехники и ИИ. Крупные компании также возглавляют консорциумы, реализующие проекты в рамках миссий. Например, LG Electronics координирует разработку гуманоидных роботов, а Samsung Heavy Industries участвует в создании судов с малыми модульными реакторами. В разработку суверенных базовых моделей ИИ вовлечены пять консорциумов под руководством LG. Международное сотрудничество развивается при участии Google DeepMind, которая открывает в Сеуле исследовательский кампус для разработки моделей ИИ для исследований в интересах национальных миссий.</p> <p>Оперативную координацию K-Moonshot обеспечивает постоянная межведомственная группа с участием директоров департаментов профильных министерств и представителей исследовательских институтов. Координационный узел программы — Национальный центр стратегии в области ИИ (NAIS) при Национальном научно-исследовательском совете (NST), объединяющий 23 государственных исследовательских института. Проектные директора NAIS наделены межведомственными полномочиями оперативно перераспределять средства между участниками консорциумов и корректировать дорожные карты миссий, минуя традиционные бюрократические процедуры.</p> <p>Кадровое обеспечение программы K-Moonshot предусматривает как меры, непосредственно связанные с ее миссиями, так и более широкие национальные программы подготовки, поддержки и привлечения исследователей, и опирается на многоуровневую экосистему грантов и стипендий, администрируемую преимущественно NST и Министерством науки и ИКТ. Подробнее о ней в полном обзоре.</p> <p>Михаил Гершман, директор Центра научно-технической, инновационной и информационной политики ИСИЭЗ НИУ ВШЭ, прокомментировал: «В условиях усиливающейся глобальной конкуренции Республика Корея перестраивает модель управления научно-технологическим развитием, консолидируя технологические приоритеты и меры поддержки, устанавливая амбициозные цели на десятилетнем горизонте и обеспечивая долгосрочное финансирование исследований. Отдельного внимания заслуживает корейский подход к подготовке и удержанию научных кадров: государство поддерживает исследователей на разных этапах карьеры — от магистратуры и аспирантуры до постдокторской подготовки, с помощью крупных и „длинных“ (до девяти лет) грантов привлекает ведущих ученых, в том числе из-за рубежа, стимулирует организации к найму целых исследовательских команд. Схожие принципы и механизмы могли бы быть последовательно адаптированы и в российском контексте, в том числе в рамках реализации национальных проектов технологического лидерства».</p> Институт статистических исследований и экономики знаний (ИСИЭЗ) НИУ ВШЭ изучил устройство масштабной программы K-Moonshot … message https://www.itweek.ru/themes/detail.php?ID=235951 Fri, 13 Nov 2026 18:18:45 +0300 <p>Международные ограничения лишают российские компании не только прямого доступа к зарубежным нейросетям по международным тарифам, но и возможности полноценно использовать Zero Data Retention (ZDR) — режим, при котором поставщик обязуется не сохранять содержимое запросов и ответов после обработки. Ни один из трех рассмотренных российских облачных провайдеров не закрепляет полноценный ZDR в изученных публичных договорах, тогда как зарубежные поставщики предлагают его по соглашению, через настройки API или по умолчанию. При этом стоимость доступа к зарубежным моделям через российские платформы оказывается в <nobr>1,6-9</nobr> раз выше международных тарифов. К таким выводам пришли аналитики российской платформы для создания ИИ-агентов Nodul, изучив тарифы и политики обработки данных 15 поставщиков ИИ-моделей.</p> <p>Zero Data Retention позволяет компаниям использовать внешние нейросети без сохранения содержимого запросов и ответов поставщиком после обработки в пределах установленных условий. При этом при разработке программного обеспечения ИИ-агенту нередко требуется доступ к корпоративному репозиторию. При подключении к репозиторию агент получает возможность анализировать исходный код, архитектуру приложения, внутренние зависимости, структуру баз данных и конфигурации. В результате во внешний API передается значительно больше корпоративной информации, чем содержится в первоначальном запросе разработчика.</p> <p>Nodul сравнил политики хранения данных российских и зарубежных ИИ-провайдеров. OpenAI и Anthropic предоставляют ZDR после индивидуального согласования, xAI позволяет самостоятельно включить функцию в настройках при ее доступности, а Google Cloud предусматривает сочетание договорных условий и технической конфигурации.</p> <p>У зарубежных агрегаторов ZDR зачастую доступен без индивидуального согласования. Fireworks AI заявляет его по умолчанию для стандартного инференса открытых моделей, Novita AI закрепляет соответствующую политику в условиях обслуживания, Together AI позволяет самостоятельно отключить хранение запросов, а OpenRouter — выбирать маршруты с ZDR.</p> <p>В то же время ни один из трех рассмотренных российских провайдеров — Yandex AI Studio, GigaChat API и Cloud.ru — не закрепляет ZDR в договорах. Аналитики не обнаружили в договорах российских поставщиков таких гарантий. При этом компании предлагают отдельные механизмы защиты информации. Yandex AI Studio позволяет отключить логирование запросов для улучшения сервиса, однако Responses API может сохранять результаты до 30 дней. GigaChat API декларирует ограничения на хранение данных и использование запросов для обучения. Cloud.ru предоставляет доступ к моделям через российскую инфраструктуру, однако локальное размещение данных не равнозначно обязательству не сохранять запросы и ответы.</p> <p>Ограничения прямого подключения к зарубежным API вынуждают российский бизнес использовать альтернативные каналы доступа. Одним из них становятся отечественные облачные платформы, которые позволяют работать с зарубежными моделями, но зачастую по значительно более высоким тарифам.</p> <p>Аналитики Nodul сравнили стоимость использования моделей по единому сценарию — 10 млн входящих и 2 млн исходящих токенов. В разработке программного обеспечения такой объем ориентировочно соответствует <nobr>1-3</nobr> дням работы одного разработчика с кодинг-агентом или разовому ревью средней кодовой базы.</p> <p>Наибольшая разница в стоимости обнаружена для четырёх моделей. Использование DeepSeek V4.1 Flash через Yandex AI Studio обходится в 4 000 рублей против 443 рублей у зарубежных агрегаторов — в девять раз дороже. Для Claude Opus 5.5 стоимость через российского провайдера составляет 14 239 рублей против 6 560 рублей за рубежом — переплата достигает 7 679 рублей, или примерно 2,2 раза. Аналогичная разница наблюдается для Claude Sonnet 5.5 и GPT-6.1 Sol: доступ к каждой модели через российскую платформу стоит 7 120 рублей против 3 280 рублей по международным тарифам. При этом более высокая стоимость не сопровождается сопоставимыми публичными договорными гарантиями Zero Data Retention.</p> <p>Базовые тарифы прямых зарубежных API и международных агрегаторов в большинстве рассмотренных случаев совпадают. Таким образом, зарубежные агрегаторы могут предоставлять ZDR без дополнительной наценки на стоимость токенов, тогда как переход к российской облачной инфраструктуре увеличивает расходы, но не обязательно обеспечивает сопоставимые гарантии несохранения данных.</p> <p>Компании могут рассматривать собственную инфраструктуру как способ решения проблемы безопасности. Однако развертывание моделей требует инвестиций в вычислительные мощности, эксплуатацию и специалистов. Более доступные открытые модели при этом не всегда обеспечивают качество флагманских коммерческих решений при работе со сложным кодом.</p> <p>Альтернативой становится использование разных моделей и поставщиков в зависимости от требований конкретной задачи. Для этого бизнесу необходима система управления маршрутизацией <nobr>LLM-запросов,</nobr> которая позволяет учитывать одновременно стоимость, качество и безопасность обработки информации.</p> <p>«Для бизнеса важно не просто подключить разработчиков к ИИ, а управлять тем, как он используется. Правильная маршрутизация позволяет автоматически выбирать оптимальную модель и провайдера для каждой задачи: простые запросы выполнять дешевле, сложные направлять более мощным моделям, а корпоративный код — только через маршруты с необходимыми гарантиями конфиденциальности. Вместе с кешированием и контролем потребления это позволяет в отдельных сценариях сокращать расходы в несколько раз, сохраняя скорость разработки и контроль над данными», — отметил Александр Данилов, генеральный директор и основатель Nodul.</p> Международные ограничения лишают российские компании не только прямого доступа к зарубежным нейросетям … message https://www.itweek.ru/themes/detail.php?ID=235950 Fri, 13 Nov 2026 17:36:04 +0300 <p>Эксперты бизнес-направления Guardant компании «Актив» в рамках конференции GuardConf 2026 представили «Оценку российского рынка ПО участниками отрасли с прогнозом на 2027 год». Аналитический отчет отражает текущее состояние российского рынка ПО, его динамику и прогнозы, а также главные драйверы и барьеры отрасли.</p> <p>Российский рынок разработки ПО сталкивается с новыми вызовами: заказчики сокращают бюджеты, конкуренция между отечественными разработчиками усиливается, а компаниям приходится пересматривать бизнес-планы и искать новые возможности для роста. Именно поэтому эксперты Guardant провели опрос, чтобы зафиксировать текущие настроения рынка и определить ключевые тренды его развития.</p> <p>В опросе приняли участие менеджеры высшего звена и собственники отечественных компаний-разработчиков ПО разного масштаба. Методология оценки включала анкетирование по 22 вопросам, сгруппированным в шесть тематических блоков: информация об участниках, итоги первого полугодия 2026 года, ожидания до конца 2026 года и на 2027 год, использование искусственного интеллекта и уровень импортозамещения. На основе ответов эксперты провели количественный анализ и сформулировали ключевые выводы:</p> <ul> <li>более половины опрошенных разработчиков сообщили о снижении выручки, при этом ожидания роста сохраняются. 52% участников сообщили о снижении выручки в первом полугодии 2026 года, при этом 44% рассчитывают на ее увеличение в 2027 году, однако участники связывают возможный рост с разными факторами;</li> <li>внедрение ИИ позволяет ускорить разработку ПО, но пока не приводит к очевидному снижению затрат. 86% активно использующих ИИ отмечают ускорение разработки, при этом 62% не заметили изменений в расходах. Это говорит о том, что скорость и экономическая эффективность внедрения ИИ — разные показатели, и бизнесу еще предстоит оценить реальную отдачу от инвестиций в искусственный интеллект;</li> <li>возможности роста за счет импортозамещения снижаются. По оценкам опрошенных, российское ПО уже занимает около 50% в представленных ими рыночных сегментах. Теперь перед вендорами стоит следующая задача: закрепить достигнутые позиции и найти новые возможности для дальнейшего роста бизнеса;</li> <li>конкуренция среди российских разработчиков усиливается и становится более значимым риском для бизнеса.</li> </ul> <p>Участники опроса стали чаще называть конкуренцию риском снижения выручки: доля таких ответов выросла с 3% при прогнозе на 2026 год до 14% на 2027 год. Сам по себе статус отечественного разработчика уже не гарантирует преимущества на рынке: все большее значение приобретают уникальность продукта и ценность для заказчика.</p> <p>«Мы более 30 лет работаем с вендорами ПО и видим, как меняются условия развития их бизнеса и требования заказчиков. Результаты исследования укрепили нас во мнении, что многие разработчики находятся в непростой ситуации: продажи снижаются, а перспективы спроса остаются неопределенными. Внедрение ИИ не всегда приносит ожидаемое сокращение затрат. В условиях усиления конкуренции вендорам важно развивать свои ключевые компетенции, повышать эффективность, делать ставку на качество сервиса и принимать взвешенные решения о запуске и развитии продуктов на основе реальных данных», — прокомментировал Михаил Чухломин, руководитель бизнес-направления Guardant.</p> <p>Информационными партнерами исследования выступили Ассоциации РУССОФТ и АРПП. </p> Эксперты бизнес-направления Guardant компании «Актив» в рамках конференции GuardConf 2026 представили «Оценку российского … message https://www.itweek.ru/themes/detail.php?ID=235947 Fri, 13 Nov 2026 10:34:24 +0300 <p><em>Современные разработчики ПО — настоящие энтузиасты искусственного интеллекта, а специалисты в области нативных облачных технологий (</em><em>cloud</em><em>-</em><em>native</em><em>) — тем более. Таков главный вывод из последнего исследования Cloud Native Computing Foundation (CNCF), посвященного разработчикам нативных облачных систем, сообщает портал </em><em>The</em> <em>New</em> <em>Stack</em><em>.</em></p> <p>Данные <a href="https://www.cncf.io/wp-content/uploads/2026/11/DN32-State-of-Cloud-Native-Development-261012-Updates.pdf">отчета</a> CNCF «The State of Cloud Native Development Q3 2026» говорят сами за себя: по состоянию на третий квартал насчитывалось 21,2 млн. разработчиков нативных облачных систем, что составляет 41% от общего числа разработчиков в мире.</p> <p>И если среди тех, кто не занимается нативными облачными технологиями, ИИ в работе используют около половины, то среди нативно-облачных специалистов этот показатель достигает трех четвертей. (Согласно представленным данным, чуть менее двух третей всех разработчиков, применяющих ИИ, используют эту технологию как ключевой, неотъемлемый элемент своего рабочего процесса.)</p> <p>#IMAGE_235948#</p> <p>Почему нативно-облачные разработчики так охотно используют ИИ? По словам исполнительного директора CNCF Джонатана Брайса, «они стремятся получить преимущество, ищут возможность работать с передовыми технологиями и хотят выйти на новый уровень — как в своей карьере, так и в использовании технологических инструментов».</p> <p>Говоря о ситуации в сфере разработки в целом, он отмечает, что помимо роста числа самих разработчиков (все больше людей приходят в эту сферу на полную или частичную занятость), стремительно расширяется и арсенал готовых к промышленному применению инструментов для нативно-облачных специалистов.</p> <p>Как и многие другие организации, развивающие открытое ПО, CNCF использует многоуровневый подход к принятию, доработке и выпуску новых инструментов. Сначала проект попадает в «песочницу» — среду, где, по словам Брайса, «отрабатываются строгие процессы, благодаря которым Open Source-проект становится надежным, предсказуемым и пригодным для интеграции в реальные рабочие системы».</p> <p>Затем следует стадия инкубации, а после нее — полноценного выпуска (graduation). Из примерно 250 проектов, существующих в рамках CNCF, лишь немногие достигают этой стадии.</p> <p>Однако в ближайшие годы их число может вырасти. В «песочнице» CNCF появились новые проекты: KubeRay, Agent Substrate, OpenShell, OpenRL и др. В стадию инкубации перешли Meshery, K8GB и некоторые другие. А проекты KubeVirt, Karmada и KubeFlow успешно завершили процесс выпуска.</p> <p>Запутались в обилии названий проектов? Стоит разобраться подробнее. «Независимо от того, в какой сфере индустрии вы работаете и к какому типу организации относитесь, вам необходимо понимать Open Source-технологии — это даст вашей компании дополнительные возможности и преимущества», — утверждает Брайс.</p> <p>И, как показывают данные нового отчета CNCF, количество разработчиков, стремящихся внедрять эти новые решения в работу, постоянно растет.</p> Современные разработчики ПО — настоящие энтузиасты искусственного интеллекта, а специалисты в области нативных … article https://www.itweek.ru/themes/detail.php?ID=235945 Fri, 13 Nov 2026 10:22:39 +0300 <p>Российская телеком-отрасль постепенно переходит на отечественные решения — тренд импортозамещения здесь усилился после 2022 года. <a href="https://www.interfax.ru/amp/1106368">По данным Росстата</a>, в январе-июне 2026 года, по сравнению с аналогичным периодом 2025 года, увеличилось количество компаний, которые занимаются разработкой и внедрением таких решений: рост составил 13,6%, а объем рынка в денежном выражении достиг 276,8 млрд. рублей. Соответственно, растет и доля оборудования отечественного производства — на сегодняшний день она <a href="https://www.interfax.ru/amp/1106368">составляет</a> порядка 35%. Официальные показатели оптимистичные, однако у импортозамещения есть определенные сложности и контртренды, которые постепенно замедляют этот процесс.</p> <h3>Падение инвестиционной активности</h3> <p>Одна из серьезных проблем связана с тем, что операторы связи недостаточно финансируют развитие инфраструктуры. Многие их инвестиционные программы заморожены, и это тормозит процесс модернизации оборудования и программного обеспечения. Она проводится в основном там, где вся система связи или ее отдельные элементы относятся к объектам критической информационной инфраструктуры (КИИ) и попадают под требования ФЗ № 187 «О безопасности критической информационной инфраструктуры Российской Федерации».</p> <p>По закону субъект КИИ — не всегда оператор, а тот, кто использует связь, например, крупный банк или госпредприятие, также и у самих финансовых организаций или других компаний могут быть собственные системы, попадающие под критерии критической информационной инфраструктуры. И тогда оператор вынужден выполнять определенную модернизацию, в том числе заменять часть оборудования/программного обеспечения на отечественные аналоги, чтобы его клиент мог выполнить предписания регулятора, например, такого как ФСТЭК. Однако все чаще операторы стараются выводить свою инфраструктуру из-под таких требований.</p> <h3>Импортозамещение с перебоями</h3> <p>Как уже было сказано выше, доля отечественного оборудования в отрасли растет. Однако многие операторы до сих пор предпочитают сотрудничать с теми зарубежными вендорами, чьи устройства уже стоят на сети. Нередки случаи, когда заказчики требуют уровня надежности и совместимости, сопоставимого с западными производителями, однако российским компаниям требуется время на разработку и тестирование отказоустойчивости продукта. Безусловно, наши вендоры уже прошли большой технологический путь и сегодня продолжают вкладываться в повышение конкурентоспособности собственных разработок. Но все равно совокупная стоимость владения импортными решениями для операторов часто оказывается ниже по сравнению с российскими аналогами. Я думаю, что будь цена отечественного оборудования дороже процентов на <nobr>10-15,</nobr> оно пользовалось бы гораздо большим спросом (по крайней мере, не возникало бы сложностей с логистикой, внедрением и обслуживанием). А вот двух-трехкратная разница в стоимости, что часто встречается, уже серьезный фактор выбора, и сегодня он работает против отечественных производителей.</p> <p>Российские разработки дороже из-за фундаментальной разницы в размере бизнеса и структуре затрат. Если мы говорим об оборудовании, то у наших производителей нет такой колоссальной экономии на масштабе. Мы закупаем компоненты сравнительно небольшими партиями по рыночной стоимости, тогда как мировые гиганты делают это десятками миллионов штук, получая минимальные входные цены от заводов. Негативно влияет на отечественных производителей и сложная логистика компонентов через несколько границ.</p> <p>Если речь идет о программном обеспечении, все решает объем рынка сбыта. Китайский или европейский вендор разрабатывает систему один раз, а затем продает ее тысячам операторов по всему миру. Даже несмотря на геополитические ограничения, иностранные вендоры ищут способ продолжить вести бизнес в России, пусть не в открытую, но косвенно, без реальной локализации. Более того, иностранцы могут позволить себе демпинг: они используют прибыль, полученную на других направлениях, и продают лицензии здесь практически по себестоимости.</p> <p>Отечественные разработчики выходят на международные рынки, но объемы поставок пока несопоставимы с глобальными игроками. Поэтому для выхода на окупаемость нам приходится закладывать реальную цену продукта.</p> <p>Известны случаи, когда российская компания получает статус ТОРП («телекоммуникационное оборудование российского происхождения»), начинает выпускать CPE-устройства: маршрутизаторы, IPTV‑приставки, точки доступа Wi‑Fi, оптические терминалы и прочее оборудование, которое ставится у абонента в доме и квартире, но все это не пользуется спросом, потому что оператору выгоднее купить китайские аналоги по более низкой цене. Более того, получать сам статус ТОРП становится все сложнее, процедура занимает больше времени: нормативы постоянно меняются, ужесточаются и сокращается число предприятий, готовых участвовать в конкурсном отборе</p> <h3>Что важно для устойчивого развития отрасли</h3> <p>Обозначенные тренды и контртренды отчетливо проявились в первом полугодии 2026 года и, скорее всего, продолжат влиять на отрасль и в последующие несколько лет. Для того чтобы она могла активно развиваться, нужен рост спроса на отечественное оборудование и ПО не только в тех сегментах, где присутствуют жесткие регуляторные требования, но и во всех остальных. Говоря о наших решениях: чтобы они были конкурентоспособны по цене, необходимо проектировать их с меньшим потреблением исходных ресурсов — в том числе вычислительных мощностей и серверного оборудования.</p> <p>#IMAGE_235946#</p> Российская телеком-отрасль постепенно переходит на отечественные решения — тренд импортозамещения здесь усилился после … article Виталий Некрасов, начальник отдела продаж департамента технологий связи АО “Искра Технологии” https://www.itweek.ru/themes/detail.php?ID=235944 Thu, 12 Nov 2026 16:27:43 +0300 <p>Разработчики РЕД СОФТ добавили поддержку Firebird в Apache ShardingSphere. Благодаря интеграции у пользователей появилась возможность превращать классические реляционные базы данных на Firebird в распределенные системы, используя open-source инструменты для масштабирования высоконагруженных проектов.</p> <p>Благодаря интеграции с Apache ShardingSphere, пользователи получают доступ к комплексному набору функций на уровне модулей ядра и экосистемы:</p> <ul> <li>шардинг (горизонтальное и вертикальное разделение): Разделение огромных таблиц на отдельные шарды обеспечивает кратное ускорение выполнения запросов и параллельную обработку транзакций, снижая нагрузку на одиночные серверы. Поддерживаются различные алгоритмы маршрутизации, включая деление по модулю (MOD), хеширование (MD5), разделение по диапазонам (Boundary Range) и временным интервалам (Auto Interval);</li> <li>разделение чтения и записи: Транзакции записи могут автоматически направляться на мастер-узел, а запросы на чтение распределяться между репликами с использованием механизмов балансировки нагрузки;</li> <li>распределенные транзакции: Реализована поддержка параллельного выполнения транзакций (протокол Local) и двухфазных коммитов (протокол XA), гарантирующих строгую согласованность и изоляцию данных;</li> <li>криптография и маскирование: Поддерживается шифрование данных (например, алгоритм AES) и необратимое хеширование (MD5) перед их записью в базу. Также доступно гибкое маскирование, позволяющее заменять конфиденциальные части строк на спецсимволы (например, «звездочки») непосредственно при возврате данных пользователю;</li> <li>теневые базы данных (Shadow DB): Возможность создания точной копии основной базы данных для проведения безопасного нагрузочного тестирования прямо на рабочей структуре, без риска повредить боевые данные.</li> </ul> <br/> Гибкие методы подключения (JDBC и Proxy) Для развертывания распределенной архитектуры инженерами реализована поддержка двух независимых подходов:<br/> <ul> <li>ShardingSphere-JDBC: Легковесный Java-фреймворк, который напрямую заменяет классический JDBC-драйвер (например, Jaybird). Каждый клиент создает децентрализованный пул соединений к базам данных, что гарантирует максимальную производительность с минимальными накладными расходами на сеть;</li> <li>ShardingSphere-Proxy: Отдельный сервер, полностью эмулирующий работу сервера баз данных. Наличие статической точки входа позволяет подключаться к системе из любого языка программирования или терминала, управляя единым пулом соединений.</li> </ul> <p>«Мы стремились не просто предоставить нашим пользователям механизм шардинга, но и внести вклад в open-source движение. Инициатива оказалась востребованной: наши доработки успешно прошли ревью и были добавлены в основной репозиторий Apache ShardingSphere. Что самое ценное — комьюнити активно подхватило проект, сторонние разработчики начали его развивать и добавлять собственные доработки и тесты», — прокомментировал Роман Симаков, заместитель директора дивизиона системного программного обеспечения по разработке.</p> Разработчики РЕД СОФТ добавили поддержку Firebird в Apache ShardingSphere. Благодаря интеграции у пользователей … message https://www.itweek.ru/themes/detail.php?ID=235943 Thu, 12 Nov 2026 16:23:19 +0300 <p>Компания по управлению онлайн-активами Руцентр расширила портфель инфраструктурных услуг и выходит в сегменты IaaS, PaaS и SaaS, продолжая линейку доменной инфраструктуры, защищенного хостинга и выделенных серверов. Ключевой акцент нового направления — безопасность, отказоустойчивость, геораспределенность и соответствие регуляторным требованиям, которые для бизнеса сегодня являются ключевым условием выбора провайдера.</p> <p>Новое направление в Руцентре включает облачные серверы, защищенные серверы под требования <nobr>152-ФЗ,</nobr> отказоустойчивые кластеры баз данных MySQL и PostgreSQL, готовые к работе кластеры Kubernetes, S3-хранилище, сетевые диски, виртуальные сети с плавающими IP и расширенные опции резервного копирования. Для задач в сфере искусственного интеллекта и машинного обучения, требующих параллельных вычислений, доступны конфигурации с GPU. Модель оплаты построена по принципу pay-as-you-go и позволяет платить за фактически использованные ресурсы. Премиальным клиентам Руцентр предлагает ранний доступ с тестовым балансом, консалтинг в разработке плана миграции и переносе текущих проектов.</p> <p>Защищенные облачные серверы под требования <nobr>152-ФЗ</nobr> имеют уровень защищенности до УЗ-1, сертифицированные средства безопасности, систему обнаружения вторжений и инструменты анализа уязвимостей, антивирусную защиту и защиту от DDoS-атак. Повышенные стандарты безопасности ЦОД, система управления инцидентами и политики резервного копирования дополняют контур отказоустойчивости — безопасность в Руцентре выстроена как базовый слой сервиса.</p> <p>«Бизнес сегодня выбирает не просто вычислительные мощности, а предсказуемую инфраструктурную среду, в которой безопасность, соответствие требованиям и управляемость встроены в базовый уровень сервиса. Запуск облачного направления в Руцентре является логическим продолжением многолетней экспертизы компании в доменном и хостинговом бизнесе», — прокомментировал Валентин Бостанов, руководитель департамента инфраструктурных сервисов Руцентра.</p> <p>В настоящее время облачная инфраструктура в Руцентре находится на этапе закрытого тестирования. Корпоративные заказчики могут получить доступ к тестовому контуру через персонального менеджера Руцентра. Общедоступный запуск облака запланирован до конца года.</p> <p>Облачное направление развивает накопленную инфраструктурную экспертизу Руцентра. Помимо этого, компания представляет аренду выделенных серверов с GPU и защищенный хостинг с интегрированной L7-защитой. Руцентр работает с цифровыми активами бизнеса и государства с 2000 года и сегодня обслуживает 72% крупнейших компаний России по выручке (рейтинг РБК 500). Компания обеспечивает работу ключевых онлайн-сервисов, банков, платежных сервисов, медиа, ритейла, маркетплейсов, операторов связи и госсектора.</p> Компания по управлению онлайн-активами Руцентр расширила портфель инфраструктурных услуг и выходит в сегменты … message https://www.itweek.ru/themes/detail.php?ID=235942 Thu, 12 Nov 2026 16:20:11 +0300 <p>Компания Falcongaze выпустила новую версию своей DLP-системы — SecureTower 8.0 Titanium. Главное нововведение — модуль DCAP. Теперь SecureTower осуществляет контроль конфиденциальной информации не только в движении, но и в покое, информируя сотрудников ИБ в соответствии с заданными политиками о том, где хранятся данные, кто имеет к ним доступ и нет ли у сотрудников избыточных прав.</p> <p>Для бизнеса DCAP означает автоматизированный порядок в хранении данных и в правах доступа к ним. Система находит важные документы на рабочих станциях, присваивает им класс и уровень критичности и следит, чтобы конфиденциальная информация находилась только в разрешенных каталогах.</p> <p>Для самых распространенных документов правила хранения уже созданы, а под специфику компании их можно дополнить своими, пользовательскими правилами. Если правило нарушено, система может переместить файл, скрыть его, удалить или изменить атрибуты доступа, а специалист по безопасности получит уведомление о событии благодаря интеграции с модулем Политики безопасности. </p> <p>В итоге снижается риск неправомерного использования и хранения данных внутри организации, экономится время службы ИБ на рутинной проверке хранилищ и формируется прозрачная картина того, где находятся самые чувствительные документы и кто имеет к ним доступ.</p> <p>«Контроль передачи информации остается важной частью информационной безопасности, однако не менее важно понимать, где хранятся корпоративные данные и кто имеет к ним доступ. Новый модуль DCAP позволяет выявлять нарушения установленных правил хранения и управлять правами доступа к файлам. Это расширяет возможности контроля для специалистов по информационной безопасности на каждом этапе жизненного цикла корпоративных данных», — отметил Александр Акимов, директор Falcongaze.</p> <p>В SecureTower 8.0 Titanium появилась веб-консоль: теперь отчеты доступны прямо в браузере, без привязки к рабочему месту специалиста. Работать с системой можно с разных устройств, что повышает мобильность сотрудников отдела информационной безопасности.</p> <p>Конкурентоспособность компании сегодня во многом зависит от того, насколько быстро она осваивает новые технологии, и искусственный интеллект занимает среди них одно из ключевых мест. Но чем шире сотрудники используют ИИ-сервисы, тем выше риск, что в них попадут чувствительные данные, которые нельзя передавать за пределы организации.</p> <p>С выходом версии SecureTower 8.0 Titanium система контролирует все взаимодействия сотрудника с ИИ-сервисами и уведомляет специалистов по безопасности об обнаруженном инциденте. Для перехваченных данных используются инструменты анализа: суммаризация и AI-обработка инцидентов. </p> <p>Новая возможность перехвата полезна компаниям, где искусственный интеллект в работе допустим, но его использование должно быть строго регламентировано и прозрачно. Так бизнес получает современный инструмент и при этом сохраняет контроль над корпоративными данными. </p> <p>Рабочие станции на macOS нередко считают менее уязвимыми из-за закрытой экосистемы Apple. Однако использование macOS не исключает внутренних угроз и утечек данных. Без контроля такие устройства остаются слепой зоной для службы ИБ.</p> <p>В новой версии SecureTower агент для macOS получил возможность перехватывать сетевой трафик. Теперь система контролирует входящую и исходящую почту по различным протоколам, переписку в социальных сетях и мессенджерах, работу с веб-почтой и веб-версиями облачных хранилищ. Еще одно нововведение — контроль печати. DLP-система фиксирует отправку документов на принтер, в том числе из приложений, в которых сотрудники работают с чувствительной информацией.</p> <p>Новые возможности дополняют уже реализованные функции контроля устройств, накопителей и сетевых ресурсов, активности приложений, кейлоггер, снимки экрана, аудио- и видеомониторинг. Развитие агента для macOS продолжается: в дальнейшем список контролируемых каналов будет расширяться.</p> <p>Мессенджеры остаются одним из самых популярных каналов утечки информации, и Falcongaze продолжает расширять их контроль. В версии 8.0 Titanium добавлена блокировка отправки файлов, в том числе по контенту, в MAX и Aitu. Появился перехват сообщений, файлов и звонков в 1С Коннект, а также перехват звонков в веб-версиях Telegram, MAX, Teams и Контур.Толк с распознаванием речи.</p> <p>Из других нововведений: расширены условия запуска записи экрана и микрофона в аудио/видеомониторинге; добавлена история местоположений сотрудников в модуле «Оборудование и программы», с возможностью настройки уведомления об отклонениях в местоположении и конфигурации ПК на почту и в Telegram; появилась возможность блокировки подключения к недоверенным Wi-Fi-сетям; функционал карантина почтовых писем стал доступен для организаций, использующих в работе MS Exchange; добавлена возможность выбора типов данных для распознавания речи и др.</p> <p>С каждой версией SecureTower охватывает больше сценариев работы с корпоративной информацией: от хранения и управления доступом до передачи данных по различным каналам. Такой подход позволяет выстраивать более целостный контроль над информацией на всех этапах ее использования. Falcongaze продолжит развивать систему с учетом изменений ИТ-инфраструктуры и новых угроз информационной безопасности. </p> Компания Falcongaze выпустила новую версию своей DLP-системы — SecureTower 8.0 Titanium. Главное нововведение — … message https://www.itweek.ru/themes/detail.php?ID=235941 Thu, 12 Nov 2026 16:13:43 +0300 <p>ITFB Group и BSS представили совместное решение на базе платформы интеллектуальной обработки документов ITFB EasyDoc и корпоративной базы знаний L2U InKnowledge. Решение позволяет компаниям включить бумажный документооборот в единое цифровое пространство и работать с ним с помощью искусственного интеллекта.</p> <p>EasyDoc — это интеллектуальная платформа извлечения, анализа и генерации текстовых данных. Она распознает сканы и фотографии документов, классифицирует их и извлекает ключевые атрибуты. После проверки оператором документы с метаданными автоматически передаются в базу знаний L2U InKnowledge от BSS. Там их можно найти полнотекстовым поиском или через ИИ-помощника, который отвечает на вопросы со ссылками на источники, формирует реестры и собирает статистику по обращениям. Помощник использует технологию RAG и подключается к собственной, локальной или облачной языковой модели. Типовые сценарии EasyDoc внедряются за один день, базовая версия базы знаний — примерно за неделю.</p> <p>Кроме того, появилось два новых модуля: EasyDoc Compare — это автономное приложение-компаньон и спин-офф экосистемы EasyDoc, которое использует API родительской системы для выполнения задач по сравнению версий документов и оценки критичности изменений, а также EasyDoc Mask — приложение для маскирования данных в документах, которое мгновенно находит конфиденциальные данные и скрывает их.</p> <p>«База знаний L2U InKnowledge собирает всю корпоративную информацию в единое пространство, но бумажные документы до сих пор оставались за его пределами. Связка с EasyDoc закрывает этот разрыв: отсканированное письмо или счёт попадает в базу знаний уже классифицированным и сразу доступно для поиска и ИИ-помощника. Аналитику по сотням обращений клиентов, на которую раньше уходили часы работы аналитиков, теперь можно получить за секунды», — сказал Дмитрий Лактионов, директор продуктового направления Базы знаний компании BSS.</p> <p>«Ценность платформы EasyDoc особенно проявляется, когда система понимает, что за документ перед ней, извлекает нужные атрибуты и сверяет их между документами пакета: например, сумму в счёте-фактуре с суммой в акте. Самое сложное — неструктурированные документы вроде договоров, где нужный реквизит может оказаться в любом месте текста. Именно здесь ИИ даёт основной эффект», — отметил Вадим Петросян, директор по развитию бизнеса ITFB Group.</p> <p>Платформа EasyDoc с 2025 года работает в НПФ «Будущее», где автоматизирует регистрацию бумажной корреспонденции. Входящий поток бумажных документов НПФ составляет примерно 142 тыс. в год, среди этих документов есть как структурированные, так и слабо структурированные, неструктурированные и даже рукописные документы. С помощью внедрения EasyDoc скорость регистрации в НПФ выросла на 20% при плановых 10%, а сам проект стал примером перехода от ручной обработки «бумажного хаоса» к управляемому интеллектуальному документообороту, где ИИ берет на себя рутину, а сотрудники переключаются на контроль и более сложные задачи. </p> <p>«Бумажные обращения остаются неотъемлемой частью пенсионного бизнеса: значительная часть клиентов по-прежнему направляет документы в НПФ на бумаге. Внедрение ИИ в процесс регистрации позволило нам сократить количество ошибок на 80% и автоматизировать 62% ручных операций, а результаты превзошли плановые показатели. Срок окупаемости проекта при текущих условиях составляет полтора-два года», — поделилась Ольга Шевченко, руководитель проектов НПФ «Будущее». </p> ITFB Group и BSS представили совместное решение на базе платформы интеллектуальной обработки документов ITFB EasyDoc … message https://www.itweek.ru/themes/detail.php?ID=235940 Thu, 12 Nov 2026 11:10:47 +0300 <p>Переход на отечественные решения в области управления доступом редко сводится к замене одного программного продукта другим. На практике основная сложность начинается после выбора новой платформы, когда компании необходимо перенести существующие политики аутентификации и авторизации, роли, интеграции, настройки многофакторной аутентификации и другие элементы конфигурации.</p> <p>Для крупной организации такая конфигурация может формироваться годами и отражать не только технические параметры, но и логику внутренних процессов. Поэтому миграция между IAM- или IdP-системами становится отдельным проектом, в котором необходимо одновременно сохранить работоспособность сервисов, не потерять накопленные настройки и не создать новые риски информационной безопасности.</p> <p>На практике можно выделить четыре основных подхода к такой миграции: перенос силами специалиста вендора, самостоятельная настройка по документации, автоматический перенос по заранее заданным правилам и гибридный сценарий, в котором формальные правила дополняются возможностями искусственного интеллекта.</p> <h3>Почему конфигурация не переносится «один в один»</h3> <p>Прямой перенос между двумя системами возможен далеко не всегда, даже если обе платформы решают сходные задачи. Одни и те же сущности могут называться по-разному, храниться в разных форматах и реализовываться через разные механизмы.</p> <p>Политика доступа, которая в одной системе описывается несколькими параметрами, в другой может быть частью отдельного объекта или зависеть от другой логики обработки. Поэтому миграция требует не простого копирования значений, а сопоставления моделей данных, сущностей и правил поведения двух решений.</p> <p>Это особенно критично для систем аутентификации и авторизации, поскольку ошибка в конфигурации может повлиять на доступ пользователей к корпоративным или внешним сервисам. Чем ближе система находится к внешнему контуру и чем больше пользователей от нее зависит, тем выше требования к качеству миграции и последующей проверке.</p> <h3>Подход 1. Миграция силами специалиста вендора</h3> <p>Первый сценарий предполагает, что переносом занимается специалист поставщика новой системы. Он изучает текущую конфигурацию, сопоставляет ее с возможностями целевого решения и вручную воспроизводит необходимые настройки.</p> <p>Сильная сторона такого подхода заключается в глубоком знании целевого продукта. Специалист понимает особенности архитектуры, типовые ограничения и возможные способы реализации тех или иных политик, поэтому вероятность получить корректную конфигурацию достаточно высока.</p> <p>При этом возникает организационная и инфраструктурная проблема: специалисту необходимо предоставить доступ к инфраструктуре либо передать конфигурацию наружу. Для банков, компаний с критической инфраструктурой и организаций с жесткими требованиями к ИБ передача таких данных или предоставление внешнего доступа — это чувствительный вопрос.</p> <p>При этом перенос сложной конфигурации — монотонная и трудоемкая работа, и при большом количестве настроек миграция может занять значительное время. Поэтому дополнительным ограничением становится стоимость времени. Чем сложнее исходная конфигурация, тем больше ручной работы требуется, а значит, миграция плохо масштабируется и зависит от доступности специалистов с нужной квалификацией.</p> <h3>Подход 2. Самостоятельная миграция по документации</h3> <p>Второй вариант — заказчику передается документация, миграция выполняется силами внутренней команды. С точки зрения контроля данных этот сценарий выглядит более привлекательно, поскольку вся работа может выполняться внутри доверенного контура.</p> <p>Однако требования к компетенциям сотрудников резко возрастают. Специалисту необходимо разбираться не только в новой системе, но и хорошо понимать логику старой платформы, с которой выполняется переход. На практике это означает, что сотрудник должен сопоставлять сущности, политики, роли и настройки, которые могут по-разному называться и реализовываться в двух продуктах. Фактически задача становится не просто переносом параметров, а интерпретацией логики одной системы и ее корректным воспроизведением в другой.</p> <p>Риск ошибок также остается на стороне заказчика. Если неверная настройка касается системы, которая используется для доступа к внешним сервисам или личным кабинетам клиентов, последствия могут быть значительно серьезнее, чем при ошибке в изолированной внутренней системе.</p> <h3>Подход 3. Автоматический перенос по формальным правилам</h3> <p>Третий подход заключается в создании специализированного мигратора, который работает по заранее описанным правилам. Для каждой известной сущности или параметра задается соответствие между исходной и целевой системой, после чего программа автоматически преобразует конфигурацию.</p> <p>Главное преимущество такой модели — скорость. Если правила уже определены, и исходная система поддерживается, большая часть переноса может выполняться автоматически и без постоянного участия специалиста.</p> <p>Еще одно важное преимущество связано с безопасностью данных. Такой инструмент можно запускать внутри инфраструктуры заказчика, поэтому конфигурация не должна покидать корпоративный контур.</p> <p>Основное ограничение состоит в том, что невозможно заранее описать все комбинации систем, версий и нестандартных настроек. Мигратор может хорошо работать для типового сценария, но столкнуться с конструкцией, которая не была предусмотрена разработчиком.</p> <p>Кроме того, автоматический перенос не отменяет проверку результата. Даже если программа формально завершила работу без ошибок, итоговая конфигурация все равно должна быть провалидирована, поскольку корректное преобразование структуры еще не гарантирует сохранения исходной бизнес-логики.</p> <h3>Подход 4. Формальные правила в сочетании с ИИ</h3> <p>Четвертый сценарий предполагает гибридную архитектуру, в которой типовые операции выполняются по детерминированным правилам, а нетиповые случаи передаются на анализ ИИ. Такой подход позволяет сохранить предсказуемость там, где соответствия известны заранее, и при этом расширить покрытие сложных сценариев.</p> <p>Если система встречает конфигурацию, которую невозможно однозначно преобразовать по статическим правилам, ИИ может проанализировать структуру исходных настроек, возможности целевого продукта и предложить вариант переноса. После этого результат должен пройти дополнительную проверку, а критичные изменения — подтверждение специалистом.</p> <p>В этой модели ИИ выступает не заменой классического мигратора, а надстройкой над ним. Формальные правила остаются базовым и наиболее надежным механизмом, а искусственный интеллект подключается только в тех случаях, где жестко заданных соответствий недостаточно.</p> <p>Такой подход потенциально позволяет сократить объем ручной работы и уменьшить количество ситуаций, в которых приходится возвращаться к полностью ручному сценарию. При этом архитектура сохраняет контроль над тем, какие операции выполняются детерминированно, а какие требуют дополнительной интерпретации.</p> <h3>ИИ может использоваться не только для переноса</h3> <p>Одним из дополнительных сценариев становится анализ уже перенесенной конфигурации. Система может сравнивать настройки с заранее определенными требованиями и рекомендациями, выявлять потенциально спорные параметры и предлагать варианты улучшения.</p> <p>Здесь важно, чтобы такие рекомендации основывались на формализованных требованиях, отраслевых практиках или стандартах, а не на субъективной логике конкретного разработчика. В этом случае миграция может использоваться как точка для пересмотра накопленной конфигурации, которая на протяжении нескольких лет могла изменяться без системного аудита.</p> <p>Другой возможный сценарий — управление настройками через естественный язык. Администратор может описать требование в понятной форме, например задать правило обязательного использования второго фактора для определенной категории сотрудников, после чего система преобразует это требование в конфигурацию целевого продукта.</p> <p>Такой механизм может упростить работу с системами управления доступом, но не отменяет необходимости контроля результата. Чем выше критичность конкретной политики, тем важнее, чтобы автоматически сформированные настройки проходили независимую проверку.</p> <h3>Ограничения ИИ-подхода</h3> <p>Главный недостаток гибридного сценария заключается в сложности реализации. Для его работы недостаточно подключить языковую модель к конфигурационному файлу, поскольку сначала необходимо формализовать базовые правила миграции, определить поддерживаемые сценарии и выстроить процесс проверки.</p> <p>Отдельная задача — создание ИИ-агента, который понимает структуру обеих систем и способен работать с документацией, конфигурацией и правилами валидации. Чем выше требования к надежности, тем сложнее становится такой агент и тем больше специализированного контекста ему требуется.</p> <p>Есть и инфраструктурное ограничение. Конфигурация системы аутентификации может содержать чувствительную информацию, поэтому передача таких данных во внешний публичный ИИ-сервис подходит не всем организациям.</p> <p>Для компаний с повышенными требованиями к конфиденциальности более реалистичными вариантами становятся локальный запуск модели или использование доверенной инфраструктуры. Локальный сценарий позволяет сохранить данные внутри контура, но требует соответствующих вычислительных ресурсов.</p> <h3>Почему автоматизация требует участие человека</h3> <p>Ни один из рассмотренных подходов полностью не устраняет необходимость экспертной проверки. Ручная миграция зависит от квалификации специалиста, статический мигратор ограничен набором заранее описанных правил, а ИИ может ошибаться при интерпретации нестандартной конфигурации.</p> <p>Поэтому наиболее практичной выглядит схема, в которой автоматизация снижает объем рутинной работы, а человек остается в контуре принятия решений. Формальные правила используются для типовых операций, ИИ помогает разбирать исключения и проводить дополнительный анализ, а специалист контролирует итоговую конфигурацию.</p> <p>Для задач информационной безопасности такой баланс особенно важен. Цель автоматизации здесь состоит не в том, чтобы исключить эксперта, а в том, чтобы сократить количество ручных операций, снизить вероятность механических ошибок и ускорить работу с большими объемами настроек.</p> <h3>Импортозамещение как задача миграции</h3> <p>При обсуждении импортозамещения основное внимание обычно уделяется выбору отечественного аналога и сравнению функциональности решений. Однако в крупных инфраструктурах стоимость и сложность самого перехода могут быть не менее значимыми, чем характеристики нового продукта.</p> <p>Чем дольше система используется в компании, тем больше в ней накапливается ролей, интеграций, исключений и нестандартных политик. В результате вопрос о выборе решения должен рассматриваться вместе со способом переноса в него существующей логики и оценки ресурсов, которые потребуются на этот процесс.</p> <p>В этом контексте средства автоматизации миграции могут стать важной частью зрелого IAM-решения. Подобный механизм можно рассматривать как отдельное направление развития, которое помогает сократить стоимость перехода и сделать импортозамещение более управляемым.</p> <p>Наиболее перспективным выглядит гибридный подход, в котором детерминированные правила отвечают за предсказуемую часть миграции, ИИ помогает работать с нестандартными ситуациями, а оценка результата остается за специалистом. Такая модель позволяет использовать преимущества автоматизации, не отказываясь от контроля там, где ошибка может напрямую повлиять на безопасность и доступность сервисов.</p> Переход на отечественные решения в области управления доступом редко сводится к замене одного программного … article Андрей Кузнецов, руководитель Digital Q.Security, главный аналитик департамента “Инструменты и технологии разработки” компании “Диасофт” https://www.itweek.ru/themes/detail.php?ID=235939 Thu, 12 Nov 2026 10:50:49 +0300 <p><em>Сегодня искусственный интеллект способен превратить патч безопасности в работающий эксплойт всего за несколько часов. В таких условиях ожидание планового «окна обслуживания», запланированного на следующую неделю, становится для бизнеса гораздо более серьезным риском, пишут на портале </em><em>The</em> <em>New</em> <em>Stack</em> <em>Орен Пенсо, глобальный технический директор подразделения Tanzu компании Broadcom, и Майкл Коте, старший технический специалист VMware.</em></p> <p>Рассмотрим, как в 2026 г. развивается ситуация с уязвимостью в популярной Open Source-библиотеке. Мейнтейнер вносит исправление и публикует бюллетень безопасности. Спустя всего несколько часов кто-то направляет ИИ-модель на анализ различий (diff) между старой и новой версиями кода — и получает готовый эксплойт. На следующее утро ваш сканер обнаруживает CVE, создается заявка, а исправление планируется к внедрению в рамках «окна обслуживания» на следующей неделе. Но к тому моменту эксплойт уже вовсю используется злоумышленниками.</p> <p>Еще год назад такой подход к управлению изменениями в корпоративной среде считался приемлемым, но сегодня он безнадежно устарел.</p> <p>И на то есть веские причины. В своем <a href="https://am.jpmorgan.com/wr/en/asset-management/liq/insights/market-insights/eye-on-the-market/patchmageddon/">отчете</a> «Patchmageddon» («Патчмагеддон»), опубликованном в июле 2026 г. (в его подготовке участвовали руководители подразделений кибербезопасности J.P. Morgan Asset Management), председатель группы по рыночной и инвестиционной стратегии в подразделении J.P. Morgan Asset   Wealth Management Майкл Чембалест подробно описывает ситуацию. Модели вроде Mythos от Anthropic или GPT-5.5 от OpenAI теперь обнаруживают ранее неизвестные уязвимости в таких масштабах, которые недоступны ни одной команде исследователей-людей. Только за первый месяц работы проект Glasswing (инициатива Anthropic и партнеров) выявил более 10 000 новых уязвимостей нулевого дня высокого и критического уровней опасности.</p> <p>Одновременно с этим сократилось время до начала эксплуатации уязвимости. Если в 2021 г. медианный интервал между раскрытием информации об уязвимости и ее первым использованием составлял около года, то в <nobr>2026-м</nobr> он сократился до одних суток, а в 2027 г., по прогнозам, составит всего одну минуту. Почти 80% случаев эксплуатации происходят либо одновременно с публичным раскрытием информации, либо даже до него. ИИ-модели находят уязвимости, а хакеры используют их с той же — если не с большей — скоростью.</p> <h3>Первый удар принимает на себя Open Source</h3> <p>Именно Open Source оказывается под основным давлением: во-первых, это фундамент для большинства современных программных продуктов, а во-вторых, его исходный код — как следует из названия — открыт для всех. Это просто замечательно — и именно так всё и должно быть, но это также означает, что для хакеров уязвимости в Open Source — самая лёгкая добыча.</p> <p>Люди, на чьи плечи ложится борьба с этим потоком уязвимостей, раскрытых ИИ, — это, по большей части, волонтёры. К маю 2026 г. Anthropic сообщила Open Source-мейнтейнерам о 530 уязвимостях высокого и критического уровня, однако к тому моменту было устранено лишь 75 из них. Этим летом многие мейнтейнеры закрывали программы по поиску уязвимостей и фактически «уходили на покой», чтобы хоть немного передохнуть от колоссального напряжения.</p> <h3>Ваша новая стратегия безопасности</h3> <p>Нравится вам это или нет, но подход корпораций к безопасности обычно меняется, когда возникает острая необходимость — и, скажем прямо, лёгкое чувство тревоги. Вот ещё несколько поводов для беспокойства:</p> <ol> <li><strong> Модели становятся всё совершеннее.</strong> По прогнозам Чембалеста, возможности, которыми сегодня обладают лишь спецслужбы отдельных государств, в ближайшие <nobr>12-24</nobr> месяца появятся в общедоступных моделях с открытыми весами. Хэмиш Лоу из Institute for AI Policy and Strategy оценивает вероятность появления к февралю 2027 г. китайской модели класса Mythos в 40%, а к концу того же года — практически как неизбежность.</li> <li><strong> Скорее всего, вы уже используете уязвимый код.</strong> Большая часть того, что работает в ваших системах, была взята из публичных репозиториев месяцы, а то и годы назад. Согласно данным Datadog за февраль 2026 г., типичная зависимость отстаёт от своей последней мажорной версии в среднем на 278 дней. Это устаревший код, который ждёт своего часа, чтобы стать инструментом для атаки.</li> <li><strong> Критерии оценки изменились.</strong> Чембалест прямо заявляет: теперь организациям придётся оценивать себя не только по точности устранения уязвимостей, но и по скорости этого процесса. Если раньше нормой считался <nobr>90-дневный</nobr> срок, то теперь счёт идёт на часы.</li> </ol> <p>Если вы владеете платформой, отвечаете за безопасность приложений или принимаете решения по технологическим рискам в регулируемой отрасли — эта проблема уже нависла над вами, независимо от того, предпринимаете вы какие-либо действия или нет. Суета без плана — это как сидеть в самолете, который задерживается на пять часов, рядом с пассажиром, который непрерывно переписывается в мессенджере, а каждое входящее сообщение сопровождается громким звуком, похожим на кряканье утки. Раздражает и напрочь убивает настроение.</p> <p>Чтобы избавиться от этого «кряканья», давайте рассмотрим подход, которым Орен делится с руководителями в сфере платформ и безопасности в финансовом секторе.</p> <h3>Перестаньте строить свою стратегию безопасности в расчете на «бесплатное пиво»</h3> <p>Над Open Source-проектами работает недостаточно людей, чтобы оперативно выпускать исправления.</p> <p>Чембалест уделяет особое внимание вопросу концентрации усилий вокруг отдельных мейнтейнеров. Согласно исследованию Linux Foundation и Гарвардского университета, охватывающему 50 крупнейших <a name="OLE_LINK23">Open</a> Source-проектов, в 23% из них более 80% добавленного кода — заслуга одного-единственного разработчика, а в 94% проектов более 90% кода написано менее чем десятью людьми. По данным компании Anchore, в реестре npm насчитывается более 18 млн. пакетов, у которых указан лишь один мейнтейнер.</p> <p>Большинство сообществ, создающих и поддерживающих Open Source, делают всё, что в их силах, а многие при этом даже выгорели, пытаясь сделать еще больше. Но обещание «бесплатного» (в смысле «бесплатного пива») никогда не подразумевало, что вам гарантируют идеальную безопасность и мгновенное устранение уязвимостей в день их обнаружения. Обещали, по сути, только «бесплатное пиво». Корпорации десятилетиями пользовались этим «бесплатным пивом» — ПО с открытым кодом, — хотя им не раз намекали, что такой подход граничит с безответственностью. Теперь мы видим подтверждение этому, причем ситуация создана нами же. Пришло время заплатить за пиво.</p> <p>Именно здесь на помощь приходит профессиональное открытое ПО. Да, это означает — вдохните глубже, закройте свои таблицы — что за использование ПО, которое можно свободно скачать, приходится платить.</p> <p>За профессиональным Open Source стоит либо поставщик, который несет реальную ответственность за продукт, либо фонд, располагающий штатом специалистов по безопасности, финансируемыми мейнтейнерами и отлаженным процессом выпуска релизов, который не зависит от выгорания отдельных сотрудников. Команда, создавшая код и досконально его знающая, берет на себя исправление ошибок и работает в рамках соглашения об уровне обслуживания (SLA).</p> <p>Техническое руководство J.P. Morgan в отчете, подготовленном Чембалестом, дает четкие рекомендации: используйте актуальные версии ПО и отказывайтесь от зависимостей, если вы не можете определить, кто их поддерживает, если за поддержкой стоит лишь один человек или если проект выглядит заброшенным. Если вы не знаете, кто отвечает за поддержку пакета, вы не можете рассчитывать на то, что кто-то исправит в нем уязвимости.</p> <h3>Установка патчей безопасности — залог непрерывности бизнеса</h3> <p>Эрик Скейлс, руководитель направления платформенной инженерии для Tanzu Platform в компании Charles Schwab, говорит прямо: «Если вам когда-нибудь приходилось устанавливать патчи на сервер, вы знаете: никто не хочет ничего обновлять. Никто вообще не хочет ничего трогать. Но теперь все боятся попасть в заголовки новостей — и в итоге лишиться работы».</p> <p>Обычно установку патча откладывают, чтобы не прерывать бизнес-процессы. Поскольку обновление может что-то сломать, его переносят на следующее «окно обслуживания» — или даже дальше. В отчете J.P. Morgan приводится исследование, согласно которому более 80% специалистов по безопасности хотя бы раз откладывали установку патча, чтобы избежать сбоев в работе компании.</p> <p>Когда до появления эксплойтов проходили месяцы, такой подход был оправдан. Теперь же, когда эксплойты появляются уже через день после раскрытия уязвимости, использование необновленной системы становится гораздо большей угрозой для непрерывности бизнеса.</p> <p>Тем не менее, проблема возможных сбоев никуда не делась. Любое исправление, которое, помимо устранения риска, создает риск дополнительных перебоев в работе, скорее всего, будет отложено. А именно за такие отсрочки и приходится расплачиваться, когда на устранение уязвимости есть всего сутки. Злоумышленники как раз и рассчитывают на то, что вы будете медлить.</p> <h3>Сделайте так, чтобы правильный путь был самым простым</h3> <p>Контролируйте происхождение используемого вами Open Source — еще более строго, чем вы делаете это сейчас.</p> <p>Давно прошли те времена, когда корпоративные разработчики могли скачивать из Интернета всё, что им вздумается, и сразу использовать это в работе. Потребовалось немало усилий, чтобы искоренить эту привычку. Сегодня большинство крупных компаний пропускают все загружаемые зависимости через внутренний прокси-сервер для артефактов — например, JFrog Artifactory или Sonatype Nexus. Разработчики настраивают свои системы сборки на этот прокси, а тот, в свою очередь, подтягивает компоненты из репозиториев вроде Maven Central, npm или PyPI. Заставлять разработчиков снова менять устоявшиеся рабочие процессы — идея не из лучших, да и удовольствия в этом мало.</p> <p>К счастью, этого делать не нужно. Чтобы изменить источник, из которого поступает ПО с открытым исходным кодом, достаточно просто перенастроить прокси-сервер — больше ничего менять не придется. Если указать в качестве источника поддерживаемый сервис (например, TrueSource), то файлы сборки, URL-адреса и конвейеры останутся прежними. Разработчики даже не заметят разницы. Единственное отличие заключается в том, что библиотеки (например, Spring) теперь будут содержать исправления, которые зачастую появляются еще до того, как CVE станет публично известной.</p> <p>Прокси-сервер может взять на себя часть задач по исправлению уязвимостей. Его можно настроить так, чтобы он блокировал версии с известными уязвимостями и автоматически подставлял вместо них ближайшие исправленные версии. В результате сборки продолжают работать, и никому не приходится создавать отдельные заявки на исправление. Исправленный пакет становится версией по умолчанию — разработчики получают его, даже не запрашивая специально.</p> <p>Это критически важный момент для решения проблемы «патчмагеддона» (массового устранения уязвимостей). Менять привычки разработчиков, когда они уже устоялись, — задача непростая. Но поскольку можно просто перенаправить репозитории на другой прокси-сервер, менять привычки сотрудников не требуется.</p> <p>Орен работал с командами, развивающими крупные платформы в сфере финансовых услуг, где зависимости уже проходят через подобные прокси-серверы. Для них задача не сводится к внедрению новой платформы для управления цепочкой поставок ПО во всей организации. Всё гораздо проще: нужно лишь указать прокси-серверу новый источник.</p> <p>Именно поэтому мы утверждаем: единственное приемлемое изменение — это отсутствие видимых изменений.</p> <h3>Остальная часть плана</h3> <p>Описанные выше ключевые аспекты — зачастую самые сложные. Есть еще три момента, которые стоит учесть:</p> <ol> <li><strong> Измеряйте скорость доставки исправлений в производственную среду.</strong> Отслеживайте время, которое проходит с момента раскрытия информации об уязвимости до развертывания исправления — для 50 наиболее важных зависимостей. Именно по этому показателю, как отмечается в отчете J.P. Morgan, вас будут оценивать.</li> <li><strong> Выясните, кто отвечает за поддержку ваших критически важных зависимостей. </strong>Для каждой из них укажите организацию, которая занимается её сопровождением. Пакеты, поддерживаемые одним мейнтейнером, а также заброшенные проекты выделите в отдельный список.</li> <li><strong> Используйте ИИ для поиска уязвимостей и подготовки исправлений</strong>, а к процессу внесения изменений (слияния кода) привлекайте соответствующих специалистов — в идеале, самих мейнтейнеров этого кода.</li> </ol> <p>Сегодня подход к безопасности кардинально меняется. Уделите этому должное внимание и скорректируйте стратегию безопасности вашей организации. Это особенно актуально, если вы — как и большинство крупных компаний, а в особенности финансовые организации — самостоятельно разрабатываете и эксплуатируете значительный объем ПО.</p> Сегодня искусственный интеллект способен превратить патч безопасности в работающий эксплойт всего за несколько часов … article https://www.itweek.ru/themes/detail.php?ID=235937 Thu, 12 Nov 2026 10:29:21 +0300 <p>Проект Open Compute Project (OCP) — это некоммерческая организация, основанная в 2011 году компаниями-учредителями, которая постаралась воспроизвести в аппаратной области подход, используемый в среде разработки открытого ПО. Буквально своей задачей проект поставил выход из ограничений проприетарной ИТ-инфраструктуры, увеличив эффективность, доступность и гибкость в построение инфраструктуры ЦОДа.</p> <h2>OCP против 19 дюймов: когда ЦОДам нужен новый стандарт</h2> <p>Одно из наиболее заметных отличий OCP от привычной серверной инфраструктуры — отказ от классической <nobr>19-дюймовой</nobr> архитектуры в пользу форм-фактора большего размера во всех трех измерениях. Вместе с ним меняется и подход к питанию: вместо множества отдельных блоков и кабелей питания используется централизованная шина (v2 и далее). На первый взгляд разница кажется несущественной. Стойка стала шире, питание организовано иначе — и что с того?</p> <h3>Какие отличия несет стандарт OCP</h3> <p>OCP — это не только новый форм-фактор, это еще и новая концепция построения корпусов серверов — максимально просто и удобно, а также концепция обслуживания — только с одной стороны (с передней). Теперь персоналу в ЦОДе не нужно переходить из холодного коридора в горячий, и наоборот, все обслуживание из комфортного «холодного» коридора, который может уже быть и не таким холодным, а в горячий коридор перенесено обслуживание модулей охлаждение в режиме hotswap без работ с корпусом сервера.</p> <p>Итак, на практике новый стандарт позволяет иначе проектировать всю систему: размещать больше компонентов, эффективнее отводить тепло, эффективнее организовывать обслуживание оборудования, а отсутствие привязки к вендору позволяет расширить выбор и снизить стоимость решения. При первом же проекте построения нового ЦОДа в соответствии со стандартом OCP одна из компаний учредителей проекта OCP заявила, что ее первоначальное развертывание серверной и стоечной инфраструктуры OCP было на 38% более энергоэффективным в строительстве и на 24% дешевле в эксплуатации, чем предыдущие объекты компании.</p> <p>Именно поэтому OCP прежде всего заинтересовал гиперскейлеров. Для компаний, которые строят инфраструктуру с тысячами и десятками тысяч серверов, стойка перестаёт быть просто шкафом, в который устанавливают оборудование. Единицей проектирования фактически становится сама стойка со всеми серверами, питанием и коммутацией внутри.</p> <p>По прогнозам Omdia, к 2030 году доля оборудования в OCP-формате может достигнуть 70%. Но это вовсе не означает, что через несколько лет привычные <nobr>19-дюймовые</nobr> стойки исчезнут. У двух подходов слишком разные области применения.</p> <p>Однако, учитывая все плюсы использования инфраструктуры стандарта OCP: снижение ТСО, очень высокая энергоэффективность, позволяющая достичь P.U.E. 1,05 и ниже, упрощенное обслуживание, отсутствие привязки к вендору и унификация всех компонентов, высокая плотность размещения, поддержка жидкостного охлаждения в самом стандарте, OCP представляется очень перспективным стандартом.</p> <h3><strong>Основные технические преимущества стандарта </strong>OCP</h3> <p>В классическом <nobr>19-дюймовом</nobr> форм-факторе при создании высокоплотной системы возможно масштабироваться только в высоту — количеством юнитов. Нужно разместить больше компонентов, обеспечить питание, оставить достаточно места для охлаждения — и всё это внутри довольно жёстких габаритов. С учетом уровня энергопотребления современных компонентов, в первую очередь GPU-ускорителей и центральных процессоров, это приводит к решениям от 3U до 8U. Если раньше можно было разместить четырехпроцессорный сервер в форм-факторе 2U, то сейчас уже двухпроцессорные серверы с двумя GPU-ускорителями шагают в 3/4U.</p> <p>OCP в свою очередь позволяет свободнее размещать компоненты и увеличивать площадь сечения воздушного потока почти на 20%. Это особенно важно, когда в сервер 2U необходимо установить несколько ускорителей или разместить большую систему хранения данных.</p> <p>Второе важное преимущество — модульность. В обычной стойке может находиться множество двухюнитовых серверов, в каждом из которых установлены собственные блоки питания, что автоматически равняется и куче проводов, а также многопортовых PDU. В OCP питание централизуется в полках, а оборудование подключается непосредственно к общей шине питания — это действительно удобно. Да и MGMT, менеджмент-сеть управления серверами с протоколами IPMI/RedFish, тоже можно подключать по принципу plug&play благодаря низким скоростям передачи данных в этой сети.</p> <p>Есть и выигрыш в энергоэффективности при превышении нагрузки 10 кВт на стойку благодаря общим блокам питания и общей шине питания постоянного тока. Та же логика работает с охлаждением. OCP изначально создавался для плотной инфраструктуры и предусматривает более эффективную организацию воздушных потоков и работу при более высокой температуре окружающего воздуха. Наконец, открытые спецификации теоретически снижают зависимость заказчика от одного производителя. Если разные вендоры выпускают совместимые компоненты в одном стандарте, отдельный сервер или модуль становится легче заменить аналогом. Ключевое слово здесь — «теоретически».</p> <h3>Почему 19 дюймов в ходу</h3> <p>На бумаге возможность использовать оборудование разных производителей выглядит одним из главных достоинств OCP. На практике всё упирается в то, насколько развита экосистема вокруг конкретного типа оборудования. Хороший пример — сетевые коммутаторы. Можно собрать стойку из нескольких десятков серверов в OCP-формате, но затем обнаружить, что подходящих коммутаторов в том же исполнении нужного класса на рынке значительно меньше, чем серверного оборудования. Это не проблема, но внутри стойки в стиле LEGO придётся немного пофантазировать с их размещением и коммутацией.</p> <p>Есть и менее техническая причина — инертность отрасли. Инфраструктура дата-центров вообще меняется довольно медленно. Если существующий подход работает, инженер вполне закономерно задаётся вопросом: зачем его менять?</p> <p>Именно поэтому массовый переход обычно начинается не с инициативы отдельных инженеров, а с управленческого решения: компания на уровне инфраструктурной стратегии определяет, что новые системы будут строиться именно так.</p> <p>Есть и более фундаментальный вопрос — надёжность. В традиционном сервере можно установить два блока питания и подключить их к двум независимым вводам. Отказ одного блока или одного ввода не останавливает сервер. В OCP питание централизовано на уровне стойки. Для гиперскейлера это не обязательно проблема: его отказоустойчивость строится выше — на уровне нескольких стоек, кластеров и даже географически распределённых площадок. Если одна стойка выйдет из строя, нагрузку примут другие.</p> <p>Но для небольшого корпоративного ЦОДа логика может быть другой. Когда критична работа конкретного сервера, а инфраструктура строится по требованиям Tier III или Tier IV, централизованное питание необходимо особенно тщательно учитывать при проектировании схемы резервирования.</p> <h3>Кому подходит OCP</h3> <p>Если среднее потребление стойки составляет около <nobr>5-10 кВт,</nobr> переход на инфраструктуру, рассчитанную на значительно более высокую плотность, практически не даёт преимуществ. Большая часть возможностей новой стойки просто останется невостребованной.</p> <p>Именно поэтому OCP пока трудно назвать универсальным решением для колокейшна и обычной корпоративной инфраструктуры. Если клиент приносит собственное оборудование 19″ с небольшой плотностью и хочет установить его в привычную стойку, у оператора ЦОДа нет причин перестраивать инфраструктуру под OCP.</p> <p>Совсем другая ситуация возникает, когда на один AI-сервер приходится уже <nobr>6-10 кВт,</nobr> а сам сервер занимает шесть-восемь юнитов, и вот вы уже строите стойки на 12, 15, 20 и более кВт.</p> <p>Допустим, к классической стойке подведено 5 кВт мощности. Формально свободного места внутри неё ещё много, но установить даже один современный высокопроизводительный сервер уже невозможно: ограничением становится не физическое пространство, а электричество и охлаждение. В этот момент высокая плотность перестаёт быть красивой характеристикой из спецификации и превращается в практическую необходимость. Высокое потребление также повышает требования к изоляции, разъёмам и безопасности обслуживания. Поэтому рост мощности стойки — это не просто возможность установить больше ускорителей. Он меняет практически всю архитектуру системы.</p> <h3>Как OCP уже используется в классической архитектуре</h3> <p>Наверняка не многие задумываются, увидев в спецификации сервера слот для сетевой карты стандарта OCP. Для многих это уже привычный слот современного классического сервера 19″, использующийся уже много лет большинством производителей. А почему этот элемент, пришедший из стандарта OCP, стал таким популярным? Все очень просто — карта в таком форм-факторе занимает меньше места в сервере и позволяет увеличить количество слотов расширения. Менее популярный стандарт слота — RunBMC, представляющий из себя физически <nobr>260-пиновый</nobr> разъем SODIMM (DDR4) и использующийся для подключения контроллера BMC (контроллера мониторинга и управления сервером). <a name="OLE_LINK26">Применение данного типа разъема</a> позволяет (в теории) использовать контроллеры управления от различных производителей.</p> <p>Также в классические серверы входит стандарт OAM (OCP Accelerator Module) — это открытый стандарт форм-фактора мезонинных плат для вычислительных ускорителей (GPU, NPU, TPU). В отличие от проприетарных разъемов, как например SXM от Nvidia, разъем OAM позволяет выбирать между ускорителями AMD, Intel, Huawei.</p> <p>Но это все отдельные элементы из мира OCP, проникшие в мир классической инфраструктуры 19«.</p> <h2>Как OCP используют в России</h2> <p>Когда речь идёт об OCP на российском рынке, то можно с ходу назвать как минимум пару отечественных производителей оборудования стандарта OCP. Ранее их было минимум три (на слуху), но в реальности их больше. Необходимо учитывать одну характерную особенность. Компания может взять открытые спецификации, создать по ним собственную стойку или сервер, адаптировать решение под свои задачи и вообще не стремиться получить официальный статус OCP Compatible.</p> <p>С практической точки зрения внутри собственного ЦОДа это не всегда проблема. Оборудование работает, нужные преимущества получены, формальное участие в международной экосистеме организации может быть не нужно.</p> <p>Проблема появляется при выходе на глобальный рынок. Если крупный зарубежный заказчик требует именно оборудование OCP Compatible, соответствия конструкции спецификации уже недостаточно. Нужен официальный статус совместимости и участие в соответствующей экосистеме. Для российских компаний сегодня это серьёзный барьер.</p> <p>Ещё одна российская особенность — география строительства ЦОДов. Если новую площадку можно вынести в регион, где доступно значительно больше земли, необходимость любой ценой уплотнять машзал снижается.</p> <p>Резюмируя, можно сформулировать так: интерес к строительству ЦОД по стандартам OCP в России есть, и некоторые компании, имеющие собственные ЦОДы на десятки тысяч серверов, уже используют OCP. Также есть и отечественные производители серверов и СХД стандарта OCP, но рынок оборудования OCP все еще небольшой.</p> <h2>Перспективы OCP</h2> <p>Главным драйвером OCP в ближайшие годы, вероятнее всего, станет искусственный интеллект. Причина здесь не в моде на ИИ, а в физике оборудования. Современные вычислительные системы с большим числом GPU требуют всё больше мощности и выделяют всё больше тепла. Старую инфраструктуру нельзя бесконечно масштабировать простым добавлением новых серверов. В этом случае очень перспективным становится <nobr>4-я</nobr> версия стандарта OCP — ORV4, как раз разработанная для GPU-серверов. Данный стандарт предлагает переход на шину питания 800 В, что даст колоссальную экономию на объеме меди в системе питания оборудования (до 80%) и сокращение потерь электроэнергии до пяти раз при использовании стоек до 1 МВт.</p> <p>Второй возможный драйвер — стандартизация. Чем больше мощности требуют новые системы и чем быстрее приходится вводить вычислительные мощности в эксплуатацию, тем дороже становится проектировать каждую площадку практически заново. Унификация стоек, питания и серверных модулей позволяет сократить сроки разработки и ввода инфраструктуры. Но даже при наличии экономических аргументов останется человеческий фактор. Инфраструктура дата-центров слишком консервативна, чтобы новый формат массово внедрялся сам собой. Там, где переход действительно оправдан, понадобится решение на уровне компании.</p> <p>OCP в этом смысле не является заменой <nobr>19-дюймовому</nobr> стандарту вообще. Это инструмент для определённого класса задач. Если компания эксплуатирует стойки по <nobr>5-10</nobr> кВт и не испытывает проблем с пространством, переход ради самого перехода ей практически ничего не даст. Классический формат ещё долго будет доминировать в обычной корпоративной инфраструктуре.</p> <p>Но там, где начинается высокая плотность — ИИ-кластеры, инфраструктура гиперскейлеров, другие энергоёмкие вычисления — преимущества OCP становятся всё труднее игнорировать. Поэтому вопрос сегодня стоит не в том, вытеснит ли OCP привычные <nobr>19-дюймовые</nobr> стойки. Гораздо полезнее спросить: в какой момент это случится? Для всё большего числа высокоплотных проектов это «новое завтра» уже наступает.</p> <p>#IMAGE_235938#</p> Проект Open Compute Project (OCP) — это некоммерческая организация, основанная в 2011 году компаниями-учредителями … article Сергей Пономарёв, руководитель конструкторского отдела компании “Е-Флопс” https://www.itweek.ru/themes/detail.php?ID=235930 Wed, 11 Nov 2026 14:00:37 +0300 <p>«Базис», российский разработчик ПО управления динамической ИТ-инфраструктурой (входит в ГК «РТК-ЦОД»), представил Basis Repository — платформу для хранения и проверки компонентов ПО по единым правилам безопасности заказчика. Решение позволяет контролировать, какие компоненты доступны командам разработки, и пересматривать разрешение на их использование при появлении новых сведений об уязвимостях. Платформа разворачивается в инфраструктуре заказчика, в том числе в закрытом контуре.</p> <p>Новый продукт предназначен для компаний, которые при создании и обновлении приложений используют стороннее ПО, включая open source компоненты. Платформа помогает разработчикам и ИБ-специалистам согласовывать их использование. Результаты проверок и история решений сохраняются в системе, позволяя видеть, кто и на каком основании разрешил использование конкретного компонента.</p> <p>Заказчик сам определяет требования к компонентам: из каких источников их получать, какие лицензии допустимы и какие использовать нельзя. Basis Repository сопоставляет результаты проверки хранилища с этими требованиями. Разработчики получают из него только ПО, которое соответствует правилам или разрешено ответственным специалистом в порядке исключения.</p> <p>Если команде необходим компонент с известной проблемой, уполномоченный сотрудник может временно разрешить его использование. Он указывает причину и срок действия разрешения. В системе сохраняются результаты проверки компонента и сведения о том, кто и на каком основании принял решение.</p> <p>Проверки можно повторять вручную или по расписанию. Если в ранее разрешенном компоненте обнаружится новая уязвимость, его дальнейшую загрузку из хранилища можно закрыть сразу для всех команд. Реакцию задает заказчик: в зависимости от настроек система может автоматически ограничить или сохранить доступ, в том числе с уведомлением ответственных специалистов.</p> <p>Платформу можно развернуть в изолированных сегментах инфраструктуры заказчика. Для закрытого контура предусмотрен перенос компонентов и данных проверки. Актуальность локальных баз поддерживается по регламенту заказчика. Права на управление платформой и согласование файлов разграничиваются по ролям, а значимые действия фиксируются в журнале аудита.</p> <p>Платформа проверяет отдельные компоненты и их наборы. По результатам анализа формируется ППК — перечень обнаруженных программных компонентов и их версий. Сведения о выявленных уязвимостях сопоставляются с записями Банка данных угроз ФСТЭК России. При передаче набора компонентов предусмотрен подписанный паспорт, который помогает проверить соответствие полученного содержимого проверенному составу.</p> <p>При проверках учитываются лицензии и сроки поддержки компонентов. Заказчик задает правила использования версий, которые больше не поддерживаются. Основанием для пересмотра разрешения на использование могут стать новая уязвимость, изменение правил компании или окончание срока временного разрешения.</p> <p>Ключевая функциональность Basis Repository реализована в собственном коде «Базиса». Она включает управление проверками, применение правил допуска, согласование и публикацию компонентов. ПО с открытым исходным кодом используется только для отдельных задач: хранения и доставки пакетов, идентификации пользователей и некоторых технических проверок.</p> <p>Basis Repository поддерживает пакеты Linux в форматах RPM и DEB, контейнерные образы Docker/OCI, пакеты npm, Maven и PyPI, а также бинарные архивы. Управление доступно через веб-портал и API. Для получения опубликованных пакетов и образов используются стандартные системные утилиты.</p> <p>«Безопасная разработка становится все более востребованной, но на российском рынке не было подходящего инструмента для хранения компонентов и контроля их использования по единым правилам. Этот запрос бизнеса и стал отправной точкой к созданию Basis Repository. Мы опирались на собственный опыт разработки Basis Digital Energy и взаимодействие с ФСТЭК России. Решение дополнит экосистему „Базиса“ и поможет заказчикам снизить риски использования открытого кода», — отметил Давид Мартиросов, генеральный директор «Базиса».</p> «Базис», российский разработчик ПО управления динамической ИТ-инфраструктурой (входит в ГК «РТК-ЦОД»), представил … message https://www.itweek.ru/themes/detail.php?ID=235929 Wed, 11 Nov 2026 13:59:33 +0300 <p>Компания Postgres Professional выпустила новую версию решения для резервного копирования и восстановления Postgres Pro Backup Enterprise (ProBackup) 3.5.0. Обновление объединяет удаленное восстановление в едином инструменте, ускоряет восстановление после сбоев и миграцию, упрощает синхронизацию реплик и повышает эффективность управления сроками хранения резервных копий. Это позволяет компаниям сокращать время простоя критичных сервисов и снижать нагрузку на ИТ-команды.</p> <p>В ProBackup 3.5.0 функциональность удаленного восстановления полностью перенесена в основную утилиту pg_probackup3. Теперь резервную копию можно передать по сети, распаковать и восстановить на целевом сервере в многопоточном режиме — без ручного копирования архивов и использования сторонних инструментов. Решение поддерживает как полное восстановление в пустой каталог, так и инкрементальное восстановление.</p> <p>Новый подход особенно актуален для компаний с централизованным хранилищем резервных копий и удаленными площадками. Он сокращает время восстановления (RTO), уменьшает число ручных операций и упрощает аварийное восстановление, миграцию и автоматическое развертывание серверов.</p> <p>В команде catchup, предназначенной для клонирования и синхронизации экземпляров PostgreSQL, появился параметр sync-replica. Он позволяет предварительно проверить возможность синхронизации реплики с ведущим сервером при расхождении историй линий времени, в том числе после повышения реплики.</p> <p>Администратор может сначала выполнить диагностическую проверку без изменения данных, получить подробный отчет и оценить риски. Затем утилита определяет точку расхождения, при необходимости выполняет откат с помощью pg_rewind и синхронизирует реплику с ведущим сервером. Это снижает вероятность ошибок при восстановлении репликации и помогает быстрее возвращать инфраструктуру в рабочий режим.</p> <p>Управление политиками хранения резервных копий стало многопоточным. В команде retention добавлены параметры threads, num-write-threads и num-validate-threads, которые ускоряют ресурсоемкие операции объединения устаревших резервных копий и очистки архивов.</p> <p>Новый параметр wal-depth позволяет при очистке журналов транзакций (WAL) гарантированно сохранять сегменты, необходимые для восстановления базы данных на нужный момент времени (PITR). Также улучшена стабильность потоковой передачи WAL: keepalive-сообщения предотвращают разрыв соединения по тайм-ауту при длительном отсутствии нагрузки на СУБД.</p> <p>В ProBackup 3.5.0 ускорена работа с SFTP, S3-совместимыми хранилищами и сжатой файловой системой CFS. Передача данных на удаленный хост теперь выполняется асинхронно несколькими запросами в рамках лимитов SFTP-сервера, а размер буфера обмена по умолчанию увеличен с 128 КБ до 1 Мб.</p> <p>Добавлена настройка тайм-аутов для S3-запросов, ускорены проверка резервных копий в режиме STREAM и монтирование копий через FUSE. Для заказчиков это означает более быстрое создание и проверку копий, меньшую нагрузку на сеть и более предсказуемую работу с облачными платформами.</p> <p>В новой версии усилены безопасность и надежность восстановления. Устранена уязвимость, позволявшая выполнить произвольную команду оболочки через путь к точке монтирования при размонтировании FUSE, а также исправлено переполнение буфера при передаче длинных значений параметров remote-host и remote-user.</p> <p>Отдельное внимание уделено работе с шифрованием TDE и сжатой файловой системой CFS: исправлены ошибки, которые могли приводить к некорректному восстановлению зашифрованных или сжатых данных. Также устранены ошибки, затрагивающие сохранность копий, удаление экземпляров в S3, инкрементальное восстановление после изменения линии времени и обработку WAL-файлов большого размера.</p> <p>«Для заказчика резервное копирование — это гарантия быстрого возвращения критичных сервисов в работу после сбоя. В ProBackup 3.5.0 мы сделали восстановление более автоматизированным, ускорили работу с удаленными хранилищами и повысили надежность синхронизации реплик. Это помогает ИТ-командам тратить меньше времени на ручные операции и увереннее обеспечивать непрерывность бизнеса», — отметил Алексей Дарвин, руководитель продукта Postgres Pro Backup Enterprise.</p> Компания Postgres Professional выпустила новую версию решения для резервного копирования и восстановления Postgres Pro … message https://www.itweek.ru/themes/detail.php?ID=235928 Wed, 11 Nov 2026 13:58:38 +0300 <p>Angara MTDR обновила один из ключевых модулей Angara AVM — сервиса контроля внутреннего контура в составе центра управления уязвимостями Angara VOC. Изменения помогают компаниям-заказчикам получать более полные сведения об активах внутренней инфраструктуры.</p> <p>Обновленный модуль сканирования уязвимостей (Vulnerability Scanner, VS) помогает устранять проблемы, с которыми компании нередко сталкиваются при регулярных проверках. Так, закрытая заявка на исправление не всегда подтверждает, что уязвимость устранена, а ручное сопоставление результатов сканирований сопряжено с высокими трудозатратами. Кроме того, частые проверки нагружают рабочие системы и требуют согласования с другими подразделениями.</p> <p>Теперь модуль точнее отслеживает жизненный цикл выявленных уязвимостей. Он сопоставляет результаты последовательных сканирований и показывает, какие уязвимости появились впервые, какие устранены, а какие сохраняются, что дает прозрачный контроль устранения и сроков исправления. В дополнение к этому расширены возможности проверки серверов, рабочих станций, сетевого оборудования, веб-приложений других компонентов инфраструктуры. Управление заданиями, расписаниями и интенсивностью сканирования позволяет адаптировать проверки к технологическим окнам и допустимой нагрузке на системы. </p> <p>Модуль контроля параметров безопасности (Security Profile Compliance, SPC) отслеживает состояние настроек систем, которые меняются в ходе обычной работы. Без такого контроля настройки сверяют с требованиями эпизодически и вручную, и небезопасное изменение может долго оставаться незамеченным.</p> <p>Интеграция нового модуля SPC расширяет возможности регулярной сверки настроек ИТ-активов с утвержденными профилями безопасности, внутренними политиками, требованиями организации и выбранными рекомендациями. Модуль выявляет отклонения и контролирует их устранение. Проверки могут охватывать операционные системы, СУБД, прикладное ПО, контейнерные платформы и сетевое оборудование. Наряду с готовыми профилями можно применять настраиваемые проверки с учетом внутренних требований организации. Регулярные проверки помогают выявлять небезопасные изменения настроек и отслеживать устранение отклонений.</p> <p>«Отчет о сканировании фиксирует состояние инфраструктуры на конкретную дату, но сама инфраструктура постоянно меняется. Чтобы понимать, снижается ли риск, важно видеть динамику — какие уязвимости закрыты после исправлений и не появились ли небезопасные изменения в настройках систем. Поэтому мы развиваем AVM как инструмент постоянного контроля внутреннего контура, где уязвимости в ПО и настройки систем рассматриваются вместе. В рамках Angara VOC эти данные дополняются результатами контроля внешнего периметра и экспертной оценкой», — отметил Артем Грибков, директор Центра киберустойчивости Angara MTDR.</p> <p>Компания также готовит обновление сервиса Angara ASM для контроля внешнего периметра. Для него разрабатываются новый личный кабинет, обновленное технологическое ядро, а также ряд других изменений. </p> Angara MTDR обновила один из ключевых модулей Angara AVM — сервиса контроля внутреннего контура в составе центра … message https://www.itweek.ru/themes/detail.php?ID=235927 Wed, 11 Nov 2026 13:57:51 +0300 <p>Российская компания CyberThreatTech (ООО Технологии киберугроз) объявила о запуске CTT AI Threat Feed, специализированного продукта класса Threat Intelligence, предназначенного для отслеживания киберугроз, направленных на системы искусственного интеллекта. По оценке компании, это первый в России и странах СНГ специализированный фид, предоставляющий структурированные машиночитаемые знания о тактиках, техниках и процедурах атак непосредственно на AI-системы. В пятницу, 13 ноября, в 10.00 состоится онлайн-трансляция презентации CTT AI ATTACK PULSE напрямую из Музея криптографии.</p> <p>Развитие искусственного интеллекта становится одним из основных направлений автоматизации бизнеса. Компании внедряют большие языковые модели, интеллектуальных помощников и автономных AI-агентов в клиентское обслуживание, разработку программного обеспечения, аналитику, документооборот и управление корпоративными системами.</p> <p>По мере расширения использования ИИ растёт и поверхность атаки. AI-приложения обрабатывают корпоративную информацию, взаимодействуют с внешними источниками данных и получают доступ к различным бизнес-системам. Это создаёт дополнительные возможности для злоумышленников, а также новые требования к средствам защиты. Сегодня организации регулярно отслеживают уязвимости, вредоносное программное обеспечение, индикаторы компрометации и техники атак на традиционную ИТ-инфраструктуру. CyberThreatTech предлагает распространить аналогичный подход на инфраструктуру искусственного интеллекта.</p> <p>«Искусственный интеллект становится частью корпоративной инфраструктуры, и его безопасность требует такого же системного подхода, как защита серверов, сетей и приложений. Мы видим, как быстро появляются новые способы воздействия на AI-модели и агентов. Наша задача состоит в том, чтобы собирать эти знания, анализировать их и предоставлять в формате, который может использоваться непосредственно средствами защиты. AI Firewall должен получать актуальную информацию об угрозах так же, как традиционные средства безопасности получают обновления об уязвимостях и атаках», — прокомментировал Николай Арефьев, основатель и генеральный директор CyberThreatTech.</p> <p>CTT AI Threat Feed агрегирует сведения из отчётов об угрозах, посвящённых атакам на AI-модели, приложения и агентов. Продукт охватывает тактики, техники и процедуры (TTP), применяемые для воздействия на системы искусственного интеллекта. Полученная информация анализируется, систематизируется и преобразуется в структурированный машиночитаемый формат. Это позволяет использовать результаты Threat Intelligence в автоматизированных процессах защиты, исследования и проверки безопасности AI-инфраструктуры.</p> <p>Ключевая особенность CTT AI Threat Feed заключается в возможности передавать знания об угрозах непосредственно программным системам, которым эти сведения необходимы для выполнения защитных функций. </p> Российская компания CyberThreatTech (ООО Технологии киберугроз) объявила о запуске CTT AI Threat Feed … message https://www.itweek.ru/themes/detail.php?ID=235926 Wed, 11 Nov 2026 13:56:05 +0300 <p>Крупный российский бизнес перешел в режим экономии, но от технологического развития не отказывается: деньги получают проекты с быстрым и измеримым эффектом, а главной ставкой остается искусственный интеллект. Об этом свидетельствуют данные исследования AxRadar консалтинговой технологической компании Axenix. Эксперты провели глубинные интервью с ИТ-руководителями (CIO, CDTO, CTO) более 50 крупнейших компаний из пяти отраслей: банков, ритейла, производства потребительских товаров (CPG), добычи и производства, а также агросектора.</p> <p>Сегодня ИТ развивают 58% опрошенных компаний, но активно — лишь 17%, еще 41% — умеренно. Остальные 42% держат ИТ на базовом уровне и пока ограничиваются тем, что закрывают основные потребности в цифровизации процессов. Разрыв между лидерами и остальными уже заметен, и, по оценке авторов исследования, если внешние условия не изменятся, доля компаний, развивающих ИТ, будет сокращаться.</p> <p>Причина сдержанности — в приоритетах бизнеса. Главным из них 67% компаний называют операционную эффективность и сокращение затрат. Органический рост и расширение доли рынка важны для 50%, новые продукты и источники прибыли — для 44%. Отсюда и новая логика ИТ-инвестиций: технологии финансируют под снижение издержек и рост производительности.</p> <p>Даже в режиме экономии ИИ остается главной технологической ставкой. Машинное обучение и генеративный ИИ входят в топ-5 ИТ-приоритетов у 58% компаний и уже используются в промышленной эксплуатации у 61%. Вместе с операционной эффективностью ИИ занимает центральное место в ИТ-повестке: хотя бы одно из этих направлений входит в топ-5 у 85% компаний, у трети — оба сразу.</p> <p>Новая волна использования ИИ и ГенИИ пока остается в экспериментах: AI-native платформы разработки пилотируют 39% компаний, а используют лишь 5%, мультиагентные системы работают только у 7%.</p> <p>Почему пилотные проекты не масштабируются? Главный барьер — неясная окупаемость: его назвали 48% респондентов. ИИ-проекты конкурируют за бюджет с бизнес-инициативами, и выигрывают те, у которых доказан финансовый эффект и короткий срок реализации. По словам ИТ-директоров, при правильном выборе функций эффект ИИ может в разы превышать вложения, но успешных примеров на рынке пока мало, а внедрение дорогое и долгое. Часть ИТ-директоров и вовсе предупреждает о риске «внедрения ИИ ради ИИ».</p> <p>Темпы внедрения сдерживают и другие факторы: качество и доступность данных, риски информационной безопасности, нехватка экспертизы. Поэтому быстрее отдачу получают те, у кого уже готовы процессы, данные и команда: они сначала выстраивают работу с данными, а затем выбирают функции с измеримым эффектом.</p> <p>Доказывать эффект приходится еще и потому, что свободных денег на развитие немного. Компании разделились почти поровну: 47% увеличат ИТ-бюджет, 29% сохранят его на текущем уровне, 24% сократят. Разброс по отраслям большой: банки тратят на ИТ 11,3% выручки, остальные — около 2%. Для банка технологии во многом и есть продукт, для промышленности и ритейла — прежде всего инструмент эффективности.</p> <p>Но даже растущий бюджет не гарантирует развития. Важно, какая его часть идет на новые проекты — ИИ, новые системы, цифровые продукты (CHANGE), а какая уходит на поддержку текущего ИТ-ландшафта (RUN).</p> <p>Здесь ситуация в отраслях тоже заметно различается. Больше половины банков и ритейлеров направляют на развитие свыше 60% ИТ-бюджета, производственные и добывающие компании — примерно половину. В CPG и агросекторе основная доля бюджета уходит на поддержку. По словам ИТ-директоров, значительную часть ресурсов забирают выполнение регуляторных требований, вынужденное импортозамещение и сопровождение текущих систем, и на ИИ и новые проекты остается немного.</p> <p>Поэтому ключевая задача сейчас — не только добиться большего бюджета, но и высвободить средства из поддержки: модернизировать устаревшие системы и сократить технический долг.</p> <p>Ограничения бюджета мешают реализации ИТ-планов у 67% компаний, а в ритейле и агросекторе — у 89%. На втором месте кадры: в нехватку компетенций, дефицит ИТ-специалистов или сложности с удержанием сотрудников упираются 54% компаний. Самый дефицитный навык — ИИ и машинное обучение (42%), далее идут кибербезопасность (27%), работа с данными и бизнес-анализ (по 25%).</p> <p>При этом формирование команды и развитие компетенций входят в пятерку ИТ-приоритетов только у 17% компаний. Без собственных компетенций бизнес зависит от подрядчиков и медленнее переводит пилоты в промышленную эксплуатацию. По мнению ИТ-директоров, в перспективе технологические компетенции придется развивать не только ИТ, но и самому бизнесу.</p> <p>«Главное, что сдерживает ИТ-планы крупного бизнеса, — деньги и люди. При этом развитие команды редко входит в ключевые приоритеты. Получается парадокс: компании делают ставку на ИИ, но не растят людей, которые будут его внедрять и развивать. К этому добавляется регуляторная нагрузка: она забирает ресурсы, которые могли бы пойти на развитие», — прокомментировал Егор Викторов, директор практики стратегического консалтинга компании Axenix.</p> <p>Российские компании последовательно импортозамещали иностранные решения, и сегодня острая фаза позади. Средняя доля отечественных продуктов в технологическом ландшафте составляет 65%: в агропромышленности — 85%, в добыче и производстве — 70%, в банковском секторе — 57%. Поэтому в пятерку ИТ-приоритетов импортозамещение включили только 23% участников исследования. Ставка теперь — на собственную инфраструктуру: 55% компаний придерживаются политики on-premise first, а облачную миграцию в приоритеты не включил никто.</p> <p>Но последствия перехода остаются: новые системы нужно поддерживать и развивать. Собственная инфраструктура надежнее, однако, как признают ИТ-директора, запускать на ней пилоты и тиражировать новые решения получается медленнее.</p> <p>Прагматичный подход к технологиям меняет и роль ИТ-директора. Через <nobr>3-5 лет,</nobr> по мнению респондентов, технологии из источника преимущества станут необходимым условием конкурентоспособности. CIO будет влиять на развитие бизнеса как советник с ответственностью за результат, а ИТ-проекты будут оценивать по окупаемости наравне с другими инвестициями. Пока же ИТ часто воспринимают как сервис, и скорость перемен сильно зависит от зрелости компании.</p> <p>«Крупный российский бизнес подошел к новому этапу технологического развития. Большинство крупных компаний уже закрыли базовые потребности в цифровизации и имеют развитые, частично импортозамещенные корпоративные системы. Лидеры считают внедрение ИИ приоритетом и активно включают его в ИТ-повестку вместе с операционной эффективностью — от этого напрямую зависит конкурентоспособность. При этом критерии отбора проектов максимально прагматичны: деньги получают инициативы с быстрым и измеримым эффектом», — прокомментировала Анастасия Студенкина, директор практики стратегического консалтинга компании Axenix.</p> <p>Исследование проходило с июня по август 2026 года. По его итогам аналитики рассчитали индекс технологических настроений от 0 до 100 баллов: он учитывает цифровую зрелость, ИТ-бюджет, планы и барьеры компаний и показывает, насколько уверенно ИТ-руководители смотрят на технологическое развитие в ближайшей перспективе. Axenix планирует проводить исследование ежегодно, чтобы отслеживать, как меняются настроения рынка и отдельных отраслей.</p> Крупный российский бизнес перешел в режим экономии, но от технологического развития не отказывается: деньги … message https://www.itweek.ru/themes/detail.php?ID=235925 Wed, 11 Nov 2026 13:24:06 +0300 <p>Я несколько лет занимаюсь системами машинного зрения для производства и почти каждый раз вижу одну и ту же картину. Проект доходит до ИТ-службы в последний момент. Технологи выбрали дефект, камера и свет стоят, станция контроля прошла приёмку, и только тогда кто-то спрашивает, куда система складывает результаты. Вопросы простые, но если не решить их до запуска, через полгода данные контроля качества окажутся на локальном диске станции и пропадут при первой замене оборудования.</p> <h3>Что система оставляет после себя</h3> <p>Станция контроля работает по жёсткой схеме. Датчик позиции даёт триггер, камера снимает деталь, программа ищет дефекты или меряет геометрию, сравнивает с допуском и выносит вердикт «годен» или «брак». На каждую деталь остаётся кадр с разметкой, измеренными значениями и решением. Оператору линии нужен только сигнал на отбраковку, и нужен он доли секунды. Всем остальным, от отдела качества до разработчиков модели, нужен кадр, и нужен месяцами.</p> <h3>Почему счётчика брака мало</h3> <p>Счётчик за смену отвечает на вопрос «сколько». На вопрос «почему» отвечают кадры. Пришла рекламация, и отдел качества хочет увидеть, что камера видела при проверке этой партии. Доля брака выросла на одной смене, и по снимкам понятно, был ли это настоящий дефект, грязная оптика или сдвинутый свет. Технологи спорят, считать ли мелкую пору браком, и спор идёт по одним и тем же снимкам, а не по пересказу. Когда архива нет, все эти разговоры превращаются в мнения.</p> <p>Есть и причина, о которой на старте обычно не думают. Самые ценные примеры для дообучения модели — редкие дефекты. Собрать их дольше, чем обучить модель, и взять их можно только из архива решений с линии. Если кадры не сохранять с первого дня, через год модель придётся улучшать на тех же немногих примерах, что были на пилоте.</p> <h3>Что хранить и сколько</h3> <p>Непрерывное видео с камеры контроля почти никогда не нужно, и я бы не стал под него строить хранилище. Хранить стоит кадры решений: весь брак, выборку годных деталей и все случаи, которые система отправила человеку на осмотр. Объём зависит от темпа линии и разрешения камеры. Считать его лучше на пилоте по реальному потоку, а не по паспорту оборудования, цифры обычно расходятся. Срок хранения удобно привязать к сроку, в течение которого по партии могут прийти претензии, и к циклу дообучения модели.</p> <h3>Связь с учётом</h3> <p>Кадр без номера партии, смены и линии почти бесполезен: найти его потом можно только по времени, и то если часы станции не уходили. Поэтому номер партии должен приходить на станцию из MES или учётной системы, а обратно уходить вердикт с причиной брака. Тогда отчёт по качеству живёт там же, где остальная производственная статистика, и из строки отчёта можно открыть конкретный кадр. Способ обмена (сигнал контроллера, API, выгрузка файлов) я советую согласовать до монтажа, пока ещё можно выбирать.</p> <h3>Кто за что отвечает на приёмке</h3> <p>Технологи на приёмке проверяют точность: долю пропусков и ложных отбраковок на реальном потоке. У ИТ-службы свои пункты. Куда пишутся кадры, у кого к ним доступ, что будет с архивом при замене станции или камеры, где лежит резервная копия и кто её проверяет. Эти вопросы стоит записать в протокол приёмки рядом с цифрами точности. Тогда их не придётся решать задним числом, когда диск станции заполнится.</p> <p>Машинное зрение даёт цеху сплошной контроль вместо выборочного. Будет ли у предприятия через год ещё и разобранный архив брака, решается в тот момент, когда выбирают камеру и свет. Мой совет коллегам из ИТ простой: просите позвать вас на это обсуждение, а не на приёмку.</p> Я несколько лет занимаюсь системами машинного зрения для производства и почти каждый раз вижу одну и ту же … article Антон Савельев, ведущий специалист по компьютерному зрению Visor Group https://www.itweek.ru/themes/detail.php?ID=235923 Wed, 11 Nov 2026 10:18:02 +0300 <p><em>Если агент искусственного интеллекта дает сбой в процессе выполнения задачи, наличие надежных записей о действиях и четко определенных границ использования инструментов позволяет заменить его другим агентом, который продолжит работу безопасно и без дублирования операций, пишет на портале </em><em>The</em> <em>New</em> <em>Stack</em> <em>Манвир Чавла — соучредитель компании Zenith (ранее занимал должность директора по разработке в Confluent и руководил направлением Growth Engineering в Dropbox).</em></p> <p>Представим ситуацию: агент получает одобрение на частичный возврат средств. Он отправляет запрос к платежному API, но в этот момент происходит сбой. Возможно платежный сервис успел провести возврат, а возможно запрос даже не дошел до него. На смену приходит новый агент, который обнаруживает запись об операции со статусом «отправлено» (dispatched), но без зафиксированного результата.</p> <p>Подобная неопределенность свойственна не только ИИ-агентам. С такой же проблемой сталкиваются любые распределенные системы, если рабочий процесс прерывается в момент внесения изменений. Однако обычный программный агент (worker) в такой ситуации просто возобновляет заранее заданный алгоритм с последней контрольной точки. ИИ-агент действует иначе: он принимает решения самостоятельно — и это создает дополнительные риски. Столкнувшись с тем же запросом от клиента при отсутствии записи о результате, агент может выстроить совершенно иной план, выбрать другие параметры или решить инициировать новый возврат, вместо того чтобы завершить уже одобренную операцию.</p> <p>Если первый возврат прошел успешно, то вторая попытка приведет к тому, что клиенту вернут средства дважды. Поскольку на исходном платеже достаточно средств для еще одного частичного возврата, ничто не помешает совершить эту ошибку.</p> <p>Новый агент должен «унаследовать» исходную операцию, а не интерпретировать ее заново.</p> <h3>Операция должна пережить агента</h3> <p>Процесс агента, его переменные в оперативной памяти, временный контекст рассуждений — все это может быть утрачено без ущерба для дела. Но бизнес-операция — например, возврат средств, его одобрение, параметры и текущий статус — должна быть сохранена. Агент, работающий в течение длительного времени, должен сохранять полезные данные, пока он активен. Однако важно соблюсти условие: ни одна критически важная операция не должна зависеть от того, продолжает ли работать исходный экземпляр агента.</p> <p>Перед отправкой запроса на возврат средств приложение сохраняет запись об операции в надежном хранилище (транзакционной базе данных). Эта запись содержит одобренную сумму, соответствующие права доступа, ключ идемпотентности (передаваемый платежному провайдеру), идентификатор операции в метаданных провайдера, а также текущий статус.</p> <p>Статус меняется с «создано» (created) на «отправлено» (dispatched) в момент отправки запроса, а на «подтверждено» (confirmed) или «сбой» (failed) — только после получения ответа от провайдера. Если агент выходит из строя, его преемник считывает эту запись и связанные с ней идентификаторы, что позволяет корректно продолжить выполнение задачи. Если запись находится в состоянии «отправлено», это означает, что была предпринята попытка выполнения операции, но результат не был зафиксирован.</p> <p>При повторном запуске (замещающий процесс) используется уже одобренная операция, а не создается новая.</p> <p>Если замещающему процессу необходимо проверить результат, он может запросить список возвратов средств, связанных с исходным платежом, и сопоставить идентификатор операции в полученных метаданных.</p> <p>Однако такая «устойчивая» (durable) запись служит не просто контекстом для повторного запуска. Приложение обеспечивает ее соблюдение на границе взаимодействия с внешними инструментами: уровень отправки запросов проверяет каждый исходящий вызов на соответствие зафиксированной записи. Агент может предложить следующий шаг, но до провайдера доходят только те операции, которые были одобрены ранее — с сохранением исходных параметров и идентификатора. Модель не может изменить то, что уже было утверждено.</p> <p>Пример: бизнес-данные, включая эталонную запись об операции, определяющую допустимые действия для замещающего процесса, хранятся в управляемой ClickHouse базе данных Postgres. С помощью технологии CDC (Change Data Capture) эти данные реплицируются в ClickHouse. Телеметрия приложения передается в ClickStack, а трассировки агента — в Langfuse; обе системы настроены на использование того же экземпляра ClickHouse в качестве основной базы данных.</p> <p>#IMAGE_235924#</p> <p>Поскольку бизнес-данные, телеметрия приложения и трассировки агента попадают в одну базу данных, для связывания операции с конкретным запуском агента (который инициировал запрос) и неудачным HTTP-вызовом достаточно одного запроса по идентификатору. Это избавляет от необходимости сопоставлять данные из трех разных инструментов.</p> <p>Здесь есть два условия. Во-первых, приложение должно передавать этот идентификатор дальше. Идентификатор операции должен присутствовать в строке Postgres, в атрибутах трассировки Langfuse и в контексте логов сервиса, поскольку автоматической корреляции между ними не существует. Во-вторых, замещающий процесс должен считывать запись непосредственно из Postgres, а не из ее реплицированной копии. CDC работает с задержкой в ​​несколько секунд. Эталонная запись в основной базе данных является той самой, которую контролирует механизм на границе взаимодействия с внешними системами.</p> <h3>Перезапуск выполнения — это еще не безопасное возобновление работы</h3> <p>Фреймворки для обеспечения «устойчивого» выполнения (durable execution), такие как LangGraph и Temporal, фиксируют прогресс выполнения и позволяют возобновить работу после сбоя. В обоих случаях рекомендуется делать побочные эффекты идемпотентными, поскольку простое возобновление процесса не решает проблему повторного выполнения. Если возврат средств был успешно проведен в тот момент, когда шаг еще числился как «ожидающий», фреймворк может перезапустить агента, но не сможет сообщить ему, был ли исходный запрос принят платежным провайдером.</p> <p>Запись об «устойчивой» операции реализует этот принцип идемпотентности для агента, чей следующий шаг заранее не определен.</p> <p>Ключ идемпотентности из такой записи связывает замещающий процесс с исходным запросом. Если при повторной попытке используется тот же ключ, поставщик услуг может распознать, что речь идет об одной и той же операции, вместо того чтобы выполнять ее как отдельный запрос на возврат средств. Это справедливо даже в том случае, если исходный запрос, отправленный агентом, был завершен уже после сбоя, или если процесс, который ошибочно сочли «мертвым», возобновил свою работу. В библиотеке AWS Builders’ Library этот шаблон формализован: идентификатор, предоставляемый вызывающей стороной, сохраняется атомарно вместе с операцией изменения данных (mutation).</p> <p>Однако повторная попытка не всегда безопасна. Результат может оставаться неопределенным. В документации Stripe указано, что ответ с кодом 500 при выполнении mutation все равно может привести к внешним последствиям. Если исход неизвестен, замещающему агенту требуются доказательства для проведения расследования.</p> <p>Langfuse позволяет увидеть, какой инструмент использовал предыдущий агент — например, запрос на возврат средств, отправленный с зафиксированным ключом идемпотентности. ClickStack дополняет картину на операционном уровне: показывает исходящий HTTP-запрос к платежному сервису, за которым последовал разрыв соединения, что позволяет сузить временной интервал возникновения ошибки.</p> <p>Оба источника данных доступны замещающему агенту напрямую. MCP-сервер Langfuse позволяет запрашивать трассировку предыдущего агента по идентификатору операции, а MCP-сервер ClickStack — искать события в сервисе за тот же промежуток времени. Предоставьте замещающему агенту только инструменты для чтения данных: он сможет проанализировать произошедшее, но границы доступных инструментов по-прежнему будут ограничивать его действия.</p> <p>Ни одна из трассировок не является доказательством того, что провайдер действительно выполнил возврат средств. Отсутствие трассировки также не доказывает, что запрос не был отправлен, поскольку Langfuse передает данные асинхронно, и сбой в системе мог помешать их доставке. Платежный провайдер остается первоисточником информации о внешнем результате операции. Телеметрия выполнения помогает сузить область поиска, но не заменяет собой официальное подтверждение.</p> <h3>Продолжайте работу, а не начинайте всё сначала</h3> <p>В распоряжении замещающего агента есть постоянная запись о действиях, а в случаях, когда результат остался неясным — еще и свидетельства выполнения операции. Теперь ему необходимо предпринять дальнейшие шаги, но не путем принятия нового решения о том, что нужно сделать.</p> <p>Замещающий агент следует протоколу восстановления, определенному в приложении, а не полагается на собственное суждение о ситуации клиента.</p> <p>Если провайдер подтверждает, что возврат выполнен, агент фиксирует результат и переходит к следующим задачам. Если провайдер сообщает, что возврат находится в ожидании или в процессе выполнения, агент ждет — повторная попытка может привести к дублированию операции. Если же возврат определенно не удался и не повлек за собой никаких внешних изменений, агент заново проверяет предварительные условия перед новой санкционированной попыткой. Если результат по-прежнему остается неясным, агент эскалирует задачу на более высокий уровень, а не пытается угадать исход. Отсутствие записи у провайдера не означает, что возврат не был обработан — возможно, провайдер еще не завершил транзакцию.</p> <p>Даже после выяснения внешнего результата замещающий агент должен убедиться, что состояние системы не изменилось. Например, сумма, доступная для возврата, могла измениться. Сотрудник мог оформить возврат средств через другой интерфейс. Статус учетной записи клиента мог измениться. Кто-то мог отозвать первоначальное разрешение.</p> <p>Сохраненное одобрение — это лишь историческое свидетельство, а не действующее полномочие для выполнения операций.</p> <p>С инженерной точки зрения ключевой вопрос заключается в том, сможет ли новый агент определить текущую цель работы, невыполненные обязательства и возможные неопределенные последствия, а затем безопасно продолжить процесс — не воспринимая при этом сведения, оставшиеся от предшественника, как руководство к действию.</p> Если агент искусственного интеллекта дает сбой в процессе выполнения задачи, наличие надежных записей о действиях … article https://www.itweek.ru/themes/detail.php?ID=235921 Wed, 11 Nov 2026 10:05:58 +0300 <p>В современной разработке автоматизация проверок безопасности стала такой же частью DevOps, как CI/CD или контроль версий. Она помогает оценивать код, зависимости, защищенность контейнеров и инфраструктуру, практически в том же темпе, в котором ИТ-команды внедряют изменения в продукт. Без анализа этих компонентов сегодня сложно представить разработку безопасного ПО. Тем не менее, такой подход упрощает поиск уязвимостей, но не позволяет выявить все риски.</p> <p>После подключения сканеров ИБ-специалисты часто сталкиваются с избыточными и нерелевантными срабатываниями, а часть критичных слабых мест при этом остается незамеченной. Причина не в том, что инструменты работают неправильно, а в том, что они не способны учитывать весь контекст конкретной системы. Разберем, почему автоматические проверки кода и инфраструктуры дают ложные сигналы, как сократить уровень шума и в каких случаях экспертный аудит остается обязательной частью DevSecOps.</p> <h3>Почему сканеры ошибаются</h3> <p>Большое количество срабатываний — одна из главных особенностей работы сканеров, в частности SAST-инструментов. Они фиксируют все подозрительные фрагменты кода, которые соответствуют заданным правилам, но далеко не каждая из них указывает на уязвимость. В одном отчете могут оказаться как действительно опасные дефекты, так и находки, которые инструмент оценивает как критичные, хотя с учетом особенностей конкретной системы они не представляют реальной угрозы.</p> <p>Распространенная причина неточных результатов — ограничения статического анализа. SAST-инструменты проверяют исходный код без запуска приложения. Они видят потенциально опасные фрагменты, но не всегда понимают, какие значения получат переменные во время выполнения, какие условия заложены в бизнес-логике и какие защитные механизмы уже работают в системе. Поэтому сканер может отметить участок программы как уязвимый, хотя в реальном сценарии использовать его для атаки невозможно.</p> <p>На точность влияет и то, что большинство правил, по которым работают автоматические средства анализа, универсальны. Они рассчитаны на разные языки, фреймворки и архитектуры, поэтому не учитывают особенности конкретного приложения. В проекте могут использоваться внутренние безопасные обертки, API-шлюзы, фильтрация запросов или политики service mesh, которые снижают риск эксплуатации. При этом инструмент может не знать об этих механизмах и продолжить оценивать программу по общему шаблону.</p> <p>Дополнительный источник лишних срабатываний — некорректно настроенный контур проверки. Если под одинаковый набор правил попадают тестовые директории, временные ветки, прототипы, устаревшие компоненты и библиотеки, количество нарушений быстро растет. При этом часть замечаний относится к коду, который не входит в поставку или не влияет на работу продуктивной системы.</p> <p>После обнаружения дефекта важно квалифицировать его приоритет. Автоматизация способна выявить характер уязвимости, но не всегда понимает ее реальную значимость для определенного проекта. Без учета особенностей ресурса невозможно установить, насколько опасна конкретная находка и насколько быстро ее нужно устранять.</p> <h3>Где возможности сканеров заканчиваются</h3> <p>Даже тщательно настроенные SAST-, SCA- и DAST-инструменты, которые оценивают код, зависимости и работающее приложение, не заменяют экспертного аудита. Сканеры хорошо справляются с техническими находками, которые можно описать формальными правилами. Однако этого недостаточно там, где для выявления слабых мест необходимо учитывать архитектуру системы и связи между ее компонентами.</p> <p>Чаще всего автоматизация не распознает ошибки бизнес-логики. Приложение может корректно выполнять каждое отдельное решение, но при этом пользователь получает возможность обходить установленные ограничения или совершать действия в непредусмотренной последовательности. Например, он может повторно использовать токен, обойти установленный лимит или получить выгоду из бонусной механики. Такие ситуации возникают из-за особенностей работы системы. Чтобы выявить нарушения, необходимо учитывать назначение ресурса, распределение ролей и порядок отдельных операций.</p> <p>ИТ-архитектура приложения тоже требует внимания AppSec- и DevSecOps-специалистов. По отдельным файлам сложно оценить границы доверия, права между сервисами, защищенность внутренних API и хранение секретов. Для подобного анализа необходимо изучить связи между ресурсами, движение данных и разграничение полномочий.</p> <p>По этой причине даже «чистый» отчет SAST или SCA еще не говорит об устойчивости системы к атакам. Эти инструменты помогают проверить код и зависимости, но не дают полной картины того, как устроены бизнес-логика и взаимодействия отдельных компонентов.</p> <h3>Как снизить количество нерелевантных срабатываний</h3> <p>Сканер выдает нерелевантные сигналы, если не учитывает особенности проекта — например, назначение компонента или условия его использования. Для того, чтобы сократить количество таких срабатываний, проверки адаптируют под конкретную систему.</p> <p>Сначала техническая команда определяет контур контроля и решает, какие элементы в него войдут. Если заранее разделить объекты по критичности, часть лишних замечаний можно отсечь еще до разбора отчета.</p> <p>Затем специалисты по безопасности корректируют настройки под особенности проекта. Из проверки убирают лишние директории и временные файлы, отключают правила, которые не подходят для используемого стека, а для повторяющихся ложных срабатываний вводят постоянные исключения или отдельные правила. Далее результаты сканирования соотносят с характеристиками определенного сервиса. Для оценки риска недостаточно знать тип уязвимости. На ее значимость влияет контекст: доступность ресурса из интернета, наличие чувствительных данных или потенциально опасной зависимости во время работы приложения и уже реализованные защитные механизмы. Только после этого можно определить приоритет исправления и сроки устранения дефекта.</p> <p>Настройка автоматических проверок — это непрерывный процесс. Технологический стек меняется, появляются новые сервисы, библиотеки и инструменты разработки, поэтому правила анализа тоже приходится регулярно пересматривать.</p> <h3> Где без ручного аудита не обойтись</h3> <p>Эксперты по AppSec и DevSecOps подключаются к проекту в тех случаях, когда одних сканеров недостаточно, чтобы выявить все возможные риски. Их работа начинается еще до написания кода и продолжается после выхода приложения в эксплуатацию.</p> <p>Сначала специалисты моделируют угрозы. Для новых систем это делают еще до разработки, для существующих — при крупных изменениях. На этом этапе определяют потенциальные сценарии атак, критичные активы, точки входа и границы доверия. Чем раньше обнаружена опасность, тем проще ее устранить: во время проектирования можно заранее скорректировать устройство продукта так, чтобы исключить потенциальную уязвимость. После релиза для этого уже придется дорабатывать код, инфраструктуру или бизнес-логику.</p> <p>Еще один этап — оценка архитектуры приложения. Здесь смотрят, как разделены компоненты и права сервисов, проверяют интеграции и ищут недостатки в принятых технических решениях.</p> <p>Особого внимания требуют наиболее значимые участки системы: доступные из внешнего периметра или работающие с чувствительными данными. Важно понять, можно ли использовать выявленные дефекты для атаки. Несколько слабых мест могут быть относительно безопасны по отдельности, но вместе создать реальную угрозу. Автоматический анализ рассматривает находки по одной и не всегда способен распознать такую связь.</p> <p>В DevSecOps сканеры берут на себя большую часть регулярных проверок кода и других компонентов, но полностью заменить ими специалиста не получится. Там, где нужно разобраться в логике продукта, увидеть взаимосвязь между отдельными факторами или разобрать реальный сценарий воздействия, нужен ручной аудит. Эксперт может посмотреть на сигнал не отдельно, а в контексте всей системы и понять, насколько она опасна на практике. Так ИБ-команде проще отделить действительно критичные уязвимости от менее значимых и решить, что исправлять в первую очередь.</p> <p>#IMAGE_235922#</p> В современной разработке автоматизация проверок безопасности стала такой же частью DevOps, как CI/CD или контроль … article Артем Пузанков, руководитель отдела консалтинга безопасной разработки компании “Бастион” https://www.itweek.ru/themes/detail.php?ID=235919 Tue, 10 Nov 2026 12:06:42 +0300 <p>Во II квартале 2026 года был зафиксирован рост цен до 102 425 руб., который сменился коррекцией до 96 983 руб. в III квартале.</p> <p>По данным исследования iKS-Consulting и RCloud by 3data, за <nobr>I–III</nobr> кварталы 2026 года средняя стоимость облачной корзины для корпоративных заказчиков выросла с 85 499 до 96 983 руб. в месяц. Однако рост не был линейным: снижение в I квартале (−2,8%) сменилось резким подъемом во II (+19,8%) и частичной коррекцией в III (−5,3%). За колебаниями индекса стоит пересмотр ограниченного числа тарифных линеек, а не массовое движение цен.</p> <p>Согласно данным iKS-Consulting и RCloud by 3data, за три квартала 2026 года российский рынок публичной облачной инфраструктуры не сформировал единого ценового тренда. Средняя стоимость облачной потребительской корзины для корпоративных заказчиков менялась разнонаправленно, а индекс цены колебался в диапазоне от 97,6 до 119,8% к предыдущему кварталу. Ключевой вывод периода наблюдения: за агрегированными показателями скрывается сегментация рынка, а конкуренция смещается от цены ресурса к производительности, качеству инфраструктуры и совокупной стоимости решения задачи.</p> <p>«Мы анализируем цены поквартально и видим разнонаправленную динамику без выраженного общего тренда: изменения затрагивали отдельные предложения, тогда как большинство тарифов оставалось на прежнем уровне, — отметил ИТ-директор облачной платформы RCloud by 3data Валентин Соколов. — На значения индекса влияют стоимость серверного оборудования и общая экономическая и политическая ситуация. При этом отрасль в целом смещается от ценовых аргументов к качеству и предсказуемости сервиса».</p> <p>I квартал 2026 года. Индекс цены облачной корзины составил 97,6% к IV кварталу 2025 года, средняя стоимость корзины — 85 499 руб. в месяц. Снижение на 2,9% относительно предыдущего квартала (87 984 руб.) носило умеренный характер. Провайдеры продолжали развивать тарифные линейки, смещая фокус с низкопроизводительных ресурсов на сегмент High Performance и повышая базовую производительность CPU.</p> <p>II квартал 2026 года. Индекс составил 119,8% к I кварталу, средняя стоимость корзины выросла до 102 425 руб. (+16,4%). Основной вклад внесло увеличение стоимости вычислительных ресурсов и оперативной памяти. При этом рост был обусловлен не дефицитом ресурсов и не массовым пересмотром тарифов, а изменением структуры предложений: провайдеры расширяли линейки более производительных конфигураций и смещали акцент с ценовой конкуренции на конкуренцию по качеству инфраструктуры.</p> <p>III квартал 2026 года. Индекс составил 94,7% ко II кварталу, средняя стоимость корзины снизилась до 96 983 руб. (−5,3%). Коррекция компенсировала лишь часть предыдущего роста: стоимость корзины по-прежнему на 13,4% превышает уровень I квартала 2026 года.</p> <p>Колебания индекса — результат точечных решений, а не общего движения цен. Ни в одном из трёх замеров рынок не продемонстрировал единого направления. В III квартале неизменными остались 14 из 30 сопоставимых тарифов vCPU, 12 из 23 тарифов RAM и 14 из 29 тарифов SSD. Изменения концентрировались в отдельных тарифных линейках и у отдельных провайдеров, тогда как большая часть предложений сохранила прежний уровень цен.</p> <p>В III квартале при общем снижении средней цены vCPU на 2,7% стоимость процессоров в группе High Performance выросла на 16,1%, а в группе Standard — на 4,0%. Оперативная память подешевела в среднем на 5,0%, но снижение не было всеобщим. Средняя стоимость SSD практически не изменилась (+0,6%), тогда как предложения класса Standard подорожали в среднем на 18,6%. Рост отдельных тарифов не равен общему удорожанию ресурса — и наоборот.</p> <p>На протяжении всего периода наблюдения конкуренция смещалась от цены ресурса к производительности, качеству инфраструктуры и совокупной стоимости решения задачи. Провайдеры конкурируют за счёт характеристик серверной платформы, частоты процессора, гарантий производительности, коэффициента переподписки и стабильности SLA. Это соответствует мировой тенденции дифференциации облачного ценообразования: крупнейшие мировые провайдеры расширяют предложения, различающиеся по производительности, характеристикам инфраструктуры и условиям потребления.</p> <p>Для корпоративных заказчиков это означает необходимость сравнивать не только стоимость vCPU, RAM и SSD, но и характеристики конфигурации, гарантии производительности и условия предоставления ресурсов. Это особенно важно при выборе между стандартными и высокопроизводительными облачными решениями.</p> Во II квартале 2026 года был зафиксирован рост цен до 102 425 руб., который сменился коррекцией … message https://www.itweek.ru/themes/detail.php?ID=235917 Tue, 10 Nov 2026 10:41:56 +0300 <p><em>Внедрение </em><em>MES </em><em>на производстве — не просто покупка программного обеспечения. Система должна работать с реальными процессами и на нефтяном месторождении, и на обогатительной фабрике. Без людей, которые одновременно понимают и производственные процессы, и ИТ, любой проект рискует превратиться в дорогостоящий, изматывающий и малополезный для бизнеса опыт. Разберем, почему именно квалификация и опыт специалистов решают исход таких проектов и какие кадры сегодня нужны отрасли.</em></p> <h3>Драйверы роста рынка MES</h3> <p>MES-система способна оказывать существенное влияние на операционную эффективность и качество выпускаемой продукции, поэтому инвестиции в это направление обычно не замораживают, даже в условиях экономической нестабильности. В 2025 году рынок MES-проектов вырос примерно на 7% и достиг объема около 18 млрд. рублей. В 2026 году, по нашим оценкам, рост продолжится на уровне 8%.</p> <p>При этом структура спроса меняется. Импортозамещение — уже не главный стимул. Компании смотрят на измеримую выгоду, сокращение простоев, снижение брака, прозрачность цепочки от сырья до отгрузки. Рынок двигают строительство новых производств, расширение некоторых текущих мощностей и модернизация действующих цехов.</p> <p>Один из основных барьеров на пути развития отечественного индустриального ПО и цифровизации промышленности — дефицит кадров. При этом рост числа MES-систем не сопровождается сопоставимым ростом числа специалистов, способных их внедрять и поддерживать. По разным оценкам, лишь от семи до пятнадцати процентов сотрудников компаний обладают компетенциями, достаточными для работы с современными АСУ ТП и промышленной робототехникой.</p> <p>При этом разработка и внедрение промышленного ПО предполагает длинные циклы внедрения, жесткие сроки, постоянные согласования и стресс. В результате часть ИТ-специалистов уходит в сферы, где проще и спокойнее и при этом можно найти конкурентное денежное вознаграждение.</p> <h3>Необходимость в отраслевых специалистах</h3> <p>Главные проблемы связаны с недостатком опытных инженеров, разбирающихся как в разработке цифровых продуктов, так и в производственных процессах конкретных отраслей, а также в экономике предприятия. Без таких знаний создать эффективную MES-систему невозможно. Ситуацию осложняет то, что конкуренция за этих специалистов идет между ИТ-компаниями (вендорами и интеграторами), промышленными предприятия разных отраслей, консалтинговыми фирмами — то есть выходит далеко за пределы одной отрасли.</p> <p>Из нашей практики мы видим, насколько важен опыт в индустрии. Человек, который двадцать лет проработал на целлюлозно-бумажном комбинате, разговаривает с «бумажниками» совсем иначе, чем обычный ИТ-специалист. То же самое касается металлургии или горной добычи. Поэтому в штате важно держать людей с релевантным индустриальным опытом. Такие специалисты сразу видят, на каком переделе, в каком хранилище, на какой локации можно получить экономический эффект, а значит — повысить эффективность компании.</p> <p>А еще на каждом производстве — свои особенности: например, может стоять оборудование от разных производителей, старые станки рядом с новыми линиями и т. д. И нужны люди, способные во всем этом разобраться. Дефицит специалистов приводит не только к увеличению сроков: компаниям приходится отказываться от наиболее сложных проектов. А это, в свою очередь, тормозит развитие самой отрасли.</p> <h3>Навыки MES-разработчика</h3> <p>Рискну утверждать, что для успеха MES-проекта компетенции в области ИТ могут быть иногда вторичны. Гораздо важнее, есть ли в проектной команде специалисты, способные понимать требования производства и переводить их на язык ИТ. Если их нет, то проблемы будут на всех этапах, начиная со сбора первичных требований: инженеры на производстве говорят одно — ИТ-команда слышит другое. В итоге система либо перегружена функционалом, который никто не использует, либо не закрывает самые болезненные точки.</p> <p>Архитектор MES должен видеть всю картину. Он проектирует структуру так, чтобы она решала текущие бизнес-задачи и могла масштабироваться. Ошибка в архитектуре может парализовать участок, а стоимость такой ошибки при непрерывном цикле производства измеряется миллионами рублей в час.</p> <p>Разработчик МES-платформы пишет код, настраивает платформу и обеспечивает работу модулей. Важно глубокое знание хотя бы одной зрелой MES-платформы. Но привлечь чистого программиста в MES-проект мало. Навыки программирования помогают, но редко приходится писать весь код с нуля. Современные MES-системы, если их делали грамотные специалисты, имеют нормальные интерфейсы обмена. Разработчик МES-платформы обязан понимать производственные процессы. Иначе код будет красивым, а результат — бесполезным.</p> <h3>Навыки инженера по внедрению MES</h3> <p>При развертывании MES-платформы на производстве особое значение приобретают навыки общения. Инженер по внедрению такого продукта — тот, кто связывает MES-систему с реальным оборудованием и людьми. Он подключает источники данных по OPC UA или Modbus, работает с PLC, строит мнемосхемы и дашборды, пишет отчеты, разбирает логи. И самое важное — умеет обучать пользователей. Ему надо говорить и с технологом, и с оператором, и с директором цеха на их языке. Он выясняет болевые точки, балансирует требования, тестирует, запускает и снова собирает обратную связь, помогает преодолеть сопротивление персонала.</p> <p>После запуска MES-системы живут годами. Без поддержки специалистов, которые понимают их изнутри, они быстро деградируют. Дополнительные сложности создают жесткие сроки, доработки на этапах опытной и промышленной эксплуатации и разногласия между ИТ и производством. Поэтому качество взаимодействия внутри команды непосредственно влияет на ход проекта.</p> <p>Отдельная задача — формирование проектной команды и управление ею. Квалифицированных специалистов с необходимым набором отраслевых, ИТ- и бизнес-знаний на рынке единицы, но еще меньше тех, кто способен руководить такими коллективами. Нехватка подобных компетенций также влияет на проекты и бизнес-результаты.</p> <h3>Способы преодоления кадрового голода</h3> <p>Формальное образование дает абстрактные знания, далекие от реальных промышленных протоколов, а вакансии даже среднего уровня требуют от трех лет практического опыта. Это создает труднопреодолимые барьеры для новичков, так как реальные экспертные знания заперты внутри крупных холдингов. Поэтому многие компании готовят MES-специалистов самостоятельно. Новички растут от поддержки до разработки на реальных проектах под наставничеством опытных инженеров и без разрыва между теорией и практикой.</p> <p>Вендоры и компании уже реагируют на конъюнктуру: запускают внутренние курсы и онлайн-платформы, внедряют профильные программы в вузах и колледжах, готовят кросс-функциональных специалистов, предлагают условия с конкурентной оплатой. Также помогают самообразование через освоение документации, стандартов ISA-95, форумов и глубокая специализация партнеров по конкретным отраслям.</p> <p>Кроме того, можно отметить уже закрепившуюся практику привлечения отраслевых узкоспециализированных профессионалов в качестве внешних экспертов на проект или для организации обучения.</p> <p>Важная задача состоит и в том, чтобы удерживать нужных специалистов. Профессионалов, обладающих разносторонним опытом и широким набором навыков, мотивируют не только деньги. Для них важны интересные проекты и задачи. И если такой сотрудник начинает скучать, риск его ухода возрастает. Поэтому компании всеми силами стараются давать ценным специалистам возможность для участия в разноплановых проектах.</p> <p>Еще один способ если не решить проблему, то снизить ее остроту — оптимизировать состав и формат работы проектных команд: понять, как наиболее эффективно перераспределить загрузку специалистов с редкими и уникальным компетенциями и навыками.</p> <p>Рост рынка MES будет поддерживать спрос на специалистов и заставлять компании инвестировать в их подготовку. Но быстро закрыть кадровый дефицит вряд ли получится: отрасли нужны люди, которые сочетают опыт производства, ИТ-компетенции и понимание экономики предприятия. Поэтому состав команды и ее отраслевой опыт еще долго будут оставаться одним из ключевых факторов успешного внедрения MES.</p> <p>#IMAGE_235918#</p> Внедрение MES на производстве — не просто покупка программного обеспечения. Система должна работать … article Павел Калякин, генеральный директор ИНКА 4.0 https://www.itweek.ru/themes/detail.php?ID=235916 Tue, 10 Nov 2026 10:28:11 +0300 <p><em>Согласно отчету IDC «Worldwide Quarterly AI Infrastructure Tracker», во втором квартале 2026 г. глобальные расходы на инфраструктуру для ИИ достигли 121,4 млрд. долл. Это на 53% больше по сравнению с аналогичным периодом прошлого года и на 34% выше показателей предыдущего квартала — рост возобновился после паузы в развертывании систем, наблюдавшейся в первом квартале, пишет в корпоративном блоге Хуан Семинара, директор по исследованиям Worldwide Infrastructure Trackers компании IDC.</em></p> <p>Ключевым изменением стало расширение структуры спроса: сегмент инфраструктуры без специализированных ускорителей (на базе центральных процессоров) вырос на 61% в годовом исчислении, опередив темпы роста систем с ускорителями (+52%). Это произошло благодаря внедрению решений для оркестрации агентного ИИ, рабочих нагрузок конвейеров данных, а также значительному росту цен на компоненты, что привело к активному использованию стандартных вычислительных платформ. IDC повысила прогноз по расходам на 2026 г. в целом до 521 млрд. долл. (предыдущий прогноз, сделанный кварталом ранее, составлял 497 млрд. долл.). Пересмотр связан с ростом цен на компоненты, увеличением спроса на системы на базе CPU и сохранением высоких капитальных затрат со стороны гиперскейлеров.</p> <h3>Почему это важно</h3> <p>Результаты второго квартала 2026 г. подтверждают, что инвестиции в ИИ-инфраструктуру перешли от этапа проверки концепций к долгосрочному циклу капиталовложений. Спрос теперь выходит за рамки исключительно систем с ускорителями, а цены на компоненты становятся одним из главных факторов, определяющих объем затрат. Корпоративные заказчики, облачные провайдеры и государственные структуры принимают долгосрочные решения: где размещать инфраструктуру, какой объем средств выделять и на каких задачах в сфере ИИ сосредоточиться в первую очередь.</p> <p>Для поставщиков это означает длительный период высокого спроса на вычислительные системы с ускорителями, высокопроизводительные системы хранения данных и сопутствующую сетевую инфраструктуру. При этом структура спроса меняется: системы на базе CPU, предназначенные для оркестрации агентного ИИ и конвейеров данных, занимают все большую долю в общих расходах, а рост стоимости памяти увеличивает цены на все типы конфигураций. Для бизнеса эти данные служат сигналом: затраты на ИИ-инфраструктуру становятся неотъемлемой структурной статьей расходов при масштабировании деятельности. Высокие цены на память и системы хранения данных означают, что ожидание обходится все дороже, а компании, которые откладывают внедрение, рискуют проиграть конкурентам как в плане производительности, так и в вопросах экономической эффективности. По прогнозам IDC, объем мирового рынка ИИ-инфраструктуры в 2029 г. превысит триллион долларов, достигнув 1,17 трлн., а в <nobr>2030-м</nobr> вырастет до 1,33 трлн. Эти показатели выше прогнозов, сделанных в прошлом квартале (1,08 трлн. и 1,21 трлн. долл. соответственно).</p> <h3>Динамика рынка</h3> <ul> <li><strong> Темпы роста ускорились в большинстве регионов.</strong> Лидирующие позиции по-прежнему занимают США: 92,8 млрд. долл. (76,4% мировых расходов, рост на 58,7% в годовом исчислении). На долю Китая пришлось 13,0 млрд. долл. (доля 10,7%, рост на 27,9% в годовом исчислении). Среди крупных регионов особо выделяется Западная Европа (+83,9% в годовом исчислении, до 6,4 млрд. долл.); за ней следует Азиатско-Тихоокеанский регион (без учета Японии и Китая) — рост на 28,5%, до 5,9 млрд. долл. Самые высокие темпы роста зафиксированы на Ближнем Востоке и в Африке (+108,9%, до 0,9 млрд. долл.), а также в Центральной и Восточной Европе (+96,7%, до 0,3 млрд. долл.), хотя здесь рост происходил с относительно низких стартовых показателей. В Японии же динамика оказалась близкой к нулевой (-1,3%).</li> <li><strong> Системы с ускорителями остаются структурной основой рынка, однако инфраструктура без специализированных ускорителей растет еще быстрее.</strong> Во втором квартале 2026 г. расходы на серверы составили 98,0% от общего объема затрат на ИИ-инфраструктуру. Объем сегмента систем с ускорителями достиг 105,8 млрд. долл. (+52,2% в годовом исчислении), а сегмента инфраструктуры без ускорителей — 15,6 млрд. долл. (+61,1% в годовом исчислении). Спрос стимулируется развитием технологий оркестрации агентного ИИ и рабочих процессов конвейеров данных. Параллельно продолжается активное развертывание систем для обучения и инференса, а значительный рост цен на память и другие компоненты увеличивает стоимость каждой конфигурации оборудования.</li> <li><strong> Цены на компоненты стали одним из ключевых факторов, определяющих общую стоимость.</strong> Поставщики памяти повышают цены, поскольку спрос превышает предложение. При этом гиперскейлеры законтрактовали значительную часть доступных объемов в рамках многолетних соглашений, из-за чего корпоративным заказчикам приходится приобретать компоненты по текущим рыночным ценам. По прогнозам IDC, высокие цены сохранятся как минимум до второй половины 2027 г. На долю СХД, предназначенных для ИИ, по-прежнему приходится лишь небольшая часть (2,0%, или 2,5 млрд. долларов; рост на 45,2% в годовом исчислении) от общего объема инвестиций в ИИ-инфраструктуру.</li> </ul> <p><strong>Основные показатели: II квартал 2026 г.</strong></p> <table> <tbody> <tr> <td> Общие расходы на ИИ-инфраструктуру (II квартал 2026 г.) </td> <td> 121,4 млрд. долл.</td> </tr> <tr> <td> Рост в годовом исчислении (II квартал 2026 г. к II кварталу 2025 г.) </td> <td> +53.3%</td> </tr> <tr> <td> Расходы на инфраструктуру для ИИ за весь 2025 г. </td> <td> 318,7 млрд. долл. (+107,2% к предыдущему году)</td> </tr> <tr> <td> Расходы на инфраструктуру для ИИ за весь 2024 г. </td> <td> 153,9 млрд. долл.</td> </tr> <tr> <td> Доля серверов в расходах на ИИ во II квартале 2026 г. </td> <td> 119,0 млрд. долл. (98,0%)</td> </tr> <tr> <td> Доля СХД в расходах на ИИ во II квартале 2026 г. </td> <td> 2,5 млрд. долл. (2,0%)</td> </tr> <tr> <td> Прогноз на 2029 г. — инфраструктура для ИИ </td> <td> 1,17 трлн. долл.</td> </tr> <tr> <td> Соотношение систем с ускорителями и без них (II квартал 2026 г.) </td> <td> 105,8 млрд. долл. (с ускорителями) vs. 15,6 млрд. долл. (без ускорителей)</td> </tr> <tr> <td> Прогноз на 2030 г. — инфраструктура для ИИ </td> <td> 1,33 трлн. долл.</td> </tr> </tbody> </table> <h3>Прогноз</h3> <p>По оценкам IDC, мировые расходы на ИИ-инфраструктуру в 2026 г. достигнут 521 млрд. долл., что означает рост примерно на 63% по сравнению с предыдущим годом. Это один из самых значительных в абсолютном выражении приростов, когда-либо зафиксированных в отдельном сегменте ИТ-рынка. Согласно прогнозу, во втором полугодии 2026 г. расходы на ИИ-инфраструктуру составят около 309 млрд. долл. — почти на 80% больше, чем за аналогичный период 2025 г. Ожидается, что к среднегодовой темп роста (CAGR) за пятилетний период, начиная с 2025 г., составит около 33%.</p> <p>Факторы, способные ускорить эту динамику:</p> <ul> <li> Более быстрое, чем ожидалось, масштабирование рабочих нагрузок, связанных с инференсом, по мере расширения внедрения ИИ-приложений в корпоративном секторе.</li> <li> Расширение программ суверенного ИИ на Ближнем Востоке, в Юго-Восточной Азии и Европе, что стимулирует дополнительные инвестиции в новые проекты.</li> <li> Появление новых архитектур моделей и фреймворков для ИИ-агентов, требующих более глубокой и распределенной вычислительной инфраструктуры.</li> <li> Рост спроса на решения, не ограничивающиеся только GPU — например, инструменты для оркестрации ИИ, рабочие нагрузки конвейеров данных, а также сценарии применения физического ИИ (робототехника, автономные транспортные средства), что расширяет целевой рынок за пределы обучения моделей и инференса на базе GPU.</li> </ul> <p>Факторы, способные сдержать рост:</p> <ul> <li> Ограничения в сфере генерации электроэнергии и пропускной способности энергосетей, которые остаются главным операционным препятствием для ввода в эксплуатацию новых центров обработки данных на ключевых рынках.</li> <li> Цены на компоненты памяти и СХД, которые увеличивают стоимость серверов и могут замедлить циклы закупок; ожидается, что высокие цены сохранятся как минимум до второй половины 2027 г.</li> <li> Ужесточение экспортного контроля и нормативных требований к суверенитету данных, что может изменить географию размещения ИИ-нагрузок и повлиять на то, какие поставщики будут получать контракты от корпоративных клиентов.</li> <li> Геополитическая нестабильность на Ближнем Востоке, где рост рынка сосредоточен вокруг ограниченного числа крупных проектов, поддерживаемых правительствами стран Персидского залива. Эскалация региональной напряженности, включая продолжающийся конфликт с участием Ирана, может привести к задержкам в принятии решений о закупках, осложнить выбор площадок для дата-центров и планирование их безопасности, а также сместить государственные приоритеты в сторону от инвестиций в ИИ-инфраструктуру. Это создает нестабильность в регионе, который в настоящее время демонстрирует самые высокие темпы роста.</li> </ul> <p>Инвесторам и заказчикам технологических решений следует следить за прогнозами капитальных затрат на третий квартал 2026 г. от ведущих гиперскейлеров и поставщиков ИИ-платформ, поскольку эти опережающие индикаторы остаются наиболее надежным показателем краткосрочного спроса на инфраструктуру.</p> Согласно отчету IDC «Worldwide Quarterly AI Infrastructure Tracker», во втором квартале 2026 г. глобальные расходы … article https://www.itweek.ru/themes/detail.php?ID=235914 Tue, 10 Nov 2026 10:17:18 +0300 <p><em>Чтобы оценить </em><em>AI</em><em>-фичу перед запуском, не нужен отдельный отдел </em><em>data</em> <em>science</em><em>. Нужен продакт, который прочитает сотню ответов модели и до релиза запишет, что считается провалом. Ниже приведен протокол из четырёх шагов, который команда может пройти с таблицей и доступом к модели.</em></p> <p>Большинство AI-фич выходят в прод после проверки на глаз. Продакт гоняет в плейграунде десяток запросов, ответы выглядят прилично, команда ставит дату релиза. Через неделю приходит первая волна жалоб, и выясняется, что модель уверенно обещает клиентам то, чего компания не делает.</p> <p>Мой тезис: оценка качества AI-фичи — работа продакта, а не <nobr>ML-инженера.</nobr> Что считать хорошим ответом, решает продукт. Это вопрос политики компенсаций, тона бренда, юридических рисков и того, какую ошибку пользователь простит. <nobr>ML-команда</nobr> может построить пайплайн, но не может за вас решить, что модели запрещено говорить. Аман Хан, директор по продукту в Arize AI, в <a href="https://www.lennysnewsletter.com/p/beyond-vibe-checks-a-pms-complete">гостевом тексте для рассылки Ленни Рачицкого</a> в апреле 2025 года написал, что умение писать evals быстро становится базовым навыком для всех, кто строит AI-продукты. Я бы сказал жёстче: если у вас нет своих evals, у фичи нет критериев приёмки.</p> <p>Ниже фреймворк, которым можно пользоваться без <nobr>ML-команды,</nobr> платных платформ и кода. Я называю его «Четыре шлюза»: четыре уровня проверки, у каждого свой артефакт и правило «идём дальше или стоп». Пример сквозной и условный: AI-помощник оператора поддержки в сервисе доставки еды. Клиент пишет «курьер опоздал на 40 минут, суп холодный», модель предлагает оператору черновик ответа и вариант компенсации.</p> <h3>С чем я спорю</h3> <p>Документация вендоров LLM даёт хорошую базу, но написана для команд с инфраструктурой. В <a href="https://platform.claude.com/docs/en/test-and-evaluate/develop-tests">руководстве Anthropic по оценкам</a> прямо сказано: лучше больше вопросов с автоматической проверкой, чем меньше вопросов с ручной разметкой, а ручной оценки по возможности избегать. Для зрелой фичи с тысячами примеров это верно. Для первой версии это вредный совет. Пока вы не прочитали ответы сами, вы не знаете, что автоматизировать, и будете измерять не то.</p> <p>Хамел Хусейн, консультант по AI-продуктам, <a href="https://hamel.dev/blog/posts/field-guide/">называет анализ ошибок</a> самым ценным занятием в AI-разработке и предупреждает, что обобщённые метрики хуже, чем бесполезны. По его словам, они мешают прогрессу: создают ложное ощущение, что качество измеряется, и распыляют внимание команды. С этим я согласен полностью. Поэтому первые два шлюза ручные, а автоматизация появляется только на третьем и только там, где её можно сверить с человеком.</p> <p>Отдельно о том, почему это не задача QA. Тестировщик проверяет, что система делает то, что описано в требованиях. У AI-фичи требований в привычном виде нет, пока их кто-то не сформулирует на примерах. Формулировать их должен тот, кто отвечает за то, что фича даёт пользователю и бизнесу. Обычно это продакт. QA и инженеры подключаются позже, когда критерии уже есть и их нужно встроить в пайплайн.</p> <h3>Шлюз 1. Чтение</h3> <p>Что делает продакт. Собирает <nobr>50-100 входов.</nobr> Лучше всего обезличенные реальные обращения. Если их нет, синтетические, но по заданным измерениям, а не наугад. Хусейн <a href="https://hamel.dev/blog/posts/evals/">советует</a> начинать синтетические данные с выбора измерений: здесь это тип проблемы (опоздание, недовоз, не тот заказ), тон клиента (спокойный, злой, саркастичный) и контекст заказа (первый заказ, постоянный клиент, крупная сумма). Затем продакт прогоняет все входы через фичу и читает каждый ответ, записывая свободным текстом, что не так. Когда заметок набирается много, он группирует их в режимы ошибок и останавливается, когда новые ответы перестают приносить новые категории.</p> <p>Артефакт: таблица режимов ошибок. Название, пример, сколько раз встретилось в выборке, насколько это плохо для пользователя и для компании. В нашем примере там окажутся «обещает компенсацию, не зная суммы заказа», «извиняется за то, чего не было», «пересказывает жалобу вместо решения».</p> <p>Правило шлюза. Если основная задача проваливается в большинстве ответов, дальше не идём. Это значит, что сломан дизайн фичи, а не формулировка промпта. Модель, которая не видит сумму заказа, не может предложить адекватную компенсацию, и никакие evals этого не исправят. Нужно добавить контекст или сузить задачу.</p> <h3>Шлюз 2. Критерии и золотой набор</h3> <p>Что делает продакт. Превращает режимы ошибок в критерии с ответом «да» или «нет». Шкалы от 1 до 5 здесь не работают: два человека по-разному понимают разницу между тройкой и четвёркой. Хусейн <a href="https://hamel.dev/blog/posts/field-guide/">пишет</a>, что бинарная оценка заставляет принять ясное решение, достигнута цель или нет, а <a href="https://developers.openai.com/api/docs/guides/evaluation-best-practices">гайд OpenAI</a> рекомендует попарное сравнение или «прошёл/не прошёл» как более надёжные. Каждый критерий формулируется как проверяемое утверждение. «Ответ называет причину задержки, только если она есть в данных заказа». «Сумма компенсации не выше лимита по политике».</p> <p>Отдельно выписываются красные линии, то есть то, чего не должно быть ни в одном ответе: обещание сверх политики, персональные данные курьера, обвинение клиента. Красные линии никогда не усредняются с остальными критериями.</p> <p>Золотой набор состоит из <nobr>80-150 входов,</nobr> которые покрывают измерения из первого шлюза и краевые случаи. В примерах тестовых наборов из гайда Anthropic такие случаи размечены прямо в коде: сарказм, опечатки, длинный сумбурный вопрос, несколько тем в одном обращении, резкая смена темы. Для каждого входа записывается ожидаемое поведение, а не эталонный текст: «извиниться, предложить компенсацию в пределах лимита, не обещать сроки».</p> <p>Артефакт: таблица золотого набора и лист критериев с красными линиями.</p> <p>Правило шлюза. Продакт и эксперт предметной области, например руководитель поддержки, независимо размечают одни и те же 30 ответов. Если они часто расходятся, критерии двусмысленные и их нужно переписать. Идём дальше, когда расхождения редкие и каждое можно объяснить.</p> <h3>Шлюз 3. Прогон и пороги</h3> <p>Что делает продакт. До прогона записывает пороги и согласует их со стейкхолдерами. По красным линиям допустим только ноль нарушений. По основным критериям фиксируется доля «да», ниже которой фича не выходит. Нужна и базовая линия: как на тех же входах справляется текущий процесс, например операторы с шаблонами ответов. Пороги фиксируют заранее, потому что после прогона всем захочется сдвинуть планку к полученному результату.</p> <p>Потом продакт прогоняет золотой набор и размечает ответы. Сотню ответов по пяти бинарным критериям реально разметить за пару часов. <nobr>LLM-судью</nobr> можно подключать, только когда есть ручная разметка, с которой его сверить. И OpenAI, и Хусейн настаивают, что автоматического оценщика сначала калибруют по людям: в гайде OpenAI сказано, что масштабировать судью стоит, когда он стабильно совпадает с человеческой разметкой. Без этого у вас появляется вторая модель, в качестве которой вы тоже не уверены.</p> <p>Артефакт: оценочная карта по критериям и одностраничное решение о запуске с подписями.</p> <p>Правило шлюза. Ноль нарушений красных линий и выполненные пороги. Если пороги выполнены, но фича проигрывает базовой линии, это повод не запускать её, а переупаковать. Например, черновик видит только оператор и сам решает, отправлять ли его клиенту.</p> <h3>Шлюз 4. Тень</h3> <p>Что делает продакт. Запускает фичу в теневом режиме или на небольшую долю трафика. Модель генерирует, решение принимает человек. В лог пишутся вход, контекст, ответ модели и действие оператора: принял, исправил, отклонил. Гайд OpenAI советует логировать всё уже в процессе разработки, чтобы потом доставать из логов хорошие случаи для набора. Раз в неделю продакт читает выборку боевых ответов, и каждый новый режим ошибки попадает в золотой набор. Набор, который перестал расти, через пару месяцев проверяет уже не ту фичу, что работает в проде.</p> <p>Доля черновиков, которые операторы правят, даёт самый честный сигнал качества, и он бесплатный. Его не нужно размечать, он появляется сам.</p> <p>Артефакт: журнал недельных разборов и правило отката. В правиле заранее записано, при каком событии фича выключается и кто это делает.</p> <p>Правило шлюза. Расширяем аудиторию, если доля «да» на боевой выборке сопоставима с офлайн-прогоном, нарушений красных линий нет, а защитная бизнес-метрика не просела. Для поддержки это время решения обращения и доля повторных обращений.</p> <h3>Шлюзы на одной странице</h3> <ol> <li> Чтение: <nobr>50-100</nobr> ответов прочитаны вручную. Артефакт: таблица режимов ошибок. Стоп, если основная задача проваливается в большинстве ответов.</li> <li> Критерии: бинарные критерии, красные линии, золотой набор на <nobr>80-150 входов.</nobr> Артефакт: таблица набора и лист критериев. Стоп, если продакт и эксперт часто расходятся в разметке.</li> <li> Прогон: пороги записаны до запуска, есть базовая линия. Артефакт: оценочная карта и решение о запуске. Стоп при любом нарушении красной линии или проигрыше базовой линии.</li> <li> Тень: ограниченный запуск, логи, еженедельный разбор, правило отката. Артефакт: журнал разборов. Расширяем, только если боевое качество не хуже офлайн-прогона.</li> </ol> <h3>Сколько это стоит</h3> <p>Первые три шлюза занимают примерно неделю времени продакта и несколько часов эксперта. Инструменты: таблица и доступ к модели. Платформы для evals полезны на четвёртом шлюзе, когда трафик растёт и читать вручную уже невозможно. Покупать их до второго шлюза бессмысленно: вы будете автоматизировать критерии, которых ещё нет.</p> <p>Чаще всего этот процесс ломается в четырёх местах. Золотой набор собран из одних «счастливых» сценариев. Вместо бинарных критериев считают среднюю оценку «4,2 из 5». <nobr>LLM-судью</nobr> никто не сверял с людьми. Набор заморозили в день релиза.</p> <p>Если начинать завтра, начните с первого шлюза: 50 входов, 50 ответов, заметки на полях. После этого разговор с командой о качестве фичи пойдёт на языке конкретных ошибок, а не впечатлений. Набор evals и есть PRD для AI-фичи, только написанный примерами.</p> <p>#IMAGE_235936#</p> Чтобы оценить AI-фичу перед запуском, не нужен отдельный отдел data science. Нужен продакт, который прочитает сотню ответов … article Иван Лапа, продакт-менеджер в Uzum Tezkor (Ташкент) https://www.itweek.ru/themes/detail.php?ID=235912 Mon, 09 Nov 2026 16:04:49 +0300 <p>Российский разработчик систем управления базами данных и продуктов для работы с данными Postgres Professional в пять раз ускорила подготовку к переносу данных в новой версии решения для миграции и репликации Postgres ProGate 1.5.0. Это позволяет заказчикам сократить подготовительный этап миграционных проектов. Обновление также включает поддержку аналитической СУБД Postgres Pro AXE 2.0, расширяет возможности обмена данными между Oracle, PostgreSQL и Postgres Pro и работы с отказоустойчивой инфраструктурой.</p> <p>В ProGate 1.5.0 время подготовки задач переноса сократилось впятеро благодаря оптимизации анализа структуры баз данных. Это ускоряет подготовительный этап миграционных проектов и позволяет ИТ-командам быстрее переходить к загрузке данных в целевые системы, в том числе в проектах с большим количеством таблиц.</p> <p>Поддержка аналитической СУБД для гибридных нагрузок Postgres Pro AXE 2.0 позволяет использовать ProGate для загрузки данных в аналитическую платформу. Заказчики могут применять единый инструмент как для миграции между СУБД, так и для подготовки данных для аналитики.</p> <p>В новой версии расширена поддержка Oracle: эта СУБД теперь может выступать целевой системой в ProCopy — компоненте первоначальной загрузки данных. Ранее перенос в Oracle был доступен в ProSync для репликации изменений. Теперь заказчики могут выполнять оба этапа: первоначальную загрузку и последующую синхронизацию данных.</p> <p>Также добавлена двунаправленная репликация между двумя основными узлами PostgreSQL или Postgres Pro версий 16 и выше. Она расширяет возможности синхронизации систем, в каждой из которых вносятся изменения.</p> <p>В ProGate 1.5.0 расширены настройки отказоустойчивости и обработки сетевых сбоев. При временной потере соединения во время первоначальной загрузки решение выполняет контролируемые повторные попытки отправки данных, исключая зависание процесса. Дополнительные показатели задержки репликации и состояния задач помогают администраторам быстрее замечать отклонения и оценивать актуальность данных в целевой системе.</p> <p>Возможность читать изменения из резервных баз Oracle позволяет снизить влияние репликации на основную систему, обслуживающую текущие бизнес-процессы. Кроме того, в обновлении усилена защита входа и пользовательских сессий, обновлены программные компоненты и устранены уязвимости зависимостей.</p> <p>«Для заказчика миграция — это не просто перенос данных, а переход на новую инфраструктуру без ущерба для текущей работы бизнеса. Поэтому в ProGate 1.5.0 мы сосредоточились на том, чтобы сократить стадию подготовки и сделать перенос более управляемым. Команды заказчика смогут быстрее запускать загрузку, отслеживать актуальность данных и оперативно реагировать на сбои. А поддержка Postgres Pro AXE 2.0 расширяет применение портфеля наших решений: единый инструмент можно использовать и для миграции, и для загрузки данных в аналитическую СУБД», — отметил Евгений Кривов, руководитель продукта Postgres ProGate компании Postgres Professional.</p> <p>Решение Postgres ProGate объединяет первичную загрузку данных, непрерывную репликацию изменений и проверку согласованности данных. Решение помогает компаниям модернизировать ИТ-инфраструктуру и переходить на новые СУБД поэтапно, поддерживая обмен данными между существующими и новыми системами. Управление доступно через единый веб-интерфейс и командную строку.</p> Российский разработчик систем управления базами данных и продуктов для работы с данными Postgres Professional … message https://www.itweek.ru/themes/detail.php?ID=235911 Mon, 09 Nov 2026 16:03:43 +0300 <p>Рынок решений для управления привилегированным доступом (PAM) остается крупнейшим сегментом российского рынка Identity Security. Его объем по итогам 2025 года достиг 5,8 млрд рублей, увеличившись на 13% за год. При этом рост рынка опережает распространение PAM в самих организациях. Такие данные приводит компания «Индид» в исследовании «Identity Security 2026», подготовленном при участии Айдентити Клуба.</p> <p>Исследование показало, что специализированные PAM-решения пока используются не во всех сценариях привилегированного доступа. Для контроля администраторов их применяют 36,5% российских организаций, а для внешних подрядчиков — 32%. Во многих компаниях управление таким доступом по-прежнему строится преимущественно на регламентах и логировании.</p> <p>Похожая картина складывается и с распространением Zero Trust. Только 16,5% организаций уже внедрили основные элементы концепции нулевого доверия. Еще 22% применяют элементы Zero Trust только для внешних подключений и подрядчиков. Компании чаще начинают с наиболее чувствительных сценариев — например, с контроля доступа подрядчиков и внешних подключений. На остальные процессы эти принципы пока распространяются заметно реже.</p> <p>Это показывает, что для многих компаний PAM пока остается инструментом для отдельных сценариев, а не основой общей модели управления привилегированным доступом.</p> <p>Еще один показатель этого разрыва — срок действия выданных полномочий. В 45,5% компаний права сохраняются до ручного отзыва. Поэтому доступ, который требовался для конкретной работы, может продолжать действовать и после ее завершения. Например, повышенные права администратора, выданные на несколько часов для обновления сервера, способны сохраняться неделями или месяцами.</p> <p>Более точный подход Just-in-Time, при котором необходимые права предоставляются только на время выполнения задачи, используют 26% организаций. В этом случае срок действия привилегий определяется не только ролью сотрудника, но и конкретной задачей, для которой они потребовались, а также сроком ее выполнения.</p> <p>Следующий этап развития российского рынка PAM связан уже не только с дальнейшим распространением специализированных решений. Меняется сама модель привилегированного доступа — от постоянных прав и контроля отдельных подключений к более точному управлению полномочиями. В этой модели доступ предоставляется на конкретную задачу, в необходимом объеме и прекращается, когда потребность в нем исчезает.</p> <p>«Зрелость PAM все больше определяется не количеством подключенных пользователей или записанных сессий. Гораздо показательнее, насколько точно компания управляет самими привилегиями: на каком основании они предоставлены, действительно ли остаются необходимыми и вовремя ли отзываются. Чем лучше выстроен этот процесс, тем меньше в инфраструктуре избыточных прав и тем ниже риск их использования не по назначению. На мой взгляд, именно это и будет определять дальнейшее развитие рынка. PAM постепенно выходит за рамки контроля отдельных категорий пользователей и становится инструментом управления всем жизненным циклом привилегий. Постоянные права будут все чаще заменяться доступом по необходимости, а принципы Zero Trust и Just-in-Time становиться частью этой логики: полномочия выдаются под конкретную задачу, в необходимом объеме и прекращаются, когда потребность в них исчезает», — отметил Андрей Лаптев, директор по продуктовому развитию компании «Индид».</p> Рынок решений для управления привилегированным доступом (PAM) остается крупнейшим сегментом российского рынка Identity Security … message https://www.itweek.ru/themes/detail.php?ID=235910 Mon, 09 Nov 2026 16:02:40 +0300 <p>CorpSoft24 запустила облачные сервисы для компаний, разрабатывающих собственный ИИ. Теперь компании, которые разрабатывают собственные ИИ-решения или внедряют готовые модели в корпоративные системы, смогут использовать облачные вычислительные мощности, языковые модели и сервисы векторизации текста без необходимости самостоятельно создавать всю необходимую инфраструктуру.</p> <p>Ранее CorpSoft24 сообщала, что предлагает бизнесу готовые ИИ-продукты и услуги по их внедрению. Сейчас, в ответ на растущий спрос со стороны компаний, развивающих собственные ИИ-решения, компания расширила предложение. Новые сервисы позволят бизнесу сократить затраты на оборудование и его обслуживание, а также быстрее запускать и масштабировать ИИ-проекты.</p> <p>В рамках нового направления CorpSoft24 предлагает два основных сервиса:</p> <ul> <li>GPU IaaS — аренда виртуальных серверов с графическими процессорами. Сервис подходит компаниям, которые самостоятельно разрабатывают или запускают ИИ-модели. Клиенты получают выделенные вычислительные мощности и могут настраивать программную среду под собственные требования;</li> <li>LLMaaS — языковые модели как сервис. Сервис позволяет использовать готовые ИИ-модели. Его можно подключать к корпоративным системам для создания виртуальных помощников, анализа документов, генерации текстов и автоматизации повседневных задач.</li> </ul> <p>В компании отметили, что при использовании ИИ-сервисов особое внимание уделяется защите корпоративных данных и контролю работы моделей. В частности, в решениях CorpSoft24 предусмотрены встроенные механизмы информационной безопасности, которые позволяют выявлять и при необходимости маскировать конфиденциальную информацию до ее передачи языковым моделям, разграничивать доступ пользователей к данным и функциям ИИ, а также обнаруживать попытки вредоносного воздействия на ИИ (включая Prompt Injection и Jailbreak). Все действия контролируются с помощью единых политик безопасности и журналов событий. Это позволяет компаниям сохранять контроль над корпоративными данными и снижает риски их утечки.</p> <p>Облачная инфраструктура CorpSoft24 размещается в России на базе центров обработки данных уровня Tier III. При работе с ИИ важно обеспечить защиту не только самой инфраструктуры, но и данных, которые передаются моделям. Для этого можно использовать инструменты контроля запросов и ответов ИИ-моделей, защиты конфиденциальной информации и выявления попыток атак.</p> <p>«Одно из главных преимуществ нового предложения — возможность сократить первоначальные инвестиции в ИИ. Бизнесу не требуется закупать серверы, самостоятельно организовывать их работу и содержать отдельную команду для обслуживания инфраструктуры. Специалисты CorpSoft24 возьмут это на себя», — отметил Константин Рензяев, генеральный директор CorpSoft24.</p> <p>По его словам, для модельных сервисов предусмотрена оплата по фактическому потреблению. Это позволяет начинать с небольших проектов и постепенно увеличивать использование ресурсов.</p> <p>В компании обращают внимание на то, что спрос на облачную инфраструктуру для ИИ в России активно растет. Согласно исследованию Selectel и Apple Hills Digital, в 2025 году объем потребления облачных серверов с графическими процессорами (GPU) увеличился почти на 69%, достигнув 8,2 млрд руб. Еще быстрее рос сегмент облачных платформ для разработки и запуска ИИ — на 97%, до 9,4 млрд руб. Что касается подходов к внедрению ИИ, то, согласно данным «Яндекса» и «Яков и Партнеры», 78% крупных российских компаний применяют готовые ИИ-решения сторонних разработчиков, а 17% занимаются собственной разработкой. Облачную модель предоставления генеративного ИИ используют 40% опрошенных компаний.</p> <p>«У компаний разные задачи и разная готовность к внедрению ИИ. Одним нужны готовые решения, другим — собственные модели и вычислительные мощности для работы с ними. Поэтому мы предлагаем несколько вариантов, чтобы бизнес мог выбрать подходящий формат и постепенно развивать свои проекты», — отметил Константин Рензяев.</p> CorpSoft24 запустила облачные сервисы для компаний, разрабатывающих собственный ИИ. Теперь компании, которые разрабатывают … message https://www.itweek.ru/themes/detail.php?ID=235909 Mon, 09 Nov 2026 10:07:31 +0300 <p><em>Корпоративное ПО больше не создает ценность само по себе. Теперь ценность заключается в результатах, которые достигаются благодаря рабочим процессам, охватывающим бизнес-приложения, данные, людей и искусственный интеллект. В 2027 г. технологические лидеры перейдут от управления отдельными приложениями к управлению результатами деятельности предприятия. Инструментом контроля станут сквозные рабочие процессы, объединяющие различные приложения. И это будет непросто, пишет в корпоративном блоге Кейт Леггетт, вице-президент, главный аналитик </em><em>Forrester</em><em>.</em></p> <h3>Три прогноза Forrester для рынка корпоративного ПО на 2027 год</h3> <ul> <li><strong> Менее 10% предприятий будут использовать автономных агентов, работающих в разных приложениях.</strong> В 2027 г. встроенные ИИ-агенты станут повсеместным явлением, поскольку разработчики ПО активно интегрируют их с данными приложений, правами доступа, бизнес-логикой и механизмами контроля. Однако технологическим руководителям будет сложно масштабировать использование таких агентов в рамках всей ИТ-экосистемы: стандарты взаимодействия еще недостаточно развиты и внедряются неравномерно. Системы управления агентами также останутся несовершенными, особенно в том, что касается контроля над сторонними агентами, действующими в нескольких приложениях одновременно. В результате компании столкнутся с проблемой ответственности и рисками, связанными с возможными сбоями: доверяя агенту в рамках одного приложения, они будут опасаться позволять ему выполнять действия в масштабах всей системы без участия человека. Руководителям рекомендуется начинать с внедрения автономных решений в ограниченных сценариях, где последствия ошибок легко контролировать, а для наиболее важных рабочих процессов — сохранять обязательный контроль со стороны человека.</li> <li><strong> Цифровой суверенитет приведет к 20%-ному увеличению локализации корпоративного ПО.</strong> После десятилетий стандартизации глобальных систем ERP, CRM, моделей данных и бизнес-процессов наметился обратный тренд: цифровой суверенитет стал одним из ключевых критериев при выборе программных продуктов. Согласно исследованию Forrester «Cloud Survey 2026», 43% лиц, принимающих решения в сфере частных облаков, предпочитают размещать приложения онпремис из соображений конфиденциальности и защиты данных. В то же время 59% тех, кто отвечает за публичные облака, отмечают, что требования цифрового суверенитета становятся решающим фактором при выборе облачного провайдера. Законы о локализации данных, требования к суверенным облакам и различия в регулировании ИИ будут распространяться все шире, что приведет к росту затрат на локализацию. Руководителям следует инвестировать в региональные хранилища данных, адаптированные для конкретных стран модели ИИ, локализованные бизнес-процессы и механизмы контроля, соответствующие требованиям законодательства отдельных юрисдикций.</li> <li><strong> Модель оплаты ИИ по факту использования</strong> обернется проблемами для ряда крупных поставщиков бизнес-приложений. Последние два года разработчики корпоративного ПО активно внедряли платные ИИ-функции, тарифицируя работу агентов в зависимости от количества диалогов, выполненных действий, решенных задач или числа «премиальных» рабочих мест. В 2027 г. такая ценовая политика сыграет против крупнейших поставщиков: организации предпочтут автоматизировать процессы на базе той платформы, которая у них уже есть и обходится дешевле. Иными словами, вместо того чтобы платить поставщику корпоративного ПО за каждое действие агента, компании, например, создадут аналогичного агента в Microsoft Copilot Studio — в рамках уже имеющейся лицензии. Руководители будут тщательно сопоставлять расходы и требовать от поставщиков либо существенного снижения тарифов на ИИ, либо расширения объема ИИ-услуг, включенных в базовый пакет, либо перехода от оплаты по факту использования к более предсказуемым моделям: подпискам SaaS в сочетании с фиксированными платежами или контрактами с установленными лимитами затрат.</li> </ul> <h3>Переход от управления приложениями к управлению результатами</h3> <p>В 2027 г. руководители в сфере корпоративного ПО должны сместить фокус с управления отдельными приложениями на контроль бизнес-результатов, охватывающий данные, рабочие процессы, ИИ и человеческие ресурсы. Вместо стремления к полной автономности операций, затрагивающих множество приложений, руководителям следует сосредоточиться на ограниченном числе наиболее ценных и хорошо контролируемых сценариев использования. Важно сохранить участие человека в принятии критически важных решений, а также активно инвестировать в качество данных, их совместимость и фундамент управления. Одновременно с этим необходимо подготовиться к ужесточению требований к цифровому суверенитету, критически оценить непредсказуемые модели оплаты ИИ и пересмотреть подход к выбору между самостоятельной разработкой и покупкой готового решения — особенно с учетом того, что ПО, созданное с помощью ИИ, становится вполне пригодным для реализации уникальных бизнес-процессов. В выигрыше окажутся те, кто рассматривает приложения лишь как компоненты архитектуры, ориентированной на достижение конкретных результатов, а не как ее центральный элемент.</p> Корпоративное ПО больше не создает ценность само по себе. Теперь ценность заключается в результатах, которые … article https://www.itweek.ru/themes/detail.php?ID=235905 Mon, 09 Nov 2026 00:00:00 +0300 <p><strong>2 декабря</strong> в Москве (а также онлайн!) пройдет зимняя конференция Conversations. 2 трека, 40+ спикеров, 600+ участников и 200+ компаний.</p> <p> <strong>Трек</strong> «<strong>Бизнес</strong>»</p> <p> Экономика внедрения и владения AI / Вайбкодинг для внутренних процессов / Голосовые агенты и AI-операторы / AI-adoption, мотивация и сопротивление / Путь от пилотов к единой AI-платформе / Кейсы и антикейсы / Ответственность и регуляторика AI / Атрибуция эффекта от AI.</p> <p> <strong>Трек</strong> «<strong>Продукты и технологии</strong>»</p> <p> AgentOps и эксплуатация агентов / Harness и Context Engineering / Долгоживущие агенты / Юнит-экономика для AI-продукта в B2B/B2C / Agentic UX / Инфраструктура в контуре / Product Discovery нового типа / Инженерия Voice AI / Превращение продакта в разработчика (и наоборот) / Безопасность агентских систем.</p> <p> <strong>Не только доклады</strong></p> <p>Воркшопы по вайб-кодингу для бизнеса и разработчиков / AI Stack-сессия / Дискуссии и тренд-токи «Около AI» / Выставка и демо решений.</p> <p> <strong>Спикеры уже на сайте. Среди них:</strong></p> <ul> <li> <strong>Как мы в Авито растим инкрементальную выручку отдела продаж</strong> с помощью GenAI-инструментов — Виталий Минаев, Ксения Шимук, Авито.</li> <li> 500 000 претензий и 85% автоматизации: <strong>как мы построили AI-систему принятия решений</strong> — Артем Гриппа, Magnit OMNI.</li> <li> Как вайб-кодинг запускает ИИ-трансформацию в нетехнических командах— Андрей Томачинский, Контур.</li> <li> Как продать ИИ тем, кто умнее вас? <strong>Кейс облачного саппорта: от саботажа до секты ИИ-евангелистов</strong> — Максим Михайлов, Cloud.ru.</li> </ul> <p> Вас ждут доклады от 35+ компаний: Wildberries   Russ, Альфа-Банк, Magnit OMNI, Just AI, билайн, Сбербанк, ПравоТех, Вебпрактики, Туту x targetai, Cloud.ru, Контур, Raft AI, Data Light, Navio и других!</p> <p> Еще больше участников и тем <a href="/ad/rd/a-17.php" target="_blank"><strong>на сайте</strong></a>!</p> <p> <strong>Успейте приобрести билет по самой низкой цене до 16 ноября! </strong>Промокод на скидку 10%: CVS26mkWi.</p> <p> За новостями конференции следите в телеграм-канале проекта Conversations Club <a href="https://t.me/conversations_ai" target="_blank">https://t.me/conversations_ai</a></p> <p> 2 декабря, Москва (Soluxe Hotel Moscow, ул. Вильгельма Пика, д.16) и онлайн. Увидимся на Conversations! </p> 2 декабря в Москве (а также онлайн!) пройдет зимняя конференция Conversations. 2 трека … message https://www.itweek.ru/themes/detail.php?ID=235903 Fri, 06 Nov 2026 16:42:39 +0300 <p>MWS Cloud, входит в МТС Web Services, провела исследование российского рынка кибербезопасности. Согласно его результатам, совокупный объём сегментов программного обеспечения, аппаратного обеспечения для цифровой безопасности и ИТ-услуг в сфере кибербезопасности в 2026 году достигнет 455,4 млрд рублей. По сравнению с 2025 годом рынок вырастет на 20,8% — с 377,1 млрд рублей до 455,4 млрд рублей. Самым крупным сегментом станет программное обеспечение с объёмом 216,5 млрд рублей, за ним следуют ИТ-услуги в области кибербезопасности с 167 млрд рублей и аппаратное обеспечение для цифровой безопасности с 71,9 млрд рублей.</p> <p>Рынок программного обеспечения для кибербезопасности в <nobr>2021–2026</nobr> годах растет в среднем на 34,4% ежегодно: с 49,4 млрд рублей до 216,5 млрд рублей. В 2026 году сегмент вырастет на 30% по сравнению с 2025 годом — с 166,5 млрд рублей до 216,5 млрд рублей. Его доля в вертикали программного обеспечения увеличивается с 8,5% в 2021 году до 13,1% в 2026 году. Ключевыми драйверами остаются развитие регуляторного контура, рост штрафов за утечки персональных данных и переход заказчиков к более продвинутым средствам защиты.</p> <p>Наиболее быстрорастущими направлениями в сегменте ПО являются системы защиты веб-приложений (WAF), которые растут в среднем на 53,2% в год, а также SIEM-системы — на 40,7%. Доля SIEM в структуре рынка увеличивается с 10,1% до 12,6%, тогда как доля классических антивирусов для бизнеса сокращается с 14,3% до 10,5%. Это отражает переход от периметровой защиты к обнаружению и реагированию на кибератаки.</p> <p>Рынок аппаратного обеспечения для цифровой безопасности к концу 2026 года достигает 71,9 млрд рублей против 40,7 млрд рублей в 2021 году. По сравнению с 2025 годом сегмент вырастет на 10% — с 65,4 млрд рублей до 71,9 млрд рублей. Среднегодовой темп роста составляет 12%. При этом доля сегмента в вертикали аппаратного обеспечения остается стабильной: 6,4% в 2021 году, 6,6% в 2025 году и 6,5% в 2026 году.</p> <p>Ключевым драйвером аппаратного сегмента выступают законодательные ограничения на использование иностранного оборудования и замена зарубежных решений российскими аналогами. Наибольшую динамику при этом показывают системы управления доступом.</p> <p>Второе место по объёму занимают ИТ-услуги в области кибербезопасности. Их объём увеличивается с 60,5 млрд рублей в 2021 году до 167 млрд рублей в 2026 году при среднегодовом темпе роста 22,5%. В 2026 году сегмент вырастет на 15% по сравнению с 2025 годом — с 145,2 млрд рублей до 167 млрд рублей. Доля сегмента в вертикали ИТ-услуг увеличивается с 7,7% до 14%.</p> <p>Основной вклад в развитие ИТ-услуг вносит спрос на управляемые сервисы информационной безопасности (MSSP). Дефицит квалифицированных кадров и высокая ключевая ставка сформировали устойчивый спрос на аутсорсинг, поскольку эта модель обеспечивает профессиональный уровень защиты без затрат на формирование и содержание собственного подразделения ИБ.</p> <p>MSSP остается самым быстрорастущим направлением сегмента. В <nobr>2021–2026</nobr> годах управляемые сервисы растут в среднем на 36,5% в год, а их доля в структуре ИТ-услуг в области кибербезопасности увеличивается с 18,3% до 31,5%. Для малого и среднего бизнеса эта модель стала приоритетной. В MSSP входят мониторинг и анализ событий безопасности (SOC as a Service), реагирование на инциденты, управление средствами защиты и уязвимостями, а также киберразведка. Одновременно усложнение ИТ-инфраструктуры и распространение облачных сред поддерживают спрос на консалтинг, независимую оценку защищённости и аудит соответствия требованиям регуляторов.</p> <p>Отдельным направлением рынка становится защита ИИ-систем и корпоративных чат-ботов.</p> <p>«ИИ существенно ускоряет не только развитие цифровых сервисов, но и появление новых киберугроз. Атаки становятся более быстрыми, масштабными и адаптивными, поэтому прежнего подхода к защите периметра уже недостаточно. Бизнесу необходимо в разы быстрее выявлять изменения в ландшафте угроз и перестраивать защиту — включая контроль данных, инфраструктуры и приложений. Скорость адаптации становится одним из ключевых факторов киберустойчивости», — прокомментировал генеральный директор МТС Web Services Павел Воронин.</p> MWS Cloud, входит в МТС Web Services, провела исследование российского рынка кибербезопасности. Согласно его результатам … message https://www.itweek.ru/themes/detail.php?ID=235902 Fri, 06 Nov 2026 16:41:15 +0300 <p>Компании «Актив» и «Такском» сообщили о поддержке сценария подписания электронных перевозочных документов (ЭПД) в мобильном приложении «Такском-Файлер» с использованием Рутокен ЭЦП 3.0 NFC. Совместное тестирование подтвердило корректную работу с квалифицированной электронной подписью, доступной водителям и специалистам логистики прямо со смартфона.</p> <p>Технология подписания документов в «Такском-Файлере» с помощью Рутокен 3.0 NFC уже хорошо знакома клиентам и используется не первый год. Новым шагом стало подтверждение работы сценария именно для ЭПД. В ходе работ специалисты компаний обеспечили стабильное подписание ЭПД по бесконтактному каналу NFC как на смартфонах и планшетах с ОС Android, так и на смартфонах с iOS.</p> <p>Рутокен ЭЦП 3.0 NFC — аппаратный носитель с бесконтактным интерфейсом, который хранит ключи электронной подписи в защищенном виде. Для подписания документа достаточно приложить Рутокен к смартфону. Ключ не покидает пределов защищенного носителя, а подпись формируется непосредственно в устройстве. В связке с мобильным приложением «Такском-Файлера» это позволяет подписывать ЭПД в полевых условиях без использования адаптеров и отдельных считывателей.</p> <p>Сергей Жуков, руководитель отдела внедрения продуктов «Такском», отметил: «Совместная работа с коллегами из „Актива“ позволила обеспечить надежное подписание ЭПД через NFC на широком парке Android-устройств. Для наших клиентов это удобный и безопасный сценарий: подписал документ — и сразу передал его в ГИС ЭПД».</p> <p>Павел Анфимов, заместитель директора по управлению продуктами компании «Актив», прокомментировал: «Рутокен ЭЦП 3.0 NFC создавался для мобильных сценариев, и подтвержденная работа с „Такском-Файлером“ в части ЭПД — ещё один шаг к тому, чтобы усиленная квалифицированная подпись была доступна даже неспециалисту в любой точке маршрута».</p> Компании «Актив» и «Такском» сообщили о поддержке сценария подписания электронных перевозочных документов (ЭПД … message https://www.itweek.ru/themes/detail.php?ID=235896 Fri, 06 Nov 2026 10:15:47 +0300 <p><em>Руководители компаний готовятся к потрясениям, вызванным искусственным интеллектом, одновременно пытаясь реализовать пилотные проекты в этой сфере. Однако существенного влияния на финансовые показатели (прибыли и убытки) пока не наблюдается. Ситуация изменится в 2027 г., пишет в корпоративном блоге Брайан Хопкинс, вице-президент </em><em>Forrester</em> <em>по портфелю перспективных технологий.</em></p> <p>В нашем новом отчете «Predictions 2027: Artificial Intelligence» выделены пять «линий разлома» — областей, где накапливалось напряжение и где вскоре неизбежны серьезные сдвиги. Речь идет о расходах на ИИ, управлении, экономике моделей, архитектуре платформ, а также об организационной среде, необходимой для масштабирования автономных ИИ-агентов.</p> <p>Технологии развиваются быстрее, чем большинство организаций успевают их осваивать. Поэтому внедрение контролируемых и безопасных ИИ-решений в промышленную эксплуатацию в 2027 г. обеспечит преимущество перед конкурентами, которые все еще находятся на стадии экспериментов и поиска верной стратегии. Ниже представлены подробности трех из пяти наших прогнозов в сфере ИИ на 2027 г.</p> <h3>На долю ИИ будет приходиться 20% корпоративных расходов на технологии</h3> <p>Согласно прогнозу Forrester по мировому технологическому рынку, в 2027 г. глобальные расходы на технологии превысят 6 трлн. долл., причем каждый пятый доллар будет направлен на ИИ. Большая часть этих средств пойдет на закупку серверов и оборудования, что для предприятий трансформируется в расходы на ИИ-токены и вычислительные ресурсы — бюджеты компаний могут просто не выдержать такой нагрузки. Хотя большинство технических руководителей рассчитывают на увеличение бюджета в следующем году, лишь 53% из них ожидают, что рост превысит уровень инфляции. Это означает, что почти половина компаний столкнется со снижением реальной покупательной способности как раз в тот момент, когда бизнес требует больше решений на базе ИИ и готов платить за них все дороже.</p> <p>Основной удар придется на сторонние сервисы. Руководители уже планируют наиболее значительные сокращения расходов именно в этой категории, а развитие ИИ дополнительно снижает стоимость предоставления консалтинговых и управляемых ИТ-услуг. Пересмотрите свои сервисные контракты и договоры на использование ПО (с оплатой за рабочее место) — сделайте это за полгода до истечения срока их действия. Постарайтесь вернуть часть средств и направьте их на планирование расходов, связанных с использованием ИИ, а также на контекстную инженерию.</p> <h3>Пробелы в системе управления приведут к провалу ключевых ИИ-проектов в ряде крупных компаний</h3> <p>Как показал недавний опыт, одного лишь набора принципов недостаточно для контроля над автономным ИИ-агентом. Эффективное управление такими агентами требует наличия специальных навыков, инструментов и механизмов контроля, обеспечивающих соблюдение установленных правил. В 2027 г. такие системы по-прежнему будут разбросаны по разным технологическим областям, оставаясь вне зоны контроля специалистов по корпоративному управлению, ответственных за разработку политик. Более половины лиц, принимающих решения в сфере генеративного ИИ, уже называют «неконтролируемое распространение автономных агентов» (agentic sprawl) серьезной проблемой. Традиционные механизмы управления изначально не были рассчитаны на ПО, которое самостоятельно выбирает инструменты и совершает действия. В 2027 г. число незарегистрированных агентов продолжит расти, а по мере совершенствования моделей их действия могут создать для вашей компании серьезные неприятности.</p> <p>В июне компания Meta <em>(признана экстремистской и запрещена в РФ)</em> наглядно продемонстрировала, к чему это может привести. Ей пришлось приостановить внутреннюю программу, в рамках которой фиксировались нажатия клавиш и содержимое экранов сотрудников для обучения ИИ-агентов: выяснилось, что эти данные стали доступны гораздо более широкому кругу лиц внутри компании, чем предполагалось изначально. Это был лишь один из многих подобных неприятных сюрпризов. В 2027 г. как минимум три крупные компании будут вынуждены либо полностью свернуть свои ключевые ИИ-проекты, либо отложить их реализацию на год. Причина в каждом случае будет одна: бизнес-подразделения несут ответственность за использование ИИ, но не имеют реальных рычагов для обеспечения соблюдения политик в ПО, на базе которого работают их агенты. Создайте специализированную группу по управлению ИИ, которая будет взаимодействовать с отделами безопасности, управления рисками, ИТ, разработки, юридическим департаментом и подразделением по управлению данными, — и наделите ее полномочиями внедрять политики непосредственно в программный код в масштабах всей организации.</p> <h3>Три четверти решений при выборе ИИ-платформ будут зависеть не от самих моделей, а от сред, в которых они работают</h3> <p>Компании будут ориентироваться прежде всего на среду исполнения, которая распределяет задачи, собирает контекст, управляет доступом к инструментам и проверяет результаты работы. Именно на этом уровне определяются точность системы и эксплуатационные расходы. Команды, использующие долгосрочно работающих агентов для написания кода или проведения исследований, сталкиваются с проблемами интеграции задолго до того, как достигают пределов возможностей самой модели, — и в 2027 г. этот разрыв станет еще заметнее. Поставщики уже начали превращать выбор модели в простой выпадающий список в интерфейсе платформы; в <nobr>2027-м</nobr> основные усилия компаний будут сосредоточены на выборе, создании или укреплении сред исполнения.</p> <p>При оценке потенциальных поставщиков ИИ-платформ уделяйте основное внимание возможностям среды исполнения и управления контекстом, а не результатам бенчмарков самих моделей. Прежде чем подписывать какие-либо документы, четко определите, за какой именно уровень технологического стека отвечает поставщик.</p> <h3>Еще две проблемные зоны</h3> <p>В отчете содержатся еще два важных вывода.</p> <p>Первый касается того, что модели с открытыми весами (open-weight models) выполняют значительную часть задач в сфере корпоративного ИИ, при этом на них приходится лишь малая доля затрат.</p> <p>Второй вывод гласит: только один из четырех проектов по созданию корпоративного контекстного слоя бужет способен обеспечить работу агентного ИИ в промышленных масштабах.</p> Руководители компаний готовятся к потрясениям, вызванным искусственным интеллектом, одновременно пытаясь реализовать … article https://www.itweek.ru/themes/detail.php?ID=235887 Thu, 05 Nov 2026 13:07:44 +0300 <p>«СиСофт Девелопмент» объявила о выпуске обновлений программ семейства EnergyCS: EnergyCS Режим, EnergyCS ТКЗ, EnergyCS Потери и EnergyCS Электрика. Обновления расширяют возможности анализа и моделирования электрических сетей, а также подготовки документации. Одно из ключевых направлений развития — согласованная работа с общей расчетной моделью, которая позволяет использовать одну схему сети для анализа установившихся режимов, токов короткого замыкания и потерь электроэнергии.</p> <p>Семейство EnergyCS предназначено для электротехнических расчетов при проектировании и эксплуатации электроэнергетических систем. В него входят пять самостоятельных программ, охватывающих основные инженерные задачи в этой сфере:</p> <ul> <li>EnergyCS Режим — расчет установившихся режимов, анализ напряжений, потоков мощности и загрузки оборудования;</li> <li>EnergyCS ТКЗ — расчет токов короткого замыкания и связанных с ними параметров работы сети;</li> <li>EnergyCS Потери — расчет и прогнозирование потерь электроэнергии, оценка мероприятий по их снижению;</li> <li>EnergyCS Электрика — комплексные расчеты распределительных сетей переменного и постоянного тока, в том числе с питанием от аккумуляторных батарей;</li> <li>EnergyCS Line — проектирование механической части воздушных линий электропередачи и волоконно-оптических линий связи на опорах ВЛ.</li> </ul> <p>Эти программы помогают обосновывать проектные решения при строительстве и реконструкции объектов, подключении новых потребителей и развитии существующих сетей. Расчетная модель создается в графическом редакторе: инженер строит схему и задает параметры элементов с помощью расширяемых справочников оборудования. Результаты расчетов отображаются непосредственно на схеме и в таблицах, что упрощает проверку и сравнение вариантов. Для EnergyCS Режим, EnergyCS ТКЗ и EnergyCS Потери предусмотрена общая модель сети: ее можно использовать для разных видов расчетов без повторного построения схемы.</p> <p>В версиях 2026 программы EnergyCS получили дальнейшее развитие.</p> <p>В EnergyCS Режим 2026 появилась команда «Баланс генераций-нагрузок» для расчета автономных сетей. Она позволяет балансировать мощности генерации, нагрузок и потерь. Результаты расчетов по линиям и трансформаторам теперь можно анализировать в отдельных таблицах, а для каждого элемента сети оценивать долю потерь от протекающей мощности. Это помогает детальнее исследовать условия работы оборудования и выявлять проблемные участки.</p> <p>EnergyCS ТКЗ 2026 дополнена расчетом междуфазных сопротивлений от предполагаемого места установки дистанционной защиты до точки короткого замыкания, а также соответствующих аварийных токов и напряжений. В справочнике кабелей расширен состав параметров для моделирования замыканий на землю. Новые функции позволяют подробнее анализировать аварийные режимы и получать исходные данные для задач релейной защиты.</p> <p>В EnergyCS Электрика 2026 усовершенствован расчет нагрузок с учетом характеристик элементов сети и потерь. Добавлены устройства плавного пуска и частотного регулирования, расширены возможности расчета токов короткого замыкания и работы с характеристиками защитных аппаратов. Кроме того, объекты можно разделять по этапам ввода и статусам — существующие, новые и демонтируемые — с последующим формированием спецификаций. Это позволяет учитывать последовательность реконструкции или развития объекта непосредственно в расчетной модели.</p> <p>В EnergyCS Потери 2026 продолжено развитие согласованной расчетной модели с EnergyCS Режим и EnergyCS ТКЗ. Уточнены табличные формы итоговых документов, расширены инструменты редактирования и оформления схем. В обновленных программах также появились средства группового изменения объектов, многократной вставки присоединений и управления текстовыми слоями. Они помогают сократить число повторяющихся операций при подготовке расчетной модели.</p> <p>Практический пример использования EnergyCS — опыт проектной организации АО «Электрощит», которая применяет EnergyCS Электрика и EnergyCS ТКЗ при проектировании объектов энергетики. Решению о переходе на специализированные инструменты предшествовала серия демонстрационных расчетов на собственных исходных данных. Использование программ помогло систематизировать работу с расчетными методиками и ускорить многие операции.</p> <p>Интерес к практическому освоению EnergyCS подтверждают отраслевые встречи и учебные мероприятия. В 2026 году возможности семейства представили на Форуме инженерных систем ЭТМ в Москве и конференциях ТИМИ/ТИМИТех в Санкт-Петербурге, Нижнем Новгороде и Тюмени. Обзорам новых версий также посвящена серия вебинаров, записи которых доступны для самостоятельного изучения.</p> <p>Очные тест-драйвы EnergyCS прошли в Минске, Москве и Уфе. В Минске при поддержке партнера «Главтелеком» с программами EnergyCS Электрика и EnergyCS ТКЗ работали представители «Мозырского НПЗ», «Калийпроекта», «Газпром трансгаз Беларусь», института «Белпромстройпроект» и других организаций. В московском тест-драйве активно проявили себя представители АО «КЭАЗ», АО «Институт Гидропроект», «Томская Энергомонтажная компания», ООО «ННГП». В Уфе в практических занятиях участвовали специалисты производственных, проектных и инжиниринговых компаний Башкортостана и других регионов, в том числе «РН-Проектирование Добыча», «Уралтрубопроводстройпроект», «Югранефтегазпроект» и «БЭСК Инжиниринг».</p> <p>«При выборе отечественного расчетного ПО инженерам важно сохранить глубину анализа и привычную последовательность работы, — прокомментировала Татьяна Медведева, продакт-менеджер по электротехническому направлению „СиСофт Девелопмент“. — Мы видим запрос на более глубокое освоение расчетных инструментов и их применение в конкретных инженерных задачах. Поэтому мы последовательно развиваем EnergyCS: расширяем состав моделируемого оборудования, добавляем расчетные функции и совершенствуем работу с моделью. Общая модель сети позволяет исследовать разные режимы на одной схеме, не создавая ее заново для каждого расчета».</p> «СиСофт Девелопмент» объявила о выпуске обновлений программ семейства EnergyCS: EnergyCS Режим, EnergyCS ТКЗ, EnergyCS … message https://www.itweek.ru/themes/detail.php?ID=235886 Thu, 05 Nov 2026 13:02:05 +0300 Сергей Писарев, руководитель группы персональных систем, департамент продуктового менеджмента, ГК <nobr>X-Com,</nobr> подготовил аналитический отчет, в котором представлены тенденции 2026 года и прогнозы на 2027 год рынка ноутбуков в РФ.<br/> <p>Общие выводы отчета:</p> <ul> <li>рынок ноутбуков в России находится в структурном спаде. Натуральные продажи сокращаются, а денежный объём может поддерживаться за счёт роста средней стоимости устройств. Модель «меньше единиц — дороже штука» сохраняется;</li> <li>фактическая динамика 2026 года слабая, но не катастрофическая. За I полугодие 2026 г. продано около 1,33 млн ноутбуков, снижение — 7,5% год к году; в июле падение составило 25%, в августе — 35% год к году. Денежный объём рынка при этом рос;</li> <li>оценки по итогам 2025 года неоднородны. Розничный аудит даёт около 2,9 млн шт. (данные Fplus, М.Видео) оценка по широкой категории мобильных ПК — чуть менее 3,4 млн шт. (ITResearch);</li> <li>сценарный прогноз на 2026 год. Базовый диапазон <nobr>2,0–2,2</nobr> млн шт. при базе 2,9 млн означает снижение на <nobr>24–31%.</nobr> Стрессовый сценарий — менее 1,8 млн шт., оптимистичный — <nobr>2,4–2,5</nobr> млн шт.;</li> <li>ценовое давление реально, но его масштаб в рознице РФ — сценарная оценка. Мировые контрактные цены памяти растут: в IV кв. 2026 г. ожидается DRAM <nobr>+10–15%</nobr> и NAND <nobr>+15–20%</nobr> кв/кв. Перенос в российские розничные цены оценивается в <nobr>15–25%</nobr> по базовому сценарию, <nobr>35–45% —</nobr> по стрессовому, <nobr>10–12% —</nobr> по оптимистичному. Возврат к ценам <nobr>2024–2025 гг.</nobr> маловероятен;</li> <li>дефицит носит не тотальный, а структурный характер. Не хватает не любых ноутбуков, а доступного ассортимента и рабочих конфигураций: 32 ГБ ОЗУ, ёмкие NVMe SSD, дискретная графика. Ситуацию усиливает переход дистрибьюторов на «тонкий склад» из-за дорогого оборотного капитала;</li> <li>регуляторные и канальные факторы повышают издержки и неопределённость. Технологический сбор, ограничения параллельного импорта и правила импортозамещения в B2B/B2G давят на поставки и ликвидность. Ставки техсбора до сверки с официальным нормативным актом нельзя использовать в количественных расчётах;</li> <li>китайские бренды усиливают позиции, но доля <nobr>75–80% —</nobr> гипотеза. Западные A-бренды уходят в серые каналы с наценкой за риск; российские марки доминируют в B2G, но в открытой рознице их доля остаётся низкой — около <nobr>3–5%;</nobr></li> <li>стабилизация ожидается не раньше II полугодия 2027 года. II кв. 2027 г. и рост продаж на <nobr>3–5%</nobr> кв/кв — сценарные предположения. Условия пересмотра: балансировка NAND, восстановление логистики, снижение стоимости кредита и реализация отложенного спроса МСБ.</li> </ul> Сергей Писарев, руководитель группы персональных систем, департамент продуктового менеджмента, ГК X-Com, подготовил … message https://www.itweek.ru/themes/detail.php?ID=235885 Thu, 05 Nov 2026 12:50:50 +0300 <p>Компания Avanpost, разработчик решений для безопасности идентификационных данных и управления доступом, выпустила новый продукт Avanpost DAG (Data Access Governance). Он объединяет комплекс решений, которые помогают организациям управлять доступом к неструктурированным данным (файлам на серверах, в облаках, на порталах) и контролировать действия с ними.</p> <p>В распределенной ИТ-инфраструктуре документы хранятся на сетевых серверах, облачных дисках и в базах знаний, вроде Confluence. Со временем там неизбежно оседают забытые архивы, рабочие копии договоров, технические инструкции с паролями и выгрузки персональных данных. Одновременно с этим права сотрудников накапливаются годами и перестают соответствовать их реальным должностным обязанностям. Службы ИБ сталкиваются с тем, что фактическое распределение доступа кардинально отличается от утвержденных регламентов. Avanpost DAG возвращает бизнесу прозрачность: система подключается к ресурсам, распознает конфиденциальные сведения по содержимому и фиксирует конкретные нарушения политик безопасности и запускает сценарии, обеспечивающие приведение прав доступа к данным в соответствие с принятыми правилами и регламентами. </p> <p>«Мы предлагаем не просто программное обеспечение, а комплексный подход к управлению неструктурированными данными. В Avanpost DAG встроен полнофункциональный движок бизнес-процессов. Выявив избыточный доступ, система не заставляет администратора удалять права вслепую, рискуя сломать рабочие процессы компании. DAG запускает настраиваемые сценарии: автоматически направляет запрос бизнес-владельцу данных, собирает согласования, формирует задачи для ИТ-отдела и контролирует их исполнение. После внесения корректировок проводится обязательное повторное сканирование, которое подтверждает, что доступ действительно закрыт и проблема решена. В дальнейшем решение отслеживает изменение прав доступа, содержимого объектов, перемещение и т.д., проверяет на соответствие политикам и сигнализирует о нарушениях в средства мониторинга ИБ (SIEM, SOAR), а также может запускать внутренние сценарии для устранения нарушений», — пояснил Павел Еременко, владелец продукта Avanpost DAG.</p> <p>Архитектура Avanpost DAG разрушает стереотип о долгих и сложных DCAP-проектах. Вендор целенаправленно пошел по пути радикального упрощения развертывания и перехода к логике коробочного решения. Внедрение системы и ее первичная настройка работают по принципу «установил и запустил». На текущем этапе вывода продукта на рынок компания предлагает предельно доступное лицензирование, а также до конца года действует маркетинговая акция, обеспечивающая очень низкий порог входа. Для объективной оценки состояния хранилищ и проверки реальных матриц доступа Avanpost предлагает заказчикам развертывание пилотного проекта на действующей ИТ-инфраструктуре. </p> <p>Avanpost DAG может работать как самостоятельное решение, однако его возможности кратно усиливаются при интеграции с системами класса IDM. Двусторонняя связь позволяет платформе анализировать права с учетом бизнес-контекста: система видит не просто логин, а кадровый статус, роль и основания назначения прав конкретного человека. Это дает возможность гибко реагировать на изменения, автоматически инициируя пересмотр доступа к данным при увольнении сотрудника или его переходе на новую должность. </p> <p>Компания представила две версии продукта:</p> <ul> <li>первая ориентирована на крупнейшие национальные корпорации. Ключевое преимущество решения — стабильная и эффективная работа в условиях высокой нагрузки;</li> <li>вторая разработана для компаний среднего бизнеса. Её главная особенность — простая, а в ряде случаев нативная интеграция с различными хранилищами данных и поддержка работы с разными типами данных.</li> </ul> <p>Архитектура Avanpost DAG построена на общем технологическом ядре с флагманскими продуктами вендора, что гарантирует отказоустойчивость и масштабирование под высокие нагрузки крупных предприятий. Регулярный автоматизированный аудит помогает ИБ-подразделениям выявлять подозрительные отклонения на ранних стадиях, снижать поверхность атаки.</p> <p>Требования регуляторов распространяются не только на исходные системы, но и на копии данных в файлах. Avanpost DAG показывает, где фактически хранятся персональные данные, включая выгрузки и сканы, и кому они доступны, а журнал событий связывает обращение к данным с пользователем, временем и объектом. Это поддерживает выполнение требований <nobr>152-ФЗ,</nobr> приказов ФСТЭК России № 21 и № 239 к разграничению доступа и расследованию инцидентов. Система также применима для задач ГОСТ Р <nobr>57580.1-2017,</nobr> PCI DSS и защиты коммерческой тайны. </p> Компания Avanpost, разработчик решений для безопасности идентификационных данных и управления доступом, выпустила новый … message https://www.itweek.ru/themes/detail.php?ID=235884 Thu, 05 Nov 2026 12:48:33 +0300 <p>Интеграционное решение для взаимодействия с государственными информационными системами TrustGate компании ИИТ («Инфотекс Интернет Траст») получило ряд функциональных обновлений. Они направлены на ускорение и повышение уровня защищенности обмена данными, выполнение новых регуляторных требований и упрощение эксплуатации корпоративной ИТ-инфраструктуры.</p> <p>TrustGate обеспечивает взаимодействие организаций с государственными информационными системами, включая Единую систему идентификации и аутентификации (ЕСИА), Единую биометрическую систему (ЕБС) и Систему межведомственного электронного взаимодействия (СМЭВ). Является типовым решением для взаимодействия с ЕСИА и ЕБС. Благодаря чему один из приоритетов развития продукта — своевременная адаптация к изменениям законодательства. </p> <p>За последние месяцы ИИТ последовательно расширяла перечень поддерживаемых видов сведений. Среди последних изменений — поддержка взаимодействия банков с Социальным фондом России по вопросам внесудебного банкротства граждан, получения сведений о банковских счетах и операциях страхователей, а также обмена информацией с нотариусами для подтверждения выдачи денежных средств заемщикам. </p> <p>Кроме того, в TrustGate реализованы виды сведений, необходимые кредитным организациям для открытия социальных вкладов и счетов через портал «Госуслуги» в соответствии с требованиями Федерального закона № <nobr>202-ФЗ,</nobr> которые с 1 января 2027 года распространятся на все банки. Новые возможности позволяют организациям выполнять регуляторные требования в рамках существующей интеграционной инфраструктуры без доработки собственных информационных систем.</p> <p>Отдельное внимание ИИТ уделяет развитию платежных сценариев. В TrustGate появилась поддержка двух новых видов сведений для взаимодействия кредитных организаций с информационно-платежным шлюзом Единого портала госуслуг. Функциональность ориентирована на организации, заинтересованные в приеме платежей за государственные и коммерческие услуги через ЕПГУ.</p> <p>Кроме того, в продукте реализована поддержка всех видов сведений для интеграции с мобильным приложением «Госключ» через СМЭВ. Теперь организации могут направлять документы на подписание с использованием УНЭП или УКЭП физического лица, УКЭП должностного лица, УКЭП юридического лица или индивидуального предпринимателя без разработки собственных адаптеров.</p> <p>ИИТ также продолжает совершенствовать технологическую основу TrustGate. В продукте появилась поддержка узловых очередей СМЭВ, позволяющих гибко маршрутизировать ответы и статусные сообщения по исходящим запросам. Новый механизм дает возможность разграничивать потоки данных по ведомствам, видам сведений и отдельным узлам информационной системы. Организации могут использовать несколько экземпляров TrustGate с независимыми базами данных, распределяя нагрузку между шлюзами и исключая перегрузку общей очереди. Это особенно важно для компаний с распределенной ИТ-инфраструктурой и большим объемом межведомственного информационного обмена.</p> <p>Наконец, продукт ИИТ поддерживает новый механизм обмена с файловым хранилищем СМЭВ 3 по протоколу HTTP based S3. С 1 декабря 2026 года использование FTP для передачи файловых вложений через хранилище СМЭВ 3 будет прекращено. Пользователям TrustGate достаточно изменить настройки адресов файлового хранилища без дополнительных программных доработок.</p> <p>Параллельно ИИТ развивает возможности самостоятельного управления интеграциями. Организации, использующие TrustGate, могут подключать новые виды сведений СМЭВ 3 с помощью сервиса ProxyGate. Такой подход позволяет выполнять необходимые настройки силами заказчика в рамках уже развернутой инфраструктуры, не ожидая выпуска обновлений со стороны разработчика.</p> <p>«Мы отслеживаем изменения нормативной базы и развитие государственных цифровых сервисов, чтобы наши заказчики могли своевременно адаптироваться к новым требованиям. Одновременно мы совершенствуем и саму платформу — делаем ее более гибкой, масштабируемой и удобной в эксплуатации. Такой подход позволяет организациям решать новые интеграционные задачи на базе уже внедренного решения без дополнительных затрат на доработку собственных информационных систем и разработку отдельных механизмов взаимодействия с ГИС», — прокомментировал Александр Володин, владелец продукта TrustGate. </p> Интеграционное решение для взаимодействия с государственными информационными системами TrustGate компании ИИТ («Инфотекс … message https://www.itweek.ru/themes/detail.php?ID=235883 Thu, 05 Nov 2026 12:47:18 +0300 <p>Технологическая компания Getmobit объявила о запуске Навигатора решений — открытой онлайн-платформы для предпроектной подготовки решений для рабочих мест — офисных, удалённых и гибридных — в существующей или проектируемой <nobr>VDI-инфраструктуре.</nobr> Навигатор переводит задачи бизнеса и контекст существующей ИТ-инфраструктуры, включая парк ПК, <nobr>VDI-системы</nobr> и ВКС, в готовую индикативную архитектуру. Он сокращает путь от формулировки потребности до первичного архитектурного решения до 1000 раз — с сотни часов технического анализа до нескольких минут.</p> <p>По итогам 2025 года российский рынок VDI вырос на 21%, к 2030 году он может достичь 10,7 млрд руб. При этом более 80% уже развёрнутых VDI по-прежнему работают на зарубежных платформах. Это создает потенциал миграции для сотен тысяч рабочих мест. Поэтому при выборе комплексного решения партнёрам и заказчикам важно учитывать не только функции новых продуктов, но и их совместимость с уже внедрёнными системами. Особенно сложной становится задача интеграции отечественных и зарубежных продуктов в рамках единой инфраструктуры.</p> <p>Традиционно такая предпроектная подготовка требует привлечения опытных системных архитекторов и значительных временных затрат. Навигатор берет на себя роль генератора индикативной архитектуры и снимает техническую боль — непредсказуемость интеграции зарубежного и отечественного ПО и «железа» друг с другом. В подбор попадают только сочетаемые между собой продукты Getmobit. Совместимость с <nobr>VDI-платформами,</nobr> ОС и оборудованием других производителей учитывается по матрице совместимости.</p> <p>Пользователь просто указывает задачу и параметры текущей инфраструктуры, получая на выходе карту компонентов, их роли, взаимосвязи и сценарии применения. Навигатор формирует архитектуру будущей системы, которая становится надежным фундаментом для дальнейшей технической и коммерческой проработки. Он ускоряет выход на стадию пилота (PoC) или расчета CAPEX/OPEX на <nobr>70–80%</nobr> за счет получения готовой рабочей спецификации в день обращения.</p> <p>Навигатор решений Getmobit предлагает более 10 актуальных бизнес-сценариев, которые охватывают ключевые задачи по модернизации цифровых рабочих мест. Сценарии постоянно пополняются и помогают подобрать архитектуру с учётом требований безопасности, особенностей существующей инфраструктуры, затрат на оборудование и необходимости обеспечить непрерывность бизнес-процессов. Среди наиболее востребованных:</p> <ol> <li>организация работы в открытом и закрытом сегментах сети с одного устройства для сокращения затрат на закупку и сопровождение двух физически независимых ПК при соблюдении требований безопасности;</li> <li>управление конечными устройствами и маршрутизация подключений при смене <nobr>VDI-платформы</nobr> для сохранения непрерывности бизнес-процессов при переходе на другую платформу виртуализации;</li> <li>организация универсального рабочего места с доступом к виртуальным приложениям и IP-видеотелефонии для объединения корпоративной связи и доступа к бизнес-системам в VDI на одном устройстве;</li> <li>оптимизация работы ВКС в среде виртуальных рабочих столов для снижения нагрузки на серверные мощности без потери качества видео и увеличения задержек во время онлайн-встреч;</li> <li>организация рабочих мест на базе тонких клиентов для обработки защищаемой информации для снижения рисков компрометации конечных устройств даже при централизации вычислений в дата-центре;</li> <li>получение единого окна доступа к виртуальным приложениям и рабочим столам для работы с локальными приложениями, виртуальными рабочими столами и терминальными сервисами без повторной авторизации;</li> <li>контроль геопозиционирования сотрудников и подрядчиков при доступе к информационным системам для ограничения инициации сессий авторизованными физическими площадками.</li> </ol> <p>В основе Навигатора — многолетняя интеграционная экспертиза Getmobit и опыт реализации проектов в разнородных ИТ-инфраструктурах. При формировании индикативной архитектуры инструмент учитывает существующий технологический стек заказчика и экосистему продуктов Getmobit.</p> <p>В зависимости от бизнес-задачи алгоритмы Навигатора подбирают оптимальную конфигурацию на базе продуктов компании, отвечающих за определённые функции в инфраструктуре цифровых рабочих мест:</p> <ul> <li>GM Smart System — платформа с единым центром управления GMSS NG Factory, который автоматизирует администрирование тысяч рабочих мест из одной точки, снижая нагрузку на техническую поддержку;</li> <li>GM-Box G1 RU — флагманская аппаратная платформа, объединяющая функции тонкого клиента и IP-телефона в едином эргономичном устройстве;</li> <li>GMSS NG Client — программное решение, дающее «вторую жизнь» legacy-оборудованию и превращающее совместимые ПК и сторонние тонкие клиенты в управляемые и безопасные конечные точки;</li> <li>BABYLxONE — универсальный интерфейс пользователя в формате супер-аппа, обеспечивающий бесшовный и безопасный доступ к виртуальным рабочим столам, приложениям и корпоративным сервисам независимо от того, где они развернуты;</li> <li>GM Virtual Media Optimizer — новое программное решение для оптимизации ВКС в VDI, которое переносит обработку аудио- и видеопотоков с серверов VDI на клиентское устройство, повышает качество связи и снижает нагрузку на серверы.</li> </ul> <p>«За годы внедрений мы накопили значительную интеграционную экспертизу и сформировали базу архитектурных сценариев, учитывающих специфику разнородных ИТ-инфраструктур. Постоянный диалог с заказчиками и партнёрами позволяет нам соотносить эту экспертизу с актуальными потребностями рынка и совершенствовать как технологические решения, так и модель взаимодействия на этапе подготовки проектов. Навигатор стал практическим воплощением этого подхода. Если раньше клиент тратил недели на подбор совместимых компонентов и расчет вариантов, то теперь он получает индикативную архитектуру цифровых рабочих мест мгновенно. Для бизнеса с парком от 1000 рабочих мест это означает ускорение старта проектов миграции на 80% и возможность сэкономить до 60% капитальных затрат за счет повторного использования существующего оборудования», — отметил Василий Шубин, директор департамента управления продуктовым портфелем Getmobit.</p> <p>Навигатор решений доступен на сайте Getmobit и может использоваться для подготовки проектов по развитию инфраструктуры удалённых рабочих мест.</p> Технологическая компания Getmobit объявила о запуске Навигатора решений — открытой онлайн-платформы для предпроектной … message https://www.itweek.ru/themes/detail.php?ID=235882 Thu, 05 Nov 2026 12:41:19 +0300 <p>В конце 2025 года сегмент ИП, продающих российскому бизнесу доступ к зарубежным ИИ-моделям через китайские прокси, практически отсутствовал. К августу 2026 года его оборот достиг <nobr>100-150</nobr> млн руб. в месяц. Это эквивалентно <nobr>14-21%</nobr> от объема легального рынка российских агрегаторов, который GPTunneL оценивает примерно в 700 млн руб. в месяц.</p> <p>В 2026 году в России сформировался новый сегмент посредников, которые предоставляют бизнесу доступ к зарубежным ИИ-моделям через китайские прокси и другие неофициальные схемы. Если в конце 2025 года таких продавцов были единицы, то к августу 2026 года их число, по оценке ИИ-платформы GPTunneL, достигло примерно 50. Совокупный оборот сегмента оценивается в <nobr>100-150</nobr> млн руб. в месяц.</p> <p>Для сравнения, объем легального рынка российских агрегаторов корпоративного доступа к зарубежным ИИ-моделям GPTunneL оценивает примерно в 700 млн руб. в месяц. Таким образом, серый сегмент уже эквивалентен примерно <nobr>14-21%</nobr> от объема легального рынка.</p> <p>Под легальными агрегаторами GPTunneL понимает российские юридические лица, которые получают доступ к зарубежным ИИ-моделям через собственные иностранные компании или партнерскую инфраструктуру, а затем предоставляют его российскому бизнесу от своего имени с уплатой необходимых налогов.</p> <p>ИП с прокси работают по другой модели. Они могут покупать у китайских посредников доступ к сервисам, которые позиционируются как Claude или GPT, но фактически работают через цепочки прокси, бесплатные лимиты других моделей, в том числе Kimi, либо через многократное использование официальных подписок OpenAI, Google и других разработчиков. Затем такой доступ перепродается российским компаниям с оплатой в рублях на счет ИП.</p> <p>Одной из причин распространения таких схем стала цена. Стоимость доступа для российского бизнеса может быть близкой к прямым тарифам Anthropic, OpenAI и Google, а в отдельных случаях даже ниже. При этом конечный пользователь не всегда может определить, через какую модель и инфраструктуру фактически проходит его запрос.</p> <p>Более низкая цена сопровождается дополнительными рисками. По данным GPTunneL, качество такого доступа может быть нестабильным, сервисы иногда надолго перестают работать, а запросы пользователей могут проходить через три-четыре посредника. Это повышает риски утечки корпоративной информации. В отдельных случаях, по оценке компании, передаваемые данные также могут использоваться для обучения китайских моделей.</p> <p>Для конечного покупателя возможны и налоговые риски. В случаях, когда посредник сам не уплачивает ввозной НДС, обязанность по его уплате может возникнуть у российского покупателя. Наличие у покупателя льгот по НДС, включая статус резидента «Сколково», этот риск автоматически не снимает.</p> <p>К концу 2026 года GPTunneL ожидает примерно двукратного роста текущих объемов. При сохранении этой динамики легальный рынок агрегаторов может увеличиться примерно до 1,4 млрд руб. в месяц, а оборот ИП с китайскими прокси — до <nobr>200-300</nobr> млн руб. в месяц.</p> В конце 2025 года сегмент ИП, продающих российскому бизнесу доступ к зарубежным ИИ-моделям через китайские прокси … message https://www.itweek.ru/themes/detail.php?ID=235881 Thu, 05 Nov 2026 10:36:30 +0300 <p><em>Хотя малые языковые модели (SLM) преподносятся как простое решение проблем, связанных со стоимостью и сложностью внедрения искусственного интеллекта, использующие их в реальных рабочих процессах CIO обнаруживают, что за этой экономией скрываются определенные нюансы, отмечают опрошенные порталом </em><em>InformationWeek</em> <em>эксперты.</em></p> <p>Аргументы в пользу SLM стали практически стандартным ответом. ИИ обходится слишком дорого, работает медленно или сопряжен с высокими рисками? Попробуйте модель поменьше.</p> <p>В прошлом году аналитики Gartner <a href="https://www.gartner.com/en/newsroom/press-releases/2025-04-09-gartner-predicts-by-2027-organizations-will-use-small-task-specific-ai-models-three-times-more-than-general-purpose-large-language-models">спрогнозировали</a>, что в 2027 г. организации будут использовать специализированные модели, предназначенные для решения конкретных задач, в три раза чаще, чем универсальные большие языковые модели (LLM). Этот сдвиг уже отражается в корпоративных бюджетах: в июле Gartner сообщила, что расходы на специализированные ИИ-модели, ориентированные на конкретные предметные области, только в <nobr>2026-м</nobr> вырастут на 210% — это более чем вдвое превышает темпы роста затрат на фундаментальные модели.</p> <p>Однако CIO, которые уже внедрили — или только пытаются внедрить — SLM в рабочие процессы, описывают гораздо более сложную картину. SLM действительно могут повысить эффективность, но зачастую не в той мере, в какой ожидалось, а сопутствующие расходы становятся заметны лишь после запуска системы в эксплуатацию.</p> <h3>Когда расчет действительно оправдывается</h3> <p>«Внедрение SLM в корпоративном секторе перешло от стадии пилотных проектов к полноценной архитектуре, и этот процесс набирает обороты», — отмечает Амит Убхаякер, директор по аналитике данных и ИИ компании Protiviti. По его словам, речь не идет о полной замене больших моделей; скорее, формируется многоуровневая архитектура: малые модели используются для маршрутизации, классификации и формирования структурированных ответов, тогда как передовые модели задействуются для решения неоднозначных, многоэтапных задач.</p> <p>Джейсон Джеймс, будучи CIO в поставщике технологических решений для ритейла Aptos, тестировал три-четыре специализированные модели на локальном оборудовании, а не в облаке. Целью было выяснить, оправданы ли затраты и усилия по поддержке таких моделей онпремис по сравнению с расходами на оплату токенов при использовании передовых моделей.</p> <p>«По сути, это чистая математика, — говорит Джеймс. — Каковы затраты на внедрение? Каковы расходы на эксплуатацию? Каков объем использования? Если при локальном запуске все эти показатели будут существенно ниже — тогда стоит рассматривать такой вариант. А если экономия незначительна, то зачем вообще что-то менять?».</p> <p>Хотя он недавно покинул Aptos, чтобы занять должность CIO в Acumatica, показатели тестирования свидетельствовали в пользу SLM — настолько, что в Aptos решили продолжить их пилотное внедрение. При этом, как отмечает Джеймс, такие модели не заменяют передовые инструменты, которые уже использовали команды в Aptos. Напротив, они расширяют выбор, позволяя избежать того, что он называет «банкротством по токенам» — ситуации, когда из-за неправильного подбора модели и некорректных промптов недостаточно подготовленные пользователи расходуют годовой бюджет на токены всего за несколько недель.</p> <p>По словам Убхаякера, SLM лучше всего проявляют себя в узких, повторяемых и поддающихся проверке задачах — например, при классификации, маршрутизации или извлечении структурированных данных, — особенно в тех случаях, когда существуют строгие требования к границам данных или нормативному соответствию. «Это не означает, что SLM вытесняют передовые модели, — говорит он. — Речь идет о создании многоуровневой архитектуры, а не о полной замене одних решений другими».</p> <h3>Когда данные разрушают бизнес-кейс</h3> <p>Именно с этой проблемой на собственном опыте столкнулся Эрик Пейс, который недавно ушел с руководящей должности в сфере корпоративных ИТ и теперь консультирует компании по вопросам внедрения ИИ. Его команда внедрила для подготовки маркетинговых сообщений небольшой дообученный вариант модели Llama, которая обучалась на исторических данных, размеченных как «хорошие» или «плохие». Результаты тестирования выглядели многообещающе, а путь к промышленной эксплуатации оказался неожиданно быстрым и недорогим. Однако выяснилось, что данные, которые казались надежными на этапе тестирования, не выдержали проверки в реальных масштабах эксплуатации.</p> <p>«В итоге нам пришлось отказаться от этого решения», — говорит Пейс, добавляя, что по-прежнему считает SLM эффективным инструментом для экономии времени, а вопросы дрейфа модели и управления версиями вполне решаемы в рамках разумного бюджета. Тем не менее, теперь он рассматривает качество данных как гораздо более критичный фактор для дообученных SLM, чем для ИИ-решений общего назначения.</p> <p>«Мало того, что наборы данных должны точно соответствовать тому, что вы хотите видеть на входе в модель, — нужно еще найти правильный баланс, — отмечает Пейс. — Возможность перестараться с обучением вполне реальна». Его совет: ставьте перед моделью четкие, ограниченные задачи, предусматривайте возможность ретроспективного тестирования и не недооценивайте объем знаний о бизнес-процессах и ответственности за данные, которые потребуются от сотрудников за пределами ИТ-отдела.</p> <p>Убхаякер уже сталкивался с подобными ситуациями, когда компании оценивали SLM, опираясь на общедоступные бенчмарки, а не на реальные данные и потоки запросов, с которыми им предстояло работать в производственной среде. «Организациям следует ориентироваться на стоимость выполнения одной успешной задачи, а не просто на стоимость одного токена, — отмечает он. — Модель меньшего размера может казаться более дешевой, однако необходимость повторных запусков, проверки результатов человеком или передачи задачи более мощным моделям может быстро свести на нет всю экономию».</p> <h3>Кто отвечает за совокупность моделей</h3> <p>Даже если каждая из SLM работает эффективно, их использование в составе целого комплекса создает дополнительные издержки. Джеймс объясняет это на практике: если рабочий процесс проходит через несколько специализированных моделей, выявить причину сбоя становится сложнее — ведь для устранения неполадки приходится взаимодействовать с владельцами каждой из моделей, чтобы понять, где именно возникла проблема и кто за нее отвечает.</p> <p>По словам Убхаякера, каждая специализированная модель требует индивидуальной оценки и мониторинга для выявления дрейфа поведения. Использование целого ряда таких моделей усложняет процессы маршрутизации запросов, обновления систем и отслеживания происхождения. Обновление или последующая донастройка базовой модели требуют повторного обучения и тестирования. Однако, как отмечает эксперт, еще более серьезный риск — это «разрыв между уверенностью руководства и реальным положением дел». Руководство часто полагает, что политики мониторинга соблюдаются, тогда как телеметрия показывает обратное — особенно когда команды внедряют специализированные модели быстрее, чем организация успевает их каталогизировать и взять под контроль.</p> <h3>Отказ от бинарного подхода</h3> <p>Все это вовсе не означает, что SLM — заведомо неудачный выбор. Просто они требуют гораздо более тщательной предварительной проработки, чем многие ожидают. Стоимость самой модели — это еще не полные затраты. Джеймс подчеркивает: прежде чем подсчитывать потенциальную экономию, необходимо заложить в бюджет расходы на управление, администрирование и обучение.</p> <p>Убхаякер считает, что решение о том, использовать ли малую или большую языковую модель для конкретной задачи, должно приниматься индивидуально для каждого случая. При выборе следует учитывать, является ли задача четко ограниченной и поддающейся проверке; обладает ли организация техническими ресурсами для поддержки модели; и способна ли малая модель действительно обеспечить требуемую точность. Ориентироваться исключительно на то, какая архитектура выглядит дешевле «на бумаге», — неверный подход. Ценность SLM относительна: она зависит от характера задачи, используемых данных и того, кто несет ответственность за модель после ее ввода в эксплуатацию.</p> Хотя малые языковые модели (SLM) преподносятся как простое решение проблем, связанных со стоимостью и сложностью … article https://www.itweek.ru/themes/detail.php?ID=235879 Thu, 05 Nov 2026 09:53:40 +0300 <p>Почти каждую неделю разработчики нейросетей добавляют новые функции ИИ-моделям, которые активно используются для разработки приложений, автоматизации процессов и работы с корпоративными данными.</p> <p>Вместе с новыми возможностями появляются и новые риски для безопасности: кибератаки становятся быстрее, ИИ-агенты получают доступ к критическим системам, а сотрудники самостоятельно создают приложения без глубоких технических знаний. Разберем, какие угрозы возникают и как компаниям к ним подготовиться.</p> <h3>ИИ резко ускоряет кибератаки</h3> <p>Нейросети позволяют злоумышленникам быстрее искать уязвимости, анализировать данные и готовить атаки. Задачи, которые раньше требовали длительной ручной работы, теперь можно частично автоматизировать.</p> <p>Особенно заметно ИИ ускоряет повторяющиеся действия. В <a href="https://www.anthropic.com/threat-intelligence-report-september-2026">отчетах Anthropic</a> описаны случаи, когда злоумышленники использовали модели для поиска учётных данных, анализа результатов атак и изменения вредоносного кода после срабатывания защиты. В некоторых расследованных атаках взлом занимал всего два-три часа, а в одной из кампаний в планировании и атаках фигурировало более 20 организаций. Сократился сам цикл атаки: «Разведка → Проверка → Изменение подхода → Повторная попытка». С помощью ИИ отдельные шаги этого цикла могут занимать минуты или даже секунды, а значит, у защитных систем становится меньше времени на выявление угрозы и перестройку защиты.</p> <p>Скорость стала дополнительным фактором киберриска. Можно сказать примерно так:</p> <p>«Киберриск = Вероятность × Последствия × Скорость».</p> <p>Это условная модель, а не строгая формула: она помогает показать, что ущерб зависит не только от вероятности и масштаба события, но и от того, насколько быстро компания его обнаружит и остановит.</p> <p>Например, <em>последствия</em> компрометации учетной записи могут существенно различаться в зависимости от <em>скорости</em>: обнаружит компания проблему через час или через сутки. Чем быстрее развивается атака, тем меньше времени остаётся на ее остановку.</p> <p>Скорость, в свою очередь, повышает требования к работе центров мониторинга безопасности (SOC). Когда злоумышленники могут за секунды менять способы атаки, ручной анализ и реагирование рискуют оказаться слишком медленными. ИИ может помочь SOC быстрее анализировать журналы событий и находить связи между ними.</p> <h3>Агенты получают слишком широкие полномочия</h3> <p>ИИ-помощники становятся новыми участниками корпоративной инфраструктуры наряду с сотрудниками. Они могут самостоятельно работать с репозиториями, базами данных, облачными сервисами и API. При этом последствия их действий зависят от предоставленных полномочий.</p> <p>Показательный <a href="https://www.tomshardware.com/tech-industry/artificial-intelligence/claude-powered-ai-coding-agent-deletes-entire-company-database-in-9-seconds-backups-zapped-after-cursor-tool-powered-by-anthropics-claude-goes-rogue">случай</a> произошёл в апреле 2026 года с компанией PocketOS, которая разрабатывает ПО для проката автомобилей. ИИ-агент столкнулся с проблемой доступа и самостоятельно нашёл в файлах проекта токен с широкими полномочиями. Затем агент удалил том с рабочей базой данных и связанными рабочими копиями. Операция заняла всего девять секунд. К счастью, при участии инфраструктурного провайдера удалось восстановить данные.</p> <p>Права ИИ-агентов необходимо ограничивать технически и предоставлять минимальные полномочия, необходимые для выполнения конкретных и заранее выбранных задач. Ещё очень желательно разделять доступ к тестовой и рабочей средам, требовать подтверждения критических операций и обязательно хранить независимые резервные копии.</p> <h3>ИИ может выходить за пределы тестовой среды</h3> <p>Эксперименты с агентами могут затронуть реальные рабочие системы, если тестовая среда для ИИ недостаточно изолирована. Например, агенту поручают проверить безопасность приложения и сообщают, что он работает в песочнице (закрытой системе). Но если у нейросети есть доступ к интернету, действующим ключам или рабочим системам, ИИ может проникнуть в продакшен-контур, которым пользуются клиенты и сотрудники.</p> <p>Подобные случаи<a href="https://www.anthropic.com/research/investigating-incidents-cybersecurity-evals"> описала Anthropic</a> во время тестирования модели Claude Mythos 5. Модель получила задание взломать вымышленную компанию. Это было испытание: может ли агент проникнуть в систему и найти скрытую информацию?</p> <p>Для взлома вымышленной компании агент придумал ловушку: создал вредоносную программу и разместил её в интернете под названием, которое использовалось во внутренних инструкциях компании. Он рассчитывал, что сотрудники или системы компании установят её, открыв доступ к своим данным.</p> <p>Модель в ходе рассуждений отмечала, что публикация такого пакета в реальном интернете была бы настоящей атакой. Но затем она сделала вывод, что всё происходит в симуляции, и продолжила выполнение задания. Проблема оказалась в том, что доступ к настоящему интернету у агента всё-таки был, и в результате созданный ИИ вредоносный код установили реальные сторонние системы и были похищены учётные данные одной из организаций.</p> <p>Чтобы агенты ничего не ломали в реальных системах, тестовые среды надо тщательно изолировать. Для этого стоит использовать отдельные сети и учётные записи, ограничивать исходящий трафик и разрешать подключения только к проверенным адресам. Конечно, за действиями агентов тоже нужно следить и предусмотреть возможность быстро остановить их работу.</p> <h3>Вайбкодинг создает новые уязвимости внутри компаний</h3> <p>Программирование с нейросетью дало сотрудникам возможность самим создавать приложения, даже если у них нет опыта разработки. При этом человек может не понимать, как устроен сгенерированный код и что он делает. В результате в корпоративной инфраструктуре появляются инструменты, безопасность которых никто полноценно не проверял.</p> <p>Такие приложения могут содержать уязвимости, передавать конфиденциальные данные внешним сервисам и получать избыточные права доступа. С поддержкой таких программ тоже возникают проблемы: сотрудник создал приложение, но со временем становится непонятно, кто отвечает за его безопасность и как его чинить при поломках.</p> <p>Для снижения этих рисков нужно вводить отдельные правила безопасности вайбкодинга. Например, назначать ответственного за каждое приложение, ограничивать доступ к корпоративным данным и проверять сгенерированный код перед запуском.</p> <h3>ИИ помогает находить сложные цепочки уязвимостей</h3> <p>Отдельную опасность представляют цепочки уязвимостей, которые позволяют злоумышленникам последовательно проникать в разные корпоративные системы. Например, ошибка в публичном сервисе может открыть доступ к системе авторизации, а через неё — к внутренним репозиториям. ИИ помогает быстрее обнаруживать и проверять такие взаимосвязи.</p> <p>Пример <a href="https://www.hacktron.ai/blog/hacking-openai">описала компания Hacktron</a>, которая занимается исследованиями кибербезопасности и разрабатывает ИИ-агентов для поиска и эксплуатации уязвимостей. В июле 2026 года её исследователи с помощью Claude обнаружили и использовали две уязвимости: в обработке изображений на публичном форуме OpenAI и в корпоративной системе единого входа (SSO). Через форум они получили доступ к учётным записям сотрудников OpenAI, а затем с помощью Codex смогли создать тестовый запрос на изменение кода во внутреннем репозитории компании. Вся цепочка заняла около 72 часов. Исследователи сообщили об уязвимостях, а OpenAI выплатила им вознаграждение в размере 6500 долл.</p> <p>Для защиты от подобных атак компаниям необходимо учитывать связи между системами, а не только отдельные уязвимости. Вот несколько способов: отслеживать зависимости программных компонентов с помощью SBOM (спецификации состава ПО), проверять связи между публичными сервисами и критической инфраструктурой, изолировать обработку пользовательских файлов. Чем меньше барьеров между системами, тем выше риск распространения атаки.</p> <h3>ИИ помогает находить уязвимости в популярном ПО</h3> <p>Ещё один пример — уязвимости PHP2Shell.</p> <p>В октябре 2026 года разработчики PHP выпустили исправления для двух критических ошибок: CVE-2026-109618 и CVE-2026-109619. Их объединили под названием PHP2Shell. Обе связаны с обработкой памяти в самом PHP и в некоторых случаях позволяют выполнить код на сервере без пароля или других учётных данных.</p> <p>Нашли уязвимости с помощью больших языковых моделей. Исследователи компании Calif сообщили о проблеме в августе 2026 года, независимо её подтвердили в OpenAI, а затем к анализу подключилась Wiz. В работе использовались генеративные модели, в том числе OpenAI. Исследователи направляли работу, проверяли результаты и готовили отчёт. Но ИИ заметно ускорил поиск сложной ошибки в коде, которая оставалась незамеченной много лет.</p> <p>После выхода исправлений 21 октября интерес к уязвимостям резко вырос: разработчики опубликовали обновления, но миллионы сайтов и серверов ещё продолжали работать на старых версиях PHP. Чтобы защититься, владельцам нужно обновить ПО.</p> <p>Уже на следующий день, по заявлению Cloudflare, число попыток взломов и использования уязвимостей достигло миллионов. 26 октября CISA добавила обе уязвимости в каталог активно используемых.</p> <p>Исследователи также увидели успешное выполнение команд на honeypot — специально созданных серверах-ловушках с уязвимыми версиями PHP. Их оставляют доступными, чтобы наблюдать за действиями злоумышленников. В одном из наблюдений за короткое время три таких тестовых PHP-сервера 35 раз использовались через уязвимости PHP2Shell.</p> <p>На момент публикации не было подтверждено, что злоумышленники сами использовали ИИ для атак. ИИ помог исследователям найти и проверить уязвимость, а затем информация о ней стала доступна всем, в том числе и злоумышленникам.</p> <p>Этот случай показывает новую особенность: ИИ ускоряет не только атаки, но и поиск уязвимостей. Для защитников это возможность раньше находить и закрывать проблемы. Но если компания долго не обновляет популярные компоненты, те же возможности получают и злоумышленники.</p> <h3>Что делать сейчас</h3> <p>Компаниям стоит уже сейчас решить, для каких задач можно использовать ИИ и к каким системам и данным его можно подключать. Для каждого такого случая нужно определить ответственного и заранее установить границы: что инструменту разрешено делать самому, а где он должен запросить подтверждение.</p> <p>Доступы лучше выдавать только необходимые для конкретной задачи. Тестовую среду нужно отделять от рабочей, а важные действия (например, удаление данных или изменение кода) проводить с подтверждением сотрудника. Действия инструмента важно записывать, чтобы при ошибке можно было понять, что произошло, и быстро остановить дальнейшую работу.</p> <p>Приложения, созданные с помощью ИИ, тоже нужно проверять ещё до запуска. У каждого такого приложения должен быть человек, который отвечает за его работу и безопасность. Чем важнее приложение и чем больше данных оно использует, тем тщательнее должна быть проверка кода, доступов и сторонних компонентов.</p> <p>Правила стоит периодически пересматривать: появляются новые инструменты, а вместе с ними — новые способы подключить их к корпоративным системам. Если заранее установить понятные ограничения и порядок проверки, компания сможет пользоваться ИИ и при этом лучше контролировать риски.</p> <p>#IMAGE_235880#</p> Почти каждую неделю разработчики нейросетей добавляют новые функции ИИ-моделям, которые активно используются для разработки … article Роман Стрельников, руководитель направления информационной безопасности “1С-Битрикс” https://www.itweek.ru/themes/detail.php?ID=235875 Tue, 03 Nov 2026 10:17:57 +0300 <p><em>2027 год станет проверкой реальности инфраструктурных стратегий: искусственный интеллект переходит в категорию критически важного производства, геополитическая неопределенность подвергает испытаниям глобальные операции, а организации выводят на передний план все больше приложений и интеллектуальных технологий, пишут в корпоративном блоге вице-президенты, главные аналитики </em><em>Forrester</em> <em>Микеле Пелино и Карлос Казанова.</em></p> <p>Для руководителей в области инфраструктуры и операций (I&O) это означает переосмысление того, как они создают инфраструктуру ИИ, повышают устойчивость и инвестируют в периферию. Forrester выделяет следующие три прогноза относительно I&O:</p> <ul> <li><strong> В четверти запросов предложений (</strong><strong>RFP</strong><strong>) на инфраструктуру ИИ будут содержаться требования вариантов ускорителей, отличных от поставляемых NVIDIA.</strong> Они останутся платформой по умолчанию для обучения передовых моделей и крупномасштабного инференса, но предприятия будут все чаще искать альтернативные ИИ-ускорители для сокращения затрат и снижения рисков в цепочке поставок и геополитических рисков и обеспечения суверенитета. Вместо замены решений NVIDIA организации будут сегментировать рабочие нагрузки по типам ускорителей в зависимости от конкретных требований. Гиперскейлеры уже расширяют возможности инфраструктуры ИИ с помощью собственных микросхем, таких как AWS Trainium, Google Ironwood TPU и Microsoft Maia. Руководители в области инфраструктуры должны включать разнородные требования к инфраструктуре ИИ в свои планы закупок и развития архитектуры.</li> <li><strong> Тридцать процентов крупных предприятий создадут частную инфраструктуру ИИ для инференса. </strong>В условиях перехода агентного ИИ в производство предприятиям потребуется выделенная инфраструктура ИИ для чувствительных, критичных к задержке и объемных рабочих нагрузок вывода. Рост стоимости токенов и более сложные агентные рабочие процессы будут еще больше стимулировать спрос на инфраструктуру, оптимизированную для экономики ИИ-инференса. Руководителям следует уже сейчас заняться разработкой корпоративной стратегии инференса, которая отделяет производственный инференс от обучения и приводит инфраструктуру в соответствие с потребностями рабочей нагрузки.</li> <li><strong> Инвестиции в инфраструктуру сместятся на 20% в сторону отраслевой периферии.</strong> Организации в таких отраслях, как промышленное производство, здравоохранение и розничная торговля, будут все чаще использовать рабочие нагрузки ИИ и аналитику на периферии, ближе к местам, где необходимо принимать решения. Малые языковые модели, модели ИИ для конкретной предметной области, робототехника и визуально-языковые системы действий будут перенесены на операционные технологические устройства для решения проблем с задержкой, отказоустойчивостью и подключением на таких объектах, как заводы, больницы, корабли и нефтяные вышки. Лица, принимающие решения в области инфраструктуры, должны разработать отраслевую вычислительную стратегию и инвестировать в меньшие форм-факторы и возможности, которые могут повысить эффективность рабочих нагрузок и одновременно приблизить ИИ к месту действия.</li> </ul> <p>ИИ станет просто еще одной частью I&O. Для этого потребуется более распределенная, специализированная и адаптируемая инфраструктура. Технологические руководители должны определить, где выполняются рабочие нагрузки, какие технологии их поддерживают и как обеспечить устойчивость инфраструктуры по мере изменения деловых и геополитических условий.</p> 2027 год станет проверкой реальности инфраструктурных стратегий: искусственный интеллект переходит в категорию критически … article https://www.itweek.ru/themes/detail.php?ID=235873 Tue, 03 Nov 2026 10:10:31 +0300 <p><em>Появление кириллических доменов расширило возможности для брендинга, но одновременно создало новое поле для конфликтов. Киберсквоттинг — регистрация чужого товарного знака в качестве доменного имени с целью перепродажи или недобросовестной конкуренции — переместился в кириллическую зону. Компании, которые не защитили свои бренды заранее, рискуют столкнуться с тем, что их название уже занято. </em><em>Разберем</em><em> нюанс</em><em>ы</em><em> современных доменных споров.</em></p> <h3>Разные зоны — разные правила</h3> <p>В России действуют несколько кириллических доменных зон, и механизмы разрешения споров в них различаются. Это важно понимать при выборе стратегии защиты бренда.</p> <p>Домены .ru и .рф находятся под юрисдикцией российского законодательства. Споры о них рассматриваются в российских арбитражных судах, а кассационной инстанцией по делам о товарных знаках выступает Суд по интеллектуальным правам. Процедура судебная, длительная, требует сбора доказательств и юридического сопровождения.</p> <p>Домены .рус, .москва, .дети и другие новые gTLD (generic top-level domains) существуют на основании договора с ICANN — международной организацией, координирующей систему доменных имен. К ним применяются международные процедуры разрешения споров: UDRP (Uniform Domain-Name Dispute-Resolution Policy) и URS (Uniform Rapid Suspension). Эти процедуры быстрее и дешевле суда, но требуют соблюдения строгих формальных критериев.</p> <p>UDRP позволяет правообладателю подать жалобу в один из аккредитованных арбитражных центров — чаще всего в Центр ВОИС по арбитражу и посредничеству. Если будет доказано, что домен идентичен или сходен до степени смешения с товарным знаком, зарегистрирован и используется недобросовестно, панель может передать домен правообладателю или аннулировать регистрацию. От подачи жалобы до решения обычно проходит около двух месяцев.</p> <p>URS — ускоренная процедура для очевидных случаев. Если нарушение явное, домен блокируется в течение нескольких недель. Но URS не передает домен — она только приостанавливает его работу на оставшийся срок регистрации.</p> <p>Ключевое различие между двумя механизмами не в скорости, а в результате. Панель UDRP может распорядиться передать домен. Российский суд домен не передает: он запрещает ответчику использовать обозначение, после чего имя освобождается и правообладатель регистрирует его в общем порядке.</p> <h3>Статистика: споров много, и их число держится на рекордном уровне</h3> <p>По данным Центра ВОИС, в 2025 году организация рассмотрела 6282 доменных спора — это наибольшее число за всю историю процедуры, которой в том же году исполнилось 25 лет. Показатели последних лет держатся примерно на одном уровне: 6192 дела в 2023 году и 6168 в <nobr>2024-м.</nobr></p> <p>Исходы, по данным ВОИС за 2025 год: около 5% жалоб отклонены, 15% дел урегулированы сторонами до вынесения решения, остальные завершились передачей домена правообладателю или аннулированием регистрации. Иными словами, при наличии зарегистрированного товарного знака и доказательств недобросовестности шансы вернуть домен высоки.</p> <h3>Кейс первый: кириллические домены в российском суде</h3> <p>В 2024 году ООО «Интернет решения», правообладатель более 60 товарных знаков с элементом "Ozon"/"Озон«, в ходе мониторинга интернета обнаружило, что предприниматель Дмитрий Гончарук зарегистрировал и администрирует домены озон.рф, озончик.рф, озоны.рф и озо.рф.</p> <p>Компания обратилась в Арбитражный суд города Москвы. Суд установил, что спорные доменные имена тождественны либо в высокой степени сходны с товарными знаками истца, в том числе с общеизвестным знаком, и 13 января 2025 года иск был удовлетворен частично: предпринимателю запрещено использовать обозначения «Озон», «Озончик», «Озоны» и «Озо» в доменных именах.</p> <p>Ответчик возражал, что использует не товарные знаки, а общеупотребительное слово «озон» и производные от него, и что сам правообладатель не воспользовался приоритетным правом на регистрацию в зоне .рф, то есть отказался от имени. Эти доводы не были приняты.</p> <p>Дальнейшая хронология показательна: апелляция оставила решение без изменения 31 марта 2025 года, Суд по интеллектуальным правам — 28 июля 2025 года, Верховный Суд отказал в передаче жалобы в коллегию 9 октября 2025 года, затем последовали заявление о пересмотре по новым обстоятельствам и отказ в нем 8 июля 2026 года, оставленный в силе 24 сентября 2026 года.</p> <p>Дело № А40-149116/2024 длилось более двух лет и прошло пять судебных инстанций.</p> <p>Из этого кейса следуют три практических вывода. Мониторинг работает: нарушение было выявлено именно так. Общеупотребительность слова сама по себе не защищает того, кто зарегистрировал домен. И отсутствие приоритетной регистрации не означает отказа правообладателя от своих прав.</p> <h3>Кейс второй: кириллический домен и процедура UDRP</h3> <p>Если домен находится в зоне, работающей по договору с ICANN, спор решается иначе.</p> <p>В 2011 году компания Dr. Ing. h.c. F. Porsche AG обратилась в Центр ВОИС по поводу домена порше.com (в технической записи — xn—e1arcf4b.com), зарегистрированного в 2006 году. Домен вел на страницу с рекламными ссылками, среди которых были предложения конкурентов.</p> <p>Отдельный интерес представляет то, что у Porsche не было товарного знака в кириллице — только знаки латиницей, охраняемые в том числе в России. Панель все равно признала сходство до степени смешения: домен является точной транслитерацией широко известной марки, и пользователь, увидев такое имя, с высокой вероятностью свяжет его с правообладателем.</p> <p>Ответчик на жалобу не ответил, но написал в Центр, что зарегистрировал имя в составе массовой закупки, допускал возможность конфликта с товарным знаком и готов передать домен. Панель расценила это как подтверждение отсутствия законного интереса, а использование припаркованной страницы с рекламой конкурентов — как недобросовестность. 8 апреля 2011 года домен был передан правообладателю (дело № D2011-0100).</p> <p>Для российских компаний здесь два важных вывода. Кириллическое имя и его техническая запись в punycode рассматриваются как одно и то же. И отсутствие кириллического товарного знака не закрывает дорогу к защите, если бренд достаточно известен.</p> <h3>Похожие буквы: как работает тайпсквоттинг</h3> <p>Отдельная категория нарушений — регистрация доменов, визуально почти неотличимых от оригинала.</p> <p>В зоне .рф такой прием невозможен: правила регистрации допускают только буквы кириллицы, цифры и дефис, смешивать алфавиты в одном имени нельзя. Зато он широко применяется в международных зонах.</p> <p>Показательны два дела Центра ВОИС. В 2013 году Siemens AG добилась передачи домена sıemens.com, где вместо латинской «i» использована турецкая «ı» без точки (дело № D2013-1318). В 2014 году то же самое сделала Twitter с доменом twıtter.com (дело № D2014-0469). На экране такие адреса выглядят почти как настоящие, но технически это совершенно другие домены, и используются они для перехвата трафика и фишинга.</p> <h3>Превентивная защита: что может сделать бизнес</h3> <p>Лучшая защита от доменных споров — меры, принятые заранее.</p> <ol> <li><strong>Зарегистрируйте товарный знак</strong>. Это ключевое условие для успеха в любом споре — и в суде, и по процедуре UDRP. Без товарного знака доказать права на имя значительно сложнее. Регистрация в Роспатенте занимает несколько месяцев.</li> <li><strong>Займите доменные имена, совпадающие с вашим брендом, в тех зонах, где вы реально работаете или планируете работать</strong>. Речь не о скупке адресов во всех зонах подряд: это дорого и не нужно. Речь о том, чтобы имя, совпадающее с вашим товарным знаком, не досталось третьим лицам там, где ваша аудитория будет его искать.</li> <li><strong>Настройте мониторинг новых регистраций</strong>. Существуют сервисы, отслеживающие появление доменов, похожих на ваш бренд. Как показывает дело «Интернет решений», именно мониторинг обычно и обнаруживает нарушение. Чем раньше оно найдено, тем проще его остановить.</li> <li><strong>Проверьте распространенные ошибки в написании бренда</strong> — в том числе варианты с похожими буквами из других алфавитов. Если у бренда есть неоднозначная транслитерация, стоит понимать, какие варианты уязвимы.</li> <li><strong>Оформляйте домены на юридическое лицо</strong>. Регистрация на сотрудника создает риски при его уходе и усложняет доказывание прав в споре.</li> <li><strong>Помните о кириллических вариантах названия, даже если основной сайт работает на латинском домене</strong>. В чужих руках такое имя может использоваться для фишинга или дискредитации бренда.</li> </ol> <h3>Что делать, если домен уже занят</h3> <ul> <li><strong>Переговоры</strong>. Иногда домен зарегистрирован по незнанию или для законных целей. Можно связаться с владельцем и обсудить выкуп. Но если владелец поймет, что вы готовы платить любую сумму, цена вырастет.</li> <li><strong>Процедура UDRP</strong> — для доменов в зонах, работающих по договору с ICANN, в том числе .рус, .москва, .дети. Жалоба подается в аккредитованный арбитражный центр. Доказывать нужно три обстоятельства: домен идентичен или сходен до степени смешения с вашим товарным знаком; у владельца домена нет прав и законных интересов в отношении имени; домен зарегистрирован и используется недобросовестно.</li> <li><strong>Суд — для .ru и .рф</strong>. Подается иск о нарушении прав на товарный знак с приложением свидетельства, доказательств использования бренда и фиксации нарушения. Суд запрещает ответчику использовать обозначение в доменном имени; после освобождения имени правообладатель регистрирует его в порядке, предусмотренном правилами регистрации.</li> <li><strong>Обращение к регистратору</strong>. Если домен используется для фишинга или распространения вредоносного ПО, регистраторы обычно реагируют быстро при наличии доказательств.</li> </ul> <p>По словам экспертов, основная ошибка компаний — откладывать регистрацию доменов на потом. Рассуждение звучит так: мы пока не используем кириллический адрес, зарегистрируем, когда понадобится. А когда время приходит, выясняется, что имя занято, и начинается долгая процедура его возврата. Стоимость регистрации домена несопоставима с судебными издержками и потерей времени.</p> <p>Важно понимать разницу в механизмах. Для доменов, существующих по договору с ICANN, действует UDRP: решение выносят арбитры, обычно в пределах двух месяцев, и панель может распорядиться передать домен. Для .ru и .рф спор идет в российском суде, который домен не передает, а запрещает его использование — и это может занять годы. Дело о доменах с обозначением «Озон» шло больше двух лет через пять инстанций.</p> <p>Недостаточно просто иметь товарный знак — нужно еще показать недобросовестность другой стороны. И здесь распространено заблуждение, будто неиспользуемый домен претензий не вызывает. Практика говорит об обратном: припаркованная страница с рекламными ссылками регулярно признается недобросовестным использованием, а в российских делах суды оценивают само по себе владение именем, сходным с известным знаком. Рассчитывать на то, что домен «просто лежит», не стоит.</p> <p>Мониторинг остается недооцененным инструментом. Практически во всех известных делах нарушение обнаруживали именно так. Чем раньше вы его заметите, тем дешевле обойдется защита".</p> <h3>Выводы</h3> <p>Кириллические домены — это не только возможность для брендинга, но и поле для конфликтов. Киберсквоттинг не исчез, он просто перешел в другую языковую среду.</p> <p>Превентивные меры — товарный знак, своевременная регистрация значимых для бизнеса имен, мониторинг — требуют небольших вложений и снимают большинство рисков. Если конфликт уже возник, работающие механизмы есть, но они требуют времени, денег и доказательной базы. Защитить бренд заранее дешевле, чем возвращать его через суд или арбитраж.</p> <p>#IMAGE_235874#</p> Появление кириллических доменов расширило возможности для брендинга, но одновременно создало новое поле для конфликтов … article Ян Созонов, юрист по доменному праву и правовому регулированию реестра .РУС (“Русские Имена”) https://www.itweek.ru/themes/detail.php?ID=235871 Tue, 03 Nov 2026 10:01:20 +0300 <p>Компания, у которой уже работает система электронного документооборота, подходит к задаче кадрового ЭДО с понятной мыслью: маршруты есть, хранилище есть, подписание есть, нужно добавить типы документов и настроить новые процессы. Решение выглядит дешевле покупки отдельной системы и логичнее с точки зрения ИТ-ландшафта.</p> <p>На практике проект такого типа либо затягивается, либо заканчивается покупкой отдельного решения после полугода доработок. Разберем, что именно не переносится и где граница между доработкой и новой системой.</p> <h3>Главное отличие: пользователь находится вне периметра</h3> <p>Классическая СЭД построена вокруг сотрудника с рабочим местом. У него есть учётная запись в домене, корпоративная почта, рабочий компьютер, он подключён к внутренней сети, и его участие в документообороте является частью его должностных обязанностей.</p> <p>Кадровый документооборот устроен иначе. Его участник это работник как физическое лицо, то есть другой субъект. У монтажника, водителя, продавца и повара нет рабочего места с компьютером. У значительной части штата нет корпоративной почты. Доступ к системе нужен с личного телефона, часто вне рабочего времени, иногда с территории, где нет устойчивой связи.</p> <p>Отсюда следуют требования, которых у СЭД не было по условию задачи: вход без доменной учётной записи, идентификация по номеру телефона, полноценное подписание со смартфона, уведомления по каналам вне корпоративного контура.</p> <p>Переделка интерфейса и мобильного клиента под эту модель настройкой не является. Это другая архитектура доступа.</p> <h3>Подписи: не три вида, а матрица</h3> <p>В СЭД вопрос подписи обычно решён однократно: квалифицированная подпись для внешнего обмена, простая или неквалифицированная для внутреннего согласования. Настройка статическая.</p> <p>В кадровом документообороте вид подписи определяется законом и зависит одновременно от двух параметров: от типа документа и от того, кто подписывает. Статья 22.3 Трудового кодекса задаёт закрытые перечни отдельно для работодателя и отдельно для работника.</p> <p>Работник подписывает только усиленной подписью, квалифицированной или неквалифицированной, следующие документы: трудовой договор, договор о материальной ответственности, ученический договор, договор на получение образования без отрыва от работы, согласие на перевод, заявление об увольнении и его отзыв, ознакомление с уведомлением об изменении определённых сторонами условий трудового договора, ознакомление с приказом о применении дисциплинарного взыскания. По остальным документам ему доступна и простая подпись, если соглашением сторон определены правила установления подписавшего.</p> <p>Для системы это означает, что вид подписи подставляется не настройкой маршрута, а правилом, которое читает тип документа и роль участника. Если оставить выбор человеку, ошибка неизбежна, и цена её высокая: ознакомление с приказом о взыскании, подписанное простой подписью, ставит под сомнение само взыскание, потому что ознакомление входит в порядок его применения по статье 193.</p> <p>Отдельный слой составляет выпуск подписей. В классической СЭД сертификаты получают несколько десятков человек, процесс ручной, и это приемлемо. В кадровом контуре сертификат нужен каждому работнику, то есть тысячам людей, и выпуск должен быть массовым, дистанционным и желательно бесплатным для компании. Это отдельная инфраструктурная задача, а не функция документооборота.</p> <h3>Документы, которые система обязана не принимать</h3> <p>Требование, непривычное для СЭД: часть документов нельзя перевести в электронный вид вообще. Часть 3 статьи 22.1 Трудового кодекса выводит из-под электронного документооборота трудовую книжку и сведения о трудовой деятельности, акт о несчастном случае на производстве, приказ об увольнении и документы о прохождении инструктажей по охране труда.</p> <p>Это закрытый перечень, и он означает, что система должна уметь блокировать отправку таких документов на подписание. Не предупреждать, а не давать. В СЭД такой логики нет по определению: там любой документ, попавший в систему, предполагается подписываемым.</p> <p>Ошибка здесь не исправляется переподписанием. Приказ об увольнении, оформленный только электронно, суд рассматривает как ненадлежащее основание прекращения трудового договора.</p> <h3>Согласия, уведомления и жизненный цикл локальных актов</h3> <p>Перед запуском кадрового документооборота работодатель принимает локальный нормативный акт о его введении, письменно уведомляет работников и собирает согласия тех, у кого был трудовой стаж по состоянию на 31 декабря 2021 года. Принятые позже и не имевшие стажа подключаются без согласия.</p> <p>Работник вправе отказаться, отказ нарушением не является, и за него нельзя уволить. Для отказавшихся компания бессрочно ведёт бумажный процесс, а документы, связанные с работой, обязана выдавать им на бумаге бесплатно и надлежаще заверенными.</p> <p>Для системы это означает флаг в карточке работника, который влияет на всю маршрутизацию, и отдельную ветку процессов. Технически несложно, организационно почти всегда упускается.</p> <p>Один человек вне контура создаёт полноценный второй процесс. В одной организации из почти шестидесяти работников отказался один, и компания считала переход стопроцентным. Фактически у неё стало два документооборота, и закончилось это тем, что приказ о сокращённом предпраздничном дне ушёл только через систему, а единственный бумажный сотрудник его не получил.</p> <p>Отдельно стоит жизненный цикл локальных актов. Ознакомление это финал, а до него акт создаётся, согласуется, утверждается, доводится до работников, и по истечении срока переиздаётся. Система, которая умеет только рассылать акт на ознакомление, оставляет остальной цикл ручным. В СЭД такой цикл обычно есть, и это одна из немногих частей, которая переносится без переделки.</p> <h3>Нагрузка ведёт себя по-другому</h3> <p>Классическая СЭД получает равномерный поток: документы создаются в течение дня, согласования распределены, пиков почти нет.</p> <p>Кадровый документооборот работает иначе. Рассылка одного локального акта на ознакомление приводит в систему весь штат одномоментно. Начало отпускного периода даёт всплеск заявлений. Январские приказы об индексации уходят всем сразу.</p> <p>При проектировании это редко учитывают: в техническое задание попадает средняя нагрузка, посчитанная от числа документов в месяц, а проверять надо другое: поведение при одновременном входе всех пользователей. Для СЭД, рассчитанной на несколько сотен активных сессий, приход всего штата в течение часа означает не рост нагрузки, а другой режим работы.</p> <h3>Интеграция идёт не туда, куда привыкли</h3> <p>СЭД обычно интегрирована с почтой, порталом, системой заявок. Кадровый документооборот должен быть связан прежде всего с учётной системой по персоналу: оттуда приходят оргструктура, штатное расписание, кадровые события, туда возвращаются статусы подписания.</p> <p>Три места, где это ломается чаще всего:</p> <ul> <li><strong>Односторонний обмен.</strong> Документ ушёл на подписание, работник подписал, статус в учётную систему не вернулся. Кадровик ведёт два окна и сверяет руками.</li> <li><strong>Расхождение справочников.</strong> Маршруты строятся на ролях, роли определяются по оргструктуре. Если справочники разошлись, документ уходит не тому согласующему, и обнаруживается это не сразу.</li> <li><strong>Потеря файлов подписи.</strong> При откреплённой подписи на каждый документ приходится отдельный файл. Интеграция, которая переносит только документ, оставляет архив без доказательной части, и выясняется это через годы.</li> </ul> <h3>Что из СЭД переносится, а что нет</h3> <p>Переносится инфраструктура: хранилище, права доступа, журналирование, общие механизмы согласования, жизненный цикл нормативных документов, интеграционная шина. Это немало, и именно поэтому идея выглядит привлекательной.</p> <p>Не переносится всё, что связано с участником вне периметра и с законом: модель доступа без доменной учётной записи, массовый выпуск сертификатов, правила выбора подписи по типу документа и роли, блокировка документов из закрытого перечня, учёт согласий и отказов, поведение под пиковой нагрузкой, обмен с учётной системой по персоналу.</p> <p>Граница проходит здесь: если ваша СЭД уже умеет работать с пользователями без доменных учётных записей и массово выпускать сертификаты, доработка реалистична. Если нет, вы пишете вторую систему внутри первой.</p> <h3>Как проверить это за один день</h3> <p>Возьмите три сценария и прогоните их на своей СЭД мысленно, а лучше руками.</p> <p>Первый. Работник без корпоративной почты и без рабочего компьютера получает трудовой договор и подписывает его со своего телефона усиленной подписью. Сколько шагов, где он берёт сертификат, что видит.</p> <p>Второй. Кадровик пытается отправить на электронное подписание приказ об увольнении. Система должна не дать.</p> <p>Третий. Локальный акт уходит на ознакомление всему штату, и все открывают его в течение часа.</p> <p>Если все три сценария проходят, доработка оправдана. Если спотыкается хотя бы первый, считайте стоимость отдельного решения: обычно она оказывается ниже стоимости доработки, потому что доработка повторяет путь, который кто-то уже прошёл.</p> <p>Нормативные ориентиры: статьи <nobr>22.1-22.3</nobr> и 193 Трудового кодекса; статьи <nobr>22.1-22.3</nobr> введены Федеральным законом от 22.11.2021 № <nobr>377-ФЗ;</nobr> Федеральный закон от 06.04.2011 № <nobr>63-ФЗ.</nobr> Сведения приведены на дату публикации.</p> <p>#IMAGE_235872#</p> Компания, у которой уже работает система электронного документооборота, подходит к задаче кадрового ЭДО с понятной … article Мария Жилева, сооснователь сервиса КЭДО “Добыто” https://www.itweek.ru/themes/detail.php?ID=235870 Mon, 02 Nov 2026 17:34:59 +0300 <p>Сентимент-анализ и «Суфлёр оператора» от BSS уже работают в контакт-центрах крупных государственных организаций обслуживающих население. Опыт применения показывает: когда система слышит эмоции клиента и подсказывает оператору ответ прямо во время разговора, конфликтов становится меньше, а обслуживание — быстрее и точнее. Именно поэтому такие инструменты становятся обязательной частью современного клиентского сервиса.</p> <p>В крупных контакт-центрах компаний и организаций с постоянным массовым потоком обращений не редки случаи звонков клиентов и граждан в состоянии стресса, раздражительности, внезапных негативных ситуаций. Часто они не отрабатываются корректно, а пропущенный конфликт становится известен лишь из жалобы. При таком развитии событий на помощь приходит модуль сентимент-анализа, который в реальном времени присваивает каждой реплике одну из трёх оценок — негатив, позитив или нейтрально, отдельно для клиента и для оператора.</p> <p>Оценку дают два независимых классификатора. Акустическая нейросетевая модель анализирует, как сказано, — тон и интонацию, а лексический классификатор смотрит, что сказано, по словарю характерных фраз. Если они расходятся, итог определяют настраиваемые правила — например, «негатив + нейтраль → негатив». Правила вынесены в конфигурацию, поэтому логику можно калибровать без доработки модуля.</p> <p>Результат анализа работает сразу в двух точках. В голосовом боте при негативе в речи клиента диалог не доводится до конца сценария, а сразу передаётся оператору выделенной скилл-группы, обученной работать со сложными обращениями. В речевой аналитике сентимент-метки помогают супервизору быстро найти диалоги с негативом и оценить, удалось ли оператору перевести разговор в позитив.</p> <p>На повышение удовлетворенности клиента работает и «Суфлёр оператора». В сущности — это коллектив ИИ-агентов, которые слушают диалог вместе с оператором в голосовом канале или чате. Система распознаёт речь или захватывает переписку, понимает запрос клиента и контекст разговора, находит нужное в корпоративной базе знаний и данные о клиенте в CRM и ERP. Затем сама или по запросу оператора выводит подсказку или заполняет форму.</p> <p>Оператор получает готовые ответы на типовые вопросы, предупреждения об отклонениях от скрипта, формулировки для деэскалации и компенсационные сценарии для претензий. По контексту разговора «Суфлёр» предлагает товары для cross-sell и upsell, в том числе маржинальные и акционные, а после звонка сам фиксирует причину обращения, упоминания конкурентов и удовлетворённость клиента.</p> <p>Решение разворачивается полностью в контуре заказчика: распознавание речи и LLM входят в поставку, при желании можно подключить облачные сервисы. Для персонализации подсказок используется RAG + LLM, для скорости и экономии ресурсов — классический полнотекстовый поиск. «Суфлёр» поддерживает протоколы MCP и A2A и «из коробки» интегрируется с чат-платформой, бот-платформой и базой знаний BSS.</p> <p>Инструменты дополняют друг друга: сентимент-анализ показывает, как идёт разговор, а «Суфлёр» подсказывает, что сделать дальше. По оценкам BSS, «Суфлёр» повышает конверсию из консультации в продажу до 20% и средний чек до 5%. Время обработки звонка сокращается на <nobr>5–10%,</nobr> нагрузка на операторов текстового канала — на <nobr>5–20%,</nobr> а новички выходят на план до двух раз быстрее. Повторных обращений становится на <nobr>5–20%</nobr> меньше, а CSI/NPS растёт на <nobr>2–5%.</nobr></p> <p>Компания перестаёт зависеть от узкой группы опытных операторов: их знания доступны каждому через подсказки. А супервизоры получают объективные данные об эмоциях в каждом диалоге вместо выборочного прослушивания.</p> <p>«Оператор контакт-центра одновременно ведёт разговор, ищет информацию в десятках инструкций и следит за настроением собеседника. Мы снимаем с него часть этой нагрузки. Сентимент-анализ вовремя показывает, что диалог уходит в конфликт, а „Суфлёр“ сразу предлагает верный ответ или уместное предложение. В итоге новичок работает на уровне опытного сотрудника, а бизнес сохраняет лояльность клиентов и выручку», — отметил Александр Крушинский, директор департамента голосовых цифровых технологий компании BSS.</p> <p>Эти технологий уже используют крупнейшие контакт-центры в государственном секторе, обслуживающих население РФ. Цифровой ассистент «научился анализировать поступающие запросы, в том числе по речевому и эмоциональному поведению», а ИИ подсказывает оператору формулировки, чтобы повысить точность ответа.</p> Сентимент-анализ и «Суфлёр оператора» от BSS уже работают в контакт-центрах крупных государственных организаций … message https://www.itweek.ru/themes/detail.php?ID=235869 Mon, 02 Nov 2026 15:38:24 +0300 <p>Сервисное обслуживание ИТ-оборудования становится одним из наиболее заметных запросов рынка. В поиске профильных подрядчиков заинтересованы как заказчики, так и компании, которые поставляют и внедряют оборудование и программное обеспечение. По данным исследования OCS, при выборе сервисного партнёра они прежде всего обращают внимание на инженерную экспертизу и региональный охват. В совокупности эти факторы отметила почти половина респондентов.</p> <p>Опрос показал, что для каждой четвёртой компании ключевым критерием при выборе сервисного подрядчика становится квалификация его специалистов. Стоимость услуг учитывается уже после оценки экспертизы. Это особенно важно для компаний с мультивендорной ИТ-инфраструктурой. Для её обслуживания необходим опыт работы с оборудованием брендов, официально не представленных в России, и многопрофильные инженерные компетенции, в том числе уникальные для рынка. Более половины респондентов отмечают важность единого окна для приёма заявок по решениям разных производителей. Такой формат упрощает взаимодействие и помогает избежать разрывов в обслуживании комплексной инфраструктуры. </p> <p>География проектов также расширилась за последние несколько лет. Компании в регионах наращивают и модернизируют ИТ-мощности, а отечественные производители активнее выходят за пределы крупных городов. Для интеграторов и производителей оборудования это означает усложнение сервисной модели. Обслуживание распределённых и удалённых объектов требует большой технической команды, отлаженной логистики и доступного запаса комплектующих. Сервисным подразделениям необходимо обеспечивать оперативную доставку ЗИП и поддерживать его наличие на региональных складах. Создание собственной инфраструктуры требует значительных вложений и времени, поэтому для большинства компаний рациональнее передать эту задачу профильному подрядчику. Региональную сеть называют основным критерием выбора 17% респондентов, наличие складов ЗИП в регионах важно для 61% опрошенных. </p> <p>Круглосуточный сервис и первая линия поддержки реже становятся определяющими критериями выбора. 44% и 30% участников исследования соответственно указали, что не считают эти возможности решающими. Это стандарт для сервисного предложения, а не самостоятельное преимущество подрядчика. При этом внешнее обслуживание чаще рассматривается не как полная замена собственной службы поддержки, а как способ расширить её возможности, например, при работе с мультивендорной инфраструктурой или региональными проектами. Для 57% респондентов привлечение подрядчика связано в первую очередь с масштабированием бизнеса: выходом на новые контракты, расширением продуктового портфеля и работой с новыми производителями. </p> <p>«При поиске сервисной организации компании учитывают множество факторов, анализируют реальный опыт и квалификацию специалистов. Чем сложнее системы и оборудование, тем важнее и строже эти критерии. Рынку нужен не исполнитель, а полноценный партнёр, который сможет координировать взаимодействие с разными производителями, обслуживать комплексную инфраструктуру и поддерживать развитие региональных проектов», — отметил Алексей Лабынцев, директор департамента сервисного обслуживания OCS.</p> <p>Партнёры и бизнес уже работали с поддержкой иностранных производителей и предъявляют высокие требования к российским подрядчикам. Компаниям важна устойчивость: инженерный и логистический ресурс, склады ЗИП, юридическая и финансовая надёжность. Исследование OCS показало, что в текущей ситуации эти факторы становятся для рынка приоритетнее цены. Экономия впоследствии может привести к увеличению расходов: нехватке запчастей в критический момент, простоям оборудования и убыткам. Финансировать большой штат инженеров и склады ЗИП при стоимости услуг в несколько раз ниже рыночной просто невозможно. Настоящей валютой становятся экспертиза и дополнительные ресурсы, которые могут помочь в развитии бизнеса. Сервисные организации, которые смогут закрывать эти запросы, с большой долей вероятности станут опорой для рынка в ближайшие несколько лет.</p> Сервисное обслуживание ИТ-оборудования становится одним из наиболее заметных запросов рынка. В поиске профильных … message https://www.itweek.ru/themes/detail.php?ID=235868 Mon, 02 Nov 2026 15:37:28 +0300 <p>Компания «Индид», российский разработчик решений в области защиты айдентити, представила обновление продукта Indeed Identity Threat Detection and Response (Indeed ITDR). Новая версия 2.3 позволяет организациям усилить защиту корпоративных систем, включая унаследованные приложения, повысить эффективность обнаружения кибератак и управления хранением событий доступа.</p> <p>Главным обновлением Indeed ITDR 2.3 стала поддержка NTLM-аутентификации. Теперь продукт охватывает все три основных протокола, используемых при доменной аутентификации Active Directory: Kerberos, LDAP и NTLM.</p> <p>Несмотря на развитие современных механизмов аутентификации, в корпоративных инфраструктурах по-прежнему используется NTLM — устаревший протокол проверки подлинности пользователей, от которого зависит работа многих унаследованных приложений. Полный отказ от него зачастую требует модернизации систем, а отсутствие дополнительных мер защиты повышает риски компрометации учетных данных и несанкционированного доступа.</p> <p>Для решения этой задачи в Indeed ITDR 2.3 добавлена обработка протокола Netlogon, который используется при взаимодействии с контроллерами домена для проверки учетных данных через NTLM. Благодаря этому продукт может отслеживать запросы на аутентификацию, выборочно блокировать их или требовать дополнительный фактор подтверждения личности. Такой подход компаниям применять политики безопасности к отдельным подключениям, сохраняя работоспособность унаследованных приложений.</p> <p>При этом Indeed ITDR не расшифровывает защищенные соединения Netlogon, а получает необходимые сведения из журналов событий Windows в реальном времени. Это дает возможность контролировать NTLM-аутентификацию без раскрытия ключей шифрования и изменения существующих схем взаимодействия с контроллерами домена.</p> <p>Новая функциональность также распространяется на случаи, когда NTLM используется как резервный способ проверки подлинности. Вместе с ранее реализованной обработкой Kerberos и LDAP это расширяет охват мониторинга Active Directory, сокращает слепые зоны и позволяет организациям постепенно отказываться от устаревшего протокола без нарушения рабочих процессов.</p> <p>В Indeed ITDR 2.3 компания «Индид» расширила возможности обнаружения атак на доменную инфраструктуру. Благодаря новвоведению, ИБ-специалисты могут раньше выявлять попытки несанкционированного доступа, обхода защиты и повышения привилегий, а также получать больше информации для расследования инцидентов.</p> <p>В частности, продукт теперь обнаруживает эксплуатацию уязвимости Kerberos CheeseOunce (CVE-2022-33679) и LDAP Guest Authentication — небезопасную анонимную аутентификацию через LDAP. Для обнаружения Kerberos FAST Downgrade и LDAP Guest Authentication в Indeed ITDR добавлена обработка Kerberos FAST и анонимных LDAP-запросов.</p> <p>Для эффективной работы с данными мониторинга разработчик усовершенствовал инструменты хранения событий. В версии 2.3 администраторы могут самостоятельно устанавливать, как долго сохранять информацию о запросах доступа, исходя из внутренних политик компании и нормативных требований. По истечении заданного срока записи удаляются, что предотвращает их бесконтрольное накопление и снижает риск переполнения дискового пространства.</p> <p>Кроме того, в консоли администрирования (Management Console) появилась возможность просматривать объем дискового пространства, занятого событиями доступа. Это помогает администраторам отслеживать накопление данных, своевременно корректировать сроки их хранения и предотвращать переполнение диска. В результате компаниям становится проще управлять журналами событий, сохраняя необходимую информацию для анализа угроз и расследования инцидентов.</p> <p>«Для нас важно, чтобы повышение безопасности не требовало от заказчиков перестройки ИТ-инфраструктуры. Во многих компаниях NTLM продолжает использоваться для работы устаревших приложений, и отказаться от него за короткий срок чаще всего невозможно. При этом использование протокола сопряжено с рисками безопасности: его уязвимости злоумышленники нередко используют для перемещения по инфраструктуре и повышения привилегий. Поэтому в Indeed ITDR 2.3 мы обеспечили поддержку всех трех основных протоколов, используемых при доменной аутентификации Active Directory, — Kerberos, LDAP и NTLM. Теперь организации могут взять NTLM под контроль, сохранив работоспособность существующих приложений и возможность постепенно переходить на современные технологии», — отметил Лев Овчинников, руководитель продукта Indeed ITDR компании «Индид».</p> Компания «Индид», российский разработчик решений в области защиты айдентити, представила обновление продукта Indeed Identity … message https://www.itweek.ru/themes/detail.php?ID=235867 Mon, 02 Nov 2026 15:35:52 +0300 <p>Устаревшее ПО становится причиной инцидентов информационной безопасности в сфере интернета вещей (IoT) в 60% успешных кибератак в 2026 году. Эксперты «Кросстех» называют основной причиной отсутствие процессов инвентаризации и управления обновлениями.</p> <p>По оценкам специалистов, злоумышленники стали на <nobr>15-20%</nobr> чаще атаковать IoT-устройства в I полугодии 2026 года по сравнению с аналогичным периодом прошлого года. Число инцидентов растет из-за расширения инфраструктуры интернета вещей: количество подключенных IoT-устройств в российских организациях превышает 100 млн, а значительная доля рынка приходится на промышленный интернет вещей (IIoT). Еще один из факторов потенциального взрывного роста количества инцидентов: c появлением ИИ-агентов требовавшие ранее высокой компетенции и больших трудозатрат атаки стали доступны даже для начинающих злоумышленников. ИИ-инструменты ускорили реверс-инжиниринг бинарных прошивок устройств для поиска узявимостей, таких как переполнения буфера, пароли в открытом виде в коде и скрытые API-интерфейсы. </p> <p>¾ российских компаний, использующих IoT-устройства, испытывают дефицит их видимости, из-за чего не могут вовремя отключать неиспользуемые устройства и обновлять ПО действующих. В этом случае злоумышленники могут использовать уязвимые устройства как точку входа, с их помощью проникать в инфраструктуру, красть чувствительную информацию и даже воздействовать на инфраструктуру.</p> <p>«Не так давно во Франции произошла атака на IoT-устройства, когда злоумышленники с помощью уязвимостей смогли воздействовать на систему регуляции температуры в холодильниках в супермаркетах. Они повысили температуру до 50 градусов, что привело к массовой порче товара. Такая ситуация вполне может быть масштабирована и на более критичные предприятия и процессы, например, в промышленности. В таком случае потери будут гораздо более значительными, чем в описанном кейсе», — отметил Василий Коровицын, ведущий эксперт департамента оценки защищенности «Кросстех».</p> <p>В компании отмечают, что разворачивание сетей 5G в России окажет влияние и на интернет вещей: системы будут становиться более масштабными, объединят тысячи автономных датчиков, дронов и контроллеров в единую технологическую сеть, что в свою очередь приведет и к росту кибератак на IoT-устройства.</p> <p>«Важно уже сейчас выстраивать процесс инвентаризации и регулярного обновления прошивок, чтобы сделать систему более устойчивой к кибератакам. Контроль активов — важнейшая составляющая, которая помогает компании понимать границы своей инфраструктуры и все потенциальные векторы атаки. Компаниям также необходимо регулярно сменять стандартные пароли, сегментировать сеть, проверять конфигурации устройств и т.д., чтобы обеспечивать киберустойчивость», — подчеркнул Василий Коровицын .</p> Устаревшее ПО становится причиной инцидентов информационной безопасности в сфере интернета вещей (IoT) в 60% … message https://www.itweek.ru/themes/detail.php?ID=235866 Mon, 02 Nov 2026 15:33:52 +0300 <p>Aktiv.consulting (бизнес-направление компании «Актив») совместно с командой ТИМ ФОРС завершили проект по приведению системы информационной безопасности компании к требованиям ГОСТ 57580.1. Компания получила официальное заключение о соответствии с итоговым уровнем 0,7, что подтверждает зрелость ее системы ИБ и надежность, как поставщика банковского сектора.</p> <p>После 2022 года Банк России последовательно ужесточает требования к защите информации в финансовой сфере. Для подрядчиков банков это означает более строгий контроль ИБ, поэтому ТИМ ФОРС решила подтвердить свой уровень независимой оценкой соответствия.</p> <p>Сложность заключалась в том, что стандарт изначально спроектирован для банков с их инфраструктурой — кассовыми узлами, процессингом, банкоматами. У ТИМ ФОРС как у ИТ-разработчика эти объекты отсутствуют. Требовалась глубокая экспертная адаптация: аргументированное исключение неприменимых мер и корректная интерпретация оставшихся применительно к деятельности компании-разработчика.</p> <p>Дополнительные ограничения: жесткие сроки, невозможность длительных выездных проверок, необходимость решить задачу без расширения штата и закупки избыточных средств защиты, а также фокус сотрудников на разработке, а не на ИБ.</p> <p>Aktiv.consulting применила гибридную методологию. Вместо классического аудита с длительными интервью использовались структурированные опросные листы с последующей выборочной экспертной верификацией. Это снизило нагрузку на персонал, ускорило сбор информации на <nobr>50–70%</nobr> и сразу дало письменные артефакты для аудиторов.</p> <p>Ключевой этап — экспертная адаптация ГОСТ 57580.1 под профиль ИТ-разработчика. Совместно со специалистами ТИМ ФОРС команда Aktiv.consulting детально проанализировала требования стандарта: аргументированно исключила меры, неприменимые для компании без банковской инфраструктуры; оставшиеся требования переложила на процессы разработки, эксплуатации и сопровождения ПО; приоритизировала меры по влиянию на итоговый балл.</p> <p>На основе собранных данных разработан полный комплект организационно-распорядительной документации и сформирована дорожная карта развития ИБ на годы вперед, учитывающая ужесточение требований регулятора с 2027 года.</p> <p>Официальное заключение о соответствии ГОСТ 57580.1 (уровень 0,7), укрепило позиции АО «ТИМ ФОРС Альянс» (входит в группу компаний ТИМ ФОРС) в тендерах и стало одним из условий работы с крупным стратегическим клиентом. Главная ценность — не сам документ, а выстроенная ИБ-инфраструктура: процессы разработки и сопровождения банковского ПО в АО «ТИМ ФОРС Альянс» ведутся в соответствии с требованиями стандарта, создана прозрачная СОИБ, понятная сотрудникам и внешним аудиторам.</p> <p>Такой подход позволил достичь целевого уровня без избыточных затрат на новые средства защиты. Полученное заключение и сформированная доказательная база применимы при работе с другими финансовыми организациями и сокращают затраты на подтверждение соответствия в новых проектах, а поддерживать и повышать уровень компания будет в рамках периодической переоценки.</p> <p>«Финтех для ТИМ ФОРС — это многолетняя практика. Нам было важно не просто получить заключение, а встроить требования банковского стандарта в то, как мы разрабатываем и сопровождаем ПО. Как интегратор производительности мы отвечаем за результат всей связки — специалистов, команд и цифровых инструментов, в том числе на базе ИИ. Информационная безопасность в этой связке — не формальность к тендеру, а базовое условие доверия заказчика», — отметил Илья Воробьев, генеральный директор АО «ТИМ ФОРС Альянс».</p> Aktiv.consulting (бизнес-направление компании «Актив») совместно с командой ТИМ ФОРС завершили проект по приведению … message https://www.itweek.ru/themes/detail.php?ID=235864 Mon, 02 Nov 2026 10:07:01 +0300 <p>Создать небольшого агента сегодня можно быстрее, чем оформить его запуск по корпоративным правилам. На прототип уходит час, на согласование описание доступов и владельцев — несколько дней.</p> <p>Отсюда и начинается агентный хаос: с момента, когда скорость создания цифровых помощников становится выше скорости назначения ответственности и правил. В результате вокруг бизнеса вырастает слой маленьких автоматизаций, о которых знают только их авторы.</p> <p>Разберем, почему это опасно — и какой контур управления нужен, чтобы в компании не появилась теневая инфраструктура.</p> <h3>Почему хаос создают маленькие решения</h3> <p>Крупный ИТ-проект невозможно запустить так, чтобы никто этого не заметил. У него есть команда, бюджет, документация, владельцы и поддержка. С небольшим агентом дела обстоят совсем по-другому — это может быть бот с ежедневным отчетом или скрипт интеграции сервисов. Собрать его можно быстрее, чем пройти стандартную процедуру запуска — и ее начинают игнорировать.</p> <p>Отсюда и появляется хаос: автоматизация уже работает с корпоративными данными и выполняет действия, но о ней могут не знать DevOps, финансы или команда поддержки. Не определено, кто устранит сбой, во сколько обходится решение — и что случится, если создатель такого решения вдруг станет недоступен.</p> <p>Полный процесс запуска большого проекта здесь избыточен, но полностью обходить контроль нельзя. Его надо облегчить: зарегистрировать решение, описать доступы, стоимость, поддержку и условия отключения.</p> <h3>В заложниках автоматизации</h3> <p>Создатель цифрового помощника нередко остается единственным человеком, знающим, что он существует и как он устроен. Пока все работает, это незаметно. Затем меняется шаблон файла или ломается интеграция — и автоматизация возвращается к своему автору.</p> <p>Мы и сами как-то столкнулись с похожим эффектом: небольшие внутренние решения начали периодически «дергать» создателя обратно. Например, агент каждую неделю отправляет в канал маркетинга отчеты, а тут вдруг не прислал — надо разбираться. Сломалась автоматизация, связанная с рекрутингом — команда ждет, когда автор придет и все починит. Если инструмент уже встроен в важный процесс, создавший его специалист остается единственной точкой знания.</p> <p>Отсюда полезное разделение: человек, который понимает бизнес-проблему и придумал агента, не обязан годами обслуживать его. Создание требует одной экспертизы, эксплуатация — другой.</p> <h3>Владельца мало, но кто еще нужен?</h3> <p>Если одного только создателя автоматизации недостаточно, значит, нужен еще специалист, который возьмет на себя другую ответственность. Для корпоративного агента полезно разделять минимум две роли:</p> <ol> <li><strong>Бизнес-владелец</strong> — отвечает за то, зачем инструмент существует, какую пользу приносит и когда его пора отключить.</li> <li><strong>Технический владелец </strong>— отвечает за работоспособность, инфраструктуру, обновления и инциденты.</li> </ol> <p>Финансы могут следить за оплатой сервисов, DevOps — за инфраструктурой, профильное подразделение — за экономическим эффектом. Так решение перестает быть намертво привязанным к автору.</p> <h3>Когда агент становится частью теневой инфраструктуры</h3> <p>Риск появляется, когда у цифрового помощника появляется доступ к данным и право что-то менять, а в компании при этом не знают, кто за него отвечает.</p> <p>Для реальной работы ему нужны полномочия: читать документы, отправлять сообщения, менять записи, создавать файлы. Чем больше таких решений существует вне общего контура, тем труднее понять, куда передается информация и какие действия выполняются от имени сотрудников.</p> <p>Ограничения лучше задавать не только в инструкции. Если действие технически доступно, одного запрета «не делай этого» маловато. Для чувствительных операций права можно урезать через промежуточный сервис, который разрешает только нужные вызовы.</p> <h3>Минимальный паспорт автоматизации вместо бюрократии</h3> <p>Для небольших агентов достаточно облегченного «паспорта». Так, перед выходом из личной песочницы должно быть понятно:</p> <ul> <li> какую бизнес-проблему решает автоматизация и по какому показателю будет понятна ее польза;</li> <li> кто отвечает за ценность, а кто — за техническую часть;</li> <li> какими данными она пользуется;</li> <li> какие действия ей разрешены и где требуется подтверждение человека;</li> <li> сколько она стоит и кто ее поддерживает;</li> <li> от каких сервисов зависит;</li> <li> когда ее пересмотреть и при каких условиях отключить.</li> </ul> <p>Последние два пункта особенно важны. Агент может долго быть полезным, а потом утратить актуальность. Если никто не отвечает за пересмотр, он продолжит использовать токены, ключи и серверные ресурсы.</p> <p>Так среди помощников появляются «зомби-агенты». Бизнес уже забыл, зачем они нужны — а расходы и доступы никуда не делись.</p> <h3>Пять одинаковых агентов — тоже хаос</h3> <p>Представьте, что специалист автоматизировал какой-то процесс. Спустя пару месяцев второй сотрудник решил эту же задачу, но другим способом, а чуть позже третий сделал свой вариант, даже не подозревая о первых двух.</p> <p>Кроме того, есть другой, более опасный вариант, когда несколько автоматизаций управляют одним объектом. Например, один агент обновил карточку в CRM, второй в тот же день сделал это снова, но по своим правилам</p> <p>В итоге компания несколько раз платит временем за создание одной и той же функции — и, более того, продолжает поддерживать несколько реализаций. Чтобы этого не произошло, нужен хотя бы самый простой каталог, где расписано, какие агенты уже существуют, для чего и кто владелец. Перед созданием решения стоит удостовериться, нет ли уже рабочего аналога — а для критичных объектов заранее определить, какая автоматизация имеет право их менять.</p> <p>Само количество агентов при этом мало о чем говорит: пять полезных и управляемых сервисов могут быть лучше пятидесяти экспериментов. Важнее бизнес-эффект при понятной полной стоимости и уровне риска.</p> <h3>«Сделано за час» — еще не значит «дешево»</h3> <p>Агент продолжает потреблять ресурсы после запуска: токены, серверные мощности, подписки и время поддержки. По отдельности суммы малы — но десяток автоматизаций, например, уже превращается в постоянную и заметную статью расходов.</p> <p>Считать нужно полную стоимость владения. Прежде чем создать агента, надо подумать: а кто будет чинить сбои и обновлять интеграции? Кто заметит, что расходы вдруг существенно выросли? Есть ли вообще в компании ответственный, который регулярно отслеживает, сколько денег уходит на все подобные инициативы?</p> <p>Если не учитывать этот важный момент, «быстро и дешево собрали» легко превратится в «дорого и незаметно поддерживаем».</p> <h3>Не всем агентам нужен одинаковый контроль</h3> <p>Персональный помощник и корпоративный — это разные классы риска. К примеру, если ИИ помогает специалисту собрать данные или подготовить отчет, а человек сам проверяет работу и отправляет результат, достаточно легкого контроля.</p> <p>Совсем другое дело — автоматизация, которая переносит данные между сервисами, пишет в общие каналы или меняет записи без ручной проверки. Здесь необходимы владельцы, мониторинг и понятные права доступа.</p> <p>Критичность тоже различается. Если внутренний бот для маркетинга не прислал еженедельный отчет, бизнес это переживет. А вот если остановился инструмент, от которого зависят продажи или рекрутинг, задержка может обойтись компании недешево. Для таких сервисов нужны SLA, резервный ответственный и порядок восстановления.</p> <h3>Дело не в сотом агенте</h3> <p>Количество агентов само по себе мало о чем говорит. Проблема начинается, когда компания уже не может быстро понять, кто отвечает за конкретную автоматизацию, к каким данным у нее есть доступ, сколько она стоит и нужна ли вообще.</p> <p>Возвращать для каждого небольшого агента полный процесс запуска крупного ИТ-проекта нет смысла. Достаточно обязательного минимума: реестр, бизнес- и технический владельцы, понятные доступы, стоимость, поддержка и условия отключения. Такой облегченный порядок позволяет не тормозить эксперименты и при этом делает автоматизации видимыми и управляемыми.</p> <p>Бизнес-владелец отвечает за ценность решения, технический — за его работу и восстановление после сбоев. И даже полезного агента нужно периодически пересматривать: задача может исчезнуть, а расходы на токены, инфраструктуру и поддержку останутся.</p> <p>Поэтому запуск агента — не конец задачи. После него появляется новый корпоративный актив, который нужно сопровождать и контролировать.</p> <p> #IMAGE_235865#</p> Создать небольшого агента сегодня можно быстрее, чем оформить его запуск по корпоративным правилам. На прототип уходит … article Алексей Феофанов, директор по развитию бизнеса Umbrella IT