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=235388 Fri, 21 Aug 2026 10:03:49 +0300 <p>Институт статистических исследований и экономики знаний (ИСИЭЗ) НИУ ВШЭ на основе данных сплошного статистического обследования Росстата анализирует динамику и структуру затрат крупных и средних организаций (без учета субъектов малого предпринимательства) на внедрение и использование цифровых технологий в 2025 г.</p> <p>В 2025 г. организации направили на внедрение и использование цифровых технологий почти 5,9 трлн руб., что в текущих ценах на 11,8% выше показателя 2024 г.</p> <p>Основные статьи расходов — ПО (лицензии, SaaS, разработка, доработка, адаптация), на которое пришлось 37% анализируемых затрат, и ИКТ-оборудование (приобретение, аренда, обслуживание, модернизация, ремонт) с долей 27%.</p> <p>Расходы на ПО выросли на 13,7%, во многом за счет увеличения заказной разработки.</p> <p>Общий объем затрат на оборудование практически сохранился на уровне 2024 г. (-0,9%), при этом расходы на приобретение ИКТ-оборудования снизились (-10,2%), прежде всего в сегменте вычислительной техники, что объясняется как высокой базой 2024 г. (годом ранее отмечался рост затрат на четверть), так и сложностями с импортом, в том числе из-за возникшего в 2025 г. дефицита серверов и оперативной памяти на мировом рынке. Одновременно в 1,5 раза вырос объем затрат на аренду вычислительных мощностей (IaaS).</p> <p>Наиболее высокими темпами росли расходы на базы данных и цифровой контент: при доле всего 3,3% в структуре затрат за год они увеличились в 1,7 раза.</p> <p>Более половины анализируемых затрат приходится на сферу ИТ и связи (36%) и финансовый сектор (23,1%). В 2025 г. вложения выросли как в этих, так и в большинстве других отраслей— всего в 16 из 18. Расходы в госуправлении, здравоохранении, оптовой и розничной торговле увеличились на <nobr>20–22%,</nobr> в ИТ и связи, финансовом секторе, обрабатывающей промышленности, профессиональной и научно-технической деятельности, на транспорте — на <nobr>11–14%.</nobr></p> <p>Основную часть затрат на цифровые технологии организации покрыли за счет собственных средств (86,6%). Доля бюджетных составила 12,3%, заемных и прочих привлеченных средств — немногим более 1%.</p> Институт статистических исследований и экономики знаний (ИСИЭЗ) НИУ ВШЭ на основе данных сплошного статистического … message https://www.itweek.ru/themes/detail.php?ID=235387 Fri, 21 Aug 2026 09:09:39 +0300 <p>Компания МУЛЬТИФАКТОР, российский разработчик ИТ- и ИБ-решений, выпустила версию службы каталогов MULTIDIRECTORY 3.2.0. Обновление фокусируется на улучшении управляемости групповыми политиками, расширении поддержки отечественных операционных систем с мандатно-ролевым доступом и повышении отказоустойчивости распределённых инфраструктур.</p> <p>Одним из центральных улучшений стало отображение LDAP-структуры непосредственно в интерфейс управления групповыми политиками. Теперь администраторы видят полную иерархию организационных подразделений с привязанными и наследуемыми политиками в режиме реального времени. Это упрощает навигацию по каталогу и позволяет назначать групповые политики напрямую на нужное подразделение без дополнительных переходов между модулями. Всё это ускоряет работу администратора и снижает риск ошибок при настройке.</p> <p>В схему LDAP-каталога добавлены новые классы объектов и атрибуты, необходимые для работы с мандатно-ролевым доступом (МРД) в Astra Linux Special Edition (релизы «Смоленск» и «Воронеж»). Благодаря этому MULTIDIRECTORY теперь полностью совместима с требованиями по защите информации, предъявляемыми к системам в государственных и регулируемых отраслях. Обновление позволяет централизованно управлять учётными записями и политиками безопасности в инфраструктурах, где используются сертифицированные версии Astra Linux с МРД.</p> <p>Для распределённых и высоконагруженных инфраструктур реализована динамическая балансировка запросов между контроллерами домена в отказоустойчивой конфигурации. Система учитывает состояние healthcheck каждого контроллера и автоматически перенаправляет запросы на доступные узлы. Это позволяет разворачивать MULTIDIRECTORY в отказоустойчивом кластере, обеспечивая бесперебойную работу инфраструктуры даже при выходе отдельных компонентов из строя.</p> <p>В новой версии устранён ряд критических ошибок, влияющих на стабильность и совместимость системы. Исправлены BER-обёртка для LDAP Controls, логика определения namingContexts в rootDSE и обработка удаления атрибутов в Modify Request — теперь операция не чувствительна к регистру. Устранены ошибки в генерации файлов init.sls в результирующих политиках, очистке тома Salt Master от устаревших политик и ожидании готовности сервисов Kerberos.</p> <p>Обновление MULTIDIRECTORY 3.2.0 превращает службу каталогов в отказоустойчивое решение для распределённых инфраструктур, которое обеспечивает соответствие регуляторным требованиям и стабильность работы в сертифицированных контурах защиты информации.</p> Компания МУЛЬТИФАКТОР, российский разработчик ИТ- и ИБ-решений, выпустила версию службы каталогов MULTIDIRECTORY 3.2.0 … message https://www.itweek.ru/themes/detail.php?ID=235384 Fri, 21 Aug 2026 00:00:00 +0300 <p><em>Новое исследование «</em><em>Scaling</em> <em>AI</em> <em>agents</em> <em>with</em> <em>trustworthy</em> <em>data</em><em>» от MIT Technology Review и Google Cloud подтверждает, что эффективное внедрение искусственного интеллекта начинается с надежного фундамента данных и современных методов управления данными.</em></p> <p>Отчет основан на опросе 300 директоров по данным и аналитике, CIO, CTO, директоров по ИИ, а также руководителей отделов продуктов, ИТ, данных и ИИ в различных отраслях.</p> <p>#IMAGE_235385#</p> <p>Основные выводы из исследования:</p> <ul> <li>Большинство организаций (83%) сообщили об использовании агентного ИИ, при этом 73% используют его для ограниченного числа сценариев. Только каждая десятая организация использует его широко.</li> <li> Хотя 100% респондентов заявили, что планируют использовать агентный ИИ в течение следующих двух лет, только около половины респондентов доверяют точности и релевантности результатов работы агентов ИИ.</li> <li> Исследование также показало, что в среднем инструментам агентного ИИ доступны около 45% данных компании, при этом избранная группа респондентов, называемая «лидерами в области данных», предоставляет ИИ доступ к более чем 70% своих данных. Другие сообщают о предоставлении доступа к 30% или менее своих данных.</li> <li> В отчете успех и доверие лидеров в области данных к агентному ИИ объясняются прочным фундаментом данных, в то время как другие организации сообщают о проблемах, связанных с устаревшими системами.</li> </ul> <p>«Мы должны предоставлять агентам доступ к данным безопасным и надежным способом, чтобы люди могли максимально эффективно использовать данные, зная, что они полностью надежны», — считает Раджприт Баджва, вице-президент Shopify по инженерии и инфраструктуре данных.</p> <p>В отчете упоминается группа компаний, которую называют «лидерами в области данных». Эти компании сообщают о большем успехе в использовании агентного ИИ и меньшем количестве ограничений данных со стороны устаревших систем. Хотя только около 50% респондентов доверяют своим агентам ИИ, 100% лидеров в области данных сообщили о доверии к точности и решениям своих агентов ИИ. В отчете говорится, что это «сильный показатель того, что надежный ИИ требует надежного фундамента данных».</p> <p>За пределами группы лидеров в области данных 66% респондентов заявили, что устаревшие системы ограничивают их возможности масштабирования агентного ИИ, а 68% заявили, что устаревшие системы замедляют скорость работы агентов. Среди других проблем — недостаток контекста и унификации данных (40% респондентов опроса Teradata/Wakefield «Why Agentic AI Stalls Enterprise» сообщили об тех же проблемах, несмотря на наличие надежных моделей ИИ).</p> <p>«Организации стремительно переходят к операционной модели, в основе которой лежит ИИ. Теперь ИИ учитывается при принятии каждого бизнес-решения, в каждом рабочем процессе и при любых инвестициях. Без четкой приверженности ИИ на уровне всего предприятия организациям будет сложно в полной мере реализовать его потенциал в масштабе предприятия», — говорит Карли Идоин, вице-президент-аналитик Gartner.</p> Новое исследование «Scaling AI agents with trustworthy data» от MIT Technology Review и Google Cloud подтверждает … message https://www.itweek.ru/themes/detail.php?ID=235382 Fri, 21 Aug 2026 00:00:00 +0300 <p><em>Зарубежные аудиторы ушли из России, но потребность в зрелой стратегии информационной безопасности никуда не исчезла. Теперь российским компаниям приходится одновременно развивать собственные команды, обращаться к локальным консультантам и превращать ИИ-агентов в персональных экспертов по кибербезопасности.</em></p> <p>После ухода из России крупнейших международных аудиторских компаний рынок информационной безопасности лишился не просто известных брендов. Вместе с ними ушел доступ к огромному массиву практического опыта, который формировался благодаря работе с компаниями из разных стран, отраслей и регуляторных сред.</p> <p>Российский рынок составляет около 2% мирового рынка ИТ и информационной безопасности. Поэтому локальные специалисты и консультанты объективно работают с меньшим количеством сценариев, бизнес-моделей и инцидентов. Именно клиентское покрытие давало зарубежным аудиторам ключевое преимущество: они могли переносить в проекты процессы и подходы, проверенные на международном уровне.</p> <p>Рост доли России с 2 до 4% мирового ИТ-рынка к 2030 году можно рассматривать не как прогноз, а как ориентир для отрасли. Однако для такого роста недостаточно увеличивать число технологий и специалистов. Российскому бизнесу нужны зрелые процессы, в том числе в информационной безопасности. После ухода международных аудиторов готового доступа к таким практикам стало меньше, поэтому компаниям приходится фактически заново собирать эту экспертизу — внутри собственных команд, с помощью российских консультантов и ИИ-агентов.</p> <p>Сегодня перед российским средним и крупным бизнесом стоит сложный вопрос: откуда брать зрелую экспертизу и на чем строить стратегию информационной безопасности, если прежние источники знаний стали недоступны?</p> <p>Единственного решения здесь нет. Компании могут использовать три подхода — внедрять ИИ-агентов, развивать собственные команды и привлекать российских аудиторов. Но по-настоящему жизнеспособная стратегия возникает только тогда, когда бизнес совмещает все три направления.</p> <h3>ИИ-агент может стать экспертом по кибербезопасности — но на его обучение потребуется время</h3> <p>Современный ИИ — это уже не просто приложение, в которое пользователь вводит запрос через браузер. Бизнес может приобрести специализированный сервис, подключенный через API к крупным языковым моделям и способный самостоятельно выбирать источники и инструменты для решения конкретной задачи.</p> <p>На основе такой системы можно создать персонального ИИ-эксперта по информационной безопасности.</p> <p>Для этого агенту необходимо предоставить максимально полную базу знаний: российскую и зарубежную профессиональную литературу, нормативные документы, методологии, отраслевые исследования, описания угроз и практические материалы. Чем больше релевантной информации получает система, тем точнее становятся ее рекомендации.</p> <p>При последовательном обучении через год такой агент сможет превратиться в полноценного помощника для команды информационной безопасности. Он сможет обращаться в том числе к источникам, находящимся за пределами России, анализировать международные практики и сопоставлять их с задачами конкретного бизнеса.</p> <p>ИИ-агент способен помочь компании определить основные риски, понять, какой аудит необходимо провести, какие данные собрать и какой информации не хватает для принятия решений. Он также может использоваться при подготовке рекомендаций и формировании первоначальной карты информационной безопасности.</p> <p>При этом ИИ не должен работать бесконтрольно. Вместе с агентами компании необходимо внедрять системы проверки их действий, результатов и доступа к корпоративной информации.</p> <h3>Одного универсального специалиста недостаточно: стратегия ИБ требует целой команды</h3> <p>Второй путь — развитие собственной экспертизы. Это наиболее устойчивый, но одновременно самый дорогой вариант.</p> <p>Построить стратегию информационной безопасности силами одного универсального специалиста невозможно. Для полноценной оценки рисков нужны сотрудники с разными компетенциями: специалисты по ИТ и информационной безопасности, финансисты, представители бизнеса и другие эксперты.</p> <p>Каждый из них отвечает за отдельную часть задачи. Технические специалисты оценивают инфраструктуру и средства защиты. Финансисты помогают рассчитать возможный ущерб и стоимость мероприятий. Представители бизнеса определяют, какие процессы и данные действительно критичны для компании.</p> <p>Формирование полноценной стратегической карты может занимать не менее трех лет. После этого ее необходимо ежегодно пересматривать и актуализировать с учетом изменений бизнеса, инфраструктуры и угроз.</p> <p>Для компании это означает необходимость постоянно содержать команду специалистов либо заново привлекать экспертов при каждом обновлении стратегии. Поэтому собственная экспертиза дает бизнесу независимость, но требует долгосрочных инвестиций в найм, обучение и сохранение команды.</p> <h3>Российские аудиторы остаются необходимы, хотя их опыт пока уступает международному</h3> <p>Третий вариант — обращаться к компаниям, которые продолжают работать в России.</p> <p>У локальных аудиторов меньше международного опыта, готовых сценариев и накопленных отраслевых практик, чем было у крупнейших зарубежных компаний. Кроме того, на российском рынке пока не так много организаций, готовых заказывать комплексную разработку стратегии информационной безопасности: такие проекты стоят дорого и требуют участия руководства.</p> <p>Тем не менее полностью отказаться от внешней экспертизы бизнес не может. Независимые консультанты позволяют посмотреть на инфраструктуру и процессы со стороны, выявить риски, которые внутренняя команда может не замечать, и проверить обоснованность уже принятых решений.</p> <p>Российские аудиторы становятся важной частью системы, но их работа должна дополняться внутренней экспертизой компании и возможностями ИИ.</p> <h3>Стратегия ИБ показывает не только как защищаться, но и сколько это будет стоить</h3> <p>Стратегия информационной безопасности строится вокруг трех базовых принципов: целостности, доступности и достоверности информации.</p> <p>Ее задача — определить, в каких областях компания подвержена рискам и к каким последствиям они могут привести.</p> <p>Например, бизнесу необходимо обеспечить доступность стратегически важных документов. Но эта доступность может быть нарушена по разным причинам: из-за отключения электроэнергии, отказа сервера, действий злоумышленников или порчи документов сотрудником.</p> <p>Стратегия позволяет последовательно ответить на несколько вопросов: какие сценарии возможны, насколько они вероятны, какой ущерб могут причинить и какие меры помогут их предотвратить.</p> <p>На основе этого компания определяет, сколько денег необходимо потратить на минимизацию каждого риска. При этом стратегия не предполагает, что бизнес должен закрыть абсолютно все угрозы. Некоторые риски можно принять, если стоимость защиты окажется выше потенциального ущерба.</p> <p>Поэтому стратегия отвечает не только на вопрос, как закрыть риск, но и нужно ли вообще это делать. В отдельных случаях эффективнее не покупать дополнительную систему защиты, а пересмотреть сам бизнес-процесс.</p> <h3>Бесплатное или корпоративное решение: выбор должен зависеть от задачи</h3> <p>Стратегия также помогает определить, какие специалисты требуются компании и в каком количестве. Для минимизации каждого риска нужен свой набор компетенций, причем эти специалисты необязательно должны работать в штате.</p> <p>Одновременно бизнес решает, какие системы целесообразно разработать самостоятельно, а какие — приобрести у внешнего поставщика.</p> <p>Особенно активно сейчас обсуждается выбор между бесплатными решениями с открытым исходным кодом и платными корпоративными продуктами. Однако сама по себе стоимость лицензии не должна становиться главным аргументом.</p> <p>Решение необходимо выбирать исходя из задачи, масштаба внедрения, количества пользователей и условий эксплуатации. Бесплатный продукт может оказаться подходящим для одного сценария, но потребовать значительных затрат на настройку, поддержку и контроль в другом.</p> <p>Стратегия информационной безопасности позволяет связать технологический выбор с реальными потребностями бизнеса, а не с модой или формальным требованием внедрить определенный класс решений.</p> <h3>Трехлетняя карта заранее показывает, что делать и какой бюджет закладывать</h3> <p>Результатом стратегической работы становится дорожная карта. Она определяет, какие мероприятия компания должна выполнить в первый, второй и последующие годы.</p> <p>Благодаря этому бизнес может заранее распределить бюджет, запланировать внедрение систем, обучение сотрудников, аудит процессов и привлечение внешних специалистов.</p> <p>Такая карта не является неизменным документом. Если компания выходит в новый сегмент, запускает продукты, перестраивает инфраструктуру или меняет бизнес-модель, стратегию информационной безопасности необходимо актуализировать.</p> <p>Защита должна развиваться вместе с бизнесом. Иначе даже качественно подготовленный документ через несколько лет перестанет соответствовать реальным процессам и угрозам.</p> <h3>В одиночку не сработает: российскому бизнесу придется объединить все три подхода</h3> <p>В текущих условиях российским компаниям не стоит выбирать между собственной командой, ИИ и внешними аудиторами. Все три подхода необходимо использовать одновременно.</p> <p>Бизнесу нужно развивать внутреннюю экспертизу, инвестировать в обучение специалистов и сохранять целостность команды. Параллельно следует внедрять ИИ-агентов, обучать их на российских и зарубежных источниках и создавать механизмы контроля за их действиями.</p> <p>Кроме того, компаниям необходимо пользоваться услугами российских аудиторов, которые могут независимо оценить процессы, инфраструктуру и принятые решения.</p> <p>Отдельное внимание следует уделять системам, предотвращающим утечки персональных данных, поскольку развитие ИИ и расширение цифровой инфраструктуры создают дополнительные риски для корпоративной информации.</p> <p>Уход международных аудиторов лишил российский рынок части накопленной экспертизы, но не сделал построение зрелой системы информационной безопасности невозможным. Совмещение внутренней команды, внешнего аудита и возможностей ИИ позволяет создать стратегию, которая будет учитывать реальные бизнес-риски, доступные ресурсы и долгосрочные цели компании.</p> <p>#IMAGE_235383#</p> Зарубежные аудиторы ушли из России, но потребность в зрелой стратегии информационной безопасности никуда … article Сергей Крюков, генеральный директор exploitDog (НИР) https://www.itweek.ru/themes/detail.php?ID=235370 Fri, 21 Aug 2026 00:00:00 +0300 <p><em>Квантовые вычисления перешли из разряда теоретического любопытства в категорию инженерной реальности. Производители демонстрируют реальный прогресс в решении проблем масштабирования и коррекции ошибок. Существуют реалистичные планы по выпуску квантовых компьютеров, которые могут принести коммерческую выгоду. Но эта выгода будет неравномерной, проявляясь в конкретных классах высокоприоритетных задач и в разные временные горизонты. Технологическим руководителям необходимо практическое понимание того, где и когда квантовые вычисления, вероятно, будут иметь значение, пишет в корпоративном блоге Дэвид Мутер, главный аналитик </em><em>Forrester</em><em>.</em></p> <h3>Квантовые компьютеры — это другие, а не более быстрые компьютеры</h3> <p>Квантовые компьютеры — это не суперкомпьютеры с большей вычислительной мощностью, как это часто изображается в новостях. Классические компьютеры основаны на булевой логике, физически реализуемой в соответствии с уровнем напряжения в полупроводниках. Квантовые компьютеры основаны на линейной алгебре и интерференционных картинах, которые возникают из-за волновой природы квантовых объектов. Это делает квантовые вычисления принципиально иными, подходящими для других типов задач.</p> <p>Какие это типы задач? Речь идёт о задачах, связанных с экспоненциально растущим числом комбинаций, физическими системами квантового уровня или вероятностными результатами, которые трудно эффективно моделировать на классических системах. Примеры: оптимизация портфеля, молекулярное моделирование, открытие новых материалов, логистические маршруты, моделирование электрических сетей и некоторые формы стохастического анализа рисков.</p> <p>Что это значит? Если задачу можно решить классическим методом, она будет решаться классическим методом и впредь. Это также означает, что квантовые компьютеры станут компонентами более широкого вычислительного конвейера, решая вычислительные задачи, которые классические компьютеры не могут решить, а для остальных задач будут использоваться классические методы.</p> <p>Таким образом, квантовые вычисления не будут развиваться как самостоятельная платформа. Квантовые компьютеры будут гибридными, сочетая классические вычисления с квантовыми в единой системе. Поставщики, которые сделают квантовые вычисления доступными благодаря гибридным средам выполнения и интеграции с классическими вычислениями, станут главными лидерами рынка.</p> <h3>Ценность квантовых вычислений эволюционирует в избирательную коммерческую значимость</h3> <p>В краткосрочной перспективе состояние рынка по-прежнему будет определяться экспериментами. Прогресс будет достигнут за счет улучшения коррекции ошибок, совершенствования алгоритмов и более четкого понимания того, какие аппаратные средства масштабируемы. Наиболее неотложным приоритетом для бизнеса в это время будет безопасность. Организациям следует ускорить планирование постквантовой криптографии, поскольку достижения как в области квантового оборудования, так и в оптимизации алгоритма Шора для снижения требуемой вычислительной мощности квантовых вычислений приближают наступление «Дня квантовых вычислений» (Q-Day).</p> <p>В долгосрочной перспективе квантовые вычисления станут коммерчески значимыми, но избирательно. Они не станут повсеместным ускорителем для всех корпоративных технологий, как компьютеры, с которыми мы выросли. Скорее, это будет высокоточный инструмент для специализированных рабочих нагрузок. Наибольшие возможности будут сосредоточены в таких отраслях, как медико-биологические науки, химическая промышленность, материаловедение, финансовые услуги, логистика, производство и энергетика.</p> <h3>Оценивайте потенциал квантовых вычислений по соответствию рабочей нагрузке</h3> <p>Как и в случае с любой технологией, способ оценки квантовых вычислений заключается в определении того, какие бизнес-задачи обладают характеристиками, которые делают эту технологию потенциально полезной. Наиболее подходящие рабочие нагрузки, как правило, связаны с вычислительной сложностью, основанной на многомерной линейной алгебре, — это, например, оптимизация, молекулярное или физическое моделирование и вероятностное моделирование. Наименее подходящие рабочие нагрузки — это те, для которых уже существуют хорошие решения в классических системах или которые имеют большую сложность данных.</p> <p>Понимание перспектив и ограничений квантовых вычислений поможет организациям избежать как упущенных возможностей из-за чрезмерной самоуспокоенности, так и погони за ложными результатами, вызванной ажиотажем. Некоторым отраслям следует начать структурированное исследование уже сейчас, поскольку долгосрочный потенциал роста может проявиться раньше, чем ожидается. Другим следует отслеживать прогресс и избегать спекулятивных инвестиций до тех пор, пока прогресс в квантовых исследованиях не покажет более четкую совместимость рабочих нагрузок.</p> Квантовые вычисления перешли из разряда теоретического любопытства в категорию инженерной реальности. Производители … article https://www.itweek.ru/themes/detail.php?ID=235386 Thu, 20 Aug 2026 11:38:42 +0300 <p>В 2026 году искусственный интеллект наконец перешел от создания контента к выполнению реальных бизнес-процессов. Рынок совершает переход от систем, которые отвечают на запросы, к системам, которые действуют самостоятельно — от генеративного к агентному ИИ. Владимир Лебедев, директор по развитию бизнеса сервис-провайдера M1Cloud, рассказал, как трансформируется облачная инфраструктура для использования ИИ-агентов.</p> <p>Глобальный рынок агентного ИИ, по оценкам Stratistics MRC, в этом году достигнет $10,3 млрд и будет расти до $207,6 млрд к 2034 году при среднегодовом темпе роста 45,6%. По данным PwC, 88% руководителей планируют увеличить бюджеты на ИИ именно ради агентных сценариев, а Gartner прогнозирует, что к концу 2026 года 40% корпоративных приложений будут оснащены специализированными ИИ-агентами (против менее 5% в 2025 году). Агентный ИИ — это принципиально иная парадигма. Автономные агенты планируют действия, обращаются к корпоративным API, делегируют задачи другим ИИ-системам и выполняют многошаговые сценарии с минимальным участием человека. Человек смещается из позиции исполнителя в позицию супервайзера.</p> <p>За взрывным ростом внедрения ИИ-агентов скрывается фундаментальная проблема: корпоративная инфраструктура к этому не готова. По данным Google Cloud, 83% организаций заявляют о необходимости срочной модернизации мощностей для поддержки промышленного агентного ИИ.</p> <p>Запрос, который раньше генерировал один ответ, теперь запускает каскад из сотен действий. В отличие от пакетной обработки — чтение баз данных, межсервисное взаимодействие, координацию агентов. Каждое действие потребляет токены, генерирует сетевой трафик и требует ресурсов для логирования. Агентам нужна память о контексте и прогрессе. Каждый лишний шаг в цепочке вызовов умножает задержку, что требует от провайдера высочайшей скорости интерконнекта и оптимизированных сетей. Возникает феномен «инференс-налога» (inference tax) — скрытых затрат на вывод данных и разрастание хранилищ, с которыми уже столкнулись 62% технических руководителей (по данным Google Cloud).</p> <p>Российский рынок следует глобальному тренду, но со своей спецификой. Совместное исследование Apple Hills Digital, VK Tech, Cloud.ru и Selectel показывает, что 46% отечественных компаний уже используют или тестируют ИИ в облаке, а 27% клиентов провайдеров уже применяют облачных ИИ-агентов. Бюджеты на ИИ увеличили 35% компаний, опередив по темпам роста даже кибербезопасность. Если при классическом обучении моделей затраты относительно предсказуемы, то агентный ИИ генерирует расходы экспоненциально. Без автоматического мониторинга и управления каскадными вызовами компании рискуют столкнуться с тем, что до трети (а в случае с агентами — и больше) облачного бюджета будет сожжено впустую на неоптимальные маршруты агентов и простаивающие stateful-контейнеры.</p> <p>В новых реалиях облачный провайдер перестает быть просто поставщиком вычислительных мощностей и становится стратегическим партнером. Только облако способно обеспечить экономически обоснованную эластичность под непредсказуемые пиковые нагрузки агентных систем, избавляя бизнес от необходимости покупать дорогостоящее железо, которое устаревает за полтора года. Помимо этого, облако становится единой платформой для управления и безопасности: когда сотни автономных агентов получают доступ к корпоративным данным, централизованный аудит, управление правами и MLOps. Зрелый провайдер берет на себя роль FinOps-консультанта, помогая оптимизировать «инференс-налог»: распределяя нагрузку между CPU (для оркестрации), GPU (для тяжелого инференса) и специализированными ускорителями, а также настраивая автоматическое масштабирование stateful-сред.</p> В 2026 году искусственный интеллект наконец перешел от создания контента к выполнению реальных бизнес-процессов … message https://www.itweek.ru/themes/detail.php?ID=235380 Thu, 20 Aug 2026 09:43:39 +0300 <p>Двадцать лет назад ИТ-индустрия пообещала бизнесу гибкость и скорость. Сначала — через сервис-ориентированную архитектуру (SOA), затем — через «серебряную пулю» микросервисов.</p> <p>Это обещание звучало заманчиво: распилите монолит на крошечные независимые сервисы, общающиеся по вебу, и вы будете выкатывать функционал бизнесу за пару дней силами изолированных команд. Маркетинговый хайп победил инженерный рассудок.</p> <p>Сегодня за ширмой «современного стека» скрывается суровая реальность: тотальный паралич Time-To-Market (TTM), астрономический технический долг и кратные финансовые потери.</p> <h2>Архитектурные заблуждения и подмена понятий: ООП наизнанку</h2> <p>В чём фундаментальный просчет концепции микросервисов в их массовом исполнении? В том, что базовые принципы проектирования программного обеспечения — инкапсуляцию, слабую связность и объектно-ориентированный подход — попытались насильно перенести на уровень сети.</p> <p>Архитекторы «новой волны» решили, что микросервис — это изолированный объект, а сетевой HTTP/REST-запрос — это просто вызов метода. Индустрия проигнорировала законы физики. Если вызов метода в едином адресном пространстве оперативной памяти (In-Memory Call) занимает наносекунды и абсолютно надежен, то сетевой вызов между мелкогранулированными компонентами занимает уже миллисекунды. А сама сеть к тому же по определению ненадежна.</p> <p>Ирония судьбы — в том, что в эпоху расцвета классической SOA те же промышленные платформы, от enterprise-решений ведущих вендоров до систем с открытым исходным кодом на .NET, Java или Python, технически предоставляли абсолютно те же преимущества, которые сегодня приписывают исключительно микросервисам.</p> <p>Архитектурные возможности изначально позволяли объединить отдельные прикладные компоненты и интеграционные адаптеры в изолированные крупногранулированные сервисы в соответствии с границами доменной области. Внутри этого домена компоненты взаимодействовали в едином адресном пространстве оперативной памяти (In-Memory), а платформы великолепно масштабировались горизонтально за счет логических экземпляров среды выполнения в составе одной или нескольких операционных систем.</p> <p>В какой-то момент в индустрии перестали соблюдать базовые принципы SOA-архитектуры, забыв, что микросервисы — это не более чем подмножество SOA.</p> <p>Вместо того чтобы наводить порядок в границах доменной области, разработчики объявили проверенные подходы «тяжелыми» и ушли в микросервисный веб. Они упустили из виду, что этот самый веб — про переносимость, и вся его прелесть проявляется тогда, когда речь идет об интеграции разнородных систем, развернутых на принципиально разных платформах, когда речь идет об интероперабельности.</p> <p>Физическая изоляция (сеть и контейнеризация) стала защитой от низкой культуры и дисциплины разработки. Если вы не умеете инкапсулировать код в логические модули, сеть заставит вас сделать это силой. Но цена такого принуждения оказалась непомерной для бизнеса.</p> <h2>Подмена понятий: из песочницы разработки в промышленную эксплуатацию</h2> <p>Чтобы понять, как мы оказались в этой точке, нужно вспомнить историю развития технологий разработки. Весь этот технологический стек — контейнеризация, платформы оркестрации и автоматизированные CI/CD-пайплайны — изначально задумывался исключительно как инструментарий для высвобождения рабочего времени разработчика.</p> <p>В частности, изоляция сред в контейнерах была введена в процесс разработки как ответ на вечное проклятие: «на моей машине всё работало». Она была нужна, чтобы программист мог мгновенно развернуть готовое локальное окружение.</p> <p>Платформы оркестрации контейнеров создавались в недрах технологических гигантов для утилизации пустующих серверов дата-центров и быстрой подготовки эфемерных тестовых сред под нужды команд автоматизации. Эти инструменты создавались для «песочниц», прототипирования и автоматизации рутины. Никто не проектировал их под высоконагруженные транзакционные контуры, требующие промышленной надежности.</p> <p>Трагедия современной ИТ-индустрии в том, что инструмент быстрой лепки временных сред ошибочно приняли за стандарт. Архитекторы перенесли логику «песочницы» на боевые контуры транзакционных систем финансового и промышленного секторов. В результате бизнес получил хрупкую распределенную систему, где стабильность решения принесена в жертву сиюминутному удобству локального написания кода.</p> <h2>Великое заблуждение: архитектура системного ПО в транзакционном бизнесе</h2> <p>Микросервисная архитектура родилась не на предприятиях непрерывного цикла и не в банках с их высокоинтенсивными рабочими нагрузками. Она появилась в недрах цифровых гигантов (Netflix, Amazon, SoundCloud), у которых вообще не было чужих систем и разных поставщиков. Они контролировали 100% своего стека и писали всё с нуля.</p> <p>В этих условиях все сервисы изначально взаимодействовали на одном «языке» (JSON/REST), и трансформировать форматы данных было просто не нужно. Внедрение сложных интеграционных шин в такую однородную среду принесло бы только лишние накладные расходы.</p> <p>Но главное — характер их работы. Микросервисы в их каноническом виде — это архитектура уровня системного ПО управления ресурсами. Условная транзакция в облачном провайдере или стриминговом сервисе запускает длительный, асинхронный процесс. Например, развертывание виртуальной машины из ISO-образа. Этот процесс занимает десятки секунд или минуты. Пользователь готов ждать.</p> <p>На этом фоне 10 миллисекунд сетевых задержек, возникающих при взаимодействии между мелкогранулированными системными сервисами (один выделяет диск, другой вешает IP), — это не более чем математическая погрешность. Там действительно не нужна интеграционная транзакционная «молотилка».</p> <p>Но когда, например, в вакансиях «инновационного финтеха» для Core-системы со строгой OLTP-нагрузкой фигурируют микросервисы и оркестраторы — это признак тотального непонимания физики процессов. Финтех-операция должна выполняться синхронно, атомарно и за миллисекунды. И здесь 15 миллисекунд сетевых издержек на каждый шаг цепочки (запрос в сервис баланса, запрос в антифрод, запрос в лимиты) — это архитектурный приговор.</p> <p>Система тратит время не на полезную работу (изменение пары байт в СУБД), а на ожидание ответов по сети, обработку HTTP-заголовков и обеспечение консистентности данных (Eventual Consistency), которая в транзакционных системах недопустима по определению.</p> <h2>Иллюзия Time-To-Market: быстро на старте, паралич на финише</h2> <p>Главный аргумент в пользу микросервисов — это ускорение TTM. И на этапе разработки системы с нуля эта иллюзия действительно работает. Написать один мелкий сервис, который выполняет одну конкретную функцию, можно за пару дней. Руководство и бизнес-заказчик аплодируют стоя.</p> <p>Проблемы начинаются, когда система разрастается до сотен мелкогранулированных ИТ-сервисов, общающихся преимущественно по Web/HTTP. Бизнес же мыслит сквозными ценностями, а не микрофункциями. И когда для реализации одной новой бизнес-функциональности (например, внедрения нового типа лояльности) требуется одновременно изменить контракты в <nobr>5-7</nobr> разных микросервисах, начинается ад:</p> <ol> <li> <strong>Паралич взаимодействия команд:</strong> нужно согласовать изменения API с пятью независимыми командами. Продуктовый TTM падает до нуля, утопая в бесконечных созвонах, а также в согласованиях контрактов в спецификациях и задачах.</li> <li><strong>Интеграционный тупик:</strong> вместо релиза одной кнопкой компания получает сложнейшие распределенные релизные циклы. Архитектура превращается в распределенный монолит — худшее из обоих миров, выпуск релиза которого происходит дольше и болезненнее, чем в крупногранулированной SOA-архитектуре двадцать лет назад.</li> </ol> <h2>Облачный грабеж и трехкратный «инфраструктурный налог»</h2> <p>Когда ИТ-директора обосновывали переход на микросервисы, главным экономическим аргументом был отказ от «вендорской иглы» — коммерческих лицензий за процессорные ядра или вычислительные узлы, выделенные под прикладное решение. Обещание звучало как финансовое освобождение: «Мы уйдем на свободное программное обеспечение (Open Source), перенесем всё в облако и будем платить только за реальное потребление».</p> <p>Но на серьезных нагрузках микросервисная архитектура дает <strong>2-3-кратный рост расходов бюджета</strong>. Этот «финансовый пылесос» состоит из трех главных составляющих:</p> <ul> <li> <strong>Память и процессоры.</strong> В микросервисах каждому крошечному сервису нужно выделить сотни мегабайт оперативной памяти просто на прогрев его собственного изолированного окружения. Транзакция превращается в каскад из <nobr>10-15</nobr> сетевых вызовов, где до <nobr>40-60%</nobr> мощности процессора тратится на постоянную сериализацию и десериализацию JSON, шифрование TLS и перекладывание байтов по сетевым стекам. Чтобы переварить ту же нагрузку, приходится покупать в 2,5 раза больше вычислительных ядер (vCPU). Умножьте это на сотни сервисов и на зоны доступности. Как итог: бизнес платит за гигабайты памяти и процессорное время, которые вообще не используются для выполнения прикладной логики. В то же время транзакция в крупногранулированном сервисе — это просто передача ссылки на объект в памяти, не требующая выделения дополнительной памяти и процессорного времени на сериализацию и десериализацию.</li> <li> <strong>Скрытый «убийца» — сетевой трафик.</strong> Чтобы обеспечить высокую доступность, экземпляры микросервисов размазываются по разным дата-центрам (зонам доступности). Облачные провайдеры жестко тарифицируют каждый гигабайт трафика между зонами доступности (Inter-AZ). В рамках единого крупногранулированного сервиса этот трафик был бесплатным (внутри хоста); в микросервисах счета за внутриоблачную сеть часто превышают стоимость самих процессоров.</li> <li> <strong>Инфраструктурные надстройки как величайший обман.</strong> Пытаясь уйти от концепции интеграционных шин, ИТ-архитекторы заявили, что связь теперь «бесплатная». Но когда сетью стало невозможно управлять, индустрия придумала концепцию Service Mesh. Вместо одной центральной шины компания получила тысячи микрошин в виде прокси-приложений (sidecar) для каждого контейнера. Эксплуатация таких решений в крупных проектах показывает, что эти прокси съедают от 20 до 50% всей оперативной памяти и до 30% CPU всего вычислительного кластера. Бизнес просто перенаправил миллионы из одного кармана в другой — в пользу облачных провайдеров.</li> </ul> <h2>Практика против моды: опыт технологических лидеров</h2> <p>Для тех, кто считает эти расчеты «теоретическим ретроградством», индустрия приготовила серию сокрушительных прецедентов от компаний, чьи масштабы нагрузок не подлежат сомнению.</p> <h3>Amazon Prime Video: отрезвление изнутри</h3> <p>Самый громкий удар по микросервисной религии нанесла сама компания Amazon — создатель главной облачной инфраструктуры планеты.</p> <p>Инженеры команды Amazon Prime Video, спроектировав распределенную систему мониторинга качества видеопотоков по «модному учебнику», столкнулись с финансовой катастрофой при попытке масштабирования. Изначальная архитектура опиралась на оркестрацию через AWS Step Functions и бессерверные вычисления AWS Lambda. Архитектурный просчет заключался в том, что компоненты пайплайна (медиаконвертер и детектор дефектов) обменивались терабайтами тяжелых сырых видеокадров, постоянно сохраняя и скачивая их через промежуточное дисковое хранилище Amazon S3.</p> <p>В результате система уперлась в потолок производительности всего на 5% от целевой мощности: компания моментально уперлась в лимиты AWS Step Functions по количеству переходов между состояниями (state transitions) в секунду, а счета за Tier-1 API-запросы к S3 и сетевую сериализацию кратно превысили стоимость самого компюта.</p> <p>Инженеры Amazon полностью переписали архитектуру, объединив все три распределенных компонента в единое монолитное приложение, развернутое в контейнерах Amazon ECS. Вместо пересылки тяжелых фреймов по сети через S3, этапы конвейера стали обмениваться данными напрямую в оперативной памяти (In-Memory) в рамках одного процесса. Результат: <strong>затраты на инфраструктуру снизились на 90%</strong>, а ограничения масштабируемости исчезли.</p> <h3>Shopify: битва за скорость «выкатки фич»</h3> <p>Гигант мировой интернет-торговли Shopify, обрабатывающий миллионы транзакций, вовремя остановил тотальное дробление систем. Архитекторы обнаружили, что мелкогранулированность и распределенность разрушили границы контекстов, вызвав тяжелейший межкомандный паралич: для банального изменения логики скидок или корзины приходилось синхронно переписывать контракты API в шести независимых командах и репозиториях.</p> <p>Shopify официально провозгласил верность концепции «Маджестик Монолита» (Majestic Monolith), но вместо хаотичного «комка грязи» они планомерно реорганизуют кодовую базу в строго изолированный «<strong>Модульный монолит» (Modular Monolith)</strong>.</p> <p>Используя разработанный ими инструмент статического анализа Packwerk (в связке с софтверными контрактами Sorbet), компания жестко контролирует границы бизнес-доменов на уровне абстракции кода. Все модули находятся в едином репозитории и разворачиваются вместе, что избавляет инженеров от сетевой бюрократии, сохраняет строгую ACID-консистентность базы данных, но при этом изолирует зоны ответственности команд и сокращает TTM в разы.</p> <h3>Segment (Twilio): тупик мелкозернистой изоляции</h3> <p>Платформа сбора данных Segment изначально создала отдельный микросервис и отдельную очередь для интеграции с каждым внешним партнером (Mixpanel, Salesforce, Google Analytics и др.). В итоге их ИТ-ландшафт превратился в распределенный ад из более чем <strong>140 разрозненных сервисов и 140 отдельных репозиториев</strong>.</p> <p>Из-за постоянных обновлений общих библиотек и латания рассинхронизированных зависимостей (Dependency Hell) разработчики тратили 80% времени на поддержание жизнедеятельности инфраструктуры и RabbitMQ-очередей, а развитие продукта полностью остановилось. Сотни простаивающих контейнеров впустую сжигали базовые CPU-квоты облака.</p> <p>В итоге Segment осуществила радикальный шаг: объединила код всех 140 интеграций обратно в один монолитный Go-бинарник, получивший кодовое имя Centrifuge. Маршрутизация трафика по конечным партнерам стала осуществляться через внутрипроцессную таблицу диспетчеризации в оперативной памяти. Это мгновенно сократило расходы на серверы, драматически подняло утилизацию CPU и полностью ликвидировало ад управления зависимостями, вернув продуктивность продуктовым командам.</p> <h2>Ад оркестрации: почему сложные платформы автоматизации противопоказаны для High Load</h2> <p>Разрубив систему на тысячи кусков, компании выбрали в качестве главного инструмента управления тяжелые платформы оркестрации контейнеров. Но они стали стандартом де-факто для высоких нагрузок абсолютно незаслуженно. Для систем с экстремальными транзакционными нагрузками и жесткими требованиями к задержкам (low-latency) избыточный слой контейнерной оркестрации противопоказан:</p> <ul> <li> <strong>Сетевой пирог виртуализации.</strong> В таких средах сетевой трафик проходит сквозь бесконечные слои абстракций — виртуальные интерфейсы, оверлейные сети, прокси-таблицы ядра и инфраструктурные шлюзы. В транзакционном High Load подобная избыточность превращается в критическое узкое место. Сетевой диспетчер или аппаратный балансировщик эпохи классической SOA распределял трафик по экземплярам приложений практически со скоростью железа.</li> <li> <strong>Борьба за ресурсы.</strong> Оркестратор пытается динамически управлять ресурсами на уровне ядра операционной системы, ничего не зная о процессах и внутренних механизмах управления памятью самого прикладного решения (например, о «сборке мусора»). В итоге планировщик инфраструктуры и внутренний диспетчер приложения начинают «драться» за процессорное время, вызывая жесткое удушение (throttling) CPU и непредсказуемые задержки (latency spikes) прямо посреди финансовой транзакции.</li> <li> <strong>Сложность вместо надежности.</strong> Системы оркестрации создавались для управления тысячами эфемерных веб-компонентов, которые могут безболезненно падать каждую секунду. Но серьезная финтех-платформа или система управления предприятием состоит из стабильных, тяжеловесных сервисов, хранящих состояние (Stateful). Разворачивать под них сложнейшие распределенные оркестраторы — это чистая подмена понятий, увеличивающая аварийность системы из-за человеческого фактора и сложности конфигурации.</li> </ul> <h2>Назад к здравому смыслу: эволюционная реабилитация SOA</h2> <p>Признание краха мелкогранулированных микросервисов вовсе не означает, что индустрия должна в панике откатиться к неделимым монолитам. Выход из этого тупика лежит в возврате к классической, фундаментальной концепции SOA, но переосмысленной на новом технологическом витке:</p> <ol> <li><strong>Крупная гранулярность.</strong> Сервис должен быть крупным. Не «сервис генерации PDF», а «Сервис расчетно-кассового обслуживания». Он объединяет в себе весь бизнес-домен. Внутри него компоненты общаются в оперативной памяти. Сетевая граница проводится только там, где бизнес-процессы действительно разделены организационно (например, интеграция систем разных поставщиков, где SOA и её интеграционные паттерны исторически незаменимы).</li> <li><strong>Отделение бизнес-домена от интеграционного слоя.</strong> Мы берем из SOA проверенную интеграционную логику, но не тащим логику бизнес-домена на централизованную шину. Её задача — выполнять исключительно трансформацию, обогащение и маршрутизацию сообщений. Она выступает просто умным почтальоном для потока данных, связывая системы разных поставщиков.</li> <li><strong>Изоляция без посредников.</strong> Для изоляции рабочей нагрузки не нужны тяжелые контейнерные движки с централизованными демонами управления, являющиеся классической единой точкой отказа и узким местом производительности. Настоящая изоляция крупного SOA-сервиса реализуется через легковесные инструменты нового поколения, работающие по принципу <em>daemonless</em> (без демона) и в режиме <em>rootless</em> (без прав суперпользователя) — такие как Podman. Контейнер в такой схеме запускается как обычный, изолированный процесс Linux, управляемый напрямую ядром ОС (через стандартный systemd). Это дает предсказуемость среды (Infrastructure as Code) и скорость железа без инфраструктурных накладных расходов оркестраторов.</li> </ol> <h2>Вывод для бизнеса</h2> <p>Эра микросервисного романтизма завершается. Компании, считающие свои деньги, больше не могут позволить себе оплачивать трехкратный инфраструктурный налог. Побеждает здравый инженерный расчет.</p> <p>Классическая SOA, очищенная от бюрократии старых инструментов и усиленная легковесной daemonless-контейнеризацией, возвращает себе статус эталонной архитектуры. Она дает ровно то, что обещали, но не смогли дать микросервисы: прогнозируемый TTM, контролируемый техдолг и адекватные затраты на железо. Настоящий High Load всегда покоится на уровне операционной системы и железа, а не на уровне абстракций оркестраторов.</p> <p>#IMAGE_235381#</p> Двадцать лет назад ИТ-индустрия пообещала бизнесу гибкость и скорость. Сначала — через сервис-ориентированную … article Дмитрий Гаврилов, основатель ООО “Открытые Технологии Виртуализации” https://www.itweek.ru/themes/detail.php?ID=235377 Thu, 20 Aug 2026 00:00:00 +0300 <p><em>Компании продолжают вкладывать миллионы в нейросети, но всё чаще признают: результата нет. Разбираемся, почему пилоты не доходят до внедрения и что стоит изменить в подходе к ИИ уже сейчас.</em></p> <p>За последние два года искусственный интеллект прошел путь от модной новинки до строки в бюджете почти каждой крупной компании. Однако чем больше денег уходит на пилоты, тем острее встает вопрос: а где, собственно, отдача? По <a href="https://fortune.com/2025/08/18/mit-report-95-percent-generative-ai-pilots-at-companies-failing-cfo/">данным</a> MIT NANDA, около 95% корпоративных ИИ-пилотов так и не доходят до измеримого финансового эффекта, а по <a href="https://www.gartner.com/en/articles/hype-cycle-for-artificial-intelligence">оценке</a> Gartner, довольны окупаемостью инвестиций менее 30% руководителей при среднем чеке проекта около 1,9 млн. долл.</p> <p>Похожая картина и в России. По <a href="https://www.vedomosti.ru/global-ideas/articles/2026/06/02/1202053-vnedrenie-ii-biznes">данным</a> издания «Ведомости», 95% отечественных компаний пока не окупают инвестиции в ИИ-технологии, хотя 40% называют искусственный интеллект главным трендом цифровизации. Проблема почти никогда не в самой технологии — модели давно умеют решать прикладные задачи. Проблема кроется в том, как компании выбирают, запускают и оценивают такие проекты.</p> <h3>Почему пилоты не долетают до результата</h3> <p>Первая причина — путаница между желанием попробовать технологию и реальной выгодой от ее внедрения. Аналитики фиксируют эффект «рабочего мусора»: сотрудники <a href="https://www.kommersant.ru/doc/8632735">массово генерируют</a> ИИ-контент, который выглядит готовым, но требует переделки. Формально ИИ внедрен, но по факту он просто перекладывает работу с одного этапа на другой. В результате вместо сокращения издержек компания получает двойную нагрузку: сначала сотрудник тратит время на формулировку запроса, затем — на проверку и доработку сгенерированного результата, а выгода от автоматизации сводится к нулю.</p> <p>Вторая причина — данные и процессы. Российские аналитики <a href="https://www.cnews.ru/news/top/2026-03-24_biznes_svernul_ili_zamorozil">отмечают</a>: около 90% проектов по генеративному ИИ в отечественных компаниях откладываются или закрываются не из-за качества моделей, а из-за неструктурированных данных и хаотичных регламентов, в которые нейросеть просто не вписывается. Внедрять ИИ в процесс, где нет единого источника данных и нет ответственного за результат, — заведомо неэффективно и не приведет к ожидаемому результату.</p> <p>Третья причина — отсутствие стратегии и метрик. Согласно <a href="https://www.cnews.ru/news/top/2025-12-19_bolshinstvo_rossijskih_kompanij">исследованию</a> МТС Web Services, лишь 26% российских компаний, закладывающих бюджет на ИИ, имеют четкую стратегию внедрения. Без понятных критериев успеха невозможно оценить окупаемость, а значит, проект существует скорее «для галочки», чем для бизнеса, и при первом же аудите бюджета или смене фокуса его свернут, списав затраты в убыток.</p> <h3>Российская специфика: дорогие эксперименты и дефицит мощностей</h3> <p>К управленческим проблемам добавляется инфраструктурная. По <a href="http://reg.ru/company/news/12957">нашим данным</a>, спрос на облачные GPU-мощности в России за первое полугодие 2026 года вырос на 507% год к году: число новых подключений увеличилось на 160%, а ежемесячная активность пользователей — на 260%. При этом дефицит высокопроизводительных ускорителей для обучения крупных моделей сохраняется: сроки поставки востребованных карт достигают <nobr>36-52 недель.</nobr> По оценке <a href="https://www.comnews.ru/content/245257/2026-05-14/2026-w20/1008/vychislitelnyy-tupik-pochemu-rossiyskiy-ii-ostaetsya-bez-moschnostey">отраслевых экспертов</a>, совокупный разрыв в вычислительных мощностях между Россией и США измеряется сотнями раз, а весь российский рынок GPU-ускорителей для ИИ в 2025 году составил около 62,7 млрд. руб. — сумма, за которую крупные технологические экономики покупают буквально в разы больше вычислений.</p> <p>На практике это означает, что покупка собственного оборудования под эксперимент зачастую экономически нерациональна: один ускоритель уровня NVIDIA H200 стоит <nobr>30-40 тыс.</nobr> долл., а полноценный сервер с восемью GPU — 300 тыс. долл. и выше, при том что жизненный цикл карты — всего <nobr>2-3 года.</nobr> Компании, которые закладывают капитальные затраты на GPU в пилот, который может не взлететь, изначально закладывают в проект избыточный риск и одну из причин будущей низкой окупаемости.</p> <h3>От ROI одной нейросети — к экономике процесса</h3> <p>Ключевая ошибка, которую совершают почти все, — считать окупаемость самого ИИ-инструмента, а не изменения, которое он должен принести бизнесу. Исключение — ситуация, когда инструмент создается не для внутреннего использования, а как продукт для продажи на рынок: тогда его собственная окупаемость действительно становится главной метрикой. Поэтому рекомендуется считать не отдельный ROI (Return on Investment, коэффициент окупаемости инвестиций) чат-бота или копилота, а влияние на сквозной процесс — от заявки клиента до закрытия сделки, — и переходить к новой модели расчета: юнит-экономике с ИИ-агентами, где единицей измерения становится не человеко-час, а количество сценариев, закрытых без участия человека.</p> <p>На практике счет выглядит так. Сначала выбирается единица процесса — например, заявка клиента, доведенная от обращения до решения, — и фиксируется ее сегодняшняя стоимость: сумма человеко-часов, инструментов и накладных расходов, деленная на число закрытых единиц за период. Дальше внедряется ИИ-агент, и считается новая стоимость единицы — расходы на инфраструктуру и лицензии (или расходы на подписку или токены) плюс время сотрудников, которое еще нужно на контроль и разбор исключений. Разница до и после, умноженная на объем процесса, и есть реальная экономика проекта, а не абстрактный процент высвобожденного времени. Отдельно стоит следить за долей сценариев, закрытых без участия человека: если она растет от месяца к месяцу, изменение действительно масштабируется.</p> <h3>Что делать прямо сейчас</h3> <p>Универсального рецепта нет, но есть несколько работающих принципов.</p> <ul> <li><strong>Считать метрику до старта, а не после. </strong>Пропишите одну фразу с цифрой и сроком — например, «сократить время обработки заявки с 4 часов до 40 минут за 3 месяца», и отдельно укажите, в каком экономическом эффекте это должно выразиться: например, в снижении затрат на найм дополнительных сотрудников, росте лояльности клиентов или увеличении среднего чека. Назначьте человека, который отвечает именно за эти показатели, а не за факт запуска проекта.</li> <li><strong>Начинать с малого и наращивать масштаб. </strong>Берите один конкретный процесс, а не весь отдел целиком, и давайте пилоту <nobr>4-6</nobr> недель на одной команде. Если показатель из первого пункта сдвинулся — расширяйте на соседние процессы, если нет — меняйте гипотезу, а не бюджет.</li> <li><strong>Заниматься данными и процессами, а не только моделью.</strong> Перед запуском проверьте на практике: сможет ли сотрудник за один день найти все данные, нужные для этого сценария, в одном месте, а не в трех разных системах и переписке. Если нет — сначала наведите порядок здесь, а не в выборе модели или ИИ-инструментов.</li> <li><strong>Работать с командой, а не только с технологией. </strong>Назначьте внутри команды человека, который отвечает за процесс, и обсудите с сотрудниками до запуска, какие задачи берет на себя ИИ и что остается за ними: это снимает страх замены и превращает пилот в общий эксперимент, а не в решение, спущенное сверху.</li> <li><strong>Не привязывать пилот к покупке оборудования.</strong> Один из вариантов — арендовать готовую инфраструктуру с почасовой оплатой: специализированные ИИ-платформы уже дают доступ и к GPU-серверам, и к готовым инференс-движкам, и к инструментам для разработки и автоматизации без необходимости собирать всё самостоятельно. Так эксперимент можно закрыть без потерь, если гипотеза не подтвердится, или быстро масштабировать, если она сработала.</li> </ul> <p>Наконец, стоит возвращаться к проекту не только на старте, а регулярно: сверять метрики каждые несколько месяцев и честно решать, масштабировать решение, дорабатывать или закрывать проект, а не держать его в статусе вечного пилота. И, главное, считать не окупаемость нейросети саму по себе, а то, как она меняет весь процесс целиком, — именно здесь чаще всего и находится реальная экономика, которую пропускают 70% руководителей, разочарованных в ИИ сегодня.</p> <p> #IMAGE_235378#</p> Компании продолжают вкладывать миллионы в нейросети, но всё чаще признают: результата нет. Разбираемся, почему пилоты … article Евгений Мартынов, директор по информационным технологиям Рег.облака https://www.itweek.ru/themes/detail.php?ID=235369 Thu, 20 Aug 2026 00:00:00 +0300 <p><em>Организации должны переосмыслить не только то, что они документируют, но и то, как они структурируют, поддерживают и представляют эти знания, чтобы автоматизированные системы могли надежно их использовать, считают опрошенные порталом </em><em>InformationWeek</em> <em>эксперты.</em></p> <p>Проблема клиента с предоставленной ему услугой передается агенту искусственного интеллекта после первоначального общения с чат-ботом. Агент проверяет официальную документацию, в которой четко указано, что в ситуациях такого типа применяется политика A — так что именно эту политику агент применяет и здесь.</p> <p>Это довольно распространенная ситуация, с которой регулярно сталкиваются многие предприятия. Кроме того, многие компании надеются, что использование ИИ-агента может повысить производительность.</p> <p>Однако такого повышения производительности не произойдет, если корпоративная база знаний, на которую опирается агент, будет неполной, неверной или устаревшей. Например, в приведенном выше сценарии представьте, что отдел продаж в течение нескольких месяцев уже придерживается политики В, но не обновил официальную документацию. У них может быть некий документ, объясняющий это изменение и новую политику, но он невидим для агентов ИИ, если не является частью базы знаний, к которой они могут получить доступ.</p> <p>В результате агент уверенно принимает неверное решение для данного клиента. Однако это не ошибка агента, а недостаток системы организационных знаний. Агенты ИИ не создают проблем со знаниями, но они выявляют проблемы, с которыми сталкиваются организации.</p> <h3>Готовность к использованию людьми не означает готовность к использованию ИИ</h3> <p>Часто организации полагают, что самой большой проблемой при переходе агентов ИИ от пилотов к производству является совершенствование самой модели. Но более серьезное препятствие часто носит более приземленный характер, говорит Кубер Шарма, старший директор UiPath по маркетингу продуктов для корпоративного ИИ и автоматизации. «Разрыв, который я чаще всего наблюдаю между пилотом и производственным внедрением ИИ-агентов, заключается не в модели. Дело в знаниях», — поясняет он. Организации разрабатывают ИИ-агентов для действий на основе документации, но затем обнаруживают, что документация не была для этого подготовлена. Вместо этого, по словам Шармы, она был создана для людей, которые могут читать между строк, консультироваться с коллегой или применять контекст.</p> <p>За время своего существования организация тратит значительное количество времени и энергии на написание документации для сотрудников: руководств по интранету, внутренних вики, документов о политиках, соглашений об обслуживании клиентов, брошюр о продукции и т. д. Какими бы важными они ни были, эти документы часто бывают неполными. Например, документ может еще не быть обновлен, чтобы отразить новую политику или процедуру или изменения в отраслевых или государственных нормативных актах.</p> <p>Когда люди используют эту документацию для поддержки своей работы, они могут выявить пробелы или несоответствия и предоставить важный контекст для их устранения. Интерпретируя неоднозначность и консультируясь с коллегами, они могут найти информацию, которую документация не охватывает, или решить, что конкретный документ больше не актуален.</p> <p>Но по мере того, как организации заменяют или дополняют агентами ИИ рабочую деятельность, осуществляемую людьми, они все больше сталкиваются с проблемами из-за неоднозначности документации. ИИ не способен обеспечить контекст или интерпретацию неполных баз знаний, которые могут обеспечить люди, и это приводит к проблемам, когда агенты сталкиваются с противоречивыми политиками, использованием электронной почты или чата в качестве документации, недокументированными исключениями или крайними случаями, дублированием документации и устаревшими практиками.</p> <p>Даже если документация точна, ее формат может стать препятствием. Файлы, хранящиеся в формате PDF, в наборах слайдов, графических материалах или специализированных учебных пакетах, могут содержать ценные институциональные знания, но без их дополнительной доработки агенты ИИ не смогут их анализировать и строить свои действия на их основе.</p> <p>Чтобы добиться успеха, агентам ИИ требуется четкая организационная память, а не институциональная интуиция и неполная документация.</p> <h3>Институциональные знания выходят за рамки официальных документов</h3> <p>Для некоторых организаций обновление официальной документации может ограничиваться обновлением нескольких ключевых PDF-файлов. Это важно, но база знаний предприятия включает в себя гораздо более широкий спектр документов и информации. Утверждения, решения, исключения, пути эскалации, бизнес-контекст, эволюция политик и неформальные практики — все это также является институциональной информацией, даже если она не отражена в официальной документации.</p> <p>Чтобы сделать институциональные знания доступными для агентов ИИ, часто требуется нечто большее, чем просто указать им на существующие файлы. По словам Джеймса Крэнвелла, руководителя отдела продуктов компании 5app, бóльшая часть корпоративного контента была создана для людей, а не для систем ИИ. Часто специалисты организации в предметной области загружают свои знания в документы Word, наборы слайдов, графики или PDF-файлы, иногда используя специфический для компании жаргон, сокращения и аббревиатуры, которые агентам ИИ трудно интерпретировать. Поэтому по мере того, как организации внедряют все больше агентов ИИ, стандартизация и структурирование их ресурсов знаний становится все более важной задачей.</p> <p>Крэнвелл не понаслышке знаком с этой проблемой. Недавно его команда создала ИИ-агент, способный анализировать пакеты электронного обучения SCORM, чтобы пользователи могли переходить к определенному разделу курса, а не извлекать сам файл курса. Этот опыт подтверждает, что организациям часто приходится адаптировать свои существующие ресурсы знаний, прежде чем агенты ИИ смогут эффективно их использовать.</p> <p>Успешное включение других источников институциональных знаний в базу знаний, используемую агентами ИИ, гарантирует, что эти агенты смогут более успешно интегрироваться в рабочие процессы предприятия. Чем больше у агента будет доступа к политикам, процедурам и другой информации, на основе которой он принимает решения, тем более информированными и точными будут эти решения, и тем лучше агент сможет не просто извлекать информацию, но и продуктивно применять ее на практике.</p> <p>По словам Шармы, знания, необходимые для работы агента, должны быть не только всеобъемлющи, но и конкретны. Не надейтесь на то, что существующий организационный контекст будет ему понятен, советует он. Вместо этого в документах должно быть четко указано, что они охватывают, а что нет, кому они принадлежат и когда они в последний раз проверялись и валидировались. Такой уровень конкретики помогает агентам ИИ отличать авторитетную информацию от устаревших или неполных рекомендаций.</p> <h3>Когда институциональные знания устаревают</h3> <p>Все большее число организаций полагаются на ИИ-агентов, которые берут на себя работу, ранее выполнявшуюся людьми. По данным McKinsey, 88% организаций в настоящее время используют ИИ для выполнения по крайней мере одной бизнес-функции, по сравнению с 78% годом ранее. И, согласно PwC, 79% опрошенных говорят, что агенты ИИ уже внедряются на их рабочих местах.</p> <p>По мере того как эти агенты будут становиться все более распространенными, будут возникать и проблемы, связанные с использованием ими устаревшей, неполной или неверной базы знаний. Когда это происходит, проблема выходит за привычные рамки: если сотрудник сбит с толку документацией, с которой он знакомится, то он может, по крайней мере, обсудить это с коллегой или использовать для интерпретации свои суждения и прошлый опыт. Неэффективные или неправильные решения, принимаемые агентами ИИ из-за плохой документации, приводят к неправильной маршрутизации, неправильным утверждениям или отказам, несогласованному взаимодействию с клиентами и, возможно, тысячам автоматизированных действий, которые не должны были выполняться.</p> <p>Как только агент начинает действовать на основе неполной информации, возникают вопросы подотчетности, что делает управление особенно важным. Организации, которые успешно справляются с этой задачей, рассматривают управление знаниями не как документирование, а как часть операционной модели агента ИИ, говорит Шарма. Когда агент выдает неверный результат, команды должны знать, кому принадлежат знания, лежащие в его основе, когда они проверялись в последний раз и почему агент полагается на них.</p> <p>Надежное управление базой знаний, на основе которой принимаются агентные решения, может смягчить некоторые из этих проблем. Организациям следует прояснить ряд вопросов, касающихся информации, которую агенты ИИ используют для принятия решений:</p> <ul> <li> Кому принадлежат данные знания?</li> <li> Кто обновляет их? Как часто?</li> <li> Кто рассматривает и утверждает изменения?</li> <li> Когда документ или его часть устаревают, кто и как их удаляет?</li> <li> Когда официальная документация меняется, кто проводит аудит агентов ИИ, чтобы убедиться в понимании ими изменений?</li> </ul> <p>Без этих ответов организации рискуют разработать системы, автоматизирующие принятие неверных решений. «Агент уверенно выдает неверный ответ, основываясь на неверном источнике. Это хуже, чем отсутствие ответа. Это сбой системы управления, одобренный ИИ», — сказал Шарма.</p> <p>Ответы на эти вопросы и понимание всеми заинтересованными лицами важности согласования этих ответов с базой знаний компании помогут избежать проблем с документацией при внедрении ИИ-агентов. Цель состоит в том, чтобы официальные знания, подготовленные для агентов, всегда были актуальными, четко сформулированными, авторитетными, структурированными, управляемыми и объяснимыми.</p> <h3>Убедитесь, что корпоративный источник истины готов к использованию ИИ</h3> <p>Организации могут беспокоиться о том, что ИИ-агент не сможет должным образом разобраться в их бизнесе, но первым шагом должно стать обеспечение понимания бизнесом самого себя.</p> <p>Агенты ИИ не могут восполнить недостающий контекст или информацию так, как это могут сделать сотрудники. Они не могут согласовать противоречивые документы, вывести неписаные правила или признать, что «все знают», что процедура изменилась. Они принимают решения на основе институциональных знаний, предоставляемых организациями, и выявляют все слабые места или пробелы в этих знаниях. Предприятие, осознающее недостаточность своей базы знаний, получает неожиданную выгоду от того, что ему приходится сталкиваться с накопившимися несоответствиями и исправлять их, а также создавать систему управления, которая позволит ему продвигаться вперед с использованием более совершенной модели поддержания этих знаний.</p> <p>Подготовка институциональных знаний для ИИ — это задача управления контентом в дополнение к управленческому процессу. Организациям все чаще приходится переосмысливать не только то, что они документируют, но и то, как они структурируют, поддерживают и представляют эти знания, чтобы автоматизированные системы могли надежно их использовать.</p> Организации должны переосмыслить не только то, что они документируют, но и то, как они структурируют … article https://www.itweek.ru/themes/detail.php?ID=235376 Wed, 19 Aug 2026 14:24:22 +0300 <p>Компания «Базис» (входит в ГК «РТК-ЦОД») объявила о выходе обновления Basis Dynamix Cloud Control 5.6 — решения для управления кластерами, расположенными в разных ЦОД, а также мажорной версии 3.0 встроенного модуля для развертывания сервисов в облаке Basis Automation Studio. Ключевыми изменениями релизов стали переработанная ролевая модель доступа пользователей, обновленная архитектура развертывания сервисов, новые инструменты управления ресурсами и углубление интеграции платформы с другими решениями экосистемы «Базис».</p> <p>Платформа Basis Dynamix Cloud Control предназначена для управления через единый портал частными и публичными облаками, построенными на базе различных платформ виртуализации — Basis Dynamix Enterprise, Basis Dynamix Standard, VMware vSphere и РУСТЭК.</p> <p>На смену встроенной ролевой модели в Basis Dynamix Cloud Control 5.6 пришла новая гибкая модель разграничения доступа, что позволяет администратору назначать права в точном соответствии с полномочиями пользователей. Переход на новую модель выполняется автоматически при обновлении инсталляции продукта: права пользователей мигрируют в новую структуру без ручной перенастройки. Вместе с новой моделью администраторы получили более удобные инструменты для работы с ролями, включая их клонирование — при копировании переносятся уровни доступа, права доступа и правила фильтрации исходной роли.</p> <p>В новой модели предусмотрены встроенные роли по умолчанию, готовые к использованию без дополнительной настройки. Поддерживается управление жизненным циклом пользовательских ролей для точечного предоставления необходимых прав на различные объекты. При архивировании учетной записи вместе с объектами доступа снимаются все связанные роли.</p> <p>В релизе 5.6 была существенно расширена функциональность сегментов Basis Dynamix Standard. Пользователям получили новые возможности, ранее уже доступные в других сегментах: поддержка сетей, роутеров, балансировщиков нагрузки, профилей безопасности и внешних систем хранения данных. Логика построения виртуальной сети стала более гибкой: маршрут по умолчанию на роутере создается автоматически, если пользователь не задал собственный. При этом в конфигурациях с несколькими роутерами разрешены удаление последнего порта роутера и отключение сети от роутера.</p> <p>Для облачных сегментов Basis Dynamix Enterprise в новом релизе была добавлена поддержка сервиса резервного копирования на базе Basis Virtual Protect — решения компании «Базис» для управления жизненным циклом резервных копий виртуальных машин. Администратор может подключить настроенный сервис к одному или нескольким сегментам Basis Dynamix Enterprise, для которых должны быть доступны инструменты резервного копирования. </p> <p>Автоматическая синхронизация изменений виртуальной инфраструктуры сегментов Basis Dynamix Enterprise дополнена операциями со снапшотами — созданием, восстановлением и удалением. Синхронизация в фоновом режиме помогает администратору поддерживать согласованность виртуальной инфраструктуры между платформой виртуализации и решением Basis Dynamix Cloud Control, что важно, например, при выполнении сервисных действий с серверами и дисками.</p> <p>Наконец, реализовано взаимодействие Basis Dynamix Cloud Control с платформой виртуализации Basis Dynamix Enterprise через учетную запись Basis Virtual Security — решения компании «Базис», предназначенного для защиты виртуальной инфраструктуры. </p> <p>В новом релизе Basis Dynamix Cloud Control особое внимание было уделено контролю над объёмом предоставляемых ресурсов, обеспечению предсказуемого потребления и оптимизации затрат. На уровне виртуального центра обработки данных (ВЦОД) введены лимиты и механизм согласования выделяемых ресурсов, дающие администраторам предсказуемый контроль над потреблением в рамках отдельных ВЦОД.</p> <p>Для облачных сегментов на платформе Basis Dynamix Enterprise реализовано управление коэффициентом и режимом переподписки виртуальных процессоров (vCPU), что позволяет администратору гибко регулировать плотность размещения виртуальных машин. Коэффициент переподписки определяет, сколько ядер vCPU будет приходиться на одно ядро физического процессора и отдельно указывается для каждого физического сервера. При отсутствии ограничений Basis Dynamix Cloud Control будет использовать для запуска виртуальных серверов любые узлы с достаточными ресурсами. При включенном режиме строгой переподписки виртуальные серверы не будут запускаться на физических узлах, если у тех недостаточно свободных ядер vCPU.</p> <p>Basis Automation Studio — это модуль Basis Dynamix Cloud Control, который представляет собой среду автоматизации развёртывания приложений и сервисов. С его помощью администратор платформы может управлять жизненным циклом облачных сервисов, работать с шаблонами и компонентами, публиковать готовые сервисы на витрине и предлагать их пользователям.</p> <p>Для Basis Automation Studio 3.0 одним из наиболее важных изменений стала смена архитектуры — модуль переведен на отказоустойчивую архитектуру в кластере Kubernetes. Компоненты Basis Automation Studio, включая контейнеры оркестратора и базу данных, работают в конфигурации высокой доступности: при выходе из строя отдельного узла нагрузка автоматически перераспределяется на оставшиеся узлы, работа платформы не прерывается. Для хранения общих данных используется распределенное отказоустойчивое хранилище, для базы данных — управление средствами оператора Kubernetes.</p> <p>Наряду с отказоустойчивостью появилось горизонтальное масштабирование: количество экземпляров ключевых сервисов задается при развертывании, что позволяет наращивать производительность платформы под растущую нагрузку без изменения ее архитектуры.</p> <p>Еще одним важным новшеством Basis Automation Studio 3.0 стало появление динамических провайдеров, которые предоставляют возможность создания динамических типов данных при заказе сервиса. Благодаря этому модуль может обращаться к внешним системам и возвращать в форму заказа вместо статичных полей актуальные данные, вычисляемые по пользовательским сценариям в изолированной среде выполнения.</p> <p>Динамические провайдеры отображаются на карточке домена и проекта. Внутри них дополнительно добавлен программный интерфейс управления динамическими типами провайдера для запуска пользовательских скриптов.</p> <p>Как и в Basis Dynamix Cloud Control, в модуле Basis Automation Studio 3.0 была переработана ролевая модель. Права доступа теперь задаются на уровне отдельных API-методов, сгруппированных по управляемым сущностям. Каждая роль привязана к области видимости: платформе, домену или проекту, — которая определяет предельный набор доступных действий. Пользователь привязывается к одной области видимости, но ему можно назначить несколько ролей, в том числе стандартных — в таком случае права доступа суммируются.</p> <p>«Приоритетными направлениями развития нашей облачной платформы Basis Dynamix Cloud Control остаются расширение возможностей управления виртуальной инфраструктурой и повышение совместимости облачного решения с другими продуктами экосистемы „Базиса“. В релизе 5.6 мы сделали несколько значительных шагов в обоих направлениях. Что касается нашего решения для управления облачными сервисами, перевод Basis Automation Studio на новую k8s-архитектуру позволит перемещать рабочую нагрузку без остановки работы продукта. Кроме того, для удобства работы с модулем мы внедрили динамические провайдеры и расширили возможности графического интерфейса платформы», — отметил Дмитрий Сорокин, технический директор компании «Базис».</p> Компания «Базис» (входит в ГК «РТК-ЦОД») объявила о выходе обновления Basis Dynamix Cloud Control 5.6 — … message https://www.itweek.ru/themes/detail.php?ID=235375 Wed, 19 Aug 2026 14:20:12 +0300 <p>Компания «Индид» выпустила новую версию Indeed Identity Threat Detection and Response (Indeed ITDR) 2.2 — продукта для своевременного выявления и реагирования на угрозы, связанные с компрометацией айдентити. Обновление расширяет сценарии применения многофакторной аутентификации, улучшает пользовательский опыт при работе в консоли администрирования и упрощает развертывание решения в корпоративной инфраструктуре.</p> <p>Сегодня для защиты корпоративной инфраструктуры недостаточно контролировать только доступ пользователя в систему. Не менее важно отслеживать дальнейшую активность учетных записей и своевременно реагировать на подозрительные действия. Эти возможности получили развитие в новой версии Indeed ITDR 2.2.</p> <p>Одно из ключевых нововведений в Indeed ITDR 2.2 — подтверждение дополнительного фактора входа с помощью одноразовых паролей (OTP), основанных на времени (time-based one-time passwords, TOTP). Обновление расширяет интеграцию с Indeed Access Manager и позволяет использовать существующую инфраструктуру аутентификации в сценариях Indeed ITDR.</p> <p>Поддержка ТOTP особенно актуальна для организаций с закрытыми инфраструктурами без доступа к внешним сетям, где использование push-уведомлений невозможно. Кроме того, пользователи могут применять сторонние приложения-аутентификаторы, поддерживающие стандарт TOTP.</p> <p>Ввод одноразового пароля выполняется через легковесное приложение, устанавливаемое на рабочих станциях под управлением Windows. Оно своевременно отображает запрос на подтверждение дополнительного фактора. В рамках дальнейшего развития продукта планируется добавить поддержку одноразовых паролей через SMS, электронную почту и физические носители.</p> <p>В версии 2.2 компания «Индид» значительно расширила возможности работы с журналом событий доступа. На странице «События» консоли администрирования появилась гибкая система фильтрации по пользователю, ресурсу, протоколу, IP-адресу и контроллеру домена. Также улучшен интерфейс фильтрации по времени возникновения события и оптимизировано хранение данных, что повышает производительность поиска.</p> <p>Обновленный интерфейс упрощает работу с Indeed ITDR и позволяет быстрее находить необходимые события при анализе подозрительной активности, расследовании инцидентов и оценке рисков безопасности. </p> <p>Другие изменения Indeed ITDR делают более удобным развертывание продукта в инфраструктурах, где интеграция с Indeed Access Manager не требуется.</p> <p>Компонент Indeed Key Server теперь можно установить на отдельный узел с помощью единого сценария установки. Это упрощает развертывание сервера в демилитаризованной зоне (DMZ) и избавляет администраторов от необходимости вручную изменять конфигурационные файлы.</p> <p>В новой версии расширен набор сценариев обнаружения атак. Indeed ITDR теперь выявляет такие техники, как Golden PAC и SAM Account Spoofing, что позволяет эффективнее обнаруживать попытки компрометации доменной инфраструктуры.</p> <p>Кроме того, улучшена совместимость с различными вариантами TLS-сертификатов, включая сертификаты LDAPS без расширения SAN, а также сертификаты с именем субъекта в формате Distinguished Name.</p> <p>«Мы последовательно улучшаем Indeed ITDR, расширяя сценарии внедрения продукта и добавляя новые возможности детектирования. Наша задача — помочь организациям своевременно реагировать на угрозы, связанные с учетными данными, не перестраивая существующую инфраструктуру. При этом для нас важно обеспечить удобство работы как для пользователей, так и для специалистов по информационной безопасности и администраторов. Последние обновления отражают наиболее частые пожелания, которые мы получаем в процессе внедрения наших продуктов», — отметил Лев Овчинников, руководитель продукта Indeed ITDR в компании «Индид».</p> Компания «Индид» выпустила новую версию Indeed Identity Threat Detection and Response (Indeed ITDR) 2.2 — продукта для … message https://www.itweek.ru/themes/detail.php?ID=235374 Wed, 19 Aug 2026 14:16:20 +0300 <p>Компания «ТризТех» представила новую версию межсетевого экрана нового поколения — PT NGFW 1.11. Главным нововведением стал встроенный Remote Access VPN (RA VPN), который позволяет организовать защищенный удаленный доступ пользователей к корпоративной сети. Кроме того, в новой версии расширены возможности маршрутизации и построения отказоустойчивых сетей, усовершенствованы управление политиками безопасности и удобство эксплуатации продукта.</p> <p>PT NGFW продолжает развиваться как единая платформа сетевой безопасности для высоконагруженных и территориально распределенных инфраструктур. Главная функция версии 1.11, Remote Access VPN, обеспечивает безопасное удаленное подключение сотрудников к внутренним ИТ-ресурсам организации непосредственно средствами межсетевого экрана, без внедрения отдельного VPN-решения. Настройка и управление параметрами RA VPN также осуществляется из единого окна PT NGFW.</p> <p>Благодаря поддержке раздельного туннелирования, через VPN можно направлять только корпоративный трафик пользователей, оставляя доступ к публичным и облачным сервисам напрямую через Интернет. Это снижает нагрузку на VPN-шлюз и каналы связи, повышая скорость и комфорт работы сотрудников. При этом трафик удаленных пользователей проходит через полный стек механизмов защиты межсетевого экрана, то есть организация может применять к удаленным подключениям те же политики безопасности, что и к сетевому взаимодействию внутри корпоративной инфраструктуры. Аутентификация удаленных пользователей происходит через RADIUS-сервер, что делает возможным не только централизованное управление правами доступа, но и применение второго фактора.</p> <p>Помимо защищенного удаленного доступа, PT NGFW 1.11 получил ряд возможностей, ориентированных на потребности крупных компаний с высоконагруженными и распределенными сетями. Среди них — поддержка технологии ECMP (Equal Cost Multi-Path), которая позволяет одновременно использовать несколько равнозначных маршрутов для передачи трафика. Это помогает эффективнее использовать пропускную способность каналов связи и сохранять передачу трафика при отказе одного из них.</p> <p>Кроме того, PT NGFW 1.11 расширяет сценарии подключения удаленных площадок и список совместимых сетевых устройств за счет возможности создания туннелей GRE и GRE over IPsec, в том числе с применением динамической маршрутизации.</p> <p>Еще одной возможностью, востребованной в высокопроизводительных сетях и центрах обработки данных, стала поддержка Jumbo Frames — увеличенного размера Ethernet-кадров. Благодаря этому можно передавать большие объемы данных меньшим количеством пакетов, снижая накладные расходы на их обработку. Максимальный размер пакета можно настраивать как для всего устройства, так и для отдельных интерфейсов. В совокупности новые возможности маршрутизации, туннелирования и работы с трафиком позволяют адаптировать PT NGFW к более широкому спектру архитектур крупных корпоративных сетей.</p> <p>В новой версии также появились функции, направленные на повышение удобства повседневной эксплуатации PT NGFW. В частности, добавлена поддержка подстановочных символов (wildcards) при настройке URL-фильтрации, благодаря чему весь процесс становится для администраторов быстрее и проще. Управление маршрутизацией тоже стало комфортнее: пользователь может настроить профили проверки доступности узлов, и в случае необходимости трафик автоматически, без ручного вмешательства пользователя переключится на резервный канал.</p> <p>«Мы продолжаем развивать PT NGFW с учетом обратной связи от заказчиков и их ежедневного опыта эксплуатации продукта. Для нас важно, чтобы межсетевой экран одинаково эффективно решал и стратегические задачи, такие как организация защищенного удаленного доступа или построение масштабной отказоустойчивой сетевой архитектуры, так и повседневные задачи администратора — от настройки политик до диагностики и работы с журналами», — отметил Антон Кузнецов, CPO компании «ТризТех».</p> Компания «ТризТех» представила новую версию межсетевого экрана нового поколения — PT NGFW 1.11. Главным нововведением … message https://www.itweek.ru/themes/detail.php?ID=235373 Wed, 19 Aug 2026 14:10:57 +0300 <p>С 1 сентября 2026 года электронные транспортные накладные (ЭТрН) становятся обязательными для большинства перевозок. Для транспортных компаний это означает переход от бумажного документооборота к работе с электронными документами непосредственно на маршруте. Saby TMS позволяет оформлять и обрабатывать электронные транспортные документы и поддерживает удобный сценарий их подписания — с помощью Рутокен ЭЦП 3.0 NFC. Устройство Рутокен разработано и выпускается компанией «Актив».</p> <p>Раньше сотруднику, которому необходимо подписать ЭТрН КЭП, требовался компьютер или специальный переходник для подключения токена к смартфону. С Рутокен ЭЦП 3.0 NFC достаточно иметь смартфон с NFC и мобильное приложение Saby TMS.</p> <p>Сотрудник прикладывает Рутокен к смартфону и подписание документа происходит «на борту» устройства Рутокен, без копирования ключа подписи в память мобильного устройства. Такой сценарий особенно удобен водителям и экспедиторам, которым важно работать с документами прямо на маршруте, а не возвращаться в офис.</p> <p>«Для перевозчика важно, чтобы электронный документооборот не привязывал водителя к компьютеру или офису. Все действия с ЭТрН — от получения документа до его подписания — должны выполняться там, где происходит перевозка: на погрузке, выгрузке или в пути. Поддержка Рутокен ЭЦП 3.0 NFC в Saby TMS дает компаниям еще один удобный способ организовать такой мобильный сценарий и при этом использовать привычную КЭП», — отметил Денис Малышев, руководитель направления автоматизации логистики Saby TMS.</p> <p>«Мы видим тренд на мобильное подписание ЭТрН с использованием защищенных ключевых носителей. Рутокен ЭЦП 3.0 NFC позволяет перенести привычный сценарий работы с КЭП со стационарного компьютера на смартфон: достаточно приложить Рутокен к мобильному устройству с NFC для подписания документа. Совместимость с Saby TMS позволит использовать этот подход непосредственно в процессах грузоперевозок и дать бизнесу большую гибкость без компромиссов в безопасности», — поделился Анфимов Павел, заместитель директора по управлению продуктами, компания «Актив».</p> <p>В Saby TMS транспортные компании ведут основные документы — транспортные накладные, путевые листы, заказы на перевозку — прямо во время рейса.</p> <p>Для подписания через NFC понадобятся: смартфон с поддержкой NFC (iOS или Android), мобильное приложение Saby TMS и Рутокен ЭЦП 3.0 NFC с сертификатом и ключами электронной подписи.</p> С 1 сентября 2026 года электронные транспортные накладные (ЭТрН) становятся обязательными для большинства перевозок … message https://www.itweek.ru/themes/detail.php?ID=235372 Wed, 19 Aug 2026 13:09:40 +0300 <p><em>MWS Cloud (входит в МТС Web Services) проанализировала требования к вычислительной инфраструктуре для запуска ведущих мировых и российских больших языковых моделей. По оценке компании, средняя стоимость минимального набора ускорителей Nvidia для запуска одной модели выросла с 13,7 млн. рублей в 2025 году до 38,8 млн. рублей в 2026 году — в 2,8 раза.</em></p> <p>В анализ вошли популярные открытые модели, выпущенные весной и летом соответствующего года. Для 2025 года рассматривались Kimi K2, gpt-oss-120b, Gemma 3 27B, GLM-4.5V, Qwen3 235B и российская Cotype Pro 2. Для 2026 года — Kimi K3, Qwen3.5 397B, DeepSeek-V4-Pro, DeepSeek-V4-Flash, GLM-5.2, Gemma 4 и Cotype Pro 3.</p> <p>Расчёт сделан для минимального количества видеокарт, необходимого для запуска модели и обработки одного запроса максимального заявленного размера. В стоимость включены серверы с GPU и коммутаторы к ним.</p> <table> <tbody> <tr> <td> <p><strong>Год</strong></p> </td> <td> <p><strong>Наиболее популярный GPU</strong></p> </td> <td> <p><strong>Другие GPU</strong></p> </td> </tr> <tr> <td> <p>2025</p> </td> <td> <p>H100 — для трёх из шести моделей</p> </td> <td> <p>H200 — для двух моделей; A100 — для одной</p> </td> </tr> <tr> <td> <p>2026</p> </td> <td> <p>H200 — для трёх из семи моделей</p> </td> <td> <p>B300 — для двух моделей; H100 и A100 — ещё для двух</p> </td> </tr> </tbody> </table> <p><strong>Рейтинг моделей по стоимости запуска в 2025 году</strong></p> <table> <tbody> <tr> <td> <p><strong>Место</strong></p> </td> <td> <p><strong>Модель</strong></p> </td> <td> <p><strong>Количество параметров</strong></p> </td> <td> <p><strong>Минимальная конфигурация</strong></p> </td> <td> <p><strong>Стоимость</strong></p> </td> </tr> <tr> <td> <p>1</p> </td> <td> <p>Kimi K2</p> </td> <td> <p>1 трлн (32 млрд. активных)</p> </td> <td> <p>8 × H200 141 Гб</p> </td> <td> <p>примерно 35 млн. рублей</p> </td> </tr> <tr> <td> <p>2</p> </td> <td> <p>Qwen3</p> </td> <td> <p>235 млрд. (22 млрд. активных)</p> </td> <td> <p>4 × H200 141 Гб</p> </td> <td> <p>примерно 18 млн. рублей</p> </td> </tr> <tr> <td> <p>3</p> </td> <td> <p>GLM-4.5V</p> </td> <td> <p>106 млрд. (12 млрд. активных)</p> </td> <td> <p>минимум 4 × H100 80 Гб</p> </td> <td> <p>примерно 15 млн. рублей</p> </td> </tr> <tr> <td> <p>4</p> </td> <td> <p>Gemma 3</p> </td> <td> <p>27 млрд</p> </td> <td> <p>2 × H100 80 Гб</p> </td> <td> <p>примерно 7,5 млн. рублей</p> </td> </tr> <tr> <td> <p>5</p> </td> <td> <p>gpt-oss</p> </td> <td> <p>117 млрд. (5,1 млрд. активных)</p> </td> <td> <p>1 × H100 80 Гб</p> </td> <td> <p>более 3,5 млн. рублей</p> </td> </tr> <tr> <td> <p>6</p> </td> <td> <p>Cotype Pro 2</p> </td> <td> <p>32 млрд</p> </td> <td> <p>1 × A100 80 Гб</p> </td> <td> <p>примерно 3 млн. рублей</p> </td> </tr> </tbody> </table> <p><strong>Рейтинг моделей по стоимости запуска в 2026 году</strong></p> <table> <tbody> <tr> <td> <p><strong>Место</strong></p> </td> <td> <p><strong>Модель</strong></p> </td> <td> <p><strong>Количество параметров</strong></p> </td> <td> <p><strong>Минимальная конфигурация</strong></p> </td> <td> <p><strong>Стоимость</strong></p> </td> </tr> <tr> <td> <p>1</p> </td> <td> <p>Kimi K3</p> </td> <td> <p>2,8 трлн (104 млрд. активных)</p> </td> <td> <p>8 × B300 288 Гб</p> </td> <td> <p>примерно 80 млн. рублей</p> </td> </tr> <tr> <td> <p>2</p> </td> <td> <p>Qwen3.5</p> </td> <td> <p>397 млрд. (17 млрд. активных)</p> </td> <td> <p>8 × H200 141 Гб</p> </td> <td> <p>примерно 55 млн. рублей</p> </td> </tr> <tr> <td> <p>2</p> </td> <td> <p>DeepSeek-V4-Pro</p> </td> <td> <p>1,6 трлн (49 млрд. активных)</p> </td> <td> <p>8 × H200 141 Гб</p> </td> <td> <p>примерно 55 млн. рублей</p> </td> </tr> <tr> <td> <p>2</p> </td> <td> <p>GLM-5.2</p> </td> <td> <p>744 млрд. (около 40 млрд. активных)</p> </td> <td> <p>8 × H200 141 Гб</p> </td> <td> <p>примерно 55 млн. рублей</p> </td> </tr> <tr> <td> <p>5</p> </td> <td> <p>DeepSeek-V4-Flash</p> </td> <td> <p>284 млрд. (13 млрд. активных)</p> </td> <td> <p>1 × B300 288 Гб</p> </td> <td> <p>примерно 10 млн. рублей</p> </td> </tr> <tr> <td> <p>6</p> </td> <td> <p>Gemma 4</p> </td> <td> <p>31 млрд</p> </td> <td> <p>2 × H100 80 Гб</p> </td> <td> <p>примерно 7,5 млн. рублей</p> </td> </tr> <tr> <td> <p>7</p> </td> <td> <p>Cotype Pro 3</p> </td> <td> <p>27 млрд</p> </td> <td> <p>1 × A100 80 Гб</p> </td> <td> <p>примерно 3 млн. рублей</p> </td> </tr> </tbody> </table> <p>Новые LLM становятся более мощными: они лучше справляются со сложными задачами и могут учитывать больше информации в одном запросе. Однако для этого им требуется больше памяти и более производительные GPU. При этом растёт и стоимость самих видеокарт, поэтому развёртывание моделей обходится дороже.</p> <p>Отдельно MWS Cloud оценила возможные конфигурации на китайских ускорителях Huawei Ascend 910B. Возможность запуска на них подтверждена не для всех рассмотренных LLM: в выборке 2025 года подтверждение есть для трёх из шести моделей, в 2026 году — для пяти из семи.</p> <p>Среди моделей с подтверждённой или экспериментально подтверждённой поддержкой Huawei в 2025 году в среднем требовалось 10,7 ускорителя Ascend 910B, а в 2026 году — 13,6. Официальной цены на данные GPU нет, но, по оценкам, она может составлять от половины до двух третей стоимости сопоставимых GPU Nvidia.</p> <p>«Цены на GPU в России во многом зависят от мирового рынка: глобальная гонка в области ИИ увеличивает спрос на вычислительные мощности и поддерживает рост стоимости ускорителей. По данным исследования MWS Cloud, 47% респондентов ожидают удорожания GPU-ресурсов в ближайшие 12 месяцев, а 45% считают, что их значение для бизнеса будет расти. Развёртывать крупные модели на собственной инфраструктуре становится дороже, однако единого ценового предела, после которого рынок потеряет интерес к ИИ, нет: если покупка оборудования перестаёт окупаться, компании выбирают более компактные модели, оптимизируют вычисления или переходят в облако, где можно платить только за фактически используемые мощности. Один из индикаторов этого сдвига — рост облачного потребления ИИ-моделей: по оценке MWS Cloud, в первом полугодии 2026 года потребление китайских LLM российскими компаниями на платформах MWS GPT Model Hub и MWS GPT более чем в 11 раз превысило показатель за весь 2025 год», — отметил генеральный директор MWS Павел Воронин</p> MWS Cloud (входит в МТС Web Services) проанализировала требования к вычислительной инфраструктуре для запуска ведущих … message https://www.itweek.ru/themes/detail.php?ID=235371 Wed, 19 Aug 2026 11:57:58 +0300 <p><em>Географическая переориентация российских компаний-разработчиков ПО с недружественного на дружественный мир, наблюдаемая в последние годы, в 2025 году имела продолжение — снова выявлено очевидное снижение продаж на рынках недружественных стран. А вот столь же очевидного увеличения реализации продуктов и услуг в дружественных странах пока не видно. В то же время, на переохлажденном российском ИТ-рынке с возросшей налоговой нагрузкой компаниям становится слишком тесно. В такой ситуации логично предположить их движение в тех направлениях, которые открыты для международной экспансии.</em></p> <p>Направление в сторону недружественных стран сложно назвать перспективным. При всем желании российских компаний-разработчиков ПО сохранить продажи в Европе и Северной Америке, западные политики без устали работают над созданием непреодолимых для них препятствий. Многие их задумки реализуются, хотя при этом западные страны лишают свои предприятия и граждан доступа к качественным услугам и продуктам.</p> <p>По итогам 2025 года продажи отечественных софтверных компаний на рынках недружественных стран сократились примерно на 40% до ₽70 млрд. Сейчас страны Европы и США обеспечивают 2,4% совокупной выручки всей индустрии разработки ПО. При этом доля компаний, имеющих продажи в недружественных странах, намного больше — 14,3% от всех опрошенных компаний. Для Европы этот показатель равен 9,9%, а для США и Канады — 8,8% (в 2024 г. было 14,2% и 11,4% соответственно).</p> <p>Однако дальнейший уход с рынков западных стран столь же массово, как в предыдущие годы, компании не планируют. Сохранить присутствие на рынке Северной Америки в 2026 году рассчитывает 9,2%, что чуть больше, чем было по итогам 2025 года. Не исключено, что шансы остаться на одном из крупнейших рынков мира повысились, когда респонденты увидели потепление отношений между Россией и США после встречи в Анкоридже. Такой же эффект произвела в свое время победа Дональда Трампа на американских президентских выборах. Он вступил в должность в январе 2025 года, и вскоре стало известно о планах его встречи с Президентом РФ В.В. Путиным, которая состоялась в августе. С Европой все было хуже, ведь от них шли сигналы только на еще больший разрыв.</p> <p>Продажи в дружественных странах дальнего зарубежья в 2025 году в рублях не изменились и составили примерно ₽170 млрд. При этом доля этих продаж в совокупной выручке софтверных компаний упала — с 6,8% до 6,1%. Укрепление российской национальной валюты по отношению к доллару не позволило нарастить выручку в рублевом выражении. Однако в долларовом выражении продажи в дружественные страны все же увеличились примерно на 10%. Это касается как всего экспорта софтверных компаний, так и их продаж на рынках дружественных стран.</p> <p>Ближнее зарубежье обеспечило по итогам 2025 года 10,2% совокупной выручки российских разработчиков ПО. Годом ранее его доля была чуть меньше — 9,8%. Продажи на постсоветском пространстве выросли примерно на <nobr>18-19%</nobr> в рублевом выражении (до ₽285 млрд) и примерно на 32% в долларах ($3,4 млрд). Указали на наличие продаж в этих странах 36,1% опрошенных компаний. На данный момент Ближнее зарубежье обеспечивает более половины экспорта российских софтверных компаний.</p> <p><strong>Распределение продаж российских софтверных компаний по группам рынков в <nobr>2021-2025</nobr> годы</strong></p> <table> <tbody> <tr> <td> </td> <td> <p>2021</p> </td> <td> <p>2022</p> </td> <td> <p>2023</p> </td> <td> <p>2024</p> </td> <td> <p>2025</p> </td> </tr> <tr> <td> <p>Россия</p> </td> <td> <p>52,5%</p> </td> <td> <p>65,6%</p> </td> <td> <p>76,2%</p> </td> <td> <p>78,6%</p> </td> <td> <p>81,3%</p> </td> </tr> <tr> <td> <p>Ближнее зарубежье</p> </td> <td> <p>13,45%</p> </td> <td> <p>11,5%</p> </td> <td> <p>10,2%</p> </td> <td> <p>9,8%</p> </td> <td> <p>10,2%</p> </td> </tr> <tr> <td> <p>Россия и Ближнее зарубежье</p> </td> <td> <p>65,95% </p> </td> <td> <p>77,1%</p> </td> <td> <p>86,35%</p> </td> <td> <p>88,4%</p> </td> <td> <p>91,5%</p> </td> </tr> <tr> <td> <p>Дальнее зарубежье:</p> </td> <td colspan="5"> </td> </tr> <tr> <td> <p>— недружественные страны (до 2022 г. «Западный мир»)</p> </td> <td> <p>25,25%</p> </td> <td> <p>12,5%</p> </td> <td> <p>7,6%</p> </td> <td> <p>4,8%</p> </td> <td> <p>2,4%</p> </td> </tr> <tr> <td> <p>— дружественные страны (до 2022 г. «Новые рынки»)</p> </td> <td> <p>8,8%</p> </td> <td> <p>10,4%</p> </td> <td> <p>6,05%</p> </td> <td> <p>6,8%</p> </td> <td> <p>6,1%</p> </td> </tr> </tbody> </table> <p>Согласно прогнозу, основанному на планах опрошенных компаний, по итогам 2026 года российские софтверные компании увеличат свое присутствие с реальными продажами почти на всех рынках. Предполагается, что даже в США будут продавать свои продукты и услуг больше компаний, чем было в 2025 году. Падение присутствия российских экспортеров прогнозируется только на рынке Европы. Прогнозируя расширение географии и рост экспорта, необходимо признать, что опыт предыдущих лет показывает, что ожидания компаний относительно роста экспорта часто оказываются несколько завышенными.</p> <p><strong>Присутствие российских компаний на зарубежных рынках в 2025 году с прогнозом на 2026 год, %</strong> <strong>опрошенных компаний</strong></p> <table> <tbody> <tr> <td> </td> <td> <p>2025 г.</p> </td> <td> <p>2026 г. (прогноз)</p> </td> </tr> <tr> <td> <p>Ближнее зарубежье</p> </td> <td> <p>36,1%</p> </td> <td> <p>40,5%</p> </td> </tr> <tr> <td> <p>Казахстан</p> </td> <td> <p>22,1%</p> </td> <td> <p>25,2%</p> </td> </tr> <tr> <td> <p>Белоруссия</p> </td> <td> <p>20,7%</p> </td> <td> <p>24,8%</p> </td> </tr> <tr> <td> <p>Узбекистан</p> </td> <td> <p>15,0%</p> </td> <td> <p>18,7%</p> </td> </tr> <tr> <td> <p>Европа (без России и Ближнего зарубежья)</p> </td> <td> <p>9,9%</p> </td> <td> <p>8,5%</p> </td> </tr> <tr> <td> <p>США/Канада</p> </td> <td> <p>8,8%</p> </td> <td> <p>9,2%</p> </td> </tr> <tr> <td> <p>Южная и Восточная Азия</p> </td> <td> <p>7,5%</p> </td> <td> <p>7,8%</p> </td> </tr> <tr> <td> <p>— Китай</p> </td> <td> <p>3,1%</p> </td> <td> <p>3,4%</p> </td> </tr> <tr> <td> <p>— Индия</p> </td> <td> <p>5,4%</p> </td> <td> <p>6,1%</p> </td> </tr> <tr> <td> <p>— Вьетнам</p> </td> <td> <p>1,7%</p> </td> <td> <p>2,4%</p> </td> </tr> <tr> <td> <p>— Индонезия</p> </td> <td> <p>2,0%</p> </td> <td> <p>3,1%</p> </td> </tr> <tr> <td> <p>Ближний Восток</p> </td> <td> <p>6,5%</p> </td> <td> <p>7,8%</p> </td> </tr> <tr> <td> <p>Южная и Центральная Америка</p> </td> <td> <p>2,7%</p> </td> <td> <p>3,1%</p> </td> </tr> <tr> <td> <p>Бразилия</p> </td> <td> <p>2,0%</p> </td> <td> <p>2,4%</p> </td> </tr> <tr> <td> <p>Мексика</p> </td> <td> <p>2,0%</p> </td> <td> <p>2,0%</p> </td> </tr> <tr> <td> <p>Аргентина</p> </td> <td> <p>2,0%</p> </td> <td> <p>2,4%</p> </td> </tr> <tr> <td> <p>Африка</p> </td> <td> <p>3,1%</p> </td> <td> <p>3,7%</p> </td> </tr> <tr> <td> <p>Австралия/Новая Зеландия</p> </td> <td> <p>1,4%</p> </td> <td> <p>1,7%</p> </td> </tr> </tbody> </table> <p>Несмотря на все препятствия, по итогам 2026 г. зарубежные продажи российских софтверных компаний все же могут вырасти более чем на 10% в долларовом выражении (с учетом той выручки, которая может остаться за пределами России).</p> <p>Однако для достижения уровня мировой конкурентоспособности, требующего огромных инвестиций, доходов от российского рынка будет недостаточно, и к нему необходимо будет прибавить выручку экспорта, которая должна быть как минимум, в разы больше, чем текущий доход от зарубежных продаж. По результатам исследования РУССОФТ, в 2025 году объем зарубежных продаж составил $6,3 млрд, а по итогам 2026 г. может достигнуть $7 млрд. При имеющемся темпе роста преодолеть планку в $40 млрд. удастся не ранее 2040 года, а к этому времени нынешние ориентиры уже будут не актуальны.</p> <p>Для наращивания экспорта можно рассчитывать, в первую очередь, на рост продаж на Ближнем зарубежье. Однако, хотя потенциал этого рынка еще не исчерпан, он в любом случае не принесет десятки миллиардов долларов. Для сравнения, один только индийский рынок может обеспечить продажи на порядок больше, чем все постсоветское пространство. Перспективными для освоения являются также рынки стран АСЕАН, прежде всего — Индонезии и Вьетнама. Более активной работе на Ближнем Востоке может помешать война. Большой интерес представляют страны Латинской Америки, но транспортные расходы и риски освоения еще непознанных рынков слишком велики.</p> <p>Для обеспечения прорыва на рынках дружественных стран необходимо устранять проблемы экспортеров, вызванные повышением налоговой нагрузки, которая к тому же может и не дать дополнительных поступлений в бюджет. Необходимо также повышать эффективность государственной поддержки экспорта ПО и услуг по его разработке, которую сейчас сложно признать высокой. До сих пор он не является приоритетом ни одной государственной программы и потому не может пользоваться финансовыми мерами поддержки инструментов Российского экспортного центра (кредиты покупателям, страхование поставок и предоставление гарантий Росэксимбанка для экспортных поставок).</p> <p>Стоит отметить, что сейчас отсутствуют показатели эффективности государственной политики в области развития ИТ-экспорта, поэтому приходится делать только общие предположения. Опрос РУССОФТ в рамках ежегодного Исследования софтверной индустрии показывает, что компании, которые уже присутствуют на зарубежных рынках, оценивают «Стимулирование экспорта ИТ государственными структурами и институтами» в целом удовлетворительно, но не очень высоко, даже в сравнении с другими направлениями государственной поддержки. В 2025 году опрошенные компании в среднем оценили стимулирование экспорта государством на 3,15 балла по <nobr>5-балльной</nobr> системе, а при опросе в 2026 году этот показатель снизился до 3,01.</p> <p>Чтобы обеспечить рост зарубежных продаж до величины $40 млрд, необходимо начать со сбора полной информации о том, чего ждут экспортеры от государства и что их не устраивает. Затем уже формулировать или корректировать стратегию комплексной поддержки ИТ-экспорта, и прежде всего — признать экспорт ПО и услуг в качестве приоритета государственной поддержки экспорта в одной из Национальных программ развития.</p> <p>В принципе, проблемы на западных рынках в том или ином виде можно было предположить лет 15 назад, как и необходимость наращивания продаж в развивающихся странах для обеспечения технологического суверенитета. Не хватало стратегического видения и системного критического анализа. РУССОФТ в своих отчетах и пресс-релизах предлагал уделять больше внимания рынкам развивающихся стран, начиная с 2008 года. Современная ситуация толкает нас к тому, чтобы совместными усилиями с государственными структурами сформулировать стратегию развития экспорта софтверной индустрии и ИТ-экспорта в целом и закрепить за Россией статус одного из мировых технологических лидеров.</p> Географическая переориентация российских компаний-разработчиков ПО с недружественного на дружественный мир … message https://www.itweek.ru/themes/detail.php?ID=235368 Wed, 19 Aug 2026 09:30:08 +0300 <p><em>Многие программы реализации цифровых двойников заходят в тупик не только из-за качества модели, но и потому, что организации пытаются перейти к оркестрации до того, как моделирование заслужит операционное доверие, пишет в корпоративном блоге Сара Ли, старший директор </em><em>IDC</em> <em>по исследованиям ИТ-стратегий в производстве.</em></p> <p>Цифровые двойники превращаются из инструментов визуализации в операционную основу физического искусственного интеллекта на производственном участке, и этот термин теперь охватывает две возможности, которые часто рассматриваются как одно целое. <em>Моделирование</em> подтверждает изменения до того, как они достигнут производства. <em>Оркестрация</em> координирует выполнение в реальном времени машинами, системами ИИ и работниками.</p> <p>Какую возможность производитель создаст первой и насколько она будет обоснована, прежде чем перейти ко второй, часто определяет масштабируемость программы.</p> <p>Согласно отчету IDC «Industry Market Trends: Worldwide Manufacturing, 2026», примерно 57% производственных предприятий имеют инициативы в области ИИ, застрявшие на стадии проверки концепции, при этом менее половины демонстрируют измеримые результаты.</p> <p>Программы реализации цифровых двойников находятся в той же ситуации.</p> <h3>Моделирование: проверка изменений до того, как они достигнут производственного цеха</h3> <p>В этой роли цифровые двойники моделируют поведение процессов, производительность оборудования и конфигурации продукции, сочетая физические и основанные на данных модели, а также гибридные подходы, объединяющие инженерный опыт с операционными данными. Традиционная аналитика объясняет, что уже произошло. Моделирование позволяет производителям изучить, что может произойти дальше — это становится все более важным, поскольку автоматизация и роботизация повышают стоимость неудачных изменений.</p> <p>Сценарии применения различаются в зависимости от отраслевой структуры. Процессные производства моделируют отдельные технологические операции и переходы между партиями — прогнозируют производительность линий отбеливания на целлюлозно-бумажных комбинатах, моделируют загрязнения теплообменников на химических заводах или симулируют ферментацию в производстве напитков. Дискретные производства работают на уровне ячеек и линий: виртуальный ввод в эксплуатацию роботизированных ячеек до прибытия оборудования на место, балансировка времени такта при сборке смешанных моделей и генерация синтетических данных для обучения моделей визуального контроля.</p> <p>Возможности одинаковые, единицы анализа разные. Программы, заимствующие эталонную архитектуру с не той стороны этого разделения, как правило, застревают на структуре данных задолго до того, как застрянут на моделировании.</p> <h3>Оркестрация: превращение интеллекта в скоординированные действия</h3> <p>В этой роли цифровые двойники объединяют данные реального времени с датчиков, контрольных систем и систем управления производственными процессами для координации решений между машинами, агентами ИИ и работниками. Области применения включают координацию парков автономных мобильных роботов (AMR) и автоматизированных транспортных средств (AGV), динамическое балансирование производственных линий, управление энергетическими нагрузками в системах коммунального хозяйства и диспетчеризацию мероприятий по техническому обслуживанию или контролю качества в зависимости от изменяющихся условий.</p> <p>По мере внедрения агентного ИИ в производственную среду оркестрация становится средой выполнения, определяющей, какой агент действует, когда и в каких границах. Производители уже консервативно устанавливают эти границы.</p> <p>Согласно опросу IDC «2026 Agentic AI Functional Use», примерно 43% респондентов из производственной отрасли сообщают, что их агенты либо не обладают полномочиями по принятию решений, либо требуют одобрения человека для каждого решения. Только 8,5% допускают полную автономию по любому критически важному вопросу. В то же время 62,5% сообщают, что расширение автономии агентов находится в стадии активного рассмотрения.</p> <p>Устранение этого разрыва — это та работа, которую должна выполнить оркестрация.</p> <h3>Почему последовательность не является необязательной</h3> <p>Моделирование отдает приоритет точности прогнозирования и экспериментам в автономном режиме. Оркестрация отдает приоритет задержке, надежности и интеграции с системами управления и выполнения. Объединение их в единую программу обычно означает, что один набор требований уступает другому, и редко бывает очевидно заранее, какой именно.</p> <p>Доверие не предоставляется по запросу. Операторам и инженерам необходимы доказательства того, что модель отражает реальные условия работы предприятия, прежде чем они начнут действовать в соответствии с ее рекомендациями, и задолго до того, как они позволят агенту действовать от их имени. Трех ложных срабатываний за квартал обычно достаточно, чтобы операторы перестали открывать дашборд.</p> <p>Искушение перейти непосредственно к оркестрации понятно. Координация роботов, агентов ИИ и производственных систем обещает видимые операционные преимущества. Но без проверенного цифрового представления производства организации рискуют ускорить принятие решений, которым они еще не научились доверять.</p> <p>Программы, дающие результаты, начинаются с принятия операционного решения, а не с выбора технологии. Независимо от того, является ли целью выход годной продукции с первого раза, время переналадки, доступность активов или энергоемкость, это решение принимается в первую очередь. Что именно должен обеспечивать цифровой двойник?</p> <h3>От моделей мира к цифровым двойникам и физическому ИИ</h3> <p>По мере того, как производители готовятся к внедрению физического ИИ, различие между общим интеллектом и оперативным интеллектом становится все более важным.</p> <p>Модели мира дают системам ИИ широкое понимание того, как ведет себя физическая среда. Цифровые двойники обеспечивают промышленную специфику, которой не хватает этим моделям: геометрию предприятия, параметры процессов, логику управления и историю эксплуатации.</p> <p>Вместе они создают основу для более надежного физического ИИ. Модель мира может понимать, как ведут себя объекты и силы в целом, но цифровой двойник обеспечивает контекст, необходимый для определения того, является ли действие безопасным и эффективным на конкретном производстве, на конкретной линии, с конкретными материалами и ограничениями.</p> <h3>Что требуется для масштабирования</h3> <p>Ограничения должны быть согласованы между процессными и дискретными средами.</p> <p>Точность двойника зависит от точности потребляемых им данных. Без непрерывной синхронизации он превращается в устаревшее представление, которое обладает авторитетом модели, но не ее точностью.</p> <p>Безопасность становится все более важной по мере того, как двойники расширяют связность в операционных средах. Соединение инженерных моделей, систем ИИ и управления производством расширяет поверхность атаки и требует обеспечения безопасности на этапе проектирования для архитектуры, связности и управления.</p> <p>Работа также меняется по мере того, как двойники и агенты получают все больше возможностей принятия решений. Операторы и технические специалисты переходят от выполнения рутинных задач к контролю за системами, проверке рекомендаций и управлению исключениями. Это требует четкого определения ролей и путей эскалации, поскольку одних дополнительных часов обучения недостаточно для устранения этого пробела.</p> <p>Успешные программы цифровых двойников редко являются исключительной прерогативой ИТ-службы. Они требуют сотрудничества между операционными, инженерными, операционными группами, группами обработки данных и функциями управления ИИ. По мере того, как двойники эволюционируют из инженерных инструментов в платформы для принятия операционных решений, определение ответственности становится столь же важным, как и архитектура.</p> <h3>Вопрос, который стоит изучить производителям</h3> <p>Для руководителей операционных подразделений реальный вопрос заключается в том, достаточно ли развиты аспекты фундамента данных, проверки моделей, доверия операторов и управления, чтобы перейти на следующую ступень: от визуализации к автономному моделированию и далее к замкнутой системе оркестрации и к принятию агентами автономных решений.</p> <p>Переход на каждую следующую ступень должна быть обеспечен подтвержденными результатами на предыдущей.</p> <p>Программы, которые пропускают ступень, не движутся быстрее. Они застревают из-за отсутствия доверия модели, а доверие восстановить сложнее, чем исправить модель.</p> Многие программы реализации цифровых двойников заходят в тупик не только из-за качества модели, но и потому … article https://www.itweek.ru/themes/detail.php?ID=235366 Wed, 19 Aug 2026 09:10:34 +0300 <p>ИИ-пилот можно запустить быстро: взять готовую модель, подключить небольшой набор данных — и обкатать сценарий на ограниченной группе пользователей. Но в промышленной эксплуатации с нагрузкой дела обстоят иначе. По оценке IDC, глобальные расходы на ИИ-инфраструктуру в 2026 году <a href="https://www.idc.com/resource-center/blog/ai-infrastructure-spending-caps-historic-year-at-90-billion-in-q4-2025-2029-spending-to-eclipse-1-trillion/">достигнут</a> 487 млрд. долл., прибавив около 53% за год. Такой рост показывает простую вещь: инфраструктура становится одной из главных статей ИИ-бюджета, а не технической деталью на стороне ИТ.</p> <p>При этом сама по себе закупка мощностей ничего не гарантирует — можно купить дорогие карты и получить простои. Поэтому компании, которые выводят ИИ из пилота, начинают адаптировать не один сервер, а весь контур: от профиля нагрузки до метрик, безопасности и финансового учета.</p> <p>Рассмотрим, как адаптировать инфраструктуру под новые нагрузки и почему недостаточно просто приобрести GPU.</p> <h3>Сначала сценарий, потом железо</h3> <p>Выражение «ИИ-инфраструктура» звучит так, будто речь идет об одном типе нагрузки — но на деле под ним скрываются разные задачи: обучение модели с нуля, дообучение, классический ML, генерация эмбеддингов. И у каждой задачи — свои узкие места, например голосовому ассистенту важна низкая задержка ответа, а для аналитики критична стоимость обработки большого объема данных.</p> <p>Поэтому зрелые компании начинают с классификации сценариев. Они отвечают на несколько простых вопросов:</p> <ul> <li> кто будет пользоваться искусственным интеллектом;</li> <li> сколько запросов ожидается;</li> <li> насколько важна скорость первого ответа;</li> <li> какой объем контекста нужен;</li> <li> можно ли обрабатывать запросы пакетно;</li> <li> что происходит при задержке.</li> </ul> <p>Без этого закупка «железа под ИИ» превращается в лотерею — инфраструктура может и не выдержать реальный сценарий.</p> <h3>Не всем нужен собственный обучающий кластер</h3> <p>Многие компании по инерции думают об ИИ-инфраструктуре как о кластере для обучения моделей. На практике большинству организаций он не нужен — у них нет ни объема данных, ни задач, ради которых стоит учить модель с нуля.</p> <p>Для внутренних ассистентов, поиска по базе знаний, обработки обращений, подготовки документов и поддержки разработчиков лучше идти другим, более простым путем. Достаточно взять готовую модель, развернуть ее у себя или провайдера, подключить корпоративные данные и настроить инференс.</p> <p>«Спроектировать инференс-платформу» звучит не так эффектно, как «построить суперкомпьютер» — зато это ближе к реальным задачам бизнеса.</p> <h3>GPU недостаточно просто купить — нужно научиться использовать</h3> <p>Самая дорогая ошибка — считать, что проблема решается количеством карт. В действительности GPU часто простаивают, в то время как команды жалуются на нехватку мощностей.</p> <p>Это видно и по рынку: в отчете Cast AI за 2026 год средняя утилизация GPU в Kubernetes-кластерах <a href="https://cast.ai/reports/kubernetes-optimization-report/">составила</a> всего 5%. Проблема эта редко связана с плохой организацией — чаще всего она структурная. В Kubernetes GPU в большинстве случаев воспринимается как неделимая единица: приложение запросило карту — получило ее целиком, а использует только часть мощности. В итоге дорогое оборудование формально занято, а фактически не загружено.</p> <p>Компании решают этот вопрос несколькими способами, например делят карту на изолированные части или выбирают инференс-серверы, которые умеют эффективнее упаковывать запросы.</p> <h3>Карты без сети и хранилища тоже простаивают</h3> <p>ИИ-нагрузки быстро показывают, что GPU — лишь часть инфраструктуры. Если данные и веса модели не успевают подаваться на узел, карта ждет. Бизнес при этом платит за дорогое оборудование, которое не делает полезной работы.</p> <p>Для больших моделей это становится отдельной инженерной задачей. Модель на 70 млрд. параметров в FP8 может весить около 70 Гб, а флагманские модели — сотни гигабайт. Их нужно быстро доставлять, хранить, обновлять и переиспользовать между узлами.</p> <p>Поэтому инфраструктура под ИИ должна включать сеть, хранилище, интерконнект, параллельную файловую систему и механику доставки весов. Если этого не сделать, компания покупает не мощность, а дорогую очередь ожидания.</p> <h3>Обычные метрики не показывают качество ИИ-сервиса</h3> <p>Классический мониторинг приложений плохо описывает ИИ-нагрузку. Для <nobr>LLM-инференса</nobr> важны другие показатели: time to first token, inter-token latency, throughput, tokens per second, запросы в секунду и стоимость обработки. NVIDIA в документации по benchmarking для LLM отдельно <a href="https://docs.nvidia.com/nim/benchmarking/llm/latest/metrics.html">выделяет</a> такие метрики как TTFT, ITL, TPS и end-to-end latency.</p> <p>Важно, что эти показатели нельзя оптимизировать для всех сценариев. Голосовому боту важен быстрый первый ответ, batch-аналитике — минимальная стоимость обработки. Поэтому зрелые команды задают SLO под конкретную ситуацию: для кого работает ИИ, какая задержка допустима, сколько компания готова платить за миллион токенов.</p> <h3>Модель нельзя встраивать напрямую в каждое приложение</h3> <p>Быстрый путь — подключить LLM прямо к монолиту или внутреннему порталу. На пилоте это удобно, однако в промышленной эксплуатации такой подход становится дорогим.</p> <p>Почему это происходит:</p> <ul> <li> становится сложнее переключить провайдера;</li> <li> приложение оказывается привязано к конкретной модели;</li> <li> почти невозможно нормально рассчитать расходы по командам;</li> <li> промпты и ответы выпадают из общего мониторинга.</li> </ul> <p>Рабочий вариант в таком случае — вынести работу с моделями в отдельный слой, ИИ-шлюз. Он становится единой точкой для квот, логирования, PII-фильтрации, кэширования, переключения моделей и контроля расходов.</p> <h3>RAG требует архитектуры доступа</h3> <p>RAG часто становится первым массовым корпоративным ИИ-сценарием: компания подключает документы, базы знаний, инструкции и хочет, чтобы сотрудники задавали вопросы на естественном языке. Однако вместе с пользой возникает и новый риск.</p> <p>Если права пользователя не участвуют в самом поисковом запросе, а фильтрация происходит уже после извлечения документов, векторная база превращается в канал переноса информации между отделами — быстрый, удобный и не оставляющий следов в привычных журналах доступа. Надеяться на фильтрацию постфактум нельзя, так как она регулярно пропускает содержимое чужих документов в ответы.</p> <p>Именно поэтому в корпоративном RAG роль, права доступа и подразделение пользователя должны быть частью самого запроса к индексу. Если гарантировать это архитектурно не получается, корпус должен сужаться до публичных документов — сегодня других надежных и безопасных вариантов тут нет.</p> <h3>Стоимость нужно считать в токенах с первого дня</h3> <p>ИИ-инфраструктура меняет привычный финансовый учет ИТ. Раньше компания считала серверы, лицензии, облачные ресурсы и человеко-часы. В ИИ-сервисах новой единицей стоимости становится токен.</p> <p>На пилоте это легко недооценить — слишком мало пользователей и запросов. В промышленной эксплуатации растут конкурентность, длина контекста, число пользователей, резервирование и объем логирования. Стоимость начинает расти нелинейно.</p> <p>Подсчет токенов нужен с первого дня. Компания должна понимать, кто генерирует расходы, какие сценарии самые дорогие, где можно кэшировать ответы, где подойдет более дешевая модель, а где оправдана премиальная.</p> <h3>Платформа лучше разрозненных запусков</h3> <p>Один из частых антипаттернов — когда каждый отдел сам разворачивает модель. На старте это кажется отличной возможностью не тормозить команды, однако вскоре компания получает дублирование расходов, разный уровень безопасности, отсутствие прозрачности и несколько точек риска.</p> <p>Но зрелая схема устроена иначе. Есть единый платформенный слой: инфраструктура, ИИ-шлюз, квоты, аудит, мониторинг, безопасность и SLA. Продуктовые команды отвечают за свои сценарии — промпты, корпус знаний, качество ответов, бизнес-эффект.</p> <p>Отдельный признак зрелости системы — оценка качества, evals. Без «золотого» набора примеров и регрессионного прогона невозможно ответить на вопрос, стало ли лучше после смены промпта или модели — и таким образом решения принимаются лишь на ощущениях.</p> <p>Зрелые команды относятся к промпту как к артефакту релиза: он версионируется, выкатывается постепенно и откатывается при деградации. Важно тут то, что закладывать evals нужно с первого дня, так как задним числом их уже не собрать. Так искусственный интеллект становится частью корпоративной архитектуры, переставая быть набором локальных экспериментов.</p> <h3>Подведем итоги</h3> <p>Адаптация ИТ-инфраструктуры под ИИ-нагрузки начинается с понимания сценариев: кому нужен искусственный интеллект, как часто, на каких данных, с какими рисками и за какие деньги.</p> <p>Компании, которые проходят этот путь осознанно, проектируют управляемый контур — инференс-платформу, правильные метрики, ИИ-шлюз, безопасный RAG, подсчет токенов и единые правила для всех команд. Не нужно делать его максимальным, перегружать всем и сразу — достаточно контроля, ясности и обратимости, то есть готовности сменить модель или провайдера, когда профиль нагрузки изменится.</p> <p>#IMAGE_235367#</p> ИИ-пилот можно запустить быстро: взять готовую модель, подключить небольшой набор данных — и обкатать сценарий … article Султан Рамазанов, директор по искусственному интеллекту Umbrella IT https://www.itweek.ru/themes/detail.php?ID=235363 Tue, 18 Aug 2026 15:56:55 +0300 <p>Компании «Аладдин» и «Пассворк» подтвердили совместимость своих продуктов — корпоративной системы централизованного управления JaCarta Management System 4LX для Linux (JMS4LX) и менеджера паролей Пассворк.</p> <p>Корректность совместной работы решений подтверждена сертификатом, выданным по результатам испытаний. Эта совместимость закрывает конкретную задачу заказчиков: организовать вход в менеджер паролей через уже действующую в компании систему усиленной аутентификации без создания отдельных учётных данных. Таким образом, пользователю не нужно запоминать ещё один пароль или носить отдельный токен для доступа к хранилищу — он проходит аутентификацию через сервис JaCarta Identity Provider (JIP), входящий в JMS4LX.</p> <p>JaCarta Management System 4LX для Linux — это система централизованного управления средствами аутентификации и электронной подписи, защищёнными носителями информации, аппаратными OTP/U2F-токенами и программными аутентификаторами. В её состав входят высокопроизводительный сервер аутентификации JaCarta Authentication Server (JAS), сервис Aladdin 2FA и JaCarta Identity Provider (JIP) — провайдер аутентификации/авторизации в приложения с поддержкой протоколов SAML и OIDC. </p> <p>Пассворк — это российский корпоративный менеджер паролей и секретов с возможностью развёртывания на собственном сервере заказчика или в облаке. Решение предназначено для безопасного хранения, управления и совместного использования учётных данных внутри компаний. Пассворк поддерживает ролевую модель доступа, полный аудит действий, интеграцию со службами каталогов и системами мониторинга безопасности. Пассворк включён в Единый реестр российского программного обеспечения (№ 6147 от 13.01.2020) и сертифицирован ФСТЭК России по <nobr>4-му</nobr> уровню доверия (№ 5063 от 30.04.2026).</p> <p>«Заказчики, которые строят ИТ-инфраструктуру на отечественных решениях, должны быть уверены: продукты работают вместе корректно и без доработок. Сертификат даёт эту уверенность на уровне вендоров: совместимость Пассворка и JMS4LX зафиксирована документально, протестирована и будет поддерживаться», — прокомментировал Андрей Пьянков, генеральный директор «Пассворк».</p> <p>«Подтверждение совместимости JMS4LX и Пассворка позволяет заказчикам использовать уже существующую инфраструктуру аутентификации для доступа к менеджеру паролей. Для компаний, где JIP уже используется в качестве корпоративного SSO, это означает, что сотрудникам не нужно заводить отдельные учётные данные для Пассворка», — прокомментировал Станислав Винарский, менеджер по развитию бизнеса JMS/JAS/JIP, «Аладдин».</p> Компании «Аладдин» и «Пассворк» подтвердили совместимость своих продуктов — корпоративной системы централизованного … message https://www.itweek.ru/themes/detail.php?ID=235362 Tue, 18 Aug 2026 15:20:16 +0300 <p>Разработчик платформы унифицированных корпоративных коммуникаций CommuniGate Pro объявил о выходе первой публичной версии десктопного и мобильного клиентских приложений. Релиз завершает этап бета-тестирования и переводит продукт на новую ступень готовности. Обновление включает более 20 новых функций, реализованных в постоянном диалоге с пользователями: изменения коснулись календаря, редактора написания письма, доступа к учетным записям и новых функций безопасности.</p> <p>Релиз направлен на решение трех задач — ускорение совместной работы, повышение прозрачности коммуникаций и упрощение рутинных операций.</p> <p>Пользователи получили возможность делиться своим расписанием с внешними партнерами или клиентами через публичные ссылки — теперь для просмотра календаря не требуется создавать учетную запись. При командной работе доступ к календарям предоставляется с гибкой настройкой уровней прав, что делает планирование прозрачным и управляемым. Полноформатный планировщик событий позволяет детально настраивать встречи и мероприятия в интуитивно понятном интерфейсе. Реализована возможность редактировать или удалять отдельное событие внутри повторяющейся серии, не нарушая всю последовательность, а также отображать время начала серии непосредственно в календаре.</p> <p>Значительные улучшения затронули и почтовый редактор. Теперь в тело письма можно мгновенно вставлять изображения, файлы и таблицы прямо из буфера обмена, а также создавать и редактировать таблицы встроенными средствами. Функция отложенной отправки позволяет задать точную дату и время доставки письма, а проверка орфографии подчеркивает ошибки, помогая избегать опечаток. Статус отправленных сообщений помогают отслеживать уведомления о доставке и прочтении с возможностью выбора автоматического или ручного режима в настройках.</p> <p>Для совместной работы с почтой и учетными записями реализован ряд новых возможностей. Доступ к почтовым папкам коллег настраивается для совместной работы, а функция делегирования позволяет доверенным лицам отправлять письма, принимать, переносить или назначать встречи от имени другого сотрудника. При отправке можно выбрать имя, от которого будет отправлено письмо, что обеспечивает прозрачность для получателя. Также пользователи могут создавать псевдонимы для своих учетных записей, чтобы лучше структурировать входящий поток.</p> <p>В релизе появились важные инструменты для защиты аккаунтов. Пользователи теперь могут самостоятельно сменить пароль непосредственно из интерфейса приложения, а также настроить двухфакторную аутентификацию — это обеспечивает дополнительный уровень защиты от несанкционированного доступа, что критически важно для корпоративных коммуникаций.</p> <p>Одним из ключевых нововведений стал функционал создания локальных архивов. Теперь можно сохранять свои почтовые сообщения непосредственно на устройстве, обеспечивая офлайн-доступ и дополнительную сохранность данных. На текущий момент доступно создание архивов и вложенных подпапок, архивация одного письма и группы писем, ручная архивация всей папки через контекстное меню, автоархивация по настройкам, удаление архивов и папок в них, ответ на письма из архива, пересылка писем из архива, работа с метками в архивах.</p> <p>Повышению удобства повседневной работы также способствуют обновленный поиск адресатов, который предлагает наиболее релевантных получателей при вводе фамилии, настройки режима удаления писем — через корзину, напрямую или пометку письма как удаленного, а также редизайн карточки контакта с более структурированным отображением информации. Для ускорения навигации добавлены горячие клавиши и возможность открывать письмо в новом окне одним нажатием Enter. Производительность приложения в целом была улучшена: оно стало быстрее и отзывчивее.</p> <p>«Мы сфокусировались на том, что напрямую влияет на эффективность повседневной работы, — прокомментировал Борис Моисеев, директор департамента разработки CommuniGate Pro. — Возможность вставить таблицу из Excel, файл или изображение в письмо за секунду, открыть календарь внешнему партнеру без создания учетной записи или выполнить проверку орфографии при написании письма — это базовые инструменты, экономящие реальное время каждого сотрудника каждый день».</p> <p>Первый официальный релиз десктопного и мобильного приложений уже доступен пользователям с действующей лицензией.</p> Разработчик платформы унифицированных корпоративных коммуникаций CommuniGate Pro объявил о выходе первой публичной версии … message https://www.itweek.ru/themes/detail.php?ID=235361 Tue, 18 Aug 2026 09:27:05 +0300 <p><em>Самый частый вопрос, который венчурные капиталисты задают начинающим предпринимателям: есть ли у них договоренности с фабрикой о экономически эффективном массовом производстве их совков для уборки собачьих экскрементов, комфортных носков или мочалок. Идея массового производства может быть актуальна и для доставки ПО, пишет на портале </em><em>ZDNet</em> <em>независимый аналитик Джо Маккендрик.</em></p> <p>Представьте, что вы отправляете свой прототип — например, начальную версию приложения, написанную с помощью вайб-кодинга, — в сервис, который будет массово производить ваше решение в повторяемом автоматизированном режиме для распространения среди широкой аудитории. В этом и заключается обещание «фабрики ПО».</p> <p>В этой концепции нет ничего нового — она была очень популярна около двух десятилетий назад, когда разработка ПО стала более компонентной и повторяемой. Microsoft <a href="https://en.wikipedia.org/wiki/Software_factory_(Microsoft_.NET)">заговорила</a> о фабриках ПО еще в 2008 г. Идея на некоторое время затихла, но теперь она вернулась, подпитываемая быстрым созданием программного кода, генерируемого и управляемого искусственным интеллектом.</p> <p>До недавнего времени, даже при наличии автоматизации и практик DevOps, «кодирование создавало узкие места для многих организаций, — говорит Мориц Плассниг, генеральный директор CloudBees. — Приходилось нанимать больше инженеров, но это было очень сложно и дорого».</p> <h3>Сегодняшняя фабрика ПО построена на моделях ИИ</h3> <p>Благодаря возможностям кодирования базовых моделей ИИ и связанных с ними агентов, концепция фабрики ПО возродилась — и сегодня серьезно рассматривается автоматизация жизненного цикла разработки ПО на уровне повторяющихся этапов. С помощью агентного кодирования «мы меньше ограничены в части кодирования», отмечает Плассниг. Оно также может повысить роль ИТ-специалистов: «Мастерство разработчиков никуда не денется, поскольку разработчики и инженеры переходят от написания кода к принятию решений о том, что будет создано и выпущено».</p> <p>Современная концепция фабрики ПО построена на основе моделей ИИ, представленных на рынке, — и эта концепция практически одинакова для всех моделей. «За последние полтора года многие компании, находящиеся на переднем крае использования агентов для автоматизации жизненного цикла разработки ПО, создавали одну и ту же машину и независимо друг от друга приходили к одному и тому же выводу о том, как эта машина должна выглядеть», — говорит Джеймин Уэст, инженер-разработчик и технологический евангелист.</p> <p>Среди компаний, создающих фабрики ПО, — такие светила современной агентной экономики, как Anthropic, Cognition, Cursor, Factory, Google, Github, OpenAI и Ramp. «Каждая из этих компаний пришла к одной и той же форме, — отмечает Уэст. — На данном этапе очень важно понимать, что это компании, находящиеся на передовой, и что формируется четкая закономерность в том, как они структурируют всю свою инженерную работу».</p> <p>По словам Пласснига, фабрика ПО служит способом быстрого воплощения идей: «Допустим, кто-то работает в службе поддержки клиентов, и у него возникает интересная идея, основанная на отзывах клиентов. Такой человек с идеей ПО может отправить ее на фабрику, где создается первая итерация. Далее специалисты по продуктам, инженеры и ИТ-специалисты изучают ее. Затем фабрика может снова взять ее и воплотить в жизнь. Это подобно тому, как в автоиндустрии появляется экспериментальный прототип, который потом передается на завод, который производит автомобили в больших масштабах».</p> <p>Фабрика ПО помогает решить проблему проверки и поддержки сотен тысяч строк кода, а также релизов, обновлений и модернизаций ПО, которые сегодня ежедневно происходят во многих организациях.</p> <p>«Вы хотите знать, действительно ли ПО работает, нет ли ошибок или хотя бы резкого роста частоты ошибок. Или, может быть, оно работает, но не превышает ли потребление памяти агентом желаемый уровень? Сегодня люди проверяют все эти оповещения, но если изменений будет в 100 раз больше, например, каждые несколько минут, система сломается. Мы дойдём до того момента, когда люди больше не смогут проверять, что работает, а что нет», — говорит Плассниг.</p> <h3>Как выглядит фабрика ПО?</h3> <p>Уэст описывает типичную фабрику, поддерживаемую базовыми моделями, как состоящую из шести компонентов:</p> <ol> <li><strong> Очередь.</strong> «Работа поступает в виде проблемы, а не промпта».</li> <li><strong> Плоскость управления.</strong> «Надежный уровень, а не ноутбук».</li> <li><strong> Песочница.</strong> «Одна на задачу. Уничтожается после ее завершения».</li> <li><strong> Запрос на слияние.</strong> «Единица вывода. Его получает человек».</li> <li><strong> Поток событий.</strong> «Отслеживает каждое действие. Прерывает его, не нарушая выполнение».</li> <li><strong> Надежная память.</strong> «Песочница выполняет каждый запуск. То, что не записано в файл, не сохраняется».</li> </ol> <p>Конечно, фабрики ПО, какими бы эффективными они ни были, не являются панацеей для внедрения передовых методов разработки ПО.</p> <p>«Сейчас уже не секрет, что генерация кода стала невероятно простой, — говорит Уэст. — Она теперь невероятно дешева. Но препятствием для многих компаний стала верификация. Убедиться, что агенты пишут код, очень легко. Но убедиться в правильности этого кода по-прежнему остается серьезной инженерной проблемой. И важно понимать, что создание фабрики ПО не означает, что вы просто отказываетесь от верификации или снижаете качество своей кодовой базы».</p> Самый частый вопрос, который венчурные капиталисты задают начинающим предпринимателям: есть ли у них договоренности … article https://www.itweek.ru/themes/detail.php?ID=235359 Tue, 18 Aug 2026 09:17:03 +0300 <p><em>За четыре года число поисковых запросов вокруг темы «ИИ как угроза» выросло примерно в 30 раз и к <nobr>2026-му,</nobr> по данным исследования Андрея Цая, вышло на первое место — обогнав даже запросы о защите самих ИИ-систем. Рассмотрим, насколько реальна эта угроза и что необходимо предпринять компаниям, чтобы ее отразить.</em></p> <h3>ИИ как орудие злоумышленников</h3> <p>На фоне развития искусственного интеллекта все чаще звучат разговоры о том, что ИИ может превратиться в инструмент злоумышленников. Однако слово «может» здесь уже не вполне уместно: ИИ становится рабочим инструментом в offensive security и способен выполнять часть задач, которые раньше требовали значительного объема ручной работы. Показателен пример XBOW — автономной системы для поиска и эксплуатации уязвимостей. В 2025 году XBOW поднялась на первое место американского рейтинга HackerOne, а позднее заняла первое место и в глобальном рейтинге платформы. При этом речь шла не о лабораторном тесте: система работала в реальных bug bounty-программах и отправляла отчеты об обнаруженных уязвимостях. Сам HackerOne отмечал выход XBOW на первое место американского рейтинга как пример того, что ИИ-системы уже способны эффективно находить определенные классы уязвимостей. Это не означает, что ИИ полностью заменил исследователя: например, команда XBOW проверяла отчеты перед отправкой в соответствии с правилами HackerOne. Но сам кейс хорошо показывает изменение масштаба и скорости работы: значительную часть поиска, проверки гипотез и валидации находок уже можно автоматизировать.</p> <p>Причина очевидна: ИИ хорошо справляется с интеллектуальной рутиной. Он может быстро обрабатывать большие объемы информации, находить закономерности, классифицировать данные и выполнять последовательности однотипных операций. И атака в этом смысле во многом похожа на другие сложные рабочие процессы. Значительная часть времени злоумышленника уходит на подготовку: сбор информации о цели, анализ инфраструктуры и технологий, поиск потенциально интересных объектов и проверку различных гипотез. Если часть этой работы передать ИИ, меняется сама экономика атаки: разведка, анализ и перебор вариантов становятся быстрее и дешевле, а один злоумышленник может выполнять объем работы, для которого раньше требовалось значительно больше времени.</p> <p>Необходимо также понимать, что скорость внедрения новых технологий у злоумышленников зачастую выше, чем в крупных организациях. Пока компания оценивает риски, согласовывает бюджет, выбирает модели и выстраивает процессы безопасного использования ИИ, атакующему достаточно получить доступ к публичному сервису или модели. Возникает асимметрия: стоимость автоматизации отдельных этапов атаки быстро снижается, тогда как стоимость полноценной защиты компании — нет. Поэтому основная угроза ИИ сегодня заключается не столько в появлении автономного «ИИ-хакера», сколько в росте производительности обычного злоумышленника.</p> <h3>Проще атака — больше желающих</h3> <p>Еще одна проблема заключается в том, что ИИ постепенно снижает порог входа в отдельные этапы кибератак. Часть задач, для которых раньше требовались специальные знания, теперь можно выполнять с помощью языковых моделей: собирать и анализировать информацию о цели, быстрее разбираться в незнакомых технологиях, модифицировать скрипты, готовить фишинговые сообщения или анализировать найденный код. Это не превращает человека без технических знаний в профессионального хакера, но сокращает разрыв между отсутствием компетенций и возможностью выполнить отдельные элементы атаки.</p> <p>Одновременно с этим появляются и новые классы атак на сами ИИ-приложения. Один из примеров — prompt injection (инъекция промптов), при которой злоумышленник через специально сформированные инструкции пытается изменить ожидаемое поведение системы. Например, если на корпоративном ресурсе работает интеллектуальный поиск или ИИ-агент, атакующий может попытаться заставить его проигнорировать исходные инструкции, обратиться к данным, которые не должны быть доступны пользователю, или выполнить нежелательное действие. Отдельно существуют jailbreak-техники, направленные на обход ограничений самой модели. Для экспериментов с такими атаками в ряде случаев действительно не требуется сложная инфраструктура: взаимодействие происходит через тот же интерфейс, которым пользуется обычный пользователь.</p> <p>Одновременно ИИ выступает как инструмент автоматизации для самого злоумышленника. Если раньше для подготовки определенной атаки требовалось самостоятельно изучать множество технических вопросов, теперь часть этой работы можно переложить на языковую модель: быстрее разобраться в технологии, получить объяснение незнакомого кода, подготовить или адаптировать отдельные фрагменты скриптов, систематизировать результаты разведки. Ограничения публичных моделей снижают возможности их прямого использования во вредоносных целях, однако злоумышленники постоянно экспериментируют и с техниками обхода таких ограничений.</p> <p>Для обхода ограничений могут использоваться изменение контекста запроса, ролевые сценарии, декомпозиция задачи на несколько внешне безобидных этапов и другие техники. Вместо прямого запроса пользователь может представить задачу как исследование, киберучение или анализ защищенности либо разбить ее на последовательность отдельных вопросов. Эффективность таких приемов зависит от конкретной модели и реализованных механизмов защиты, но для атакующего важен сам принцип: ИИ позволяет значительно быстрее проводить эксперименты и проверять множество вариантов.</p> <p>Еще сильнее меняется скорость работы. Если раньше сбор и изучение контекста для определенной атаки могли занимать дни, то автоматизированная система способна существенно сократить этот этап. В результате отдельные стадии атаки становятся проще, дешевле и лучше масштабируются. Высвободившееся время злоумышленник может потратить на более сложные действия, которые пока хуже поддаются автоматизации.</p> <p>Для бизнеса это неприятная тенденция, поскольку стоимость атаки снижается, но стоимость полноценной защиты от нее автоматически не уменьшается. Компании по-прежнему должны поддерживать инфраструктуру безопасности, контролировать доступы, анализировать события и защищать данные.</p> <h3>Shadow AI как источник риска внутри компании</h3> <p>Однако усиление внешнего атакующего — только одна сторона проблемы. ИИ одновременно меняет поверхность атаки внутри самой компании: сотрудники подключают публичные модели, генераторы кода, агентов и другие инструменты быстрее, чем служба безопасности успевает их обнаруживать и оценивать. Так возникает другая категория риска — Shadow AI (теневой ИИ).</p> <p>Термин появился по аналогии с давно известным Shadow IT (теневые ИТ) — ситуацией, когда сотрудники самостоятельно используют для рабочих задач программное обеспечение и сервисы, которые компания официально не разрешила и не контролирует. Например, сотруднику нужен удобный инструмент для хранения файлов, совместной работы или обработки документов, и он самостоятельно регистрируется во внешнем сервисе. С точки зрения сотрудника он просто выбрал удобный инструмент, а с точки зрения службы безопасности внутри компании появился неконтролируемый канал обработки корпоративных данных.</p> <p>С Shadow AI происходит похожая история. В компании может не быть понятных правил использования ИИ — какие сервисы разрешены, какие данные можно туда отправлять, какую информацию категорически запрещено загружать, какие инструменты допустимы для разработки и анализа. В результате сотрудники начинают самостоятельно выбирать открытые ИИ-сервисы и использовать их для рабочих задач.</p> <p>Главные риски здесь связаны с утечками данных. Сотрудник может работать с корпоративного компьютера или ноутбука в публичном ИИ-сервисе и передавать туда информацию, которую нельзя выводить за пределы компании. Причем он сам часто даже не задумывается, что создает риски утечки. Для него это просто удобный способ решить рабочую задачу.</p> <p>Допустим, сотрудник отдела продаж берет папку с документами по клиентам за прошлый год и загружает ее в ИИ с просьбой сформировать отчет, прогноз или маркетинговое предложение. На первый взгляд задача выглядит безобидной и даже полезной: сотрудник хочет быстрее проанализировать информацию, чтобы повысить продажи. Но вместе с запросом за пределы корпоративного контура уходит клиентская база: контактные данные, сведения о продажах, цены, скидки и другая коммерческая информация. В результате могут компрометироваться и персональные данные, и коммерческая тайна, и внутренняя информация о работе с клиентами.</p> <p>Традиционные средства контроля утечек данных остаются необходимой частью защиты, но в случае с ИИ их возможностей может быть недостаточно. Компании важно понимать не только то, какие данные передаются за пределы корпоративного контура, но и в какой ИИ-сервис они уходят, разрешен ли этот сервис конкретному сотруднику, идет ли речь о загрузке файла, отправке промпта или обращении к модели через API. Поэтому классические механизмы защиты приходится дополнять обнаружением ИИ-сервисов и контролем специфичных для них сценариев использования.</p> <p>У Shadow AI есть и техническая сторона. Внутри разработки могут появляться генераторы кода, различные модели, агенты и другие инструменты, которые сотрудники самостоятельно подключают к рабочим процессам. Проблема заключается в том, что качество и безопасность таких инструментов часто под вопросом. Один сотрудник может использовать модель для генерации кода, другой — подключить сторонний инструмент для автоматизации, третий — развернуть собственный сервис. При этом количество подобных решений может расти настолько быстро, что служба безопасности просто не успевает их обнаруживать и оценивать. А защищать то, что СБ не видит, технически невозможно. Если компания не знает, какими ИИ-инструментами пользуются сотрудники, она не может полноценно оценить риски, определить, какие данные через них проходят, и подобрать соответствующие средства защиты.</p> <p>Поэтому сама по себе политика запрета не решает проблему. Более того, жесткий запрет может сделать ситуацию менее прозрачной. Если сотруднику официально запрещено пользоваться ИИ, но инструмент необходим ему для работы, он с высокой вероятностью начнет искать собственное решение. В итоге компания формально может считать, что никакого ИИ у нее нет, тогда как сотрудники будут его использовать с личных устройств.</p> <p>Выход здесь — в создании контролируемой корпоративной среды для работы с ИИ. Если сотрудникам действительно нужны языковые модели, агенты или другие ИИ-инструменты, компания должна предоставить разрешенные способы их использования: определить перечень допустимых сервисов и моделей, правила работы с данными, механизмы доступа, журналирования и контроля. Это необязательно означает полный отказ от внешних ИИ-сервисов — важно, чтобы компания понимала, какие инструменты используются, какие данные в них передаются и на каких условиях они обрабатываются.</p> <p>Такая среда должна быть не только безопасной, но и удобной. Иначе запрет снова будет проигрывать удобству публичных инструментов. Сотрудник выбирает не по критерию безопасности. Он ищет способ быстрее выполнить свою работу. И если корпоративная система оказывается слишком неудобной, поиск обходных путей практически неизбежен.</p> <p>#IMAGE_235360#</p> За четыре года число поисковых запросов вокруг темы «ИИ как угроза» выросло примерно в 30 раз … article Светлана Газизова, владелец продукта по безопасности ИИ компании UserGate https://www.itweek.ru/themes/detail.php?ID=235358 Mon, 17 Aug 2026 19:08:47 +0300 <p>Кадровый системный интегратор SENSE провёл исследование динамики зарплат российских ИТ-специалистов на основе данных более 43 тыс. человек по 36 ролям и выяснила, что медианная зарплата специалистов уровня Senior в I квартале 2026 года вернулась к показателю трёхлетней давности. За полгода она снизилась на 17%, с 360 тыс. до 300 тыс. рублей после вычета налогов. </p> <p>Исследование охватывает семь замеров с I квартала 2023 года по I квартал <nobr>2026-го.</nobr> За это время российский ИТ-рынок прошёл полный цикл: от последовательного роста зарплат до их заметного снижения после пика III квартала 2025 года.</p> <p>Изменения затронули все грейды, за полгода медианная зарплата специалистов уровня Middle снизилась на 8%, с 250 тыс. до 230 тыс. рублей после вычета налогов. У Senior она сократилась на 17%, с 360 тыс. до 300 тыс. рублей, а у Lead — на 12%, с 450 тыс. до 395 тыс. рублей. При этом зарплаты Middle и Lead всё ещё немного превышают показатели начала 2023 года, тогда как медиана Senior полностью вернулась к уровню трехлетней давности.</p> <p>«Совпадение зарплатных показателей с уровнем 2023 года не означает, что рынок вернулся в прежнее состояние. За одинаковыми цифрами скрывается другая логика найма. Если раньше работодатели конкурировали за специалистов и расширяли зарплатные вилки, то теперь они точнее оценивают прикладную ценность каждой роли. Спрос сохраняется, но становится более избирательным: лучше всего удерживают позиции специалисты, чьи компетенции связаны с устойчивостью инфраструктуры, безопасностью и решением конкретных задач бизнеса.</p> <p>В этих условиях компаниям важно не только точнее нанимать специалистов, но и эффективнее развивать уже сформированные команды. Поэтому переход от HR Tech к People Tech, то есть от автоматизации отдельных HR-функций к управлению всем профессиональным путём сотрудника, становится одной из ключевых тем отраслевой дискуссии. Этот вопрос активно обсуждается в профессиональном сообществе, в том числе на конференциях для HR- и ИТ-лидеров. Бизнес стремится объединить подбор, адаптацию, обучение и оценку эффективности в единую систему, ориентированную на реальные задачи компании», — комментирует Иван Котковский, управляющий партнёр кадрового системного интегратора SENSE, сооснователь и член программного комитета ежегодного кэмпа PEOPLE TECH для HRD, CPO / CTO HR.</p> <p>Наиболее заметно снизились зарплаты в направлениях, которые активнее всего росли в <nobr>2024–2025 годах.</nobr> Одним из таких направлений стало Data & ML. Самую сильную коррекцию за полгода показали специалисты Data Quality уровня Lead: их медианная зарплата сократилась на 30%, с 400 тыс. до 280 тыс. рублей. Data Scientist Lead за тот же период потеряли 115 тыс. рублей, а Senior — 85 тыс. рублей.</p> <p>В то же время прикладные и инфраструктурные роли внутри Data & ML оказались устойчивее: медианная зарплата DBA Middle снизилась только на 3%, а ML Middle — на 7%. По мнению аналитиков SENSE, рынок стал строже оценивать не само владение ИИ-инструментами, а способность специалистов решать с их помощью конкретные задачи бизнеса.</p> <p>Заметный откат произошёл и в классическом backend. За полгода медианная зарплата Python Senior снизилась на 28%, с 360 тыс. до 260 тыс. рублей, а C#.Net Senior — на 26%, с 380 тыс. до 280 тыс. рублей. Зарплата Java Middle к I кварталу 2026 года вернулась к отметке 250 тыс. рублей, зафиксированной в начале <nobr>2023-го.</nobr> На динамику направления повлияли замедление найма и пересмотр ИТ-бюджетов в финансовом секторе, который долгое время оставался одним из основных заказчиков специалистов этого профиля.</p> <p>Существенную переоценку пережила и мобильная разработка. От собственных пиков III квартала 2024 года до I квартала <nobr>2026-го</nobr> медианные зарплаты iOS-разработчиков снизились на <nobr>19–37%</nobr> в зависимости от грейда, Android-разработчиков — на <nobr>19–31%.</nobr> Сильнее всего коррекция затронула специалистов уровня Middle.</p> <p>Наиболее устойчивыми оказались направления, спрос на которые связан с долгосрочными задачами бизнеса. После пика зарплаты архитекторов информационной безопасности снизились не более чем на 1%, а медианы DevSecOps сохранились на прежнем уровне. В направлении 1С зарплаты по четырём из шести исследованных ролей не изменились по сравнению с III кварталом 2025 года. Относительно небольшую коррекцию также показали Frontend, DevOps и SRE.</p> <p>При этом в период роста отдельные роли показали особенно заметную динамику. От начала наблюдений до своих максимальных значений медианные зарплаты бизнес-аналитиков уровня Middle выросли на 67%, системных аналитиков Middle — на 66%. Архитекторы информационной безопасности уровня Middle прибавили 50%, DBA Lead — 46%, а DBA Senior — 43%. Это показывает, что общая коррекция не отменила структурный спрос на отдельные компетенции, хотя после пика III квартала 2025 года динамика стала разнонаправленной.</p> Кадровый системный интегратор SENSE провёл исследование динамики зарплат российских ИТ-специалистов на основе данных более … message https://www.itweek.ru/themes/detail.php?ID=235355 Mon, 17 Aug 2026 11:50:26 +0300 <p>Российский разработчик систем управления базами данных Postgres Professional объявил о выходе Postgres ProGate 1.4.0 — очередного обновления платформы миграции и репликации данных. Ключевое новшество версии — поддержка аналитической СУБД для гибридных нагрузок Postgres Pro AXE с загрузкой в S3-совместимое хранилище, что открывает заказчикам новые сценарии для построения аналитических хранилищ. Также в релиз вошла функциональность по повышению производительности утилит, укреплению безопасности и переработке механизма интроспекции схем данных.</p> <p>Postgres ProGate предназначена для проектов миграции, разового переноса данных и непрерывной репликацей между СУБД. Продукт помогает автоматизировать ключевые этапы работы с данными: первичную загрузку, синхронизацию изменений в режиме, близком к реальному времени, и проверку корректности переноса.</p> <p>Главное новшество версии — поддержка аналитической СУБД AXE в качестве приёмника данных с возможностью загрузки в S3-совместимое хранилище. Это расширяет сценарии использования платформы для построения современных аналитических хранилищ и data lake-решений на базе экосистемы Postgres Professional.</p> <p>Также одним из наиболее стала полная переработка механизма интроспекции. Реализована асинхронная обработка, что заметно ускоряет интроспекцию схем с большим количеством таблиц. Добавлена поддержка проверки привилегий доступа к схемам и таблицам, а также проверки совместимости подключений для prosync, включая права на чтение таблиц, — результаты доступны через API. Улучшено автоматическое сопоставление схем и таблиц для задач трансфера на основе совпадения имён.</p> <p>Утилита procopy получила более гибкий контроль над параллельной обработкой задач. Добавлен параметр sub_task_count, определяющий, на сколько подзадач может разбиваться исходная задача копирования, при этом расчёт размера подзадач теперь выполняется автоматически, а параметр sub_task_rows переведён в статус deprecated. Появился флаг force_restart_task, позволяющий перезапускать задачи без очистки данных и без изменения идентификатора задачи — это удобно для регулярных переносов данных, например, снапшотов T-1.</p> <p>Кроме того, в procopy и prosync добавлен параметр disable_constraint_checks, который отключает проверку ограничений и пользовательских триггеров на время записи батча в целевую PostgreSQL-совместимую БД, что ускоряет загрузку в сценариях, где целостность гарантируется на стороне источника или последующей верификацией.</p> <p><nobr>CDC-репликация</nobr> стала стабильнее и быстрее. Добавлена опция single_loader, которая позволяет для конкретной таблицы принудительно использовать один загрузчик, обеспечивая последовательную обработку изменений для таблиц, связанных внешними ключами. Исправлена ошибка считывания записей с большими значениями SCN из онлайн-журналов Oracle. Устранено удержание WAL-файлов на источниках PostgreSQL при редких изменениях за счёт улучшения механизма продвижения слотов логической репликации. Повышена производительность применения изменений для Oracle.</p> <p>Добавлена фиксация блокировки учётной записи пользователя при превышении лимита неудачных попыток ввода пароля. Все компоненты системы переведены на Go 1.26.5, а Apache Thrift обновлён до версии v0.23.0 с устранением ранее обнаруженных уязвимостей.</p> <p>«Поддержка Postgres Pro AXE в качестве приёмника данных — это новый вектор развития продукта. Если раньше ProGate использовался преимущественно для миграции и репликации между операционными базами данных, то теперь платформа закрывает и сценарий поставки данных в аналитику с загрузкой в S3-совместимые хранилища. Это существенно расширяет область применения продукта и открывает нашим заказчикам возможность строить аналитические конвейеры на единой технологической платформе. В сочетании с переработанной интроспекцией, которая в разы ускоряет работу со схемами из сотен и тысяч таблиц, новыми опциями управления параллелизмом в procopy и усилением безопасности мы сделали серьёзный шаг в развитии платформы и дали нашим клиентам новые споособы решения своих бизнес-задач», — прокомментировал руководитель продукта Postgres ProGate Евгений Кривов.</p> Российский разработчик систем управления базами данных Postgres Professional объявил о выходе Postgres ProGate 1.4.0 — … message https://www.itweek.ru/themes/detail.php?ID=235352 Mon, 17 Aug 2026 09:43:07 +0300 <p><em>Искусственный интеллект делает более быстрым и простым извлечение конфиденциальной личной информации из обычных бизнес-данных. Вице-президент Gartner Барт Виллемсен объясняет порталу </em><em>InformationWeek</em><em>, почему это происходит и что должны делать руководители служб информационной безопасности (</em><em>CISO</em><em>).</em></p> <p>Правила регулирования конфиденциальности данных, например европейский GDPR и американские федеральные законы, такие как HIPAA, больше не достаточны для защиты персональных данных в эпоху ИИ.</p> <p>Gartner <a href="https://www.gartner.com/en/documents/7864881">прогнозирует</a>, что к 2029 г. большинство инцидентов, связанных с нарушением конфиденциальности, будут вызваны ИИ-выводами об отдельных лицах, а не прямым раскрытием личной информации, такой как имена, адреса и номера социального страхования.</p> <p>По словам Виллемсена, способность ИИ быстро распознавать образы означает, что злоумышленникам больше не нужно красть или покупать учетные данные, чтобы получить конфиденциальную информацию о людях. Анонимизация данных сама по себе не обеспечивает достаточной защиты, поскольку алгоритмы ИИ могут повторно идентифицировать людей или выводить конфиденциальные атрибуты из анонимизированных наборов данных.</p> <p>«Настоящей анонимизации не существует, за исключением фактического удаления данных. Атака на основе инференса очень эффективна, потому что она затрагивает всё, а не только непосредственно идентифицируемые репозитории», — говорит Виллемсен.</p> <p>По мере совершенствования генеративного ИИ и машинного обучения эти технологии могут выводить конфиденциальные личные характеристики — такие как состояние здоровья или поведенческие модели — из анонимизированных или агрегированных данных.</p> <p>«Современные модели могут восстанавливать личные данные, используя поведенческие модели, показатели использования и агрегированные записи транзакций. Например, ИИ может идентифицировать людей по данным о поездках, социальным сетям, рентгеновским снимкам, ЭКГ, МРТ, даже походке или практически любой комбинации из примерно трёх транзакций», — объясняет Виллемсен.</p> <p>Кроме того, по его словам, когда ИИ галлюцинирует или создает синтетические данные о людях, эти неверные данные могут вызывать реальные проблемы. Например, предвзятость и галлюцинации ИИ могут привести к неправомерному тюремному заключению и серьезным ошибкам в юридических исследованиях.</p> <p>Последствия выходят далеко за рамки нарушений конфиденциальности, считает Эндрю Обадиару, CISO компании Cobalt. «ИИ может определить состояние здоровья человека, его финансовое положение, влияние внутри организации или вероятность ответа на фишинговое письмо, не имея доступа к медицинской карте или кадровому делу», — говорит он.</p> <p>По его словам, данные, которые не кажутся конфиденциальными — такие как справочники сотрудников, отношения с поставщиками, активность в социальных сетях или взаимодействие с клиентами — могут стать ценными, когда ИИ связывает эти фрагменты. ИИ может использовать их для определения структуры подчиненности, администрирования систем, взаимоотношений между руководителями, полномочий по расходам или того, какой инженер отвечает за критически важную производственную систему. Затем злоумышленники могут использовать эти данные, чтобы сделать свои атаки гораздо более точными.</p> <p>«В результате фишинговые кампании становятся значительно более убедительными, компрометация корпоративной электронной почты происходит быстрее, вымогательство — более целенаправленным, а операции по вторжению — гораздо эффективнее, поскольку злоумышленник уже знает, кого атаковать, прежде чем отправить первое письмо», — поясняет Обадиару.</p> <p>Организациям необходимо начать задумываться не только о том, какие данные они собирают, но и о том, «что эти данные раскрывают, когда они объединяются, сопоставляются и интерпретируются все более совершенными системами ИИ», — добавляет он. И, из-за развития технологий ИИ, правила обеспечения конфиденциальности, которые исторически были сосредоточены на непосредственно идентифицируемых данных, должны также распространяться на косвенно или повторно идентифицируемый контент.</p> <p>«Сочетание данных, зарегистрированных где угодно, доступа к ним по всему миру (случайно или в результате злонамеренного взлома) и возможностей, доступных любому, кто хочет получить доступ к данным с помощью современных аналитических и генеративных ИИ-технологий, — вот что отличает сегодняшнюю ситуацию. Кроме того, организации практически не очищают данные, которые им больше не нужны», — говорит Виллемсен.</p> <p>По его словам, риск повторной идентификации данных существовал задолго до сегодняшнего бума ИИ, но ИИ значительно ускоряет этот процесс. Он ссылается на <a href="https://www.nature.com/articles/s41467-019-10933-3.pdf">исследование</a> 2019 г., проведенное специалистами в области науки о данных Люком Роше, Жюльеном М. Хендрикксом и Ивом-Александром де Монжуа, которые разработали генеративную графическую модель для повторной идентификации людей. «Используя нашу модель, мы обнаружили, что 99,98% американцев будут правильно идентифицированы в любом наборе данных с использованием 15 демографических атрибутов», — написали они.</p> <h3>ИИ усиливает угрозу повторной идентификации</h3> <p>По словам Обадиару, что изменилось с развитием ИИ, так это то, что теперь «скорость на стороне злоумышленников — и масштаб». «Пять лет назад создание подробных профилей тысяч потенциальных жертв было экономически нецелесообразным. Сегодня это не так», — отмечает он.</p> <p>Виллемсен обращает внимание на <a href="https://arxiv.org/pdf/2602.16800">исследование</a> 2026 г., проведенное инженерами Саймоном Лерменом, Даниэлем Палекой, Джошуа Свансоном, Майклом Аэрни, Николасом Карлини и Флорианом Трамером. Авторы обнаружили, что больше языковые модели (LLM) могут повторно идентифицировать людей, «используя только псевдонимизированные онлайн-профили и переписки, что сопоставимо с тем, что может выполнить опытный следователь за много часов работы».</p> <p>Примечательно пояснение авторов: «В каждой ситуации методы на основе LLM значительно превосходят классические базовые методы, достигая до 68% полноты при 90% точности по сравнению с почти 0% для лучшего метода без применения LLM. Наши результаты показывают, что практическая неопределенность, защищающая псевдонимных пользователей в Интернете, больше не действует и что модели угроз для конфиденциальности в Интернете необходимо пересмотреть».</p> <p>По словам Обадиару, лучшие атаки на основе инференса совсем не выглядят как атаки. «Злоумышленник может начать с LinkedIn, публичных документов, социальных сетей, украденных учетных данных, активности на GitHub и утечек маркетинговых баз данных. Ни один из этих наборов данных сам по себе не представляет особой ценности. Но ИИ выполняет сложную работу по их объединению», — отмечает он.</p> <p>По словам Виллемсена, чтобы снизить риски нарушения конфиденциальности, основанные на инференсе, CISO следует начать с обеспечения управления данными на протяжении всего их жизненного цикла и удаления данных, как только они перестанут приносить бизнес-ценность, которая оправдывала бы затраты и риски их защиты. «У данных есть жизненный цикл, и мы знаем, что хранить их вечно — это неразумно. Поэтому жестко запрограммируйте его конец», — советует он.</p> <h3>Шаги по устранению основанных на инференсе рисков от Gartner</h3> <p>По словам Виллемсена, для CISO защита от угроз, основанных на ИИ-инференсе, начинается с управления ИИ. Вот его советы:</p> <ul> <li><strong> Управление ИИ.</strong> Внедрите в разработку ИИ установление механизмов защиты конфиденциальности на этапе проектирования и регулярно оценивайте риски предвзятости или инференса.</li> <li><strong> Внедрение технологий повышения конфиденциальности (PET).</strong> PET — это «набор технологических инструментов», — говорит Виллемсен. Эти технологии защищают персональные данные, обрабатывая их в защищенном состоянии или в рамках «конфиденциальных вычислений». К PET относятся дифференциальная конфиденциальность, синтетические данные, машинное обучение с учетом конфиденциальности и гомоморфное шифрование, которое выполняет вычисления над зашифрованными данными без необходимости их предварительного расшифрования. PET могут свести к минимуму вероятность повторной идентификации ИИ отдельных лиц, даже если ИИ проанализирует данные.</li> <li><strong> Контроль жизненного цикла.</strong> Сбор данных должен ограничиваться основными потребностями бизнеса и включать контроль доступа. Данные следует удалять, как только они перестают быть полезными и/или их защита становится экономически нецелесообразной. Что касается управления данными, то Виллемсен советует проводить «последовательную и очень тщательную очистку».</li> <li><strong> Повышение кибербезопасности для угроз, основанных на ИИ.</strong> Организациям следует расширять свои традиционные подходы к кибербезопасности, уделяя приоритетное внимание расширенному мониторингу, обнаружению аномалий и возможностям планирования сценариев для выявления угроз, основанных на инференсе.</li> <li><strong> Прозрачность и человеческий контроль.</strong> Задокументируйте, где в сети организации уместно использование ИИ-инференса, регулярно проводите аудит систем ИИ и поддерживайте участие человека в проверке выводов, генерируемых ИИ, прежде чем допустить технологию действовать с конфиденциальными данными.</li> </ul> <p>«Не стоит недооценивать риски, связанные с различными типами ИИ, прежде чем использовать какой-либо из них», — заключает Виллемсен.</p> Искусственный интеллект делает более быстрым и простым извлечение конфиденциальной личной информации из обычных … article https://www.itweek.ru/themes/detail.php?ID=235351 Mon, 17 Aug 2026 09:20:51 +0300 <p><em>Корпоративные озера-хранилища данных (</em><em>data</em> <em>lakehouse</em><em>) эволюционируют. Изначально предназначенные в первую очередь для консолидации данных для аналитики, сегодня озера-хранилища данных стали операционной основой для агентного искусственного интеллекта, предоставляя надежные, управляемые и данные реального времени, необходимые интеллектуальным агентам для рассуждений и действий, пишет в корпоративном блоге Ноэль Юханна, вице-президент и главный аналитик </em><em>Forrester</em><em>.</em></p> <p>По мере того, как ИИ переходит от генерации инсайтов к выполнению бизнес-процессов, организациям необходимо переосмыслить ожидания от своей lakehouse-платформы. Эта эволюция переопределяет оценку поставщиков, приоритизируя готовность к ИИ, доверие, открытость и операционный интеллект, а не производительность хранения и запросов.</p> <h3>Новые возможности lakehouse поддерживают сценарии использования агентного ИИ</h3> <p>Чтобы помочь организациям справиться с этим сдвигом, в отчете «Forrester Wave: Data Lakehouses, Q3 2026» представлена оценка 14 ведущих поставщиков lakehouse. Она отражает меняющуюся роль озер-хранилищ в эпоху ИИ и определяет возможности, которые будут отличать платформы, способные поддерживать агентный ИИ корпоративного масштаба. Хотя традиционные возможности управления данными остаются важными, в отчете ясно показано, что готовые к будущему озера-хранилища должны также служить исполнительным уровнем для приложений, управляемых ИИ.</p> <p>Ключевые выводы из отчета заключаются в следующем:</p> <ul> <li> <strong>Lakehouse</strong> <strong>становится исполнительным уровнем для агентного ИИ.</strong> Озеро-хранилище больше не ограничивается хранением и предоставлением данных для аналитики. Кроме этого оно должно постоянно предоставлять надежный, управляемый контекст реального времени, который агенты ИИ могут использовать для рассуждений, принятия решений и действий. Этот сдвиг коренным образом меняет подход организаций к оценке поставщиков. Вместо того чтобы отдавать приоритет только возможностям хранения, покупатели должны оценивать, насколько эффективно озеро-хранилище данных поддерживает ИИ-нативные рабочие нагрузки, операции в режиме реального времени и интеграцию с корпоративными экосистемами ИИ.</li> <li><strong> Доверие является основой готового к ИИ озера-хранилища данных.</strong> Поскольку агенты ИИ все чаще принимают автономные решения, недостатки в качестве, управлении, отслеживании происхождения или безопасности данных становятся рисками выполнения, а не аналитическими ограничениями. Организациям следует отдавать приоритет lakehouse-платформам, которые включают в себя управление данными, автоматическое отслеживание их происхождения, детальный контроль доступа, непрерывный мониторинг качества данных и обеспечение соблюдения политик в качестве основных возможностей платформы.</li> <li><strong> Открытые архитектуры имеют решающее значение для долгосрочного успеха ИИ. </strong>ИИ быстро развивается, требуя от организаций интеграции множества моделей, фреймворков оркестрации, облачных сред и сервисов данных. Озера-хранилища, построенные на основе открытых форматов таблиц, совместимых стандартов метаданных, расширяемых API и обмена данными без копирования, обеспечивают необходимую гибкость для адаптации, одновременно снижая зависимость от поставщика. При оценке поставщиков следует учитывать совместимость экосистем и архитектурную открытость как стратегические отличительные черты, а не как дополнительные функции.</li> <li><strong> Обеспечение использования ИИ является новым конкурентным преимуществом </strong><strong>lakehouse</strong><strong>-платформ.</strong> Хранение данных, масштабируемость и производительность запросов уже стали обязательными условиями. Сегодня отличительными чертами озер-хранилищ являются предоставление контекста реального времени, семантический интеллект, нативные векторные возможности и готовые к использованию ИИ сервисы данных, которые позволяют автономным агентам извлекать, анализировать и действовать на основе корпоративных данных. Организациям следует оценивать поставщиков на основе того, насколько эффективно их платформы поддерживают ИИ, поскольку эта возможность будет определять ценность для предприятий и конкурентное преимущество следующего поколения платформ данных.</li> </ul> <h3>Apache Fluss — новое lakehouse-нативное потоковое хранилище</h3> <p>Фонд Apache Software Foundation (ASF), глобальный центр разработки ПО с открытым исходным кодом, объявил о том, что Apache Fluss стал проектом верхнего уровня (TLP).</p> <p>Apache Fluss — это опенсорсная система потокового хранения для аналитики реального времени и ИИ. Она предоставляет уровень данных реального времени для lakehouse, объединяя потоковые данные, постоянно обновляемые таблицы и исторические данные lakehouse посредством общей абстракции таблиц. Fluss интегрируется с вычислительными движками, включая Apache Flink и Apache Spark, а также с открытыми lakehouse-форматами, включая Apache Paimon, Apache Iceberg, Apache Hudi и Lance.</p> <p>«Архитектура Lakestream от Fluss объединяет потоки данных с данными lakehouse, обеспечивая lakehouse возможности режима реального времени и одновременно сокращая дублирование данных и сложность конвейера обработки. Она доказала свою эффективность в масштабе основных производственных нагрузок электронной коммерции Alibaba, Это побудило нас открыть исходный код и передать Fluss в ASF. Я надеюсь, что Fluss станет открытой основой данных для озер-хранилищ реального времени и будет способствовать развитию аналитики и ИИ в открытой экосистеме данных», — сказал Фэн Ван, руководитель Open Data Platform в Alibaba Cloud.</p> Корпоративные озера-хранилища данных (data lakehouse) эволюционируют. Изначально предназначенные в первую очередь для … article https://www.itweek.ru/themes/detail.php?ID=235349 Fri, 14 Aug 2026 15:23:21 +0300 <p>Институт статистических исследований и экономики знаний (ИСИЭЗ) НИУ ВШЭ продолжил отслеживать направления, формирующие передний край глобальной исследовательской повестки. Среди выделенных по итогам 2025 года 890 фронтиров самые высокие значения индекса значимости у тематик, связанных с решением экологических проблем, цифровой трансформацией и психическим здоровьем человека.</p> <p>Климатическая повестка выходит за рамки прогнозирования изменений температуры. Исследования также охватывают поведение людей, оценку рисков и адаптацию к новым условиям, что требует объединения естественных и общественных наук. Одновременно меняется сам подход к взаимодействию с природой: антропоцентрическая парадигма, ставящая во главу угла интересы человека, постепенно уступает место экоцентрической.</p> <p>Рост городского населения и расширение урбанизированных территорий меняют структуру землепользования, усиливают нагрузку на природные ресурсы. Важным инструментом адаптации и планирования территорий становятся геоинформационные системы. В городах формируются локальные климатические эффекты, включая острова тепла и изменение режима осадков, повышается уязвимость к экстремальным погодным явлениям. Смягчать эти эффекты могут экосистемные услуги — секвестрация углерода, фильтрация загрязнителей и регулирование гидрологического режима. Гидротермальная карбонизация органических отходов позволяет получать энергетически ценные продукты и богатые углеродом материалы, что способствует развитию экономики замкнутого цикла.</p> <p>Необходимость снизить негативное воздействие на окружающую среду стимулирует развитие возобновляемой и водородной энергетики. Дальнейшее развитие топливных элементов и электролизеров во многом зависит от создания эффективных катализаторов. Наиболее перспективными считаются наночастицы благородных металлов, а более доступными альтернативами — оксиды никеля и кобальта и карбиды железа. В солнечной энергетике разрабатываются фотоэлектрические элементы нового поколения, в частности перовскитные и тандемные структуры, а также прозрачные проводящие покрытия.</p> <p>Для решения сложных задач уже недостаточно только наращивать вычислительные мощности: требуется одновременно собирать данные, моделировать процессы и управлять ими. В 2025 году заметно усилилась синергия вычислительных и измерительных технологий.</p> <p>ИИ из инструмента анализа превращается в технологию действия. Обработка данных переносится на периферию (edge) — непосредственно в устройства, датчики и локальные модули. В основе систем периферийного ИИ лежит машинное обучение, позволяющее интерпретировать разнородные и зашумленные данные без обращения к облачным центрам.</p> <p>В интеллектуальные системы управления все чаще встраивают нейросети, например для координации групп автономных роботов или управления роботизированными манипуляторами. Широко применяется глубокое обучение, позволяющее работать с неструктурированными данными и оперативно реагировать на изменения.</p> <p>Чем сложнее модели, тем важнее регуляризация. В критических областях применения ИИ особенно высоки требования к устойчивости моделей и способности точно обрабатывать новые данные. Например, медицинские диагностические системы должны надежно работать для пациентов, чьи демографические характеристики отличаются от представленных в обучающей выборке.</p> <p>Разработки на стыке ИИ и физики сокращают путь сигнала от регистрации до его интерпретации. Усиливать и стабилизировать сигналы позволяют резонаторные технологии, применяемые в высокочувствительных радиочастотных и сенсорных устройствах. Так, фотонные «электронные носы» на основе массивов микрорезонаторов формируют уникальный «оптический отпечаток» анализируемой смеси, а локальный ИИ-интерфейс распознает его непосредственно на чипе.</p> <p>Спектроскопия, выделенная в самостоятельный фронтир, позволяет увидеть то, что прежде оставалось скрытым. В 2025 г. коллаборация BASE в ЦЕРН впервые продемонстрировала применение крайне значимой для изучения асимметрии материи и антиматерии когерентной спектроскопии квантовых переходов спина одиночного антипротона. В прикладной сфере поверхностно-усиленная рамановская спектроскопия (SERS) на наночастицах позволяет регистрировать сигналы отдельных молекул и в комбинации с ИИ-анализом спектров разрабатывать методы цитологической диагностики.</p> <p>В классических дисциплинах такой объединенный инструментарий обеспечивает переход от наблюдения к целенаправленному управлению процессами на микро- и наноуровне. В физике совершенствуются методы управления светом, электрическими сигналами, магнитными состояниями и квантовыми эффектами, которые используются в системах спутниковой связи и навигации, жидкокристаллических дисплеях, кремниевых фотонных устройствах и голографическом хранении данных. В химии сочетание измерений и моделирования поддерживает молекулярный дизайн: изучение процессов гидрогенизации и динамики адсорбции в нестационарных условиях помогает создавать материалы и катализаторы с заданными свойствами. Такие разработки способствуют миниатюризации оптических чипов, росту скорости обработки информации и плотности ее записи.</p> <p>Крупный блок ведущих фронтиров образуют исследования в области развития человеческого потенциала и связанные с поддержанием здоровья как человека, так и животных. Их общая черта — внимание к раннему выявлению рисков: от молекулярных и клеточных изменений до механизмов психических расстройств и факторов развития ребенка.</p> <p>В биомедицине и ветеринарии биомаркеры позволяют отслеживать изменения задолго до появления выраженных клинических признаков, обеспечивая переход от симптоматической к ранней, точной и персонализированной диагностике. Анализ сывороточных биомаркеров помогает выявлять воспалительные процессы, метаболические нарушения, опухоли, повреждения тканей и др. Другой фронтир связан с антиоксидантами, подавляющими свободнорадикальное окисление, которое может запускать и усиливать различные патологические процессы.</p> <p>Одна из центральных тематик этого блока — ментальное здоровье. Возрастает значение исследований, направленных на выявление биологических, психологических и средовых механизмов формирования психических расстройств, а также факторов, способствующих сохранению психологической устойчивости. Профилактика ментальных расстройств затрагивает и сферу воспитания детей, согласно результатам исследований, качество связи родителя с ребенком в раннем возрасте оказывает прямое влияние на метилирование ДНК и формирование архитектуры нейронных сетей мозга. Эта проблематика имеет не только медицинское, но и социальное, экономическое и демографическое значение, поскольку ментальное здоровье во многом определяет уровень качества жизни человека.</p> <p>Карта ведущих научных фронтиров отражает поиск системных ответов на глобальные вызовы. Сохранение планеты становится фокусом экологических исследований, работы в области биомедицины направлены на повышение качества жизни человека, фундаментальную основу новых решений обеспечивают биология, физика и химия, цифровые технологии расширяют возможности измерения и управления. Перечень фронтиров может служить ориентиром при выборе тем исследований и определении приоритетов поддержки науки и технологий.</p> Институт статистических исследований и экономики знаний (ИСИЭЗ) НИУ ВШЭ продолжил отслеживать направления, формирующие … message https://www.itweek.ru/themes/detail.php?ID=235347 Fri, 14 Aug 2026 10:25:07 +0300 <p><em>Облачные провайдеры растят DevOps-инженеров, которых потом переманивает BigTech. Почему компании продолжают вкладываться в людей, зная, что те уйдут, — и что это говорит о рынке IT-кадров?</em></p> <p>Хороший DevOps-инженер готовится к докладу на конференции — шлифует слайды, прогоняет демо. Он еще не знает, что через два месяца уволится. Не потому что плохо платили или надоело — просто выступил, к нему подошли, предложили больше. Это не провал HR, а нормальная механика рынка, в которой облачные провайдеры играют специфическую роль — они растят специалистов, которых потом хотят все.</p> <h3>Рынок сжался — но не для всех</h3> <p>В 2025 году вакансий для айтишников стало на 26% меньше, чем годом ранее. Казалось бы, передышка для работодателей. Но облачные провайдеры её не почувствовали: клиентская база росла, крупный бизнес ускорял переход в облако, и спрос на опытных инженеров оставался высоким. По <a href="https://www.techtarget.com/whatis/feature/Tech-job-market-statistics-and-outlook">данным </a>TechTarget, 87% технических директоров по-прежнему говорят, что не могут найти нужных специалистов.</p> <p>Проблема структурная. Технологические навыки устаревают примерно за 2,5 года, а университеты обновляют программы куда медленнее. Система подготовки кадров просто не рассчитана на такую скорость изменений — и отрасль давно научилась справляться с этим своими силами.</p> <h3>Как устроена карьерная труба</h3> <p>В провайдерской среде есть устойчивая модель, которую внутри индустрии неформально называют «трубой». Специалист приходит с минимальными навыками — в техподдержку, на дежурную смену, в администрирование. Работает на больших объемах и разнообразных задачах. Постепенно растёт. Через несколько лет из него получается инженер с реальной экспертизой.</p> <p>Если посмотреть на DevOps-инженеров в облачных командах, то 9 из 10 — те, кто проросли внутри компании, а не пришли готовыми. Это не случайность и не особенность одного провайдера. Это общая логика отрасли: в отличие от BigTech, где специалист приходит уже сформированным под конкретную задачу, провайдерская среда по природе своей многоуровневая. Здесь есть ступеньки, на которых можно учиться в процессе работы — и это работает.</p> <h3>Чем облако привлекает инженера</h3> <p>Объяснять выбор в пользу провайдера только деньгами — упрощение. Суть в характере работы.</p> <p>DevOps в корпоративном IT обслуживает одну команду, настраивает один пайплайн, работает по гайдам. Задача решена — переключается на следующую, примерно такую же. В облачном провайдере задача другая: не развернуть инфраструктуру для своей команды, а создать сервис, который потом будет предоставляться тысячам клиентов в автоматизированном режиме. Это ближе к разработке, чем к эксплуатации. Другой уровень сложности, другое мышление.</p> <p>Именно поэтому опыт из облака ценится на рынке: инженер, проработавший в провайдере, приходит в BigTech с насмотренностью и навыками, которые там сложно получить иначе. Рынок это подтверждает — по <a href="https://enigmai.ru/salary/devops/devops-salary-2026/">данным</a> Enigma Intelligence, наиболее востребованными в <nobr>2025-2026</nobr> годах стали специалисты в Platform Engineering и DevSecOps, то есть именно в том, чем занимаются облачные команды каждый день.</p> <h3>Когда специалист уходит</h3> <p>Конференции стали обязательной частью профессиональной жизни инженера. Выступить с докладом — значит показать экспертизу, прокачать личный бренд, поделиться опытом с сообществом. Всё это так. Но у этой медали есть обратная сторона: человек всё о себе рассказал, экспертизу показал, контакты на последнем слайде оставил. Хедхантерам остается только подойти после секции.</p> <p>Однажды так мы потеряли одного из сильных инженеров: выступил с докладом, познакомился с нужным человеком и через два месяца принял оффер. Обидно? Отчасти. Неожиданно? Нет. Такова механика открытого рынка — и мы сами участвуем в ней с обеих сторон.</p> <p>Переходы между провайдерами — обычная история. Специалисты идут туда, где больше объёмы, интереснее задачи, выше зарплата. Это работает в обе стороны. Главное — понимать, что удержать человека силой невозможно, а вот создать среду, из которой не хочется уходить, — вполне.</p> <p>К слову, к клиентам инженеры уходят редко — и это не случайно. В облачном провайдинге специалист не привязан к конкретному заказчику: с ним работает команда, контакты ситуативны, личного коннекта, который мог бы перерасти в оффер, почти не возникает. Это механика аутсорс-разработки, не провайдинга.</p> <h3>Рынок труда: от голода к насыщению</h3> <p>Ещё полтора года назад картина была другой. Вакансия могла висеть полгода — и ни одного подходящего кандидата, даже при конкурентной зарплате. Дефицит ощущался физически: планы запуска продуктов сдвигались, нагрузка на команды росла.</p> <p>С лета 2025 года ситуация изменилась. Крупные компании начали тихие сокращения: официальных объявлений нет, но мидлы с именитым бэкграундом появились на рынке. Параллельно в BigTech заработала механика «банки» — когда проект закрывается, команду не распускают сразу, а дают несколько месяцев на поиск места внутри. Кто не находит — выходит на рынок.</p> <p>Итог: рынок соискателя превратился в рынок работодателя. Вакансии закрываются быстрее, а зарплатная гонка утихает. 47% IT-специалистов <a href="https://www.newstaff.ru/trendy-najma-it-specialistov-v-2025-godu-chto-menyaetsya-na-rynke/">называют</a> главным фактором при выборе работы гибкий формат и возможность роста — зарплату ставят на первое место только 18%. Для провайдеров, которые исторически делают ставку на развитие сотрудников, — это сигнал в нужную сторону.</p> <h3>Что дальше</h3> <p>Рост облачного рынка в России замедляется: <nobr>35-40%</nobr> несколько лет назад, около 29% в 2024 году, прогноз на <nobr>2026-й —</nobr> порядка 24%. При таком замедлении найм тоже будет сжиматься. Компании, которые в период бума набирали людей «с запасом», сейчас пересматривают ФОТ и смотрят, что команды реально делают.</p> <p>Но структурная история с «трубой» никуда не денется — и в этом, пожалуй, главное. Провайдеры продолжат выращивать специалистов снизу, потому что иначе не работает. Готовых инженеров с нужным стеком на рынке не хватало и не будет хватать, особенно с учётом того, что автоматизация убирает начальные позиции и подпитка снизу для всей отрасли постепенно иссякает.</p> <p>На Западе это уже институализировалось: Microsoft запустила Datacenter Academy, AWS строит партнёрства с техническими школами через Workforce Accelerator — провайдеры сами пишут учебные программы, поставляют оборудование для лабораторий, финансируют стипендии. В России этот путь только начинается.</p> <p>Инженер, который вырос в провайдере и ушел к конкуренту или в BigTech, — это не только потеря. Он знает продукт изнутри, иногда рекомендует его клиентам, иногда возвращается. Это другая форма лояльности. И она тоже работает.</p> <p>#IMAGE_235348#</p> Облачные провайдеры растят DevOps-инженеров, которых потом переманивает BigTech. Почему компании продолжают вкладываться … article Сергей Рыжков, руководитель онлайн-продаж и аналитики Рег.облака https://www.itweek.ru/themes/detail.php?ID=235345 Fri, 14 Aug 2026 10:08:55 +0300 <p><em>Поставщики систем планирования ресурсов предприятия (ERP) быстро позиционируют автономные операции как следующую «платформенную» задачу, но реальным ограничением для их внедрения станет корпоративный контроль — смогут ли технологические руководители проверять действия агентов, управлять их использованием и сохранять бизнес-смысл в условиях фрагментации, пишет в корпоративном блоге Фарам Медхора, главный аналитик </em><em>Forrester</em><em>.</em></p> <p>Фрагментация — это реальность работы ERP-систем: согласно исследованию Forrester «Enterprise Applications Software Survey 2026», только 7% лиц, принимающих решения по ERP на предприятиях, используют только один экземпляр системы. В сложной многоэкземплярной инфраструктуре агенты будут наследовать региональные варианты, приобретенные системы и противоречивые определения, что выявит недостатки управления, которые технологические руководители могли терпеть во времена, когда автоматизация оставалась под контролем человека.</p> <p>Если технологические руководители хотят начать пожинать плоды агентных ERP-систем, им не стоит начинать с каталога агентов. Вместо этого им следует начать с модели управления, чтобы понять, насколько они смогут подтвердить, оценить и защитить автономность с помощью переносимости.</p> <p> #IMAGE_235346#</p> <h3>Контроль за доказательствами: верификация — это новый скоростной лимит ERP</h3> <p>Агентная ERP создает проблему контроля. Каждое действие агента требует подтверждения: кто его одобрил, какая учетная запись его выполнила, какие данные были использованы и кто несет ответственность за результаты, когда действия агента достигают этапов проводок, сверки или закрытия.</p> <p>Эта проблема контроля затрагивает наиболее уязвимые места в большинстве ERP-систем: управление данными, контроль и безопасность. Согласно нашим данным, 65% пользователей ERP оценивают точность данных как сложную проблему, и 64% говорят то же самое о безопасности и соответствии нормативным требованиям. Риски уже очевидны. Уязвимость BodySnatcher (CVE-2025-12420) показала, как некорректная аутентификация агентов может позволить осуществлять привилегированное подмену личности в ServiceNow, а дело Moffatt против Air Canada (2024) подтвердило, что компании (а не поставщик) остаются ответственными за предоставленную ИИ информацию о клиентах.</p> <p>Агентную ERP-систему следует рассматривать в первую очередь с точки зрения обеспечения контроля, а во вторую — с точки зрения автоматизации. Сегментируйте автономность по классам транзакций: расширяйте возможности консультативных агентов сейчас, требуйте полной отслеживаемости для контролируемого выполнения и откладывайте автономное выполнение до тех пор, пока команды не смогут доказать ответственность за исключения, предоставить аудиторские доказательства и возможность отката.</p> <p>Для этого вам потребуется перейти к стандартизированному ядру, которое вы откладывали, поскольку агенты будут усиливать вариативность процессов, данных и контроля. Вам также потребуется сначала провести каждого кандидата на автоматизацию через стандартизацию, и если вы не можете его стандартизировать, это означает, что вы не можете его безопасно автоматизировать.</p> <h3>Контроль за ценой: счетчик — это новый контроль объема работ</h3> <p>Ценообразование ERP-систем движется в сторону моделей, основанных на использовании, кредитных пулах и многоуровневых счетчиках. Это переносит риск с прайс-листа поставщика на ваш текущий тариф. Большинство CIO по-прежнему договариваются о продлении как о фиксированных затратах, но эта привычка устареет по мере роста использования агентов. Как только агенты начнут применяться в повседневной работе, использование может превысить бюджетные рамки. Фактически, 30% руководителей, принимающих решения в сфере корпоративного SaaS, уже отмечают непредсказуемость ценообразования на основе использования как проблему.</p> <p>Мы уже видим, как контроль дает сбой. Uber исчерпала свой бюджет на ИИ за несколько месяцев после того, как применение Claude Code широко распространилось среди инженеров. Salesforce учитывает использование Agentforce через Flex Credits с учетом превышения лимитов. Покупатели RISE with SAP колеблются, когда не могут самостоятельно отслеживать лицензирование и использование.</p> <p>Это означает, что технологические руководители никогда не должны подписывать соглашения об использовании агентной ERP без телеметрии со стороны покупателя, жестких ограничений, триггеров превышения лимитов и сценариев потребления, смоделированных финансовыми специалистами. Помните, если поставщик контролирует и счетчик, и интерпретацию показаний счетчика, вы не контролируете программу.</p> <h3>Контроль за переносимостью: следующая проблема привязки к поставщику — семантическая</h3> <p>Перенос ваших данных к новому поставщику больше не является трудной задачей. Трудность заключается в том, чтобы разобраться, как старый поставщик определял ваш бизнес. Если ваши KPI, бизнес-сущности и связи данных построены вокруг модели одного поставщика, вы остаетесь привязанными к нему даже после миграции данных. Это то, что мы называем семантической зависимостью. Открытые стандарты, такие как MCP и Agent2Agent, которые могут снизить барьеры для подключения, теперь развиваются под эгидой Linux Foundation, но этого недостаточно (даже близко) для обеспечения переносимости сути бизнеса.</p> <p>Технологическим лидерам необходимо ознакомиться с новым термином: семантическая переносимость. В дальнейшем вам нужно будет включать семантическую переносимость в каждое продление контракта. Это означает требование прав на экспорт определений KPI, моделей сущностей и связей основных данных, прежде чем вы будете добавлять больше интеллектуальных функций в контекстный слой поставщика. Это крайне важно, потому что то, что вы не можете экспортировать сегодня, завтра станет вашей стоимостью перехода.</p> <h3>Масштабируйте операционную модель до развертывания агентов</h3> <p>Наиболее эффективные CIO не будут гнаться за самым эффектным помощником. Они сначала определят ответственность: кто утверждает агентов, кто отвечает за ожидания, кто контролирует бюджеты потребления и кто управляет семантикой. Именно с этой моделью будут работать ваши финансовые директора, аудиторы и клиенты.</p> Поставщики систем планирования ресурсов предприятия (ERP) быстро позиционируют автономные операции как следующую «платформенную» … article https://www.itweek.ru/themes/detail.php?ID=235343 Fri, 14 Aug 2026 09:57:10 +0300 <p>Доменная отрасль во многих странах постепенно интегрируется с системами цифровой идентификации. Государства рассматривают доменную инфраструктуру как часть общей системы кибербезопасности, устойчивости онлайн-сервисов и управления онлайн-активами. Россия также движется в этом направлении: с сентября 2026 года для доменов в зонах .ru, .рф и .su ключевые операции будут связаны с подтверждением администратора через ЕСИА.</p> <p>Рассмотрим, как меняется регулирование доменной отрасли в разных странах, как российский подход соотносится с международной практикой и что новые требования означают для бизнеса.</p> <h3>В России меняются правила регистрации доменов</h3> <p>С 1 сентября 2026 года вступают в силу новые правила регистрации и продления доменов в зонах .ru, .рф и .su. Администраторам потребуется обязательная идентификация через ЕСИА — систему авторизации на портале «Госуслуги». Изменения закреплены федеральным <a href="https://www.consultant.ru/document/cons_doc_LAW_523115/">законом № <nobr>569-ФЗ</nobr></a>.</p> <p>Новые требования распространяются на все категории администраторов. Физическим лицам и индивидуальным предпринимателям понадобится подтвержденная учетная запись на Госуслугах. Юридическим лицам необходимо зарегистрировать организацию на портале и назначить сотрудника с подтвержденными полномочиями для управления доменами. Иностранные граждане и компании также должны будут учитывать новые требования: пройти идентификацию через ЕСИА при наличии такой возможности либо заранее выбрать иную допустимую модель управления доменом. Некоторые регистраторы предлагают решение «Доверенный администратор» (trustee-сервис), которое позволяет управлять доменом в зонах .ru, .рф и .su без идентификации через Госуслуги. Домен регистрируется на российское юрлицо с подтвержденной записью в ЕСИА, а вы сохраняете полный контроль через свой личный кабинет.</p> <p>Обязанность указывать достоверные данные при регистрации доменов существовала и раньше: администраторы должны были предоставлять регистраторам актуальные паспортные, контактные и регистрационные данные. Однако проверка этой информации в значительной степени оставалась ручной и зависела от предоставленных документов.</p> <p>Теперь система предполагает цифровое подтверждение данных через государственную инфраструктуру идентификации. Это должно повысить прозрачность доменной среды, упростить установление владельцев интернет-ресурсов и усилить меры против мошеннических и противоправных онлайн-активностей.</p> <p>Для пользователей регистрация и продление доменов в стандартных сценариях также станут проще: часть данных будет автоматически заполняться на основе информации из ЕСИА без необходимости отдельно загружать документы и подтверждения. Но для компаний с неупорядоченным доменным портфелем новые правила могут выявить старые проблемы: домены, оформленные на бывших сотрудников, подрядчиков, старые юридические лица или аккаунты, к которым давно нет доступа.</p> <h3>Почему государства стали внимательнее к доменной инфраструктуре</h3> <p>Рост внимания к доменной отрасли напрямую связан с вопросами кибербезопасности. Домены регулярно используются в фишинговых атаках, распространении вредоносного ПО, мошеннических схемах и управлении ботнетами. Для атакующих домен остается удобной точкой входа: он помогает имитировать бренд, запускать поддельные лендинги, маскировать инфраструктуру и перенаправлять пользователей на вредоносные ресурсы.</p> <p>Проблема носит глобальный характер. По данным <a href="https://interisle.net/insights/phishing-landscape-2025-an-annual-study-of-the-scope-and-distribution-of-phishing">исследования</a> американской аналитической компании Interisle Consulting Group, в 2025 году количество доменов, использованных в фишинговых атаках по всему миру, превысило 1,5 млн., а общее число зарегистрированных фишинговых кампаний приблизилось к 2 млн.</p> <p>Российский сегмент интернета также сталкивается с ростом подобных угроз. По <a href="https://domainpatrol.ru/upload/iblock/676/kq5hwn3umunbtr2b21ndavh17ptw6is1/KO_2025_rus.pdf">данным</a> проекта «Доменный патруль» Координационного центра .RU/.РФ, в 2025 году в рунете заблокировали более 42 тыс. фишинговых сайтов и свыше 10 тыс. ресурсов, распространявших вредоносное ПО.</p> <p>На этом фоне государства рассматривают доменную инфраструктуру как часть системы цифровой устойчивости и кибербезопасности. Возможность быстро установить владельца интернет-ресурса позволяет оперативнее реагировать на инциденты, снижать масштабы злоупотреблений и выстраивать взаимодействие между регистраторами, ИБ-службами и правоохранительными органами.</p> <p>Еще один фактор — повышение прозрачности цифровой среды. Для регуляторов важно понимать, кто управляет ключевыми онлайн-активами внутри национального доменного пространства. Это позволяет снизить риски анонимного использования доменов в противоправной деятельности и сделать управление цифровой инфраструктурой более предсказуемым при взаимодействии бизнеса и государства. Для бизнеса эта логика тоже важна. Домен давно перестал быть просто адресом сайта: он связан с почтой, клиентским трафиком, рекламными кампаниями, API-интеграциями, SSL/TLS-сертификатами и доверием пользователей. Потеря контроля над доменом может привести не только к недоступности сайта, но и к сбоям в сервисах, утрате почтового контура или репутационному ущербу.</p> <h3>Какие модели идентификации действуют в разных странах</h3> <p>Подходы к идентификации владельцев доменов отличаются в зависимости от страны, однако почти все крупные юрисдикции движутся в сторону более прозрачной модели регулирования.</p> <p>В Евросоюзе изменения связаны с директивой NIS2, которая требует от регистраторов и реестров обеспечивать проверку и актуальность данных владельцев доменов. Речь идет не о централизованной государственной идентификации, а о повышении прозрачности доменной среды и снижении количества анонимных или недостоверных регистраций.</p> <p>Германия стала одной из первых стран, внедривших такие требования. Владельцы доменов должны подтверждать контактные данные, а при подозрительной активности регулятор или регистратор вправе запросить дополнительную верификацию. Европейская модель в большей степени носит риск-ориентированный характер: углубленная проверка обычно применяется при выявлении подозрительных действий или жалоб. В случае отказа от подтверждения данных домен может быть ограничен в обслуживании или заблокирован.</p> <p>Азиатские страны чаще используют более формализованные механизмы проверки личности или регистрационных данных. В Китае действует система real-name verification с обязательной проверкой документов владельца домена. В Индии регулирование также движется в сторону усиления KYC/e-KYC-процедур для доменных регистраций, в том числе на фоне судебной практики и обсуждения мер против фишинга и мошеннических сайтов.</p> <p>В ряде стран регулирование доменной отрасли строится вокруг принципа локального присутствия. Например, регистрация доменов в Австралии или Сингапуре может требовать локализации бизнеса, наличия национального регистрационного номера или использования trustee-сервисов, когда формальным администратором выступает местный регистратор, а фактическое управление остается за иностранной организацией.</p> <h3>Как устроена российская модель идентификации</h3> <p>Российская система идентификации администраторов доменов строится вокруг интеграции регистраторов с ЕСИА — Единой системой идентификации и аутентификации, используемой на портале Госуслуг.</p> <p>При регистрации или продлении домена администратор должен будет авторизоваться через Госуслуги и подтвердить свою учетную запись. Для физических лиц и индивидуальных предпринимателей потребуется подтвержденный аккаунт пользователя. Юридическим лицам необходимо зарегистрировать организацию в ЕСИА и назначить сотрудника с подтвержденными полномочиями для управления доменами.</p> <p>После авторизации сведения о владельце домена будут автоматически подтверждаться через государственную систему идентификации и передаваться регистратору в рамках установленного регулирования. Это позволит отказаться от значительной части ручных проверок и отдельной загрузки документов при стандартных сценариях регистрации и продления доменов.</p> <p>Российская модель сочетает элементы нескольких международных подходов, но при этом формирует собственную систему регулирования. В отличие от европейской модели, где углубленная проверка обычно применяется в ответ на подозрительную активность или жалобы, российский подход предполагает превентивную идентификацию администратора до выполнения ключевых операций с доменом.</p> <p>При этом российская система опирается не на новую отдельную процедуру, а на уже существующую цифровую инфраструктуру ЕСИА. Для пользователей это снижает количество ручных действий, а для регистраторов и государства создает более устойчивую модель подтверждения данных администратора домена.</p> <h3>Как администраторам доменов в компаниях подготовиться к новым правилам</h3> <p>До вступления новых требований остается немного времени, поэтому компаниям стоит провести аудит доменного портфеля и проверить текущую модель управления онлайн-активами.</p> <p>Бизнесу важно:</p> <ul> <li> собрать перечень всех доменов, используемых компанией</li> <li> проверить связанные элементы инфраструктуры: DNS-записи, SSL/TLS-сертификаты, почтовые настройки, редиректы, поддомены и домены рекламных кампаний;</li> <li> проверить, на кого зарегистрированы домены и актуальны ли данные администраторов;</li> <li> убедиться, что критически важные домены оформлены на юридическое лицо компании, а не на сотрудников, подрядчиков или внешних разработчиков;</li> <li> проверить, у кого есть доступ к учетным записям, через которые осуществляется управление доменами;</li> <li> зарегистрировать организацию в ЕСИА и определить сотрудников, ответственных за администрирование доменов;</li> <li> убедиться, что у ответственных сотрудников есть подтвержденные полномочия для работы через Госуслуги.</li> </ul> <p>Особое внимание стоит уделить доменам, зарегистрированным на бывших сотрудников или сторонних исполнителей. После запуска обязательной идентификации отсутствие прямого контроля над учетной записью администратора может осложнить продление домена, подтверждение данных или восстановление доступа к онлайн-ресурсам компании.</p> <p>Также стоит определить владельца процесса внутри компании. На практике доменами могут заниматься ИТ, ИБ, юристы, маркетинг и подрядчики, но при отсутствии единого ответственного доменный портфель быстро становится непрозрачным. Минимальный набор контроля — единый реестр доменов, регламент продления, порядок выдачи доступов, резервные контакты и регулярная проверка критичных доменных операций.</p> <p>Для бизнеса новые правила управления доменами — это повод проверить, кто фактически контролирует ключевые онлайн-адреса, где находятся доступы и можно ли без задержек подтвердить права на домен. Чем раньше компания проведет аудит доменного портфеля, тем ниже риск столкнуться с проблемами при продлении, изменении DNS-настроек или восстановлении доступа к онлайн-сервисам. В итоге подготовка к ЕСИА становится частью грамотного управления цифровой инфраструктурой — так же, как контроль учетных записей, сертификатов, почты и других критичных сервисов.</p> <p>#IMAGE_235344#</p> Доменная отрасль во многих странах постепенно интегрируется с системами цифровой идентификации. Государства … article Георгий Казаров, руководитель отдела доменов Руцентра https://www.itweek.ru/themes/detail.php?ID=235342 Thu, 13 Aug 2026 16:27:50 +0300 <p>MWS Cloud, входящая в МТС Web Services (MWS), проанализировала потребление китайских больших языковых моделей российскими компаниями на основе данных платформ MWS GPT Model Hub и MWS GPT. В первом полугодии 2026 года объём потребления более чем в 11 раз превысил показатель за весь 2025 год. Наиболее востребованными стали семейства Qwen, GLM и Kimi. Рынок предоставления LLM из облака в 2026 году достигнет почти 1,5 млрд рублей.</p> <p>В 2025 году на работу с китайскими генеративными моделями российские компании израсходовали 39,1 млрд токенов. В первом полугодии 2026 года потребление превысило 400 млрд токенов, увеличившись в 11,3 раза.</p> <p>Основными пользователями платформы являются представители крупного бизнеса. Они чаще всего применяют LLM для автоматизации клиентского взаимодействия: запускают чат-ботов для круглосуточной поддержки без участия оператора, генерируют и персонализируют маркетинговый контент — от текстов рассылок и описаний товаров до рекламных объявлений, — а также автоматизируют анализ обратной связи: выявляют тональность отзывов, категоризируют запросы и формируют сводные отчёты.</p> <p>Весь рынок LLM в России в 2026 году вырастет на 35% и составит порядка 19,6 млрд рублей. Облачный сегмент рынка, включающий предоставление доступа к LLM по модели SaaS и через API, в 2026 году достигнет почти 1,5 млрд рублей.</p> <p>На фоне растущего спроса и выхода новых моделей MWS Cloud почти вдвое расширила число больших языковых моделей в сервисе MWS GPT Model Hub, доведя их количество до 17. Главными пополнениями платформы стали GLM 5.2, опенсорс LLM от компании Z.AI, которая была признана лучшей LLM в агентских задачах. MWS Cloud стала первой компанией в России, развернувшей модель у себя в облаке. Кроме того, в сервисе появились первые модели распознавания речи (ASR) и синтеза речи (TTS), а также реранкеры для повышения качества поиска и RAG-пайплайнов. Сервис доступен в рамках платформы MWS Cloud Platform.</p> <p>Среди новых LLM — GLM 5.2, Kimi K2.6, Qwen3.6, Gemma 4, GPT OSS и другие. Каталог из 17 моделей даёт разработчикам возможность подбирать модель под конкретную задачу с учётом требований к качеству, скорости и стоимости. Все модели доступны через единый OpenAI-совместимый API, что упрощает интеграцию и переключение между ними.</p> MWS Cloud, входящая в МТС Web Services (MWS), проанализировала потребление китайских больших языковых моделей российскими … message https://www.itweek.ru/themes/detail.php?ID=235340 Thu, 13 Aug 2026 09:52:19 +0300 <p>Генеративный ИИ заметно изменил работу разработчиков. Создавать новый код стало проще и быстрее, чем когда-либо раньше. При этом потенциал генеративного ИИ в разработке уже подтверждается исследованиями. В ежегодном <a href="https://www.mckinsey.de/capabilities/quantumblack/our-insights/the-state-of-ai-how-organizations-are-rewiring-to-capture-value?utm_source">отчете</a> McKinsey «The State of AI» разработка программного обеспечения названа одной из областей, где технология быстрее всего переходит от экспериментов к практическому применению. Именно поэтому сегодня внимание постепенно смещается от вопросов внедрения к вопросам долгосрочных последствий такого ускорения.</p> <p>Но вместе с этим изменились и стимулы внутри разработки: во многих случаях написать новое решение оказывается проще, чем разобраться в существующем. Именно здесь начинает формироваться новый механизм накопления технического долга.</p> <p>Проблема заключается не в качестве генерации кода. Современные модели уже доказали свою эффективность: они ускоряют разработку, помогают быстрее реализовывать новые функции и снимают с инженеров значительную часть рутинной работы. Изменения происходят глубже. Вместе с ростом производительности меняется сама экономика инженерных решений. Написать новый код стало проще, тогда как понимание архитектуры, рефакторинг и сопровождение сложных систем не стали дешевле. В результате создать новую реализацию все чаще оказывается проще, чем развивать существующую.</p> <p>Рассмотрим, почему эта тенденция постепенно становится одним из ключевых факторов роста технического долга в эпоху генеративного ИИ.</p> <h3>Главный дефицит сместился</h3> <p>Долгое время одним из основных ограничений в разработке было создание кода. Генеративные модели существенно снизили стоимость этой работы. Сегодня многие задачи, которые раньше требовали значительных затрат времени, решаются за считанные минуты.</p> <p>Но вместе с этим изменился сам характер дефицита. Если раньше главным ограничением было написание кода, то сегодня все большую ценность приобретают понимание системы, проектирование архитектуры, ревью решений и анализ зависимостей между компонентами. Проще говоря, дефицитным становится не код, а способность понимать, как устроен продукт в целом.</p> <p>Это важное изменение. Потому что именно на уровне архитектуры принимаются решения, последствия которых определяют стоимость развития системы через несколько лет.</p> <h3>Изменилась экономика инженерных решений</h3> <p>Технический долг существовал всегда. Любой развивающийся продукт со временем накапливает компромиссы, временные решения и ограничения.</p> <p>Однако раньше разработчик чаще выбирал между двумя одинаково сложными вариантами: переработать существующую логику или написать новую. Сегодня этот баланс нарушен.</p> <p>Рефакторинг по-прежнему остается сложной задачей. Чтобы качественно изменить существующий механизм, необходимо понимать значительную часть системы, учитывать взаимосвязи между модулями и прогнозировать последствия изменений. Такие задачи требуют большого объема контекста и серьезного погружения в проект.</p> <p>Создать новое локальное решение значительно проще. Если появляется очередное бизнес-требование, зачастую быстрее написать отдельную реализацию, чем разбираться в существующей архитектуре. В моменте это выглядит рационально. Задача закрыта, сроки соблюдены, система продолжает работать.</p> <p>Именно поэтому технический долг редко возникает из-за плохих решений. Намного чаще он становится следствием решений, которые были логичны в конкретный момент времени.</p> <h3>Почему становится больше дублирующей логики</h3> <p>Эту тенденцию хорошо видно на крупных продуктах с большим количеством интеграций.</p> <p>Представим систему, в которой уже существует единый механизм работы с сетевыми запросами. Он отвечает за обработку ошибок, сериализацию данных, кеширование, поддержку различных версий API и другие инфраструктурные задачи.</p> <p>Затем появляется новый сценарий, который не укладывается в существующую логику. Архитектурно правильный путь — встроить его в уже работающий механизм. Но для этого необходимо разобраться в текущей реализации, оценить последствия изменений и убедиться, что они не затронут другие части системы.</p> <p>Во многих случаях проще создать отдельное исключение. Один такой случай не создает проблем. Однако со временем исключений становится больше. Появляются несколько вариантов обработки похожих сценариев, дублируются отдельные механизмы, растет количество специальных правил.</p> <p>Каждое решение по отдельности работает. Но общая сложность системы постепенно увеличивается.</p> <h3>Почему ИИ не устраняет технический долг</h3> <p>Существует мнение, что генеративный ИИ поможет справиться с накопленной сложностью за счет ускорения разработки. На практике чаще происходит обратное.</p> <p>ИИ не заменяет инженерную дисциплину. Он усиливает существующие практики. Если команда системно занимается архитектурой, контролирует сложность продукта и регулярно инвестирует время в рефакторинг, новые инструменты позволяют делать это быстрее.</p> <p>Если же проект развивается через постоянное накопление локальных решений, генеративный ИИ ускоряет и этот процесс. Во многом это связано с особенностями самих моделей. Для них локальная задача значительно проще, чем изменение архитектуры на уровне всей системы. Рефакторинг требует большого объема контекста. Необходимо учитывать связи между различными частями приложения и понимать последствия изменений за пределами конкретного модуля.</p> <p>Кроме того, модель не может переиспользовать абстракцию, которую не видит в доступном контексте. Поэтому во многих случаях для нее безопаснее создать новую реализацию, чем менять существующую.</p> <p>С инженерной точки зрения такая стратегия выглядит рационально. Но на длинной дистанции именно она становится одним из источников роста технического долга.</p> <h3>Когда технический долг начинает воспроизводить сам себя</h3> <p>На определенном этапе накопленная сложность начинает влиять на дальнейшие решения команды.</p> <p>Чем больше в системе исключений, специальных правил и дублирующей логики, тем сложнее становится ее понимать. Чем сложнее система, тем дороже обходится рефакторинг. А чем дороже рефакторинг, тем чаще появляются новые локальные решения вместо архитектурных изменений.</p> <p>Возникает замкнутый цикл, в котором технический долг начинает создавать условия для собственного дальнейшего роста. Сам по себе этот механизм существовал и раньше: чем сложнее становилась система, тем дороже обходились изменения и тем чаще команды принимали локальные компромиссные решения.</p> <p>Генеративный ИИ делает эту петлю значительно сильнее. Модель работает с той кодовой базой, которая уже существует. Чем больше в ней дублирующей логики, специальных исключений и неоднородных решений, тем хуже она ориентируется в проекте и тем чаще предлагает еще один способ решить ту же задачу. В результате возникает новая обратная связь: качество последующих изменений начинает зависеть от качества уже накопленной кодовой базы. Если она становится все менее однородной, модель еще чаще воспроизводит локальные решения вместо развития существующей архитектуры. До появления генеративного ИИ такой обратной связи между состоянием системы и инструментом разработки фактически не существовало.</p> <h3>Как появляется магическое мышление</h3> <p>Самые серьезные последствия обычно становятся заметны спустя годы. Со временем в проекте появляются решения, происхождение которых уже никто не может объяснить. Новые разработчики воспринимают их как часть архитектуры. Старые участники команды помнят, что когда-то на это были причины, но не всегда могут восстановить их логику.</p> <p>Постепенно возникает своего рода «магическое мышление». Команда уже не понимает, почему отдельные решения существуют и какие задачи они изначально решали, но менять их не решается. Логика архитектуры уступает место негласному правилу: «так тут принято и это как-то работает».</p> <p>В этот момент технический долг перестает быть исключительно инженерной проблемой. Он начинает влиять на управляемость продукта, скорость его развития и безопасность кода. Чем больше в системе локальных исключений и дублирующей логики, тем сложнее анализировать последствия изменений, контролировать появление потенциальных уязвимостей и поддерживать единые требования к качеству разработки.</p> <h3>Какие метрики становятся важнее скорости</h3> <p>Распространение генеративного ИИ заставляет по-новому смотреть и на оценку эффективности разработки.</p> <p>Количество написанного кода постепенно теряет смысл как показатель производительности. Схожий вывод <a href="https://github.blog/news-insights/research/does-github-copilot-improve-code-quality-heres-what-the-data-says/?utm_source">делают</a> и исследователи GitHub. В исследовании качества кода, созданного с помощью GitHub Copilot, авторы предлагают оценивать влияние ИИ не только через скорость разработки, но и через такие характеристики, как сопровождаемость, надежность и читаемость кода. Значительная часть этого объема может представлять собой будущий технический долг.</p> <p>Поэтому все большее значение приобретают другие показатели:</p> <ul> <li> стоимость изменений;</li> <li> объем ресурсов на сопровождение;</li> <li> количество инцидентов после релизов;</li> <li> скорость адаптации новых разработчиков;</li> <li> способность команды безопасно развивать существующую архитектуру.</li> </ul> <p>Именно такие метрики позволяют понять, становится ли продукт устойчивее или просто быстрее наращивает сложность. Не менее важно отслеживать, как изменения влияют на безопасность кода: увеличение числа локальных исключений и дублирующей логики постепенно усложняет аудит, сопровождение и поиск потенциальных уязвимостей.</p> <h3>Что в итоге</h3> <p>Генеративный ИИ не создает технический долг сам по себе. Он меняет условия, в которых принимаются инженерные решения. Создание нового кода становится дешевле. Понимание системы — нет.</p> <p>Поэтому главный вызов ближайших лет связан не с качеством генерации как таковым. Намного важнее сохранить архитектурную дисциплину в условиях, когда написать новую реализацию зачастую проще, чем разобраться в существующей.</p> <p>Чем активнее компании используют ИИ в разработке, тем большее значение будет иметь способность контролировать сложность систем. Именно она определит, станет ли ускорение разработки источником долгосрочного преимущества или приведет к накоплению проблем, которые придется решать уже следующим командам.</p> <p>#IMAGE_235341#</p> Генеративный ИИ заметно изменил работу разработчиков. Создавать новый код стало проще и быстрее, чем когда-либо раньше … article Султан Рамазанов, директор по искусственному интеллекту Umbrella IT https://www.itweek.ru/themes/detail.php?ID=235338 Thu, 13 Aug 2026 09:37:32 +0300 <p><em>Компании годами делают резервные копии, уверенные в том, что данные находятся под защитой. Когда случается инцидент и нужно срочно восстановить работу — выясняется, что копии есть, но восстановление займёт месяц или вовсе невозможно. Разберем типичные заблуждения, из-за которых бэкап превращается в имитацию защиты, и рассмотрим, как проверить систему резервного копирования, не дожидаясь инцидента.</em></p> <h3>Заблуждение первое: репликация заменяет резервное копирование</h3> <p>Репликация — это зеркало системы на текущий момент. Данные основной площадки копируются на резервную в режиме реального времени, и обе всегда синхронизированы. Есть вторая копия, всё актуально, на случай сбоя, есть куда переключиться — и репликация начинает казаться достаточной мерой защиты.</p> <p>Проблема возникает там, где реплика бессильна — например, при ошибке человека. Если данные случайно удалили или повредили на основной площадке, это мгновенно реплицируется на вторую. Обе площадки содержат уже испорченные данные, так как синхронизированы. Откатиться к состоянию до ошибки невозможно: снимка прошлого состояния нет.</p> <p>Резервная копия решает эту задачу — она фиксирует состояние данных в определённый момент времени и позволяет к нему вернуться. Репликация и резервное копирование не взаимозаменяемы: одно обеспечивает доступность, другое — возможность восстановления. Когда одно заменяют другим, защиты от потери данных нет.</p> <h3>Заблуждение второе: зелёные отчёты вместо тестового восстановления</h3> <p>Нередко компании убеждены: раз задания выполняются по расписанию и отчёты зелёные — резервные копии в порядке. Тестовое восстановление откладывается на потом, потому что всё работает и повода проверять нет.</p> <p>Цена этой уверенности выясняется в момент инцидента. При первой необходимости срочно восстановить большой объём данных оказывается, что перекачка займёт месяц: слишком большой объём, слишком медленный канал, хранилище не выдерживает нагрузку на чтение. То, что в планах должно было занимать часы, растягивается на недели. Плановый RTO расходится с реальным: никто заранее не проверил скорость восстановления.</p> <p>Зелёный статус в отчёте говорит только о том, что задание завершилось без ошибок на этапе копирования. Он ничего не говорит о том, цела ли цепочка копий и пригодны ли данные для восстановления. Блоки могут быть повреждены, цепочка инкрементов разорвана, метаданные битые — при этом процесс копирования отработал штатно. Всё это проверяется только тестовым восстановлением — пока оно не сделано, состояние копий под вопросом.</p> <h3>Заблуждение третье: изолировать бэкап — достаточно</h3> <p>Изоляция резервной копии — необходимая база, но не конечная цель. Представим: резервные копии отделены физически — например, в облаке провайдера. Сетевой доступ ограничен изолированным сегментом. Управление доступно только через отдельные учётные записи вне основной инфраструктуры, с обязательным MFA. Даже взломав основную сеть, злоумышленник не может добраться до копий.</p> <p>Но, если изоляция не сработает, следующий уровень защиты — неизменяемость копии. Реализуется это через принцип WORM: в S3-хранилищах — с помощью Object Lock, при котором система на уровне политики отказывается выполнять команду удаления до истечения заданного срока. Даже получив права администратора или root, уничтожить защищённую копию невозможно, пока не истёк заданный срок.</p> <p>На этом моменте легко поставить галочку «защищено» и закрыть вопрос. Но этой меры недостаточно, если срок хранения копии короткий. Злоумышленник, не имея возможности повредить копии, остаётся в инфраструктуре незамеченным и методично повреждает данные в основной системе. Новые бэкапы записывают уже испорченную информацию, а старые — единственные чистые — уходят за пределы глубины хранения и затираются. Когда атака обнаружена, восстанавливаться не из чего: все доступные копии содержат повреждения, а неизменяемость честно охраняла уже бесполезные файлы.</p> <p>Поэтому изоляцию и неизменяемость необходимо дополнять достаточной глубиной хранения. Облако упрощает эту задачу: ёмкость наращивается без закупки оборудования, а старые копии перемещаются в более дешёвые классы хранения.</p> <h3>Как проверить главное в системе бекапа за два часа</h3> <p>При ограниченном времени стоит сосредоточиться на трёх вопросах: изолирован ли доступ к управлению хранилищем, есть ли действительно неизменяемая резервная копия и когда с неё в последний раз проводилось восстановление.</p> <p>Если вход идёт под теми же учётными данными, что и в основной инфраструктуре, компрометация сети открывает путь и к управлению копиями. Доступ выносится в отдельные учётные записи, закрывается вторым фактором, а интерфейс управления отделяется от остальной сети.</p> <p>Следующий вопрос — настроена ли неизменяемость. Ответа «да, настроена» недостаточно. Важно понять, как именно она реализована. WORM-блокировка файловой системы или S3 Object Lock обеспечивают защиту, которую нельзя снять даже с правами администратора. Если же неизменяемость сводится к галочке в интерфейсе, которую тот же администратор может убрать, — это не защита. Отдельный вопрос — срок. Три дня блокировки копии при месячной глубине хранения не перекрывают окно обнаружения атаки. Здесь сталкиваются задачи эксплуатации и безопасности. Администраторы сокращают срок лока до <nobr>3-7 дней,</nobr> чтобы ошибочные бэкапы не тарифицировались месяцами. Специалисты ИБ требуют защиту на весь срок хранения, так как при атаке видят риск: злоумышленник дожидается снятия блокировки и затирает бэкап. Без синхронизации между командами возникает разрыв: копии хранятся месяц, но удалить их можно уже через неделю. Эти параметры нужно выставлять совместно, иначе защита остаётся открытой для атаки.</p> <p>Наконец, необходимо убедиться, что из неизменяемой копии реально можно восстановиться. Единственный способ — тестовое восстановление. Если оно проводилось давно или с тех пор менялась инфраструктура, стоит запустить его немедленно. Полноценно поднять систему за два часа нереально, но восстановить что-то небольшое — можно для диагностики механизма. Тест проверяет ключевые предположения: цепочка копий цела, каталог метаданных исправен, хранилище отдаёт данные. Ломается, как правило, сам механизм — и это выясняется только при реальной проверке.</p> <h3>Что делать, если нашли критическое нарушение</h3> <p>Критические нарушения бывают разными. Например, сервер вовсе не включён в задание резервного копирования, или полная копия не делалась больше года, а всё это время копировались только изменения.</p> <p>Первый импульс — быстро перенастроить задание и считать задачу закрытой. Добавить пропущенный сервер или принудительно запустить полную копию — необходимый первый шаг, но не финальный. Обнаружив проблему, ее нужно превратить в правило, чтобы она не повторилась. Например, регулярно сверять список серверов в задании бэкапа с тем, что реально есть в инфраструктуре, — это исключит ситуацию, когда сервер просто забыли добавить. А правило о том, что полная копия должна обновляться регулярно, не даст инкрементам накопиться до состояния, когда восстановление уже невозможно.</p> <p>После того как точечные нарушения закрыты, проверяем главное: рабочая ли копия. Убедиться в этом можно только тестовым восстановлением. Разовая проверка закрывает вопрос сегодня, но не завтра. Тестовое восстановление должно быть регулярной процедурой, закреплённой в регламенте, — иначе его снова отложат до инцидента.</p> <p>#IMAGE_235339#</p> Компании годами делают резервные копии, уверенные в том, что данные находятся под защитой. Когда случается инцидент … article Виктор Виноградов, директор по информационной безопасности mt cloud https://www.itweek.ru/themes/detail.php?ID=235337 Thu, 13 Aug 2026 09:30:08 +0300 <p><em>Агентная разработка ПО снижает барьер для создания приложений, но также поднимает более сложный вопрос для технологических лидеров: кто несет ответственность, когда ПО, созданное с помощью искусственного интеллекта, становится критически важным для бизнеса? В новом отчете </em><em>Forrester</em> <em>«</em><em>Reinventing</em> <em>Software</em> <em>Development</em> <em>Services</em> <em>For</em> <em>The</em> <em>Age</em> <em>Of</em> <em>AI</em> <em>Coding</em><em>» утверждается, что поставщики услуг по разработке ПО сталкиваются с кризисом идентичности, поскольку производство кода становится сервисом массового потребления, а клиенты ставят под сомнение рентабельность инвестиций в аутсорсинг по сравнению с разработкой собственными силами с использованием ИИ. Лучшие сервис-провайдеры перейдут от продажи инженерных возможностей к продаже доверия: отказоустойчивой архитектуры, снижению рисков, организации контекста и подотчетности, пишет в корпоративном блоге Клинтон Хергет, главный аналитик </em><em>Forrester</em><em>.</em></p> <h3>ИИ-кодирование делает доверие новой валютой в сфере ПО</h3> <p>Когда бизнес может сам превратить промпт в работающее приложение, старая концепция услуг по разработке ПО начинает давать сбой. Если создание кода собственными силами кажется простым, быстрым и дешевым, зачем платить сервис-провайдеру за его разработку?</p> <p>Этот вопрос сейчас напрямую стоит перед поставщиками услуг на этом рынке. Быстрое совершенствование обученных кодированию больших языковых моделей (LLM) снизило барьер для создания работающих приложений для любого, кто имеет доступ к таким LLM и базовые навыки работы с промптами. В результате предприятия экспериментируют с созданием ПО собственными силами (особенно «гражданскими разработчиками»), в то время как поставщики услуг пытаются объяснить, почему предлагаемая ими ценность выходит за рамки простого написания кода.</p> <p>Но реальная проблема не в том, что создание ПО стало простым, а в том, что код стал менее важным источником ценности.</p> <p>Более сложная работа переместилась в другие области: архитектуру, проектирование продуктов, безопасность, ремонтопригодность, контроль затрат, обеспечение качества, интеграцию и долгосрочную отказоустойчивость. В отчете четко обозначено это противоречие: поставщики услуг должны отказаться от предоставления инженерных возможностей как услуги и перейти к долгосрочным, учитывающим риски, основанным на ответственности партнерствам, подкрепленным глубокой человеческой экспертизой.</p> <h3>Следующее поле битвы — ответственность за ПО</h3> <p>Поставщикам услуг по разработке ПО не нужно выигрывать у ИИ соревнование по написанию кода. Им нужно обеспечить ценностное предложение, основанное на доверии. Им нужно переориентироваться на продажу гарантий как услуги (Assurance As A Service).</p> <p>ПО остается сложным. Со временем корпоративные приложения накапливают риски в виде ошибок, простоев, критических изменений API, уязвимостей безопасности, проблем с интеграцией и технического долга. Код может быть стало проще генерировать, но надежность и контроль затрат не являются общим местом.</p> <p>Текущий сдвиг порождает новое ценностное предложение для поставщиков и новый взгляд на покупку для клиентов. В отчете представлены несколько основных рекомендаций, описанных ниже.</p> <h3>Оптимизация разработки с приоритетом ИИ</h3> <p>Качество ПО, созданного ИИ, во многом зависит от того, как команды определяют, направляют, тестируют и проверяют его работу. В отчете утверждается, что поставщики услуг могут создавать ценность, освоив методы разработки с помощью ИИ, включая разработку на основе спецификаций, правильный выбор инструментов для моделей и агентов, а также эффективное использование токенов. Эти возможности наиболее важны в сложном корпоративном ПО, для которого работающий прототип — это только начало. Помогая клиентам улучшить использование ИИ, поставщики могут конкурировать за счет измеримого улучшения, а не только за счет объема доставки.</p> <h3>Дифференциация за счет архитектуры и дизайна продукта</h3> <p>ИИ может генерировать код, но люди по-прежнему принимают многие решения, которые с наибольшей вероятностью влияют на результаты бизнеса. В отчете отмечается, что почти половина организаций использует ИИ на этапе кодирования жизненного цикла разработки ПО (SDLC), по сравнению с 35% на этапах анализа и планирования. Этот разрыв имеет значение: навыки управления продуктом (например, анализ заинтересованных сторон, определение требований) плюс навыки проектирования систем (например, моделирование данных, определение микросервисов, облачная инфраструктура) остаются критически важными источниками ценности, предлагаемой поставщиками услуг. Реальная возможность для консалтинга заключается не в том, чтобы «писать код быстрее», а в том, чтобы «убедить, что мы создаем правильный продукт правильным способом».</p> <h3>Продавайте отказоустойчивость вместо скорости</h3> <p>ИИ может создавать ощущение мгновенной доставки, что ослабляет скорость как конкурентное преимущество. Я рекомендую поставщикам услуг сосредоточиться вместо этого на долгосрочной ремонтопригодности, контроле качества, тестовом покрытии, безопасности, снижении технического долга и корпоративной отказоустойчивости. Когда ПО становится критически важным для бизнеса, эти факторы оказывают большее влияние на рентабельность инвестиций в ПО, чем первоначальные затраты на разработку. Клиенты должны требовать доказательств того, что поставщики услуг могут повышать отказоустойчивость с течением времени, а не просто быстро выпускать функционал.</p> <h3>Роль клиента тоже меняется</h3> <p>Этот сдвиг не означает, что клиенты должны передавать больше ответственности поставщикам и отходить в сторону; это означает, что отношения между клиентом и поставщиком должны стать более четко определенными в отношении разделения ответственности.</p> <p>ИИ-нативное ПО нуждается в контексте клиента: подробные требования, архитектурные ограничения, бизнес-логика, сценарии исключений, записи решений, модели угроз, требования к соответствию нормативным требованиям, клиентские инсайты и ​​допустимый уровень риска. Большая часть этого контекста находится внутри организации клиента, а не у поставщика.</p> <p>В отчете предлагается модель, согласно которой клиенты сосредотачиваются на понимании и агрегировании внутреннего контекста, в то время как поставщики помогают создавать стандарты проектирования приложений, лучшие практики и долгосрочное управление рисками в области безопасности, ремонтопригодности и стоимости. На практике это «гарантия как услуга»: партнерство, которое превращает контекст клиента плюс опыт поставщика в надежную бизнес-функциональность.</p> <h3>Что должны делать технологические лидеры сейчас</h3> <p>ИИ-кодирование будет продолжать совершенствоваться, но это не должно подталкивать технологических лидеров к ложному выбору между полностью аутсорсинговой доставкой и неконтролируемым внутренним использованием ИИ. Более важный вопрос — как разделить ответственность.</p> <p>Начните с определения того, какие возможности ПО требуют гарантии — те, которые связаны с доходом, клиентским опытом, операциями, безопасностью или соответствием нормативным требованиям. Затем решите, какой контекст должен оставаться в собственности клиента, а какие возможности должен гарантировать поставщик. Наконец, пересмотрите отношения, сосредоточившись на результатах, отказоустойчивости и подотчетности, а не на возможностях.</p> <p>ПО все чаще может создавать себя само. Корпоративное доверие — нет.</p> Агентная разработка ПО снижает барьер для создания приложений, но также поднимает более сложный вопрос для … article https://www.itweek.ru/themes/detail.php?ID=235336 Wed, 12 Aug 2026 14:39:14 +0300 <p>Компания Security Vision представила обновление платформы SV5. Ключевой фокус релиза — развитие инструментов интеграции и оптимизация работы с данными. Платформа получила новые параметры коннекторов, дополнительные аналитические функции и более гибкие механизмы управления настройками.</p> <p>Для WMI-коннектора добавлена настройка пространства имён (namespace) для выполнения WQL-запросов по заданному адресу. В конфигурациях коннекторов также появились сжатие при передаче событий. Обновление библиотеки librdkafka обеспечивает работу Kafka-коннектора с аутентификацией SASL/SCRAM для версий 4.0.0 и выше.</p> <p>В переменные добавлено преобразование чисел между двоичной, восьмеричной и шестнадцатеричной системами счисления. Новая возможность расширяет сценарии нормализации и подготовки данных.</p> <p>В преобразовании «Формула» появились функции вычисления модуля числа и квадратного корня — abs() и sqrt().</p> <p>Для виджетов «Линейный график» и «Столбчатая диаграмма» добавлены настройки масштабирования, позволяющие точнее настраивать отображение данных.</p> <p>Выгрузка отчётов через портал переведена на асинхронный режим, что делает работу с длительными операциями формирования отчётности удобнее.</p> <p>Обновлены настройки блока «Граф» и отображение блока «История» в карточке объекта. Также скорректирован интерфейс представлений в редакторе типов объектов системы и справочников.</p> <p>В настройках модулей расширено управление иконками, а условие маппинга иконок в графе переработано в формат фильтра.</p> <p>Для Правил корреляции создан новый раздел с общим представлением и редактором. В журнале аудита изменения правил группировки теперь фиксируются раздельно для системных и пользовательских справочников, а запуск выключенных коннекторов через рабочие процессы запрещён.</p> Компания Security Vision представила обновление платформы SV5. Ключевой фокус релиза — развитие инструментов интеграции … message https://www.itweek.ru/themes/detail.php?ID=235335 Wed, 12 Aug 2026 14:37:07 +0300 <p>Институт статистических исследований и экономики знаний (ИСИЭЗ) НИУ ВШЭ продолжил анализ российского рынка интеллектуальной собственности и изучил на основе данных Роспатента интенсивность и ключевые тренды лицензионной деятельности в России, уделяя особое внимание динамике и структуре вовлечения исключительных прав в хозяйственный оборот.</p> <p>В 2025 г. Роспатент зарегистрировал почти 2,7 тыс. распоряжений исключительным правом на изобретения, полезные модели и промышленные образцы — на 4,6% больше, чем годом ранее. Из них 2,2 тыс. (+4%) составили коммерческие договоры о предоставлении права использования и об отчуждении исключительного права.</p> <p>Патентообладатели по-прежнему чаще предоставляют право использования по лицензии, чем полностью отчуждают исключительное право: в 2025 г. зарегистрировано почти 1,3 тыс. таких распоряжений против 944 договоров об отчуждении.</p> <p>Почти две трети зарегистрированных распоряжений (65,9%) относились к изобретениям, доля которых среди патентов, включенных в сделки, составила 43,2%. На полезные модели приходилось 20,2% распоряжений и 38,3% патентов, на промышленные образцы — 14 и 18,5% соответственно. При этом в <nobr>2020–2025 гг.</nobr> число распоряжений исключительным правом на изобретения сократилось на 18,4%, а количество патентов, включенных в такие сделки, — на 20,3%.</p> <p>На протяжении всего рассматриваемого периода наибольшее число распоряжений приходилось на патенты в области химии и нефтехимии, медицины, энергетики и электротехники. В 2025 г. их суммарная доля в общем потоке зарегистрированных распоряжений составила 39,1%.</p> <p>По сравнению с предыдущим годом наиболее заметно выросло число распоряжений правами на разработки в области легкой и пищевой промышленности (+29,9%), химии и нефтехимии (+13,2%), нефтегазодобычи (+12,6%). Положительная динамика также отмечалась в электронике, вычислительной технике и приборостроении (+3,5%), металлургии (+1,5%). Снижение наблюдалось в энергетике и электротехнике (-18,2%), машиностроении, станкостроении и производстве инструмента (-15,5%), медицине (-5,8%), строительстве и производстве строительных материалов (-4,1%).</p> <p>Основными участниками рынка интеллектуальной собственности выступают частные организации. В 2025 г. на них приходилось 62% зарегистрированных распоряжений со стороны лицензиаров (продавцов) и 88% — со стороны лицензиатов (покупателей). Доля физических лиц составляла соответственно 24 и 8%. Суммарный вклад государственных предприятий, НИИ, КБ и вузов оставался ограниченным — 14% среди лицензиаров и 4% среди лицензиатов.</p> <p>Роспатент также регистрирует распоряжения исключительными правами на объекты в сфере цифровизации — программы для ЭВМ, базы данных и топологии интегральных микросхем. В 2025 г. зарегистрировано 662 таких распоряжения — несколько меньше, чем годом ранее, но почти в полтора раза больше, чем в начале рассматриваемого периода (2020 г.). Договоры об отчуждении исключительного права составляли 89,9% их общего числа.</p> <p>По итогам 2025 г. число распоряжений исключительным правом на патенты впервые с 2021 г. выросло. Основной вклад внесла активизация сделок с полезными моделями и промышленными образцами. Рынок по-прежнему формируют преимущественно частные организации, а в цифровом сегменте доминируют сделки по отчуждению исключительных прав.</p> Институт статистических исследований и экономики знаний (ИСИЭЗ) НИУ ВШЭ продолжил анализ российского рынка интеллектуальной … message https://www.itweek.ru/themes/detail.php?ID=235334 Wed, 12 Aug 2026 14:32:19 +0300 <p>«СёрчИнформ» представила результаты опроса, проведенного в 2026 году среди 100 специалистов и руководителей служб ИБ коммерческих и государственных организаций. Респондентам были заданы вопросы о технической реализации средств защиты файловой инфраструктуры. В опросе приняли участие малые организации (39%) и средние и крупные компании (61%).</p> <p>Большинство опрошенных организаций используют для хранения данных файловые серверы (87%), АРМ сотрудников (80%) и базы данных (68%).</p> <p>Также аналитики «СёрчИнформ» выяснили основные причины применения мер защиты данных в организациях. На первом месте у российских компаний стоят требования властей к защите персональных данных, которые мотивируют 87% опрошенных внедрять соответствующие меры. Следующей по значимости причиной являются нормативные требования к защите информации в государственных информационных системах — 63%. Собственные локальные акты также играют важную роль в защите данных для 54% компаний. В условиях увеличения штрафов за ИБ-нарушения и актуализации требований к безопасности ИС госсектора и КИИ, защита файловой инфраструктуры становится объективной потребностью организаций любых отраслей.</p> <p>Значительную долю среди опрошенных организаций занимают меры по обеспечению защиты критической информационной инфраструктуры — 46%. Прикладные задачи организации требуют внедрения мер защиты в 28% случаев, а защита коммерческой тайны — в 24%.</p> <p>Самые распространенные проблемы при защите данных: сложности с контролем операций с данными (44%), согласование настроек для различных ИТ- и ИБ-систем (42%) и классификация содержимого файлов (38%).</p> <p>«Обработка и передача информации, в том числе конфиденциальной, — это основа критических бизнес-процессов в любой организации. Поэтому важно контролировать работу сотрудников с такой информацией, а также минимизировать риски утечек, порчи, уничтожения конфиденциальных данных. Однако большинству опрошенных компаний сложно найти баланс между обеспечением защиты и сохранением оперативности работы с данными. Первый шаг к решению этой задачи — классификация всех файлов по содержанию, чтобы определить, какие из них требуют особого контроля и защиты», — отметил Алексей Парфентьев, заместитель генерального директора по инновационной деятельности «СёрчИнформ».</p> <p>Аналитики «СёрчИнформ» в рамках опроса выяснили, какие инструменты используют российские компании в 2026 году для защиты данных. Опрошенные активно используют штатные средства системного программного обеспечения и баз данных. Эти инструменты применяют 89% компаний. Криптографические средства защиты используют 68% организаций, прикладное ПО, не относящееся к средствам защиты — 56%. Системы аудита и защиты файловых хранилищ (DCAP) задействованы в защите данных лишь у 9% организаций.</p> <p>«Большинство компаний защищают данные сразу несколькими способами. Но чаще всего для этого используют встроенные функции информационных систем и прикладного ПО, а не специализированные средства. Такой формат защиты не позволяет организациям в полной мере реализовать задачи защиты конфиденциальных данных, более того — размывает политики безопасности до индивидуальных настроек в разных системах, не синхронизированных в единую логику. Защита при таком сценарии становится точечной, а момент передачи из системы в систему вовсе выпадает из-под контроля», — прокомментировал Алексей Парфентьев, заместитель генерального директора по инновационной деятельности «СёрчИнформ».</p> <p>Внедрение автоматизированных решений по маркировке — важный шаг к повышению уровня информационной безопасности и соблюдению законодательства. При этом, большая часть опрошенных компаний (78%) не выполняют маркировку защищаемых электронных документов, в частности, проставление грифов «Коммерческая тайна», «Для служебного пользования».</p> <p>«Текущий уровень автоматизированной маркировки защищаемых электронных документов в организациях остается крайне низким — всего 4% компаний используют технические средства, такие как системы аудита и защиты файловых хранилищ (DCAP), для автоматической маркировки конфиденциальной информации. Большинство (78%) и вовсе не проводят такую работу. Из-за этого бизнесу будет проблематично применить меры дисциплинарной и материальной ответственности за разглашение коммерческой тайны в „цифре“, а у организаций госсектора возникает риск нарушения требований властей, в частности, постановления Правительства РФ № 1233 от 13.11.1994», — прокомментировал Дмитрий Вощуков, специалист по связям с государственными органами «СёрчИнформ».</p> <p>43% опрошенных компаний отмечают недостаток функциональности имеющихся средств для защиты данных.</p> <p>В связи с этим, невысок показатель обнаружения инцидентов с несанкционированным доступом внутренних нарушителей к защищаемой информации.</p> <p>«Штатные ИТ-средства не умеют классифицировать файлы по содержимому. Кроме того, нарушитель может обойти встроенные ограничения: достаточно переместить файл или изменить его разрешения. Поэтому для защиты данных нужны специализированные средства — криптографические и некриптографические. Например, системы аудита и защиты файлов (DCAP). Они автоматически находят и классифицируют конфиденциальные документы, применяют меры защиты только к чувствительным данным и позволяют контролировать их на всех этапах жизненного цикла», — прокомментировал Алексей Парфентьев, заместитель генерального директора по инновационной деятельности «СёрчИнформ».</p> <p>Многофункциональность систем аудита и защиты файлов и гибкость их применения подтверждаются данными опроса. Наиболее важной функцией для компаний является защита от утечек и неправомерного доступа (86%), аудит обработки конфиденциальных данных (71%), инвентаризация информационных активов (57%) и контроль прав доступа пользователей к информации (57%).</p> <p>Системы аудита и защиты файлов — не единственный инструмент внутренней информационной безопасности. Решения этого класса интегрируются с другими средствами защиты информации, позволяя обеспечить максимально эффективную защиту от неправомерного доступа и действий с защищаемыми данными. 86% опрошенных компаний интегрируют системы аудита и защиты файловых хранилищ (DCAP) со средствами предотвращения утечек информации (DLP), 14% встраивают средства аудита и защиты файлов в инфраструктуру центров обеспечения ИБ (SOC), столько же — объединяют функции этих решений и инструментов защищенного обмена и работы с данными (VDR).</p> <p>Главные стоп-факторы, сдерживающие внедрение систем аудита и защиты файловых хранилищ (DCAP) среди российских компаний — неосведомленность о средствах этого класса (49%), высокая стоимость (43%) и нехватка кадров для работы с системой (39%).</p> <p>«Системы аудита и защиты файлов (DCAP) — все еще новое для большинства заказчиков решение. Хотя первые системы этого класса появились в конце 2010 года, рынок все еще формируется. Вопрос цены при внедрении системы аудита и защиты файлов (DCAP) возникает при выборе между их применением и использованием штатных средств ОС или прикладного ПО. При этом функций неспециализированных систем в большинстве случаев недостаточно для защиты данных. Среди специализированных средств защиты информации, решения этого класса — одни из наиболее простых в использовании и нетребовательных к аппаратным мощностям. Использование системы аудита и защиты файлов (DCAP) снижает нагрузку на ИБ-службы и позволяет высвободить время ИБ-специалистов, поскольку автоматизирует рутинные процессы аудита и разграничения доступа к файлам», — прокомментировал Алексей Парфентьев, заместитель генерального директора по инновационной деятельности «СёрчИнформ».</p> «СёрчИнформ» представила результаты опроса, проведенного в 2026 году среди 100 специалистов и руководителей … message https://www.itweek.ru/themes/detail.php?ID=235333 Wed, 12 Aug 2026 14:29:35 +0300 <p>ГигаАгент от Сбера — первый в России автономный универсальный ИИ-агент для решения повседневных задач: управления календарём, работы с документами, ведения переписки, исследования информации, создания отчётов и презентаций. ГигаАгент — это российский ответ зарубежным решениям OpenClaw, Hermes Agent, NemoClaw.</p> <p>В отличие от диалоговых интерфейсов (чатов) ГигаАгент способен лучше запоминать контекст, не нуждается в контроле каждого шага, учитывает и накапливает обратную связь, подстраивается под индивидуальный способ работы пользователя. Агент может работать автономно и в фоновом режиме, проявляет проактивность: самостоятельно задаёт уточняющие вопросы, когда этого требует ситуация, и способен параллельно решать несколько задач в едином смысловом поле.</p> <p>Три свойства принципиально выделяют ГигаАгент среди существующих решений: </p> <ul> <li>автономность. ГигаАгент взаимодействует с пользователем как самостоятельный агент 24/7 и в проактивном режиме. Если ему не хватает информации, он честно сообщает об этом, а если находит ошибку в рассуждениях, может аргументированно возразить. Такое поведение заложено в архитектуру системы и делает долгосрочное взаимодействие более последовательным и предсказуемым. ГигаАгент не просто исполнитель, а полноценный партнёр, готовый к дискуссии и обсуждению идей для реализации;</li> <li>саморазвитие. ГигаАгент способен самостоятельно совершенствовать свою работу. Он читает и переписывает собственный исходный код. Каждое изменение фиксируется как коммит во встроенном Git-репозитории. Агент ведёт список улучшений, которые используются при восстановлении в случае возникновения критических ошибок;</li> <li>непрерывность. Большинство ИИ-агентов работают только в рамках одной сессии и не сохраняют накопленный опыт. ГигаАгент, напротив, запоминает предыдущие задачи, принятые решения и историю взаимодействия. После перезапуска он продолжает работу с учётом уже накопленного контекста, что позволяет использовать его как ИИ-агента с долговременной памятью.</li> </ul> <p>Андрей Белевцев, старший вице-президент, руководитель блока «Технологическое развитие» Сбербанка, отметил: «ГигаАгент — это новый этап взаимодействия человека с генеративным искусственным интеллектом. Если раньше ИИ лишь находил ответы, то теперь становится полноценным цифровым партнёром, который помогает достигать рабочих и личных целей. Появился новый сценарий. Вы ставите задачу — агент анализирует её сложность, планирует решение и разбивает на подзадачи, при необходимости пишет код и в итоге готовит финальный ответ пользователю. Это может быть как в целях повышения личной эффективности, так и для автоматизации бизнес-процессов, а ГигаАгент адаптируется и эволюционирует вместе с пользователем. Важно, что это полностью российская разработка, безопасная и доступная каждому».</p> <p>В основе ГигаАгента лежит проект саморазвивающегося ИИ-агента Ouroboros, разработанного командой исследователей Института AIRI. Сейчас фреймворк развивается совместно с командой Сбера и стал важным этапом в развитии технологии генеративного искусственного интеллекта. На бенчмарках агент демонстрирует высокие результаты — на лидерборде Terminal Bench 2.1 для модели Opus 5 от Anthropic качество агента составляет 86,97%.</p> <p>Для хранения и обработки данных пользователя ГигаАгент использует только отечественные платформы. Например, его можно запустить с помощью такого решения для организации работы с ИИ-агентами, как Agents Space. </p> ГигаАгент от Сбера — первый в России автономный универсальный ИИ-агент для решения повседневных задач: управления … message https://www.itweek.ru/themes/detail.php?ID=235332 Wed, 12 Aug 2026 14:20:36 +0300 <p>Аналитики компании IT_ONE проанализировали около 12 тысяч вакансий в разных направлениях разработки ПО. Почти в 35% из них в перечне требований к кандидату встречалось упоминание вайбкодинга. Работодатели всё чаще ожидают от специалистов знания популярных ИИ-инструментов и умения эффективно встраивать ИИ в процесс разработки.</p> <p>Согласно исследованию IT_ONE наиболее часто такие требования к знанию вайбкодинга предъявлялись к кандидатам на должности Data-инженера / Data-сайентиста, <nobr>ML-инженера,</nobr> системного аналитика. </p> <p>Среди языков программирования для вайбкодинга чаще всего упоминались Python (безусловный лидер) и Java. </p> <p>Ввиду того, что вайбкодинг — относительно новое явление, использование этого определения на рынке пока не носит системный характер. В большинстве вакансий для описания этого явления употреблялся термин «ИИ-разработка» или смежные термины — такие, как «ML», «промпт-инжиниринг» в контексте разработки и т. д.</p> <p>Среди типов требований по вайбкодингу встречаются знание ИИ-инструментов (GitHub Copilot, Cursor, ChatGPT, Claude) и навыки проверки и тестирования ИИ-сгенерированного кода (валидации). Владение инструментами для вайбкодинга фактически стали отраслевым стандартом. </p> <p>Со средней частотой упоминаются умение составлять эффективные промпты для автоматизированного создания кода (промпт-инжиниринг), понимание границ возможностей языковых моделей (LLM), умение встраивать ИИ в процесс разработки (workflow). </p> <p>Относительно редко работодатели требуют умение использовать ИИ для отладки кода (AI-assisted debugging), навыков ИИ-генерации unit-тестов и тест-кейсов, навыков создания и настройки ИИ-агентов для автоматизации. ИИ-агенты и автоматизация — новые тренды среди запросов.</p> <p>Дополнительно аналитики IT_ONE провели опрос руководителей компаний, для которых актуально направление внутренней разработки. </p> <p>Чаще всего в таких компаниях с помощью ИИ решают или планируют решать задачи написания и рефакторинга кода, автоматизации рутинных задач, генерации тестов и тест-кейсов, дебаггинга и поиска ошибок. Среди других задач — генерация документации и SQL-запросов, анализ требований, поиск и отбор кандидатов (HR), автоматизация код-ревью. </p> <p>Сотрудники этих компаний заинтересованы в повышении квалификации в области промпт-инжиниринга, методов обеспечения безопасности и конфиденциальности данных при взаимодействии с ИИ, оценки качества ответов ИИ, интеграции ИИ в CI/CD. Также упоминаются юридические и этические аспекты работы с нейросетями. </p> <p>При этом респонденты отметили проблемы, ограничивающие возможности специалистов. Наиболее актуальные из них — нехватка внутренних инструментов ИИ, блокировка внешних сервисов (в том числе из-за санкций), нехватка знаний в промпт-инжиниринге, невозможность оценить пользу от применения ИИ. </p> <p>На низкое качество и нерелевантность ответов моделей сотрудники жалуются довольно редко. Нехватка вычислительных мощностей также пока не является основным сдерживающим фактором для большинства компаний: это может означать, что бизнес уже подготовился к применению ИИ, или что ИИ в опрошенных компаниях используется пока в небольшом объеме, или что ставка делается на облачные модели. </p> <p>Отдельно стоит упомянуть востребованность компаний в специалистах с опытом применения ИИ в ИТ-ландшафте, построенном на российском ПО. </p> <p>«Сегодня под вайбкодингом рынок обычно понимает не умение „кодить на ощущениях“, а применение ИИ в качестве ассистента (AI-assisted / agentic coding). Разработчик должен уметь быстро получать черновой код от LLM/агентов, но при этом он сам отвечает за архитектуру этого кода, проверку, безопасность и выпуск в прод. Это означает, что рынку нужны в первую очередь опытные специалисты, которые сочетают классические навыки программирования и CI/CD с навыками вайбкодинга. ИИ-инструменты становятся для них „супер-помощниками“ для ускорения рутинных задач: генерации и оптимизации SQL и Spark-кода, автоматизации ETL, документирования, рефакторинга», — отметила Ксения Манскова, руководитель направления ресурс-менеджмента в компании IT_ONE. </p> Аналитики компании IT_ONE проанализировали около 12 тысяч вакансий в разных направлениях разработки ПО. Почти … message https://www.itweek.ru/themes/detail.php?ID=235331 Wed, 12 Aug 2026 14:19:00 +0300 <p>Компания BSS обновила разработанную для банков систему противодействия мошенничеству (FRAUD-Анализ), добавив модуль интеграции с государственной системой обмена данными о цифровом мошенничестве — ГИС Антифрод.</p> <p>Модуль позволяет банкам автоматически получать сведения от других кредитных организаций, операторов связи, ЦБ и государственных ведомств о связанных с мошенничеством лицах и телефонных номерах, выявленных попытках противоправных действий и других признаках цифрового мошенничества.</p> <p>Эти сведения становятся дополнительными сигналами при оценке операций и принятии решений. Новый модуль BSS позволяет не только технически подключиться к государственной системе, но и настроить обработку сигналов оттуда с учетом внутренних процессов банка, чтобы оперативно учитывать поступающие сведения при проведении операций. А при появлении новых типов сигналов их можно будет добавлять в систему без полной перестройки интеграции. </p> <p>«Для банков интеграция с ГИС Антифрод открывает доступ к важнейшему источнику сигналов при проверке операций, помогает защищать интересы клиентов и снижать собственные риски. С 1 марта 2027 года неисполнение требований по использованию сведений ГИС Антифрод может повлечь обязанность банка возместить клиенту сумму перевода, совершенного без его согласия», — отметил Илья Иванов, директор по развитию продуктов Центра разработки интеграционных решений и антифрод-систем компании BSS.</p> <p>Система противодействия мошенничеству от BSS (FRAUD-Анализ) обеспечивает безопасность дистанционного обслуживания как юридических, так и физических лиц и защищает от действий злоумышленников. Система успешно используется российскими банками для комплексного мониторинга и предотвращения мошенничества.</p> Компания BSS обновила разработанную для банков систему противодействия мошенничеству (FRAUD-Анализ), добавив модуль интеграции … message https://www.itweek.ru/themes/detail.php?ID=235328 Wed, 12 Aug 2026 09:29:19 +0300 <p>Недавно была опубликована спецификация Agent Plugins 1.0.0 — проекта открытого стандарта для упаковки навыков ИИ-агентов и конфигураций подключения к внешним системам. Сейчас документ имеет статус Working Draft: спецификация ещё находится в разработке и может меняться.</p> <p>Новость сразу привлекла внимание ИТ-сообщества. Это закономерно: проект развивается открыто, а в первоначальный состав технического управляющего комитета вошли представители Amazon, Cursor, Microsoft, OpenAI и Vercel. В число совместимых ИИ-инструментов уже вошли ChatGPT, Codex, Cursor, GitHub Copilot, Kiro и VS Code.</p> <p>Единый формат Agent Plugins 1.0 позволяет упаковывать инструкции, интеграции и накопленную экспертизу в повторно используемые компоненты. Если формат получит широкое распространение, компании смогут применять одни и те же компоненты в разных совместимых ИИ-инструментах, упрощая распространение решений и сокращая объём повторной работы.</p> <h2>От разрозненных интеграций к тиражируемым решениям на базе ИИ-агентов</h2> <p>Появление ИИ-агентов стало важным этапом в развитии автоматизации: они научились не только формировать ответы, но и выполнять последовательности действий. При этом их устройство пока неоднородно, поскольку технология находится на раннем этапе развития. Первые решения оставались изолированными, зависели от конкретных платформ и требовали отдельной настройки интеграций.</p> <p>Сначала модели подключали к отдельным функциям и API: один вызов получал данные, другой отправлял сообщение, третий создавал задачу. Такие интеграции работали, но обычно были тесно связаны с конкретным приложением, SDK и способом описания инструментов.</p> <p>Следующим шагом стал Model Context Protocol, или MCP. Он задал общий способ подключения ИИ-клиентов к данным, инструментам и внешним системам. Благодаря MCP ИИ-агент может не только сформировать ответ, но и получить информацию из корпоративной базы, обратиться к сервису или выполнить разрешённое действие. При этом сам протокол не описывает, как ИИ-агент должен вести весь рабочий процесс: какие проверки выполнить, в какой последовательности действовать и что считать приемлемым результатом.</p> <p>Эту часть рабочего сценария описывают Agent Skills. Навык хранит инструкции, справочные материалы, шаблоны и при необходимости скрипты. По сути, это переносимое описание того, как выполнять определённую работу. Но навык и MCP-сервер до сих пор нередко приходилось по-разному размещать и настраивать в разных клиентах для работы с ИИ-агентами.</p> <p>Agent Plugins 1.0 добавляет ещё один уровень — стандартную упаковку и обнаружение компонентов. В корне плагина находится манифест plugin.json, навыки размещаются в папке skills, а конфигурация MCP-серверов — в mcp.json. Стандарт не заменяет MCP и Agent Skills и не добавляет агентам новых возможностей. Он объединяет существующие компоненты в общий переносимый пакет, который совместимый клиент может проверить, обнаружить и загрузить.</p> <p>Для бизнеса это означает возможность тиражирования: один раз собранный для конкретного рабочего сценария плагин не нужно заново упаковывать под каждый совместимый ИИ-инструмент. Его можно передавать другим пользователям и подключать в разных рабочих средах. Инструкции и базовая структура интеграций при этом сохраняются, однако доступы, установка и функции конкретного инструмента требуют отдельной проверки.</p> <h2>От личного ИИ-помощника до сложного корпоративного процесса</h2> <p>Agent Plugins 1.0 не ограничен определённым типом задач. В формате плагина можно упаковать как простой сценарий, связанный с одним сервисом, так и многоэтапный процесс, в котором ИИ-агент обращается к нескольким корпоративным системам. Сам стандарт не содержит готовых бизнес-сценариев, но включает примеры и подробное описание компонентов, из которых можно собрать плагин.</p> <h3>Простой сценарий: организация встречи</h3> <p>Пользователь просит ИИ-агента подобрать время для встречи с несколькими коллегами на следующей неделе. В навыке можно зафиксировать правила и порядок действий: продолжительность встречи, допустимое время, обязательных участников и их роли, часовые пояса и другие ограничения.</p> <p>Через MCP-сервер агент получает доступ к календарям, сравнивает свободные интервалы и предлагает подходящие варианты. После подтверждения пользователя агент может создать встречу, добавить участников, описание и ссылку для подключения.</p> <p>В результате в плагине сохраняется не только конфигурация подключения к календарю, но и весь порядок действий: какие данные проверить, как выбрать время и в какой момент запросить подтверждение.</p> <h3>Сложный сценарий: обработка клиентского обращения</h3> <p>Более сложный плагин может сопровождать обращение клиента от поступления до передачи в работу. ИИ-агент определяет суть запроса, проверяет наличие необходимых данных, находит информацию о клиенте и договоре в CRM, изучает предыдущие обращения в сервисной системе и сверяется с корпоративной базой знаний.</p> <p>Навык задаёт последовательность проверки, правила распределения обращений, требования к ответу и случаи, когда необходимо участие специалиста. Через MCP-серверы агент получает данные из корпоративных систем и выполняет разрешённые действия: например, готовит проект ответа, создаёт задачу для ответственного подразделения или предлагает изменить статус обращения. Отправка сообщения клиенту и другие значимые действия выполняются только после подтверждения сотрудника.</p> <p>Такой плагин объединяет уже не одну инструкцию, а целый рабочий процесс с несколькими источниками данных, правилами доступа, точками контроля и шаблонами результата.</p> <p>Принцип в обоих сценариях остаётся одинаковым: навык определяет, как выполнять работу, а MCP-серверы предоставляют необходимые данные и разрешённые действия. Поэтому плагин подходит и для небольшой повседневной задачи, и для сложного процесса, связанного с несколькими корпоративными системами.</p> <h2>Что важно учесть при подключении плагина в разных ИИ-инструментах</h2> <p>Agent Plugins 1.0 позволяет использовать один и тот же пакет в разных совместимых клиентах — то есть ИИ-инструментах, которые поддерживают этот формат. Вместе с пакетом переносятся инструкции, шаблоны, справочные материалы и конфигурация MCP-подключений. При этом права доступа, установка и функции конкретного инструмента остаются на стороне клиента.</p> <p>Перед распространением плагин необходимо протестировать во всех целевых рабочих средах и указать, в каких ИИ-инструментах его работа была проверена.</p> <p>При подключении плагина к другому ИИ-инструменту потребуется отдельно проверить и настроить:</p> <ul> <li> <strong>Доступ к корпоративным системам.</strong> Пользователям может потребоваться повторная авторизация, а компании — настройка прав, учётных данных и сетевых ограничений.</li> <li><strong> Возможности конкретного ИИ-инструмента.</strong> Например, ChatGPT, Codex, Cursor, GitHub Copilot, Kiro и VS Code могут различаться по поддержке отдельных функций и способам их реализации. Если сценарий зависит от функции конкретного инструмента, в другом она может быть недоступна или работать иначе. Поэтому при разработке плагина лучше по возможности избегать функций, привязанных к конкретному ИИ-инструменту.</li> <li><strong> Выполнение рабочего сценария.</strong> Из-за различий между моделями, системными настройками и механизмами подтверждения действий один и тот же плагин может давать разные результаты. При этом ИИ-инструмент и модель ИИ — разные компоненты. Например, ChatGPT — ИИ-инструмент, а GPT — семейство моделей, которые он может использовать. Поэтому тестировать необходимо связку конкретного инструмента и выбранной модели.</li> <li><strong> Установку и распространение.</strong> Каждый ИИ-инструмент по-своему организует подключение плагинов, выдачу доступа пользователям и установку обновлений.</li> </ul> <p>Таким образом, новый стандарт позволяет не собирать сам плагин заново, но не отменяет настройку доступов, проверку интеграций и тестирование. Чем больше в решении внешних систем и функций, зависящих от конкретного ИИ-инструмента, тем больше дополнительных работ потребуется при его использовании в другом клиенте.</p> <h2>Где новый стандарт можно использовать уже сейчас</h2> <p>Хотя спецификация пока продолжает развиваться, её уже можно использовать, если решение планируется распространять как целостный пакет. Единая структура может упростить подключение и распространение плагина.</p> <p>Особенно это актуально для систем, которые в дальнейшем планируется развивать, подключать к новым корпоративным сервисам или использовать в разных ИИ-инструментах.</p> <p>Это не означает, что существующие решения необходимо срочно переводить на Agent Plugins 1.0. Но при проектировании можно сразу разделять инструкции агента, справочные материалы, конфигурации подключений и компоненты, зависящие от конкретного ИИ-инструмента. Предыдущие наработки также можно постепенно адаптировать под новый формат.</p> <h2>Какие выводы можно сделать</h2> <p>Главная ценность Agent Plugins 1.0 — возможность отделить описание рабочего сценария, инструкции, накопленную экспертизу и конфигурацию интеграций от конкретного ИИ-инструмента.</p> <p>Независимо от конкретной технологии, инженерный принцип прост: если для задачи уже существует подходящий стандарт и его можно использовать, лучше опираться на него, а не создавать собственный формат. Это сокращает объём повторной работы, упрощает развитие решения и снижает зависимость от конкретного инструмента.</p> <p>Применительно к Agent Plugins 1.0 это означает, что формат стоит учитывать уже сейчас в проектах, для которых важны переносимость, повторное использование компонентов и подключение к разным ИИ-инструментам.</p> <p>При этом формат не делает модель умнее и не заменяет проектирование самого процесса. Чтобы воспользоваться его преимуществами, компания должна понимать, какие данные использует агент, по каким правилам действует и когда передаёт решение человеку. Поэтому готовность к применению стандарта зависит не только от ИТ-инфраструктуры, но и от зрелости бизнес-процессов.</p> <p>Если рабочая логика формализована, созданные сценарии смогут сохранять ценность даже при смене ИИ-инструментов. Спецификация пока новая и будет развиваться, поэтому важно следить за её изменениями и поддержкой со стороны разных клиентов. По нашему мнению, Agent Plugins 1.0 — важный шаг к более управляемому и повторно используемому применению ИИ в корпоративных системах.</p> <p>#IMAGE_235329#</p> Недавно была опубликована спецификация Agent Plugins 1.0.0 — проекта открытого стандарта для упаковки навыков … article Эдуард Забоев, технический директор DIGITAL SECTOR https://www.itweek.ru/themes/detail.php?ID=235326 Wed, 12 Aug 2026 09:20:35 +0300 <p>Интерес российского бизнеса к CRM- и ERP-системам с интеграцией искусственного интеллекта за последний год вырос в <a href="https://corp.cnews.ru/news/line/2025-07-10_interes_rossijskih_kompanij" title="https://corp.cnews.ru/news/line/2025-07-10_interes_rossijskih_kompanij">два-три раза</a>. Количество поисковых запросов «Битрикс24 ИИ» увеличилось на 600%, «CRM с нейросетью» — на 550%, «ИИ в 1С» — на 85%. При этом, <a href="https://corp.cnews.ru/news/line/2026-01-22_39_rossijskih_kompanij_v" title="https://corp.cnews.ru/news/line/2026-01-22_39_rossijskih_kompanij_v">по данным</a> исследования «СберАналитики» и «Сбер Бизнес Софт», 39% российских организаций уже используют ИИ-агентов и ассистентов для автоматизации документооборота, финансов и HR. Однако в ERP-системы ИИ только начинает проникать. Чаще всего это пока отдельные подсистемы-сателлиты, которые интегрированы с ERP. Почему так происходит и как правильно встраивать интеллектуальные модули в уже работающие корпоративные приложения?</p> <h3>Рынок созрел, но внедрения с ИИ точечные</h3> <p>Объем российского рынка ERP-систем по итогам 2025 года <a href="https://sarnovosti.ru/news/sber-sozdaet-erp-budushchego-/?erid=2Vfnxy9PNyp" title="https://sarnovosti.ru/news/sber-sozdaet-erp-budushchego-/?erid=2Vfnxy9PNyp">оценивается</a> примерно в 100 млрд. рублей и продолжает плавно расти. При этом интерес к использованию встроенных ИИ-инструментов в корпоративных системах огромный. Но пока еще процент компаний, реально применяющих ИИ в ERP, остается небольшим. Сейчас начинают появляться ИИ-сервисы, которые могут встраиваться по API в ERP-системы.</p> <p>Но прежде чем браться за внедрение, компаниям предстоит ответить на несколько принципиальных вопросов.</p> <h3>Где ИИ действительно полезен</h3> <p>Искусственный интеллект эффективен там, где есть большие объемы данных или текста, много рутины, необходимы прогнозы, поиск аномалий или важен интерфейс для сотрудников на естественном языке. В корпоративных системах таких точек множество. Распознавание и обработка первичных документов — сканов и фотографий счетов, накладных, актов. ИИ позволяет заводить их в систему с автоматическим формированием документов. Сегодня такие проекты могут быть реализованы буквально в течение месяца.</p> <p>Еще один вектор — прогнозирование спроса, закупок, производства и движения денежных средств на основе исторических данных. Контроль качества данных: выявление дублей, ошибок ввода, выбросов и аномалий. Копилоты и запросы к данным на естественном языке — например, в формате: «Покажи маржу по региону за квартал».</p> <p>Также ИИ хорошо разгружает направление ИТ-поддержки и развития ERP-систем. Может заниматься классификацией и маршрутизацией обращений, next-best-action в CRM, автоподготовка проектов ответов в Service Desk. Успешно справляется с генерацией драфтов писем, коммерческих предложений, документации. И, наконец, это помощь разработчикам и эксплуатационным командам: ассистенты кода, разбор логов, ИИ ServiceDesk.</p> <h3>Три уровня встраивания ИИ: над, внутри и под</h3> <p>Встраивать ИИ в существующие системы можно тремя способами, и каждый имеет свою логику.</p> <ol> <li><strong>Слой над системой</strong> — копилоты, запросы на естественном языке, аналитика. Этот подход не затрагивает ядро системы, внедряется быстро и безопасно, поэтому считается отличной точкой старта ИИ-трансформации.</li> <li><strong>Сервисы внутри или рядом с системой</strong> — распознавание, прогнозирование, классификация. Подключаются через вызовы API и расширения. Именно здесь ИИ встраивается непосредственно в прикладные модули ERP, CRM, MES, Workflow.</li> <li><strong>Слой под системой</strong> — данные, СУБД, инфраструктура. Эффективен для разбора логов, мониторинга и контроля качества данных. Например, ИИ может за считанные минуты написать скрипт парсинга сотен гигабайт технологических логов и выявить причины сбоев и медленных запросов. За день интенсивной работы можно получить 100 Гб текста в формате логов. Даже профильный специалист будет разбирать такой объем вручную несколько дней, а ИИ выдает результат для оценки эксперта за минуты.</li> </ol> <h3>Заменять или достраивать — и когда все-таки заменять?</h3> <p>У многих компаний возникает соблазн: не мучиться с интеграцией, а просто заменить старую систему на AI-native решение следующего поколения. Однако опыт показывает, что это самый дорогой, долгий и рискованный путь.</p> <p>При таком подходе «выбрасываются» годы настройки процессов, интеграции, накопленные данные и доверие пользователей. Сам по себе ИИ почти никогда не оправдывает полную замену. В коробочных решениях он как правило, универсален и не заточен под данные и процессы конкретного предприятия. Данные все равно придется мигрировать, процессы настраивать, а людей — переучивать. Полная замена оправданна лишь в нескольких ситуациях: система зашла в тупик по развитию, вендор ушел с рынка, а технологический стек нежизнеспособен. Во всех остальных случаях разумнее достраивать — дополнять текущую систему зрелыми проверенными компонентами, например сервисами «1С», GigaChat, YandexGPT, и настраивать их под контекст конкретного бизнеса.</p> <h3>Главный принцип: не навреди</h3> <p>Ключевое правило встраивания ИИ в традиционные бизнес-приложения — подключение интеллектуальных модулей как изолированного сервиса. Отказ или деградация модели не должны влиять на действующую основную систему. Обязательны резервный сценарий на случай отказа ИИ, сотрудник в контуре для критичных действий. Особенно это важно там, где ИИ касается цифр. Генеративные модели вероятностны и могут ошибаться правдоподобно. В черновике письма или в кратком пересказе такая ошибка стоит недорого и легко правится человеком, а в проводке или налоговом регистре — это уже последствия для отчетности перед ФНС и СФР. Именно поэтому в регламентированном контуре ИИ остается ассистентом: он распознает, предлагает, заполняет черновик, но официальную учетную запись формирует проверенный механизм системы, а критичное действие подтверждает человек. Каждое действие модели должно быть прослеживаемым — какая версия, на каких данных, кто подтвердил результат, — иначе аудитор не восстановит происхождение цифры. ИИ готовит цифру, но отвечает за нее система и человек.</p> <p>Еще один важный аспект — безопасность данных. После 2022 года большинство крупных заказчиков стремятся развертывать ИИ-модели внутри собственного контура. Клиенты не готовы отдавать данные за пределы компании. Поэтому стараются делать так называемые ПАКи. Оборудование, операционная система и модель ставятся внутрь компании, и к ним через API добавляются необходимые ИИ-сервисы.</p> <h3>С чего начать: рекомендации для ИT-директоров</h3> <p>Первое и самое важное — посчитать экономику. Внедрение ИИ должно быть дешевле, чем решение задачи силами сотрудников, или приносить измеримый бизнес-эффект. Второе — выбрать пилотный проект с быстрой окупаемостью. Лучшие кандидаты для первых экспериментов — распознавание первичных документов, копилот для отчетности, ИИ Service Desk для первой линии поддержки. Третье — обеспечить изоляцию ИИ-сервиса от критического ядра системы. Четвертое — подготовить резервные сценарии: если ИИ не справляется, процесс должен продолжаться в ручном режиме. И пятое — не пытаться внедрить ИИ повсеместно. В системе нужно найти место, где ИИ применим и экономически обоснован, а также бизнес готов к его внедрению. Это поможет добиться первых побед для выделения инвестиций на новые кейсы.</p> <p>Искусственный интеллект в ERP — это не хайп, а инструмент, который уже сегодня помогает снижать стоимость владения системами, ускорять разработку и эксплуатацию, а главное — создавать новую ценность для бизнеса. Но как и любой инструмент, он требует вдумчивого подхода. Начинать стоит с малого: копилоты, распознавание документов, прогнозирование. Постепенно наращивать компетенции и масштабировать успешные практики. И главное — помнить: ИИ должен работать на бизнес, а не бизнес — на ИИ.</p> <p>#IMAGE_235327#</p> Интерес российского бизнеса к CRM- и ERP-системам с интеграцией искусственного интеллекта за последний год … article Илья Бычков, директор направления разработки практики “1С” компании “Рексофт” https://www.itweek.ru/themes/detail.php?ID=235325 Wed, 12 Aug 2026 09:12:21 +0300 <p><em>Согласно Gartner, до конца 2028 г. ни одна масштабная корпоративная рабочая нагрузка искусственного интеллекта не будет выполняться на квантовом оборудовании, а классический ускоренный ИИ будет доминировать во всех производственных бенчмарках, сообщает портал </em><em>HPCwire</em><em>.</em></p> <p>Квантовый ИИ (Quantum AI) относится к методам ИИ или машинного обучения, которые требуют выполнения на квантовом оборудовании для достижения заявленного преимущества в производительности, стоимости или возможностях по сравнению с классическими вычислениями.</p> <p>«Для достижения отказоустойчивых квантовых вычислений в масштабе, необходимом для получения измеримых преимуществ в производительности или снижении затрат на ИИ, требуются достижения в четырех областях: аппаратное обеспечение, коррекция ошибок, промежуточное ПО и алгоритмы», — говорит Чираг Декате, вице-президент-аналитик Gartner.</p> <p>Настоящий квантовый ИИ отличается от трех часто путаемых категорий:</p> <ul> <li><strong> Классический ИИ:</strong> модели ИИ, такие как глубокое обучение, трансформеры и обучение с подкреплением, которые работают исключительно на CPU, GPU или TPU и обеспечивают измеримую окупаемость инвестиций для предприятий уже сегодня.</li> <li><strong> ИИ, дополненный квантовыми методами (</strong><strong>Quantum</strong><strong>-</strong><strong>inspired</strong> <strong>AI</strong><strong>):</strong> классические алгоритмы, заимствующие идеи из квантовой механики, такие как отжиг, тензорные сети и амплитудное кодирование, но работающие на обычном оборудовании. Эти методы уже приносят пользу в задачах оптимизации, моделирования и выборки и не зависят от квантового оборудования.</li> <li><strong> Гибридные квантово-классические методы:</strong> экспериментальные рабочие процессы, в которых небольшие квантовые схемы используются совместно с классическим ИИ или высокопроизводительными вычислительными системами (HPC). Эти подходы используются для исследований и пилотных проектов с поддержкой поставщиков, а не для производственного ИИ.</li> </ul> <p>«Когда поставщики заявляют о предоставлении „квантового ИИ“, они обычно имеют в виду гибридные или дополненные квантовыми технологиями методы, а не нативно-квантовый ИИ, работающий в масштабах предприятия, — отмечает Декате. — Настоящие квантовые вычисления не готовы ни к одной производственной ИИ-нагрузке и, скорее всего, не будут готовы до конца этого десятилетия. Более того, ни один рецензированный результат не демонстрирует квантового преимущества в производственных ИИ-нагрузках».</p> <p>Формирование пула поставщиков, ориентированных на конвергенцию квантовых технологий и ИИ, ускоряется, и советы директоров, находящиеся под давлением необходимости «не упустить квантовые технологии», будут склонны перенаправлять ИИ-бюджеты на НИОКР, которые не смогут принести пользу в этом десятилетии. Поэтому Gartner прогнозирует, что отказоустойчивые квантовые вычисления для ИИ до конца 2030 г. останутся на стадии НИОКР, с недостаточным масштабом логических кубитов для поддержки экономически жизнеспособных сквозных алгоритмов ИИ.</p> <h3>Разделите квантовый бюджет и ИИ-бюджет</h3> <p>Квантовые НИОКР и производственная инфраструктура ИИ имеют несовместимые временные горизонты, юнит-экономики и потребности в управлении. Генеративный ИИ приносит измеримую отдачу по показателям скорости выполнения, точности и автоматизации в течение <nobr>12-18 месяцев.</nobr> Между тем, квантовый ИИ никогда еще не приносил измеримой ценности ни в одной производственной рабочей нагрузке и вряд ли сделает это в обозримом будущем.</p> <p>«Смешивание двух бюджетов искажает подотчетность обоих и позволяет квантовой опциональности вытеснять производственные возможности ИИ, — говорит Декате. — CIO на постоянной основе включают генеративный ИИ, агентный ИИ, кибербезопасность и облачные технологии в категории основных расходов. Квантовые технологии не фигурируют в списках приоритетных инвестиций. CIO, которые финансируют квантовые технологии, делают это по значительно более низким ставкам, чем генеративный ИИ, и не требуют краткосрочной окупаемости инвестиций».</p> <p>Чтобы получить максимальную отдачу от квантовых решений, предприятиям следует:</p> <ul> <li><strong> Внедрять классические методы, дополненные квантовыми технологиями, в существующий стек ИИ.</strong> Организациям следует отдавать приоритет алгоритмам, дополненными квантовыми методами, работающим на современной инфраструктуре GPU, а не развитию квантового оборудования. В таких областях, как оптимизация, генеративный ИИ, линейная алгебра, анализ графов и обучение с подкреплением, классические подходы обеспечивают аналогичные преимущества без затрат, сложности или незрелости квантовых систем.</li> <li><strong> Определить критерии прекращения пилотного проекта и не вестись на показуху со стороны поставщиков.</strong> Каждый пилотный квантовый проект должен начинаться с предварительного определения показателей успеха, четкого классического эталона и явных условий прекращения. Это предотвращает чрезмерное расходование бюджета на бесконтрольные эксперименты без получения измеримой ценности.</li> <li><strong> Отслеживать значимый квантовый прогресс.</strong> Наиболее важным показателем прогресса является не количество физических кубитов, а доступность логических кубитов, работающих с приемлемым уровнем ошибок. Достижения в области коррекции ошибок, калибровки с помощью ИИ и квантового управления более важны для получения бизнес-ценности, чем громкие заявления о более крупных квантовых процессорах.</li> </ul> Согласно Gartner, до конца 2028 г. ни одна масштабная корпоративная рабочая нагрузка искусственного … article https://www.itweek.ru/themes/detail.php?ID=235324 Tue, 11 Aug 2026 13:14:15 +0300 <p>Компания «ИТ-Экспертиза» представила версию программного комплекса информационной безопасности (ПК ИБ) САКУРА 3.3. Среди ключевых изменений — многофакторная аутентификация, интеграция с OpenVPN и почтовым сервером, безопасный доступ и управление секретами с поддержкой HashiCorp Vault.</p> <p>Обновление направлено на усиление контроля доступа, расширение возможностей интеграции и улучшение пользовательского опыта.</p> <p>Реализованная в САКУРА 3.3 многофакторная аутентификация и подтверждение через мобильное приложение усиливает безопасный доступ к ИТ-инфраструктуре. Система включает профили MFA (многофакторной аутентификации), команды сценариев и интеграцию с разными LDAP-каталогами. Также добавлено безопасное управление секретами с поддержкой HashiCorp Vault и возможностью переключения между провайдерами хранения. Эта функциональность обеспечивает дополнительный уровень защиты критически важных данных и учётных записей.</p> <p>В данной версии реализована интеграция с популярным VPN-решением OpenVPN, что расширяет возможности контроля сетевого доступа. Добавлен новый тип внешней системы — почтовый сервер для отправки событий и уведомлений. Также улучшена обработка ответов в интеграции с SCCM и расширены способы сбора информации в интеграции с КриптоПро NGate. Эти обновления позволяют организациям более гибко настраивать инфраструктуру безопасности и автоматизировать уведомления.</p> <p>Улучшена производительность агентов для Windows, что особенно важно при работе на устройствах с ограниченными ресурсами. Добавлены алгоритмы автоматического определения домена при входе в систему, что упрощает администрирование в распределенных сетях.</p> <p>В ПК ИБ САКУРА 3.3 добавлена палитра команд (CommandPalette) с поддержкой быстрого доступа, истории и избранного, а также расширен набор горячих клавиш для удобства администраторов системы. В редакторе ролей реализован режим «Только для чтения» для снижения риска случайных изменений конфигурации.</p> <p>«В версии 3.3 мы сосредоточились на трёх ключевых направлениях: усиление безопасности через MFA и управление секретами, расширение экосистемы интеграций и улучшение пользовательского опыта. Эти изменения отражают потребности наших заказчиков в гибкой и удобной системе контроля и управления удаленными рабочими местами», — отметил Максим Ефремов, заместитель генерального директора по ИБ компании «ИТ-Экспертиза».</p> Компания «ИТ-Экспертиза» представила версию программного комплекса информационной безопасности (ПК ИБ) САКУРА 3.3. Среди … message https://www.itweek.ru/themes/detail.php?ID=235323 Tue, 11 Aug 2026 13:07:45 +0300 <p>Компания VolgaBlob обновила платформу Smart Monitor, предназначенную для аналитики, ИТ-мониторинга и построения SOC/SIEM. В релизе 6.1 акцент сделан на модули для работы с ИИ-инфраструктурой, также значительные обновления получило ядро платформы.</p> <p>Одним из ключевых изменений релиза стал потоковый коррелятор в Core — базовом модуле платформы. Ранее здесь использовалась ретроспективная корреляция, основанная на анализе накопленных исторических данных. Теперь оба подхода объединены: в интерфейсе появилась отдельная вкладка с правилами, позволяющими обрабатывать данные в момент их поступления.</p> <p>Потоковый коррелятор поддерживает полный цикл активных действий: создание инцидентов, запись в базу данных, работу с активными списками. Сочетание исторической и потоковой корреляции в рамках единой платформы — редкость на рынке, появление этой возможности в Smart Monitor существенно расширило сценарии применения системы.</p> <p>По мере того, как организации все активнее разворачивают ИИ-модели на локальных мощностях, растет потребность в специализированных инструментах контроля. Однако обычный инфраструктурный мониторинг не учитывает специфику ИИ: он не отслеживает использование GPU-памяти, стоимость запроса, трассировки ИИ-агентов, доступность ИИ-сервисов. Новая версия Smart Monitor закрывает этот пробел.</p> <p>В состав платформы вошел новый модуль AI Observability, который собирает телеметрию ИИ-контура из нескольких источников, нормализует ее в единый набор данных и предоставляет готовый коробочный контент. Он обеспечивает мониторинг ИИ-инфраструктуры: отслеживает состояние GPU, прокси- и инференс-серверов, контролирует производительность, доступность ресурсов, потребление токенов. В результате бизнес может видеть состояние, расходы и производительность инфраструктуры в едином окне и выявлять причины сбоев и перерасхода раньше, чем они скажутся на пользователях и бюджете.</p> <p>Собранные данные также используются в работе модуля AI Security, предназначенного для обнаружения угроз, связанных с ИИ-инструментами организации. Он анализирует действия локальных ИИ-агентов, запросы и ответы LLM, снимки конфигураций разрешений, регистрируя инциденты безопасности на их основе. В обновленной версии модуля добавлены новые правила безопасности, согласованные с конфигурациями сбора данных и разработанные в соответствии со стандартом OWASP Top 10 для AI. Правила охватывают сценарии компрометации ИИ-инфраструктуры, выявление угроз и инъекций, позволяя выстроить комплексную защиту корпоративных ИИ-систем.</p> <p>Также важно отметить, что в новой версии появился специальный фреймворк, предназначенный для задач машинного обучения — <nobr>«ML-студия».</nobr> Он реализован непосредственно внутри платформы и позволяет использовать готовую модель прогнозирования. Благодаря этому аналитики и инженеры теперь могут решать <nobr>ML-задачи</nobr> непосредственно в Smart Monitor. В наличии библиотека дефолтных алгоритмов с возможностью добавления собственных.</p> <p>Модуль поведенческой аналитики (UBA) получил новый оркестратор задач, через который теперь проходят все расчеты политик профилирования и обработка объектов. Ключевое техническое улучшение — переход на кластерную обработку: каждая нода берет объекты из очереди и обрабатывает их параллельно, что обеспечивает значительный прирост скорости. В интерфейсе появилось управление задачами: их можно останавливать, перезапускать или точечно запускать упавшие задачи.</p> <p>Модуль МАЯК, предназначенный для мониторинга сразу на нескольких уровнях (инфраструктура, сервисы, приложения) и позволяющий автоматически находить первопричины сбоев, получил Maintenance Mode — режим обслуживания. Если раньше объекты инфраструктуры, на которых проводились плановые технические работы, могли создавать ложные тревоги, то теперь их можно перевести в режим обслуживания — разово или с указанием временного интервала. Пока окно обслуживания активно, объекты не учитываются в модели здоровья, а в интерфейсе метрик отображается бейдж «технический перерыв».</p> <p>Инцидент-менеджер получил поддержку политик SLA. Теперь для инцидентов можно настраивать правила по рабочим процессам и статусам: время до назначения ответственного, время взятия в работу, время полного решения. При этом счетчик не сбрасывается при смене статуса — система сохраняет информацию о том, насколько заблаговременно был выполнен SLA.</p> <p>В планировщике задач внедрено распределение запусков по времени: система анализирует расписание всех актуальных заданий и предлагает оптимизацию. Это устраняет проблему одновременного старта сотен задач и пиковых нагрузок. Добавлен график нагрузки по запускам за сутки, введена многоуровневая система статусов ошибок — с отдельными индикациями ошибок поискового запроса и активного действия.</p> <p>«Новый релиз — логичный шаг в развитии Smart Monitor как единой платформы для observability, безопасности и анализа данных, которая закрывает новые потребности бизнеса в контроле над всей инфраструктурой, включая ИИ-контур», — прокомментировал Максим Кириенко, коммерческий директор VolgaBlob.</p> Компания VolgaBlob обновила платформу Smart Monitor, предназначенную для аналитики, ИТ-мониторинга и построения SOC/SIEM … message https://www.itweek.ru/themes/detail.php?ID=235322 Tue, 11 Aug 2026 13:06:39 +0300 <p>Специалисты компании «Информзащита» выявили, что 34% систем управления инженерной инфраструктурой ЦОД работают на устаревших прошивках. В выборке из 66 395 систем управления зданиями и инженерными процессами BMS более чем у трети устройств использовались неактуальные версии программного обеспечения. Одновременно 84% BMS обмениваются данными по небезопасным протоколам, а 800 устройств содержат известные эксплуатируемые уязвимости из категории KEV. Годом ранее исследование BMS в 529 организациях показывало другую сторону той же проблемы: 72% компаний эксплуатировали BMS с KEV, у 66% организаций присутствовали уязвимости, которые ранее использовались в ransomware-атаках, а у 48% такие уязвимости сочетались с небезопасным подключением к сети. Устаревшая прошивка опасна именно в сочетании с открытым протоколом и доступом из соседнего сегмента сети — а именно так выглядит типичная BMS.</p> <p>Причина такой ситуации во многом связана с жизненным циклом инженерного оборудования. В реальности за медленным патчингом чаще стоит более простая причина — у BMS просто нет владельца с точки зрения безопасности. Для корпоративной рабочей станции установка обновления может укладываться в стандартное окно обслуживания. С контроллером BMS, системой мониторинга электропитания или устройством, участвующим в управлении охлаждением, процедура устроена иначе. Перед обновлением необходимо проверить совместимость новой версии с контроллерами, датчиками, шлюзами и программным обеспечением диспетчеризации, согласовать работы с эксплуатационной службой и убедиться, что изменение прошивки не повлияет на технологический процесс. В дата-центре цена ошибки особенно высока, так как некорректная работа BMS способна затронуть охлаждение, энергоснабжение, резервные генераторы, пожарную автоматику и другие системы, работа которых связана с непрерывностью сервиса. Поэтому обновление нередко откладывается до следующего регламентного окна, а временное решение постепенно превращается в постоянное. </p> <p>Кроме того, значительная часть оборудования проектировалась в расчете на закрытую технологическую сеть, где основным требованием была стабильность обмена данными. Отсюда широкое распространение BACnet, MODBUS и других протоколов, в базовых реализациях которых отсутствуют привычные для IT-среды механизмы аутентификации и шифрования. 84% BMS используют небезопасные протоколы, причем BACnet применяется примерно на 42% таких систем. Это значит, что даже свежая прошивка не решает проблему целиком: обновление закрывает уязвимости в коде, но не меняет архитектуру протокола без аутентификации. Для систем мониторинга электропитания доля небезопасных протоколов составляет 82%, для UPS — 86%, для OT-контроллеров — 85%. В результате проблема старой прошивки редко существует изолированно. Одно устройство может одновременно иметь неподдерживаемую версию ПО, доступную для эксплуатации уязвимость и возможность принимать команды по протоколу, который изначально не предусматривает полноценной проверки отправителя.</p> <p>Разбивка по векторам атак показывает, что прямое подключение BMS к интернету представляет лишь один из сценариев. Из 66 395 исследованных BMS напрямую доступны из внешней сети 369 устройств, то есть менее 1%. Вместе с этим, реальный сценарий атаки — не сканирование интернета, а один шаг lateral movement из уже скомпрометированного IT-сегмента. Гораздо существеннее риск перемещения злоумышленника из уже скомпрометированного сегмента. В отдельной выборке инфраструктуры ЦОД 5 410 из 39 335 BMS, или 14%, находились всего в одном сетевом переходе от системы, связанной с интернетом. Для PDU этот показатель достигает 41%, для HVAC — около трети. Поэтому первым вектором остается компрометация смежного IT-, IoT- или сетевого узла с последующим lateral movement в технологический сегмент. Второй вектор связан с эксплуатацией известных уязвимостей в старых версиях прошивок. Третий — с воздействием непосредственно на технологический обмен через BACnet, MODBUS и другие протоколы без достаточной аутентификации. Еще один сценарий формируют средства удаленного администрирования и подрядчики, которым требуется доступ к BMS для обслуживания оборудования. Исследование BMS 2025 года отдельно относит неуправляемый сторонний удаленный доступ, открытые сетевые порты, слабую аутентификацию и неподдерживаемые версии ПО к характерным проблемам таких сред.</p> <p>Ситуацию осложняет организационное устройство эксплуатации ЦОД. Инженерная инфраструктура нередко находится в зоне ответственности служб, для которых приоритетами служат доступность, температурный режим, энергопотребление и выполнение SLA. ИБ-подразделение при этом может видеть серверы, сетевое оборудование и корпоративные системы, но не иметь такой же полноты данных о версиях прошивок контроллеров, шлюзов и BMS. Часть устройств устанавливается интеграторами или поставщиками инженерных систем и годами работает без пересмотра исходной конфигурации. Это создает сложный парк оборудования разных поколений, где одномоментное обновление невозможно. Наличие резервного оборудования само по себе проблему не закрывает: основной и резервный контроллеры могут иметь одинаковую версию прошивки и один набор уязвимостей. Если атакующий эксплуатирует эту уязвимость, откажут оба контроллера одновременно, резервирование страхует от отказа оборудования, но не от кибератаки. Именно поэтому наличие физического резервирования нельзя автоматически считать защитой от киберинцидента, связанного с эксплуатацией программной ошибки.</p> <p>Самая высокая доля устаревших прошивок обнаружена в системах мониторинга электропитания — 59%. Далее идут OT-системы управления с 48%, BMS с 40%, IoT и интеллектуальные датчики с 37% и UPS с 23%. Для операторов коммерческих и colocation-ЦОД особенно чувствительны BMS, PDU и охлаждение, поскольку нарушение их работы затрагивает одновременно инфраструктуру нескольких клиентов. Для облачных площадок и центров обработки данных с высокой плотностью вычислений возрастает зависимость от охлаждения и управления питанием. В корпоративных ЦОД тот же риск дополняется длительным сроком эксплуатации инженерного оборудования, которое зачастую обновляется значительно реже серверной части.</p> <p>Приоритетом для владельца ЦОД должна стать инвентаризация инженерных активов с привязкой к версии прошивки, модели устройства, статусу поддержки производителя и роли в технологическом процессе. Простого перечня IP-адресов здесь недостаточно: необходимо понимать, какие BMS управляют охлаждением, какие контроллеры участвуют в энергоснабжении, какие системы связаны с генераторами и пожарной автоматикой и по каким сетевым маршрутам к ним можно добраться. Обновления следует планировать исходя из эксплуатационной критичности и наличия реально используемых уязвимостей, в первую очередь закрывая KEV и устройства, доступные из смежных сегментов. Там, где установка новой прошивки невозможна, нужны компенсирующие меры: изоляция BMS от корпоративной сети, микросегментация, отказ от прямого интернет-доступа, контроль подрядчиков и выделенные механизмы удаленного подключения. Для BACnet, MODBUS и других технологических протоколов необходим мониторинг команд и отклонений от штатного поведения. Такая схема позволяет работать с устаревшим оборудованием без иллюзии, что закрытый внешний периметр автоматически делает инженерную инфраструктуру недоступной для атакующего.</p> Специалисты компании «Информзащита» выявили, что 34% систем управления инженерной инфраструктурой ЦОД работают … message https://www.itweek.ru/themes/detail.php?ID=235320 Tue, 11 Aug 2026 09:57:18 +0300 <p><em>Центры обработки данных сталкиваются с растущими рисками со стороны киберфизических систем (КФС). Безопасность операционных технологий (ОТ) имеет решающее значение для предотвращения сбоев и обеспечения операционной устойчивости, пишет на портале </em><em>Data</em> <em>Center</em> <em>Knowledge</em> <em>Шон Тафтс, технический директор Claroty.</em></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> <ul> <li><strong>Цепочка поставок.</strong> Технологии, обеспечивающие энергоснабжение и охлаждение современных дата-центров, быстро развиваются. Многие новые поставщики, включая стартапы и компании из регионов с частичным доверием, могут не иметь зрелых циклов безопасной разработки ПО и производственных процессов. По мере того, как эти технологии внедряются в критическую инфраструктуру, становятся необходимыми отказоустойчивые программы КФЗ для управления рисками со стороны третьих лиц.</li> <li><strong>Качество.</strong> Рынок вознаграждает скорость, и огромные деньги могут зависеть от соблюдения жестких сроков развертывания. Поскольку подрядчики, сторонние организации и внутренние команды работают быстрее, чем когда-либо, ошибки, связанные со скоростью, становятся все более распространенными. Примеры из реальной жизни включают неправильную настройку сегментации сети, открытые порты и неизмененные учетные данные по умолчанию.</li> </ul> <p>Скорость стала конкурентным преимуществом, но также и угрозой безопасности. Без надлежащего уровня управления организации рискуют строить критическую инфраструктуру будущего, используя сегодняшние слепые операционные зоны.</p> <h3>Что говорят исследования</h3> <p>Недавние исследования показывают, насколько напрямую эти уязвимости могут приводить к сбоям в работе. В недавнем <a href="https://claroty.com/team82/research/attacking-ups-network-cards-to-take-down-data-centers">отчете</a> Team82 «Attacking UPS Network Cards to Take Down Data Centers» были обнаружены уязвимости почти максимального уровня серьезности в сетевых интерфейсах, используемых для управления системами ИБП. Обход аутентификатора в сочетании с условием удаленного выполнения кода в худшем случае может позволить злоумышленнику обойти средства управления входом в систему и выдавать команды, которые прерывают подачу питания на защищенные нагрузки. В дата-центре это не просто неудобство. Потенциально это событие, способное привести к масштабному отключению.</p> <p>Результаты другого <a href="https://claroty.com/team82/research/turning-up-the-heat-hacking-trane-hvac-controllers">исследования</a> Team82 «Turning Up the Heat: Hacking Trane HVAC Controllers» выявили цепочку уязвимостей в широко используемом контроллере ОВиК, включая путь к удаленному доступу на уровне root без аутентификации и утечку конфиденциальных данных объекта. В совокупности такая цепочка может дать злоумышленнику влияние на системы охлаждения, которые напрямую определяют, остаются ли стабильными рабочие нагрузки высокой плотности. Охлаждение — это не фоновая система. От нее зависит время безотказной работы, и по мере увеличения плотности размещения оборудования в стойках запас по тепловому режиму уменьшается.</p> <p>Закономерность важнее отдельных инцидентов. В обоих случаях оборудование, о котором большинство команд ИТ-безопасности редко задумываются, оказалось именно тем оборудованием, которое определяет, останется ли объект в рабочем состоянии.</p> <h3>Устранение пробелов</h3> <p>Многие киберфизические устройства были разработаны для обеспечения безотказной работы и ремонтопригодности в эпоху ограниченных возможностей подключения и совершенно иной модели угроз. Сегодня подключенность является требованием бизнеса; удаленное обслуживание стало обычным явлением, и эти системы часто полностью выходят за рамки традиционного управления ИТ-уязвимостями. Команды по эксплуатации объектов располагают отношениями с поставщиками, но им не хватает рабочего процесса для отслеживания рисков, связанных со встроенным ПО. Команды безопасности знают, как операционализировать управление уязвимостями, но не контролируют активы.</p> <p>Начните с обеспечения видимости активов как в «серой», так и в «белой» зонах, чтобы знать, что имеется, где оно находится, с чем оно взаимодействует и какие протоколы и версии прошивки оно использует. Сопоставьте эти активы с операционными целями, чтобы ремедиационные и компенсационные меры отдавали приоритет тому, что наиболее важно для безотказной работы. Далее, сегментация должна стать первоклассным инструментом контроля бесперебойной работы, ограничивая обмен данными только необходимыми ресурсами, разрешая управляющий трафик только авторизованным каналам и разделяя сети управления и бизнес-сети, чтобы компрометация не приводила к масштабным проблемам на всем предприятии. Примените тот же подход к удаленному доступу, обеспечив надежную аутентификацию, принцип минимальных привилегий и возможность аудита сеансов для поставщиков и подрядчиков.</p> <p>Наконец, рассматривайте обнаружение и реагирование как киберфизические дисциплины, сопоставляя события безопасности с операционными аномалиями и обеспечивая, чтобы сценарии реагирования предвидели манипуляции с системами мониторинга и управления, с целью предотвращения превращения инцидентов в простои.</p> <h3>Почему это важный вопрос для руководства</h3> <p>Страховщики все чаще ожидают наличия проверяемых доказательств киберфизических мер контроля, обеспечивающих операционную устойчивость. Это означает прозрачность в отношении КФС-активов, сегментацию, ограничивающую радиус поражения, регулируемый удаленный доступ и отчетность, показывающую прогресс во времени. Эти ожидания все больше соответствуют строгим требованиям, предъявляемым к другим секторам критической инфраструктуры.</p> <p>Это переводит безопасность ОТ из технической в бизнес-тему. Если бесперебойная работа — это продукт, то киберфизическая устойчивость — это часть качества продукта.</p> <p>В отрасли справедливо уделяют основное внимание физическим угрозам и безопасности периметра. Но системы, обеспечивающие бесперебойную работу, охлаждение серверов и электроснабжение, заслуживают не меньшего внимания. Потому что, когда этот уровень выходит из строя, в новостях редко появляется сообщение «нарушение безопасности». Вместо этого появляется сообщение «сбой».</p> Центры обработки данных сталкиваются с растущими рисками со стороны киберфизических систем (КФС). Безопасность … article https://www.itweek.ru/themes/detail.php?ID=235318 Tue, 11 Aug 2026 09:41:54 +0300 <p><em>ИИ-агенты становятся полноценными участниками рабочих процессов. Для бизнеса это естественное продолжение автоматизации: если low-code позволяет оперативнее создавать приложения и сценарии, то ИИ-агенты быстрее выполняют действия внутри них. При этом ИИ-агент в корпоративной среде должен управляться через те же инструменты, что и сотрудник — роли, права, ограничения, ответственность и цифровой след.</em></p> <h3>Почему ИИ-агент — больше, чем помощник</h3> <p>На первом этапе корпоративный ИИ часто воспринимался как интеллектуальный ассистент: подготовить текст, найти информацию, кратко пересказать документ, помочь с письмом, предложить структуру презентации или сформулировать ответ. В такой модели риск ограничен: ассистент помогает человеку думать и готовить материалы, но финальное действие остается за сотрудником.</p> <p>Модель меняется. ИИ-агенты начинают подключаться к корпоративным системам и выполнять действия: создать карточку в системе управления взаимоотношениями с клиентами (CRM), обновить статус сделки, завести заявку, подготовить договор, назначить встречу, сформировать задачу в проектной системе, проверить соответствие данных, запустить рабочий процесс. Это другой уровень ответственности.</p> <p>Пока ИИ только предлагает текст, за ошибку несет ответственность человек. Когда агент меняет данные, инициирует процессы или выполняет действия, его ошибка может стать частью корпоративной системы. Поэтому к ИИ-агентам стоит относиться как к новому типу цифрового исполнителя.</p> <h3>Аналогия с человеком-ассистентом</h3> <p>Самый доступный способ объяснить принцип управления ИИ-агентом — сравнить его с человеком-ассистентом. Руководитель не предоставляет новому ассистенту полный доступ к почте, календарю, договорам, CRM, финансам, кадровым документам и коммерческим условиям. Сначала определяется роль: что человек должен делать, какие данные ему нужны, какие действия он может выполнять самостоятельно, а какие — только после согласования.</p> <p>Ассистент готовит письма, собирает материалы, создает черновики, вносит данные, но отправляет, утверждает и меняет условия только руководитель. С ИИ-агентом должна работать та же логика.</p> <p>Агенту нельзя давать доступ к данным, которые недоступны человеку на аналогичной роли. Если человеку нельзя самостоятельно выполнять критичное действие, то и агент не может иметь такую возможность. В корпоративной среде доверие должно подтверждаться не обещаниями, а настройками прав, журналом действий и контролем данных.</p> <h3>Какие действия могут выполнять ИИ-агенты</h3> <p>ИИ-агенты могут быть полезны в разных корпоративных сценариях.</p> <p>В продажах они могут готовить резюме по клиенту, обновлять карточку сделки, формировать план действия после встречи, предлагать следующий шаг, собирать материалы для предпродажной подготовки.</p> <p>В клиентском сервисе — классифицировать обращения, предлагать ответы, создавать заявки, проверять статус выполнения, передавать сложные случаи ответственным сотрудникам.</p> <p>В HR — готовить описания вакансий, собирать данные по кандидатам, формировать черновики писем, помогать с адаптационными маршрутами.</p> <p>В закупках и договорной работе — проверять комплектность документов, готовить черновики запросов, сверять условия, напоминать о сроках согласования.</p> <p>В ИТ и эксплуатации — создавать заявки, анализировать инциденты, предлагать решения, обновлять статусы, собирать информацию из мониторинга и базы знаний.</p> <p>Во всех этих сценариях ценность ИИ-агента возникает благодаря способности сокращать ручные операции и помогать сотруднику быстрее проходить процесс.</p> <p>Чем ближе агент к данным, деньгам, обязательствам и клиентам — тем строже правила.</p> <h3>Три уровня автономности</h3> <p>На практике рекомендуется разделять ИИ-агентов по уровню автономности.</p> <p>Первый уровень — агент предлагает. Он анализирует информацию, готовит черновик, рекомендует действие, подсвечивает риск или собирает данные, но ничего не меняет в системе без участия человека. Это самый безопасный сценарий, подходящий для первых внедрений, так как у сотрудника сохраняется контроль над ИИ.</p> <p>Второй уровень — агент готовит действие к утверждению. Он может сформировать заявку, подготовить изменение в CRM, собрать пакет документов, создать черновик письма или предложить изменение статуса, но финальное подтверждение делает человек. Такой уровень подходит для процессов, где важно ускорить подготовку, но нельзя полностью автоматизировать ответственность.</p> <p>Третий уровень — агент выполняет действие автоматически. Он может самостоятельно создавать задачи, обновлять статусы, отправлять уведомления, запускать стандартные процессы, переносить данные между системами. Этот уровень допустим только для качественно описанных, низкорисковых и контролируемых сценариев.</p> <p>Критичные операции — платежи, изменение коммерческих условий, юридически значимые действия, доступ к чувствительным данным, массовые рассылки, изменение прав пользователей — должны оставаться под контролем человека.</p> <h3>Какие риски нужно учитывать</h3> <p>Риск ИИ-агента заключается в том, что неправильное действие может быть выполнено быстро, с доступом к реальным данным и системам.</p> <ul> <li><strong>Избыточные права.</strong> Если агенту дали доступ ко всем данным «на всякий случай», он может использовать ненужную для конкретной задачи информацию. Это повышает риски утечек, нарушений политики доступа и некорректного использования данных.</li> <li><strong> Избыточная автономность.</strong> Возможность агента выполнять действия без подтверждения требует от компании уверенности в стабильности сценария и отсутствии критичных последствий.</li> <li> <strong>Непрозрачность действий.</strong> Отсутствие информации об инициаторе действия, запросе, использовании данных и внесенных изменениях лишает компанию управляемости.</li> <li><strong> Ошибочная интерпретация задачи.</strong> ИИ-агент может неверно понять контекст, выбрать неподходящие данные, перепутать приоритет, не учесть исключение или выполнить формально правильное действие в неправильной ситуации.</li> <li> <strong>Размытая ответственность.</strong> Если агент ошибся, кто отвечает? Пользователь, который дал запрос? Владелец процесса? ИТ? Команда, которая настроила агента? Поставщик платформы? Эти вопросы важно решать до запуска, а не после инцидента.</li> </ul> <h3>Что должно быть в модели управления ИИ-агентами</h3> <p>Для промышленного применения ИИ-агентов необходима понятная управленческая модель.</p> <ul> <li><strong>Роль агента. </strong>У каждого агента должно быть назначение: какую задачу он решает, в каком процессе работает, кому помогает, какие действия выполняет и кто является владельцем сценария.</li> <li><strong>Ограничение прав. </strong>Агент должен иметь доступ только к тем данным и действиям, которые нужны для его роли, а не ко всей системе, документам и клиентам.</li> <li><strong>Перечень допустимых действий. </strong>Необходимо заранее определить и зафиксировать: что агент может делать сам, что — только подготовить, а что запрещено.</li> <li><strong>Подтверждение человеком для критичных операций</strong>. Если действие влияет на деньги, юридические обязательства, клиентов, права доступа, персональные данные или критичный процесс — агент готовит, человек утверждает.</li> <li><strong>Цифровой след. </strong>Компания должна видеть, кто инициировал действие, какой агент его выполнил, какие данные использовались, что было изменено, когда это произошло и кто подтвердил результат.</li> <li><strong>Мониторинг и возможность остановки. </strong>У агента должен быть владелец, а у компании — возможность быстро отключить сценарий, ограничить права, остановить автоматическое действие или пересмотреть правила.</li> <li><strong>Регулярная проверка. </strong>ИИ-сценарии не должны запускаться и забываться. Их необходимо пересматривать: меняются процессы, данные, системы, требования ИБ, регуляторика и поведение пользователей.</li> </ul> <h3>Почему это связано с low-code</h3> <p>Low-code и ИИ-агенты усиливают друг друга. Low-code дает среду для быстрого создания приложений, интерфейсов, рабочего процесса и интеграций. ИИ-агенты добавляют интеллектуальный слой: помогают принимать решения, готовить действия, обрабатывать данные и взаимодействовать с системами.</p> <p>Вместе они могут значительно ускорить корпоративные изменения, но при этом повышают требования к управлению. Если low-code без правил ведет к зоопарку приложений, то ИИ + low-code без правил — к зоопарку действий: автоматических, некачественно описанных, с разными правами, уровнем контроля и размытой ответственностью.</p> <p>ИИ-агенты должны быть встроены в ту же модель системы управления, что и low-code-контур: роли, права, архитектурные ограничения, ИБ, реестр, сопровождение, мониторинг и экономика.</p> <h3>Практический чек-лист перед запуском ИИ-агента</h3> <p>Перед запуском ИИ-агента в корпоративный процесс стоит ответить на вопросы:</p> <ol> <li> Какую конкретную задачу решает агент?</li> <li> Кто владелец процесса и агента?</li> <li> Какие данные агенту действительно нужны?</li> <li> Какие действия он может выполнять самостоятельно?</li> <li> Какие действия требуют подтверждения человеком?</li> <li> Какие действия агенту запрещены?</li> <li> Где фиксируется цифровой след?</li> <li> Как пользователь понимает, что действие выполнил агент?</li> <li> Кто разбирает ошибочные действия?</li> <li> Как агент отключается или ограничивается при инциденте?</li> <li> Как часто пересматриваются его права и сценарии?</li> <li> Как оценивается эффект: скорость, качество, снижение ручного труда, риски?</li> </ol> <p>Без ответов на эти вопросы запускать агента в промышленный процесс рано. Его можно тестировать, использовать в ограниченном контуре, проверять гипотезу, но не наделять полномочиями, влияющими на критичные операции.</p> <h3>Роль интегратора</h3> <p>В корпоративной среде внедрение ИИ-агентов — не только настройка модели или подключение инструмента к внутренней системе. Это проектирование управляемого цифрового участника процесса. Интегратор помогает определить применимые сценарии, описать роли и права агентов, встроить их в существующие процессы, связать с low-code-платформами, настроить контроль данных, журналирование, подтверждение человеком и сопровождение.</p> <p>Крупному бизнесу нужны не быстрые приложения и умные помощники, а управляемая система изменений, где каждый участник — человек, приложение или ИИ-агент — действует в обозначенных границах. Задача интегратора: помочь компании запустить безопасный, поддерживаемый и промышленно применимый ИИ + low-code сценарий.</p> <h3>Практический вывод</h3> <p>ИИ-агенты становятся частью корпоративных процессов, поэтому к ним следует относиться как к части операционной модели.</p> <p>Каждый агент должен иметь роль с четкими правами, права — с ограничениями, действия — с цифровым следом, критичные операции — с подтверждением человеком, а весь сценарий — с назначенным владельцем. Только в такой модели ИИ-агенты смогут предлагать бизнесу скорость без потери контроля.</p> <p>В корпоративной среде доверие к ИИ строится не на том, насколько убедительно он отвечает, а на том, насколько управляемо он действует.</p> <p>#IMAGE_235319#</p> ИИ-агенты становятся полноценными участниками рабочих процессов. Для бизнеса это естественное продолжение автоматизации: если … article Михаил Миронов, директор отделения low-code-решений группы компаний IBS https://www.itweek.ru/themes/detail.php?ID=235317 Mon, 10 Aug 2026 18:21:18 +0300 <p>Системный интегратор DCLogic и разработчик российской observability платформы GMONIT приступили к совместной интеграции платформ INFRABASE и GMONIT. Меморандум о технологическом и стратегическом партнерстве компании подписали на ежегодной конференции GMONIT Observability Day 2026.</p> <p>DCLogic развивает платформу INFRABASE для управления ИТ-инфраструктурой и автоматизации жизненного цикла виртуальных машин. GMONIT — одноименную observability платформу, обеспечивающую комплексную наблюдаемость цифрового контура. Интеграция позволит объединить данные о состоянии цифровых сервисов и ИТ-инфраструктуры с инструментами управления ресурсами, планирования вычислительных мощностей и FinOps.</p> <p>Двусторонний обмен данными между платформами объединит возможности GMONIT в области наблюдаемости цифрового контура и инструменты INFRABASE для управления ИТ-инфраструктурой. GMONIT будет предоставлять INFRABASE данные о работе приложений, инфраструктуры и цифровых сервисов для анализа загрузки ресурсов, прогнозирования потребности в вычислительных мощностях и подготовки рекомендаций по оптимизации инфраструктуры. В свою очередь, результаты анализа и рекомендации, сформированные в INFRABASE, смогут использоваться в GMONIT для дальнейшей оценки состояния цифровых сервисов и планирования развития ИТ-инфраструктуры.</p> <p>В настоящее время специалисты компаний ведут проектирование интеграции, разрабатывают архитектуру взаимодействия платформ, проводят нагрузочное тестирование и валидацию совместного решения. После завершения испытаний оно станет доступно для коммерческого внедрения.</p> <p>«Современные инструменты по наблюдаемости, учету и прогнозированию инфраструктуры должны не только показывать состояние информационных систем, но и помогать принимать решения по развитию инфраструктуры. Интеграция платформ INFRABASE и GMONIT позволит перейти от мониторинга к интеллектуальному управлению вычислительными ресурсами. Для заказчиков это означает более точное планирование мощностей, повышение эффективности использования инфраструктуры и снижение эксплуатационных затрат», — отметил генеральный директор DCLogic Евгений Шелестюк.</p> <p>«Сегодня observability выходит далеко за рамки мониторинга, превращая данные наблюдаемости в стратегический актив для принятия решений о развитии ИТ-инфраструктуры. Для многих ИТ-директоров одной из ключевых задач становится обоснованная оптимизация затрат на ИТ-инфраструктуру на основе объективных данных. Именно этому запросу отвечает совместный проект GMONIT и DCLogic, открывая новый сценарий использования данных наблюдаемости и превращая их из инструмента контроля в основу для управления инфраструктурой — от мониторинга и анализа до планирования ее развития. Именно в этом мы видим следующий этап развития observability: когда данные не просто показывают, что происходит в ИТ, а помогают определять, какой должна быть ИТ-инфраструктура завтра», — подчеркнул генеральный директор GMONIT Игорь Пустоветов.</p> <p>Совместный проект станет еще одним шагом в развитии отечественной экосистемы инфраструктурного программного обеспечения. Решение ориентировано прежде всего на крупные компании с распределенной или быстро растущей ИТ-инфраструктурой, которым необходимо одновременно обеспечивать стабильность цифровых сервисов, контролировать потребление ресурсов и планировать развитие вычислительных мощностей.</p> Системный интегратор DCLogic и разработчик российской observability платформы GMONIT приступили к совместной интеграции … message https://www.itweek.ru/themes/detail.php?ID=235316 Mon, 10 Aug 2026 18:19:31 +0300 <p>Компания BSS представила мажорное обновление 2.15 «Речевой аналитики». Ключевой вектор релиза — эволюция встроенного искусственного интеллекта из инструмента реактивной обработки запросов в полноценного проактивного ИИ-агента, способного самостоятельно управлять качеством клиентского сервиса.</p> <p>Главной инновацией версии 2.15 стала трансформация инсайт-режима в автономного Инсайт-агента. Теперь ИИ не требует постоянного участия пользователя: по заданному расписанию он самостоятельно анализирует коллекции записей, выявляет паттерны и аномалии, формирует инсайты и автоматически рассылает отчеты заинтересованным лицам, включая смежные подразделения, которые не являются прямыми пользователями системы. </p> <p>Внедрение технологии RAG (Retrieval-Augmented Generation) в автоматические оценочные карты позволяет бизнесу получать семантический контроль качества на основе корпоративных баз знаний или загруженных регламентов без необходимости сложной интеграции.</p> <p>Для подразделений контроля качества (КК) релиз принес существенное повышение эффективности. В модуле Контактного центра усовершенствован механизм семплинга: теперь в одной задаче можно зафиксировать множественные условия отбора за разные периоды, что оптимизирует время при работе в системе. Внедрен интерактивный виджет «Дерево маркеров» для наглядной визуализации тематик и подтематик с возможностью глубокой фильтрации, а также новый отчет «Распределение оценок» для трекинга нагрузки контролеров. Для экономии времени сотрудников контроля качества добавлены «Справочники» — предустановленные варианты обратной связи и тематизации.</p> <p>Значительные обновления получил Агент-Тренер. ИИ-собеседник теперь поддерживает выбор языка общения, а система оценивания стала многоуровневой (включая критические цели, мгновенно прекращающие симуляцию). Важнейшее нововведение — ИИ начал предоставлять подробное обоснование для каждой цели: почему она зачтена, не зачтена или выполнена частично. Результаты обучения теперь агрегируются в новом «Дашборде ученика».</p> <p>Зрелость платформы также подчеркивает масштабный UX/UI-рефакторинг: внедрен современный компонент с расширенной фильтрацией во всех списках, адаптивный виджет со статистикой диалогов, улучшен Конструктор отчетов и реализована транскрибация аудио-сообщений в текстовых чатах.</p> <p>«В версии 2.15 мы фактически стерли грань между аналитическим инструментом и цифровым сотрудником. Объединив обновленный инсайт-режим и возможность автономной работы, мы вывели на рынок полноценного ИИ-агента. Он не просто ждет запроса от аналитика, а самостоятельно мониторит массивы коммуникаций, находит скрытые взаимосвязи и проактивно доставляет инсайты бизнесу. Наша цель — дать компаниям технологию, которая работает на опережение, беря на себя рутину и позволяя людям фокусироваться на принятии стратегических решений», — прокомментировала Анна Ивлева, владелец продукта «Речевая Аналитика» департамента голосовых цифровых технологий компании BSS.</p> <p>Выход релиза 2.15 подтверждает экспертизу BSS как одного из безусловных лидеров отечественного рынка в области разработки и внедрения речевых технологий и искусственного интеллекта. Многогранный опыт компании в сфере цифровизации клиентского сервиса позволяет BSS предлагать рынку <nobr>CX-платформу</nobr> нового уровня для интеллектуального управления клиентским опытом. Она объединяет данные, инструменты автоматизации и аналитику для персонализированного и предиктивного сервиса, повышения эффективности и доходности бизнеса.</p> Компания BSS представила мажорное обновление 2.15 «Речевой аналитики». Ключевой вектор релиза — эволюция встроенного … message https://www.itweek.ru/themes/detail.php?ID=235315 Mon, 10 Aug 2026 13:01:08 +0300 <p>Российский разработчик АО «СБК» выпустил продуктовый релиз платформы унифицированных коммуникаций CommuniGate Pro 6.5.6. Новая версия существенно расширяет возможности веб-интерфейса, улучшает MAPI-коннектор для корпоративных пользователей Windows и продолжает работу по повышению стабильности календарей.</p> <p>Веб-интерфейс получил ряд новых функций, ориентированных на повседневные задачи пользователей. Теперь пользователи могут создавать календарное событие непосредственно из письма, что ускоряет планирование. При добавлении адресатов в письмо или событие система автоматически подтягивает контакты, в том числе из внешних справочников. Релиз включает полноценную функцию предоставления доступа к календарю, включая публичный доступ по уникальной ссылке. Пользователи могут изменять язык интерфейса, настраивать уведомления о доставке и прочтении писем, а также создавать собственные почтовые правила для автоматической обработки входящих сообщений. Интерфейс позволяет изменять ширину сайдбара, а при наведении на папку система отображает ее полное имя и размер. Релиз добавляет на страницу авторизации QR-код и ссылку для TOTP, что упрощает первичную настройку двухфакторной аутентификации (2FA).</p> <p>Для администраторов и ИТ-специалистов релиз 6.5.6 значительно дорабатывает MAPI-коннектор. Разработчики подготовили MSI-инсталлятор для <nobr>64-разрядных</nobr> версий Windows, что позволяет устанавливать коннектор централизованно через групповые политики сразу для всех пользователей. Также пользователи могут отзывать отправленные сообщения, а платформа группирует письма в беседы, упрощая работу с перепиской.</p> <p>В бэкенд-части команда разработчиков продолжила улучшать работу с календарями и сериями повторяющихся событий, начатую в предыдущем релизе.</p> <p>«Новый релиз CommuniGate Pro 6.5.6 делает платформу еще более удобной и гибкой для конечных пользователей и администраторов. Мы расширили функциональность веб-интерфейса, упростили интеграцию с внешними справочниками и добавили важные инструменты для централизованного управления, такие как MSI-установка MAPI-коннектора. Продолжая работу над стабильностью календарей, мы следуем запросам наших клиентов и укрепляем позиции CommuniGate Pro как надежного решения для корпоративной коммуникации», — прокомментировал Борис Моисеев, директор департамента разработки CommuniGate Pro.</p> <p>Пользователи уже могут скачать обновление CommuniGate Pro 6.5.6 на официальном сайте компании.</p> Российский разработчик АО «СБК» выпустил продуктовый релиз платформы унифицированных коммуникаций CommuniGate … message