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=234944 Wed, 03 Jun 2026 09:12:05 +0300 <p>DevRel-специалист говорит на одном языке с разработчиками и клиентами, разбирается в коде и выступает лицом компании. Рассмотрим, какие навыки нужны для этой работы, и почему техподдержка — один из самых подходящих бэкграундов для профессии.</p> <h3>Кто такой DevRel и что он делает</h3> <p>Слово DevRel — это сокращение от Developer Relations и переводится как «отношения с разработчиками». Должность объединяет обязанности из областей PR, маркетинга и технологий.</p> <p>Классический DevRel-специалист занимается популяризацией компании с технологической стороны. Это значит выступать на конференциях, писать статьи, рассказывать людям с разным опытом о том, чем занимается компания и как её продукты полезны потенциальным клиентам.</p> <p>Ещё DevRel часто помогает внутренней и внешней командам разработки синхронизироваться по рабочим вопросам и находить решения. Это может выглядеть так: внешняя команда программистов работает с технологиями компании и находит ошибку в одной из частей системы. Они приходят с этой ошибкой к DevRel, а ему нужно передать проблему внутренней команде, но при этом помочь разобраться и объяснить, что именно не так. Поэтому DevRel должен тоже работать с кодом: поискать проблему, протестировать сценарии работы, попробовать отладить и посмотреть на результаты. И уже с более полной картиной прийти к внутренним программистам компании.</p> <p>Главная и основная задача — это популяризация бренда. Если люди ассоциируют компанию с определённым техническим специалистом, и это создаёт бизнесу хороший имидж, значит, DevRel работает успешно.</p> <h3>Откуда приходят в DevRel и почему нужен технический бэкграунд</h3> <p>В российских компаниях DevRel сегодня чаще всего появляется внутри компании, когда кто-то из специалистов нарабатывает достаточный набор навыков и переходит на новую должность. Реже в DevRel нанимают людей со стороны: с 2021 по 2025 годы на hh.ru количество вакансий оставалось на уровне <nobr>30-50 позиций.</nobr></p> <p>Люди приходят в эту специальность из очень разных сфер: технической поддержки, разработки, тестирования, аналитики. Важно развить достаточный уровень инженерной экспертизы и опыта. Классический DevRel не может быть без технического бэкграунда, потому что нужно понимать не только клиентов и партнёров, но и разработчиков.</p> <p>В отличие от мидлов и сеньоров в программировании, DevRel может не иметь коммерческого опыта разработки. Для опытного инженера коммерческий опыт служит доказательством, что он умеет работать с реальным продуктом и отвечать за код в рабочих условиях. Для DevRel такой опыт в разработке полезен, но не всегда обязателен, потому что его основная ценность в понимании технического контекста, коммуникации и переводе между разными участниками процесса.</p> <h3>Какие софт-скиллы нужны DevRel</h3> <p>Важно правильно доносить мысли и уметь работать в команде. Переводить мысль на разные языки — возможно, главный навык хорошего DevRel-специалиста. Он должен не просто понимать техническую часть, а уметь превратить это понимание в коммуникацию, которая помогает людям решить задачу.</p> <p>Другое важное умение — организованность. Чаще всего DevRel решает задачи не один, а в контакте с другими сотрудниками. Нужно координировать разные команды и людей: прийти к внутренней команде, договориться о приоритете, получить ответ, вернуться к внешним разработчикам и объяснить, что изменилось. Может понадобиться провести встречу, презентацию, обучение.</p> <p>Спокойствие и конфликтоустойчивость тоже важны. DevRel работает в том числе с людьми, у которых что-то не получается. А когда у людей что-то не получается, они не всегда формулируют проблему спокойно и корректно.</p> <p>Большой опыт публичных выступлений нужен не всегда, потому что обязанности DevRel в разных компаниях сильно отличаются друг от друга. Но ответственность за публичное слово всё равно нужно уметь нести.</p> <h3>Почему опыт техподдержки особенно хорошо подходит</h3> <p>Работа в технической поддержке — один из самых релевантных опытов для DevRel-позиции. Эти две профессии похожи, потому что в поддержке специалист тоже является посредником: между клиентом и своей командой разработки. Поэтому человек быстро учится понимать проблемы обеих сторон и решить их так, чтобы по возможности все были в выигрыше.</p> <p>В техподдержке развивается и другой важный навык: умение переводить с технического языка на нетехнический и обратно. В компанию может написать программист, у которого не работает интеграция между приложениями, а может и обычный пользователь, который не видит нужную кнопку. В обоих случаях нужно понять, что стоит за обращением или за проблемой, найти техническую причину, иногда вместе с командой разработки, и всё исправить.</p> <p>Коммуникацию нужно уметь поддерживать и между инженерами: у программистов нет какого-то универсального технического языка, у каждого может быть своё видение, опыт и стек технологий. Из-за этих отличий и DevRel-специалист, и сотрудник поддержки должны уметь построить диалог между разными разработчиками.</p> <p>У DevRel и техподдержки есть пересекающиеся задачи. Например, написать документацию по части сервиса для внешних команд партнёров или подрядчиков. Если DevRel-специалист до этого работал в поддержке, он уже погружён в продукт, разбирался в устройстве или даже знает, как работает код нужной части системы. Тогда задачу можно выполнить, не подключая команду разработки.</p> <h3>Что нужно развивать дополнительно</h3> <p>Это не значит, что после <nobr>2-3</nobr> лет работы в техподдержке специалист становится полностью готовым к DevRel. Один из главных навыков, который нужно поменять — мышление. Например, поддержка работает с запросами локально: задача специалистов в том, чтобы решить запрос и не думать, с чем он может быть связан. DevRel должен мыслить более глобально и мыслить стратегически: как влияет эта проблема на работу компании? Нужно ли её исправлять, улучшать или изменять другим путём? Какие риски могут быть связаны с работой над конкретной задачей?</p> <p>Полезного DevRel-специалиста отличает умение доходить до источника проблемы. Поэтому любопытство и желание досконально разобраться тоже нужно развивать. Это не совсем хард-скилл и не совсем софт-скилл. Скорее рабочая привычка: не останавливаться на статусе «работает» или «не работает», а найти первопричину.</p> <h3>Стоит ли DevRel специально идти в поддержку</h3> <p>Это вопрос, который каждый решает для себя самостоятельно, но у работы в техподдержке много плюсов для будущего DevRel.</p> <p>Главное — это опыт, который сложно получить где-то ещё. Если начинать с разработки или тестирования, скорее всего нужно будет работать с отдельными модулями и компонентами. В техподдержке нужно знать всё, пусть и не на таком же глубоком уровне. Но для работы в поддержке тоже важно иметь нужные качества: желание помогать людям, техническая база и достаточный уровень эмпатии.</p> <p>#IMAGE_234945#</p> DevRel-специалист говорит на одном языке с разработчиками и клиентами, разбирается в коде и выступает … article Владимир Верхотуров, тимлид отдела “Продуктовый DevRel” компании ”Битрикс24” https://www.itweek.ru/themes/detail.php?ID=234942 Wed, 03 Jun 2026 08:58:19 +0300 <p><em>То, как сегодня агентный искусственный интеллект используется в разработке ПО, является предвестником более широких изменений в модели разработки, пишут в корпоративном блоге партнеры McKinsey Джаред Мун и Адам Теллуолл (Лондон), Рори Уолш (Дублин) и Вито Ди Лео (Цюрих).</em></p> <p>В 9:00 утра владелец продукта заходит в систему, чтобы проверить прогресс, достигнутый ее командой за ночь. Она видит, что функция перешла от структурированных требований к протестированному коду. Отмечены граничные случаи. Она отмечает, что архитектурные зависимости проверены. Краткое резюме описывает компромиссы и нерешенные вопросы.</p> <p>Никто не работал допоздна. Работали агенты ИИ.</p> <p>К середине утра команда проверяет результаты, уточняет контрольные точки и пересматривает приоритеты бэклога. К вечеру следующие структурированные входные данные ставятся в очередь для работы агентов ИИ в течение очередного ночного цикла.</p> <p>Эта <nobr>24-часовая</nobr> модель работы больше не является теоретической. Ведущие организации уже перестраивают процесс разработки, ориентируясь на почти непрерывное выполнение. Модель разработки ПО быстро развивается, и многие компании уже видят, как она обеспечивает трех-пятикратное повышение производительности при сокращении численности команды на 60%. Организации добиваются этих результатов не просто за счет внедрения агентов ИИ, а за счет перестройки операционной модели таким образом, чтобы люди и агенты могли сотрудничать 24 часа в сутки.</p> <h3><nobr>24-часовой</nobr> спринт: проектирование для непрерывной производительности</h3> <p>Ведущие компании переходят к модели ежедневного спринта, которая сочетает в себе человеческое суждение с ночным выполнением задач агентами — значительное сокращение типичных двухнедельных циклов спринта. В течение дня люди сосредотачиваются на проверке результатов, разрешении неясностей, укреплении архитектурных ограничений и согласовании с заинтересованными сторонами. Всё чаще их роль сводится не столько к созданию артефактов, сколько к надзору и совершенствованию системы, которая их создаёт.</p> <p>Ночью агенты выполняют структурированную работу в масштабе. Их задачи включают в себя обогащение требований, проверку архитектуры, генерацию и тестирование кода, а также упаковку результатов для проверки.</p> <p>Эта модель работает только при наличии нескольких практических основ. Во-первых, у бизнеса должно быть чёткое видение того, что нужно построить (это может быть дорожная карта продукта или стандарт, на основе которого будет строиться), чтобы они могли оценивать требования, сгенерированные агентами, на предмет качества и соответствия этому видению.</p> <p>Затем базовая технологическая среда должна быть стандартной и согласованной (например, с использованием общих фреймворков и модульных архитектур), чтобы решения могли масштабироваться, а компоненты могли повторно использоваться, а не изобретаться заново каждый раз.</p> <p>В-третьих, путь от требований к коду должен следовать стандартной структуре, чтобы агенты могли надёжно интерпретировать входные данные и получать предсказуемые результаты в разных проектах.</p> <p>И в-четвёртых, одни и те же ключевые заинтересованные стороны должны оставаться вовлеченными на протяжении всего потока создания ценности, чтобы избежать несогласованности и постоянных переделок.</p> <p>Без такого уровня согласованности и ясности результаты работы агентов будут фрагментированными, и им будет трудно доверять.</p> <p>Главный вывод: непрерывная <nobr>24-часовая</nobr> доставка достижима, но только при наличии архитектурной дисциплины и стандартизированных рабочих процессов, чтобы агенты могли надежно работать в масштабе.</p> <h3>Расширьте автоматизацию, чтобы исключить передачу задач от человека к человеку</h3> <p>Традиционная автоматизация непрерывной интеграции и непрерывной доставки (CI/CD) в значительной степени сосредоточена на тестировании и развертывании. Хотя затраты на это варьируются, наш опыт показывает, что они могут составлять до 30% от общих затрат на технологии. Бóльшая часть усилий, сосредоточенных на требованиях и кодировании, остается ручной и требует интенсивной интерпретации. Именно здесь накапливаются трения, и ценность достигает плато.</p> <p>В большинстве организаций требования, стандарты, архитектурные спецификации и пользовательские истории существуют в разрозненных документах и ​​инструментах. Каждый переход вносит неоднозначность. Люди многократно переводят намерения из одного артефакта в другой.</p> <p>#IMAGE_234943#</p> <p>Агентная модель устраняет эти трения, структурируя артефакты для передачи задач от машины к машине. Функциональные описания, нефункциональные требования, ограничения, диаграммы последовательностей и репозитории кодифицируются в стандартизированных, машиночитаемых форматах. В результате конвейер может выполняться от начала до конца за несколько часов, при этом вмешательство человека происходит только на определенных этапах проверки, а не в качестве посредника.</p> <p>Главный вывод: масштабирование ИИ требует применения инженерных методов к самой системе разработки, что делает процесс повторяемым и автоматизирует передачу задач.</p> <h3>Создание инфраструктуры знаний для обеспечения автономности агентов</h3> <p>Для получения точных результатов фабрикам агентов необходимы организационный контекст и память. Ведущие компании создают графы знаний, которые функционируют как слой памяти ИИ на протяжении всего жизненного цикла разработки ПО (SDLC) для каждой области. Эти графы связывают элементы, которые агенты должны понимать, такие как отзывы клиентов, архитектурные решения, проектная документация, заявки, активность в GitHub, отчеты об инцидентах и ​​обобщенные правила соответствия нормативным требованиям. В результате получается семантически связанная система (то есть, способ для агентов понимать значение данных, чтобы лучше выполнять свои задачи).</p> <p>Такое влияние является преобразующим. На вопросы, которые раньше требовали недель интервью с многочисленными экспертами в предметной области, агент-«библиотекарь» может ответить за минуты, используя структурированную институциональную память. Каждое решение становится отслеживаемым. Если заинтересованная сторона спрашивает, почему функция была отложена, ответ может быть напрямую связан с источником, например, данными опросов клиентов или аналитикой использования. Неявные знания, накопленные в рамках сообщества, становятся явными и объяснимыми, сокращая время адаптации для новых членов команды и укрепляя управление.</p> <p>Важно отметить, что это не должно начинаться с масштабной, нисходящей разработки онтологии. Граф должен органично развиваться вокруг приоритетных областей и действующих программ, накапливая ценность с течением времени. По мере масштабирования знания становятся производственной инфраструктурой, а не статической документацией, и устойчивым источником конкурентного преимущества.</p> <p>Главный вывод: структурированные, взаимосвязанные знания — это основа автономии агентов. Рассматривайте свою архитектуру знаний как стратегическую инфраструктуру.</p> <h3>Получение выгоды: изменение размеров команд и перепроектирование портфеля</h3> <p>Агентный SDLC может существенно повысить производительность, поскольку теперь меньшие команды могут выполнять бóльшие объемы работы. Первые внедрения показывают, что большие команды из <nobr>8-12</nobr> штатных сотрудников могут уступить место меньшим группам высококвалифицированных специалистов, контролирующих выполнение задач с помощью агентов. Результатами являются сокращение сроков и снижение затрат или увеличение производительности.</p> <p>Для получения выгоды организациям следует сосредоточиться на трех приоритетах. Во-первых, это переквалификация персонала. В то время как центральной команде необходимы навыки для разработки и поддержки фабрик агентов (обеспечение стандартизации и соответствия нормативным требованиям, внедрение передовых методов и т. д.), инженерам-программистам по всей организации необходимо развивать навыки принятия решений, код-ревью и управления агентами, с которыми они работают. Роли смещаются от ручной координации и тестирования к обеспечению согласованности архитектуры, моделированию предметной области и управлению ИИ.</p> <p>Во-вторых, необходимо обеспечить участие в агентной разработке всех «внешних» звеньев — специалистов по поддержке и соблюдению нормативных требований в отделах рисков, юриспруденции, тестирования и закупок. Без этого ускоренный SDLC не приведет к ускорению прогресса. Агенты и автоматизация (например, с помощью политики как кода) могут помочь гарантировать, что эти механизмы контроля не станут узкими местами, одновременно повышая качество, согласованность, полноту и отслеживаемость. Эти механизмы контроля должны быть заложены в основу проекта, а не становиться препятствием в конце процесса.</p> <p>И третье — это перепроектирование распределения ресурсов таким образом, чтобы повышение производительности приводило к созданию новой ценности. Освобожденные ресурсы часто реинвестируются для ускорения реализации дорожных карт, модернизации платформ или запуска новых продуктов.</p> <p>Главный вывод: повышение производительности может быть преобразовано в структурные изменения портфеля. Измените размер команд и сознательно перераспределите ресурсы, чтобы получить максимальную выгоду.</p> <p>Трансформация должна начинаться там, где ее влияние наиболее велико. В большинстве технологических организаций бóльшая часть общих расходов приходится на небольшое количество крупных программ. Целенаправленное выполнение этих инициатив — будь то модернизация унаследованных систем, переделка существующих объектов или запуск новых продуктов — максимизирует видимый эффект и ускоряет обучение.</p> <p>Если агенты возьмут на себя выполнение задач в масштабе и будут создавать надежный и стабильно безопасный код, роль человека будет концентрироваться в архитектуре, оценке продукта и проектировании систем, что сделает институциональные знания и техническую согласованность решающими факторами дифференциации. Организации, которые начнут развивать эти возможности в рамках более широких усилий по перестройке своей операционной модели, не просто будут двигаться быстрее; они переосмыслят то, как ПО создает ценность.</p> То, как сегодня агентный искусственный интеллект используется в разработке ПО, является предвестником более широких … article https://www.itweek.ru/themes/detail.php?ID=234940 Tue, 02 Jun 2026 16:12:14 +0300 <p>Axiom JDK объявила о выпуске Axiom Trusted Images — линейки доверенных контейнерных образов для разработки и промышленной эксплуатации приложений в Kubernetes и cloud-native инфраструктуре. Впервые продукт был представлен 2 июня в Москве на конференции «БеКон», посвященной безопасному использованию контейнеров и контейнерных сред.</p> <p>Новый продукт помогает компаниям снизить риски безопасности в контейнерной инфраструктуре и ускорить вывод цифровых сервисов в промышленную эксплуатацию. Axiom Trusted Images предоставляют проверенный базовый слой контейнеров вместо разрозненных публичных образов с непрозрачным составом, лишними компонентами и уязвимостями, которые требуют дополнительного анализа со стороны ИБ, DevOps и разработки.</p> <p>Выпуск Axiom Trusted Images стал развитием продуктовой экосистемы Axiom JDK. Исторически компания решает задачи безопасной эксплуатации Java-приложений. Но современные корпоративные системы состоят из разных технологических компонентов: NGINX, Node.js, Go, C, C++, специализированных runtime-сред и контейнерной инфраструктуры. Каждый из этих компонентов становится частью контура промышленной эксплуатации, поэтому бизнесу нужен единый подход к безопасности базовых контейнерных образов независимо от языка разработки и типа сервиса.</p> <p>Axiom Trusted Images помогают компаниям получить несколько ключевых бизнес-преимуществ:</p> <ul> <li>снизить поверхность атаки за счёт минимального состава контейнерных образов и вариантов поставки под разные сценарии: shell, distroless, rootless;</li> <li>сократить количество CVE в базовом слое за счёт удаления лишних компонентов, постоянного мониторинга и регулярного обновления образов;</li> <li>упростить подготовку к требованиям ИБ, регуляторов и внутреннего аудита благодаря SBOM, цифровой подписи и подтверждённому происхождению образов;</li> <li>ускорить прохождение проверок безопасности перед запуском продуктов за счёт прозрачного состава, фиксированных версий и понятного процесса устранения уязвимостей;</li> <li>высвободить время разработчиков, DevOps и платформенных команд, которые вместо ручного сопровождения базовых образов могут сосредоточиться на запуске новых сервисов;</li> <li>стандартизировать контейнерный слой для разных команд и технологических стеков за счёт готовых доверенных образов для NGINX, Node.js, Go, C, C++ и других сценариев.</li> </ul> <p>«Контейнеры ускорили разработку и сделали доставку приложений в эксплуатацию более гибкой, но одновременно усложнили контроль того, что именно попадает в промышленную среду. Для бизнеса это уже не только технический вопрос, но и вопрос скорости релизов, управляемости рисков и готовности к аудиту. Axiom Trusted Images позволяют сделать базовый контейнерный слой прозрачным, минимальным и сопровождаемым, чтобы команды могли быстрее выводить новые продукты на рынок без компромиссов по безопасности», — отметил Роман Карпов, генеральный директор Axiom JDK.</p> <p>В состав линейки входят доверенные образы для разных технологических стеков, включая NGINX, Node.js, Go, C, C++. Для Java-сценариев в экосистеме Axiom JDK доступен отдельный продукт — Axiom Runtime Container Pro, предназначенный для экономичного и безопасного запуска Java-приложений в контейнерной среде.</p> <p>Основа Axiom Trusted Images — Axiom Linux, специализированный лёгкий дистрибутив для контейнеров, который поставляется в вариантах musl и glibc. Он используется как компактный базовый слой для защищённых образов под разные технологические стеки.</p> <p>Решение поддерживает платформы x86_64 и ARM64, а также развёртывание на российских Linux-дистрибутивах и Kubernetes-платформах. Axiom Trusted Images можно использовать как замену стандартных базовых образов: обычно для подключения достаточно изменить ссылку на базовый образ в Dockerfile.</p> <p>Axiom JDK регулярно проверяет представляемые образы на известные уязвимости и устраняет их в рамках SLA. Это делает работу с CVE более предсказуемой и снижает нагрузку на команды эксплуатации.</p> <p>Актуальность решения подтверждается ростом внимания к безопасности контейнеров и DevSecOps-практикам. По данным State of DevOps Russia 2025, 46,8% респондентов уже используют сканеры уязвимостей контейнерных образов, а 35,6% — анализаторы конфигураций Kubernetes. При этом внедрение ИБ-инструментов остаётся сложной задачей: 45,5% участников отмечают нехватку технической экспертизы, 42,2% — проблемы совместимости, а 26,8% признают, что результаты проверок им непонятны. Для контейнерной инфраструктуры это особенно критично: недостаточно просто запустить сканирование образов, нужно интерпретировать CVE, понимать состав базового слоя, оценивать риски, пересобирать образы и готовить доказательную базу для ИБ и аудита. Такой процесс требует значительных ресурсов и отвлекает DevOps, ИБ и разработку от вывода новых продуктов на рынок.</p> <p>Axiom Trusted Images особенно актуальны для организаций, развивающих Kubernetes-платформы, микросервисную архитектуру, внутренние платформы разработки, а также для компаний с повышенными требованиями к информационной безопасности, аудиту и промышленной эксплуатации. </p> Axiom JDK объявила о выпуске Axiom Trusted Images — линейки доверенных контейнерных образов для разработки … message https://www.itweek.ru/themes/detail.php?ID=234939 Tue, 02 Jun 2026 16:09:48 +0300 <p>Yandex B2B Tech обновила ИИ-помощника для анализа и визуализации данных — Нейроаналитика. Агент стал умнее: теперь он не просто делает выводы по готовым дашбордам, а может напрямую обращаться к сырым корпоративным данным компании и самостоятельно создавать аналитические отчеты. Это позволит бизнесу ускорить и улучшить аналитику на базе искусственного интеллекта в организации. Обновленный ИИ-агент доступен всем пользователям в BI-системе Yandex DataLens.</p> <p>Раньше Нейроаналитик работал только с готовыми отчётами: пользователь заранее строил графики, а агент помогал в них разобраться — подсказывал формулы, находил инсайты. Теперь достаточно задать вопрос в свободной форме на естественном языке — агент сам найдёт нужные данные в корпоративном источнике и создаст подробные визуализации с выводами. Так, например, можно узнать, как менялась выручка конкретного менеджера в определённом городе за последний месяц. Нейроаналитик работает с корпоративными данными внутри DataLens в рамках прав доступа, которые настроены в системе для каждого пользователя.</p> <p>По данным отраслевых исследований, специалисты по работе с данными тратят до 20 часов в неделю на доступ, объединение и подготовку данных вместо непосредственного анализа. При этом 92% аналитиков предпочли бы заниматься другими задачами вместо подготовки данных, но 65% всё равно проводят за ней минимум половину рабочего времени. Нейроаналитик забирает эту нагрузку на себя: специалисты по данным могут сосредоточиться на более сложных задачах — определять ключевые вопросы, выбирать нужные разрезы и формулировать гипотезы — а бизнес-пользователи получают ответы быстро, без необходимости знать формулы или структуру данных.</p> <p>В Yandex DataLens появился виджет с готовыми подсказками от ИИ-помощника прямо на аналитическом дашборде. Теперь пользователю не нужно каждый раз писать сложные промпты к дашбордам и обновлять их, достаточно один раз дать агенту простую инструкцию на естественном языке. При каждом открытии дашборда агент анализирует нужные данные и показывает актуальный статус. Это удобно для сотрудников, которые не занимаются аналитикой профессионально: например, оператор склада без сложных промптов понимает, есть ли проблемы с текущими заказами.</p> <p>«Самый сложный момент в аналитике — это осмысление данных, время, которое порой уходит на то, чтобы предподготовить их и оформить в нужном представлении. Мы движемся к модели, в которой пользователь сможет работать с данными через единый интерфейс напрямую и быстро: задавать вопросы к анализу, получать предподготовленные данные и способы их визуализации моментально, оставляя механистичный труд Нейроаналитику», — рассказал технический директор Yandex Cloud Иван Пузыревский.</p> <p>В будущем у Нейроаналитика появится еще больше обновлений. В новых версиях агент сможет помогать пользователям искать нужные дашборды и отвечать на вопросы по работе с Yandex DataLens на основе документации сервиса и внутренней базы знаний компании.</p> Yandex B2B Tech обновила ИИ-помощника для анализа и визуализации данных — Нейроаналитика. Агент стал умнее: теперь … message https://www.itweek.ru/themes/detail.php?ID=234937 Tue, 02 Jun 2026 11:27:10 +0300 <p>Эксперты компании «Информзащита» зафиксировали рост активности атак на корпоративные учетные записи с использованием техники распыления паролей. По данным исследований компании, в 2026 году злоумышленники ежемесячно задействуют более 12000 уникальных spray IP, каждый из которых атакует не менее 10 учетных записей. По сравнению с концом 2025 года число таких IP увеличивается в среднем на 11% месяц к месяцу, а доля неуспешных попыток входа в корпоративные сервисы держится на уровне <nobr>28-30%.</nobr> Для бизнеса это означает, что атака на идентификационные данные фактически превратились в постоянный фоновый процесс: злоумышленники не ждут отдельного повода, а регулярно проверяют облачные сервисы, почтовые системы и удаленные рабочие контуры на слабые пароли и у компаний нет периодов, когда риск можно считать низким.</p> <p>Техника распыления паролей отличается от классического перебора тем, что атакующий не сосредотачивается на одной учетной записи. Вместо тысяч попыток входа к одному пользователю он берет ограниченный набор популярных, утекших или сгенерированных паролей и последовательно проверяет их на большом массиве сотрудников. Попытки распределяются по разным IP-адресам, странам, автономным системам и временным интервалам. В журналах безопасности такая активность выглядит как множество несвязанных между собой отказов, а не как очевидная брутфорс-атака. Именно поэтому простые правила блокировки по числу ошибок с одного адреса уже не дают нужного эффекта: при использовании только таких порогов распределенные атаки закономерно проходят мимо системы мониторинга и воспринимаются как «нормальный» фон.</p> <p>Рост таких атак связан с доступностью инфраструктуры. Атакующие используют облачные серверы, прокси-сети, скомпрометированные домашние маршрутизаторы, а также одноразовые узлы, которые быстро выводятся из кампании после попадания в списки блокировки. На практике один и тот же сценарий может одновременно затрагивать десятки организаций, но в каждой из них оставлять лишь слабый след. Отдельную роль играет качество парольных словарей, так как злоумышленники часто формируют их не только из открытых утечек, но и с учетом региональной лексики, названий компаний, корпоративных шаблонов и типовых правил сложности пароля. В результате снижается объем шума, но повышается шанс успешного входа.</p> <p>В 2026 году техника распыления паролей используется как первый этап цепочки. После успешной аутентификации атакующий проверяет почтовый ящик, создает правила пересылки, пытается получить доступ к файловым хранилищам, внутренним чатам и административным панелям. В ряде случаев за первичным входом следует попытка захвата сессии и изменения параметров MFA, затем — подключение сторонних приложений через OAuth или проверка устаревших протоколов, где многофакторная аутентификация работает неполноценно . По оценке «Информзащиты», доля инцидентов, в которых после распыления паролей фиксировались признаки дальнейшего движения по облачной среде, выросла с 18% в конце 2025 года до 27% в первом полугодии 2026 года, что говорит не только о росте количества атак, но и о большей «глубине» их развития внутри облачной инфраструктуры</p> <p>По отраслевой структуре чаще всего такие атаки затрагивают финансовые организации и страховые компании: на них приходится около 24% наблюдаемых случаев. ИТ-компании и сервисные провайдеры занимают 19%, ритейл и e-commerce — 17%, промышленность и логистика — 14%, профессиональные сервисы и консалтинг — 11%, образовательные организации — 8%, здравоохранение — 7%. У каждой отрасли свой фактор риска. В финансах атакующих привлекают платежные процессы и доступ к клиентским данным, в ИТ — возможность выйти на инфраструктуру заказчиков, в ритейле — высокая доля внешних сервисов и сезонные пики нагрузки, в промышленности — сложная сеть подрядчиков и удаленного доступа, что также говорит о том, что злоумышленники чаще переходят от проверки учетной записи к полноценному движению внутри облачной инфраструктуры.</p> <p>Разбивка по векторам атак показывает, что техника распыления паролей занимает около 38% попыток первичного доступа к корпоративным аккаунтам. На credential stuffing с использованием утекших баз приходится 24%, на атаки через устаревшие протоколы — 14%, на AiTM-фишинг и повторное использование токенов — 11%, на злоупотребление OAuth-разрешениями и device code flow — 7%, на MFA fatigue — 4%, на атаки через сервисные учетные записи, API-ключи и другие non-human identities — около 2%. Эти цифры показывают, что пароль остается удобной точкой входа, но сам инцидент почти всегда развивается шире: от проверки учетной записи до закрепления в почте, облаке или бизнес-приложении, поэтому фокус мониторинга только на этапе аутентификации уже недостаточен.</p> <p>Для снижения рисков компаниям в первую очередь следует отключать устаревшие протоколы там, где они не нужны бизнесу, вводить phishing-resistant MFA для привилегированных, финансовых и административных ролей, регулярно проверять корпоративные пароли на наличие в утечках и исключать повторное использование паролей между сервисами. Отдельного контроля требуют успешные входы после серии отказов, смена MFA-параметров, создание правил пересылки в почте, выдача OAuth-разрешений, входы с новых устройств и активность из нетипичных регионов. Простых блокировок по числу ошибок уже недостаточно: техника распыления паролей как раз рассчитана на обход таких порогов. Рабочая защита строится на корреляции событий, поведенческой аналитике, контроле сессий, инвентаризации сервисных учетных записей и быстрой проверке каждого успешного входа, которому предшествовала распределенная подозрительная активность. В противном случае атака так и останется в логах в виде набора несвязанных между собой «обычных» событий.</p> Эксперты компании «Информзащита» зафиксировали рост активности атак на корпоративные учетные записи с использованием … message https://www.itweek.ru/themes/detail.php?ID=234936 Tue, 02 Jun 2026 11:24:14 +0300 <p>Компания BSS и Федеральное государственное бюджетное образовательное учреждение высшего образования «Ижевский государственный технический университет имени М.Т. Калашникова» (ИжГТУ) заключили партнерское соглашение о сотрудничестве в сфере подготовки кадров для цифровой экономики.</p> <p>Партнерство направлено на интеграцию актуальных отраслевых знаний и практического опыта в образовательный процесс, а также на создание для студентов прямого пути к стажировкам и трудоустройству в технологической компании. Документ подписан в рамках исполнения требований постановления Правительства РФ и закрепляет долгосрочное взаимодействие вуза и ИТ-бизнеса.</p> <p>Взаимодействие сторон будет строиться на взаимовыгодных основах и конкретных обязательствах, нацеленных на практический измеримый результат. Сотрудничество сфокусируется на следующих направлениях:</p> <ol> <li>преподавание экспертов BSS в ИжГТУ. Специалисты компании — практики в области искусственного интеллекта, больших языковых моделей (LLM), технологии RAG и речевой аналитики — будут проводить лекции, практические занятия и мастер-классы для студентов ИжГТУ по ИТ-дисциплинам;</li> <li>стажировки и трудоустройство в BSS. Лучшие студенты получат возможность пройти стажировку в BSS с назначением персональных наставников и последующим рассмотрением кандидатур для трудоустройства;</li> <li>разработка образовательных программ. Эксперты BSS примут участие в актуализации рабочих программ дисциплин, программ практик и учебно-методических материалов, обеспечивая их соответствие актуальным требованиям рынка труда.</li> </ol> <p>«Для BSS образование — это стратегическая инвестиция в будущее отрасли. Мы видим высокий потенциал у студентов ИжГТУ и готовы делиться с ними экспертизой, накопленной за 30 лет разработки программного обеспечения и работы с крупнейшими предприятиями. Наши технологии — это не просто код, это решения, которые уже сегодня автоматизируют контакт-центры, улучшают клиентский опыт и трансформируют бизнес-процессы. Мы хотим, чтобы выпускники вуза приходили к работодателям с пониманием реальных задач и готовыми компетенциями», — отметил Георгий Кравченко, Генеральный директор BSS.</p> <p>Партнерство BSS, обладающей уникальной экспертизой, с ИжГТУ позволит студентам получить доступ к передовым технологиям ИИ, речевым платформам и современным инструментам по созданию ИИ-агентов и мультиагентных систем. Соглашение призвано способствовать укреплению связей между академическим сообществом и технологическим бизнесом, что критически важно для подготовки кадров для цифровой экономики.</p> <p>ИжГТУ имени М.Т. Калашникова — один из ведущих технических вузов Приволжского федерального округа, реализующий программы подготовки по IT-направлениям «Информационные системы и технологии», «Прикладная информатика», «Программная инженерия». Университет активно развивает цифровую образовательную среду и сотрудничает с индустриальными партнерами для обеспечения практической ориентированности обучения.</p> <p>«Цифровизация инженерного образования — наш приоритет. Партнерство с BSS открывает для студентов уникальную возможность работать с технологиями уровня enterprise, участвовать в реальных проектах и формировать портфолио еще до выпуска. Это именно тот формат „университет 4.0“, к которому мы стремимся», — подчеркнул заведующий кафедрой «Информационные системы» Максим Горохов, ответственный за взаимодействие с индустриальным партнером в лице BSS от ИжГТУ.</p> Компания BSS и Федеральное государственное бюджетное образовательное учреждение высшего образования «Ижевский … message https://www.itweek.ru/themes/detail.php?ID=234935 Tue, 02 Jun 2026 09:18:01 +0300 <p><em>В условиях роста сетевых заторов ИТ-командам необходимо сокращать дублирование инструментов, контролировать затраты и готовиться к AIOps и агентам искусственного интеллекта, пишет на портале </em><em>InformationWeek</em> <em>Мэри Шеклет, президент консалтинговой компании Transworld Data.</em></p> <p>Затор (logjam) определяется как «непреодолимое скопление или клубок логов», подобно тому, как бревна накапливаются в реке и перекрывают ее. В сети, которая сама по себе является рекой коммуникаций, сетевые сотрудники также сталкиваются со своего рода заторами.</p> <p>Они тонут в океане избыточных логов. Избыточное сетевое журналирование перегружает процессоры, переполняет память и сбивает с толку сетевых сотрудников, которые пытаются расшифровать, какие логи являются — и должны быть — пригодными для использования.</p> <p>Между тем, ежедневные заторы данных и рабочих процессов превращаются в более серьезную проблему, поскольку сетевые сотрудники стремятся объединить инструменты, которые стандартный сетевой мониторинг, наблюдаемость, AIOps и теперь агенты ИИ навязали им для мониторинга телеметрии и других сетевых событий на все более детальном уровне.</p> <p>Эти технологии пересекаются друг с другом, и дублирование приводит к неэффективному расходованию корпоративных ИТ-ресурсов. Как ИТ-службы могут контролировать затраты? И как сетевым сотрудникам избежать дублирования усилий, когда они все еще пытаются понять, какие инструменты следует использовать и для чего?</p> <h3>Понимание типов сетевых проблем, требующих решения</h3> <p>Современные ИТ-сети охватывают центральные ИТ-подразделения, периферийные узлы, облачные локации, а также удаленные домашние и полевые офисы. Стандартные инструменты мониторинга сети, которые до сих пор используются многими подразделениями, были разработаны для монолитных сетей, таких как единая корпоративная сеть масштаба предприятия. Они не могут справиться со сложностями гибридной сетевой топологии, выходящей за пределы предприятия.</p> <p>Подразделения это понимают, как и поставщики сетевого оборудования. И те, и другие видят необходимость обновления планов развития средств управления сетью, поскольку почти никто больше не работает с монолитными корпоративными сетями.</p> <p>Перед ними стоит вопрос: какие надлежащие инструменты и методологии следует обновить — и какие существующие инструменты можно исключить?</p> <h3>Навигация по инструментам</h3> <p>Существуют четыре категории инструментов мониторинга и предотвращения сбоев в сети:</p> <ol> <li><strong> Стандартный мониторинг сети. </strong>Стандартный мониторинг сети самодостаточен, поскольку это зрелая технология, и сотрудники хорошо с ней знакомы. Он использует метрики сетевого трафика, использования ЦП и ресурсов хранения, допустимых ошибок и времени отклика, но ИТ-специалисты должны предварительно определить эти метрики. Инструменты мониторинга выдают оповещения, когда происходит превышение этих предопределенных метрик, и затем задача ИТ-специалистов — найти и устранить проблемы.</li> <li><strong> Наблюдаемость. </strong>Стандартный мониторинг сети недостаточен, поскольку он сообщает только о том, что ИТ-специалисты предварительно для него определили. Наблюдаемость идет глубже. Она сообщает не только о нарушениях метрик, но и о том, где и почему произошло нарушение. Она предоставляет эту информацию, анализируя метрики, журналы и трассировки — и соответствующее ПО может делать это автономно. Это дает ИТ-специалистам преимущество в решении проблем.</li> <li><strong> AIOps. </strong>Цель AIOps — расширить возможности наблюдаемости за счет применения ИИ и автоматизации для решения проблем. Недостаток AIOps заключается в том, что при анализе данных эта методология имеет ограниченное представление о контексте сетевого события. Она даже не может определить, являются ли анализируемые телеметрические данные достоверными. Именно здесь по-прежнему должна вмешиваться ИТ-служба, поскольку для подтверждения достоверности результатов AIOps и применения исправлений требуются специалисты по сетям.</li> <li><strong> Сетевые ИИ-агенты.</strong> Новая волна инструментов в виде сетевых ИИ-агентов пытается еще больше автоматизировать решение проблем там, где есть необходимость вмешательства сетевого персонала. ИИ-агенты автоматически обнаруживают и устраняют проблемы. Они делают это, используя машинное обучение для изучения истории производительности сети, чтобы получить бизнес-контекст того, как сеть должна функционировать.</li> </ol> <h3>Пять лучших практик управления переходом</h3> <p>Переход от стандартного мониторинга сети к наблюдаемости, затем к AIOps, а затем к сетевым ИИ-агентам — это естественное развитие ПО для управления сетями. Компании и поставщики это понимают, поэтому была определена эволюционная дорожная карта управления сетями.</p> <p>Но прежде чем они смогут приступить к реализации этой дорожной карты с использованием новых технологий, компании должны оценить, на каком этапе пути они находятся с точки зрения инструментов, персонала, бизнес-требований и затрат. Вот пять лучших практик:</p> <p><strong>1. Оцените свой текущий набор инструментов. </strong>Для многих сотрудников ИТ-подразделений, занимающихся сетевыми технологиями, разбор используемых в настоящее время инструментов — и тех, которые были забыты и лежат на полке — является колоссальной задачей. Но сейчас самое время этим заняться.</p> <p>Инструменты управления сетью должны быть учтены во всех сетях предприятия, независимо от того, находятся ли сети локально в дата-центре, на периферии предприятия или в облаке.</p> <p>Инструменты должны быть классифицированы по функциям, чтобы исключить любые дублирования. Если разные инструменты используются для одних и тех же функций в разных местах сети, эти инструменты должны быть стандартизированы в единый набор инструментов. Это упростит работу персонала, уточнив, какие инструменты следует использовать и как проводить обучение.</p> <p><strong>2. Встретьтесь с поставщиками для оценки их планов развития.</strong> Часть процесса инвентаризации и оценки инструментов — это взаимодействие с поставщиками инструментов, чтобы узнать, в каком направлении они движутся со своими планами развития.</p> <p>План развития средств управления сетью ясен: от стандартного мониторинга сети к наблюдаемости, затем к AIOps и, наконец, к сетевым ИИ-агентам.</p> <p>Если у поставщиков эта эволюция не отражена в их планах, пора искать тех, у кого она отражена.</p> <p><strong>3. Займитесь повышением квалификации персонала по AIOps. </strong>Большинство сотрудников, занимающихся корпоративными сетями, хорошо владеют стандартным мониторингом и уже работают с наблюдаемостью.</p> <p>Следующий шаг — внедрение автоматизации в наблюдаемость с помощью AIOps, что все еще находится в процессе, поскольку требует перестройки и, в некоторых случаях, переосмысления рабочих процессов сети.</p> <p>Сетевые сотрудники должны изучить новые инструменты AIOps, а также способы интеграции дополнительной AIOps-автоматизации в рабочие процессы сети и повседневные операции.</p> <p>Эти изменения должны быть задокументированы, а документация — слабое место в сетевых операциях.</p> <p>Чтобы обеспечить соответствие оперативной документации изменениям в рабочих процессах, целесообразно привлечь внешних аудиторов для проверки документации и операций, чтобы выявить и исправить любые несоответствия.</p> <p><strong>4. Очень осторожно внедряйте агентов ИИ. </strong>Концепция полностью автоматизированных сетевых операций с использованием агентов ИИ пока остается скорее теорией, чем фактом.</p> <p>Тем не менее, некоторые организации уже пробуют свои силы в этом направлении.</p> <p>Сетевые агенты ИИ используют машинное обучение для изучения прошлой производительности сети, чтобы получить бизнес-контекст для своей автоматизации. Но у них нет практических знаний и опыта, которыми обладают сотрудники сетевой службы.</p> <p>Рекомендуется первоначально внедрять сетевых ИИ-агентов в хорошо предсказуемых и контролируемых сетях с низким риском изменений или аномалий.</p> <p><strong>5. Оцените ценность унаследованных технологий. </strong>Унаследованные технологии означают не только старость, но и проверенность, надежность и долговечность.</p> <p>Существуют инструменты управления сетью, которые выдержали испытание временем и продолжают хорошо работать.</p> <p>При анализе имеющихся инструментов организациям следует внимательно изучить, что продолжает приносить пользу. Безусловно, следует совершенствовать инструменты и навыки, но не стоит выбрасывать то, что по-прежнему хорошо работает.</p> В условиях роста сетевых заторов ИТ-командам необходимо сокращать дублирование инструментов, контролировать затраты … article https://www.itweek.ru/themes/detail.php?ID=234933 Tue, 02 Jun 2026 09:04:12 +0300 <p>Представьте типичную ситуацию: компания закупает корпоративный ИИ-инструмент, проводит обучение, запускает пилот. Через три месяца — <nobr>5-10%</nobr> активных пользователей, остальная команда возвращается к привычным инструментам. Формально внедрение состоялось, но реального эффекта нет.</p> <p>По данным McKinsey   Company, большинство компаний до сих пор не получают системного результата от внедрения ИИ, несмотря на рост инвестиций. И дело здесь не в качестве самих инструментов.</p> <p>Главная причина в другом: то, что принято называть «саботажем», на самом деле является рациональной реакцией системы на плохо выстроенное внедрение.</p> <p>Сотрудники не игнорируют ИИ — они выбирают способ работы, который дает предсказуемый результат и не создает дополнительных рисков. Чтобы понять это поведение, важно посмотреть не только на людей, но и на то, как именно компания внедряет изменения.</p> <h3>Саботаж — это не проблема сотрудников</h3> <p>В большинстве компаний саботаж объясняют через психологию: страх, нежелание меняться, сопротивление новому. На практике это поверхностное объяснение.</p> <p>Сотрудник не обязан использовать инструмент только потому, что он «внедрен». Он оценивает его с точки зрения своей ежедневной работы: ускоряет ли инструмент задачи, снижает ли риски ошибок, делает ли результат более предсказуемым.</p> <p>Если ответ отрицательный, отказ от использования — рациональный выбор.</p> <p>Поэтому не стоит считать саботаж сбоем в поведении людей. Это сигнал: система внедрения ИИ не создает достаточной ценности в реальной работе.</p> <h3>Почему люди не доверяют ИИ</h3> <p>Ключевая причина сопротивления кроется не в страхе как таковом — все дело в незнании. Человек не понимает, как новый инструмент работает, где допускает ошибки, можно ли ему доверять. В такой ситуации любое использование ИИ воспринимается как риск, и первое же закономерное желание, которое возникает у сотрудника — отказаться от него вовсе.</p> <p>Это универсальный механизм: люди боятся не технологий, а неопределенности. Чем лучше человек понимает систему, тем ниже уровень сопротивления. И наоборот — отсутствие понимания почти неизбежно приводит к отказу от использования.</p> <h3>Два типа сотрудников</h3> <p>После появления ИИ команды почти всегда делятся на две группы. Первая — любопытные. Они начинают экспериментировать, тестируют сценарии, адаптируют инструмент под свои задачи и быстро усиливают свою эффективность.</p> <p>Вторая — нелюбопытные. Они не пытаются разобраться, занимают позицию «докажите, что это работает» и в итоге выпадают из процесса.</p> <p>Это не вопрос квалификации — это вопрос поведения. И именно от соотношения этих двух групп во многом зависит успех внедрения. Если нелюбопытных сотрудников оказывается больше, внедрить новую технологию очень тяжело. Речь не только об ИИ — такие члены команды, как правило, не заинтересованы в любых изменениях.</p> <h3>Главный риск — не сотрудники, а руководство</h3> <p>Отдельный специалист в команде может не использовать ИИ. Система это переживет — и, более того, однажды просто «переварит» такого человека, потому что он закономерно будет отставать от остальных.</p> <p>Если же внедрению искусственного интеллекта сопротивляется руководитель, ситуация сразу осложняется. Он задает норму, от его действий не в последнюю очередь зависит, как быстро сотрудники освоят новую технологию. Когда руководитель сам не применяет ИИ в работе и не верит в него, инициативы будут блокироваться, а внедрение фактически остановится.</p> <p>Поэтому основная трудность — не сопротивляющиеся сотрудники, а отсутствие поддержки изменений на уровне управления.</p> <h3>Как проявляются психологические барьеры</h3> <p>Психологические барьеры сотрудников, которые стоят между ними и освоением ИИ, выражаются в виде поведенческих сигналов. Если научиться их распознавать, будет легко понять, что именно тревожит члена команды.</p> <ul> <li> Страх потери экспертизы. Сотрудники опасаются, что их знания обесценятся. Это снижает готовность делиться опытом и пробовать новые инструменты.</li> <li> Недоверие к качеству результатов. Разовые ошибки или галлюцинации быстро формируют устойчивое ощущение, что инструмент требует больше времени на проверку, чем дает выгоды.</li> <li> Страх контроля. Если непонятно, что логируется и как используется, сотрудники начинают избегать корпоративных инструментов.</li> <li> Усталость от изменений. Каждый новый инструмент требует времени на освоение. Без явной ценности он воспринимается как дополнительная нагрузка.</li> </ul> <p>Важно, что эти препятствия усиливаются, если компания не задает понятных правил и сценариев работы.</p> <h3>Организационные барьеры: где ломается система</h3> <p>Возможно, сотрудники готовы активно использовать ИИ, но система не дает им делать это эффективно. Можно выделить несколько основных трудностей:</p> <ul> <li> Нет владельца со стороны бизнеса. Типичная ситуация: «ИТ внедрило, бизнес не использует». Без бизнес-владельца инструмент не привязан к реальным задачам.</li> <li> Нет четких сценариев использования. Формулировка «давайте внедрим ИИ» не работает — нужны конкретные кейсы с понятными метриками.</li> <li> Инструмент не встроен в процессы. Отдельный чат-бот почти всегда проигрывает привычным инструментам. ИИ должен работать внутри CRM, IDE или документов.</li> <li> Нет данных и контекста. Без доступа к корпоративным знаниям ИИ дает общие ответы, которые требуют ручной проверки.</li> <li> Безопасность блокирует внедрение. Если правила появляются в конце, запуск останавливается на этапе согласований.</li> <li> Нет поддержки после запуска. Разовое обучение не работает. Без постоянной помощи сотрудники возвращаются к старым инструментам.</li> <li> Неверные метрики. MAU показывает активность, но не эффективность. Важно измерять влияние на процесс: скорость, качество, нагрузку.</li> </ul> <h3>Почему «хорошая технология» не становится инструментом</h3> <p>Даже сильные решения не приживаются без системной встройки.</p> <p>Во-первых, у инструмента часто нет конкретной «работы», которую он должен выполнять. Он воспринимается как универсальный помощник, но не решает конкретную задачу.</p> <p>Во-вторых, пилот не превращается в процесс. На этапе тестирования все держится на энтузиастах, но после запуска отсутствуют роли, правила и поддержка.</p> <p>В-третьих, отсутствуют стимулы. Если KPI не меняются, сотрудники продолжают работать по-старому — это логично.</p> <p>И, наконец, нет итераций. Промпты, сценарии и базы знаний не улучшаются, и качество быстро перестает соответствовать ожиданиям.</p> <h3>Все упирается в управление изменениями</h3> <p>Ключевая проблема большинства внедрений в том, что ИИ воспринимается как инструмент, а не как изменение системы. Тогда как при трансформации по правилам change management, или управления изменениями, было бы правильно:</p> <ul> <li> сформировать рабочую группу;</li> <li> задать план внедрения;</li> <li> определить метрики;</li> <li> выделить бюджет и время;</li> <li> назначить ответственных.</li> </ul> <p>В результате команда получает новый инструмент, но не новую норму работы. А успех внедрения зависит именно от нормы — от того, донесут ли ее принципы и правила до команды, сможет ли команда приспособиться к ее условиям.</p> <h3>Как вести себя лидеру</h3> <p>Любое внедрение ИИ — это управляемое изменение, и у него должен быть лидер. Его задача заключается не в том, чтобы пассивно ждать, пока команда разберется сама и освоит новую технологию. Лидер задает направление — а значит, формулирует правила, объясняет, где и как использовать искусственный интеллект, поддерживает команду на этапе адаптации.</p> <p>Важно, что на этом этапе лидер фактически «верит за команду». Сотрудники могут относиться к идее внедрить ИИ скептически и быть не готовыми к изменениям, и задача лидера — зарядить их, направить в нужное русло. Если он сам не настроен на перемены, ничего не выйдет.</p> <h3>Нужно помнить, что сопротивление — нормальная часть процесса</h3> <p>Любая система сопротивляется изменениям, это не сбой. Очень редко бывает так, что людям предлагают попробовать что-то новое, и они сразу же радостно соглашаются.</p> <p>В случае с внедрением ИИ возможны два варианта развития событий:</p> <ul> <li> сотрудники начинают активно использовать ИИ-инструменты, адаптируются, наращивают экспертизу и усиливаются;</li> <li> сотрудники продолжают игнорировать изменения, отказываются от них — и в итоге выходят из системы, потому что становятся для нее либо слабым звеном, которое справляется со своими задачами, просто работает медленнее остальных, либо балластом, которые вообще не могут поддерживать темп команды.</li> </ul> <p>Компании, которые достигают успехов, учитывают это заранее и строят процессы с учетом неизбежного сопротивления.</p> <h3>Что в итоге</h3> <p>Саботаж искусственного интеллекта — это не проблема сотрудников и не признак их нежелания меняться. Это следствие того, что система не дает им понятного и безопасного способа, как использовать на практике новый инструмент.</p> <p>Важно помнить, что ИИ внедряется через процессы, новые нормы и грамотное управление изменениями. Здесь недостаточно обучения и лицензий хотя бы потому, что невозможно заставить сотрудников учиться, если они этого не желают.</p> <p>Без правильного внедрения команда возвращается к проверенным вариантам — тому, что работает. И будет странно требовать от них иного.</p> <p>#IMAGE_234934#</p> Представьте типичную ситуацию: компания закупает корпоративный ИИ-инструмент, проводит обучение, запускает пилот. Через три … article Константин Попандопуло, технический директор Umbrella IT https://www.itweek.ru/themes/detail.php?ID=234928 Mon, 01 Jun 2026 13:30:21 +0300 <p>Центр стратегических разработок опубликовал ежегодное исследование российского рынка информационной безопасности по итогам 2025 года и подготовил прогноз его развития до 2031 года. По оценке экспертов, рынок сохраняет устойчивую положительную динамику — выше среднемировых показателей и темпов роста большинства сегментов российского ИТ-сектора.</p> <p>«Рынок информационной безопасности в России демонстрирует стабильный рост. По итогам 2025 года рост составил 16,1% по сравнению с годом ранее. Это превышает глобальные тенденции и динамику большинства сегментов российского ИТ-сектора. Если текущие условия сохранятся, то к 2031 году рынок может превысить 1 трлн рублей, а среднегодовой темп роста в период с 2026 по 2031 годы составит 19,4%», — отметила заместитель генерального директора ЦСР Екатерина Кваша.</p> <p>Основу рынка формируют средства защиты информации (СЗИ) — 74% совокупного объема, или 271 млрд рублей (+18,1%). Крупнейшие категории — сетевая безопасность, защита инфраструктуры и защита конечных точек. Наибольшие темпы роста (+45,6 п.п. год к году) зафиксированы в сегменте защиты приложений (application security), что указывает на повышение значимости обеспечения безопасности прикладных контуров. Рынок услуг ИБ достиг 93,5 млрд рублей (+10,7%): острый дефицит квалифицированных специалистов продолжает стимулировать спрос на управляемые сервисы — MSS, MDR, SOC-as-a-Service.</p> <p>По объемам продаж средств защиты информации лидирует «Лаборатория Касперского» с долей 20,1% рынка (+0,5 п.п. год к году). Наиболее заметное усиление позиций показала Positive Technologies: доля компании выросла на 3,2 п.п., составив 16,8%. Среди ключевых игроков также ГК «Солар» и BI.ZONE, специализирующиеся на сервисах ИБ, и производители средств сетевой безопасности — «ИнфоТеКС», «Код Безопасности» и UserGate. Доля отечественных поставщиков на рынке СЗИ превысила 94%.</p> <p>В целом, российский рынок кибербезопасности сохраняет устойчивую положительную динамику сразу по нескольким направлениям. Первоначальная волна импортозамещения — когда организации в срочном порядке закрывали разрывы в защитном контуре — сменяется более зрелым подходом: компании переходят к системной перестройке ИБ-архитектур с акцентом на управляемость, интегрированность и доказуемую эффективность вложений. Параллельно меняется само восприятие кибербезопасности: из набора технических мер она превращается в элемент операционной устойчивости бизнеса — способность выдерживать атаки, сохранять непрерывность процессов и минимизировать финансовый ущерб.</p> <p>Дефицит кадров и регуляторное давление усиливают спрос на управляемые сервисы и платформенные решения, позволяющие быстро получить доступ к экспертизе без создания дорогостоящей внутренней инфраструктуры. Активное внедрение облачных технологий и ИИ расширяет цифровые возможности организаций, но одновременно увеличивает поверхность атаки и формирует новые классы рисков, требующих соответствующих подходов к защите.</p> Центр стратегических разработок опубликовал ежегодное исследование российского рынка информационной безопасности по итогам … message https://www.itweek.ru/themes/detail.php?ID=234926 Mon, 01 Jun 2026 00:00:00 +0300 <p>Многие компании верят: если мы внедрили CI/CD и наняли десяток DevOps-инженеров, мы стали Agile. На практике же TTM (Time-to-Market) часто не только не падает, но и растет. Почему? Потому что была совершена подмена понятий. Изначально, DevOps задумывался как способ <em>стереть границу</em> между кодом и инфраструктурой, сократить время ожидания разработчика на готовое окружение для разработки. В итоге мы построили новую <em>«админскую стену»,</em> только теперь обложенную YAML-файлами.</p> <p>В среде современного DevOps часто господствует «админский» подход. Люди месяцами спорят о выборе между Terraform, Pulumi, Helm, Kustomize или Ansible, выбирая «марку молотка», в то время как дом всё ещё не построен, а чертежи никто не видел. Забывается главная цель DevOps — сокращение TTM. Если выбор инструмента не ускоряет доставку фич, спор становится пустым: ресурсы тратятся на освоение инструментария, а не на доставку ценности. Такой подход заставляет внедрять решение просто потому, что команда его знает, а не потому, что оно оптимально (например, тащить Ansible туда, где достаточно простого Containerfile или Dockerfile). В этих спорах теряется принцип Shared Responsibility: важно не то, насколько красив манифест, а может ли разработчик самостоятельно внести в него правки, не дожидаясь администратора.</p> <p>Проблема усугубляется еще тем фактом, что многие компании создают «DevOps-подразделения», которые на самом деле являются просто отделами администрирования. Нередко это происходит так: руководство читает отчеты Gartner и видит, что «успешные компании используют Kubernetes и Terraform». В итоге покупается дорогой «молоток», нанимаются «мастера молотка», но гвоздей в компании нет. Инженерам приходится придумывать себе работу, создавая сложнейшие абстракции над простыми вещами, чтобы оправдать свое существование. Нередко автоматизируются те процессы, которые вообще не должны были существовать, или тратится время на написание сложных абстракций в каком-нибудь Helm, которые никто кроме автора не может понять. Но DevOps — это про коммуникацию, а не про то, как вы лихо умеете писать плейбуки в Ansible.</p> <p>Между тем, мы убили SysOps, заменив его эфемерным DevOps’ом. В компаниях, где нет своего кода, своей разработки, мы наблюдаем парад абсурда: люди внедряют технологии для <em>Continuous Deployment</em> туда, где деплоить нечего. Тратятся бюджеты на поддержку инфраструктуры для автоматизации самой автоматизации, стыдливо избегая честного слова «эксплуатация». Сейчас, признать, что вам нужен просто надежный SysOps — значит разрушить сложившийся миф и признать, что половина ваших модных инструментов — это просто балласт.</p> <p>Признать, что вам нужен качественный SysOps вместо карго-культового DevOps — это не шаг назад. Это шаг к эффективности. Ведь в конечном итоге бизнесу нужны работающие сервисы, а не красивые графики в ArgoCD, за которыми скрывается пустота.</p> <p>А что же не так с компаниями, в которых явно присутствует этап разработки программного обеспечения, теми компаниями, которые можно смело отнести к ISV? В компаниях-разработчиках админский DevOps нередко превращается в изощренную форму саботажа. Здесь выбор «марки молотка» напрямую бьет по прибыли: пока инженеры по эксплуатации полируют свои идеальные пайплайны, разработчики бьются лбом об ограничения инфраструктуры, которые им навязали «для их же блага». В итоге мы получаем продукт, который оброс костылями не из-за плохого кода, а из-за того, что его пытались засунуть в чуждую ему, избыточно сложную среду.</p> <p>Почему же DevOps стал инструментом администраторов, ведь CI/CD задумывался как способ дать разработчику контроль над доставкой кода (Self-Service)? Одна из причин заключается в том, что технологический порог входа стал так высок, что инструмент оказался в руках специалистов по инфраструктуре. Разработчикам становится всё сложнее поддерживать YAML-файлы на тысячи строк, они теперь должны быть наполовину системными программистами. Вместо написания бизнес-логики разработчики ПО вынуждены изучать HCL, копаться в репозиториях инфраструктуры и ждать завершения CI/CD-пайплайна, который падает из-за лишнего пробела. Кроме того, на российском рынке в крупных корпорациях (банки, госсектор) разделение на «тех, кто пишет» и «тех, кто катит» до сих пор сильнее, чем на Западе, из-за жестких требований безопасности и бюрократии. К тому же сложившийся дефицит кадров привел к тому, что проще нанять одного «звездного» DevOps-инженера, который настроит всё для десятка разработчиков, чем обучать всю команду нюансам инфраструктуры. В итоге, для разработчика программного обеспечения самообслуживание превратилось в самоистязание.</p> <p>В современных условиях DevOps-команда должна перестать быть «обслуживающим персоналом» или «хранителями ключей». Она должна стать <em>продуктовой командой</em>, чей продукт — это платформа, а ее клиент — это разработчик ПО. Целью должно стать создание условий, чтобы разработчик мог развернуть необходимый ему сервис, не вникая в YAML-описания конфигурации развертывания, без знания какая «марка молотка» использована под капотом. Необходимо выстраивание Internal Developer Platform (IDP), где разработчик нажимает кнопку «Создать среду» и получает готовое окружение за минуты, а не часы или даже дни. Необходимо перестать мерить успех количеством «закрытых тикетов» или «написанных скриптов». Метрикой успеха должно стать время, потраченное разработчиком на инфраструктуру. Если он тратит более 5% — модель DevOps убыточна. Переход к платформенной модели способен сократить цикл разработки с недель до часов. Это прямое снижения операционных расходов и реальный рывок в капитализации.</p> <p>Автоматизация ради автоматизации — это дорогое хобби, которое бизнес больше не может себе позволить. Настоящий DevOps начинается не с выбора между Terraform и Pulumi, а с вопроса: «Как это изменение поможет нам доставлять код быстрее и надежнее?». Если внедрение нового инструмента увеличивает TTM и строит новые заборы между командами — значит, вы просто сменили вывеску «Системное администрирование» на более модную, сохранив старые проблемы. Пора перестать коллекционировать «молотки» и начать, наконец, забивать гвозди. Чтобы ваша автоматизация не превратилась в «новые грабли», проведите ревизию процессов прямо сейчас:</p> <ul> <li> <strong>Упрощайте.</strong> Если задачу можно решить простым Containerfile, не тащите туда сложный Helm.</li> <li><strong>Стирайте границы</strong>. Разработчик должен иметь возможность сам управлять окружением. Используйте rootless-решения, которые позволяют запускать контейнеры без прав суперпользователя — это дает командам автономность, не создавая дыр в безопасности и лишних тикетов на админов.</li> <li><strong>Считайте метрики.</strong> Главный показатель успеха — это сокращение времени от идеи до выпуска в промышленную эксплуатацию, а не количество закрытых задач по автоматизации. DevOps — это мост, а не новая стена. Не дайте технологическому стеку стать препятствием на пути к здравому смыслу.</li> </ul> <p>#IMAGE_234927#</p> Многие компании верят: если мы внедрили CI/CD и наняли десяток DevOps-инженеров, мы стали Agile … article Дмитрий Гаврилов, основатель ООО “Открытые Технологии Виртуализации” https://www.itweek.ru/themes/detail.php?ID=234925 Mon, 01 Jun 2026 00:00:00 +0300 <p><em>Поскольку агентов ИИ на порядки больше, чем людей, устаревшие системы безопасности дают сбой. Джастин Долли, директор по работе с клиентами и безопасности компании Ory, рассказывает на портале </em><em>The</em> <em>New</em> <em>Stack</em> <em>о том, как защитить свою инфраструктуру с помощью системы управления идентификацией и доступом агентов (</em><em>Agent</em> <em>IAM).</em></p> <p>Переход от традиционных веб-приложений к агентным экосистемам — это не просто изменение пользовательского интерфейса; это фундаментальный сдвиг в модели угроз Интернета. Мы переходим из мира, где неправильный ввод создает неправильные данные, в мир, где неправильный ввод создает неправильные действия. В условиях, когда агенты ИИ эволюционируют от простых чат-ботов до автономных контроллеров, способных вызывать API, читать конфиденциальные файлы и отправлять электронные письма, наши устаревшие модели безопасности не выдерживают давления.</p> <p>Поскольку агентов уже на порядки больше, чем людей, если вы сегодня создаете или развертываете агентов ИИ, вы, вероятно, сталкиваетесь с замаскированной проблемой IAM. Согласно недавнему глобальному опросу Enterprise Management Associates (EMA) «Agentic AI Identities», 95% респондентов используют ИИ-агентов в производственной среде или ограниченных пилотных программах.</p> <p>Рассмотрим, как осуществить переход от человекоцентричной безопасности к эре Agent IAM.</p> <h3>1. В чем проблема: идентификационный вакуум</h3> <p>Основная проблема заключается в том, что агенты ИИ в настоящее время работают в условиях идентификационного вакуума. В большинстве производственных сред агентам предоставляется общий, унаследованный доступ. Они работают как служебные учетные записи с широкими правами доступа или, что еще хуже, наследуют полные права доступа пользователя, который их запустил.</p> <p>Это создает три критические уязвимости:</p> <ul> <li><strong> Модель угроз, основанная на действиях (</strong><strong>Action</strong><strong>-</strong><strong>Based</strong> <strong>Threat</strong> <strong>Model</strong><strong>).</strong> В отличие от традиционных приложений, агенты что-то «делают». Если большую языковую модель (LLM) обманут с помощью инъекции промпта, она не просто отобразит неправильный ответ; она выполнит вызов вредоносного инструмента. 80% респондентов <a href="https://www.osohq.com/learn/why-your-authorization-model-wont-survive-agentic-ai">сообщают</a> о случаях, когда приложения действуют за пределами предполагаемых границ.</li> <li><strong> Поверхность атаки системы RAG. </strong>Системы генерации с расширенной выборкой (RAG) уязвимы для косвенной инъекции промптов. Если агент получает документ, содержащий вредоносные инструкции, этот документ становится новым владельцем («мастером») агента, игнорируя меры защиты разработчиков.</li> <li><strong> Взрывной рост использования нечеловеческих идентификаторов (NHI).</strong> Мы наблюдаем массовый всплеск роста API, сервисов и автономных агентов, которым не хватает централизованного источника достоверной информации об идентификации. 39% респондентов опроса SailPoint «AI agents: The new attack surface» сообщают об инцидентах несанкционированного доступа агентов, и у большинства команд нет возможности отозвать доступ отдельного агента, не нарушив работу всего сервиса.</li> </ul> <h3>2. Почему это важно: растущий разрыв в устранении уязвимостей</h3> <p>Недавнее появление Claude Mythos от Anthropic <a href="https://www.ory.com/blog/anthropic-mythos-iam-identity-security-risk">повысило ставки</a>. Модель выявила тысячи уязвимостей нулевого дня в основных ОС и браузерах, включая ошибки, которые пережили более 20 лет проверки людьми.</p> <p>Это важно, потому что ИИ теперь является множителем силы для обнаружения уязвимостей. Хотя ИИ может находить ошибки со скоростью машины, люди по-прежнему устраняют их в «человеческом темпе» (совещания, бэклоги, циклы обновления).</p> <p>Если ваша инфраструктура IAM является собственной разработкой или неуправляемым Open Source, вы не сможете достаточно быстро обновлять ее, чтобы угнаться за злоумышленником, использующим ИИ. Идентификация — наиболее уязвимый уровень, поскольку это плоскость управления; если идентификация агента скомпрометирована, вся инфраструктура становится открытой для горизонтального перемещения. Исследование SailPoint показывает, что 33% респондентов сталкивались с ненадлежащим обращением агентов с данными с ограничен доступом.</p> <h3>3. Как решить проблему: план управления идентификацией и доступом для агентов</h3> <p>Для решения проблемы агентной безопасности необходимо перенести ограничительные механизмы с <nobr>LLM-промптов</nobr> на инфраструктуру. Вы не можете уговорить агента действовать безопасно; вы должны авторизовать его действовать безопасно. Усугубляет проблему агентной безопасности тот факт, что большинство участников опроса EMA считают, что их IAM-решения не готовы к новой реальности:</p> <ul> <li> 62% заявляют о неготовности к отказоустойчивости агентов;</li> <li> 49% утверждают, что не готовы к соответствию нормативным требованиям для агентов;</li> <li> 62% сообщают о неготовности к масштабируемости агентов;</li> <li> 59% заявляют о неготовности к безопасности агентов.</li> </ul> <p><strong>Относитесь к агентам как к первоклассным идентификаторам. </strong>Агенты должны рассматриваться как первоклассные нечеловеческие идентификаторы. Это означает:</p> <ul> <li><strong> Аутентификация.</strong> Агенты должны проходить аутентификацию у провайдера идентификации, используя учетные данные с ограниченной областью действия.</li> <li><strong> Токены с коротким сроком действия.</strong> Используйте OAuth2 для выдачи токенов, ограниченных областью взаимодействия. Если агент скомпрометирован, токен быстро истекает, ограничивая окно эксплуатации уязвимости.</li> <li><strong> Управление доступом на основе отношений (ReBAC).</strong> Используйте модель разрешений на основе графа, чтобы точно определить, к чему может получить доступ агент.</li> <li><strong>Согласование извлечения с авторизацией. </strong>В системах RAG разрешение на «просмотр» должно соответствовать разрешению на «извлечение». Прежде чем агент получит документ для размещения в его контекстном окне, система должна проверить: имеет ли этот конкретный Agent ID разрешение на просмотр этого Document ID? Если нет, документ никогда не будет получен, что предотвратит просмотр агентом вредоносного кода и его воздействие на него.</li> <li><strong>Инженеры как дирижеры. </strong>Измените свой инженерный подход. Перестаньте пытаться жестко запрограммировать каждое действие агента. Вместо этого действуйте как дирижер, управляя агентами с помощью политики как кода. Используйте инструменты для визуализации этих сложных цепочек разрешений, чтобы точно видеть, как отношения между агентами разрешаются в «РАЗРЕШИТЬ» или «ОТКАЗАТЬ».</li> </ul> <h3>Подводные камни и как их избежать</h3> <p>Даже при наличии продуманного плана часто возникают скрытые издержки и технические ловушки:</p> <ul> <li><strong> Ловушка унаследованного доступа:</strong> <ul> <li> Проблема: разработчики часто предоставляют агентам права администратора для упрощения разработки.</li> <li> Решение: внедрите принцип минимальных привилегий с самого начала. Если агенту нужно только читать маркетинговые документы, не предоставляйте ему доступ ко всему бакету S3.</li> </ul> </li> <li><strong> Задержка обратной связи:</strong> <ul> <li> Проблема: по мере добавления уровней безопасности задержка агента увеличивается, что заставляет пользователей обходить безопасность ради скорости.</li> <li> Решение: используйте высокопроизводительные механизмы управления разрешениями, которые могут обрабатывать сложные запросы за миллисекунды, гарантируя, что безопасность не ухудшает пользовательский опыт.</li> </ul> </li> <li><strong> Агенты-призраки:</strong> <ul> <li> Проблема: агенты создаются для задачи, задача завершается, но учетные данные остаются активными.</li> <li> Решение: внедрите автоматическое управление жизненным циклом. Используйте отзыв цепочки токенов, чтобы, если родительский агент-оркестратор помечен как проблемный, все токены дочерних агентов мгновенно аннулировались.</li> </ul> </li> <li><strong> Слепота:</strong> <ul> <li> Проблема: модели разрешений для сотен агентов становятся слишком сложными для восприятия человеком.</li> <li> Решение: используйте инструменты визуализации для аудита ваших моделей. Если вы не видите граф, вы не можете обеспечить его безопасность.</li> </ul> </li> </ul> <h3>Резюме: идентификация — это отправная точка</h3> <p>Безопасность — это процесс, а не продукт. Хотя ограничительные механизмы LLM и защита на уровне промптов важны, их легко обойти. Единственная жесткая граница, которая остается неизменной перед лицом автономного агента, — это граница авторизации.</p> <p>Относитесь к своим агентам как к идентификаторам, определяйте их окружение с помощью ReBAC и обеспечьте профессиональное управление вашим стеком IAM, чтобы идти в ногу с темпами обнаружения, обусловленными ИИ. Будущее Интернета связана с агентами; убедитесь, что ваша безопасность тоже.</p> Поскольку агентов ИИ на порядки больше, чем людей, устаревшие системы безопасности дают сбой. Джастин Долли, директор … article https://www.itweek.ru/themes/detail.php?ID=234923 Mon, 01 Jun 2026 00:00:00 +0300 <p>К началу 2026 года корпоративная ИТ-инфраструктура на базе Windows 10 и вышедших в то же время сопутствующих продуктах фактически оказалась в зоне риска: поддержка устаревших решений Microsoft завершена, безопасных способов оставаться на привычной ИТ-инфраструктуре практически не осталось. В ближайшее время злоумышленники начнут активно эксплуатировать уязвимости, исправлений для которых нет в результате отмены поддержки.</p> <h3>Тихий кризис, который больше не тихий</h3> <p>Окончание поддержки Windows 10 и серверных продуктов Microsoft стало точкой отсчета существенного увеличения рисков для корпоративной ИТ-инфраструктуры. В октябре 2025 Microsoft официально прекратила поддержку Microsoft Exchange Server 2016 и 2019, а вместе с ними и других ключевых сервисов своей экосистемы, на которой десятилетиями строились корпоративная почта, адресные книги, календарь и другие элементы системы коммуникации.</p> <p>На первый взгляд, это очередное обновление продуктовой политики вендора. Но для России, где по оценкам экспертов, подавляющее большинство организаций по-прежнему живет на этой версии операционной системы и связанных с ней офисных приложениях, речь идет о стратегической угрозе.</p> <p>Это не метафора, а вполне конкретная техническая реальность. Если раньше уязвимость уровня ProxyShell закрывалась в течение считанных дней, то теперь исправление таких проблем может существенно затягиваться, если вообще быть возможным, вследствие чего злоумышленники получают возможность либо начинать максимально быстро эксплуатировать уязвимости после их обнаружения, либо изучать унаследованный стек, а компании лишаются возможности хоть как-то повлиять на уровень защищенности своих почтовых серверов. Именно поэтому речь идет о наступлении периода, в котором сама архитектура корпоративной почты начинает терять целостность и устойчивость.</p> <p>В удобстве экосистемы Windows кроется ее главная уязвимость: зависимость от продуктов западного недружественного нам вендора, контроль над которыми теперь окончательно уходит за пределы российского ИТ-контурa.</p> <h3>В кризис: медленно, но верно</h3> <p>Важно понимать, что развитие ситуации не будет мгновенным: никто не столкнется с внезапных отказом сервисов. Однако существует опасность другого рода: продукты, на которых строится безопасная офисная работа — Windows 10, Microsoft Office 2016 и 2019, Microsoft Exchange Server 2016 и 2019, перестанут получать обновления. Это означает, что каждая найденная проблема безопасности, останется открытой на непрогнозируемое время.</p> <p>То, что происходит дальше, технически предсказуемо. Exchange, Outlook и связанный с ними серверный стек — не автономные приложения, а цепочка взаимозависимых механизмов, работа которых базируется на постоянном обновлении криптографических библиотек, протоколов аутентификации и транспортных модулей.</p> <p>После остановки поддержки эта цепочка начинает постепенно рассыпаться:</p> <ul> <li> устаревают версии протоколов, на которых держатся внешние и внутренние соединения;</li> <li> MAPI и EWS продолжают функционировать, но без актуальных исправлений остаются уязвимы к перехвату сессий и манипуляциям с заголовками;</li> <li> подсистема обработки вложений в Outlook превращается в потенциальную точку входа для вредоносного кода;</li> <li> AD остаётся без обновлений версий Kerberos, из-за чего возрастает риск атак типа Pass-the-Ticket и Pass-the-Hash.</li> </ul> <p>На поверхности все выглядит рабочим, но скрыто развивается характерный процесс деградации: система перестает адаптироваться к новым угрозам и постепенно превращается в статичную конструкцию, не способную сопротивляться современному уровню автоматизированных атак.</p> <p>На горизонте в полгода, пока исследователи и киберпреступники будут изучать продукт в поисках новых слабых мест, риски возрастут экспоненциально. Корпоративная почта, через которую ежедневно проходят финансовые документы, персональные данные и конфиденциальные переписки, превратятся в мишень кибермошенников.</p> <p>В эпоху, когда атаки все чаще совершаются с применением ИИ и автоматизированных инструментов подбора эксплойтов, это сродни вождению автомобиля без тормозов: пока дорога ровная, кажется, что можно ехать, но одна непредсказуемая яма способна обернуться катастрофой.</p> <h3>«Костыли» не помогут</h3> <p>Сейчас становится очевидно, что попытки «кустарного устранения» системных рисков сторонними средствами приводят к предсказуемым последствиям: каждое «временное исправление» порождает каскад проблем, включая функциональную несовместимость и рост операционных издержек.</p> <p>До недавнего времени компании могли позволить себе стратегию «отложенной миграции». Существовали обходные пути, неофициальные обновления, возможность продлить жизнь старым лицензиям. Но теперь сам вендор меняет правила игры. Microsoft уходит от бессрочных лицензий, делая ставку на модель подписки. В угоду обеспечения безопасности (в ее прочтении от вендора) компании вынуждены ежегодно платить за доступ к собственным данным, а фактически — арендовать собственный ИТ-контур.</p> <p>Поэтому попытка заменить один элемент этой системы неизбежно вскрывает ее внутренние сцепления: любое отклонение от штатного поведения приводит к проблемам совместимости, нарушению адресных книг, сбоям в механизмах автодискавери и неконтролируемому росту нагрузки на серверы.</p> <p>Для российских пользователей эта перемена имеет особый смысл. Если раньше можно было зафиксировать систему на стабильном релизе, то теперь отказ от подписки ведет к полному выбытию продукта как из правового, так и из технологического поля.</p> <p>Любая попытка сохранить привычную инфраструктуру превратится в рискованную игру с лицензиями, VPN, серыми обновлениями и искусственными схемами поддержки. И самое главное — все эти усилия не решают корневую проблему: ни одна из них не способна вернуть безопасность и предсказуемость в среду, которая живет вне воли разработчика.</p> <h3>Почему «пересидеть» не получится</h3> <p>С каждым месяцем инфраструктура, построенная на устаревших продуктах Microsoft, будет терять устойчивость. Уязвимости будут множиться, а ряды специалистов, способных поддерживать старые системы, будут истощаться.</p> <p>На практике это означает, что привычные для специалистов по информационной безопасности сценарии атак станут значительно проще в реализации. Скомпрометированный почтовый ящик превращается в идеальную точку входа для фишинга внутри периметра: злоумышленник получает возможность рассылать письма от имени сотрудников, менять реквизиты в финансовых документах, перехватывать цепочки согласований.</p> <p>Через устаревшие версии EWS и MAPI становится возможным извлекать токены доступа и хешированные пароли, а затем использовать их для постепенного перемещения по инфраструктуре в сторону более критичных систем. Не менее опасны сервисные учетные записи, которые часто используются для автоматизации бизнес-процессов: потеря контроля над ними открывает путь к вмешательству в CRM, ERP и другие ключевые приложения.</p> <p>Таким образом, риск уже не ограничивается «взломом почты» как таковым: устаревший Exchange превращается в платформу для комплексных атак, последствия которых затрагивают финансовые операции, клиентские данные и процессы принятия решений на уровне всей компании.</p> <p>Новое поколение администраторов не будет иметь возможность проходить официальное обучение у вендора. Так рушится преемственность опыта. В какой-то момент в компании просто некому будет обслуживать старую инфраструктуру.</p> <p>Именно поэтому переход на отечественные решения перестает быть вопросом удобства — это вопрос выживания. Сегодня бизнес еще может планомерно выбрать партнера, протестировать импортонезависимые продукты, выстроить плавный переход. Завтра все это придется делать в пожарном режиме, под давлением инцидентов и требований службы безопасности.</p> <h3>Что делать в 2026 году</h3> <p>Отказ от поддержки устаревших версий Windows — не катастрофа, а момент стратегического выбора. И выбор этот состоит не в том, уходить ли от западных вендоров, а в том, каким образом выстраивать новую архитектуру корпоративных коммуникаций.</p> <p>На практике этот выбор инфраструктуры неизбежно сводится к стратегии миграции, и здесь у компаний фактически есть лишь несколько реалистичных сценариев:</p> <ul> <li> параллельный запуск новой платформы рядом с существующим Exchange;</li> <li> для организаций с большим количеством филиалов подходит поэтапный перенос групп сотрудников с сохранением обратимой конфигурации и возможностью отката;</li> <li> миграция с переключением, как вынужденная мера для инфраструктур в критическом состоянии.</li> </ul> <p>Ключевой принцип при выборе любой модели: в приоритете контролируемость, а не скорость. Платформа должна поддерживать доменную аутентификацию, корректно работать с существующими политиками безопасности, обеспечивать импорт PST-данных и прозрачную маршрутизацию писем на период сосуществования двух систем.</p> <p>Отдельного внимания требуют мобильные клиенты: их подключение через ActiveSync или его аналоги должно проходить без изменения привычного опыта сотрудников. Все эти параметры — практические критерии, по которым следует оценивать зрелость решений и способность конкретного вендора обеспечить действительно бесшовный переход.</p> <p>* * *</p> <p>Российский рынок не стоит на месте. За последние три года отечественные разработчики проделали путь, который в нормальных условиях занял бы десятилетие. Кроме того, на рынке есть зрелые, надежные программные продукты, готовые заменить не только почтовые сервисы, но и часть инфраструктуры, на которой держится корпоративные коммуникации.</p> <p>Архитектура многих российских решений позволяет не обрывать связи с текущими ИТ-системами, а сосуществовать с ними, запускаться параллельно с Microsoft Exchange, постепенно перемещая данные пользователей, минимизируя стресс для бизнеса и обычных сотрудников.</p> <p>Точка невозврата уже пройдена. Вопрос теперь стоит не в том, произойдет ли переход на отечественные решения, а в том, насколько контролируемым он будет.</p> <p>#IMAGE_234924#</p> К началу 2026 года корпоративная ИТ-инфраструктура на базе Windows 10 и вышедших в то же время … article Александр Буравцов, директор по ИБ CommuniGate Pro https://www.itweek.ru/themes/detail.php?ID=234922 Fri, 29 May 2026 10:44:26 +0300 <p>Объем российского B2B- и B2G-рынка видеонаблюдения по итогам 2025 года достиг 67,6 млрд рублей, более чем удвоившись с 2021 года. Среднегодовой темп роста (CAGR) отрасли составил 23,4%. Согласно новому аналитическому отчету компании ivideon, поставщика облачного видеонаблюдения и интеллектуальной видеоаналитики, к 2030 году емкость рынка может удвоиться и достигнуть отметки в 135 млрд рублей. Ключевыми драйверами столь высокой динамики стали развитие государственных инфраструктурных проектов, процессы импортозамещения, а также активное внедрение видеоконтроля в распределенном бизнесе.</p> <p>В своем отчете компания ivideon исследовала рынок видеонаблюдения и видеоаналитики на основе публичной финансовой отчетности 237 юридических лиц: в емкость включены 107 компаний, формирующих 93 уникальных бренда. Исследование охватывает профессиональный сегмент видеонаблюдения для бизнеса и государства (B2B/B2G) и учитывает «чистую» выручку профильных игроков. Рынок нередко оценивают шире — около 100 млрд рублей; такие оценки могут включать интеграционные проекты, перепродажу оборудования, потребительский сегмент и смежные элементы инфраструктуры безопасности. В выборку вошли ведущие игроки рынка; анализ строился на операционных юридических лицах и структуре групп компаний по публичным данным, что обеспечивает репрезентативность оценки.</p> <p>Несмотря на устойчивое доминирование традиционных локальных систем видеонаблюдения (сегмента on-premise — оборудование и ПО, развернутые на стороне клиента), на которые по итогам года пришлось 51,5 млрд рублей (76,2% рынка), отрасль переживает структурный сдвиг в сторону облачных и ИИ-решений. Классическое аппаратно-программное обеспечение показывает прирост на уровне 17% в год, при этом облачное видеонаблюдение (VSaaS) и системы на базе нейросетевой видеоаналитики растут кратно быстрее базового оборудования — на 26% и 40% соответственно. </p> <p>Видеоаналитика стремительно выделяется в самостоятельный рынок ПО для анализа видео — отдельный от камер и оборудования. По оценке Ivideon, в 2025 году объем этого сегмента достиг 9,4 млрд рублей против 4 млрд рублей четырьмя годами ранее. Динамику сегмента задают удешевление вычислений на стороне устройства (EdgeAI) и расширение сценариев использования видео: системы выходят за рамки контура безопасности и становятся инструментами операционного управления бизнесом. Ожидается, что к 2030 году он вырастет до 31 млрд рублей. В топ-5 игроков сегмента видеоаналитики вошли разработчики алгоритмов computer vision NVI Solutions, NtechLab, VisionLabs, ЦРТ (Визирь) и Netris.</p> <p>Динамику рынка в 2025 году поддерживали: импортозамещение; рост спроса на облачные сервисы и подписочные модели; расширение применения видеоаналитики в B2B и B2G-сегментах; развитие AI/EdgeAI и повышение точности аналитических сценариев; запрос бизнеса на снижение издержек, централизацию управления и повышение эффективности операций. Дополнительный импульс рынку дают B2B- и B2G-проекты, а также спрос со стороны retail, HoReCa, логистики, промышленности и девелопмента, где видеонаблюдение все чаще рассматривается не только как элемент безопасности, но и как инструмент управления бизнес-процессами.</p> <p>Характерной чертой российского рынка видеонаблюдения остается его фрагментированность. Исследование не выявило крупного игрока, доминирующего во всех категориях; позиции строго распределены по технологическим нишам. В сегменте классических внедрений лидируют вендоры комплексных платформ Trassir, Rubezh, Bolid и Байтэрг; в крупнейшем B2G-сегменте on-premise значимую роль играет Ростелеком через программу «Цифровой регион». </p> <p>Первую строчку в сфере облачного видеонаблюдения среди независимых игроков занимает компания Ivideon; у Ростелекома — собственная платформа, а телеком-операторы (Уфанет, Дом.ру, МТС, Билайн, Мегафон) формируют значительную часть сегмента. </p> <p>В государственном секторе доля российских производителей последовательно растет: с 2027 года Минпромторг вводит балльную систему оценки локализации, и к 2030 году их доля в B2G ожидается на уровне 90%+. Реестр отечественного ПО расширяется параллельно — это меняет конкурентную карту в пользу локализованных игроков и в оборудовании, и в софте.</p> <p>«Рынок видеонаблюдения в России проходит этап качественной трансформации. Если раньше выбор определяли цена камеры и стоимость хранения архива, то сегодня заказчики ищут операционную эффективность, прикладную аналитику и управляемость распределенной инфраструктуры», — отметил Заур Абуталимов, генеральный директор Ivideon. — «Видео перестает быть архивом для безопасности и становится сенсорным слоем бизнеса — стандарты сервиса, шоплифтинг, скорость обслуживания, очереди, выкладка. Рынок превращается из инфраструктурного сегмента в технологическую платформу, в которой все большую ценность формируют облачные сервисы, аналитика и интеллектуальные функции, гибридные решения, объединяющие безопасность, автоматизацию и бизнес-эффективность».</p> Объем российского B2B- и B2G-рынка видеонаблюдения по итогам 2025 года достиг 67,6 млрд рублей, более чем удвоившись … message https://www.itweek.ru/themes/detail.php?ID=234920 Fri, 29 May 2026 10:39:21 +0300 <p>Строительный сектор становится одним из драйверов потребления высокопроизводительных ресурсов. Синергия технологии информационного моделирования (BIM) и облака становится стандартом индустрии, обеспечивающим прозрачность и эффективность на всех этапах жизненного цикла объекта. Владимир Лебедев, директор по развитию бизнеса сервис-провайдера M1Cloud, рассказал, почему BIM-модель в строительстве эволюционировала от локальных чертежей к комплексным облачным экосистемам.</p> <p>По данным Expert Market Research (Claight), объем мирового рынка информационного моделирования зданий достиг $11,17 млрд в 2025 году. Ожидается, что в период с 2026 по 2035 год рынок будет расти в среднем на 16,4% в год и к 2035 году достигнет $51 млрд. И российский рынок демонстрирует высокую динамику, поддерживаемую государственным регулированием. По данным Минстроя РФ, доля застройщиков, применяющих технологии информационного моделирования, по итогам I квартала 2026 года достигла 47%. Это на три процентных пункта выше показателя за IV квартал 2025 года.</p> <p>По мере детализации строительного проекта объем данных растет экспоненциально — это колоссальный массив данных, включающий архитектурные, инженерные и экономические параметры, что делает локальную инфраструктуру «узким местом». Облачная среда общих данных гарантирует, что все участники проекта работают с актуальной версией модели в режиме реального времени. Помимо этого, рендеринг и инженерные расчеты требуют значительных мощностей (в том числе GPU и CPU). Облако позволяет динамически выделять их под конкретные задачи, избавляя компанию от капитальных затрат на дорогостоящее оборудование. При этом провайдеры обеспечивают защиту данных и отказоустойчивость, которые сложно реализовать внутри корпоративной ИТ-службы.</p> <p>С точки зрения рентабельности, облачные решения показывают прямой экономический эффект — использование облачной платформы для управления BIM-моделями позволяет сократить трудозатраты BIM-отдела и уменьшить время проверки моделей.</p> <p>При проектировании автоматическая проверка проекта в облаке выявляет ошибки до начала работ. Совместная работа сокращает сроки согласования проектных решений. В ходе строительства инженеры получают доступ к модели через мобильные устройства. Любое изменение в офисе мгновенно отображается на стройке, что исключает ошибки из-за неактуальных чертежей. Интеграция с данными со стройки позволяет вести мониторинг прогресса в реальном времени. На этапе ввода в эксплуатацию заказчик получает цифровую модель, интегрированную с облачными системами управления зданием. Это позволяет оптимизировать энергопотребление и планировать ремонты на основе реальных данных.</p> <p>Интеграция BIM с облаком открывает путь для ИИ-аналитики. Искусственный интеллект, работающий на облачных мощностях, способен анализировать тысячи проектов, предсказывая задержки в графиках или дефицит материалов. В <nobr>2026-2030</nobr> годах аналитики M1Cloud ожидают массового перехода к «предиктивному строительству», где облачный провайдер выступает фундаментом для интеллектуальной аналитики и интернета вещей (IIoT).</p> <p>Переход строительной отрасли в облако — это смена парадигмы управления. Облачные платформы делают BIM масштабируемым и по-настоящему коллективным инструментом. Сегодня успех в девелопменте принадлежит тем, кто умеет управлять информацией, и облако — единственный инструмент, способный обеспечить необходимую для этого скорость и надежность.</p> Строительный сектор становится одним из драйверов потребления высокопроизводительных ресурсов. Синергия технологии … message https://www.itweek.ru/themes/detail.php?ID=234919 Fri, 29 May 2026 10:38:20 +0300 <p>Институт статистических исследований и экономики знаний (ИСИЭЗ) НИУ ВШЭ с помощью системы iFORA картировал точки разломов — необратимых изменений, которые под влиянием ИИ уже произошли в системе управления, экономике и социальной сфере и будут лишь усиливаться в дальнейшем.</p> <p>В системе управления ключевой сдвиг связан не с автоматизацией рутин, а с встраиванием ИИ в ядро принятия решений. Управленческий цикл ускоряется, точность контроля процессов растет, а решения все чаще принимаются на основе больших данных. Интеллектуализация охватывает основные этапы — от стратегического планирования до операционного контроля и мониторинга в реальном времени. В управленческой сфере, где ошибка в данных может обернуться искажением не отдельного показателя, а всей цепочки принятия решений, критическим становится качество данных. Их дефицит, а также проблемы подготовки и обработки остаются для компаний серьезным вызовом наряду с организационными барьерами внедрения ИИ. Сохраняется институционально нерешенная проблема размытой ответственности за рекомендации и действия, сформированные с использованием ИИ: ее сложно определить, когда результат зависит одновременно от человека, качества данных, ИИ-моделей и организационных процессов. По мере того как алгоритмические системы все глубже встраивают в контур управления, их надежность становится одним из ключевых условий безопасности. Уязвимость модели, данных или инфраструктуры превращается в уязвимость всей организации.</p> <p>В экономике ИИ перестает играть сугубо прикладную роль и становится частью процессов создания стоимости — от разработки продукта до взаимодействия с клиентом. Автоматизация все более широкого круга функций, включая роботизацию бизнес-процессов, меняет структуру издержек и подходы к организации деятельности. Производительность растет за счет оптимизации ресурсов и управления данными, при этом функции все чаще перераспределяются между человеком и алгоритмами. Одновременно на базе ИИ формируются новые бизнес-модели. В платформенной экономике — от электронной коммерции до финансовых сервисов — конкурентное преимущество все больше зависит от способности анализировать поведение пользователей, персонализировать предложения и управлять клиентским опытом в реальном времени. В этой логике данные перестают быть сопутствующим ресурсом, превращаясь в часть продукта, основу монетизации и инструмент долгосрочного удержания клиентов. ИИ уже используется в широком спектре бизнес-процессов, а его внедрение сопровождается трансформацией структуры занятости и спроса на навыки. Речь идет не столько о сокращении занятости, сколько о снижении доли рутинных задач, перераспределении функций и быстрой смене требований к компетенциям, в частности возрастает значимость навыков, связанных с работой с данными, применением аналитических инструментов и разработкой ИИ-решений. Облачная инфраструктура и распределенная архитектура позволяют быстро масштабировать продукты и сервисы на базе ИИ, снижать барьеры входа и ускорять коммерциализацию новых решений. Одновременно необходимым условием развития ИИ становится доступ к хранилищам, центрам обработки данных и специализированному оборудованию. Зависимость от поставщиков вычислительных мощностей и инфраструктуры создает предпосылки концентрации данных, технологий и алгоритмов у крупных игроков.</p> <p>В общественной сфере ИИ выступает не столько инструментом автоматизации, сколько триггером пересборки базовых практик производства знаний, коммуникации и социализации. На наших глазах происходит масштабный сдвиг в сторону массовой генерации контента: благодаря ИИ практически исчезают барьеры входа в создание текстов, изображений и видео, усиливаются позиции отдельных авторов и малых команд. Генеративный ИИ в России уже применяет каждый шестой интернет-пользователь, что указывает на значительный потенциал дальнейшего распространения технологии, появления мультимодального контента и новых форм самовыражения. Наряду с трансформацией творческого процесса ИИ меняет и сферу образования. В цифровой среде активно развиваются адаптивные образовательные системы, позволяющие сделать обучение более персонализированным и непрерывным. Интеграция ИИ в социальные и контентные платформы усиливает роль алгоритмов в формировании информационной повестки и структуры социальных связей. При этом массовое производство синтетического контента повышает риски распространения фейковых новостей, затрудняет оценку достоверности информации и снижает доверие к ней. Значительная часть пользователей ИИ уже связывают его развитие с усилением зависимости от алгоритмов и ростом возможностей для манипулирования общественным мнением, около 30% испытывают тревогу по поводу растущего влияния ИИ. Одновременно обостряются вопросы уязвимости цифровой среды, конфиденциальности и безопасности персональных данных: расширение использования ИИ сопровождается экспоненциальным ростом объемов информации, превращая ее защиту в системный риск. Рост доступности инструментов генерации контента размывает границы авторства и прав интеллектуальной собственности.</p> <p>Резюме: ИИ выходит за рамки прикладных задач и отдельных индустриальных решений, меняя саму логику функционирования систем управления, экономики и общества. Все трансформации тесно переплетены: изменения в сфере управления создают новые экономические условия, которые, в свою очередь, влияют на социальные нормы и институты; а на их стыке проявляются глубокие структурные сдвиги и разломы. В совокупности эти процессы указывают на формирование новой социальной среды, в которой ключевое значение приобретает не только доступ к передовым технологиям, но и способность общества выстраивать механизмы доверия, контроля и распределения ответственности в условиях повсеместного присутствия ИИ.</p> <p>«Развитие ИИ характеризуется сочетанием двух встречных процессов. С одной стороны, технология становится массовым инструментом: порог входа снижается, в разработку и применение вовлекаются новые участники. С другой стороны, контроль над данными, вычислительными мощностями, инфраструктурой и моделями все заметнее концентрируется у ограниченного числа технологических лидеров. На уровне социума ИИ расширяет возможности коммуникации, самовыражения, образования, способы производства и распространения знаний, но также усложняет механизмы доверия, побуждая общество заново определять, какую информацию считать достоверной и заслуживающей внимания. В сфере управления ИИ открывает возможности перехода от реактивной модели к предиктивной, при которой решения принимаются не постфактум, а на основе раннего выявления изменений в поведении рынков, граждан и производственных систем. На макроуровне ИИ становится инфраструктурой новой производительности и, подобно электричеству или интернету, постепенно проникает во все сектора, меняя логику взаимодействия экономических агентов. Экономический эффект ИИ при этом распределяется неравномерно: в выигрыше оказываются не те, кто внедряет точечные решения, а те, кто перестраивает бизнес-модели, организационные процессы, управление данными и компетенции работников вокруг мультиагентных ИИ-систем. Выполненное с помощью системы iFORA картирование ключевых разломов показывает, что речь уже идет не о трансформации отдельных отраслей под влиянием ИИ, а о глубокой перестройке системы управления, экономики и общественных отношений. Результативность этой ИИ-трансформации будет зависеть от того, смогут ли институты превратить ИИ из инновации в надежную инфраструктуру развития с прозрачными правилами, механизмами ответственности и управления рисками», — отметил Константин Вишневский директор Центра стратегической аналитики и больших данных ИСИЭЗ НИУ ВШЭ.</p> Институт статистических исследований и экономики знаний (ИСИЭЗ) НИУ ВШЭ с помощью системы iFORA картировал точки … message https://www.itweek.ru/themes/detail.php?ID=234918 Fri, 29 May 2026 10:31:28 +0300 <p>«Яндекс» представил новую нейросеть Alice AI LLM Flash — это быстрая языковая модель, которая оптимизирована под наиболее популярные задачи бизнеса. Она хорошо работает с текстами и документами — а это почти 60% от всех b2b-запросов к моделям Яндекса. С помощью новой модели компании смогут решать эти задачи быстрее и почти в 5 раз дешевле, чем ранее. Новая модель уже доступна бизнесу в Yandex AI Studio.</p> <p>Alice AI LLM Flash эффективна в задачах, которые требуют качественного ответа при высокой скорости отклика — например, в диалогах или при обработке большого количества данных. Она подойдет для модерации контента на сайте, классификации обращений в техподдержку или диалога с клиентом. Новая модель позволит малому бизнесу использовать нейросети с минимальными финансовыми затратами, в то же время она поможет крупным компаниям сэкономить на обработке массовых запросов, сохранив хорошее качество и высокую скорость ответов. Она будет востребована у банков, ритейлеров, телеком-операторов и других компаний с большим объемом однотипных задач, в которых критически важна скорость ответа.</p> <p>Alice AI LLM Flash в 56% случаев превосходит нейросеть GPT-5.4 mini по качеству решения бизнес‑задач. При этом она сохраняет все преимущества флагманской модели Alice AI LLM: она превосходит западную модель в диалоговых сценариях (лучше в 73% случаев), обобщении и структуризации текста (66%) и в поиске данных по файлам и базам знаний (61%).</p> <p>«Яндекс выходит на новый для себя рынок моделей, созданных специально под запросы бизнеса. Alice AI LLM Flash поможет российским компаниям перейти на российские нейросети для автоматизации работы с огромными объемами данных. Новая модель — это собственная разработка, прошедшая полный цикл обучения на данных Яндекса. Она сопоставима по стоимости с ближайшим западным аналогом GPT-5.4 mini, при этом мы также обеспечиваем безопасность обрабатываемых данных и стабильную работу в России», — рассказал руководитель платформы Yandex AI Studio Артур Самигуллин.</p> <p>Также на платформе открыли доступ к опенсорсной модели DeepSeek V4 Flash. Это первая в России доступная в облаке модель с контекстным окном в 1 млн токенов. Ее можно использовать для разработки корпоративных ИИ-агентов, анализа больших документов и решения сложных многоэтапных задач. При этом она в полтора раза дешевле предыдущей версии DeepSeek V3.2.</p> «Яндекс» представил новую нейросеть Alice AI LLM Flash — это быстрая языковая модель, которая оптимизирована под … message https://www.itweek.ru/themes/detail.php?ID=234917 Fri, 29 May 2026 10:29:57 +0300 <p>Компания МУЛЬТИФАКТОР, российский разработчик ИБ- и ИТ-решений, объявила о масштабном обновлении сервиса распределённого мониторинга MULTISTATUS.</p> <p>Теперь компании могут полностью контролировать доступность своих интернет-ресурсов. Благодаря новым улучшениям они получают возможность мгновенно запускать непрерывный мониторинг, создавать публичные статусные страницы и использовать инструменты для расчёта SLA. А расширенная сеть точек проверки и гибкая система уведомлений позволяют проактивно выявлять сбои на региональном уровне и оперативно реагировать на инциденты.</p> <p>Реализована возможность перевода ресурсов с разовых проверок на непрерывный круглосуточный контроль. Пользователи могут непрерывно отслеживать состояние сервисов по отдельным типам проверок или использовать комплексные сценарии контроля инфраструктуры.</p> <p>Что доступно: мониторинг HTTP/HTTPS, Ping, TCP-портов, SSL-сертификатов и доменов.</p> <p>Появился новый функционал для ускорения запуска мониторинга. В рамках пилотного внедрения специалисты анализируют связанную инфраструктуру заказчика (домены и поддомены), определяют ресурсы, требующие контроля, и формируют рекомендации по настройке.</p> <p>Главное преимущество этой функции — заказчик может перейти к тестированию платформы и постановке ресурсов на мониторинг без длительной ручной настройки, существенно сокращая время внедрения. В дальнейшем этот инструмент (инструмент автоматического обнаружения веб-ресурсов) будет доступен как дополнительная автоматическая опция.</p> <p>MULTISTATUS автоматически рассчитывает показатели доступности сервисов на основе настроенных правил инцидентов и позволяет анализировать уровень доступности за различные периоды времени. Пользователи могут анализировать уровень доступности, отслеживать время простоя и визуализировать данные через настраиваемые дашборды.</p> <p>Увеличилось количество точек проверки до восьми локаций в России, Казахстане и Европе. А для заказчиков стала доступна возможность подключения кастомных локаций.</p> <p>Расширение географии мониторинга позволяет быстрее выявлять региональные проблемы доступности, сбои у операторов связи или деградацию работы сервисов в отдельных сегментах сети.</p> <p>В новой версии MULTISTATUS появились публичные статусные страницы, которые можно использовать для внешнего информирования заказчиков и партнёров о состоянии инфраструктуры.</p> <p>Пользователи могут публиковать страницы со статусом сервисов, отображать SLA. В ближайшее время планируется поддержка размещения таких страниц на собственном домене компании-заказчика.</p> <p>Теперь сервис поддерживает группировку оповещений по ресурсам и сценариям инцидентов с отправкой уведомлений через электронную почту, Telegram или голосовые звонки дежурным специалистам. Такой подход позволяет выстраивать разные сценарии реагирования в зависимости от критичности инцидента.</p> <p>Отдельно стоит отметить запуск полноценного личного кабинета. Администраторы получили единое пространство для управления ресурсами, мониторингом, дашбордами, правилами инцидентов и API-интеграциями.</p> <p>Компания МУЛЬТИФАКТОР представила новый сайт MULTISTATUS и пересмотрела условия использования сервиса. Стоимость теперь рассчитывается прозрачно — исходя из количества контролируемых ресурсов, частоты и географии проверок.</p> <p>Одной из ключевых особенностей MULTISTATUS остаётся собственный механизм оценки доступности инфраструктуры с точки зрения конечного пользователя.</p> <p>Сервис использует сети мониторинговых агентов, размещённых в различных дата-центрах и регионах. Этот подход помогает выявлять локальные сетевые проблемы и оперативно реагировать на инциденты до того, как они повлияют на бизнес-процессы.</p> Компания МУЛЬТИФАКТОР, российский разработчик ИБ- и ИТ-решений, объявила о масштабном обновлении сервиса … message https://www.itweek.ru/themes/detail.php?ID=234916 Fri, 29 May 2026 10:26:51 +0300 <p>Мобильное приложение банка ВБРР, разработанное на базе системы ДБО BSS, укрепило позиции в рейтинге RuStore.</p> <p>Команда ВБРР реализовала программу по изучению клиентского опыта и анализу лучших рыночных практик, уделив особое внимание развитию платежных сервисов и удобству ежедневных операций, а BSS обеспечила необходимые технологические доработки и развитие платформы. </p> <p>Дополнительным фактором роста пользовательской оценки стало внедрение SDK Review, который позволил банку выстроить более системную работу с обратной связью клиентов. </p> <p>В результате приложение банка ВБРР получило оценку 4,4 на основе более чем 14 тысяч отзывов и преодолел отметку в 400 тысяч скачиваний. За последнее время рейтинг приложения вырос на 1,6 пункта. </p> <p>Клиенты отмечают повышение стабильности и удобства приложения, а также качество работы поддержки. </p> <p>ВБРР онлайн — ключевой канал взаимодействия с клиентами, банк последовательно инвестирует в его развитие и пользовательский опыт. Рост рейтинга и положительная обратная связь подтверждают эффективность цифровой стратегии ВБРР онлайн и технологического партнерства с BSS</p> <p>«Проект с ВБРР показывает, что современные технологии и постоянная работа с обратной связью клиентов позволяют банкам успешно конкурировать с крупнейшими игроками рынка. По уровню пользовательских оценок приложение ВБРР сегодня опережает приложения ряда крупнейших игроков рынка. Мы рады, что наша технологическая поддержка и экспертиза помогают партнерам достигать таких результатов», — прокомментировал Виталий Патешман, директор по продажам компании BSS.</p> Мобильное приложение банка ВБРР, разработанное на базе системы ДБО BSS, укрепило позиции в рейтинге RuStore. Команда … message https://www.itweek.ru/themes/detail.php?ID=234914 Fri, 29 May 2026 09:15:54 +0300 <p>Когда-то производители соревновались за объемы сырья и дешевизну рабочих рук, теперь же борьба идет за чистые данные и обучающие алгоритмы. Перемены видны в заводских цехах, логистических хабах и на фермах, хотя многие участники рынка все еще скептически поглядывают на «умные» технологии. Пока одни примеряют на себя роль цифровых первопроходцев, другие продолжают жить по старинке, полагаясь на интуицию технолога и записи в бумажных журналах.</p> <p>В этой статье мы будем использовать термин «нейроаналитика» расширительно: под ним понимаются любые технологии искусственного интеллекта, применяемые в пищевой промышленности и смежных отраслях, — от компьютерного зрения и предиктивных моделей до генеративных сетей и оптимизационных алгоритмов. Главный объединяющий признак — работа с данными, а не жестко заданные правила.</p> <h3>Еда по алгоритмам</h3> <p>Современный ИИ в пищевой индустрии — это не только футуристичные роботы-повара, которые, к слову, уже существуют. Речь о разросшемся семействе технологий, готовых взять на себя массу типовых операций и совершать их на высоких скоростях. Компьютерное зрение контролирует уровень налива и целостность этикетки, предиктивная аналитика предугадывает спрос на молоко за месяц вперед, алгоритмы логистики выстраивают маршруты так, чтобы творог не превращался в просрочку, а генеративные модели позволяют технологам разрабатывать новые рецептуры без увеличения себестоимости. По оценкам аналитиков «Яков и Партнеры», совокупный экономический потенциал подобных решений в российском АПК и пищепроме достигает 6 млрд. долл. ежегодно. И крупные игроки уже научились превращать алгоритмы в живые деньги. Один из лидеров отечественной мясопереработки фиксирует порядка 300 млн. руб. ежегодной экономии и дополнительный рост выручки на <nobr>1,5-2%</nobr> исключительно за счет прироста производительности, который обеспечило внедрение ИИ.</p> <p>Согласно данным Аналитического центра при Правительстве РФ, внедрение ИИ в отрасли позволяет в среднем:</p> <ol> <li> снизить операционные расходы (OPEX) в среднем на <nobr>10-15%,</nobr> а в отдельных проектах — до 25%;</li> <li> сократить потери сырья и списания готовой продукции до 30%;</li> <li> повысить производительность труда на <nobr>15-40%</nobr> за счет автоматизации рутины.</li> </ol> <p>Впрочем, от осознания выгод до их воплощения в живых деньгах — пропасть. И переступить через нее способны лишь те, кто определил зоны максимальной окупаемости (еще на стадии планирования).</p> <h3>Зоны максимальной окупаемости</h3> <p>Сетевой ритейл задает в этом смысле собственный темп: вложенный рубль возвращается за полгода-год, что по меркам промышленного внедрения ощущается почти мгновенно. Огромные массивы данных и низкая маржинальность <nobr>(2-5%)</nobr> вынуждают ритейлеров выжимать резервы отовсюду. Нейросети, умеющие переваривать погодные сводки, промо-календарь и историю продаж, подходят для такой задачи как нельзя лучше. Одна федеральная сеть уже отдала под управление алгоритмов 80% заказов для своих магазинов — в результате утилизация нераспроданного товара пошла вниз, а полки перестали пустовать. Сервисы быстрой доставки еды шагнули еще дальше, доверив искусственному интеллекту маршрутизацию курьеров и сборку заказов, и теперь время ожидания исчисляется минутами — такими же стремительными, как сам сервис.</p> <p>В сегменте товаров с коротким сроком годности цена ошибки прогноза равна полному списанию продукта. Крупный молочный производитель добился роста точности прогнозов более чем на 3 процентных пункта и сократил списания на треть. Годовая экономия оценивается в <nobr>40-50 млн.</nobr> руб. Масштабный проект реализован и на одном из крупных хлебозаводов: нейросети взяли на себя контроль входящих документов объемом 2 млн. страниц в месяц. Время проверки сократилось с недель до одной рабочей смены, а объем ручной обработки снизился на 40%.</p> <p>Производственный опыт, накопленный десятилетиями, сталкивается с ограничениями при масштабировании. Нейроаналитика позволяет оцифровать интуицию технолога и превратить сенсорный контроль в стандартизированный процесс. При массовом производстве (десятки тысяч единиц в сутки) разница между интуитивными решениями и решениями на основе данных оборачивается миллионами рублей недополученной прибыли.</p> <h3>От поля до конвейера — скрытые резервы</h3> <p>Нейроаналитика обнаруживает то, что долго ускользало от внимания, — чаще всего в устоявшихся процессах (без планов на изменения). Речь о полях, фермах, конвейерных линиях и курьерских маршрутах — словом, обо всей цепочке, проходя по которой сырье превращается в готовый продукт и добирается до конечного потребителя. Скрытые резервы редко заметны сразу — их выявляют алгоритмы, анализирующие данные с датчиков и камер (обученные находить статистические аномалии).</p> <h3>Самые заметные зоны, где нейросетям делегированы задачи</h3> <ul> <li> <strong>Агрохолдинги</strong><strong>.</strong> ИИ переводит управление посевами и поголовьем на потоковую аналитику. Вместо усредненных календарных планов и решений «по погоде» алгоритмы ежедневно пересчитывают дозу удобрений, опираясь на спутниковые снимки и данные почвенных датчиков; в животноводстве же предиктивные модели предупреждают о риске заболевания у конкретного животного за несколько дней до первых симптомов.</li> <li><strong>Переработка</strong><strong>.</strong> Нейросеть встраивает оптический контроль на линиях упаковки, розлива и сортировки, где плотность потока превышает сотни единиц в минуту. Камеры с ИИ-обработкой кадра непрерывно проверяют геометрию изделия, читаемость кода, отсутствие вмятин и корректность маркировки.</li> <li><strong>Общепит и доставка готовой еды</strong><strong>.</strong> Программа берет на себя задачи ценообразования и оптимизации маршрутов «последней мили», она в режиме реального времени агрегирует и анализирует данные по спросу, дорожной ситуации и загрузке курьеров, гарантируя соблюдение целевого показателя среднего времени ожидания.</li> </ul> <p>Крупные хозяйства сегодня поставляют не только зерно или мясо, но и гигабайты данных телеметрии. Начинать анализ лучше всего с животноводческих комплексов — там окупаемость заметна сразу. «Умные» ошейники на коровах — это уже не забава и не игрушка, а инструмент, который круглосуточно отслеживает здоровье и период половой охоты. Результат: рост надоев и снижение падежа без привлечения дополнительных специалистов. От фермы маршрут анализа естественно уходит в поле, где на смену ошейникам приходят оптические датчики и спутниковая навигация. Система автопилотирования ведет комбайн вдоль кромки с точностью до 10 см, не «слепнет» при потере спутникового сигнала и даже способен распознавать препятствия. Экономия на каждом комбайне превышает 2 млн. руб. с тысячи гектаров, на тракторах — свыше 2,6 млн. руб. Агрохолдинг с парком в 500 машин способен сберечь за сезон порядка 450 млн. руб. Практика внедрена в более чем 1,2 тыс. фермерских хозяйств и у трех десятков крупнейших игроков. Опыт этих предприятий постепенно экспортируется, сообщают разработчики систем автопилотирования. По окончании работы техники расчет урожайности выполняется нейросетями. На Кубани два года испытывают модель, которая на основе текущих методов внесения удобрений корректирует их дозировку (по итогам испытаний на 17 полях урожайность выросла на 6,3% при средней экономии 24 кг удобрений на гектар и общем эффекте в 1,86 млн. руб.).</p> <blockquote> <p><em>Реактивное управление — это фиксация потерь постфактум. Предиктивная аналитика переносит фокус внимания менеджмента на опережение событий. Прогноз спроса, выполненный в отдельных категориях на коротком горизонте с точностью до 85</em><em>-</em><em>90%, снимает необходимость держать раздутые страховые запасы, высвобождая оборотный капитал, который можно направить на развитие продуктовой линейки.</em></p> </blockquote> <h3>Препятствия, знакомые каждому, кто запускал пилот</h3> <p>При обилии успешных примеров и наличии государственной поддержки (в рамках нацпрограммы «Цифровая экономика»: субсидии до 50% затрат на ПО, льготные займы РФРИТ) некоторые предприятия среднего и крупного сегмента замедляют свое движение. Многие из ограничений носят организационный характер.</p> <ul> <li> <strong>Качество первичных данных</strong><strong>.</strong> Нейросеть использует оцифрованную, структурированную информацию. Если показатели хранятся в бумажных журналах, Excel-таблицах или памяти технологов, алгоритм не может на них обучиться. Попытки дать ИИ неочищенные или недостоверные сведения не принесут ожидаемого результата.</li> <li> <strong>Кадровый дефицит на стыке отраслей</strong><strong>.</strong> Рынку нужны специалисты, одинаково хорошо понимающие специфику пищевых технологий и методы машинного обучения (пока в стране таких немного).</li> <li><strong>Адаптация к санкционным условиям</strong><strong>.</strong> Закупка прецизионных датчиков и камер сопряжена с объективными сложностями — рынок переориентируется на азиатских и отечественных производителей, однако логистические цепочки пока нестабильны.</li> <li><strong>Инерция управленческого мышления</strong><strong>.</strong> Собственник или технолог с <nobr>30-летним</nobr> стажем склонен доверять личному опыту больше, чем непрозрачному для него алгоритму. Опасение утратить контроль над процессом блокирует запуск пилотных проектов.</li> </ul> <blockquote> <p><em>Собирать модель машинного обучения с нуля совсем не обязательно — на рынке уже хватает тиражируемых решений, которые без особого драматизма встраиваются в действующий ИТ-ландшафт. С ними предприятие не строит исследовательский R&D-контур и не нанимает команду MLOps-инженеров до того, как получен первый экономический результат. Цифровизация сводится к подбору, адаптации и запуску готового решения, а стартовая экспертиза ограничивается умением интегратора развернуть модель на существующих данных и привязать ее к заводской учетной системе.</em></p> </blockquote> <h3>Анатомия управленческого решения</h3> <p>Любой разговор о цифровизации рано или поздно упирается в человека, который принимает окончательное решение, и здесь нейроаналитика сталкивается с самым неудобным барьером — многолетней привычкой полагаться на собственный опыт и чутье. Технолог с тридцатилетним стажем или собственник, построивший завод с нуля, редко готовы променять интуицию на график, сгенерированный моделью, в чью внутреннюю механику они не могут заглянуть. Спорить с таким оппонентом на языке алгоритмов бессмысленно, а вот предъявить цифры с одной-единственной линии после двухнедельного пилота — работает почти безотказно. Параметры просты и не требуют интерпретации: процент снижения незапланированных остановок, объем возвратов, килограммы списанного сырья. Дальше решение о масштабировании рождается уже не в кабинете, а в цехе, где начальник смены, увидевший результат своими глазами, становится самым убедительным сторонником перемен.</p> <p>Когда технология встраивается в ежедневный контур, следом меняется система координат для персонала. Освобожденные от рутины люди переключаются на анализ отклонений и настройку процесса, а директор завода вместо утренней сводки о ночных происшествиях получает набор сценариев на ближайшую смену и рекомендации по загрузке мощностей. Система KPI перестраивается незаметно, но основательно. Раньше эффективность начальника цеха мерили скоростью реакции на сбой, теперь — умением этот сбой предотвратить. Вся управленческая конструкция смещается из реактивного режима в профилактический; этот сдвиг, пожалуй, и есть главный финансовый итог внедрения.</p> <blockquote> <p><em>Отсрочка внедрения аналитических систем обходится бизнесу дороже инвестиций в их установку. Каждый месяц работы предприятия на исторических данных, без прогностических моделей, консервирует перерасход сырья и неотлаженную логистику. Обострение дефицита рабочих рук оставляет производителям два сценария: роботизация и нейросетевое управление либо постепенная потеря рыночной доли.</em></p> </blockquote> <h3>Основные выводы</h3> <ol> <li> Технологии промышленной нейроаналитики приносят измеряемый финансовый результат в горизонте <nobr>6-12</nobr> месяцев для ритейла и <nobr>1-2</nobr> года для переработки и АПК. Снижение OPEX на <nobr>10-25%</nobr> становится не столько поводом для гордости, сколько базовым ориентиром.</li> <li> Массивы исторической информации, очищенные и размеченные, превращаются в материальный ресурс предприятия наравне с оборудованием и сырьем. Инвестиции в их упорядочивание определяют скорость и качество внедрения ИИ.</li> <li> Конкурентное преимущество получают компании, которые выращивают или привлекают специалистов, способных одновременно разобраться и в технологии производства, и в логике построения моделей.</li> <li> Тиражируемые «коробочные» продукты позволяют начинать цифровую трансформацию, не дожидаясь формирования собственной команды разработчиков.</li> <li> Прорыв случается, когда руководитель начинает использовать нейроаналитику как стратегический актив, а не просто ИТ-сервис.</li> </ol> <p>Скорее всего в ближайшие <nobr>5-7</nobr> лет российский пищевой сектор незаметно для внешнего наблюдателя пересмотрит собственное представление о норме. Компании, успевшие сделать ставку на data-driven-менеджмент, перестанут обсуждать искусственный интеллект как нечто внешнее — нейроаналитика станет такой же рутиной, как ежемесячный отчет о прибылях и убытках, и будет вызывать примерно столько же споров. Те, кто отложит цифровизацию до лучших времен, в какой-то момент обнаружат, что соревнуются уже не с соседним заводом, а с полностью автоматизированной системой, где каждое действие просчитано на несколько шагов вперед.</p> <p>#IMAGE_234915#</p> Когда-то производители соревновались за объемы сырья и дешевизну рабочих рук, теперь же борьба идет за чистые … article Константин Деревсков, генеральный директор ООО “Старт Качества” https://www.itweek.ru/themes/detail.php?ID=234913 Fri, 29 May 2026 09:08:28 +0300 <p><em>Один и тот же набор данных не должен существовать дважды, чтобы быть полезным. Однако в большинстве сред это происходит. Одна версия хранится в файловой системе, предназначенной для корпоративных пользователей и приложений, которые ожидают путей, каталогов и изменяемого состояния. Другая версия экспортируется в объектное хранилище, чтобы распределенные движки и конвейеры искусственного интеллекта могли эффективно ее обрабатывать. Эти копии создаются не намеренно. Они являются артефактами несовместимых интерфейсов хранения, пишет на портале </em><em>BigDataWire</em> <em>Арон Бранд, технический директор CTERA.</em></p> <p>В небольших масштабах это дублирование допустимо. В масштабах ИИ оно становится структурной неэффективностью. Объемы хранения увеличиваются быстрее, чем сами данные, конвейеры накапливают логику синхронизации, а вычисления все больше зависят от перемещения данных, а не от их обработки.</p> <p>Почему это происходит?</p> <h3>Две модели, два предположения о данных</h3> <p>Файловые системы и объектные хранилища не являются взаимозаменяемыми абстракциями. Они кодируют принципиально разные предположения о том, как ведут себя данные.</p> <p>Файловые системы отдают приоритет структуре, координации и изменяемости. Объектное хранилище отдает приоритет экзабайтному масштабу, простоте и параллелизму.</p> <p>Ни одна из моделей не является ошибочной. Каждая оптимизирована для разных классов рабочих нагрузок. Проблема в том, что современные конвейеры данных требуют одновременного применения обеих моделей.</p> <h3>Рабочие нагрузки ИИ охватывают оба мира</h3> <p>Конвейеры ИИ не всегда четко согласуются с одной из парадигм.</p> <p>Обучение и крупномасштабная аналитика хорошо работают с семантикой объектного хранилища: высокопроизводительное параллельное чтение на распределенных вычислительных узлах. В то же время исходные данные часто создаются в средах, зависящих от семантики файлов, где структура, инкрементальные обновления, блокировка и обеспечение соблюдения политик имеют важное значение.</p> <p>Это создает постоянное несоответствие.</p> <p>На практике организации компенсируют это перемещением данных. Файловые наборы данных экспортируются в объектное хранилище для аналитики. Объектные данные восстанавливаются в файловых системах для последующих рабочих процессов. Конвейеры расширяются, включая этапы подготовки, копирования и преобразования в качестве основных шагов. То, что начинается как интеграция, превращается в зависимость, и в конечном итоге конвейер формируется скорее ограничениями хранилища, чем логикой данных.</p> <h3>Объектное хранилище как плоскость данных ИИ</h3> <p>Объектное хранилище стало основой по умолчанию для крупномасштабной аналитики и ИИ, поскольку оно соответствует поведению современных вычислительных систем.</p> <p>Распределенные задачи обучения, механизмы запросов и конвейеры обработки признаков предполагают параллельный доступ, взаимодействие без сохранения состояния и большие последовательные операции чтения на неизменяемых наборах данных. Объектное хранилище естественным образом удовлетворяет этим предположениям.</p> <p>Недавние достижения укрепили эту роль. Высокопроизводительное объектное хранилище все чаще поддерживает прямые пути передачи данных, такие как S3 через RDMA, что снижает участие ЦП и позволяет данным перемещаться непосредственно в память графического процессора. На этом этапе пропускная способность хранилища — это не просто фоновая проблема. Она напрямую определяет использование вычислительных кластеров.</p> <p>Это имеет архитектурные последствия. При пропускной способности в сотни Гбит/с любой слой, который перехватывает или преобразует операции ввода-вывода между вычислительными ресурсами и объектным хранилищем, вносит накладные расходы на ЦП и ограничивает пропускную способность. В масштабах ИИ эти накладные расходы уже не являются незначительными. Часто они становятся узким местом.</p> <h3>Файлы как интерфейс для агентов ИИ</h3> <p>Если объектное хранилище становится плоскостью данных, то файлы вновь становятся плоскостью управления для систем, управляемых ИИ, в рамках федеративной ткани данных.</p> <p>Агенты ИИ обладают состоянием. Они создают контекст, сохраняют промежуточные результаты и координируют действия во времени. Файловая система поддерживает это естественным образом: каталоги организуют работу, пути кодируют связи, а само пространство имен становится общей памятью, в которой могут перемещаться как люди, так и агенты.</p> <p>В отличие от этого, объектное хранилище является плоским. Агенты должны восстанавливать структуру, выводить связи и управлять состоянием извне, что добавляет сложности.</p> <p>Файловая система делает контекст явным и непосредственно используемым. Это особенно важно для мультиагентных рабочих процессов. Файлы выступают в качестве уровня координации, где агенты взаимодействуют, читая и записывая артефакты, организуя задачи и отслеживая прогресс в общем рабочем пространстве.</p> <p>Сдвиг происходит не в плане ухода от объектного хранилища, а в сторону наложения на него семантики файлов. Объектное хранилище остается масштабируемой основой, в то время как файлы обеспечивают интерфейс, который лучше соответствует тому, как работают агенты: управление контекстом, памятью и взаимодействием.</p> <h3>Компромиссные подходы создают новые узкие места</h3> <p>Исторически усилия по унификации доступа к файлам и объектам принимали две формы.</p> <p>Подходы, основанные на копировании, экспортируют данные в объектное хранилище для аналитики. Это сохраняет производительность вычислительных нагрузок, но приводит к задержкам, дублированию и фрагментации управления.</p> <p>Подходы, основанные на шлюзах, преобразуют протоколы в реальном времени, предоставляя доступ к файловым данным через объектные API. Это позволяет избежать дублирования, но вносит накладные расходы на преобразование, зависящие от ЦП, и ограничивает пропускную способность.</p> <p>Оба подхода решают часть проблемы, но усиливают другую. Один оптимизирует формат данных, другой — согласованность доступа. Ни один из них не устраняет фундаментальное несоответствие.</p> <h3>К унифицированной архитектуре хранения</h3> <p>В современных платформах данных наблюдается тенденция к конвергенции, а не к трансляции.</p> <p>Конвергентная архитектура рассматривает файловые и объектные интерфейсы как два представления одних и тех же данных. Данные записываются один раз, хранятся в формате, непосредственно используемом объектно-ориентированными вычислениями, и предоставляются через файловую семантику там, где это необходимо. Нет дублирования, нет конвейера экспорта и нет трансляции протоколов на критическом пути.</p> <p>Разница очевидна и существенна. Промежуточные этапы исчезают. Данные не нужно перемещать, изменять или повторно предоставлять, прежде чем их можно будет использовать.</p> <p>Хранилище перестает быть чем-то, вокруг чего работают конвейеры, и становится тем, с чем они работают напрямую. Для инженеров данных это коренным образом меняет проектирование конвейеров. Вместо того чтобы рассматривать перемещение данных как необходимое условие, конвейеры могут работать непосредственно с авторитетным набором данных. Доступ заменяет извлечение в качестве первого шага. Преобразование и анализ выполняются без промежуточных этапов.</p> <p>Это снижает сложность конвейера, повышает актуальность данных и уменьшает накладные расходы на хранение. Что еще важнее, это восстанавливает согласованность между вычислительными ресурсами и данными. Рабочие нагрузки выполняются там, где данные уже существуют, вместо того, чтобы ждать их перемещения.</p> <p>Это также открывает новые возможности для взаимодействия. Существующие наборы объектных данных могут быть немедленно доступны в виде файловых систем без миграции. Данные, создаваемые приложениями, могут использоваться конвейерами ИИ в режиме реального времени. Агенты могут работать непосредственно с живыми наборами данных, используя файловую семантику для навигации и одновременно объектное хранилище для масштабируемости.</p> <h3>Заключение</h3> <p>Файловое и объектное хранение не являются конкурирующими парадигмами. Это взаимодополняющие абстракции, которые развивались в различных условиях.</p> <p>Изменилась природа рабочих нагрузок. Системы ИИ, и все чаще агенты ИИ, требуют и того, и другого. Им необходима масштабируемость и параллелизм объектного хранилища, а также структура и доступность файловых систем.</p> <p>Поддержание их в качестве отдельных систем заставляет инженеров данных преодолевать разрыв посредством копирования, преобразования и оркестровки. Такой подход не масштабируется. Сейчас наметился способ решения этой проблемы. Благодаря конвергенции доступа к файлам и объектам в единую, федеративную ткань данных, хранилище данных становится соответствующим тому, как на самом деле работают современные системы. Оно перестает быть чем-то, что конвейеры обходят стороной. Оно становится частью самой модели выполнения.</p> Один и тот же набор данных не должен существовать дважды, чтобы быть полезным. Однако в большинстве сред это … article https://www.itweek.ru/themes/detail.php?ID=234906 Thu, 28 May 2026 09:56:49 +0300 <p><em>Инфраструктура современного оператора связи стала слишком динамичной и многослойной, чтобы управлять ею через ручные сверки, локальные таблицы и несвязанные учетные процессы. Физические ресурсы, логические каналы, виртуальные функции, сервисные зависимости, склад и договоры меняются быстрее, чем обновляются данные о них. Из-за этого учет перестает быть технической формальностью. Для крупного оператора нормально, что информация о ресурсах и связанных с ними объектах распределена между разными системами. Критично другое: выстроены ли между этими системами интеграции и включено ли обновление данных в эксплуатационные процессы. Перед подключением, ремонтом или модернизацией специалисты должны проверить доступность ресурса, его связи с услугами и зону ответственности. В управляемой модели они получают эту информацию в системе до начала работ, а не восстанавливают ее вручную по таблицам, документам и ситуации на объекте.</em></p> <p><em>Для ИТ-директора это не вопрос аккуратности справочников, а вопрос управляемости. Несогласованные данные увеличивают трудозатраты, замедляют изменения, увеличивают время восстановления при авариях и риск штрафов за нарушение SLA, а также могут привести к ошибкам при оценке технической возможности подключения. В итоге бизнес получает дублирующие закупки, простаивающее оборудование, неиспользуемые лицензии и теневую инфраструктуру. </em><em>Рассмотрим</em><em>, почему ручной и фрагментированный учет больше не справляется с инфраструктурой современных операторов связи и какие риски это создает для эксплуатации и бизнеса</em><em>.</em></p> <h3>Проблема 1. Нет единого источника доверия по данным инфраструктуры</h3> <p>В телекоме проблема начинается не с самого факта, что данные распределены между OSS, ERP, системами техподдержки, складом и локальными учетными решениями. Для крупного оператора это нормальный ИТ-ландшафт: разные контуры отвечают за эксплуатацию, финансы, закупки, сервисные процессы и SLA.</p> <p>Риск возникает, когда между этими контурами нет согласованной модели данных и надежной синхронизации. Один и тот же объект сети существует сразу в нескольких ролях: как технический ресурс, бухгалтерский актив, элемент сервиса, складская позиция или объект обслуживания. Если статусы, связи и параметры обновляются несинхронно, оператор получает несколько версий одной инфраструктуры.</p> <p>Дальше это напрямую влияет на процессы. Перед подключением клиента, модернизацией участка сети или устранением аварии командам приходится вручную сверять данные: где ресурс реально находится, свободен ли он, на каком он балансе, какие сервисы от него зависят и кто отвечает за его состояние. Большая часть времени уходит не на выполнение работ, а на восстановление актуальной картины сети.</p> <p>Решение не в том, чтобы заменить все системы одним монолитом. Современный подход: модульный ИТ-ландшафт, где каждый контур сохраняет свою функцию, но работает через стандартизированные интерфейсы и опирается на единую модель инфраструктурных данных. Тогда у оператора появляется не набор разрозненных «версий правды», а управляемый контур данных о ресурсах, их статусе, связях, загрузке и жизненном цикле.</p> <h3>Проблема 2. Критичные знания об инфраструктуре остаются вне системы</h3> <p>Excel остается удобным инструментом для разовых задач, но плохо работает как основной контур учета инфраструктуры. Проблема быстро выходит за пределы самого файла: таблицы начинают жить на локальных компьютерах, в почте, на сетевых дисках и в личных папках сотрудников.</p> <p>В телеком-инфраструктуре это особенно рискованно, потому что критичные знания о сети фактически закрепляются не за системой, а за конкретными людьми. Кто-то знает, где лежит актуальная версия таблицы. Кто-то помнит, почему ресурс отмечен как занятый. Кто-то вручную сверяет данные после аварии, модернизации или подключения. Пока эти сотрудники доступны, процесс может выглядеть рабочим. Но при отпуске, увольнении, смене подрядчика или аварийной ситуации компания теряет не только человека, но и часть операционной памяти.</p> <p>Дальше ручной учет начинает тормозить эксплуатацию. Перед выездом бригады, ремонтом, переключением или подключением клиента приходится проверять не только состояние ресурса, но и актуальность самой информации. Часть данных может быть в схемах, таблице, часть в письмах, часть в голове инженера, часть в устаревшей выгрузке из другой системы.</p> <p>Из-за этого растет доля скрытых трудозатрат. Инженеры и технические службы тратят время не на работу с сетью, а на поиск файлов, сверку версий, уточнение статусов и восстановление истории изменений. Для оператора это превращается в операционный риск: в критический момент нельзя быстро понять, какие ресурсы реально доступны, какие работы уже выполнены и на какие данные можно опираться.</p> <h3>Проблема 3. Учет не отражает сетевые и сервисные зависимости</h3> <p>Универсальные учетные системы могут фиксировать оборудование, стоимость, владельца, складской статус или заявку. Но для управления сетью этого недостаточно: телеком-ресурс важен не сам по себе, а через связи с другими ресурсами, сервисами и эксплуатационными процессами.</p> <p>Один и тот же элемент инфраструктуры может быть частью маршрута, участвовать в оказании нескольких услуг, зависеть от физического оборудования, логического ресурса, виртуальной функции и внешнего подрядчика. Если система видит его только как инвентарную единицу или актив, она не показывает главное: какие сервисы завязаны на этот ресурс, что изменится при его переключении, какие SLA могут быть затронуты и кто должен участвовать в работах.</p> <p>Из-за этого часть решений снова уходит в ручной режим. Перед модернизацией, ремонтом или подключением нового клиента командам приходится отдельно восстанавливать зависимости: проверять схемы, уточнять маршруты, сверять данные с эксплуатацией и искать владельцев смежных контуров. Формально учет есть, но он не дает ответа на вопросы, от которых зависит работа сети.</p> <p>Для оператора это означает, что система хранит данные об объектах, но не описывает инфраструктуру как связанную среду. В такой модели сложно оценить влияние изменений, управлять SLA, планировать загрузку ресурсов и быстро разбирать инциденты. Телекому нужна не просто база активов, а модель сети, где физические, логические, виртуальные и сервисные уровни связаны между собой.</p> <h3>Проблема 4. Цифровая модель сети не успевает за изменениями</h3> <p>В операторской сети изменения происходят непрерывно: меняются трассы кабеля, порты на оборудовании, VLAN, IP-адресация, логические каналы, параметры клиентских подключений, состав сервисных цепочек. Часть изменений проходит в рамках плановых работ, часть возникает при авариях, временных переключениях или срочных подключениях клиентов.</p> <p>Проблема появляется, когда факт изменения уже произошел в сети, но еще не отражен в учетной системе. Например, инженер переключил клиента на другой порт, чтобы обойти неисправный участок, но информация осталась только в наряде или комментарии к заявке. В учете прежний порт по-прежнему считается занятым, новый не связан с сервисом, а сама схема подключения уже не соответствует реальности.</p> <p>Такие расхождения быстро накапливаются. Один временный кросс остается постоянным, резервная линия продолжает числиться свободной, демонтированное оборудование остается в модели сети, а освобожденная емкость не возвращается в доступный ресурс. В результате система показывает не текущее состояние инфраструктуры, а ее состояние на момент последней ручной актуализации.</p> <p>Это напрямую влияет на эксплуатацию. При новом подключении оператор может зарезервировать ресурс, который фактически уже используется, и ошибиться в оценке технической возможности. При аварии несоответствие между учетной моделью и реальной конфигурацией увеличивает время поиска поврежденного участка, затронутых услуг и доступного варианта переключения. При модернизации риск возникает не в самих изменениях, а в том, что фактически выполненные работы могут отклониться от запланированной схемы и остаться без корректного отражения в системе.</p> <p>Поэтому актуализация данных должна быть частью эксплуатации, но управление изменениями не должно начинаться с фиксации уже выполненных работ. В управляемой модели сначала в системе проектируется целевая конфигурация: рассчитываются ресурсы, прокладываются маршруты, определяются связи с услугами и формируется задание на выполнение работ. Затем изменения реализуются на объекте, в том числе силами подрядчика, после чего фактический результат сверяется с проектной моделью. Если работы выполнены с отклонениями, они фиксируются в системе и становятся основанием для корректировки данных, оценки последствий и, при необходимости, предъявления требований исполнителю.</p> <p>При таком подходе качество данных становится ответственностью не отдельного сотрудника, который обновляет учет после завершения работ, а всей команды, участвующей в планировании, выполнении и приемке изменений. Цифровая модель сети в этом случае используется не только для отражения текущего состояния инфраструктуры, но и для контроля того, как сеть должна измениться и насколько фактический результат соответствует плану.</p> <h3>Проблема 5. Бизнес не видит фактическую загрузку и доступность ресурсов</h3> <p>Когда учет не отражает фактическое состояние сети, бизнес перестает понимать, какие ресурсы у него реально есть, где они используются и какую нагрузку несут. На уровне эксплуатации это выглядит как техническая проблема, но на уровне управления превращается в прямые потери.</p> <p>Например, в сети может стоять оборудование, которое физически работает, но не связано в учетной системе с конкретным сервисом, площадкой или ответственным подразделением. Или наоборот: ресурс давно выведен из эксплуатации, но продолжает числиться занятым. То же самое происходит с портами, каналами, IP-адресами, лицензиями, стойками, кроссовым оборудованием и складскими остатками.</p> <p>Из-за этого компания начинает закупать то, что уже есть, но не видно в доступном ресурсе: заказывать новые порты, когда свободная емкость есть на соседнем узле, продолжать оплачивать лицензии, которые не используются, держать оборудование в резерве «на всякий случай», потому что нет доверия к данным о фактической загрузке. В итоге CAPEX и OPEX растут не из-за развития сети, а из-за непрозрачности ресурсов.</p> <p>Отдельная проблема — теневая инфраструктура. Это ресурсы, которые появились после временных подключений, аварийных переключений, модернизаций или локальных решений на местах, но не попали в управляемый контур. Они могут работать и даже обслуживать клиентов, но для планирования, финансового учета, аудита и управления рисками фактически остаются невидимыми.</p> <p>В такой ситуации бизнес не может точно оценить утилизацию активов, планировать закупки, управлять запасами и считать экономику модернизации. Формально инфраструктура есть, но ее реальная доступность, загрузка, стоимость владения и жизненный цикл остаются непрозрачными.</p> <h3>Заключение</h3> <p>Все пять проблем сходятся в одной точке: оператор теряет доверие к данным об инфраструктуре. Когда разные системы показывают разные версии сети, часть информации остается в таблицах и у сотрудников, а учет не отражает связи между ресурсами, услугами и зонами ответственности, данные перестают быть основой для решений.</p> <p>Для операторов и служб связи это означает, что проблему нельзя решить очередной инвентаризацией или переносом таблиц в новую систему. Если данные обновляются отдельно от реальных работ в сети, они снова начнут устаревать. Поэтому ключевая задача не в том, чтобы один раз собрать полную базу ресурсов, а в том, чтобы встроить учет в ежедневные процессы: подключение, ремонт, переключение, модернизацию, вывод оборудования из эксплуатации.</p> <p>Такой контур должен фиксировать не только наличие ресурса, но и его статус, связи, загрузку, владельца, историю изменений и влияние на услуги. Тогда перед новым подключением, аварийными работами или плановой модернизацией команда видит не разрозненные записи в разных системах, а актуальную модель инфраструктуры, на которую можно опираться.</p> <p>Но эта модель становится рабочей только в том случае, если ей доверяют сотрудники, которые планируют, выполняют и принимают работы на сети. Система должна помогать им заранее проверить ресурсы и зависимости, зафиксировать фактический результат, увидеть отклонения от плана и актуализировать данные без дополнительных ручных сверок. Иначе даже современный учетный контур начнут обходить через таблицы, перепроверки и локальные договоренности. Поэтому для оператора важно не только внедрить систему, но и правильно встроить ее в ИТ-архитектуру и процессы эксплуатации: настроить интеграции, закрепить порядок актуализации данных и сделать систему рабочим инструментом для всей команды. Только тогда актуальные данные действительно начинают использоваться в ежедневной работе и становятся надежной основой для управления инфраструктурой.</p> <p>#IMAGE_234907#</p> Инфраструктура современного оператора связи стала слишком динамичной и многослойной, чтобы управлять ею через ручные … article Евгений Мошняцкий, коммерческий директор НТЦ АРГУС https://www.itweek.ru/themes/detail.php?ID=234905 Thu, 28 May 2026 09:17:59 +0300 <p><em>Команды разработчиков могут укрепить доверие к коду, сгенерированному агентами искусственного интеллекта, с помощью четырехэтапного фреймворка цикла разработки, ориентированного на агентов (</em><em>Agent</em> <em>Centric</em> <em>Development</em> <em>Cycle</em><em>,</em><em> AC/DC): «направление», «генерация», «проверка» и «исправление» (</em><em>guide</em><em>, </em><em>generate</em><em>, </em><em>verify</em> <em>and</em> <em>solve</em><em>), пишет на портале </em><em>The</em> <em>New</em> <em>Stack</em> <em>Маниш Капур, старший директор по техническому маркетингу продуктов компании Sonar.</em></p> <p>Большая часть дискуссий об ИИ-кодировании по-прежнему сосредоточена на том, насколько быстро машины могут создавать код. Но объем кода — это не то же самое, что прогресс в разработке ПО. Поскольку команды полагаются на агентов для выполнения больших объемов работы, более сложный вопрос заключается в том, могут ли они создать повторяемую систему для управления, проверки и исправления созданного машинами кода, до того, как он создаст риски в дальнейшем.</p> <p>Один из полезных способов осмысления этой системы — это фреймворк AC/DC. В основе AC/DC лежат четыре этапа, которые определяют, как на самом деле работает агентная разработка в масштабе: «направление», «генерация», «проверка», «исправление». Из этих этапов наибольшее внимание рынка привлекает этап генерации кода агентами ИИ. Но на практике успех или провал фреймворка зависит от силы окружающих его слоев. При слабом руководстве агенты начинают с неверных предположений. При слабой проверке ошибки незаметно накапливаются. При слабом решении проблем команды получают в наследство растущую очередь проблем, для решения которых нет масштабируемого способа.</p> <h3>Почему проверка выходит на первый план</h3> <p>В течение многих лет современная разработка ПО была организована в соответствии с человеческим темпом работы. Разработчики писали код относительно небольшими итерациями. Коллеги по команде проверяли его. Конвейер валидировал его. Проблемы обычно выявлялись после того, как код уже был написан, но до того, как они становились слишком большими для понимания.</p> <p>Агентная разработка меняет эти условия. Вместо нескольких сотен строк, сформированных в результате непрерывного взаимодействия людей, команды теперь могут получать тысячи строк, созданных в более длительных циклах рассуждений, охватывающих несколько файлов и уровней стека. В таком масштабе традиционные методы проверки начинают испытывать слишком высокую нагрузку. Бремя понимания изменений возрастает гораздо быстрее, чем скорость генерации.</p> <p>Это создает проблему управления. Если организации продолжат рассматривать проверку как контрольную точку на поздней стадии, они обнаружат, что генерация кода опередила их способность обеспечить доверие. Именно здесь многие команды впервые почувствуют реальные трудности разработки с использованием ИИ: не в момент создания, а когда их попросят утвердить, объединить и поддержать созданный код.</p> <h3>Направление: задавайте агентам границы, а не просто промпты</h3> <p>Первое требование в агентном рабочем процессе — это задание направления. Не общих промптов, а структурированного контекста.</p> <p>Агенты должны понимать не только задачу, стоящую перед ними. Они должны понимать среду, в которой эта задача выполняется: архитектурные границы, инженерные стандарты, ожидания соответствия нормативным требованиям, соглашения об именовании и практические ограничения, которые редко умещаются в одном документе. Без этого агент может создать что-то, что кажется правильным локально, но при этом оказывается неправильным для более широкой системы.</p> <p>Это одно из главных заблуждений в современных дискуссиях об инструментах ИИ. Многие команды предполагают, что более сильные модели естественным образом уменьшают потребность в явном руководстве. В действительности часто верно обратное. Чем больше работы делегируется агентам, тем важнее становится четко определить область применения. Направление — это то, что уменьшает неизбежный дрифт до того, как он попадет в кодовую базу.</p> <p>В этом смысле этап «направление» — это не просто подготовка. Это первый уровень контроля.</p> <h3>Проверка: уровень, превращающий скорость в доверие</h3> <p>Проверка — это этап, на котором агентная разработка становится либо управляемой, либо хрупкой.</p> <p>Системы ИИ часто дают сбои, которые трудно обнаружить на ранних стадиях: скрытые логические ошибки, проблемы с надежностью, проблемы безопасности или затраты на обслуживание, которые проявляются только позже. Поскольку модели являются вероятностными и контекстно-зависимыми, проверка не может быть поверхностным код-ревью. Она должна быть основной функцией цикла разработки.</p> <p>Это означает, что проверка должна происходить в двух местах: внутри рабочего цикла, пока агент еще генерирует данные, и снова после того, как агент сочтет, что работа завершена. Первый этап выявляет ошибки на ранней стадии и помогает направлять следующий шаг. Второй этап проверяет, действительно ли результат удовлетворяет функциональным, нефункциональным и организационным требованиям.</p> <p>Это меняет роль обратной связи. Вместо того чтобы выявлять проблемы только после того, как большой запрос на изменение попадает к человеку-рецензенту, проверка становится активной частью рабочего процесса.</p> <p>Она также должна быть объяснимой и воспроизводимой. Детерминированный анализ, проверки безопасности, анализ сложности и тестирование создают доказательства. Они показывают, что было проверено, что прошло успешно, что не прошло и почему. В корпоративных условиях такая прозрачность является основой подотчетности.</p> <p>Качество кода все больше влияет на экономику разработки с использованием ИИ. В контролируемом <a href="https://arxiv.org/abs/2605.20049">исследовании</a>, проведенном компанией Sonar с использованием согласованных пар репозиториев с одинаковыми внешним поведением, архитектурой, зависимостями и тестовым покрытием, агенты, работающие с кодовыми базами более высокого качества, в среднем использовали примерно на 7% меньше входных токенов, на 8% меньше выходных токенов и на 11% меньше усилий по рассуждениям. Они также перечитывали файлы на 34% реже, что является полезным сигналом того, что более понятный код снижает неопределенность и позволяет агентам более уверенно вносить изменения. Другими словами, качество кода больше не является просто вопросом поддерживаемости. Оно начинает выглядеть как переменная эффективности инфраструктуры ИИ.</p> <h3>Исправление: замкнуть цикл вместо увеличения бэклога</h3> <p>Уровень проверки полезен только в том случае, если он приводит к действиям.</p> <p>Вот почему этап «исправление» так важен в модели AC/DC. Когда выявляются проблемы, процессу необходим систематический способ их устранения, повторной проверки исправлений и извлечения уроков из результатов. В противном случае проверка становится механизмом отчетности, а не оперативным механизмом. Это особенно важно в средах, где ИИ увеличивает общий объем проверяемого кода. Без механизма исправления любая система обнаружения в конечном итоге превращается в генератор бэклога.</p> <p>«Исправление» предотвращает этот режим сбоев, превращая обнаружение проблем в итеративный цикл. Предлагаются исправления, они перепроверяются и передаются в следующий цикл, так что система со временем улучшается. В зрелых рабочих процессах это означает, что разработчики тратят меньше энергии на решение повторяющихся проблем и больше энергии на архитектуру, оценку и проектные решения более высокого порядка.</p> <h3>Реальный сдвиг</h3> <p>Практический вывод прост. В агентной модели разработки основная задача больше не состоит в написании кода; она заключается в создании системы, которая делает сгенерированный код надежным.</p> <p>Командам по-прежнему нужны сильные модели и полезные инструменты, но реальным отличием является все, что окружает генерацию: качество контекста, который получают агенты, сила уровня проверки и способность достаточно быстро исправлять проблемы, чтобы успевать за машинным выводом.</p> <p>Организации, которые адаптируются быстрее всего, будут не теми, кто генерирует больше всего кода. Они смогут последовательно превращать этот код в ПО, которое будет понятным, управляемым и готовым к внедрению в производство.</p> <p>В эпоху программных агентов реальное преимущество будет заключаться не только в генерации кода. Оно будет заключаться в создании дисциплины для этого процесса.</p> Команды разработчиков могут укрепить доверие к коду, сгенерированному агентами искусственного интеллекта, с помощью … article https://www.itweek.ru/themes/detail.php?ID=234901 Wed, 27 May 2026 15:07:57 +0300 <p>Компания «Аладдин» сообщила о том, что система защиты информации на рабочих станциях и серверах Secret Disk для Linux сертифицирована во ФСТЭК России. Срок действия сертификата — до 26 января 2029 года.</p> <p>Согласно полученному сертификату, Secret Disk для Linux официально сертифицирован как программное средство со встроенными средствами защиты от несанкционированного доступа к информации, не являющейся государственной тайной. Также сертификат подтверждает, что Secret Disk реализует функции идентификации и аутентификации, управления доступом и регистрации событий безопасности. Решение соответствует требованиям документа «Требования по безопасности информации, устанавливающие уровни доверия к средствам технической защиты информации и средствам обеспечения безопасности информационных технологий» (ФСТЭК России, 2020) — по 4 уровню доверия и технических условий. </p> <p>Secret Disk для Linux — сертифицированная система защиты информации на рабочих станциях и серверах. Шифрование помогает избежать компрометации чувствительных к утечке конфиденциальных данных: злоумышленник не может воспользоваться данными, хранящимися в зашифрованном виде, даже если получит доступ к файлам.</p> <p>Решение обеспечивает защиту от несанкционированного доступа к информации, хранящейся и обрабатываемой на встроенных носителях, защиту от утечки информации при доступе посторонних лиц, в том числе при сервисном обслуживании, утере корпоративных ноутбуков, а также контроль доступа пользователей к защищённым данным. Система использует двухфакторную аутентификацию с применением ключевого контейнера пользователя и разграничение прав доступа между администраторами ИТ и ИБ. </p> Компания «Аладдин» сообщила о том, что система защиты информации на рабочих станциях и серверах Secret Disk для … message https://www.itweek.ru/themes/detail.php?ID=234899 Wed, 27 May 2026 12:56:02 +0300 <p>Представьте: клиент оставил заявку. Она пришла на почту менеджеру, тот переслал её в чат, коллега из другого отдела увидел сообщение через час, уточнил детали ещё через два — и только тогда процесс сдвинулся с места. Всё это время компания формально работала: системы работали, люди работали. Но заявка просто ждала.</p> <p>Именно так выглядит автоматизация без выстроенного процесса.</p> <h3>Когда инструментов много, а результата мало</h3> <p>Большинство компаний среднего размера сегодня неплохо оснащены технически. Есть CRM, куда попадают сделки. Есть ERP, где живут заказы и финансы. Есть мессенджеры, почта, таск-трекеры, иногда — отдельные интеграции между системами. Казалось бы, цифровой контур выстроен.</p> <p>Но стоит посмотреть не на список инструментов, а на то, как реально движется конкретная задача от момента возникновения до результата, — картина меняется.</p> <p>Входящий запрос поступил. Кто-то должен его заметить. Кто-то — решить, кому передать. Кто-то — уточнить статус через три дня, потому что ответа не было. Кто-то — вручную собрать информацию из двух систем, чтобы просто понять, на каком этапе вещи находятся.</p> <p>Работа идёт. Но значительная её часть — это не сама работа, а управление движением задачи между людьми.</p> <h3>Где на самом деле теряется время</h3> <p>Есть распространённое заблуждение: бизнес теряет эффективность там, где что-то делается медленно или плохо. На самом деле в большинстве случаев потери сосредоточены не внутри шагов, а между ними.</p> <p>Возьмём простой пример — согласование договора. Сам процесс проверки юристом занимает час. Но договор может лежать в очереди два дня, потому что никто не знал, что он уже готов к проверке. Потом ещё день — потому что юрист в отпуске, а регламента передачи нет. Потом ещё полдня — потому что правки вернулись не туда.</p> <p>Итог: работа на час растянулась на неделю. И ни один инструмент в этой цепочке не был сломан.</p> <p>То же самое происходит с закупками, которые тормозят из-за одного неотвеченного письма. С клиентскими обращениями, которые зависают между отделами. С внутренними заявками, которые маршрутизируются через переписку и устные договорённости.</p> <p>Проблема не в скорости исполнения. Проблема в том, что нет механизма, который сам знает, что должно произойти дальше.</p> <h3>Что значит «автоматизировать процесс», а не «автоматизировать действие»</h3> <p>Здесь важно разграничить два подхода, которые на первый взгляд выглядят похоже.</p> <p>Автоматизация действия — это когда система делает что-то конкретное: отправляет письмо, создает задачу, записывает данные. Полезно, но изолированно. Каждое действие существует само по себе.</p> <p>Автоматизация процесса — это когда заранее описана вся логика: что запускает процесс, какие условия проверяются, кто подключается на каком этапе, когда срабатывает следующий шаг, как контролируются сроки и где фиксируется результат.</p> <p>Разница принципиальная. В первом случае компания автоматизирует точки. Во втором — маршрут целиком.</p> <p>Именно поэтому компании с большим количеством внедрённых инструментов нередко работают медленнее, чем хотелось бы: каждый инструмент делает своё дело, но никто не управляет переходами между ними. Этим управляют люди — вручную, по памяти, через мессенджеры.</p> <h3>Почему новые технологии не решают эту проблему сами по себе</h3> <p>Последние пару лет бизнес активно интересуется AI-инструментами, умными интеграциями, предиктивной аналитикой. И всё это действительно может давать эффект — но только при одном условии: если сам процесс уже выстроен.</p> <p>Если между событием и результатом нет чёткой логики — что происходит, кто отвечает, в какой момент, при каких условиях, — то новый инструмент просто ускоряет существующий хаос. Быстрее уведомление уйдёт не туда. Быстрее задача окажется у человека, который не знает, что с ней делать.</p> <p>В практике работы компаний из разных отраслей — от логистики до финансовых сервисов — этот паттерн повторяется. Бизнес говорит «нам нужна автоматизация» и в ходе разбора выясняется, что сначала нужно ответить на более простой вопрос: а как процесс должен работать в принципе? Кто за что отвечает? Что должно происходить, если что-то пошло не так?</p> <p>Пока этого описания нет, автоматизировать нечего.</p> <p>Здесь важно разграничить роли, которые часто путают: AI-агент может усилить процесс — подсказать, классифицировать, снять рутину, ускорить шаг. Но он не выстраивает процесс. Если нет понятного маршрута, ролей, правил и точек контроля — агенту просто не на что опереться. В таком случае он не устраняет хаос, а действует быстрее внутри него.</p> <p>Поэтому правильная последовательность выглядит так: сначала выстроить логику процесса, потом убрать из него рутину и только затем усиливать отдельные этапы интеллектуальными инструментами там, где это действительно даёт эффект. Это намного практичнее, чем искать, куда «прикрутить ИИ» просто потому, что это модно.</p> <h3>С чего начинать</h3> <p>Хорошая новость в том, что выстраивание логики процесса — это не многомесячный проект и не задача только для ИТ-отдела. Это в первую очередь управленческая работа.</p> <p>Практически для любого повторяющегося процесса можно задать несколько ключевых вопросов:</p> <ul> <li> Что является сигналом к началу процесса?</li> <li> Кто и в какой момент должен быть подключён?</li> <li> Какие условия влияют на маршрут?</li> <li> Где нужен контроль сроков?</li> <li> Как выглядит завершение и что фиксируется?</li> </ul> <p>Когда ответы на эти вопросы есть — процесс можно описать, передать в систему и запускать автоматически. Workflow в этом смысле не про технологию. Это про то, что процесс перестаёт держаться на памяти конкретных людей и неформальных договорённостях.</p> <p>Вот как это выглядит на примере одной управляющей компании, обслуживающей несколько объектов коммерческой недвижимости. Заявки от арендаторов приходили по-разному: кто-то писал в Telegram, кто-то на почту, кто-то звонил. Диспетчеры вручную разбирали поток, определяли категорию, передавали исполнителю, отдельно следили за сроками.</p> <p>Формально всё работало. Но путь от обращения до исполнения занимал в среднем <nobr>4-6 часов.</nobr> Не потому что работа была сложной. А потому что большую часть этого времени заявка просто ждала: пока диспетчер увидит, пока классифицирует, пока передаст, пока исполнитель подтвердит получение. Сама работа занимала куда меньше времени — потери накапливались между шагами.</p> <p>Когда специалисты компании прошли по пяти вопросам выше и выстроили логику процесса — определили точку входа, условия маршрутизации, зоны ответственности, контроль срока реакции и автоматическую эскалацию — ничего принципиально нового не появилось. Появилась структура, которой раньше не было.</p> <p>В результате среднее время обработки сократилось до <nobr>40-50 минут.</nobr> Нагрузка на диспетчеров снизилась вдвое. Не потому что люди стали работать быстрее — просто перестали тратить время на координацию, которую теперь делает система.</p> <p>Но главный эффект часто не в том, что процесс пошёл быстрее. Важнее другое: у компании появляется видимость там, где раньше была зависимость от людей и ручного контроля.</p> <p>Когда процесс выстроен в единую логику, становится понятно: где именно возникают задержки, какие шаги чаще всего требуют вмешательства, на каких людях завязаны маршруты, где повторяются одни и те же сбои. Это и есть наблюдаемость процесса — возможность не просто исполнять, но видеть и управлять.</p> <p>Без неё управляемость, как показывает практика, иллюзией. Процесс вроде бы идёт — но куда именно и с какими потерями, никто точно не знает.</p> <h3>Главное</h3> <p>Автоматизация сама по себе не делает бизнес быстрее и управляемее. Это делает выстроенный процесс — и уже потом автоматизация, которая его поддерживает.</p> <p>Большинство компаний идут в обратном порядке: сначала внедряют инструменты, потом удивляются, почему задачи всё равно теряются. Выход не в том, чтобы добавить ещё один сервис. Выход в том, чтобы сначала ответить на вопрос: а как этот процесс вообще должен работать?</p> <p>#IMAGE_234900#</p> Представьте: клиент оставил заявку. Она пришла на почту менеджеру, тот переслал её в чат, коллега из другого … article Иван Лашков, руководитель отдела маркетинга платформы STAQ https://www.itweek.ru/themes/detail.php?ID=234898 Wed, 27 May 2026 11:20:38 +0300 <p>Российский вендор Deckhouse представил итоги развития своей платформы за последние полгода. Основные изменения коснулись управляющего слоя и безопасности Deckhouse Kubernetes Platform (DKP), виртуализации в рамках решения, а также развития линейки управляемых сервисов. Кроме того, обновление затронуло возможности наблюдаемости, работу с данными и инструменты обучения специалистов.</p> <p>В центре управления кластерами DKP, Deckhouse Commander, реализованы биллинг и управление затратами. Новый инструмент позволяет перевести потребление ресурсов (CPU, память, хранилище) в понятные бизнес-показатели по проектам, командам и кластерам. Это делает расходы на инфраструктуру прозрачными и предсказуемыми для компаний.</p> <p>Платформа переходит на новый уровень безопасности модулей. Внедрена система контроля целостности модулей на базе файловой системы EROFS и технологии <nobr>dm-verity.</nobr> Это гарантирует защиту компонентов платформы от несанкционированных изменений на уровне ядра ОС.</p> <p>Кроме того, использование distroless-образов в CNI Cilium сокращает поверхность потенциальных атак на платформу, а новые политики не позволяют рабочим нагрузкам размещаться на системных узлах и получать избыточные привилегии. Это исключает человеческий фактор при настройке размещения нагрузок и избавляет ИБ-специалистов от ручной проверки манифестов.</p> <p>Также компания переоформила сертификат ФСТЭК России № 4860: теперь он распространяется не только на контейнеризацию, но и на виртуализацию. В результате продукт DKP Certified Security Edition Pro позволяет управлять контейнерами и виртуальными машинами в рамках единой защищённой платформы. Подробнее об обновлении сертификата — в записи вебинара. </p> <p>Платформа предоставляет командам доступ к семи управляемым сервисам для работы с данными, включая PostgreSQL, Kafka и Valkey. Managed-модель снижает операционную нагрузку на инфраструктурную команду и ускоряет запуск новых бизнес-приложений.</p> <p>Deckhouse позволяет управлять виртуальными машинами (ВМ) в общем контуре с контейнерами. Платформа обеспечивает единый подход к управлению любыми пользовательскими нагрузками, сквозную наблюдаемость и общие инструменты безопасности.</p> <p>В обновлении добавлены функции: клонирование ВМ, выбор конкретного сервера при миграции ВМ, работа с внешними USB-устройствами и оптимизированная работа с хранилищем образов. В сочетании с полноценным API и единым веб-интерфейсом это позволяет автоматизировать работу с виртуальными машинами так же легко, как и с контейнерами. Такой подход избавляет от дублирования инфраструктуры, снижает операционные расходы и ускоряет развёртывание приложений.</p> <p>Запуск AI/ML-нагрузок любой сложности. DKP обеспечивает более гибкое распределение ресурсов GPU под разные типы нагрузок на одном узле с помощью покарточной настройки MIG.</p> <p>Актуальные версии Kubernetes. Разработчики DKP добавили в платформу поддержку версий Kubernetes 1.34 и 1.35, а также внедрили инструменты для гибкого управления доступностью экспериментальных возможностей Kubernetes. Это позволяет командам раньше пробовать инновационные технологии Kubernetes в своих задачах.</p> <p>Встроенный реестр образов (Registry). Появилась возможность использовать внутренний реестр вместо внешнего — как для образов платформы, так и для прикладной нагрузки. Это избавляет от необходимости настраивать сторонние инструменты и экономит ресурсы на их поддержку.</p> <p>Разделение прав доступа в UI. В интерфейсе провели деление платформы на административную (система) и пользовательскую (проекты) части. Правила доступа позволяют чётко разделить доступные операции на уровне всей системы или отдельного проекта — теперь и в UI.</p> <p>Развитие универсальной интеграции. Deckhouse Kubernetes Platform работает в любых окружениях: от публичных облаков до физических серверов. В новом релизе возможности интеграции расширены для VMware Cloud Director, vSphere и zVirt. Единый стандарт управления позволяет переносить нагрузки между разными провайдерами через настройку конфигурации — без сложной архитектурной перестройки системы.</p> <p>Упрощение эксплуатации и повышение наблюдаемости. Настраивать условия алертов и создавать собственные метрики стало проще и быстрее. Все действия доступны из одного окна — это сокращает время настройки, снижает «порог входа» для специалистов и сокращает время на диагностику сбоев.</p> <p>Понятная документация и обучение. Команда Deckhouse добавила материалы и актуализировала разделы в документации, чтобы сделать её удобнее и практичнее для команд внедрения и эксплуатации. В Deckhouse Академии запущены новые курсы по безопасности и наблюдаемости, а также открыта профессиональная сертификация для ИБ-инженеров.</p> <p>«Развивая Deckhouse Kubernetes Platform как открытый индустриальный стандарт, за последние полгода мы значительно расширили функциональность платформы. Особое внимание уделили прозрачности расходов и информационной безопасности: биллинг в Deckhouse Commander даёт чёткое понимание стоимости каждого проекта, а новые уровни защиты повышают устойчивость к современным угрозам. Мы упрощаем пользовательский путь и добавляем управляемые сервисы: в последнем обновлении это семь сервисов, закрывающих основные сценарии работы с данными и очередями. При этом DKP остаётся единым слоем управления, одинаково стабильно работающим в облаках и частных контурах вне зависимости от вендора», — прокомментировал Карапет Манасян, директор по продукту Deckhouse Kubernetes Platform.</p> Российский вендор Deckhouse представил итоги развития своей платформы за последние полгода. Основные изменения коснулись … message https://www.itweek.ru/themes/detail.php?ID=234897 Wed, 27 May 2026 11:14:39 +0300 <p>ICT.Moscow проанализировал перспективы развития проектов с открытым исходным кодом (Open Source) в 2026 году, опросив более 300 представителей ИТ-сферы. Прогнозируется, что российские аналоги будут чаще выбирать в качестве замены зарубежным платформам для хранения кода.</p> <p>По данным ICT.Moscow, специалисты станут все активнее пробовать российские платформы для проектов Open Source. По результатам опроса, в котором приняли участие 307 представителей ИТ-сферы, 36% респондентов считают, что такие ресурсы в 2026 году будут охотнее выбирать в качестве альтернативы зарубежным репозиториям. При этом 14% отмечают растущий интерес к гибридным и коммерческим бизнес-моделям распространения открытых решений.</p> <p>Согласно проведенному исследованию влияние искусственного интеллекта (ИИ) на развитие Open Source в России становится все более очевидным. 46% участников опроса полагают, что эта технология будет ключевым фактором для увеличения числа открытых проектов как в России, так и за ее пределами.</p> <p>35% респондентов рассчитывают, что в стране появятся центры экспертизы на стыке индустрии, науки и сообществ открытого кода. Причем разработчики и контрибьюторы не обязательно будут объединяться вокруг успешных проектов — в такой сценарий верят только 10% опрошенных.</p> <p>Часть ожиданий связана с участием государства в судьбе сферы открытого кода: по мнению 35% опрошенных, в 2026 году могут быть внедрены национальные стандартов качества и безопасности продуктов Open Source, в то время как 15% надеются на новые инициативы в регулировании этой индустрии.</p> <p>Несмотря на преобладание оптимистичных прогнозов, 28% опрошенных не ждут значительных изменений в сфере открытого софта в России, указывая на неясность относительно будущего локального развития. 21% участников выражают опасения, что темпы роста проектов замедлятся, и 12% предполагают, что тенденция к закрытию репозиториев может усилиться, в том числе через распространение лишь частично открытых лицензий на ПО (Source Available).</p> <p>Опрос проводился командой аналитического хаба ICT.Moscow в апреле 2026 года. Участникам предлагалось выбрать несколько вариантов ответа на вопрос о том, чего они ожидают от российского Open Source в ближайшей перспективе.</p> ICT.Moscow проанализировал перспективы развития проектов с открытым исходным кодом (Open Source) в 2026 году … message https://www.itweek.ru/themes/detail.php?ID=234896 Wed, 27 May 2026 11:13:12 +0300 <p>Эксперты компании «Информзащита» выявили тенденцию роста инцидентов безопасности, связанных с использованием AI-агентов в корпоративной среде: в 2026 году с такими событиями столкнулись 42% организаций против 31% годом ранее. По оценке специалистов, рост связан с тем, что компании стали чаще выводить AI-агентов за пределы пилотных проектов — в ИТ, инженерные команды, клиентский сервис, безопасность, закупки и внутренние операционные процессы. Данные опроса фиксируют, что 58% респондентов указывают, что обнаружение и реагирование занимает более пяти часов. Основная причина задержки — отсутствие сквозного журналирования цепочки решений агента: команда видит итоговое действие, но не видит, какой промпт, какой инструмент и какие данные привели к этому действию. Российская динамика согласуется с глобальным трендом, но пока отстает по проявлениям.</p> <p>Главная сложность в том, что AI-агент отличается от обычного чат-бота или аналитического инструмента. Он использует API, создает задачи, редактирует документы, запускает скрипты, пересылает данные, подключается к CRM, SIEM, тикетным системам и репозиториям. При недостаточной настройке прав такой агент начинает действовать шире, чем предполагали владельцы процесса. Около 53% организаций сталкивались с ситуациями, когда AI-агенты превышали заданные полномочия, например, обращались к учетным записям и хранилищам, не входившим в исходную задачу.</p> <p>На динамику 2026 года повлияла децентрализация внедрения. Только 5% компаний используют единую платформу для AI-агентов, тогда как 44% работают сразу с двумя-тремя платформами, а 43% — с четырьмя и более. Внутренний контроль при такой модели быстро теряет полноту: часть агентов создается бизнес-подразделениями без согласования с ИБ, часть появляется в рамках low-code-сценариев, часть подключается к SaaS-сервисам через личные или групповые токены, нередко с избыточными правами на запись. Отдельная техническая проблема состоит в том, что AI-агент с точки зрения целевых систем выглядит как обычная учетная запись, при этом ни инструменты IAM, ни процессы согласования доступа изначально не проектировались под нечеловеческие идентичности с автономным поведением. По данным исследований, организации, последовательно применяющие принцип минимально необходимого доступа к AI-агентам, фиксируют инциденты в 17% случаев, против 76% у компаний без такой практики — это самое крупное единичное снижение риска среди всех контролируемых мер. Дополнительный фактор риска — появление в <nobr>2025-2026</nobr> годах открытых протоколов взаимодействия агентов с инструментами (Model Context Protocol, MCP) и между собой (Agent-to-Agent, A2A): они ускоряют интеграцию, но создают новый слой доверительных отношений, которым по умолчанию не управляет ни одна классическая система защиты. По оценке «Информзащиты», в компаниях с численностью от 1000 сотрудников доля неинвентаризированных AI-агентов в 2026 году достигает 27%, а в организациях с активным использованием low-code и no-code платформ — до 39%. Это не всегда прямое нарушение политики, но именно такие зоны чаще становятся источником утечек, ошибочных действий и неконтролируемого обмена данными.</p> <p>Разбивка по векторам атак показывает, что наиболее заметную долю занимают злоупотребления правами и выход за пределы разрешенного сценария — 31% выявленных событий. В декабре 2025 года OWASP выпустила отдельный Top 10 for Agentic Applications, ASI (Top 10 для агентных приложений), в котором классические <nobr>LLM-риски</nobr> переосмыслены под автономное исполнение: prompt injection (инъекция в запрос) превращается в Agent Goal Hijack (перехват цели агента), excessive agency (избыточные полномочия) — в вектор privilege escalation (эскалации привилегий), data poisoning (отравление данных) — в memory poisoning (долговременную порчу памяти агента). Структура инцидентов, фиксируемая «Информзащитой», соответствует этой классификации. На prompt injection и подмену инструкций приходится 24%, на утечки через подключенные коннекторы и корпоративные хранилища — 18%, на shadow AI-агентов без владельца и формального учета — 14%, на компрометацию токенов, API-ключей и сервисных учетных записей — 9%, на атаки через сторонние плагины и цепочки поставки — 4%.</p> <p>Наиболее уязвимыми оказались финансовые организации, на которые приходится 26% зарегистрированных инцидентов с AI-агентами. В зоне повышенного риска также находятся ИТ- и телеком-компании с долей 21%, промышленность и энергетика — 17%, ритейл и e-commerce — 14%, медицинские и фармацевтические организации — 11%, логистика и транспорт — 7%, профессиональные услуги и консалтинг — 4%. Финансовый сектор лидирует из-за высокой плотности интеграций, большого числа регуляторных требований и активного использования автоматизации в антифроде, клиентской поддержке и обработке документов. В ИТ и телекоме риск усиливается из-за доступа агентов к репозиториям, CI/CD и системам управления инфраструктурой. В промышленности проблема чаще связана с подключением AI-инструментов к данным мониторинга, техдокументации и сервисным контурам.</p> <p>Картину 2026 года уже сформировали несколько публично раскрытых инцидентов. В апреле 2026 года компания Vercel подтвердила компрометацию через сторонний AI-инструмент Context.ai с ущербом около $2 млн, развивавшуюся по классическому supply-chain-сценарию: от личного аккаунта сотрудника в AI-сервисе, к корпоративному Google Workspace и далее к внутренним средам. Уязвимость EchoLeak в Microsoft 365 Copilot (CVE-2025-32711) показала возможность zero-click-эксфильтрации данных через скрытую инструкцию в письме, без действий пользователя. Отдельный класс рисков иллюстрируют инциденты с агентами разработки: задокументированы случаи, когда автономный кодинговый агент за секунды удалял рабочие базы данных и резервные копии, реагируя на типовую техническую ошибку.</p> <p>«Компания может видеть выполнение задачи, но не видеть всю цепочку решений, которая к ней привела. В 2026 году мы ожидаем, что число инцидентов будет расти прежде всего там, где агенты внедряются быстрее, чем появляются владельцы, журналы действий и правила остановки», — прокомментировал Анатолий Песковский, директор Департамента наступательной безопасности компании «Информзащиты».</p> <p>По рекомендациям экспертов, компаниям необходимо вести полный реестр агентов, фиксировать владельца каждого сценария, ограничивать права по принципу минимально необходимого доступа, разделять доступ к данным и действиям, контролировать использование токенов и сервисных учетных записей, а также внедрять журналирование на уровне промптов, инструментов, API-вызовов и итоговых операций. Для сценариев с доступом к персональным данным, финансовой информации, исходному коду и производственным системам нужен отдельный процесс согласования, тестирование на prompt injection и регулярная проверка фактических полномочий. Дополнительный слой защиты дают runtime-политики: ограничение списка доступных инструментов и внешних доменов, обязательное подтверждение операций с высоким риском, изоляция секретов от контекста модели, выполнение действий агента в изолированной среде (sandboxing) и заранее настроенный механизм принудительной остановки — kill switch на уровне платформы оркестрации. Отдельным направлением становится инвентаризация и управление нечеловеческими идентичностями (NHI): каждому агенту присваивается собственная учетная запись с уникальными правами, отделенная от учетных записей разработчиков и сервисных аккаунтов общего назначения. Параллельно формируется практика «надзорных агентов» (guardian agents), которые в реальном времени отслеживают поведение основных агентов и блокируют действия, выходящие за установленные политики. Практика показывает, что наибольший эффект дает связка инвентаризации, runtime-контроля, DLP, мониторинга аномального поведения и заранее описанных процедур отключения агента при выходе за допустимый контур. Без такой дисциплины автономность агентов начинает работать против бизнеса: скорость операций растет, но вместе с ней увеличивается окно, в котором ошибка агента или точная атака превращается в полноценный инцидент. «Информзащита» рекомендует встраивать AI-агентов в стандартные циклы управления уязвимостями, инцидентами и доступом с самого начала проекта, а не после первого инцидента: издержки на «догоняющий» контроль, по нашим наблюдениям, кратно превышают стоимость превентивного внедрения.</p> Эксперты компании «Информзащита» выявили тенденцию роста инцидентов безопасности, связанных с использованием AI-агентов … message https://www.itweek.ru/themes/detail.php?ID=234895 Wed, 27 May 2026 11:12:17 +0300 <p>Компании, выстраивающие системный подход к управлению опытом сотрудников (Employee Experience, EX) на основе данных, могут достигать роста общей продуктивности до 15%, увеличивать вовлеченность до 75%, снижать текучесть кадров до 35% и ускорять ключевые бизнес-процессы до 25%. К такому выводу пришли аналитики консалтинговой технологической компании Axenix по итогам исследования, посвященного влиянию EX на рост и эффективность бизнеса.</p> <p>В условиях замедления экономического роста и ограниченных ресурсов, компании усиливают фокус на повышении производительности команд. Одновременно растут ожидания сотрудников к качеству взаимодействия с работодателем, что требует более системного подхода к управлению человеческим капиталом. </p> <p>По данным Axenix, 56% HR-директоров планируют усиливать программы организационной эффективности, пересматривать структуру нагрузки и искать способы ускорения работы с использованием ИИ-инструментов. HRD отмечают, что продолжат усилия для удержания, однако речь все чаще идет о прагматичных решениях: создании условий для самых результативных сотрудников, оценке реальной эффективности применяемых инструментов. Тенденция постепенно переходит из массовых кампаний борьбы за кадры к аналитическому и адресному подходу.</p> <p>Стратегическим ответом на этот запрос становится выстраивание системы управления опытом сотрудников на основе данных. В ее основе — цифровой профиль сотрудника, объединяющий HR-метрики, поведенческие данные и обратную связь. </p> <p>Модель Axenix включает восемь взаимосвязанных элементов и превращает EХ в масштабируемую систему:</p> <ul> <li>сегментация по рабочим контекстам и поведенческим профилям;</li> <li>путь сотрудника — синергия опыта и функциональных процессов;</li> <li>три среды: цифровая, физическая, взаимодействия;</li> <li>точки контакта как кросс-функциональная экосистема сервисов;</li> <li>методология: EJM (карта пути сотрудника), пульс-опросы, Voice of Employee (голос сотрудника);</li> <li>технологии HCM-платформ с ИИ-надстройкой;</li> <li>система измеримости через HR- и бизнес-метрики.</li> </ul> <p>Опыт сотрудников рассматривается как фактор, влияющий на вовлеченность, удержание персонала и производительностью труда в компании. Улучшение взаимодействия с компанией — от доступа к инструментам и информации до качества управленческих практик — позволяет устранять организационные барьеры и повышать согласованность работы команд, а также отражается на качестве клиентского взаимодействия и бизнес-результатах компании.</p> <p>Практика Axenix показывает, что внедрение данного подхода на пилотных сегментах позволяет уже на раннем этапе фиксировать ускорение процессов на <nobr>10-15%</nobr> и рост удовлетворенности сотрудников до 20%, а также получать возврат инвестиций в течение одного квартала без существенных затрат.</p> <p>«Качественный EX снижает текучесть, ускоряет бизнес-процессы и повышает лояльность сотрудников, обеспечивая понятную связь между операционной эффективностью и ростом выручки и маржи: „оптимизация барьеров-скорость и производительность команд-качество <nobr>CX-рост</nobr> выручки/снижение OPEX-ROI HR-инициатив“. Управление опытом сотрудников следует рассматривать не как набор отдельных HR-практик, а как целостную систему, в которой важны согласованность, измеримость и связь с бизнес-результатом», — прокомментировала Ирина Чистова, директор практики «Стратегический консалтинг», направление «Клиенто-центричные трансформации» Axenix.</p> <p>«Управление опытом сотрудников требует не отдельных инициатив, а координации между HR, IT, административными и бизнес-функциями. В рамках проектов мы видим, что многие барьеры возникают именно на стыке процессов и зон ответственности. Компании, которым удается выстраивать более согласованную среду взаимодействия, получают более устойчивые команды, предсказуемые процессы и высокий уровень вовлеченности сотрудников», — отметила Анастасия Сидакова, менеджер практики «Стратегический консалтинг», направление «Люди и организация» Axenix.</p> <p>Исследование основано на серии из 25 глубинных интервью с HR-директорами крупных компаний и бенчмарк-анализе практик рынка и проектного опыта Axenix, сформированного в ходе реализации EX-проектов в различных отраслях. Такой подход позволил сопоставить управленческие решения с их влиянием на HR- и бизнес-показатели.</p> Компании, выстраивающие системный подход к управлению опытом сотрудников (Employee Experience, EX) на основе данных … message https://www.itweek.ru/themes/detail.php?ID=234894 Wed, 27 May 2026 11:10:54 +0300 <p>Облачный провайдер mClouds ввел в эксплуатацию обновленную GPU-платформу на серверах Dell R7725 с процессорами последнего поколения AMD EPYC 9555 4,2 ГГц и памятью DDR5-6400. Решение ориентировано на ускорение в сфере AI, 3D-моделирования, сложных инженерных расчетов и работой с нагруженными базами данных.</p> <p>Ключевой особенностью платформа стала её гибридная направленность. Платформа позволяет как работать с GPU, так и размещать бизнес-критичные задачи, требующие высокой скорости от всех подсистем облака. Кластер укомплектован графическими ускорителями NVIDIA L4 24 ГБ, NVIDIA A16 64 ГБ и NVIDIA RTX 6000 PRO 96GB. В обновленном кластере осуществен переход на PCIe Gen 5, что обеспечило максимальные скорости работы для локальных NVMe дисков, позволяя ускорять работу с загрузкой данных в GPU-кластере. </p> <p>Процессоры EPYC 9555 с 64 ядрами. Каждый вычислительный хост кластера оснащен двумя процессорами AMD EPYC 9555, что в сумме дает 128 физических ядер, работающих на частоте 4,2 ГГц. Оптимально для ресурсоемких задач: размещение рабочих мест VDI с GPU, повышенная производительность для задач 1С Предприятия, сложных инженерных расчетов в CAD и BIM средах и работе с нейросетями.</p> <p>Оперативная память. Быстрая DDR5-6400 для высокочастотных нагрузок, до 30% рост пропускной способности, в сравнении с DDR5-4800.</p> <p>Дисковая подсистема. Перешла на PCIe Gen 5 со скоростями выше 10 ГБ/с и обеспечивает высокую скорость передачи данных при загрузке и сохранении сложных CAD-моделей, обучении нейросетей, обработке больших массивов данных.</p> <p>Кроме того, новый кластер предлагает три конфигурации видеокарт, что позволяет гибко подобрать ресурсы под свои задачи:</p> <ul> <li>NVIDIA A16 64 Гб с 5120 ядрами CUDA и 160 тензорными ядрами ориентирована на профессиональные BIM- и CAD-расчеты, обеспечивает высокую плотность виртуальных рабочих мест в системах проектирования;</li> <li>NVIDIA L4 24 Гб оснащена 7680 ядрами CUDA, 60 RT-ядрами и 240 тензорными ядрами — эта конфигурация обеспечивает высокую производительность в проектах инференса нейросетей, работе с графикой и требовательных задачах VDI;</li> <li>NVIDIA RTX 6000 PRO 96GB оснащена 24 064 ядрами CUDA, 188 RT-ядрами и 752 тензорными ядрами — обеспечивает оптимальную экономику при работе с моделями, требующих 96GB памяти.</li> </ul> <p>Новый кластер на базе AMD EPYC 9555 уже доступен для заказа.</p> <p>Александр Иванников, директор по развитию провайдера облачной инфраструктуры mClouds, отметил: «В последние годы вычислительная мощность становится ключевым драйвером роста для бизнеса, особенно в области AI-технологий. Мы постоянно развиваем наши платформы и стремимся предоставлять клиентам все необходимые инструменты для успешной реализации проектов, сохраняя сбалансированный подход к ценообразованию. Новый кластер уже прошел тестирование и показывает до <nobr>30–40%</nobr> роста по сравнению с платформой предыдущего поколения — компании смогут выйти на новый уровень производительности».</p> Облачный провайдер mClouds ввел в эксплуатацию обновленную GPU-платформу на серверах Dell R7725 с процессорами … message https://www.itweek.ru/themes/detail.php?ID=234893 Wed, 27 May 2026 09:06:50 +0300 <p><em>Руководители предприятий потратили два года и сотни миллиардов долларов на искусственный интеллект. Результаты оказались неоднозначными. Согласно глобальному опросу McKinsey 2024 года, менее одной трети компаний сообщили, что их инвестиции в ИИ принесли значимую и устойчивую бизнес-ценность. Демонстрации, как правило, впечатляют, а производственная эксплуатация — разочаровывает, пишет на портале </em><em>BigDataWire</em> <em>Сохам Мазумдар, соучредитель и генеральный директор WisdomAI.</em></p> <p>Чаще всего предлагается диагноз: модель недостаточно хороша, инфраструктура данных недостаточно зрелая или сотрудники не прошли обучение. Этот диагноз в значительной степени неверный или, по крайней мере, неполный.</p> <p>Настоящая проблема заключается в контексте, а именно в отсутствии устойчивого, динамического слоя корпоративного контекста, расположенного между ИИ и данными. Пока организации не поймут, что это значит, и не начнут действовать соответствующим образом, модернизация моделей и инвестиции в инфраструктуру не устранят этот пробел.</p> <h3>Пробел в контексте</h3> <p>Каждая корпоративная система ИИ, будь то инструмент разговорной аналитики, агент финансового планирования или оптимизатор цепочки поставок, работает путем преобразования человеческого вопроса в задачу, выполняемую машиной. Для точного преобразования система должна понимать бизнес, значение данных, как определяются метрики, какие бизнес-правила применяются и как эти правила развивались с течением времени.</p> <p>Именно это понимание мы подразумеваем под контекстом. В большинстве корпоративных внедрений он либо отсутствует, либо неполный, либо устаревает быстрее, чем кто-либо успевает его отслеживать.</p> <p>Рассмотрим пример глобального производителя из списка Global 2000, внедряющего систему ИИ для финансовой аналитики. Система может получать доступ к хранилищу данных и выполнять запросы. Но может ли она точно рассчитать валовую прибыль по бизнес-подразделениям, если правила должны учитывать внутрикорпоративные переводы, региональное распределение затрат и исключения, сделанные в ходе двух последних приобретений? Эти правила существуют в головах нескольких старших финансовых аналитиков. Они существуют в электронных таблицах, в трехлетних обсуждениях в Slack, в недокументированной институциональной памяти. Когда аналитики меняют роли или уходят на пенсию, знания исчезают, и система ИИ, лишённая этого контекста, начинает генерировать ответы, которые точны, но неверны.</p> <p>Это не проблема качества данных. Это проблема контекста, и она проявляется во всех отраслях.</p> <h3>Четыре измерения, в которых руководители ошибаются</h3> <p>Существует четыре структурных требования для эффективного контекстного слоя, и большинство организаций не справляются со всеми из них.</p> <p><strong>1. Контекст должен быть самообучающимся. </strong>Наиболее распространённая ошибка — рассматривать контекст как разовую реализацию. Организации вкладывают значительные средства в первоначальные усилия по сбору контекста, помечая метаданные, документируя бизнес-определения, каталогизируя утверждённые запросы, а затем считают процесс завершенным, чего никогда не бывает.</p> <p>Контекст постоянно и часто незаметно разрушается. Схемы меняются по мере того, как инженерные команды развивают модель данных. Происходит дрифт данных, поскольку источники данных меняются способами, о которых никто официально не объявляет. Бизнес-метрики переопределяются, «ARR» означает что-то другое после приобретения или изменения модели ценообразования. Бизнес-процессы реорганизуются, и логика, лежащая в основе панелей мониторинга за прошлый квартал, незаметно становится неверной. К тому времени, когда ошибка проявляется, контекст часто устаревает уже несколько месяцев.</p> <p>Если слой контекста зависит от людей, которые его поддерживают, люди становятся узким местом, и они всегда будут терять позиции. Эффективный механизм контекста должен постоянно обучаться на основе моделей использования, проверенных ответов и исправлений, внесенных людьми, улучшаясь со временем, а не деградируя.</p> <p><strong>2. Контекст многомерен и не может быть зафиксирован в одном месте.</strong> Корпоративные знания не хранятся в одной системе. Они одновременно существуют в схемах, в логике, закодированной в проверенных за много лет запросах аналитиков, в формальной и неформальной документации, в семантическом слое и слое метаданных, а также в неявных знаниях, которые существуют только в головах людей.</p> <p>Ошибка большинства предприятий заключается в том, что они стремятся к одному источнику контекста — каталогу метаданных, семантическому слою, словарю данных — и ожидают, что он возьмет на себя всю нагрузку. Ни один отдельный слой не может этого сделать. Утвержденные запросы, которые эксперт-аналитик совершенствовал в течение пяти лет, кодируют бизнес-логику, которую невозможно полностью задокументировать. Слой метаданных фиксирует структуру, но не смысл. Семантический слой фиксирует определения, но не решения, принимаемые в процессе применения этих определений.</p> <p>Эффективный контекстный слой должен одновременно охватывать все эти измерения и поддерживать согласованность между ними по мере независимого развития каждого из них.</p> <p><strong>3. Контекстный слой должен быть архитектурно независим от базовых платформ данных. </strong>Это наиболее важное архитектурное решение, к которому большинство организаций относятся недостаточно серьезно.</p> <p>Когда контекст создается внутри конкретной платформы, будь то облачное хранилище данных, облако-хранилище данных или семантический слой, специфичный для поставщика, он переплетается с проприетарными структурами и API этой платформы. Контекстный слой — это самый ценный интеллектуальный актив, создаваемый организацией, работающей с данными. Он кодирует многолетнюю бизнес-логику, проверенные запросы и институциональные знания. Когда этот актив зависит от платформы, организация теряет свою архитектурную гибкость и переговорные возможности.</p> <p>Ситуацию усугубляет реальность, с которой уже сталкивается большинство предприятий: данные редко хранятся в одном месте. Типичная компания из списка Global 2000 работает в гетерогенной среде: Snowflake для корпоративного хранилища данных, Databricks для рабочих нагрузок анализа данных, Salesforce для CRM, SAP для ERP и длинный хвост унаследованных и ведомственных систем, которые в ближайшее время не будут объединены. Контекстный слой, встроенный в любую из этих платформ, фиксирует то, что видит эта платформа, и ничего больше. Наиболее важные бизнес-вопросы, связывающие показатели выручки с операционными данными и поведением клиентов, требуют контекста, охватывающего все эти аспекты.</p> <p>Таким образом, абстрагирование — это не просто защита от будущих изменений платформы, это единственная архитектура, которая может соответствовать реальности того, как корпоративные данные существуют сегодня. Стеки данных развиваются, миграции происходят, и платформа, оптимальная сегодня, может перестать быть оптимальной через три года. Организации, которые абстрагировали свой контекстный слой, теперь могут обслуживать весь спектр своих данных и осуществлять переход на новые платформы без необходимости начинать все заново, в то время как те, кто этого не сделал, ограничены в обоих измерениях, часто обнаруживая издержки только тогда, когда миграция уже началась.</p> <p><strong>4. Каждый ИИ-агент наследует проблему контекста и усугубляет ее. </strong>Четвертое измерение становится актуальным только сейчас, когда предприятия переходят от "вторых пилотов и чат-ботов к автономным агентам.</p> <p>При использовании копилота в цикле участвует человек. Аналитик читает ответ, выносит суждение, выявляет ошибку. Цикл обратной связи достаточно гибок. Отличительной же характеристикой агентного ИИ является то, что он работает без постоянного контроля со стороны человека. Агенты выполняют запросы, синтезируют данные, генерируют отчеты и запускают последующие рабочие процессы автономно, в масштабе и непрерывно.</p> <p>Эта автономность является ценностным предложением, и именно поэтому высокое качество базового контекстного слоя становится обязательным.</p> <p>Плохо настроенная панель мониторинга выдает неверную цифру одному человеку на одном совещании. Агент, работающий с устаревшим или неполным контекстом, распространяет эту ошибку на десятки нижестоящих систем и решений, прежде чем кто-либо поймет, что что-то пошло не так. Автономия, которая делает агентов ценными, — это то же самое свойство, которое делает плохой контекст таким опасным. Каждый агент, развернутый организацией, заслуживает доверия лишь настолько, насколько хорош контекст, лежащий в его основе, а уверенные, но неверные ответы, предоставляемые со скоростью машины и встроенные в автоматизированные рабочие процессы, представляют собой потенциальный сбой в управлении.</p> <h3>Структура для принятия инвестиционных решений</h3> <p>Для руководителей высшего звена, оценивающих инвестиции в ИИ, стоит задать поставщикам четыре прямых вопроса:</p> <ul> <li><strong> Обучается ли система или требует ручного обслуживания?</strong> Контекстный слой, зависящий от человеческого контроля, будет разрушаться, поэтому стоит конкретно спросить поставщиков, как контекст обновляется с течением времени и какие человеческие усилия требуются для поддержания его точности.</li> <li><strong> Сколько измерений контекста она охватывает?</strong> Решения, которые рассматривают только один слой — метаданные, семантические определения или историю запросов — в отрыве от контекста, следует рассматривать со скептицизмом. Более надежные системы интегрируют несколько измерений контекста и поддерживают их согласованность по мере развития каждого из них.</li> <li><strong> Переносим ли контекст?</strong> Если организации потребуется сменить платформу данных через два года, что произойдет с созданным ею контекстом? Ответ на этот вопрос покажет, насколько сильно в архитектуре заложена стратегическая привязка к поставщику.</li> <li><strong> Какова модель управления агентами?</strong> Перед развертыванием автономных агентов организации должны иметь возможность четко определить, в каком контексте эти агенты работают, как этот контекст проверяется и какие механизмы существуют для обнаружения и исправления ошибок до их распространения.</li> </ul> <h3>Стратегические последствия</h3> <p>Схема, наблюдаемая в успешных внедрениях ИИ на предприятиях, остается неизменной. Организации, создающие долгосрочную ценность, не обязательно обладают самыми большими моделями или наибольшим объемом данных. Это те, кто инвестирует в живой, многомерный, платформенно-независимый контекстный слой и рассматривает его как стратегический актив, а не как деталь реализации.</p> <p>Для предприятий создание и поддержание этого контекстного слоя — это инвестиции в ИИ. Организации, которые осознают это сейчас, получат накопительное преимущество, в то время как те, кто продолжит рассматривать это как второстепенный аспект, окажутся в дорогостоящем и повторяющемся цикле пилотных проектов, которые впечатляют на демонстрациях и разочаровывают в производственной среде.</p> Руководители предприятий потратили два года и сотни миллиардов долларов на искусственный интеллект. Результаты … article https://www.itweek.ru/themes/detail.php?ID=234890 Tue, 26 May 2026 10:25:56 +0300 <p>В GreenData проанализировали восемь классов отечественных бизнес-критичных систем по уровню проникновения low-code. Эксперты выяснили, что low-code в России развивается неравномерно: в процессных системах он стал архитектурным ядром, а в «тяжелых» транзакционных и аналитических системах чаще остается слоем надстройки.</p> <p>В GreenData сравнили зрелость low-code в системах управления бизнес-процессами, продажами и клиентскими отношениями, корпоративными сервисами, ресурсами предприятия, аналитикой, документами, планированием, а также рисками и комплаенсом. В основу оценки легли десять архитектурных слоев: интерфейс, модель данных, бизнес-правила, workflow, интеграции, отчетность, контроль версий, безопасность, DevOps и совместимость обновлений.</p> <p>По каждому слою продуктам присваивалась оценка от 0 (только через код) до 3 (low-code как платформенный слой, пригодный для масштабной разработки без помощи ИТ). Суммарный балл определял уровень зрелости: <nobr>80-100 —</nobr> low-code платформа/работает в платформенной логике, <nobr>55-79 —</nobr> продукт с глубокой настройкой или продукт на low-code платформе; <nobr>30-54 —</nobr> low-code конструктор поверх коробки, а ниже 30 — low-code в основном декларативный. </p> <p>Наиболее зрелыми с точки зрения low-code эксперты назвали BPM-системы: глубину проникновения low code здесь оценили в <nobr>70-85%.</nobr> Практически все заметные игроки рынка уже работают с low-code по платформенной логике. Граница между классическими системами управления бизнес-процессами и LCAP (Low-code Application Platform) размывается.</p> <p>В сегменте ESM/ITSM проникновение low-code оценили в <nobr>60–75%.</nobr> Причем для ESM характерен показатель ближе к верхней границе, для классического ITSM — скорее к середине диапазона. Многие современные российские платформы изначально проектировались с фокусом на low-code. А часть популярных продуктов предлагают широкие возможности настройки, хотя их нельзя назвать классическими LCAP. </p> <p>Близкий уровень зрелости показывают CRM-системы <nobr>(55–70%).</nobr> CRM-сегмент в России активно смещается в сторону платформенной гибкости, но на рынке по-прежнему значительна доля продуктовых, отраслевых и коробочных решений, где low-code присутствует, но не на уровне архитектурного слоя. Наиболее развитые решения российского рынка сильны в сценариях быстрых настроек, smart-процессов, воронок и виджетов, однако, LCAP-платформами не являются. </p> <p>Замыкают список low-code лидеров риск-системы/GRC — здесь уровень проникновения аналитики оценили в <nobr>50-55%.</nobr> В риск-системах low-code используется как базовый механизм адаптации: он востребован для оперативного изменения моделей рисков, контрольных процедур, комплаенс-правил, матриц полномочий и индикаторов риска. У части отечественных продуктов просматривается платформенная логика по правилам, процессам, интеграциям и аудиту. Тем не менее в ряде решений low-code выступает скорее как надстройка, но их можно гибко адаптировать к изменениям регуляторики и внутренних политик. </p> <p>Среди догоняющих — рынок ECM/CSP/СЭД <nobr>(35–50%).</nobr> Low-code здесь активно используется для моделирования маршрутов документов, настройки карточек, бизнес-правил, согласований. Однако в большинстве платформ он все еще остается скорее мощным инструментом конфигурирования и кастомизации, чем полноценным архитектурным ядром. Ядро системы (хранение больших объемов документов, сложный поиск, механизмы версионности) по-прежнему в значительной степени опирается на традиционную разработку. В классических СЭД low-code представлен слабее всего, в ECM — тормозится монолитной архитектурой и сложностью адаптации. Значительно лучше ситуация с CSP, хотя весь сегмент движется в сторону процессов, форм, порталов и гибких настроек.</p> <p>А вот в «тяжелых» транзакционных и аналитических системах картина принципиально иная. В ERP проникновение low-code составляет всего <nobr>5-15%,</nobr> в BI — <nobr>15-30%,</nobr> а в IBP/CPM — <nobr>25-40%.</nobr> В этих классах low-code преимущественно используется как надстройка для self-service аналитики, работы с отчетами и дашбордами, настройки расширений, простых бизнес-правил. При этом он почти не затрагивает ядро: модели данных, сложные расчеты, высоконагруженные транзакции и механизмы обеспечения целостности. </p> <p>В ERP нет убедительных примеров полноценных low-code платформ или low-code конструкторов (класс слишком тяжелый для этого), хотя достаточно много продуктов с глубокой настройкой.</p> <p>Объяснить такой разрыв можно тем, что в ERP, BI и IBP критически высока доля сложной доменной логики, жестких транзакционных зависимостей, детализированных расчетов и глубоко проработанных отраслевых моделей данных. Здесь ошибки обходятся слишком дорого, а требования к надежности, производительности и безопасности значительно выше. Кроме того, в BPM, CRM и ESM/ITSM уже сформировалась культура платформенного подхода, DevOps-практики. В ERP и BI этот переход идет медленнее из-за масштаба внедрений, длительных жизненных циклов проектов и высокой инертности легаси-архитектур.</p> <p>«Российский рынок массово использует термин low-code, но за ним скрываются совершенно разные технологические подходы: от полноценной платформенной разработки бизнес-критичных приложений до кастомизации готовых продуктов. Поэтому ключевой вопрос не в наличии low-code-инструментов, а в глубине их проникновения в архитектуру. И здесь картина крайне неоднородна: в таких классах, как BPM, CRM, ESM/ITSM и риск-системы, low-code уже выступает как базовый архитектурный слой. А вот в ERP, BI и IBP он чаще остается на уровне „надстройки“ или ограничивается лишь визуализацией», — считает Денис Голдобин, управляющий директор-партнер GreenData. </p> <p>В ближайшее время, по прогнозам GreenData, именно преодоление этого разрыва станет главным драйвером развития российского low-code рынка. Вендоры «тяжелых» систем будут постепенно переходить к модульной архитектуре, в которой low-code помогает выстраивать процессы и логику, бизнес-правила и пользовательский опыт, а высоконагруженное ядро по-прежнему останется на специализированных технологиях и классической разработке.</p> В GreenData проанализировали восемь классов отечественных бизнес-критичных систем по уровню проникновения low-code … message https://www.itweek.ru/themes/detail.php?ID=234889 Tue, 26 May 2026 10:25:17 +0300 <p>Клиентам Банка Русский Стандарт из сегмента микро- и малого бизнеса стал доступен функционал Автоматизированной упрощенной системы налогообложения (АУСН), внедренный компанией BSS на базе ее промышленного решения.</p> <p>Банк Русский Стандарт развернул сервис Автоматизированной упрощенной системы налогообложения (АУСН) от компании BSS. Теперь клиенты — предприниматели и малый бизнес — могут подключить новый бездекларационный налоговый режим прямо в Интернет-банке RSB Business Online и управлять им непосредственно в интерфейсе системы дистанционного банковского обслуживания, а передача данных о доходах для расчета налога будет происходить автоматически. Предоставление клиентам возможностей АУСН соответствует стратегии банка по активному развитию цифровых сервисов для бизнеса и расширению каналов взаимодействия.</p> <p>При выборе технологического партнера для внедрения АУСН Банк Русский Стандарт отдал предпочтение экспертизе и опыту компании BSS и ее решению как наиболее функциональному и проверенному на рынке. На сегодняшний день модуль АУСН от BSS уже функционирует в восьми российских банках, включая Банк Русский Стандарт. Все финансовые организации, внедрившие решение BSS, успешно прошли аккредитацию Федеральной налоговой службы и включены в реестр уполномоченных кредитных организаций.</p> <p>Решение BSS, построенное на платформе Digital2Go, представляет собой готовый промышленный тиражируемый российский продукт, не имеющий аналогов на рынке. В отличие от самостоятельной разработки «с нуля» (сроки — от года, бюджет — десятки миллионов рублей), клиенты BSS используют испытанное коробочное решение с тремя ключевыми компонентами: клиентским интерфейсом в ДБО, интеграционным адаптером для обмена данными и аналитической системой для разметки операций и расчета НДФЛ.</p> <p>Клиенты банка получают возможность автоматической передачи транзакций в налоговую службу для расчета налога без представления декларации, а также полный спектр функций для оплаты налогов, передачи сведений о сотрудниках и мониторинга кассовых операций.</p> <p>«Внедрение тиражируемого решения BSS по АУСН в Банке Русский Стандарт еще один успешный кейс решения потребности банка в короткие сроки с гарантированным результатом. Мы предлагаем готовое промышленное решение для использования АУСН в банковском ДБО, полностью протестированное. Наша команда сопровождает банки на всех этапах: от развертывания до прохождения аккредитационных испытаний. Такой подход позволяет нашим партнерам запускать сервис в <nobr>3–5</nobr> раз быстрее и с существенно меньшими затратами по сравнению с собственной разработкой», — подчеркнула Юлия Савинова, руководитель направления по развитию цифровых продуктов Центра цифровых решений для бизнеса компании BSS.</p> <p>Запуск АУСН в Банке Русский Стандарт открывает новые возможности для привлечения и удержания клиентов МСБ: переход на данный налоговый режим возможен исключительно при обслуживании в уполномоченном банке. Решение BSS, доказавшее свою надежность на практике, позиционируется как наиболее предсказуемый путь для финансовых организаций, стремящихся минимизировать риски при прохождении аккредитации.</p> Клиентам Банка Русский Стандарт из сегмента микро- и малого бизнеса стал доступен функционал Автоматизированной … message https://www.itweek.ru/themes/detail.php?ID=234887 Tue, 26 May 2026 09:34:12 +0300 <p><em>Еще два года назад корпоративное внедрение искусственного интеллекта в большинстве российских компаний выглядело скорее экспериментом, чем полноценной бизнес-практикой. Нейросети использовались точечно: маркетологи тестировали генерацию текстов, HR — автоматический подбор резюме, отделы поддержки — чат-ботов с заранее прописанными сценариями.</em></p> <p><em>Сегодня рынок вступает в другую фазу. Компании все чаще рассматривают ИИ не как отдельный инструмент, а как инфраструктурный слой, встроенный в ежедневные процессы. Причина проста: давление на эффективность растет, а количество рутинных операций продолжает увеличиваться.</em></p> <p>На этом фоне бизнес постепенно смещает фокус с демонстрационных сценариев — вроде генерации изображений или маркетинговых текстов — к более прикладным задачам: автоматизации документооборота, управлению знаниями, внутренним консультациям и сокращению операционной нагрузки.</p> <p>Переход от экспериментального использования ИИ к встроенным бизнес-инструментам подтверждается и динамикой рынка. По <a href="https://www.mckinsey.com/capabilities/quantumblack/our-insights/the-state-of-ai">данным McKinsey</a>, в 2025 году уже более 70% компаний в мире использовали искусственный интеллект хотя бы в одной бизнес-функции, а наиболее активно ИИ внедряется в процессы, связанные с клиентским сервисом, маркетингом, аналитикой и управлением знаниями.</p> <p>Особенно заметно этот тренд проявляется в средах с высокой сложностью принятия решений — там, где сотрудники ежедневно работают с большим объемом регламентов, процедур и повторяющихся запросов.</p> <h3>Почему сложные процессы становятся идеальной средой для ИИ</h3> <p>Во многих компаниях значительная часть рабочего времени уходит не на принятие решений, а на поиск информации, сверку нормативных требований, интерпретацию внутренних правил, повторяющиеся консультации и навигацию по системам. Фактически специалист часто становится посредником между сотрудником и корпоративным знанием.</p> <p>Особенно остро эта проблема проявляется в сферах, где ошибки дорого стоят: финансах, логистике, юридической функции, соблюдении нормативных требований и закупках.</p> <p>Закупочная функция — один из наиболее показательных примеров. Работа с закупками, особенно в сегменте регулируемых процедур, требует постоянной работы с нормативной базой, документацией, сроками, техническими требованиями и внутренними регламентами. Даже опытные специалисты регулярно сталкиваются с необходимостью уточнять детали процедур, проверять требования или консультироваться по нестандартным ситуациям.</p> <p>В результате бизнес сталкивается сразу с несколькими издержками:</p> <ul> <li> сотрудники тратят значительное время на поиск информации;</li> <li> возрастает нагрузка на внутреннюю поддержку;</li> <li> новые специалисты дольше проходят адаптацию;</li> <li> ошибки в документации приводят к дополнительным затратам.</li> </ul> <p>Именно в таких процессах ИИ становится особенно полезным, поскольку позволяет работать с объемом информации, который сложно обработать вручную в ограниченные сроки. Алгоритмы способны быстро анализировать документацию, выявлять закономерности, сопоставлять данные и находить потенциальные риски. В отличие от последовательного человеческого анализа, ИИ обрабатывает множество параметров одновременно, что ускоряет подготовку к закупкам и снижает вероятность пропустить важные детали.</p> <h3>От чат-бота к рабочему инструменту</h3> <p>Дискуссия вокруг корпоративного ИИ во многом все еще сводится к чат-ботам, хотя бизнес уже движется в сторону более глубокой интеграции интеллектуальных инструментов в рабочие процессы.</p> <p>Если ранний этап внедрения был связан преимущественно с внешними интерфейсами взаимодействия — отдельными помощниками, работающими по принципу «вопрос — ответ», — то новая модель строится вокруг встроенных ИИ-ассистентов, интегрированных непосредственно в корпоративную среду.</p> <p>Изменение здесь носит не косметический, а архитектурный характер. Искусственный интеллект постепенно становится интерфейсом доступа к корпоративным знаниям, внутренним регламентам и функциональности цифровых систем. ИИ меняет саму логику поиска информации. Раньше сотрудник тратил время на поиск источников и понимание, где именно искать ответ. Теперь система анализирует данные сразу по всему информационному пространству и выдает готовый результат. В этих условиях фокус смещается: важнее становится не поиск как таковой, а умение точно формулировать запросы и проверять корректность ответов, которые предлагает ИИ.</p> <p>Подобная модель уже формируется в CRM-системах, ERP-платформах, корпоративном документообороте и сервисных решениях. Постепенно аналогичный подход распространяется и на более специализированные отраслевые процессы — в том числе на закупочную функцию, где скорость доступа к информации напрямую влияет на качество решений и операционную эффективность.</p> <h3>Как ИИ начинает менять закупки по <nobr>223-ФЗ</nobr></h3> <p>Закупочная функция в сегменте <nobr>223-ФЗ</nobr> долгое время оставалась одной из наиболее сложных сред для интеллектуальной автоматизации. Высокая регуляторная нагрузка, объемная документация и значительная стоимость ошибки ограничивали возможности для масштабного внедрения ИИ в процессах, где ошибка может повлечь нарушение требований или срыв процедуры, бизнес традиционно осторожно относится к автоматизации.</p> <p>Ситуация начала меняться по мере развития корпоративных ИИ-инструментов. Если ранние сценарии ограничивались точечными консультационными сервисами или навигацией пользователей внутри отдельных процедур, то сегодня рынок постепенно движется к более глубокой интеграции интеллектуальных ассистентов непосредственно в рабочую среду закупок.</p> <p>Практический смысл таких решений связан прежде всего с оптимизацией рутинной интеллектуальной работы. Закупочным специалистам ежедневно приходится одновременно учитывать требования законодательства, внутренние регламенты, сроки, закупочную документацию и функциональность электронных систем. Значительная часть времени при этом расходуется на поиск, сверку и интерпретацию информации, а не на принятие решений как таковых.</p> <p>В электронных закупках интеллектуальные ассистенты берут на себя часть рутинной навигации и поддержки пользователя. Они могут объяснить условия закупки, помочь разобраться в требованиях документации, подсказать релевантные сервисы платформы, ответить на вопросы по процедурам и нормативным требованиям, а также быстро находить нужную информацию без ручного поиска по базе знаний или инструкциям. Это меняет сам сценарий взаимодействия с системой: вместо поиска ответа пользователь сразу работает с готовой информацией в контексте своей задачи.</p> <h3>Что получает бизнес на практике</h3> <p>Главный эффект подобных решений заключается не в технологической новизне, а в перераспределении времени сотрудников. Когда специалист перестает тратить часы на поиск информации, повторяющиеся консультации и ручную навигацию по сложным интерфейсам, появляется возможность перераспределить ресурсы в пользу задач с более высокой добавленной стоимостью.</p> <p>На практике компании обычно рассчитывают сразу на несколько эффектов:</p> <ul> <li> сокращение времени поиска информации;</li> <li> ускорение адаптации новых сотрудников;</li> <li> снижение числа типовых ошибок;</li> <li> уменьшение нагрузки на внутреннюю поддержку;</li> <li> более быстрое принятие решений.</li> </ul> <p>Рост интереса бизнеса к ИИ-ассистентам объясняется и экономикой процессов. По разным оценкам, автоматизация повторяющихся интеллектуальных операций позволяет сотрудникам экономить до <nobr>20-30%</nobr> рабочего времени, особенно в функциях с высокой административной нагрузкой. Для компаний это означает не только рост производительности, но и снижение стоимости адаптации новых сотрудников, ускорение внутренних процессов и меньшую зависимость от экспертных знаний отдельных специалистов.</p> <p>Для руководителей это означает заметное снижение зависимости процессов от конкретных сотрудников — особенно в функциях, где накоплен значительный объем внутренней экспертизы. Именно поэтому ИИ-ассистенты уже начинают менять не только рабочие процессы, но и структуру команд. Когда часть рутинных задач автоматизируется, а выполнение операций становится более прозрачным, руководители получают возможность точнее оценивать эффективность работы и реальный вклад сотрудников. В таких условиях спрос смещается в сторону специалистов, чья работа создает более высокую ценность для бизнеса — через экспертизу, принятие решений и контроль качества результатов, в том числе предоставляемых ИИ.</p> <h3>От ассистентов к полуавтоматическим решениям</h3> <p>Текущий этап внедрения ИИ в корпоративные процессы, вероятно, станет промежуточным. Следующий шаг — переход к более активной роли искусственного интеллекта.</p> <p>В закупках это может означать автоматическую подготовку части документации, предварительную проверку соответствия требованиям, рекомендации по процедурам, интеллектуальный поиск рисков и развитие аналитических сценариев.</p> <p>Иными словами, рынок постепенно движется от модели «ИИ отвечает на вопрос» к модели «ИИ помогает выполнять работу».</p> <p>Для бизнеса внедрение ИИ означает не только перераспределение задач, но и изменение требований к персоналу. Когда выполнение процессов становится измеримым, а рутинные операции — автоматизированными, руководители получают более четкое понимание эффективности команд и вклада каждого сотрудника. В таких условиях большую ценность приобретают специалисты, способные работать со сложными задачами, принимать решения и усиливать результат бизнеса, а не выполнять повторяющиеся операции.</p> <p>Именно в прикладных сценариях, где ИИ способен снижать операционную нагрузку, ускорять принятие решений и повышать управляемость процессов, будет определяться его реальная ценность для бизнеса. Вероятно, именно здесь искусственный интеллект окончательно перейдет из категории технологического эксперимента в статус базовой корпоративной инфраструктуры.</p> <p>#IMAGE_234888#</p> Еще два года назад корпоративное внедрение искусственного интеллекта в большинстве российских компаний выглядело скорее … article Дмитрий Чукин, генеральный директор ”Торги223” https://www.itweek.ru/themes/detail.php?ID=234886 Tue, 26 May 2026 09:26:01 +0300 <p><em>Следующий этап развития корпоративного искусственного интеллекта может определяться не столько возможностями моделей, сколько физической инфраструктурой и операционной дисциплиной, необходимыми для его поддержки. В то же время амбиции индустрии ИИ в отношении инфраструктуры начинают сталкиваться с физической реальностью, отмечают опрошенные порталом </em><em>InformationWeek</em> <em>эксперты.</em></p> <p>Опубликованные в последние недели многочисленные отчеты указали на задержки и ограничения, влияющие на расширение мощностей для ИИ, от проблем со строительством дата-центров до растущей обеспокоенности по поводу доступности электроэнергии. Недавний <a href="https://am.jpmorgan.com/wr/en/asset-management/institutional/insights/market-insights/market-updates/on-the-minds-of-investors/energy-infrastructure-ais-power-play/">анализ</a> JPMorgan показал растущее давление на энергетическую инфраструктуру по мере ускорения связанного с ИИ спроса на электроэнергию. Кроме того, юридические споры, задержки с получением разрешений и сложность контрактов все больше замедляют развитие новых дата-центров для ИИ-нагрузок.</p> <p>В то же время крупные технологические компании продолжают увеличивать свои расходы на инфраструктуру ИИ, что подтверждает ожидания того, что спрос предприятий на вычислительные ресурсы также будет продолжать резко расти.</p> <p>Для CIO эту проблему становится все труднее игнорировать. Дискуссия об ИИ сейчас в основном сосредоточена на моделях, приложениях и повышении производительности. Гораздо меньше внимания уделяется инфраструктуре, необходимой для поддержания масштабного внедрения ИИ на предприятиях, а также тому, что произойдет, если эта инфраструктура окажется ограниченной, с задержками или регионально неравномерной.</p> <p>Дэвид Линтикум, основатель Linthicum Research и бывший управляющий директор Deloitte, считает, что отрасль уже сталкивается с «классическим несоответствием между объявленными инвестициями и развертываемыми мощностями».</p> <p>Непосредственный риск заключается не обязательно в резком дефиците мощностей для ИИ. Более вероятен постепенный переход к более ограниченной операционной среде, где инференс становится дороже, доступ менее предсказуемым, а решения о приоритизации все более неизбежными. Эта перспектива уже побуждает некоторых технологических лидеров переосмыслить предположения, лежащие в основе их планов развития ИИ.</p> <h3>Разрыв между инвестициями в ИИ и операционными мощностями</h3> <p>Масштабы инвестиций, направляемых в инфраструктуру ИИ, остаются огромными, при этом гиперскейлеры и поставщики ИИ продолжают тратить миллиарды в погоне за будущим объемом вычислений. Но некоторые эксперты заявляют, что отрасль, возможно, недооценивает, насколько сложно преобразовать капитальные затраты в операционные мощности для ИИ. По их мнению, проблема заключается в том, что масштабирование физической инфраструктуры происходит гораздо медленнее, чем того требует ПО.</p> <p>«Капиталовложения попадают в заголовки новостей, но доступность электроэнергии, получение разрешений, модернизация сетей, вопросы охлаждения, поставка специализированного оборудования и сроки строительства замедляют реальную реализацию, — отмечает Линтикум. — Деньги движутся быстрее, чем инфраструктура».</p> <p>Эдвард Либиг, CEO и CISO Yoink Industries и адъюнкт-профессор Вашингтонского университета в Сент-Луисе, подчеркивает, что проблема выходит за рамки доступности вычислительных ресурсов. «Кривая спроса на инфраструктуру ИИ, похоже, опережает не только строительство дата-центров, но и доступность электроэнергии, охлаждение, масштабируемость межсоединений и операционную интеграцию, необходимые для надежного запуска этих сред», — говорит он.</p> <p>Однако Либиг также предостерегает от того, чтобы рассматривать ограничения инфраструктуры исключительно как проблему ее предоставления. По его мнению, это давление выявляет слабые места в подходах самих предприятий к развертыванию ИИ. «Мы начинаем видеть, как ограничения инфраструктуры выявляют, есть ли у организаций стратегия дисциплинированной работы с ИИ или это просто совокупность разрозненных инициатив в области ИИ, конкурирующих за ресурсы», — говорит он.</p> <p>Это различие может становиться все более важным по мере того, как предприятия расширяют внедрение ИИ в различных отделах. Многие организации одновременно экспериментируют с «вторыми пилотами», рабочими процессами с поддержкой ИИ, аналитическими инструментами, системами поиска и агентными системами, часто без централизованного управления или операционной приоритизации. Либиг описывает результат всего этого как «разрастание ИИ», когда спрос на инфраструктуру растет быстрее, чем измеримая бизнес-ценность. «Организации, наиболее страдающие от нехватки мощностей для ИИ, могут быть не теми, у кого меньше всего инфраструктуры, а теми, у кого меньше всего операционной дисциплины в отношении развертывания ИИ», — говорит он.</p> <h3>Как могут проявляться инфраструктурные ограничения</h3> <p>Не все эксперты считают, что предприятия столкнутся с немедленным кризисом мощностей для ИИ. Дональд Фармер, футуролог из Tranquilla AI, занимает более взвешенную позицию, утверждая, что у многих CIO может быть больше времени, чем кажется. «Мы ожидаем, что основным двигателем внедрения в корпоративной среде станет агентный ИИ, а не генеративный ИИ, — говорит он, ссылаясь на исследование TDWI, которое показывает, что только 31% компаний считают, что внедрение агентного ИИ происходит уже сейчас, тогда как 49% прогнозируют, что это займет от 1 до 5 лет. — Поэтому я подозреваю, что у производства электроэнергии еще есть время для ускорения этого процесса».</p> <p>Фармер также указывает на повышение эффективности как моделей, так и оборудования, что снизит вычислительную нагрузку. Тем не менее, несколько экспертов сходятся во мнении, что ограничения, вероятно, будут возникать неравномерно, при этом средние предприятия могут столкнуться с наибольшим давлением в периоды пиковой нагрузки.</p> <p>«Я подозреваю, что нагрузкам обучения ничего не грозит, — говорит Фармер. — В условиях, когда мощности ограничены, гиперскейлеры, предположительно, будут отдавать приоритет своим собственным рабочим нагрузкам ИИ и своим крупнейшим корпоративным клиентам».</p> <p>Линтикум аналогично формулирует проблему не как явный дефицит, а скорее как периодическую нестабильность. «Самый большой риск заключается не в том, что ИИ не сможет работать, ​​а в том, что доступ станет дороже, будет страдать задержками или будет неравномерным в зависимости от региона и поставщика», — говорит он.</p> <p>Это различие важно, поскольку многие корпоративные стратегии в области ИИ в настоящее время предполагают относительно беспрепятственный доступ к вычислительным ресурсам. Организациям, разрабатывающим планы по быстрому экспериментированию, инференсу в реальном времени и постоянно доступным сервисам ИИ, возможно, потребуется подготовиться к более ограниченной среде, чем они первоначально предполагали.</p> <p>«Один из возникающих рисков заключается в том, что организации могут непреднамеренно выстроить бизнес-процессы, предполагающие бесконечную доступность ИИ и бесконечную скорость обработки инференса, — говорит Либиг. — Физическая инфраструктура может поставить под сомнение это предположение раньше, чем многие ожидают».</p> <h3>Управление ИИ становится инфраструктурной проблемой</h3> <p>Перспектива ограниченных возможностей ИИ также начинает менять дискуссии об управлении и приоритизации.</p> <p>Либиг утверждает, что предприятия, ориентированные на операционную надежность и отказоустойчивость, в конечном итоге могут оказаться в более выгодном положении в периоды давления на инфраструктуру, поскольку они, как правило, более обдуманно расширяют ИИ. Эти компании, как правило, отдают приоритет критически важным для операционной деятельности сценариям использования и расширяют их постепенно после подтверждения ценности, управления и контроля.</p> <p>«Ограниченное расширение создает устойчивость, поскольку организации могут расставлять приоритеты для наиболее важных функций ИИ, когда условия инфраструктуры ужесточаются», — говорит Либиг.</p> <p>Такой подход также меняет то, как CIO оценивают инвестиции в ИИ внутри компании. Центральный вопрос смещается от приобретения дополнительных мощностей для ИИ к определению того, для каких рабочих нагрузок оправдан приоритетный доступ к ограниченной инфраструктуре.</p> <p>Линтикум описывает аналогичную необходимость в операционной дисциплине. Он утверждает, что CIO должны начать разделять инициативы в области ИИ на уровни — критически важные, важные и экспериментальные, — чтобы распределение инфраструктуры стало целенаправленным, а не реактивным. «Предприятия без планов на случай непредвиденных обстоятельств наиболее уязвимы», — говорит он.</p> <p>Этот сдвиг может также заставить организации стать более избирательными в отношении того, где действительно необходимы передовые модели ИИ. Фармер отмечает, что многие предприятия уже добиваются успеха с небольшими локальными моделями, работающими на стандартном оборудовании, особенно в средах, где вопросы управления, соответствия нормативным требованиям или стоимости делают зависимость от облачных технологий менее привлекательной. «Не все должно работать на самой последней и лучшей модели», — говорит он.</p> <h3>Что CIO должны спрашивать у поставщиков сейчас</h3> <p>По мере того, как ограничения инфраструктуры становятся все более очевидными, CIO также должны начать рассматривать возможности ИИ как вопрос устойчивости и непрерывности, а не просто как вопрос закупок, считают эксперты. Чтобы предотвратить потенциальные проблемы, ИТ-руководству нужна ясность в отношении текущих поставок.</p> <p>Линтикум отмечает, что предприятиям необходима от поставщиков гораздо большая прозрачность в отношении того, как управляется дефицит мощностей. «Они должны очень прямо спрашивать о гарантиях пропускной способности, региональной доступности, приоритизации очередей, волатильности цен, вариантах резервирования и переносимости между средами», — говорит он.</p> <p>Фармер также утверждает, что обсуждения должны все больше фокусироваться на операционной надежности, а не на наборе функций. Среди вопросов, которые он предложил CIO задавать поставщикам, есть следующие:</p> <ul> <li> Каковы ваши договорные обязательства по доступности пропускной способности в пиковые периоды?</li> <li> Если я беру на себя обязательства по многолетнему резервированию пропускной способности, что это дает мне с точки зрения приоритета по сравнению с клиентами, использующими ресурсы по запросу?</li> </ul> <p>Либиг идет дальше, утверждая, что CIO должны требовать прозрачности в отношении того, как сами поставщики ведут себя в условиях ограниченного ресурса: «Как определяется приоритетность рабочих нагрузок в пиковые периоды спроса? Могут ли сервисы корректно снижать производительность при росте нагрузки на инфраструктуру? Какие существуют зависимости от общих пулов графических процессоров или сторонних поставщиков моделей?».</p> <p>Эти вопросы отражают более широкие изменения, происходящие в стратегии корпоративного ИИ. Доступность инфраструктуры, которая когда-то рассматривалась в основном как абстрактная проблема гиперскейлеров, все чаще становится операционной зависимостью. При разработке планов развития ИИ для предприятий необходимо учитывать не только то, что они хотят видеть в системах ИИ, но и то, сможет ли базовая инфраструктура надежно поддерживать эти амбиции в масштабе.</p> Следующий этап развития корпоративного искусственного интеллекта может определяться не столько возможностями моделей … article https://www.itweek.ru/themes/detail.php?ID=234884 Mon, 25 May 2026 18:03:16 +0300 <p>Компания Avanpost, российский разработчик решений для управления доступом и защиты цифровых идентичностей, объявляет о запуске облачного сервиса Avanpost Identity Cloud. Открыто публичное тестирование сервиса.</p> <p>Участники программы получают пробный период с доступом ко всем функциям сервиса до 1 сентября — с неограниченным числом пользователей — и возможность выстроить защиту корпоративного доступа: от базовой многофакторной аутентификации до тарифа «E-Passport» без капитальных затрат и длительного внедрения. После окончания пробного периода действуют выгодные условия с тарификацией за пользователя.</p> <h3>Эталонная безопасность облака</h3> <p>Avanpost Identity Cloud создан не как «упрощённый» SaaS, а как продолжение зрелой on-premise практики Avanpost, которой много лет доверяют крупные геораспределённые компании с высокими требованиями к кибербезопасности и отказоустойчивости. Возможности и архитектурные принципы корпоративного решения перенесены в облако без потери уровня защиты.</p> <p>Ключевые архитектурные особенности сервиса:</p> <p>● Изоляция тенантов. Для каждого клиента разворачивается независимый tenant: отдельный контур, база данных и политики доступа. Инциденты, ошибки конфигурации или пиковые нагрузки у одного клиента не влияют на других. Уровень изоляции сопоставим с выделенным on-premise решением, но без затрат на собственную инфраструктуру.</p> <p>● Компонент Access Bridge обеспечивает защищённую интеграцию платформы Identity Cloud с корпоративными системами заказчика, сохраняя полный контроль над данными и периметром безопасности.</p> <p>● Гибкость развёртывания. Решение отличается гибкостью развертывания и адаптируется под любую архитектуру — от централизованной до распределённой в изолированных сегментах.</p> <p>● Непрерывность бизнеса. Поддержка офлайн-аутентификации гарантирует непрерывность бизнес-процессов даже при сбоях связи, а централизованное управление из единой административной консоли значительно упрощает внедрение и эксплуатацию.</p> <p>● Простота внедрения. Централизованное управление через единую административную консоль реализует принцип plug-and-play, исключая необходимость ручной настройки локальных компонентов и значительно упрощая внедрение.</p> <p>● Безопасность. При этом критически важные секреты приложений (LDAP, RADIUS) обрабатываются исключительно внутри контура заказчика и не передаются за его пределы, обеспечивая высокий уровень безопасности.</p> <h3>Поэтапная защита: единая платформа с четырьмя тарифами</h3> <p>Avanpost Identity Cloud построен как ступенчатая модель: любая компания может стартовать с базового второго фактора и без смены платформы дорастать до Zero Trust по мере зрелости и появления новых задач бизнеса.</p> <p>Тарифы:</p> <p><strong>Start</strong>. Быстрый уход от одной только парольной защиты для VPN, веб-приложений и типовых корпоративных сценариев. Поддержка SSO для веб-приложений, широкий набор методов 2FA (Push в мобильный аутентификатор, программный и аппаратный TOTP, аппаратные OTP-токены), интеграция по OpenID Connect, SAML, RADIUS и LDAP, удобный самостоятельный первый вход пользователя.</p> <p><strong>Expert</strong>. Адаптивная и контекстная аутентификация: способ проверки подстраивается под IP-адрес, группу пользователя, сценарий входа и уровень риска. Разные правила для обычных сотрудников, подрядчиков, администраторов и привилегированных учётных записей — с возможностью усиления проверки физическим фактором (аппаратные токены, смарт-карты) для критичных операций. Базовая риск-ориентированная защита и расширенные сценарии аварийного и офлайн-входа.</p> <p><strong>E-passport</strong>. Реализация с Unified SSO — единая защищённая сессия между приложениями, десктоп-приложениями, инфраструктурными и legacy-сценариями. Поддержка аппаратных факторов и электронной подписи, криптографически защищённая сессия, кросс-протокольный SSO.</p> <p><strong>Zero Trust.</strong> Непрерывная проверка доступа с учётом пользователя, устройства, контекста и риска. Идентификация и профилирование устройств, политики доверия, риск-ориентированные решения о доступе, усиление проверки при смене контекста или устройства. Особенно актуально для распределённой работы и BYOD. Самый надёжный доступ к корпоративным ресурсам.</p> <h3>Кому подойдёт сервис</h3> <p>Защита с использованием дополнительных факторов аутентификации и систем единого входа (SSO) становится неотъемлемым элементом базовой кибергигиены современной компании.</p> <p>Сервис Avanpost Identity Cloud ориентирован на широкий круг организаций — от среднего до крупного бизнеса — особенно тех, кто использует гибридные или облачные ИТ-ландшафты.</p> <p>Продукт представляет ценность как для собственников бизнеса, заинтересованных в снижении рисков и защите активов, так и для ИТ- и ИБ-специалистов, отвечающих за надежность инфраструктуры. Отдельное внимание уделено удобству сотрудников: реализован безопасный и интуитивно понятный единый доступ ко всем корпоративным системам, что повышает продуктивность и снижает вероятность ошибок при работе с учетными данными.</p> <p>В рамках программы доступны все функции максимального тарифа, без ограничений по количеству пользователей. С 1 сентября 2026 года доступна выгодная ежемесячная тарификация по уникальным пользователям — оплата осуществляется по факту использования сервиса.</p> <p>«Мы намеренно пошли ’’снизу вверх’’ — от on-premise к облаку, а не наоборот. За годы работы с крупными заказчиками мы хорошо понимаем, какие требования бизнес предъявляет к кибербезопасности, отказоустойчивости и изоляции данных, и заложили это в архитектуру Avanpost Identity Cloud с первого дня. Изоляция тенантов, Access Bridge с защищённым хранением секретов, поддержка корпоративных протоколов в одной точке — всё это отличает enterprise-облако от типового MFA-сервиса. При этом мы хотим, чтобы средний бизнес и привлекаемые в роли подрядчиков компании получили возможность стартовать быстро: поэтому мы открываем пробный период всех функций сервиса. Каждая компания сможет попробовать и выстроить защиту — от базовых механизмов до полноценной модели Zero Trust — на единой платформе», — пояснила Надежда Поленовская, директор партнерского и клиентского маркетинга Avanpost.</p> Компания Avanpost, российский разработчик решений для управления доступом и защиты цифровых идентичностей, объявляет … message https://www.itweek.ru/themes/detail.php?ID=234879 Mon, 25 May 2026 08:58:11 +0300 <p><em>Forrester прогнозирует, что к 2030 г. искусственный интеллект приведет к исчезновению 49% существующих рабочих мест в сфере обслуживания клиентов, пишут в корпоративном блоге вице-президенты и главные аналитики </em><em>Forrester</em> <em>Кейт Леггетт и Лаура Рамос.</em></p> <p>Мы уже видим, как контакт-центры оптимизируют свои организационные структуры, сокращая количество руководителей групп. ИИ берет на себя работу по обучению и планированию. Когда это переход завершится, основная задача человеческого труда сместится от реактивного взаимодействия с клиентами к прямому управлению ИИ, который с ними взаимодействует. Изменятся и выполняемые задачи. В частности:</p> <ul> <li> Руководители службы поддержки клиентов будут использовать ИИ для смещения стратегии в сторону создания ценности для клиента, а не только операционного совершенства. Они будут отвечать за создание большей ценности для клиента и рост доходов. Этот сдвиг уже происходит: согласно последнему отчету Salesforce «State of Service», 85% лиц, принимающих решения, ожидают, что служба поддержки внесет больший вклад в выручку.</li> <li> Деятельность представителей службы поддержки клиентов (customer service representatives, CSR) расширится, и она станет более специализированной. Вместо непосредственного решения запросов клиентов, CSR низшего звена будут управлять командами ИИ-агентов, помогать им решать вопросы, требующие участия человека, и предоставлять ИИ обратную связь для оптимизации его результатов. CSR более высокого звена также будут специализироваться: некоторые займут более технические должности, будут экспертами по политике или возьмут на себя больше обязанностей по управлению взаимоотношениями с клиентами.</li> <li> Операционные роли получат стратегический импульс благодаря помощи ИИ. Инсайты о клиентах, полученные с помощью разговорного ИИ и анализа диалогов, позволят службе поддержки клиентов стимулировать инновации в процессах и продуктах. Команды аналитиков начнут проводить детальный анализ реальной производительности и стоимости операций, вплоть до стоимости автоматизации конкретного намерения.</li> <li> ИТ-роли расширятся для поддержки маховика инноваций, которым движет ИИ. Инструменты low-code сделают настройку и оптимизацию ИИ-агентов доступными для гражданских разработчиков. Это откроет новые «легкие технологические» профессии по созданию ИИ-агентов, а также другие профессии, которые управляют качеством результатов и процессов ИИ. ИИ также сохранит традиционные ИТ-должности, отвечающие за интеграцию инструментов и агентов ИИ в более широкую инфраструктуру обслуживания клиентов, бэк-офис и системы телефонии.</li> </ul> <p> #IMAGE_234880#</p> <h3>Что моделирование Forrester говорит о влиянии ИИ на должностные роли в ближайшие годы</h3> <p>Самые важные вопросы сегодня: какие должности в сфере обслуживания клиентов пострадают больше всего? Как быстро произойдет сокращение этих должностей? И превзойдет ли обычная текучесть кадров способность руководства переквалифицировать или повысить квалификацию оставшихся сотрудников?</p> <p>Forrester проанализировала потенциальное влияние ИИ на организации, занимающиеся обслуживанием клиентов. Мы сделали некоторые предположения о соотношении численности персонала и темпов сокращения. Мы использовали эти данные для создания двух моделей, отражающих сценарии численности персонала на двух- и пятилетнем временных горизонтах. Результаты моделирования выделяют важные изменения, которые руководители служб поддержки клиентов должны учитывать в своих сценариях:</p> <ul> <li> В контакт-центрах с большим объемом работы будет наблюдаться пропорционально большее сокращение персонала. На основе нашего исследования потенциала автоматизации с помощью ИИ мы ожидаем, что организации, обрабатывающие в месяц сотни тысяч запросов и более — как правило, B2C-организации — столкнутся с наибольшим сокращением штата. Организации с меньшим объемом запросов — как правило, из сферы B2B — увидят меньший процент первичных обращений, обработанных ИИ, из-за более длительных рабочих процессов с бóльшим количеством исключений.</li> <li> Руководителям службы поддержки клиентов потребуются новые способы оценки производительности и влияния на клиентов. Для прогнозирования будущих уровней штатного персонала ведущие команды проводят имитационные упражнения, моделирующие увеличение показателей удержания с помощью ИИ при сохранении стабильного объема взаимодействий. Они рассматривают более широкое влияние человеческого взаимодействия на удовлетворенность клиентов, удержание и доход. Они также включают прогнозы заработной платы для определения реальной рентабельности инвестиций в ИИ.</li> </ul> <p>Этот переход в сфере управления персоналом будет невероятно сложным. Вы должны понимать навыки, необходимые для каждой задачи. Используйте эту информацию для переквалификации или повышения квалификации ваших сотрудников. Вам придется активно заниматься управлением изменениями. Вам также придется переосмыслить организационные структуры и ответственность организации за операции, выполняемые ИИ.</p> Forrester прогнозирует, что к 2030 г. искусственный интеллект приведет к исчезновению 49% существующих … article https://www.itweek.ru/themes/detail.php?ID=234878 Mon, 25 May 2026 08:48:44 +0300 <p><em>По мере роста корпоративных проектов в области искусственного интеллекта компаниям необходимо оценить, может ли существующая сетевая инфраструктура поддерживать растущие потребности ИИ. Мэри Шеклет, президент консалтинговой компании Transworld Data, предлагает на портале </em><em>InformationWeek</em> <em>пять шагов, которые помогут руководителям сетевых подразделений подготовиться к рабочим нагрузкам ИИ.</em></p> <p>Предприятия вкладывают значительные средства в инструменты и проекты ИИ, но модернизация сети слишком часто остается вне списка инвестиций. Современные сети были созданы для быстрой обработки транзакций, электронной почты, веб-браузинга, передачи файлов и запросов к базам данных — но смогут ли они справиться с ежедневным использованием ИИ в корпоративных и периферийных теневых сетях, и что теперь должны делать CIO и сетевые администраторы?</p> <h3>Оцените свою текущую сеть</h3> <p>Из-за недостатка эмпирических данных никто точно не знает, как ИИ повлияет на ИТ или сети. С точки зрения сети, ИИ потребует пропускной способности для больших объемов данных, и поскольку подразделения по всей компании, вероятно, будут использовать ИИ в режиме по запросу, сетевому персоналу будет сложно заранее настроить пропускную способность сети и приоритеты среды исполнения на основе регулярного и предсказуемого графика.</p> <p>Вот почему крайне важно каталогизировать и оценить текущие возможности сети. Как работает сеть с точки зрения пропускной способности, задержки, безопасности, надежности, качества обслуживания и сетевого управления? Есть ли узкие места в производительности? Обновлены ли маршрутизаторы, серверы и точки доступа?</p> <p>Проведение оценки сети дает организациям понимание базового уровня, на основе которого они могут планировать модернизацию сети для рабочих нагрузок ИИ.</p> <h3>Пообщайтесь с заинтересованными в ИИ сторонами</h3> <p>Практически само собой разумеется, что почти каждый отдел в организации будет использовать ту или иную форму генеративного ИИ, даже если это всего лишь коммерчески доступная версия ChatGPT. Однако в компании будут подразделения, которые решат пойти гораздо дальше. Они захотят приобрести или создать системы ИИ, которые смогут прогнозировать производительность цепочки поставок, ставить медицинские диагнозы или оценивать финансовые риски.</p> <p>Исторически сложилось так, что бизнес-аналитики и ИТ-разработчики встречались с пользователями на ранних этапах концептуальной разработки проектов, но, учитывая жизненно важную роль, которую сеть будет играть в предоставлении ИИ, сейчас для сетевых администраторов не время оставаться в стороне.</p> <p>Вместо этого они должны настаивать на участии в ранних этапах создания концепции и планирования разработки систем ИИ, поскольку эти проекты, вероятно, потребуют модернизации сети. Им также следует разработать способы объяснения технических требований сети простым языком другим лицам, принимающим решения, чтобы все понимали и были согласны с любыми первоначальными инвестициями в сеть, необходимыми для поддержки ИИ.</p> <h3>Инвестируйте в масштабируемые технологии</h3> <p>Возьмем, к примеру, технологию 5G. К концу 2025 г. она приближалась к 100%-ному покрытию в Северной Америке, но некоторые компании все еще отставали, используя маршрутизаторы и коммутаторы, несовместимые с 5G. Если сети должны быть готовы к ИИ, используемые ими маршрутизаторы и коммутаторы должны, как минимум, поддерживать связь 5G и, в идеале, быть модернизируемыми до 6G, когда она станет доступна.</p> <p>То же самое относится к ПО, которое управляет сетью. Если у существующих поставщиков компании отсутствуют планы по масштабированию своей продукции для ИИ, следует рассмотреть новые масштабируемые продукты. Установленные серверные базы, а также системы хранения данных SAN и NAS также должны быть модернизированы для ИИ.</p> <p>Во всех случаях цель сетевых администраторов состоит в том, чтобы запрашивать обновления технологий, готовых к внедрению ИИ, со сроком службы не менее пяти лет, поскольку никто не хочет через год-два обращаться к высшему руководству с просьбой о новом обновлении.</p> <h3>Рассмотрите облачный подход к ИИ</h3> <p>Один из способов решения проблемы масштабируемости — развертывание ИИ в облаке, где вы можете постепенно масштабировать свои сетевые ресурсы по мере необходимости. Этот подход имеет смысл по двум причинам:</p> <ol> <li> Уже существует опыт масштабирования компаниями своих облачных ресурсов и расходов, который, похоже, приемлем для руководства.</li> <li> Поскольку никто точно не знает, какие ресурсы потребуются для корпоративного ИИ, вы можете масштабировать их вверх или вниз в облаке без риска приобретения сетевых активов, которые вам могут не понадобиться.</li> </ol> <p>Облачный ИИ может быть развернут в виде частного облака для подразделений, которым необходима надежная защита и контроль безопасности для своего ИИ. В облаке компании также имеют возможность разделять ресурсы и расходы с другими. Аналогичным образом, можно масштабировать варианты поддержки ИИ в облаке. Эти варианты варьируются от выбора собственного сетевого персонала для поддержки своей инфраструктуры ИИ в облаке до передачи этой функции облачному провайдеру.</p> <h3>Защитите ИИ</h3> <p>Компаниям, использующим ИИ в нескольких отделах, следует рассмотреть возможность внедрения сетей с нулевым доверием, если у них их еще нет. Сеть с нулевым доверием не предоставит пользователю доступ, если у него отсутствуют необходимые учетные данные и разрешения. Концепция нулевого доверия также включает встроенные возможности аудита, которые автоматически оповещают сетевой персонал при обнаружении добавления, удаления или изменения каких-либо ИТ-активов в сети.</p> <p>Сети с нулевым доверием тесно связаны с надежным управлением идентификацией и доступом пользователей, перемещающихся между локальными и мультиоблачными данными для использования в ИИ. Существует три отдельных технологии управления идентификацией, которые следует рассмотреть сетевым администраторам:</p> <ul> <li> Управление идентификацией и доступом (IAM), которое уже используется на большинстве площадок, администрирует и отслеживает действия пользователей и доступ в локальных сетях.</li> <li> Управление правами доступа к облачной инфраструктуре (CIEM), которое выполняет те же функции, что и IAM, только в облаке.</li> <li> Управление идентификацией и администрированием (IGA), которое выступает в качестве общей структуры и единой панели управления, в рамках которых работают как IAM, так и CIEM.</li> </ul> <h3>Действуйте на опережение</h3> <p>Сетевые администраторы стремятся к упреждающему подходу к ИИ, предоставляя масштабируемые, гибкие и оптимизированные сети, способные выдерживать нагрузки ИИ. В то же время у них мало опыта работы с ИИ и понимания того, как он повлияет на сети.</p> <p>Заблаговременное участие в обсуждениях и проектах, связанных с ИИ, позволяет сетевым администраторам лучше подготовиться к тому, чтобы сеть, предназначенная для обработки и передачи данных с ИИ, соответствовала поставленным задачам.</p> По мере роста корпоративных проектов в области искусственного интеллекта компаниям необходимо оценить, может ли … article https://www.itweek.ru/themes/detail.php?ID=234875 Fri, 22 May 2026 16:18:13 +0300 <p>CICADA8, компания по управлению уязвимостями и цифровыми угрозами в реальном времени, представила масштабное обновление первого в России решения для оценки безопасности подрядчиков и дочерних организаций CICADA8 CyberRating, благодаря которому борьба с атаками через партнеров выходит на новый уровень. Теперь российские компании могут проводить всесторонний автоматизированный аудит контрагентов на базе ИИ, от оценки защищенности внешнего ИТ-периметра до анализа зрелости их внутренних процессов ИБ.</p> <p>Новая версия решения дополнена модулем «Опросы» и технологией интеллектуального анализа на базе искусственного интеллекта, которые позволяют автоматизировать аудит внутренних процессов информационной безопасности подрядчиков, контрагентов и дочерних зависимых обществ. Обновленная платформа CICADA8 CyberRating представляет собой комплексный инструмент, который в режиме единого окна объединяет объективный технический скоринг внешнего периметра, включая автоматизированный интеллектуальный поиск сетевой инфраструктуры (доменов и адресов) с глубоким аудитом внутренних процессов компании. </p> <p>Оценка рисков третьих сторон стала критической необходимостью для бизнеса, что напрямую подтверждается позицией регулятора. В конце 2025 года представители ФСТЭК России официально отнесли отсутствие контроля за подрядчиками к числу самых частых типовых нарушений кибербезопасности. С вступлением в силу нового Приказа ФСТЭК № 117 в марте 2026 года требования к защите инфраструктуры при работе с контрагентами стали обязательными.</p> <p>По оценке аналитиков CICADA8, более трети инцидентов в 2025 году были связаны со взломом партнеров и подрядчиков, имеющих доступ в инфраструктуры заказчиков. Крупные компании, стремящиеся контролировать уровень защищенности своих подрядчиков, обычно ограничиваются мониторингом их внешнего ИТ-периметра. Однако за надежно защищенным периметром может скрываться исключительно формальный подход к защите данных: отсутствие внутренних политик информационной безопасности и управления доступом. </p> <p>До сих пор оценка внутренних процессов партнёров оставалась трудоёмкой и плохо масштабируемой задачей: компании обменивались Excel-таблицами, специалисты вручную выверяли сотни ответов и неделями анализировали десятки страниц нормативных документов. Масштабировать такой процесс было сложно, а управлять им в реальном времени — практически невозможно. Поэтому этот аспект информационной безопасности третьих сторон обычно оставался «слепой зоной».</p> <p>Обновленная платформа CICADA8 CyberRating решает эту проблему, впервые объединяя обе вертикали оценки контрагентов в режиме единого окна. Новый модуль «Опросы» превращает рутинный комплаенс в гибкий, прозрачный и управляемый процесс. Платформа уже содержит готовые анкеты, разработанные на основе лучших мировых практик ИБ, а встроенный конструктор позволяет создать индивидуальный опрос с нуля под специфические требования организации. </p> <p>Пользователи могут формировать смысловые блоки, использовать различные типы вопросов, настраивать ветвление сценариев в зависимости от ответов, а также задавать индивидуальный вес и логику расчёта для каждого параметра. При этом весь операционный цикл — от рассылки анкет и контроля сроков до сбора данных и первичной математической интерпретации результатов — выполняется системой автоматически с помощью технологий искусственного интеллекта.</p> <p>В рамках релиза CICADA8 CyberRating также реализован модуль интеллектуального анализа, который решает главную проблему любого аудита — обработку неструктурированных данных. Искусственный интеллект, встроенный в платформу, способен распознавать и анализировать ответы контрагента, данные в свободной форме, оценивая их смысловую полноту. Модуль выполняет семантический анализ загруженных документов и нормативных актов подрядчика — политик парольной защиты, положений о коммерческой тайне, планов аварийного восстановления — и проверяет их на предмет соответствия корпоративным требованиям заказчика. </p> <p>CICADA8 CyberRating мгновенно выявляет логические нестыковки, после чего формирует карту потенциальных рисков и список экспертных рекомендаций. Компании фактически получают продвинутого аудитора, который за секунды обрабатывает объем информации, на анализ которого у специалистов ранее уходили недели ручного труда.</p> <p>«В совокупности автоматизированное анкетирование, ИИ-аудит документов и непрерывный технический мониторинг внешнего периметра формируют комплексную модель безопасности третьих сторон на 360 градусов. Платформа показывает, как контрагент или дочерняя организация защищены технически, как выстроены его внутренние процессы и насколько зрелыми являются его политики и регламенты. Все результаты сводятся в единый интуитивно понятный интерфейс, позволяющий выстроить полностью управляемый процесс взаимодействия с контрагентами непосредственно в платформе», — рассказал Никита Котиков, руководитель продукта CyberRating CICADA8.</p> CICADA8, компания по управлению уязвимостями и цифровыми угрозами в реальном времени, представила масштабное … message https://www.itweek.ru/themes/detail.php?ID=234873 Fri, 22 May 2026 11:28:42 +0300 <p>Компания Servicepipe, российский разработчик решений для анализа и фильтрации нежелательного трафика, представила обновленную версию адаптивной системы защиты IT-инфраструктуры от DDoS-атак и сетевых угроз DosGate и анализатора сетевого трафика FlowCollector. Новации будут наиболее актуальны для крупнейших игроков российского рынка.</p> <p>В частности, изменилась единая система управления on-premise-продуктами. Обновленный интерфейс органично встраивается в сложившиеся процессы эксплуатации инфраструктуры заказчика: для интеграции продуктов защиты Servicepipe с системами мониторинга и журналирования расширена поддержка SNMP и syslog. Добавлены настройки параметров, получение данных с подконтрольных серверов и отправка уведомлений.</p> <p>Для контроля состояния ресурсов единая система управления отправляет уведомления о критических ошибках и аномалиях. Также теперь в системе управления можно просматривать графики утилизации ресурсов. Это особенно полезно при разборе инцидентов и мониторинге динамики нагрузки.</p> <p>В системе управления реализована поддержка многоуровневой ролевой модели, которая позволяет гранулярно настраивать права доступа.</p> <p>К доступным ранее методам аутентификации LDAP и TACACS+ добавлены AD и RADIUS, с помощью которых администраторы могут связывать группы из корпоративных каталогов с ролями внутри продукта. Это снижает объем ручной настройки прав и упрощает внедрение в enterprise-средах.</p> <p>В системе фильтрации на базе DosGate расширен функционал в части поддержки автономных систем (ASN).</p> <p>«В этом обновлении мы усилили то, что особенно важно для enterprise-заказчиков: мониторинг, уведомления, управление доступом и интеграции с корпоративными системами. Это помогает быстрее реагировать на события и проще встраивать DosGate и FlowCollector в процессы», — отметил директор по продуктам Servicepipe Михаил Хлебунов.</p> Компания Servicepipe, российский разработчик решений для анализа и фильтрации нежелательного трафика, представила … message https://www.itweek.ru/themes/detail.php?ID=234872 Fri, 22 May 2026 11:25:01 +0300 <p>Институт статистических исследований и экономики знаний (ИСИЭЗ) НИУ ВШЭ изучил аспекты цифровой трансформации машиностроения, оценил необходимый для этого ресурсный, в частности кадровый, потенциал организаций отрасли, а также их текущий уровень использования цифровых технологий и перспективный спрос.</p> <p>Большинство обследованных организаций машиностроения (93%) уже используют хотя бы одну цифровую технологию из включенных в мониторинг, а в среднем — пять; наиболее востребованы — станки с ЧПУ и системы цифрового проектирования и моделирования. В среднем каждая третья организация является потенциальным пользователем решений на основе искусственного интеллекта; уровень текущего их применения варьирует в диапазоне от 2,9% (ИИ-агенты) до 14,1% (технологии обработки визуальных данных, включая компьютерное зрение).</p> <p>Внедрение цифровых технологий считают перспективным почти все обследованные предприятия машиностроения (94%); немногим менее половины относят это к своим стратегическим приоритетам (46%) или имеют конкретные планы по внедрению цифровых технологий в ближайшие три года (48%); почти треть (30%) отмечают, что их конкурентоспособность существенно зависит от применения цифровых решений.</p> <p>Затраты на внедрение и использование цифровых технологий у значительной доли обследованных организаций (39%) составляют до 1 млн руб. Инвестиции выше этой отметки и до 50 млн руб. осуществляют 44% предприятий. От 100 млн рублей в год на цифровые решения расходуют чуть более 7% обследованных организаций, среди крупных — такой бюджет примерно у 12% компаний.</p> <p>Нехватку финансовых ресурсов, необходимых для комплексной модернизации производственного оборудования и реализации проектов по внедрению новых технологий, предприятия машиностроения чаще всего называли ключевым барьером цифровизации (57%). Второй по важности ресурсный барьер — длительные сроки окупаемости таких проектов. Кадровые ограничения связаны в первую очередь с дефицитом специалистов гибридных профессий, высококвалифицированных рабочих, инженерно-технических кадров и ИКТ-специалистов.</p> <p>Большинство обследованных компаний (80%) оценили уровень цифровых навыков своих сотрудников как релевантный для выполнения текущих обязанностей. Примерно в каждой третьей уровень компетенций специалистов, занятых в разработке и производстве, назвали достаточным для работы со всеми цифровыми технологиями, используемыми в производственном процессе, а также позволяющим осваивать новые.</p> <p>На рынке труда по-прежнему доминирует модель, при которой специалисты обладают либо глубокой отраслевой экспертизой, либо развитыми ИТ-навыками. Обследованные компании машиностроения, особенно крупные, стремятся создать благоприятную среду для развития кадрового потенциала и совершенствования цифровых навыков своих сотрудников. Так, на постоянное их развитие нацелены более чем в половине обследованных организаций; еще в 42% — их наличие учитывают при принятии кадровых решений.</p> Институт статистических исследований и экономики знаний (ИСИЭЗ) НИУ ВШЭ изучил аспекты цифровой трансформации … message https://www.itweek.ru/themes/detail.php?ID=234871 Fri, 22 May 2026 11:21:27 +0300 <p>В 2026 году облачная инфраструктура не просто оптимизирует затраты — она трансформирует их в стратегические инвестиции. Переход от статических мощностей к эластичным сервисам, от изолированных ИТ-отделов к кросс-функциональным продуктовым командам меняет базовую экономику цифрового бизнеса. Владимир Лебедев, директор по развитию бизнеса сервис-провайдера M1Cloud, рассказал, что сегодня облако дает не просто виртуальные машины, а финансовый рычаг: возможность масштабировать успех, гасить риски на ранних стадиях и направлять капитал туда, где создается реальная ценность.</p> <p>Уже несколько лет как ИТ-расходы перестали быть переменными, привязанными к фактической нагрузке и к гипотетическим сценариям. Облако заменило эту неопределенность моделью pay-as-you-go. Но дело не только в смене типа затрат. Это смена финансовой модели: бюджет ИТ трансформировался в управляемый портфель сервисов с прозрачной юнит-экономикой. Организации получают возможность масштабироваться без кассовых разрывов, замораживать излишки и перенаправлять высвободившийся капитал в R&D, маркетинг или новые цифровые продукты.</p> <p>Финансовая выгода облака не ограничивается снижением совокупной стоимости владения. Ключевой эффект — радикальное ускорение time-to-market. Когда развертывание среды занимает минуты, а не месяцы, циклы разработки сокращаются в разы. Это напрямую влияет на денежный поток: продукты раньше выходят на рынок, раньше начинают приносить выручку, раньше окупаются. Кроме того, облачная архитектура позволяет экспериментировать с минимальным финансовым риском. A/B-тестирование, пилотные запуски, MVP — все это становится экономически оправданным, поскольку стоимость ошибки стремится к нулю. В таких условиях ИТ-бюджет превращается во внутренний венчурный портфель: каждый сервис оценивается по contribution margin, а не по стоимости железа. Именно так рождаются цифровые продукты, которые генерируют новую выручку, а не просто поддерживают legacy-процессы.</p> <p>В долгосрочной перспективе облачная инфраструктура становится фундаментом для AI/ML-работ, обработки больших данных и гипермасштабной автоматизации — направлений, где стоимость простоя или нехватки вычислительных ресурсов измеряется десятками миллионов рублей. Инвестиции в облако сегодня — это страховой полис от технологического отставания завтра.</p> <p>Гибкость облака порождает новую управленческую задачу: как не превратить свободу масштабирования в неконтролируемые расходы. Ответом стала методология FinOps. Это не просто отчеты с данными мониторинга, а кросс-функциональная практика, объединяющая инженеров, финансистов и бизнес-лидеров. FinOps вводит культуру осознанного потребления: автоматические политики остановки неиспользуемых ресурсов, резервирование мощностей с дисконтом, тегирование затрат по продуктам и командам, сценарный анализ. В зрелых облачных средах <nobr>20–35%</nobr> экономии достигается именно за счет финансовой оптимизации, а не самой миграции. Это про максимизацию ценности. Когда каждая команда видит стоимость своих ресурсов в реальном времени, принятие решений смещается с технического на бизнесовое. ИТ-менеджеры начинают отвечать не за «аптайм», а за ROI цифровой инициативы.</p> <p>Переход в облако традиционно вызывает вопросы к безопасности, соответствии регуляторным требованиям и зависимости от провайдера.</p> <p>Однако современные облачные платформы предлагают встроенные механизмы шифрования, детальные аудит-логи, сертифицированные среды под требования <nobr>152-ФЗ,</nobr> ФСТЭК, PCI DSS. Это снижает затраты на внутреннюю ИБ-инфраструктуру и ускоряет прохождение проверок. </p> <p>В 2026 году финансовая модель цифрового бизнеса теперь строится на эластичности, прозрачности и скорости. В эпоху, когда конкурентное преимущество определяется скоростью адаптации, переход от затрат к инвестициям — это условие устойчивого роста и долгосрочной рентабельности.</p> В 2026 году облачная инфраструктура не просто оптимизирует затраты — она трансформирует … message https://www.itweek.ru/themes/detail.php?ID=234869 Fri, 22 May 2026 09:29:33 +0300 <p><em>В технической поддержке программного обеспечения не всегда получается строго следовать алгоритмам: в зависимости от ситуации могут требоваться глубокие технические знания, развитая эмпатия или их сочетание. С одной стороны, нужно разобраться в сетях, протоколах и ошибках. С другой — услышать клиента, понять его реальную боль, иногда успокоить и объяснить сложное простыми словами. Рассмотрим, как найти баланс между автоматизацией и живым участием специалистов поддержки.</em></p> <p>Когда количество обращений небольшое, возможно собрать сильную команду, которая закроет все задачи бизнеса. Но при масштабировании становится все сложнее набирать сотрудников поддержки, которые будут одинаково сильны и в технических вопросах, и в эмпатии.</p> <p>Иногда компании готовы жертвовать качеством ответов и привлекать сторонние команды, увеличивая количество обработанных обращений. Это удобное, но не всегда эффективное решение. У внешних специалистов могут быть отличные навыки коммуникации, но недостаток экспертизы и технических знаний. Клиенты быстро получают типовые ответы по шаблону, но любое отклонение от сценария требует обращения к более опытным сотрудникам.</p> <p>Специалисты с глубокой технической экспертизой тоже не всегда встраиваются в рабочие процессы. Они могут перехватывать заявки с более рядовыми вопросами и конкурировать со штатными сотрудниками за пользователя, что приводит к «битве за обращения». Конкуренция между внутренней и внешней командами снижает качество поддержки.</p> <p>Сегодня все актуальнее становится путь автоматизации и увеличения мощностей без расширения команды за счет подключения искусственного интеллекта. Полностью передавать коммуникацию AI-ассистентам не стоит: это отсекает эмпатию и может приводить к потере «человеческого лица» технической поддержки. Более удачным решением сочетания ИИ и работы специалистов поддержки может стать гибридный подход.</p> <h3>Как выстроить архитектуру работы сотрудников и бота</h3> <p>Реальный сотрудник всегда является главным звеном технической поддержки. Искусственный интеллект не заменяет его, а снимает часть рутинных задач:</p> <ul> <li> проводит первичную классификацию обращений;</li> <li> ищет решения в базе знаний;</li> <li> автоматически заполняет карточки инцидентов.</li> </ul> <p>Операторы лучше ориентируются в потоке обращений и уделяют больше внимания сложным, нетиповым запросам. При этом ИИ может анализировать тональность сообщения и сигнализировать, что требуется более оперативный ответ.</p> <p>Правильное совмещение выглядит так:</p> <ul> <li> бот обрабатывает простые, повторяющиеся запросы: сброс пароля, проверка статуса, ссылка на инструкцию;</li> <li> сложные, нестандартные или эмоционально окрашенные обращения передаются оператору;</li> <li> ИИ выступает помощником пользователя: дает подсказки по диагностике, поддерживает быстрый поиск по документации, отвечает на типовые запросы по встроенному шаблону.</li> </ul> <p>В такой гибридной схеме сотрудник тратит меньше времени на рядовые задачи и может сосредоточиться на важном.</p> <h3>Что не стоит делегировать искусственному интеллекту</h3> <p>Успешная интеграция ИИ в систему поддержки возможна, когда внутри команды выстроена система обработки обращений.</p> <p>Приоритет операторов — срочные запросы, например телефонные звонки или помощь в подключении к онлайн-мероприятиям. При этом типовые заявки в чатах чаще можно закрыть при помощи ИИ с минимальным подключением сотрудников. Бот подключается к базе данных компании, отвечает даже ночью и может сократить время обратной связи до одной минуты. Практика показывает, что такой подход позволяет вдвое сокращать очередь диалогов с техподдержкой и решать до 30% запросов без участия человека.</p> <p>Соотношение человеческого и машинного участия зависит от специфики компании. Для технически сложных продуктов требуется больше живых специалистов, которые способны понять контекст. Искусственный интеллект может выступать фильтром и ассистентом, заниматься аналитикой входящих обращений, собирать обратную связь и пожелания. Если ниша более простая и участие операторов требуется только в нетиповых кейсах, ИИ закроет большую часть вопросов самостоятельно.</p> <p>Умеренное внедрение искусственного интеллекта помогает увеличивать количество и скорость ответов техподдержки, не снижая качества. Но машина не заменяет реального сотрудника, а лишь дополняет. Человеческий ресурс все еще остается важен в вопросах, которые требуют нетипового мышления и эмпатии.</p> <p>#IMAGE_234870#</p> В технической поддержке программного обеспечения не всегда получается строго следовать алгоритмам: в зависимости … article Екатерина Аверичева, руководитель департамента технической поддержки “МТС Линк” https://www.itweek.ru/themes/detail.php?ID=234868 Fri, 22 May 2026 08:14:44 +0300 <p>Обнародованы итоги ежегодного панельного исследования Монитор технологий — 2025. Основные выводы исследования:</p> <p>• ИТ- рынок в 2025 году вырос на <nobr>3-8%,</nobr> средний рост выручки вендоров — 22% (41% по итогам 2024 года)</p> <p>• 78% вендоров отмечают формирование конкурентной среды (69% в 2024 году и 52% в 2023).</p> <p>• <nobr>2025-й —</nobr> начало эры результатов в ИТ. 92% опрошенных имеют дорожную карту цифровой трансформации (ЦТ) и отлаженные процессы.</p> <p>• 31% компаний использует продукты Open Source, сохраняя зависимость от открытого ПО. 20% опрошенных относится к Open Source негативно по идеологическим причинам</p> <p>• 34,9% потребителей считают функционал главным критерием выбора ИТ-решений (14,9% в 2024 году)</p> <p>• 29% отечественных вендоров не опасается возвращения западных (15% в 2024 году)</p> <p>• Увеличивается доля выручки, которую крупные вендоры получают от внутренних заказов — это снижает стимулы для создания продуктов мирового уровня.</p> <p>• Потенциал рынка не обеспечивает покрытие инвестиций в отрасль. 38% опрошенных вендоров указали на нехватку рынка для их продуктов (28% по итогам 2024 года)</p> <p>• 79% вендоров готовятся к изменению структуры ИТ-рынка. К 2028 году количество ИТ компаний может сократится вдвое, а экосистемные вендоры увеличат свою долю на 25%.</p> <p>• В <nobr>2025-м</nobr> изменился взгляд на информационную безопасность: вендоры из сегмента ИБ сместили многих крупных игроков. Рынок ждет прорывных решений для усиления технологической независимости.</p> <p>• 20% респондентов считает, что вендоры необоснованно завышают стоимость продуктов и практикуют дифференцированный подход к клиентам.</p> <p>• Вендоры заняты изменениями на уровне технологий архитектуры своих решений, чтобы удовлетворить запросы бизнес-пользователей с точки зрения самостоятельного развития и конфигурирования продукта.</p> <p>• 29% вендоров ждут от государства сохранения существующих льгот (2024 год — 42%)</p> <p>• Более 50% вендоров вышли или планируют выйти на зарубежные рынки (39% в 2024 году и 28% в <nobr>2023-м),</nobr> однако доля продаж на них не превышает 10% (среднее 2%).</p> <p>«<em>Впервые за четыре года исследования Монитор технологий мы фиксируем не просто смену драйвера, мы являемся свидетелями формирования тренда на инверсию полюсов между цифровой трансформацией и импортозамещением. Если ранее, начиная с 2022 года, импортозамещение было драйвером цифровой трансформации, который заставлял пересматривать организационные процессы, участвовать топ-менеджмент во внедрении отечественных решений, то теперь ЦТ становится драйвером импортозамещения. Вопрос „что заменить?“ сменился вопросом „как мы хотим развиваться?“. И уже в ответе на него игроки приходят к использованию отечественного ПО как к естественному, а не вынужденному выбору. И если раньше импортозамещение задавало темп, диктовало повестку, формировало рынок, не всегда оптимально, то теперь оно становится правилами игры — технической нормой, обеспечивающей совместимость, поддержку и развитие ИТ-ландшафтов. Отечественный ИТ-рынок переходит от реактивной позиции к формированию внутренней логики развития.</em></p> <p><em>При этом 39% компаний внедрили метрики эффективности цифровой трансформации. Связка „цифровая трансформацию = автоматизация + процессы“ разваливается, поскольку автоматизация без переосмысления процессов начала тормозить, а не ускорять цифровую трансформацию (23% респондентов).</em></p> <p><em>Импортозамещение пока не закончилось, оно по-прежнему драйвер роста рынка, как минимум, на ближайшие годы (39% респондентов). Но лидерство перешло к цифровой трансформации как к осознанному, управляемому и измеримому процессу (47% респондентов). Это начало эры, где ЦТ определяет изменения, а импортозамещение становится инструментарием этих изменений», — прокомментировал лидер аналитического проекта Монитор технологий, директор по развитию и цифровой трансформации РДТЕХ Евгений Осьминин.</em></p> <p>Исследование прошло с ноября 2025 года по февраль 2026 включительно. Аналитики провели интервью с более чем 50 ИТ-руководителями, 20 HRD, порядка 100 представителями ИТ-служб компаний из самых разных сфер экономики, 20 отечественными вендорами.</p> Обнародованы итоги ежегодного панельного исследования Монитор технологий — 2025. Основные выводы исследования: • ИТ- рынок … message https://www.itweek.ru/themes/detail.php?ID=234844 Fri, 22 May 2026 00:00:00 +0300 <p><em>В 2026 году рынок мобильных финтех-приложений достиг стадии зрелости. Базовая функциональность перестала быть конкурентным преимуществом и превратилась в обязательный стандарт. </em><em>Рассмотрим</em><em>, с какими вызовами сталкиваются банки сегодня и какие тренды определяют развитие отрасли.</em></p> <h3>Вызов, к которому рынок оказался не готов</h3> <p>Нестабильный интернет — проблема, с которой сегодня сталкиваются все отрасли. Однако в финтехе она превратилась в архитектурный тупик. Оказалось, что текущая инфраструктура банков в большинстве своем не умеет работать без надежной связи.</p> <p>Причина находится в специфике банковских сервисов. В других типах приложений часть функций можно вынести в офлайн: сохранить данные на устройстве, дать пользователю базовый доступ без соединения и синхронизировать всё позже. В банкинге такой подход не работает. Локальное хранение данных повышает риски, а проведение операций требует постоянной верификации.</p> <p>Без стабильной связи мобильный банк перестает быть надежным. Пользователь теряет доступ к счетам, а банк не может предложить безопасный офлайн-сценарий.</p> <p>Проблема нестабильного интернета уже влияет на продуктовые решения и заставляет пересматривать архитектуру, когда система может корректно работать с временными локальными состояниями, ограниченными сценариями и последующей синхронизацией.</p> <p>Для продуктовых и технических команд это означает необходимость проектировать сервисы с учетом нестабильного соединения и решать задачи управления локальными данными и их консистентностью, предотвращения дублирующих операций и контроля рисков при отложенной обработке. Рекомендуем закладывать fallback-сценарии на этапе планирования и приоритизировать критические функции. Заранее определять, какие пользовательские действия должны оставаться доступными даже при ограниченной связи. Устойчивость к новым условиям становится не дополнительной функцией, а базовым требованием к архитектуре.</p> <h3>Супераппы: рост сложности как новая норма</h3> <p>Сегодня банки идут не по пути упрощения, а в сторону расширения функциональности.</p> <p>Устойчивым трендом последних лет остаются супераппы. Банки объединяют в одном приложении финансовые и нефинансовые сервисы — покупки, доставку, путешествия, сервисы для автомобилистов.</p> <p>Логика лидеров рынка проста: чем больше сервисов собрано под одной иконкой, тем чаще пользователь возвращается в приложение. За счет этого банки встраиваются в ежедневную рутину клиента. Время в приложении растет, а вместе с ним — лояльность пользователей.</p> <p>Масштабирование до супераппа неизбежно усложняет продукт. Пользователь, открывая приложение, должен сразу понимать, зачем ему доставка, путешествия и другие сервисы. Без хорошего онбординга приложение превратится в нагромождение непонятных сервисов.</p> <p>Одновременно растет и сложность системы: чем больше функционала, тем больше точек падения и зон риска, особенно если между элементами есть множество взаимосвязей.</p> <p>Справляться с растущей сложностью помогает модульная архитектура.</p> <p>Многие банки используют системы библиотек, которые позволяют быстро пересобирать приложение под новые задачи. Кроссплатформенная разработка также ускоряет процессы. Технология Kotlin Multiplatform (KMP) позволяет создавать приложения сразу для нескольких операционных систем — Android, iOS, а также десктопных платформ.</p> <p>Для продуктовых команд ключевой задачей становится управление логикой решения: четкая модульная архитектура, жесткая приоритизация сценариев, контроль связей между сервисами. Особое внимание следует уделять онбордингу и навигации, чтобы пользователь за короткое время понимал, как использовать новые сценарии внутри приложения.</p> <h3>Встроенные банки внутри маркетплейсов</h3> <p>Параллельно с развитием супераппов формируется тренд на встроенные банки внутри маркетплейсов. Банковские сервисы встраиваются в экосистему, где у пользователя уже есть накопленный опыт и данные.</p> <p>В перспективе ближайших пяти лет конкуренция между классическими банками и финтех-игроками в мобильной среде будет усиливаться за счет появления новых банков, созданных крупными экосистемами. Уровень доверия к таким продуктам изначально выше благодаря уже сформированному пользовательскому опыту взаимодействия с брендом. Основное соперничество сместится в сторону дополнительной ценности для пользователя: выиграют те решения, которые смогут предложить более выгодные сценарии, расширенный функционал и органичную интеграцию финансовых сервисов в повседневные цифровые привычки.</p> <p>С технической точки зрения усложняется сама среда: растет число интеграций, появляется необходимость четко разграничивать ответственность между системами и обеспечивать согласованность операций в распределенной архитектуре. В этих условиях продукт уже нельзя разрабатывать как изолированное приложение. Он должен проектироваться как встраиваемый слой, подключаться к пользовательскому сценарию и принимать решения в момент действия. При этом критично закладывать отказоустойчивость, чтобы сбои не разрывали основной процесс, и сокращать путь пользователя до одного-двух действий.</p> <h3>Биометрия и новые технологии безопасности</h3> <p>Сегодня изменяются не только продуктовые модели. Активно развиваются технологии, влияющие на безопасность и пользовательский опыт. Мобильные банковские приложения и платформы МФО все чаще используют биометрическую идентификацию не только для входа, но и для подтверждения операций, включая переводы и оформление займов. Биометрическая идентификация становится базовой частью цифрового продукта, и это уже не только рыночный тренд, но и требование регулятора. При этом характер угроз также меняется: все чаще пользователи сами инициируют переводы под действием мошенников. Поэтому анализа транзакций и классической биометрии становится недостаточно: фокус аналитики смещается с самой операции на поведение пользователя в момент ее совершения.</p> <p>Банки и МФО начинают применять поведенческую биометрию непосредственно в мобильном приложении: последовательность действий в интерфейсе, темп ввода, наклон устройства, использование телефона во время звонка и другие сценарии становятся маркерами риска.</p> <p>На практике это требует точной настройки поведенческих сигналов, сценарной логики реакции и порогов риска: система должна вовремя остановить подозрительное действие, но не мешать обычному пользователю. Такой баланс нельзя собрать шаблонно, он требует глубокой проработки мобильной архитектуры, антифрод-логики и пользовательского пути одновременно.</p> <h3>Заключение</h3> <p>Три тренда — супераппы, банки внутри сервисов и биометрия — меняют требования к тому, как должны проектироваться банковские приложения. Продукты становятся сложнее, количество сценариев растет, а требования к архитектуре усиливаются. На первый план выходят гибкость, устойчивость к внешним ограничениям и способность быстро адаптироваться. Именно эти факторы в ближайшие годы будут определять конкурентоспособность мобильных банковских приложений.</p> <p>#IMAGE_234845#</p> В 2026 году рынок мобильных финтех-приложений достиг стадии зрелости. Базовая функциональность перестала быть конкурентным … article Алексей Артамонов, директор Nord Clan https://www.itweek.ru/themes/detail.php?ID=234834 Fri, 22 May 2026 00:00:00 +0300 <p><em>Организации могут выбирать между искусственным интеллектом, встроенным в основные корпоративные системы, или автономными приложениями ИИ, и те, кто использует встроенный ИИ, сообщают о большей экономии времени. Таков вывод из опроса </em><em>Workday</em> <em>«</em><em>The</em> <em>Copy</em><em>/</em><em>Paste</em> <em>Economy</em><em>: </em><em>Why</em> <em>Task</em><em>-</em><em>Oriented</em> <em>AI</em> <em>is</em> <em>Failing</em> <em>the</em> <em>Enterprise</em><em>», охватившего 6100 специалистов в области финансов, управления персоналом, ИТ и операций по всему миру, все из которых активно используют ИИ в организациях с численностью сотрудников более 500 человек, сообщает портал </em><em>No</em> <em>Jitter</em><em>.</em></p> <p>Основные данные отчета:</p> <ul> <li> 27% организаций встроили ИИ непосредственно в свои основные рабочие процессы;</li> <li> остальные 73% организаций используют автономные системы ИИ, работающих параллельно с основными корпоративными системами (HCM, финансы, планирование, закупки, ITSM и др.). В этих автономных системах ИИ используется для таких задач, как составление черновиков, обобщение и ответы на вопросы;</li> <li> среди организаций, в которых ИИ встроен в основные системы, 60% сотрудников сообщают об экономии времени на 25% и более при выполнении задач. Когда ИИ находится вне основных систем, менее четверти сотрудников заявили, что экономят столько времени. Когда ИИ интегрирован в основную систему, наиболее распространенные варианты использования включают проактивную поддержку принятия решений, адаптацию новых сотрудников и составление бюджета.</li> </ul> <p>В отчете Workday выделены два основных этапа освоения ИИ: пилотное внедрение и масштабирование. 27% организаций, встроивших ИИ в основные системы, находятся на обоих этапах, но «в основном встраивание сосредоточено в организациях, занимающихся масштабированием: 36% организаций, масштабирующих ИИ, сообщают о его глубокой интеграции по сравнению с 14% тех, кто все еще находится на этапе пилотного внедрения, — говорит представитель Workday. — Встраивание ускоряется по мере перехода организаций от пилотного внедрения к масштабированию, но оно не является исключительным ни для одного из этапов».</p> <p>Каждый пятый респондент опроса сообщил, что теряет более семи часов в неделю на ручные задачи, такие как перемещение информации между системами, повторный ввод одной и той же информации в разные системы, согласование противоречивых данных и получение разрешений. Показатель потерянного из-за различных проблем времени отличается от процента времени, сэкономленного на задачах с использованием ИИ, поэтому на основе данного опроса невозможно рассчитать чистую экономию времени, заявляют в Workday. Однако, по оценкам авторов исследования, по состоянию на январь 2026 г. 85% сотрудников экономили от одного до семи часов в неделю благодаря использованию ИИ.</p> <p>Наибольшие препятствия для внедрения ИИ различаются в зависимости от бизнес-функции. Например, ИТ-службы назвали ключевым препятствием накладные расходы на управление: 30% указали на необходимость слишком большого количества согласований/проверок. «Службы операций акцентировали внимание на качестве данных (27%), а кадровые службы — на жестких системах, препятствующих использованию ИИ-инсайтов (26%)», — говорится в отчете.</p> Организации могут выбирать между искусственным интеллектом, встроенным в основные корпоративные системы, или автономными … article https://www.itweek.ru/themes/detail.php?ID=234866 Thu, 21 May 2026 12:46:46 +0300 <p><em>В рамках проведенного в апреле-мае 2026 года исследования корпоративная платформа </em><em>CaseStudy.Techart изучила, как сотрудники российских компаний соблюдают правила цифровой гигиены в повседневной работе. В основу анализа легли ответы на вопросы, связанные с управлением паролями, использованием корпоративных ресурсов, проверкой писем, удаленным доступом и соблюдением базовых требований информационной безопасности.</em></p> <p>Полученные результаты показывают характерную для корпоративной среды ситуацию: сотрудники в целом понимают базовые требования к цифровой безопасности, однако на практике многие по-прежнему допускают действия, способные создавать риски для компании.</p> <p>Наиболее устойчивыми оказались привычки, связанные с формальными регламентами. Так, 96% участников используют для передачи документов только разрешенные корпоративные каналы и почту. Еще 87% сообщили, что их рабочие устройства автоматически блокируются при уходе с рабочего места. Это говорит о том, что организационные меры и технические ограничения действительно формируют дисциплину сотрудников — особенно в вопросах, которые регулярно контролируются внутри компании.</p> <p>Одновременно исследование показало, что наиболее проблемной зоной остается управление паролями. У 78% респондентов есть пароли короче 12 символов, а 61% признают, что используют одинаковые комбинации для разных сервисов. При этом лишь 35% сотрудников работают с менеджерами паролей. Такая статистика хорошо отражает одну из ключевых проблем корпоративной безопасности: даже при наличии политик и инструкций сотрудники продолжают выбирать удобство вместо устойчивых практик защиты.</p> <p>Отдельного внимания заслуживает отношение к передаче доступа. Около 30% участников готовы поделиться своим доступом к корпоративной системе с коллегами. Формально подобные действия часто воспринимаются как «рабочая помощь», однако именно они делают невозможным полноценный контроль действий пользователей внутри инфраструктуры компании.</p> <p>Исследование также зафиксировало неоднозначную ситуацию вокруг удаленной работы и использованием личных устройств. Почти 40% респондентов работают с корпоративными ресурсами со своих личных устройств, а VPN при удаленном подключении используют только 57% сотрудников. Эти цифры особенно показательны на фоне роста гибридных форматов работы: компании активно расширяют доступность сервисов вне офиса, но далеко не всегда успевают сформировать у сотрудников устойчивые привычки безопасного подключения. Порой и сами компании зачастую не предлагают надлежащие механизмы, не разъясняют как ими пользоваться.</p> <p>С электронной почтой ситуация выглядит более стабильной, хотя и здесь сохраняются потенциальные риски. Около 74% сотрудников проверяют адреса получателей перед отправкой писем, а 91% не открывают вложения и ссылки без проверки отправителя. Это свидетельствует о том, что тема здоровой осмотрительности в вопросах фишинга постепенно становится частью корпоративной культуры. Однако даже оставшиеся 9% пользователей, склонные открывать подозрительные вложения, представляют серьезную угрозу для бизнеса: в реальной практике одной ошибки достаточно для компрометации всей внутренней инфраструктуры.</p> <p>Интересно, что наиболее «видимые» нарушения встречаются сравнительно редко. Только 13% участников признались, что хранят стикеры с логинами и паролями рядом с рабочим местом. Еще несколько лет назад подобная практика воспринималась почти как норма офисной среды. Сегодня сотрудники стали осторожнее в вопросах физической безопасности данных, однако цифровые привычки меняются заметно медленнее.</p> <p>В целом результаты исследования показывают, что корпоративная цифровая гигиена даже сегодня находится в переходной стадии. Большинство сотрудников уже знакомы с базовыми принципами информационной безопасности, но эти знания не всегда превращаются в устойчивое поведение. Наиболее уязвимыми остаются именно повседневные сценарии — повторное использование паролей, работа с личных устройств, передача доступов и отказ (возможно по незнанию или сложно) от дополнительных инструментов защиты.</p> <p>Для компаний это означает, что одних регламентов и эпизодического обучения сегодня недостаточно. Эффективная цифровая гигиена формируется не через формальный инструктаж, а через регулярную практику и осознание сотрудниками в реальных сценариев киберугроз. Именно на стыке технологий и поведенческих привычек сегодня проходит основная линия защиты корпоративной инфраструктуры.</p> <p>#IMAGE_234867#</p> В рамках проведенного в апреле-мае 2026 года исследования корпоративная платформа CaseStudy.Techart изучила, как … article Владимир Бобров, автор курсов на платформе CaseStudy.Techart https://www.itweek.ru/themes/detail.php?ID=234833 Thu, 21 May 2026 00:00:00 +0300 <p><em>Корпоративное ПО всегда создавалось исходя из предположения, что за клавиатурой будет сидеть человек. Каждое проектное решение, каждый рабочий процесс, каждая модель ценообразования были оптимизированы для людей, взаимодействующих с интерфейсами. Это предположение рушится быстрее, чем ожидало большинство поставщиков. Поставщики, которые не адаптируются, не просто потеряют долю рынка. Они превратятся в инфраструктуру, пишет в корпоративном блоге Эрик Ньюмарк, вице-президент и генеральный директор подразделения SaaS, корпоративного ПО, CX и решений для рабочих мест компании IDC.</em></p> <p>Агентам ИИ не важен ваш пользовательский интерфейс. Их не впечатлит элегантная панель управления или хорошо продуманное навигационное меню. Что им нужно, так это доступ к данным, глубина API и надежность интеграции. Это фундаментальный сдвиг в том, для чего теперь на самом деле предназначено корпоративное ПО. И цифры показывают, что он происходит быстрее, чем ожидало большинство поставщиков.</p> <h3>Момент настал</h3> <p>Когда Anthropic запустила Model Context Protocol (MCP) в ноябре 2024 г., за первый месяц было зафиксировано около 100 тыс. загрузок, что стало солидным стартом для нового стандарта интеграции. Когда OpenAI внедрила MCP в марте 2025 г., количество ежемесячных загрузок за несколько недель подскочило до 22 млн. Более чем двухсоткратное увеличение за считанные дни. Это уже не кривая принятия интересного новшества. Это свидетельство того, что стандарт закрепился.</p> <p>Несколько поставщиков отреагировали быстро. Salesforce запустила приложение Agentforce Sales внутри ChatGPT в открытой бета-версии в декабре 2025 г. Block, Pfizer и Cloudflare начали запускать рабочие процессы, управляемые агентами, в производственной среде. Теоретическое стало практическим, и конкурентная динамика корпоративного ПО изменилась, в то время как некоторые поставщики все еще спорили о том, являются ли агенты реальными.</p> <h3>Владей агентом или откройся ему</h3> <p>Самое поучительное, что происходит сейчас, — это не какой-либо конкретный шаг поставщика. Речь идёт о контрасте между тем, как разные поставщики позиционируют себя в мире, управляемом агентами.</p> <p>В 2024 г. Salesforce разработала Agentforce как собственную платформу для агентов: работающую внутри экосистемы Salesforce, оптимизированную для продаж и обслуживания клиентов, предлагаемую по цене премиального продукта. Логика была проста: контролировать уровень оркестровки, управлять пользовательским опытом, укреплять лояльность клиентов. Затем в 2025 г. они переключились на MCP. MCP-клиент Agentforce перешёл в бета-версию. Серверы MCP, размещенные на серверах Salesforce, были запущены в бета-версию на Dreamforce в октябре 2025 г., а общедоступная версия появилась в <nobr>2026-м.</nobr> Приложение Agentforce Sales было запущено в ChatGPT в декабре 2025 г. Это классический пример хеджирования рисков: они хотят, чтобы клиенты использовали Agentforce, но знают, что внешние агенты всё равно будут приходить, поэтому они обеспечивают присутствие Salesforce в рабочем процессе в любом случае.</p> <p>Сравните это с другой позицией, наблюдаемой у нескольких поставщиков ERP-систем и бэк-офиса: позиционирование системы учёта как конечного пункта назначения для агентов, а не как источника информации для них. Главная идея — открытость. Вместо того чтобы гнаться за владением уровнем ИИ, эти поставщики инвестируют в чистые API и совместимость с MCP, чтобы внешние агенты могли беспрепятственно обращаться к их системам, независимо от модели или уровня оркестровки, выбранного клиентом. Они делают ставку не на владение агентом, а на то, чтобы стать для него незаменимыми.</p> <p>Две логичные ставки на одно и то же будущее. Одна сторона считает, что может владеть уровнем оркестровки. Другая считает, что долгосрочная ценность заключается в том, чтобы быть самой чистой и доступной системой учета. Обе стороны могут быть правы. Важно то, что ни одна из них не ждет, чтобы это выяснить.</p> <h3>От песочницы к производству</h3> <p>Внедрение на корпоративном уровне имеет значение, потому что оно исключает из обсуждения теоретические рассуждения.</p> <p>Компания Block создала внутреннего агента ИИ под названием Goose, работающего на MCP, который оркестрирует рабочие процессы между внутренними системами и соединяет хранилища данных с реестрами внутренних сервисов. Cloudflare создала платформу MCP с внутренним управлением, которая позволяет командам предоставлять агентам доступ к внутренним ресурсам без создания угроз безопасности, при этом управление не прикручено, а построено на уровне протокола. Предприятия в сферах финансовых услуг и медико-биологических наук используют серверы MCP для контролируемого доступа агентов к конфиденциальным данным в рамках одной и той же архитектуры. Эта тенденция постоянно повторяется: агенты находятся на уровне оркестровки, корпоративные системы — на уровне данных и выполнения, а люди проверяют результаты, а не выполняют рабочие процессы.</p> <p>Это не экспериментальные разработки. Это производственные развертывания в сложных организациях. Эта тенденция достаточно устойчива, чтобы назвать ее новой архитектурой для корпоративных вычислений, а не просто трендом.</p> <h3>Конкурентные преимущества UX исчезают</h3> <p>Если агенты станут основным уровнем оркестровки (а текущая траектория указывает именно на это), конкурентное преимущество в корпоративном ПО сместится от качества интерфейса к качеству данных и всеобъемлющему API.</p> <p>Кросс-прикладной агент, координирующий работу в системах CRM, ERP и HCM, выбирает платформы не по внешнему виду, а по надежности предоставляемых возможностей и достоверности данных. Это имеет экзистенциальное значение для поставщиков, чьи конкурентные преимущества построены на пользовательском опыте (UX). И это заставляет заново переосмыслить ценообразование, стратегию выхода на рынок и продуктовую стратегию. Если основным пользователем вашей платформы может быть ИИ, а не человек, кому вы продаете? Как устанавливать цены, если потребление определяется количеством вызовов агентов, а не количеством рабочих мест? Это не гипотетические проблемы будущего. Дальновидные поставщики работают над ними прямо сейчас.</p> <h3>Примите решение раньше, чем это сделает рынок</h3> <p>Поставщики, наиболее подготовленные к этому сдвигу, инвестируют в глубину API, чистые модели данных и совместимость с MCP, а также четко определяют, хотят ли они владеть уровнем оркестровки или быть лучшей в своем классе системой, по которой звонят агенты. Поставщики, наиболее уязвимые к этому сдвигу, по-прежнему конкурируют в основном по интерфейсу, не имея четкого ответа на вопрос об агентах.</p> <p>Наметился более глубокий разрыв: какие поставщики станут нервным центром эры агентов, а какие — инфраструктурой, на которой работают эти агенты? Оба варианта жизнеспособны. Но они требуют совершенно разных продуктовых стратегий, моделей ценообразования и отношений с клиентами.</p> <p>Окно для осознанного выбора закрывается. Поставщики, которые будут откладывать решение, изучая рынок, обнаружат, что решение уже принято.</p> Корпоративное ПО всегда создавалось исходя из предположения, что за клавиатурой будет сидеть человек. Каждое … article https://www.itweek.ru/themes/detail.php?ID=234859 Wed, 20 May 2026 16:34:08 +0300 <p>ICT.Moscow представил обновление исследования о состоянии 6G в мире в 2026 году. В этот раз авторы отдельно изучили тренд на сотрудничество участников индустрии, в том числе роль научных центров в нем.</p> <p>В документе анализируются проекты, анонсированные в зарубежных медиа в период с января 2024 года по март 2026 года, и выявленные в них различные формы кооперации: с участием науки (в том числе в рамках научных статей), любые виды сотрудничества, партнерства на уровне государств, а также совместные проекты, напрямую относящиеся к искусственному интеллекту (ИИ). Дополнительно приводится информация об инициативах, связанных с концепцией технологического суверенитета.</p> <p>По состоянию на 2023 год совместная разработка играла ключевую роль и наука занимала в таких партнерствах значимое место, этот тренд сохранился. Но если ранее больший интерес к кооперации в сфере связи шестого поколения проявляли лаборатории из Европы, сейчас же — из США. Однако если смотреть на активность отдельных компаний, то лидируют все же европейские — Nokia (Финляндия, 24% инфоповодов) и Ericsson (Швеция, 21%). Из числа других стран заметны Индия, Республика Корея, Швеция и Япония, на которые приходятся доли от 20% до 23% рассмотренных инфоповодов.</p> <p>40% всех новостей о сотрудничестве в сфере 6G содержат информацию о научных центрах, в первую очередь из США, Республики Корея, Швеции, Индии, Финляндии и других государств. Частично этот список пересекается с перечнем стран, опубликовавших за <nobr>2014–2025</nobr> годы наибольшее число общих исследований о 6G и его потенциале для бизнеса.</p> <p>Помимо кооперации ключевых акторов этой индустрии, прослеживается динамика во взаимодействии государств. Так, в период с с 2024 по 2025 год было достигнуто несколько новых договоренностей о партнерстве в области 6G между Швецией и США, Японией и США, Великобританией и Индией, а также Китаем, Евросоюзом, Республикой Корея и Индией.</p> <p>ИИ хорошо заметен среди инфоповодов о сотрудничестве в 6G, он упоминается в 37% материалов. Это связано с возрастанием активности технологических компаний полупроводниковой индустрии, таких как Arm, NVIDIA и Qualcomm, которые инициируют создание масштабных отраслевых объединений для содействия развитию шестого поколения связи.</p> <p>В 2026 году возникает тема технологического суверенитета как одного из глобальных трендов. Она проявляется и в области 6G, где международное сотрудничество с фиксированной привязкой к производителям чипов для ИИ противопоставляется концепции независимости.</p> ICT.Moscow представил обновление исследования о состоянии 6G в мире в 2026 году. В этот раз авторы … message https://www.itweek.ru/themes/detail.php?ID=234858 Wed, 20 May 2026 16:33:23 +0300 <p>На конференции ЦИПР-2026 Сбер представил производительную аналитическую систему управления базами данных (СУБД) Platform V DataMarts для обработки больших объемов информации в реальном времени. Разработкой решения занимается российская ИТ-компания СберТех — дочерняя компания Сбера.</p> <p>Решение разработано на базе открытого исходного кода российской СУБД ClickHouse и поддерживает SQL-подобный язык запросов и хранит данные в виде столбцов, что обеспечивает быструю обработку, масштабируемость в распределенной среде и оптимальное использование вычислительных ресурсов. Система от СберТеха доработана в соответствии с требованиями, которые предъявляются к современным программным продуктам финансового класса. Это обеспечивает безопасность обрабатываемых данных и высокую скорость доступа к ним.</p> <p>Продукт зарегистрирован в Реестре российского ПО и отвечает актуальным регуляторным и корпоративным стандартам. С его помощью отечественные предприятия могут в онлайн-режиме отслеживать динамику транзакций в высоконагруженных сервисах, готовить финансовую и коммерческую отчетность в различных разрезах, эффективно решать задачи продуктовой и поведенческой аналитики.</p> <p>Андрей Белевцев, старший вице-президент, руководитель блока «Технологическое развитие» Сбербанка, отметил: «Современная СУБД — это уже не вспомогательное звено, а ключевое звено инфраструктуры высоконагруженных сервисов. Российский бизнес сознательно выбирает путь построения систем на отечественных технологиях. И здесь важны не просто возможности базы данных, а три кита: производительность, безопасность и способность органично встроиться в общий технологический стек без потери эффективности. Обеспечение бесперебойной работы крупнейших корпораций — ключевой фактор сохранения конкурентоспособности на рынке и поддержания надлежащего качества сервиса для миллионов клиентов».</p> <p>Одна из особенностей Platform V DataMars — простота и удобство внедрения. СУБД совместима с инфраструктурными решениями других отечественных вендоров, а также содержит готовый набор инструментов для автоматизированного развертывания и сопровождения. Для системы разработаны преднастроенные сценарии, охватывающие ключевые этапы: установку на серверы клиента, обновления и откаты к предыдущим версиям, проверку состояния системы, резервное копирование и восстановление. Такой подход уменьшает объем ручных операций, снижает риски сбоев, повышает предсказуемость внедрения и существенно ускоряет ввод в промышленную эксплуатацию.</p> <p>Максим Тятюшев, генеральный директор СберТеха, прокомментировал: «Platform V DataMarts создана для компаний, которым особенно важна скорость аналитики и принятия решений. Система позволяет бизнесу оптимизировать управление большими данными, снизить затраты на инфраструктуру, повысить точность прогнозирования, не прибегая к зарубежным продуктам, и за счет этого минимизировать риски потери прибыли и утечки конфиденциальной информации. Производительность и безопасность делают нашу СУБД надежным решением для крупных промышленных и логистических предприятий, компаний государственного и банковского сектора, ритейлеров, страховых и телекоммуникационных организаций».</p> На конференции ЦИПР-2026 Сбер представил производительную аналитическую систему управления базами данных (СУБД) Platform … message https://www.itweek.ru/themes/detail.php?ID=234855 Wed, 20 May 2026 09:32:31 +0300 <p><em>В этой статье мы обсудим, как ожидания бизнеса расходятся с реальными возможностями ИИ, стоит ли сравнивать российские решения с мировыми аналогами и почему автоматизация при неправильном понимании природы нейросетей может принести обратный эффект.</em></p> <h3>Из крайности в крайность</h3> <p>Разработки в сфере искусственного интеллекта ведутся в том числе и в России, и вполне естественно возникает вопрос их сопоставления с мировыми аналогами. Однако это сравнение представляется преждевременным. Создание конкурентоспособных нейросетей требует наличия мощной компонентной базы и колоссальных вычислительных ресурсов, а одной из основных преград на пути к технологическому паритету выступает дефицит аппаратного обеспечения.</p> <p>Кроме того, для обучения моделей необходимы качественные датасеты. Сложность здесь заключается не только в физическом объеме информации, но и в легальности и технической чистоте ее получения. Массовый сбор данных из открытых источников сопряжен с серьезными юридическими и инженерными трудностями, даже если контент не защищен авторским правом. Прямое взаимодействие с держателями баз данных — гораздо более эффективный и устойчивый путь, чем попытки разрозненного извлечения сведений из сети.</p> <p>Как пример возьмем патентную сферу. Для качественного обучения системы недостаточно стандартных реестров национальных ведомств. Глубокий анализ требует обработки сопутствующей переписки с зарубежными регистраторами, материалов экспертиз и иных специфических документов. Несмотря на то что формально такие сведения могут считаться публичными, их технический сбор и систематизация остаются крайне трудоемкой задачей. В таких реалиях зачастую рациональнее использовать уже готовые зарубежные решения, чем пытаться наполнить отечественную модель эквивалентным объемом структурированных данных.</p> <p>Развитие российского ИИ-сектора во многом подстегивается в связи с высоким спросом со стороны бизнеса, который порой испытывает завышенные ожидания и не всегда осознает лимиты технологий. Они связны с тем, что генеративные модели по своей сути не выдают гарантированно верную истину. Их работа — это формирование наиболее правдоподобного ответа, максимально похожего на результат человеческого труда. Однако ИИ нередко воспринимают как некую интеллектуальную сущность, обладающую мышлением, что, безусловно, не соответствует действительности.</p> <p>И хотя выше было сказано, что сопоставлять российские и зарубежные решения преждевременно, впадать в другую крайность тоже будет ошибкой. Утверждение о том, что российский сегмент искусственного интеллекта находится в роли догоняющего, является не вполне корректным. В действительности мировое сообщество исследователей находится на этапе поиска наиболее продуктивных ниш для использования этой сложной и во многом нелинейной технологии.</p> <h3>Ради быстрого эффекта</h3> <p>На нынешнем уровне развития моделей их практическое применение сосредоточено в зонах быстрого эффекта: подготовке текстового контента, оптимизации документооборота, аналитической поддержке и автоматизации взаимодействия с клиентами. Преимущество искусственного интеллекта проявляется там, где необходимо оперировать естественным языком, учитывать сложный контекст и работать с высокой вариативностью неструктурированных данных.</p> <p>При этом ИИ не может служить универсальной заменой классическим ИТ-системам. В процессах, поддающихся жесткой регламентации и описанию через строгие алгоритмы, традиционные решения остаются более надежными, экономичными и проверяемыми. Точно так же он не способен выступать полноценной альтернативой человеческому интеллекту при выполнении многоуровневых задач. Наибольшие риски сопряжены с делегированием нейросетям вопросов стратегического управления и принятия критических тактических решений. Природа алгоритмов заставляет их выдавать наиболее усредненный результат, в то время как прорывные (равно как и критически ошибочные) бизнес-стратегии обычно лежат за пределами статистической нормы, в области нестандартных решений.</p> <p>Кроме того, преждевременная интеграция ИИ непосредственно в критические операционные циклы компании несет в себе скрытые угрозы. Использование автоматизированных моделей без участия квалифицированного специалиста и системы многоуровневого мониторинга способно дестабилизировать бизнес-процессы. Учитывая, что этап повсеместного и бесперебойного внедрения ИИ еще не пройден, объективно оценить долгосрочную безопасность такой глубокой автоматизации на данный момент крайне сложно.</p> <h3>Зеркало слепых зон</h3> <p>Поскольку модель обучается на массивах данных, отражающих реальный рыночный опыт, она неизбежно впитывает не только накопленную экспертизу, но и транслирует коллективные заблуждения конкретной индустрии. В итоге ИИ становится зеркалом существующих в отрасли слепых зон. Системные недоработки, использование архаичных методик и укоренившиеся профессиональные деформации оказывают фундаментальное влияние на релевантность выводов искусственного интеллекта. Они не разрушают вычислительную логику нейросети как таковую, но радикально искажают информационную среду.</p> <p>Как следствие, если внутри корпоративной культуры или целого профессионального сообщества определенные установки принимаются на веру без должной верификации, алгоритм начинает интерпретировать их как непреложную норму. Это создает ряд специфических рисков в зависимости от сферы применения.</p> <p>К примеру, в банковском секторе нейросеть может необоснованно завышать уровень риска при оценке заемщика, если исторически принятые в организации решения отличались избыточным консерватизмом. Модель просто копирует осторожность кредитных офицеров прошлого, блокируя развитие новых клиентских сегментов.</p> <p>В медицине алгоритмы рискуют тиражировать популярные, но не всегда наиболее эффективные диагностические шаблоны. Если в обучающей выборке преобладали стандартные протоколы без учета современных клинических исследований, ИИ будет предлагать инерционный путь лечения.</p> <p>В юридической практике искусственный интеллект склонен воспроизводить громоздкие и архаичные формулировки договоров. Он опирается на десятилетний опыт работы юридического департамента, игнорируя тот факт, что правовая среда и стандарты делового оборота уже давно изменились.</p> <p>В сфере кибербезопасности системы мониторинга могут ложно идентифицировать угрозу там, где имеет место лишь нестандартное, но легитимное поведение пользователя. Это происходит, если норма в обучающей базе была описана слишком узко.</p> <p>В промышленном производстве ИИ способен легитимизировать обходные пути. Если в логах эксплуатации зафиксировано, что регламенты годами нарушались ради выполнения плана, модель сочтет такие действия оптимальным стандартом, поскольку так делали всегда.</p> <p>Однако наибольшую опасность представляют так называемые галлюцинации уверенности. Благодаря совершенству лингвистических структур ИИ мастерски использует профессиональную терминологию, ссылается на реальные корпоративные процедуры и безупречно выдерживает официально-деловой стиль. В результате возникает опасный психологический эффект: текст, который выглядит и звучит как профессиональный отчет, воспринимается человеком как априори достоверный. Подобное внешнее правдоподобие притупляет критическое восприятие, многократно повышая риск принятия ошибочных решений на основе технически совершенной, но фактически неверной рекомендации.</p> <h3>Ловушка автоматизированной инерции</h3> <p>В свете вышесказанного становится понятным, почему интеграция искусственного интеллекта, вопреки распространенному заблуждению, не обязательно приводит к модернизации бизнеса. На практике ИИ — это мощный катализатор, и если его внедрить без предварительного пересмотра данных и регламентов, он лишь многократно ускоряет накопленную системную инерцию. Вместо качественного скачка компания получает высокоскоростное воспроизводство старых ошибок.</p> <p>Ярким примером служит автоматизация документооборота. Если нейросеть получает доступ к архиву, не прошедшему предварительную селекцию и очистку, она начинает генерировать устаревшие формы контрактов и отчетов с беспрецедентной скоростью. Аналогично в клиентском сервисе: ИИ, обученный на архаичных скриптах, будет безупречно транслировать неэффективные модели коммуникации, которые давно раздражают потребителя. В обоих случаях показатели производительности (количество созданных документов или обработанных заявок) формально растут, однако ценность и качество принимаемых решений остаются на прежнем, а иногда и более низком уровне.</p> <p>Особую опасность этот эффект представляет в отраслях с высокой ценой ошибки. В таких сферах, как медицина, юриспруденция, финансы, кибербезопасность, государственное управление, промышленная безопасность, HR, патентное дело и научно-исследовательские разработки (R&D), автоматизированная ошибка может привести к катастрофическим правовым, экономическим или социальным последствиям.</p> <p>Как следствие, для перехода к зрелому использованию ИИ недостаточно просто выбрать современную языковую модель. Требуется внедрение жесткой инженерной и экспертной дисциплины, включающей следующие этапы:</p> <ul> <li> Глубокий аудит данных на предмет исторических перекосов.</li> <li> Четкое разделение объективных фактов, субъективных экспертных суждений и специфических корпоративных привычек, которые часто ошибочно принимаются за стандарты.</li> <li> Актуализация интеллектуальных активов: радикальное обновление корпоративных баз знаний перед их подачей на вход модели, удаление противоречащих друг другу или устаревших инструкций.</li> <li> Стресс-тестирование на пограничных сценариях и проверка поведения алгоритма в нестандартных, спорных и редких ситуациях, где вероятность ошибки максимально велика.</li> <li> Использование независимых отраслевых стандартов, научной литературы и международного опыта для верификации ответов.</li> <li> Внедрение механизмов, заставляющих ИИ аргументировать свой ответ и указывать степень уверенности в нем, что позволяет оператору оценить надежность рекомендации.</li> <li> Обязательное участие квалифицированного специалиста в утверждении решений, цена ошибки в которых превышает допустимый порог риска.</li> </ul> <p>Фундаментальное правило безопасной интеграции гласит: качество работы искусственного интеллекта невозможно объективно проверить, используя исключительно те же массивы данных, тех же людей и те же процедуры, которые изначально сформировали среду с искажениями. Истинная модернизация начинается там, где появляется внешний независимый фильтр и критическое осмысление накопленного опыта.</p> <p>#IMAGE_234856#</p> В этой статье мы обсудим, как ожидания бизнеса расходятся с реальными возможностями ИИ, стоит ли … article Александр Киселев, патентный поверенный UserGate