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=235070 Thu, 25 Jun 2026 15:15:07 +0300 <p>Эксперты компании «Информзащита» выявили, что в 2026 году украденные учетные данные по-прежнему используются более чем в 80% кибератак хотя бы на одном этапе развития инцидента. За последний год число случаев, когда злоумышленники входили в корпоративные системы под видом легитимных пользователей, выросло на 29%. В наиболее быстрых сценариях от первого доступа до попытки кражи данных проходило около 72 минут против 285 минут годом ранее — то есть окно реагирования сократилось почти вчетверо, и SOC физически не успевает в него вписаться при ручных процессах. Получив пароль, хэш, служебный ключ или данные активного сеанса, атакующий получает доступ не к одной системе, а к тем ресурсам, на которые уже имеет право сотрудник: почте, файловым хранилищам, внутренним приложениям, облачным сервисам и административным консолям.</p> <p>Система видит привычную учетную запись, разрешенное подключение, корректный пароль или действующий ключ доступа, и часто этого достаточно, чтобы злоумышленник получил доступ к тем же приложениям, что и сотрудник, а затем начал изучать доступные ресурсы, права групп и сетевые маршруты. Средства защиты, настроенные на обнаружение вредоносных файлов и попыток эксплуатации уязвимостей, могут не увидеть проблему в момент входа: формально пользователь авторизовался корректно. Особенно опасны учетные записи с расширенными правами, технические пользователи для интеграций, а также сотрудники, которые имеют доступ сразу к нескольким контурам компании.</p> <p>Пароли похищают через фишинговые страницы, вредоносные программы для кражи данных из браузеров, поддельные обновления, сообщения от имени подрядчиков и сервисов доставки. Отдельную нишу занимают личные устройства сотрудников. На них нередко сохраняются корпоративные пароли, данные доступа к почте и облачным сервисам, файлы с ключами или конфигурациями. В открытой статистике по журналам вредоносных программ для кражи данных 30% скомпрометированных устройств относились к корпоративным, а 46% устройств, где были обнаружены корпоративные учетные записи, не находились под управлением работодателя. Это означает, что <nobr>MDM-политики</nobr> и корпоративный антивирус физически отсутствовали на почти половине машин, с которых утекли рабочие пароли — компрометация произошла за пределами видимости любого корпоративного средства защиты. На практике это означает, что часть корпоративных доступов оказывается скомпрометированной за пределами корпоративной сети и без прямого взлома инфраструктуры компании.</p> <p>Разбивка по векторам атак показывает, что кража учетных данных почти всегда пересекается с другими техниками. На социальную инженерию приходится 33% первичных проникновений, причем 22% связаны непосредственно с фишингом. Еще в 13% случаев атакующие использовали учетные данные, скомпрометированные ранее, а в 8% — подбирали пароли к существующим учетным записям. Дополнительные 11% формируют ошибки в настройках прав доступа и злоупотребление легитимными полномочиями сотрудников или подрядчиков. В сумме атаки на идентификацию обеспечивают 65% первичных проникновений. Полученный пароль редко остается единственным инструментом злоумышленника: его проверяют в почтовых сервисах, на шлюзах удаленного доступа, во внутренних приложениях и на серверных ресурсах, а затем используют для закрепления и повышения привилегий.</p> <p>После первого входа наибольшую роль играет внутренняя связность инфраструктуры. В исследовании, посвященном боковому перемещению внутри сети, 87% серверов принимали удаленные подключения по RDP или SSH, а 78,7% были доступны по SMB или WinRM. При этом 43,2% внутреннего трафика аутентификации приходилось на NTLM — устаревший механизм проверки подлинности, который допускает повторное использование хэша пароля вместо самого пароля. У 12,2% организаций выявлены прямые административные маршруты от пользовательских рабочих станций к серверам. В такой среде скомпрометированная учетная запись превращается в точку входа сразу во все направления, к которым она имеет право: от файлового сервера и почтового ящика до систем резервного копирования и консоли управления доменом — без единого дополнительного эксплойта. .</p> <p>Отраслевой срез показывает, что проблема по-разному проявляется в зависимости от устройства ИТ-ландшафта. В добывающей отрасли учетные данные фигурировали среди скомпрометированных данных в 43% подтвержденных утечек, в управляющих и головных компаниях — в 33%, в строительстве — в 31%. Для ритейла показатель составил 26%, для профессиональных услуг — 24%. В финансовом секторе, промышленности и транспорте учетные данные были затронуты в 22% подтвержденных утечек. Этот показатель описывает состав похищенных данных; частоту всех инцидентов он не измеряет. Тем не менее распределение хорошо отражает зоны повышенного внимания: чем больше в компании подрядчиков, распределенных площадок, технических учетных записей, удаленного доступа и старых интеграций, тем выше вероятность, что один пароль сохранится дольше положенного и попадет в чужие руки. Высокие показатели в добыче и управляющих компаниях объясняются не слабостью ИТ-команд, а структурой доступа- все это создает длинный хвост учеток, которые никто не считает приоритетными для ротации. </p> <p>Причина часто кроется в накопившихся исключениях. Учетная запись создавалась для проекта, затем проект завершился, но доступ остался. Технический пользователь получил широкие права ради стабильной работы интеграции. Сотрудник сменил подразделение, а прежние полномочия не были отозваны. Подрядчик подключался к системе на время внедрения и продолжил иметь возможность входа после окончания работ. Одновременно часть паролей сохраняется в браузерах, файлах конфигурации, скриптах автоматизации и системах управления задачами. Внутри одной инфраструктуры могут сосуществовать современные механизмы аутентификации, старые протоколы, общие учетные записи и несколько независимых каталогов пользователей. Злоумышленнику достаточно найти наиболее слабый участок этой цепочки.</p> <p>Сокращать риск необходимо через управление полным жизненным циклом учетной записи. Компании стоит инвентаризировать пользовательские, привилегированные и технические учетные записи, определить владельца каждого доступа, проверить его фактические права и отключить неиспользуемые учетные записи. Для администраторов и систем с высокой критичностью требуется раздельная работа с обычными и привилегированными учетными записями, многофакторная аутентификация с использованием аппаратных ключей или других устойчивых к фишингу методов, ограничение доступа по времени и контроль действий в ходе сеанса. Техническим учетным записям необходимы регулярная смена секретов, запрет постоянных паролей, ограничение источников подключения и минимальные права, достаточные только для конкретной операции.</p> <p>Отдельного контроля требуют входы с новых устройств, попытки авторизации из непривычных регионов, одновременное использование одной учетной записи в разных средах и последовательные обращения к большому числу ресурсов. Не менее полезно регулярно сопоставлять корпоративные адреса электронной почты с данными о внешних утечках, но реагировать нужно не только сменой пароля. При подтвержденной компрометации требуется отозвать активные сеансы, проверить выданные ключи доступа, сбросить пароли технических пользователей и проанализировать, какие системы были доступны под этой учетной записью. Радиус поражения одного украденного пароля измеряется не его сложностью, а объемом прав, которые к нему прикреплены, и временем, за которое организация способна отозвать активные сессии после сигнала тревоги — в большинстве обследованных сред этот показатель составил от 4 до 18 часов. Украденные учетные данные остаются удобным инструментом для атакующих по одной причине: организация сама заранее определяет, насколько далеко можно пройти с чужим паролем. Чем уже права доступа и чем быстрее компания способна отозвать их после подозрительной активности, тем меньше шансов, что единичная компрометация перейдет в масштабный инцидент.</p> Эксперты компании «Информзащита» выявили, что в 2026 году украденные учетные данные по-прежнему используются более чем … message https://www.itweek.ru/themes/detail.php?ID=235069 Thu, 25 Jun 2026 15:08:36 +0300 <p><nobr>2024-2025</nobr> годы проходили под знаменем экстренной миграции и заполнения ниш ушедших вендоров, в начале 2026 года рынок начал фильтровать решения через призму совокупной стоимости владения, доступности железа и реальной облачной экспертизы. Владимир Лебедев, директор по развитию бизнеса сервис-провайдера M1Cloud, подвел итоги I полугодия и дал прогноз на 2026 год.</p> <p>В условиях отсутствия прямых поставок от глобальных вендоров, рынок адаптировался к параллельному импорту и использованию альтернативных платформ. Для российского облачного рынка теперь норма, что нет унифицированного стека.</p> <p>Однако в I полугодии 2026 года проблема трансформировалась: дефицит сместился с серверов на компоненты и сетевое оборудование. Заказчики готовы переплачивать за облако, чтобы не брать на себя риски простоя поставок и ремонта.</p> <p>Мультиоблако как гарантия независимости столкнулось с реальностью кадрового голода и сложностями администрирования. Стоимость поддержки полноценного мультиоблака выросла на 40% из-за дефицита мультикомпетентных DevOps-инженеров. Бизнес стремится снизить операционные расходы, предпочитая делегировать обслуживание сложной облачной инфраструктурой, поэтому в I полугодии 2026 года на рынке одна из востребованных моделей «Primary + Backup» (продуктовые / критические системы и резервные копии) — консолидация ИТ-систем у одного-двух стратегических провайдеров. Основной провайдер берет на себя 80% нагрузки и ответственность за интеграцию, второй используется исключительно как аварийный контур или для специфических сервисов (например, высокопроизводительные GPU-кластеры для ИИ).</p> <p>В 2026 году помимо нехватки на рынке высокопроизводительных GPU, рост плотности вычислений для ИИ уперся в лимиты электропитания стойко-мест. ИИ перестал быть отдельной вертикалью в бизнесе и стал параметром инфраструктуры — в приоритет выходит безопасность ИИ-моделей. Заказчики запрашивают не просто «GPU-сервер», а «платформу для инференса» с встроенными инструментами ИИ-безопасности.</p> <p>Тренд на гибридность в 2026 году трансформировался из стратегического выбора в тактику управления рисками дефицита. Заказчики строят гибрид, потому что публичное облако не может гарантировать SLA на определенные типы нагрузок из-за фрагментации парка, а приватное — слишком дорого масштабировать под пики. Таким образом, критичные ядра систем остаются на собственном или выделенном железе (bare metal), а эластичные фронтенды уходят в публичное облако. Это усложняет архитектуру, но страхует от простоев. В такой ситуации провайдер становится интегратором разнородных сред.</p> <p>По предварительным оценкам аналитиков M1Cloud, объем рынка облачных сервисов в РФ по итогам I полугодия 2026 года составил около 450 млрд рублей. Годовая динамика роста замедлилась до <nobr>25-30%</nobr> (против <nobr>35-40%</nobr> в аналогичном периоде 2025 года). При этом доля IaaS в структуре рынка занимает около 60%. Номинальное увеличение выручки провайдеров во многом обеспечено не кратным ростом потребления ресурсов, а индексацией цен из-за удорожания логистики оборудования и энергоносителей.</p> <p>Рынок продолжает консолидироваться, но не столько через поглощение крупных игроков, сколько через покупку компетенций и готовых мощностей, где объектом покупки выступают не клиентские базы, а развернутые кластеры с подключенной мощностью и штатом облачных инженеров, способных работать с гетерогенным парком.</p> <p>Российский облачный рынок остается одним из самых маржинальных в ИТ-секторе. Рынок сохранит темпы роста в диапазоне <nobr>25-30%,</nobr> но драйвером станет не количество заказчиков, а глубина проникновения сервисов. Наибольший рост покажут игроки со зрелым стеком, диверсифицированной базой поставок оборудования, собственной инженерной экспертизой и с опытной командой эксплуатации. Роль провайдера окончательно трансформировалась в технологического партнера и инфраструктурного интегратора, который способен обеспечить непрерывность бизнеса заказчика в условиях турбулентной внешней среды.</p> 2024-2025 годы проходили под знаменем экстренной миграции и заполнения ниш ушедших вендоров, в начале 2026 года рынок … message https://www.itweek.ru/themes/detail.php?ID=235067 Thu, 25 Jun 2026 11:22:35 +0300 <p>Yandex B2B Tech открыла публичный доступ к Vibecraft — сервису для создания сайтов и веб-приложений по текстовому описанию. С его помощью предприниматели, менеджеры могут создавать прототипы цифровых продуктов, трекеров, CRM-систем, мини-игр и не только. Попробовать сервис можно на сайте vibe.sourcecraft.dev — каждый пользователь получит 4000 нейрокредитов для тестирования.</p> <p>Для создания проекта в Vibecraft нужно описать задачу в чате с ИИ-помощником. Он уточнит, для какой аудитории создаётся сервис, какие функции нужны и как им будут пользоваться. По этим критериям Vibecraft собирает первую версию сайта или веб-приложения. Все проекты пользователи могут публиковать в интернете на собственных доменах. Vibecraft может собрать сайт или прототип веб-приложения с личным кабинетом, каталогом, формой загрузки файлов, встроенной базой данных и фирменным дизайном пользователя. </p> <p>Во время закрытого тестирования пользователи создали более 1000 проектов. Более половины обращений к Vibecraft были связаны с разработкой прикладных сервисов, а не только сайтов. Пользователи создавали панели управления, калькуляторы, мини-игры, инструменты аналитики, CRM-системы, интернет-магазины и другие проекты. </p> <p>«Vibecraft помогает превратить идею сервиса в работающий прототип, проверить интерес пользователей и затем принять решение о полноценной разработке. Так предприниматели и команды могут направлять ресурсы на проекты, которые уже подтвердили свою востребованность», — рассказал Иван Пузыревский, технический директор платформы Yandex Cloud.</p> <p>Сегмент no-code и low-code решений в России растёт на 40% в год и может достичь 30 млрд рублей к 2028 году. При этом около 36% представителей малого бизнеса в России по-прежнему работают без собственного сайта из-за ограничений бюджета, времени и отсутствия технических навыков. Менее 15% малых предпринимателей используют сайты как канал продвижения, при этом почти половина хотела бы их создать. Vibecraft помогает преодолеть эти барьеры: он уточняет детали, предлагает структуру и собирает рабочий сайт. По оценкам участников тестирования, первый результат можно получить за <nobr>5–10 минут.</nobr> Vibecraft также помогает определить состав проекта, предлагая необходимые формы, пользовательские сценарии и бизнес-логику.</p> Yandex B2B Tech открыла публичный доступ к Vibecraft — сервису для создания сайтов и веб-приложений … message https://www.itweek.ru/themes/detail.php?ID=235066 Thu, 25 Jun 2026 09:34:35 +0300 <p><em>Сетевые руководители знают, что их сотрудники ежедневно сталкиваются с огромным потоком данных и телеметрии, но готовы ли их команды доверить агентам искусственного интеллекта больше задач в области сетевых операций? Мэри Шеклет, президент консалтинговой компании Transworld Data, приводит на портале </em><em>InformationWeek</em> <em>четыре шага, которые помогут организациям подготовиться к этому.</em></p> <p>Навыки сетевых специалистов часто оказываются неактуальными, когда речь идет о внедрении ИИ и автоматизации в сетях. Это происходит в то время, когда компании ожидают мгновенного решения сетевых проблем, а также возможности масштабирования и развертывания как можно большего количества новых приложений внутри компании и в облаке — часто за считанные секунды. Разработчики уже имеют высокоавтоматизированные методы развертывания, но сетевые специалисты отстают.</p> <p>Пришло время взглянуть на следующую волну автоматизации сетевых операций. Другими словами, можно ли использовать развертывание сетевых ИИ-агентов и автоматизации для ускорения циклов развертывания сети и решения возникающих проблем?</p> <h3>Для чего предназначены агенты ИИ</h3> <p>Сетевые агенты ИИ находятся на стадии исследования. Их конечная цель — расширить автоматизацию сети за пределы мониторинга и AIOps, в область, где основы управления сетью максимально автоматизированы. Это включает мониторинг, оповещение, реагирование и разрешение инцидентов, а также соблюдение корпоративной безопасности и соответствия нормативным требованиям. После того, как будет достигнута уверенность в возможностях этих агентов, следующим шагом станет автоматическое масштабирование и управление сетевыми ресурсами для оптимизации рабочих нагрузок приложений.</p> <p>Для выполнения этих задач сетевым агентам ИИ требуется получить от команд, занимающихся сетью, безопасностью и комплаенсом, набор бизнес-правил. Далее агенты ИИ используют машинное обучение для понимания сети, чтобы самостоятельно улучшать свою производительность.</p> <h3>Почему сетевые агенты ИИ остаются в значительной степени желательным решением</h3> <p>Сегодня сочетание факторов привело к тому, что внедрение сетевых агентов ИИ остается скорее желательным, чем реальным.</p> <p>Хотя сетевые сотрудники могут создавать бизнес-правила для управления сетью и масштабируемости, необходимые сетевым агентам ИИ, они также должны обеспечить единообразие этих правил и рекомендаций во всех сетях, будь то в центре обработки данных, на периферии или в облаке. Многие организации сталкиваются с этой проблемой из-за множества разнородных сетей.</p> <p>Кроме того, существуют проблемы с интеграцией систем и сетей, а также с координацией безопасности, комплаенса и управления сетью, которые могут охватывать несколько различных функциональных отделов внутри компании. Сотрудничество между этими командами на практике может быть сложной задачей — но без него у агентов ИИ остаются пробелы в инструкциях.</p> <p>Как и в случае с обучением агентов, существует также кривая обучения персонала в отношении ИИ и автоматизации. Хотя большинство корпоративных сетевых команд перешли от стандартного мониторинга сети к наблюдаемости, они все еще лишь умеренно вовлечены в AIOps, который является критически важным шагом на пути к сетевым агентам ИИ. Хорошая новость заключается в том, что несколько крупных поставщиков сетевого оборудования предлагают четкие пути миграции технологий, которым могут следовать организации — пути, которые могут привести организации от стандартного мониторинга сети до сетевых агентов ИИ.</p> <h3>Как выглядят сетевые агенты ИИ на практике</h3> <p>Изучая сетевые агенты ИИ, сетевые команды хотят понять, как эти агенты работают и как могут принести пользу сетевым операциям.</p> <p>В ходе одного из испытаний, проведенного в ноябре 2025 г. компанией Nanites, которая предоставляет компонуемые (т. е. модульные) сетевые агенты ИИ, были получены интересные результаты. Исследователи смоделировали сбой интерфейса в сети Cisco IS-IS (промежуточная система — промежуточная система). Система Nanites AI проанализировала оповещение и устранила проблему за 3 минуты, что обычно занимает у квалифицированного инженера более 30 минут. Внутри системы были выполнены следующие действия:</p> <ul> <li> Автономная обработка оповещений от Grafana (ПО для сбора метрик, логирования и трассировки).</li> <li> Выявление первопричин путем логического анализа (вероятно, путем наблюдения за сетевыми паттернами, конфигурациями, топологией и трафиком, а затем формулирования выводов), а не просто на основе правил или сценариев.</li> <li> Динамическое определение точных шагов по устранению неполадок в режиме реального времени.</li> <li> Автономное выполнение этих шагов при непосредственном взаимодействии с системами.</li> <li> Применение исправлений за секунды (только с одобрения человека).</li> </ul> <p>Авторы сделали примечание, в котором говорится, что данное испытание проводилось в строго контролируемой сетевой среде.</p> <p>Время устранения неполадок в ходе испытания было впечатляющим; на первый взгляд, агент ИИ явно работал намного быстрее, чем инженер-человек. Но не менее примечательным было и то, что испытание проводилось в строго контролируемой сетевой среде, а также необходимость участия сотрудника сетевого отдела для принятия окончательного решения.</p> <p>Даже в идеальных системах — что для большинства не является реальностью — ИИ не доверяют действовать полностью автономно. Это поднимает вопросы о том, насколько необходимо участие человека, если организация передает управление своей сетью агентам ИИ.</p> <h3>Почему сетевые команды изучают возможности использования ИИ-агентов</h3> <p>Даже при наличии опасений сетевым менеджерам ясно, что инструменты, используемые их сотрудниками, не справятся с лавинами данных, которые они теперь видят ежедневно.</p> <p>В феврале 2026 г. Нерадж Кумар, директор по разработке решений Solarwinds, <a href="https://www.solarwinds.com/blog/from-data-overload-to-decisions-rethinking-itops-in-apj">сослался</a> на исследование IDC, которое показало, что 59% организаций инвестируют в AIOps как средство автоматизации мониторинга сети, но 75% организаций по-прежнему заняты «поддержанием работоспособности». Разрозненность инструментов оказалась одной из причин, по которой организациям трудно двигаться вперед, — но также и перегрузка инфоормацией от поступающих сетевых данных и телеметрии.</p> <p>«Ни один CIO не скажет, придя в офис в понедельник: „Сегодня моя среда проще, чем в прошлом году“. Внедрение гибридных и мультиоблачных решений дало командам больше гибкости, но также и больше точек интеграции, потоков телеметрии и способов распространения инцидентов по всей системе», — отметил Кумар.</p> <p>Очевидно, что для бесперебойной работы сетей и их масштабирования под конкретные задачи требуется больше ИИ и автоматизации. Это стимулирует внедрение сетевых агентов ИИ для выполнения большего объема работы — но готовы ли сотрудники сети эффективно их использовать?</p> <h3>Четыре способа подготовиться к внедрению сетевых агентов ИИ</h3> <p>Для организаций, которые в настоящее время не чувствуют себя готовыми к внедрению агентного ИИ, есть хорошие новости: сейчас самое время заложить основу для сетевых агентов ИИ, поскольку технология все еще находится на очень ранних этапах внедрения. Если эти шаги будут предприняты сейчас, управление сетью не будет отставать.</p> <p>Вот четыре рекомендации:</p> <ol> <li><strong> Начните с того, что у вас есть. </strong>Сетевые сотрудники уже знают, что при масштабировании сети они получают огромное количество данных и оповещений. Они также знают, что не могут справиться со всеми оповещениями и что имеющиеся инструменты не всегда справляются с этой задачей. В результате почти все приходят к тому, что необходима бóльшая автоматизация сетевых операций, будь то с помощью AIOps или сетевых агентов ИИ.<br/> <br/> В этот момент сетевые сотрудники должны начать свою оценку. Если бы вы могли автоматизировать любые операции в сети, какие операции вы бы больше всего хотели автоматизировать с помощью ИИ? Какого повышения производительности вы бы ожидали? Четко определяя приоритеты, сотрудники сужают фокус и организуют стратегию вокруг значимых бизнес-результатов. </li> <li><strong> Определите стратегию и составьте дорожную карту. </strong>После того, как сетевые сотрудники определили цели автоматизации и повышения производительности сети, следующим шагом является создание графика этих улучшений и определение технологий, которые могут обеспечить желаемые результаты.<br/> <br/> Было бы здорово представить себе полностью автономную сеть, использующую сетевых агентов ИИ, которые могли бы самостоятельно управлять сетью и достигать всех целей по производительности, но почти никто не согласился бы на это. Испытание агентов ИИ компанией Nanites — прекрасный пример: производительность была достигнута, но только в строго контролируемой сетевой среде, в присутствии сетевых специалистов, принимающего окончательное решение о том, каких сетевых агентов ИИ рекомендовать.<br/> <br/> Командам следует принимать это во внимание при разработке своей стратегии. Сетевые сотрудники должны учитывать, как повседневные проблемы в системе могут повлиять на эффективность ИИ, и разрабатывать дорожные карты, учитывающие необходимость участия человека. </li> <li><strong> Сотрудничайте с дальновидным сетевым вендором. </strong>В целом, предприятия и поставщики видят эволюцию управления сетью от стандартного мониторинга к наблюдаемости, затем к AIOps и, наконец, к сетевым агентам ИИ. Однако не все поставщики одинаково хороши в качестве деловых партнеров и имеют эффективную технологическую дорожную карту для своих продуктов. При выборе сетевых вендоров для сотрудничества следует учитывать долгосрочную перспективу; цель состоит в том, чтобы найти поставщиков, которые постоянно инвестируют в свою продукцию, поддерживают ее и предлагают отличную поддержку.</li> <li><strong> Протестируйте сетевых агентов ИИ в контролируемых сетевых средах. </strong>Nanites протестировала сетевых агентов ИИ в строго контролируемой сетевой среде. Это позволило адаптировать сценарий использования, чтобы наблюдать за тем, как набор сетевых агентов ИИ работает в конкретном контексте. Другими словами, тестирование проводилось не в гибридной конфигурации множества облачных и внутренних сетей, которые есть у большинства предприятий. Предприятиям следует извлечь из этого урок. Начните постепенно, тестируя сетевой ИИ и автоматизацию в строго контролируемой сетевой среде. Как только проблемы там будут устранены, агентный ИИ можно будет протестировать в новых областях и далее масштабировать.</li> </ol> Сетевые руководители знают, что их сотрудники ежедневно сталкиваются с огромным потоком данных и телеметрии … article https://www.itweek.ru/themes/detail.php?ID=235064 Thu, 25 Jun 2026 09:16:47 +0300 <p><em>Когда бизнесу предлагают open source-систему мониторинга для ИТ — от популярных решений вроде Zabbix до других инструментов этого класса — идея выглядит рационально: лицензии нет, продукт доступен, можно быстро начать и не тратить бюджет на коммерческое решение. Но в реальности компания получает не «бесплатный мониторинг», а задачу для своей команды. Систему нужно внедрить, настроить под инфраструктуру, связать с ИТ- и ИБ-процессами, поддерживать, обновлять, проверять и развивать. Поэтому главный вопрос не в том, сколько стоит лицензия, а в том, во сколько компании обходится эксплуатация такого стека. </em></p> <h3>Нулевая лицензия не означает нулевую стоимость</h3> <p>Главный миф про open source-мониторинг звучит просто: если за лицензию не надо платить, значит решение бесплатное. На практике это не так. Бесплатно компания получает только саму технологию: готовое ядро, которое умеет собирать данные, отслеживать состояние систем и показывать, что происходит в инфраструктуре. Это действительно ценно. Если писать такой инструмент с нуля, стоимость была бы несравнимо выше.</p> <p>Но между «скачали технологию» и «получили надежный мониторинг для бизнеса» лежит большая работа. Систему нужно настроить под конкретную инфраструктуру, подключить нужные источники данных, связать с другими ИТ- и ИБ-инструментами, настроить алерты, проверить обновления, описать правила эксплуатации. Все это не делает само ядро open source. Это делает команда компании.</p> <p>И здесь бесплатность быстро превращается в экономику. Допустим, компании нужно развернуть мониторинг для инфраструктуры хотя бы на 50+ рабочих мест и нескольких ключевых сервисов. Начинающий администратор с такой задачей, скорее всего, не справится. Нужен ИТ-специалист уровня senior, который будет разбираться в продукте, разворачивать систему, подключать источники данных, настраивать базовый сбор метрик, проверять совместимость и устранять первичные ошибки внедрения.</p> <p>Даже если считать консервативно, такой специалист может стоить компании <nobr>250-350 тыс.</nobr> рублей в месяц с учетом налогов и сопутствующих расходов. Если внедрение, настройка и стабилизация open source-мониторинга занимают около шести месяцев, только трудозатраты одного специалиста превращаются в <nobr>1,5-2,1 млн.</nobr> рублей. Параллельно появляются тестирование, документация, исправление ошибок после запуска, первичная поддержка, согласование алертов с владельцами систем, проверка интеграций и участие смежных специалистов. Даже в умеренном сценарии это может добавить еще несколько сотен тысяч рублей. В итоге проект, который на старте выглядел как «бесплатный», уже на первом этапе легко выходит на <nobr>2-3 млн.</nobr> рублей внутренних затрат. И это все еще не полная стоимость владения. Это только цена технического запуска.</p> <p>При этом open source не стоит списывать как неудачный вариант. У него есть сильные стороны: низкий порог входа, зачастую бесплатные лицензии даже для коммерческого использования, гибкость, большое сообщество, возможность быстро проверить гипотезу и собрать решение под нестандартную инфраструктуру. Для небольшой среды, пилотного проекта или команды с сильной инженерной экспертизой open source может быть рациональным выбором. Проблема начинается не там, где компания выбирает open source, а там, где она считает его бесплатным и не закладывает ресурсы на внедрение, поддержку и развитие.</p> <h3>Скрытая стоимость превращения метрик в пользу</h3> <p>Собрать данные — еще не значит получить управляемую картину инфраструктуры. После запуска мониторинг может показывать графики, статусы и сотни событий, но бизнесу важно не количество сигналов, а понимание, какие из них действительно влияют на работу сервисов.</p> <p>Именно это часто не учитывают на старте. Без донастройки системы мониторинга генерируют слишком много алертов. Формально контроль есть: устройства подключены, метрики собираются, уведомления приходят. Но, если алертов слишком много, ИТ-команда быстро перестает отличать важное от второстепенного. Вместо помощи мониторинг создает дополнительный шум. Значит, систему нужно настраивать не только технически, но и по смыслу. Например, для мониторинга коммутатор ядра и гостевой коммутатор могут выглядеть как похожие устройства. Оба отдают параметры, оба могут прислать алерт. Но для бизнеса это разные ситуации. Отказ коммутатора ядра может остановить ключевые сервисы. Сбой гостевого коммутатора обычно имеет другой уровень критичности.</p> <p>Поэтому после подключения источников начинается отдельная работа: убрать ложные срабатывания, настроить пороги, учесть критичность оборудования и сервисов, определить ответственных за реакцию. Иначе компания получает не инструмент управления доступностью, а генератор технических уведомлений.</p> <p>Часто качество мониторинга становится понятно только во время первого инцидента. Пока все работает, графики выглядят убедительно. Но сбой показывает, помогает ли система быстро найти причину или просто добавляет еще один поток сообщений. После таких ситуаций правила приходится пересматривать: менять приоритеты, уточнять сценарии уведомлений, донастраивать алерты. В open source-стеке эта работа остается на стороне компании. Можно читать документацию, искать статьи, писать на форумы, обращаться к сообществу. Но это не техническая поддержка с понятными сроками реакции и ответственностью за конкретный кейс. Сообщество может помочь, а может не ответить. Для бизнеса это риск: если проблема возникла в критичный момент, ждать ответа на форуме нельзя.</p> <p>У этой донастройки тоже есть понятная цена. После запуска мониторинга инженер может тратить не <nobr>30-40</nobr> часов в месяц, а <nobr>80-120 часов:</nobr> разбирать ложные срабатывания, менять пороги, проверять уведомления, согласовывать критичность сервисов, дорабатывать дашборды, уточнять сценарии реакции и исправлять ошибки, которые проявились только в реальной эксплуатации. При внутренней ставке <nobr>2,5-4 тыс.</nobr> рублей в час это уже <nobr>200-480 тыс.</nobr> рублей ежемесячно. За полгода такой период стабилизации добавляет к проекту еще <nobr>1,2-2,9 млн.</nobr> рублей. И это без учета времени смежных специалистов: владельцев сервисов, сетевых инженеров, специалистов по ИБ и эксплуатации, которые помогают определить приоритеты, проверить зависимости и подтвердить, что мониторинг показывает не просто набор событий, а реальное влияние на работу бизнеса.</p> <p>Это только цена, чтобы довести open source-мониторинг до рабочего состояния и настроить его под реальные приоритеты бизнеса. Но на этом расходы не заканчиваются.</p> <h3>Стоимость команды, которая держит мониторинг в рабочем состоянии</h3> <p>Компания развивается, а вместе с ней меняется инфраструктура: появляются новые сервисы, обновляется оборудование, добавляются интеграции, растет объем метрик, повышаются требования к надежности и безопасности. Поэтому мониторинг нельзя один раз настроить и оставить без внимания. Его нужно поддерживать: следить за системой, разбирать алерты, обновлять правила, проверять данные и актуализировать настройки. Все это требует времени специалистов, а значит становится отдельной статьей затрат. В сложных средах это уже не разовая задача, а постоянная нагрузка на человека или команду: обновления нужно тестировать, интеграции проверять, а реакцию на события закреплять за ответственными. Иначе мониторинг быстро устаревает, теряет ценность и сам становится источником проблем.</p> <h3>Скрытые риски open source-мониторинга</h3> <p>Риски open source-мониторинга связаны не с тем, что сама технология плохая. Наоборот, под многие бизнес-задачи есть зрелые open source-проекты. Риск появляется тогда, когда компания берет такой стек как готовую бесплатную систему, но не выстраивает вокруг него эксплуатацию, ответственность, безопасность и процесс обновлений.</p> <p>Первый риск — безопасность и зависимость от правил внешней экосистемы. Open source не означает, что продукт автоматически безопасен. Его тоже пишут люди, а значит, в коде, обновлениях и инфраструктуре проекта могут быть ошибки, уязвимости и атаки на цепочку поставки. Например, в 2026 году <a href="https://www.securitylab.ru/news/568899.php">сообщалось </a>о компрометации инфраструктуры Notepad++: злоумышленники использовали механизм обновлений, чтобы доставлять вредоносные файлы отдельным пользователям. В другом свежем <a href="https://xakep.ru/2026/06/08/hola-miner/">кейсе</a> Windows-версия браузера Hola распространяла скрытый майнер Monero после атаки на цепочку поставок. Это не значит, что open source опасен сам по себе. Но это показывает: открытый код не отменяет проверки обновлений, контроля источников, тестирования и ответственности за то, что компания ставит в свою инфраструктуру.</p> <p>Второй риск — изменение модели развития проекта. Open source-проект может постепенно перестать быть «бесплатной локальной историей» в том виде, в котором его выбрала компания. Сегодня бизнес разворачивает решение у себя, считает, что контролирует стек и не зависит от поставщика. А завтра вокруг проекта появляется коммерческий контур: облачная версия, подписка, платная поддержка, новые условия сопровождения. Формально продукт может оставаться open source, но самые удобные сценарии, поддержка и развитие начинают смещаться туда, где уже появляются деньги и зависимость от внешней площадки. Похожую логику рынок уже видит на примере Zabbix: ожидается версия 8.0 LTS, при этом рядом с классической бесплатной установкой активнее продвигается Zabbix Cloud. Это не значит, что локальная версия исчезнет или станет платной. Но для бизнеса это сигнал: если критичная система мониторинга строится на внешнем open source-проекте, нужно заранее понимать, куда он развивается и не станет ли завтрашняя модель неудобной, дорогой или рискованной.</p> <p>Третий риск — технический долг. Если после инцидента стало понятно, что нужно изменить порог алерта, но задачу отложили, она не исчезает. Если для сбора данных с отдельного узла сделали временный скрипт, но потом не заменили его нормальным решением, такой «костыль» остается в системе. Если источник данных подключили быстро, но не проверили влияние на безопасность или производительность, проблема тоже уходит в долг. Со временем таких мелочей становится много, и мониторинг превращается в хрупкую конструкцию: его сложнее обновлять, труднее сопровождать и опаснее менять.</p> <p>Четвертый риск — простой бизнеса. Плохо настроенный open source-мониторинг может пропустить ранние признаки проблемы: алертов слишком много, они не приоритизированы или не доходят до ответственных. В итоге компания узнает о сбое уже тогда, когда не работает сервис, CRM, почта или сайт. Показательный <a href="https://www.cnews.ru/news/top/2023-08-30_zavody_toyota_vozobnovili_rabotu">пример</a> — остановка всех 14 заводов Toyota в Японии в 2023 году. Причиной стал недостаток места на диске базы данных: во время регламентных работ произошла ошибка, серверы обработки заказов стали недоступны, резервное переключение не сработало, и это привело к остановке заводов. Это хороший пример того, как инфраструктурная проблема, которую мониторинг должен помогать выявлять заранее, может привести к остановке бизнеса.</p> <p>Пятый риск — масштабирование. Чем больше инфраструктура, тем дороже становится ее наблюдаемость. Растет число устройств, сервисов, метрик, алертов и интеграций. Нужно больше вычислительных ресурсов, больше хранилища, больше настроек и проверок. Если мониторинг интегрирован с другими системами, приходится следить за изменениями API, тестировать обновления и проверять, что после них не сломались сбор данных, уведомления и дашборды. В какой-то момент даже в непрофильной компании вокруг мониторинга появляется процесс, похожий на DevOps: пилотная зона, предпрод, тестирование обновлений, контроль совместимости.</p> <h3>Чем отличается экономика коммерческого решения</h3> <p>Коммерческие системы мониторинга устроены иначе. В большинстве случаев компания платит не только за лицензию, а за готовый продукт и ответственность вендора. Это включает развитие кода, выпуск обновлений, документацию, техническую поддержку, обучение, инструкции по внедрению и, при необходимости, сопровождение через интегратора.</p> <p>У коммерческого решения тоже есть ограничения. Как правило, оно требует бюджета на лицензию, внедрение и сопровождение. Компания может зависеть от roadmap вендора, условий договора, стоимости продления, доступности поддержки и политики обновлений. Кроме того, готовый продукт не всегда идеально ложится на конкретную инфраструктуру: часть сценариев все равно приходится адаптировать, а нестандартные доработки могут требовать отдельного проекта и дополнительных затрат.</p> <p>Для российского бизнеса важны и формальные требования. Как правило, коммерческое решение можно проверить по понятным признакам: входит ли продукт в реестр российского ПО, есть ли необходимые сертификаты, какие условия поддержки прописаны в договоре, какие SLA берет на себя поставщик. В open source-стеке значительную часть этих вопросов компания закрывает сама. В коммерческой модели часть ответственности переходит к вендору.</p> <p>Еще одно отличие — масштаб опыта. Вендор поставляет продукт десяткам или сотням компаний, собирает обратную связь, видит типовые проблемы внедрения и может включать доработки в roadmap. За счет этого появляются отраслевые практики, инструкции, готовые шаблоны, понятные сценарии интеграции и обновлений. Такой конвейер создается один раз и затем используется многими компаниями, поэтому в большинстве случаев он обходится дешевле, чем попытка каждой организации самостоятельно выстроить такую экспертизу внутри.</p> <p>Это не означает, что коммерческое решение всегда лучше open source. Но его экономика обычно устроена понятнее: компания платит за продукт, поддержку, обновления, ответственность поставщика и накопленную практику внедрений. Особенно это важно в российских условиях, где есть импортозамещение, проприетарное оборудование, требования регуляторов и специфические интеграции. В таких случаях общие практики open source-сообщества не всегда можно напрямую перенести на конкретную инфраструктуру и бизнес-задачу.</p> <h3>Заключение</h3> <p>Поэтому выбор между open source и коммерческим мониторингом не должен сводиться к вопросу, где дешевле лицензия. В open source компания получает гибкость и контроль, но берет на себя больше инженерной и эксплуатационной нагрузки. В коммерческом решении часть этой нагрузки переходит к вендору или интегратору, но появляется стоимость лицензии, договора поддержки и зависимость от поставщика. Рациональный выбор начинается не с цены входа, а с расчета полной стоимости владения: людей, времени, поддержки, рисков, масштабирования и требований бизнеса.</p> <p>#IMAGE_235065#</p> Когда бизнесу предлагают open source-систему мониторинга для ИТ — от популярных решений вроде Zabbix до других … article Владислав Ганжа, директор лаборатории кибербезопасности UDV Group https://www.itweek.ru/themes/detail.php?ID=235062 Wed, 24 Jun 2026 13:31:43 +0300 <p>Сейчас на стадии строительства находится 42 проекта ЦОДов совокупным объемом инвестиций 282,1 млрд рублей. В числе крупнейших — дата-центры крупных технологических и корпоративных заказчиков, включая проекты «Яндекса», Сбера, DataPro, АФК Системы, ГК «Монарх», Гознак, Вконтакте и других инвесторов.</p> <p>При этом рынок развивается неравномерно. За последние три года — с мая 2023 года по май 2026 года — количество проектов на активных стадиях снизилось на 41,6%, а объем инвестиций в них — на 26,3%. В приостановке находится 38 проектов суммарным объемом 168,6 млрд рублей.</p> <p>По оценке аналитиков, под давлением чаще оказываются коммерческие проекты, которые планировались за счет частных инвестиций и заемного финансирования. На них сильнее влияют высокая стоимость капитала, рост затрат на строительство и инженерную инфраструктуру, а также сложности с поставками оборудования и подключением к энергетическим мощностям.</p> <p>«Рынок дата-центров остается одним из ключевых инфраструктурных сегментов цифровой экономики, но сейчас он проходит этап отбора. Спрос на вычислительные мощности растет, особенно на фоне развития облачных сервисов и искусственного интеллекта. Однако для коммерческих проектов решающими становятся стоимость финансирования, доступ к энергии и возможность масштабировать объект без чрезмерной нагрузки на экономику проекта. В настоящее время количество проектов могло бы быть значительно выше, а отрасль получила бы больший объем финансирования и более существенный импульс к развитию при условии доступности заемного капитала», — отметил генеральный директор Инвестиционно-аналитической группы ПКР Даниил Новицкий.</p> <p>Региональная структура инвестиций также показывает концентрацию рынка вокруг крупных инфраструктурных центров. Наибольший объем инвестиций в активные проекты приходится на Иркутскую область — 4 проекта на 170 млрд рублей. Далее следуют Москва — 16 проектов на 165,5 млрд рублей и Московская область — 11 проектов на 132,7 млрд рублей. Иркутскую область в число лидеров выводят проекты EN+ Group и «РУСАЛ Тайшет», а в Московской области значимые проекты реализуют, в частности, «Икселерейт», «Яндекс», Сбер, Авито. Саратовскую область в число лидеров выводит крупный проект Сбера в Балаково.</p> <p>Концентрация рынка заметна не только по регионам, но и по составу инвесторов. Крупнейшим инвестором в активные проекты ЦОДов является EN+ Group, в портфеле которого три проекта общей стоимостью 140 млрд рублей. Они связаны с развитием ЦОДов Cloud X в Иркутской области, в том числе рядом с Усть-Илимской ГЭС. Ещё один значимый игрок — Сбер: холдинг реализует масштабный проект центра обработки данных в Балаково Саратовской области.</p> <p>В целом топ-10 инвесторов отрасли реализуют 31 проект на активных стадиях суммарным объемом 590,1 млрд рублей. Это подтверждает общий тренд: в условиях дорогого финансирования и высоких требований к энергетике устойчивее чувствуют себя крупные холдинги, у которых есть ресурсы для долгосрочных инфраструктурных проектов.</p> <p>В <nobr>2026–2030</nobr> годах к вводу в эксплуатацию ожидается 97 проектов ЦОДов суммарным объемом инвестиций 838,1 млрд рублей. Наибольший объем проектов и инвестиций запланирован на 2027 год. Среди крупнейших ожидаемых объектов — ЦОДы Сбера в Московской и Саратовской областях, проект «Русала» в Иркутской области, а также новые очереди дата-центра DataPro в Москве.</p> <p>«В ближайшие <nobr>2–3</nobr> года фокус рынка будет смещаться в регионы с избыточными энергетическими ресурсами и к площадкам, расположенным ближе к источникам генерации. Это особенно важно для ИИ-задач, которые требуют высокой энергоемкости. Одновременно будет расти интерес к модульным и компактным решениям: они требуют меньших первоначальных вложений, быстрее развертываются и позволяют масштабировать мощности под реальный спрос», — добавил генеральный директор Инвестиционно-аналитической группы ПКР Даниил Новицкий.</p> <p>По мнению Филиппа Врацких, генерального директора «Техэкспо», развитие рынка ЦОДов всё сильнее зависит не только от спроса на вычислительные мощности, но и от доступности энергетической инфраструктуры.</p> <p>«Дата-центр — это не только серверы и стойки, но и сложный энергетический объект. Чем выше нагрузка от облачных сервисов, искусственного интеллекта и государственных цифровых платформ, тем важнее становится вопрос надежного и масштабируемого энергоснабжения. В ближайшие годы преимущество будут получать проекты, где энергетическая часть продумана заранее: есть доступ к мощности, резервирование, возможность быстрого развертывания и понятная экономика эксплуатации. Именно поэтому рынок будет внимательнее смотреть на модульные решения, локальную генерацию и инфраструктуру, которую можно масштабировать по мере роста нагрузки», — прокомментировал Врацких.</p> <p>По словам экспертов, корпоративный сегмент будет чувствовать себя устойчивее коммерческого: крупные холдинги продолжат развивать собственные мощности, чтобы снизить зависимость от арендной инфраструктуры и обеспечить контроль над критически важными данными. Дополнительным драйвером станет господдержка ИТ-инфраструктуры, связанная с задачами информационной безопасности и цифрового суверенитета.</p> <p>«Несмотря на снижение инвестиционной активности в коммерческом сегменте, у отрасли ЦОДов остается потенциал к восстановлению и росту. Объем данных, развитие облачных технологий, искусственного интеллекта и цифровых сервисов продолжают увеличивать спрос на инфраструктуру хранения и обработки информации. Поэтому вопрос не в том, нужны ли рынку новые дата-центры, а в том, где и в какой экономической модели они будут строиться», — резюмировал генеральный директор Инвестиционно-аналитической группы ПКР Даниил Новицкий.</p> Сейчас на стадии строительства находится 42 проекта ЦОДов совокупным объемом инвестиций 282,1 млрд рублей. В числе … message https://www.itweek.ru/themes/detail.php?ID=235061 Wed, 24 Jun 2026 13:28:08 +0300 <p>Искусственный интеллект все заметнее влияет на содержание труда и требования к работникам. На этом фоне все чаще звучат предупреждения о нехватке ИИ-компетенций. Насколько эти опасения подтверждаются данными? Институт статистических исследований и экономики знаний (ИСИЭЗ) НИУ ВШЭ анализирует структурный разрыв между спросом и предложением навыков работы с искусственным интеллектом на российском рынке труда на основе результатов Обследования рабочей силы (ОРС) Росстата.</p> <p>Как ранее подробно сообщали, данные ОРС указывают на отсутствие массового дефицита ИИ-компетенций: навыками работы с ИИ владеют 37,5% занятых, тогда как необходимыми для текущей работы их считают лишь 4,9%.</p> <p>При этом «избыток» ИИ-компетенций встречается значительно чаще, чем их дефицит: у трети всех занятых фактический уровень владения ИИ превышает требования работодателя. Даже с учетом ограничений самооценок, данные ОРС фиксируют высокий уровень соответствия между имеющимися и востребованными ИИ-компетенциями: в 73% случаев работники обладают необходимым для работы уровнем подготовки.</p> <p>Однако за общей картиной отсутствия массового дефицита скрываются локальные зоны нехватки анализируемых навыков. Среди работников, которым ИИ необходим для выполнения текущей работы, о дефиците соответствующих компетенций сообщает каждый шестой (15%).</p> <p>На базовом уровне дефицит минимален (6%), но по мере роста требований заметно увеличивается: при требованиях среднего уровня о нем сообщает каждый пятый работник (20%), продвинутого — почти каждый четвертый (24%). Наибольшие сложности связаны с переходом от базового использования массовых ИИ-сервисов к профессиональной интеграции ИИ в рабочие процессы.</p> <p>В профессиональном разрезе самая высокая интенсивность дефицита наблюдается у специалистов по ИКТ и ИКТ-техников. Однако основной вклад в общий дефицит формируют массовые профессии: специалисты в области образования, науки и техники, бизнеса и администрирования. По численности работников с дефицитом ИИ-компетенций лидирует сфера образования, далее следуют обрабатывающие производства, информация и связь, профессиональная и научная деятельность, здравоохранение.</p> <p>ИИ постепенно становится технологией общего назначения и выходит за пределы ИКТ-сектора, распространяясь на массовые профессии и традиционные отрасли экономики. Анализ данных Обследования рабочей силы Росстата за 2025 год указывает на отсутствие массового дефицита навыков для работы с ИИ-инструментами. Имеющиеся у работников ИИ-компетенции в большинстве случаев соответствуют должностным требованиям, а нередко и превосходят их. Ключевой вызов связан не с нехваткой базовых пользовательских навыков работы с ИИ, а с переходом от использования массовых ИИ-сервисов к профессиональной интеграции ИИ в рабочие процессы.</p> Искусственный интеллект все заметнее влияет на содержание труда и требования к работникам. На этом фоне все … message https://www.itweek.ru/themes/detail.php?ID=235060 Wed, 24 Jun 2026 13:25:53 +0300 <p>Компания «Аладдин» объявила о выпуске обновленной версии JaCarta Identity Provider (JIP) — продукта для реализации корпоративного SSO (однократной аутентификации) в совместимые приложения. Основным нововведением стала реализация механизма строгой аутентификации, что позволит пользователям авторизоваться в корпоративных приложениях с помощью цифровых сертификатов на USB-токенах и смарт-картах.</p> <p>Новый функционал JIP поможет заказчикам привести свою ИТ-инфраструктуру в соответствие с требованиями <nobr>117-го</nobr> Приказа ФСТЭК России, который предписывает использование строгой аутентификации и механизмов однократного входа (SSO) для всего оборудования и ПО ГИС и КИИ. Это имеет очень важное значение для ИТ и ИБ-инфраструктур российского рынка, позволяя значительно усилить защиту от фишинга, MITM и других распространенных атак.</p> <p>JaCarta Identity Provider (JIP) позволяет реализовать:</p> <ul> <li>однократную аутентификацию в информационную систему и во все используемые приложения и сервисы (единый вход или SSO — Single Sign-On);</li> <li>аутентификацию по kerberos-билету (наличие Kerberos-билета определяется автоматически);</li> <li>строгую аутентификацию по цифровым сертификатам и усиленную аутентификацию с использованием OTP и PUSH (необходим высокопроизводительный сервер аутентификации JaCarta Authentication Server (JAS);</li> <li>поддержку SLO для клиентов SAML и кросс-протокольного SLO SAML/OIDC;</li> <li>полную автоматизацию учёта и управления настройками OIDC/SAML-клиентов JIP;</li> <li>аудит — формирование журнала аутентификаций и других действий администраторов и пользователей, которые необходимо отслеживать для обеспечения информационной безопасности;</li> <li>мониторинг — отслеживание параметров работы JIP.</li> </ul> <p>«Требования регуляторов к механизмам аутентификации в государственных информационных системах и объектах КИИ становятся всё более строгими. Мы видим растущий запрос заказчиков на решения, которые позволяют одновременно повысить уровень безопасности и сохранить удобство доступа пользователей к корпоративным ресурсам. Реализованный в JaCarta Identity Provider механизм строгой аутентификации по сертификатам на токенах и смарт-картах помогает выполнить требования <nobr>117-го</nobr> приказа ФСТЭК России и существенно снизить риски, связанные с компрометацией учётных данных и фишинговыми атаками», — прокомментировал Станислав Винарский, менеджер по развитию бизнеса JMS/JAS/JIP, «Аладдин».</p> Компания «Аладдин» объявила о выпуске обновленной версии JaCarta Identity Provider (JIP) — продукта для реализации … message https://www.itweek.ru/themes/detail.php?ID=235057 Wed, 24 Jun 2026 10:49:49 +0300 <p><em>Искусственный интеллект повысит производительность за счет трансформации рабочей силы, пишут в корпоративном блоге ведущие аналитики </em><em>IDC</em><em>, приводя в качестве подтверждения выводы нового отчета </em><em>IDC</em> <em>«</em><em>The</em> <em>Economic</em> <em>Impact</em> <em>of</em> <em>AI</em><em>: 2026 </em><em>Edition</em><em>».</em></p> <p>Искусственный интеллект больше не является обещанием будущего; это экономическая сила, активно меняющая отрасли, рабочую силу и прогнозы ВВП по всему миру. Хотя ожидается, что ИИ приведет к масштабной трансформации рабочей силы в течение ближайших пяти лет, сроки остаются неопределенными, поскольку организации продолжают испытывать трудности с определением оптимальных сценариев использования и измеримых бизнес-результатов. Несмотря на широко распространенные прогнозы о том, что ИИ заменит рабочие места, пока мало доказательств того, что это происходит в больших масштабах, и бóльшая выгода от повышения производительности может быть достигнута за счет замены работы, а не работников. Таковы основные выводы из отчета этого года об экономическом влиянии ИИ.</p> <p>Главная новость: инвестиции обусловлены прогнозируемым экономическим эффектом</p> <p>Мы приближаемся к тому, что, по прогнозам, <nobr>2027-й</nobr> станет началом «второй волной» расходов на ИТ, обусловленных ИИ, когда инвестиции в ИИ приведут к тому, что общие расходы на технологии достигнут уровней, которые наблюдались в середине <nobr>1990-х.</nobr></p> <p>Мировые расходы на ИТ выросли в 2025 г. более чем на 14%, в основном за счет инвестиций поставщиков услуг в инфраструктуру ИИ. Сервис-провайдеры продолжают активно инвестировать, но «вторая волна» — это ожидаемый всплеск корпоративных расходов на сценарии использования, связанные с агентным ИИ. Прогнозируется, что бюджеты корпоративных ИТ-подразделений будут расти самыми быстрыми темпами почти за 30 лет.</p> <p>Эта грядущая волна зависит от экономического воздействия ИИ, которое ожидают организации. Здесь есть важная оговорка: пока что эти запланированные инвестиции в значительной степени поддерживаются ожидаемым повышением производительности, которое будет зависеть от измеримых бизнес-результатов.</p> <p>Многие бизнес-руководители сообщают о расходах, которые, по крайней мере частично, обусловлены FOMO (страхом упустить возможность). Существуют пробелы в зрелости ИИ, которые многим организациям необходимо восполнить в течение следующих <nobr>6-12 месяцев.</nobr></p> <p>В начале <nobr>2026-го</nobr> IDC назвала этот год «годом расплаты» («year of reckoning») для мировой экономики и ИИ. Экономический рост и ИИ теперь тесно связаны, причем в последние два года ИИ в значительной степени отвечал за стабильный рост ВВП, особенно в США и Китае. В условиях инфляции, которая в 2026 г. создаст проблемы для ИИ-экономики, существуют риски торможения.</p> <p>Но если нынешние темпы внедрения сохранятся и если измеримые бизнес-результаты будут поддерживать расходы на ИТ, ИИ приведет к перестройке производительности, глобальной трансформации рабочей силы и созданию к 2031 г. ценности на сумму более 22 трлн. долл.</p> <h3>Колоссальная совокупная ценность</h3> <p>В базовом сценарии прогнозируется, что в период с 2025 по 2031 гг. экономический вклад ИИ будет расти со среднегодовым темпом 35,6% и к 2031 г. достигнет уровня 22,5 трлн. долл. Даже в ограниченном, негативном сценарии (с учетом геополитических потрясений, регуляторных трений и замедления внедрения в предприятиях) эта цифра составляет 18,1 трлн. долл. В сценарии ускоренного роста она возрастает до 24,5 трлн. долл..</p> <p>Это не абстрактные цифры. Они отражают реальные потоки прямых доходов от ИИ, эффекты в цепочках поставок и последующую экономическую активность, поскольку работники и домохозяйства получают выгоду от повышения производительности.</p> <p>Экономическое воздействие ИИ распределится по регионам мира:</p> <p>#IMAGE_235059#</p> <ul> <li> Северная и Южная Америки: 14,1 трлн. долл., более 60% глобального эффекта, обусловленного доминированием США в гиперскейлерах, базовых моделях и полупроводниках.</li> <li> Азиатско-Тихоокеанский регион: 4,4 трлн. долл., это регион с самым быстрым ростом, где Китай выступает в качестве двигателя поставок, а развитые рынки, такие как Япония, Корея и Сингапур, стимулируют корпоративные инновации.</li> <li> Европа, Ближний Восток и Африка: 4,0 трлн. долл. Европа устанавливает золотой стандарт регулирования посредством Закона ЕС об ИИ, в то время как Ближний Восток (в частности, ОАЭ и Саудовская Аравия) становится новым двигателем роста.</li> </ul> <p>Несмотря на все эти впечатляющие цифры, влияние ИИ на макроэкономические данные пока выделить сложно. Мы только сейчас переходим от оценок влияния ИИ, основанных на опросах, к точке, где измеримое отклонение от исторических тенденций должно стать видимым в течение следующих 12 месяцев.</p> <p>Что меняет ситуацию, так это агентный ИИ. В отличие от предыдущих волн ИИ, агенты могут выполнять сложные многоэтапные задачи с минимальным участием человека, сокращая неэффективность бизнес-процессов в масштабах, недоступных предыдущим инструментам автоматизации. Покупатели ИТ-решений ожидают экономии операционных расходов в результате внедрения автоматизации на основе ИИ.</p> <h3>Риски реальны и в основном внешние</h3> <p>В отчете выделены четыре основных фактора, которые могут нарушить график создания ценности с помощью ИИ:</p> <ol> <li><strong> Геополитика и фрагментация торговли. </strong>Экспортный контроль над полупроводниками уже меняет цепочки поставок. Если напряженность усилится, доступ к критически важному оборудованию для ИИ станет непредсказуемым как для бизнеса, так и для правительств.</li> <li><strong> Энергетическая инфраструктура.</strong> Потребности ИИ в энергии превышают пропускную способность существующих электросетей. Доступность электроэнергии становится настоящим узким местом для расширения центров обработки данных и стратегическим фактором, который нельзя игнорировать ни в одной серьезной дорожной карте ИИ.</li> <li><strong> Дефицит квалифицированных кадров.</strong> Спрос на специалистов, обладающих навыками разработки, внедрения и управления ИИ, растет быстрее, чем успевают реагировать программы обучения. Переквалификация сейчас так же важна, как и инфраструктура.</li> <li><strong> Отставание внедрения систем управления.</strong> Менее трети предприятий полностью внедрили структуры управления ИИ. В условиях резкого расхождения регуляторных подходов между ЕС и США, многонациональные организации сталкиваются с действительно сложной ситуацией в сфере соблюдения нормативных требований.</li> </ol> <h3>ИИ заменяет работу, а не работников (пока что)</h3> <p>Главный вывод прост: в официальных данных по безработице нет доказательств того, что ИИ приводит к существенному сокращению рабочих мест. Уровень безработицы в США остается на исторически низком уровне.</p> <p>Но отсутствие массового сокращения рабочих мест — это не то же самое, что «обычное положение дел». Происходит и будет ускоряться трансформация рабочей силы: переход от рутинных задач к нерутинной когнитивной и межличностной работе.</p> <p>Этот переход происходит уже несколько десятилетий и в значительной степени связан с расходами на ИТ. Доля рутинных задач в общей занятости снизилась с примерно <nobr>60-65%</nobr> в 1960 г. до <nobr>40-45%</nobr> в <nobr>2020-м.</nobr> ИИ не создает нового направления, но значительно ускоряет эту траекторию. IDC прогнозирует дальнейшее снижение доли рутинных задач до примерно 30% к 2031 г.</p> <p>В отчете в качестве конкретного примера приводится разработка ПО: ИИ может в значительной степени автоматизировать рутинное кодирование и документирование (сокращение времени выполнения задач до 70%), в то время как работа по тестированию и архитектуре дополняется, а не заменяется ИИ. Разработчики, которые смогут адаптироваться, будут тратить больше времени на стратегическую, требующую принятия решений работу, в которой, в конечном итоге, и заключается ценность.</p> <h3>Что это значит для ИТ-поставщиков: три императива</h3> <p>ИТ-поставщикам необходимо срочно заняться следующими стратегическими направлениями:</p> <ol> <li><strong> Получение краткосрочной прибыли за счет агентного ИИ. </strong>Наиболее значимая возможность в краткосрочной перспективе заключается в применении агентов ИИ на уровне задач, в рамках рабочих процессов и во всех приложениях. Продукты должны отражать быстро меняющиеся сценарии использования и помогать клиентам достигать экономического эффекта в масштабе, а не просто проводить пилотные проекты.</li> <li><strong> Инвестирование в долгосрочный успех клиентов. </strong>Передача знаний важнее, чем контракты на поддержку. Покупателям ИТ-решений нужна помощь в управлении изменениями, повышении квалификации и достижении реальных бизнес-результатов от агентного ИИ. Если конечные пользователи не смогут получить экономическую выгоду в масштабе, инвестиционный импульс застопорится.</li> <li><strong> Взятие на себя ответственности за управление ИИ. </strong>Социальные последствия широкого внедрения ИИ огромны. Поставщики, которые активно взаимодействуют с политиками и бизнес-лидерами, направляя их к результатам, которые раскрывают человеческий потенциал, а не просто автоматизируют его, будут лучше подготовлены к сохранению актуальности и доверия в долгосрочной перспективе.</li> </ol> <h3>Итог</h3> <p>Новый отчет рисует картину ИИ-экономики, которая является масштабной, ускоряющейся и неопределенной по срокам. Увеличение экономического вклада ИИ до 22,5 трлн. долл. не является гарантированным; оно зависит от того, насколько организации перейдут от пилотных проектов к масштабному внедрению, насколько энергетическая инфраструктура и навыки будут успевать за прогрессом, а также от рамок управления, которые способствуют, а не препятствуют инновациям.</p> <p>Ясно одно: предприятия и поставщики, которые рассматривают ИИ как стратегический приоритет, инвестируя в трансформацию рабочей силы, управление изменениями и ответственное внедрение, будут в наилучшем положении для получения выгоды, даже если ожидаемые сроки будут нарушены. Те, кто будет ждать определенности, могут обнаружить, что окно для конкурентной дифференциации уже закрылось.</p> Искусственный интеллект повысит производительность за счет трансформации рабочей силы, пишут в корпоративном блоге … article https://www.itweek.ru/themes/detail.php?ID=235056 Wed, 24 Jun 2026 10:31:35 +0300 <p><em>Давление, связанное с необходимостью добиваться успехов в области искусственного интеллекта, может стать рецептом выгорания ИТ-руководителей. CIO компаний Expereo и Quadient рассказали порталу </em><em>InformationWeek</em><em>, как разделение ответственности за результаты внедрения ИИ может помочь предотвратить перегрузку, продолжая при этом стимулировать внедрение и получение ценности.</em></p> <p>В условиях, когда советы директоров все больше стремятся к успехам в области ИИ, CIO начинают понимать, что попытка взять на себя всю ответственность — это быстрый путь к выгоранию.</p> <p>Нина Татсия, CIO компании Quadient, столкнулась с этой реальностью после того, как в прошлом году заняла высшую технологическую должность в компании-поставщике ПО для автоматизации бизнеса. «Когда я ступила в должность, я обнаружила, что работаю по 20 часов в день... потому что хотела делать все, включая ИИ, — рассказывает она. — Конечно, это нежизнеспособно».</p> <p>Выгорание среди ИТ-руководителей не является чем-то новым. Например, должность CISO давно несет в себе этот риск: согласно <a href="https://www.proofpoint.com/us/newsroom/press-releases/proofpoint-2025-voice-ciso-report">отчету</a> Proofpoint «2025 Voice of the CISO Report», 63% опрошенных руководителей служб информационной безопасности испытывали или наблюдали профессиональное выгорание в течение предыдущего года.</p> <p>Поскольку CIO испытывают давление по поводу внедрения ИИ и его быстрой эволюции, они могут столкнуться с аналогичными рисками.</p> <h3>CIO под давлением</h3> <p>CIO, как правило, увлечены новыми технологиями, но ИИ — пожалуй, наиболее близкая к имитации человеческого интеллекта технология — создает уникальный набор проблем:</p> <ul> <li> все еще неясный путь к возврату инвестиций после миллионов и миллиардов, потраченных компаниями;</li> <li> тревога сотрудников по поводу возможной потери работы;</li> <li> ожидания заинтересованных сторон в отношении трансформации бизнеса с помощью ИИ.</li> </ul> <p><a href="https://www.ibm.com/downloads/documents/us-en/16ddce7b4954875d">Исследование</a> IBM «2026 Tech Leader Study» иллюстрирует давление, с которым сталкиваются CIO, стремясь вывести ИИ из пилотных проектов в корпоративную эксплуатацию. Только 11% из 2000 опрошенных технологических руководителей высшего звена заявили, что готовы к развертыванию агентов ИИ, запланированному на следующий год. Кроме того, 77% опрошенных организаций сообщили о том, что управление ИИ отстает. Несмотря на отсутствие полного контроля над системами, две трети технологических руководителей заявили, что несут ответственность за результаты работы этих систем.</p> <p>И, наконец, есть финансовый аспект руководства со стороны CIO. Расходы на ИИ стремительно растут, однако 84% технологических руководителей, опрошенных IBM, заявили, что они не полностью внедрили финансовое управление ИИ, а 85% заявили, что у них нет полной информации о расходах на ИИ в режиме реального времени.</p> <h3>Путь к выгоранию</h3> <p>В гонке за внедрением ИИ CIO могут сильно нагружать себя и свои команды, но Жан-Филипп Авеланж, CIO компании Expereo, предоставляющей управляемые сетевые услуги, считает, что риски выходят за рамки проблем с рабочими нагрузками. «Можно проделывать большую работу, но не это приводит к выгоранию ИТ-отдела или CIO, — поясняет он. — Проблема в несоответствии ожиданиям». Если разрыв между ожиданиями от CIO советов директоров и высшего руководства и реальностью не удастся преодолеть, высок риск выгорания.</p> <p>Авеланж отмечает, что выгорание CIO оказывает мультипликативный эффект на всю организацию. Выгоревшие сотрудники, обеспокоенные тем, что их рабочие места будут изменены — или ликвидированы — ИИ, могут затруднить для организации получение выгоды от этой технологии.</p> <p>«FOBO — страх упустить выгоду — теперь стал частью рабочего жаргона», — говорит Стейси Кэдиган, партнер Information Services Group, отмечая, что эта тревога угрожает подорвать достижения, которых организации стремятся добиться с помощью ИИ. «Ожидаемое повышение производительности может оказаться невозможным, если сотрудники будут дезориентированы, потрясены и истощены переходом к ИИ», — поясняет она.</p> <h3>Путь к успеху вместо забвения ИИ</h3> <p>CIO должны принять реальность того, что они не могут решить все проблемы, возникающие в процессе работы их организаций над тем, чтобы максимально использовать возможности ИИ, считает Татсия. «Невозможно изучить всё, и не следует изучать всё. Необходимо... сохранять свои навыки как человека, управляющего этой сферой», — говорит она.</p> <p>Эксперты отмечают важность следующего:</p> <ul> <li><strong>Мягкие навыки. </strong>Креативность, понимание людей и понимание бизнес-целей гораздо важнее для CIO, чем понимание каждой мельчайшей детали существующих технологий, считает Татсия.</li> <li><strong>Новая структура команды и повышение квалификации.</strong> Чтобы соответствовать новым требованиям к ИТ, CIO следует сосредоточиться на повышении квалификации нынешних членов команды и стратегическом найме, говорит Татсия. CIO определенно должны изменить форму и структуру команды, чтобы соответствовать этому технологическому сдвигу и новым способам работы.</li> <li><strong>Управление ожиданиями.</strong> По мере того, как CIO реформируют свои команды и учатся быть агентами перемен на своих предприятиях, им необходимо найти способы общаться с другими руководителями и советами директоров по поводу принимаемых ими стратегических решений. CIO должны управлять ожиданиями, а не обрекать себя на отставание, пытаясь выполнить все задачи и угодить всем, говорит Авеланж.</li> </ul> <h3>Всем нужна возможность выпустить пар</h3> <p>Как бы всепоглощающе ни был ИИ, посвятить ему всю работу, отдать все время — это нежизнеспособно. Если CIO хотят избежать выгорания сейчас или в будущем, им необходимо выделить время на другие аспекты своей жизни. «Мне нужно найти тот час в день, когда я не думаю о работе, что очень сложно. Занимайтесь спортом или гуляйте... иначе вы не будете по-настоящему полезны для себя, своей семьи или работы», — советует Татсия.</p> <p>CIO могут лучше управлять риском выгорания, окружая себя правильными людьми и расставляя приоритеты в использовании своего времени, но им также необходима структурная поддержка со стороны своих предприятий. «Организации, которые действительно смогут уменьшить усталость руководства и помочь ему наиболее эффективно справиться с выгоранием, — это те, которые действительно инвестируют в перепроектирование управления ИИ», — считает Кэдиган. Разделение ответственности за результаты ИИ и ранний анализ операционных моделей могут быть более эффективными, чем просто постоянное давление только на CIO.</p> Давление, связанное с необходимостью добиваться успехов в области искусственного интеллекта, может стать рецептом … article https://www.itweek.ru/themes/detail.php?ID=235055 Tue, 23 Jun 2026 15:03:11 +0300 <p>Компания AppSec Solutions, российский разработчик решений для кибербезопасности, выпустила крупное обновление платформы анализа защищённости мобильных приложений AppSec.Sting. Платформа полностью переведена с монолитной на микросервисную архитектуру на базе Kubernetes и получила переработанный подход к анализу: расширено покрытие SCA с интеграцией в AppSec.Track, обновлён динамический анализ под iOS, полностью обновлен пользовательский интерфейс. Таким образом, AppSec.Sting повышает пропускную способность и отказоустойчивость для клиентов, что ускоряет сканирование и снижает затраты на вычислительные ресурсы — в облаке и в инфраструктуре заказчика.</p> <p>Микросервисная модель снимает ключевые ограничения «монолита» — избыточное потребление ресурсов и сложность масштабирования. Теперь вычислительные мощности выделяются точечно: их получают только те компоненты, которые участвуют в сканировании в конкретный момент, а при росте нагрузки система масштабируется горизонтально. Это позволяет одновременно выполнять значительно больше сканирований без деградации производительности и убирает простаивающие мощности.</p> <p>Для заказчиков, разворачивающих решение в собственном контуре, это означает ощутимое снижение требований к серверному парку и совокупной стоимости владения. Параллельно команда переработала ядро анализа — платформа стала находить больше и работать быстрее:</p> <ul> <li>SCA — анализ состава ПО. Переработан движок извлечения компонентов и существенно расширено покрытие: платформа точнее определяет, из каких библиотек и зависимостей собрано приложение. Добавлена интеграция с AppSec.Track — для контроля open-source-рисков и безопасности цепочки поставок;</li> <li>iOS — переработанный динамический анализ. Реализован перехват трафика и обновлены инструменты DAST — сканирование приложений для iPhone стало точнее и глубже;</li> <li>WebView — отдельный модуль. Добавлен поиск уязвимостей в WebView, одной из самых частых точек уязвимостей в мобильных приложениях;</li> <li>Правила детектирования. Обновлены и расширены правила поиска — выше покрытие и точность.</li> </ul> <p>«Мы провели технологическую трансформацию продукта, которая напрямую экономит ресурсы клиентов: вычислительных мощностей требуется меньше, а объём одновременной работы кратно вырос. При этом мы вложились не только в инфраструктуру, но и в сам анализ — заметно расширили покрытие SCA и связали его с AppSec.Track, переработали динамический анализ под iOS и полностью обновили интерфейс. Наша цель — гибкая и современная платформа, которая находит больше, работает быстрее и удобнее в эксплуатации», — рассказал Никита Пинаев, руководитель продукта AppSec.Sting в AppSec Solutions.</p> <p>AppSec.Sting — часть экосистемы AppSec Solutions для автоматизированного анализа и безопасной разработки ПО и один из первых продуктов компании, запущенный в 2020 году. Платформа объединяет ключевые практики анализа защищённости мобильных приложений — DAST, SAST/BCA (анализ бинарного кода), IAST, API Security Testing и SCA — и в автоматическом режиме выявляет и приоритизирует уязвимости, отделяя наиболее критичные. Это помогает владельцам приложений находить и закрывать уязвимости до того, как ими воспользуются злоумышленники. AppSec.Sting регулярно проводит исследования мобильных приложений в популярных магазинах приложений.</p> Компания AppSec Solutions, российский разработчик решений для кибербезопасности, выпустила крупное обновление платформы анализа … message https://www.itweek.ru/themes/detail.php?ID=235054 Tue, 23 Jun 2026 10:02:12 +0300 <p><em>Согласно прогнозам </em><em>IDC</em><em>, глобальные ИТ-расходы на искусственный интеллект в 2026 г. достигнут 409 млрд. долл., что примерно на 53% больше, чем в прошлом году, и к 2029 г. они выйдут на уровень 700 млрд. долл. Это не тенденция. Это структурная трансформация глобальной технологической экономики, происходящая в режиме реального времени, пишет в корпоративном блоге Эрик Ньюмарк, вице-президент и генеральный директор подразделения SaaS, корпоративного ПО, CX и решений для рабочих мест IDC.</em></p> <p>И все же, несмотря на все эти инвестиции, предприятия не успевают за ИИ. Он уже широко применяется в производственной среде: по состоянию на начало 2026 г. примерно две трети организаций уже использовали ИИ в реальных производственных средах. Но большинство из них не масштабировали ИИ существенно за пределы целевых, изолированных развертываний. Широкое, полномасштабное внедрение остается исключением, а не правилом. Исследование IDC «FutureScape 2026» уточняет этот момент, прогнозируя, что почти 50% цифровых сценариев использования ИИ не достигнут целевых показателей ROI в 2026 г. из-за неясной выгоды для бизнеса, слабого взаимодействия человека и машины и недостаточного фундамента данных.</p> <p>Это не технологическая проблема. Технологии сейчас развиваются быстрее, чем когда-либо в истории современных корпоративных вычислений. Согласно отчету IDC «The Speed of AI Value Creation in Applications: What’s Causing the Delay?», это проблема обеспечения внедрения. Суть в том, что разрыв увеличивается. ИИ-инновации опережают принятие ИИ на предприятиях, и только вендоры, разрабатывающие и продающие ПО ИИ, могут решить эту проблему.</p> <h3>Разрыв между пилотными проектами и производством — где умирает ценность</h3> <p>Мы это уже проходили. В начале облачной эры организации проводили десятки успешных пилотных проектов, одновременно пытаясь мигрировать основные рабочие нагрузки. В начале эры SaaS внедрение застопорилось из-за сложности интеграции и управления изменениями, а не из-за возможностей продуктов. Эта картина знакома. Технологии стремительно развиваются, а корпоративной экосистеме (интеграции, управление, навыки, инфраструктура данных) требуются годы, чтобы догнать их.</p> <p>ИИ повторяет этот цикл с большей скоростью и более значительными последствиями. Вендоры, которые это понимают и действуют в соответствии с этим, определят следующую эру лидерства в сфере корпоративного ПО. Вендоры, которые этого не понимают, обнаружат, что одних лишь отличных технологий недостаточно для устранения разрыва доходов.</p> <h3>Ориентируйтесь на результаты, а не на возможности</h3> <p>Первое, что необходимо сделать, — это переосмыслить то, что вендоры на самом деле продают. Предприятиям не сложно понять, что может делать ИИ на демонстрации. Им сложно связать возможности ИИ с измеримыми бизнес-результатами в рамках их конкретных операционных сред, данных, рабочих процессов и требований комплаенса.</p> <p>Вендоры, которые ориентируются на эталонные показатели моделей и планы развития функций, говорят на языке, который их покупатели перестали считать приоритетным. Вендоры, которые ориентируются на количественно измеримые результаты (сокращение времени обработки счетов, снижение количества ошибок в прогнозировании спроса, ускорение закрытия финансовой отчетности), завоюют доверие и внутреннюю поддержку, необходимые для перехода от пилотного проекта к производству. Это не маркетинговая корректировка. Это фундаментальное перепозиционирование ценностного предложения с прямым влиянием на выручку. Для любого поставщика ИИ рост больше не связан с количеством лицензий. Он связан с тем, насколько глубоко клиенты интегрируют ИИ в повседневные рабочие процессы. Продажи, ориентированные на результат, ускоряют этот процесс.</p> <h3>Время получения выгоды теперь является конкурентным преимуществом</h3> <p>Одним из наиболее важных показателей, которые должны отслеживать вендоры, является время получения выгоды: как быстро новый клиент получает существенно улучшенный рабочий процесс благодаря ИИ. Сейчас этот срок слишком велик для слишком многих предприятий. Сложность интеграции, пробелы в готовности данных и нехватка внутренних навыков создают трение, которое замедляет темпы и дает комитетам по закупкам поводы для раздумий.</p> <p>Вендоры могут напрямую устранить этот пробел. Готовые интеграции для распространенных корпоративных архитектур, шаблоны рабочих процессов, адаптированные к конкретным отраслевым сценариям использования, и структурированные программы адаптации, которые сопровождают клиентов от пилотного проекта до внедрения в производство, перестали быть просто желательными услугами. Теперь это сам продукт. Предприятия, успешно масштабирующие ИИ, делают это с помощью партнеров-поставщиков, которые работают с ними там, где они находятся, а не там, где, по мнению поставщика, они должны быть.</p> <h3>Прекратите перекладывать проблему данных на клиента</h3> <p>Плохой фундамент данных неизменно является одним из главных препятствий для окупаемости инвестиций в ИИ. Наше исследование это наглядно показало, и это основная причина, по которой примерно половина пилотных ИИ-проектов не приносят окупаемости. Тем не менее, многие вендоры по-прежнему ошибочно рассматривают готовность данных как необходимое условие для клиента, а не как их общую проблему.</p> <p>От этого предположения нужно отказаться. На следующем этапе развития рынка победят те вендоры, которые помогут предприятиям оценивать, очищать и структурировать свои данные в рамках процесса внедрения, а не в качестве предварительного условия, которое клиенты должны выполнить до начала реального взаимодействия. Это означает инвестиции в инструменты обеспечения готовности данных, предложение предварительных оценок и явное включение качества данных в критерии успеха с самого первого дня. В лучшем случае, передача проблемы с данными клиенту задерживает развертывание. В худшем случае, это полностью губит проект и лишает его возможности продления.</p> <h3>Управление — это не функция, это фундамент</h3> <p>Проблемы управления (безопасность, возможность аудита, соответствие нормативным требованиям, ответственное использование ИИ) значительно замедляют циклы принятия решений предприятиями. Вендоры, рассматривающие управление как дополнительный уровень, который можно добавить позже, сами себе создают препятствия. Предприятия, которые останавливаются после успешного пилотного проекта, часто делают это не потому, что ИИ перестал работать, а потому, что юридические вопросы, вопросы комплаенса или ИТ-безопасности выявили проблемы, для решения которых продукт не был предназначен.</p> <p>Внедрение объяснимости, контроля доступа, журналов аудита и схем обеспечения нормативных требований в основной продукт, а не их добавление поверх, — вот что отличает вендоров, хорошо подготовленных к корпоративным внедрениям, от тех, кто вечно застревает на стадии проверки концепции. И окно возможностей для правильного решения этой задачи сужается, поскольку требования к управлению быстро приближаются к нормативным требованиям.</p> <h3>Согласование коммерческих моделей с успехом клиентов</h3> <p>Наиболее подготовленными к преодолению разрыва во внедрении ИИ будут те вендоры, которые строят свои коммерческие отношения вокруг результатов клиентов, а не вокруг количества рабочих мест или потребления токенов. Недавно анонсированные Oracle 22 приложения Fusion Agentic являются отличным примером такого переориентирования, поскольку они переводят корпоративные программные решения из пассивных «систем учета» в автономные «системы результатов». SAP и ServiceNow недавно объявили о подобном позиционировании. SAP выходит за рамки традиционного SaaS в сторону модели, ориентированной на результат, где агентный ИИ, основанный на Joule, находится между пользователем и корпоративным исполнением. Пользователи заявляют о своих бизнес-целях, а автономные системы SAP обрабатывают все остальное, более тесно согласовывая исполнение с результатом. ServiceNow также целенаправленно переориентировалась на выполнение задач, ориентированных на результат, перепозиционировав себя из платформы учета в то, что теперь называется «диспетчерской вышкой ИИ». Этот сдвиг распространяется и на ее партнерскую экосистему, где обновленные программы теперь вознаграждают участников на основе реальных результатов клиентов и успешных внедрений, а не традиционных уровней членства.</p> <p>Вендорам необходимо постоянно уделять больше внимания ценообразованию, основанному на результатах, стимулированию к завершению основных этапов внедрения и выделению ресурсов для обеспечения успеха клиентов, чтобы четко демонстрировать, что их финансовые интересы соответствуют результатам клиентов, а не только первоначальной транзакции. Такое соответствие укрепляет доверие, необходимое для долгосрочного расширения, выгодного обеим сторонам.</p> <p>Растущий разрыв между ИИ-инновациями и внедрением ИИ на предприятиях реален, но его можно сократить. Технология не является препятствием. Путь к его сокращению лежит непосредственно в том, как вендоры ПО взаимодействуют со своими клиентами не только в точке продажи, но и на протяжении всего пути от пилотного проекта до производства и масштабирования. Вендоры, которые возьмут на себя эту ответственность, выиграют дважды: завоюют доверие предприятий и благодаря этому увеличат долю рынка.</p> Согласно прогнозам IDC, глобальные ИТ-расходы на искусственный интеллект в 2026 г. достигнут 409 млрд. долл … article https://www.itweek.ru/themes/detail.php?ID=235052 Tue, 23 Jun 2026 09:44:38 +0300 <p><em>Компании продолжают массово внедрять искусственный интеллект. По данным Gartner, к 2028 году агентный ИИ будет встроен в 33% корпоративных приложений — против менее 1% в 2024</em><em>-м</em><em>. Но на практике большинство компаний сталкиваются не с проблемой доведения ИИ задач до результата, а с проблемой внедрения: инструменты закуплены, пилоты запущены, а реального эффекта бизнес не видит.</em></p> <p><em>Причина часто оказывается неожиданной. Судьбу ИИ-трансформации в компании сегодня решают не отдельные команды и не центры компетенций, а руководители среднего звена — люди, которые управляют процессами, KPI и ежедневной работой команд. Именно от них зависит, станет ли ИИ рабочим инструментом или останется дорогим экспериментом.</em></p> <p><em>Обсудим</em><em>, почему внедрением не может заниматься только центр компетенций и что стоит учесть руководителям.</em></p> <h3>Автоматизация ради автоматизации: как делать не надо</h3> <p>Одна из самых распространенных ошибок — начинать внедрение с технологии вместо бизнес-задачи. Внутри компании это выглядит так: «Нам нужен ИИ-агент. Все вокруг используют — значит, и нам надо». Но для чего?</p> <p>Представьте, что в отдел — допустим, в тендерный — приходит руководство и говорит: «Похоже, вы тратите слишком много времени на ручную работу. Давайте что-то автоматизируем». Команда анализирует процессы и находит задачу, которая действительно занимает до 40% рабочего времени сотрудников. Ее автоматизируют, внедрение проходит успешно, люди начинают работать быстрее.</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>В то время как задача второго — обеспечивать стабильность. На английском языке этот принцип называется «keep the lights on»: проще говоря, нужно делать все, чтобы свет не погас.</p> <p>Именно поэтому мидл-менеджмент обычно сопротивляется изменениям. Дело не в том, что руководитель «боится ИИ», это даже не назвать саботажем — просто любое изменение разрушает систему, которую он так тщательно выстраивал. Особенно болезненно это выглядит в случаях, когда процессы только-только удалось стабилизировать, а теперь их нужно перестраивать под искусственный интеллект.</p> <p>С точки зрения руководителя все выглядит примерно так:</p> <ul> <li> KPI только начали работать;</li> <li> команда уже адаптировалась;</li> <li> процессы стабилизировались;</li> <li> риски стали понятными.</li> </ul> <p>И в этот момент команду снова переводят в режим изменений, которые нарушают хрупкий баланс, выстроенный с большим трудом. При таком раскладе сопротивление — совершенно нормальная реакция.</p> <h3>Почему мидл-менеджмент может сопротивляться ИИ</h3> <p>Одна из ключевых причин — несовпадение ожиданий и реальности.</p> <p>Сегодня информационное поле устроено так, будто искусственный интеллект уже умеет практически все. Тут вам и агенты вместо сотрудников, и полноценная команда без живых разработчиков, и автоматизация всех-всех бизнес-процессов — не просто ИИ, а какой-то Брюс Всемогущий.</p> <p>В результате топ-менеджмент ожидает мгновенного эффекта, мидл — копит скепсис и ищет подтверждения того, что это не работает. Особенно если неудачные кейсы уже были: например, пилот оказался слишком дорогим или качество оказалось нестабильным.</p> <p>Внутри компаний это может привести к аллергии на любые ИИ-инициативы.</p> <p>Важно и то, чтобы руководитель верил в изменения. Мидл-менеджеру недостаточно просто стоять в стороне и не мешать, если компания решила внедрить искусственный интеллект: он должен стать драйвером новых процессов.</p> <p>На практике это означает:</p> <ul> <li> перестраивать работу команды;</li> <li> менять сценарии;</li> <li> вводить новые правила;</li> <li> переобучать сотрудников;</li> <li> контролировать результат.</li> </ul> <p>Без этого внедрение почти всегда останавливается на уровне пилота.</p> <h3>Что должен делать руководитель отдела</h3> <p>Успешное внедрение ИИ начинается не с выбора инструмента, а с ответов на несколько базовых вопросов.</p> <p>До запуска пилота руководителю важно определить:</p> <ul> <li> какой бизнес-показатель должен измениться;</li> <li>сколько времени, денег или ресурсов процесс требует сейчас;</li> <li> кто отвечает за итоговый результат;</li> <li> какие данные можно передавать в ИИ, а какие нельзя;</li> <li> какой бюджет компания готова потратить на эксперимент.</li> </ul> <p>После пилота появляются другие вопросы:</p> <ul> <li> изменился ли KPI;</li> <li> появился ли экономический эффект;</li> <li> куда направить высвобожденное время сотрудников;</li> <li> масштабировать решение, дорабатывать его или отключить.</li> </ul> <p>На практике именно здесь проходит граница между экспериментом и реальным внедрением. Если руководитель не понимает, что должно измениться после автоматизации, пилот почти гарантированно останется красивой демонстрацией возможностей технологии.</p> <h3>Теневой ИИ: самый опасный сценарий</h3> <p>Когда руководители процессов не вовлечены во внедрение искусственного интеллекта, сотрудники берут ситуацию в свои руки — и на сцену выходит теневой ИИ.</p> <p>Это значит, что команда сама покупает инструменты и использует открытые модели, загружает туда корпоративные данные, не заботясь о том, нарушает ли при этом NDA, и автоматизирует процессы. Но автоматизирует хаотично, как попало — и может генерировать при этом расходы, которые никто не контролирует.</p> <p>В результате компания перестает понимать сразу несколько вещей:</p> <ul> <li> где именно используется ИИ;</li> <li> какие данные попадают во внешние сервисы;</li> <li> сколько денег тратится на модели и токены;</li> <li> какой эффект дают эти расходы.</li> </ul> <p>Известны случаи, когда руководство выдавало доступ к новым инструментам без ограничений, а спустя несколько недель обнаруживало счета на тысячи долларов за использование моделей. При этом никто не мог ответить, какой бизнес-результат был получен за эти деньги.</p> <p>Именно поэтому без владельца ИИ не становится технологическим преимуществом бизнеса. Он просто сеет хаос. Использование системы должно быть управляемым и прозрачным.</p> <h3>Почему ИИ требует от руководителей новых навыков</h3> <p>Мидл-менеджеры умеют поддерживать процессы, мастерски управляют стабильностью, обеспечивают выполнение KPI — но в случае с ИИ этого уже недостаточно. Он требует другого типа управления: change management, или управления изменениями.</p> <p>То есть здесь важна способность экспериментировать, быстро пересобирать процессы, тестировать новые сценарии, адаптировать команду под новые инструменты. Нужно уметь работать в условиях неопределенности, а это не каждому по силам.</p> <p>Сейчас конкуренция компаний заключается не только в том, у кого «круче технология». Бизнесу важно и то, насколько быстро и легко мидл-менеджмент приспосабливается к переменам.</p> <h3>Итог: почему судьба внедрения решается именно на уровне мидл-менеджмента</h3> <p>На практике все упирается в простую вещь: эффективность компании складывается из эффективности отдельных подразделений.</p> <p>Не нужно быть «в десять раз лучше рынка». Достаточно, чтобы каждый отдел работал хоть на 10% эффективнее конкурентов — быстрее обрабатывал заявки, точнее работал с тендерами, дешевле привлекал лиды, быстрее выпускал продукт.</p> <p>ИИ — как раз инструмент такого усиления, и с его внедрением роль мидл-менеджмента меняется. Если раньше руководитель процесса в значительной степени выступал координатором и контролером исполнения, то теперь ему все чаще приходится становиться архитектором изменений. Понимать, какие задачи должны выполнять люди, какие можно передать ИИ, как измерять эффект и куда направлять высвобожденный ресурс.</p> <p>В конечном счете искусственный интеллект привел к тому, что мир меняется намного быстрее, и все больше компаний переходят к change management. Теперь недостаточно поддерживать привычный порядок вещей — нужно уметь перестраивать его под новые инструменты.</p> <p>#IMAGE_235053#</p> Компании продолжают массово внедрять искусственный интеллект. По данным Gartner, к 2028 году агентный ИИ будет … article Алексей Феофанов, директор по развитию бизнеса Umbrella IT https://www.itweek.ru/themes/detail.php?ID=235048 Mon, 22 Jun 2026 13:51:28 +0300 <p>Российский рынок облачных сервисов продолжает расти, однако драйверы этого роста заметно меняются. Если еще несколько лет назад компании переходили в облако ради скорости запуска сервисов или отказа от части капитальных затрат, то сегодня ключевым фактором становится стремление бизнеса обеспечить предсказуемость развития ИТ-инфраструктуры в условиях роста стоимости оборудования и сохраняющейся неопределенности на рынке поставок, отмечают эксперты компании DataSpace Cloud.</p> <p>По оценкам компании, до конца 2026 года спрос на облачные решения продолжит увеличиваться. При этом меняется не только структура проектов, но и сама роль облака в ИТ-стратегиях компаний.</p> <h3> Тренд 1. Удорожание инфраструктуры меняет экономику ИТ-проектов</h3> <p>Одним из наиболее заметных событий на рынке в конце 2025 — начале 2026 года стало резкое подорожание оперативной памяти. По отдельным позициям рост цен достигал нескольких сотен процентов. Вслед за памятью выросли цены на серверы, системы хранения данных и другие элементы серверной инфраструктуры.</p> <p>В результате многие компании столкнулись с необходимостью пересматривать ранее утвержденные бюджеты и финансовые модели. Проекты, которые изначально предполагали закупку оборудования в собственность, все чаще трансформируются в сервисную модель потребления ресурсов через облако.</p> <h3>Тренд 2. На первый план выходит прогнозируемость</h3> <p>Дополнительное давление на инфраструктурные проекты продолжают оказывать сложности с поставками оборудования. Несмотря на адаптацию рынка к новым условиям, сроки поставок остаются значительными, а параллельный импорт не всегда позволяет гарантировать получение необходимого оборудования в требуемые сроки.</p> <p>В такой ситуации компаниям становится сложно планировать модернизацию инфраструктуры на несколько лет вперед. Облако позволяет снять значительную часть этих рисков, обеспечивая доступ к необходимым ресурсам без зависимости от закупочных циклов, логистики и наличия оборудования на рынке.</p> <h3>Тренд 3. Меняется подход к оценке эффективности облака</h3> <p>Одновременно меняются и критерии, по которым компании оценивают эффективность облачных сервисов.</p> <p>Сегодня высокий SLA, отказоустойчивая инфраструктура, сертифицированные дата-центры уровня Tier III, резервирование инженерных систем, возможности масштабирования и современные технологические стеки уже перестали быть факторами выбора. Для корпоративных заказчиков это базовая гигиена облачного провайдера. Именно поэтому критерии оценки смещаются из технологической плоскости в экономическую: компании анализируют влияние облака на CAPEX, скорость вывода новых сервисов на рынок (time-to-market), устойчивость бизнес-процессов и способность снижать инфраструктурные риски.</p> <p>В собственном контуре компаний остаются legacy-системы, проприетарные базы данных и критически важные приложения с жесткими требованиями к задержкам. В облако, напротив, переносятся веб-приложения, CRM, корпоративные сервисы, среды разработки и тестирования, аналитические платформы, AI/ML-нагрузки и системы обработки данных. </p> <p>«Облачная стратегия в 2026 году строится на прагматичном распределении нагрузок: большинство систем и данных мигрирует в облако, а в собственной инфраструктуре остается только то, что невозможно или нецелесообразно переносить. Аргумент „данные слишком чувствительны для облака“ утратил силу — провайдеры предлагают аттестованные контуры для персональных данных <nobr>(152-ФЗ),</nobr> сертифицированные платформы для банков (PCI DSS, ГОСТ <nobr>57580-1)</nobr> и отраслевые compliance-решения, что снимает регуляторные барьеры для миграции», — отметил Алексей Макаркин, директор по продукту DataSpace Cloud.</p> <p>По его мнению, до конца года рынок продолжит движение от модели владения инфраструктурой к модели потребления сервисов. </p> Российский рынок облачных сервисов продолжает расти, однако драйверы этого роста заметно меняются. Если еще несколько лет назад … message https://www.itweek.ru/themes/detail.php?ID=235047 Mon, 22 Jun 2026 13:50:33 +0300 <p>Холдинг «Росэл» Госкорпорации Ростех проапгрейдил коммерческую платформу виртуализации ECP VeiL, усилив ее киберустойчивость при помощи новых опций. Ранее такие механизмы защиты были доступны только в версии ECP VeiL SE для госкомпаний, ведомств и предприятий ОПК. Обновленная платформа в условиях роста уровня киберугроз позволит организовать цифровую защиту малому и среднему бизнесу.</p> <p>В ECP VeiL версии 5.3.0 внедрена доверенная загрузка виртуальных машин. Решение не позволяет запустить удаленное рабочее место, если его конфигурация, файлы или компоненты были изменены несанкционированно. Это защищает систему от запуска уязвимых или вредоносных компонентов. </p> <p>Обновленная платформа контролирует физические серверы. Она не позволяет изменять важные системные файлы и программную среду. При возникновении угрозы система может принудительно отключить всех пользователей. Также платформа централизованно проверяет запуск приложений и выполнение команд. Любые подозрительные действия автоматически блокируются. Снять блок и разрешить выполнение может только администратор.</p> <p>В новой версии также оптимизированы алгоритмы балансировки нагрузки. Теперь система переносит виртуальные машины с перегруженных узлов на свободные. Это обеспечивает стабильную работу сервисов в часы пик и более эффективное использование серверных мощностей. Кроме того, усилена отказоустойчивость — улучшен механизм переключения ролей контроллеров при авариях. Это снижает риски простоя и гарантирует непрерывность работы даже в нештатных ситуациях.</p> <p>Платформа VeiL — разработка научно-исследовательского института «Масштаб» (входит в «Росэл»).</p> <p>«Ранее механизмы доверенной загрузки виртуальных машин, контроля целостности узлов виртуализации и обеспечения защищенной программной среды были доступны только пользователям ECP VeiL SE. Среди них — госкомпании, ведомства, предприятия ОПК и другие организации, которые в силу закона должны соответствовать строгим требованиям регуляторов в сфере информационной безопасности. Однако сегодняшний уровень киберугроз настолько велик, что мы посчитали необходимым адаптировать наши решения и под коммерческую версию VeiL. Теперь представители малого и среднего бизнеса смогут построить в своих компаниях действительно доверенную виртуальную инфраструктуру», — прокомментировал генеральный директор НИИ «Масштаб» Антон Балицкий.</p> <p>ЕСР VeiL предназначена для создания виртуализованной инфраструктуры на базе универсальных серверных платформ с архитектурой х86-64. На виртуальных машинах ЕСР VeiL могут функционировать практически все распространенные бизнес-приложения, включая межсетевые экраны, маршрутизаторы, IP-АТС, почтовые и прокси-серверы, корпоративные порталы, веб-сайты, ERP, CRM и системы документооборота.</p> Холдинг «Росэл» Госкорпорации Ростех проапгрейдил коммерческую платформу виртуализации ECP VeiL, усилив ее киберустойчивость … message https://www.itweek.ru/themes/detail.php?ID=235046 Mon, 22 Jun 2026 09:32:36 +0300 <p><em>По мере того, как кодирование с помощью искусственного интеллекта переходит от промптов к циклам, верификация становится главной задачей для нативно-облачных команд разработчиков, пишет на портале </em><em>The</em> <em>New</em> <em>Stack</em> <em>Арджун Айер, генеральный директор Signadot.</em></p> <p>Недавно в дискуссии об ИИ-кодировании произошли перемены. Спор больше не о том, могут ли агенты писать производственный код или какая модель лучше. Он теперь о том, кто или что должен им подсказывать.</p> <p>Теперь на слуху идея «проектировать циклы, которые выдают промпты вашим агентам». Становится ясно: формируется третья эра агентной разработки, и она поднимает важные вопросы о том, что делают инженеры, каковы затраты на доставку ПО и какая инфраструктура должна ее обеспечивать.</p> <p>Для команд, создающих нативно-облачные приложения на Kubernetes, ответы на эти три вопроса вскоре будут иметь огромное значение.</p> <h3>Три эры, одно направление</h3> <p>Агентная разработка на каждом этапе эволюции продвигает человека на один уровень абстракции вверх.</p> <p>Первая эпоха была ориентирована на промпты. Разработчик находился внутри цикла, набирая инструкции, читая вывод, внося исправления. Пропускная способность ограничивалась вниманием одного разработчика.</p> <p>Вторая эпоха ориентирована на спецификации, и именно на этом этапе сегодня находится большинство команд, внедряющих подобные подходы. Разработчик инвестирует на начальном этапе: подробные спецификации, контекстные документы, соглашения, закодированные в репозитории. Агент выполняет действия в соответствии со спецификацией, а человек проверяет выполненную работу. Единица работы выросла из промпта в задачу.</p> <p>Третья эпоха делает сам цикл единицей работы. Цикл — это небольшая программа, которая выдает агенту промпт, оценивает ответ, решает, достигнута ли цель, и, если нет, снова выдает промпт, используя полученные данные. Она работает по расписанию, а не зависит от внимания человека. Циклы запускают другие циклы.</p> <p>Разработчик больше не пишет код и все чаще не пишет задачи. Он пишет систему, которая генерирует, оценивает и повторяет работу.</p> <p>Скептики называют это «cron job (индивидуальное задание, которое выполняется согласно заданному расписанию) с улучшенным маркетингом», и это сравнение полезно для понимания того, где здесь возникают проблемы. Cron job выполняет фиксированный скрипт. В цикле же присутствует лицо, принимающее решения: модель, которая считывает состояние работы и выбирает следующее действие. Инженерная задача состоит в том, чтобы всё, что окружает это решение, сходилось к правильному результату, а не блуждало.</p> <h3>Кем становится разработчик</h3> <p>В мире, управляемом промптами, сила разработчика заключалась в умении управлять процессом. В мире, управляемом спецификациями, она заключается в ясности намерений.</p> <p>В мире, управляемом циклами, сила — в качестве системы, окружающей агента. Важный инженерный вопрос сводится к следующему: что проверяет этот цикл, прежде чем объявить об успехе? Какую обратную связь он получает при сбое? Когда он останавливается?</p> <p>Эти вопросы разделяют инженерную роль на две части. Разработчики приложений становятся авторами намерений и циклов: они решают, что создавать, и кодируют цель. Платформенные инженеры становятся владельцами того, что означает «сделано».</p> <p>Проверки, выполняемые циклом, среды, в которых он выполняется, бюджет, в рамках которого он работает, и доказательства, прилагаемые к его результатам, — все это должно быть согласовано во всех циклах в организации, а не импровизироваться каждым из них.</p> <p>Это знакомая схема, но с новой темой. Десять лет назад платформенные команды превратили CI/CD из чего-то, что каждая команда создавала на скорую руку, в мощеную дорогу. Уровень верификации для агентных циклов — это тот же переход, за исключением того, что он находится во внутреннем цикле, до появления каких-либо запросов на изменения (PR), независимо от параллелизма, который генерируют циклы.</p> <h3>Экономика: циклы сходятся или сгорают</h3> <p>Заманчиво предположить, что агенты сделали генерацию кода дешевой, поэтому все это не имеет значения. Это не совсем так.</p> <p>Благодаря агентам генерация стала быстрой и дешевле, чем затраты на рабочее время разработчиков, но токены — это реальная и растущая статья расходов. Работа агента в течение нескольких часов — это решение о расходах, а цикл — это бесконечная работа агента по задумке. Бюджеты, сохранившиеся после интерактивных сессий, не обязательно сохранятся после циклов.</p> <p>Первоочередная мера реагирования — это ограничители: лимиты итераций, обнаружение отсутствия прогресса и потолки затрат. Они необходимы, но они только ограничивают ущерб от неэффективного цикла. Они не делают его эффективным.</p> <p>Эффективность цикла сводится к двум измерениям, и они перемножаются.</p> <p>Первое — это качество обратной связи, которое определяет, сколько итераций требуется циклу. Цикл, получающий нечеткий сигнал об ошибке, пытается угадать причину и делает это снова. Цикл, получающий реальную ошибку от реальной системы с достаточным контекстом для локализации причины, исправляет фактическую проблему и переходит к следующему шагу. Качество обратной связи также определяет то, насколько правильным может быть цикл: он может сходиться только к тому, что видит его обратная связь.</p> <p>Второе — это момент завершения цикла, который определяет стоимость каждой итерации. Если цикл завершается в CI или после PR, каждый цикл оплачивает выполнение конвейера плюс время ожидания в очереди, а частота выполнения составляет от минут до часов. Если же завершение происходит во внутреннем цикле, то при условии прямого доступа агента к среде выполнения частота составляет секунды.</p> <p>Общая стоимость цикла — это произведение: количество итераций до проверки, умноженное на стоимость одной итерации.</p> <p>Эти измерения также подпитывают друг друга. Если передавать достоверную обратную связь в CI, каждый цикл замедляется, пока агент обрабатывает частичные сигналы между ними. Если же включить её во внутренний цикл, то оба параметра сжимаются одновременно.</p> <h3>Нативные облачные системы поднимают планку качества «сделано»</h3> <p>Для изолированной программы оба измерения практически бесплатны. Набор тестов выполняется локально за секунды и сообщает всю правду, потому что вся правда локальна.</p> <p>В распределенной системе правда не локальна. Изменение считается правильным или неправильным в зависимости от того, как оно взаимодействует с вызываемыми им сервисами, хранилищами данных и очередями, которые оно затрагивает, а также уровнями маршрутизации и политик, под которыми оно работает.</p> <p>Обратная связь, которую агент может получить быстро, — локальные тесты и заглушки — является частичной. Обратная связь, которая сообщает правду, традиционно находится в CI и общей среде тестирования, где циклы медленные и конфликтные. Нативно-облачные команды вынуждены выбирать между быстрым циклом, который сходится к неправильной цели, и циклом, содержащим достоверную информацию, который итерируется со скоростью конвейера.</p> <p>Традиционные варианты окружения неэффективны в масштабе агентов. Здесь важно следующее: в нативно-облачных системах обратная связь цикла должна поступать из среды выполнения, и эта среда должна быть доступна из внутреннего цикла. Архитектура нативно-облачного агентного цикла — это, по большей части, архитектура поверхности проверки, которую вы ему предоставляете.</p> <h3>Четыре уровня нативно-облачного агентного цикла</h3> <p>Полная система имеет четыре уровня. Сам цикл — это самая маленькая часть.</p> <p><strong>Уровень среды выполнения.</strong> Циклу требуется среда для каждой итерации, которая ведет себя как производственная среда, но не требует таких же затрат. Решение — легковесные временные среды на общем кластере: развертывайте только те сервисы, которые затрагиваются изменением, и используйте маршрутизацию запросов на одном общем кластере, чтобы направлять трафик цикла через них и через общую базовую конфигурацию для всего остального.</p> <p>Среды материализуются за секунды, предельные затраты отслеживают измененные поды, а не весь стек, и обратная связь поступает из реальных зависимостей и реальных путей передачи данных. Именно это приводит к завершению цикла во внутренний цикл.</p> <p><strong>Интерфейс проверки.</strong> Агенты не просматривают панели мониторинга и не должны придумывать собственное определение завершения. Проверки, которые должно пройти изменение, должны быть частью декларативных рабочих процессов, которые платформенные команды определяют, версионируют и предоставляют агентам в качестве утвержденного способа подтверждения изменения.</p> <p>Организация, а не агент, решает, что означает «прохождение». Доказательства, связанные с изменением, поступают из процесса, который могут проверять люди, и человеческая проверка может сосредоточиться на намерениях и дизайне.</p> <p><strong>Слой обратной связи.</strong> Это механизм сходимости. Бит «пройдено» или «не пройдено» указывает циклу на необходимость повторной попытки, но не на то, что нужно изменить. Среда выполнения должна возвращать структурированные результаты: какая проверка не удалась, журналы и трассировки, относящиеся к собственным запросам цикла, разница в поведении на границе, которая нарушилась.</p> <p>Каждое увеличение точности обратной связи исключает догадки, а устранение догадок означает устранение затрат.</p> <p><strong>Слой управления.</strong> Бюджеты, потолки итераций, обнаружение отсутствия прогресса и надежная запись того, что было выполнено и доказано в каждом цикле. Это то, что позволяет организации уверенно выполнять множество циклов вместо одного, вызывающего беспокойство.</p> <p>Когда расходы ограничены, а сходимость измеряется, агентная разработка становится возможностью, которую можно планировать, а не неожиданной статьей расходов.</p> <p>«Пишите циклы, а не промпты» — это видимая вершина более масштабного заявления: теперь сила команды заключается в системе проверки, которую используют циклы, а эта система принадлежит организации, предоставляющей платформу.</p> <h3>С чего начать?</h3> <p>Переход к разработке на основе циклов не произойдет в результате какого-то одного решения. Он произойдет в результате сравнения эксперимента одной команды, который быстро сходится, и эксперимента другой, который сжигает квартальный бюджет, создавая изменения, которым никто не доверяет. Разница будет заключаться в четырех уровнях, а не в продуманности циклов.</p> <p>Нативно-облачным командам следует начать с уровня среды выполнения, потому что от него зависит каждый другой уровень. Рабочие процессы верификации имеют смысл только в той мере, в какой и среда, в которой они выполняются, а обратная связь правдива только в той мере, в какой правдива система, которая ее генерирует.</p> <p>Если ваши агенты пишут код быстрее, чем ваша команда может ему доверять, цикл наверняка подскажет вам, какого слоя не хватает.</p> По мере того, как кодирование с помощью искусственного интеллекта переходит от промптов к циклам, верификация … article https://www.itweek.ru/themes/detail.php?ID=235044 Mon, 22 Jun 2026 09:06:30 +0300 <p><em>В современном мире многие чат-боты или голосовые помощники могут не только проконсультировать по какому-то вопросу, но и полноценно записать на прием, вызвать врача на дом или отменить визит. Все это возможно благодаря интеграции с информационной системой. Главная задача интеграции — скрыть внутреннюю сложность </em><em>предметной области</em><em> и выдать сценарию уже готовые, «чистые» данные. Если инженеру или аналитику приходится самому разбирать технические ошибки или сложные форматы, такая интеграция считается слабой и ненадежной.</em> <em>Давайте рассмотрим всё на примере медицинской информационной системы (МИС).</em></p> <h2>Техническая сторона: какими способами программы «общаются» между собой</h2> <p>Выбор способа обмена данными API (Application Programming Interface) — SOAP (Simple Object Access Protocol) или REST (Representational State Transfer) — определяет логику взаимодействия систем. В медицинской среде оба подхода имеют свои области применения, и понимание их специфики важно для создания надежных интерфейсов.</p> <p>Пример использования API в жизни:</p> <ul> <li> <strong>Оплата картой:</strong> сайт использует API банка для проведения платежа.</li> <li><strong>Карты на сайтах:</strong> интеграция карт Google или «Яндекса» на сторонних сайтах.</li> <li><strong>Войти через Google/VK: </strong>использование учетных данных одной системы на другой.</li> </ul> <p>Определение REST и SOAP:</p> <p><strong>REST (Representational State Transfer)</strong> — это архитектурный стиль взаимодействия компонентов распределенных приложений в сети, обычно использующий протокол HTTP (HyperText Transfer Protocol). Он определяет набор правил для обмена данными между клиентом и сервером (например, мобильным приложением и сервером), обеспечивая стандартизированный, гибкий и масштабируемый способ взаимодействия.</p> <p><strong>SOAP (Simple Object Access Protocol)</strong> — это строгий протокол обмена структурированными сообщениями в формате XML (eXtensible Markup Language), используемый для взаимодействия приложений. Он обеспечивает высокую безопасность и надежность, часто применяется в банковских системах и корпоративных сервисах (API), работая поверх HTTP, HTTPS (HyperText Transfer Protocol Secure), SMTP (Simple Mail Transfer Protocol) и других протоколов.</p> <p>Для простого понимания можно использовать аналогии из жизни:</p> <ul> <li> SOAP — это официальное заказное письмо в плотном конверте с кучей печатей и подписей. Чтобы его прочитать и подтвердить получение, нужно соблюсти множество формальностей, что делает процесс медленным и тяжелым.</li> <li> REST — это быстрая записка, СМС или почтовая открытка. Она короткая, легкая и содержит только самую суть, поэтому передается мгновенно.</li> </ul> <p>Давайте сравним оба метода:</p> <table> <tbody> <tr> <th> Параметр сравнения</th> <th> Протокол SOAP (тяжелый)</th> <th> Архитектура REST (легкий)</th> </tr> <tr> <td> <strong>Формат обмена</strong></td> <td> Только сложный код XML</td> <td> Обычно легкий код JSON (JavaScript Object Notation)</td> </tr> <tr> <td> <strong>Гибкость</strong></td> <td> Жесткие правила и структура </td> <td> Высокая, легко адаптировать под нужды </td> </tr> <tr> <td> <strong>Скорость</strong></td> <td> Ниже из-за объема данных </td> <td> Выше за счет компактности</td> </tr> <tr> <td> <strong>Безопасность</strong></td> <td> Высокая, на уровне сообщения</td> <td> На уровне канала связи (стандарт интернета)</td> </tr> </tbody> </table> <h2>API: что такое «хорошо» и что такое «плохо»</h2> <p>Логика работы любого виртуального помощника в медицине обычно состоит из трех этапов: выбор услуги, идентификация пациента и получение услуги (запись или вызов врача на дом). То, как технически реализованы эти этапы, определяет, будет ли сервис полезен людям.</p> <h3>Чего стоит избегать</h3> <p><strong>«</strong>Плохая» интеграция перекладывает технические проблемы системы на плечи инженера. Это делает сервис нестабильным и сложным в поддержке.</p> <ul> <li> <strong>Низкоуровневые вызовы на этапе выбора услуги</strong><strong>:</strong> когда для одного простого действия боту нужно вызвать десять разных методов. Логика при этом запутывается. При такой долгой загрузке человек чаще всего просто кладет трубку, не дождавшись ответа. Исследования показывают, что если ожидание превышает 5 секунд, большинство пользователей прекращают общение.</li> <li> <strong>Сложные форматы данных:</strong> получение данных в виде «матрешки» (один код внутри другого). Сценарий не должен заниматься очисткой служебных таблиц с описанием типов и технического шума. Работа с такими данными заметно снижает долю успешно завершенных заявок.</li> <li> <strong>Сырые данные при идентификации:</strong> передача пустых полей или дат в техническом формате. Если процесс подтверждения личности затягивается из-за технических заминок, вероятность того, что человек завершит звонок, вырастает в разы.</li> <li><strong>Чрезмерная сложность для </strong><strong>медучреждения</strong><strong>:</strong> иногда системы настолько запутаны, что сами медучреждения не понимают, как правильно заводить в них врачей или услуги. Это ведет к тому, что в справочниках появляются дубли и ошибки, которые не должны исправляться в сценарии робота.</li> </ul> <h3>К чему нужно стремиться</h3> <p><strong>«</strong>Хорошая» интеграция работает по принципу «одной кнопки»: сценарий просит выполнить действие и получает понятный результат. Это позволяет почти каждому обратившемуся успешно получить услугу.</p> <ul> <li> <strong>Умный выбор услуги через параметры:</strong> сервис будет работать гораздо лучше, если вместо цепочки из десяти запросов использовать получение информации через несколько запросов с четкими параметрами.<br/> Пример<em>:</em> вместо того чтобы сначала просить список всех специальностей, потом всех врачей, а потом все даты, лучше использовать метод «Получить свободные слоты», передав в него сразу код специальности и нужный диапазон дат. Это сокращает время ожидания, и человек не бросает трубку. </li> <li> <strong>Надежная идентификация:</strong> система должна позволять быстро и однозначно подтвердить личность пациента. Чаще всего это происходит тремя способами: по ФИО и дате рождения, по номеру СНИЛС или по номеру полиса ОМС. Качественная интеграция позволяет боту мгновенно сверить эти данные с базой.</li> <li><strong>Понятные ответы:</strong> на этапе получения услуги система возвращает статус: «Пациент не найден», «Найдено несколько совпадений», «Запись успешно создана». Такие сценарии работают гораздо эффективнее других.</li> <li><strong>Автоматизация рутины:</strong> система сама приводит даты к нужному виду и проверяет обязательные поля.</li> </ul> <h2>Что делать, если в системе не хватает данных</h2> <p>Одной из наиболее коварных ловушек при интеграции является интерпретация отсутствующих данных. Поля в МИС могут быть не заполнены по историческим причинам или из-за особенностей работы конкретного отделения.</p> <p>Интеграционная часть должна выступать в роли «умного фильтра», который оценивает достоверность информации. Например, если для оформления вызова врача на дом требуется адрес, а система возвращает пустую строку, качественный интегратор действует так:</p> <ol> <li><strong>Ищет альтернативы:</strong> пытается получить адрес из истории предыдущих вызовов пациента у себя внутри.</li> <li><strong>Оценивает важность:</strong> проверяет, является ли это поле критическим для данного действия.</li> <li><strong>Запрашивает уточнение:</strong> если данные необходимы, система передает в код информацию чтобы в дальнейшем уточнить ее у пациента.</li> </ol> <p>Такой подход делает работу виртуального помощника надежной. Инженер по интеграции знает: если данные получены, они проверены, а если их нет это реальное отсутствие информации в базе, а не ошибка связи.</p> <h2>Путь пациента: стресс против комфорта</h2> <p>То, как медучреждение настроило методы и справочники в своей системе, напрямую влияет на то, получит ли человек пользу от сервиса.</p> <p><strong>Вариант «</strong><strong>с</strong><strong>тресс».</strong> Организация использует множество мелких методов, а данные в системе заполнены с ошибками (дубли врачей, пустые адреса). Человек хочет записаться, но робот делает <nobr>10-15</nobr> последовательных запросов, после каждого вопроса наступает долгая пауза. При длительной задержке ответа человек просто <strong>кладет трубку</strong>. В итоге бот предлагает время, которое уже занято. Человек остается без записи и разочаровывается в сервисе.</p> <ul> <li> <strong>Для инженера</strong> такая работа превращается в бесконечное «латание дыр» и ручную чистку данных. До <nobr>60-80%</nobr> времени тратится не на развитие сервиса, а на исправление ошибок и попытки понять, почему цепочка запросов оборвалась.</li> <li><strong>Итог:</strong> проект обрастает техническим долгом, становится очень дорогим в обслуживании, а любые изменения в МИС приводят к полной остановке сервиса.</li> </ul> <p><strong>Вариант «</strong><strong>к</strong><strong>омфорт».</strong> Организация настроила получение информации посредством нескольких запросов с параметрами.</p> <ul> <li><strong>Выбор услуги</strong><strong>.</strong> Человек говорит: «Запиши к терапевту на завтра». Система мгновенно находит доступные варианты.</li> <li><strong>Идентификация</strong><strong>.</strong> Робот быстро находит пациента по ФИО, СНИЛС или ОМС.</li> <li><strong>Получение услуги</strong><strong>.</strong> Бот предлагает время: «Есть на 10:00 и 11:30. Какое выбрать?». После ответа запись подтверждается мгновенно. Человек быстро и четко записывается к врачу, он доволен, а медицинская организация получила запись без лишних усилий персонала. В медицине такая скорость работы значительно увеличивает количество реальных визитов граждан к врачам.</li> <li> <strong>Инженер</strong> в такой системе работает с готовыми и надежными блоками данных. Это позволяет внедрять новые функции (например, автоматические опросы о качестве обслуживания) за считанные часы, а не недели.</li> <li><strong>Итог:</strong> создается масштабируемая система с низкими затратами на поддержку, которая стабильно работает и легко растет вместе с потребностями организации.</li> </ul> <h2>Итог правильной интеграции</h2> <p>Сценарий должен работать с понятными человеческими понятиями (врач, время, пациент), а не с техническими деталями базы данных. Качественная интеграция и порядок в данных заказчика это залог того, что ваш сервис будет приносить реальную пользу, а люди будут доверять виртуальным помощникам.</p> <p>И при правильной (хорошей) интеграции конверсия сервисов, например «запись на прием к врачу» или «вызов врача на дом», будет превышать 70%, при «плохой» будет втрое меньше.</p> <p> #IMAGE_235045#</p> В современном мире многие чат-боты или голосовые помощники могут не только проконсультировать по какому-то … article Михаил Гончарук, руководитель проектов департамента голосовых цифровых технологий компании BSS https://www.itweek.ru/themes/detail.php?ID=235043 Fri, 19 Jun 2026 12:52:39 +0300 <p>Институт статистических исследований и экономики знаний (ИСИЭЗ) НИУ ВШЭ на основе данных Росстата проанализировал спрос и предложение навыков работы с технологиями искусственного интеллекта (ИИ) на российском рынке труда.</p> <p>Навыками работы с ИИ так или иначе уже владеют более трети (37,5%) занятого населения в России, при этом мужчины (40%) лишь незначительно опережают женщин (36%) по уровню владения ИИ-компетенциями.</p> <p>Каждый пятый работник (22,7% опрошенных) знаком с технологиями ИИ на базовом уровне, достаточном для работы с чат-ботами, генераторами изображений и другими массовыми ИИ-сервисами через готовые пользовательские интерфейсы. Средний и продвинутый уровни освоены значительно реже: специализированные ИИ-инструменты для решения профессиональных задач используют 11,7% занятых, а навыками создания и сопровождения ИИ-решений обладают лишь 3,2% опрошенных.</p> <p>Базовые ИИ-навыки широко распространены во всех возрастных группах, при этом максимальные показатели <nobr>(46–47%)</nobr> фиксируются среди молодежи <nobr>(15–29 лет),</nobr> а далее падают до 30% и ниже (среди лиц старше 50 лет). Особенно выражен возрастной разрыв для продвинутых компетенций <nobr>(5–6%</nobr> против 2% в указанных группах соответственно).</p> <p>Освоение ИИ-компетенций тесно связано и с уровнем формального образования. Среди работников с высшим образованием доля владеющих ИИ-инструментами достигает 47%, среди обладателей среднего профессионального образования она составляет 33% и опускается до <nobr>27–28%</nobr> среди лиц с более низким уровнем образования. Кадровое ядро ИИ-экономики в значительной степени составляют молодые специалисты, недавно завершившие профильное обучение.</p> <p>Формальная потребность в ИИ-компетенциях пока остается ограниченной: лишь 4,9% работников сообщили о необходимости таких навыков для выполнения своей работы. Это в 7,6 раза меньше доли работников, уже освоивших ИИ-инструменты. С учетом особенностей измерения данный показатель следует рассматривать как нижнюю оценку реального спроса, однако сам масштаб расхождения может указывать на опережающее освоение ИИ-технологий работниками.</p> <p>Востребованность и фактическое распространение ИИ-навыков концентрируются в одних и тех же сегментах экономики: сфере информации и связи, профессиональной и научной деятельности, а также финансовом секторе. Среди профессиональных групп лидируют ИКТ-специалисты, специалисты в области науки и техники и руководители.</p> <p>Между тем ИИ-компетенции все чаще выходят за пределы отраслей и профессий, традиционно связанных с цифровыми технологиями. Высокий уровень владения ИИ-навыками фиксируется в юриспруденции, гуманитарных областях, культуре и государственном управлении. Например, навыками работы с ИИ владеют 41% госслужащих, что может отражать результаты программ цифровой трансформации госсектора.</p> <p>Анализ данных Обследования рабочей силы Росстата за 2025 год указывает на массовое «скрытое» освоение ИИ-навыков работниками, опережающее формальный спрос со стороны работодателей. Кроме того, уже на ранней стадии распространения технологий ИИ прослеживаются контуры цифрового неравенства: если базовый уровень ИИ-навыков характерен для широкого круга работников и доступен без специальной подготовки, то на среднем и продвинутом все отчетливее проявляется влияние факторов образования и возраста.</p> Институт статистических исследований и экономики знаний (ИСИЭЗ) НИУ ВШЭ на основе данных Росстата проанализировал спрос … message https://www.itweek.ru/themes/detail.php?ID=235042 Fri, 19 Jun 2026 09:20:33 +0300 <p><em>Агентный трафик меняет цифровой клиентский опыт, пишет в корпоративном блоге Сэнди Кариелли, вице-президент и главный аналитик </em><em>Forrester</em><em>.</em></p> <p>В отчете «The Forrester Wave: Bot And Agent Trust Management Software, Q2 2026» рассмотрено, как этот сдвиг трансформирует рынок, исторически ориентированный на обнаружение и смягчение атак ботов, в рынок, который также должен обеспечивать доверенный автоматизированный трафик в масштабе.</p> <p>Вот три ключевых вывода, которые подчеркивают происходящие изменения и которые должны учитывать организации.</p> <h3>1. Рынок смещается от «блокировки ботов» к «обеспечению доверенного автоматизированного трафика»</h3> <p>Распространение агентов искусственного интеллекта размывает грань между человеческим и автоматизированным трафиком. Агенты могут представлять собой законных клиентов, деловых партнеров или злоумышленников. Ранее считавшиеся доверенными агенты могут быть использованы для выполнения вредоносных действий.</p> <p>Это создает фундаментальное противоречие: слишком агрессивная блокировка рискует нарушить реальный клиентский опыт, но разрешение неправильного автоматизированного трафика открывает двери для мошенничества и злоупотреблений. В результате рынок эволюционирует от подхода, ориентированного на безопасность, к модели, ориентированной на доверие, которая подчеркивает понимание намерений, различение хорошего и плохого автоматизированного трафика и обеспечение полезной активности агентов при одновременном пресечении вредоносного трафика.</p> <p>Для заказчиков это означает, что приобретаемые ими решения должны выходить за рамки обнаружения и реагирования. Они должны определять, кто или что взаимодействует с их приложениями, почему и как это согласуется с получением бизнес-ценности.</p> <h3>2. Управление доверием к ботам и агентам — это на самом деле межфункциональная бизнес-проблема</h3> <p>Мы годами отмечали, что руководители в области безопасности, борьбы с мошенничеством, электронной коммерции, маркетинга и бизнеса заинтересованы в управлении ботами. С переходом к управлению доверием к ботам и агентам межфункциональное участие становится критически важным. Трафик ботов и агентов влияет на гораздо большее, чем только на команды безопасности. Теперь организациям необходимо координировать действия всех заинтересованных сторон, чтобы определять политики, которые обеспечивают баланс между:</p> <ul> <li>безопасностью и предотвращением мошенничества;</li> <li> клиентским опытом;</li> <li> получением дохода и эффективностью маркетинга.</li> </ul> <p>Например, у разных заинтересованных сторон может быть разное отношение к сбору данных большими языковыми моделями (LLM). Одни будут обеспокоены потенциальной утечкой интеллектуальной собственности и инфраструктурными затратами из-за интенсивного сбора данных. Другие предпочтут разрешить сбор данных определенным LLM, чтобы их бренд и сайт чаще отображались в ответах ИИ и привлекали больше клиентов-людей на сайт. Это также означает, что ПО для управления доверием к ботам и агентам должно интегрироваться в экосистему (включая поставщиков идентификационных данных, платформы электронной коммерции и маркетинговые инструменты) и поддерживать рабочие процессы и панели мониторинга, специфичные для конкретных сценариев использования.</p> <p>Организациям следует рассматривать управление доверием к ботам и агентам как общую дисциплину, а не как точечное решение. Успех здесь зависит от управления, согласованности действий между командами и возможности внедрения политик в различных бизнес-функциях.</p> <h3>3. Аналитика и партнерство с поставщиками — ключевые отличительные черты</h3> <p>Обнаружения ботов уже недостаточно. Организациям все чаще требуется более глубокая аналитика для понимания:</p> <ul> <li> намерений и поведения ботов и агентов, включая того, как агенты связаны с конкретными потребителями-людьми;</li> <li> взаимоотношений между агентами и клиентами и их влияния на то, что агентам должно быть разрешено делать от имени клиентов;</li> <li> шаблонов и целей атак (включая случаи, когда идентифицируемые и одобренные агенты начинают вести себя злонамеренно);</li> <li> измеримого влияния на бизнес и рентабельности инвестиций.</li> </ul> <p>В то же время организации все больше полагаются на вендоров как на стратегических партнеров, а не просто на поставщиков технологий. Постоянное исследование угроз, проактивная поддержка и сотрудничество в настройке моделей и подготовке к крупным событиям имеют решающее значение для поддержания эффективной защиты, особенно в условиях, когда операторы ботов продолжают развивать свои атаки. Например, некоторые поставщики предлагают функции, позволяющие клиентам заблаговременно уведомлять их о предстоящих распродажах.</p> <p>Для организаций это означает необходимость оценивать приобретаемые решения не только с точки зрения обнаружения угроз, но и с точки зрения видимости, объяснимости и партнерства.</p> Агентный трафик меняет цифровой клиентский опыт, пишет в корпоративном блоге Сэнди Кариелли, вице-президент и главный … article https://www.itweek.ru/themes/detail.php?ID=235040 Fri, 19 Jun 2026 09:04:04 +0300 <p>В 2014 году Россия взяла курс на импортозамещение в ИТ-секторе. Поначалу это выглядело как игра в конструктор: собрали в России из иностранных компонентов, вот и локализация. Однако после 2022 года правила резко поменялись. Прятать чужое за своим шильдиком уже нельзя — нужна своя инфраструктура, причем полного цикла.</p> <p>Однако проблема в том, что современное высокотехнологичное устройство — это не просто компоненты, а результат объединенной работы отлаженной цепочки промышленностей: нефтехимической, полупроводниковой, энергетической, машиностроительной и т. д. Другими словами, задача крайне амбициозная и трудно выполнимая.</p> <p>Тем не менее за последние годы отрасль действительно начала меняться. Сформировалась определенная производственная инфраструктура: появились линии поверхностного монтажа, выросли мощности по выпуску компьютеров, ноутбуков, серверов и промышленной электроники, усилилась разработка собственных процессоров. Государство, в свою очередь, старается поддерживать отрасль, так что теперь это крупнейший заказчик отечественной вычислительной техники. Но между «локальной сборкой» и полноценной независимостью все еще огромная технологическая пропасть.</p> <p>Чтобы понять, какие вещи мы уже способны производить самостоятельно, а что останется импортозависимым к <nobr>2027-2030 годам,</nobr> рассмотрим вычислительную технику покомпонентно, начиная от литографического оборудования и материаловедения, заканчивая уже готовыми процессорами, памятью и остальными комплектующими.</p> <h3>Про деньги</h3> <p>Для начала — о финансовых показателях. В 2023 году российский рынок микроэлектроники <a href="https://delprof.ru/press-center/open-analytics/rossiyskiy-rynok-mikroelektroniki-i-komponentov/">показал</a> огромный рост, достигнув порядка 310 млрд. рублей. Положительная тенденция продолжилась и в 2024 году: объем вырос до 370 млрд. Однако в 2025 году произошел прогнозируемый спад, естественное «охлаждение» рынка. Тем не менее, ожидается возврат к умеренной динамике роста. Отраслевые эксперты <a href="https://delprof.ru/press-center/open-analytics/rossiyskiy-rynok-mikroelektroniki-i-komponentov/">предполагают</a>, что к 2030 году объем рынка может увеличиться в диапазоне от 794 млрд. до 1 трлн. рублей.</p> <p>Минпромторг к этому времени <a href="https://www.cnews.ru/news/top/2025-12-15_minpromtorg_posle_nedofinansirovaniya">ожидает</a> до 70% локализации оборудования и материалов за счет разработанной ведомством программы поддержки. Впрочем, часть экспертов относится к этой цели со скепсисом, отмечая критический недостаток финансирования — 240 млрд. рублей. По их оценкам, для реальной независимости от импортных поставок <a href="https://www.cnews.ru/news/top/2025-12-15_minpromtorg_posle_nedofinansirovaniya">требуется</a> около 0,5 трлн. рублей.</p> <p>Так или иначе, сектор развивается, что стало возможным за счет инвестиций в локализацию производства, объемных закупок со стороны государства, строительства новых дата-центров и облачных инфраструктур, а также стабильного роста конвейерных мощностей, с которых сходит отечественная вычислительная техника.</p> <h3>Собираем матплаты, корпусируем чипы</h3> <p>На сегодняшний день ряду российских предприятий удалось существенно продвинуться в импортозамещении. Так, сразу несколько крупных компаний <a href="https://ppt.ru/art/gisp/rossiyskie-materinskie-platy-iz-reestra-minpromtorga">наладили</a> линии монтажа, с которых сходят материнские платы, внесенные в реестр Минпромторга. Пока, правда, это только сборка и реже проектирование: все необходимые компоненты привозят из Китая, туда же иногда отправляются дизайн-проекты, согласно которым там изготавливают продукцию.</p> <p>В Калининграде в год <a href="https://sdelanounas.ru/blogs/170977/">собирается</a> около 200 тыс. модулей оперативной памяти DDR4. Там же <a href="https://www.cnews.ru/news/top/2026-04-13_v_rossii_nachalos_suverennoe">налажен</a> серийный выпуск SPD-чипов. Это важный компонент, хранящий служебную информацию о DDR-модуле, без которой он не сможет запуститься: частота, задержки, рабочее напряжение.</p> <p>На заводе в Йошкар-Оле <a href="https://www.cnews.ru/news/top/2026-04-13_v_rossii_nachalos_suverennoe">выпускают</a> восьмислойные печатные платы формата DIMM. Это предприятие полного цикла, где в том числе делается фольгированный текстолит. При этом платы соответствуют 6 классу точности, то есть почти максимальному.</p> <p>Таким образом в России есть фундамент для производства собственных модулей оперативной памяти, но не хватает главного и самого сложного компонента — непосредственно самих чипов DRAM, которые монтируют на текстолит.</p> <p>Их в мире делают пять гигантов: Samsung, Hynix, Micron, Nanya, CXMT. До появления российских компаний в этом списке еще очень далеко, но маленькие шаги в этом направлении уже есть.</p> <p>Например в Зеленограде <a href="https://www.cnews.ru/news/top/2026-01-16_v_rossii_otkryvayut_novuyu">заработала</a> площадка корпусирования чипов. Мощности рассчитаны на выпуск до 100 000 штук в месяц, а работать на предприятии будут с корпусами PBGA, FC-BGA и HFCBGA. Такие нужны для процессоров в простых бытовых устройствах, системах управления авто, самолетами и кораблями.</p> <p>Помимо Зеленоградского нанотехнологического центра (ЗНТЦ), корпусированием в России занимаются GS Group, «Микрон» и Московский институт электронной техники, но именно ЗНТЦ — самый крупный игрок.</p> <h3>Процессоры, FPGA, микроконтроллеры</h3> <p>Микропроцессоры. Их разработка и производство ведутся в России, но с существенными оговорками. Процесс крайне сложный: надо добыть кварцевый песок, восстановить кремний, очистить его до уровня 9N или 99,9999999%. Затем надо вырастить из него кристалл, разрезать на пластины, отполировать и организовать логистику до «чистой комнаты», причем спроектированной по определенному стандарту <a href="https://www.iso.org/standard/53394.html">ISO 14644</a>. Нужной инфраструктуры для этого пока нет, поэтому кристаллы покупаются за рубежом.</p> <p>Далее начинается этап работы с литографическим оборудованием, но и тут свои подводные камни. В России литографы нужного класса просто отсутствуют. Раньше проблему решали заключая контракты с внешним подрядчиком, например, тайваньским заводом TSMC, но сейчас эта опция заблокирована. Из-за этого <a href="https://habr.com/ru/news/964706/">закрылись</a> проекты «Эльбрус» и Baikal. Классная инженерная школа у нас есть, но к производству готовых изделий мы пока не готовы.</p> <p>Просто купить литографы у ASML, Canon или Nikon тоже нельзя — экспортные ограничения, а производить самостоятельно — сверхзадача: оборудование крайне сложное, поэтому тут нужны опыт и экспертиза, исчисляемые десятками лет. Остается осваивать технологии самостоятельно, но процесс не быстрый, так что только сейчас мы добрались до того, что было доступно Intel, AMD и Nvidia еще в начале <nobr>2000-х.</nobr> Тем не менее отрасль не унывает — разработки и прототипирование ведутся.</p> <ul> <li> Уже есть «Прогресс СТП-350» — российский степпер, <a href="https://russianelectronics.ru/2026-02-02-rossijskij-350-nm-fotolitograf-oczenili-v-500-mln-rublej/">разработанный</a> ЗНТЦ при участии предприятия «Планар» из Беларуси. Устройство рассчитано на <nobr>200-мм</nobr> пластины, использует волну длиной 365 нм и обеспечивает разрешение до 350 нм.</li> <li> Та же ЗНТЦ <a href="https://habr.com/ru/news/1015588/">ведет</a> разработку литографа 130 нм. Завершение работ планируется на конец 2026 года.</li> <li> Литографы есть и на мощностях завода «Микрон». Они могут выпускать интегральные схемы по <nobr>90-нм</nobr> техпроцессу.</li> </ul> <p>Таким образом выпуск процессоров, FPGA и микроконтроллеров в России возможен, но только для специфического оборудования: ракет, самолетов, автомобилей. Им не нужны заоблачные частоты, а надежность и безопасность — да, поэтому наши 90-200-нм чипы здесь подходят отлично. Однако в ноутбук, смартфон или сервер их не поставишь: это прошлый век. Конечно можно заказывать что-то более современное в Китае. Их завод SMIC освоил 7 нм и уже ведет разработки <nobr>3-нм</nobr> кристаллов, но договориться с ним означает вернуться к приклеиваниям шильдика на чужую продукцию, а этот путь не приведет к настоящей независимости.</p> <h3>Пассивные и силовые компоненты</h3> <p>Процессоры, материнские платы и память — это лишь верхушка айсберга. Для полноценно работающего ПК, ноутбука или сервера требуются сотни других, менее технологически сложных элементов, без которых никуда: резисторы, варисторы, конденсаторы, VRM-модули.</p> <p>На территории России такая продукция выпускается предприятиями «Реконд», «Гириконд», «Кулон», «Нюкон» и десятком других, но до западных аналогов еще далеко.</p> <p>Резисторы зачастую имеют большие допуски и невысокую точность, конденсаторы — большие габариты, меньшие емкости и большую паразитную индуктивность, силовые транзисторы — более низкие частоты переключения. Как результат, большинство российских изделий проходит сертификацию по военным и промышленным стандартам, но пока не готово к использованию в серьезной вычислительной технике и передовой потребительской электронике. Главная проблема, однако, заключается в том, что отечественные компоненты в несколько раз дороже аналогичных из Азии, поэтому доля последних в составе электронных устройств для гражданского рынка <a href="https://www.vedomosti.ru/technology/articles/2024/10/03/1066146-rossiiskaya-elektronika-okazalas-zavisimoi-ot-inostrannih-kondensatorov">достигает</a> 90% по отдельным типам.</p> <h3>Заключение</h3> <p>Сегодня часто звучит вопрос: «Когда в России появится собственный современный процессор?». Но это неверная постановка проблемы. Создание конкурентоспособной микроэлектроники начинается не с финального аккорда, то есть процессора, а с выстраивания всей производственной цепочки — от добычи сырья и нефтехимии до машиностроения, приборостроения и высокоточного оборудования.</p> <p>Для реального технологического суверенитета необходимы долгосрочные инвестиции, системная государственная политика и десятилетия последовательной работы. Нужно развивать материаловедение, создавать литографическое оборудование, строить новые производственные линии, готовить инженеров и научные кадры, а также поддерживать исследования, в том числе международные. Это задача не отдельных предприятий, а масштабной промышленной стратегии национального уровня.</p> <p>Ведущие мировые компании шли к нынешнему уровню десятилетиями, формируя вокруг себя огромную экосистему поставщиков, научных центров и производств. Поэтому импортозамещение в микроэлектронике — это не вопрос быстрого выпуска «своего процессора», а длительный процесс формирования полноценной технологической базы страны. Подтверждение тому — попытка президента США Дональда Трампа в 2025 году ограничить поставки электроники из Китая и перенести все производство в США. Благое намерение вызвало перебои поставок и огромные <a href="https://www.computerra.ru/313842/tarifnyj-shok-kak-torgovye-poshliny-ssha-unichtozhayut-it-industriyu/">скачки</a> цен.</p> <p>Возвращаясь к России: мы уже достигли немалых результатов. Появились мощности по сборке вычислительной техники, производству печатных плат, корпусированию микросхем и выпуску отдельных компонентов. Развиваются проекты собственных литографов и микропроцессоров, а государство продолжает стимулировать отрасль через закупки и программы поддержки. Формируется фундамент для дальнейшего развития, а значит, и реальное импортозамещение становится все ближе.</p> <p>#IMAGE_235041#</p> В 2014 году Россия взяла курс на импортозамещение в ИТ-секторе. Поначалу это выглядело как игра … article Андрей Ильичёв, руководитель департамента продуктовых решений “Инферит Техника” (кластер “СФ Тех” ГК Softline) https://www.itweek.ru/themes/detail.php?ID=235037 Thu, 18 Jun 2026 18:00:55 +0300 <p>Российский облачный рынок продолжает расти. По оценке M1Cloud, по итогам 2025 года его объем оценивался примерно в 400 млрд рублей, а в 2026 году рынок может сохранить темпы роста не ниже 30%. На этом фоне рынок труда в ИТ перестраивается: в марте 2026 года количество активных вакансий в профобласти «Информационные технологии» на hh.ru снизилось на 37% год к году, тогда как число активных резюме выросло на 29%. Массовый найм стал осторожнее, но спрос на специалистов, которые помогают бизнесу переносить критичные системы в облака, внедрять ИИ, управлять затратами и защищать инфраструктуру, сохраняется.</p> <p>Дмитрий Соловьёв, технический директор M1Cloud, рассказал, что в 2026 году рынку нужны не просто администраторы виртуальных машин: заказчики ждут от провайдера экспертизу на стыке инфраструктуры, ИИ, безопасности и экономики облака, а также объяснил, почему облачные команды будут конкурировать за специалистов, которые умеют превращать сложные технологические платформы в управляемый, безопасный и экономически понятный сервис для бизнеса.</p> <p>Спрос на кадры, связанные с ИИ, растет быстрее среднего по рынку. По данным hh.ru, в 2025 году количество вакансий для <nobr>ML-инженеров</nobr> выросло со 135 до 396, для AI-инженеров — со 164 до 290. Для облачного рынка это означает рост запросов на GPUaaS: бизнесу нужны ресурсы для обучения моделей, но покупка и эксплуатация GPU-оборудования на собственной площадке часто экономически нецелесообразна. Поэтому провайдерам нужны инженеры, которые проектируют и администрируют GPU-кластеры, настраивают сетевую инфраструктуру и системы хранения под высокую нагрузку, управляют контейнерными средами, MLOps-инструментами и интеграцией ИИ-сервисов в инфраструктуру заказчиков.</p> <p>Рост облачных бюджетов требует управления стоимостью, а не только контроля счета. В неуправляемых средах часть расходов возникает из-за простаивающих ресурсов, избыточно выбранных конфигураций, дублирования сервисов и отсутствия правил потребления. FinOps объединяет финансы, ИТ и бизнес-команды: специалисты анализируют потребление, распределяют затраты по проектам, помогают выбирать модели потребления и резервирования ресурсов, выстраивают бюджетирование и прогнозирование. По данным State of FinOps 2026, практика вышла за пределы публичного облака: 90% FinOps-команд управляют или планируют управлять SaaS-расходами, 57% — частными облаками, а 98% уже работают с затратами на ИИ.</p> <p>В условиях дефицита кадров компании переносят инфраструктуру в облака, но скорость разработки зависит не только от аренды ресурсов. Командам нужны внутренние платформы разработчика (Internal Developer Platforms), которые позволяют быстро и безопасно разворачивать приложения, базы данных, окружения тестирования и мониторинг без постоянного участия инфраструктурных инженеров. Platform Engineering развивается как практическое продолжение DevOps: эти специалисты создают self-service инструменты, стандартизируют шаблоны инфраструктуры, автоматизируют CI/CD, интегрируют Kubernetes, IaC и инструменты наблюдаемости (observability). В результате бизнес быстрее выводит продукты на рынок, а эксплуатационные команды меньше времени тратят на типовые запросы.</p> <p>Миграция критичных систем и ИИ-нагрузок в облака меняет профиль рисков. Наряду с классическими задачами — сегментацией сети, управлением доступами, шифрованием, резервным копированием и соответствием требованиям регуляторов — растет значение защиты контейнерных сред, API, пайплайнов данных и моделей машинного обучения. По прогнозу Sk Capital и «Кода Безопасности», сегмент облачной кибербезопасности в России может вырасти с 7 млрд рублей в 2024 году до 32 млрд рублей к 2028 году. Поэтому будут востребованы специалисты, которые понимают и ИБ, и устройство облачной инфраструктуры: умеют выстраивать zero trust, защищать CI/CD и Kubernetes, контролировать доступ к данным для обучения моделей, снижать риски утечек через API и работать с угрозами для <nobr>ML-систем,</nobr> включая adversarial-атаки.</p> <p>Чем сложнее облачная инфраструктура, тем труднее управлять ею вручную. Виртуальные машины, контейнеры, микросервисы, сетевые компоненты и хранилища генерируют большой поток метрик, логов и событий. AIOps (Artificial Intelligence for IT Operations) применяет машинное обучение для мониторинга, корреляции событий, обнаружения аномалий, прогноза инцидентов и автоматического масштабирования ресурсов. Такие специалисты помогают сократить время реакции на инциденты, снижать количество ложных срабатываний и находить причины проблем до того, как они затронут пользователей. В ближайшие <nobr>2–3</nobr> года спрос на AIOps-компетенции в России будет расти вслед за усложнением облачных сред, распространением Kubernetes, мультиоблачных архитектур и ИИ-нагрузок.</p> Российский облачный рынок продолжает расти. По оценке M1Cloud, по итогам 2025 года его объем оценивался примерно … message https://www.itweek.ru/themes/detail.php?ID=235035 Thu, 18 Jun 2026 17:59:53 +0300 <p>Институт статистических исследований и экономики знаний (ИСИЭЗ) НИУ ВШЭ проанализировал ключевые тренды публикационной активности ученых в области цифровой трансформации. Результаты анализа свидетельствуют о том, что цифровизация стала одним из ключевых факторов конкурентоспособности компаний и приоритетом для науки.</p> <p>Эмпирической базой исследования послужил массив публикаций в изданиях, индексируемых в базе данных Scopus, за <nobr>2010–2025 гг.</nobr> (182,4 тыс. по миру в целом, 4,5 тыс. в России). В указанный массив попали публикации во всех предметных областях, в заголовке и/или аннотации и/ или ключевых словах которых встречается хотя бы один из терминов, связанных с цифровой трансформацией бизнеса. Анализ публикационной активности — одна из задач Мониторинга цифровой трансформации бизнеса, проводимого ИСИЭЗ НИУ ВШЭ с 2023 г.</p> <p>Цифровая трансформация бизнеса и общества за десятилетие превратилась из нишевой темы в одно из наиболее быстрорастущих направлений российской исследовательской повестки. Интерес к этой области усилился на фоне пандемии: в 2021 г. вклад страны в мировой массив публикаций по данной тематике достигал 4,5%, а число профильных научных работ выросло более чем в 50 раз по сравнению с началом <nobr>2010-х</nobr> годов. Ввиду внешних факторов в 2024 г. доля страны упала до 1,9%. Тем не менее Россия занимает <nobr>12-е</nobr> место по числу исследований цифровой трансформации бизнеса (согласно расчетам на массиве публикаций в Scopus за <nobr>2022–2024 гг.).</nobr> Потенциал для повышения глобальной видимости исследований создает научная кооперация: доля публикаций с зарубежными соавторами за пять лет <nobr>(2019–2024 гг.)</nobr> выросла почти вдвое.</p> <p>Мировая повестка исследований в области цифровой трансформации остается устойчивой, однако меняются технологии, определяющие ее развитие. Анализ частоты упоминания ключевых слов в научных публикациях за последние <nobr>8–10</nobr> лет показывает, что при сохранении интереса к цифровизации в широком смысле, вопросам принятия решений и развитию Индустрии 4.0, все более заметную роль играют искусственный интеллект, машинное обучение, Интернет вещей, робототехника, умное производство и концепция Индустрии 5.0.</p> <p>Российская исследовательская повестка в области цифровой трансформации встроена в глобальные тренды и одновременно ориентирована на национальные приоритеты. Так, четыре из пяти ключевых тем (киберфизические системы в Индустрии 4.0, модели цифровой трансформации, цифровые двойники в киберфизических системах, цифровые компетенции в образовании) освещаются и в зарубежных исследованиях, и в России. Мониторинг ИСИЭЗ НИУ ВШЭ показывает, что все больше российских компаний включаются в цифровую трансформацию, внедряя продвинутые ИТ-решения. Научная повестка следует тому же тренду — от описания отдельных технологий к анализу полной перестройки бизнес-процессов и моделей.</p> <p>Исследования цифровой трансформации становятся все более междисциплинарными, объединяя управление, технологии и экономику. Повестку исследований задают отрасли-лидеры цифровизации: большинство российских работ посвящено опыту финансового сектора, ИКТ и телекоммуникаций, где цифровая трансформация развивается наиболее активно; тогда как малый бизнес и традиционные отрасли значительно реже попадают в фокус внимания.</p> <p>Научные приоритеты и бизнес-запросы идут в России параллельными курсами, без ощутимой синергии. Расширяется круг университетов и исследовательских центров, специализирующихся на исследованиях цифровой трансформации. При этом если в мире ведущую роль в исследованиях по этой теме играют инженерно-технические вузы, то в России — преимущественно многопрофильные, прежде всего социально-экономические, университеты. В результате исследования больше сфокусированы на бизнес-эффектах применения технологий, а не на их разработке.</p> Институт статистических исследований и экономики знаний (ИСИЭЗ) НИУ ВШЭ проанализировал ключевые тренды публикационной … message https://www.itweek.ru/themes/detail.php?ID=235034 Thu, 18 Jun 2026 13:53:45 +0300 <p>Российский разработчик ПО СберТех развивает функциональность своей СУБД Platform V Pangolin DB, внедряя возможности по использованию искусственного интеллекта (AI). Продукт получил расширение PGVector, позволяющее хранить и обрабатывать данные в векторном представлении, что является необходимым условием для работы генеративных моделей AI. Благодаря этому российские компании смогут на базе СУБД запускать семантический поиск, рекомендательные сервисы и собственных AI-агентов.</p> <p>Максим Тятюшев, генеральный директор СберТеха, отметил: «Мы видим растущий спрос бизнеса на инструменты, которые позволяют эффективно работать с данными, в том числе за счет возможностей AI. Теперь клиенты, использующие нашу СУБД, могут строить сервисы на базе искусственного интеллекта без привлечения дополнительных программных продуктов. Новая функциональность поможет компаниям ускорить внедрение AI-решений, повысить точность персонализированных рекомендаций, улучшить качество ответов интеллектуальных ассистентов и технической поддержки».</p> <p>Расширение PGVector позволяет реализовать векторный поиск по большим объемам неструктурированной информации: текстам, изображениям, аудио и видео. Благодаря этому большие языковые модели могут находить релевантную информацию в базах данных и формировать ответы на запросы пользователей. СберТех не просто интегрировал эту технологию в свою СУБД, но и адаптировал работу расширения к корпоративным требованиям надежности, производительности и безопасности.</p> <p>Platform V Pangolin DB — реляционная система управления базами данных (СУБД), полностью совместимая с PostgreSQL. Продукт содержит ряд важных доработок, которые позволяют использовать его в масштабах корпораций, и уже доказал свою эффективность эксплуатации в ряде крупнейших компаний России. Десятки тысяч инсталляций Platform V Pangolin DB успешно работают в составе сервисов и приложений различного уровня масштаба и критичности.</p> Российский разработчик ПО СберТех развивает функциональность своей СУБД Platform V Pangolin DB, внедряя … message https://www.itweek.ru/themes/detail.php?ID=235033 Thu, 18 Jun 2026 11:32:20 +0300 <p>Более 80% компаний среди крупного и среднего бизнеса допускают критичные ошибки в работе с корпоративными знаниями. Это приводит к увеличению нагрузки на сотрудников и становится стоп-фактором при внедрении ИИ-ассистентов, следует из результатов проведенных Minervasoft аудитов.</p> <p>В ряде случаев бизнес формально подходит к внедрению систем управления знаниями: решает исключительно технические задачи и не уделяет достаточно внимания культуре и процессам работы со знаниями. В результате компания получает статичный инструмент без возможности масштабирования, а сотрудники продолжают работать по памяти или обращаться к коллегам. </p> <p>Еще один барьер при внедрении ИИ-ассистентов — низкое качество контента внутри базы знаний. Сотрудники работают с объемными документами, непонятными статьями и устаревшими инструкциями. Это приводит к увеличению числа ошибок, удлиняет время поиска информации и снижает доверие к платформе.</p> <p>Третья ошибка — функционал платформы не соответствует реальным задачам бизнеса. Например, нет гибкого разграничения доступа или возможности использовать базу как единый источник для разных каналов обслуживания. Это не позволяет системно работать со знаниями и поддерживать единые стандарты в разных подразделениях и регионах.</p> <p>Четвертая — отсутствие реальных KPI и прозрачной аналитики. Без отчетности компания не видит, как база знаний влияет на скорость поиска информации, количество ошибок и качество обслуживания. В итоге знания размещаются формально, а система со временем перестает развиваться.</p> <p>Пятая ошибка — переоценка внутренних ресурсов. В некоторых компаниях работу с базой знаний поручают сотрудникам, которые успешно проявили себя в других областях, но не имеют опыта подготовки и структурирования статей. Однако такие назначения не всегда приводят к ожидаемому результату: работа с корпоративными знаниями требует отдельных навыков и компетенций.</p> <p>«Наличие платформы само по себе не решает задачу управления знаниями. Отдачу получают компании, которые относятся к базе знаний как к операционной инфраструктуре — с собственными процессами, ответственными и метриками, — подчеркнул директор проектов Minerva Result в Minervasoft Денис Кучеров. — Технологии здесь лишь часть успеха. Чтобы пользу приносили и сотрудники, и ИИ-ассистенты, знания должны быть актуальными, понятными и применимыми. Это возможно только при наличии процессов и культуры менеджмента знаний».</p> Более 80% компаний среди крупного и среднего бизнеса допускают критичные ошибки в работе с корпоративными … message https://www.itweek.ru/themes/detail.php?ID=235032 Thu, 18 Jun 2026 11:31:17 +0300 <p>Postgres Professional представила Postgres Pro Standard 18.4.1 — новую версию коммерческой СУБД на базе PostgreSQL 18.4. Релиз сочетает возможности открытой СУБД PostgreSQL и технологии Postgres Professional, разработанные для корпоративной эксплуатации.</p> <p>В отличие от «ванильного» PostgreSQL, Postgres Pro Standard включает дополнительные инструменты для отказоустойчивости, резервного копирования, аудита, мониторинга и администрирования. В версии 18.4.1 одним из ключевых нововведений стала поддержка встроенного решения высокой доступности BiHA (Built-in High Availability), которое позволяет создавать отказоустойчивые кластеры без использования сторонних компонентов и инструментов управления.</p> <p>«Мы продолжаем развивать Postgres Pro Standard как промышленную СУБД для корпоративных систем, делая упор на надёжность и простоту эксплуатации. В новом релизе наши клиенты получат встроенную отказоустойчивость, дополнительные инструменты контроля и диагностики. Всё это позволяет обеспечивать бесперебойную работу бизнеса, а также снижать затраты на запуск и сопровождение ИТ-систем», — подчеркнул директор департамента разработки продуктов Postgres Professional Василий Чепцов.</p> <p>BiHA обеспечивает автоматическое аварийное переключение, восстановление узлов и защиту от сбоев на базе встроенных механизмов физической репликации. Пользователям доступны автоматический выбор нового лидера, каскадная репликация, поддержка узла-рефери для предотвращения split-brain (раскола кластера), а также возможности географически распределенных и катастрофоустойчивых кластеров.</p> <p>В состав Postgres Pro Standard 18.4.1 вошли новые утилиты и расширения для администрирования и контроля данных. Среди них — модуль pg_hint_plan, позволяющий гибко корректировать планы выполнения SQL-запросов с помощью специальных указаний (хинтов), который ранее был доступен только пользователям Postgres Pro Enterprise. А также pgpro_validate — для проверки целостности экземпляра СУБД, pgbouncer_exporter для экспорта метрик в Prometheus. Кроме того, в релизе оптимизированы отдельные механизмы планировщика запросов и работы с памятью, что позволяет повысить производительность высоконагруженных систем.</p> <p>Дополнительные улучшения коснулись средств аудита, резервного копирования и адаптивной оптимизации запросов. В сертифицированной редакции усилены механизмы защиты конфигурации, а инструменты диагностики получили новые возможности для анализа инцидентов и журналирования.</p> <p>С выходом версии 18.4.1 пользователи Postgres Pro Standard получают дополнительные инструменты для построения отказоустойчивых систем без усложнения архитектуры и зависимости от сторонних компонентов. Подробная информация о возможностях решения и инструкции по переходу представлены в документации Postgres Professional.</p> Postgres Professional представила Postgres Pro Standard 18.4.1 — новую версию коммерческой СУБД на базе PostgreSQL … message https://www.itweek.ru/themes/detail.php?ID=235030 Thu, 18 Jun 2026 09:39:58 +0300 <p><em>Большинство организаций неправильно измеряют бизнес-ценность, создаваемую агентным искусственным интеллектом. Новая концепция IDC объясняет, почему ценность нелинейна, затраты динамичны, а постоянная оценка рентабельности инвестиций не подлежит обсуждению, пишет в корпоративном блоге Андреа Сивьеро, старший директор </em><em>IDC</em> <em>по исследованиям стратегии бизнеса, основанной на ИИ.</em></p> <p>Существует хорошо отработанная методика расчета рентабельности инвестиций в ИТ. Определите базовый уровень, смоделируйте повышение эффективности, спрогнозируйте экономию затрат и представьте цифры финансовому директору. Для большинства технологических инвестиций этот подход работает.</p> <p>Агентный ИИ разрушает его.</p> <p>В отличие от традиционных программных решений, агентный ИИ (системы, которые автономно выполняют многоэтапные задачи, принимают решения в реальном времени и взаимодействуют с внешними инструментами и другими агентами) не предоставляет фиксированный, предсказуемый результат в обмен на фиксированный, предсказуемый ввод. Агенты учатся. Они адаптируются. Они принимают решения автономно в рамках многоэтапных процессов, взаимодействуют с другими системами и другими агентами, а также создают ценность или риск, которые накапливаются таким образом, что традиционные модели ROI не способны их учитывать.</p> <p><em>По данным исследования IDC, 42% организаций по всему миру уже сообщают, что оценка ROI их цифровых и ИИ-инвестиций затруднена или даже невозможна.</em></p> <p>Основные препятствия: ограниченная прозрачность долгосрочного воздействия, неопределенные или противоречивые базовые показатели и отсутствие специализированного отдела или рабочей группы по оценке ценности ИИ. Агентный ИИ не решает эти проблемы. Он их усиливает.</p> <p>Решение заключается не в прекращении измерений, а в изменении методов измерения.</p> <h3>Почему агентный ИИ требует новой системы оценки ценности</h3> <p>Основная проблема заключается в том, что ценность агентного ИИ нелинейна. Один агент, взаимодействующий с клиентом, конвейером данных и бэк-офисным процессом, не обеспечивает четкий процент производительности. Он генерирует результаты, определяемые качеством внедрения, границами автономности, петлями обратной связи, а также качеством данных и процессов, в рамках которых он работает.</p> <p>Затраты представляют собой столь же сложную картину. Расходы на агентный ИИ охватывают лицензирование LLM и SLM, вызовы API, потребление токенов и облачную инфраструктуру, но основными факторами, определяющими затраты, часто являются оркестровка и управление. В рамках концепции IDC стоимость агентного ИИ определяется как фундаментально поведенческая, зависящая от того, как агенты получают промпты, как часто они используют внешние инструменты и насколько тщательно за ними следят. Предположение о линейном масштабировании затрат — одна из самых дорогостоящих ошибок, которые может совершить ИТ-руководитель.</p> <p>Риск добавляет третье измерение. В агентных системах сбои распространяются. Неправильно настроенная граница принятия решений в одном агенте может каскадно распространяться на этапы, инструменты и последующие процессы таким образом, что статические модели риска этого не учитывают.</p> <h3>Шестикомпонентная структура для максимизации бизнес-ценности</h3> <p>Для решения этой проблемы IDC разработала схему максимизации бизнес-ценности агентного ИИ — структурированный подход, построенный на шести компонентах, через которых сквозной нитью проходит управление.</p> <p>#IMAGE_235031#</p> <ul> <li><strong>Стратегия. </strong>Агентный ИИ внедряет автономное принятие решений, поэтому стратегия должна определять, где автономия допустима, а где она ограничена. Результатом является не расплывчатое стремление к «лучшей производительности». Это многоплановая дорожная карта с ответственными за метрики, общая для всей организации и явно привязанная к приоритизации инвестиций. Организации, которые рассматривают агентов как инструменты, а не как автономных субъектов, обрекают себя на сбои в управлении, а не на повышение производительности.</li> <li><strong>Приоритизация сценариев использования.</strong> Не каждая проблема является проблемой, решаемой агентами. Внедрение агентного ИИ в узкие, изолированные задачи, с которыми прекрасно справляется детерминированная автоматизация, приводит к нерациональному расходованию инвестиций и добавляет ненужную сложность. Схема IDC вводит измерения приоритизации, специфичные для агентных контекстов: многоэтапные требования к рассуждениям, динамические потребности в принятии решений, сложность оркестровки и степень, в которой сама автономия создает ценность. Результатом является ранжированный, скорректированный по осуществимости портфель сценариев использования, а не список технически интересных экспериментов.</li> <li><strong>Картирование ценности.</strong> Картирование ценности позволяет привязать инвестиции в агентный ИИ к четким бизнес-результатам и предотвратить бесцельные эксперименты, которые раздувают бюджеты на ИИ без достижения измеримых результатов. Критически важно, что ценность агентного ИИ не статична. Она накапливается по мере того, как агенты учатся, адаптируются и расширяют сферу применения. Картирование ценности должно учитывать кривую обучения, а не только немедленный прирост эффективности, и должно включать нефинансовые факторы, такие как устойчивость и доверие клиентов, наряду с традиционными финансовыми показателями.</li> <li><strong>Расширенная модель затрат.</strong> Схема IDC предусматривает динамическую модель общей стоимости владения, которая отличает капитальные затраты от постоянных, специфических для ИИ операционных затрат и предоставляет FinOps-, юридическим и финансовым командам необходимую информацию для управления сложной экономикой агентного ИИ, основанной на использовании.</li> <li><strong>Корректировка рисков.</strong> Рентабельность инвестиций в агентный ИИ не должна представляться в виде единичной оценки. Она должна основываться на сценариях, быть привязана к траектории внедрения, качеству выходных данных и временным предположениям, и все это должно быть назначено конкретным ответственным лицам с документально подтвержденным уровнем доверия. Риск следует рассматривать как динамический, обновляемый по мере замены оценок реальными данными и моделируемый с учетом взаимозависимостей, которые делают сбои в агентных системах системными, а не изолированными.</li> <li><strong>Непрерывная оптимизация ценности.</strong> Анализ жизненного цикла развертывания агентных систем, проведенный IDC, показывает, что без активной настройки производительность агентов снижается по мере изменения контекста и накопления граничных случаев. Для поддержания устойчивой ценности необходимо рассматривать агентный ИИ как постоянную задачу управления жизненным циклом, а не как проект, который нужно завершить и передать в операционный отдел. Для этого необходим специализированный Центр передового опыта с четким графиком управления, определенными стандартами и организационным мандатом на обеспечение непрерывной оптимизации.</li> </ul> <h3>От концепции к действию</h3> <p>Схема IDC по максимизации бизнес-ценности агентного ИИ разработана для достижения шести конкретных результатов: дорожной карты автономности на несколько временных горизонтов, ранжированного портфеля сценариев использования, калькулятора бизнес-ценности, динамической модели совокупной стоимости владения, оценщика рисков на основе сценариев и модели управления жизненным циклом агента. Это не амбициозные результаты. Это минимальный набор инструментов, необходимых организации для управления агентным ИИ как бизнес-инвестицией, а не как технологическим экспериментом.</p> <p>Анализ IDC показывает, что организации, которые создадут эту инфраструктуру сейчас, получат больше пользы от существующих развертываний агентного ИИ и будут структурно лучше подготовлены к масштабированию по мере появления следующей волны возможностей.</p> Большинство организаций неправильно измеряют бизнес-ценность, создаваемую агентным искусственным интеллектом. Новая концепция … article https://www.itweek.ru/themes/detail.php?ID=235028 Thu, 18 Jun 2026 09:28:30 +0300 <p><em>С развитием бизнеса на маркетплейсах практически каждый продавец приходит к необходимости усиливать ИТ-часть и быстро понимает: универсального решения «из коробки» не существует. Но главный вызов заключается не в автоматизации отдельных процессов, а в сохранении управляемости и контроля над бизнесом. О</em><em>бсудим</em><em>, как выстраивать ИТ-инфраструктуру селлера на разных стадиях развития</em><em>.</em></p> <h3>Чужая система координат</h3> <p>Иногда кажется, что рынок сервисов для продавцов на маркетплейсах растет быстрее самих маркетплейсов. Аналитические платформы, конструкторы, системы учета и автоматизации обещают предпринимателям управляемость «из коробки»: подключил сервис — и бизнес прозрачен.</p> <p>На старте готовые сервисы действительно работают. Они позволяют быстро выйти в продажи без собственной ИТ-команды и закрывают базовые задачи — учет заказов, аналитику, склад, рекламу.</p> <p>Но вместе с удобством предприниматель получает зависимость. Инфраструктура оказывается арендованной: логика расчетов, доступ к данным и правила интеграций определяются не бизнесом, а поставщиком сервиса. Пока объемы небольшие, это почти незаметно. Но с ростом начинают проявляться ограничения:</p> <ul> <li> невозможно гибко считать юнит-экономику;</li> <li> данные из разных источников не сходятся;</li> <li> любое отклонение от стандартного сценария требует доработок или обходных решений;</li> <li> стоимость сервисов и интеграций растет быстрее оборота.</li> </ul> <p>В какой-то момент инструмент, который помог запуститься, начинает ограничивать развитие.</p> <h3>Главная проблема — не отсутствие, а избыток</h3> <p>На практике минимальный технологический набор для профессионального селлера включает несколько ключевых компонентов:</p> <ul> <li> система управления складом (WMS), обеспечивающая точный учет и контроль остатков;</li> <li> система управления заказами (OMS), которая позволяет отслеживать статус каждой покупки и планировать отгрузки;</li> <li> интеграции через API между всеми системами для синхронизации данных;</li> <li> ERP для ведения бухгалтерского и финансового учета;</li> <li> CRM для работы с клиентами, маркетинга и обработки обращений.</li> </ul> <p>При этом, по <a href="https://www.itforless.com/resources/blog/the-real-cost-of-unused-saas-tools">оценкам</a> индустриальных исследований, <nobr>20-30%</nobr> расходов на SaaS-инструменты приходится на дублирующие, неиспользуемые или слабо используемые сервисы. Отдельная статья расходов — интеграции между системами. Это не разовые вложения: любая интеграция требует постоянной поддержки, доработок и адаптации к изменениям API. По мере роста бизнеса число таких связей увеличивается, и стоимость ИТ-инфраструктуры начинает расти не линейно, а за счет накопления и усложнения взаимодействий между системами.</p> <p>Каждый инструмент решает свою локальную задачу и при этом создает отдельный поток данных. В какой-то момент компания понимает, что проблема не в функциональности отдельных сервисов, а в отсутствии единой картины бизнеса.</p> <p>Продажи, расходы, трафик и финансы существуют раздельно. Решения принимаются на основе фрагментов информации, а не целостной экономики.</p> <p>По <a href="https://www.forbes.com/councils/forbescommunicationscouncil/2025/10/22/the-real-cost-of-bad-data-how-it-silently-undermines-pricing-and-growth/">оценкам</a> Gartner, плохое качество данных обходится компаниям в среднем в $12,9 млн. ежегодно. Для селлеров это означает искажение юнит-экономики: по <a href="https://foyzo.com/marketplace-insights/marketplace-fees-2026/">оценкам</a> отрасли, при реальной марже <nobr>10-25%</nobr> даже ошибка в расчетах на уровне <nobr>5-10%</nobr> может полностью обнулить прибыль.</p> <p>Поэтому главным ИТ-проектом растущего селлера становится не внедрение новой системы, а интеграция всех существующих. Компании начинают строить собственное «ядро» — центральную базу данных, куда стекается вся операционная информация. Именно способность связать данные между собой превращается в ключевой фактор управляемости.</p> <h3>Автоматизация как источник новых рисков</h3> <p>Дополнительное ограничение — вопрос доступа и безопасности. Для того, чтобы сторонний сервис начал считать экономику бизнеса, ему необходимо предоставить доступ к личному кабинету маркетплейса — чаще всего через API или другие интеграции. Насколько это безопасно? Даже если это известная платформа, никто не может гарантировать, как именно будут использоваться данные и какие сценарии возможны в случае инцидента.</p> <p>Представьте наихудший вариант: сервис допустил ошибку или злоупотребил доступом, и бизнес пострадал. Судебные разбирательства здесь мало помогают — основной ущерб уже нанесен. Особенно это актуально для России, где механизмы компенсаций и ответственности сервисов находятся пока на стадии формирования.</p> <p>Быстрое внедрение автоматизации и ИИ опережает развитие систем контроля, формируя так называемый накопленный долг по безопасности. По <a href="https://www.ibm.com/think/x-force/2025-cost-of-a-data-breach-navigating-ai">данным</a> IBM, 97% организаций, столкнувшихся с инцидентами, связанными с ИИ, не имели должного контроля доступа, а 60% компаний не имеют формализованных политик управления ИИ.</p> <p>Облачные решения усиливают это противоречие. Они создают ощущение надежности, однако зависимость от одного провайдера означает, что технический инцидент может парализовать бизнес мгновенно. Пример: год назад перебои в международной интернет-инфраструктуре, связанные с событиями в Иране, затронули часть зарубежных облачных сервисов, которыми пользовался ряд компаний. Это показало, что в ряде случаев даже двух серверов в разных локациях недостаточно — иногда необходим третий балансировщик, чтобы ежедневно зеркалировать данные и иметь возможность мгновенно восстановить систему из резервной копии.</p> <p>Аналогичные ситуации уже происходили с крупными провайдерами: уход Microsoft из России стал шоком для компаний, полностью завязанных на облачные решения — сотрудники потеряли доступ к корпоративной почте, контактам и мессенджерам, на которые полагались для ежедневной работы.</p> <p>Поэтому зрелые игроки постепенно переходят к компромиссной модели: внешние сервисы используются как интерфейсы, но ключевые данные хранятся внутри компании — с резервными копиями, распределенным хранением и контролем доступа.</p> <h3>Почему с ростом бизнес неизбежно приходит к собственной разработке</h3> <p>С увеличением масштаба многие предприниматели проходят одинаковый путь: со временем складывается ситуация, когда поддержка набора внешних сервисов становится дороже и сложнее, чем создание собственной системы.</p> <p>Прежде чем начать разработку собственной WMS-системы, тестируются готовые решения. Все они имеют определенную логику, но не закрывают потребности на 100%. С планируемыми темпами роста становится очевидно, что любое из имеющихся решений требовало бы бесконечных доработок, каждая из которых стоила бы дорого и не гарантировала нужного результата. Поэтому компании идут по пути создания собственного решения, которое дает полную свободу действий и позволяет выстроить систему под реальные бизнес-процессы.</p> <p>Есть несколько типичных сигналов:</p> <ul> <li> данные из разных систем регулярно расходятся;</li> <li> отчеты собираются вручную или в Excel;</li> <li> невозможно посчитать маржинальность по SKU в реальном времени;</li> <li> рост оборота не приводит к росту прибыли;</li> <li> добавление нового канала или товара резко усложняет процессы.</li> </ul> <p>Это не всегда означает, что компании необходимо создавать всю ИТ-систему с нуля. Чаще это постепенное формирование собственного data-слоя и логики обработки данных поверх существующих инструментов.</p> <p>Кастомная разработка появляется не из технологических амбиций, а из управленческой необходимости. Бизнесу нужен контроль над логикой расчетов, данными и процессами. Маркетплейс-торговля постепенно превращается из торговой деятельности в инженерную — где конкурентным преимуществом становится не товар, а архитектура управления.</p> <h3>Эволюция ИТ-архитектуры селлера</h3> <p>На практике можно выделить три этапа технологической зрелости:</p> <ol> <li><strong> Старт</strong><strong>. </strong>Готовые сервисы «из коробки», минимальные интеграции, быстрый выход в продажи.</li> <li><strong> Рост</strong><strong>. </strong>Комбинация нескольких систем, появление бизнес-аналитики, первые попытки свести данные.</li> <li><strong> Зрелость</strong><strong>. </strong>Собственное ядро данных, централизованная логика расчетов, контроль над архитектурой.</li> </ol> <p>Проблема возникает, когда бизнес остается на первом или втором этапе при растущих оборотах.</p> <h3>Маркетплейс как инструмент, а не бизнес-модель</h3> <p>Главное изменение мышления происходит позже — когда предприниматель перестает воспринимать маркетплейс как сам бизнес. Площадка — это канал продаж и источник трафика, но устойчивость появляется только там, где существует собственная экономика: бренд, операционная эффективность, логистика или производственное преимущество.</p> <p>Рост оборота без системы учета часто приводит не к прибыли, а к управленческому кризису. Масштабирование требует понимания маржинальности, долговой нагрузки и реальных финансовых потоков — а значит, собственной инфраструктуры данных.</p> <p>Именно поэтому технологическая архитектура сегодня стала базовой частью торговли. Продавец больше не просто закупает и продает товар — он управляет системой интеграций, финансовых моделей и данных.</p> <p>Поэтому в новой реальности выигрывает не тот, кто быстрее выходит на маркетплейс, а тот, кто раньше начинает строить собственную управляемую инфраструктуру.</p> <p>#IMAGE_235029#</p> С развитием бизнеса на маркетплейсах практически каждый продавец приходит к необходимости усиливать ИТ-часть … article Никита Терехов, CEO и управляющий партнер международного онлайн-ретейлера Dubai Express https://www.itweek.ru/themes/detail.php?ID=235027 Wed, 17 Jun 2026 13:09:02 +0300 <p>«Яндекс» выложил в опенсорс YaFF (Yet Another Flat Format) — новый формат передачи и чтения данных для высоконагруженных сервисов. Технология позволяет работать с данными, не расходуя ресурсы на их распаковку. Это даёт возможность экономить до 20% вычислительных мощностей.</p> <p>Современные сервисы и приложения получают данные по сети или с диска в компактном виде. Чаще всего крупные ИТ-компании используют для «упаковки» и передачи данных формат Protobuf. Он удобный и надёжный, но имеет существенный недостаток: полученные данные нужно каждый раз распаковывать. Это ресурсоёмкая операция, на которую уходит до 10% всех мощностей сервиса. Альтернативный формат — FlatBuffers — позволяет читать данные без распаковки, но для перехода на него нужно практически полностью переписать код. Технология «Яндекса» решает эти проблемы. </p> <p>YaFF (Yet Another Flat Format) можно использовать поверх стандартного формата Protobuf, чтобы считывать данные напрямую — без распаковки. Это позволяет применять YaFF в уже существующих проектах и экономить вычислительные ресурсы, не переписывая код сервиса. Новый формат подойдет банкам и маркетплейсам, телеком-операторам и разработчикам облачных сервисов — всем, для кого критичны скорость обработки данных и эффективность использования «железа». </p> <p>Технология уже внедрена в рекламной системе «Яндекса». В условиях обработки сотен тысяч запросов в секунду это позволило снизить нагрузку на процессоры на <nobr>10–20%.</nobr> Высвобожденные ресурсы компания направляет на обработку большего числа пользовательских запросов без расширения серверного парка.</p> <p>Документация и код Yet Another Flat Format опубликованы на платформе GitHub.</p> «Яндекс» выложил в опенсорс YaFF (Yet Another Flat Format) — новый формат передачи и чтения данных для … message https://www.itweek.ru/themes/detail.php?ID=235026 Wed, 17 Jun 2026 13:07:50 +0300 <p>Независимая аналитическая компания Apple Hills Digital опубликовала отчет по исследованию «Рынок программного обеспечения искусственного интеллекта (AI/ML/GenAI) в РФ», в котором определила объем, структуру и динамику российского рынка ПО ИИ с <nobr>2022–2025 год,</nobr> а также дала прогноз и обозначила ключевые драйверы его развития до 2030 года.</p> <p>Главный вывод: рынок ПО искусственного интеллекта в России выходит из стадии точечных экспериментов и переходит к более зрелому этапу, где заказчики этой технологии ждут конкретной пользы для бизнеса.</p> <p>Ключевые тренды: </p> <ul> <li>ИИ в России все быстрее превращается из экспериментального направления в полноценный рынок корпоративного ПО. Объем российского рынка ПО ИИ составил 25 млрд рублей. За последние три года рынок почти удвоился, а к 2030 году может приблизиться к 95 млрд рублей;</li> <li>самым заметным драйвером становятся технологии GenAI. Сегодня основную часть рынка формируют прикладные решения — сервисы разговорной речи (10 млрд рублей и 53% сегмента) и компьютерное зрение (5,8 млрд рублей и 31% сегмента). Их рост поддерживался за счет интеграции с технологиями GenAI. В 2025 году применение GenAI было основным драйвером для рынка программного обеспечения ИИ. Компании стали активнее использовать GenAI в автоматизации бизнес-процессов, переходя от базовых, рутинных к более сложным, комплексным рабочим процессам — за три года это направление выросло с 0,1 млрд до 2,0 млрд рублей, а CAGR составил 156,7%;</li> <li>изменение логики спроса — важный сигнал для рынка. Если раньше многие компании приходили в тему ИИ из опасения отстать от тренда, то сейчас они все чаще оценивают, где технология действительно дает эффект: помогает сокращать издержки, ускорять процессы и повышать производительность;</li> <li>доли поставки платформ ИИ в публичном облаке и локальных развертываниях сопоставимы, но преобладает локальная поставка. Сейчас в России по-прежнему преобладает локальное развертывание ИИ-решений, однако несколько быстрее растут облачные модели. В 2025 году на локальное развертывание пришлось 62,3% рынка, или 15,6 млрд рублей. Однако решения в публичном облаке растут быстрее и к 2030 году будут прибавлять в среднем 34% в год, что связано со скоростью обновления моделей, доступностью вычислительных ресурсов и снижением барьеров для запуска новых сценариев ИИ. </li> </ul> <p>Эта тенденция перекликается с исследованием Apple Hills Digital по облачным трендам: российские компании активнее наращивают ИТ-бюджеты, выводят ИИ в промышленную эксплуатацию и все чаще рассматривают облако как среду для быстрого запуска и масштабирования новых технологий.</p> <p>«Российский рынок искусственного интеллекта заметно повзрослел. Если еще недавно многие компании приходили в эту тему из опасения отстать от тренда, то сейчас фокус меняется — бизнес хочет понимать, где именно ИИ дает измеримый эффект, оптимизирует издержки, ускоряет процессы или создает новые предпосылки для роста. Эта тенденция сохранится и до 2030 года будет обеспечивать устойчивый ежегодный рост с CAGR 30,5%», — отметила Елена Семеновская, аналитик Apple Hills Digital. </p> Независимая аналитическая компания Apple Hills Digital опубликовала отчет по исследованию «Рынок программного обеспечения … message https://www.itweek.ru/themes/detail.php?ID=235024 Wed, 17 Jun 2026 10:47:50 +0300 <p>Команда российской ИИ-платформы для работы с кодом GitVerse развернула зеркала библиотек для наиболее популярных языков программирования. Проект охватывает ключевые направления разработки — от веба и бэкенда до DevOps и контейнеризации. Он позволяет пользователям GitVerse защититься от сбоев при работе с внешними зарубежными сервисами.</p> <p>На GitVerse теперь доступны зеркала для хранилища библиотек Python Package Index (PyPI), официального сервиса для работы с модулями Go (proxy.golang.org) и реестра пакетов для языка программирования Rust (Crates.io). Ранее на платформе были созданы зеркала для Maven Central (репозитория пактов для языка Java), NPM (менеджера пакетов для JavaScript), а также Docker Hub (хранилище образов контейнеров). </p> <p>Таким образом, GitVerse сегодня предоставляет локализованные в российской инфраструктуре практически все самые популярные реестры пакетов для разработки. Это важно для компаний, которым необходима стабильность процессов и технологический суверенитет.</p> <p>Зеркала можно использовать как основной или резервный источник зависимостей, чтобы гарантировать непрерывность локальной разработки в тех случаях, когда исходный репозиторий пакетов недоступен. Благодаря размещению в российской инфраструктуре снижаются сетевые задержки и ускоряется загрузка пакетов по сравнению с зарубежными хранилищами. </p> <p>GitVerse — продукт ИТ-компании СберТех, российская ИИ-центричная платформа, которая позволяет командам совместно работать с кодом, надёжно его хранить, автоматически сканировать на уязвимости, отслеживать изменения и собирать аналитику. Функциональность платформы усилена ИИ-инструментами: ассистентом GigaCode с агентным режимом, гибридной средой GigaIDE (локально и в облаке) и мультиагентной системой разработки GigaStudio. Платформе доверяют свыше 200 тыс. пользователей — на GitVerse размещено более 140 000 проектов и хранится 13,8 ТБ данных (примерно 130 млрд строк кода).</p> Команда российской ИИ-платформы для работы с кодом GitVerse развернула зеркала библиотек для наиболее популярных языков … message https://www.itweek.ru/themes/detail.php?ID=235023 Wed, 17 Jun 2026 10:46:11 +0300 <p>Специалисты компании «Информзащита» выявили рост рисков, на фоне активного подключения ИИ-агентов к корпоративным почтам, внутренним базам, документообороту, клиентским обращениям и финансовым операциям; при этом механизмы контроля за их действиями остаются недостаточно зрелыми. В 2026 году только 14% компаний имеют внутренние инструменты, позволяющие выявить такую манипуляцию и заблокировать опасный сценарий без ожидания ручной реакции. По собранным данным, доля проектов, где ИИ-агенты получают доступ к внешним письмам, сайтам, документам и пользовательским обращениям, за год выросла с 18% до 34%, а число запросов на оценку безопасности подобных сценариев увеличилось на 41%.</p> <p>Агенты часто используются в решении потоковых задач, разбирают входящие сообщения, извлекают сведения из договоров и таблиц, готовят ответы, создают заявки, переносят данные между системами, и в ряде компаний действует как полноценный участник процесса с доступом к корпоративному контуру. Он получает информацию извне, сопоставляет ее с внутренними данными и при определенных настройках запускает следующее действие. </p> <p>Сценарий атаки часто начинается типично через почту, через которую приходит запрос от контрагента, в форму поддержки загружается обращение клиента, в документе появляется комментарий, на сайте размещается текст, который агент должен использовать как источник. Внутри такого контента злоумышленник прячет инструкцию: изменить ход обработки, раскрыть сведения, переслать данные, проигнорировать ограничение, сформировать ответ с нужной формулировкой. Сотрудник видит обычный деловой материал, агент может принять скрытую команду за часть рабочего контекста и выполнить ее как штатную операцию. Расследование в таких случаях осложняется тем, что действие не выглядит как классический взлом: оно проходит через разрешенный сценарий автоматизации.</p> <p>Многие проекты стартуют в бизнес-подразделениях с конкретной практической целью сократить время обработки писем, ускорить первую линию поддержки или разобрать поток документов. Команды безопасности подключаются уже после пилота, когда у агента есть доступ к почтовому ящику, файловому хранилищу, системе заявок или клиентской базе. Права при этом часто выдаются с запасом, потому что широкий доступ повышает качество результата. В защите такая логика создает лишние привилегии, размывает границы ответственности и усложняет восстановление цепочки событий.</p> <p>По векторам атак наиболее заметна электронная почта и вложения: на них приходится около 32% выявленных рискованных сценариев. Это письма от клиентов, поставщиков, подрядчиков, соискателей и партнеров, где скрытая инструкция маскируется под нормальную деловую переписку. Сайты и внешние базы знаний формируют 24% случаев: агент обращается к ним для подготовки ответа, сверки сведений или поиска справочной информации. Документы контрагентов дают около 18% сценариев, включая таблицы, презентации, договоры, технические описания, комментарии, скрытые элементы форматирования и метаданные. На чаты, системы заявок и клиентские формы приходится 15%. Еще 11% связаны с цепочками из нескольких систем, где команда появляется в одном канале, затем действие выполняется в другом: письмо приводит к созданию заявки, заявка меняет данные в карточке клиента, после этого система отправляет подтверждение внешнему адресату.</p> <p>Особенно опасен разрыв между скоростью агента и скоростью проверки. Ручной контроль работает, когда речь идет о единичном черновике или операции, где у сотрудника есть время внимательно изучить результат. В потоковых процессах такая проверка быстро превращается в задержку, которую начинают обходить ради скорости. По данным специалистов, 25% организаций полагаются на ручную проверку высокорисковых результатов, 14% умеют выявлять манипуляцию, но не могут автоматически остановить агента, 34% знают о риске, но не имеют средств обнаружения и сдерживания. Еще 14% компаний пока не включили такой сценарий в модель угроз. При реальном инциденте агент успевает отправить данные наружу, согласовать заявку, подготовить изменение реквизитов или сформировать ответ с вредоносной ссылкой раньше, чем событие попадет к ответственному специалисту.</p> <p>Сильнее всего проблема проявляется в отраслях, где внешние запросы быстро переходят во внутренние действия. В финансовом секторе сосредоточено около 31% выявленных сценариев повышенного риска: агенты помогают разбирать платежные запросы, клиентские обращения, документы по операциям и внутренние заявки. На розничную торговлю и электронную коммерцию приходится 19%; зона риска связана с поддержкой покупателей, возвратами, бонусными программами, личными кабинетами и изменением контактных данных. Промышленность и логистика дают около 14% сценариев из-за документооборота с поставщиками, заявок на отгрузку, маршрутной информации и производственных инструкций. В ИТ-компаниях и у разработчиков программного обеспечения доля составляет 13%, поскольку агенты получают доступ к задачам, технической документации, хранилищам кода и описаниям внутренних процессов. Телекоммуникации занимают 9%, здравоохранение — 8%, государственные и профессиональные услуги — 6%.</p> <p>Агент с доступом к почте, файловому хранилищу и системе заявок — это по факту непривилегированный администратор без аудита. Его права необходимо пересматривать так же строго, как права администратора, финансового сотрудника или оператора клиентской поддержки. Особого внимания требуют цепочки из нескольких агентов и систем: один инструмент анализирует письмо, второй извлекает данные, третий создает запись, четвертый отправляет ответ. Чем длиннее такая связка, тем сложнее понять, где появилась вредоносная команда и какой элемент выполнил опасное действие. Без подробных журналов, привязки операций к конкретному агенту и контроля переходов между системами расследование быстро теряет точность.</p> <p>Снижать риск можно через управляемую архитектуру использования ИИ-агентов. У каждого агента должен быть владелец, описанная цель, ограниченный набор источников данных и перечень действий, разрешенных без дополнительного подтверждения. Внешний контент нужно проверять до передачи агенту: письма, документы, страницы и вложения должны проходить фильтрацию на скрытые команды, попытки изменить роль агента и инструкции, выходящие за рамки исходной задачи. Для операций с высоким риском требуется отдельный уровень подтверждения. Изменение платежных реквизитов, отправка персональных данных, массовая рассылка, действия с правами пользователей и доступ к финансовым системам должны выполняться только после проверки ответственным сотрудником или через заранее настроенный механизм доверенного согласования. Практическую основу защиты составляют журналирование, контроль поведения, ограничение внешней передачи данных и автоматическое сдерживание. При отклонении от нормального сценария агент должен остановиться сам и передать событие в разбор. </p> Специалисты компании «Информзащита» выявили рост рисков, на фоне активного подключения ИИ-агентов к корпоративным … message https://www.itweek.ru/themes/detail.php?ID=235022 Wed, 17 Jun 2026 10:44:59 +0300 <p>Команда Deckhouse, направление компании «Флант», выпустила версию 1.18 Deckhouse Stronghold — российского решения для безопасного управления жизненным циклом секретов. Новый релиз сфокусирован на интеграции с внешними системами управления ключами, расширении возможностей аудита и внедрении удобных сценариев эксплуатации для корпоративных инфраструктур.</p> <p>Главное нововведение версии — поддержка управляемых ключей (Managed Keys). Теперь Deckhouse Stronghold может работать с внешними KMS, не размещая приватные ключи внутри своего хранилища. Это снижает риски компрометации и упрощает соответствие строгим требованиям безопасности и комплаенса. </p> <p>Для бесшовной интеграции в корпоративные IAM-среды добавлены аутентификация через внешний SAML 2.0 Identity Provider и поддержка Web SSO. Вход в систему стал удобнее и безопаснее благодаря поддержке WebAuthn (FIDO2/Passkeys), которая полностью убирает зависимость от паролей.</p> <p>Повседневная административная работа выведена на новый уровень. Теперь параметры репликации KV-mount, мониторинг audit-логов и просмотр сервисных журналов доступны прямо из веб-интерфейса — без необходимости использовать <nobr>CLI-утилиты.</nobr> Журналы аудита получили гибкую фильтрацию и возможность исключения чувствительных полей из записей, что повышает удобство анализа событий, упрощает расследование возможных инцидентов и помогает соблюдать политики обработки данных.</p> <p>Stronghold 1.18 поддерживает загрузку внешних плагинов в контейнерном исполнении. Ранее при использовании в составе Deckhouse Kubernetes Platform хранилище работало только в поставке «как есть» — механизма загрузки плагинов в кластере не было, это было доступно лишь в standalone-исполнении. Теперь инженеры могут подключать собственные решения, совместимые с HashiCorp Vault, и адаптировать продукт под специфику инфраструктуры без изменения кода.</p> <p>«Новый релиз развивает функциональные возможности Deckhouse Stronghold как полноценного enterprise-хранилища секретов для крупных корпоративных инфраструктур. В версии 1.18 мы сделали акцент как на новых функциях безопасности, так и на удобстве повседневной работы с продуктом: добавили поддержку внешних KMS, расширили возможности аудита и перенесли ряд административных операций в веб-интерфейс, чтобы сделать управление секретами в Deckhouse Stronghold проще и эффективнее», — отметил Владимир Девятайкин, менеджер продукта Deckhouse Stronghold.</p> Команда Deckhouse, направление компании «Флант», выпустила версию 1.18 Deckhouse Stronghold — российского решения для … message https://www.itweek.ru/themes/detail.php?ID=235021 Wed, 17 Jun 2026 10:44:16 +0300 <p>Компания «СёрчИнформ» представила результаты опроса по теме искусственного интеллекта в области ИБ, проведенного среди 170 российских специалистов по информационной безопасности. Вопросы касались практики использования нейросетей для решения ИБ-задач, а также рисков утечек конфиденциальной информации через ИИ.</p> <p>Российский бизнес активно внедряет искусственный интеллект в операционные процессы для повышения эффективности, и сфера информационной безопасности не стала исключением. В 2024 году, по данным опроса «СёрчИнформ», 77% ИБ-специалистов считали возможным внедрение технологий искусственного интеллекта в свою работу, 23% опрошенных ответили, что в работе ИБ-специалистов нет места ИИ.</p> <p>В 2026 году 34% опрошенных специалистов по информационной безопасности уже активно используют ИИ в работе. 39% — планируют внедрение ИИ в будущем, это свидетельствует о растущем интересе и потенциале для расширения использования ИИ в области ИБ. Однако более четверти опрошенных (27%) все еще не планируют использовать ИИ для решения ИБ-задач.</p> <p>«Использование ИИ в информационной безопасности активно растет. Примерно треть специалистов уже используют ИИ для решений задач, еще 39% планируют внедрять в будущем. Причины такого сдвига, на мой взгляд, комплексные — снижение стоимости ИИ, появление локальных решений, улучшение моделей: они стали быстрее, умнее и требуют меньше ресурсов. ИБ-специалисты видят реальную пользу, а для тех, кто ранее отказывался от использования ИИ из-за риска утечки данных, появилась возможность использовать локальные системы», — прокомментировал начальник отдела безопасности «СёрчИнформ» Алексей Дрозд.</p> <p>Более половины опрошенных специалистов (53%) оценивают эффективность использования ИИ для решения ИБ-задач как среднюю, и 36% — как высокую. В то же время 11% специалистов видят различные ограничения возможностей ИИ и оценивают эффективность использования нейросетей в работе ИБ-специалиста как низкую.</p> <p>При этом никто из опрошенных ИБ-специалистов не готов полностью полагаться на результаты работы ИИ. 76% доверяют ИИ, но с осторожностью, 19% — скептически относятся к результатам работы искусственного интеллекта. 5% ИБ-специалистов пока не готовы доверять ИИ.</p> <p>Также аналитики «СёрчИнформ» выяснили, в каком формате опрошенные специалисты используют ИИ. Большинство (56%) предпочитают использовать ИИ, встроенный в софт. Однако нередко (49%) ИБ-специалисты используют бесплатные ИИ-модели в открытом доступе. 44% — пользуются собственной локальной ИИ-моделью.</p> <p>ИБ-специалисты активно внедряют ИИ для помощи с аналитическими и классификационными задачами, однако для более критичных задач, таких как реагирование на инциденты и обнаружение угроз, использование ИИ пока ограничено.</p> <p>Наиболее популярные сценарии использования ИИ для решения ИБ-задач — генерация ответов (например, ИИ-помощник для анализа документов и т.д.) — 49%, анализ логов и событий безопасности — 47%, помощь в классификации и анализе контента (аудио, изображения, большие объемы текста, перевод) — 42%.</p> <p>Четверть опрошенных доверяют нейросетям анализ инцидентов информационной безопасности. Еще реже опрошенные передают ИИ обнаружение вредоносных программ (12%), детектирование фишинга (10%), реагирование на инциденты и предотвращение атак (6%).</p> <p>«Многие полагают, что в ИИ-системах существует одна универсальная „кнопка“, которая решит все задачи. На деле же, за этим стоят разные специализированные инструменты, каждый из которых эффективно работает в своей области ИБ. Например, нейросети хорошо справляются с классификацией изображений, в то время как большие языковые модели чаще используют для генерации и анализа текста. Важно понимать, что для разных задач нужны разные решения. Анализ логов, обнаружение фишинга, автоматизация реагирования на инциденты — все это требует различных инструментов и подходов. Поэтому комплексное внедрение ИИ в ИБ-задачи зачастую включает в себя интеграцию нескольких технологий», — рассказал начальник отдела безопасности «СёрчИнформ» Алексей Дрозд.</p> <p>Среди главных преимуществ использования ИИ в информационной безопасности опрошенные специалисты видят: автоматизацию рутинных задач (86%), улучшение аналитических возможностей (73%) и повышение скорости обнаружения угроз (69%).</p> <p>Лишь 11% российских ИБ-специалистов используют технологии ИИ, встроенные в защитные решения. Почти половина (49%) планируют протестировать ИИ в защитных решениях в ближайшее время. 39% специалистов не используют, 1% опрошенных не планируют использовать.</p> <p>«Интересно отметить крайнюю разрозненность ответов, функции ИИ, встроенные в ИБ-средства, сейчас используют 11% и лишь 1% опрошенных не планируют использовать возможности нейросетей. Эти цифры демонстрируют, насколько сильно изменилось восприятие ИИ-инструментов в отрасли безопасности. Если в <nobr>2017-2018</nobr> годах об использовании ИИ в ИБ не могло быть и речи, то сейчас ИИ воспринимается как технология обязательная, но все еще новая — ведь большая часть респондентов только планирует ее применение. Однако все еще основную роль играет показатель доверия к ИИ среди ИБ-специалистов: абсолютное большинство относится к результатам анализа ИИ со здоровым скептицизмом, а показатель безоговорочного доверия к ИИ среди опрошенных специалистов и вовсе равен нулю», — прокомментировал Алексей Парфентьев, заместитель генерального директора по инновационной деятельности «СёрчИнформ».</p> <p>Кроме преимуществ ИИ, опрошенные ИБ-специалисты отмечают и ограничения, с которыми сталкиваются при использовании ИИ. Среди них: высокие требования к вычислительным ресурсам (62%), сложности интеграции с существующими системами (46%) и недостаточная прозрачность решений ИИ (42%).</p> <p>В 2025 году, по данным опроса «Битрикс24» и «Русской школы управления», каждый пятый сотрудник российских компаний передавал конфиденциальные данные ИИ. Компрометация конфиденциальной информации из-за отправки корпоративных или персональных данных в нейросети — один из рисков, который теперь необходимо контролировать ИБ-специалистам.</p> <p>В 2024 году, по данным «СёрчИнформ», почти в половине российских компаний ИБ-специалисты видели риски, связанные с утечками конфиденциальной информации через чат-боты, и ограничивали персоналу доступ к ИИ-сервисам. По данным опроса в 2026 году, большинство ИБ-специалистов (53%) оценивают риск утечки конфиденциальных данных при использовании ИИ сотрудниками как высокий, 29% опрошенных как средний.</p> <p>При этом лишь 8% опрошенных ИБ-специалистов запрещают сотрудникам использовать ИИ для работы, 36% — не контролируют использование ИИ. 30% ИБ-специалистов разрешают сотрудникам использовать нейросети из «белых списков», а 26% разрешают использовать ИИ только по определенным сценариям.</p> <p>Среди мер контроля, которые используют ИБ-специалисты: мониторинг активности сотрудников при работе с ИИ (44%), инструкции и регламенты по использованию нейросетей (29%), обучающие программы и тренинги по безопасному использованию ИИ (23%) и блокировка отправки определенного содержимого в файле или обращении (18%).</p> <p>«Свободно распространяемые ИИ-сервисы создают значительные риски для конфиденциальности данных российских компаний. Защита от этих угроз в первую очередь лежит на разработчиках средств защиты информации, таких как файрволы искусственного интеллекта (AI Firewall) и системы защиты от утечек информации (DLP). Системы защиты от утечек, которые не учитывают популярные ИИ-сервисы, такие как чат-боты с генеративным искусственным интеллектом (ChatGPT, Copilot и DeepSeek), рискуют стать неконкурентоспособными на рынке. Мы как разработчик предвидим подобные риски, поэтому уже добавили в свое решение функцию детектирования и блокировки многих популярных ИИ-сервисов, а сейчас готовим комплексное обновление этого функционала», — прокомментировал Алексей Парфентьев, заместитель генерального директора по инновационной деятельности «СёрчИнформ».</p> <p>Также по данным опроса «СёрчИнформ», 42% ИБ-специалистов сталкивались с тем, что сотрудники передавали в ИИ-сервис конфиденциальные или чувствительные данные. 28% респондентов ответили, что им не хватает инструментов для контроля утечек через нейросети.</p> <p>Среди мер, которые предпринимают ИБ-специалисты для предотвращения передачи конфиденциальных данных ИИ-системам: обучение сотрудников (54%), мониторинг и аудит использования ИИ (45%) и ограничение доступа к конфиденциальным данным (43%).</p> <p>Также ИБ-специалисты выделили основные сложности, с которыми они сталкиваются, при контроле использования ИИ. Среди них: отсутствие четкой стратегии и стандартов для мониторинга и регулирования использования ИИ, простота доступа к нейросетям с различных устройств и невозможность отслеживать все сценарии использования ИИ сотрудниками, человеческий фактор (риск ошибок или злоупотреблений со стороны сотрудников), нехватка знаний и навыков, которая затрудняет разработку эффективных мер контроля и реагирования на угрозы и др.</p> Компания «СёрчИнформ» представила результаты опроса по теме искусственного интеллекта в области ИБ, проведенного … message https://www.itweek.ru/themes/detail.php?ID=235020 Wed, 17 Jun 2026 10:34:03 +0300 <p>При поддержке BSS состоялась встреча Frank Award 2026 «Банковские контакт-центры», на которой было представлено самое комплексное в России актуальное исследование клиентского опыта в отрасли. По его результатам были награждены лучшие банковские практики. Эксперт BSS принял участие в церемонии награждения и экспертной дискуссии.</p> <p>BSS выступила партнером отраслевой встречи Frank Award 2026 «Банковские контакт-центры», организованной аналитической компанией Frank RG. Мероприятие объединило представителей крупнейших банков РФ, включая Сбер, Т-Банк, Альфа-Банк, ПСБ, ВТБ, Уралсиб, ОТП Банк.</p> <p>На встрече Frank RG представила исследование клиентского опыта в банковских контакт-центрах. Ключевые результаты:</p> <ul> <li>уже 64% пользователей предпочитают чат в мобильном приложении — фокус смещается все больше на текстовые каналы. На втором месте — колл-центр (42%), на третьем — чат в интернет-банке (23%). Также клиенты общаются через чат на сайте (6%), форму обратной связи (5%), Email (4%), мессенджеры (3%) и соц. сети (3%);</li> <li>контакт-центры становятся важной точкой поддержки клиентов в стрессовых ситуациях — растет количество обращений, связанных с мошенничеством и блокировками счетов;</li> <li>доля максимальных оценок роботам достигла 75%, однако пользователи по-прежнему отмечают недостаточное понимание запросов и отсутствие гибкости в диалоге;</li> <li>главный фактор качественного обслуживания для клиентов — минимальное количество усилий при решении вопроса: быстрый ответ и короткий диалог без переключений, решение проблемы с первого обращения. </li> </ul> <p>По результатам исследования состоялась церемония награждения лучших банковских практик. Заместитель генерального директора BSS Василий Жилов вручил награду банку ПСБ, признанному победителем в номинации за лучшую работу чат-бота. </p> <p>Исследование также стало отправной точкой для экспертной дискуссии о будущем банковских контакт-центров, в которой приняли участие представители ведущих финансовых организаций страны. Среди спикеров выступил эксперт BSS Василий Жилов.</p> <p>По словам Василия, сегодня банки располагают огромным объемом данных о взаимодействии с клиентами — телефонные разговоры, переписки в чатах, история обращений в приложении — однако эти данные существуют разрозненно и не позволяют получить целостную картину клиентского опыта.</p> <p>«Если создать единый операционный слой управления данными, можно гораздо точнее понимать причины оттока клиентов или снижения конверсии и принимать решения на основе полной картины клиентского пути», — отметил Василий Жилов. </p> <p>Эксперт также подчеркнул, что важно соблюдать баланс между автоматизацией и удовлетворенностью клиентов: можно существенно сократить издержки на входящей линии за счет автоматизации, но если клиент останется недоволен взаимодействием, бизнес потеряет больше. </p> <p>При этом ключевая причина недоверия к роботам сегодня связана не с ограничениями технологий, а с качеством их внедрения и настройки. Современные системы понимают смысл обращений, качественно синтезируют речь, используют интеллектуальный поиск информации и многое другое: </p> <p>«Технологии уже приносят результат: получают все более высокие оценки при обработке обращений, анализируют качество всех коммуникаций контакт-центра, заводят и решают тикеты в Service desk, помогают операторам проходить онбординг в 3 раза быстрее. А в ближайшие годы мы увидим по-настоящему human-centric решения, которые к тому же будут проявлять эмпатию», — прокомментировал Василий Жилов. </p> <p>Эксперт BSS также коснулся оценки эффективности контакт-центров и отметил, что важно смотреть не только на традиционные операционные показатели, такие как AHT или FCR, но и на бизнес-метрики: скорость получения клиентом ценности (Time to Value), пожизненную ценность клиента (LTV) и стоимость привлечения (Customer Acquisition Cost). Достижению этих показателей сегодня часто мешает «лоскутная автоматизация».</p> <p>«Банки тратят до 40% бюджетов на интеграцию различных цифровых решений между собой. Поэтому сегодня особенно важен комплексный подход, который охватывает сразу пять ключевых направлений: сервисные функции, продажи, предотвращение оттока, маркетинговые коммуникации и развитие сотрудников. Объединение этих процессов в единой среде с общими данными и <nobr>ML-логикой</nobr> позволит выйти на новый уровень клиентского сервиса», — отметил Василий Жилов.</p> При поддержке BSS состоялась встреча Frank Award 2026 «Банковские контакт-центры», на которой было представлено самое … message https://www.itweek.ru/themes/detail.php?ID=235019 Wed, 17 Jun 2026 10:27:51 +0300 <p>Компания BSS дает мощный толчок развитию диалоговых интерфейсов с новой версией Dialog Composer 3.0. Ключевой особенностью релиза стала нативная поддержка архитектуры ИИ-агентов на базе больших языковых моделей (LLM). Обновленный no-code инструмент позволяет компаниям быстро внедрять автономных ИИ-ассистентов, существенно снижая нагрузку на контактные центры и операционные службы.</p> <p>Один из ведущих российских разработчиков речевых технологий и искусственного интеллекта, компания BSS, представила масштабное обновление своей no-code платформы для разработки диалоговых сценариев — Dialog Composer (DC) версии 3.0. Релиз помогает перейти от классической автоматизации на жестких скриптах к созданию сложных автономных ИИ-агентов, способных самостоятельно принимать решения и интегрироваться в бизнес-процессы заказчика.</p> <p>Ключевой особенностью DC 3.0 стала возможность реализации полноценных ИИ-агентов. В отличие от традиционных сценарных ботов, где прописаны каждый шаг и реакция, новые агенты на базе больших языковых моделей (LLM), промптов и набора инструментов сами определяют, какие уточняющие вопросы задать клиенту, запоминают контекст диалога и автономно выбирают необходимый инструмент для решения задачи.</p> <p>Для разработчиков платформа предлагает современный визуальный интерфейс, отладку каждого элемента, систему версионности для безопасного отката изменений, а также гибкую настройку параметров LLM (температура, лимиты токенов и вызовов). Архитектура агентов теперь поддерживает создание пользовательских инструментов на Python, интеграцию через OpenAPI и подключение MCP-инструментов, что обеспечивает бесшовную стыковку с любыми корпоративными системами.</p> <p>Понимая, что не все бизнес-процессы готовы к полной передаче диалога нейросетям, и учитывая интересы заказчиков, предпочитающих проверенные и детерминированные сценарные решения, в DC 3.0 был существенно доработан базовый функционал:</p> <ul> <li>появилась возможность копировать созданные элементы (ноды) в другие ветки сценария, что ускоряет разработку;</li> <li>удаление целой ветки сценария теперь выполняется в несколько кликов, избавляя от необходимости удалять элементы поштучно;</li> <li>грамматика для транскрибации голосового ответа теперь задается один раз на уровне всего бота, а не в каждой отдельной ноде, что экономит часы рутинной работы;</li> <li>добавлена кнопка для копирования всей отладочной информации одним кликом, заменяющая неудобные скриншоты или ручной перенос данных.</li> </ul> <p>Отдельный блок улучшений коснулся ботов с архитектурой RAG (Retrieval-Augmented Generation). Изменения внедрены напрямую на основе обратной связи от клиентов. Система логирования стала прозрачнее: теперь можно анализировать время обработки запросов и строить статистику по наиболее востребованным документам. Кроме того, ИИ-ассистент теперь может предоставлять клиенту не только сформированный ответ, но и прямую ссылку на источник. Визуальная часть режима тестирования RAG также была переработана: отладочная информация структурирована по блокам и доступна для быстрого копирования.</p> <p>Кроме того, в DC 3.0 реализован механизм отслеживания количества одновременных текстовых и голосовых сессий прямо в интерфейсе платформы. Если ранее для анализа пиковых нагрузок и контроля лицензий инженерам приходилось вручную выгружать логи и запускать скрипты, то теперь эта аналитика доступна в режиме реального времени, что существенно повышает операционную эффективность команд внедрения и эксплуатации.</p> <p>«Выпуск Dialog Composer 3.0 — это знаковый переход от обычной автоматизации диалогов к запуску по-настоящему интеллектуальных цифровых сотрудников. Мы предлагаем среду простого создания ИИ-агентов, которые способны самостоятельно принимать решения, использовать внешние инструменты и опираться на историю взаимодействий. При этом мы сохранили и усилили классические no-code инструменты для тех клиентов, кому важна абсолютная предсказуемость сценарных ботов. Это тот самый баланс инноваций и надежности, который требует современный рынок», — отметил Александр Крушинский, директор департамента голосовых цифровых технологий компании BSS.</p> <p>Обновление Dialog Composer 3.0 подтверждает статус компании BSS, как одного из безусловных лидеров отечественного рынка в области разработки и внедрения речевых технологий, искусственного интеллекта, ИИ-агентов и мультиагентных систем. Предлагая бизнесу <nobr>CX-платформу</nobr> нового уровня, BSS не только задает технологические тренды, но и обеспечивает компаниям реальные инструменты для повышения качества клиентского опыта, снижения операционных затрат и ускорения цифровой трансформации.</p> Компания BSS дает мощный толчок развитию диалоговых интерфейсов с новой версией Dialog Composer 3.0. Ключевой … message https://www.itweek.ru/themes/detail.php?ID=235018 Wed, 17 Jun 2026 09:38:32 +0300 <p><em>Если мы хотим, чтобы агентный искусственный интеллект создавал совокупную ценность, мы должны сначала перепроектировать операционную модель, которая его окружает, пишет в корпоративном блоге Сэм Хиггинс, вице-президент и главный аналитик </em><em>Forrester</em><em>.</em></p> <p>Я люблю аксиомы, что-то легко запоминающееся, быстро произносимое и достаточно убедительное, чтобы остаться в памяти. Своим старшим сыновьям я часто говорил: «Если сомневаешься, не делай». Моему младшему сыну, у которого аутизм, я говорю: «Оставайся рядом; будь в безопасности». Это короткие фразы с большим смыслом, которые помогают в момент, когда времени мало, а ставки высоки.</p> <p>Вероятно, именно поэтому такие идеи, как закон Мура, закон Амары и закон Паркинсона, продолжают находить отклик у технологических лидеров. Они помогают нам придерживаться простых идей, когда мы осмысливаем внедрение, ценность и реализацию технологий в масштабе. Они помогают нам оставаться на верном пути и поддерживать наших сотрудников, когда нарастает ажиотаж в СМИ, презентации консультантов становятся все толще, а эксперты LinkedIn заполняют наши ленты уверенностью. И это подводит меня к закону Конвея.</p> <h3>Выбор платформы — не отправная точка</h3> <p>Я несколько раз в неделю провожу семинар для клиентов под названием «Преодоление препятствий на пути внедрения ИИ в масштабах организации». Недавно один из клиентов сказал: «Закон Конвея срабатывает каждый раз. Мы хотим внедрить системы, прежде чем заняться бизнесом... и каждый раз получаем тот же результат: системы оказываются такими же несовершенными, как и наши организации». Другими словами: начните с операционной модели и организационной структуры, а затем ориентируйте платформы на соответствующие области.</p> <p>Одна из главных ошибок в области ИИ сейчас — это убеждение, что ответ кроется в основном в выборе правильной платформы, модели или стека поставщика. Это не так. Если операционная модель неясна, фрагментирована или создана для более ранней эпохи работы, система ИИ унаследует эти недостатки и воспроизведет их со скоростью машины. Вот почему закон Конвея снова кажется таким актуальным: системы не выходят за рамки организаций — они их зеркалируют. А в эпоху агентного ИИ они усиливают худшие из их особенностей: разобщенность, политику и многое другое.</p> <h3>Начните с вашей организации и ваших людей</h3> <p>Этот момент лежит в основе наших исследований когнитивной операционной модели, интеллектуального предприятия и архитектуры, ориентированной на навыки. И основная предпосылка этих исследований — парадокс производительности ИИ: преимущества рассеиваются внутри операционных моделей, разработанных для работы, выполняемой исключительно людьми и основанной на задачах. Прикручивание агентов к вчерашним ролям, рабочим процессам и правам принятия решений — это эффективное с точки зрения маркетинга внедрение технологий компаниями, которым необходимо максимизировать оценку IPO, чтобы получить капитал, необходимый для подпитки денежной печи ИИ.</p> <p>Вот почему переход от генеративного ИИ к агентному ИИ так важен. Генеративный ИИ был разминкой: агентный ИИ меняет правила игры, потому что мы переходим от промптов к планам. Эти системы теперь извлекают информацию, принимают решения, запускают процессы, уведомляют и действуют. Это смещает акцент с качества результатов на управление, подотчетность, координацию и легитимность — особенно в государственном управлении, где объяснимость, справедливость и общественное доверие являются незыблемыми.</p> <h3>Почему важно изменение операционной модели</h3> <p>Если ваша операционная модель разрознена, фрагментирована, перегружена передачей задач и построена на исключительно человеческом понимании работы, ваша система ИИ будет отражать эту сложность. Агенты будут выбираться, развертываться и управляться в соответствии с теми же линиями разлома. Результат? Дублирование возможностей, фрагментированный контекст, непоследовательный контроль и точечные решения, маскирующиеся под трансформацию.</p> <p>Закон Конвея объясняет, почему сдвиг операционной модели так важен. По своей сути, агентный ИИ — это проблема архитектуры работы и шок для операционной модели. Если агенты все чаще становятся исполнителями рутинной когнитивной работы по умолчанию, то организация должна быть перестроена с учетом этой реальности. Роли, рабочие процессы, пути эскалации, управленческие предположения и модели подотчетности — все меняется. В противном случае, технология просто автоматизирует археологию современных предприятий.</p> <h3>Почему важны навыки и контекст</h3> <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> </ul> <p>Для меня в этом заключается современная ценность закона Конвея. В головокружительном вихре перемен, в котором мы находимся, если мы хотим, чтобы агентный ИИ создавал совокупную ценность, мы должны сначала перепроектировать операционную модель, которая его окружает. Вот почему наши текущие исследования так сосредоточены на структуре, контексте и перепроектировании самой работы. В противном случае мы не построим будущее работы — мы автоматизируем прошлое. Так что запомните: «Операционные модели обеспечивают результаты».</p> Если мы хотим, чтобы агентный искусственный интеллект создавал совокупную ценность, мы должны сначала перепроектировать … article https://www.itweek.ru/themes/detail.php?ID=235017 Wed, 17 Jun 2026 09:21:35 +0300 <p><em>Мультиагентные системы искусственного интеллекта уже вовсю работают в производственной среде, но кто за ними следит? Моше Бар, генеральный директор Codenotary, рассказывает на портале </em><em>The</em> <em>New</em> <em>Stack</em> <em>об операционных пробелах в отслеживании автономных агентов.</em></p> <p>За последние несколько месяцев произошли незаметные изменения. Фреймворки, такие как CrewAI, AutoGen и LangGraph, больше не просто появляются в демонстрациях — они работают в производственной среде.</p> <p>Команды объединяют планировщиков, использующих инструменты агентов, средства поиска и внешние API, а затем передают им реальную работу. Реагирование на инциденты, внутренние «вторые пилоты», конвейеры автоматизации — все это начинает выглядеть не как эксперименты, а как инфраструктура.</p> <p>И как только эти системы запускаются, проблемы становятся очевидными очень быстро. Не обычная проблема «LLM галлюцинируют». А что-то более операционное.</p> <p>Сейчас мы очень хорошо умеем создавать агентов, но не очень хорошо умеем ими управлять. Фреймворки упрощают компоновку, но они не дают реального контроля, когда все работает в масштабе.</p> <p>И этот пробел сразу же проявляется в производственной среде. Неприятная реальность заключается в том, что многие команды, развертывающие сегодня мультиагентные системы, работают с ними с меньшей прозрачностью, чем это было 10 лет назад при использовании микросервисов. Они доверяют результатам, не до конца понимая путь, который их породил.</p> <p>Это работает для демонстрации. Но это не работает, когда эти системы начинают взаимодействовать с реальными данными, реальными пользователями и реальными деньгами.</p> <p>На самом деле ломается сама система. Запрос, который должен занимать один или два шага, превращается в десятки вызовов модели. Агенты взаимодействуют друг с другом, повторяя попытки, перефразируя, зацикливаясь ровно настолько, чтобы оставаться работоспособными, но недостаточно эффективными. Задержка увеличивается. За этим следуют затраты. Ничего не падает, поэтому и оповещения не срабатывают. Вы просто замечаете, что что-то идет не так...</p> <p>Или, что еще хуже, кажется все работает, но ответ немного неверен. Один агент выдает ошибку по таймауту, другой компенсирует ее, третий заполняет пробелы частичным контекстом. К тому времени, как вы увидите результат, ошибка уже где-то глубоко запрятана в цепочке решений, которые трудно восстановить.</p> <p>А затем есть данные. Нет ни одной очевидной утечки, но происходит их постепенное распространение. Один агент читает конфиденциальную информацию, другой её резюмирует, третий включает её в запрос к внешней модели. Ни в какой момент ничего не выглядит явно опасным, однако система в целом выходит за рамки, за которые не должна выходить.</p> <p>Общая нить здесь в том, что никто на самом деле не видит, что происходит.</p> <p>Большинство команд пытаются использовать уже имеющиеся инструменты. Журналы, трассировки, возможно захват запросов. Это помогает в крайних случаях, но не отвечает на основной вопрос: как система на самом деле пришла к такому результату?</p> <p>Агентные системы — это не просто распределенные системы с большим количеством вызовов API. Они ведут себя скорее как развивающиеся графы выполнения, где решения принимаются динамически, а пути меняются в зависимости от промежуточных результатов. Наблюдение за отдельными вызовами похоже на просмотр одного кадра стека и попытку вывести всю программу целиком.</p> <p>Чего не хватает, так это видимости на уровне, где эти системы фактически работают.</p> <p>Необходимо видеть, как запрос разворачивается между агентами, насколько глубока цепочка рассуждений, где она разветвляется и где зацикливается сама на себе. Необходимо понимать не только то, что токены были израсходованы, но и почему их количество продолжало расти на разных этапах. Необходимо отслеживать движение данных — не только их исходное состояние, но и то, как они трансформировались и куда в конечном итоге попали.</p> <p>Без этого отладка сводится к симптомам. Медленная реакция здесь, завышенный счет там, случайный неправильный ответ. Основное поведение остается неясным.</p> <p>Особенно интересно то, что эти системы со временем формируют закономерности. Хотя они и не детерминированы, они и не случайны. Определенные потоки становятся распространенными, определенная глубина рассуждений — типичной. Эта базовая линия невероятно полезна, потому что реальный сигнал поступает, когда система отклоняется от нее. Когда агент внезапно выбирает путь, по которому он никогда раньше не ходил, или начинает получать доступ к данным, к которым обычно не обращался, или расширяет цепочку рассуждений далеко за пределы ее обычной формы.</p> <p>Вот где должен находиться мониторинг — не в статических правилах, а в достаточно глубоком понимании нормального поведения системы, чтобы распознавать отклонения.</p> <p>Вопрос не в том, нужен ли агентам мониторинг. Вопрос в том, готовы ли мы относиться к ним как к системам, которыми они уже стали.</p> <p>Сейчас большинство из нас не готовы, и это нужно исправить.</p> Мультиагентные системы искусственного интеллекта уже вовсю работают в производственной среде, но кто за ними … article https://www.itweek.ru/themes/detail.php?ID=235015 Tue, 16 Jun 2026 09:40:46 +0300 <p><em>Новый <a href="https://www.linuxfoundation.org/hubfs/Research%20Reports/State-of-Tech-Talent-Europe-2026-REV-1.pdf">отчет</a> </em><em>Linux</em> <em>Foundation</em><em> «</em><em>2026 </em><em>State</em> <em>of</em> <em>Tech</em> <em>Talent</em> <em>Europe</em> <em>Report</em> <em>показывает», что искусственный интеллект способствует 27%-ному росту найма в сфере технологий в Европе, даже несмотря на сокращение числа вакансий для начинающих специалистов как растущей глобальной тенденции, сообщает портал </em><em>The</em> <em>New</em> <em>Stack</em><em>.</em></p> <p>Влияние ИИ на мировую рабочую силу ощущается во всех отраслях, но, пожалуй, нигде это не проявляется так остро, как в разработке ПО и в технологическом секторе в целом.</p> <p>Такие компании, как OpenAI и Google, уже переосмысливают представление о руководящих технических должностях: FDE (<strong>Forward Deployed Engineer</strong><strong>s</strong><strong>, </strong>инженеры по передовому внедрению) — технические специалисты широкого профиля, которые выступают посредниками между моделью ИИ и заказчиком, преобразуя сложные возможности в работающие решения, — становятся одними из самых востребованных в отрасли.</p> <p>В других областях возникают проблемы с проверкой кода, сгенерированного ИИ, что меняет повседневную работу инженерных команд. А вакансии для начинающих программистов — традиционный путь в карьеру в сфере ПО — выглядят все более нестабильными.</p> <p>Новый отчет Linux Foundation проливает некоторый свет на то, что часто обсуждается без фактических данных, и картина выглядит гораздо сложнее, чем принято считать.</p> <h3>Сокращение числа начинающих специалистов</h3> <p>Linux Foundation опросил почти 400 менеджеров по найму и обучению на европейском и других крупных рынках и обнаружил, что ИИ приводит к чистому увеличению найма технических специалистов на 27% в Европе. Но эта цифра скрывает нечто важное: в европейских организациях наблюдается тенденция к сокращению числа начинающих специалистов на 3%, хотя в остальном мире эта категория выросла на 14%.</p> <p>В отчете не дается однозначного объяснения того, почему Европа может отставать от остального мира в вопросах найма молодых специалистов, но отмечается, что Старый Свет отстает по ряду более широких показателей готовности к внедрению ИИ, включая меньшее развертывание основной инфраструктуры ИИ, более острую нехватку персонала в сфере кибербезопасности и более медленное внедрение технологического стека, лежащего в основе производственного ИИ.</p> <p>Тьерри Каррез, генеральный директор Linux Foundation Europe, связывает вопрос о талантах с более широким стремлением к технологической независимости Европы — движением, охватывающим все, от облачной инфраструктуры и разработки ИИ до суверенитета данных и стремления к снижению зависимости от крупных технологических компаний.</p> <p>«Цифровой суверенитет невозможен без местных технических специалистов, — говорит он. — ИИ меняет все. Модели продолжают расти в своих возможностях, и их влияние на рынок технических специалистов необходимо должным образом оценить».</p> <p>Хотя распространилось мнение, что ИИ уничтожает технологические должности начального уровня, Сеад Ахметович, генеральный директор и соучредитель глобальной платформы для найма разработчиков и проведения мероприятий WeAreDevelopers, утверждает, что реальность гораздо сложнее. По его словам, что паника по поводу сокращения найма начинающих специалистов не отражает реальной ситуации: «Должности начального уровня не исчезают, но исчезает работа, которая их определяла. ИИ теперь выполняет многие задачи, на которых обучались начинающие разработчики, поэтому старое определение роли джуниора устаревает. Новое определение выглядит совершенно иначе и требует другого набора навыков с первого дня».</p> <p>Авторы отчета сами признают это, отмечая, что если тенденция к сокращению сохранится, это, вероятно, будет отражать поглощение ИИ задач, которые традиционно служили отправной точкой для начала карьеры.</p> <p>«Организации могут сокращать набор джуниоров, одновременно увеличивая спрос на должности мидлов и сеньоров, требующие умения принимать решения, контекстного мышления и контроля над системами ИИ», — говорится в отчете, что поднимает вопросы о том, как необходимо переосмыслить саму роль джуниора, прежде чем можно будет перестроить кадровый резерв.</p> <p>Проще говоря, возможно, европейской индустрии просто нужно время, чтобы наверстать упущенное — компании медленнее переосмысливают эти роли, чем ИИ их замещает.</p> <h3>Вверх по стеку </h3> <p>Давление на навыки не ограничивается младшим сегментом рынка. В отчете Linux Foundation говорится, что почти две трети европейских организаций заявляют о значительных пробелах в компетенциях в области безопасности ИИ и управления ИИ-рисками. Эта сфера вызвала наибольшее беспокойство в ходе опроса, опередив пробелы в технических ИИ-навыках. Также растет спрос на кросс-доменных специалистов, и такое сочетание находится в дефиците на любом уровне — тенденция, которую, по словам Ахметовича, он видит непосредственно в процессе найма.</p> <p>«Настоящая проблема — это дефицит квалифицированных кадров, и он затрагивает все уровни, — говорит он. — В сфере технологий всех продвигают вверх по стеку. Компаниям нужны люди, которые сочетают в себе навыки разработки ПО, владение ИИ, осведомленность в вопросах безопасности, продуктовое мышление и понимание бизнеса, а такое сочетание редко встречается на любом уровне».</p> <p>Этот профиль — технически подкованный специалист широкого профиля, разбирающийся в разработке, ИИ и бизнес-контексте — уже становится одной из самых востребованных ролей в сфере технологий, и наиболее ярким примером является FDE: роль, находящаяся на стыке глубоких технических знаний и навыков работы с клиентами.</p> <p>Финтех-гигант Ramp внедряет эту модель на уровне новой услуги: компания направляет собственных инженеров непосредственно в финансовые команды клиентов для создания и развертывания агентов ИИ — ставка на то, что разрыв между возможностями ИИ и реальным внедрением может быть преодолен только с помощью человеческой экспертизы на местах. Ори Дэниел, возглавляющий новый сервис Ramp, говорит, что импульсом послужило одно ключевое наблюдение: «Узким местом оказалась не сама модель, а кропотливая предварительная работа, которая должна быть проделана, чтобы сделать данные и бизнес-контекст понятными для агентов».</p> <h3>Проблема конвейера</h3> <p>Однако всё это не решает вопрос о специалистах начального уровня. В отчёте установлено, что организации в 3,7 раза чаще инвестируют в обучение существующих сотрудников, чем в найм новых, и что когда они всё же нанимают новых сотрудников, тем требуется более чем вдвое больше времени, чтобы стать полностью продуктивными. В краткосрочной перспективе становится всё сложнее оправдать экономическую целесообразность привлечения джуниоров, даже несмотря на то, что долгосрочная потребность в таком кадровом резерве остаётся неизменной.</p> <p>Аргумент Ахметовича заключается в том, что формулировка вопроса как бинарного — нанимать джуниоров или нет — совершенно неверна. «Остается верным утверждение, что невозможно вырастить сеньора, не наняв сначала джуниора, — говорит он. — Разумный ответ заключается не в сокращении кадрового резерва молодых специалистов, а в его перепроектировании. Необходимо быстрее повышать квалификацию сотрудников и создавать более четкий путь от специалистов начального уровня к реальным инженерным обязанностям».</p> <h3>Как на самом деле выглядит новая роль джуниора</h3> <p>Данные Linux Foundation указывают на то, что среди европейских организаций инвестиции в техническое обучение занимают более высокое место, чем компенсация как инструмент удержания персонала, это отметили 93% респондентов. Аппетит к разработке есть. Чего не хватает, так это четкого представления о том, как на самом деле выглядит новая роль джуниора, и понимания срочной необходимости создания программ обучения, соответствующих направлению развития отрасли, прежде чем разрыв между существующими должностями и людьми, способными их занять, станет сложнее преодолеть.</p> <p>Стоит отметить, что к этим выводам следует относиться с некоторой осторожностью. Опрос в значительной степени опирается на организации, уже активно занимающиеся внедрением Open Source и ИИ — эта группа, вероятно, сообщает о более позитивных результатах, чем рынок в целом. Отчет отражает то, как относительно вовлеченные в ИИ компании ожидают развития процесса найма, а не то, как, вероятно, будет развиваться европейский рынок труда в сфере технологий в целом.</p> Новый отчет Linux Foundation «2026 State of Tech Talent Europe Report показывает», что искусственный интеллект способствует … article https://www.itweek.ru/themes/detail.php?ID=235013 Tue, 16 Jun 2026 09:11:29 +0300 <p><em>В 2026 г. разработка ПО вышла на новый рубеж. Генеративный искусственный интеллект больше не просто помогает разработчикам быстрее писать код; он меняет подход к планированию, созданию, тестированию и поставке ПО, пишет в корпоративном блоге Диего Ло Джудиче, вице-президент и главный аналитик </em><em>Forrester</em><em>.</em></p> <p>Недавний отчет Forrester «The State Of Agentic Software Development, 2026», показывает, что боты TuringBots теперь становятся агентами, а не просто ИИ-помощниками, встроенными в отдельные инструменты. Новой нормой является разработка ПО с использованием автономных агентов, которые сотрудничают на протяжении всего жизненного цикла разработки программного обеспечения (SDLC), стремясь к более сквозной автоматизации.</p> <p>Этот сдвиг важен, потому что изолированного повышения индивидуальной производительности уже недостаточно. Технологические лидеры находятся под давлением: от них требуют добиваться более быстрых и безопасных результатов, не увеличивая штат сотрудников и не повышая риски. Агентные подходы становятся единственным надежным способом достичь и того, и другого.</p> <h3>От TuringBots к агентному SDLC</h3> <p>Эволюцию лучше всего представить как три фазы (см. рисунок ниже).</p> <p> #IMAGE_235014#</p> <p>В течение 2023 и 2024 гг. TuringBots в основном были сфокусированы на кодировании и модульном тестировании. В <nobr>2025-м</nobr> эти возможности расширились на смежные задачи, такие как документирование, помощь в проектировании и генерация тестов. Сейчас, в 2026 г., мы видим настоящий переломный момент: агенты теперь работают на всех этапах: анализ и планирование, проектирование, разработка, тестирование и доставка — и все чаще координируются между собой.</p> <p>Вместо того чтобы просить один инструмент генерировать код, команды теперь могут делегировать задачи («создать данную функцию»), в то время как агенты декомпозируют работу, генерируют артефакты, запускают тесты и готовят релизы. Люди остаются ответственными, тогда как ИИ выполняет большую часть работы.</p> <h3>Без сквозного внедрения ИИ повышение производительности будет разочаровывающим</h3> <p>Многие компании разочарованы первыми результатами, потому что они применяют ИИ слишком узко. Кодирование может улучшиться на <nobr>30-40%,</nobr> но если планирование, тестирование и выпуск остаются ручными, общая производительность команды часто увеличивается менее чем на 10%. Узкие места просто перемещаются. Агентная разработка ПО меняет математику. Когда ИИ применяется последовательно на протяжении всего SDLC, преимущества накапливаются, а не компенсируют друг друга. Именно поэтому ведущие разработчики переходят от точечных инструментов к агентным платформам, которые координируют работу множества специализированных агентов, вместо того чтобы сосредотачиваться только на генерации кода.</p> <h3>Роли разработчиков ПО не исчезнут, но они будут эволюционировать</h3> <p>Агентная разработка не устранит разработчиков, тестировщиков или архитекторов, но она изменит представление о том, что значит «хорошо» для каждой из этих ролей.</p> <ul> <li><strong> Менеджеры/владельцы продуктов</strong> «вайбят» прототипы и функции для остальной командой для внедрения в продукт. Они также генерируют спецификации, что позволяет осуществлять разработку, основанную на спецификациях.</li> <li><strong> Разработчики</strong> меньше пишут код и тратят больше времени на проверку, руководство и координацию работы агентов по кодированию. По мере совершенствования ИИ и роста доверия к нему они будут писать и проверять минимальное количество кода, если вообще будут это делать.</li> <li><strong> Тестировщики</strong> переходят от написания скриптов тестов к установлению целей по качеству и контролю за агентами тестирования, включая тестирование самих систем ИИ.</li> <li><strong> Архитекторы и старшие инженеры</strong> уделяют больше внимания проектированию системы, ограничениям и контекстной инженерии — обеспечивая работу агентов в рамках заданных границ.</li> </ul> <p>Во всех ролях критически важным навыком является не только техническая глубина, но и способность четко определять намерения, контекст и ограничения для ИИ-коллег.</p> <h3>Тестирование и управление станут более, а не менее важными</h3> <p>По мере роста автономности доверие становится ограничивающим фактором. Агентные системы могут выдавать галлюцинации, вносить незаметные дефекты или распространять ошибки быстрее, чем это когда-либо могли бы сделать люди. Именно поэтому тестирование становится более, а не менее важным в агентном SDLC.</p> <p>Ведущие организации инвестируют и переходят от TuringBots к агентной разработке ПО и теперь относятся к артефактам, созданным ИИ, с той же или даже большей строгостью, что и к коду, написанному человеком. В то же время управление должно масштабироваться по мере роста внедрения. Прежде чем расширять автономность агентов в производственных системах, необходимо обеспечить защитные механизмы, возможность аудита и четкую ответственность человека.</p> <h3>Что должны делать технологические лидеры сейчас</h3> <p>Для CIO, CTO и вице-президентов по инжинирингу <nobr>2026-й —</nobr> это год перехода от экспериментов к целенаправленному внедрению. Вот четыре ключевых шага, которые вы должны предпринять уже сейчас:</p> <ol> <li><strong> Проведите пилотные проекты на нескольких этапах SDLC,</strong> смещая применение ИИ на более ранние и более поздние этапы, а не только используя его в процессе кодирования, чтобы выявить реальные узкие места и преимущества.</li> <li><strong> Развивайте операционные модели и роли, </strong>четко определяя, как взаимодействуют люди и агенты.</li> <li><strong> Инвестируйте в тестирование и управление ИИ на ранних этапах,</strong> включая тестирование приложений с ИИ и самих агентов.</li> <li><strong> Сосредоточьтесь на платформах агентной разработки, а не на инструментах,</strong> отдавая предпочтение платформам, которые координируют и обеспечивают оркестровку агентов от начала до конца.</li> </ol> <p>Агентная разработка ПО больше не является концепцией будущего. Она становится доминирующей моделью для высокоэффективных команд разработчиков. Лидерами, которые добьются успеха в 2026 г., станут те, кто будет рассматривать агентов не как умных помощников, а как первоклассных участников в перестроенном, сжатом SDLC — с человеком, твердо контролирующим ситуацию.</p> В 2026 г. разработка ПО вышла на новый рубеж. Генеративный искусственный интеллект больше не просто … article https://www.itweek.ru/themes/detail.php?ID=235012 Mon, 15 Jun 2026 16:39:20 +0300 <p>Система аудита и защиты файловых хранилищ (DCAP) «СёрчИнформ Файловый Аудитор» поддержала новый источник данных. Теперь решение может проводить аудит корпоративного облачного рабочего пространства Google Workspace.</p> <p>Решение сканирует хранилища Google Drive внутри Google Workspace и присваивает документам метки в зависимости от содержимого: «Персональные данные», «Договоры с клиентами», «Файлы с паролями» и т.д. Затем ИБ-специалист может отследить историю их изменений и расследовать инциденты, связанные с нежелательными действиями пользователей. Также «СёрчИнформ Файловый аудитор» может сохранять теневые копии файлов в собственной базе, чтобы уберечь их от нежелательных правок и потери.</p> <p>Аудит корпоративных облачных пространств позволяет находить в них документы, требующие защиты, и проверять, соответствует ли работа сотрудников с ними правилам безопасности. Это облегчает расследования и помогает создать единые политики защиты критичных данных независимо от места их хранения.</p> <p>«Облачные рабочие пространства прочно вошли в практику компаний, особенно если сотрудники распределены по разным городам или странам, — прокомментировал Алексей Парфентьев, заместитель генерального директора по инновационной деятельности „СёрчИнформ“. — Люди загружают туда документы, правят их, пересылают ссылки коллегам. Без контроля в таком хаосе легко потерять критичные данные или случайно открыть к ним доступ посторонним. Поэтому мы выстроили защиту на двух уровнях: „СёрчИнформ Файловый аудитор“ следит за порядком внутри хранилищ — как локальных, так и облачных, в том числе Google Workspace — а система защиты от утечек информации (DLP) „СёрчИнформ КИБ“ контролирует, чтобы файлы с конфиденциальными данными не покидали корпоративный периметр».</p> <p>«СёрчИнформ» продолжает расширять список поддерживаемых облачных бизнес-сервисов. «Файловый Аудитор» контролирует файлы в Jira и Confluence, совместно с КИБ интегрирован с облачными пространствами «Мой Офис», VK Workspace, Яндекс 360, Microsoft 365, в том числе отслеживает перемещение документов из «закрытых» папок в общий доступ.</p> Система аудита и защиты файловых хранилищ (DCAP) «СёрчИнформ Файловый Аудитор» поддержала новый источник данных. Теперь … message https://www.itweek.ru/themes/detail.php?ID=235011 Mon, 15 Jun 2026 16:37:08 +0300 <p>«Тантор Лабс» представила новую версию Платформы Tantor 6.4, решения для централизованного администрирования, мониторинга и эксплуатации PostgreSQL-инфраструктуры. Обновление включает расширенные возможности аналитики и мониторинга, поддержку используемой в машине баз данных Tantor XData Gen3 СУБД Tantor Polar, улучшения ИИ-ассистента и дальнейшее развитие средств администрирования и безопасности.</p> <p>ИИ-ассистент Платформы получил поддержку подключения к внешним OpenAI-совместимым серверам через настройку LLM_BASE_URL, ключа API и модели. Кроме того, улучшен поиск по базе знаний: теперь используются гибридный поиск BM25 + vector search, переписывание пользовательских запросов и reranker-модель для повышения релевантности ответов ассистента.</p> <p>В новой версии Платформы Tantor появилась история изменений конфигурации для одиночных экземпляров и Patroni-кластеров. Платформа фиксирует измененные параметры, старые и новые значения, файл конфигурации, дату изменения, пользователя и источник операции. Для синхронизации с группами конфигураций отображается список затронутых параметров. Историю можно просматривать в виде списка или сгруппированного журнала и при необходимости быстро откатывать изменения. Новый механизм упрощает аудит и анализ причин изменения настроек.</p> <p>Платформа получила сразу несколько улучшений в области мониторинга: тепловые карты бэкапов с визуализацией успешных и проблемных резервных копий за период до одного года, тепловые карты сработавших алертов по дням для анализа инцидентов и повторяющихся проблем, возможность временно отключать уведомления по отдельным триггерам без остановки самого мониторинга, массовое закрытие алертов с единым комментарием и историю потребления памяти SQL-запросами в разделе текущей активности. Новые инструменты позволяют быстрее анализировать состояние инфраструктуры и снижать нагрузку на команды эксплуатации.</p> <p>Одним из ключевых нововведений стала поддержка СУБД Tantor Polar — распределенной СУБД на базе PostgreSQL, построенной на архитектуре разделения вычислений и хранилища (применяется в представленной в апреле 2026 г. машине баз данных Tantor XData Gen3). Платформа теперь отображает топологию Compute-, Proxy- и Storage-узлов Polar-кластера, а также предоставляет данные по активности, ролям и состоянию компонентов через интерфейс и API. Для СУБД Tantor Polar используются отдельные типы метрик, что позволяет полноценно администрировать такие кластеры в едином контуре управления.</p> <p>В Query Profiler добавлен мастер автоконфигурации расширенной аналитики. Платформа автоматически проверяет состояние экземпляра, предлагает необходимые параметры PostgreSQL и инициализирует нужные расширения. Реализован автоматический перерасчет рекомендаций при изменении параметра max_connections. Связанные настройки, включая work_mem и temp_buffers, пересчитываются автоматически с учетом актуального количества соединений.</p> <p>В версии 6.4 расширены возможности интеграции с LDAP и Active Directory. Так, обеспечена поддержка нескольких LDAP/AD-подключений в рамках одного tenant, реализована изоляция пользователей и групп между LDAP-профилями, добавлена поддержка tls skip verify для LDAPS-подключений с внутренними или самоподписанными сертификатами. Появилась интеграция с YCHAT как новым каналом уведомлений: сообщения алертов отправляются в markdown-формате и содержат ключевую информацию о событии.</p> <p>В DB Browser появилась возможность создавать базы данных напрямую из интерфейса платформы. В составе pg_anon реализованы импорт и экспорт словарей анонимизации, а также обновлена версия самого расширения для повышения совместимости с новыми версиями СУБД.</p> <p>В новой версии значительно переработан раздел Overview. Теперь на одной странице доступны карточки с ключевыми метриками: сессии, QPS/TPS, среднее время запроса, CPU, RAM, block I/O, WAL, автовакуум, хранилище, топ-запросы и другие показатели. Виджеты, мини-графики и alert-статусы используют унифицированную стилистику, проблемные зоны подсвечиваются без необходимости переходить в детализированные разделы. Загрузка данных в виджетах выполняется по требованию, что заметно ускоряет отображение страницы и повышает отзывчивость системы. Дополнительно в разделе управления доступом появилась подсветка пересечений и конфликтов правил pg_hba.conf, включая дублирующиеся записи и некорректные диапазоны.</p> <p>«Платформа Tantor — многолетний технологический лидер среди продуктов для управления корпоративными СУБД, и в версии 6.4 мы сделали акцент на улучшениях ИИ-ассистента, развитии эксплуатационной аналитики и повышении удобства администрирования крупных PostgreSQL-инфраструктур. Поддерживается и новая СУБД Tantor Polar, реализующая уникальную для российского рынка возможность горизонтального масштабирования без шардирования и без потери совместимости с PostgreSQL, расширениями и бизнес-приложениями, включая 1С», — отметил генеральный директор Вадим Яценко.</p> «Тантор Лабс» представила новую версию Платформы Tantor 6.4, решения для централизованного администрирования, мониторинга … message https://www.itweek.ru/themes/detail.php?ID=235009 Mon, 15 Jun 2026 16:36:16 +0300 <p>Институт статистических исследований и экономики знаний (ИСИЭЗ) НИУ ВШЭ выделил с помощью системы анализа больших данных iFORA приоритетные технологии, меняющие облик металлургической промышленности.</p> <p>Наиболее высокий индекс значимости в проанализированном массиве источников имеют аддитивные технологии (№ 1 в рейтинге). Из инструмента быстрого прототипирования металлических изделий они постепенно превратились в одно из ключевых направлений развития современной металлургии. С их помощью производят заготовки, близкие к конечному изделию по форме и размерам, а также детали сложной геометрии, недоступной для традиционных методов литья. Широкое применение в аддитивном производстве получило лазерное сплавление в порошковом слое (powder bed fusion) (№ 4), используемое при изготовлении сложных компонентов для аэрокосмической и автомобильной промышленности, биомедицины и других высокотехнологичных сфер.</p> <p>Другим важным вектором технологического развития металлургии является создание новых типов сплавов. Альтернативой традиционным становятся высокоэнтропийные сплавы (№ 5), получаемые путем сочетания нескольких основных элементов в значительных концентрациях. Суперсплавы (№ 6) используются в изделиях и конструкциях, эксплуатируемых в экстремальных условиях. Высокопрочная сталь (№ 7), относящаяся к классу конструкционных сталей с улучшенными характеристиками, обеспечивает оптимальный баланс прочности, свариваемости, пластичности и коррозионной стойкости. Благодаря такому набору характеристик она востребована в разных сферах, включая автомобильную промышленность, производство промышленного оборудования и инфраструктурные проекты. Среди перспективных новых материалов выделяются металлогидриды (№ 9). Их применяют прежде всего в технологиях хранения и транспортировки водорода благодаря способности его удерживать в кристаллической структуре, а также в некоторых металлургических и химико-технологических процессах, например, в очистке металлов.</p> <p>Растущий спрос на более качественные материалы и конкуренция со стороны композитов стимулируют развитие оборудования, позволяющего выпускать продукцию с требуемыми характеристиками при меньших затратах. Электрометаллургия и электродуговые печи (№ 8) стали стандартом выплавки стали, постепенно вытесняя традиционные мартеновские печи. Благодаря внедрению новых типов электродуговых печей можно получать металл высокой чистоты, а также увеличивать степень автоматизации и экологичности производства.</p> <p>По мере усложнения производственных процессов в металлургии и усиления требований к качеству продукции растет потребность в инструментах мониторинга и контроля на разных этапах производства и эксплуатации изделий. Для этих задач все шире используются цифровые двойники (№ 2). В частности, их применяют для анализа деформаций стальных конструкций. С помощью технологий предиктивного обслуживания (№ 10) на основе искусственного интеллекта можно в режиме реального времени анализировать данные промышленных датчиков, оценивать состояние оборудования, в целом оптимизировать техническое обслуживание. Среди методов исследования структуры и состава металлов и сплавов важное место занимает рентгеновская дифракция (№ 3). В последние годы активно развивается энергодисперсионная рентгеновская дифракция и другие модификации метода.</p> <p>Металлургия, одна из старейших отраслей промышленности, проходит через комплексную технологическую трансформацию. Ее проявления затрагивают различные этапы производственного процесса: от разработки новых материалов и сплавов до внедрения высокотехнологичного оборудования и цифровых инструментов мониторинга и управления. В совокупности эти изменения способствуют повышению эффективности производства, обеспечивая контроль качества и сокращение издержек.</p> Институт статистических исследований и экономики знаний (ИСИЭЗ) НИУ ВШЭ выделил с помощью системы анализа больших … message https://www.itweek.ru/themes/detail.php?ID=235007 Mon, 15 Jun 2026 16:34:52 +0300 <p>ЦСР впервые представил исследование рынка средств защиты «конечных точек» в России, охватывающее перспективы его развития до 2031 года.</p> <p>Заместитель генерального директора ЦСР Екатерина Кваша отметила: «Российский рынок средств защиты конечных точек (Endpoint Security) сохраняет устойчивую положительную динамику и остается одним из крупнейших сегментов рынка средств защиты информации. По итогам 2025 года его объем превысил 40 млрд рублей, увеличившись на 14,9% год к году, что сопоставимо с общемировыми темпами роста данного класса решений. Ожидаем, что до 2031 года российский рынок Endpoint Security вырастет до 78,3 млрд рублей при среднегодовом темпе роста 11,3%».</p> <p>EPP-решения остаются крупнейшей категорией рынка и формируют основную часть выручки производителей, однако наиболее быстро растущим направлением является категория EDR. Ожидается, что его доля составит 26 млрд руб. в 2031 году против 7,3 млрд руб. в 2025 году, т.е. вырастет в 3,5 раза. Рост ЕРР-решений составит 59,5% (32,8 млрд руб. и 52,3 млрд руб. в 2025 и 2031 годах соответственно). Это отражает общий сдвиг спроса от базовой превентивной защиты к более сложным сценариям обнаружения, расследования и реагирования на атаки на рабочих станциях, серверах, удаленных рабочих местах и других конечных узлах.</p> <p>Доля иностранных решений в новых продажах упала с 26% в 2021 году до 4,6% в 2025 году. Пять ведущих игроков теперь полностью российские. В сфере Endpoint Security традиционно лидируют «Лаборатория Касперского» и Dr.Web. Постепенно формируется сильная группа российских компаний, таких как Positive Technologies, BI.ZONE, «Код Безопасности», F6 и другие, которые стремятся занять ведущие позиции, особенно в свете тенденции к платформизации информационной безопасности.</p> <p>Развитие рынка будет поддерживаться несколькими долгосрочными факторами: усложнением угроз, ростом требований к киберустойчивости компаний, развитием MDR- и SOC-as-a-Service-моделей, регуляторным давлением, распространением облачных и гибридных инфраструктур, а также появлением новых рисков, связанных с внедрением искусственного интеллекта и усложнением управления доступами в корпоративной среде. Требования к защите персональных данных, ГИС, КИИ и иных систем фактически предполагают наличие механизмов защиты от вредоносного ПО, контроля запуска программ и устройств, регистрации и анализа событий, выявления атак, реагирования на инциденты и восстановления работоспособности. Дополнительное значение имеет обновление требований ФСТЭК, усиливающее роль мониторинга и реагирования на уровне конечных устройств.</p> ЦСР впервые представил исследование рынка средств защиты «конечных точек» в России, охватывающее перспективы его развития … message https://www.itweek.ru/themes/detail.php?ID=235006 Mon, 15 Jun 2026 16:33:22 +0300 <p>Экспертно-аналитический центр (ЭАЦ) ГК InfoWatch представил отчёт по результатам исследования мировых тенденций в сфере обеспечения безопасности облачной и гибридной инфраструктуры. Как отмечают аналитики, вместе с ростом облачных мощностей растет внимание злоумышленников к ним — каждая четвертая атака в мире приходится именно на облака. При этом человеческий фактор по-прежнему играет важную роль и с точки зрения защиты, и как потенциальная уязвимость.</p> <p>Специалисты ЭАЦ InfoWatch отмечают, что в концепциях защиты сетей предприятий происходят фундаментальные изменения. 82% организаций поддерживают гибридную инфраструктуру, объединяющую локальные центры обработки данных с общедоступными облаками. И хотя эта модель обеспечивает гибкость и масштабируемость, она также разрушает традиционные сетевые границы, создавая сложную сеть соединений, которую трудно отслеживать и защищать, подчеркивают аналитики.</p> <p>«Пользователи и приложения выходят за пределы традиционного сетевого периметра — 53% облачных рабочих нагрузок в мире размещаются на общедоступных облачных платформах, что на 8% больше, чем в прошлом году. Вместе с тем, наблюдается резкое увеличение интенсивности атак на облачные и гибридные инфраструктуры. Злоумышленники хорошо осведомлены об облачных средствах защиты и все чаще используют тактики их обхода, чтобы как можно дольше оставаться незамеченными и извлечь максимум выгоды из атаки», — отметил главный аналитик ЭАЦ InfoWatch Сергей Слепцов.</p> <p>По данным компании SentinelOne, которые аналитики приводят в исследовании, сегодня каждая четвертая кибератака в мире (25%) приходится на облачную инфраструктуру. Число атак растет в среднем на 21% в годовом исчислении, причем Россия по этому показателю опережает зарубежные страны — в нашей стране рост числа атак на облачные и гибридные инфраструктуры в 2025 году составил 30%. Самый большой интерес для злоумышленников представляют российские ИТ и телеком — на компании этой отрасли пришлось 26% атак, на втором месте финансы (19%), замыкают тройку сферы торговли и электронная коммерция (14%). Также в пятерке самых привлекательных целей промышленные предприятия (12%) и медицинские организации (9%).</p> <p>Специалисты ЭАЦ InfoWatch обращают внимание, что злоумышленники хорошо понимают проблемные точки гибридной инфраструктуры, где многие функции не просто не устраняют существующие угрозы, а увеличивают их.</p> <p>«Атакующие не видят разделения между локальным центром обработки данных и облачной средой — они видят единую расширенную сеть. Их стратегии все чаще предполагают „межсредовую интеграцию“, то есть закрепление в менее защищенной облачной среде с последующим переходом к критически важным локальным системам. Обнаружение злоумышленников становится все более проблематичным из-за пробелов в видимости, присущих гибридным инфраструктурам. В том числе поэтому сегодня высокий процент облачных взломов остается незамеченным в течение нескольких месяцев, а время ожидания обнаружения иногда превышает 200 дней», — подчеркнул Сергей Слепцов.</p> <p>Методы защиты тоже совершенствуются — на первый план выходит повсеместное использование принципа нулевого доверия, платформенных решений в области безопасности и межсетевых экранов нового поколения, микросегментация и непрерывный мониторинг сети, активное применение технологий ИИ для защиты и повышенное внимание к безопасности приложений. При этом текущих мер явно недостаточно — по данным Cloud Security Report 2025 от Trend Micro, только 25% компаний в мире доверяют своим инструментам обнаружения сложных угроз.</p> <p>«Одно из главных препятствий на пути внедрения эффективных решений в области безопасности облачных и гибридных инфраструктур — это отсутствие достаточного числа квалифицированных специалистов. Причем как по информационной безопасности в целом, так и в сфере противодействия угрозам в облачных и гибридных средах в частности. Около трех четвертей компаний испытывают нехватку специалистов в области облачной безопасности, эта тенденция прослеживается и в России, и в мире. И это одна из важнейших проблем, которую предстоит решать как в рамках отдельных предприятий, так и на национальном уровне в целом», — заключил Сергей Слепцов.</p> Экспертно-аналитический центр (ЭАЦ) ГК InfoWatch представил отчёт по результатам исследования мировых тенденций … message https://www.itweek.ru/themes/detail.php?ID=235005 Mon, 15 Jun 2026 16:24:27 +0300 <p>PlatformCraft, технологическая платформа ООО «ПК», объявила о запуске холодного объектного хранилища PC-Storage для файлов, к которым редко обращаются, но которые важно хранить долго, надежно и с понятной экономикой. Новый формат дополняет уже доступное в PlatformCraft горячее хранилище и дает компаниям возможность разделить активно используемые данные и архивный контур.</p> <p>Среди базовых сценариев:</p> <ul> <li>хранение архивов, в том числе медиаконтента (исходников, фото- и видеоматериалов, рекламных креативов), которые нужны для юридического хранения, повторного использования или редкого доступа по запросу;</li> <li>размещение резервных копий, закрытых проектных материалов и технических архивов, к которым команда обращается не постоянно, но должна иметь возможность быстро найти их при необходимости.</li> </ul> <p>«Мы добавили в PlatformCraft не просто еще один тариф, а отдельный сценарий работы с файлами. У многих компаний есть большой слой данных, которые нужно хранить долго, но обращаться к ним лишь изредка. Раньше для таких задач в рамках PC-Storage был только горячий контур. С запуском холодного хранилища у клиентов появляется возможность разделить активные и архивные данные и управлять экономикой хранения заметно точнее», — отметил коммерческий директор PlatformCraft, Надир Хамзин.</p> <p>Запуск расширяет линейку сервисов хранения PlatformCraft и позволяет компаниям гибко выбирать модель работы с файлами в зависимости от частоты доступа и характера нагрузки. Подключение холодного хранения будет доступно по подписке с 15 июня, а для новых пользователей предусмотрен пробный период и бесплатный исходящий трафик 30 дней. </p> PlatformCraft, технологическая платформа ООО «ПК», объявила о запуске холодного объектного хранилища PC-Storage для файлов … message https://www.itweek.ru/themes/detail.php?ID=235002 Mon, 15 Jun 2026 10:59:58 +0300 <p><em>Агенты искусственного интеллекта могут строить древовидные структуры данных (B±деревья) и диспетчеры буферов, но, по словам доцента кафедры компьютерных наук Университета Карнеги-Меллона Энди Павло, оптимизатор запросов и автономная база данных остаются их самой сложной нерешенной задачей, сообщает портал </em><em>The</em> <em>New</em> <em>Stack</em><em>.</em></p> <p>По мере того, как большие языковые модели (LLM) развиваются от простых чат-ботов до автономных агентов, способных рассуждать, планировать и действовать, они начинают самостоятельно управлять сложными стеками приложений. Однако сейчас эти агенты сталкиваются со своим самым серьезным препятствием — базой данных.</p> <p>«Базы данных представляют собой самую сложную и важную проблему для агентов из-за их бескомпромиссных требований к корректности и производительности», — заявил Энди Павло на недавней конференции «Percona Live 2026» в Калифорнии.</p> <p>В ходе обсуждения взаимодействия ИИ и Open Source-инфраструктуры он утверждал, что, хотя агенты-кодировщики могут легко воспроизводить стандартные структуры данных, база данных остается самой сложной частью любой системы для автоматизации и оптимизации.</p> <p>«Например, если агент генерирует галлюцинации компонента пользовательского интерфейса, страница выглядит немного некорректно; если он генерирует галлюцинации на уровне запроса или изменения конфигурации в производственной базе данных, вся система может исчезнуть», — сказал Павло.</p> <p>Вот это действительно должно вызвать тревогу.</p> <h3>Мультиагентное перетягивание каната</h3> <p>Павло выделил два основных способа влияния ИИ на мир баз данных: агенты-настройщики и агенты-кодировщики. Первые стремятся избавить нас от «черной магии» оптимизации баз данных, автоматически корректируя параметры системы, физические схемы (такие как индексы) и стратегии выполнения запросов. Исторически это требовало от администратора базы данных (DBA) многолетней работы над развитием интуиции, чтобы понять, какая конфигурация обеспечит лучшую задержку или пропускную способность.</p> <p>Проблема в том, что эти специализированные агенты часто работают изолированно, отметил Павло. Агент, регулирующий параметры, может не знать, что делает агент, регулирующий индексы, что приводит к локальным минимумам, где система лучше стандартной, но далека от оптимальной. По его словам, исследования Университета Карнеги-Меллона в области многораундовой и последовательной настройки направлены на решение этой проблемы путем создания координирующей структуры, хотя даже она сталкивается с «проклятием размерности».</p> <p>Университетская группа баз данных является пионером в области разработки концепции самоуправляемой и управляемой машинным обучением оптимизации баз данных. Последовательная и многораундовая настройка являются основными компонентами их проектов по автономным СУБД.</p> <p>Многораундовая и последовательная настройка баз данных ИИ относится к передовым методам машинного обучения и инженерии данных, в которых модели ИИ совершенствуются для многошагового рассуждения, использования инструментов или сложных историй диалогов. Эти структуры гарантируют, что модели ИИ не только реагируют изолированными одношаговыми импульсами, но и сохраняют контекст и логику в сложных взаимодействиях.</p> <p>С триллионами возможных комбинаций конфигураций пространство поиска идеальной базы данных фактически экспоненциально.</p> <h3>Преимущества агентов-кодировщиков и проблема оптимизатора запросов</h3> <p>Что касается разработки, агенты-кодировщики уже доказали свою высокую эффективность в качестве партнеров. Павло отметил, что в Университете Карнеги-Меллона количество строк кода, представленных студентами для проектов по базам данных, резко возросло после того, как было разрешено использовать LLM. «Агенты-кодировщики очень хорошо справляются с созданием практически всех частей базы данных — B±деревьев, хеш-таблиц, диспетчеры буферов — потому что они могут воспроизводить стандартные реализации, найденные в учебниках и Open Source-репозиториях», — сказал он.</p> <p>Однако, по его словам, «двойной черный ромб» (экстремальные сложность и непредстказуемость) по-прежнему остается проблемой оптимизатора запросов. В отличие от базовых структур данных, оптимизаторы запросов редко доступны в виде чистых, модульных Open Source-ссылок. Они часто тесно связаны с системами, для которых были созданы. Кроме того, доказательство семантической корректности правила преобразования, сгенерированного ИИ, — то есть, что оно дает тот же результат, что и исходный запрос, но быстрее, — остается нерешенной проблемой.</p> <h3>Риски включают галлюцинации и проблемы безопасности</h3> <p>Переход к агентному управлению базами данных сопряжен со значительными рисками. Павло и некоторые лидеры отрасли, такие как соучредитель Percona Питер Зайцев, предупреждают, что делегирование оркестровки агентам создает огромные пробелы в стабильности и безопасности. Уже задокументированы случаи, когда агенты, направленные на базу данных, случайно выводят из строя всю систему или допускают утечку конфиденциальной информации, поскольку не понимают нюансов контроля доступа, сказал Зайцев.</p> <p>Кроме того, LLM страдают от так называемой проблемы «ИИ-помоев» («AI slop»), когда они генерируют код, узкоспециализированный для конкретного запроса, но не способный к обобщению. Например, если разработчик использует агента для оптимизации пункта «Извлечь год», агент может создать внутреннюю структуру данных, которая сломается в тот момент, когда разработчик попытается выполнить «Извлечь месяц».</p> <h3>Автоматизация как помощник, а не замена</h3> <p>Несмотря на эти препятствия, Павло выразил оптимизм по поводу модели «агент-оператор». Она предполагает, что агенты будут обрабатывать ситуации типа «в 3 часа ночи всё идёт наперекосяк» — внезапные аномалии производительности и проблемы со стабильностью, — в то время как люди сосредоточатся на проектировании архитектуры более высокого уровня. По словам Павло, использование методов Agent Boosting (практики, направленные на повышение эффективности работы ИИ-агентов в сфере кодирования) для получения обучающих данных из ранее настроенных баз данных позволяет сократить время, необходимое для оптимизации системы, с 12 часов до менее чем 15 минут.</p> <p>В новую эру ИИ цель состоит не только в том, чтобы иметь ИИ, который пишет код, но и в том, чтобы система могла рассуждать о собственной производительности и корректности. По мнению Павло, база данных является основой знаний для любого агента. «Если мы хотим автономных систем, мы должны сначала освоить непрощающее искусство автономных баз данных», — сказал он.</p> Агенты искусственного интеллекта могут строить древовидные структуры данных (B±деревья) и диспетчеры буферов, но … article https://www.itweek.ru/themes/detail.php?ID=235000 Mon, 15 Jun 2026 10:29:40 +0300 <p>У нейросетей много полезных сценариев: от автоматизации простых рутинных задач до участия в нетривиальной творческой работе руководителя. На уровне менеджмента ИИ-модели успешно помогают распределять задачи в команде, оценивать риски и принимать решения. Ограничения у такого подхода тоже есть, и важно понимать, как правильно пользоваться технологиями.</p> <p>Ниже расскажу о наблюдениях и рекомендациях по использованию ИИ-агентов в работе тимлида.</p> <h3>Как подготовить агента к работе с вашим проектом</h3> <p>Чтобы ИИ мог давать правильные подсказки и советы, его нужно ввести в курс дела. Тогда он становится контекстным помощником, который знает проект, документацию и внутренние ограничения, поэтому может оценивать задачи ближе к тому, как это сделал бы человек из команды.</p> <p>В сценарии взаимодействия тимлида и нейросети важен не столько конкретный инструмент, сколько накопленный контекст. Человек постепенно превращает ИИ в рабочее пространство проекта: добавляет документацию, описывает правила, хранит заметки по сотрудникам и ограничениям. В итоге модель может оценивать задания не абстрактно, а с опорой на собранную информацию.</p> <p>Контекст нужно собрать как маленькую рабочую папку проекта: с описанием команды, задач и решений. Тогда при работе не нужно каждый раз пересказывать все заново, а достаточно дать инструкцию: работать с конкретной папкой, использовать определённые файлы как источник правды.</p> <p>Чем больше тимлид складывает в рабочее пространство правил и рабочих решений, тем ближе ответы ИИ к логике конкретной команды. Когда такой контекст собран, агента можно использовать не только для технических задач, но и для управленческой работы.</p> <h3>Работа с командой</h3> <p>Один из главных полезных сценариев — помощь с пониманием возможностей команды и распределением задач. Этот вариант применения ИИ позволяет закрыть довольно много реальных задач.</p> <p><strong>Составление тестовых заданий для новых участников.</strong> Когда в команде появляется вакансия, агент может помочь составить тестовое задание, по которому проще оценить подходящих кандидатов.</p> <p>Нейросеть может составить такое задание с учетом контекста реальной работы команды: документации, REST API, типичных задач. В этом случае тестовое становится менее абстрактным и ближе к тому, с чем человеку действительно предстоит работать.</p> <p>Одна и та же задача может показать разные навыки и подходы. Один человек, даже не зная конкретного языка или технологии, попробует рассуждать логически и понять, что делает код, а другой просто остановится. Для тимлида такая разница важна, потому что показывает не только уровень знаний, но и готовность разбираться, учиться и двигаться дальше.</p> <p>Особенно хорошо такой сценарий может проявиться, когда кто-то из команды переходит на другое место работы. Чаще всего каждый человек выполняет немного разные функции и наверняка обладает определенными уникальными компетенциями. Когда агент знает, кого именно нужно заменить, он может подготовить персонализированное пробное задание и проанализировать, как его выполнили разные кандидаты.</p> <p><strong>Распределение задач.</strong> Для этого нужно, чтобы ИИ-ассистент был в контексте компетенций сотрудников. Это можно сделать через составление рабочих профилей каждого члена команды с указанием слабых и сильных сторон.</p> <p>Когда агент понимает возможности разных людей, он может составить оптимальный план выполнения по каждому проекту с указанием состава задач для каждого и примерными сроками выполнения. Например, при проектировании архитектуры проекта нейросеть может посоветовать ответственных за разные части в зависимости от навыков и предпочтений.</p> <p><strong>Анализ рисков.</strong> Когда ИИ-ассистент знает компетенции сотрудников, он может подсветить потенциальные проблемы еще до начала работы. Например, заметить, что у команды не хватает опыта в конкретной технологии или что сроки выглядят слишком оптимистично.</p> <h3>ИИ как психолог</h3> <p>Агентов можно использовать как инструмент для рефлексии. Тимлид находится между интересами бизнеса и команды: нужно принимать решения, разбирать конфликты, давать обратную связь. В таких ситуациях ИИ может выступать не совсем как настоящий психолог, но как собеседник, который помогает разложить все соображения и посмотреть на ситуацию со стороны.</p> <p>Чтобы такой сценарий работал лучше, желательно завести для него отдельное пространство. Внутри можно создавать отдельные чаты под разные сессии: про конфликт интересов, про выгорание, про конкретный разговор с сотрудником. Тогда контекст не смешивается, и модель лучше понимает, что именно обсуждается сейчас.</p> <p>Для такого разговора ИИ нужно дать достаточно вводных: что произошло, что именно тревожит тимлида и какого результата он хочет добиться.</p> <p>Ответы модели не стоит воспринимать как профессиональную терапию. Лучше использовать ИИ как безопасный черновик для размышления: сформулировать проблему, проверить аргументы, увидеть возможные слепые зоны.</p> <h3>Ограничения инструмента</h3> <p>Чтобы работать эффективнее, нужно помнить не только плюсы технологий, но и недостатки. Вот основные ограничения.</p> <ul> <li><strong>Контекст нужно поддерживать вручную.</strong> Агент полезен, пока актуальна его память о контексте. Если команда изменилась, поменялись архитектура или приоритеты, то без обновлённого контекста ИИ начнет опираться на устаревшую картину проекта. Тогда агент может уверенно предлагать решения, которые уже не соответствуют реальности.</li> <li><strong>Сложно обеспечить совместную работу и контроль версий.</strong> В сегодняшних сервисах не всегда удобно дать доступ нескольким людям или посмотреть историю изменений документов.</li> <li><strong>Нужны правила безопасности и приватности. </strong>Многие инструменты не дают задать ограничения, какую информацию можно использовать и где она хранится. Поэтому нельзя включать в запросы и контекст персональные данные. Например, использовать псевдонимы, только рабочие наблюдения и никогда не передавать в ИИ данные, которые нельзя безопасно передавать внешнему сервису.</li> </ul> <h3>Связки с другими инструментами и источниками данных</h3> <p>В более продвинутом сценарии ИИ-ассистента можно связать с другими источниками данных, например таск-трекером или внутренней базой знаний. Тогда агент сможет не просто рассуждать на основе заранее подготовленных файлов, а видеть более актуальную картину на основе текущей ситуации.</p> <p>Но такие подключения стоит делать осторожно: ИИ может стать бесконтрольным наблюдателем за всей внутренней жизнью компании. Чем шире доступ, тем выше риск утечки, поэтому крайне нежелательно давать доступ машине к любой чувствительной информации.</p> <p>Начинать лучше с передачи агенту нужных материалов вручную: описание проекта, чек-листы, обезличенные профили команды. Если этого недостаточно, можно попробовать подключать отдельные сервисы в режиме чтения и только к тем данным, которые необходимы для конкретного сценария.</p> <h3>Есть ли отличия в разных моделях</h3> <p>В сценарии помощи тимлиду разница между моделями и инструментами не всегда решающая. Главное, чтобы агент умел работать в одном проектном контексте: читать файлы, помнить правила, обращаться к документации. Поэтому схожий сценарий можно собрать почти в любом ИИ-агенте.</p> <p>Лучший способ найти подходящую модель — попробовать несколько инструментов на реальных задачах команды. Одни модели лучше подходят для кода и анализа репозитория, другие хорошо работают с длинными документами и планированием. Поэтому выбирать инструмент стоит под конкретную работу команды и иногда менять его в зависимости от задач.</p> <h3>ИИ в роли помощника тимлида</h3> <p>ИИ в команде можно описать как второго тимлида или заместителя, но с важной оговоркой: финальная ответственность все равно остается за человеком. Агент может предложить распределение задач, подсветить слабые места, помочь с тестовым заданием. Главное ограничение модели — машина не знает людей лучше руководителя и не должна принимать управленческие решения. Задача ИИ в том, чтобы усилить тимлида. Это значит держать больше контекста, задавать дополнительные вопросы и брать на себя часть рутинной подготовки.</p> <p>Сильная сторона агента проявляется, когда он долго работает внутри одного проектного контекста: тогда он лучше понимает состав команды, ограничения, принятые решения. В таком режиме он становится дополнительным собеседником, с которым можно обсудить план, проверить идею и увидеть риски.</p> <p>#IMAGE_235001#</p> У нейросетей много полезных сценариев: от автоматизации простых рутинных задач до участия в нетривиальной … article Владимир Верхотуров, тимлид отдела ”Продуктовый DevRel” компании ”Битрикс24” https://www.itweek.ru/themes/detail.php?ID=234997 Thu, 11 Jun 2026 09:44:30 +0300 <p><em>Стивен Эллиот, вице-президент группы </em><em>IDC</em> <em>по инфраструктуре и операциям, облачным операциям и DevOps, рассказывает в корпоративном блоге, как руководители предприятий могут снизить риски и превратить системы искусственного интеллекта в конкурентное преимущество.</em></p> <p>Эра ИИ-помощников подходит к концу.</p> <p>Чат-боты, помощники, составители резюме — полезны, да, но это разминка. Следующим шагом станет агентный ИИ: системы, которые не просто реагируют на запросы, но и планируют, рассуждают и выполняют работу в ваших системах, рабочих процессах и на ваших данных, с участием человека или без него. Сегодня руководители предприятий ставят агентный ИИ в центр своих бизнес-трансформаций, переосмысливая то, как люди взаимодействуют с рабочими процессами на основе ИИ.</p> <blockquote> <p><em>IDC прогнозирует развертывание к 2029 г. 1,15 млрд. активных агентов, выполняющих 217 млрд. действий в день, что в 40 раз больше показателя 2025 г.</em></p> <p>#IMAGE_234998#</p> </blockquote> <h3>Ставки не теоретические</h3> <p>Бизнес-модели, навыки, экономика, управление, соответствие нормативным требованиям и требования к безопасности быстро меняются, создавая масштабные и быстро развивающиеся риски. Цифры из опроса IDC «State of Enterprise Agent Adoption 2025» это подтверждают:</p> <ul> <li> Более 30% предприятий уже внедрили формальные метрики ценности ИИ.</li> <li> До 20% компаний из списка G1000 могут к 2030 г. столкнуться с юридическими и управленческими последствиями из-за плохо управляемых агентов.</li> <li> 60% компаний из списка G2000 к 2028 г. внедрят формальный жизненный цикл разработки агентов.</li> </ul> <p>Генеральные директора, члены совета директоров и акционеры требуют результатов от ИИ уже сейчас. Ожидание затормозит рост доли рынка, возможностей для роста и инноваций. Первые добившиеся успеха расширят свои преимущества, применяя проверенные знания ИИ в новых сценариях использования. В ИИ-экономике непрерывное обучение обеспечивает скорость и кумулятивные результаты.</p> <h3>Это не апгрейд. Это новая операционная модель</h3> <p>Если «второй пилот» составляет электронное письмо, то агент управляет всем рабочим процессом: сбором данных, принятием решений, эскалацией исключений, замыканием цикла. Автономно. Постоянно. В разных системах. С участием человека или без него. Это требует от руководителей перепроектирования процессов с ИИ в центре, не как дополнительной функцией, а как сердцем каждого рабочего процесса.</p> <p>По данным IDC, к 2027 г. предприятиям потребуются архитектуры, поддерживающие синхронное перемещение данных, приложений, рабочих процессов и агентов. Если ваша текущая система не была разработана для этого, время уже идет.</p> <blockquote> <p><em>Агентные системы создают принципиально иной профиль риска, чем инструменты ИИ, которые большинство предприятий развернули в 2023 и 2024 гг.</em></p> </blockquote> <p>Последствия выходят за рамки архитектуры. Копилоты работали под наблюдением человека — каждый результат проверялся, каждое действие подтверждалось. Агенты работают иначе: они инициируют, объединяют решения и действуют в разных системах в режиме реального времени. Неправильно настроенный агент не просто выдает неправильный ответ; он принимает неверное решение, потенциально в больших масштабах, прежде чем кто-либо это заметит. Именно этот переход от результатов, проверенных человеком, к автономным действиям приводит к полному краху систем управления, созданных для эпохи помощников. Управление, безопасность и координация являются критически важными инвестиционными требованиями, а не второстепенным аспектом для эффективных и результативных результатов ИИ. Управление и безопасность должны быть заложены с самого начала, поскольку риски для бизнеса и карьеры слишком высоки, чтобы рассматривать их как второстепенные. Каждый цифровой работник будет управляться как обычный сотрудник.</p> <p>Руководители, которые осознают это различие на раннем этапе, получат структурное преимущество. Они будут не просто быстрее развертывать системы — они создадут операционные возможности, инфраструктуру аудита и системы доверия, необходимые для безопасного масштабирования. Те, кто рассматривает агентный ИИ как продолжение своей стратегии «второго пилота», столкнутся с растущими затратами на исправление ошибок по мере роста портфелей агентов и расширения пробелов в управлении.</p> <p>Конкурентный разрыв, формирующийся сейчас, — не между компаниями, которые используют ИИ, и теми, которые его не используют. Речь идёт о противостоянии организаций, которые научились дисциплинированно внедрять агентов, и тех, кто всё ещё импровизирует. Скорость без структуры — это уязвимость. Структура без скорости — это неактуальность. Руководители, которые ориентируются в обоих аспектах, устанавливают правила игры.</p> <h3>Семь областей. Одна структура</h3> <p>Предлагаемая IDC структура внедрения ИИ выявляет семь областей, где ранние решения оказывают огромное влияние на последующие этапы. Правильно их примите, и вы нарастите темп:</p> <ul> <li> Бизнес-результаты.</li> <li> Проектирование рабочих процессов.</li> <li> Готовность данных.</li> <li> Архитектура среды выполнения.</li> <li> Управление.</li> <li> Операционная модель.</li> <li> Кадры.</li> </ul> <p>В каждой области выделены ключевые моменты, которые руководители должны учитывать для оценки своей готовности к внедрению и управлению ИИ. После проведения самооценки исследование предоставляет подробный анализ критически важных областей трансформации — разработка ПО, выбор партнёров и инфраструктуры ИИ, а также ИТ-операции. Эти рекомендации служат руководством для обсуждения вашего пути внедрения агентного ИИ.</p> <h3>Ключевые выводы для руководителей</h3> <ul> <li> Рассматривайте агентный ИИ как новую операционную модель, а не как обновление вашей стратегии «второго пилота».</li> <li> Управление и безопасность теперь являются конкурентным преимуществом, а не просто мерами по обеспечению соответствия ИТ-требованиям.</li> <li> Семидоменная структура — это ваша шпаргалка: используйте её, чтобы снизить риски развертывания и извлечь выгоду за счет накопления ценности.</li> <li> Те, кто первыми начнут, установят правила игры. Ожидание — это не нейтральная позиция, а стратегическая уступка.</li> </ul> Стивен Эллиот, вице-президент группы IDC по инфраструктуре и операциям, облачным операциям и DevOps, рассказывает … article https://www.itweek.ru/themes/detail.php?ID=234995 Thu, 11 Jun 2026 09:39:00 +0300 <p>В классической ИТ-архитектуре понятие Disaster Recovery (DR), как правило, является синонимом «запасного плана». Это страховка, которая требует огромных капитальных вложений, но остается пассивной до самого момента аварии. Однако в настоящее время в ключевых отраслях — таких как непрерывное производство, финансовый сектор, государственное управление, электронные госуслуги и здравоохранение — предъявляются повышенные требования к отказоустойчивости бизнес-процессов в режиме 24/7/365.</p> <p>Необходимость повышения экономической эффективности заставляет рынок пересматривать этот классический подход. Сегодня мы наблюдаем тектонический сдвиг: переход от ИТ-инфраструктуры «пассивного ожидания» к распределенным зонам доступности (Availability Zones).</p> <h3>Эволюция стратегий: От «холодного» резерва к «живому» облаку</h3> <p>Для сравнения эффективности подходов рассмотрим три основные модели организации инфраструктуры.</p> <p><strong>1.</strong> <strong>Классический DR (Active-Passive). </strong>Это традиционная модель: основной центр обработки данных (ЦОД А) несет 100% полезной нагрузки, а резервный (ЦОД B) находится в режиме ожидания. Данные между ними реплицируются синхронно или асинхронно. Преимущество такого подхода заключается в относительно простой настройке. В то же время схеме присущ серьезный недостаток: оборудование резервного ЦОДа простаивает, но при этом требует постоянного технического обслуживания и лицензирования программного обеспечения. Кроме того, Active-Passive несет в себе скрытые риски — в частности, риск сбоя при переключении на резервную площадку из-за рассинхронизации настроек системного ПО или человеческого фактора.</p> <p><strong>2. Две «площадки» (Active-Active). </strong>Инфраструктура распределена между двумя площадками, каждая из которых активно обрабатывает транзакции. Ключевые преимущества этой модели — 100%-ное использование доступных ресурсов и отсутствие рисков, связанных с ручным или автоматическим переключением нагрузок: при аварии «выживший» ЦОД просто продолжает работу.</p> <p>Однако подход имеет ряд серьезных ограничений. Первая проблема — сугубо технологическая: эффект «расщепления мозга» (split-brain). В случае разрыва связности между ЦОДами возникает риск того, что сервисы на обеих площадках начнут считать себя изолированными мастерами, что неизбежно ведет к консистентным сбоям и повреждению данных. Для предотвращения split-brain требуется третья независимая сторона — арбитр (Quorum Witness). Вторая сложность носит экономический характер: при отказе одного из дата-центров вся нагрузка локализуется на оставшейся площадке. Чтобы минимизировать дефицит производительности и пропускной способности в момент аварии, компании приходится постоянно держать до 50% вычислительных ресурсов в горячем резерве на каждом узле.</p> <p><strong>3. </strong><strong>Три зоны доступности — три «площадки» (Multi-AZ/3-site). </strong>Это «золотой стандарт» современной ИТ-отрасли. Инфраструктура распределяется по трем независимым локациям с минимальными задержками (latency) между ними. Схема обладает рядом неоспоримых преимуществ.</p> <p>Первое — технологическое: наличие кворума по умолчанию. Система всегда имеет математическое «большинство». Если одна из площадок выходит из строя, две оставшиеся подтверждают целостность и непротиворечивость данных, продолжая работу без риска рассинхронизации. Второе преимущество — нулевое окно обслуживания. Вы можете полностью остановить одну из зон для планового обновления программного или аппаратного обеспечения, пока система сохраняет высокую доступность (High Availability) за счет двух оставшихся площадок. Наконец, третье преимущество — экономическое, которое часто упускают из виду. Чтобы минимизировать дефицит производительности при отказе одного плеча, в модели Multi-AZ достаточно иметь всего порядка <nobr>8-10%</nobr> избыточных мощностей на каждой из площадок. Подобный резерв, чаще всего, у компаний уже заложен под пиковые нагрузки или под будущий рост бизнеса.</p> <h3>Почему стоит выбрать концепцию трех зон доступности?</h3> <ol> <li><strong> Математическая гарантия целостности данных. </strong>В бизнес-транзакциях — будь то бухгалтерская проводка или межбанковский перевод — «потерять» или «удвоить» запись абсолютно недопустимо. Трехзонная архитектура на базе алгоритмов распределенного консенсуса (таких как Raft или Paxos) гарантирует, что любая транзакция будет подтверждена как минимум двумя вычислительными узлами, физически расположенными в разных дата-центрах.</li> <li><strong> Соответствие жестким требованиям КИИ и регуляторов. </strong>Для объектов критической информационной инфраструктуры (КИИ) требование устойчивости к региональным и техногенным катастрофам становится обязательным. Развертывание в трех зонах доступности позволяет разнести оборудование на безопасное географическое расстояние, полностью сохраняя непрерывную репликацию данных и гарантируя их постоянную доступность.</li> <li><strong> Экономика масштабируемых систем. </strong>Современные программно-определяемые технологии (SDS/SDN) позволяют строить распределенную отказоустойчивую сеть на базе стандартного серверного оборудования (Commodity Hardware). Отказ от покупки дорогостоящих проприетарных СХД для организации репликации делает трехзонную модель Active-Active сопоставимой по стоимости владения (TCO) с классическим пассивным DR, но при этом в разы более эффективной.</li> </ol> <h3>Резюме</h3> <p>Переход на архитектуру трех зон доступности (Multi-AZ) — это стратегический сдвиг от <em>реактивной</em> модели управления (когда инфраструктуру приходится восстанавливать после аварии) к <em>превентивной</em> (когда система физически не замечает отказа отдельных узлов или площадок). По сути, это полная смена парадигмы управления рисками. Для предприятий и организаций такой подход означает гарантированное сохранение лояльности клиентов, минимизацию рисков простоя критических технологических циклов и прямую экономию на потенциальных штрафах регуляторов. Сегодня, в 2026 году, современное предприятие уже не может позволить себе тратить время на то, чтобы «восстанавливаться» после сбоя. Оно должно этот сбой просто игнорировать, непрерывно продолжая работу в распределенной среде.</p> <p>#IMAGE_234996#</p> В классической ИТ-архитектуре понятие Disaster Recovery (DR), как правило, является синонимом «запасного плана». Это … article Дмитрий Гаврилов, основатель ООО “Открытые Технологии Виртуализации” https://www.itweek.ru/themes/detail.php?ID=234993 Thu, 11 Jun 2026 09:32:41 +0300 <p>За последние два года искусственный интеллект превратился из экспериментальной технологии в обязательный пункт корпоративной стратегии. Практически каждая крупная компания уже запустила пилот, тестирует генеративный ИИ или заявляет о намерении автоматизировать часть бизнес-процессов. На рынке сформировалось ощущение, что внедрение ИИ — вопрос конкурентоспособности и выживания.</p> <p>Однако за громкими анонсами скрывается менее привлекательная реальность. Большинство проектов так и не доходят до промышленной эксплуатации. По данным ряда международных исследований, подавляющая часть инициатив в области генеративного ИИ не демонстрирует ожидаемого экономического эффекта и остается на уровне экспериментов.</p> <p>Парадокс заключается в том, что проблема редко связана с самими технологиями.</p> <h3>Бизнес пытается автоматизировать не процессы, а надежды</h3> <p>Каждый новый технологический цикл рождает собственный набор иллюзий. В эпоху CRM считалось, что достаточно внедрить систему управления клиентами, чтобы автоматически выросли продажи. Позже аналогичные ожидания связывали с большими данными, RPA и цифровой трансформацией.</p> <p>Сегодня такая же судьба постигла генеративный ИИ.</p> <p>Во многих компаниях решение о внедрении принимается не потому, что существует конкретная бизнес-проблема, а потому что технология находится на пике внимания. В результате организации начинают создавать универсальных ИИ-агентов, не понимая, какую именно задачу те должны решать и каким образом будет измеряться результат.</p> <p>На практике искусственный интеллект часто становится новым интерфейсом для старых неэффективных процессов. Если компания не понимает собственную клиентскую воронку, не знает структуру обращений и не может определить стоимость одного контакта, то ИИ не устранит эти проблемы. Он лишь ускорит их масштабирование.</p> <p>Автоматизация хаоса остается хаосом.</p> <h3>Самый дорогой риск — человеческий</h3> <p>Существует еще одна причина, о которой редко говорят публично.</p> <p>Руководители контакт-центров и клиентских служб оцениваются не по количеству внедренных инноваций, а по отсутствию ошибок. Любое решение, способное создать дополнительный риск для клиентского опыта, воспринимается крайне осторожно.</p> <p>Когда ошибается оператор, организация воспринимает это как рабочий процесс. Когда ошибается ИИ, инцидент воспринимается как системная проблема.</p> <p>В результате компании предъявляют к ИИ более жесткие требования, чем к людям.</p> <p>Представим контакт-центр, где сотрудники допускают ошибки в <nobr>10-15%</nobr> нестандартных обращений. Это считается допустимым уровнем. Но если ИИ-агент ошибается в одном разговоре из ста пятидесяти, обсуждение быстро смещается от экономического эффекта к вопросу о том, можно ли вообще использовать такую технологию.</p> <p>Подобная логика понятна с точки зрения личной ответственности менеджеров, но часто приводит к отказу от проектов, которые уже доказали свою экономическую эффективность.</p> <h3>Почему большинство компаний оценивают не те показатели</h3> <p>Еще одна распространенная ошибка — выбор неправильных метрик.</p> <p>Во многих проектах успех ИИ измеряется временем ответа, количеством обработанных запросов или стоимостью токена. Эти показатели удобны для разработчиков, но практически ничего не говорят бизнесу.</p> <p>Клиентский сервис существует не для того, чтобы быстро отвечать на вопросы. Его задача — решать проблемы клиентов.</p> <p>Поэтому для оценки ИИ-агентов гораздо важнее показатели уровня решенных обращений без участия оператора, точность ответов, количество повторных контактов и стоимость обработки одного запроса.</p> <p>Когда компания начинает смотреть на эти метрики, выясняется, что эффективность ИИ определяется не качеством модели как таковой, а глубиной интеграции в реальные бизнес-процессы.</p> <h3>Где экономика ИИ действительно работает</h3> <p>При этом говорить о том, что генеративный ИИ не окупается, было бы ошибкой.</p> <p>Существуют сегменты, где экономический эффект уже подтверждается практикой. В первую очередь это клиентский сервис крупных B2C-компаний, контакт-центры, страхование, телеком, банковский сектор, девелопмент и подписочные сервисы.</p> <p>Общая черта таких проектов — высокая стоимость человеческого труда и большой объем однотипных коммуникаций.</p> <p>Например, в девелопменте ИИ может работать со «спящей» клиентской базой, которую компания физически не способна регулярно обрабатывать силами операторов. В страховании — автоматизировать первую линию поддержки. В фитнес-индустрии — заниматься пролонгацией абонементов и реактивацией клиентов.</p> <p>Во всех этих сценариях ценность создается не за счет замены людей, а за счет возможности выполнять работу, которая ранее вообще не выполнялась из-за ограниченности ресурсов.</p> <p>Именно поэтому многие успешные проекты связаны не с сокращением штата, а с масштабированием бизнеса без пропорционального роста расходов.</p> <h3>Главный вопрос — не «какая модель», а «какой процесс»</h3> <p>Рынок искусственного интеллекта постепенно проходит классический цикл взросления.</p> <p>Фокус смещается с обсуждения моделей и параметров на вопросы экономики и операционной эффективности. Компании начинают понимать, что ценность создается не в момент запуска пилота, а в момент интеграции технологии в ежедневную работу бизнеса.</p> <p>Для этого необходимы три вещи.</p> <p>Во-первых, внедрение должно начинаться с <em>конкретной бизнес-задачи</em>, а не с желания использовать модную технологию.</p> <p>Во-вторых, <em>проект должен иметь владельца</em> внутри компании, отвечающего за бизнес-результат, а не только за техническую реализацию.</p> <p>В-третьих, ИИ необходимо <em>рассматривать как постоянно развивающуюся систему</em>, а не как программный продукт, который можно внедрить один раз и забыть о нем.</p> <h3>От хайпа к эффективности</h3> <p>Сегодня рынок находится в точке, когда первая волна энтузиазма начинает уступать место прагматизму.</p> <p>Компании больше не спрашивают, нужен ли им искусственный интеллект. Они задают гораздо более важный вопрос: способен ли он приносить деньги.</p> <p>Именно этот вопрос в ближайшие годы разделит рынок на две группы. Одни организации продолжат собирать коллекцию пилотных проектов и презентаций для совета директоров. Другие научатся превращать ИИ в инструмент повышения выручки и снижения издержек.</p> <p>Разница между ними будет определяться не качеством используемой модели и не объемом инвестиций.</p> <p>Разница будет заключаться в способности связать технологию с реальными бизнес-процессами и измеримым экономическим результатом.</p> <p>#IMAGE_234994#</p> За последние два года искусственный интеллект превратился из экспериментальной технологии в обязательный пункт … article Андрей Зименков, фаундер и CEO targetai