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=235469 Fri, 04 Sep 2026 13:57:21 +0300 <p>Искусственный интеллект из самостоятельного направления разработок превращается в сквозной инструмент исследований, технологического развития и трансформации экономики. Этот переход отчетливо прослеживается в стратегических документах Китая и Республики Корея на <nobr>2026–2030 гг.</nobr> Институт статистических исследований и экономики знаний (ИСИЭЗ) НИУ ВШЭ проанализировал, как эти страны адаптируют научно-технологическую политику к новой роли ИИ.</p> <p>Справочно: анализ охватывает Шестой базовый план развития науки и технологий Республики Корея (июнь 2026), Основные положения <nobr>15-го</nobr> пятилетнего плана социально-экономического развития КНР (март 2026) и Мнения Госсовета КНР об углубленной реализации инициативы «ИИ+» (август 2025).</p> <p>В обеих странах ИИ-трансформация выходит далеко за пределы научного сектора. В Китае акцент переносится с «гонки моделей» на массовую диффузию ИИ и создание новых сценариев его применения. В Южной Корее ИИ-трансформация наряду с научной системой охватывает промышленность и региональные кластеры.</p> <p>ИИ-трансформация науки опирается на национальную вычислительную инфраструктуру. Китай развивает интегрированную сеть суперкомпьютеров, центров интеллектуальных вычислений и облачных платформ; Республика Корея планирует сформировать к 2030 г. государственно-частный пул из 260 тыс. GPU.</p> <p>Китайский план ориентирован на полный цикл — от исследований до ускоренной коммерциализации. Один из новых фронтиров — физический ИИ: развитие сред для обучения роботизированных систем и разработка гуманоидных роботов. Параллельно создаются институты отраслей будущего, центры проверки концепций, механизмы разделения инвестиционных рисков и регуляторные песочницы.</p> <p>В Республике Корея ИИ встраивают непосредственно в исследовательский процесс: план предусматривает развитие ИИ-соисследователей (AI Co-Scientist), автономных лабораторий и междисциплинарных проектов с применением ИИ. Масштабная технологическая трансформация сопровождается институциональной реформой науки, включающей переход к более долгосрочному и предсказуемому финансированию исследований, а также снижение административной нагрузки.</p> <p>В совокупности опыт двух стран показывает, что комплексная ИИ-трансформация науки требует не отдельной программы поддержки ИИ, а согласованного изменения всей исследовательской среды. Наибольший интерес представляет сочетание вычислительной инфраструктуры и широкого доступа к ее ресурсам, внедрения ИИ непосредственно в исследовательский процесс, долгосрочных механизмов финансирования науки и инструментов, ускоряющих переход от исследований к практическому применению.</p> Искусственный интеллект из самостоятельного направления разработок превращается в сквозной инструмент исследований … message https://www.itweek.ru/themes/detail.php?ID=235468 Fri, 04 Sep 2026 13:53:18 +0300 <p>MWS Cloud, входящая в МТС Web Services, развернула передовую модель GLM-5.3 в собственной облачной инфраструктуре. Она доступна в сервисе MWS GPT Model Hub и полностью локализована на территории России: данные пользователей и запросы к ней не покидают страну. Стоимость останется на уровне GLM-5.2.</p> <p>Развертывание GLM-5.3 в облаке MWS Cloud позволяет российским компаниям использовать модель для разработки программного обеспечения и решения агентских задач в российском ИТ-контуре. Среди возможных сценариев — генерация и анализ кода, поиск ошибок, работа с репозиториями, автоматизация многоэтапных процессов и создание ИИ-агентов.</p> <p>GLM-5.3 разработана китайской компанией Z.ai и опубликована с открытыми весами. По данным разработчика, модель использует ту же базовую архитектуру, что и GLM-5.2, а прирост качества получен за счет масштабирования посттренинга. Модель ориентирована на сложные задачи программирования и длительные последовательности действий с использованием инструментов. Z.ai опубликовала веса через две недели после запуска модели — это время разработчик отвел на дополнительную оценку и усиление мер безопасности.</p> <p>Локальное размещение модели в инфраструктуре MWS Cloud дает компаниям возможность работать с GLM-5.3 без передачи запросов и обрабатываемых данных за пределы России. Вычисления выполняются в облаке MWS Cloud на территории страны.</p> <p>По данным Z.ai и независимым оценкам, GLM-5.3 выступает на уровне передовых закрытых моделей. В задачах программирования она стабильно опережает Claude Opus 4.8 и сопоставима с новейшими Claude Fable 5 и GPT-5.6 Sol, лишь немного уступая им в самых сложных тестах. Сильнее всего модель проявляет себя в длительных агентских сценариях: здесь она в большинстве тестов не уступает закрытым моделям, а в части из них выходит вперед. В пользовательском рейтинге Text Arena модель идет практически вровень с лидером, а по качеству создания веб-интерфейсов входит в число лучших. В краудсорсинговом рейтинге Design Arena, где реальные пользователи сравнивают модели по качеству дизайна, GLM-5.3 входит в тройку лучших в общем зачете, заметно поднявшись относительно предыдущей версии, и занимает второе место среди моделей с открытыми весами.</p> MWS Cloud, входящая в МТС Web Services, развернула передовую модель GLM-5.3 в собственной облачной инфраструктуре. Она … message https://www.itweek.ru/themes/detail.php?ID=235463 Fri, 04 Sep 2026 11:01:36 +0300 <p><em>Матар Пелеш, инженер по разработке решений компании Port, рассказывает на портале </em><em>The</em> <em>New</em> <em>Stack</em> <em>о том, как агенты искусственного интеллекта функционируют в качестве потребителей, внутренних компонентов и управляемых ресурсов на современных платформах для разработчиков.</em></p> <p>Инженерные организации стараются работать настолько быстро, насколько позволяют технологии, внедряя агентный ИИ в свои платформы для разработчиков и разрабатывая способы использования ИИ-агентов для максимизации производительности инженеров.</p> <p>Но когда речь заходит об агентной платформе для разработчиков, каждая команда, с которой мы общаемся, видит роль этих агентов немного по-разному. После сотен обсуждений мы определили три типа ролей.</p> <h3>Роль 1: ИИ-агенты как потребители платформы</h3> <p>В этой роли агент, по сути, является пользователем платформы. Он использует платформу в рамках своей задачи по чтению контекста и выполнению действий. Когда агенты впервые появились, многие компании заявили, что относятся к ним как к сотрудникам, а в платформе разработки агент становится просто еще одним инженерным ресурсом, использующим ее.</p> <p>#IMAGE_235465#</p> <p>Типичный пример: инженер просит Claude Code добавить конечную точку в платежный сервис. Прежде чем начать писать какой-либо код, агент получает от платформы информацию о владельце сервиса, зависимостях и стандартах, которым он должен соответствовать, затем запускает среду предварительного просмотра с помощью действия самообслуживания и выполняет тесты.</p> <p>Для корректной работы агенту необходимо проанализировать реальную, актуальную информацию о ваших системах, начиная с каталога услуг и заканчивая владельцами, зависимостями, стандартами и текущим состоянием. Если контекст неверен, высока вероятность того, что агент станет слишком самоуверенным и допустит ошибку. Большинство команд решают эту проблему, предоставляя локальный контекст отдельно для каждого агента. Из-за этого эта информация оказывается связана с агентами ненадежным образом, не говоря уже о том, что ни один из них не управляется. Сравните это с озером контекста, которое предоставляет каждому агенту единый управляемый источник достоверной информации. Платформа также должна быть доступна для работы агента, что означает ориентацию на API и MCP.</p> <p>Что требуется от платформы? Интерфейс, ориентированный на API и MCP, управляемый контекстный слой, из которого агент считывает данные, и набор действий самообслуживания, которые он может вызывать.</p> <h3>Роль 2: ИИ-агенты как внутренние компоненты платформы</h3> <p>Платформы, способные регистрировать агентов и запускать их в рамках рабочих процессов, используют агентов как часть полноценного бизнес-процесса. Агент работает внутри платформы, запускается событием, а не запрашивается человеком, и находится в механизме оркестровки рядом с детерминированными шагами.</p> <p>#IMAGE_235466#</p> <p>Возьмем запуск ежевечерней проверки, которая выявляет уязвимые зависимости в 40 сервисах. Платформа извлекает средство исправления из реестра и запускает его один раз для каждой службы, так что каждая команда владельцев получает доступ к открытому запросу на слияние (PR), ожидающему проверки.</p> <p>Что требуется от платформы? Уровень оркестровки для запуска агентов, реестр для выбора нужного агента, идентификационный номер для каждого агента, чтобы действие регистрировалось для конкретного агента, а не для заимствованных учетных данных человека, и этап с участием человека, где риск значителен.</p> <h3>Роль 3: ИИ как ресурс со своим собственным жизненным циклом (также известно как AgenticOps)</h3> <p>В этой роли агент является таким же ресурсом, как и LLM, серверы MCP и навыки, которые с этим связаны. Платформа предоставляет их, управляет ими и возвращает обратно, точно так же, как это происходит с сервисом, базой данных или средой.</p> <p>#IMAGE_235467#</p> <p>Например, предположим, инженеру нужен дежурный агент для сортировки обращений. Он выбирает модель, инструменты и среду выполнения либо через форму, либо описывая свои потребности, и платформа предоставляет все необходимое, подобно торговому автомату, включая хорошо управляемого агента, соответствующего необходимым стандартам.</p> <p>Это создает проблему «золотого пути». «Золотой путь» — это маршрут, который по умолчанию обеспечивает команде доступ к ресурсу правильным образом, и он нужен для жизненного цикла агента: запрос, получение и регистрация, а затем публикация для следующей команды. Это также то, чем чаще всего интересуются организации: реестр агентов и навыков был востребован 47% организаций, с которыми мы общались.</p> <p>Что требуется от платформы? Путь самообслуживания, который обеспечивает среду выполнения, выдает идентификационные и ограниченные учетные данные, подключает утвержденный контекст и регистрирует агента на выходе, а также маршрут для публикации для следующей команды.</p> <h3>Краткое описание трех ролей</h3> <table> <thead> <tr> <td> <p><strong>Роль</strong></p> </td> <td> <p><strong>Что агент собой представляет </strong></p> </td> <td> <p><strong>Пример</strong></p> </td> <td> <p><strong>Что требуется от платформы</strong></p> </td> </tr> </thead> <tbody> <tr> <td> <p><strong>Роль 1: ИИ-агенты как потребители платформы</strong></p> </td> <td> <p>Пользователь платформы, считывающий контекст и выполняющий действия в рамках своей задачи</p> </td> <td> <p>Claude Code определяет владельца сервиса, зависимости и стандарты, затем запускает среду предварительного просмотра и запускает тесты</p> </td> <td> <p>Управляемый контекстный слой, например, озеро контекста, и действия самообслуживания, которые он может вызывать</p> </td> </tr> <tr> <td> <p><strong>Роль 2: ИИ-агенты как внутренние компоненты платформы</strong></p> </td> <td> <p>Шаг в рабочем процессе, запускаемый событием, а не по запросу пользователя</p> </td> <td> <p>Ежевечернее сканирование выявляет уязвимую зависимость в 40 службах, и агент исправления открывает PR для каждой из них</p> </td> <td> <p>Слой оркестрации для запуска агентов, реестр для получения нужных данных, идентификация агентов и человек, вовлеченный в процесс там, где риск реален</p> </td> </tr> <tr> <td> <p><strong>Роль 3: ИИ как многоразовые строительные блоки (AgenticOps)</strong></p> </td> <td> <p>Ресурс, который платформа предоставляет, управляет им и возвращает обратно</p> </td> <td> <p>Инженер запрашивает агента сортировки по вызову, выбирает модель и инструменты и возвращает уже зарегистрированными</p> </td> <td> <p>Путь самообслуживания, который обеспечивает среду выполнения, выдает идентификатор и ограниченные учетные данные, подключается в утвержденном контексте и регистрирует агента</p> </td> </tr> </tbody> </table> <h3>Иногда эти три роли оказываются связанными</h3> <p>Интересный случай с цепочкой ролей. Инженер запрашивает агента сортировки в роли 3; тот добавляется в реестр агентов как часть рабочего процесса создания, а неделю спустя рабочий процесс инцидента вызывает его как компонент (роль 2). Когда агент запускается, он считывает данные о владельце службы и последних развертываниях из того же контекстного хранилища, реализуя роль 1. Это один и тот же агент, которого вы видите в разных ролях.</p> <h3>Как может выглядеть платформа, охватывающая все три роли</h3> <p>Агент может использовать платформу в качестве пользователя через учетную запись службы, читая контекстное озеро и выполняя действия самообслуживания. Агенты работают в рамках рабочих процессов платформы как часть бизнес-процесса. Кроме того, AgenticOps работает в режиме самообслуживания, поэтому команда может запросить агента и получить уже зарегистрированного. Все три роли находятся в одном каталоге, в одном контексте и в одном журнале аудита.</p> Матар Пелеш, инженер по разработке решений компании Port, рассказывает на портале The New Stack о том, как агенты … article https://www.itweek.ru/themes/detail.php?ID=235461 Fri, 04 Sep 2026 09:52:39 +0300 <p>В операционном управлении — будь то производство, логистика, ритейл или сфера услуг — внедрение систем бизнес-аналитики давно перестало быть просто модным трендом. Это базовый стандарт конкурентоспособности. При этом многие компании совершают одну и ту же стратегическую ошибку: заказывают ИТ-подрядчикам «красивые панели показателей в реальном времени» и получают на выходе плоский список из десятков разрозненных цифр. Это создает иллюзию контроля, но на деле лишь нагружает руководителя информационным шумом.</p> <p>Как ИТ-эксперт, сопровождающий цифровую трансформацию, я предлагаю компаниям сместить фокус. В управления важны не сами по себе показатели. Главное — возможность иметь динамическую иерархическую отчетность. Руководителю жизненно необходимо за секунды переходить от показателей верхнего уровня к нижнему, сравнивать любые периоды между собой и делать это непосредственно в любой момент времени.</p> <p>Все всегда начинается с финансов. Но аналитическая система должна жестко ассоциировать финансовые результаты с физическими, так называемыми натуральными показателями. Финансы — это всегда запаздывающий индикатор, результат уже свершившихся событий. Чтобы управлять бизнесом, мы должны привязать деньги к количеству выпущенной продукции, отработанным сменам, объему потраченных материалов или скорости движения запасов на складах.</p> <p>В любом бизнесе существует <nobr>3-5</nobr> ключевых физических метрик, которые характеризуют его «биение сердца». Они обычно хорошо известны грамотному руководителю. Вокруг них строится семейство зависимых показателей. Вот универсальный перечень таких натуральных метрик и обоснование их выбора:</p> <ul> <li><strong>Выработка на единицу трудозатрат (человеко-часов). </strong>Обоснование: напрямую связывает фонд оплаты труда с физическим объемом работы. Позволяет увидеть не просто рост затрат на персонал, а падение реальной эффективности конкретных смен или участков.</li> <li><strong>Процент отклонений от стандарта (брак, переделки, ошибки). </strong>Обоснование: главный индикатор качества процессов. Рост этого показателя мгновенно объясняет рост себестоимости без необходимости глубокого финансового аудита.</li> <li><strong>Время простоя оборудования или логистических узлов. </strong>Обоснование: натуральная метрика, которая конвертируется в упущенную выручку и сверхурочные выплаты. Показывает реальную загрузку мощностей и узкие места.</li> <li><strong>Расход материалов или энергии на единицу продукции. </strong>Обоснование: позволяет отследить скрытые потери. Если деньги растут, а физический расход на единицу стабилен — проблема в ценах поставщиков. Если растет физический расход — проблема в технологии или персонале.</li> </ul> <h3>Показательный кейс: как это работает на практике</h3> <p>Представим производственную или торговую компанию. Во вторник утром генеральный директор видит, что операционная прибыль за вчера просела относительно плана на 8%.</p> <p>В «плоской» системе: директор звонит финдиректору и просит «поднять цифры». Через два дня приходит сводная таблица, из которой следует, что выросла себестоимость. Еще день уходит на запрос объяснительных от начальников. Время упущено, убыток закреплен.</p> <p>В иерархической системе: директор нажимает на просевший показатель прибыли на Экране № 1. Система мгновенно показывает, что драйвером стал рост затрат на конкретном участке. Он переходит на уровень ниже (Экран № 2) и видит: финансовый рост вызван натуральным показателем «процент отклонений», который резко подскочил в предыдущую смену. Переходя к еще большей детализации (Экран № 3), он видит прямую корреляцию: пик брака совпал с выходом новой бригады и партией сырья от нового поставщика.</p> <p>Итог: руководитель не ждет еженедельного совещания. Он прямо между встречами звонит начальнику производства, корректирует процесс и изолирует бракованную партию. На планерке вопрос уже закрыт.</p> <h3>Как руководителю читать и анализировать данные</h3> <p>Самое главное требование к системе: она должна позволять на одном, двух или трех экранах динамически отслеживать причинно-следственные связи.</p> <ul> <li><strong>Экран «Капитанский мостик»</strong><strong> (стратегический).</strong> Здесь только финансовые итоги и <nobr>3-5</nobr> главных натуральных индикаторов. Руководитель смотрит сюда каждое утро. Цель: увидеть отклонение от плана и сравнение с прошлыми периодами.</li> <li><strong>Экран «Операционный разрез» (тактический).</strong> Сюда руководитель переходит по клику, если видит «красную зону». Здесь детализация по блокам: производство, склад, логистика.</li> <li><strong>Экран «Контекст и связи» (аналитический).</strong> Возможность наложить любые показатели друг на друга. Например, сопоставить график «количества отработанных человеко-часов» с графиком «объема выпуска». Если линии расходятся, вы сразу видите неэффективность использования ресурсов без необходимости сводить сложные таблицы.</li> </ul> <h3>Конец эры «давайте запросим статистику»</h3> <p>Главная ценность такого подхода к аналитике в реальном времени заключается в фундаментальном изменении культуры управления.</p> <p>Раньше на регулярных совещаниях руководителей часто звучала фраза: «Давайте после встречи запросим статистику по этой гипотезе». Это убивало динамику и скорость реакции. </p> <p>Когда выстроена правильная иерархическая система, связывающая рубли с натуральными показателями (штуками, часами, килограммами), любые гипотезы проверяются прямо на экране за полминуты. Это позволяет управленцам быстро находить корневые причины проблем, назначать ответственных и действовать на опережение. Чтобы на регулярных совещаниях никогда не стоял вопрос о необходимости «запросить цифры», а любой вопрос мог быть проверен сразу же, на экране нашей системы. Именно это дает реальную власть над операционной деятельностью.</p> <p>#IMAGE_235462#</p> В операционном управлении — будь то производство, логистика, ритейл или сфера услуг — внедрение систем … article Сергей Капарис, управляющий партнер Umbrella Consulting Group https://www.itweek.ru/themes/detail.php?ID=235458 Thu, 03 Sep 2026 15:43:37 +0300 <p>«Базис» выпустила новую версию Basis Workplace, флагманской платформы для управления инфраструктурой виртуальных рабочих столов (VDI). Ключевыми изменениями релиза 3.4 стали возможность работы с несколькими инсталляциями с одного рабочего места, поддержка виртуализации приложений и нативный инструмент миграции с Basis Workplace второго поколения. Помимо этого, в релизе был расширен инструментарий управления пулами и виртуальными рабочими местами, добавлены новые сценарии развертывания и средства управления сертификатами, а также обновлен протокол Basis Connect.</p> <p>В Basis Workplace 3.4 администраторы получили возможность определять набор приложений, которые автоматически устанавливаются на виртуальные рабочие места (ВРМ) пользователей. Настройки применяются централизованно для пулов, что исключает ручную установку на каждом ВРМ, снижает нагрузку на поддержку и гарантирует единообразное рабочее окружение для сотрудников. Гибкие политики позволяют контролировать, каким сотрудникам какие приложения доступны, а пользователь получает готовую, полностью оснащенную среду с первого же сеанса — без ожидания и запросов в техподдержку.</p> <p>В новом релизе добавлен режим мультиклиента, который позволяет администраторам одновременно работать в нескольких инсталляциях Basis Workplace с одного рабочего места. Единая точка администрирования упрощает обслуживание <nobr>VDI-инфраструктуры,</nobr> расположенной в разных ЦОДах, филиалах, контурах и т.д., а также позволяет быстро переключаться между средами и ускоряет реакцию на инциденты.</p> <p>В персонализированных пулах — логических объединениях виртуальных рабочих столов, использующих общие ресурсы и настройки — стало доступно использование персональных дисков пользователей, а также перемещение дисков между пулами. В случае изменения индивидуального шаблона, с использованием которого создавался персонализированный пул, реализованный механизм рекомпозиции позволяет пересобирать виртуальные машины этого пула.</p> <p>Клиентскую часть Basis Workplace теперь можно устанавливать отдельно от протоколов доставки, в том числе для включения в дистрибутив заказчика. На одну виртуальную машину допускается последовательная установка нескольких дополнительных сервисов, а брокер сообщений NATS можно развернуть как отдельный сервис, объединив три его экземпляра в кластер. Все перечисленное позволяет администратору учесть потребности и особенности создаваемой <nobr>VDI-инфраструктуры</nobr> уже на этапе инсталляции Basis Workplace.</p> <p>Basis Workplace позволяет загружать серверный сертификат заказчика непосредственно на этапе инсталляции, а для SSL-запросов в новой версии был реализован переход на системное хранилище сертификатов операционной системы.</p> <p>Для заказчиков, использующих Basis Workplace 2.6.4 и планирующих переход на версию платформы 3.4 создан новый инструмент миграции пулов. Он переносит объекты и их настройки, поддерживает миграцию сессионных, персональных и терминальных пулов. Для персональных пулов предусмотрена возможность отката миграции.</p> <p>В собственном протоколе доставки Basis Connect появилось управление направлением проброса буфера обмена. Теперь администратор может включать и выключать передачу файлов, текста и изображений через буфер; обмен данными можно разрешить только с пользовательского устройства на сервер, только в обратную сторону или в обе стороны одновременно. В окне протокола также добавлен графический интерфейс с подробными сведениями о доступных USB-устройствах, смарт-картах, токенах, принтерах и других.</p> <p>Список поддерживаемого платформой Basis Workplace ПО пополнили операционные системы Windows 11 и «Альт» 11 в качестве гостевых и клиентских ОС, а также платформа виртуализации VMware vCenter Server 6.7u3.</p> <p>В версии платформы 3.4 появились новые инструменты создания отчетности по запуску приложений и подключениям к терминальным пулам. Теперь администратор может получать списки уникальных пользователей и устройств доступа, а также вручную выгружать эти данные. Все это обеспечивает прозрачность использования опубликованных ресурсов и помогает эффективнее управлять инфраструктурой.</p> <p>«Basis Workplace развивается как самодостаточная платформа, закрывающая все больше сценариев работы с <nobr>VDI-инфраструктурой</nobr> внутри одного продукта. Виртуализация отдельных приложений стала ключевым новшеством релиза. Она позволяет централизованно и быстро обеспечивать сотрудников доступом к необходимым корпоративным приложениям. Отдельно в новом релизе мне бы хотелось отметить появление инструментов для миграции с Basis Workplace второго поколения — функциональной и надежной, но уже архитектурно устаревшей версии нашей платформы», — прокомментировал Дмитрий Сорокин, технический директор «Базис».</p> «Базис» выпустила новую версию Basis Workplace, флагманской платформы для управления инфраструктурой виртуальных рабочих столов … message https://www.itweek.ru/themes/detail.php?ID=235457 Thu, 03 Sep 2026 15:41:48 +0300 <p>Российский облачный рынок проходит через структурную трансформацию, сравнимую по масштабу с переходом от физических серверов к виртуализации. Наряду с классической моделью IaaS — аренда виртуальных машин, дискового пространства и сетевых ресурсов — будет расти спрос на AI-IaaS: инфраструктуру как сервис, предназначенную для обучения, дообучения и эксплуатации моделей искусственного интеллекта. Владимир Лебедев, директор по развитию бизнеса сервис-провайдера M1Cloud, рассказал, что в традиционном облаке объектом выступают виртуальные машины, контейнеры и хранилища, а в AI-IaaS к ним добавляются поведение модели, происхождение данных, промпты, векторные индексы, GPU-кластеры и действия подключенных инструментов.</p> <p>По оценкам аналитиков M1Cloud, прогноз роста облачного рынка до 2030 года предполагает среднегодовой темп <nobr>25-32%</nobr> с учетом миграции нагрузок из зарубежных платформ и расширения ИИ-проектов в госсекторе, финансах, промышленности и телекоме.</p> <p>Трансформация российского облачного рынка определяется не только технологической логикой, но и регуляторными ограничениями. Требования локализации данных, ограничение трансграничной передачи, необходимость использования инфраструктуры российских провайдеров и доказательного соответствия нормативным актам создают уникальный контур, в котором AI-IaaS становится не опцией, а условием продолжения цифровизации. Для суверенного ИИ критичны локализация вычислений, география GPU, логирование и воспроизводимость цикла и не менее важны, чем производительность.</p> <p>В 2026 году доля AI-IaaS в общем объеме российского облачного рынка оценивается в <nobr>12-15%,</nobr> что соответствует <nobr>18-22</nobr> млрд рублей. Ключевым драйвером выступают пилотные GPU-кластеры и первые промышленные инференс-нагрузки крупных языковых моделей. Заказчики тестируют сценарии RAG (генерация с дополненным поиском), чат-ботов и автоматизации документооборота, но объемы пока ограничены экспериментальными бюджетами.</p> <p>К 2027 году доля AI-IaaS вырастет до <nobr>22-27%,</nobr> а абсолютный объем достигнет <nobr>38-48</nobr> млрд рублей. На этом этапе произойдет переход от пилотов к промышленной эксплуатации: банки, страховые компании и государственные структуры запустят продуктивные RAG-контуры и внутренние ассистенты. Спрос сместится от аренды «сырых» GPU к управляемым сервисам с встроенной фильтрацией промптов, журналированием и контролем цепочки данных.</p> <p>В 2028 году ожидается рост доли до <nobr>33-38%</nobr> и объема до <nobr>62-78</nobr> млрд рублей. Массовое дообучение моделей на корпоративных данных станет стандартом. AI Firewall и контроль цепочки поставки модели превратятся из конкурентного преимущества в обязательное требование. Регулятор, вероятно, утвердит отраслевые стандарты безопасности для ИИ-инфраструктуры, аналогичные требованиям к КИИ.</p> <p>К 2029 году доля AI-IaaS достигнет <nobr>42-48%,</nobr> объем — <nobr>95-115</nobr> млрд рублей. Доминирующим сценарием станут мультиагентные системы и автономные бизнес-процессы, в которых модель не просто отвечает на запрос, а инициирует действия в CRM, ERP и платежных контурах. Это увеличит требования к разграничению прав инструментов и непрерывному мониторингу дрейфа.</p> <p>Наконец, к 2030 году более половины инфраструктурных расходов российских компаний, использующих облака, будет приходиться на ИИ-нагрузки: инференс, дообучение, хранение векторных баз, оркестрацию GPU-заданий и обеспечение безопасности цепочки принятия решений модели. Обучение крупных моделей с нуля остается нишевым из-за стоимости и ограничений на поставки передовых ускорителей. Прогнозируемая доля — <nobr>50-55%,</nobr> абсолютный объем — <nobr>130-160</nobr> млрд рублей. AI-IaaS станет базовым слоем корпоративной ИТ-архитектуры, а не надстройкой над классическим облаком.</p> <p>Ускоренный сценарий роста сегмента AI-IaaS реализуется при государственных программах субсидирования и обязательном внедрении ИИ в госуслуги и КИИ. Рост может достичь <nobr>35-40%</nobr> в год, к 2030 году AI-IaaS займет более 60% облачных расходов. Сформируются отраслевые ИИ-платформы с жесткой изоляцией.</p> <p>С другой стороны, сдержанный сценарий наступит при дефиците GPU, ужесточении экспортных ограничений и замедлении корпоративных бюджетов. Рост ограничится <nobr>18-22%</nobr> в год, и к 2030 году доля AI-IaaS не превысит <nobr>35-40%,</nobr> значительная часть нагрузок остается в on-premise.</p> <p>К 2030 году российский облачный рынок завершит переход от парадигмы «аренда серверов» к парадигме «управление цепочкой принятия решений модели». Для российских компаний и провайдеров окно стратегического маневра открыто в <nobr>2026–2028 годах,</nobr> после чего архитектура рынка будет определяться теми, кто первым встроил безопасность, суверенитет и наблюдаемость в архитектуру ИИ-инфраструктуры.</p> Российский облачный рынок проходит через структурную трансформацию, сравнимую по масштабу с переходом … message https://www.itweek.ru/themes/detail.php?ID=235455 Thu, 03 Sep 2026 15:40:39 +0300 <p>Эксперты компании «Информзащита» выявили, что в 2026 году средства удаленного доступа использовались в 62% киберинцидентов, не связанных с компрометацией деловой электронной почты. В 2025 году их доля составляла 49%, за год показатель вырос на 13 п. п. В эту категорию входят атаки через RDP, VPN и системы удаленного мониторинга и управления RMM.</p> <p>Причина такой динамики связана прежде всего с тем, что удаленный доступ изначально предполагает возможность подключения к корпоративной инфраструктуре извне. VPN-шлюзы, серверы RDP и RMM-платформы используются администраторами, подрядчиками, технической поддержкой и сотрудниками филиалов, поэтому полностью убрать их из внешнего контура во многих компаниях невозможно. Для атакующего такой сервис представляет удобную точку входа. При наличии действующей учетной записи или возможности обойти механизм аутентификации ему не требуется доставлять сложное вредоносное ПО на рабочую станцию пользователя. Активность может начинаться с обычного подключения к легитимному сервису и внешне выглядеть как действия штатного специалиста.</p> <p>Пароли от VPN, RDP и административных систем попадают в руки злоумышленников после фишинговых кампаний, заражений инфостилерами, утечек из сторонних сервисов и компрометации подрядчиков. Риск возрастает там, где для удаленного подключения не используется MFA, разрешена парольная аутентификация без дополнительных факторов, учетные записи годами сохраняют избыточные права, а доступ открыт для широкого диапазона внешних адресов. Отдельная проблема связана с сервисными и техническими учетными записями. Они реже используются людьми в повседневной работе, поэтому смена паролей и пересмотр привилегий для них нередко откладываются. При этом именно такие записи могут давать расширенный доступ к инфраструктуре.</p> <p>Разбивка по основным векторам первоначального проникновения показывает, что удаленный доступ заметно опережает эксплуатацию программных уязвимостей. На RDP, VPN, RMM и другие внешние средства удаленного подключения приходится 65% инцидентов вне BEC. Еще 11% связаны с эксплуатацией известных уязвимостей, причем в рассмотренных случаях исправления для них уже существовали. Годом ранее доля этого вектора достигала 29%. Еще 8% пришлось на ошибки конфигурации и злоупотребление доверенными связями, хотя ранее их совокупная доля не превышала 1%. Оставшиеся около 16% распределяются между другими сценариями первоначального доступа, включая загрузку вредоносного ПО, социальную инженерию и менее распространенные способы компрометации. Получается, что злоумышленники все чаще выбирают сценарии, в которых можно использовать уже существующую инфраструктуру доступа и доверия, вместо разработки отдельного эксплойта.</p> <p>Рост доли удаленного доступа объясняется и архитектурой корпоративных сетей. Пограничные устройства часто совмещают несколько функций и обладают высокими привилегиями. Компрометация VPN-шлюза, RMM-сервера или системы администрирования может сразу дать атакующему возможность работать с несколькими сегментами сети. После входа начинается сбор информации об инфраструктуре, поиск доменных учетных записей, повышение привилегий и горизонтальное перемещение. Скорость такого сценария заметно выше, когда удаленный сервис уже интегрирован с Active Directory, имеет доверительные отношения с другими системами или позволяет запускать команды на множестве рабочих станций. В расследованиях фиксировались случаи, когда после первоначального доступа злоумышленники переходили к контролю доменной инфраструктуры за считанные минуты.</p> <p>Наиболее заметные риски формируются в отраслях, где удаленное администрирование используется постоянно и охватывает большое число систем. В здравоохранении показатель составил 33%, в образовании — 25%. Эти значения нельзя напрямую приравнивать к доле атак через RDP, VPN или RMM из статистики расследований, поскольку использовалась другая методика, однако отраслевой разрез показывает, где проблемы с безопасностью удаленного доступа проявляются особенно часто. Для технологических и сервисных компаний риск связан с большим числом административных подключений и клиентских сред, для промышленности — с сочетанием удаленного обслуживания и устаревающей инфраструктуры, а для здравоохранения и образования — с большим числом разнородных систем и ограниченными возможностями быстро менять их конфигурацию.</p> <p>Отдельное внимание требуется RMM-платформам. Такие системы создавались именно для централизованного управления парком устройств, поэтому их функции совпадают с тем, что нужно атакующему после проникновения. Через легитимный агент можно запускать команды, устанавливать программное обеспечение, передавать файлы и управлять удаленной машиной. Это осложняет детектирование, поскольку сам факт запуска RMM-клиента не является признаком атаки. Аналогичная проблема возникает с VPN. Успешная аутентификация с корректными учетными данными может не вызвать срабатывания средств защиты, хотя подключение выполняется злоумышленником. Поэтому контроль только вредоносных файлов и сигнатур сетевых атак не закрывает этот сценарий.</p> <p>Снижать риск необходимо одновременно на уровне идентификации пользователя, сетевой архитектуры и мониторинга. Для всех внешних административных подключений необходимо использовать MFA и по возможности отказаться от факторов, которые можно повторно применить после кражи учетных данных. Прямой RDP-доступ из интернета следует исключить, а VPN и RMM-сервисы ограничить по источникам подключения и доступным сегментам. Административные и сервисные учетные записи необходимо отделять от пользовательских, сокращать их привилегии и регулярно менять учетные данные, особенно после устранения уязвимостей на пограничных устройствах. Логи VPN, RDP, RMM, служб каталогов и средств защиты конечных точек должны анализироваться совместно, поскольку аномалия часто заметна не в самом факте подключения, а в последовательности действий после него. Дополнительный эффект дают сегментация сети, контроль новых RMM-инструментов, ограничение административных интерфейсов и регулярная инвентаризация всех внешних сервисов. При доле удаленного доступа в 65% инцидентов защита этого контура должна рассматриваться как отдельная задача управления доступом, а не только как часть стандартной настройки сетевого периметра.</p> Эксперты компании «Информзащита» выявили, что в 2026 году средства удаленного доступа использовались в 62% … message https://www.itweek.ru/themes/detail.php?ID=235453 Thu, 03 Sep 2026 09:49:23 +0300 <p><em>Опрос разработчиков, проведенный компанией Coddy, </em><a href="https://coddy.tech/blog/coding-for-beginners/ai-coding-addiction-report"><em>показал</em></a><em>, что программирование с помощью искусственного интеллекта приводит к новому виду эмоционального выгорания, сообщает портал </em><em>ZDNet</em><em>.</em></p> <p>Наверное, в этом нет ничего неожиданного. Благодаря GitHub Copilot, Claude Code, Cursor и любого другого нового ИИ-инструмента для разработчиков, вы как программист можете выполнять больше работы, чем когда-либо прежде. Но даже несмотря на то, что разработчики все чаще используют их для создания шаблонов, объяснения незнакомого кода, составления тестов, рефакторинга модулей и устранения неполадок, многие из них также обнаруживают, что те же самые инструменты могут вызывать проблемы.</p> <h3>Трудоголизм, вызванный ИИ</h3> <p>«Сейчас 2:47 ночи... Я не устраняю сбой. Крайнего срока нет. Я просто наблюдаю, как Claude Code проводит рефакторинг модуля... и я не могу отвести взгляд», — пишет в своем посте в LinkedIn Квентин Руссо, технический директор и соучредитель компании Rootly, занимающейся отчетами об инцидентах на основе ИИ. Почему так происходит? Потому что, продолжает он, «агентное кодирование вызывает привыкание. Когда агент делает все правильно, ты получаешь дофаминовый заряд. Когда это не удается, ты испытываешь прилив адреналина». Руссо признается, что не мог спать и был вынужден обратиться за медицинской помощью.</p> <p>В этом нет ничего удивительного. Программисты уже давно склонны к трудоголизму. Однако ИИ придал работе новый темп, когда, как выразился Руссо, «наблюдение за работой агента достаточно пассивно, чтобы не чувствовать усталости, и достаточно активно, чтобы держать вас на крючке». В результате возникает новый вид эмоционального выгорания.</p> <p>Это не просто опыт одного программиста. ИИ-кодирование может превратить разработку ПО в непрерывный цикл обратной связи. Вместо того, чтобы завершить задачу и отвлечься, разработчики могут постоянно просить агента о другой реализации, переписывании, оптимизации или рефакторинге, или сочетать это с беспокойством о том, что остановка означает невыполнение работы.</p> <h3>Когда ИИ становится не помощником, а кандалами</h3> <p>Компания Coddy Tech, занимающаяся обучением программированию, в ходе опроса 305 разработчиков выяснила, что для 80% из них использование ИИ больше похоже на зависимость, чем на преимущество. Конечно, они находят эти инструменты полезными, но они также обеспокоены тем, что возникновение привычки зависеть от ИИ ослабляет их собственные возможности решения проблем, увеличивает их рабочую нагрузку и формирует нездоровые отношения с работой.</p> <p>Согласно отчету, 43% респондентов продолжают программировать с помощью ИИ в нерабочее время, даже когда они собирались остановиться, а 32% откладывают сон, чтобы продолжить работу. Кроме того, 39% опрошенных отмечают, что инструменты ИИ усложняют возможность отключиться от рабочего процесса.</p> <p>Дело не только в том, что инструменты ИИ вызывают привыкание. 74% разработчиков сообщают, что интенсивное использование ИИ увеличивает вероятность повышения зарплаты или продвижения по службе. Однако 51% также заявляют, что у них стало больше шансов перегореть.</p> <h3>Доверяй, но проверяй: ИИ не безупречен</h3> <p>Как показал опрос Stack Overflow «2025 Developer Survey», 45% респондентов разочарованы ответами ИИ, которые могут быть «почти правильными, но не совсем». В результате вывод выглядит убедительно, но приводит к сложной работы по отладке.</p> <p>Исследование Stack Overflow также показало, что, хотя внедрение инструментов ИИ продолжает расти и в настоящее время 80% разработчиков используют их в своих рабочих процессах, доверие к точности ИИ упало с 40% в предыдущие годы до всего лишь 29% в этом году. В результате положительное отношение программистов к ИИ за год снизилось с 72 до 60%.</p> <p>С одной стороны, повышается удобство использования, с другой — растет рабочая нагрузка разработчика. Помимо попыток понять, насколько правильно угадал ИИ, они должны понимать требования, распознавать конфликты сгенерированного кода с архитектурой системы, тестировать крайние случаи, устранять риски безопасности и нести ответственность за последствия в производственной среде.</p> <p>Это создает «долг верификации». Результат появляется быстро, но вы все равно вынуждены устанавливать, является ли он правильным, безопасным, поддерживаемым и подходящим для конкретной кодовой базы.</p> <p>Кроме того, зависимость, описанная в исследовании Coddy, может быть усилена тем, как работодатели интерпретируют результаты, полученные с помощью ИИ. Если организация рассматривает ИИ как способ увеличить возможности разработчиков, сотрудники могут столкнуться с необходимостью предоставлять больше функций, закрывать больше заявок и выполнять больше проверок за то же количество часов.</p> <p>Это, в свою очередь, может привести к тому, что время, сэкономленное на отдельных задачах по кодированию, будет перенаправлено на другие задачи: больше запросов на слияние, больше сгенерированных изменений для проверки, больше зависимостей для проверки и больше операционных рисков для управления.</p> <p>Таким образом, ИИ-кодирование становится вопросом баланса работы и отдыха в не меньшей степени, чем вопрос применения ИИ-инструментов. Команды, которые используют агентов для устранения рутинного труда, могут увидеть реальные преимущества. Команды, которые используют их для ускорения каждого этапа разработки ПО, рискуют создать более быструю и безжалостную версию той же работы.</p> <p>Для разработчиков, таких как Руссо, проблема уже не только в том, может ли ИИ писать код. Он может. Вопрос теперь заключается в том, могут ли разработчики по-прежнему решать, когда заканчивается их рабочий день и цикл работы агента.</p> Опрос разработчиков, проведенный компанией Coddy, показал, что программирование с помощью искусственного интеллекта приводит … article https://www.itweek.ru/themes/detail.php?ID=235451 Thu, 03 Sep 2026 09:40:30 +0300 <p><em>Обсудим, п</em><em>очему в 2026 году чистый инхаус всё чаще проигрывает гибридной модели</em><em>.</em></p> <p>В России <a href="https://www.interfax.ru/russia/1028484">работает</a> около 1 млн. ИТ-специалистов, но дефицит кадров, по оценкам Минцифры, всё еще составляет <nobr>500-700 тыс.</nobr> человек. Параллельно растет<a href="https://marketing.rbc.ru/research/52099/"> рынок ИТ-аутсорсинга</a>: в 2024 году его оборот достиг 262 млрд. руб., рост на 24% к предыдущему году. Согласно исследованию CNews Research, <a href="https://codingteam.ru/blog/autsorsing-razrabotchikov-v-2025-kogda-vigodnee-na">более 72% компаний</a> с цифровыми продуктами привлекают внешних разработчиков хотя бы на одном из этапов жизненного цикла проекта. Вопрос «нанять своего или взять подрядчика» остается одним из самых частых у малого и среднего бизнеса. Однозначного ответа нет, но есть конкретные критерии, которые помогают сделать выбор.</p> <h3>Экономика вопроса: сколько стоит собственный разработчик</h3> <p>По данным <a href="https://habr.com/ru/specials/1060148/">«Хабр Карьеры»</a>, в первой половине 2025 года медианная зарплата ИТ-специалиста в России составила 191 тыс. руб./мес — на 4% больше, чем во втором полугодии 2025 года. В Москве этот показатель уже 235 тыс. руб./мес.</p> <p>К зарплате прибавляются страховые взносы <nobr>(15-30%</nobr> сверху в зависимости от статуса компании), оборудованное рабочее место, лицензии на ПО, корпоративное обучение, время HR на поиск и онбординг. Реальная нагрузка на бизнес примерно на <nobr>30-40%</nobr> выше окладной части. Мидл-разработчик в Москве обходится компании в <nobr>270-350 тыс.</nobr> руб./мес, а годовой бюджет на одного специалиста стартует от 3,2 млн. руб.</p> <p>Сравним с аутсорсом. Час работы мидла в агентстве — <nobr>3-5 тыс.</nobr> руб., у проверенного фрилансера — <nobr>2-3 тыс.</nobr> руб. На бюджет одного штатного разработчика можно купить <nobr>800-1200</nobr> часов внешней разработки в год. Этого хватает почти любому бизнесу, который не строит вокруг сайта основной продукт.</p> <h3>Рынок поменялся: ситуация в 2026 году</h3> <p>Картина в ИТ-найме за последние два года резко изменилась. По данным <a href="https://trends.rbc.ru/trends/social/cmrm/698da33a9a79474de4341261">hh.ru и «РБК Трендов»</a>, количество вакансий в ИТ просело примерно на 20%, а активных резюме стало больше на четверть. На одну вакансию сейчас приходится <nobr>12-15 кандидатов.</nobr></p> <p>Однако нанимать стало не проще. Дефицит сместился в сторону точечной экспертизы: архитекторы, специалисты по информационной безопасности, инженеры данных, DevOps. Мидлы и сеньоры с конкретным сочетанием технологий по-прежнему уходят с рынка за <nobr>1-2 недели.</nobr> Зарплатные ожидания продолжают расти: за год средняя по веб-разработке поднялась на <nobr>10-15%.</nobr></p> <p>Для бизнеса это означает простую вещь: окно «найму своего, пока недорого» закрылось. Экономика инхауса работает только при стабильной загрузке.</p> <h3>Когда инхаус оправдан</h3> <p>Свой разработчик окупается в четырех сценариях.</p> <ul> <li><strong>Постоянный поток задач.</strong> Если на сайте каждый день что-то меняется — тесты гипотез, новые лендинги, доработки личного кабинета, интеграции с маркетплейсами — внешний подрядчик тормозит процессы.</li> <li><strong>Глубокая связка с бизнес-логикой.</strong> Кастомные системы управления взаимоотношениями с клиентами (CRM), ERP, нестандартные процессы обработки заказов требуют погружения в специфику. Подрядчик, который параллельно ведет десяток клиентов, не удержит в голове все нюансы.</li> <li><strong>Чувствительные данные и безопасность.</strong> Когда сайт обрабатывает персональные или финансовые данные, важна предсказуемость доступов и зон ответственности.</li> <li><strong>Сайт как продукт.</strong> Если приложение или платформа — ядро бизнеса, отдавать их разработку наружу стратегически рискованно.</li> </ul> <h3>Когда выгоднее аутсорс</h3> <p>Большинству небольших и средних компаний штатный разработчик не нужен. Аутсорс выигрывает, когда:</p> <ul> <li> сайт меняется редко: раз в месяц-два появляется новая страница, баннер или акция;</li> <li> нужны специфические компетенции на короткий срок — например, разработка мобильного приложения или интеграция со специфической платежной системой;</li> <li> бизнес сезонный: летом нагрузка одна, зимой другая, и держать постоянного разработчика нерационально;</li> <li> стартап проверяет гипотезы, и пока непонятно, какой технический стек нужен в долгую.</li> </ul> <p>У многих небольших интернет-магазинов нет ни одного разработчика в штате — и при этом их сайты работают годами.</p> <h3>Гибрид — самый частый сценарий</h3> <p>Чаще всего выстраивается гибридная модель. У бизнеса есть один технический специалист уровня тимлида или продакт-менеджера, а основная разработка идет на стороне.</p> <p>Этот человек знает бизнес и продукт изнутри. Управляет подрядчиками, ставит задачи, принимает работу. Закрывает срочные инциденты: отвалилась форма заказа, упала страница, нужно за час добавить виджет под акцию.</p> <p>Гибрид закрывает главную слабость аутсорса — отсутствие человека, который держит в голове всю картину. И не требует найма команды из трех-пяти разработчиков.</p> <h3>На что смотреть при выборе подрядчика</h3> <p>Перед подписанием договора стоит проверить четыре вещи.</p> <ul> <li><strong>Регламент реагирования на инциденты.</strong> Узнайте, что произойдет, если сайт упадет в субботу вечером. У хорошего подрядчика прописаны SLA с конкретными временами реакции. У плохого — общие слова про «оперативное решение».</li> <li><strong>Доступы и документация.</strong> Код, доступы к хостингу, репозитории, базы данных принадлежат вам, а не подрядчику. Регулярно видим истории, где владелец бизнеса не может попасть на собственный сайт, потому что всем владеет агентство, с которым испортились отношения.</li> <li><strong>Передача дел.</strong> Что произойдет, если решите сменить подрядчика? Хорошая команда умеет передавать проекты и не пытается удерживать клиента собственной незаменимостью.</li> <li><strong>Прозрачность отчетности.</strong> Часы, задачи, статусы видны заказчику. Любая модель «доверьтесь нам, мы всё сделаем» в долгосрочной перспективе превращается в проблему.</li> </ul> <h3>Как принять решение: три вопроса самому себе</h3> <p><strong>Сколько часов разработки реально нужно в месяц?<br/> </strong>Меньше <nobr>60-80 —</nobr> аутсорс. Стабильно больше <nobr>120-160 —</nobr> пора думать про штат. </p> <p><strong>Насколько уникален продукт?</strong><br/> Сайт-визитка, типовой интернет-магазин на готовом движке, корпоративный портал на коробочном решении — аутсорс. Сложный сервис с собственной бизнес-логикой — инхаус или гибрид. </p> <p><strong>Готовы быть работодателем для разработчика?<br/> </strong>Если в команде нет человека, который понимает в разработке хотя бы на уровне тимлида, штатный сотрудник быстро превращается в черный ящик: непонятно, как его оценивать, что он делает и за что ему платить. </p> <p>Главная ошибка, которую мы видим в малом и среднем бизнесе — найм разработчика «на вырост». Компания берет человека в расчете на будущие задачи, но будущее не наступает, специалист недозагружен, а 3 млн. руб. в год продолжают уходить с расчетного счета. Простая проверка: если реальный объем задач занимает меньше 70% рабочего времени разработчика, штат не окупится. Считайте не зарплату, а часовую ставку и фактический объем работы, и берите подрядчика, пока стабильная загрузка не подтвердилась цифрами хотя бы за полгода.</p> <p>#IMAGE_235452#</p> Обсудим, почему в 2026 году чистый инхаус всё чаще проигрывает гибридной модели. В России работает около 1 млн … article Алексей Солдатов, руководитель технической поддержки SpaceWeb https://www.itweek.ru/themes/detail.php?ID=235449 Wed, 02 Sep 2026 14:34:58 +0300 <p>Yandex B2B Tech запустила Yandex BareMetal Extend — решение, с помощью которого компании могут получить готовую инфраструктуру на выделенных серверах без закупки и поддержки дорогостоящего оборудования. В отличие от классических частных облаков, в новом решении инфраструктура заказчика физически отделена от публичного облака. Yandex BareMetal Extend позволит бизнесу сохранять повышенный контроль над инфраструктурой, но при этом не потерять гибкость и скорость разработки. Уже сейчас можно оставить заявку на сайте и получить консультацию.</p> <p>Yandex BareMetal Extend — это не классическое решение по аренде «железа». В нем есть три заранее преднастроенных модуля: виртуализация, Kubernetes<sup class="reg">®</sup> и платформа для разработки приложений Stackland. В зависимости от задач компания может выбрать один из них и развернуть на выделенных серверах контейнерные приложения или критичные бизнес-системы. ИТ-командам компаний не придется самостоятельно поддерживать виртуальные мощности. По данным Atlassian DX Report, 50% разработчиков теряют более 10 часов в неделю на непрофильную работу. </p> <p>Партнером по разработке решения с виртуализацией стал облачный провайдер с экспертизой интегратора K2 Cloud. Совместно со специалистами Yandex Cloud компания будет оказывать техническую поддержку клиентам в формате единого окна. </p> <p>«Крупным компаниям важно одновременно соблюдать требования информационной безопасности и сокращать время на запуск ИТ-систем. В Yandex BareMetal Extend клиент получает выделенную инфраструктуру с уже настроенной средой, поэтому команде не нужно самостоятельно собирать и поддерживать её из отдельных компонентов. Мы отдаём клиенту не набор компонентов для самостоятельной сборки, а среду, готовую к работе с первого дня аренды», — рассказал Иван Пузыревский, технический директор платформы Yandex Cloud.</p> <p>«У K2 Cloud большой опыт создания изолированной программной среды для крупного бизнеса — с соответствием требований ИБ, аттестациями и строгими SLA. Мы объединили нашу экспертизу с технологиями Yandex Cloud и получили уникальное решение. Заказчики получат готовую изолированную инфраструктуру с управлением виртуальными ресурсами из единого интерфейса под критичные системы», — отметил Сергей Зинкевич, CEO K2 Cloud.</p> <p>Yandex BareMetal соответствует первому уровню защищённости персональных данных и обеспечивает защиту на уровнях ЦОД, сети и сервиса. Клиенты также могут резервировать ресурсы и объединять инфраструктуру на выделенных серверах с помощью приватного соединения.</p> Yandex B2B Tech запустила Yandex BareMetal Extend — решение, с помощью которого компании могут получить готовую … message https://www.itweek.ru/themes/detail.php?ID=235444 Wed, 02 Sep 2026 10:10:22 +0300 <p><em>За тридцать лет индустрия информационной безопасности пережила несколько технологических сдвигов, но ни один из них не менял расстановку сил так быстро, как генеративный ИИ. Раньше между появлением нового класса атак и его массовым применением проходили годы: злоумышленникам нужно было время, квалификация и инфраструктура. Сегодня этот барьер обрушился. Написать фишинговое письмо на безупречном русском, собрать досье на жертву, сгенерировать вариант вредоносного кода, обходящий сигнатурный детектор, — всё это стало доступно человеку без глубокой технической подготовки и занимает минуты, а не недели. </em><em>Рассмотрим, </em><em>к</em><em>ак эволюционировали методы кибератак с появлением ИИ</em><em>.</em></p> <p>Масштаб перемен уже поддаётся измерению. По данным отчёта Bugcrowd Inside the Mind of a Hacker, к концу 2025 года 82% исследователей (в том числе действующих не по правилам; против 64% в <nobr>2023-м)</nobr> применяли ИИ в своей работе. Искусственный интеллект перестал быть экзотикой в арсенале атакующего и стал рабочим инструментом по умолчанию.</p> <p>Эволюцию «наступательного» ИИ удобно разложить на три волны, которые не сменяют, а наслаиваются друг на друга.</p> <h3>Три этапа взросления атакующих нейросетей</h3> <p>Первая волна — автоматизация рутины. Здесь ИИ не принимает решений, а масштабирует то, что человек и так делал руками: генерирует тексты фишинга, переводит их на десятки языков без характерных ошибок, пишет шаблоны, парсит открытые источники. Это уже полностью реальность и массовая практика. Стоимость подготовки убедительной атаки упала на порядок, а качество — выросло.</p> <p>Вторая волна — ассистирование в сложных задачах. ИИ становится «вторым пилотом» атакующего: помогает разобраться в незнакомом коде, предлагает варианты эксплуатации уязвимости, адаптирует полезную нагрузку под конкретное окружение, ведёт разведку и приоритизирует цели. Решение по-прежнему за человеком, но скорость и охват растут кратно. Именно на этом этапе мы находимся сейчас.</p> <p>Третья волна — автономное принятие решений. Это агентные системы, которые получают цель («получить доступ к сегменту сети») и самостоятельно строят цепочку действий: разведка → выбор вектора → эксплуатация → закрепление → латеральное перемещение, реагируя на обратную связь от среды без участия оператора. Полноценных автономных атакующих агентов «в дикой природе» пока единицы, и они несовершенны, но направление обозначено предельно чётко. Именно к этому сценарию защиты нужно готовиться уже сегодня, а не когда он станет мейнстримом.</p> <h3>Что случилось с классическими векторами</h3> <p>Важно понимать: генеративный ИИ не создал новых классов атак. Фишинг, социальная инженерия и вредоносное ПО были и двадцать лет назад. ИИ изменил их экономику и качество.</p> <ul> <li><strong>Фишинг</strong>. Раньше защитой служили сами письма: корявый язык, нелепые обращения, кривая верстка — «маркеры мошенника», которым учили сотрудников. Генеративные модели эти маркеры стёрли. Показателен рубеж, зафиксированный в сети детектирования Hoxhunt: несколько лет доля писем с признаками ИИ-генерации держалась ниже 5%, а в декабре 2025 года подскочила примерно в 14 раз — до 56% всех выявленных атак. Изменилась и экономика: по оценкам, приводимым в индустриальных отчётах, LLM сократили время подготовки убедительной кампании с примерно 16 часов ручной работы до нескольких минут, а затраты на массовую рассылку упали примерно на 95%. Письмо теперь грамотное, персонализированное под должность и контекст получателя, а массовая кампания легко превращается в тысячи уникальных вариантов, каждый из которых обходит фильтры по «шаблонности».</li> <li><strong>Социальная инженерия</strong><strong>.</strong> Здесь качественный скачок дали дипфейки. Хрестоматийный пример — инцидент с инженерной компанией Arup в начале 2024 года: сотрудника финансового отдела в Гонконге убедили провести 15 переводов на общую сумму около 25 млн. долл. после видеозвонка, на котором все «руководители», включая финансового директора, были сгенерированы ИИ. И это не единичный случай: по оценке Surfshark на основе AI Incident Database, совокупные потери от дипфейк-мошенничества к концу прошлого года достигли порядка 1,56 млрд. долл., причём более 1 млрд. пришлось только на 2025 год. Опаснее всего то, что человек здесь беззащитен по природе: в контролируемых исследованиях качественные видео-дипфейки люди правильно распознают лишь примерно в четверти случаев. Доверие к «знакомому лицу и голосу» из защитного механизма превратилось в вектор атаки.</li> <li><strong>Вредоносное ПО</strong><strong>.</strong> ИИ ускорил разработку и, что опаснее, — вариативность. Полиморфный код, который на каждой итерации меняет структуру, сохраняя функциональность, генерируется теперь программно и в промышленных объёмах. Для сигнатурного детектирования это тяжёлый удар: сигнатура ловит известное, а машина производит бесконечный поток «нового».</li> <li><strong>Пентест.</strong> Автоматизация многих этапов внешнего и внутреннего тестирования на проникновение с помощью нейросетей значительно сокращает время от обнаружения уязвимого ресурса до получения доступа во внутреннюю инфраструктуру. Разница и преимущество опытного оператора с нейростью перед специалистом без такого инструмента сразу заметны. Там, где человеческий глаз и подход могут не заметить сложную уязвимость, ИИ может показать новый вектор или атаку, находя решение даже в самых сложных условиях.</li> </ul> <p>#IMAGE_235448#</p> <p>Как показывает <a href="https://www.first.org/blog/20260615-vulnerability-forecast-update">The 2026 Vulnerability Forecast Update</a>, в этом году ожидается 66 000 новых публичных CVE, что на 46,3% выше первоначального прогноза в 2026 году. Это на 37% больше по сравнению с <nobr>2025-м,</nobr> в котором нашли <a href="https://www.stingrai.io/blog/vulnerability-statistics-2026">48 185 CVE</a>, и на 20% больше чем в <nobr>2024-м</nobr> (40 009 CVE). По прогнозу заметна высокая динамика, и с помощью нейросетей теперь обнаруживают намного больше новых <nobr>0-day</nobr> уязвимостей.</p> <h3>Гонка вооружений: где был переломный момент</h3> <p>Противостояние атакующих и защитных алгоритмов — не новость. ML в антивирусах и системах обнаружения вторжений применяется больше десяти лет: поведенческий анализ, классификаторы вредоносных файлов, детекторы аномалий появились задолго до нынешнего хайпа. Массовый разворот защиты в сторону ИИ произошёл в конце <nobr>2010-х,</nobr> когда EDR- и NGAV-решения сделали машинное обучение стандартом, а не экзотикой.</p> <p>Настоящий перелом наступил в <nobr>2022-2023 годах,</nobr> с выходом больших языковых моделей в широкий доступ. До этого преимущество в автоматизации было скорее на стороне защиты — у неё было больше ресурсов и данных. Генеративный ИИ впервые дал атакующему инструмент такой же мощности, что и у обороняющегося, и почти бесплатно. Симметрия нарушилась: порог входа в качественную атаку упал быстрее, чем успела адаптироваться защита. Именно этот разрыв мы сейчас и наблюдаем.</p> <h3>Какие задачи атакующие уже делегируют машине</h3> <p>Если рассмотреть по отдельности каждый из этапов проникновения с точки зрения атакующего, ИИ сегодня применяется почти в каждом из них:</p> <ul> <li> <strong>Разведка (recon).</strong> Сбор и категоризация больших объемов данных по компании из открытых источников, составление карты внешнего периметра, анализ утечек и построение профилей сотрудников. То, что раньше отнимало у аналитка дни, модель делает за десятки минут.</li> <li> <strong>Активная эксплуатация</strong>. Пентест-агенты позволяют проанализировать каждый из обнаруженных ресурсов как если бы это делал реальный злоумышленник — использовать инъекции, анализировать поведение приложения на различные запросы, обнаруживать сложные цепочки уязвимостей, и все это автоматически.</li> <li><strong>Социальная инженерия.</strong> Генерация фишинга и приманок. Уникальные письма, поддельные страницы, легенды для переписки — под конкретную жертву и её контекст. Сюда же относятся дипфейки: голос и видео для обхода процедур подтверждения личности и «звонка руководителя».</li> <li><strong>Разработка и мутация ПО.</strong> Написание и обфускация полезной нагрузки, генерация полиморфных вариантов, адаптация под окружение.</li> <li><strong>Полноценная имитация атакующего.</strong> Пентест-агенты позволяют проанализировать сайт как если бы это делал реальный злоумышленник — использовать инъекции, анализировать поведение приложения на различные запросы, обнаруживать сложные цепочки уязвимостей, генерация proof-of-concept под свежие багии помощь в написании эксплойтов, и все это автоматически.</li> </ul> <p>Отдельно — обход защиты. Генеративные модели используются для мимикрии под легитимный трафик: вредоносная активность «размазывается» так, чтобы статистически не отличаться от нормального поведения пользователя или приложения, а команды управления прячутся в обычных на вид запросах. Это прямая атака на детекторы аномалий, построенные на «отклонении от нормы».</p> <h3>Как ИИ работает на стороне защиты: SOC, SIEM, поведенческий анализ</h3> <p>Хорошая новость в том, что те же технологии усиливают и оборону — причём защита научилась применять ИИ раньше и системнее.</p> <p>В современных SOC и SIEM-системах машинное обучение решает главную боль аналитика — шум. Классические корреляционные правила генерируют тысячи срабатываний, большинство из которых ложные. <nobr>ML-модели</nobr> строят поведенческий базлайн (UEBA, анализ поведения пользователей и сущностей): что для конкретного аккаунта, сервера или сервиса является нормой по времени, объёму, географии, набору действий. Отклонение от этого профиля — сигнал, даже если формально ни одно сигнатурное правило не сработало. Именно так ловятся атаки, у которых нет известной сигнатуры.</p> <p>По эффективности для сложных угроз можно выделить несколько подходов:</p> <ul> <li> <strong>Обучение без учителя (кластеризация, детекторы аномалий)</strong> — для zero-day и незнакомых атак, где нет размеченных примеров. Модель ищет не «известное плохое», а «непохожее на нормальное».</li> <li><strong> Графовые модели и анализ последовательностей</strong> — для APT и латерального перемещения. Продвинутая целевая атака растянута во времени и складывается из событий, каждое из которых по отдельности выглядит безобидно. Увидеть её можно только как цепочку — граф связей между хостами, аккаунтами и процессами.</li> <li><strong> Рекуррентные и трансформерные архитектуры</strong> — для анализа временных рядов событий и выявления аномального контекста в потоке логов.</li> <li><strong> Модели на данных цепочки поставок</strong> — для атак через доверенных поставщиков, где вредоносный код приходит легитимным каналом обновления и требует анализа отклонений в самом артефакте, а не в сети.</li> </ul> <p>Ни один из этих методов не самодостаточен. Работает ансамбль: сигнатуры закрывают известное дёшево и точно, ML — неизвестное и поведенческое. И это окупается: по данным отчёта IBM Cost of a Data Breach 2025, организации, широко применяющие ИИ и автоматизацию в безопасности, обнаруживают и локализуют инциденты заметно быстрее и с ощутимо меньшими издержками, чем те, кто этого не делает.</p> <p>Предиктивные модели угроз пытаются ответить на вопрос «где ударят следующим». Они анализируют профиль организации, её поверхность атаки, историю инцидентов в отрасли, активность конкретных группировок и приоритизируют риски: какие активы и какие уязвимости с наибольшей вероятностью станут целью.</p> <p>Дефицит кадров в ИБ — структурная проблема, и здесь ИИ даёт ощутимый эффект. Системы SOAR (оркестрация, автоматизация и реагирование) берут на себя рутину: обогащение инцидента данными, первичную сортировку, изоляцию заражённого хоста, блокировку индикатора компрометации по готовому сценарию (playbook). Языковые модели добавляют к этому автоматическое резюмирование инцидента и черновики отчётов.</p> <p>Смысл не в том, чтобы заменить аналитика, а в том, чтобы он занимался расследованиями, а не перекладыванием тикетов. Когда 80% типовых срабатываний обрабатывается автоматически, у человека высвобождается время на то, что машине пока не по силам, — сложные, нестандартные, целевые атаки. Тут важно предостеречь: полная автоматизация реагирования без контроля человека опасна, потому что автономный ответ на ложный или спровоцированный сигнал сам становится вектором атаки — злоумышленник может намеренно заставить защиту «выстрелить себе в ногу».</p> <h3>Цикл «атака — защита», когда с обеих сторон ИИ</h3> <p>Мы движемся к ситуации, где и атакующий, и обороняющийся — это алгоритмы, соревнующиеся в скорости адаптации. Атакующая модель генерирует вариант, обходящий детектор; защитная — учится его ловить; атакующая — генерирует следующий. Цикл, который раньше измерялся месяцами, сжимается до дней и часов, а на этапе исполнения — до секунд. По данным CrowdStrike, среднее «время прорыва» (от первичной компрометации до первого латерального перемещения) в 2025 году составило 29 минут — на 65% быстрее, чем годом ранее, а рекордный показатель — 27 секунд; передача доступа от брокера первичного доступа к операторам вымогательского ПО, по данным Mandiant, сжалась до 22 секунд. Тот же CrowdStrike фиксирует рост ИИ-опосредованных атак примерно на 89% год к году.</p> <p>Кто выигрывает в такой гонке? Тот, у кого качественнее данные и быстрее петля обратной связи. И здесь у защиты есть структурное преимущество, о котором часто забывают: обороняющийся видит свою инфраструктуру целиком, а атакующий — только снаружи и по частям. Это преимущество работает при одном условии — если защита действительно видит всё. Слепые зоны — забытые тестовые серверы, теневые облачные сервисы, неучтённые VPN-точки, старые поддомены — обнуляют его. Автоматизированный сканер злоумышленника найдёт их за часы, и никакой продвинутый SOC не защитит актив, о существовании которого он не знает.</p> <p>Именно поэтому фундамент защиты в эпоху ИИ — это полная и непрерывная видимость поверхности атаки.</p> <h3>Что будет через 5<strong>-</strong>10 лет</h3> <p>Прогнозировать в ИБ на десять лет — сложно, но тренды достаточно устойчивы, чтобы обозначить контур. ИИ — полезный инструмент, который уже активно используется защитниками, но он не спасёт там, где нет базовой кибергигиены. Сначала база — классические процессы сканирования. Для них использование агентских систем — пустая трата токенов. А дальше — не бояться экспериментировать, решать свои задачи.</p> <p>Атаки станут агентными и автономными. Значительная часть операций — от разведки до эксплуатации — будет выполняться без прямого участия человека, а атаки станут по-настоящему массово-персонализированными: индивидуальный подход к каждой жертве при промышленном масштабе.</p> <p>Скорость выйдет на первый план. Ключевой метрикой станет не «есть ли у вас защита», а «за сколько вы обнаруживаете и реагируете». Человек останется в контуре принятия стратегических решений, но операционную скорость будут задавать машины с обеих сторон.</p> <p>Доверие к цифровому контенту продолжит расти. Дипфейки сделают верификацию личности отдельной инженерной дисциплиной. Пароля и даже голоса будет недостаточно — потребуются криптографические и поведенческие методы подтверждения.</p> <p>Защита консолидируется. Контроль периметра, SIEM, XDR и SOAR срастутся в единые экосистемы, где данные о поверхности атаки становятся общим контекстом для решений. Рынок уже движется к модели непрерывного управления экспозицией угроз (Continuous Threat Exposure Management) — от разовых проверок к постоянному мониторингу.</p> <p>Генеративный ИИ — это усилитель, и он укрепляет обе стороны. Проиграет не тот, у кого нет ИИ, а кто продолжает жить в логике реактивной защиты: узнавать о проблеме постфактум и проверять периметр по расписанию. Важно принять новую реальность, где всё меняется каждый день и с обеих сторон работают машины, построить защиту как непрерывный процесс, а не разовое действие. Технологии здесь скорее вторичны. Первична дисциплина видеть всё и вовремя.</p> <p>#IMAGE_235445#</p> За тридцать лет индустрия информационной безопасности пережила несколько технологических сдвигов, но ни один … article Давид Ордян, основатель и генеральный директор METASCAN https://www.itweek.ru/themes/detail.php?ID=235443 Wed, 02 Sep 2026 09:51:39 +0300 <p><em>Исследования указывают на разрыв между амбициями в области искусственного интеллекта и реальной ситуацией на практике, но хорошая новость заключается в том, что специалисты могут его преодолеть, сосредоточившись на тщательных исследованиях и убедительных сценариях использования в производстве, сообщает портал </em><em>ZDNet</em><em>.</em></p> <p>Согласно отчету глобальной контентной и технологической компании Thomson Reuters «2026 Future of Professionals Report», до 91% сотрудников заявляют, что их организации не в полной мере используют потенциал ИИ.</p> <p>Исследование, основанное на глобальном опросе 1800 специалистов из различных секторов, показывает растущий разрыв между амбициями в области ИИ и реальностью, что становится все более серьезной проблемой, отмечает Кирсти Рот, операционный директор Thomson Reuters.</p> <p>Полтора года назад сотрудники с энтузиазмом экспериментировали с ИИ, а их руководители с готовностью поддерживали эти исследования. Сегодня ситуация изменилась. Специалисты тратят токены на использование ИИ, а их руководители обеспокоены ростом расходов на ИТ. Учитывая, что исследования MIT показывают, что 95% проектов в области ИИ не приносят пользы, неудивительно, что компании начинают сомневаться.</p> <h3>ИИ крайне фрагментирован и раздроблен</h3> <p>«Люди начинают понимать, что эти технологии стоят больших денег, и они пока не обязательно видят от них пользу, — говорит Рот. — И поэтому разговор сводится к классическому вопросу управления изменениями: „Хорошо, у нас есть все эти технологии и все эти инструменты, но как мы можем реально изменить наши процессы и способы работы, чтобы быть более эффективными?“».</p> <p>Новые развивающиеся технологии, от агентных моделей ИИ до инструментов глубокого исследования, будут продолжать проникать в бизнес. Как считает генеральный директор Boomi Стив Лукас, общее положение дел в области ИИ крайне фрагментировано и раздроблено: «Сейчас профессионалы знакомятся со множеством терминов — передовые модели, частные модели, доменные модели, модели с открытыми весами, агентные структуры, агентные механизмы и агентные циклы — которые не существовали еще несколько месяцев назад, не говоря уже о нескольких годах».</p> <p>Рот, опираясь на исследование своей фирмы и личный опыт, предлагает компаниям и их специалистам, получающим выгоду от ИИ, сосредоточиться на двух областях: тщательных исследованиях и надежных сценариях использования в производстве.</p> <h3>Поддержка тщательных исследований</h3> <p>Профессионалы, принявшие участие в опросе, четко понимают, что должны делать их инструменты ИИ: защищать конфиденциальные данные (96%), обосновывать результаты авторитетным контентом (94%) и предоставлять объяснимые и обоснованные рассуждения (90%). Однако двое из пяти специалистов (41%), использующих ИИ в своей работе, отмечают, что у них нет доступа к высококачественным инструментам.</p> <p>Согласно исследованию, даже при наличии ИИ-стратегии ее реализация часто отстает. Чуть более трети (35%) специалистов в компаниях, имеющих четко определенную ИИ-стратегию, говорят, что этот подход не проявляется в их повседневной работе.</p> <p>По словам Рот, одно из объяснений — это то, что она называет «инструментальным взрывом» («tool blast»), когда организации навязывают сотрудникам широкий спектр ИИ-сервисов без четкого понимания бизнес-результатов. «Я слышала, как люди говорят: „Мне дали все это. Но что я должен с этим делать?“ Слишком многие компании не понимают, какие инструменты должны использовать сотрудники. Я думаю, что в этом случае очень трудно увидеть рост, за исключением того, что ваши затраты на ПО значительно возрастут», — отмечает она.</p> <p>Согласно <a href="https://www.gartner.com/en/newsroom/press-releases/2026-05-26-gartner-says-applying-uniform-governance-across-ai-agents-will-lead-to-enterprise-ai-agent-failure">прогнозу</a> Gartner, 40% предприятий к 2027 г. сократят использование или выведут из эксплуатации автономных агентов ИИ из-за опасений по поводу их ценности.</p> <p>Рот говорит, что вдумчивые бизнес-руководители ищут действенные решения на основе ИИ для сложных задач, предоставляя специалистам возможность изучать новые технологии, не принимая на себя слишком большого риска. Это то, что она делает в Thomson Reuters, где, по ее словам, придерживаются непредвзятого подхода к генеративному ИИ. «Если у вас появляется классный инструмент, и вы работаете в отделах маркетинга, продаж или программирования, и хотите его попробовать, мы позволим вам это сделать», — поясняет она.</p> <p>Рот отмечает, что вместо того, чтобы ориентироваться на целевые показатели затрат, компания поощряет людей тестировать инструменты ИИ и искать лучшие способы работы. «Мы говорим людям: „Вот инструменты. Переосмыслите, что вы можете сделать“, — рассказывает она. — Конечно, некоторые показывают себя лучше, чем другие, а некоторым требуется больше подсказок и помощи. Но мы поощряем людей думать о том, что эти инструменты могут сделать в современном мире. И этот подход, похоже, хорошо работает».</p> <p>Важным элементом этой стратегии, по мнению Рот, является четкое определение того, какие инструменты приносят пользу, а какие нет, и в последнем случае — прекращение исследований. «На начальном этапе мы пробовали всё подряд в течение примерно шести недель. Можно было получить лицензию практически на всё, что угодно, дать возможность своей команде поэкспериментировать с этим, в зависимости от того, в какой сфере вы работаете, — говорит она. — Мы тестировали результаты, и если они были хорошими, мы внедряли это в других командах. А если результаты были плохими, мы прекращали это и двигались дальше. Поэтому я думаю, что стратегия доступа и экспериментирования на раннем этапе действительно важна».</p> <h3>Определение надежных сценариев использования в производстве</h3> <p>По словам Рот, компании, опережающие конкурентов в области генеративного и агентного ИИ, — это те, кто превращает исследования в сервисы производственного уровня, в то время как отстающие этого не делают.</p> <p>«Успешные фирмы сейчас начинают говорить: „Хорошо, мы выбрали этот инструмент, и мы будем его использовать, и поэтому мы изменим наши бизнес-процессы, чтобы работать по-новому“, и тогда вы начинаете видеть улучшения и экономию», — говорит она, делая важное уточнение: «Однако по-прежнему кажется, что большинство компаний находятся на начальной стадии. Думаю, те, кто преуспевает, очень точно определяют свои сценарии использования».</p> <p>В Thomson Reuters конкретные сценарии использования сосредоточены на пяти ключевых областях: разработка ПО, поддержка и обеспечение успеха клиентов, маркетинг, редакционная и контентная деятельность, а также основные технологические операции.</p> <p>«Конечно, мы хотели бы улучшить работу каждого, и мы сделаем все возможное, — говорит Рот. — Но это пять основных областей, где мы видим наибольший прогресс, и им уделяется наибольшее внимание». Инструменты ИИ для этих областей отыскиваются, тестируются и внедряются, а затем измеряется их эффективность. Сегодня 87% сотрудников Thomson Reuters активно используют инструменты ИИ в своей повседневной работе.</p> <p>Итак, как выглядит успешное внедрение генеративного и агентного ИИ в масштабах всей организации, и как это изменило повседневную практику сотрудников?</p> <p>Рот приводит в пример службы поддержки клиентов и продаж, где сотрудники могут использовать внутреннюю платформу ИИ компании, известную как Open Arena, и передовую модель Claude.</p> <p>Вместо того чтобы тратить часы на сбор информации от торговых представителей и из платформы Salesforce, сотрудники могут использовать утвержденные сервисы ИИ для получения ответов на запросы за считанные секунды. «В этом новом мире вы можете написать запрос в Claude, чтобы получить эту информацию; он может составить вам сводку, понять, каковы ключевые возможности, где могут быть какие-либо риски для данного клиента, или обращался ли он недавно в службу поддержки и был чем-то недоволен, и вы можете гораздо быстрее хорошо подготовится к встрече», — рассказывает она.</p> <p>Сотрудники Thomson Reuters также используют ИИ для исследования рынка, составления документов и отслеживания прибыльности продуктов и услуг.</p> <p>Главное, что усвоила Рот при внедрении ИИ в производство, накопив за последние несколько лет немалый опыт внедрения ИИ в операционную реальность глобального коллектива из 27 тыс. человек, — это то, что бизнес-руководители должны усердно работать над преодолением страхов профессионалов.</p> <p>«Люди не любят перемен. Ключевым моментом на раннем этапе было разъяснение сути ИИ, а затем оставалось лишь дать людям возможность поэкспериментировать и, надеюсь, перестать бояться новых технологий, — говорит она. — Сейчас мы достигли гораздо более зрелого уровня, и, учитывая то, что нам удалось внедрить, я думаю, что направление развития и последовательность действий одинаково важны».</p> Исследования указывают на разрыв между амбициями в области искусственного интеллекта и реальной ситуацией … article https://www.itweek.ru/themes/detail.php?ID=235442 Tue, 01 Sep 2026 14:05:39 +0300 <p>SimpleOne (направление прикладных бизнес-систем корпорации ITG) выпустила версию 1.8.0 системы управления ИТ-активами SimpleOne ITAM. Обновление сокращает время инвентаризации оборудования, позволяет учитывать активы не только по складам, но и по конкретным офисам и кабинетам, а также избавляет финансовые службы от ручных расчетов при работе с затратами в разных валютах.</p> <p>Ключевым нововведением версии 1.8.0 стала возможность подключения сканера штрихкодов при проведении инвентаризации склада. Ранее в системе была реализована инвентаризация с помощью камеры мобильного телефона — теперь к задаче можно подключить внешний сканер, который считывает штрихкод с инвентарным номером актива. Это ускоряет обход крупных складов: сканер считывает метки быстрее и точнее камеры телефона, а данные сразу сверяются со списком активов и попадают в ведомость инвентаризации без ручного переноса.</p> <p>Дополнительно в системе появился новый тип задачи — инвентаризация по расположению. Она позволяет пересчитывать активы не по складам, а по фактическому месту их использования — конкретному офису, этажу или кабинету, даже если по учету оборудование числится за разными складами. Это особенно удобно для компаний с распределенной сетью офисов: можно провести точечную проверку одного подразделения, не запуская инвентаризацию всего склада.</p> <p>В 1.8.0 автоматизирован расчет совокупных затрат на актив с учетом конвертации валют. Раньше, если затраты на актив фиксировались в разных валютах, посчитать реальную стоимость владения оборудованием можно было только вручную, сводя данные в отдельных таблицах. Теперь система автоматически складывает все затраты по активу и автоматически приводит их к единой валюте по актуальному курсу. Финансовые и ИТ-руководители получают точную картину затрат на актив без дополнительных расчетов и могут быстрее принимать решения о ремонте, замене или списании оборудования.</p> <p>«Когда данные о том, где стоит актив и сколько он реально стоит, хранятся в одной системе, ИТ-отдел начинает говорить с финансами на одном языке. Решения о ремонте, замене или списании принимаются на цифрах, а не на ощущениях. Именно так выглядит зрелый подход к управлению ИТ-активами», — отметил Руслан Шарипов, генеральный директор SimpleOne, корпорация ITG.</p> <p>SimpleOne ITAM 1.8.0 уже доступна для действующих клиентов компании. Новые пользователи могут запросить демонстрацию продукта на сайте SimpleOne.</p> SimpleOne (направление прикладных бизнес-систем корпорации ITG) выпустила версию 1.8.0 системы управления ИТ-активами SimpleOne … message https://www.itweek.ru/themes/detail.php?ID=235441 Tue, 01 Sep 2026 09:51:32 +0300 <p>С 1 сентября вступает в силу норма об идентификации администраторов доменов в зонах .ru, .рф и .su через портал «Госуслуги» (ЕСИА). Однако в крупнейшем корпоративном регистраторе Руцентре по состоянию на 27 августа процедуру прошли лишь 42,2% администраторов, а в самом массовом регистраторе Рег.ру — 25,7% пользователей. Юридические лица могут пройти идентификацию только у одного регистратора в России — Руцентра.</p> <p>Компания по управлению онлайн-активами Руцентр провела исследование безопасности доменной инфраструктуры российских компаний. Одной из ключевых тем стал уровень готовности к идентификации через ЕСИА, которая вводится с 1 сентября 2026 года согласно Федеральному закону от 29.12.2025 № <nobr>569-ФЗ.</nobr> В крупнейших игроках рынка идентификацию прошли меньше половины пользователей — в Руцентре 43% администраторов, а в Рег.ру лишь 26,7%. Ежедневно эти цифры прирастают на несколько процентных пунктов. Совокупно эти два регистратора занимают долю в 68% Рунета. Основные сложности связаны с несовпадением данных — многие домены оформлены на устаревшие данные, вымышленные имена, бывших сотрудников и фрилансеров. </p> <p>Ключевым барьером для прохождения идентификации остается многолетняя практика регистрации корпоративных доменов на физические лица. В 2026 году в зоне .ru на долю физических лиц приходится 72,7% доменов, в зоне .рф — 82,9%. При этом среди топ-5000 полезных для пользователей сайтов Рунета на физлица зарегистрировано 32% ресурсов. В случае увольнения администратора или его недоступности компания рискует остаться без возможности продлить или перенести критически важный онлайн-актив. </p> <p>Важно отметить, что нормативно-правовые акты, разъясняющие формат применения новой нормы закона, еще не приняты. Закон устанавливает новый порядок регистрации, при котором регистрировать домены смогут только регистраторы из специального перечня. Порядок включения регистраторов в перечень будет определен Правительством Российской Федерации в ближайшее время. Координационный центр доменов .RU/.РФ уведомил регистраторов, что работа аккредитованных регистраторов продолжится по действующим правилам до включения в перечень, либо до 18 января 2027 года. Это означает, что ограничения на операции с доменными именами для администраторов, еще не прошедших идентификацию, с 1 сентября пока применяться не будут.</p> <p>Наряду с регуляторными изменениями эксперты Руцентра зафиксировали рост внешних киберугроз, связанных с брендовым фишингом. 38,5% компаний столкнулись с появлением сайтов-имитаторов, еще 35,9% — со сканированием доменной инфраструктуры и попытками перехвата управления. Это подтверждается и ростом объема Whois-запросов к доменам почти вдвое — до 95 млн. за полугодие, из которых 83 млн. пришлись именно на корпоративные домены. Чаще всего мишенями атак становятся крупные онлайн-площадки. Злоумышленники целенаправленно собирают данные о владельцах ресурсов для последующего фишинга или перехвата управления. В то же время защита учетных записей администраторов остается слабым звеном. Доля пользователей с включенной двухфакторной аутентификацией составляет лишь <nobr>15-16%.</nobr></p> <p>Дополнительным системным риском стал массовый отзыв иностранных SSL/TLS-сертификатов. С июня по август 2026 года удостоверяющие центры отозвали 6 997 сертификата, из которых 4677 — от GlobalSign. Причина — введение санкционных проверок клиентов по требованию международного консорциума CA/Browser Forum. Доля российских сертификатов в зоне .ru составляет менее 1%, как и доля устройств с установленными отечественными корневыми сертификатами. После отзывов активные сертификаты Национального удостоверяющего центра выросли на 7,7% за неделю, а Технического центра Интернет — в 4,5 раза с начала июня 2026 года.</p> <p>Руцентр провел исследование безопасности доменной инфраструктуры российских компаний уже во второй раз. Предыдущее исследование было выпущено в сентябре 2025 года. В 2026 году к созданию исследования присоединилась компания Технический центр Интернет, технический оператор российской национальной доменной зоны верхнего уровня, которая предоставила дополнительные данные о ситуации на рынке SSL/TLS-сертификатов. Как и в прошлый раз исследование содержит две части, включающие количественный и качественный анализ. Методология построена на анализе системных метрик и операционных показателей, отражающих состояние защищенности онлайн-активов на уровне всего доменного рынка в Российской Федерации. В опросе принимали участие представители ИТ- и ИБ-подразделений компаний, преимущественно из сегмента крупного бизнеса, — почти 40% компаний с численностью свыше 1000 сотрудников. Сбор и обработка данных проводились экспертами Руцентра в августе 2026 года.</p> С 1 сентября вступает в силу норма об идентификации администраторов доменов в зонах .ru, .рф и .su через … message https://www.itweek.ru/themes/detail.php?ID=235439 Tue, 01 Sep 2026 09:42:15 +0300 <p>Российский рынок частных облаков последние несколько лет активно смещается в сторону OpenStack — как альтернативы ушедшим вендорам и как основы для построения отечественных платформ. OpenStack давно перестал быть экзотикой для узкого круга энтузиастов, ведь на нём сегодня строятся частные облака у операторов, банков и промышленных компаний, которым нужен контроль над инфраструктурой без привязки к одному вендору. Но у этого перехода есть обратная сторона, о которой на старте проекта задумываются реже, чем стоило бы: облако на OpenStack нужно не только развернуть, но и потом годами обновлять, своевременно реагируя на выявленные бреши в безопасности, устанавливая новые релизы компонентов и удовлетворяя требования регуляторов. И если сам факт перехода на OpenStack давно перестал быть новостью, то вопрос «а как это облако вообще обновлять, когда придёт время» у большинства эксплуатирующих команд до сих пор упирается в ручной труд, дефицитную экспертизу и риск простоя. То есть проблема не в том, чтобы просто поднять OpenStack, а в том, чтобы удерживать его в рабочем и безопасном состоянии на протяжении всего жизненного цикла. Разберёмся, почему обновление OpenStack остаётся сложной инженерной задачей, какие этапы этого процесса можно автоматизировать и какие ограничения необходимо заложить в механизм обновления, чтобы автоматизация сама не стала источником риска.</p> <h2> Проблема, о которую спотыкается почти каждый оператор облака </h2> <p>OpenStack принято хвалить за гибкость и открытость, но за кулисами этой гибкости стоит один из самых болезненных процессов в жизненном цикле облачной платформы — обновление. В отличие от монолитных систем, OpenStack — это фреймворк из полутора-двух десятков взаимозависимых сервисов (Keystone, Nova, Neutron, Cinder, Glance, Placement и т. д.), каждый со своей базой данных, своими миграциями схемы, своим порядком запуска и своими требованиями к совместимости версий API. Обновить такую систему не значит «поставить новую версию пакета». Это значит провести десятки взаимосвязанных операций в строго определённой последовательности, не нарушив по пути ни одну зависимость.</p> <p>Именно поэтому в большинстве продуктивных инсталляций OpenStack обновление до сих пор остаётся ручной, экспертной и тревожной процедурой, а не рутинной операцией.</p> <h2>Что именно усложняет обновление OpenStack</h2> <p>Если разложить проблему на составляющие, получится примерно такой список (и он актуален независимо от того, разворачивается ли OpenStack «руками», через Ansible-плейбуки или через Kubernetes-операторы):</p> <ul> <li><strong>Порядок и зависимости сервисов.</strong> Часть компонентов должна обновляться раньше других — например, Keystone и Placement обычно идут в начале цепочки, а сервисы, зависящие от их API, следом. Ошибка в порядке приводит к рассинхронизации версий API между сервисами и падению запросов.</li> <li><strong>Миграции баз данных.</strong> Каждое обновление тянет за собой миграции схем в базах Nova, Neutron, Cinder и других сервисов. Некоторые миграции требуют «миграции данных без остановки» ещё на текущей версии — если этот шаг пропущен, обновление может завершиться с повреждением данных.</li> <li><strong>Простой сервисов управления и, в худшем случае, сетей и вычислительных ресурсов пользователей.</strong> Даже при аккуратном планировании слой управления обычно недоступен часть времени обновления. Плохо спроектированный процесс способен зацепить и вычислительные ресурсы пользователей — то есть повлиять на уже работающие виртуальные машины и пространство пользователей.</li> <li><strong>Непредсказуемое поведение при сбое посередине процесса.</strong> Полноценный откат обновления OpenStack на предыдущую версию сама по себе нетривиальная и рискованная операция: схемы БД уже частично мигрированы, часть контейнеров и конфигураций уже обновлена, и «просто вернуть как было» технически далеко не всегда возможно. Поэтому куда важнее другое качество процесса — способность вовремя остановиться в момент сбоя, не разрушив кластер, и точно показать администратору, на каком шаге и что пошло не так, вместо того чтобы продолжать обновление вслепую или бросить систему в непонятном промежуточном состоянии.</li> <li><strong>Человеческий фактор и разрыв компетенций.</strong> Классический процесс обновления — это последовательность команд в CLI, правка YAML-файлов инвентаря и конфигурации, запуск плейбуков с нужными флагами в нужном порядке. Уровень экспертизы, который для этого требуется, есть далеко не в каждой команде эксплуатации, а дефицит сертифицированных OpenStack-инженеров на рынке — известная проблема.</li> <li><strong>Долгий цикл патчинга безопасности.</strong> Когда обновление — это рискованный процесс и многочасовая процедура, а не «нажал кнопку и забыл», критические обновления безопасности откладываются дольше, чем следовало бы. Разрыв между выходом патча и его применением в продуктиве — это прямой риск для периметра.</li> <li><strong>Дрейф конфигурации между средами.</strong> В компаниях с несколькими окружениями (dev/test/prod) ручные обновления быстро приводят к тому, что конфигурации расходятся, и то, что сработало на тесте, ломается в проде именно из-за незамеченного отличия.</li> </ul> <h2>Как эти проблемы решаются (или не решаются) в разных реализациях OpenStack</h2> <p>Здесь стоит сразу отметить: экосистема способов развернуть OpenStack довольно широкая, и подход к обновлению принципиально различается в зависимости от выбранного инструментария.</p> <ul> <li> <strong>Kolla-Ansible</strong> (в том числе на связке с Docker или Podman) разворачивает сервисы в контейнерах и обновляет их через Ansible-плейбуки (kolla-ansible upgrade). Классически это <nobr>CLI-процедура:</nobr> инженер вручную правит globals.yml, инвентарь, версии тегов образов и запускает плейбук, понимая, что происходит на каждом шаге. Вынос процесса в CI/CD позволяет сделать обновление воспроизводимым и версионируемым, а также сократить количество ручных операций. Но сам по себе CI/CD не снимает требования к квалификации специалиста. Кто-то по-прежнему должен понимать структуру пайплайна, интерпретировать результаты выполнения отдельных стадий и принимать решение при ошибках. Поэтому автоматизация исполнения и автоматизация принятия решений при обновлении — это разные задачи.</li> <li> <strong>OpenStack-Ansible (OSA)</strong> концептуально близок к Kolla-Ansible, но использует <nobr>LXC-контейнеры</nobr> или venv вместо Docker/Podman-образов. Процесс обновления так же построен на плейбуках и так же требует ручного сопровождения и экспертизы.</li> <li> <strong>TripleO / director-based установки</strong> (классический подход Red Hat OpenStack Platform до недавних версий) добавляют ещё один слой сложности — undercloud и overcloud обновляются отдельно, а сам процесс исторически считался одним из самых трудоёмких в экосистеме.</li> <li> <strong>Charmed OpenStack от Canonical</strong> на базе Juju ближе всего к идее «графического» управления жизненным циклом: Juju GUI позволяет визуально управлять обновлением charms, что снижает порог входа по сравнению с чистым CLI, хотя полноценной автоматизации «в один клик» с предварительными проверками и остановкой на проблемном шаге это тоже не даёт из коробки.</li> <li><strong>MicroStack / Sunbeam</strong> (тоже Canonical, snap-based) упрощают обновления до команды snap refresh, но это решение ориентировано на небольшие и edge-инсталляции, а не на полномасштабные продуктивные облака.</li> <li><strong>Kubernetes-нативные подходы</strong> (OpenStack-Helm, Airship, а также коммерческий Mirantis OpenStack for Kubernetes) выигрывают за счёт того, что опираются на нативные механизмы Kubernetes — поэтапное обновление, readiness/liveness probes, helm rollback. Именно в этом сегменте чаще всего встречаются продукты с полноценным веб-интерфейсом управления обновлениями, потому что Kubernetes-примитивы изначально спроектированы для автоматизации подобных процессов.</li> </ul> <p>Общий вывод, к которому подводит этот обзор, хочется сформулировать следующим образом. Проблема «обновление зависит от инженера с CLI» и проблема «обновление недоступно как самообслуживаемая операция» — это два разных уровня, и решаются они не одним и тем же шагом. Вынос процесса в CI/CD (как в случае с GitLab у связки Kolla-Ansible/Podman) решает первую: обновление становится воспроизводимым, версионируемым и не требует ручных команд в терминале. Но оно не решает вторую — запустить и проконтролировать пайплайн по-прежнему может только тот, кто ориентируется в GitLab, а не в продукте, которым он управляет. Поэтому интерфейс с кнопкой запуска сам по себе ещё не делает обновление автоматизированным. Существеннее то, какие проверки выполняются до старта, как система учитывает зависимости компонентов, может ли она остановить процесс при ошибке и насколько подробно сообщает администратору о состоянии инфраструктуры. Именно эти механизмы определяют, можно ли передать часть решений от инженера автоматике.</p> <h2>Что должно скрываться за кнопкой автоматического обновления</h2> <p>Автоматизация обновления OpenStack не сводится к переносу последовательности команд из CLI в CI/CD. Пайплайн может выполнять подготовленные операции, фиксировать стадии и сохранять результаты их выполнения. Но сам по себе он не определяет, какие действия допустимы в текущем состоянии инфраструктуры, в какой последовательности их выполнять и когда процесс необходимо остановить.</p> <p>Поэтому поверх исполнительного слоя нужна логика, которая учитывает зависимости сервисов OpenStack, совместимость версий, состояние узлов и результаты проверок после каждого этапа. Иначе автоматизируется только запуск команд, а принятие решений по-прежнему остается на инженере.</p> <p>При этом важно разделять два разных процесса: обновление хостовой операционной системы и переход на новую версию самого OpenStack. Внешне они похожи, но предъявляют разные требования к последовательности операций и допустимому уровню параллелизма.</p> <h3>Патчинг хостовой ОС: ротация узлов</h3> <p>При установке пакетов и обновлений безопасности на контроллерах и гипервизорах можно использовать принцип последовательной ротации.</p> <p>Контроллер выводится в режим обслуживания, получает обновления, при необходимости перезагружается и возвращается в кластер. Только после проверки его состояния процесс переходит к следующему узлу. Пока один контроллер обслуживается, остальные продолжают обрабатывать запросы, что позволяет сохранить доступность управляющего слоя.</p> <p>Для гипервизоров возможна другая схема: обновление по одному узлу или группами в пределах зоны доступности. Размер такой группы должен учитывать доступный запас вычислительных ресурсов. Перед обслуживанием с гипервизора переносятся виртуальные машины, сам узел выводится из эксплуатации, обновляется и после проверки возвращается в строй.</p> <p>Одновременно выводить в обслуживание все гипервизоры одной зоны доступности нельзя. Поэтому механизм автоматизации должен ограничивать уровень параллелизма и учитывать, достаточно ли оставшихся ресурсов для размещения нагрузки.</p> <p>Такая схема особенно важна для установки обновлений безопасности. Ее задача не просто ускорить патчинг, а формализовать операции, которые при ручном выполнении зависят от последовательности действий конкретного инженера: миграцию нагрузки, перевод узла в обслуживание, установку обновлений, перезагрузку и проверку его состояния перед переходом к следующему этапу.</p> <h3>Обновление версии OpenStack: почему поэтапность не всегда означает меньший риск</h3> <p>При переходе между версиями OpenStack логика сложнее. До начала обновления нужно определить, поддерживается ли переход между исходным и целевым релизами. Для этого может использоваться заранее подготовленная матрица совместимости, учитывающая версии компонентов и допустимые маршруты обновления.</p> <p>Отдельный вопрос — порядок обновления контроллеров. Интуитивно безопасной кажется последовательная схема, при которой узлы переводятся на новую версию один за другим. Однако для конкретной архитектуры такой подход необходимо проверять с учетом совместимости API и компонентов. Если часть сервисов уже работает на новой версии, а часть остается на старой, может возникнуть период, когда управляющий слой работает в несогласованном состоянии.</p> <p>Поэтому последовательность операций должна определяться не универсальным принципом «обновлять по одному», а особенностями конкретного релиза и архитектуры развертывания.</p> <p>Не менее важен контроль состояния системы во время перехода. До старта должны выполняться системные проверки. После критических операций необходимо проверять работоспособность компонентов. Если очередная проверка не пройдена, дальнейшие действия следует остановить и зафиксировать этап, на котором возникла ошибка.</p> <p>Для OpenStack такой сценарий зачастую безопаснее попытки автоматически вернуть всю систему в исходное состояние. Если часть схем баз данных уже мигрирована, а некоторые компоненты обновлены, полноценный откат может оказаться отдельной сложной и рискованной процедурой. Поэтому от механизма автоматизации требуется прежде всего контролируемая остановка и точная диагностика.</p> <p>Очередность обновления контроллеров и гипервизоров также должна учитывать зависимости между управляющим и вычислительным слоями. Переход вычислительных узлов на новую версию следует начинать только после того, как управляющий слой приведен в согласованное состояние. После этого гипервизоры можно обновлять по одному или группами, предварительно освобождая их от пользовательской нагрузки.</p> <h3>Что именно нужно автоматизировать</h3> <p>При оценке механизма обновления OpenStack важно смотреть не только на инструмент, который исполняет команды. Ansible, CI/CD или Kubernetes позволяют автоматизировать значительную часть технических операций, но сами по себе не определяют, можно ли выполнять конкретное обновление в текущем состоянии инфраструктуры.</p> <p>Более высокий уровень автоматизации появляется там, где формализована логика принятия решений: проверяется допустимость перехода между версиями, учитывается состояние компонентов, контролируется размер одновременно обслуживаемой группы узлов, соблюдается очередность между управляющим и вычислительным слоями, а дальнейшие действия блокируются при возникновении ошибки.</p> <p>Именно поэтому перенос команд из терминала в пайплайн решает только часть задачи. Он делает процесс воспроизводимым и версионируемым, но не заменяет механизм управления жизненным циклом облачной платформы.</p> <h3>Что должен видеть администратор</h3> <p>Способ запуска обновления вторичен. Это может быть CLI, CI/CD или графический интерфейс. Гораздо важнее, какую информацию получает администратор до начала процесса и во время его выполнения.</p> <p>До старта обновления должны быть понятны текущие версии компонентов, доступный целевой релиз, результаты предварительных проверок и ограничения выбранного сценария. Во время обновления необходимы данные о текущем этапе, состоянии узлов и возникших ошибках.</p> <p>Задача интерфейса в данном случае не в том, чтобы скрыть сложность OpenStack за одной кнопкой. Он должен дать администратору понятную точку управления процессом, тогда как правила последовательности, совместимости и безопасной остановки должны соблюдаться автоматически.</p> <h3>От чего зависит длительность обновления</h3> <p>Продолжительность обновления нельзя свести к одному нормативному значению. Она зависит от числа узлов, состава компонентов, объема миграций, пользовательской нагрузки и расстояния между исходным и целевым релизами.</p> <p>Последовательный переход между соседними релизами, как правило, требует меньше промежуточных изменений. Если же обновление затрагивает несколько релизов, приходится учитывать больше изменений в компонентах, схемах баз данных и конфигурациях.</p> <p>Отдельно в технологическое окно закладывается время на освобождение гипервизоров от нагрузки, миграцию виртуальных машин, обслуживание узлов и проверки после обновления. Поэтому задача автоматизации состоит не только в сокращении общей продолжительности процедуры. Не менее важно сделать состав операций и их последовательность предсказуемыми, чтобы окно обслуживания можно было планировать заранее.</p> <h3>Почему обновление нужно тестировать заранее</h3> <p>Автоматизация не отменяет предварительной подготовки обновления. Для каждого поддерживаемого перехода необходимо проверить совместимость компонентов, миграции баз данных, последовательность операций и работу основных сценариев после установки новой версии.</p> <p>Чем больше расстояние между исходным и целевым релизами, тем больше промежуточных изменений приходится учитывать. Поэтому наличие новой версии OpenStack еще не означает, что на нее можно безопасно перейти из любого предыдущего состояния.</p> <p>Для эксплуатации это означает, что маршрут обновления должен быть заранее определен и протестирован. Автоматический механизм затем воспроизводит уже проверенную последовательность, контролируя состояние системы на каждом критическом этапе.</p> <h2>Когда обновление OpenStack действительно можно считать автоматизированным</h2> <p>Кнопка запуска сама по себе еще не делает обновление автоматическим. За ней может находиться тот же набор команд, который раньше инженер последовательно выполнял вручную.</p> <p>Более зрелый подход начинается с автоматизации не только исполнения, но и части решений. Система проверяет состояние инфраструктуры до старта, учитывает совместимость версий и зависимости компонентов, ограничивает потенциально опасный параллелизм, контролирует результат отдельных операций и прекращает дальнейшие действия, если состояние системы отклоняется от ожидаемого.</p> <p>При этом полностью исключить инженерную экспертизу невозможно. OpenStack остается сложной распределенной системой, а нестандартные ошибки могут требовать ручной диагностики. Задача автоматизации в другом: убрать из регулярного процесса повторяющиеся операции и решения, которые можно формализовать, снизить зависимость результата от ручных действий и оставить специалистам действительно нестандартные ситуации.</p> <p>Поэтому зрелость механизма обновления определяется не количеством операций, сведенных к одному нажатию, а тем, насколько предсказуемо система проходит штатный сценарий и насколько управляемо ведет себя при возникновении ошибки. По мере роста OpenStack-инфраструктуры такая автоматизация становится частью управления ее жизненным циклом, поскольку без нее увеличиваются трудозатраты на эксплуатацию и зависимость от ручных операций.</p> <p> #IMAGE_235440#</p> Российский рынок частных облаков последние несколько лет активно смещается в сторону OpenStack — как альтернативы … article Кирилл Острогожский, архитектор компании ITKey https://www.itweek.ru/themes/detail.php?ID=235438 Tue, 01 Sep 2026 09:20:51 +0300 <p><em>Финансовые, а не инженерные аспекты губят проекты по внедрению агентного искусственного интеллекта. Поскольку объем телеметрических данных в ближайшие два года вырастет на порядок, конвейеры наблюдаемости становятся контрольным звеном, сообщает портал </em><em>The</em> <em>New</em> <em>Stack</em><em>.</em></p> <p>По мере того как компании переходят от экспериментов с ИИ к запуску автономных агентов в производственной среде, возникает проблема, связанная с инфраструктурой: растущие расходы на телеметрию. Недетерминированные, итеративные агенты, способные генерировать данные со скоростью машин, гораздо сложнее поддаются мониторингу, а расходы на них спрогнозировать гораздо сложнее, чем в случае с обычными приложениями.</p> <p>Многие компании испытывают трудности с выделением и обоснованием расходов на телеметрию. Согласно <a href="https://www.prnewswire.com/news-releases/new-apica-research-agentic-ai-poised-to-trigger-9-5x-telemetry-data-explosion-leaving-most-enterprises-exposed-302789312.html">опросу</a> более 300 руководителей в сфере корпоративных ИТ в Северной Америке и Западной Европе, проведенному Omdia/Informa TechTarget по заказу Apica, 59% организаций уже прекратили или отложили внедрение ИИ-агентов из-за расходов на мониторинг.</p> <p>Чаще всего это происходит при внедрении ИИ-агентов в критически важных областях: например, в сферах кибербезопасности, соблюдения нормативных требований и выявления мошенничества. По мере роста расходов на мониторинг, проекты по внедрению ИИ-агентов далеко не всегда закрываются по инициативе инженерных команд. Чаще всего их закрывает финансовый отдел.</p> <p>Энди Манн, директор по продуктам и технологиям Apica, недавно стал свидетелем того, как это произошло в одном крупном банке. Организация не смогла точно определить свои затраты на программы ИИ. «Они поняли, что не могут позволить себе продолжать в том же духе, поэтому у них не было другого выбора, кроме как отменить некоторые программы ИИ, — рассказывает он. — Я уже сталкивался с такими вещами, потому что ИИ-проекты легко съедают типичные бюджеты».</p> <p>Последствия огромны. По мере того, как люди, финансирование и ресурсы мониторинга перенаправляются на новые рабочие нагрузки ИИ, другие подразделения бизнеса начинают страдать. Манн говорит, что он видит перебои в работе, простои и атаки с проникновением, а средства защиты от DDoS-атак конкурируют за одни и те же ресурсы.</p> <p>Исследование Apica также выявило эту проблему. Только за последний год на большинстве предприятий (54%) объем телеметрии утроился, причем 43% этого роста приходится на рабочие нагрузки ИИ/машинного обучения, что, безусловно, является основным фактором. Предприятия вынуждены бороться с этим кризисом, поскольку их расходы на наблюдаемость растут. Они сообщают, что тратят в среднем 3,17 млн. долл. на обеспечение наблюдаемости, причем эта цифра растет на 28% в годовом исчислении и предела этому росту не видно. Неудивительно, что 83% опрошенных считают ИИ-наблюдаемость главным приоритетом на ближайший год.</p> <h3>Грядущая волна может оказаться катастрофической</h3> <p>При появлении нового облачного сервиса, базы данных или приложения нагрузка на систему мониторинга и объем телеметрических данных обычно увеличиваются на относительно предсказуемую величину. Но сейчас компании прогнозируют, что в течение двух лет объем телеметрических данных вырастет в среднем в 9,5 раза. Около 44% организаций ожидают, что объем телеметрических данных вырастет в <nobr>6-100 раз.</nobr></p> <p>«Представьте, что ваш счет по кредитной карте или чек из супермаркета выросли почти на порядок. Это уже не просто увеличение. Это не плавный рост, а стремительный взлет, и это вызывает панику», — говорит Манн.</p> <p>Причина в том, что работа агента — это не то же самое, что отдельный запрос к приложению. Задача службы поддержки может включать в себя трассировку верхнего уровня, несколько вызовов модели, операции извлечения данных, вызовы инструментов, повторные попытки и циклы. Но если агент делегирует работу другому агенту, это добавляет в трассировку еще одну ветвь.</p> <p>Каждая модель может генерировать данные о токенах, задержках, затратах и поставщиках, а каждый вызов инструмента создает собственные записи об аргументах, результатах, статусе и последующих действиях. Идентификаторы, такие как <em>tool_name</em>, <em>agent_id</em> и <em>trace_id</em>, также создают избыточность данных, из-за чего их сложнее агрегировать и дороже индексировать, и затраты растут на каждом этапе.</p> <p>Это создает ощутимый разрыв между амбициями в области ИИ и готовностью инфраструктуры. Несмотря на то, что 35% компаний заявляют о широком внедрении агентного ИИ, эксплуатация и управление такими системами сильно отличаются от того, что было раньше. Почти две трети компаний лишь в некоторой степени готовы к таким изменениям. В отличие от обычных приложений, агенты могут вызывать множество моделей и инструментов, повторно выполнять задачи или расширять рабочий процесс непредсказуемым образом, из-за чего сложно спрогнозировать затраты на обеспечение производительности и мониторинг.</p> <h3>От огромных затрат на телеметрию до уровня контроля на входе</h3> <p>По словам Манна, решение заключается в том, чтобы вмешаться на более ранних этапах. «Нельзя бесконечно отправлять практически бесполезные данные на дорогостоящую центральную аналитическую платформу или платформу хранения данных, потому что нет смысла анализировать данные, которые говорят о том, что все в порядке, — говорит он. — Как можно раньше подключите конвейер к сборщикам данных и управляйте ими на уровне источника».</p> <p>Традиционные платформы наблюдаемости ориентированы на сбор данных, их прием, хранение и индексацию, а затем анализ. Такая модель подходила для рабочих процессов, управляемых людьми и анализируемых с помощью дашбордов, но для агентного ИИ необходимо принимать решения до того, как телеметрия дойдет до наиболее затратных частей стека.</p> <p>Архитектура, ориентированная на конвейер, позволяет отбирать повторяющиеся успешные события, сохраняя при этом данные о сбоях, повторных попытках, нарушениях политик и аномально медленных трассировках. Она позволяет дополнять записи данными об агенте, сеансе, модели, инструменте, токене и предполагаемой стоимости, удалять конфиденциальные запросы и идентификаторы, а также агрегировать метрики и долгосрочные записи и отправлять их в места назначения с разными профилями затрат и хранения.</p> <p>Компактная метрика или выборка могут отражать обычный успешный вызов инструмента, в то время как при неудачном вызове сохраняется родительская трассировка, сведения об ошибке, история повторных попыток и контекст безопасности. Цель состоит в том, чтобы сохранить информацию, необходимую для объяснения поведения агента, сократив при этом объем избыточных данных и ограничив объем индексируемой информации.</p> <p>Агентам также необходим контекст на уровне миллисекунд для принятия автономных решений. Обработка телеметрии в непосредственной близости от источника позволяет организациям быстро выявлять ситуации, когда происходит слишком много повторных попыток, чрезмерное количество циклов использования инструментов или аномально высокий расход токенов, не дожидаясь, пока данные будут собраны и проиндексированы централизованно.</p> <p>Без контроля на уровне источника компании рискуют передавать фрагментированные и ненужные телеметрические данные на платформы, которые взимают плату за каждый дополнительный гигабайт, индекс и сохраненную запись.</p> <h3>Архитектура, которая отделяет победителей от проигравших</h3> <p>Трудно не заметить, насколько выгоден подход, при котором переосмысливается конвейер сбора телеметрических данных. Использующие его компании на 50% лучше подготовлены к росту объемов данных, связанному с агентным ИИ. Именно внедрение такого подхода выделяет зрелые организации, использующие агентный ИИ, на фоне конкурентов: такие организации на 80% реже сталкиваются с проблемами, связанными с операционными расходами, которые мешают их конкурентам.</p> <p>Решение заключается в том, чтобы перенести аналитические функции на более ранние этапы. Вместо того чтобы рассматривать платформу наблюдаемости как универсальный инструмент, компании могут принимать решения о том, какие телеметрические данные использовать, еще до того, как они попадут на платформу, — отфильтровывая ненужную информацию, выделяя то, что действительно важно, и маршрутизируя данные в соответствии с их ценностью и назначением. Это означает, что в дорогостоящие системы хранения и анализа будет поступать меньше данных, а та информация, которая все же попадет в эти системы, будет более полезной и доступной в режиме реального времени.</p> <p>Важно отметить, что речь не идет о полном отказе от платформ наблюдаемости, на которые уже полагаются компании. Речь идет о том, чтобы создать перед ними более интеллектуальный контрольный слой, который будет решать, какие данные заслуживают обработки, куда их следует направлять и сколько это будет стоить.</p> <p>Существующие платформы наблюдаемости по-прежнему играют важную роль. «Конвейер не может делать все, но он может взять на себя первичную обработку данных, — говорит Манн. — Вы по-прежнему работаете с крупными аналитическими платформами, но при этом экономите деньги, снижаете риски и повышаете эффективность соблюдения нормативных требований».</p> <p>Согласно исследованию Apica, контрольный конвейер, базовые метрики и сервисы подготовки данных позволяют снизить совокупную стоимость владения на 40% по сравнению с унаследованными платформами наблюдаемости. Разумеется, фактическая экономия будет зависеть от объемов телеметрии, политики хранения данных, правил выборки, решений по маршрутизации, действующих контрактов и доли данных, которые можно обработать до приема в систему.</p> <p>Сейчас самое время пересмотреть архитектуру. Около 68% компаний планируют в течение следующих шести месяцев оценить изменения в своей системе наблюдаемости, а почти четверть из них заявляют, что существующие отношения с поставщиками не будут играть существенной роли при принятии этих решений. Следующий этап развития системы наблюдаемости будет связан с умением справляться с тем, что ИИ будет «выбрасывать» в инфраструктуру.</p> <p>Это означает, что конвейер больше нельзя рассматривать как систему, которая просто перемещает телеметрические данные из пункта А в пункт Б. Он становится управляющим слоем для все более автономной и требовательной к данным среды.</p> <p>Организации, которые создадут инфраструктуру, готовую к работе с агентным ИИ, смогут снизить затраты на наблюдаемость и повысить эффективность управления рисками. Манн не считает, что у платформенных инженеров и SRE-команд есть большой выбор. «Это уже становится решением на уровне совета директоров, — говорит он. — В конечном счете, это выбор того, насколько разумно вы можете позволить себе вести свой бизнес».</p> Финансовые, а не инженерные аспекты губят проекты по внедрению агентного искусственного интеллекта. Поскольку … article https://www.itweek.ru/themes/detail.php?ID=235436 Mon, 31 Aug 2026 18:03:03 +0300 <p>Аналитический центр проекта STAQ, предназначенного для цифровизации бизнес-процессов, провел исследование, направленное на выявление наиболее востребованных направлений использования платформенных решений в ключевых отраслях России в 1 полугодии 2026 года. Данные были получены по итогам анализа проектной практики STAQ за 1 полугодие 2026 года.</p> <p>По данным анализа проектов и клиентских запросов STAQ за январь-июнь 2026 года наиболее активно платформенные решения применялись в трёх ключевых отраслях: промышленное производство, розничная торговля и транспорт. Помимо этих индустрий, можно выделить строительство и управление инфраструктурными объектами, добывающую промышленность, телекоммуникации, агропромышленный комплекс и финансовый сектор. В этих сегментах платформы востребованы прежде всего для управления заявками и инцидентами, контроля эксплуатации оборудования, координации выездных сотрудников и соблюдения SLA. </p> <p>Существуют важные причины востребованности платформ в данных отраслях. Первая причина — высокая стоимость простоев и операционных ошибок. Остановка производственной линии, кассового оборудования, склада или транспортного узла быстро приводит к прямым финансовым потерям, нарушению графиков и снижению качества обслуживания. Вторая причина — большое число распределенных процессов. Предприятиям нужно одновременно управлять оборудованием, заявками, сотрудниками, выездными бригадами и подрядчиками на сотнях объектов. Третья причина — переход от разрозненной автоматизации к единому цифровому контуру. Компании стремятся связать существующие ERP, WMS, POS, MES, SCADA, IoT-системы и внутренние базы данных без полной перестройки ИТ-ландшафта.</p> <p>На промышленных предприятиях платформенные решения чаще всего использовались по следующим направлениям: управление производственными заданиями и сменной отчетностью, техническое обслуживание и ремонт оборудования, мониторинг технологических параметров с использованием IoT и SCADA, управление качеством, инцидентами и отклонениями. Отдельное направление — задачи, которые традиционно относят к контуру MES: сменные задания, отчётность по выпуску, регистрация отклонений и контроль исполнения на уровне цеха. </p> <p>По данным аналитиков STAQ, в среднем по проектам, применение платформ на производственных предприятиях в 1 полугодии 2026 года позволило в сравнении с показателями до внедрения: сократить затраты на внеплановые ремонты на 21%, уменьшить количество незапланированных простоев на 28%, ускорить реакцию на выявленные дефекты на 16%. Данные начали использоваться не только для отчетности. Система автоматически формирует задачу при обнаружении отклонения, назначает ответственного, контролирует срок выполнения и сохраняет результат.</p> <p>Основными направлениями использования платформ в розничной торговле стали: централизация заявок от магазинов и других торговых объектов, обслуживание касс, холодильников, торговых автоматов и инженерных систем, управление мерчандайзерами, техническими специалистами и подрядчиками, контроль SLA, наличия товаров и качества обслуживания торговых точек. Вместо обращений по телефону, электронной почте и в мессенджерах торговая сеть получает единую точку входа. Заявки автоматически распределяются по региону, типу проблемы, приоритету и компетенции исполнителя. В одном из проектов STAQ была централизована обработка заявок более чем из 300 магазинов. В сравнении с периодом до внедрения сроки исполнения заявок сократились на 30%, количество случаев отсутствия товара из-за отказов оборудования уменьшилось на 50%, более 20% заявок стали обрабатываться без участия человека, а среднее число заявок, закрываемых одним диспетчером за смену, выросло на 60%.</p> <p>В транспортно-логистической отрасли платформы применялись для управления техническим состоянием транспорта и инфраструктуры, планирования ТОиР и внеплановых ремонтов, диспетчеризации и контроля исполнения рейсов, обработки ИТ- и инфраструктурных инцидентов, управления подрядными перевозчиками и соблюдения SLA. В одном из проектов STAQ для крупной логистической компании количество инцидентов, влияющих на операционные процессы, сократилось на 47%, выполнение SLA по критичным системам достигло 94%, а простои стоек регистрации уменьшились на 62%. Интеграция с ERP также позволила ускорить закупку запасных частей на два дня. Основной результат использования платформ для транспортно-логистической отрасли — сокращение незапланированных остановок и переход от ручной диспетчеризации к управлению на основании данных.</p> <p>Во 2 полугодии 2026 года STAQ ожидает сохранения спроса на платформенные решения со стороны промышленности, ритейла и логистики, но при более консервативном отношении к ИТ-бюджетам: в приоритете будут проекты с измеримой и быстрой окупаемостью, а повестка сместится с роста выручки на сокращение операционных затрат. Изменится характер проектов: компании будут чаще переходить от автоматизации отдельного процесса к тиражированию решений на несколько площадок. Основными направлениями развития станут: предиктивное обслуживание оборудования на основе IoT-данных, применение ИИ для классификации заявок, выявления отклонений и поддержки диспетчеров, объединение производственных, эксплуатационных и сервисных процессов на одной платформе. Кроме того, компании осуществят более глубокую интеграцию с ERP, WMS, POS, MES и SCADA. </p> <p>«В 1 полугодии 2026 года платформенный подход вышел за рамки простой замены бумажных процессов цифровыми. Компании используют платформы как операционный контур, который связывает оборудование, сотрудников, подрядчиков и управленческую аналитику. Мы видим, что ожидания от предиктивной аналитики и ИИ сегодня опережают готовность данных: пока не выстроен учёт оборудования, заявок и истории ремонтов, модели не на чем обучать. Поэтому ближайший этап для большинства компаний — не новые технологии, а качество эксплуатационных данных», — отметил Евгений Гусев, генеральный директор STAQ.</p> Аналитический центр проекта STAQ, предназначенного для цифровизации бизнес-процессов, провел исследование, направленное … message https://www.itweek.ru/themes/detail.php?ID=235435 Mon, 31 Aug 2026 18:01:51 +0300 <p>Концепция Bring Your Own Device (BYOD), когда сотрудники работают с личных гаджетов, окончательно закрепилась в российской корпоративной практике. По оценке экспертов «Кросстеха», до 90% сотрудников организаций используют личные устройства для решения рабочих задач. Внедрение BYOD или отдельных элементов концепции выгодно бизнесу, так как позволяет сократить расходы на оборудование и создать более комфортные условия работы для сотрудников. При этом зачастую внедрение происходит без должной подготовки, что потенциально может привести к серьезным инцидентам информационной безопасности. Около 70% организаций внедряют этот подход с ошибками, создавая дополнительные киберриски, которые могут приводить к утечкам данных и другим инцидентам информационной безопасности безопасности</p> <p>Главная ошибка — попытка управлять чужой техникой через крайности. Первая крайность — полная вседозволенность. Когда компания не задает правил, менеджер скачивает договор на личный смартфон, чтобы доработать его вечером дома. Если этот телефон потеряется в такси или попадет в руки ребенку, который случайно установит вредоносную игру, корпоративная тайна мгновенно станет публичной. </p> <p>Вторая крайность — тотальная слежка и гиперопека. Когда отдел безопасности требует установить на личный ПК программы, которые отслеживают все действия пользователя, сотрудники воспринимают это как вторжение в личную жизнь. В ответ возникает «Теневое ИТ»: вместо разрешенных каналов специалисты начинают тихо пересылать рабочие документы в личные мессенджеры и сторонние хранилища, полностью скрывая эти процессы от компании.</p> <p>«Адекватный путь внедрения BYOD строится не на полном контроле устройства, а на понятном разделении личного и рабочего пространства. Главный принцип — компании должно быть важно только то, как обрабатываются ее данные, а не то, чем занимается человек в свое свободное время на своем устройстве», — говорит Егор Норкин, архитектор ИБ компании «Кросстех».</p> <p>Наиболее эффективный подход к BYOD строится на трех ключевых мерах: изоляции рабочего контура на личных устройствах, разграничении доступа к критичным системам и прозрачных правилах взаимодействия. На смартфонах рабочая среда прячется в зашифрованный контейнер, исключающий утечки и позволяющий точечно удалить данные компании при увольнении. Для домашних ПК организуется защищенный доступ через выделенные рабочие столы без прямой связи с внутренней сетью, а все требования к технике, компенсации и технической поддержке фиксируются в понятном регламенте. </p> <p>«ИБ сегодня — это баланс между сохранностью данных, бизнес-целями и комфортом людей. Бизнес всегда в приоритете, но рабочие процессы должны быть устроены так, чтобы они не были уязвимы. BYOD — отличная концепция, если решить это уравнение правильно. Сделать личную технику сотрудников безопасной абсолютно реально: достаточно грамотно оценить риски, разграничить корпоративный контур и уходить в крайности», — отметил Егор Норкин.</p> Концепция Bring Your Own Device (BYOD), когда сотрудники работают с личных гаджетов, окончательно закрепилась … message https://www.itweek.ru/themes/detail.php?ID=235434 Mon, 31 Aug 2026 12:42:28 +0300 <p>Компания «РЕД СОФТ» объявила о выпуске корректирующего релиза операционной системы РЕД ОС 8.0.3 для архитектуры ARM. Система адаптирована для широкой линейки ARM-оборудования — от российских процессоров «Байкал» до популярных одноплатных компьютеров.</p> <p>РЕД ОС под ARM может применяться при создании встраиваемых систем, IoT-устройств, учебных стендов и серверных решений, требующих энергоэффективности. Использование единой операционной системы на всех типах устройств позволяет унифицировать ИТ-инфраструктуру предприятия, упростить администрирование и сократить расходы на поддержку.</p> <p>Образы РЕД ОС 8.0.3 для ARM доступны для скачивания на официальном сайте РЕД ОС.</p> <p>Совместимость РЕД ОС с архитектурой ARM продолжает расширяться. В новом релизе дополнен перечень поддерживаемых одноплатных компьютеров, востребованных на рынке.</p> <p>Функциональность образов РЕД ОС 8.0.3 полностью идентична версии для архитектуры x86_64. Полный список изменений и нововведений, вошедших в релиз РЕД ОС 8.0.3, доступен на сайте РЕД ОС.</p> <p>Важным отличием от предыдущего релиза является то, что теперь в одном образе объединена поддержка сразу нескольких ARM-устройств. На этапе установки можно выбрать требуемое устройство, и система будет установлена с соответствующим устройству ядром Linux. «Из коробки» поддерживаются следующие устройства:</p> <ul> <li>платформы на базе процессоров Huawei Kunpeng и Ampere Altra;</li> <li>устройства от «Элпитех» на базе процессоров Байкал-М, а также Байкал-S;</li> <li>устройства от ГК «Аквариус» на базе процессора Байкал-М;</li> <li>устройства от «Гравитон» на базе процессора Байкал-М.</li> </ul> <p>Расширена поддержка популярных одноплатных платформ, широко используемых в образовании, робототехнике, промышленной автоматизации и IoT-проектах. В список поддерживаемых РЕД ОС устройств добавлены новые модели: Raspberry Pi 3+ и Orange Pi Zero 3. Кроме того, обновлены образы для уже поддерживаемых платформ: Raspberry Pi 4/5, ROCKPro64, Orange Pi Zero 2W, Orange Pi 3 LTS и Repka Pi 4 Optimal. </p> <p>Пользователям доступен выбор из нескольких вариантов окружения рабочего стола: KDE Plasma, MATE или GNOME. Также доступна минимальная конфигурация без графики.</p> <p>РЕД ОС 8 под ARM была сертифицирована ФСТЭК России в декабре 2025 года. Сертифицированная РЕД ОС 8 под ARM поддерживает платформы на базе процессоров Huawei Kunpeng и Ampere Altra и ряд устройств на процессоре Байкал-М. Ведется работа над расширением поддерживаемых устройств на архитектуре ARM в Сертифицированной редакции РЕД ОС 8.</p> <p>«РЕД ОС 8.0.3 для ARM — это качественное обновление продукта для распространенных в России ARM-устройств. Все образы полностью сохраняют функциональность, идентичную версии для x86_64, что открывает ещё больше сценариев использования. В дальнейшем мы продолжим расширять перечень поддерживаемых устройств и совершенствовать механизмы развёртывания, чтобы каждый пользователь мог найти оптимальное решение для своих задач», — отметил Рустам Рустамов, заместитель генерального директора РЕД СОФТ.</p> Компания «РЕД СОФТ» объявила о выпуске корректирующего релиза операционной системы РЕД ОС 8.0.3 для архитектуры ARM … message https://www.itweek.ru/themes/detail.php?ID=235433 Mon, 31 Aug 2026 12:40:41 +0300 <p><span>Компания</span><span> Axiom JDK (АО</span> <span>«Аксиом») представила исследование о</span> <span>том, как российские компании управляют версиями Spring Boot, планируют миграцию и</span> <span>оценивают риски после окончания публичной поддержки. Сегодня международная поддержка Spring недоступна российским заказчикам на</span> <span>стандартных условиях. При этом 55,8% Java-разработчиков не</span> <span>определили срок эксплуатации Spring без публичных обновлений, 61,2% отметили практическую ценность расширенной поддержки, но</span> <span>только 26,9% уже используют или готовы рассматривать</span> <span>её. В</span> <span>опросе приняли участие более 300 специалистов в</span> <span>области Java-разработки, 87,8% из</span> <span>которых регулярно используют Spring</span> <span>— самый распространённый фреймворк для разработки Java-приложений в</span> <span>России.</span></p> <p>Исследование отражает прежде всего ситуацию в крупном бизнесе и финансовой отрасли: 71,1% участников работают в организациях численностью более 1000 сотрудников, 56,1% представляют финтех. Таким образом, риски окончания поддержки Spring затрагивают не только команды разработки, но и Java-приложения, обеспечивающие ключевые процессы банков, крупных компаний и цифровых сервисов.</p> <p>Наиболее распространённым поколением остаётся Spring Boot 3.x: его используют 83,7% участников. Spring Boot 2.x продолжает применять 21,2%, Spring Boot 4.x — 26%. Близкую картину показывает исследование State of Java 2026 компании JUG Ru Group: версии 2.x используют 20,4% опрошенных пользователей Spring, 3.x — 73,1%, 4.x — 24,7%.</p> <p>Публичные обновления версий Spring Boot выпускаются ограниченное время — для промежуточных веток около 13 месяцев. После завершения этого периода компании должны перейти на новую версию, сопровождать используемую ветку самостоятельно или использовать коммерческую поддержку.</p> <p>В июне 2026 года завершился выпуск публичных обновлений для Spring Boot 3.5 — наиболее распространённого поколения среди участников исследования. Международная коммерческая поддержка Spring российским заказчикам на стандартных условиях недоступна после прекращения VMware и Broadcom продаж и сопровождения в России. Поэтому компаниям необходимо самостоятельно обеспечить источник исправлений и план перехода.</p> <p>Однако исследование показывает, что такой сценарий сформирован не везде. 53,5% участников не знали дату окончания поддержки Spring Boot 3.5, а 55,8% не определили допустимый срок эксплуатации версии без публичных обновлений, включая исправления безопасности.</p> <p>18,9 % участников сообщили, что работы по переходу на Spring Boot 4 уже выполняются или завершено, для 41% переход пока остается планом. 23,7 % респондентов не приняли решение. </p> <p>При этом 32,7% участников одновременно используют несколько поколений Spring Boot. Новые приложения могут уже работать на актуальной версии, тогда как действующие системы продолжают использовать 2.x и 3.x. Это увеличивает объём работ по контролю уязвимостей, совместимости и обновлений и не позволяет завершить миграцию одномоментно.</p> <p>Требования информационной безопасности назвали причиной обновления Java и связанных фреймворков 57,7% участников. Однако инициаторами изменений чаще становятся разработчики (63,5%), тогда как подразделения ИБ и AppSec указали 36,5%. Риск возникает, когда между выявлением уязвимости и внедрением исправления не назначен единый владелец процесса, не установлен срок реакции и не определён источник обновлений.</p> <p>Результаты согласуются с данными State of Java 2026 по поддержке Spring Boot. По оценке JUG Ru Group, 61,5% разработчиков самостоятельно обновляют зависимости, 34,9% проверяют совместимость, 27% анализируют уязвимости, 23,4% контролируют версии и сроки поддержки, 21,5% исправляют дефекты. Отказ от внешней поддержки не устраняет эти задачи — они переходят внутренним командам и конкурируют за ресурсы с развитием продуктов.</p> <p>Только 26,9% участников исследования Axiom JDK уже используют или готовы рассматривать коммерческую поддержку Spring Boot. При этом 61,2% отметили хотя бы одну её практическую ценность. Наиболее востребованы исправления безопасности после окончания публичной поддержки — 29,8%, сопровождение необходимых версий и помощь с миграцией — по 23,4%, закреплённые сроки реакции (SLA) — 20,5%, экспертные консультации — 20,2%. Даже среди участников, которые не рассматривают комплексную коммерческую поддержку, 43,4% готовы использовать ее под конкретные задачи, например, чтобы облегчить работу по поиску исправлений и миграции. </p> <p>«Spring лежит в основе большого числа приложений крупного бизнеса и финансового сектора. Окончание публичной поддержки становится проблемой в момент появления уязвимости, когда компании срочно требуется проверенное исправление. Если источник обновлений и ответственный за процесс не определены заранее, риски переходят из технической плоскости на уровень реальной работы бизнеса, информационной безопасности и бюджетов — растут затраты и нагрузка на команды разработки. Для каждой промышленной системы необходимо заранее установить срок эксплуатации версии, план миграции и порядок получения исправлений», — отметил Илья Сазонов, директор по продукту Axiom JDK (АО «Аксиом»)</p> Компания Axiom JDK (АО «Аксиом») представила исследование о том, как российские компании управляют версиями Spring … message https://www.itweek.ru/themes/detail.php?ID=235432 Mon, 31 Aug 2026 12:38:51 +0300 <p>Компания GreenData, российский разработчик low-code-платформы, выпустила обновление, которое упрощает полный цикл работы с данными: от анализа и корректировки показателей до автоматического формирования табличных отчетов. В новой версии low-code-платформы появилась возможность редактировать данные прямо в OLAP, а также настраивать итоговые строки и столбцы в OLAP-представлениях. Дополнительно были расширены возможности по работе с новыми электронными таблицами: стало возможно осуществить экспорт сразу при выполнении серверной процедуры в рамках выполнения алгоритма.</p> <p>Так, пользователи теперь могут не только анализировать данные, но и редактировать их непосредственно в представлении OLAP. Бизнес-администратор сам определяет сценарий работы: разрешить только открытие карточек объектов, только редактирование значений в таблице или использовать оба режима одновременно. Все необходимые настройки выполняются в карточке куба, позволяя вносить изменения без постоянного перехода из аналитического представления в карточки объектов и обратно.</p> <p>Также в OLAP-представлениях появилась настройка отображения итоговых строк и столбцов. Пользователь может выбрать необходимые вычисления для строк или столбцов — например, сумму, среднее, минимальное или другое значение. После применения настроек итоги сразу отображаются в таблице. Новый механизм помогает быстрее получать сводные показатели и анализировать данные без дополнительной обработки или экспорта информации во внешние инструменты.</p> <p>Еще одно изменение касается электронных таблиц. Теперь их можно автоматически экспортировать в формат XLSX прямо из алгоритмов. Для этого в платформе появились новые функции, которые позволяют сформировать файл, сохранить его в системе или использовать для дальнейшей автоматизированной обработки. Такой сценарий может применяться для регулярной отчетности, обмена данными с внешними системами и подготовки табличных документов по заданным правилам.</p> <p>«Новые возможности помогают сократить количество ручных операций при работе с аналитикой и отчетностью. Пользователь может получить сводные показатели непосредственно в OLAP-представлении, при необходимости скорректировать данные, а затем автоматически сформировать XLSX-файл. В результате весь процесс, от анализа информации до подготовки отчета, выполняется в рамках единого рабочего сценария», — отметила Ксения Золотарева, директор по продукту GreenData.</p> Компания GreenData, российский разработчик low-code-платформы, выпустила обновление, которое упрощает полный цикл работы … message https://www.itweek.ru/themes/detail.php?ID=235430 Mon, 31 Aug 2026 09:53:09 +0300 <p>Далеко не каждой системе необходим отдельный Kafka, RabbitMQ или специализированный message-брокер: для многих backend-продуктов очередь на базе PostgreSQL проще и надежнее в эксплуатации. Используя FOR UPDATE SKIP LOCKED, advisory locks, transactional outbox и корректную модель повторной обработки, можно связать изменение бизнес-данных и постановку фоновой задачи в одной транзакции.</p> <p>В статье разбираю реализацию пула обработчиков на Go, конкуренцию между потребителями и нарастающую задержку перед повтором. Показываю, как работать с очередью необработанных сообщений, корректной остановкой и очисткой накопившихся записей. А ещё определяю границу, после которой очередь поверх Postgres перестаёт быть прагматичным решением и проигрывает специализированному брокеру сообщений — по пропускной способности, времени отклика и управляемости.</p> <h3>Проблема двух систем</h3> <p>Почти в каждом backend-продукте пользователь оформляет заказ. Системе нужно отправить письмо, сформировать отчёт и вызвать внешние API. Выполнять такую задачу прямо в HTTP-запросе не всегда разумно. Увеличивается время ответа, а пользовательский сценарий становится зависимым от внешних сервисов. Команда обычно пользуется привычным набором: Kafka, RabbitMQ или Redis.</p> <p>Появляется риск рассинхронизации. Заказ уже сохранён в базе, но сообщение в брокер не отправлено. Процесс завершился между двумя операциями. Или обратная ситуация: задача стала доступна воркеру до того, как связанные с ней данные были зафиксированы в базе. Это частный случай проблемы двойной записи. Изменение бизнес-данных и постановка фоновой задачи происходят в разных системах и не образуют одну транзакцию.</p> <p>Классическим ответом на эту проблему является использование паттерна «transactional outbox». Приложение в одной транзакции меняет бизнес-данные и пишет строку в служебную таблицу исходящих сообщений, а отдельный процесс читает её и доставляет сообщение в брокер. Атомарность восстановлена, свойства Kafka или RabbitMQ сохранены. Но в системе появляется ещё один компонент, который нужно писать, разворачивать и мониторить, а брокер по-прежнему остаётся в эксплуатации. Получается, что таблица в PostgreSQL всё равно нужна — вопрос лишь в том, служит она перевалочным пунктом или самой очередью.</p> <p>Можно пойти дальше и убрать брокер совсем. Если очередь живёт в том же PostgreSQL, что и бизнес-данные, то изменение заказа и постановка фоновой задачи — одна атомарная операция. В рамках операции либо произошло и то, и другое, либо ничего. Никакого зазора, в который может провалиться работа.</p> <h3>Одна строчка SQL вместо брокера</h3> <p>Вся конструкция опирается на обычную таблицу — назовём её «jobs». В ней хранится минимум: тип задачи, полезная нагрузка в JSON, статус, время, раньше которого задачу запускать не нужно, а также счётчик попыток. Постановка задачи — это простой INSERT (его можно выполнить в той же транзакции, что и изменение бизнес-данных). Такой процесс закрывает проблему двух систем из предыдущего раздела.</p> <p>Однако остается вопрос, как несколько параллельных Go-воркеров будут разбирать задачи, не выстраиваясь в очередь друг за другом? Ответ — конструкция <strong>FOR UPDATE SKIP LOCKED</strong>, появившаяся в PostgreSQL ещё в версии 9.5:</p> <p><em>SELECT id FROM jobs</em></p> <p><em>WHERE status = ’ready’ AND run_at <= now()</em></p> <p><em>ORDER BY run_at</em></p> <p><em>LIMIT 10</em></p> <p><em>FOR UPDATE SKIP LOCKED;</em></p> <p>Запрос выбирает готовые к запуску задачи и временно блокирует выбранные строки. Если другую задачу уже обрабатывает параллельный воркер, SKIP LOCKED не ждёт освобождения блокировки, а пропускает эту строку и переходит к следующей. Благодаря этому несколько воркеров могут работать одновременно, при этом они не забирают задачу дважды и не создают общую очередь ожидания.</p> <p>Далее воркер в короткой транзакции переводит задачи в статус обработки и фиксирует изменение. Затем он уже выполняет основную работу. Поэтому длительные операции не удерживают блокировки в базе и не мешают другим воркерам получать новые задачи.</p> <h3>Правила работы с очередью</h3> <p>Таблица задач и механизм SKIP LOCKED позволяют нескольким воркерам безопасно забирать работу без дублирования. Чтобы такую очередь можно было использовать в продакшене, нужно предусмотреть обработку сбоев. Если задача завершилась ошибкой, её не стоит сразу удалять. Обычно её возвращают в очередь с задержкой, увеличивая интервал между попытками. Это снижает нагрузку на временно недоступный внешний сервис. После заданного числа неудачных попыток задачу переводят в отдельный статус или хранилище для ручного разбора.</p> <p>Также необходимо учитывать и сбои самих воркеров. Если процесс получил задачу и завершился до окончания работы, она не должна остаться в статусе обработки навсегда. Для этого задаче дают ограниченное время обработки: когда оно истекает, другой воркер может взять её повторно. При штатной остановке воркер, наоборот, перестаёт брать новые задачи и завершает уже начатые.</p> <p>При такой модели возможны повторные запуски одной и той же задачи. Например, внешний API мог получить запрос, а воркер — завершиться до сохранения результата. Поэтому обработчики должны корректно переносить повторное выполнение. Например, не отправлять пуш-сообщение дважды или не создавать повторный платёж.</p> <p>Готовые библиотеки избавляют от необходимости реализовывать эти механизмы с нуля. Для Go можно рассмотреть библиотеки River, gue и другие решения поверх PostgreSQL. Выбор зависит от требований к автоматическим повторам и планированию задач, а также наблюдаемости и модели обработки.</p> <h3>Работает и на серьёзном масштабе</h3> <p>Очередь в PostgreSQL не ограничивается небольшими сервисами. Ее используют и высоконагруженные системы, если очередь проектируют и обслуживают как отдельный компонент.</p> <p>Например, для конкурентного получения задач в Я.Диске используется механизм FOR UPDATE SKIP LOCKED. Масштаб: десятки тысяч задач в секунду и сотни типов задач. Один из крупнейших сервисов рунета выбрал SQL-очередь, при том, что Kafka в компании тоже есть и используется там, где её свойства подходят лучше.</p> <p>Второй кейс — компания 37signals, создатели фреймворка Ruby on Rails, Basecamp и почтового сервиса HEY. В HEY отказались от Redis и перевели фоновые системы на очередь Solid Queue. Она обрабатывает около 20 млн. задач в сутки. Для этого используются 800 воркеров, четыре диспетчера и два планировщика на 74 виртуальных машинах. Очередь работает в отдельной базе данных, для которой выделены 32 CPU, 64 Гб памяти и 350 Гб диска. Solid Queue стал очередью по умолчанию в Ruby on Rails 8, а подход официально признан стандартом целой экосистемы.</p> <h3>Где начинаются проблемы</h3> <p>Очередь в PostgreSQL удобна, пока нагрузка на неё остаётся умеренной и предсказуемой. Но у подхода есть особенности, которые нужно учесть до запуска в продакшен.</p> <p>Первая особенность связана с частым изменением записей. Задача обычно создаётся, затем меняет статус, а после выполнения удаляется или архивируется. В PostgreSQL старые версии строк не исчезают сразу, их очищает механизм vacuum. Если он не успевает за потоком обновлений, таблица и индексы разрастаются, а запросы к очереди начинают работать медленнее. Поэтому для таблицы задач обычно настраивают отдельные параметры autovacuum, следят за размером таблицы и не хранят завершённые задачи.</p> <p>Вторая особенность касается механизма LISTEN/NOTIFY. Его суть в мгновенных уведомлениях, которыми удобно будить воркеров вместо периодического опроса таблицы. Компания Recall.ai в марте 2025 года получила из-за него три простоя: уведомления выполнялись в транзакциях, а на этапе COMMIT возникала конкуренция за глобальную блокировку, из-за чего коммиты фактически выстраивались в очередь. В PostgreSQL 19 обещают внедрить улучшения, которые уменьшают лишние пробуждения backend-процессов при NOTIFY, но это не отменит необходимости измерять поведение конкретной системы под нагрузкой.</p> <h3>Где проходит граница очередей</h3> <p>Интуитивно хочется провести границу и разделить применение очередей по реальной нагрузке. Но с большим опытом приходит понимание, что универсального порога по нагрузке нет. На практике значение имеют размер задач, число воркеров, индексы, частота повторных попыток и ресурсы самой базы.</p> <p>Гораздо важнее оценивать стоимость эксплуатации. Очередь на PostgreSQL удобна, пока использует существующую базу: те же бэкапы, мониторинг, инструменты диагностики и компетенции команды. Для многих прикладных задач этого достаточно — особенно, если очередь обслуживает фоновые операции одного приложения.</p> <p>Очереди «Яндекс Диска» и 37signals показывают, что PostgreSQL способен обрабатывать очень большой поток задач, но для этого очереди выделяют собственную базу, ресурсы, настройки обслуживания, мониторинг и т. д. У Диска очередь работает на шардированной базе с отдельной обвязкой, а в 37signals для Solid Queue используется выделенная база данных.</p> <p>Не менее важна семантика. Очередь в PostgreSQL — когда одному приложению нужно выполнить фоновую задачу. Если же одно событие должны независимо получать несколько сервисов, а историю нужно хранить и перечитывать — лучше подходит Kafka. Она рассчитана на хранение потока событий и независимое чтение разными группами потребителей.</p> <p>RabbitMQ уместнее, когда нужны готовые механизмы маршрутизации, подтверждения обработки и управления потоком сообщений. Эти возможности можно частично реализовать поверх таблицы в PostgreSQL, но тогда очередь постепенно превращается в собственный брокер, который нужно проектировать и сопровождать. RabbitMQ же предоставляет подтверждения обработки сообщений как встроенный механизм.</p> <p>Очередь на PostgreSQL не заменяет Kafka или RabbitMQ, но хорошо подходит для фоновых задач. Главный критерий выбора — не популярность или абстрактный предел по числу задач. В приоритете — какие свойства требуются системе и сколько будет стоить их эксплуатация.</p> <p>#IMAGE_235431#</p> Далеко не каждой системе необходим отдельный Kafka, RabbitMQ или специализированный message-брокер: для многих … article Роман Муковнин, старший инженер-программист WildBerries https://www.itweek.ru/themes/detail.php?ID=235429 Mon, 31 Aug 2026 09:44:38 +0300 <p><em>Опрошенные порталом </em><em>InformationWeek</em> <em>эксперты рассказывают о том, как </em><em>CIO</em> <em>могут помочь своим компаниям справиться с растущими и непредсказуемыми расходами на искусственный интеллект и сформировать бюджет, который будет приносить прибыль.</em></p> <p>Предприятиям не обойтись без расходов на ИИ. Но просто вкладывать деньги в эту технологию недостаточно для того, чтобы раскрыть ее потенциал в качестве инструмента повышения эффективности и роста доходов. Выделение бюджета на ИИ, который приносит реальную выгоду, является непростой задачей, поскольку CIO приходится учитывать расходы, которые не всегда очевидны.</p> <p><a href="https://assets.kpmg.com/content/dam/kpmgsites/xx/pdf/2026/06/global-ai-pulse-q2.pdf">Исследование</a> KPMG «Q2 2026 Global AI Pulse» показало, что только 35% организаций имеют полное представление о своих операционных расходах, связанных с ИИ. Эти организации в пять раз чаще сообщают о подтверждённой окупаемости инвестиций, чем те, у кого такой информации нет.</p> <h3>Почему расходы на ИИ сложно спрогнозировать</h3> <p>У предприятий нет чёткой схемы бюджетирования ИИ. Руководители компаний выясняют всё на ходу, а это значит, что неожиданностей и ошибок не избежать.</p> <p>«Очень легко столкнуться с непредвиденными расходами. И очень, очень сложно обеспечить структурированность и предсказуемость при масштабировании возможностей ИИ в крупной организации», — говорит Пол Блоуэрс, CIO компании Plante Moran, занимающейся аудитом, налогообложением, консалтингом и управлением активами.</p> <p>Расходы на ИИ не ограничиваются покупкой платформы или инструмента. Чтобы ИИ приносил пользу, ему нужна правильная основа, а для создания такой основы требуются инвестиции.</p> <p>«Вам нужен уровень данных, вам нужен уровень контекста, вам нужен уровень перевода. Кроме того, у вас будут уровень ИИ и уровень активации», — говорит Кристин Парк, директор по трансформации компании Branch, занимающейся мобильной аналитикой и диплинкингом. К этим базовым требованиям добавляются вопросы безопасности и управления, которые крайне важны.</p> <p>По словам Парк, в ее компании создание такой основы потребовало затрат на очистку баз данных и знаний. Кроме того, она наняла пару инженеров по автоматизации на основе ИИ, чтобы они помогали с рабочими процессами.</p> <h3>Затраты на внедрение ИИ не ограничиваются инструментами</h3> <p>При планировании бюджета на ИИ необходимо учитывать затраты на изменение методов работы сотрудников и способов выполнения самой работы.</p> <p>«Если вы закладываете в бюджет только стоимость инструмента, то, на мой взгляд, вас ждут проблемы, потому что нужно закладывать средства и на трансформацию, — говорит Парк. — Инструмент — это доступ, а трансформация — это переосмысление вашей работы».</p> <p>Переосмысление методов работы команд требует времени и денег. По словам Парк, это «сложный проект», который включает в себя изменения в реализации, конфигурации и рабочих процессах. «ИИ не решает всех проблем. ИИ — это инструмент», — отмечает она.</p> <h3>Затраты на использование ИИ сложно предсказать</h3> <p>Потребление по-прежнему является сложной частью головоломки бюджетирования ИИ. Цены на токены упали, но их использование резко возросло.</p> <p>«Каждый раз, когда выходит новая модель или новый сценарий использования внедряется в производственный процесс, потребление этих токенов растет все быстрее и быстрее, — говорит Блоуэрс. — Мы, CIO, сейчас становимся специалистами в области моделирования и ведения переговоров по токенам, но ситуация в этой сфере пока далека от стабильности».</p> <p>Он ожидает, что модели ценообразования на токены будут продолжать развиваться, а поставщики будут предлагать разные подходы.</p> <h3>ИИ увеличивает расходы</h3> <p>Предприятиям приходится не только самостоятельно решать вопрос с расходами на ИИ, но и учитывать, как инвестиции поставщиков в ИИ влияют на их затраты. Провайдеры SaaS-решений ищут способы встроить ИИ в свои продукты и монетизировать его, что приводит к росту цен.</p> <p>«Большинство ведущих поставщиков SaaS существенно повышают цены, чтобы реализовать свои планы по внедрению ИИ, — говорит Блоуэрс. — И можно с уверенностью сказать, что многие, если не большинство CIO, согласятся с тем, что эти цены растут еще до того, как будут внедрены зрелые функции ИИ, или до того, как мы сможем спрогнозировать, как будет выглядеть потребление внутри этих SaaS-инструментов и платформ».</p> <h3>Как бюджетируют ИИ</h3> <p>Учитывая, что затраты на ИИ так трудно предсказать, CIO начинают переосмысливать бюджетирование этой технологии. Для Парк это означает, что расходы на ИИ рассматриваются не как постоянная статья расходов, а как переменные затраты. «Это модель, основанная на потреблении. Это не фиксированная стоимость, как у SaaS», — поясняет она.</p> <p>Для компаний, которые не приложили достаточных усилий для создания прочной основы для инструментов и рабочих процессов ИИ, обсуждение бюджета может начаться с оценки затрат на создание всего с нуля. Эта основа очень важна. Опрос PwC «2026 Global CEO survey», в котором приняли участие 4454 топ-руководителя, показал, что организации с прочными основами, которые описываются как «ответственные платформы и технологические среды ИИ, обеспечивающие интеграцию в масштабах всего предприятия», имеют в три раза больше шансов получить «значимую финансовую отдачу».</p> <p>При планировании затрат на трансформацию предприятиям необходимо четко представлять, что означает интеграция ИИ для бизнеса. Парк утверждает, что чрезмерное внимание к показателям эффективности является ошибкой. «Мы действительно рассматриваем это как ключевой аспект исследований и разработок, потому что я не думаю, что ИИ должен быть инструментом повышения эффективности, — говорит она. — Я не считаю, что ИИ следует рассматривать как способ сокращения затрат на персонал. Я думаю, это неправильная формула».</p> <p>Независимо от того, какой путь выберут компании — повышения эффективности или внедрения инноваций, — им необходимо заложить в бюджет расходы на внедрение и использование ИИ. Дело не ограничивается покупкой ИИ-инструмента или платформы и требованием к сотрудникам их использовать. «Предоставить людям доступ — это еще не значит внедрить технологию», — говорит Парк.</p> <p>Конечно, по мере внедрения ИИ его использование — и затраты — могут расти. И бюджеты на ИИ должны учитывать этот рост.</p> <p>Блоуэрс вместе с другими руководителями работает над формированием бюджета своей компании на повседневное использование ИИ, в том числе инструментов для повышения производительности. «Мы планируем развивать этот подход по аналогии с FinOps: стимулировать внедрение, предоставлять сотрудникам возможность контролировать расходы, вводить ежемесячные лимиты с некоторыми поведенческими стимулами, — отмечает он. — Обучение само по себе является ключевым инструментом контроля затрат, а не просто способом ограничить потребление токенов».</p> <p>Они также занимаются определением сценариев использования ИИ для масштабирования. «Масштабирование немного проще контролировать с точки зрения затрат, планировать и прогнозировать, потому что мы централизуем процессы и они проходят через наши обычные бизнес-процессы и этапы жизненного цикла разработки ПО», — говорит Блоуэрс.</p> <p>ИИ, встроенный в SaaS-продукты, — это третья статья расходов, которой занимаются Блоуэрс и его коллеги. Это значит, что нужно обсуждать с поставщиками, как ИИ встраивается в уже имеющиеся у компании инструменты и как это влияет на цены при продлении контрактов.</p> <p>«Чтобы справиться с этой проблемой, мы настаиваем на том, чтобы наши партнеры-поставщики соглашались на наши условия, разрабатывали проактивные дорожные карты и оценивали влияние на наши прибыль и убытки, прежде чем соглашаться на предлагаемое ими ценообразование токенов», — говорит Блоуэрс.</p> <p>В компании Парк консолидация инструментов стала частью подхода к бюджетированию. «Вам нужно начать консолидировать инструменты, чтобы получить экономию», — говорит она.</p> <h3>Роль CIO в бюджетировании ИИ</h3> <p>CIO играет ключевую роль во внедрении и бюджетировании ИИ, но для этого ему необходимо взаимодействовать с другими руководителями высшего звена и членами совета директоров, чтобы определить, какую ценность они ожидают получить от ИИ и сколько готовы на это потратить.</p> <p>Поэтому особенно важным партнером является финансовый директор. «Нужно тесно сотрудничать с финансовыми директорами, — говорит Блоуэрс. — Честно говоря, здоровая критика в этом вопросе полезна. Финансовый директор выступает за тщательный контроль бюджета, связанного с ИИ».</p> <p>Давление на CIO не ограничивается контролем расходов. Генеральные директора и члены совета директоров также ожидают, что их ИТ-руководители будут управлять рисками, связанными с ИИ, и при этом не отставать от конкурентов.</p> <p>«Мы сталкиваемся с огромным сопротивлением в вопросах затрат, огромным сопротивлением в вопросах рисков и огромным давлением, требующим действовать быстрее и делать больше, чтобы не отставать, — отмечает Блоуэрс. — Роль CIO заключается в том, чтобы увязать все эти опасения в рамках нашей ИИ-стратегии и помочь найти баланс в этом вопросе».</p> Опрошенные порталом InformationWeek эксперты рассказывают о том, как CIO могут помочь своим компаниям справиться … article https://www.itweek.ru/themes/detail.php?ID=235426 Fri, 28 Aug 2026 00:00:00 +0300 <p><em>С 1 сентября в России вступают в силу изменения в законодательстве, которые затронут всех владельцев доменов в зонах </em><em>.RU, .SU и .РФ. Согласно Федеральному закону № <nobr>569-ФЗ,</nobr> регистрация и дальнейшее управление доменными именами будут возможны только после идентификации администратора через ЕСИА («Госуслуги</em><em>»)</em><em>. При этом подзаконные акты, которые должны определить порядок применения новых требований, пока находятся в стадии разработки. </em><em>Рассмотрим</em><em>, какие риски это создает для бизнеса и что предпринимателям стоит сделать уже сейчас.</em></p> <p>Идея обязательной идентификации направлена на снижение количества анонимных регистраций и мошенничества с доменными именами. После внедрения механизма каждый администратор домена будет подтверждать свою личность через «Госуслуги» — ЕСИА, что, по замыслу авторов нововведения, должно повысить прозрачность российского доменного пространства.</p> <p>Рынок уже начал готовиться к изменениям. Наблюдается заметный рост количества обращений клиентов к регистраторам по вопросам переоформления доменов и актуализации регистрационных данных. Серьезной нагрузки на службы поддержки пока нет, окончательные правила регистрации будут утверждены до 1 сентября. И у регистраторов остается время на полноценное тестирование новых процессов и интеграцию с государственными информационными системами.</p> <h3>Какие риски влекут новые правила</h3> <p>Главный риск для компаний связан не со штрафами — их закон не предусматривает, — но с потерей возможности управлять собственным доменом. Если администратор не сможет пройти идентификацию через ЕСИА, он так же не сможет зарегистрировать новый домен в зонах .RU, .SU и .РФ, продлить срок его действия, изменить регистрационные данные или перенести домен к другому регистратору. В перспективе это может привести к утрате самого доменного имени. Нововведения касаются именно кантри-кодов .RU, .SU и .РФ — или страновых доменов, которые в отличии от доменов общего пользования, таких как, например, .РУС, могут иметь отдельные требования и правила регистрации.</p> <p>Еще один риск — потеря доступа к корпоративной почте и связанным с ней онлайн-сервисам. Если почта работает на домене компании (name@company.ru), а компания потеряла возможность управлять им, могут возникнуть проблемы с почтовыми настройками: станет невозможно изменить <nobr>MX-записи,</nobr> которые указывают, где находится почта, или подтвердить права на домен для почтовых сервисов, могут также возникнуть перебои в доставке писем. Компании, которые используют корпоративную почту или домен для авторизации, восстановления доступа или подтверждения владения системами аналитики, рекламными кабинетами, облачными сервисами, CRM, сервисами для рассылок и прочими онлайн-сервисами, потеряют доступ к этим ресурсам.</p> <h3>Как подготовиться к новой процедуре идентификации</h3> <p>Особенно внимательно стоит проверить старые корпоративные сайты. Нередко оказывается, что домен зарегистрирован не на владельца бизнеса, а на бывшего директора, системного администратора, разработчика сайта или даже на юридическое лицо, которое уже ликвидировано.</p> <p>Такая ситуация часто остается незамеченной, так как при повседневной работе сайта компании обычно не требуется взаимодействовать с администратором домена. Компания пользуется сайтом и считает его своим, потому что у нее есть доступ к CMS, хостингу, контенту, есть возможность менять страницы.</p> <p>В результате бизнес может не знать, что права на управление доменным именем оформлены на человека, который больше не связан с компанией. Но после введения идентификации через ЕСИА именно такая ситуация может стать причиной потери доступа к домену.</p> <p>Соответственно, если домен оформлен на бывшего руководителя или сотрудника, предпринимателю следует заранее установить с ним контакт и провести смену администратора. Сменить администратора после вступления новых правил в силу может оказаться значительно сложнее.</p> <p>Аналогичный подход рекомендуется и компаниям, чьи домены зарегистрированы на организации без подтвержденной учетной записи на «Госуслугах». В этом случае разумно либо заранее создать такую учетную запись, либо переоформить домен на администратора, который сможет пройти необходимую процедуру идентификации через ЕСИА, например, на собственника бизнеса или действующего директора.</p> <p>Владельцам сайтов не стоит ожидать существенного роста расходов. Интеграция с ЕСИА потребует значительных инвестиций от доменных регистраторов, но для конечных пользователей удорожание регистрации и продления доменов составит всего несколько сотен рублей в год. Для бизнеса такие затраты не сопоставимы с рисками потери уже раскрученного сайта, восстановление которого потребует значительно больше времени и средств.</p> <h3>Что делать, если сохранить текущий домен не получится</h3> <p>Если компания понимает, что сохранить существующий домен не удастся, подготовиться к переезду на новый сайт лучше заранее. Для сайтов, уже имеющих поисковый трафик, смена домена без предварительной подготовки может привести к потере позиций в поисковой выдаче, поэтому перенос необходимо планировать заблаговременно, используя инструменты поисковых систем для корректной смены адреса сайта.</p> <p>До появления окончательных правил регистрации стоит провести «ревизию» доменного портфеля: проверить, кто указан администратором каждого домена, актуальны ли регистрационные данные и сможет ли этот человек или организация пройти идентификацию через ЕСИА после вступления новых требований в силу. Именно такая подготовка сегодня остается самым эффективным способом избежать потери доступа к корпоративному сайту.</p> <p>#IMAGE_235427#</p> С 1 сентября в России вступают в силу изменения в законодательстве, которые затронут всех владельцев … article Алексей Созонов, заместитель директора доменного регистратора Webnames.ru https://www.itweek.ru/themes/detail.php?ID=235422 Fri, 28 Aug 2026 00:00:00 +0300 <p><em>Искусственный интеллект — это нечто гораздо большее, чем просто повышение индивидуальной эффективности. Организациям следует задуматься о том, как автоматизация межкомандных процессов может способствовать стратегическому росту и снижению операционного сопротивления, пишет на портале </em><em>InformationWeek</em> <em>Мэтт Лайтесон, </em><em>CIO</em> <em>IBM по технологическим платформам.</em></p> <p>Сегодня слишком много разговоров об ИИ сосредоточено на индивидуальной продуктивности и рутинных задачах, а также на развитии набора навыков. Это важные темы, но бизнес-лидеры упускают из виду ключевой момент.</p> <p>Ценность корпоративного ИИ заключается не в том, чтобы повысить скорость выполнения задач или превзойти человека в креативности, а в чем-то гораздо более значимом: в обеспечении обмена информацией, аналитикой и знаниями в масштабах всей организации и раскрытии потенциала талантов, который сдерживается организационным сопротивлением.</p> <p>Вполне естественно сосредоточиться на том, как ИИ может помочь людям быстрее выполнять задачи, будь то создание рецептов и составление маршрутов для путешествий в домашних условиях или реферирование PDF-файлов и анализ массивов данных на работе. Но компании — это не просто здания, в которых работают «индивидуалисты». Это интегрированные и организованные системы, протоколы, ноу-хау, технологии и многое другое, что позволяет им масштабироваться и постоянно добиваться большего с меньшими затратами.</p> <h3> Масштабирование ИИ за пределы индивидуального уровня</h3> <p>Организационное сопротивление — это не второстепенная проблема. Совокупность внутренней бюрократии, избыточных процессов и других препятствий может существенно замедлить работу команды. По данным исследования, проведенного компанией McKinsey в ноябре 2025 г., 57% рабочего времени в США можно автоматизировать с помощью доступных сегодня технологий.</p> <p>Рассмотрим пример: аналитик по закупкам сверяет заказы на поставку со счетами-фактурами. В настоящее время эти сотрудники тратят много времени на сопоставление позиций, проверку условий договоров с поставщиками и устранение расхождений в данных из разных систем. Это малоэффективная работа, которая отнимает время, силы и возможности для более глубокой и целенаправленной деятельности.</p> <p>А теперь представьте, что весь процесс в значительной степени автоматизирован. Аналитик загружает счет-фактуру или отмечает заказ на поставку. ИИ берет на себя заполнение сметы расходов, сопоставление позиций и предоставляет администраторам инсайты, чтобы они могли быстрее принимать решения и исправлять ошибки. После сверки данные автоматически обновляются во всех финансовых системах. Нет необходимости вводить данные повторно, нет необходимости в ручном контроле, нет напрасной траты времени.</p> <p>Вот когда можно ощутить реальный эффект от внедрения автоматизации. Время экономит не только один аналитик. Благодаря автоматизированной сверке данных отделы закупок, финансов и комплаенса могут направить свои усилия на более важные задачи. Это оптимизирует то, что делается для сокращения операционных расходов, ускорения роста выручки за счет повышения скорости и повышения качества внутренних процессов и управления рисками за счет обеспечения соответствия каждого этапа рабочего процесса политикам, разрешениям и принципам управления. Благодаря этим трем направлениям — оптимизации затрат, ускорению роста и управлению рисками — корпоративный ИИ приносит прибыль, которая намного превышает эффект от прироста производительности отдельных сотрудников.</p> <h3>Создание основы</h3> <p>Для эффективного масштабирования ИИ на предприятии требуется нечто большее, чем просто использование нового инструмента отдельным человеком. Для этого требуется стек ИИ корпоративного уровня, который позволяет пользователям находить нужных агентов, получать доступ к корпоративной информации и генерировать инсайты, которые поддерживают стратегию команды. В сочетании с изменениями в организационной культуре эти возможности на уровне рабочих процессов позволяют по-настоящему получить выгоду от ИИ.</p> <p>Это больше, чем просто автоматизация задач; это оркестрация рабочего процесса. ИИ, работающий на основе упорядоченных данных, четких разрешений и эффективного управления, способен выполнять роль связующей ткани организации, управляя задачами в различных приложениях.</p> <p>В случае с нашим аналитиком по закупкам это означает понимание того, кто уполномочен просматривать данные и утверждать действия, и соответствующее перемещение информации с портала запросов в систему учета расходов. Чистые, интегрированные системы ИИ позволяют аналитику быстро находить нужных агентов или получать доступ к любому из них через единый портал.</p> <p>Когда он обдумывает новый проект, интерактивный ИИ-помощник может ответить на любые его вопросы, предоставив достоверные данные в соответствии с уровнем доступа, и направить ход его мыслей в нужное русло. Если ему нужно связаться с разными членами команды, ИИ-помощник может составить персонализированные сообщения с учетом индивидуальных особенностей, принадлежности к команде, географического положения и других факторов. Использование ИИ позволяет сотрудникам быстро и продуктивно способствовать стратегическому развитию бизнеса.</p> <h3>От работы с ИИ к ИИ как рабочей силе</h3> <p>Это не просто технологическая трансформация. После внедрения ИИ на предприятии компаниям придется пересмотреть свои процессы и корпоративную культуру, чтобы адаптировать их к новым реалиям. Результатом станут не только быстрые ответы на электронные письма и генерация контента. Мы увидим более активный обмен информацией, креативность, стратегическое планирование и критически важную работу, которую сотрудники смогут выполнять, не отвлекаясь на то, что у них получается хуже всего.</p> <p>Ставки высоки: по оценкам McKinsey, ИИ может принести компаниям прибыль в размере 4,4 трлн. долл. Мы уже видим это на примере IBM: мы уже сэкономили 4,5 млрд. долл., несмотря на то, что ИИ только начинает проникать в нашу деятельность. Внедрив методы управления организационными изменениями, предприятия могут оптимизировать рабочие процессы, чтобы сократить расходы, ускорить рост доходов и снизить риски.</p> <p>Сейчас самое время подготовиться к этой возможности и воспользоваться ею. После внедрения отдельных ИИ-инструментов компаниям необходимо сосредоточиться на корпоративных рабочих процессах, которые созрели для агентной трансформации. Им следует развернуть единую платформу, которая позволит создавать, повторно использовать, масштабировать и контролировать ИИ на всех уровнях предприятия — и при этом обеспечивать безопасность. По мере внедрения корпоративного ИИ компаниям необходимо вовлекать в этот процесс сотрудников, подталкивать их не только к использованию новых инструментов, но и к переосмыслению рабочих процессов. В совокупности эти шаги запустят «маховик» ИИ, откроют возможности для непрерывных инноваций и в конечном итоге обеспечат значимую бизнес-ценность.</p> Искусственный интеллект — это нечто гораздо большее, чем просто повышение индивидуальной эффективности. Организациям следует … article https://www.itweek.ru/themes/detail.php?ID=235417 Fri, 28 Aug 2026 00:00:00 +0300 <p><em>Глобальная стратегия Atlassian по переходу в облако делает миграцию из этой экосистемы все более актуальной задачей для российских компаний. Рассмотрим, как при переходе сохранить бизнес-логику, минимизировать риски и правильно организовать процесс.</em></p> <h3>Почему пришло время мигрировать c Atlassian</h3> <p>Решениями Atlassian еще пользуются в российских компаниях, но все больше факторов подталкивают бизнес к переходу на альтернативные платформы. 15 февраля 2024 года вендор прекратил официальную поддержку, выпуск обновлений и исправлений для продуктов линейки Server. Формально эти системы можно продолжать использовать в закрытом контуре, принимая на себя риски.</p> <p>30 марта 2026 года закрылись продажи продуктов линейки Data Center новым клиентам, а с 30 марта 2028 года обладатели действующих подписок не смогут покупать новые лицензии, расширения и приложения из Atlassian Marketplace. 28 марта 2029 года жизненный цикл локальных решений окончательно подойдет к концу: сроки действия подписок Data Center завершатся, а системы, связанные с приложениями из Marketplace, перейдут в режим только для чтения.</p> <p>На смену этим решениям в экосистеме вендора приходит линейка Cloud. Это часть стратегии перевода в облако, которую Atlassian последовательно реализует уже несколько лет. Однако российскому бизнесу Cloud подходит не на 100%, поскольку не в полной мере отвечает требованиям информационной безопасности, не поддерживает работу в закрытом контуре и сложную кастомизацию. К тому же многие отечественные компании не могут выносить данные в зарубежный облачный сервис.</p> <p>В этих условиях раннее планирование миграции с Atlassian выглядит оптимальным вариантом. Оно позволит избежать рисков, связанных с продолжением эксплуатации устаревших продуктов без официальной поддержки.</p> <p>Во-первых, даже закрытый контур не делает систему «бессмертной». Чем дольше она работает без обновлений безопасности, тем выше становятся накопленные риски. Во-вторых, по мере модернизации остальной ИТ-инфраструктуры может ухудшаться ее совместимость с лишенными поддержки решениями Atlassian. В-третьих, через два-три года может быть сложнее найти сотрудников, хорошо знакомых со старой версией системы, старыми плагинами и кастомизациями. В-четвертых, бизнес-процессы постепенно перестраиваются, а вместе с ними должна дорабатываться платформа. Такие изменения лучше вносить сразу в новую систему, чем в старую, от которой вероятно придется отказаться.</p> <h3>Что перенести на новую платформу</h3> <p>При миграции с Atlassian в первую очередь следует перенести управление задачами, проектами и статусами, а главное — жизненными циклами, ведь именно на них опираются реальные бизнес-процессы. Важно переместить не просто карточки, а соответствующие им операции, иначе система не будет работать и превратится в обычный архив.</p> <p>Второй слой миграции — структура данных: настраиваемые поля и схемы распределения прав доступа. Они кажутся незначительными элементами, но именно на их основе строятся отчетность, маршрутизация, фильтры и SLA (соглашения об уровне услуг). Главное — не копировать все поля и права без изменений, а заново собрать модель таким образом, чтобы она была безопасной и актуальной.</p> <p>Третий слой — аналитика: дашборды, отчеты и настроенные фильтры. Основная ценность системы для руководителей часто заключается не в управлении задачами, а именно в этих инструментах. Без них даже переход на более мощную платформу может вызвать негативную реакцию менеджмента. В связи с этим следует тщательно продумать перенос аналитики и заранее включить его в план проекта.</p> <p>Четвертый слой — базы знаний из Confluence и сопутствующие вложения из Jira. При миграции важно оценить, какие из них лучше перенести в активный контур, какие — архивировать, а какие — удалить. Переход на новую платформу станет удачным моментом для такой оптимизации.</p> <p>Следующий слой — экосистема: внешние интеграции и установленные плагины, которых в крупной компании может накопиться очень много. Для их правильного переноса следует перед миграцией составить архитектурную схему, на которой будет указано, какие интеграции и плагины используются, зачем они нужны и насколько они критичны для бизнеса. Это поможет спланировать, что предстоит актуализировать, что — собрать заново, а что — заменить.</p> <h3>Пошаговый план миграции</h3> <p>Чтобы переход на новую платформу прошел успешно, важно использовать системный подход к подготовке и осуществлению миграции. Эту работу можно разделить на шесть шагов.</p> <p><strong>Шаг 1. Инвентаризация данных и аудит процессов. </strong>Сначала необходимо проанализировать набор используемых продуктов Atlassian, проверить их версии и сроки окончания поддержки. Следует оценить связанные с платформой риски на горизонте двух-трех лет, а также определить, требуется ли ее дорабатывать в ближайшее время. Работа в условиях закрытого контура не снимает вопросы технической поддержки, информационной безопасности, обновлений, совместимости и планирования выхода из экосистемы — их все равно нужно прояснить заранее. Также следует составить карту процессов, разделяя их по сценариям и выделяя критически важные для бизнеса операции. Это поможет сделать обоснованный выбор, на какую систему или гибридное решение переходить. Главным критерием должна стать возможность воспроизвести текущие процессы на новой платформе.</p> <p><strong>Шаг 2. Проектирование целевой модели в новой системе. </strong>После инвентаризации следует спроектировать целевую модель с описанием того, как процессы будут функционировать после перехода. Необходимо определить, какие операции перейдут в новую систему, что произойдет с архивом, где потребуются интеграции и как они будут работать, а также каким образом будет организован переход пользователей. Отдельного внимания требуют правила переноса исторических данных и нефункциональные требования. Необходимо описать, как должна работать система, задать требования к отказоустойчивости и информационной безопасности.</p> <p><strong>Шаг 3. Первичная настройка и кастомизация платформы. </strong>На этом этапе нужно настроить выбранную платформу или связку платформ: создать процессы, формы, роли и другие элементы, необходимые для работы решений, а также настроить права доступа, аналитику, уведомления, интеграции и маршруты согласования — все то, что обеспечивает функционирование ПО в рамках реальных рабочих процессов. Важно не стремиться к точному копированию старой системы, иначе есть риск перенести накопившиеся в ней проблемы в новый интерфейс; устаревшие процессы целесообразно собрать заново, проведя их аудит и оптимизацию.</p> <p><strong>Шаг 4. Тестовый перенос ограниченного объема данных. </strong>В его рамках следует проверить, как в новую систему перемещаются задачи, поля, статусы и другие элементы. Особое внимание стоит уделить тому, что не перенеслось автоматически: как правило эта информация наиболее полезна для доработки процесса. В автоматическом режиме обычно переносятся задачи, описания и другие элементы, поддающиеся прямому сопоставлению. Однако корректность такого переноса напрямую зависит от точности карты соответствия полей между системами, особенно если платформы различаются по структуре данных. При этом важно четко определить назначение каждого элемента: без правильной интерпретации значений старых полей и статусов автоматизированный перенос данных может пройти некорректно. По итогам этого шага необходимо проанализировать миграционный отчет, однако не менее важна сама практика тестового переноса.</p> <p><strong>Шаг 5. Проверка реальных пользовательских сценариев. </strong>На этом этапе в первую очередь тестируют пользовательский опыт: насколько удобно создавать заявки, согласовывать их и назначать исполнителей, работают ли переназначение по процессу, SLA и аналитика, закрываются ли обращения и насколько удовлетворены пользователи. Если все эти сценарии выполняются корректно, миграция становится не просто технически успешной, но и полезной для бизнеса.</p> <p><strong>Шаг 6. Итоговая промышленная миграция. </strong>Финальный этап — промышленная миграция, сопровождаемая волнами коммуникации с командами. Она должна стать не резким отключением старой системы, а плавным управляемым переходом, о котором заранее знают все участники и в рамках которого четко определены роли и зоны ответственности. Это исключает ситуации, в которых сотрудники месяцами дублируют работу в двух системах одновременно, и позволяет сервисным менеджерам бесшовно перейти на новую платформу.</p> <h3>Основные риски миграции</h3> <p>Если неправильно спланировать переход на новую платформу, можно нарушить уникальную бизнес-логику, зафиксированную в глубоких кастомизациях решений Atlassian. Это более серьезный риск, чем потерять данные. Даже если успешно перенести все задачи, комментарии и вложения, но упустить из виду правила согласования или автоматическое переназначение, бизнес-процесс не будет работать.</p> <p>Другой важный риск — сложности и ошибки при переносе исторических данных. Если таких записей накопилось много, перемещать весь массив может быть дорого, долго и нецелесообразно. Однако вовсе не перенести исторические данные — опасно для бизнеса. Разумным выбором станет категоризация элементов с учетом ценности и применения в рабочих процессах.</p> <p>Третий риск при миграции — неполный или некорректный перенос прав доступа и ролевых моделей. Следует отдельно планировать распределение прав на новой платформе: если они выйдут за нужные рамки, возникнут проблемы безопасности, а если слишком сильно ограничить доступ, пользователи не смогут нормально работать. Это особенно критично для сервисных процессов, HR-заявок, защиты данных, финансовых согласований, проектной документации и базы знаний.</p> <p>Четвертый риск — жесткая зависимость от приложений из Marketplace, у которых нет прямых аналогов. На старых версиях Atlassian одни и те же плагины могли работать годами. В таких случаях при миграции возникают вопросы, какую логику они используют, кто ее поддерживает, можно ли отказаться от этих приложений и есть ли у них аналоги. Иногда небольшой плагин оказывается самым критичным элементом всего бизнес-процесса, поэтому миграцию надо начинать с аудита, а не с выбора новой платформы.</p> <p>Наконец, главная ошибка — попытка перенести систему как есть, без предварительной оптимизации. При таком подходе вместе с полезными составляющими можно скопировать источники хаоса. Задача миграции не сохранить все плюсы и минусы старой системы, а обеспечить корректную работу процессов, убрать лишнее и выстроить эффективную архитектуру.</p> <h3>Безопасный переход</h3> <p>Сделать миграцию максимально комфортной и безопасной поможет в первую очередь отказ от переноса всех составляющих старой системы. Активные элементы можно добавить в рабочий контур, важные исторические данные — сохранить в архиве, а ненужные записи — удалить. Еще одним обязательным условием успеха станет тестовый перенос. Пилотная часть проекта поможет проверить критически важные узлы архитектуры и оценить реальную картину.</p> <p>Для компании, которая рассматривает миграцию с Atlassian, на первом плане должен быть не вопрос, работает ли платформа сегодня, а возможность безопасно выстраивать процессы на ее базе в перспективе. Если слишком долго откладывать переход на новую систему, можно оказаться в ситуации, когда поддерживать старые решения слишком дорого, а отказаться от них слишком сложно. В связи с этим лучше заранее выстроить на основе отечественного ПО новую жизнеспособную архитектуру, которая будет получать официальную поддержку и эволюционировать вместе с бизнес-процессами компании.</p> <p>#IMAGE_235418#</p> Глобальная стратегия Atlassian по переходу в облако делает миграцию из этой экосистемы все более актуальной … article Константин Преображенский, начальник отдела аналитики и проектов IBS https://www.itweek.ru/themes/detail.php?ID=235408 Fri, 28 Aug 2026 00:00:00 +0300 <p><em>DNS </em><em>(Domain Name System</em><em>,</em><em> система доменных имен)</em> <em>редко попадает в поле зрения пользователей и даже менеджмента компаний: пока сайт открывается, о не</em><em>й</em><em> почти не вспоминают. Но чем сильнее бизнес зависит от онлайн-каналов, тем важнее становится этот невидимый слой интернета. От DNS зависит, откроется ли сайт, сработает ли приложение, пройдет ли запрос к API и продолжит ли компания общаться с клиентами через цифровые сервисы. </em><em>Рассмотрим</em><em>, почему DNS в России становится вопросом устойчивости бизнеса.</em></p> <p>Раньше DNS воспринималась скорее как техническая настройка: пока сайт открывался, бизнес редко задумывался, как именно работает маршрутизация трафика. Однако за последние несколько лет ситуация изменилась. Для компаний DNS постепенно становится вопросом не только производительности, но и устойчивости, управляемости и контроля над критическими сервисами.</p> <p>Причин здесь несколько. Бизнес всё сильнее зависит от цифровых каналов: сайт, приложение, API (Application Programming Interface, интерфейс для обмена данными и командами между разными программами и цифровыми системами), почта, личный кабинет — всё это начинается с DNS. Одновременно растут требования к доступности сервисов и предсказуемости инфраструктуры. В этих условиях рынок постепенно переходит от классической модели DNS к более распределенным архитектурам, в первую очередь — к Anycast.</p> <h3>Что такое DNS и почему это важно для бизнеса</h3> <p>DNS — базовый механизм маршрутизации интернет-трафика, который связывает доменное имя с сервером, где расположен сервис.</p> <p>Когда пользователь вводит адрес сайта, открывает мобильное приложение или обращается к API, именно DNS определяет, куда должен быть направлен запрос и насколько быстро он дойдет до нужного ресурса. Этот процесс остается незаметным для пользователя, но напрямую влияет на доступность цифрового сервиса.</p> <p>От DNS зависят:</p> <ul> <li> скорость первого отклика сайта или приложения;</li> <li> стабильность пользовательского доступа;</li> <li> корректная работа почты и цифровых сервисов;</li> <li> возможность быстро управлять инфраструктурой;</li> <li> устойчивость сервисов при нагрузках и сбоях.</li> </ul> <p>Через DNS компании настраивают почтовую инфраструктуру, подтверждают права на домены для внешних сервисов, подключают аналитические и облачные платформы, управляют маршрутизацией трафика. Поэтому DNS постепенно становится связующим слоем между доменом, инфраструктурой и пользователем.</p> <p>Если DNS работает медленно или нестабильно, пользователь может не попасть к сервису даже в том случае, если сама инфраструктура продолжает работать корректно. В цифровой экономике отказ DNS — это уже прямой операционный риск.</p> <h3>Почему DNS переходит к распределенной модели</h3> <p>Традиционно DNS строилась по модели Unicast: один IP-адрес соответствует одному конкретному серверу. Пользовательский запрос всегда направляется в заранее определенную точку. Если сервер находится далеко или испытывает высокую нагрузку, растет задержка ответа, а при сбое страдает доступность сервиса.</p> <p>Модель Anycast работает иначе. Один и тот же IP-адрес одновременно используется на нескольких географически распределенных узлах, а запрос автоматически направляется к ближайшей или наиболее доступной точке. За счет этого сервис не зависит от одного узла: если одна точка перегружена или недоступна, запросы могут обслуживаться через другие узлы сети.</p> <p>Для бизнеса это дает сразу несколько эффектов:</p> <ul> <li> снижение задержки и более быстрый отклик сервисов;</li> <li> распределение нагрузки между несколькими узлами;</li> <li> более высокую устойчивость к сбоям;</li> <li> возможность масштабировать инфраструктуру без остановки сервисов.</li> </ul> <p>Именно поэтому Anycast давно используется крупными глобальными DNS-провайдерами и сетями серверов для быстрой доставки контента пользователям (CDN-платформами) как базовая архитектура для сервисов с высокими требованиями к доступности.</p> <p>По сути, DNS проходит ту же трансформацию, которую раньше прошли облачные платформы и сети доставки контента: из вспомогательной настройки она превращается в отдельный инфраструктурный слой со своими требованиями к производительности и отказоустойчивости. При этом Anycast не отменяет необходимости правильно управлять DNS-зонами: контролировать записи, доступы, сроки действия доменов, изменения конфигурации и резервные сценарии. Технология повышает устойчивость, но не заменяет операционную дисциплину.</p> <h3>Почему тема DNS стала особенно актуальной сейчас</h3> <p>Переход к Anycast — это естественный этап развития DNS-инфраструктуры, который уже стал стандартной практикой для высоконагруженных сервисов. В России этот подход сегодня получает более широкое распространение — во многом под влиянием изменений в технологической и регуляторной среде последних лет.</p> <p>После 2022 года компании начали учитывать не только технические характеристики сервисов, но и устойчивость инфраструктуры к внешним ограничениям: доступность поддержки, стабильность расчетов, зависимость от зарубежной юрисдикции. Даже в случаях, когда зарубежные сервисы продолжают работать, бизнес всё чаще оценивает риски, связанные с критической зависимостью от внешних платформ. Для DNS этот вопрос особенно чувствителен, если доменная инфраструктура становится недоступной или плохо управляемой, последствия могут затронуть не один сервис, а весь цифровой контур компании.</p> <p>Параллельно усилился тренд на «заземление» инфраструктуры — размещение и обслуживание ключевых элементов цифрового контура в России. Этому способствует как регулирование, так и сама логика управления рисками. Речь не только о физическом размещении отдельных сервисов, но и о более понятной юрисдикции, доступной поддержке, прозрачных правилах обслуживания и возможности быстрее реагировать на инциденты.</p> <p><a href="https://www.consultant.ru/document/cons_doc_LAW_61801/?utm_source=chatgpt.com">Закон о персональных данных</a> требует хранить и обрабатывать данные граждан РФ с использованием баз данных на территории страны, а регулирование в сфере <a href="https://www.consultant.ru/document/cons_doc_LAW_220885/?utm_source=chatgpt.com">критической информационной инфраструктуры</a> и <a href="https://www.consultant.ru/document/cons_doc_LAW_323815/?utm_source=chatgpt.com">устойчивости</a> Рунета задает общий вектор на контролируемость и отказоустойчивость цифровых сервисов. DNS напрямую не является базой персональных данных, но она находится в том же контуре операционной устойчивости: без нее не работают сайт, почта, личный кабинет, API и другие сервисы, через которые бизнес взаимодействует с клиентами.</p> <p>В последние годы этот подход начал усиливаться и на практике: регуляторы <a href="https://www.interfax.ru/digital/1017951">рекомендуют</a> использовать российские хостинг- и CDN-площадки в случаях, когда от инфраструктуры зависит стабильность сервисов.</p> <p>Для бизнеса это означает, что вопрос «где расположена DNS» постепенно становится таким же важным, как вопрос «где находятся данные», и компании начинают смотреть на него шире — кто управляет DNS, где находятся ключевые точки инфраструктуры, как быстро можно получить поддержку и какие резервные сценарии предусмотрены на случай сбоя.</p> <h3>Как меняется рынок DNS в России</h3> <p>Исторически компании часто выбирали DNS по остаточному принципу: либо использовали базовые сервисы регистратора, либо подключали зарубежные решения, если требовались высокая производительность и гибкость управления.</p> <p>Сегодня требования изменились. Бизнесу важны:</p> <ul> <li> скорость отклика;</li> <li> отказоустойчивость;</li> <li> прозрачное управление инфраструктурой;</li> <li> масштабируемость;</li> <li> понятная юрисдикция и доступная поддержка.</li> </ul> <p>На этом фоне в России начали активнее развиваться распределенные DNS-модели. В первую очередь они становятся востребованы у компаний, для которых онлайн-каналы напрямую связаны с выручкой, клиентским опытом и непрерывностью процессов: e-commerce, медиа, финансовых сервисов, SaaS-платформ, образовательных проектов и крупных корпоративных сайтов.</p> <h3>Anycast DNS как часть новой операционной устойчивости</h3> <p>Для бизнеса внедрение Anycast выходит за рамки технического обновления DNS и представляет собой стратегический пересмотр архитектуры сетевой инфраструктуры: компании начинают воспринимать цифровые сервисы как непрерывный операционный контур, где отказ даже одного элемента может влиять на выручку, клиентский опыт и стабильность процессов.</p> <p>В этой логике DNS перестает быть «фоновой настройкой», о которой вспоминают только при регистрации домена. Сегодня от нее зависит, насколько быстро пользователь получит доступ к сервису, как инфраструктура переживает пиковые нагрузки и насколько устойчиво работает цифровой контур в случае сбоев или внешних ограничений. Именно поэтому распределенные модели вроде Anycast постепенно становятся новой инфраструктурной нормой для цифровых сервисов.</p> <p> #IMAGE_235409#</p> DNS (Domain Name System, система доменных имен) редко попадает в поле зрения пользователей и даже менеджмента компаний … article Георгий Казаров, руководитель отдела доменов Руцентра https://www.itweek.ru/themes/detail.php?ID=235425 Thu, 27 Aug 2026 17:41:32 +0300 <p>В сентябре 2026 года компания datagarden, российский разработчик высокопроизводительных систем хранения данных мирового уровня, впервые представит заказчикам vitiscale — собственную горизонтально масштабируемую СХД, спроектированную для самых требовательных задач. vitiscale обеспечивает десятки миллионов IOPS и сотни тысяч RPS в секунду при минимальном времени отклика и гарантирует производительность, необходимую для эффективной работы AI/ML-решений, аналитики больших массивов данных, высоконагруженных ферм СУБД и быстрого восстановления данных.</p> <p>«vitiscale — это полностью оригинальная разработка, а не производное от существующего решения на основе open-source, — рассказал Филипп Комиссаров, технический директор datagarden. — Мы сознательно пошли на то, чтобы переписать программную архитектуру системы хранения практически с нуля: только так можно было извлечь из оборудования максимум и устранить те узкие места, с которыми мы годами сталкивались в ходе эксплуатации хранилищ такого класса. Для заказчика это выражается во вполне практичных вещах: та же задача решается кратно меньшим числом узлов, требует значительно меньше энергии и места в стойках, а производительность и емкость растут линейно и без остановки сервисов. Мы строили vitiscale, ориентируясь на нагрузки эпохи искусственного интеллекта и аналитики больших данных, где одинаково важны и высочайшая производительность, и минимальный отклик».</p> <p>Программная архитектура vitiscale построена на принципах множественного параллельного ввода-вывода и прямого доступа к данным. Это означает, что каждый узел системы обслуживает запросы напрямую — без промежуточных контроллеров метаданных или избыточных шлюзов. Благодаря этому даже при внушительных нагрузках vitiscale требует значительно меньше оборудования, чем классические СХД и open-source-кластеры. vitiscale предоставляет блочный доступ (NVMe over Fabrics (TCP, RDMA, Fibre Channel), а также iSCSI и FC) и объектное хранилище с S3 API. Кластер масштабируется от 3 до 512 узлов с шагом в один узел и без остановки сервисов. Производительность и емкость растут линейно — до десятков петабайт в одной системе. Система совместима с отечественными ОС, включая Astra Linux SE, AltLinux, РОСА и РЕД ОС. Продукт включен в реестр российского ПО Минцифры (№ 23346), программно-аппаратный комплекс на серийной платформе datagarden — в реестр ПАК (№ 28285).</p> <p>Горизонтально масштабируемую СХД vitiscale команда datagarden разрабатывает с 2022 года. Ключевая цель проекта — максимально эффективно использовать аппаратные ресурсы системы. Над продуктом работает команда инженеров, которые в течение многих лет эксплуатировали хранилища данного класса и знают их узкие места изнутри.</p> <p>Компания datagarden разрабатывает и производит в России централизованные и распределенные системы хранения данных. Архитектура и алгоритмы хранения в основе продуктов datagarden соответствуют современным профилям нагрузок — от виртуализации и СУБД до искусственного интеллекта — и рассчитаны на непрерывную эксплуатацию и рост объемов данных.</p> В сентябре 2026 года компания datagarden, российский разработчик высокопроизводительных систем хранения данных мирового … message https://www.itweek.ru/themes/detail.php?ID=235424 Thu, 27 Aug 2026 17:40:05 +0300 <p>В 2026 году два крупнейших регулятора — Евросоюз с AI Act (Regulation (EU) 2024/1689) и Россия с <nobr>243-ФЗ —</nobr> впервые массово перенесли ответственность за ИИ-системы с разработчика модели на всю цепочку, включая провайдера вычислительной среды. Владимир Лебедев, директор по развитию бизнеса сервис-провайдера M1Cloud, рассказал, что теперь географическое расположение GPU, юрисдикция дата-центра и архитектура логирования превращаются в переменные, которые определяют легальность ИИ-модели.</p> <p>AI Act — это первый в мире комплексный подход к регулированию ИИ на уровне целого союза. Он вводит регулирование поэтапно. С февраля 2025 года начали действовать запреты на системы с неприемлемым риском, в том числе запрещены отдельные практики (социальный скоринг, биометрическая идентификация в реальном времени в чувствительных контекстах), и нормы ИИ-грамотности. С августа <nobr>2025-го</nobr> вступили в силу обязательства для поставщиков моделей общего назначения (general-purpose AI или GPAI). С августа <nobr>2026-го</nobr> начал применяться основной массив обязанностей к системам высокого риска. С августа <nobr>2027-го</nobr> начнут действовать дополнительные требования к высокорисковым системам. Именно эта последняя волна бьет по инфраструктуре сильнее всего.</p> <p>На уровне ЕС созданы Управление по ИИ (AI Office) при Еврокомиссии и Европейский совет по ИИ — они координируют правоприменение. AI Office с августа <nobr>2025-го</nobr> имеют инспекционные полномочия и может запрашивать техническую документацию, включая сведения о среде, в которой обучалась и работает модель.</p> <p>Для инфраструктурного провайдера это означает конкретный набор обязательств. Провайдер GPAI-модели обязан вести и актуализировать техническую документацию, описывающую модель, процессы ее обучения и тестирования, результаты оценки; раскрывать пользователям информацию о возможностях и ограничениях модели; соблюдать политику авторских прав; публиковать детальную сводку по обучающим данным по шаблону AI Office. Для моделей, создающих системный риск, добавляются расширенные обязанности — подробные стратегии оценки и внутреннего тестирования. Без технической реализации этих требований в облаке заказчик просто не пройдет аудит — даже если его собственная модель полностью корректна.</p> <p>26 июля 2026 года подписан <nobr>243-ФЗ</nobr> «О поддержке развития технологий искусственного интеллекта в Российской Федерации», основная часть вступает в силу с 1 сентября 2026 года. Закон регулирует узкий, но емкий сегмент — большие фундаментальные модели с числом параметров от 1 миллиарда. Для них устанавливаются пять базовых требований. Разработчиком модели должно быть российское юридическое лицо, и оно же должно отвечать за изменение характеристик модели. Компания-разработчик обязана обеспечить полную техническую и технологическую воспроизводимость всего цикла разработки, включая обучение. Подготовка ответов на запросы пользователей и хранение данных должны производиться в ЦОДах на территории России, принадлежащих российским юрлицам. Используемые зарубежные компоненты должны распространяться на условиях открытой лицензии. С 1 марта 2027 года добавляется требование о подтверждении соответствия модели российскому законодательству и традиционным духовно-нравственным ценностям.</p> <p>Важная деталь: закон не запрещает трансграничное использование ИИ-компонентов и не обязывает обучать модель только на российских данных. Это снимает главный страх рынка и одновременно переводит фокус с расположения данных на локализацию оборудования. И вот тут инфраструктура выходит на первый план.</p> <p>Локализация данных и вычислений по <nobr>243-ФЗ</nobr> требует российской юрисдикции ЦОД и российского юрлица-провайдера. Без гео-распределенных площадок и входа в реестр отечественного ПО это правило не выполнить.</p> <p>Контроль доступа к GPU-среде предполагает изоляцию dev-, research- и prod-контуров и минимизацию круга лиц с правами. На уровне собственного сервера это дорого и хрупко; на уровне провайдера — стандартная функция приватных кластеров с ролевой моделью на гипервизоре.</p> <p>Мониторинг инференса требует понимать, что генерирует модель в проде. Реализуется через inline-модули аудита, которые интегрируются с системами защиты вроде СЗИИ и работают на стороне облака, а не на стороне разработчика модели.</p> <p>Отчетность по вычислениям — требование, которое на горизонте <nobr>2-3</nobr> лет станет обязательным: считать, сколько ресурсов ушло на обучение и инференс. Здесь критичны телеметрия GPU, биллинг с разбивкой по задачам и прозрачные SLA — то, что у зрелого провайдера уже реализовано.</p> <p>Для заказчика реализация таких требований самостоятельно довольно сложная задача: для этого нужна либо собственная инженерная команда по инфраструктуре, либо опытный сервис-провайдер.</p> <p>Раньше комплаенс лежал на заказчике. Сейчас без провайдера, который технически обеспечивает локализацию, логирование и изоляцию, выполнить <nobr>243-ФЗ</nobr> практически невозможно. Соответственно, на первый план будет выходить регуляторно-совместимый контур для ИИ с прецедентами в финсекторе или госсекторе.</p> <p>Подтверждает этот сдвиг и динамика рынка. По прогнозу Gartner, мировые расходы на ИИ-оптимизацию IaaS в 2026 году вырастут на 96% и достигнут 42 млрд долларов. IDC оценивает общие траты на ИИ-инфраструктуру в $497 млрд за 2026 год, причем в первом квартале 2026 рынок уже преодолел отметку $89,7 млрд (+33% год к году). Фокус на инфраструктуру, которая умеет работать с ИИ-нагрузкой: с GPU, с телеметрией, с изолированными контурами.</p> <p>Сервис-провайдер M1Cloud один из первых предложил безопасность ИИ, обеспечение прослеживаемости и соответствия требованиям регуляторов на уровне инфраструктуры, благодаря партнерству с ООО СЗИИ («Системы защиты искусственного интеллекта») и интеграции в облачную инфраструктуру решения для специализированной защиты ИИ-моделей от современных киберугроз.</p> В 2026 году два крупнейших регулятора — Евросоюз с AI Act (Regulation (EU) 2024/1689) и Россия … message https://www.itweek.ru/themes/detail.php?ID=235423 Thu, 27 Aug 2026 17:38:31 +0300 <p>Спрос на услуги и решения класса DevSecOps в российских компаниях вырос примерно на <nobr>20-22%</nobr> с начала 2026 года по сравнению с аналогичным периодом 2025 года. Эксперты «Кросстеха» связывают эту динамику с развитием процессов внутренней разработки в российских компаниях, где безопасность становится неотъемлемой частью процесса создания продукта.</p> <p>Специалисты отмечают, что в начале <nobr>2020-х</nobr> собственная разработка была в основном распространена в финансовом секторе и телекоме — компании из этих отраслей традиционно используют широкий стек ПО как для внутренних процессов, так и для взаимодействия с клиентами. В середине 2026 года внутренние команды разработки становятся обыденностью. Так, по данным «Кросстеха», лидерами по запросам на проекты, связанные с DevSecOps, в первой половине 2026 года стали промышленность и ритейл.</p> <p>Среди основных причин популяризации собственной разработки среди российских компаний — желание бизнеса контролировать технологии, которые используются в его инфраструктуре, и отсутствие решений, которые удовлетворяют потребности бизнеса. Еще одна причина — снижение стоимости разработки за счет развития искусственного интеллекта, которые забирает на себя значительную часть процесса создания IT-решений.</p> <p>Расширение числа проектов, связанных с разработкой собственных решений, ведет к необходимости внедрять безопасную разработку, благодаря чему с начала 2026 года растет спрос на DevSecOps. Наиболее востребованным остается внедрение инструментов тестирования кода (SAST, DAST, SCA), пентест приложений и API, а также консалтинг по DevSecOps и построение процесса безопасной разработки внутри компании.</p> <p>«Компании, которые еще недавно интегрировали готовые продукты, сегодня оказались в роли разработчиков — и далеко не всегда с соответствующей культурой безопасной разработки. Уязвимость может попасть в продукт не через код, который написала команда, а через внешнюю библиотеку или контейнерный образ, о котором никто не задумывался. Именно поэтому спрос смещается не просто на инструменты, а на выстраивание процесса — от анализа зависимостей до безопасности на каждом этапе CI/CD», — прокомментировал Антон Редько, руководитель группы «Безопасная разработка» «Кросстеха».</p> Спрос на услуги и решения класса DevSecOps в российских компаниях вырос примерно на 20-22% с начала 2026 … message https://www.itweek.ru/themes/detail.php?ID=235421 Thu, 27 Aug 2026 10:38:03 +0300 <p><em>Аналитические группы становятся экспертами в области искусственного интеллекта, пишет на портале </em><em>BigDataWire</em> <em>Сохам Мазумдар, соучредитель и генеральный директор WisdomAI.</em></p> <p>На протяжении многих лет аналитические команды помогали организациям разобраться в своих данных. Они создавали дашборды. Они создавали отчеты. Они создавали конвейеры обработки данных. Они разрабатывали определения, документировали метрики и помогали руководителям отвечать на вопросы о том, что происходит внутри компании.</p> <p>Теперь сотрудники компаний все чаще обращаются к ChatGPT, Claude, Copilot и другим системам на основе ИИ вместо того, чтобы напрямую открывать дашборды. Вместо того, чтобы самостоятельно работать с инструментами отчетности, они задают вопрос и ждут ответа.</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>Они уже понимают, что лежит в основе данных, как определяются показатели, откуда берется бизнес-логика и как информация перемещается по организации. Не менее важно, что они понимают, как должен выглядеть правильный ответ и где наиболее вероятно возникновение ошибок.</p> <p>По мере того как ИИ становится все более важной частью доступа сотрудников к информации, аналитические группы берут на себя обязанности, которые все больше напоминают обеспечение качества. Они проверяют результаты, оценивают надежность, расследуют сбои, отслеживают согласованность и выявляют условия, которые заставляют агентов выдавать неверные результаты.</p> <p>Исторически сложилось так, что аналитические группы отвечали за то, чтобы дашборды и отчеты точно отражали бизнес. ИИ расширяет зону их ответственности. Тем же командам теперь предлагается оценить, дают ли агенты, вторые пилоты и аналитические системы на базе ИИ ответы, заслуживающие такого же уровня доверия.</p> <h3>Управление выходит за рамки данных</h3> <p>Большинство программ управления были построены вокруг контроля доступа к информации. Цель состояла в том, чтобы обеспечить сотрудникам доступ к необходимым им данным, сохраняя при этом согласованность, безопасность и доверие во всей организации.</p> <p>ИИ ставит перед ними другую задачу. Агент может иметь доступ к нужным системам, нужным данным и нужным разрешениям, но при этом выдавать неполный, противоречивый или просто неправильный ответ.</p> <p>Это смещает фокус управления за пределы контроля доступа и управления данными. Организациям необходимо иметь представление о том, как ведут себя агенты, насколько последовательно они применяют бизнес-логику и остаются ли результаты, которые они генерируют, надежными с течением времени.</p> <p>Организация, которая не может доверять выводам, сделанным ее системами ИИ, не решила проблему управления просто потому, что базовые данные хорошо управляются. По мере того как агенты все глубже интегрируются в бизнес-процессы, надежность, валидация и контроль становятся не менее важными, чем прослеживаемость происхождения, права доступа и документация.</p> <h3>Переход от управления данными к управлению ИИ</h3> <p>Профессия аналитика уже претерпела несколько серьезных трансформаций: от отчетности и бизнес-аналитики к самообслуживанию в аналитике и современным платформам данных. ИИ порождает еще одну трансформацию.</p> <p>По мере того как агенты все активнее участвуют в предоставлении сотрудникам доступа к информации, организациям становятся нужны люди, которые смогут оценивать надежность, расследовать сбои и определять, заслуживают ли доверия результаты работы ИИ. Аналитические команды хорошо подходят для выполнения этой задачи, поскольку они уже разбираются в данных, бизнес-логике и операционном контексте, лежащих в основе ответов, которые выдают эти системы.</p> <p>На протяжении многих лет их роль заключалась в том, чтобы помогать людям принимать более взвешенные решения на основе данных. Теперь они все чаще отвечают за то, чтобы системы ИИ могли делать то же самое.</p> Аналитические группы становятся экспертами в области искусственного интеллекта, пишет на портале BigDataWire Сохам … article https://www.itweek.ru/themes/detail.php?ID=235419 Thu, 27 Aug 2026 09:05:07 +0300 <p><em>Сегодня ИИ, а точнее машинное обучение (ML), все глубже встраивается в управление доставкой, помогая прогнозировать спрос и опоздания, рассчитывать сроки и оптимизировать процессы. Разбираемся, какие задачи последней мили уже можно передать алгоритмам и почему главным преимуществом логистических платформ становится не сам искусственный интеллект, а качество накопленных данных и возможности прогнозирования.</em></p> <h3>От автоматизации к планированию и прогнозу</h3> <p>Переход от простой автоматизации к прогнозному управлению доставкой происходил постепенно. По мере накопления данных и развития технологий логистические системы стали решать все более сложные задачи. Условно этот процесс можно разделить на два этапа.</p> <p><strong>Цифровизация доставки.</strong> Этот этап связан прежде всего с автоматизацией рутинных операций. Системы научились распределять заказы между курьерами, строить маршруты, рассчитывать предполагаемое время доставки (ETA), объединять несколько заказов в одну цепочку и пересчитывать параметры при изменении ситуации. Это позволило сократить объем ручной работы и снизить зависимость процессов от диспетчера.</p> <p><strong>Прогнозное управление. </strong>Здесь системы начинают не только обрабатывать текущую ситуацию, но и прогнозировать дальнейшее развитие событий. Например, модели машинного обучения анализируют историю заказов и оценивают будущий спрос в конкретной зоне и временном интервале. Это позволяет бизнесу заранее планировать количество курьеров и адаптировать ресурсы к ожидаемой нагрузке, что особенно важно для доставки последней мили, где спрос распределяется неравномерно. Количество заказов в пятницу вечером и утром буднего дня может отличаться в несколько раз. Если курьеров недостаточно, увеличивается нагрузка и растет риск опозданий. Если их слишком много, появляются простои, а стоимость выполнения одного заказа увеличивается.</p> <p>И ценность ML заключается не в самом прогнозе, а в возможности использовать его для принятия операционных решений. В частности, чем точнее компания понимает будущую нагрузку, тем эффективнее может распределять ресурсы и поддерживать баланс между стоимостью доставки и качеством сервиса.</p> <p>При этом прогнозирование дает бизнесу еще одну возможность: проверять решения до их внедрения. На основе накопленных данных можно моделировать различные сценарии работы доставки и смотреть, как изменение отдельных параметров повлияет на результат. Например, при расширении зоны доставки можно рассчитать необходимое количество курьеров, изменение их загрузки и возможное влияние нового радиуса на стоимость заказа и сроки.</p> <p>Такие тесты позволяют проверять гипотезы на виртуальной модели, не экспериментируя сразу на реальных заказах и клиентах. В результате управление доставкой постепенно переходит от реактивного подхода, когда бизнес исправляет уже возникшую проблему, к проактивному, когда последствия решения можно оценить заранее.</p> <h3>Динамическая маршрутизация</h3> <p>Еще одна важная задача в управлении последней милей связана с построением маршрутов. Здесь важно уточнить, что сама маршрутизация не является задачей искусственного интеллекта. В ее основе лежат алгоритмы оптимизации, а модели машинного обучения могут использоваться для более точного прогнозирования отдельных параметров, которые учитываются при расчетах.</p> <p>Современная система должна учитывать не только расстояние между точками, но и временные интервалы доставки, доступность и загрузку курьеров, зоны обслуживания, приоритеты заказов и другие ограничения. При этом исходные условия постоянно меняются. Поступают новые заказы, один курьер задерживается, другой освобождается раньше, меняется время готовности заказа.</p> <p>Поэтому маршрут не формируется один раз на всю смену. Система пересчитывает его по мере поступления новых данных и помогает перераспределять заказы между исполнителями. <nobr>ML-модели</nobr> могут дополнять этот процесс, например повышая точность расчета ожидаемого времени доставки (ETA).</p> <p>Для бизнеса результат такой оптимизации выражается в конкретных показателях, таких как сокращение простоев и лишнего пробега, более равномерная загрузка курьеров и соблюдение заявленных сроков доставки.</p> <h3>Опоздания под контролем</h3> <p>Еще одно направление, где машинное обучение может быть полезно, связано с прогнозированием опозданий. В традиционной модели проблема становится очевидной, когда курьер уже выбился из графика или клиент не получил заказ в обещанное время. <nobr>ML-модели</nobr> позволяют оценить риск задержки заранее, анализируя накопленные данные и текущие параметры доставки. Причины при этом могут быть совершенно разными. Одни возникают внутри самого процесса, когда, например, заказ поздно собрали, задержали на упаковке или не успели передать исполнителю. Другие возникают из-за форс мажорных обстоятельств и их невозможно полностью исключить организационными мерами. Например, на движение курьера могут повлиять авария, перекрытие дороги, проверка сотрудниками полиции и т. д.</p> <p>Задача алгоритмов в такой ситуации не в том, чтобы исключить все форс-мажоры, а в том, чтобы как можно раньше увидеть отклонение и минимизировать его последствия. Если система получает актуальные данные о ходе доставки, она может пересчитать ETA, изменить последовательность выполнения заказов или перераспределить часть нагрузки между исполнителями.</p> <p>В результате бизнес получает возможность управлять отклонением «на лету», еще до того, как оно превратится в опоздание для клиента. И чем раньше будет обнаружен риск, тем больше вариантов остается для корректировки ситуации и сохранения заявленного уровня сервиса.</p> <h3>Где заканчивается работа алгоритма</h3> <p>По мере развития технологий все больше операционных задач можно автоматизировать. Система способна распределять заказы между курьерами, пересчитывать маршруты, рассчитывать ETA и выявлять риск отклонения от заданных сроков. Однако это не означает, что управление доставкой можно полностью передать алгоритмам.</p> <p>Ключевые правила по-прежнему определяет бизнес. Компания решает, какие зоны обслуживать, какие временные интервалы предлагать клиентам, какие заказы считать приоритетными и какой уровень сервиса поддерживать. Алгоритмы работают внутри этих ограничений и помогают находить оптимальное решение в конкретной ситуации.</p> <p>При этом автоматизация постепенно освобождает сотрудников от значительной части рутинных операций. Им уже не нужно вручную распределять каждый заказ, постоянно перестраивать маршруты или отслеживать движение каждого курьера. Эти задачи система может выполнять самостоятельно в рамках заданных правил.</p> <p>В результате роль человека не сокращается, а меняется. Чем больше типовых операций берет на себя технология, тем больше внимания сотрудник может уделять задачам более высокого уровня, анализировать показатели, искать причины отклонений, проверять гипотезы, менять правила работы системы и продумывать новые сценарии. Алгоритмы в этом смысле не заменяют специалиста, а позволяют ему перейти от ручного управления процессом к работе с решениями и развитием доставки.</p> <h3>Качество и полнота данных выходят на первый план</h3> <p>Когда набор технологических возможностей у логистических платформ становится сопоставимым, различия начинают формироваться на уровне данных. Одна и та же модель может показывать разную точность в зависимости от того, на какой информации она обучалась и с какими сценариями сталкивалась раньше.</p> <p>При этом большой объем данных сам по себе не гарантирует хороший результат. Важны их качество, полнота, актуальность и разнообразие. Чем лучше данные отражают реальные процессы доставки и возможные отклонения, тем надежнее модель работает в новых ситуациях.</p> <p>Особенно заметно это при моделировании сценариев. Чтобы оценить последствия изменения зоны доставки, нагрузки или доступного курьерского ресурса, недостаточно знать только среднее количество заказов. Чем полнее система видит историю операций и взаимосвязь разных параметров, тем ближе результаты виртуального теста к тому, что произойдет в реальных условиях.</p> <p>И в отличие от отдельных технологий, накопленную историю операций невозможно быстро скопировать или приобрести. Она формируется со временем, поэтому именно данные постепенно становятся одним из ключевых активов логистических платформ и определяют качество работы <nobr>ML-моделей.</nobr></p> <h3>Что дальше</h3> <p>Следующий этап развития технологий управления доставкой будет связан не столько с расширением функционала, сколько с повышением точности уже существующих решений. По мере накопления данных модели смогут лучше учитывать особенности спроса, загрузку и поведение курьеров, а также отклонения, возникающие в разных сценариях доставки.</p> <p>При этом полностью автономное управление последней милей пока остается скорее перспективой, ведь слишком многое здесь зависит от нестандартных ситуаций, которые требуют оценки и вмешательства человека. Поэтому задача технологий — не исключить его из процесса, а взять на себя расчеты и значительную часть операционных решений, сохранив за специалистом контроль в ситуациях, где алгоритма недостаточно.</p> <p>В результате развитие ML в логистике будет определяться не количеством новых функций с маркировкой ИИ, а тем, насколько точно технологии работают с реальными процессами и улучшают конечный результат. И ценность таких решений будет измеряться конкретными показателями, насколько они помогают сокращать опоздания и простои, поддерживать качество сервиса и снижать стоимость доставки.</p> <p>#IMAGE_235420#</p> Сегодня ИИ, а точнее машинное обучение (ML), все глубже встраивается в управление доставкой, помогая … article Денис Сокольников, технический директор компании “Мастер Деливери” https://www.itweek.ru/themes/detail.php?ID=235401 Thu, 27 Aug 2026 00:00:00 +0300 <p>Цифровизация должна сокращать издержки и ускорять бизнес, но иногда происходит наоборот: новая система требует дорогих интеграций, доработок, миграции данных и поддержки. Разбираем, где компании чаще всего ошибаются и что стоит проверить до старта проекта.</p> <p>Российский бизнес продолжает вкладывать в цифровизацию все больше денег. По предварительной <a href="http://issek.hse.ru/mirror/pubs/share/1132489160.pdf">оценке</a> ИСИЭЗ НИУ ВШЭ, затраты на развитие цифровой экономики в России в 2025 году составили 7,1 трлн. рублей, это на 6,5% больше, чем годом ранее. Только внутренние затраты организаций на создание, распространение и использование цифровых технологий оцениваются в 4,5 трлн. рублей. За пять лет эта сумма выросла примерно вдвое. Причем 87,5% расходов крупных и средних организаций на цифровые технологии в 2024 году финансировались из собственных средств.</p> <p>В 2026 году расходы продолжают расти. В исследовании Apple Hills Digital, Selectel, Cloud.ru и VK Tech 65% опрошенных российских компаний <a href="https://apple-hills.com/ru/reports/cloud-consumption-trends-2025">сообщили</a>, что увеличили ИТ-бюджеты: 48% подняли их в пределах 15%, еще 17% более чем на 15%. Исследование охватило 419 компаний из разных отраслей и 27 глубинных интервью с ИТ-руководителями.</p> <p>То есть вопрос уже не столько в том, готов ли российский бизнес тратить деньги на цифровизацию. Готов. Другой вопрос: сколько из этих денег действительно должно было быть потрачено.</p> <p>Компания может согласовать систему за 20 млн. рублей, успешно провести тендер и даже уложиться в смету. А потом обнаружить, что отдельно нужны интеграции, миграция данных, переделка нескольких внутренних сервисов, обучение сотрудников, дополнительная инфраструктура и команда, которая будет развивать продукт после запуска.</p> <p>Иногда проблема обнаруживается еще позже: система работает, но не дает эффекта, ради которого ее создавали.</p> <p>Это не редкий сценарий. Оператор ИТ-решений ОБИТ в 2025 году <a href="https://obit.ru/press-center/news/polovina-it-proektov-provalivaetsya-iz-za-proschetov-na-starte/">проанализировал</a> более 100 входящих запросов от компаний среднего и крупного бизнеса с оборотом от 2 млрд. рублей. В выборку вошли промышленность, ритейл, ИТ и телеком, логистика. Почти в каждом втором случае компании приходили с запросом на повторный проект или доработку после предыдущего неудачного внедрения. Самыми частыми причинами стали недооценка стоимости владения, проблемы интеграции и неправильный выбор решения.</p> <p>Разберем ошибки, из-за которых цифровизация становится дороже, чем могла бы быть.</p> <h2>Ошибка 1. Цифровизировать компанию отдельными проектами</h2> <p>У компании появляется CRM. Потом ERP. Отдельно развивается мобильное приложение. Маркетинг подключает систему лояльности, HR работает в своей системе, финансы в своей. Где-то появляется BI, затем AI-сервис. Каждый проект можно защитить отдельно. У каждого есть заказчик, задача, бюджет. Иногда все они даже работают нормально.</p> <p>Через несколько лет обнаруживается другая проблема: весь этот набор плохо работает как единая система. Одни и те же данные хранятся в нескольких местах. У одного клиента разные ID. Часть информации синхронизируется автоматически, часть переносится вручную. Новая функция в мобильном приложении требует изменений в трех внутренних системах. Замена CRM неожиданно затрагивает продажи, приложение, аналитику и программу лояльности. Так появляется тот самый зоопарк ИТ-систем.</p> <p>В III Всероссийском опросе по цифровой трансформации Comindware, Artezio и РУССОФТ 60% участников <a href="https://www.comindware.ru/blog/investitsii-v-tsifrovizatsiyu-v-rossii-vyrosli-v-poltora-raza/amp/">сообщили</a>, что проводят отдельные проекты цифровизации, но не имеют общей стратегии. Еще 18% сказали, что такой стратегии нет вообще. 80% компаний используют разрозненные интеграции между информационными системами, а в единой цифровой среде работают только 12%.</p> <p>У этой проблемы уже вполне материальные последствия. К2Тех <a href="https://k2.tech/press_releases/opros-k2teh-68-kompanij-ne-vidyat-czelostnuyu-kartinu-biznesa-iz-za-zooparka-it-sistem/">опросил</a> более 300 руководителей и ИТ-специалистов средних и крупных российских компаний. 68% респондентов сообщили, что из-за зоопарка решений не могут получить целостную картину данных. 47% сталкиваются с высокими скрытыми затратами на поддержку разрозненных систем, еще 33% говорят о техническом долге, который мешает развитию.</p> <p>Проблема тут не в количестве программ. У крупной компании их и не может быть две или три. Вопрос в том, как устроены связи между ними и понимает ли компания, каким должен быть ее ИТ-ландшафт через несколько лет.</p> <p>Допустим, отделу продаж действительно нужна новая система. Помимо вопроса «Решает ли она нашу задачу?» стоит задать еще один: «Что произойдет со всей инфраструктурой после ее появления?». Новая система может дать локальный эффект сейчас, но заметно увеличить стоимость любых изменений потом.</p> <p>Что проверить до следующего внедрения? Нужно хотя бы на верхнем уровне понимать:</p> <ul> <li> какие системы новый продукт заменяет, а какие дополняет;</li> <li> какие данные он будет получать и передавать;</li> <li> где будет храниться мастер-версия данных;</li> <li> сколько новых интеграций появится;</li> <li> не придется ли хранить еще одну копию уже существующей информации;</li> <li> от каких систем и подрядчиков новый продукт будет зависеть;</li> <li> можно ли будет заменить его через несколько лет без перестройки половины ИТ-ландшафта.</li> </ul> <p>Здесь полезна архитектурная схема не только текущего состояния, но и целевого. Иначе цифровой контур формируется не потому, что его кто-то таким спроектировал, а потому что проекты запускались один за другим.</p> <h2>Ошибка 2. Не решить заранее, какой результат должен дать проект</h2> <p><strong>«</strong>Запустить CRM до декабря» звучит как цель. «Разработать приложение» тоже. Как и «автоматизировать оформление заказа», «внедрить AI» или «перевести сотрудников в новую систему». Только все это цели проекта, а не бизнеса.</p> <p>Русская школа управления в 2025 году <a href="https://uprav.ru/blog/55-rukovoditeley-nazyvayut-vysokuyu-stoimost-glavnym-barerom-tsifrovizatsii-biznesa/">опросила</a> руководителей и HR-специалистов российских компаний. 55% назвали одним из главных барьеров цифровизации высокую стоимость внедрения. Но на втором месте оказался гораздо более интересный ответ: <em>35% не понимают эффекта от цифровых решений</em>. Еще 29% назвали сопротивление сотрудников, 27% недостаток компетенций у руководителей, 26% сложности ИТ-инфраструктуры.</p> <p>Проблема становится заметна после релиза. Проект завершили. Система работает. Как понять, что несколько миллионов были потрачены не зря? <br/> Если до начала работы компания не измеряла текущий процесс, ответа может и не быть. </p> <p>Например, смысл нового личного кабинета может быть не в самом факте его появления, а в том, чтобы больше клиентов решали свои вопросы без обращения в поддержку.</p> <p>У автоматизации документооборота задача может состоять в сокращении срока согласования с пяти дней до одного. У нового внутреннего сервиса — в том, чтобы операция, которая занимала у сотрудника 20 минут, выполнялась за пять. А у мобильного приложения — не обязательно в росте установок. Возможно, важнее доля пользователей, дошедших до покупки или снижение нагрузки на офлайн-канал.</p> <p>Поэтому еще до разработки хорошо зафиксировать три вещи: что происходит сейчас. Например, обработка одной заявки занимает 40 минут. Что хотим получить. Например, 15 минут. Как и когда будем это измерять.</p> <p>Без первой точки сравнения можно получить красивый продукт, хорошие отзывы внутри команды и ни одного доказательства, что бизнес стал работать лучше. Еще хуже, когда KPI цифровизации выбирается из технических показателей. Количество функций, число релизов или процент готовности проекта мало говорят о результате для компании. Система может быть написана без критических ошибок, запущена в срок и полностью соответствовать техническому заданию. И одновременно быть неудачным бизнес-проектом.</p> <h2>Ошибка 3. Считать бюджет внедрения, а не реальную стоимость владения</h2> <p>Это одна из самых приземленных ошибок, потому что ее легко увидеть в деньгах. В <a href="https://obit.ru/press-center/news/polovina-it-proektov-provalivaetsya-iz-za-proschetov-na-starte/">исследовании</a> ОБИТ 61% проблемных проектов были связаны с недооценкой стоимости владения ИТ-решением. Компании не полностью учитывали стоимость интеграции, дальнейшего обслуживания и обучения сотрудников. В 48% случаев возникали сложности интеграции с существующей инфраструктурой, в 35% выбранное решение не соответствовало фактическим требованиям бизнеса.</p> <p>По оценке ОБИТ, доработки и исправления после неудачного внедрения могут потребовать еще <nobr>10-30%</nobr> от первоначального бюджета. В отдельных случаях перезапуск проекта требует вложений, сопоставимых с первоначальными или даже вдвое большими.</p> <p>Если компания говорит, что внедрение стоит 15 млн. рублей, стоит уточнить, что именно входит в эти 15 млн.:</p> <ul> <li>Только разработка? </li> <li>Разработка и лицензии? </li> <li>А интеграции? </li> <li>Миграция данных? </li> <li>Изменения в действующих системах? </li> <li>Инфраструктура? </li> <li>Информационная безопасность? </li> <li>Переходный период, когда старое и новое решение работают параллельно?</li> <li> Обучение? </li> <li>Поддержка? </li> <li>Развитие продукта через год? </li> <li>Стоимость сотрудников заказчика, которые будут участвовать в проекте?</li> </ul> <p>Цифровой продукт редко заканчивает потреблять деньги в день релиза. Поэтому сравнивать варианты только по стоимости разработки не очень полезно.</p> <p>Условный проект может выглядеть так:</p> <ul> <li>15 млн. рублей стоит разработка и внедрение;</li> <li>еще 2 млн. потребовали доработки интеграций; </li> <li>1,5 млн. ушли на подготовку и миграцию данных из смежных ИС; </li> <li>1 млн. на переход и обучение;</li> <li>2,5 млн. на поддержку и доработки первого года.</li> </ul> <p>Мы получили уже 22 млн. вместо 15 млн. Это не среднерыночный расчет и не прогноз для любого проекта, а просто иллюстрация того, насколько по-разному могут выглядеть «стоимость разработки» и «сколько бизнес реально потратил на изменение». Поэтому разумнее считать совокупную стоимость владения (ТСО) хотя бы на несколько лет.</p> <p>Иногда более дорогой продукт на этапе покупки оказывается дешевле в эксплуатации. А иногда дешевое коробочное решение через два года обрастает таким количеством доработок, что стоимость его поддержки становится отдельной строкой бюджета.</p> <h2>Ошибка 4. Сначала выбрать технологию, а потом искать ей задачу</h2> <p>Еще несколько лет назад бизнес хотел блокчейн. Сейчас хочет AI. Между ними были супераппы, low-code, микросервисы и много чего еще. Фраза «нам нужно внедрить AI» сама по себе ничего не говорит о том, что компании нужно сделать. То же относится к CRM, ERP, мобильному приложению или отечественной замене зарубежной системы.</p> <p>В анализе ОБИТ 35% проблемных внедрений были связаны с тем, что выбранное решение не соответствовало фактическим бизнес-требованиям. В числе причин компания называет недостаточное тестирование продукта до внедрения и незрелость самого решения. Отдельно эта проблема проявилась во время импортозамещения.</p> <p>Т1 и РУССОФТ <a href="https://t1.ru/media/news/issledovanie-it-kholdinga-t1-i-russoft-spros-na-rossiyskie-it-resheniya-opredelyaetsya-strategiey-ra">исследовали</a> 78 российских компаний с фокусом на крупный бизнес. Среди серьезных препятствий при переходе на отечественные системы компании называли высокую стоимость новых продуктов, проблемы совместимости с текущей инфраструктурой и недостаточную функциональную зрелость части российских аналогов.</p> <p>Одновременно 54% респондентов уже включают миграцию на российские технологии в стратегию развития собственных информационных систем. Только 14% рассматривают импортозамещение исключительно как вынужденную реакцию на внешние обстоятельства.</p> <p>В исследовании РБК и Ростелекома среди 308 руководителей российских компаний 36,7% <a href="https://rtkit.rbc.ru/">назвали</a> одной из проблем импортозамещения интеграцию отечественных решений с существующими системами, 32,5% долгие сроки внедрения.</p> <p>То есть задача «заменим зарубежную систему на российскую» сама по себе тоже может оказаться слишком узкой. Если компания все равно вынуждена менять критичный кусок ИТ-ландшафта, логично сначала посмотреть, нужен ли ей точный цифровой аналог старого процесса. Возможно, за годы работы изменился сам бизнес, появились лишние этапы, а некоторые функции старого продукта уже никому не нужны.</p> <p>Поэтому порядок лучше разворачивать следующим образом: сначала проблема → затем целевой процесс → требования → ограничения текущей архитектуры → возможные решения → выбор между готовым продуктом, доработкой и собственной разработкой</p> <p>Не обязательно каждый раз писать новую систему. И не обязательно сразу раскатывать выбранное решение на всю компанию. Если технология новая, интеграций много, а процессы критичные, пилот часто дешевле большого запуска. На ограниченной группе пользователей можно проверить реальные сценарии, производительность, интеграции и ограничения продукта. Это намного лучше, чем обнаружить их после миграции нескольких тысяч сотрудников.</p> <p>После анализа проблемных проектов ОБИТ тоже рекомендует предварительное тестирование и пилотирование, а миграцию критичных систем проводить поэтапно.</p> <h2>Ошибка 5. Автоматизировать старый процесс, не задаваясь вопросом, нужен ли он таким вообще</h2> <p>Когда компания готовит требования к новой системе, самый простой способ их получить — описать текущую работу. Есть пять этапов согласования? Переносим пять этапов в систему. Сотрудник четыре раза вводит одни и те же данные? Сделаем ему четыре красивые формы. Раньше документ отправляли на почту руководителю? Теперь будет кнопка «Отправить руководителю». Формально это цифровизация. Но процесс остался прежним.</p> <p>Здесь есть показательный пример из финансового сектора. В исследовании Ассоциации ФинТех при участии К2Тех 70% компаний <a href="https://k2.tech/press_releases/67-finansovyh-kompanij-rf-vklyuchili-perehod-na-rossijskie-resheniya-v-svoi-strategii-razvitiya/">сообщили</a>, что в ходе трансформации ИТ-архитектуры провели аудит и пересмотр значимой части бизнес-процессов. Более 80% организаций отметили положительные эффекты такой перестройки: повышение эффективности, большую гибкость, создание задела для развития и работу с накопленным техническим долгом.</p> <p>Конечно, финансовый сектор нельзя автоматически переносить на весь российский бизнес. Но сам подход показателен: смена технологий становится поводом пересмотреть процесс, а не просто перенести его в новую систему.</p> <p>· До автоматизации полезно буквально нарисовать процесс как есть: что сейчас делает клиент, сотрудник и система. Затем нарисовать должно быть. И к каждому действию задать неприятный вопрос: </p> <ul> <li>А зачем оно вообще существует? </li> <li> Почему заявка должна пройти три согласования? </li> <li> Почему данные повторно вводятся руками? </li> <li> Почему менеджер переносит информацию из одной программы в другую? </li> <li> Почему человек принимает решение, которое полностью определяется набором формальных правил?</li> <li> Почему клиент должен заполнять то, что компания уже о нем знает?</li> <li> Какие этапы после цифровизации должны не ускориться, а исчезнуть?</li> <li> Если раньше сотрудник заполнял Excel, а теперь заполняет новую корпоративную систему и на всякий случай продолжает вести тот же Excel, то бизнес не очень много выиграл.</li> </ul> <h2>Ошибка 6. Недооценить интеграции, данные, безопасность и аварийные сценарии</h2> <p>На презентации новый продукт обычно выглядит отдельно. Есть красивые экраны приложения, новый личный кабинет, CRM или внутренняя платформа. В реальной ИТ-инфраструктуре ничего отдельно не существует.</p> <p>Мобильному приложению нужно получить пользователя из одной системы, остаток из другой, цены из третьей, историю заказов из четвертой, принять платеж через внешнего провайдера и вернуть результат в ERP. <br/> И здесь начинается та часть проекта, которую бизнес не всегда видит на старте. </p> <p>У ОБИТ сложности интеграции были причиной проблем в 48% проанализированных проектов. Компания отмечает, что они приводили не только к дополнительным затратам, но и к рискам простоев бизнес-процессов.</p> <p>У Comindware 80% участников исследования работают с разрозненными интеграциями.</p> <p>У К2Тех 74% опрошенных видят решение проблемы несогласованных данных в сквозной интеграции систем и создании единого контура управления данными. Интересно, что бизнес не обязательно хочет выбрасывать существующий ИТ-ландшафт: 46% компаний называют приоритетом оптимизацию текущих систем без масштабных инвестиций.</p> <p>То есть еще до интерфейсов полезно нарисовать карту интеграций и данных:</p> <ul> <li>Откуда приходит каждый тип информации?</li> <li> Какая система считается источником истины?</li> <li> Кому разрешено менять данные?</li> <li> Как часто они синхронизируются? </li> <li> Что происходит, если две системы содержат разные значения?</li> <li> Что будет, если внешнее API не отвечает?</li> <li> А если запрос был отправлен дважды?</li> <li> Как система восстановит операцию после сбоя?</li> <li> Кто увидит ошибку и кто будет ее разбирать?</li> <li> Вот эти вопросы часто влияют на стоимость проекта сильнее, чем количество экранов.</li> </ul> <strong>Отдельно стоит проверить, что будет при сбоях.</strong> <p>Цифровизация делает бизнес быстрее, но заодно сильнее связывает операции с технологиями. Если раньше недоступность одного сервиса мешала части сотрудников, после автоматизации сбой может остановить всю цепочку.</p> <p>КРОК в исследовании 70 ИТ-руководителей крупных и крупнейших российских компаний <a href="https://www.croc.ru/press_releases/issledovanie-krok-90-kompanij-apk-i-52-ritejlerov-stali-bolshe-tratit-na-it-v-2025-godu/">отметил</a>, что в 2025 году заметно вырос фокус на резервировании и отказоустойчивости. Среди инфраструктурных проблем 36% респондентов называли отсутствие резервного ЦОДа, необходимость зеркалировать резервные копии, дублировать сети и сервисы. Поэтому до запуска стоит проверять не только happy path, где все работает как задумано.</p> <ul> <li>Что произойдет, если платежный сервис недоступен два часа?</li> <li> Если упала CRM?</li> <li> Если внешняя система отвечает десять секунд вместо одной?</li> <li> Если в Black Friday нагрузка выросла в несколько раз?</li> <li> Если мобильное приложение работает, а один из внутренних сервисов нет?</li> </ul> <p>Хорошая архитектура предусматривает не только полную работоспособность, но и управляемую деградацию. Пользователь по возможности должен сохранить хотя бы часть сценариев, а бизнес понимать, как система вернется в штатный режим.</p> <p><strong>И безопасность нельзя добавлять последним пунктом перед релизом. </strong></p> <p>Исследования показали, что крупные российские компании назвали соответствие высоким требованиям информационной безопасности главным критерием выбора ИТ-партнера, а кибербезопасность остается одним из основных направлений ИТ-инвестиций российского бизнеса.</p> <p>Но безопасность влияет не только на выбор подрядчика. Она может заметно поменять архитектуру, способ хранения данных, процессы авторизации, интеграции, инфраструктуру и стоимость разработки. Если требования ИБ появляются после того, как продукт уже почти готов, часть работы иногда приходится делать заново.</p> <h2>Ошибка 7. Решить, что legacy обязательно нужно переписать</h2> <p>Старому коду легко назначить виноватого. Если релизы идут медленно, разработчики жалуются на монолит, документации мало и вокруг системы накопилось много странных решений, появляется естественное желание: давайте перепишем все нормально. Иногда это правда правильный вариант. Но возраст системы сам по себе еще не бизнес-проблема.</p> <p>Опираясь на данные вышеуказанных исследований, 78% российских компаний, использующих облачные технологии, сохраняют legacy-системы. У 14% legacy составляет больше половины ИТ-портфеля. 46% участников называют одним из главных приоритетов оптимизацию существующих систем без масштабных инвестиций. В исследовании КРОК более 30% респондентов говорили о необходимости обновления оборудования и работы с legacy. Тут нет противоречия. Потому что legacy можно модернизировать по-разному.</p> <p>Допустим, старое ядро работает стабильно, содержит критическую бизнес-логику и справляется с нагрузкой. Но у него плохие интеграции. Тогда иногда разумнее оставить ядро и построить нормальный API-слой.</p> <p>Если тормозит один модуль, можно вынести его. Если система мешает независимым релизам, разделить наиболее проблемные компоненты. Если высокая стоимость поддержки связана с конкретной частью кода, провести рефакторинг именно там.</p> <p>Полная замена тоже возможна, но тогда бизнесу стоит понимать, что именно он покупает за стоимость переписывания:</p> <ul> <li>Будут быстрее запускаться функции?</li> <li> Снизится стоимость поддержки?</li> <li> Уйдут ограничения по нагрузке?</li> <li> Станет проще находить разработчиков?</li> <li> Исчезнут риски безопасности?</li> <li> Можно будет подключать новые продукты?</li> <li> Если на эти вопросы нет ответа, то проект под названием «перепишем все с нуля» легко превращается в очень дорогой способ получить почти то же самое.</li> </ul> <p>Особенно рискован big bang, когда старая система выключается, а новая должна одномоментно заменить все функции. Чем критичнее продукт, тем разумнее рассматривать поэтапную миграцию, когда часть функций или пользователей переводится последовательно и у команды остается возможность проверить систему на реальной работе.</p> <p>Иногда хороший результат технического аудита звучит не как «вам нужно 30 млн. рублей на новый продукт», а как «эту часть вообще не трогаем».</p> <h2>Ошибка 8. Сначала внедрить AI, а потом разбираться с данными</h2> <p>С AI проблема качества данных стала гораздо заметнее. Можно купить хороший инструмент прогнозирования, подключить BI, внедрить AI-ассистента или модель для автоматического принятия решений. Но если клиент хранится в трех системах под разными идентификаторами, справочники не совпадают, часть данных вводится вручную, а происхождение цифры в отчете никто не может объяснить, новая технология это не исправит. Она будет работать с тем, что ей дали.</p> <p>51% компаний сохраняют внедрение AI среди ключевых приоритетов. Одновременно 68% респондентов говорят, что не получают целостной картины данных из-за разрозненного ИТ-ландшафта.</p> <p>В исследовании КРОК качество входных данных и отсутствие формальных регламентов названы среди факторов, которые мешают масштабированию технологических инициатив.</p> <p>Отдельно Strategy Partners <a href="https://strategy.ru/research/research/polovina-promyshlennyh-predpriyatij-ispytyvaet-deficit-chelovecheskih-resursov-i-kompetencij-dlya-raboty-s-dannymi/">исследовала</a> работу с данными на российских промышленных предприятиях. В 56% компаний ручной ввод остается распространенным способом сбора данных. Только у четверти есть отдельное подразделение для работы с данными, еще у 36% выделен специалист по аналитике. Среди основных барьеров компании называют нехватку людей, компетенций и технических ресурсов.</p> <p>Это особенно важный момент для AI-проектов, потому что там качество исходной информации напрямую связано с качеством результата.</p> <p>До запуска стоит разобраться:</p> <ul> <li> где хранится мастер-версия данных;</li> <li> кто является их владельцем;</li> <li> кто отвечает за качество;</li> <li> есть ли дубли;</li> <li> насколько информация полная и свежая;</li> <li> как изменяются справочники;</li> <li> можно ли понять происхождение конкретного значения;</li> <li> какие данные вообще нельзя использовать в выбранном сценарии;</li> <li> кто отвечает за ошибку, если автоматическая система приняла неправильное решение.</li> </ul> <p>Если у компании три разных значения одного показателя в трех системах, AI не создаст магическим образом правильное. Есть риск, что появится просто четвертый вариант.</p> <h2>Ошибка 9. Считать, что цифровизация закончилась в день релиза</h2> <p>Команда несколько месяцев или лет делает систему. Проходит приемка. Проект закрывают. На презентации появляется зеленый статус «внедрено». А сотрудники продолжают пользоваться Excel. Или переносят часть данных вручную. Или нашли способ обходить новый процесс, потому что старый быстрее. Или система используется, но время выполнения операции не уменьшилось.</p> <p>Технический запуск еще не означает, что произошло изменение бизнеса.</p> <p>В исследовании Т1 и РУССОФТ сопротивление сотрудников новым системам отметили 79,5% представителей крупных компаний. В исследовании Русской школы управления эту проблему отметили 29% респондентов.</p> <p>Разница в цифрах большая, потому что исследования изучали разные выборки и сценарии. Т1 и РУССОФТ рассматривали крупный бизнес и переход на отечественные системы, РШУ шире спрашивала о цифровизации управленческих процессов. Но обе работы показывают, что технология сама по себе не заставляет людей изменить способ работы.</p> <p>И здесь легко дать неправильный совет: «нужно лучше обучать сотрудников». Обучение нужно, но сначала стоит проверить сам продукт. Если раньше сотрудник выполнял пять действий, а после внедрения системы делает восемь, сопротивление не обязательно связано с консерватизмом. Если новая программа работает медленнее старой, человек будет искать обходной путь. Если данные нужно вводить и в старую, и в новую систему, он продолжит вести Excel. Если продукт не учитывает реальные исключения из процесса, сотрудники быстро построят вокруг него собственный параллельный процесс в почте и мессенджерах.</p> <p>Поэтому после релиза важно измерять не только технические показатели. Да, нужны uptime, количество ошибок и SLA. Но параллельно стоит смотреть:</p> <ul> <li> какая доля сотрудников действительно работает в новой системе;</li> <li> какую часть процесса они проходят в ней полностью;</li> <li> сколько ручных операций осталось;</li> <li> сколько времени занимает задача;</li> <li> изменилась ли частота ошибок;</li> <li> не продолжают ли сотрудники вести параллельные таблицы;</li> <li> как часто им приходится обходить систему;</li> <li> изменился ли бизнес-показатель, ради которого все начиналось.</li> </ul> <p><strong>Цифровизация заканчивается тогда, когда изменился процесс и появился измеримый результат для бизнеса.</strong></p> <p>Именно поэтому сложный цифровой продукт почти никогда нельзя воспринимать как объект, который один раз разработали и забыли. Меняется бизнес, появляются новые требования, интеграции, регуляторика, нагрузка. Продукту приходится меняться вместе с ними.</p> <h2>Что проверить до того, как утвердить бюджет</h2> <p>Ошибки из этой статьи могут выглядеть очень разными, но большинство можно обнаружить до начала большой разработки. Перед запуском проекта полезно честно ответить хотя бы на несколько групп вопросов.</p> <p><strong>Бизнес</strong><strong>:</strong></p> <ul> <li>Какую проблему мы решаем?</li> <li> Сколько она стоит компании сейчас? </li> <li> Какой показатель должен измениться после запуска?</li> <li> Знаем ли мы его текущее значение?</li> <li> Как поймем через полгода, что проект сработал?</li> </ul> <p><strong>Процесс</strong><strong>:</strong></p> <ul> <li>Нужно ли вообще автоматизировать процесс в его нынешнем виде?</li> <li> Какие этапы можно убрать?</li> <li> Какие действия должен перестать делать человек?</li> <li> Не создаем ли мы цифровую копию старой бюрократии?</li> </ul> <p><strong>ИТ-ландшафт</strong><strong>:</strong></p> <ul> <li>Какие системы затронет новый продукт?</li> <li> Сколько интеграций потребуется?</li> <li> Где находится источник истины для каждого типа данных?</li> <li> Что придется доработать в существующих системах?</li> <li> Что будет, если одна из интеграций перестанет работать?</li> </ul> <p><strong>Деньги</strong><strong>:</strong></p> <ul> <li>Посчитана стоимость разработки или полная стоимость владения?</li> <li> Учтены ли миграция данных, инфраструктура, интеграции и обучение?</li> <li> Как будет финансироваться поддержка?</li> <li> Кто будет развивать систему после первого релиза?</li> <li> Сколько решение будет стоить компании через три года?</li> </ul> <p><strong>Технология</strong><strong>:</strong></p> <ul> <li>Почему выбран именно этот класс решений?</li> <li> Смотрели ли мы альтернативы?</li> <li> Нужна ли собственная разработка?</li> <li> Можно ли доработать существующий продукт?</li> <li> Нужно ли действительно полностью переписывать legacy?</li> <li> Можно ли сначала проверить гипотезу на пилоте?</li> </ul> <p><strong>Риски</strong><strong>:</strong></p> <ul> <li>Что произойдет при пиковой нагрузке?</li> <li> Как работает система при частичной недоступности сервисов?</li> <li> Есть ли план поэтапной миграции и возможность отката?</li> <li> Учтены ли требования информационной безопасности в архитектуре, а не только перед релизом?</li> <li> Какие данные система получает и можно ли им доверять?</li> </ul> <p><strong>Пользователи</strong><strong>:</strong></p> <ul> <li>Участвовали ли реальные сотрудники или клиенты в проверке сценариев?</li> <li> Станет ли им проще выполнять задачу?</li> <li> Не придется ли пользоваться старой и новой системой одновременно?</li> <li> Как мы измерим реальное использование продукта после запуска?</li> </ul> <p>Если на значительную часть этих вопросов пока нет ответа, возможно, компании еще рано проводить тендер на разработку.</p> <p>Иногда первым этапом должен стать не дизайн приложения и не оценка программистами количества часов, а обследование: разбор процессов, архитектуры, интеграций, данных, технического долга, требований безопасности и экономики будущего решения.</p> <p>Такой этап тоже стоит денег. Но его задача как раз в том, чтобы не выяснять самые дорогие особенности проекта тогда, когда контракт уже подписан, команда работает, а половина бюджета потрачена.</p> <p>Цифровизация обходится дорого не только тогда, когда разработчики ошибаются в коде. Гораздо больше денег можно потерять раньше: выбрать не ту задачу, не посчитать владение, добавить еще одну систему в уже сложный ландшафт или автоматизировать процесс, который стоило сначала переделать.</p> <p>И чем крупнее проект, тем дороже становится вопрос, который бизнес не задал себе на старте.</p> <p> #IMAGE_235402#</p> Цифровизация должна сокращать издержки и ускорять бизнес, но иногда происходит наоборот: новая система требует дорогих … article Владимир Белозеров, заместитель коммерческого директора компании KODE https://www.itweek.ru/themes/detail.php?ID=235416 Wed, 26 Aug 2026 17:10:38 +0300 <p>SimpleOne (направление прикладных бизнес-систем корпорации ITG) выпустила версию 1.35.0 Low-code GenAI платформы. Обновление позволяет снизить нагрузку на администраторов системы и сократить количество ручных действий за счет гибкой настройки индикаторов SLA и копирования блоков рабочих процессов, а также упрощает работу с записями в связанных списках благодаря добавлению поддержки массового редактирования.</p> <p>Ключевое изменение версии 1.35.0 — более гибкая настройка индикаторов SLA. Теперь параметры расчёта индикации — момент запуска отсчёта, момент превышения срока, рабочее расписание и часовой пояс — можно определять не только вручную, но и на основании данных из связанных с обращением записей. </p> <p>Такая функциональность полезна в территориально распределённых компаниях. Например, сроки по заявке нужно считать по графику той площадки, которая обслуживает сотрудника: у сотрудника указан город, у города — обслуживающая площадка, у площадки — свой рабочий календарь и часовой пояс. Раньше под каждый календарь приходилось заводить отдельный индикатор, клиенты компании сообщали о <nobr>10–15</nobr> копиях одного и того же SLA. Теперь достаточно одного индикатора: он проходит по цепочке связей и охватывает нужные параметры сам. Календарь — только один из параметров, по тому же механизму задаются часовой пояс и обе временны́е точки. При этом источником служит любая связанная с обращением запись, то есть под контекст подстраивается не отдельный сценарий, а расчёт SLA целиком.</p> <p>Второе значимое улучшение — добавление возможности копирования блоков в редакторе рабочих процессов. Администраторы теперь могут копировать блок действий в текущие процессы, а также другие рабочие процессы, сохранив все параметры настройки. Новая функциональность заметно ускоряет настройку процессов и сокращает количество ошибок при настройке.</p> <p>Дополнительно были расширены возможности массового редактирования: теперь редактирование поддерживается не только в основных списках записей, но и в связанных списках. Администраторы и агенты поддержки могут быстро вносить одинаковые изменения сразу в несколько записей, без необходимости переходить в отдельное представление списка.</p> <p>«Мы сознательно сосредоточились на участках, где у администраторов больше всего рутины: гибкие SLA и переиспользование блоков рабочих процессов. Для нас стоимость владения системой — отдельное направление развития в каждом релизе. Мы считаем, что платформа должна дешеветь в сопровождении по мере роста конфигурации, не наоборот. Ведь именно от нагрузки, связанной с поддержкой системы, зависит, сколько времени и ресурсов команда клиента сможет потратить на ее развитие», — прокомментировал Илья Радченко, директор по платформенным продуктам SimpleOne, корпорация ITG.</p> <p>Помимо новой функциональности, в версии 1.35.0 устранён ряд дефектов, включая проблемы с контейнерами, уязвимости безопасности и ошибки в работе индикаций. </p> SimpleOne (направление прикладных бизнес-систем корпорации ITG) выпустила версию 1.35.0 Low-code GenAI платформы. Обновление … message https://www.itweek.ru/themes/detail.php?ID=235415 Wed, 26 Aug 2026 17:09:06 +0300 <p>Компания Axenix сообщила о создании первой в России методологии, позволяющей организациям выстроить эффективное, безопасное и системное использование инструментов генеративного ИИ для проектов по интеграции данных и разработке дата-продуктов. Новый подход призван перевести корпоративные ИИ-эксперименты из режима точечного применения в управляемый процесс с прозрачными расчетами, которые опираются на отслеживаемые данные и дают контролируемый результат. </p> <p>Методология предназначена для компаний, которые уже используют или планируют использовать <nobr>LLM-инструменты</nobr> и ИИ-агентов в разработке решений по управлению данными. </p> <p>В ее основе лежит концепция Data Governance, переосмысленная с учетом современных возможностей генеративного ИИ. Дата-продукты являются разновидностью программного обеспечения, однако обладают целым рядом особенностей, требующих отдельной методики разработки. В традиционной разработке основной фокус сосредоточен на функциях продукта: интерфейсе, бизнес-логике, пользовательских сценариях, фронтенде и бэкенде. В случае с дата-продуктами он направлен преимущественно на сами данные — их происхождение, определения, взаимосвязи, контекст и правила интерпретации. </p> <p>Ключевая задача методологии — сделать так, чтобы данным можно было верить. В корпоративной среде недостаточно получить цифру, которая выглядит правдоподобно. Важно понимать, из каких источников она получена, по каким правилам рассчитана, какие исходные данные использовались, кто отвечает за определения, можно ли воспроизвести расчет и т.п. Качество данных особенно важно для бизнес-аналитики, управленческой и регуляторной отчетности.</p> <p>Ошибка в одном показателе или неоднозначность в трактовке данных может привести к неверным руководящим решениям, в том числе стратегическим, а также к претензиям со стороны надзорных органов.</p> <p>Предложенный подход включает ряд ключевых этапов:</p> <ul> <li>оценку текущей зрелости компании в работе с данными и ИИ-инструментами;</li> <li>адаптацию методологии к конкретным бизнес-реалиям и ИТ-ландшафту;</li> <li>определение функциональной архитектуры будущей системы;</li> <li>анализ уже существующих инструментов Data Governance, каталогов, глоссариев и средств контроля качества данных;</li> <li>выявление недостающих элементов;</li> <li>выбор инструментов для поддержки целевого процесса;</li> <li>запуск пилотного проекта по созданию дата-продукта по новой методике;</li> <li>формирование контекстного и семантического слоя для уже существующих источников.</li> </ul> <p>Методология вводит понятие опорного слоя и придает ему особое значение. Опорный слой включает в себя онтологию и семантику, а также так называемый контур доверия. Без него невозможно обеспечить единое понимание бизнес-понятий, метрик и правил интерпретации данных на уровне всей компании. Именно опорный слой должен стать связующим элементом между бизнес-смыслом, источниками данных, методиками расчета показателей и ИИ-инструментами, которые участвуют в разработке, а в дальнейшем, и потреблении данных.</p> <p>Методология также предполагает бережное отношение к уже сделанным компанией инвестициям. Если у нее есть каталоги данных, бизнес-глоссарии, инструменты контроля качества или другие элементы Data Governance, их не нужно заменять автоматически. В них уже накоплены метаданные, определения и управленческий контекст. Задача состоит в том, чтобы встроить существующие активы в новую архитектуру, определить недостающие элементы и обеспечить совместимость старого и нового подходов.</p> <p>«Есть иллюзия, что с помощью ИИ можно в считанные минуты сгенерировать нужное приложение, имея только бизнес-идею. На самом деле это не так просто, особенно в отношении дата-продуктов. Крайне важно определить для ИИ „смысл“ данных компании, погрузить его в контекст. В противном случае есть серьезный риск получить „черный ящик“, корректность и безопасность работы которого невозможно проверить. Наша методология объясняет, как сформировать грамотную среду управления данными и построить взаимодействие с ИИ так, чтобы дата-продукты были предсказуемыми, прозрачными и воспроизводимыми и как результат, давали корректную аналитику», — прокомментировала Лариса Малькова, управляющий директор практики «Данные и прикладной ИИ» Axenix.</p> Компания Axenix сообщила о создании первой в России методологии, позволяющей организациям выстроить эффективное … message https://www.itweek.ru/themes/detail.php?ID=235414 Wed, 26 Aug 2026 17:04:43 +0300 <p>Какие навыки ИИ повышает в цене, а какие — снижает? Раньше других это могут оценить организации, создающие решения на базе ИИ: постоянное взаимодействие с технологией дает им комплексное представление о ее возможностях, ограничениях и влиянии на рынок труда. Институт статистических исследований и экономики знаний (ИСИЭЗ) НИУ ВШЭ изучил прогнозные оценки более 500 таких организаций, полученные в рамках Мониторинга разработки и применения технологий искусственного интеллекта и цифровой трансформации бизнеса.</p> <p>В работе с информацией направление изменений зависит от характера выполняемых задач. Спрос на базовые навыки, связанные с вводом данных и подготовкой документации, будет в целом снижаться (сокращение прогнозируют 45% организаций, рост — 25%), а на аналитические компетенции — расти (36% против 27% прогнозирующих снижение). ИИ автоматизирует рутинные операции, однако постановка задач, интерпретация выводов и принятие решений сохранятся за специалистами.</p> <p>Для ИТ-навыков оценки влияния ИИ оказались неоднозначными. Снижение спроса на навыки программирования прогнозируют 30% организаций, рост — 29%, стабильность — 34%. Автоматизация части работы с кодом может сдерживать найм, однако усложнение программных продуктов и интеграция ИИ-моделей одновременно повышают потребность в технической экспертизе. Востребованность навыков установки и защиты компьютерных систем оценивается более определенно: роста спроса ожидают 38% респондентов, снижения — лишь 11%. Вероятно, увеличение объема генерируемого ИИ кода и применение технологии для кибератак повышают потребность в квалифицированном контроле, настройке и защите систем.</p> <p>В менеджменте центр тяжести будет смещаться от администрирования к стратегии и лидерству. Снижение управленческих рутин прогнозируют 35% организаций, рост — 26%. При этом повышения востребованности стратегического мышления и навыков управления процессами ожидают 41% респондентов, лидерства и мотивации — 36%; снижение спроса на эти навыки предполагают лишь 6 и 4% соответственно. Документооборот, календарное планирование и контроль отчетности поддаются автоматизации, тогда как выбор приоритетов, разрешение конфликтов, мотивация команды и формирование среды доверия остаются за руководителями.</p> <p>Для рабочих профессий уязвимость перед ИИ зависит прежде всего от степени стандартизации операций и разнообразия условий труда. В обследовании сопоставлялись навыки разного уровня квалификации — от вождения и обслуживания оборудования до сортировки, погрузки, сборки и строительства. Наиболее высок риск снижения спроса на сортировку и упаковку: сокращение прогнозируют 29% организаций, рост — 16%. Значительно устойчивее монтаж и ремонт оборудования (снижение ожидают только 6%, рост — 24%) и строительство (снижение — 8%; две трети респондентов предполагают сохранение или рост спроса). В отношении вождения оценки разделились: 21% ожидают сокращения востребованности, 22% — повышения. Повторяющиеся операции в стабильных условиях легче передать роботизированным системам, тогда как работа в изменчивой среде пока требует человеческой адаптивности. В долгосрочной перспективе развитие робототехники и автономных систем будет расширять границы автоматизации.</p> <p>Высокой устойчивостью к ИИ-автоматизации обладают человекоориентированные компетенции: уход за людьми, оказание медицинских услуг, коммуникации, сотрудничество, консультирование, креативность. Наименее уязвимы навыки, основанные на командной работе, общении, доверии и физическом присутствии: снижение спроса на них прогнозируют лишь <nobr>9–13%.</nobr> Более неоднозначно оценивается креативность: роста ее востребованности ожидают 28% респондентов, снижения — 23%. С одной стороны, ИИ уже способен генерировать тексты и изображения, с другой — снижает порог входа в креативную деятельность, беря на себя технические задачи и тем самым создавая возможности для новых замыслов и подходов.</p> <p>Изменения профессиональных компетенций затронут большинство профессий. Риски и возможности, которые несет ИИ, определяются не статусом профессии или уровнем квалификации работников, а содержанием выполняемых задач. Повторяющиеся стандартизированные задачи, которые можно описать с помощью инструкций и алгоритмов, в перспективе будут переданы ИИ, а необходимые для их выполнения навыки потеряют ценность. Одновременно увеличится спрос на компетенции более высокого порядка, связанные с принятием решений в условиях неопределенности, лидерством, командной работой, обеспечением безопасности. Итоговый баланс оценок подтверждает этот сдвиг: верхние позиции заняли стратегическое управление, лидерство и мотивация, установка и защита компьютерных систем, нижние — документирование информации, сортировка и упаковка, простые административные задачи.</p> Какие навыки ИИ повышает в цене, а какие — снижает? Раньше других это могут оценить организации, создающие … message https://www.itweek.ru/themes/detail.php?ID=235413 Wed, 26 Aug 2026 17:04:31 +0300 <p><em>Рост инвестиций в развитие российских софтверных компаний, который достигал примерно <nobr>30-35%</nobr> в 2024 году, в 2025 году сменился их сокращением на 37%. Абсолютная величина совокупных инвестиций уменьшилась с ₽575 млрд. до ₽360 млрд.</em></p> <p>В условиях отсутствия других полноценных источников инвестиций почти вся прибыль предприятий, специализирующихся на разработке ПО, направляется на развитие, поэтому увеличение налоговой нагрузки неизбежно привело к сокращению инвестиционной активности. Напомним, что с 1 января 2025 года был введен НДС для малых компаний, использующих УСН, а вместо нулевого налога на прибыль для аккредитованных ИТ-компаний введена ставка в размере 5%.</p> <p>Математически само по себе увеличение отчислений в бюджет могло дать сокращение только на <nobr>5-10%.</nobr> На увеличение налоговой нагрузки наложилось снижение темпов роста спроса из-за высокой ставки ЦБ РФ и ряда других факторов. В результате продажи компаний-разработчиков ПО росли медленнее их затрат, а это привело к снижению рентабельности софтверного бизнеса.</p> <p><strong>Основные показатели, характеризующие инвестиционную активность в софтверной индустрии в <nobr>2024-2026</nobr> годах</strong></p> <table> <tbody> <tr> <td> </td> <td> <p>2024 г.</p> </td> <td> <p>2025 г.</p> </td> <td> <p>2026 г. (прогноз)</p> </td> </tr> <tr> <td> <p>Отношение совокупных инвестиций к совокупному обороту софтверных компаний</p> </td> <td> <p>23,5%</p> </td> <td> <p>12,8%</p> </td> <td> <p>13,0%</p> </td> </tr> <tr> <td> <p>Объем инвестиций</p> </td> <td> <p>₽575 млрд</p> </td> <td> <p>₽360 млрд</p> </td> <td> <p>₽425 млрд</p> </td> </tr> <tr> <td> <p>Доля опрошенных компаний, сообщивших о привлечении инвестиций</p> </td> <td> <p>47,2%</p> </td> <td> <p>38,0%</p> </td> <td> <p>35,3%</p> </td> </tr> <tr> <td> <p>Доля внешнего финансирования <br/> в общем объеме инвестиций </p> </td> <td> <p>19,3%</p> </td> <td> <p>17,7%</p> </td> <td> <p>19,0%</p> </td> </tr> <tr> <td> <p>Доля опрошенных компаний, сообщивших о наличии внешних инвестиций</p> </td> <td> <p>27,4%</p> </td> <td> <p>25,5%</p> </td> <td> <p>25,1%</p> </td> </tr> <tr> <td> <p>Общий объем внешних инвестиций</p> </td> <td> <p>₽110 млрд</p> </td> <td> <p>₽64 млрд</p> </td> <td> <p>₽81 млрд</p> </td> </tr> </tbody> </table> <p>Ассоциация РУССОФТ проводила в 2025 году экспресс-опросы софтверных компаний с целью моделирования изменения ряда показателей финансового состояния бизнеса при сохранении всех льгот и при частичном лишении налоговых послаблений. Результаты этих опросов показали, что увеличение налоговой нагрузки негативно отразится прежде всего на объеме инвестиций. При нынешних условиях в софтверной индустрии существует прямая корреляция совокупной прибыли софтверных компаний и совокупных вложений в их развитие. Поскольку совокупная чистая прибыль по итогам 2025 года сократилась примерно на треть, то и почти аналогично снизился объем инвестиций в софтверной индустрии.</p> <p>С 1 января 2026 года было введено еще одно изменение в налоговой политике — страховые взносы для аккредитованных ИТ-компаний увеличились примерно вдвое (с 7,6% до 15%). С учетом того, что <nobr>60-80%</nobr> затрат софтверных компаний приходится на фонд оплаты труда, дополнительные отчисления существенно сокращают прибыль при прочих равных условиях. Тем не менее, результаты опроса показывают сдержанный оптимизм.</p> <p>Расчеты на основании планов опрошенных компаний на 2026 год дают рост совокупных инвестиций на 18%. Предположительно выручка увеличится на 17%, чуть возрастет доля внешнего финансирования (с 17,7% до 19,0%), а дополнительные отчисления в пенсионный и социальные фонды частично компенсирует снижение темпов роста средней зарплаты. Прибавка на 18% отражает скорее самый оптимистический сценарий. Реалистичный же предполагает меньший прирост. При этом нельзя исключить и сокращение инвестиций.</p> <p>Показатель удовлетворенности респондентов имеющимся объемом инвестиций, как правило, очень низкий. Опрашиваемые компании в течение нескольких лет видели перспективы окупаемости при вложениях, которые должны были быть в <nobr>2-3</nobr> раза больше фактических. Произошедший в 2021 году инвестиционный бум привел к тому, что потребность в инвестициях в индустрию была удовлетворена намного лучше, чем в предыдущие годы — на 58%. В 2022 году произошел рост показателя удовлетворенности респондентами объемами финансовых вложений до 63%, но этот год был особенным: из-за высокой степени неопределенности не столько выросли вложения, сколько снизилась в них потребность. В 2023 году показатель удовлетворенности снизился до 51%, а в 2024 году — до 42%. Уменьшение этого показателя при росте объема инвестиций говорит о том, что потребность в инвестициях росла быстрее, чем объем инвестиций в развитие софтверных компаний, что было объяснимо на фоне активной реализации процесса импортозамещения ПО.</p> <p>По итогам 2025 года показатель удовлетворенности в инвестициях уменьшился еще больше. По всем опрошенным компаниям фактические вложения составили менее четверти от требуемых (23,5%). Если опираться на ожидания опрошенных компаний, то в 2026 году этот показатель должен повыситься, но все же останется очень низким — 27,2%.</p> <p>Удовлетворенность в объеме инвестиций ниже у продуктовых компаний в сравнении с сервисными, что объясняется их потребностью в разработке собственного программного продукта, что занимает длительное время.</p> <h3>Распределение стабильно</h3> <p>По итогам 2024 года доля собственных инвестиций софтверных компаний составила 77,3%. В 2025 году изменение этого показателя оказалось незначительным. В 2026 году имеются надежды на небольшое увеличение внешнего финансирования (прежде всего, государственного), но структура инвестиций в целом ожидается неизменной при допущении незначительных колебаний.</p> <p><strong>Распределение объема инвестиций в индустрию программного обеспечения по источникам финансирования (по итогам <nobr>2024-2026 годов)</nobr></strong></p> <table> <tbody> <tr> <td> </td> <td> <p>2024 г.</p> </td> <td> <p>2025 г.</p> </td> <td> <p>2026 г. (прогноз)</p> </td> </tr> <tr> <td> <p>Собственные вложения (реинвестиции из прибыли)</p> </td> <td> <p>77,3%</p> </td> <td> <p>76,8%</p> </td> <td> <p>74,8%</p> </td> </tr> <tr> <td> <p>Дополнительные вложения учредителей</p> </td> <td> <p>3,5%</p> </td> <td> <p>5,6%</p> </td> <td> <p>6,2%</p> </td> </tr> <tr> <td> <p>Полученные от заказчиков/клиентов средства, которые пошли на развитие (создание новых тиражируемых решений или новых версий уже существующих решений)</p> </td> <td> <p>15,7%</p> </td> <td> <p>13,85%</p> </td> <td> <p>14,4%</p> </td> </tr> <tr> <td> <p>Государственное финансирование (без участия частных инвесторов), включая гранты и субсидирование льготного кредитования</p> </td> <td> <p>1,9%</p> </td> <td> <p>1,6%</p> </td> <td> <p>4,3%</p> </td> </tr> <tr> <td> <p>Вложения сторонних частных инвесторов (в т. ч. фондовый рынок, венчурные фонды, включая созданные с участием государства)</p> </td> <td> <p>0,4%</p> </td> <td> <p>2,15%</p> </td> <td> <p>0,3%</p> </td> </tr> <tr> <td> <p>Другие источники</p> </td> <td> <p>1,2%</p> </td> <td> <p>—</p> </td> <td> <p>—</p> </td> </tr> </tbody> </table> <p>Если при анализе данных по распределению инвестиций между собственными и привлеченными средствами по итогам 2025 года к собственным средствам добавить инвестиции со стороны учредителей, то эта доля увеличится до 82,4%. Следовательно, на все источники внешнего финансирования приходится 17,6%. Годом ранее этот показатель был равен 19,2%.</p> <p>Вложения сторонних частных инвесторов обеспечивают 2,15% общего объема инвестиций, а годом ранее они составляли 0,4%. Однако делать вывод о каком-то росте активности частных инвесторов пока преждевременно. При единичных случаях привлечения внешних инвесторов очень велико влияние случайных факторов. Рост до 2,15% в 2025 году обеспечила одна компания, участвовавшая в опросе. Без учета ее данных такого роста не будет. К тому же, в 2026 году ожидается возвращение участия внешних источников инвестиций к прежнему уровню.</p> <h3>Самые привлекательные</h3> <p>При делении компаний на категории выяснилось, что у компаний с выручкой менее ₽375 млн. в 2025 году имелась бОльшая доля внешних инвестиций в общем объеме вложений, чем у компаний большего размера. Аналогичное преимущество имелось у небольших предприятий по итогам 2024 года. Соотношение общего объема вложений к обороту у них также выше, чем у компаний с выручкой более ₽375 млн.</p> <p>Продуктовая модель предполагает бОльшую инвестиционную привлекательность в сравнении с сервисной. Однако доля внешнего финансирования в общем объеме инвестиций в <nobr>2024-2025</nobr> годах была выше именно у сервисных компаний. Это, скорее всего, связано с меньшими рисками для внешних инвесторов из-за более коротких сроков окупаемости, и с более низкой рентабельностью, а значит меньшим объемом наличия у них собственных средств для инвестиций.</p> <p>Если по итогам 2024 года соотношение объема инвестиций в развитие относительно оборота были выше у компаний, которые работают только в России в сравнении с предприятиями, имеющими продажи за рубежом, то по итогам 2025 года произошло выравнивание показателей у этих двух категорий компаний.</p> <p><strong>Данные об инвестициях по категориям опрошенных компаний по итогам 2025 года</strong> </p> <table> <tbody> <tr> <td> </td> <td> <p>Объем инвестиций <br/> по отношению к обороту </p> </td> <td> <p>Сообщили <br/> о наличии инвестиций <br/> в 2025 г.,% опрошенных компаний </p> </td> <td> <p>Доля внешнего финансирования во всём объеме инвестиций</p> </td> <td> <p>Сообщили <br/> о наличии внешнего финансирования в 2025 г.,% опрошенных компаний </p> </td> </tr> <tr> <td> <p><strong>Все опрошенные компании</strong></p> </td> <td> <p>13,8%</p> </td> <td> <p>38,0%</p> </td> <td> <p>9,9%</p> </td> <td> <p>25,5%</p> </td> </tr> <tr> <td colspan="5"> <p><strong>Размер компаний</strong></p> </td> </tr> <tr> <td> <p>Оборот <br/> менее ₽375 млн </p> </td> <td> <p>24,2%</p> </td> <td> <p>35,7%</p> </td> <td> <p>19,4%</p> </td> <td> <p>24,2%</p> </td> </tr> <tr> <td> <p>Оборот <br/> более ₽375 млн </p> </td> <td> <p>13,1%</p> </td> <td> <p>43,8%</p> </td> <td> <p>8,9%</p> </td> <td> <p>28,8%</p> </td> </tr> <tr> <td colspan="5"> <p><strong>Модель бизнеса</strong></p> </td> </tr> <tr> <td> <p>Продуктовая</p> </td> <td> <p>15,0%</p> </td> <td> <p>42,6%</p> </td> <td> <p>8,6%</p> </td> <td> <p>23,6%</p> </td> </tr> <tr> <td> <p>Сервисная</p> </td> <td> <p>6,8%</p> </td> <td> <p>31,8%</p> </td> <td> <p>22,4%</p> </td> <td> <p>28,0%</p> </td> </tr> <tr> <td colspan="5"> <p><strong>Наличие экспортных доходов</strong></p> </td> </tr> <tr> <td> <p>Не присутствовали <br/> за рубежом в 2025 г. </p> </td> <td> <p>14,8%</p> </td> <td> <p>33,9%</p> </td> <td> <p>11,5%</p> </td> <td> <p>26,3%</p> </td> </tr> <tr> <td> <p>Присутствовали <br/> за рубежом в 2025 г. </p> </td> <td> <p>12,5%</p> </td> <td> <p>39,5%</p> </td> <td> <p>9,8%</p> </td> <td> <p>18,6%</p> </td> </tr> <tr> <td colspan="5"> <p><strong>Местоположение головного офиса</strong></p> </td> </tr> <tr> <td> <p>Москва</p> </td> <td> <p>14,3%</p> </td> <td> <p>39,7%</p> </td> <td> <p>17,2%</p> </td> <td> <p>23,8%</p> </td> </tr> <tr> <td> <p>Петербург</p> </td> <td> <p>13,2%</p> </td> <td> <p>38,8%</p> </td> <td> <p>10,8%</p> </td> <td> <p>24,5%</p> </td> </tr> <tr> <td> <p>Другие города</p> </td> <td> <p>13,6%</p> </td> <td> <p>37,1%</p> </td> <td> <p>7,1%</p> </td> <td> <p>26,6%</p> </td> </tr> </tbody> </table> Рост инвестиций в развитие российских софтверных компаний, который достигал примерно 30-35% в 2024 году … message https://www.itweek.ru/themes/detail.php?ID=235407 Wed, 26 Aug 2026 09:27:29 +0300 <p><em>Путь к диверсификации поставщиков обещает быть многообещающим — если только не стать жертвой ловушки мультиоблачного искусственного интеллекта, считают опрошенные порталом </em><em>InformationWeek</em> <em>эксперты.</em></p> <p>Диверсификация поставщиков облачных услуг для поддержки стратегии ИИ может принести свои плоды, но если CIO и CTO не сохранят контроль, они рискуют сделать данные неуправляемыми.</p> <p>По мере того, как рабочие нагрузки ИИ распространяются по все более разнообразной технологической экосистеме, конфиденциальные данные и операционный контекст перемещаются вместе с ними, отмечает Брайан Груттадауриа, CTO по гибридным облакам Hewlett Packard Enterprise. «Реальная цена разрастания поставщиков заключается не только в дополнительной сложности; это фрагментация данных, контекста, управления и контроля именно в тот момент, когда ИИ больше всего от них зависит», — говорит он.</p> <p>Диверсификация поставщиков в рамках мультиоблачной стратегии требует распределения рабочих нагрузок между несколькими облачными провайдерами. Она в основном используется для минимизации зависимости от поставщика, повышения отказоустойчивости и резервирования, а также оптимизации затрат и производительности. К сожалению, в сочетании с ИИ диверсификация поставщиков может внезапно превратиться в настоящий ад.</p> <h3>Признаки неправильной диагностики проблемы</h3> <p>Слишком многие организации рассматривают мультиоблачный ИИ как архитектурную проблему, тогда как на самом деле это организационная и финансовая проблема, считает Джесси Дин, CIO компании TDI Security, занимающейся управлением кибербезопасностью. «Из-за страха перед привязкой к поставщику и слабого управления компании разбрасывают данные и модели по нескольким облакам», — отмечает он. Это может привести к размыванию инженерного кадрового потенциала и увеличению долгосрочных затрат. ИТ-руководителям необходимо все тщательно продумать, чтобы устранить фундаментальные недостатки. «Приоритизация единой стратегии стандартизации данных и приверженность основной облачной среде для размещения данных являются ключом к снижению технической сложности и затрат», — полагает Дин.</p> <p>По словам Ха Хоанг, CIO компании Commvault, риск заключается не в том, что организации полагаются на несколько облаков, поскольку у многих из них есть веские причины для этого. «Риск заключается в том, что каждое облако превращается в собственную экосистему ИИ с различными моделями, конвейерами данных, политиками управления и инструментами для разработчиков», — предупреждает она.</p> <p>Как и многие ИТ-руководители, Хоанг считает, что ИИ принесет наибольшую пользу, когда сможет безопасно получать доступ к надежным корпоративным данным и работать согласованно в масштабе всего бизнеса. Если данные фрагментированы, а политики безопасности различаются в каждом облаке, организации могут получить разрозненных агентов, дублирование инвестиций и непоследовательные бизнес-результаты. «Мультиоблачная среда должна быть обдуманным архитектурным решением, а не случайным результатом независимого выбора технологий», — говорит она.</p> <p>Наиболее явным признаком чрезмерной диверсификации поставщиков является то, что данные и рабочие нагрузки больше не являются последовательно видимыми или управляемыми в разных средах, отмечает Груттадауриа. «Если ИТ-служба не может видеть и контролировать актив, независимо от того, где он находится — в облаке, локально или на периферии, — это признак того, что архитектура переросла возможности управления», — предупреждает он.</p> <h3>Поиск пути выхода из ловушки мультиоблачного ИИ</h3> <p>Ответ на вопрос о том, как избежать ловушки мультиоблачного ИИ, заключается в создании единой ткани данных, охватывающей облако, локальные системы и периферию, формируя единое операционное пространство имен вместо набора разрозненных хранилищ данных, считает Юрий Губин, технический директор компании DataArt, занимающейся разработкой ПО и ИТ-консалтингом. «Когда данные, рабочие нагрузки и ИИ используют общую основу, они остаются видимыми, управляемыми и переносимыми независимо от того, где они работают», — говорит он. Это позволяет организациям внедрять инновации от разных поставщиков, не беря на себя бремя мультивендорной сложности.</p> <p>Начните с управления, а не с технологий, советует Хоанг: «Определите небольшое количество утвержденных платформ ИИ, установите общие стандарты безопасности и идентификации и рассматривайте корпоративные данные как общий актив, а не как нечто, принадлежащее отдельным облакам или бизнес-подразделениям». ИТ-руководители также должны проектировать решения с учетом переносимости там, где это имеет смысл с точки зрения бизнеса. «Это не означает, что каждая рабочая нагрузка должна свободно перемещаться между облаками, но это означает избегание ненужной привязки по основным возможностям ИИ», — поясняет она. Это обеспечит гибкость, которая может создать конкурентное преимущество.</p> <h3>Не забывайте о бизнес-целях</h3> <p>Лучшая профилактика — это создание корпоративной операционной модели ИИ до того, как внедрение ИИ начнет масштабироваться, полагает Хоанг. «Каждая новая платформа ИИ должна соответствовать общим стандартам безопасности, доступа к данным, наблюдаемости, управления и контроля затрат», — говорит она. Также важно обеспечить, чтобы каждая инвестиция в ИИ была связана с измеримым бизнес-результатом. Цель состоит не в том, чтобы поддерживать каждую модель или каждого облачного провайдера; цель состоит в том, чтобы обеспечить бизнес-результаты с наименьшей операционной сложностью.</p> Путь к диверсификации поставщиков обещает быть многообещающим — если только не стать жертвой ловушки … article https://www.itweek.ru/themes/detail.php?ID=235399 Wed, 26 Aug 2026 00:00:00 +0300 <p>ИИ-агентов все чаще воспринимают как полноценных цифровых сотрудников. Это вполне логично: если <a href="https://www.itweek.ru/themes/detail.php?ID=235254">система получает доступ к корпоративным данным</a>, выполняет действия и запускает процессы, ей действительно нужны права, ограничения и понятная зона ответственности. Так появляются ИИ-аналитики, ИИ-юристы, ИИ-рекрутеры, ИИ-разработчики.</p> <p>Проблемы возникают, когда саму <a href="https://www.itweek.ru/ai/article/detail.php?ID=235377">ИИ-систему</a> начинают выстраивать по принципам привычной оргструктуры. Такой подход понятен, потому что проще встроить нового исполнителя в уже сложившуюся модель работы, чем сразу пересматривать способ ее организации. Но по мере роста числа агентов становится заметно, что фиксированные цифровые роли подходят не для всех задач. И здесь возникает вопрос — а действительно ли ИИ нужна собственная «должность»?</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> <p>Для ИИ эти нюансы особенно важны. Если фактический порядок работы отличается от формального описания, система рискует опираться на неполную модель процесса и автоматизировать сценарий, который не учитывает часть реальной работы. Поэтому такие расхождения нужно сначала выявить.</p> <p>Для этого используют аналитику бизнес-операций (Task Mining) и аналитику бизнес-процессов (Process Mining). Task Mining показывает, как сотрудники выполняют отдельные операции на компьютере: какие действия совершают и в какой последовательности работают с системами. Process Mining позволяет увидеть реальные маршруты процесса, задержки, возвраты и отклонения между этапами. Для ИИ эти данные могут стать важнейшим источником контекста наряду с классическими регламентами, правилами и корпоративными знаниями.</p> <h3>ИИ должен менять процесс</h3> <p>Когда понятно, как выполняется процесс на самом деле, возникает следующий вопрос — нужно ли автоматизировать его в существующем виде?</p> <p>Представим процесс, который проходит через пять подразделений. Один сотрудник анализирует обращение, второй проверяет документы, третий оценивает риски, четвертый готовит решение, пятый формирует ответ. Можно создать столько же ИИ-агентов и автоматизировать операции на каждом этапе.</p> <p>Работа ускорится, но сам процесс останется прежним. Между этапами сохранятся передачи, повторные проверки, согласования и ожидание. ИИ будет быстрее выполнять существующую схему вместе с действиями, которые могли появиться из-за прежнего распределения функций между людьми.</p> <p>Поэтому перед автоматизацией важно посмотреть на процесс целиком и определить, какие этапы действительно нужны для получения результата. Часть проверок можно объединить, часть передач убрать, а некоторые действия могут вообще потерять смысл. При наличии необходимых доступов и интеграций ИИ может сам собрать данные, провести стандартные проверки, подготовить результат и подключить человека там, где требуется экспертное решение или ответственность.</p> <p>В таком случае эффект дает не столько скорость выполнения отдельных операций, сколько изменение самого процесса. Сокращается количество передач, ручных действий и промежуточных этапов, которые раньше были необходимы из-за устройства работы.</p> <p>Именно здесь появляется потенциал для существенного роста производительности с учетом возможностей ИИ.</p> <h3>Управлять нужно результатом</h3> <p>Если работа строится вокруг задачи, количество агентов само по себе мало о чем говорит. Сто цифровых сотрудников не делают компанию автоматически эффективнее десяти. Иногда большое количество ролей означает лишь то, что существующую оргструктуру почти без изменений воспроизвели в ИИ-системе.</p> <p>Поэтому смотреть стоит на результат: сколько времени теперь занимает процесс, как изменилась стоимость выполнения задачи, какую часть операций система закрывает самостоятельно и где по-прежнему требуется участие человека.</p> <p>Сама оргструктура при этом остается. Она нужна, чтобы закреплять ответственность и полномочия между людьми. Но логика работы ИИ не обязана повторять эту схему: задача может проходить через систему без искусственного деления на цифровые должности и передаваться сотруднику только в тех точках, где его участие действительно необходимо.</p> <p>Для руководителя меняется и объект контроля. Важно понимать, как распределена работа между человеком и ИИ, по каким правилам действует система, где проходят границы ее самостоятельности и какой результат это дает бизнесу.</p> <p>#IMAGE_235400#</p> ИИ-агентов все чаще воспринимают как полноценных цифровых сотрудников. Это вполне логично: если система получает доступ … article Александр Бочкин, генеральный директор “Инфомаксимум” https://www.itweek.ru/themes/detail.php?ID=235404 Tue, 25 Aug 2026 18:45:56 +0300 <p>Институт статистических исследований и экономики знаний (ИСИЭЗ) НИУ ВШЭ на основе данных сплошного статистического обследования Росстата проанализировал уровень использования цифровых технологий в крупных и средних организациях (без учета субъектов малого предпринимательства) в 2025 г.</p> <p>В 2025 г. цифровые технологии использовали порядка 84% крупных и средних организаций — больше, чем годом ранее.</p> <p>Базовым условием распространения цифровых технологий является доступ к интернету. Фиксированным подключением пользуются почти четыре из пяти организаций (78%), мобильным интернетом — почти две из пяти (39%).</p> <p>Информационно-коммуникационную инфраструктуру наряду с доступом к интернету характеризуют использование операционных систем с открытым исходным кодом (например, Linux) и наличие серверов. В 2025 г. такие операционные системы применяли 24% крупных и средних организаций, серверы имели 37%.</p> <p>Среди цифровых технологий наиболее востребованы цифровые платформы и облачные сервисы, за ними следуют геоинформационные системы. Каждая десятая из обследованных организаций внедрила RFID-технологии; чуть меньше — Интернет вещей и технологии сбора, обработки и анализа больших данных. Каждая двадцатая применяла технологии искусственного интеллекта для решения производственных задач. Промышленные роботы, аддитивные технологии и цифровые двойники в силу своей специфики распространены меньше — в <nobr>1–2%</nobr> крупных и средних организаций.</p> <p>Ключевым барьером для использования передовых цифровых технологий — решений для сбора, обработки и анализа больших данных, искусственного интеллекта и Интернета вещей — как и в предыдущие годы, остаются высокие затраты: их отмечает каждая вторая организация. Каждая третья указывает на отсутствие массивов данных и недостаточное развитие ИКТ-инфраструктуры; в среднем каждая четвертая — на нехватку средств для привлечения квалифицированных кадров, обладающих навыками работы с такими технологиями.</p> <p>Наряду с ресурсными ограничениями ряд организаций сообщили об отсутствии потребности в этих технологиях. Это свидетельствует о том, что темпы внедрения зависят не только от объема необходимых вложений, но и от готовности организаций пересматривать бизнес-процессы. Поэтому такие решения распространяются постепенно и прежде всего там, где дают измеримый эффект.</p> Институт статистических исследований и экономики знаний (ИСИЭЗ) НИУ ВШЭ на основе данных сплошного статистического … message https://www.itweek.ru/themes/detail.php?ID=235403 Tue, 25 Aug 2026 18:43:34 +0300 <p>Стоимость российских языковых моделей за последний год снизилась до 67%, согласно исследованию Nodul. Однако если сравнивать их с зарубежными решениями того класса, с которыми российские разработчики сами сопоставляют свои LLM, российские модели по-прежнему могут стоить существенно дороже.</p> <p>Российские разработчики заметно снизили стоимость использования языковых моделей по сравнению с октябрем 2025 года.</p> <p>Наиболее сильное снижение произошло у GigaChat. Стоимость GigaChat Lite снизилась с 0,20 до 0,065 рубля за 1 тыс. токенов — на 67,5%. В линейке GigaChat Pro цена сократилась с 1,50 до 0,50 рубля — на 66,7%.</p> <p>В линейке Яндекса снижение было меньше. YandexGPT Pro стоила 1,20 рубля за 1 тыс. токенов, модель старшего поколения YandexGPT Pro 5.1 — 0,80 рубля, то есть на 33% меньше. Стоимость YandexGPT Lite не изменилась и составляет 0,20 рубля.</p> <p>В 2026 году российские разработчики также расширили линейки более доступными моделями. Alice AI LLM Flash стоит 0,10 рубля за 1 тыс. входных и 0,20 рубля за 1 тыс. генерируемых токенов. В коммерческой линейке GigaChat стоимость Lite-модели составляет 0,065 рубля за 1 тыс. токенов.</p> <p>Снижение цен можно объяснить тем, что российские разработчики постепенно сокращают прежнюю ценовую премию и приближают тарифы к мировому рынку. На это косвенно указывает стоимость доступа к одним и тем же зарубежным моделям через российские облачные платформы.</p> <p>Так, DeepSeek V4 Flash напрямую стоит 0,0375 рубля за 1 тыс. входных и 0,112 рубля за 1 тыс. генерируемых токенов. Через Yandex AI Studio — 0,30 и 0,50 рубля соответственно, то есть в 8 и 4,5 раза дороже.</p> <p>У Cloud.ru разрыв меньше: DeepSeek V4 Pro стоит напрямую 0,112 рубля за 1 тыс. входных и 0,337 рубля за выходные токены, через Cloud.ru — 0,183 и 0,732 рубля, или примерно в 1,6 и 2,2 раза дороже.</p> <p>Эти показатели не позволяют рассчитать реальную маржинальность провайдеров. Публичные тарифы не раскрывают себестоимость инфраструктуры, условия развертывания моделей и коммерческие расходы. Однако они показывают, насколько различается ценовая премия за доступ к одной и той же модели через разных поставщиков инфраструктуры.</p> <p>Снижение тарифов само по себе не означает, что российские LLM стали самыми доступными. Для оценки их ценовой конкурентоспособности российские модели сравнили не с наиболее новыми и дорогими frontier-решениями, а с зарубежными моделями, которые сами разработчики выбирали в качестве ориентиров для своих релизов.</p> <p>При запуске YandexGPT 5.1 Pro Яндекс сравнивал ее с GPT-4.1. Сейчас YandexGPT 5.1 Pro стоит 0,80 рубля за 1 тыс. входных и генерируемых токенов, тогда как GPT-4.1 — около 0,17 рубля за входные и 0,68 рубля за генерируемые.</p> <p>В результате YandexGPT 5.1 Pro обходится примерно в 4,7 раза дороже GPT-4.1 по входным токенам и примерно на 17% дороже по выходным.</p> <p>Еще заметнее разница у Alice AI LLM, которую разработчик сопоставляет с DeepSeek V3.1. Alice AI LLM стоит 0,50 рубля за 1 тыс. входных и 1,20 рубля за 1 тыс. генерируемых токенов. DeepSeek V3.1 по официальному тарифу стоила около 0,048 и 0,143 рубля соответственно. Таким образом, российская модель обходится примерно в 10,5 раза дороже по входным и в 8,4 раза — по исходным токенам.</p> <p>Alice AI LLM Flash позволяет провести еще одно такое сравнение. Яндекс сопоставляет ее с GPT-5.4 mini. Alice AI LLM Flash стоит 0,10 рубля за 1 тыс. входных и 0,20 рубля за генерируемые токены, GPT-5.4 mini — около 0,064 и 0,383 рубля соответственно.</p> <p>То есть Alice AI LLM Flash примерно в 1,6 раза дороже по входным токенам, но почти в два раза дешевле по выходным. Это показывает, что конечная экономика зависит не только от модели, но и от структуры конкретной задачи — соотношения объема входного контекста и генерации.</p> <p>Сравнение актуальных тарифов показывает, что наиболее низкую цену на мировом рынке по-прежнему в значительной степени задают китайские модели.</p> <p>DeepSeek V4 Flash стоит около 0,0375 рубля за 1 тыс. входных и 0,112 рубля за выходные токены, DeepSeek V4 Pro — 0,112 и 0,337 рубля соответственно. GLM-5 стоит 0,08 и 0,27 рубля, Qwen 3.8 Max — 0,17 и 0,511 рубля.</p> <p>В этом же нижнем ценовом диапазоне находятся европейский Mistral Large 3 — 0,04 рубля за входные и 0,13 рубля за выходные токены, а также GPT-5.4 mini — около 0,064 и 0,383 рубля.</p> <p>Из российских решений ближе всего к нижней части диапазона находятся GigaChat Lite с ценой 0,065 рубля за 1 тыс. токенов и Alice AI LLM Flash с тарифами 0,10 рубля за вход и 0,20 рубля за выход.</p> <p>Старшие российские модели стоят заметно дороже: GigaChat Pro — 0,50 рубля за 1 тыс. токенов, GigaChat 2 Max — 0,65 рубля, YandexGPT Pro 5.1 — 0,80 рубля. Alice AI LLM стоит 0,50 рубля за входные и 1,20 рубля за выходные токены.</p> <p>Высокая стоимость больше не является обязательным признаком frontier-модели.</p> <p>В верхней части диапазона остаются Claude Fable 5 с ценой около 0,80 рубля за 1 тыс. входных и 4 рубля за генерируемые токены, а также GPT-5.6 Terra — около 0,34 и 1,53 рубля соответственно.</p> <p>Однако на рынке США появляются более дешевые альтернативы сопоставимого высокого класса. Один из показательных примеров Grok с заметно более низкой стоимостью, чем у ряда решений OpenAI и Anthropic.</p> <p>Ценовое давление на наиболее дорогие LLM идет уже не только со стороны китайских разработчиков. Конкуренция усиливается и внутри американского сегмента. Новые игроки предлагают сопоставимый уровень возможностей в сложных логических задачах, программировании и агентных сценариях при более низкой стоимости инференса.</p> Стоимость российских языковых моделей за последний год снизилась до 67%, согласно исследованию Nodul. Однако если … message https://www.itweek.ru/themes/detail.php?ID=235398 Tue, 25 Aug 2026 10:15:42 +0300 <p>13 августа 2026 года в рамках деловой программы бизнес‑регаты IT SAILING DAY 2026 состоялась панельная дискуссия, посвященная поиску баланса между сокращением затрат и поддержанием эффективности в крупных компаниях. Мероприятие прошло в седьмой раз подряд и было организовано системным интегратором и разработчиком ИТ‑решений DCLogic.</p> <p>В дискуссии также приняли участие ведущие эксперты ИТ‑рынка — представители ИТ‑вендоров и дистрибьюторов, а также руководители и специалисты крупного бизнеса, которые поделились практическими кейсами и отраслевыми наблюдениями. Модератором сессии выступил Сергей Козырь, генеральный директор Digital Advisers, который структурировал обсуждение и помог раскрыть ключевые аспекты темы.</p> <p>Эксперты обозначили конкретные инструменты, позволяющие enterprise‑компаниям оптимизировать ИТ‑расходы: переход на гибкие модели оплаты (включая подписочные сервисы), запуск пилотных проектов для быстрой проверки гипотез и масштабирования только доказавших эффективность решений. Особый акцент был сделан на измеримости ценности — внедрение технологий, теперь обосновывают через четкие метрики и экономический эффект, что помогает исключить нецелевые траты.</p> <p>Также выделили ключевые векторы применения ИИ в enterprise‑сегменте: компании делают ставку на интеграцию генеративного ИИ в существующие ИТ‑контуры для сокращения рутинных операций при сохранении безопасности данных, активно развивают внутренние компетенции по созданию ИИ‑агентов, чтобы снизить зависимость от дорогостоящих внешних разработок, и при этом также привязывают внедрение ИИ технологий к измеримым бизнес‑результатам.</p> <p>Важной частью дискуссии стали экспертные оценки. Сергей Козырь отметил: «С одной стороны, сегодня бизнес сталкивается с серьезными вызовами: у многих компаний наблюдается невыполнение планов. С другой — происходит сокращение бюджетов и доступных возможностей. При этом объем задач для ИТ‑подразделений не уменьшается, а зачастую даже растет — особенно в условиях оптимизации».</p> <p>Евгений Шелестюк, генеральный директор DCLogic, добавил: «За последние два месяца мы заметили резкий сдвиг в запросах клиентов. Если раньше компании стремились наращивать капитал и повышать стоимость бизнеса, то сейчас главный тренд — переход на подписочную модель, чтобы снизить единовременные затраты.</p> <p>Клиенты хотят платить меньше „в моменте“ и получать решения в формате сервиса: аренда серверов, доступ к облачным ресурсам, помесячная оплата — фактически это аналог рассрочки».</p> <p>Участники также выделили важность системного подхода: аудит ИТ‑инфраструктуры, прозрачное бюджетирование и дорожные карты позволяют выявлять избыточные процессы и выбирать оптимальные решения. Дополнительным рычагом экономии стало применение готовых интеграционных инструментов (коннекторов, типовых решений), сокращающих стоимость и сроки проектов. Отдельно эксперты рассмотрели эволюцию рисков — от классической ИБ к комплексному подходу, включающему и физическую защиту объектов, и корректную работу с данными.</p> <p>Представленные на дискуссии практики дают рынку готовые ориентиры: компании могут применять описанные механизмы для снижения издержек, ускорения окупаемости ИТ‑проектов и формирования устойчивой стратегии развития. Такой подход позволяет не просто сокращать бюджет, а перераспределять ресурсы на наиболее результативные направления, сохраняя конкурентоспособность в меняющихся условиях.</p> 13 августа 2026 года в рамках деловой программы бизнес‑регаты IT SAILING DAY 2026 состоялась панельная дискуссия … message https://www.itweek.ru/themes/detail.php?ID=235396 Tue, 25 Aug 2026 09:20:24 +0300 <p><em>Угроза «SaaS-апокалипсиса» упускает из виду более широкую картину. Хотя большинство комментариев сосредоточены на снижении доходов от модели, основанной на использовании рабочих мест (прогнозируя, что агенты искусственного интеллекта положат конец лицензиям на ПО), это лишь один из девяти критически важных факторов, способствующих кардинальным изменениям, пишут в корпоративном блоге вице-президенты и главные аналитики </em><em>Forrester</em> <em>Крейг Ле Клер и Тед Шадлер.</em></p> <p>Будучи глобальной исследовательской компанией, оценивающей весь технологический ландшафт, Forrester создала AI Disruption Model — модель анализа влияния ИИ на основе данных. Эта модель, построенная на исследованиях Forrester и общедоступной информации, отсеивает лишнюю информацию, обеспечивая прозрачность рыночных изменений и всеобъемлющую основу для прогнозирования будущего.</p> <p>Forrester AI Disruption Model оценивает 17 категорий технологий и услуг, охватывающих более 200 рынков. Данная модель анализирует структурную динамику рынка по девяти ключевым факторам, включая взаимозаменяемость ИИ, трудоемкость, коммерческую модель, поддержку агентных рабочих нагрузок, затраты на переход и регуляторные барьеры. Главный вывод очевиден: влияние ИИ не будет распределено равномерно. В то время как некоторые рынки и поставщики сталкиваются с серьезными трудностями, другие готовы к историческому ускорению.</p> <p> #IMAGE_235397#</p> <p>Мы разделили рынки на четыре категории: подверженные дестабилизации (disrupted), нейтрально реагирующие (neutral), подверженные балансу факторов (contested) и обеспечивающие ускорение (accelerated):</p> <ul> <li> Рынки, подверженные дестабилизации — здесь ИИ воспроизводит свою основную ценность. Если ИИ может сделать что-то, что может сделать человек или существующий программный продукт, он это сделает. Поставщики и сервис-провайдеры в этой категории сталкиваются с ценовым давлением, сокращением рабочих мест и коммодитизацией своих основных возможностей или наборов функций. Наиболее серьезно дестабилизирующие факторы, связанные с ИИ, затрагивают трудоемкие сегменты, такие как внедрение технологий, разработка ПО на заказ, креативные услуги и корпоративное обучение. Эти рынки находятся под огромным давлением, поскольку ИИ берет на себя функции, ранее выполнявшиеся экспертами-людьми.</li> <li> Нейтрально реагирующие рынки — здесь ценность не является преимущественно информационной. Если поставщики и сервис-провайдеры предлагают физические возможности, ориентированные на регулируемые рынки или защищенные высокими затратами на смену поставщика, они менее подвержены влиянию перехода на ИИ. Эти факторы сдерживают прогресс ИИ и обеспечивают стабильность ценности.</li> <li> Рынки, подверженные балансу факторов — готовые к ускоренному развитию. Поставщики и сервис-провадеры на таких рынках видят баланс обеспечивающих нейтральное реагирование и ускорение факторов, позволяющий перейти к ускоренному развитию. Они не будут сидеть сложа руки и ждать, пока их вытеснят, а перенаправят инвестиционный капитал и НИОКР на поддержку агентных рабочих нагрузок, данных, доверия и суверенитета. Поставщики в этой категории могут позитивно внедрять ИИ в свои платформы, но сталкиваются с проблемами реализации, капитала и трудовых ресурсов.</li> <li> Рынки, обеспечивающие ускорение — здесь продают все, что требуется для работы с ИИ. Поставщики инфраструктуры, данных, моделей, интеграции или возможностей обеспечения доверия являются основой агентных рабочих процессов — и будущими опорами бизнеса, основанного на ИИ. Спрос на их предложения напрямую зависит от уровня внедрения ИИ: чем больше специализированных ИИ-агентов и целевых агентных систем развертывают предприятия, тем больше технологий продают эти поставщики.</li> </ul> <p>Задача для покупателей корпоративных технологий, поставщиков и сервисных компаний — понять, как ИИ меняет рынки. Независимо от того, являетесь ли вы покупателем, стремящимся оптимизировать свой технологический портфель, или поставщиком, защищающим свою долю рынка и будущее, Forrester AI Disruption Model предлагает схему, необходимую для понимания этого сдвига.</p> <p>Покупатели корпоративных технологий могут использовать эту модель с целью защиты инвестиций при закупках, изолируя устаревшие, обремененные долгами инструменты, чтобы направить инвестиции масштабируемым, готовым к использованию агентных систем поставщикам. Для поставщиков технологий и сервис-провайдеров модель предлагает действенную дорожную карту, позволяющую оценить риски, защитить основной доход и переориентироваться на долгосрочный рост, прежде чем устаревшие модели исчерпают себя.</p> Угроза «SaaS-апокалипсиса» упускает из виду более широкую картину. Хотя большинство комментариев сосредоточены … article https://www.itweek.ru/themes/detail.php?ID=235394 Tue, 25 Aug 2026 09:06:47 +0300 <p>Скорость работы за последний год выросла у всех, кто подключил к процессам ИИ-инструменты. Вместе со скоростью выросла и вероятность того, что ошибка уйдет в производство незамеченной: проверять результат стало некогда, а иногда некому.</p> <p>Рассмотрим, как бизнесу выстроить систему верификации и почему ответственность за решение остается на человеке при любой степени автоматизации.</p> <h3>60% компаний работают с нейросетями без регламента</h3> <p>Требование повышать эффективность сегодня стоит перед большинством компаний, и ИИ-инструменты выглядят самым доступным способом это требование выполнить. Там, где раньше задача занимала день, после подключения нейросети уходит несколько часов. Поэтому внедрение идет в десятки процессов одновременно, при этом, часто без предварительной перестройки процессов.</p> <p>Побочный эффект такого темпа уже заметен. Проверка результата занимает время, которое как раз и хотели сэкономить, поэтому часть шагов начинает выпадать: цифры не сверяются с источником, формулировки принимаются в том виде, в каком их выдала модель, спорные места дорабатываются реже. Углы срезаются постепенно и почти незаметно для самой команды.</p> <p>Безопаснее всего ускоряться там, где ошибка обходится сравнительно дешево. Такой подход сохраняет выигрыш в скорости и снимает основной риск, поэтому имеет смысл закрепить его как процедуру. Пока что такая процедура есть у меньшинства: около 60% организаций <a href="https://pohodu.media/tenevoj-ii-kak-bezopasno-rabotat-s-nejrosetjami-v-kompanii/">не имеют</a> формализованных правил работы с нейросетями, при том что 26% сотрудников используют их регулярно и еще 35% периодически. Сотрудник в такой ситуации сам решает, какой сервис выбрать, какие данные туда отправить и насколько тщательно нужно проверять ответ.</p> <p>Отсутствие правил само по себе не создает проблему, пока результат работы модели остается корректным. Но когда модель ошибается, а ошибка выглядит достоверно и уходит дальше по цепочке без проверки, бизнес сталкивается с серьезными рисками. Именно такие случаи сейчас доходят до публичных разбирательств и показывают, во что обходится компании непроверенный ответ.</p> <h3>Модель выдумывает ссылки, компания платит штраф</h3> <p>Ярче всего проблема ИИ-галлюцинаций проявилась в юридической сфере. Причина в том, что каждая ссылка в документе проверяется второй стороной и судом, поэтому выдуманная норма обнаруживается почти всегда. Модель выдает ее с точной формулировкой и номером дела, но при проверке выясняется, что документа не существует.</p> <p>В базе таких случаев к июлю 2026 года <a href="https://www.kommersant.ru/doc/8799829">накопилось</a> 1725 дел из 35 стран с 5169 некорректными ссылками. История дошла и до российских судов: весной 2026 года арбитражный суд <a href="https://ziam.moscow/publikatsii/sud-oshtrafoval-kompaniyu-za-ispolzovanie-ii-pri-podgotovke-kassatsionnoy-zhaloby/">оштрафовал</a> компанию на 50 тысяч рублей за ссылки на несуществующую судебную практику, квалифицировав это как обман суда.</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> <p><strong>Организационная часть:</strong></p> <ul> <li> Разложить процессы по уровню критичности и зафиксировать, во сколько компании обходится ошибка на каждом из них.</li> <li> Назначить ответственного за проверку на каждом уровне, от линейного руководителя до топ-менеджмента.</li> <li> Ввести правило обязательной проверки фактов, цифр и ссылок в документах, которые уходят за пределы компании.</li> <li> Установить лимит эксперимента в днях и деньгах для задач с низкой критичностью.</li> <li> Составить список задач, результат которых не принимается без проверки человеком.</li> </ul> <p><strong>Техническая часть:</strong></p> <ul> <li> Собрать базу скиллов, тулов и плагинов с правилами работы ИИ-агента для разных этапов процесса. Каждый этап работы получает свой набор инструкций, который определяет, на какие данные агент опирается, какой результат считается корректным и какие действия недопустимы.</li> <li> Настроить процесс ревью, при котором решения, выданные агентом, проверяет другой агент.</li> <li> Запустить рефлексию по итогам ревью: агент разбирает собственные ошибки и определяет, на каком шаге и почему инструкция сработала неверно.</li> <li> Скорректировать работу агента по результатам ревью, чтобы та же ошибка не воспроизводилась на следующих задачах.</li> </ul> <p>Разумеется, скорость работы остается конкурентным преимуществом, и компании, которые откажутся от нее из осторожности, проиграют тем, кто научился работать быстро. Смысл шкалы критичности в том, что она показывает, где можно двигаться на полной скорости без оглядки и где стоит потратить лишний час на проверку. Без такой разметки команда либо тормозит везде одинаково, либо везде одинаково рискует.</p> <p>Технология при этом развивается быстрее, чем компании успевают выстраивать вокруг нее процессы. Верификация становится постоянной частью работы руководителя, благодаря которой ускорение всех процессов возможно. Компании, которые отстраивают эти процессы, получают возможность внедрять новые инструменты без пауз и рисков, которые несут незамеченные ошибки.</p> <p>#IMAGE_235395#</p> Скорость работы за последний год выросла у всех, кто подключил к процессам ИИ-инструменты. Вместе … article Олег Строкатый, руководитель направления контроля качества ”Битрикс24” https://www.itweek.ru/themes/detail.php?ID=235393 Mon, 24 Aug 2026 17:07:41 +0300 <p>По оценке специалистов компании «Информзащита», в первом полугодии 2026 года доля атак через цепочки поставок ПО среди значимых облачных инцидентов выросла на 15 процентных пунктов — с 10% до 25%. За полгода доля выросла в 2,5 раза, при этом абсолютное число значимых инцидентов, связанных с цепочками поставок, более чем удвоилось.</p> <p>Рост связан с тем, что современная разработка опирается на большое число внешних компонентов и автоматизированных процессов, которым компания вынуждена доверять. Даже относительно небольшой корпоративный продукт зависит от внешних библиотек, пакетов, расширений среды разработки, систем сборки и репозиториев. Каждый такой компонент связан с учетными записями сопровождающих, токенами доступа и автоматизированными процессами публикации. Компрометация одного аккаунта сопровождающего, токена публикации или элемента CI/CD может дать злоумышленнику штатный канал доставки вредоносного кода в корпоративную сборку. Вредоносный пакет устанавливается штатным менеджером зависимостей, измененный компонент попадает в сборку, а похищенный токен используется в легитимном CI/CD-процессе. Для средств сетевого контроля установка пакета, обращение CI/CD к репозиторию или публикация артефакта часто выглядят как обычная работа команды разработки.</p> <p>В первой половине 2026 года подобные кампании затрагивали сразу несколько экосистем, включая npm, PyPI, Composer, расширения Visual Studio Code, плагины Jenkins и AUR. В одном из эпизодов компрометация единственной учетной записи разработчика позволила внедрить вредоносные изменения более чем в 140 пакетов. В других случаях атакующие получали контроль над аккаунтами сопровождающих и публиковали измененные версии сразу сотен компонентов. Масштаб такой операции зависит от числа организаций, которые автоматически получают обновления скомпрометированного проекта через привычный процесс установки зависимостей.</p> <p>Отдельную роль играет кража секретов разработчиков. Вредоносный пакет может использоваться как средство первоначального доступа, после чего атакующие извлекают персональные токены GitHub, ключи облачных платформ, учетные данные реестров пакетов или переменные окружения из систем сборки. Эти данные могут открыть доступ к следующему уровню инфраструктуры: приватным репозиториям, облачным ресурсам, контейнерным реестрам или системам сборки. В исследованных кампаниях украденные токены применялись повторно через несколько недель после первоначальной компрометации, причем часть такой активности, по оценкам исследователей, могла относиться уже к другим группам. В одном из эпизодов злоумышленники заявляли о доступе примерно к четырем тысячам частных репозиториев. Такой сценарий требует не только удалить вредоносный пакет, но и отозвать или заменить учетные данные, которые могли быть похищены во время его выполнения.</p> <p>Структура атак через цепочки поставок в 2026 году складывается из нескольких связанных сценариев. Первый строится вокруг компрометации открытого пакета или аккаунта его сопровождающего. Второй затрагивает CI/CD и позволяет менять сборки, кэши либо workflow без прямого доступа к конечному приложению. Еще один распространенный путь проходит через учетные данные разработчиков, когда первоначальное заражение используется для перехода в облачную инфраструктуру или внутренние репозитории. Отдельно развиваются атаки через плагины и расширения инструментов разработки. Такие инструменты особенно ценны для злоумышленника, если они имеют доступ к секретам, сборке или корпоративным сервисам. Расширение IDE работает внутри среды, где разработчик уже авторизован в корпоративных сервисах, а Jenkins-плагин или компонент сборочного конвейера может взаимодействовать с инфраструктурой от имени сервисной учетной записи.</p> <p>В результате граница между компрометацией поставщика и атакой на конечную компанию становится менее очевидной. Организация может не иметь уязвимого публичного сервиса и при этом получить вредоносный код через обновление зависимости. Другой сценарий начинается за пределами ее инфраструктуры, когда атакующий похищает токен сотрудника у разработчика стороннего продукта, а затем использует этот доступ уже против облачных ресурсов клиента. Для бизнеса последствия такого проникновения выходят за рамки заражения отдельной рабочей станции. При наличии широких прав у сервисных аккаунтов атакующий получает возможность читать секреты, менять содержимое репозиториев, воздействовать на процессы сборки и переходить к другим облачным проектам.</p> <p>При оценке отраслевого распределения инцидентов, связанных с цепочками поставок, наиболее высокая доля приходится на технологические компании и разработчиков ПО — около 34% случаев. Финансовый сектор формирует еще 21%, интернет-ритейл и другие цифровые торговые площадки — 16%, промышленность — 14%, компании из сферы профессиональных и корпоративных услуг — около 9%. На остальные отрасли приходится порядка 6%. Такая структура связана прежде всего с интенсивностью использования сторонних компонентов. У технологических компаний больше открытых зависимостей, репозиториев и автоматизированных сборочных процессов, финансовые организации активно используют внешние программные продукты и интеграции, а в ритейле и промышленности риск дополнительно расширяют многочисленные подрядчики, облачные сервисы и специализированное ПО. В этих условиях компрометация одного поставщика может затронуть сразу несколько организаций, которые используют общий пакет, плагин или компонент сборочной инфраструктуры.</p> <p>Риск усиливается, когда управление зависимостями отделено от управления доступом и секретами. Команда может проверять уязвимости библиотек, но не отслеживать, кому разрешена их публикация и какие права имеет CI/CD после установки нового компонента. В другой организации защищен репозиторий исходного кода, однако сервисный токен сборочной системы имеет административные полномочия в облаке. Именно через такие связи атака выходит за пределы исходной точки: один похищенный секрет может дать доступ к следующему сервису, а затем — к другим учетным данным и системам. Один похищенный секрет превращается в доступ к следующему сервису, а оттуда к другим учетным данным и системам.</p> <p>Для снижения риска компаниям следует контролировать всю цепочку доверия от исходного кода и зависимостей до CI/CD и развертывания в продуктивной среде. Новые зависимости имеет смысл проверять до включения в сборку, а недавно опубликованные версии не устанавливать автоматически без дополнительной верификации. Для критичных проектов оправдан период задержки перед использованием новой версии пакета, поскольку часть вредоносных публикаций удаляется вскоре после обнаружения. Доступ CI/CD следует ограничивать минимально необходимыми действиями, долгоживущие токены заменять короткоживущими учетными данными, а секреты разработчиков регулярно проверять на утечки и аномальное применение. Отдельного контроля требуют изменения владельцев пакетов, публикация новых версий, отключение защиты веток и действия сервисных аккаунтов за пределами обычного профиля.</p> <p>Практический приоритет — ограничить последствия компрометации одного элемента цепочки. Организация должна исходить из того, что популярная зависимость, аккаунт сопровождающего или токен разработчика могут быть скомпрометированы, и заранее ограничивать их возможности. Чем меньше полномочий получает такой компонент после попадания внутрь процесса разработки, тем ниже вероятность того, что одна вредоносная публикация даст атакующему доступ сразу к репозиториям, облачным ресурсам и корпоративным данным.</p> По оценке специалистов компании «Информзащита», в первом полугодии 2026 года доля атак через цепочки поставок ПО … message https://www.itweek.ru/themes/detail.php?ID=235392 Mon, 24 Aug 2026 17:02:39 +0300 <p>Компания «ДАКОМ М» (бренд Space) выпустила Space VDI 6.2.0 — новую версию платформы виртуальных рабочих мест для корпоративной инфраструктуры. Ключевыми направлениями развития релиза стали разграничения прав доступа администраторов, совместимость со SpaceVM 7, а также совершенствование инструментов администрирования, поддержки многоуровневой PKI и сценариев управления <nobr>VDI-средой.</nobr></p> <p>В состав релиза вошли Space Dispatcher 6.2.0, Space Gateway 1.8.1, Space Client 3.8.1 для Linux и Space Client 3.8.2 для Windows. Space VDI 6.2.0 совместима с платформами виртуализации SpaceVM 6.5.9 и SpaceVM 7.0.2.</p> <p>В Space VDI 6.2.0 реализована балансировка пользовательских подключений в мультишлюзе Space Gateway. Решение позволяет объединить несколько шлюзов в единый контур удалённого доступа и распределять нагрузку между ними при подключении пользователей.</p> <p>Мультишлюз Space Gateway предназначен для инфраструктур с большим числом удалённых пользователей. Балансировка подключений между шлюзами помогает масштабировать контур удалённого доступа и эффективнее использовать вычислительные и сетевые ресурсы.</p> <p>Space Dispatcher — управляющий компонент платформы получил существенное развитие в новом релизе Space VDI. В версии 6.2.0 реализована поддержка многоуровневой инфраструктуры открытых ключей, а инструменты работы с сертификатами получили дальнейшее развитие в интерфейсе и административных сценариях платформы. Это расширяет возможности интеграции Space VDI с корпоративной PKI и делает управление сертификатами более удобным в рамках единого контура администрирования.</p> <p>В новой версии также добавлены инструменты для разграничения прав доступа администраторов для управления на уровне пулов с помощью пользовательской роли «Модератор», развиты механизмы обновления компонентов, расширены административные сценарии и усовершенствована работа со службами каталогов, событиями и параметрами безопасности. В совокупности эти изменения повышают гибкость управления средой виртуальных рабочих мест и делают эксплуатацию платформы более предсказуемой в инфраструктурах с высокими требованиями к надёжности и управляемости.</p> <p>Отдельное внимание в релизе уделено развитию сценариев предоставления корпоративных приложений. В документации Space VDI появился новый раздел с рекомендациями по работе с пулами приложений, которые позволяют предоставлять пользователям доступ к отдельным приложениям без развёртывания полноценного виртуального рабочего стола. Такой подход помогает точнее настраивать пользовательские сценарии и более гибко организовывать доступ к прикладным системам.</p> <p>«Space VDI изначально создавалась как отечественная платформа с собственной технологической базой и глубокой интеграцией компонентов экосистемы Space. Такой подход позволяет нам обеспечивать предсказуемое развитие продукта, стабильную совместимость между компонентами и долгосрочную поддержку заказчиков в проектах импортозамещения. Мы видим высокий спрос на VDI со стороны коммерческих компаний и государственных организаций, поэтому продолжаем последовательно развивать инструменты администрирования и безопасности платформы. Новые возможности Space VDI 6.2.0 помогают заказчикам проще масштабировать инфраструктуру виртуальных рабочих мест, сохраняя высокий уровень управляемости среды и удобство её эксплуатации», — отметил Руслан Белов, директор по продукту Space VDI компании «ДАКОМ М». </p> <p>Для заказчиков в открытой документации продукта подготовлены рекомендации по обновлению и миграции компонентов Space Dispatcher с учетом особенностей используемой инфраструктуры. При переходе на Space VDI 6.2.0 необходимо соблюдать матрицу совместимости компонентов экосистемы Space и выполнять обновление в рекомендованной последовательности.</p> Компания «ДАКОМ М» (бренд Space) выпустила Space VDI 6.2.0 — новую версию платформы виртуальных рабочих мест для … message https://www.itweek.ru/themes/detail.php?ID=235391 Mon, 24 Aug 2026 16:53:15 +0300 <p>Системный интегратор и разработчик «Навикон» вывел на рынок агентную ИИ-платформу NaviCortex. ИТ-решение позволяет искать ответы в корпоративных документах, а также выполнять аналитические задачи. Платформа рассчитана в первую очередь на крупные и средние компании с повышенными требованиями к информационной безопасности и суверенитету данных.</p> <p>В крупных компаниях информация, необходимая для принятия решений, как правило распределена между разными источниками. Документы и регламенты хранятся в корпоративных порталах и СЭД, данные о клиентах — в CRM, финансовые показатели — в учетных системах, а часть информации остается в файлах и у отдельных экспертов. </p> <p>Чтобы получить аргументированный ответ на вопрос, сотрудникам приходится тратить время на длительный поиск, переключаться между системами, вручную сводить данные из разных систем. NaviCortex объединяет корпоративные источники в единое рабочее пространство и позволяет взаимодействовать с ними в едином интерфейсе.</p> <p>В отличие от классических систем интеллектуального поиска, которые работают по схеме «запрос — поиск по документам — ответ», новое решение «Навикон» построено на агентной архитектуре. Получив задачу, ИИ-агент самостоятельно разбивает ее на этапы, определяет необходимые источники, обращается к корпоративным системам, выполняет расчеты и проверяет результат. При сложных запросах отдельные части задачи могут передаваться специализированным агентам, а дополнительная проверка позволяет сверять числа, периоды и другие необходимые данные. </p> <p>Например, на вопрос о текущей задолженности клиента и возможности продолжать отгрузки платформа может одновременно получить сумму задолженности из ERP, проверить финансовую политику компании в базе знаний и уточнить статус клиента в CRM. В результате пользователь получает единый ответ, а не набор ссылок на три разные системы. По тому же принципу платформа сопоставляет показатели из разрозненных источников, готовит аналитические справки, проверяет требования регламентов или собирает информацию для управленческой отчетности.</p> <p>Платформа не только находит информацию и отвечает на вопросы, но и выполняет работу по запросу пользователя. Агент пишет и запускает код в изолированной песочнице, рассчитывает показатели, строит таблицы и графики — а результат формирует в виде готового документа, таблицы или презентации. Для загрузки собственных файлов и дальнейшей работы с ними пользователям доступно персональное защищенное пространство.</p> <p>NaviCortex можно интегрировать с ERP, CRM, WMS, СЭД, корпоративными порталами, базами данных и другими системами через API. Заказчики, в свою очередь, могут специализированных агентов для отдельных сотрудников, подразделений и сценариев без переработки всей системы.</p> <p>Отдельное внимание разрабочик уделил вопросам корпоративной безопасности. Платформа учитывает права конкретного пользователя при обращении к документам и информационным системам, контролирует входящие запросы и ответы, фиксирует действия в журнале аудита и изолирует пользовательские песочницы. Решение может быть развернуто внутри закрытого контура компании, работать по гибридной модели или размещаться в облаке российского провайдера. При локальном развертывании данные и генерацию ответов можно оставить в инфраструктуре заказчика.</p> <p>«Сейчас корпоративный ИИ часто сводится к чат-боту, который умеет искать информацию в базе документов. Но реальные вопросы бизнеса устроены сложнее: для ответа нужно взять данные из нескольких систем, сопоставить их с внутренними правилами, что-то рассчитать, проверить результат, а иногда — сразу подготовить документ. Именно под такие задачи мы создавали NaviCortex. Наша цель — дать сотруднику ИИ-инструмент, который понимает контекст бизнеса компании и способен самостоятельно пройти путь от вопроса до готового результата», — прокомментировал Илья Народицкий, директор по стратегическим инновациям компании «Навикон».</p> <p>Продукт оптимизирован для работы на русском языке и поддерживает модели с открытым исходным кодом, которые можно размещать в инфраструктуре заказчика. Клиент получает доступ к исходному коду платформы и может развивать и кастомизировать решение самостоятельно или с поддержкой «Навикон». </p> <p>Платформа подойдет компаниям с большим объемом внутренней информации и разветвленным ИТ-ландшафтом. В частности, организациям из регулируемых сфер — финсектора, фармацевтики, пищевой промышленности и ритейла.</p> Системный интегратор и разработчик «Навикон» вывел на рынок агентную ИИ-платформу NaviCortex. ИТ-решение позволяет … message https://www.itweek.ru/themes/detail.php?ID=235390 Mon, 24 Aug 2026 09:48:45 +0300 <p><em>Инструменты кодирования с использованием искусственного интеллекта ускоряют работу отдельных специалистов, но большие запросы на слияние (pull requests, </em><em>PR</em><em>), слабые методы измерения и устаревшие процессы сдерживают производительность и уверенность инженеров, отмечают опрошенные порталом </em><em>The</em> <em>New</em> <em>Stack</em> <em>эксперты.</em></p> <p>ИИ отлично справляется с тем, чтобы ускорить работу отдельных людей, но окружающие системы затем снова всё замедляют. Этот результат — или, скорее, его отсутствие — усиливается размером компании и размером PR. До такой степени, что, хотя инвестиции в ИИ в большинстве компаний увеличились в 28 раз, показатели скорости разработки остаются на прежнем уровне и даже снижаются. Таковы результаты недавно опубликованного исследования DX «State of AI Impact in Engineering», в котором оцениваются инженерные организации по таким параметрам, как скорость, эффективность, качество и влияние.</p> <p>«Это вызывает беспокойство, потому что, когда затраты выросли в 28 раз — и стали буквально единственным экспоненциально выросшим показателем — а скорость не растет экспоненциально, мы не выпускаем экспоненциально больше ПО», — сетует Джастин Реок, заместитель технического директора DX.</p> <p>В то время как расходы на ИИ продолжают стремительно расти, коэффициент инноваций — соотношение усилий инженеров, затрачиваемых на разработку новых функций, с затратами на техническое обслуживание, рутинную работу и операционные издержки — остается неизменным. Это означает, что, согласно отчету DX, ИИ не освобождает время инженеров для разработки интересных бизнес-решений.</p> <p>Почему же индустрия тратит так много денег на агентные и ​​ИИ-инструменты для разработчиков, одновременно проводя сокращения штата, и все это безрезультатно?</p> <h3>Имеет ли место тенденция к ухудшению опыта разработчиков?</h3> <p>«Возможно, мы все еще находимся в переломном моменте, когда большая часть сэкономленного времени по-прежнему тратится на технический долг, на задачи из бэклога, которые не обязательно помечены как новые функции», — говорит Реок, который все еще надеется, что разрыв между затратами и выгодами от ИИ — это всего лишь проблемы роста. «Но с точки зрения опыта разработчиков меня также беспокоит выявленное в отчете конкретное противоречие между поддерживаемостью кода и уверенностью в изменениях», — добавляет он.</p> <p>Эти два фактора составляют основу индекса опыта разработчиков (Developer Experience Index, DXI):</p> <ul> <li><strong> Поддерживаемость кода:</strong> я чувствую себя комфортно, внося изменения в код; я понимаю код, который передо мной.</li> <li><strong> Уверенность в изменениях:</strong> я уверен, что, выпустив код в продакшн, я ничего не сломаю.</li> </ul> <p>Традиционно, как объясняет Реок, поддерживаемость кода и уверенность в изменениях положительно коррелируют, поскольку первая делает инженеров более уверенными в выпуске кода в продакшн. «ИИ упрощает понимание того, что перед вами, и даже внесение в это изменений. Но уверенность в изменениях сейчас находится в отрицательной зоне, — говорит он. — Мы стали больше бояться выпускать код. Мы можем легче понимать, поддерживать, просматривать код и вносить в него изменения. Но мы меньше доверяем тому, что выпускаем».</p> <p>Это обходится еще дороже. По словам Реока, за каждый пункт улучшения DXI приходится платить десятью часами работы каждого инженера в год. Это впервые, когда в масштабах всей отрасли наблюдается снижение этого показателя на два пункта.</p> <h3>Является ли ИИ неподходящим инструментом для крупных организаций?</h3> <p>Как показывает исследование DX, небольшие организации тратят больше средств на ИИ и получают от него больше пользы, в то время как традиционные софтверные компании с трудом получают какую-либо отдачу от инвестиций.</p> <p>Мартин Дэвидсон, технический директор микроконсалтинговой компании a2bic.ai, и его соучредитель, обладающие в общей сложности <nobr>80-летним</nobr> опытом, доводят ситуацию до крайности: они могут управлять командами ИИ-агентов, выполняющих работу 100 инженеров начального и среднего уровня. «Небольшим организациям не приходится платить издержки нелинейной координации и коммуникации, которые увеличиваются с ростом размера организации. Вспомните мифический человеко-месяц: каналы связи растут как n(n−1)/2, поэтому у команды из 10 человек 45 каналов накладных расходов, — объясняет Дэвидсон. — Трое из этих людей фактически нужны только для согласования действий. Но как только остаётся один или два человека, затраты на коммуникации исчезают. По мере сокращения среднего звена управления отпадает необходимость в ежемесячных общих собраниях на всех уровнях организации».</p> <p>По его словам, в средних и крупных организациях пытаются внедрить — или «впихнуть» — ИИ в существующие системы, охватывающие людей, процессы и технологии. Но ИИ — это фундаментальный технологический и операционный сдвиг парадигмы. Это то, что он называет проблемой обновления, когда некоторые из этих структур больше не соответствуют своему назначению.</p> <p>«Это нельзя переделать. У нас есть процессы и структуры, которые были разработаны, когда написание кода было дорогостоящим делом. Сейчас это уже не так — написание кода по сути бесплатно, но мы всё ещё цепляемся за старые структуры. А они недешевы, — продолжает Дэвидсон. — Структуры компании похожи на здания — в какой-то момент вы понимаете, что они больше не соответствуют своему назначению, и их нужно снести и выстроить заново».</p> <p>Конечно, это не новая проблема. Это та же самая логика, которая удерживала подавляющее большинство предприятий от полного перехода в облако.</p> <p>«Возможно, победителями станут не те компании, которые успешно трансформируются. Возможно, победителями станут те, кто начнет все с чистого листа, без каких-либо ограничений. Это трудно сделать, если вы работаете в устаревшей организации. И, вероятно, еще более трудно, если вы ею управляете», — отмечает Дэвисон.</p> <p>К счастью, ИИ очень хорошо распознает закономерности, что делает его очень полезным для разгадывания тайн унаследованных систем, их миграции в облако и переписывания.</p> <h3>ИИ усугубляет разрастание кода</h3> <p>Конечно, многие команды и их промпты игнорируют общепринятые шаблоны достижения успеха, в том числе тот факт, что уменьшение размера пакета способствует более стабильным релизам. В отчете DX говорится, что в июле 2025 г. средний размер PR составлял 42 строки кода, а годом позже — 72 строки.</p> <p>Кроме того, из всех показателей DXI, измеренных за последний квартал, больше всего пострадал показатель поэтапной разработки — когда инженеры работают над небольшими, поэтапными изменениями. «Такая разработка дает множество преимуществ в дальнейшем: откат изменений, меньше проверок, более понятная документация, улучшенные модульные тесты и так далее», — отмечает Реок.</p> <p>Не только DX выявляет эти тревожные тенденции. В новом отчете LinearB о разрыве в производительности ИИ-разработки 253 организации ранжированы по использованию ИИ на четыре категории. Исследование показывает, что меньший размер PR напрямую связан с более успешным внедрением ИИ. У «элитных организаций», входящих в 10% лучших, средний размер PR — менее 100 строк кода, в то время как у организаций из нижней части списка — им «недостает фокуса» — PR составляют более 228 строк кода.</p> <h3>Можно ли улучшить то, что не измеряется?</h3> <p>Исследования DX и LinearB по измерению количественного и качественного опыта разработчиков основаны на собственных данных, полученных от организаций, использующих их продукты, поэтому ни один из этих результатов не отражает полной картины. На самом деле, ситуация в остальной части отрасли может быть гораздо хуже.</p> <p>Согласно отчету LeadDev «AI Impact Report 2026», только 31% опрошенных команд вообще измеряют влияние ИИ. Исследователи определили эти измерения следующим образом:</p> <ul> <li> реальное повышение производительности;</li> <li> риск безопасности;</li> <li> сохранение основных инженерных навыков;</li> <li> управление агентным ИИ;</li> <li> реструктуризация команды;</li> <li> наем и обучение младших специалистов.</li> </ul> <p>Среди организаций, которые фактически начали внедрять инструменты для разработчиков на основе ИИ, согласно отчету LeadDev, 70% теперь описывают себя как внедрившие их «широко или полностью», и только 26% сообщают, что ИИ повысил производительность инженеров более чем на 25%. Эти 26%, как уточняет Майкл Хилл, управляющий редактор LeadDev и автор отчета, включают в себя респондентов, полагающихся на интуицию, а не только на подтвержденные данные.</p> <p>«Оптимизм в отношении производительности (26% отмечают значительный рост) и разрыв в измерениях (только 31% фактически отслеживает его) — это два отдельных результата, полученные на основе ответов на два разных вопроса», — отмечает он, а это значит, что «большинство людей, сообщающих о росте, не могут это доказать».</p> <p>Как известно, нельзя улучшить то, что не измеряешь. Но даже у тех, кто проводит измерения, результаты вызывают беспокойство.</p> Инструменты кодирования с использованием искусственного интеллекта ускоряют работу отдельных специалистов, но большие … article https://www.itweek.ru/themes/detail.php?ID=235389 Mon, 24 Aug 2026 09:25:14 +0300 <p><em>В мире корпоративного искусственного интеллекта назревает проблема, и ИТ-руководители сталкиваются с дилеммой. Как улучшить результаты и снизить затраты на ИИ-инициативы, одновременно защитив корпоративный бренд? В конце концов, высшее руководство все чаще называет внедрение ИИ основным поводом для сокращения штата на 20% и более. Советы директоров и инвесторы компаний оказывают сильное давление на исполнительных руководителей, требуя показать финансовые и ощутимые выгоды от масштабных инвестиций в ИИ, которые обходятся крупным предприятиям более чем в 10 млн. долл. в год, пишет на портале </em><em>BigDataWire</em> <em>Кумар Гошвами, соучредитель и генеральный директор Komprise.</em></p> <p>В целом, пока сложно продемонстрировать окупаемость инвестиций в ИИ. Исследование MIT Research показало, что 95% пилотных проектов генеративного ИИ не приносят измеримой финансовой отдачи, а Gartner прогнозирует, что более 40% проектов агентного ИИ будут отменены к концу 2027 г.</p> <p>Хотя существует множество факторов, объясняющих низкую рентабельность инвестиций и высокий уровень неудач, качество данных является постоянным препятствием, на которое указывают аналитики. Индустрия ИИ до сих пор фокусировалась на уровне рассуждений, в то время как уровню подготовки данных уделялось сравнительно меньше внимания.</p> <p>Более того, подготовка данных часто обсуждается в терминах «последней мили»: разбить документы на фрагменты, сгенерировать вложения, загрузить векторную базу данных, построить конвейер поиска. Это предполагает, что к моменту попадания в конвейер данные чистые, классифицированные, управляемые и релевантные, но это в значительной степени не соответствует действительности. Исследования снова и снова показывают, что организации сталкиваются с проблемами, связанными с разрозненностью, управлением и общим качеством данных. Опрос Databricks показал, что только 37% руководителей считают свои приложения генеративного ИИ готовыми к внедрению в производство.</p> <p>Этот разрыв — проблема «первой мили» ИИ: поиск данных, их понимание, классификация и определение того, что вообще не должно попадать в модель.</p> <h3>Проблема неструктурированных данных для ИИ</h3> <p>Если вы спросите поставщика облачных услуг или платформы LLM, как использовать неструктурированные данные, они почти всегда начнут с того, что посоветуют вам загрузить файлы в хранилище S3 или в озеро-хранилище (lakehouse) данных. Однако этот подход быстро меняется, поскольку объем файловых и объектных данных неуклонно растет, а затраты и риски безопасности для ИИ увеличиваются.</p> <p>Неструктурированные данные, которые составляют от 80 до 90% новых корпоративных данных, растут примерно в три раза быстрее, чем структурированные данные, и теперь являются исходным материалом, необходимым для каждой корпоративной ИИ-инициативы. Тем не менее, большинство ИТ-команд по-прежнему не могут сказать вам, где все это хранится, каково его содержимое или как безопасно использовать это в ИИ.</p> <p>Проблема обработки больших объемов неструктурированных данных многогранна, она охватывает следующее:</p> <ul> <li> файловые хранилища NAS, накопленные за многие годы, и объектные хранилища, распределенные по облачным провайдерам;</li> <li> миллиарды разнообразных файлов: документы, отсканированные PDF-файлы, чертежи САПР, архивы электронной почты, мультимедийные файлы, данные приборов и многое другое;</li> <li> широко распространены дубликаты, «осиротевшие», тривиальные и «зомби», или «мертвые» данные, засоряющие хранилище и ухудшающие видимость;</li> <li> несогласованная структура папок и отсутствие структуры, контекста и богатых метаданных, что затрудняет обнаружение и организацию неструктурированных данных;</li> <li> большая часть этих данных трудно поддается запросам, поскольку они не хранятся в базе данных, разбросаны по разрозненным хранилищам и имеют мало идентифицирующих характеристик.</li> </ul> <h3>Объяснение проблемы «первой мили»</h3> <p>Для подготовки данных к использованию в ИИ необходимо выполнить несколько критически важных этапов предварительной обработки: индексирование в хранилищах разных производителей, обнаружение, очистка и удаление дубликатов, классификация путем обогащения и извлечения метаданных, обнаружение конфиденциальных данных и включение политик управления и безопасности в рабочие процессы обработки данных для ИИ.</p> <p>Эта проблема выявлена ​​в исследовании Komprise «2026 State of Unstructured Data Management», согласно которому классификацию и маркировку неструктурированных данных назвали своей главной проблемой при подготовке данных для ИИ 56% директоров по ИТ-инфраструктуре, по сравнению с 41% годом ранее. Управление и безопасность заняли второе место с 46%.</p> <p>Причина этой проблемы «первой мили» заключается в том, что ИИ эволюционировал от массовых потребительских чат-ботов до стратегических, крупномасштабных корпоративных инициатив с использованием корпоративных данных.</p> <ul> <li><strong>Миф об «песочнице» ИИ.</strong> До недавнего времени большинство корпоративных ИИ-проектов представляли собой изолированные эксперименты или небольшие проверки концепций. При обработке 500 корпоративных документов их можно вручную выбрать, загрузить в хранилище данных и запустить конвейер RAG. Однако с расширением применения ИИ на более крупные задачи это не масштабируется для рабочих нагрузок, которые могут включать 100 000 или более файлов, с неизвестным процентом файлов, не подходящих для данной задачи.</li> <li><strong>Миф о векторной фильтрации.</strong> Существует устойчивое предположение, что векторная база данных автоматически отфильтрует избыточный или устаревший контент. На практике, если у компании есть десяток версий одних и тех же устаревших документов, разбросанных по различным системам хранения, поиск пользователя выдаст несколько противоречащих друг другу версий в одном и том же запросе. ИИ-инженеры не учитывают, что подача огромного количества устаревших, избыточных или низкокачественных данных в модель ИИ приводит к сильным иллюзиям, медленному времени ответа на запросы и раздуванию счетов за токены.</li> <li><strong>Отсутствие инструментов управления на уровне файлов.</strong> Традиционные инструменты хранения данных были созданы для администраторов хранилищ и предназначены для резервного копирования, многоуровневого хранения и архивирования, а не для развертывания рабочих процессов обработки данных для специалистов в области науки о данных. Не хватает инструментов для безопасной и эффективной доставки чистых, организованных файлов из устаревших корпоративных файловых хранилищ в конвейеры обработки данных. В эти рабочие процессы необходимо интегрировать средства управления соответствием нормативным требованиям в отношении использования данных путем выявления конфиденциальных и регулируемых данных и принятия соответствующих мер при необходимости.</li> <li><strong>Экономика владения.</strong> Бизнес-приложения, такие как CRM, ERP и системы взаимодействия с клиентами, влияющие на выручку, имеют финансовую историю и поддержку руководства, поэтому они бюджетируются. Неструктурированные данные в основном находятся в другой бюджетной строке: ИТ-инфраструктура и системы хранения, центр затрат без влияния на доходы. Поиск дубликатов, устаревших или регулируемых файлов, по общему мнению, является более сложной инженерной задачей, но у нее нет бизнес-спонсора в отличие от новой функции CRM. Однако ИТ-команды сейчас понимают, что ИИ зависит от высококачественных, управляемых данных, а подготовка данных требует значительных бюджетных затрат.</li> </ul> <h3>Lakehouse не решает проблему</h3> <p>ИИ повысил важность озера-хранилища данных — архитектуры, сочетающей в себе недорогое хранение в озере данных с управлением уровня хранилища данных. Тем не менее, у lakehouse есть ограничения, когда речь идет о курировании неструктурированных данных для ИИ.</p> <p>Во-первых, lakehouse по-прежнему требует размещения необработанных данных где-то, прежде чем уровень управления сможет с ними работать. Большинство реализаций следуют поэтапной схеме, часто называемой «медальонной архитектурой», размещая необработанные данные в «бронзовом» слое, прежде чем они будут очищены и структурированы. Для строк, извлеченных из CRM, этот шаг обходится недорого. Для петабайтов файловых данных, распределенных по локальным NAS-серверам, нескольким облачным хранилищам и периферийным точкам, это не так, а большие объемы уже являются нормой.</p> <p>Во-вторых, инструменты, созданные для перемещения данных на платформы, такие как ETL и ELT, не были разработаны для больших наборов неструктурированных данных, распределенных по разрозненным хранилищам.</p> <p>Это обосновывает подход «нулевого перемещения»: индексировать и классифицировать данные там, где они хранятся, отфильтровывать избыточные, устаревшие, тривиальные (ROT) данные до их перемещения и перемещать только управляемое подмножество, необходимое для рабочей нагрузки. Lakehouse — прекрасное место назначения. Но требует предварительного решения о том, что там должно находиться.</p> <h3>Переход к нулевой фазе</h3> <p>Финансовые затраты на перемещение всего — это только половина проблемы. Другая половина проявляется в том, что производит система ИИ: ввод в модель низкокачественного или дублирующегося контента, как правило, приводит к заведомо неверному ответу. Существуют также затраты на управление. Контроль доступа на уровне файлов существует не просто так, и когда необработанные данные копируются целиком в новую среду, эти средства контроля не всегда переносятся вместе с ними.</p> <p>Разбивка на фрагменты, синтаксический анализ и векторные вложения по-прежнему необходимы, но они относятся к концу процесса. Нам нужен нулевой этап перед ними: найти, какие данные существуют и где, классифицировать их по содержимому и конфиденциальности, отфильтровать нерелевантные данные и обеспечить соблюдение правил управления и доступа до того, как какие-либо данные будут перемещены в модель или озеро-хранилище данных.</p> <p>Вот как развиваются рабочий процесс и набор инструментов для конвейеров обработки данных ИИ:</p> <ul> <li> инструменты обнаружения и классификации для поиска контента в разрозненных хранилищах;</li> <li> платформы управления неструктурированными данными для метаданных, политик и перемещения;</li> <li> уровни управления и контроля доступа для обеспечения безопасности и отслеживания происхождения данных;</li> <li> инструменты синтаксического анализа, оптического распознавания символов и обогащения для преобразования файлов в пригодный для использования контент;</li> <li> уровни поиска и векторного представления для обслуживания рабочей нагрузки ИИ.</li> </ul> <p>В дальнейшем ИТ- и дата-командам необходимо рассматривать индексирование, поиск и классификацию данных как инфраструктуру, а не как второстепенный аспект. Это позволит организациям эффективно отсеивать дубликаты файлов, неавторитетные и нерелевантные данные, одновременно учитывая специфические требования к данным, которые не подпадают под действие нормативных требований и правил безопасности.</p> <p>Предприятия, которые преодолеют барьер «первой мили», в конечном итоге будут передавать меньше данных в ИИ, экономя на токенах, хранении, вычислительных ресурсах и затратах на передачу данных, обеспечивая при этом доступность только необходимых для конкретного сценария использования данных.</p> <p>Предприятиям, которые хотят, чтобы ИИ работал в масштабе с достижимой окупаемостью инвестиций, в первую очередь необходимо ответить на вопрос: «Где хранятся наши неструктурированные данные, что в них содержится и как мы можем обеспечить их доставку с соблюдением принципов управления?», а не «Какую модель встраивания нам следует использовать?».</p> В мире корпоративного искусственного интеллекта назревает проблема, и ИТ-руководители сталкиваются с дилеммой. Как … article https://www.itweek.ru/themes/detail.php?ID=235388 Fri, 21 Aug 2026 10:03:49 +0300 <p>Институт статистических исследований и экономики знаний (ИСИЭЗ) НИУ ВШЭ на основе данных сплошного статистического обследования Росстата анализирует динамику и структуру затрат крупных и средних организаций (без учета субъектов малого предпринимательства) на внедрение и использование цифровых технологий в 2025 г.</p> <p>В 2025 г. организации направили на внедрение и использование цифровых технологий почти 5,9 трлн руб., что в текущих ценах на 11,8% выше показателя 2024 г.</p> <p>Основные статьи расходов — ПО (лицензии, SaaS, разработка, доработка, адаптация), на которое пришлось 37% анализируемых затрат, и ИКТ-оборудование (приобретение, аренда, обслуживание, модернизация, ремонт) с долей 27%.</p> <p>Расходы на ПО выросли на 13,7%, во многом за счет увеличения заказной разработки.</p> <p>Общий объем затрат на оборудование практически сохранился на уровне 2024 г. (-0,9%), при этом расходы на приобретение ИКТ-оборудования снизились (-10,2%), прежде всего в сегменте вычислительной техники, что объясняется как высокой базой 2024 г. (годом ранее отмечался рост затрат на четверть), так и сложностями с импортом, в том числе из-за возникшего в 2025 г. дефицита серверов и оперативной памяти на мировом рынке. Одновременно в 1,5 раза вырос объем затрат на аренду вычислительных мощностей (IaaS).</p> <p>Наиболее высокими темпами росли расходы на базы данных и цифровой контент: при доле всего 3,3% в структуре затрат за год они увеличились в 1,7 раза.</p> <p>Более половины анализируемых затрат приходится на сферу ИТ и связи (36%) и финансовый сектор (23,1%). В 2025 г. вложения выросли как в этих, так и в большинстве других отраслей— всего в 16 из 18. Расходы в госуправлении, здравоохранении, оптовой и розничной торговле увеличились на <nobr>20–22%,</nobr> в ИТ и связи, финансовом секторе, обрабатывающей промышленности, профессиональной и научно-технической деятельности, на транспорте — на <nobr>11–14%.</nobr></p> <p>Основную часть затрат на цифровые технологии организации покрыли за счет собственных средств (86,6%). Доля бюджетных составила 12,3%, заемных и прочих привлеченных средств — немногим более 1%.</p> Институт статистических исследований и экономики знаний (ИСИЭЗ) НИУ ВШЭ на основе данных сплошного статистического … message