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=234965 Fri, 05 Jun 2026 14:33:37 +0300 <p>Сейчас автоматизация процессов — это базовая задача для бизнеса, способ повысить конкурентоспособность и закрыть боли, связанные с неэффективностью исполнения этапов бизнес-процессов. Когда компания растет, процессов становится больше, они усложняются и теряют прозрачность: руководству сложнее понять, где возникают потери и почему, например, в одном месяце продажи оказались на 25% ниже, чем в другом.</p> <p>Но автоматизации процессов может быть недостаточно. Поэтому следующий шаг — повышение эффективности уже автоматизированных процессов, ведь даже в них остаются узкие места: где-то процесс замедляется из-за человеческого фактора, где-то по-прежнему требуется ручное участие.</p> <p>И вот здесь уже может быть полезен искусственный интеллект. Не как волшебная надстройка, которая сама исправит все проблемы, а как инструмент, который может заметно ускорить рутинные операции.</p> <h3>Три контура внедрения</h3> <p>Сегодня можно выделить три сценария внедрения ИИ для уже автоматизированных процессов.</p> <p><strong>Первый — ИИ, который уже встроен в платформу. </strong>В CRM (системах управления взаимоотношениями с клиентами) и low-code BPM (платформах для управления бизнес-процессами, которые позволяют создавать и настраивать решения без сложной разработки) вендоры зачастую из коробки дают возможность его использовать. То есть заказчик покупает систему, и внутри уже есть ИИ-функции.</p> <p>Плюс очевидный: не нужно привлекать дополнительную экспертизу для настройки, вводить еще одного вендора в ИТ-ландшафт, заключать отдельный договор, разворачивать отдельный продукт. Решение полностью лицензируется единой поставкой. Функций, скорее всего, будет ограниченное количество, но для старта этого часто достаточно.</p> <p><strong>Второй сценарий — это отдельно стоящие решения. </strong>Это те инструменты, которые идут не внутри платформы, а рядом с ней. Они, как правило, более функциональны по сравнению с встроенными и лицензируются дополнительно.</p> <p>Главная задача — «подружить» их с основной системой через интеграцию в нужных точках процесса. Это дороже, сложнее во внедрении и требует погружения в сам продукт. Но при этом и возможностей больше, потому что решение независимое, оно изначально не заточено под конкретную задачу, и его можно далее глубже настраивать под себя.</p> <p><strong>Третий — использование ИИ для настройки самих процессов. </strong>Такие инструменты уже есть в ряде российских платформ.</p> <p>Как это работает: пользователь в чате с ИИ-агентом может описать процесс, и система отрисует его в BPMN-нотации (стандарте моделирования бизнес-процессов), визуализирует схему, настроит атрибуты, карточки внутри системы, дополнительные параметры. Пользователь пишет: «добавь задачу согласования коммерческого предложения после его создания в системе», задача идет на коммерческого директора с двумя вариантами ответа — согласовать или отклонить. Сценарий можно сразу запустить на тест, с маршрутизацией и ответственными.</p> <p>По факту получается, что пользователю вместо <nobr>8-16</nobr> часов на настройку нужно потратить час-полтора на то, чтобы пообщаться с ИИ-агентом и получить уже готовый процесс, который останется только проверить и при необходимости скорректировать.</p> <h3>Сценарии, которые работают</h3> <p>У компании может быть несколько десятков поставщиков или даже тысячи. Каждый предлагает оборудование в разных конфигурациях, и под конкретный запрос менеджеру нужно собрать спецификацию: открыть прайс-листы, подобрать позиции, сопоставить параметры. Можно сделать это вручную — и потратить, например, час времени. А можно поставить задачу ИИ-агенту, и он за минуту отберет данные и сформирует готовый файл, который нужно только проверить и отправить. Тут ИИ дает самый очевидный эффект.</p> <blockquote> <p><em>При этом важно, что речь не про один-два сценария. ИИ встраивается практически в любой процесс, и количество таких решений по сути не ограничено.</em></p> </blockquote> <p>В BPM-системах можно строить модель оттока клиентов прямо на данных внутри системы. Или формировать саммари по заказу: система пробегается по лиду, сделке, позициям и выдает сводку: какая потребность, какая номенклатура, в какой бюджет нужно уложиться. Менеджер проверяет и нажимает «сохранить» — заказ создается автоматически.</p> <p>Другой пример — генерация писем. Система автоматически формирует письмо для клиента из карточки в системе, подтягивает актуальные цены, позиции, выстраивает структуру — приветствие, основную часть, CTA (call to action, призыв к действию). Получается двойной эффект: быстрее реакция и выше уровень коммуникации. Письмо можно отредактировать, отправить из системы или поставить задачу «напиши и отправь». За то же время менеджер может сделать не одно, а сразу десять писем.</p> <p>ИИ может работать не только на данных внутри системы, но и с внешними источниками. Допустим, нужно понять конкурентную среду по сделке по продаже оборудования. Раньше для этого приходилось идти в интернет и собирать информацию по разным сайтам. Сейчас внутри CRM можно задать запрос и получить сводку или сравнительный анализ по аналогичным предложениям на рынке.</p> <p>Существуют и точечные сценарии. Спросить у агента: «С кем согласовать скидку при таких условиях?» — он найдет ответ, даст ссылку. Это полезно, но эффект локальный.</p> <blockquote> <p><em>Системная ценность появляется тогда, когда ИИ встроен в процесс и работает на данных информационной системы.</em></p> </blockquote> <p>Представим ситуацию: новому менеджеру передают клиента, а он не знает контекста: о чем с ним ранее договаривались, какие были сделки. ИИ-ассистент может собрать как внешнюю информацию по клиенту, так и внутренние данные: какие сделки были, на какие суммы проходили оплаты, в чем был интерес, какие активности фиксировались, по каким каналам чаще шла коммуникация. В целом менеджер потратил бы на сбор и изучение контекста, к примеру, три часа. А с помощью ИИ-агента эту информацию можно получить за три минуты.</p> <h3>Почему этап пилота затягивается</h3> <p>Если ИИ так эффективен, почему компании не внедряют его массово? У заказчиков есть причины сомневаться.</p> <ul> <li> Неясно, насколько достоверные сведения возвращает агент. Все равно нужно перепроверять, отлаживать, смотреть, где он ошибается, где додумывает, где не так понял контекст.</li> <li> У ИИ есть склонность к «галлюцинациям» — он начинает додумывать, если теряет контекст. Значит, нужны дисциплина в работе с ним и дополнительные проверки. Это не отменяет пользы, но добавляет неопределенности.</li> <li> Непонятно, как будут меняться роли людей. Если все автоматизируется с помощью ИИ, что тогда будут делать сотрудники?</li> <li> Заказчики хотят увидеть уже доказанный эффект. Чтобы кто-то попробовал, получил результат и показал, что это действительно работает. Любая технология становится дешевле и понятнее, когда превращается в «коробочную» — кто-то уже внедрил, проверил, и дальше ее можно адаптировать под себя.</li> </ul> <p>Но при этом, чтобы развивать такие решения внутри компании, нужны компетенции. Это не та история, где можно просто взять и начать. Нужен отдельный человек, который понимает, как ставить задачу ИИ, как проверять результат и как встраивать его в существующие процессы.</p> <h3>Сначала процесс, потом ИИ</h3> <p>ИИ должен ложиться на хорошо отстроенный процесс: сначала его нужно проанализировать, осознать, оптимизировать, автоматизировать, чтобы появилась система, в которой ИИ сможет жить. И только потом уже имеет смысл добавлять ИИ.</p> <p>Почему это важно? Потому что такие решения работают на структурированных данных и на их объеме. Это хорошо видно на примере маркетплейсов. Они не случайно предлагают подборку «вам может подойти» — иногда предложения выглядят неожиданно точными, хотя человек, казалось бы, еще не покупал подобные товары. В ритейле такие модели используются давно — именно за счет накопленных данных.</p> <blockquote> <p><em>ИИ дает системный эффект только в том случае, если он накладывается на уже выстроенные процесс.</em></p> </blockquote> <p>Невозможно внедрить агента, который предлагает клиенту релевантный продукт для допродажи, если в системе нет накопленной базы знаний по сделкам. В простом примере: человек купил детское питание — сервис ему предлагает подгузники, что выглядит логично. Но в автомобильной отрасли, в продаже автозапчастей, взаимосвязи строятся уже неочевидно: их нужно «выучить» на данных.</p> <h3>ИИ не заменяет людей</h3> <p>С внедрением ИИ не идет речи о том, что люди станут не нужны. Речь про повышение продуктивности. Меньше рутины, больше задач, где действительно нужно участие человека: коммуникации с клиентами, работа с контрагентами, оптимизация процессов.</p> <p>Это хорошо видно, в том числе, по работе с low-code. Несмотря на упрощение настройки, человеческое участие никуда не девается. Все равно нужно осмыслить, что именно настраивается, и внести правки в результат работы искусственного интеллекта.</p> <blockquote> <p><em>ИИ не убирает человека из процесса, а усиливает его. Быстрее передаются в пилот решения, проверяются гипотезы, настраиваются процессы.</em></p> </blockquote> <p>С внедрением ИИ у заказчиков появляется новая роль — условно, специалист по настройке таких решений. В крупных компаниях, например в ритейле, формируются отдельные команды, которые анализируют процессы, ищут точки применения ИИ и с его помощью улучшают существующие системы. То есть автоматизация начинает восприниматься не просто как поддержка, а как инструмент постоянной оптимизации.</p> <h3>Результат против ожиданий</h3> <p>Модель работы постепенно меняется. Сейчас привычный формат — интерфейс: карточки, кнопки, поля. Дальше работа будет смещаться в сторону ассистентов — чата, где формулируется задача или задается вопрос, и сразу возвращается конкретный ответ, без дашбордов и ручной настройки фильтров.</p> <p>Ассистенты уже сейчас закрывают значительную часть задач. При текущем темпе внедрения через пару лет это станет рядовой практикой. При этом у вендоров разная зрелость встроенного ИИ, но направление у всех одно — массовость и тиражирование. Это формирует высокие ожидания от технологии.</p> <p>И здесь важно не подменять реальный эффект ожиданиями. ИИ действительно ускоряет процессы, но только там, где есть выстроенная логика, понятные регламенты и накопленные данные. В этих условиях он снимает рутину и дает измеримый результат. Если этого нет, он не решает проблему, а просто масштабирует те же самые ошибки.</p> <p>#IMAGE_234966#</p> Сейчас автоматизация процессов — это базовая задача для бизнеса, способ повысить конкурентоспособность и закрыть боли … article Светлана Ермакова, руководитель направления CRM и BPM, “Софтлайн Решения” (ГК Softline) https://www.itweek.ru/themes/detail.php?ID=234964 Fri, 05 Jun 2026 09:20:27 +0300 <p><em>Федеративная архитектура (</em><em>Federation</em> <em>Architecture</em><em>, </em><em>FA</em><em>) обеспечивает баланс преимуществ конвергенции ИТ-ОТ с мерами безопасности, одновременно снижая риски, связанные с искусственным интеллектом, и обеспечивая централизованное получение инсайтов, пишет на портале </em><em>Data</em> <em>Center</em> <em>Knowledge</em> <em>Давуд Шахлаи, старший менеджер компании Belden.</em></p> <p>Разрозненные операции все чаще ограничивают эффективность, необходимую для современных рабочих нагрузок, и интеграция информационных технологических систем с операционными технологическими системами (конвергенция ИТ-ОТ) является решением этой проблемы.</p> <p>Однако полностью конвергентные архитектуры ИТ-ОТ создают профиль рисков, который многим операторам трудно обосновать. По мере ускорения внедрения ИИ этот риск становится более острым, особенно когда конвергенция создает точки соприкосновения автоматизации на границе ИТ и ОТ.</p> <p>Рабочие нагрузки, связанные с ИИ, подталкивают организации к конвергенции и увеличивают потребность в общей инфраструктуре, общих данных и централизованных инсайтах. В то же время ИИ создает междисциплинарный риск, который становится видимым только при совместном рассмотрении ИТ-безопасности, безопасности ОТ и рисков, возникающих в связи с ИИ.</p> <p>Задача состоит в том, чтобы обеспечить конвергенцию, не ставя под угрозу основы безопасности и управления в ОТ-средах.</p> <h3>Ценность конвергенции ИТ-ОТ</h3> <p>Конвергенция ИТ-ОТ иногда представляется как цель или неизбежная тенденция, но на самом деле это средство достижения цели. Она обеспечивает единый интеллект на всем инфраструктурном стеке и площадках. Частое преимущество заключается в устранении слепых зон.</p> <p>Когда сигналы об энергоснабжении, охлаждении и ИТ-системах доступны в едином представлении, операторы могут быстрее выявлять проблемы, затрагивающие разные области, например, сопоставляя неисправность системы охлаждения, влияющую на ряд серверов, с пиком задержки сети или снижением производительности ЦП.</p> <p>Помимо обеспечения видимости, конвергенция позволяет скоординированно оптимизировать процессы. При высокой плотности рабочих нагрузок, превышающей температурные пределы, ручное или изолированное управление питанием и охлаждением становится сложнее поддерживать.</p> <p>Сторонники конвергенции могут утверждать, что интегрированные системы могут способствовать более быстрой оперативной реакции и повышению эффективности, особенно когда инсайты и планирование из центрального командного центра охватывают несколько площадок. Однако сочетание конвергенции ИТ-ОТ с реалиями ОТ-среды остается сложной задачей и вызывает постоянные дискуссии.</p> <h3>Состояние дискуссий</h3> <p>Полная конвергенция не так широко распространена, как некоторые предполагают. Дискуссия ведется не о том, полезна ли централизованная видимость. Она о том, насколько корпоративные ИТ должны охватывать ОТ-системы, управляющие физическими процессами.</p> <p>Ключевая причина — структурное несоответствие между ИТ и ОТ. В то время как ИТ-инфраструктура оптимизирована для гибкости и частых изменений, ОТ-инфраструктура оптимизирована для детерминированного поведения, доступности и длительных жизненных циклов. Эти различия создают трения, когда ИТ-практики распространяются на ОТ-среды.</p> <p>Риск также асимметричен. Сбои в ИТ-инфраструктуре часто можно устранить путем восстановления и перестройки. Сбои в ОТ-инфраструктуре могут повредить физические активы и их сложнее устранить. ИТ-служба разрабатывает процесс реагирования на инциденты безопасности, предполагая, что нарушение может произойти, в то время как ОТ-служба инвестирует в предотвращение. Именно поэтому многие операторы рассматривают пути управления ОТ-инфраструктурой как серьезное архитектурное решение.</p> <p>В результате многие организации колеблются между двумя крайностями. Некоторые расширяют удаленные полномочия на объекты для повышения эффективности. Другие замораживают архитектуру, чтобы избежать расширения рисков. На практике конвергенция представляет собой спектр, и каждая организация ищет дисциплинированную золотую середину.</p> <p>Полная конвергенция продолжает обсуждаться по причинам, не связанным со злым умыслом. Развитие ИТ-инфраструктуры делает глубокую интеграцию неизбежной. Упрощение управления способствует созданию единой платформы, а рыночные стимулы поощряют интегрированные платформы. Некоторые площадки в конечном итоге имеют подключенные сети, но неизменные процессы, что может усилить проблемы безопасности и эксплуатации.</p> <p>Уже сейчас, еще до того, как этот спор утихнет, ИИ появляется как следующая переменная и повышает ставки.</p> <h3>Фактор ИИ</h3> <p>ИИ меняет модель угроз, поскольку он может работать внутри доверенных ИТ-сред с законным доступом и выдавать рекомендации, которые могут масштабироваться быстрее, чем люди могут реально контролировать.</p> <p>Это важно, потому что многие дискуссии о безопасности неявно предполагают, что ИИ остается «запертым» в дата-центрах и не может поворачивать ручки или включать/выключать рубильники в операционной инфраструктуре. Двусторонняя конвергенция ИТ-ОТ разрушает этот структурный барьер.</p> <p>ИИ стимулирует предиктивное техническое обслуживание, аналитику и оптимизацию, которые являются основными мотивами конвергенции. В то же время его профиль риска является недетерминированным и непрозрачным. ИИ может влиять на решения и автоматизированные действия через системы, которые рассматривают ИИ как доверенного участника.</p> <p>Системы ИИ статистически оптимизированы, но по своей природе несовершенны. ИИ может преследовать непредусмотренные цели, например, снижать энергопотребление на охлаждение за счет изменения температурных пределов способами, которые выглядят приемлемо на панелях управления, но снижают уровень безопасности. Эта динамика часто описывается как игра с прокси, проблема согласования или потеря контроля.</p> <p>В конвергентных архитектурах сетевые пути и механизмы автоматизации могут превращать аналитические задачи в оперативные команды. Это смещает границу безопасности с одних только сетей и устройств на модель ИИ, ее входные данные и управление тем, что происходит после выдачи рекомендации. Именно поэтому для перспективной модернизации необходим дисциплинированный подход: сохранение уровня безопасности операционных технологий при одновременном обеспечении возможности анализа и оптимизации с помощью ИИ.</p> <p>В центрах обработки данных есть одна особенность: ИИ, оптимизирующий охлаждение, может работать на той же инфраструктуре, которая зависит от этого охлаждения. Это делает ограничения и защитные механизмы первостепенной задачей проектирования.</p> <p>Первые эксперименты показывают, что ИИ может рекомендовать ограниченные действия, но только в сочетании с явными мерами безопасности и человеческим контролем.</p> <h3>Шаблон федеративной архитектуры</h3> <p>FA — это дисциплинированный способ конвергенции ИТ и ОТ без расширения поверхности управления, что операторам может быть трудно оправдать. FA не отвергает конвергенцию. Она переосмысливает ее, делая обязательным небольшой набор архитектурных обязательств и рассматривая любую более глубокую интеграцию как явное решение, требующее обоснования.</p> <p>FA построена на трех принципах:</p> <ol> <li> Автономия на периферии: каждое предприятие сохраняет способность к безопасной, детерминированной работе, даже если оно отключено от корпоративных или облачных систем.</li> <li> Однонаправленный поток данных: операционные данные поступают вверх для аналитики, а архитектурные пути записи в системы ОТ исключены по замыслу.</li> <li> Человеческий контроль: централизованные системы, включая ИИ, могут генерировать рекомендации, но квалифицированные инженеры должны санкционировать изменения до их внедрения.</li> </ol> <p>FA намеренно минимальна. Это набор архитектурных настроек по умолчанию, на основе которых можно безопасно строить другие проектные решения. Для некоторых организаций FA может стать моделью конвергенции, которую они выберут на долгосрочную перспективу. Для других это может быть промежуточным этапом, первым, более безопасным шагом через двустороннюю дверь для итеративного внедрения конвергенции.</p> <p>После внедрения FA организации могут анализировать результаты и либо откатываться назад с минимальными усилиями, либо выбирать контролируемые отклонения от однонаправленности в каждом конкретном случае, не ослабляя автономность периферии или человеческий контроль.</p> <p>Жизнеспособным примером реализации второго принципа может быть разрешение обновлений ПО в контролируемые временные окна для определенных разделов инфраструктуры.</p> <p>FA служит прагматичным вариантом по умолчанию для организаций, стремящихся к получению междоменных инсайтов, избегающих постоянного удаленного управления и готовящихся к расширению интеграции ИИ.</p> <h3>FA: что вы сохраняете и чем жертвуете</h3> <p>Что вы сохраняете с FA:</p> <ul> <li> Полная видимость всего парка техники и централизованная аналитика с использованием телеметрии, передаваемой на север.</li> <li> Обнаружение аномалий, предиктивное техническое обслуживание и обоснованное планирование и составление графиков.</li> <li> Цифровые двойники и моделирование, поддерживающие более безопасные решения об изменениях.</li> <li> Системы рекомендаций, ориентированные на данные.</li> <li> Перспективная и дисциплинированная стратегия, влияющая на модернизацию всей организации.</li> </ul> <p>FA совместима с тем, как владельцы критической инфраструктуры оценивают риски: сохранение видимости и поддержки принятия решений, а также ограничение того, что может напрямую влиять на физические системы.</p> <p>С точки зрения FA, изолированные (air-gapped) площадки могут удовлетворять двум основным принципам: автономность на периферии и человеческий контроль. Для таких площадок добавление восходящего потока данных обеспечивает аналитическую ценность по разумной цене.</p> <p>Чем вы жертвуете с FA:</p> <ul> <li> Скорость удаленного управления и непрерывная оптимизация парка техники.</li> <li> Удобство постоянного двустороннего подключения.</li> <li> Полностью автоматизированное реагирование между площадками в замкнутом цикле.</li> </ul> <p>Для организаций, которые оптимизировали операционные расходы за счет централизации, эти компромиссы снижают ключевые показатели эффективности. Для тех, кто вложил значительные средства в локальные ресурсы и персонал, влияние незначительно.</p> <p>FA в первую очередь не увеличивает затраты на технологии. Она перераспределяет затраты с централизованной эффективности на локальную ответственность. Организации, которые уже работают с полномочиями на уровне площадки, воспринимают FA как дополнительные капитальные затраты. Организации, оптимизированные для сокращения централизованных операционных затрат, воспринимают FA как структурное увеличение операционных расходов. FA предоставляет организациям возможность платить либо операционными возможностями, либо архитектурным риском.</p> <p>Некоторые организации уже могут быть глубоко вовлечены в двустороннюю конвергенцию. Они могут управлять рисками и использовать оптимизацию замкнутого цикла.</p> <p>То же самое не всегда верно для других критически важных сред, где последствия могут быть физически серьезными. Для них гарантированное отсутствие путей управления может даже стимулировать конвергенцию в стиле FA, поскольку утечка данных больше не приравнивается к нарушению систем управления.</p> <h3>Дисциплинированный подход к конвергенции</h3> <p>FA использует аналитические преимущества конвергенции ИТ-ОТ, а также ИИ, сохраняя при этом локальное управление и явное определение рисков, обеспечивая дисциплинированную основу для модернизации в критически важных средах. Отдавая приоритет автономности на периферии, однонаправленному потоку данных и человеческому контролю, FA обеспечивает структуру, соответствующую осторожному характеру критической инфраструктуры.</p> <p>Поскольку ИИ продолжает менять операционные ландшафты, внедрение дисциплинированного подхода, такого как FA, гарантирует, что организации смогут модернизироваться без ущерба для безопасности или контроля. Будь то долгосрочная стратегия или промежуточный шаг, FA позволяет предприятиям уверенно ориентироваться в сложностях конвергенции.</p> Федеративная архитектура (Federation Architecture, FA) обеспечивает баланс преимуществ конвергенции ИТ-ОТ с мерами … article https://www.itweek.ru/themes/detail.php?ID=234962 Fri, 05 Jun 2026 08:51:24 +0300 <p><em>И</em><em>зменения в законодательстве о закупках постепенно формируют новую архитектуру рынка IT-оборудования. Национальный режим, требования к локализации и новая система отчетности меняют не только правила участия в тендерах, но и саму экономику отрасли.</em><em> Рассмотрим</em><em>, почему закупки становятся инструментом промышленной политики и какие компании выиграют в новой модели рынка.</em></p> <p>Еще несколько лет назад рынок государственных закупок IT-оборудования жил в режиме постоянных регуляторных изменений. Появлялись новые ограничения, выходили разъяснения ведомств, корректировались постановления. Участникам рынка приходилось почти ежегодно адаптироваться к новым правилам.</p> <p>Регулирование национального режима становится более унифицированным, хотя подзаконная настройка и практика применения продолжают развиваться. Базовая механика закупок сохранилась, но существенно изменился комплаенс-контур допуска товаров и подтверждения происхождения. Изменилась логика формирования спроса и предложения. Национальный режим в меньшей степени воспринимается как совокупность разрозненных защитных мер, а превращается в инструмент, который задает правила развития рынка и влияет на формирование требований к локализации и происхождению радиоэлектронной продукции. В результате закупка IT-оборудования все чаще рассматривается не как разовая поставка, а как часть более долгосрочной промышленной политики. По сути, мы наблюдаем не очередную волну регулирования, а структурную перезагрузку рынка. Закупочная система все заметнее используется как инструмент реализации технологической и промышленной политики.</p> <h3>Архитектурная перестройка регулирования и новая роль закупок</h3> <p>Ключевой структурный сдвиг связан с тем, что национальный режим получил единое законодательное оформление. Изменения, внесенные законом № <nobr>318-ФЗ,</nobr> закрепили единый рамочный подход к национальному режиму в <nobr>44-ФЗ</nobr> и <nobr>223-ФЗ.</nobr> Если раньше регулирование строилось на отдельных постановлениях и разъяснениях, то теперь базовая логика закреплена на уровне федерального закона.</p> <p>В рамках этой модели применяются запрет, ограничение и преимущество в отношении отечественной продукции. Прикладные механизмы при этом формируются через подзаконные акты правительства, включая постановление № 719, которое устанавливает критерии и условия подтверждения производства российской промышленной продукции, включая требования к технологическим операциям. В совокупности эта система перестает быть набором отдельных ограничений и превращается в полноценную архитектуру регулирования доступа продукции к государственным закупкам.</p> <p>На этом фоне меняется и сама роль закупочной системы. Государство начинает управлять не формой торгов, а структурой спроса. Через такие инструменты, как постановление № 1875, требования к локализации, отраслевые реестры продукции и специальные режимы для программного обеспечения, формируется детализированная модель допуска продукции к закупкам. В результате закупка становится не просто процедурой выбора поставщика, а инструментом реализации промышленной политики, через которую государство стимулирует локализацию и развитие технологических цепочек. А когда закупки начинают выполнять эту функцию, они формируют и новый тип спроса на рынке.</p> <h3>Якорный спрос и новая модель конкуренции</h3> <p>Когда государство начинает управлять структурой спроса через закупки, на рынке формируется предсказуемый внутренний спрос. Одним из механизмов стала обязательная отчетность по закупкам российских товаров в рамках <nobr>223-ФЗ.</nobr> Данные из реестров договоров позволяют измерять долю отечественной продукции и оценивать эффективность национального режима.</p> <p>Импортозамещение в этой модели перестает быть декларацией и становится системой измеримых показателей. При применении «защитных мер» национального режима ограничена замена российского товара иностранным на стадии исполнения контракта. Это закрепляет долгосрочную логику выбора технологических решений. А значит меняются и правила конкуренции на рынке.</p> <p>Цена перестает быть единственным фактором. В ряде сегментов возрастает значение регуляторной исполнимости поставки наряду с ценой. Выигрывает не тот, кто дешевле привез оборудование, а тот, кто способен гарантировать его происхождение, локализацию, исполнение контракта и сопровождение в течение всего жизненного цикла. Механизмы вроде <nobr>15-процентного</nobr> преимущества для российской продукции в рамках <nobr>223-ФЗ</nobr> дополнительно усиливают эту логику.</p> <h3>Ужесточение требований и рост барьеров входа</h3> <p>Одновременно с изменением модели конкуренции заметно ужесточаются требования к участникам рынка. Для поставщиков IT-оборудования ключевыми становятся риски, связанные не столько с самой поставкой, сколько с подтверждением соответствия продукции регуляторным требованиям.</p> <p>Прежде всего это касается происхождения товаров и глубины локализации. Сегодня недостаточно просто заявить российское происхождение продукции — необходимо документально подтвердить цепочку операций, наличие записи в реестре и соответствие установленным требованиям. Любые разрывы в цепочке поставок, несоответствие заявленной локализации или ошибки в документах могут привести к риску отклонения заявки или проблемам на этапе исполнения контракта. Существенно возрастает и роль комплаенса, поскольку поставщик должен обеспечивать регуляторную корректность всей сделки на протяжении всего жизненного цикла контракта.</p> <p>Повышаются требования и к заказчикам. Если раньше достаточно было формально принять указанные в заявке сведения, то теперь заказчик обязан проверять их достоверность: сопоставлять реестровые записи, подтверждать происхождение продукции и контролировать соответствие закупаемого товара заявленным характеристикам.</p> <p>Показательным примером такой логики является контур гособоронзаказа. В рамках регулирования по <nobr>275-ФЗ</nobr> требования к дисциплине исполнения доведены до максимума: расчеты ведутся через отдельные счета, участники кооперации обязаны вести раздельный учет по каждому контракту, а взаимодействие всех участников цепочки находится под постоянным контролем. Эта модель хорошо показывает общий тренд рынка — рост прозрачности, финансовой дисциплины и управляемости кооперации.</p> <p>Такая система требований неизбежно повышает барьеры входа на рынок. Простая модель дистрибуции постепенно уступает место более сложной системе, где ключевое значение имеют управляемость поставок, подтверждаемая локализация и способность выстраивать устойчивые кооперационные цепочки. Именно поэтому следующей закономерностью становится консолидация рынка.</p> <h3>Консолидация рынка и смена роли игроков</h3> <p>Ужесточение требований постепенно меняет структуру самого рынка. Когда растут требования к комплаенсу, финансовой дисциплине, контролю кооперации и сопровождению контрактов, работать в этой системе становится сложнее. Необходимость подтверждать происхождение продукции, управлять цепочками поставок и обеспечивать исполнение контрактов на протяжении всего жизненного цикла требует более зрелых процессов и ресурсов.</p> <p>В этих условиях естественным образом усиливается консолидация рынка. Компании, которые не готовы работать в новой регуляторной логике, постепенно уходят с него или переходят в нишевые сегменты. Одновременно усиливаются позиции игроков, способных выстраивать устойчивые производственные и сервисные цепочки.</p> <p>Меняется и сама роль участников рынка. Модель простого дистрибьютора, который закупает оборудование и перепродает его заказчику, постепенно теряет устойчивость. На первый план выходит другой тип игрока — инфраструктурный интегратор, который не только поставляет оборудование, но и обеспечивает его соответствие требованиям национального режима, управляет кооперацией, сервисом и исполнением контракта. Эти изменения уже формируют новую устойчивую модель рынка.</p> <h3>Необратимость новой модели рынка</h3> <p>Важно понимать, что происходящие изменения носят не временный характер. Они закреплены не только на уровне отдельных постановлений, но и в самой законодательной архитектуре регулирования.</p> <p>Национальный режим зафиксирован в нормах федеральных законов, дополнен системой подзаконных актов и поддержан механизмами контроля и отчетности. Постановления с перечнями продукции, требования к подтверждению происхождения, минимальные доли закупок и другие инструменты формируют устойчивую систему регулирования.</p> <p>В результате формируется новая конфигурация рынка. Внутренний спрос становится более управляемым, локализация — измеримой, а конкурентоспособность компаний все больше определяется их способностью соответствовать промышленной политике государства и обеспечивать полный жизненный цикл решений. Именно эта логика и будет определять развитие рынка государственных закупок IT-оборудования в ближайшие годы. Именно поэтому для участников рынка возникает стратегический вопрос — как работать в этой новой системе правил.</p> <h3>Новые правила игры для участников рынка</h3> <p>В новой конфигурации рынка меняется и сам подход к регуляторике. Ее уже нельзя воспринимать исключительно как ограничение или административную нагрузку. По сути, она становится одним из ключевых факторов, определяющих стратегию развития бизнеса.</p> <p>Сегодня именно требования законодательства формируют рамку, внутри которой выстраиваются продуктовые линейки, кооперационные связи и цепочки поставок. Компании, работающие на рынке IT-оборудования, вынуждены учитывать требования к локализации, подтверждению происхождения продукции, включению в реестры и сопровождению контрактов на протяжении всего жизненного цикла. В результате регуляторная среда превращается в инструмент проектирования бизнеса: вокруг нее формируются инженерные компетенции, сервисная инфраструктура и модели долгосрочного партнерства между производителями, интеграторами и заказчиками.</p> <p>Национальный режим, требования к локализации и механизмы контроля уже закреплены на уровне законодательства и подзаконных актов. Эта модель будет постепенно развиваться и уточняться.</p> <p>Поэтому участникам рынка не стоит рассчитывать на возвращение к прежним условиям. Новая архитектура закупок уже сформирована и станет базовой рамкой для развития отрасли. Поэтому ключевой вопрос сегодня не в том, ослабнут ли требования. Ключевой вопрос — кто из игроков рынка сможет встроить свою стратегию в эту новую модель и использовать ее как точку роста.</p> <p>#IMAGE_234963#</p> Изменения в законодательстве о закупках постепенно формируют новую архитектуру рынка IT-оборудования. Национальный … article Сергей Семикин, СЕО компании “ГИГАНТ — Компьютерные системы” https://www.itweek.ru/themes/detail.php?ID=234961 Thu, 04 Jun 2026 16:10:30 +0300 <p>Компании все чаще рассматривают искусственный интеллект как функциональный слой, глубоко интегрированный в бизнес-процессы и ИТ-ландшафты. Этот сдвиг в 2026 году ведет к переходу от точечных внедрений к комплексным платформенным решениям и архитектуре, где ИИ становится неотъемлемой частью операционной деятельности. ИИ трансформируется в фундаментальный элемент корпоративной инфраструктуры. Владимир Лебедев, директор по развитию бизнеса M1Cloud, рассказал, что ИИ трансформируется в фундаментальный элемент корпоративной инфраструктуры.</p> <p>Мировой рынок ИИ достиг $371,71 млрд в 2025 году, и, по оценкам MarketsandMarkets, в 2026 году составит $601,93 млрд. В России рынок также демонстрирует интенсивную динамику. По данным Just AI и Onside, российский рынок генеративного ИИ по итогам 2025 года достиг 58 млрд рублей, что почти в 4,5 раза больше, чем в 2024 году. Прогнозируется, что к 2030 году этот показатель может достигнуть 778 млрд рублей. Такой рост свидетельствует об активном внедрении ИИ-технологий в отечественном бизнесе.</p> <p>Еще год-два назад внедрение ИИ в бизнесе часто носило характер пилотных проектов. Сегодня ИИ-модели используются для автоматизации операций, поддержки принятия решений, персонализации взаимодействия с клиентами и оптимизации производственных процессов. Однако по мере созревания технологий возникла потребность в более глубокой и системной интеграции. Это требует создания полноценной инфраструктуры, способной поддерживать жизненный цикл ИИ-систем: от обучения до развертывания, мониторинга и обеспечения безопасности.</p> <p>Переход к парадигме «ИИ как инфраструктура» означает не только техническую интеграцию, но и стратегическое изменение подхода к управлению и эксплуатации ИИ. Компании, успешно внедряющие ИИ на уровне инфраструктуры, получают значительные конкурентные преимущества, включая повышение операционной эффективности, ускорение инноваций и улучшение качества принимаемых решений.</p> <p>Однако несмотря на рост внедрения ИИ на предприятиях, существующая инфраструктура не всегда готова к обработке рабочих нагрузок. Это подчеркивает необходимость в специализированных решениях и платформах, которые могут обеспечить необходимую производительность, масштабируемость и безопасность.</p> <p>С расширением применения ИИ и его интеграцией в критически важные корпоративные системы значительно возрастают риски кибербезопасности. Традиционные средства защиты оказываются недостаточными перед лицом новых, специфических угроз, нацеленных непосредственно на ИИ-модели и данные. Злоумышленники активно разрабатывают методы атак, использующие уязвимости в алгоритмах машинного обучения.</p> <p>По данным StormWall, в 2025 году число атак с участием ИИ-ботов в России увеличилось на 63% по сравнению с 2024 годом. Эти цифры подчеркивают острую необходимость в специализированных решениях для защиты ИИ.</p> <p>В ответ на эти вызовы зрелые сервис-провайдеры предлагают заказчикам комплексные решения для специализированной защиты ИИ-моделей от современных киберугроз на базе искусственного интеллекта. По информации экспертов M1Cloud, сервисы облачной ИИ-безопасности (AI Security) имеют специализированную архитектуру, ориентированную на реальные сценарии атак на ИИ, позволяя безопасно внедрять и эксплуатировать ИИ даже при работе с конфиденциальными данными. Сервисы облачной ИИ-безопасности обеспечивают защиту от prompt injection, data poisoning, model inversion и других специфических угроз, направленных на манипулирование или извлечение информации из ИИ-моделей, а также осуществляют непрерывный мониторинг работы ИИ-моделей, выявляя аномалии и риски и другие опции.</p> <p>ИИ как инфраструктура — это новая реальность корпоративного мира. Однако эти возможности сопряжены с новыми, сложными вызовами в области кибербезопасности. Сервис-провайдеры, предлагающие специализированные решения для защиты ИИ-моделей, играют ключевую роль в обеспечении безопасного и устойчивого развития ИИ-инфраструктуры. Только при условии надежной защиты компании смогут в полной мере реализовать потенциал искусственного интеллекта, превратив его в мощный двигатель роста и инноваций.</p> Компании все чаще рассматривают искусственный интеллект как функциональный слой, глубоко интегрированный в бизнес-процессы … message https://www.itweek.ru/themes/detail.php?ID=234960 Thu, 04 Jun 2026 16:09:21 +0300 <p>Компания по управлению онлайн-активами Руцентр запустила новую версию хостинг-платформы со встроенной защитой от кибератак уровня L7. Решение является собственной разработкой Руцентра и будет интегрировано во всю продуктовую линейку виртуального хостинга. Обновление затронет более 50 тысяч активных клиентов из сегмента крупного и среднего бизнеса и порядка 150 тысяч сайтов, размещенных на хостинговой платформе компании.</p> <p>Разработка Руцентра устанавливает новые стандарты безопасности на рынке хостинга. В основе решения — инфраструктурная архитектура с технологией интеллектуальной фильтрации трафика, которая сфокусирована на самом сложном классе атак уровня L7. Технология обеспечивает расширенную защиту с автоматической блокировкой SQL-инъекций, межсайтового скриптинга (XSS), подделки запросов (CSRF) и ботнетов. </p> <p>Вся фильтрация трафика будет происходить в контуре Руцентра, а не на мощностях владельцев сайтов. Если атаки на сетевом (L3) и транспортном (L4) уровнях традиционно отражаются силами операторов связи, то прикладной уровень (L7) обрабатывается на собственном серверном и сетевом оборудовании Руцентра. Кроме того, защиту уровня L7 хостинг-провайдеры обычно предлагают в качестве дополнительной услуги, а Руцентр интегрирует во всю линейку услуг виртуального хостинга на базовом уровне.</p> <p>С новой технологией Руцентра даже в экстренной ситуации сайт будет оставаться доступным без необходимости приобретения дополнительных сервисов и привлечения внешних специалистов. Подключение защиты осуществляется на уровне балансировщиков трафика — без перерыва в работе сайтов и почты. При DDoS-атаке владельцу онлайн-ресурса не потребуется менять настройки домена или хостинга: балансировщики автоматически перенаправляют трафик на очистку. </p> <p>«Традиционная модель, когда безопасный хостинг собирается из разрозненных опций, себя исчерпала. Клиент не должен быть экспертом по DDoS, WAF и бэкапам, чтобы защитить свой онлайн-проект, при этом под атаки сегодня попадают абсолютно все. Новая версия платформы Руцентра предлагает комплексную защиту всех уровней, от сетевого до прикладного, как единый стандарт. Это именно то, что мы называем безопасным хостингом по умолчанию — провайдер берет на себя фильтрацию трафика, а клиент получает гарантию, что его сайт будет работать даже во время массированной атаки», — прокомментировал Валентин Бостанов, руководитель департамента хостинга Руцентра.</p> <p>Новая тарифная линейка будет доступна для заказа с 4 июня. А для всех действующих клиентов Руцентра автоматический переход на новую платформу безопасного хостинга состоится 18 июня. При этом стоимость услуг уже оплаченного срока не изменится, новая тарификация применится только при очередном продлении услуги.</p> <p>Руцентр входит в число крупнейших российских хостинг-провайдеров, имеет лицензии ФСТЭК на техническую защиту конфиденциальной информации и лицензию ФСБ в области шифрования. Компания предоставляет услуги защищенного хостинга ФЗ-152 и хостинга для госсистем. Запуск нового сервиса становится очередным шагом компании по усилению продуктового портфеля в области информационной безопасности.</p> Компания по управлению онлайн-активами Руцентр запустила новую версию хостинг-платформы со встроенной защитой … message https://www.itweek.ru/themes/detail.php?ID=234959 Thu, 04 Jun 2026 16:06:48 +0300 <p>Крупный бизнес больше не рассматривает замену зарубежных ERP-систем как формальную ИТ-задачу. Компании реального сектора связывают такие проекты с устойчивостью операционной модели, управляемостью данных и снижением зависимости от зарубежной ИТ-инфраструктуры. На практике это приводит к тому, что компании выбирают разные модели развития ERP-ландшафта. К такому выводу пришли аналитики Axenix в исследовании «Российский ERP-рынок: траектории развития».</p> <p>Исследование показало, что российский рынок систем управления перешел к прагматичной трансформации. Одного лишь импортозамещения больше недостаточно для старта проектов. Сегодня бизнес инвестирует в изменения для снижения рисков, оптимизации затрат и повышения управляемости данных. Компании отказываются от универсальных стратегий, выбирая гибкие сценарии с учетом своей операционной готовности.</p> <p>Одни продолжают использовать зарубежные платформы с локальной поддержкой и собственными доработками. Другие переходят на российские продукты или развивают отдельные специализированные системы под конкретные бизнес-задачи. Российские подразделения международных компаний выделяют локальный ИТ-контур из глобальной системы, переносят данные и поддержку, но не всегда рассматривают этот этап как окончательное решение. Выбор подхода зависит от отрасли, зрелости процессов, качества данных и готовности бизнеса к изменениям.</p> <p>ERP остается центром корпоративной архитектуры, но сама модель таких систем меняется. Компании все чаще разделяют учетное ядро и специализированные контуры: ERP-ядро отвечает за финансы, учет, казначейство и базовые закупки, а отдельные системы закрывают производство, логистику, документооборот, аналитику, бюджетирование и отраслевые процессы. Такой подход снижает риск единовременной миграции, позволяет обновлять ИТ-ландшафт поэтапно и ускоряет изменения в специализированных контурах.</p> <p>При выборе ERP-платформы участники исследования обращают внимание прежде всего на то, понимает ли вендор практику больших внедрений: управление релизами, тестирование, поддержка, архитектурный надзор, документация, исправление дефектов, работа с критичными инцидентами. Не менее важны для заказчиков качество документации и наличие понятной дорожной карты развития. Одновременно компании оценивают способность системы работать под нагрузкой и в едином контуре с большим оргобъемом и массивами данных. Особое внимание уделяется технологическому стеку выбираемого решения. Российское происхождение ERP не гарантирует полной независимости, если инфраструктура продолжает работать на иностранных системах виртуализации или аналитических инструментах.</p> <p>Одним из самых сложных этапов ERP-трансформации остается работа с данными, которые часто становятся главным скрытым риском внедрения. По оценке Axenix, программу управления мастер-данными стоит запускать еще до миграции. Без очистки справочников, правил контроля качества данных и интеграций новая система унаследует старые проблемы.</p> <p>Исследование также зафиксировало, что ожидания «бесшовной» замены ERP без изменения процессов постепенно исчезают. Компании признают, что переход требует пересмотра организационной модели, подходов к управлению данными и внутренних процессов. Те, кто начинают такую подготовку заранее, проходят миграцию быстрее и с меньшими потерями времени и бюджета. </p> <p>«Российский ERP-рынок перестал жить логикой срочного импортозамещения. Компании начали оценивать не только происхождение платформы, но и способность решения обеспечивать устойчивость бизнеса на горизонте <nobr>5-10 лет.</nobr> Поэтому рынок движется в сторону гибких архитектур, поэтапной миграции и более прагматичного подхода к трансформации. В ближайшие годы рынок будет развиваться не вокруг одного доминирующего продукта, а вокруг способности поставщиков подтверждать надежность решений в реальных корпоративных сценариях», — прокомментировал Евгений Смирнов, эксперт по ERP компании Axenix.</p> <p>По прогнозу Axenix, в <nobr>2027-2028</nobr> годах рынок вряд ли придет к одному новому ERP-лидеру. Вероятнее закрепление гибридной модели: российское или импортонезависимое ядро, отраслевые контуры, собственные доработки, сильный слой данных и интеграций. </p> <p>Крупные компании будут переходить на российские решения поэтапно. Полная замена ERP-монолита одним проектом останется редкой из-за риска остановки критичных процессов, сложности данных и необходимости вовлекать бизнес на длительный срок.</p> <p>Российские платформы продолжат расти, но крупный бизнес будет требовать отраслевых шаблонов, подтвержденных нагрузочных тестов, архитектурного надзора и развития партнерской экосистемы.</p> <p>Исследование «Российский ERP-рынок: траектории развития» Axenix провела весной 2026 года. Аналитики компании изучили открытые отраслевые данные и провели серию интервью с представителями крупнейших российских компаний из промышленности, энергетики, транспорта, финансового сектора и машиностроения. </p> Крупный бизнес больше не рассматривает замену зарубежных ERP-систем как формальную ИТ-задачу. Компании реального сектора … message https://www.itweek.ru/themes/detail.php?ID=234958 Thu, 04 Jun 2026 16:04:07 +0300 <p>Банк ЗЕНИТ объявил о запуске кабинета налогоплательщика Автоматизированной упрощенной системы налогообложения на базе платформы Digital2SME от компании BSS. Автоматизированная упрощенная система налогообложения (АУСН) — это специальный налоговый режим, который предоставляет малому бизнесу преимущества:</p> <ul> <li>автоматический расчет налогов самим ФНС;</li> <li>отсутствие обязательных страховых взносов;</li> <li>ставки налогообложения: 8% с полученных доходов, либо 20% с разницы между доходами и расходами.</li> </ul> <p>На АУСН может перейти бизнес с численностью работников не более 5 человек и годовым доходом не более 60 млн рублей. Подробные условия опубликованы на сайте ФНС. </p> <p>АУСН от BSS — активно внедряемое на российском рынке промышленное коробочное решение, полностью прошедшее аккредитацию Федеральной налоговой службы. На сегодняшний день сервис успешно функционирует в девяти банках, включая Банк ЗЕНИТ. Еще несколько финансовых организаций находятся на финальной стадии внедрения.</p> <p>«Благодаря слаженному взаимодействию с командой BSS мы смогли запустить решение АУСН для клиентов Банк ЗЕНИТ всего за 3 месяца. Справедливый итог проделанной работы — удобный сервис для предпринимателей и признание банковского сообщества — премия FINAWARD’26, полученная банком «За инновации в цифровом взаимодействии бизнеса и государства», — отметил Дмитрий Дьяков, руководитель блока МСБ Банка ЗЕНИТ.</p> <p>Клиенты Банка ЗЕНИТ, подключившие кабинет налогоплательщика АУСН, получают:</p> <ul> <li>автоматическую передачу данных о доходах и расходах в ФНС напрямую из ДБО;</li> <li>расчет налога налоговым органом без необходимости подачи декларации;</li> <li>удобный мониторинг начислений и оплат в личном кабинете;</li> <li>интеграцию с кассовыми системами и бухгалтерскими сервисами;</li> <li>поддержку при переходе на новый режим и консультации по налоговым вопросам.</li> </ul> <p>«Для нас большая ценность, что Банк ЗЕНИТ доверил реализацию такого стратегически важного проекта команде BSS. АУСН — это не просто новый функционал, это инструмент, который помогает малому бизнесу сократить административную нагрузку и сфокусироваться на развитии. Наше решение, уже проверенное в реальных условиях и одобренное ФНС, позволяет банкам минимизировать риски и выводить сервис на рынок в предсказуемые сроки», — подчеркнула Юлия Савинова, руководитель направления по развитию цифровых продуктов Центра цифровых решений для бизнеса компании BSS.</p> Банк ЗЕНИТ объявил о запуске кабинета налогоплательщика Автоматизированной упрощенной системы налогообложения на базе … message https://www.itweek.ru/themes/detail.php?ID=234955 Thu, 04 Jun 2026 10:07:38 +0300 <p><em>Отслеживание производительности искусственного интеллекта имеет решающее значение. Однако традиционные ИТ-инструменты не справляются с этой задачей. CIO должны расширить свое видение и кругозор, считают опрошенные порталом </em><em>InformationWeek</em> <em>эксперты.</em></p> <p>Ни один уголок современного предприятия не остается незатронутым ИИ. Но по мере расширения сценариев использования и резкого роста внедрения появляются трещины в развертывании этой технологии. CIO все чаще сталкиваются с трудностями в отслеживании того, что делают системы ИИ, кто их использует и как они работают.</p> <p>Во многих случаях CIO обнаруживают, что у них нет возможности отслеживать или измерять критически важные факторы, такие как дрейф модели, задержка, частота галюцинаций, снижение производительности, теневой ИИ и ухудшение результатов. Неудивительно, что по мере того, как системы ИИ принимают все более важные решения и обрабатывают критически важные действия, риски возрастают.</p> <p>«CIO уверены, что знают, как ИИ развертывается в их организации, но обычно они не могут сказать, как он на самом деле работает», — отмечает Арнаб Чакраборти, директор по ответственному ИИ компании Accenture.</p> <p>Согласно ИИ-индексу HAI 2026 Стэнфордского университета (на основе данных McKinsey), доля организаций, оценивших свою реакцию на инциденты, связанные с ИИ, как «отличную», снизилась с 28% в 2024 г. до 18% в <nobr>2025-м.</nobr> При этом 88% организаций сообщили об использовании ИИ как минимум в одной бизнес-функции, но менее 10% полностью масштабировали ИИ в какой-либо отдельной области.</p> <p>Вывод? В условиях быстро меняющегося пространства ИИ наблюдаемость имеет решающее значение. Однако ИИ требует принципиально иного подхода, чем традиционные ИТ-решения. «Для понимания повседневной производительности и управления рисками крайне важно мыслить шире традиционных ИТ-показателей», — считает Чакраборти.</p> <h3>Важность видимости производительности ИИ</h3> <p>Что отличает мониторинг ИИ от традиционного ИТ-мониторинга, так это непредсказуемость. Время безотказной работы, пропускная способность, коэффициенты использования и ошибки — показатели, которые лежат в основе ИТ — не отражают факторы и риски, характерные для ИИ. Это потому, что ИИ по своей природе является вероятностным. Одни и те же входные данные может давать совершенно разные выходные данные.</p> <p>Эти проблемы могут принимать самые разные формы. CIO, как правило, знают предполагаемое назначение систем ИИ, но им не хватает понимания точности, задержки, пользовательского интерфейса, затрат и рисков. Им также приходится бороться с проблемами дрейфа моделей, поведения агентов и теневого ИИ. К сожалению, ни один поставщик не создал инструмент, обеспечивающий наблюдаемость на всех уровнях ИИ.</p> <p>Проблема кроется в самом принципе работы ИИ. Это не единая модель с единственным результатом. ИИ обычно представляет собой набор компонентов: конвейеры данных, базовые модели, системы поиска, агенты и другие компоненты — все они взаимодействуют с людьми и рабочими процессами. Агентный ИИ вносит дополнительные риски. К ним относятся «каскадные ошибки, сбои интеграции, неясная ответственность и труднопредсказуемое поведение, возникающее при взаимодействии нескольких агентов в рамках рабочих процессов», — говорит Илана Голбин Блюменфельд, партнер по ответственному ИИ в PwC US.</p> <p>Неправильно откалиброванная политика поиска может исказить результаты в десятке последующих приложений. Дрейф векторной базы данных может проявляться в виде галлюцинаций в чат-боте. По мере того, как предприятия объединяют агентов для выполнения более длительных задач, количество потенциальных проблем увеличивается быстрее, чем появляются инструменты, предназначенные для мониторинга среды. «Это не просто линейный эффект, это эффект накопления», — отмечает Чакраборти.</p> <p>Часто эти проблемы остаются незамеченными в течение недель или месяцев — пока что-то внезапно не сломается. Это происходит потому, что уровень снижения производительности незаметен — до тех пор, пока он не проявится. «Если вы не вмешаетесь достаточно рано, через несколько дней вы можете внезапно оказаться в нежелательном положении», — говорит Грейс Тринидад, директор по исследованиям в области безопасности и доверия к ИИ в IDC.</p> <p>По ее словам, существующие панели мониторинга и инструменты безопасности не могут решить эту проблему. Большинство из них полагаются на оценки риска и рейтинги уверенности, которые недостаточны и совершенно непрозрачны применительно к ИИ. Фактически, две организации могут запускать идентичные модели и получать совершенно разные представления об одном и том же факторе риска. «Нет стандартизации того, что входит в оценку риска», — говорит она.</p> <h3>Как развивается мониторинг ИИ</h3> <p>Нельзя управлять тем, чего не видишь. Microsoft обнаружила, что 73% организаций выявили несанкционированные инструменты ИИ в своих сетях, однако только 28% имеют комплексные возможности мониторинга или блокировки. Исследование McKinsey «2026 AI Trust Maturity Survey» показало, что средний показатель зрелости организаций составляет 2,3 из 4, при этом только около трети достигли уровня зрелости 3 или выше в области стратегии, управления и контроля за агентным ИИ.</p> <p>«Одна из самых больших проблем для организаций заключается в том, что они по-прежнему отслеживают ИИ как традиционное ПО. Они видят, что инфраструктура ИИ работает, но не понимают, почему она выдает плохие или ненадежные результаты», — говорит Блюменфельд. ​​Часто организации разрабатывают процессы предварительной оценки рисков и сбора информации, которые не учитывают фактическое использование системы ИИ и то, как риски внутри приложения могут меняться. «Ключевым моментом является выбор инструментов, которые могут интегрироваться в мультиоблачных, мультимодельных и агентных средах ИИ», — отмечает она.</p> <p>Фактически, наблюдаемость ИИ быстро развивается в сторону полной видимости всего стека, а также более тонкого понимания поведения ИИ. В этом мире телеметрические данные отходят на второй план по сравнению с такими вещами, как семантическое сопоставление и интерпретация намерений, непрерывный мониторинг и аудит, представления и элементы управления, соответствующие ролям, и инструменты, которые более комплексно контролируют требования безопасности и регулирования. По словам Блюменфельд, эти инструменты должны охватывать управление, мониторинг инфраструктуры и видимость на уровне моделей.</p> <p>Надежный процесс обнаружения является основополагающим, считает Тринидад. Важно каталогизировать модели, агентов, владельцев, версии, контексты развертывания и журналы — предпочтительно в реестре ИИ. Имея четкое представление о том, что должны делать системы, и понимание того, что нужно изменить, предприятие может начать внедрять мониторинг во всю систему. С помощью этой информации CIO могут выявлять отклонения данных и моделей, снижение производительности, галюцинации, теневой ИИ и риски безопасности до того, как они вызовут проблемы или нанесут ущерб репутации.</p> <p>Многоуровневый мониторинг также требует автоматизированных механизмов защиты, отмечает Чакраборти. Это означает установление правильных пороговых значений для ключевых факторов, включая частоту галюцинаций, задержку, смещение, конфиденциальность, затраты, отклонения данных и моделей, соответствие нормативным требованиям и качество выходных данных. Также требуется правильное сочетание инструментов от гиперскейлеров и сторонних поставщиков для управления и измерения задач.</p> <p>Благодаря интегрированной плоскости управления — единому архитектурному слою, который собирает и отображает все сигналы — менеджеры и руководители из разных отделов могут видеть то, что действительно важно для них. Например, директор по управлению рисками видит пороговые значения рисков и нарушения, финансовый директор отслеживает потребление и стремительный рост затрат на облачные сервисы, руководитель отдела кадров видит влияние на персонал, а инженеры держат руку на пульсе вопросов аудита и объяснимости. «Это формирует вашу ДНК, почти как нервную систему для вашего ИИ», — говорит Чакраборти.</p> <h3>Куда движется наблюдаемость ИИ</h3> <p>«CIO следует рассматривать наблюдаемость ИИ как основной принцип проектирования, а не как нечто добавляемое после развертывания», — считает Блюменфельд. ​​Она также отмечает, что важно рассматривать наблюдаемость как межфункциональную инициативу, охватывающую ИТ, бизнес, управление рисками и соблюдение нормативных требований, а также внутренние аудиторские группы. «Отрасль выходит за рамки мониторинга отдельных моделей ИИ и переходит к мониторингу целых экосистем агентов, уровней оркестровки, конвейеров данных и автономных рабочих процессов», — говорит она.</p> <p>Если организации правильно учитывают эти параметры, они могут масштабировать ИИ быстрее и безопаснее, контролировать затраты даже при росте рабочей нагрузки, создавать безупречный аудиторский след и повышать доверие клиентов. По прогнозам Gartner, инвестиции в мониторинг больших языковых моделей к 2028 г. составят 50% от общего числа внедрений генеративного ИИ, по сравнению с 15% сегодня.</p> <p>Безусловно, наблюдаемость ИИ — это не дополнительный элемент, и он не следует стандартной формуле ИТ-инфраструктуры. Это фундаментальный элемент, который необходимо встроить в структуру ИИ. «Организации, которые с самого начала правильно подойдут к этому вопросу и инвестируют в развитие соответствующих возможностей, станут лидерами в эпоху ИИ», — считает Чакраборти.</p> Отслеживание производительности искусственного интеллекта имеет решающее значение. Однако традиционные ИТ-инструменты … article https://www.itweek.ru/themes/detail.php?ID=234952 Thu, 04 Jun 2026 09:38:41 +0300 <p>Практически каждая компания, которая развивает цифровой продукт, рано или поздно сталкивается с одним и тем же вопросом: формировать собственную команду тестирования или привлекать внешнего подрядчика. Еще несколько лет назад выбор был относительно очевидным — крупный бизнес предпочитал развивать внутренние компетенции, а стартапы чаще обращались к внешним командам. Сегодня ситуация стала сложнее. Рынок испытывает дефицит квалифицированных QA-инженеров, стоимость найма растет, а скорость вывода новых продуктов становится критическим фактором конкуренции.</p> <p>Поэтому вопрос «тестирование ПО in-house или аутсорсинг» уже нельзя рассматривать только через призму затрат. На первый план выходят качество продукта, контроль процессов, безопасность данных, доступность экспертизы и способность быстро масштабировать ресурсы. Ошибка при выборе модели может привести не только к перерасходу бюджета, но и к задержкам релизов, росту количества дефектов и снижению удовлетворенности пользователей.</p> <p>Разберем сильные и слабые стороны каждого подхода и посмотрим, в каких ситуациях они работают лучше всего.</p> <h3>Что такое тестирование in-house</h3> <p>Тестирование in-house предполагает, что внутренняя команда QA является частью компании и работает вместе с разработчиками, аналитиками и владельцами продукта. Такой подход обеспечивает высокий уровень контроля над процессами и позволяет тестировщикам глубоко понимать архитектуру системы, бизнес-логику и цели продукта.</p> <p>Главное преимущество модели — постоянная коммуникация между участниками разработки. Когда тестировщики находятся внутри команды, они быстрее получают информацию об изменениях, участвуют в обсуждении требований и могут выявлять риски еще до начала разработки. Особенно эффективно это работает в долгосрочных проектах, где продукт развивается годами.</p> <p>Кроме того, внутренняя команда часто становится носителем критически важных знаний о системе. Это особенно ценно для банковских платформ, медицинских сервисов, государственных информационных систем и других продуктов с повышенными требованиями к безопасности.</p> <p>Однако полностью внутренняя QA-команда уже не всегда является признаком зрелости: иногда она превращается в дорогой и медленно масштабируемый ресурс, если не подкреплена автоматизацией и внешней экспертизой.</p> <h3>Что такое аутсорсинг тестирования</h3> <p>Аутсорсинг тестирования — это передача задач по обеспечению качества специализированной внешней компании. Вместо формирования собственного отдела бизнес получает доступ к уже готовой команде специалистов, обладающих необходимой экспертизой и набором инструментов.</p> <p>Основное преимущество такого подхода — гибкость. Если компании необходимо быстро протестировать новый продукт, провести нагрузочные испытания или организовать автоматизацию тестирования, подрядчик может подключить нужных специалистов за считанные дни или недели.</p> <p>Например, многие финтех-стартапы на ранних этапах используют внешние команды QA, поскольку создание полноценного отдела тестирования требует значительных инвестиций. При этом бизнес получает доступ к инженерам, которые уже имеют опыт работы с похожими продуктами.</p> <p>Однако существуют и риски. Внешняя команда не всегда обладает глубоким пониманием продукта, а эффективность взаимодействия во многом зависит от качества коммуникации. Кроме того, появляются вопросы контроля процессов и безопасности данных, которые необходимо учитывать при выборе подрядчика.</p> <h3>Сравнение тестирования in-house и аутсорсинга тестирования</h3> <p>Когда обсуждается тестирование ПО in-house или аутсорсинг, руководители обычно сравнивают не только стоимость, но и влияние модели на качество продукта и скорость развития бизнеса.</p> <table> <tbody> <tr> <th> Критерий</th> <th> In-house-команда</th> <th> Аутсорсинг</th> </tr> <tr> <td> Стоимость</td> <td> Высокие постоянные расходы</td> <td> Гибкие затраты по мере необходимости</td> </tr> <tr> <td> Контроль качества</td> <td> Максимальный контроль процессов</td> <td> Контроль через KPI и SLA</td> </tr> <tr> <td> Скорость запуска</td> <td> Требуется время на найм</td> <td> Быстрое подключение специалистов</td> </tr> <tr> <td> Безопасность данных</td> <td> Более высокий уровень контроля</td> <td> Требуются дополнительные меры защиты</td> </tr> <tr> <td> Масштабируемость</td> <td> Ограничена кадровым ресурсом</td> <td> Быстрое расширение команды</td> </tr> <tr> <td> Экспертиза</td> <td> Зависит от сотрудников компании</td> <td> Доступ к специалистам разных профилей</td> </tr> </tbody> </table> <p>На практике многие компании используют не один критерий, а целый набор факторов.</p> <p>Для одних критична скорость запуска проекта, для других — контроль качества или требования регуляторов к безопасности.</p> <h3>Стоимость и бюджет</h3> <p>При формировании собственного QA-отдела компания несет фиксированные расходы: заработные платы, налоги, обучение сотрудников, лицензии на инструменты и затраты на подбор персонала. В условиях дефицита кадров стоимость найма опытных специалистов может оказаться существенной статьей бюджета.</p> <p>Аутсорсинг позволяет перевести часть расходов в переменные затраты. Компания платит только за необходимые ресурсы и может масштабировать команду по мере изменения нагрузки. Именно поэтому на старте проектов внешняя модель часто оказывается экономически привлекательнее.</p> <p>Согласно исследованиям рынка ИТ-аутсорсинга, около двух третей компаний передают внешним подрядчикам хотя бы часть технологических функций. При этом тестирование программного обеспечения остается одним из самых востребованных направлений. Для многих организаций причиной становится не только экономия, но и возможность быстрее получить специалистов необходимого уровня.</p> <p>По оценкам ряда отраслевых исследований, использование внешних QA-команд позволяет сократить расходы на тестирование на <nobr>30-70%</nobr> в зависимости от модели сотрудничества и структуры проекта. Дополнительным преимуществом становится возможность оперативно наращивать ресурсы под конкретные задачи без длительного процесса найма.</p> <h3>Контроль качества и процессов</h3> <p>Одна из главных причин создания внутренних QA-команд — желание сохранить полный контроль над качеством продукта. Руководители могут напрямую влиять на процессы тестирования, стандарты работы и приоритеты команды.</p> <p>При работе с подрядчиком часть контроля неизбежно передается внешней стороне. Это не означает снижение качества, но требует четко сформулированных требований, понятных KPI и прозрачной системы отчетности. Чем подробнее описано техническое задание и ожидания бизнеса, тем эффективнее будет сотрудничество.</p> <p>Хорошим примером здесь выступает банковский сектор. По данным World Quality Report, финансовые организации направляют на QA и тестирование около трети всего бюджета разработки. При этом значительная часть критически важных систем продолжает тестироваться внутренними командами. Причина проста: ошибки в платежной инфраструктуре или системах дистанционного обслуживания могут стоить компании не только денег, но и репутации.</p> <h3>Безопасность данных и конфиденциальность</h3> <p>Для компаний, работающих с финансовой информацией, медицинскими данными или персональными сведениями пользователей, вопросы безопасности нередко становятся решающим фактором.</p> <p>Внутренняя команда позволяет минимизировать риск утечки информации и лучше контролировать доступ к критически важным данным. Поэтому банки, страховые компании и государственные структуры часто делают выбор именно в пользу модели in-house.</p> <p>Если же используется аутсорсинг, необходимы дополнительные меры защиты: соглашения о неразглашении, аудит безопасности подрядчика, сегментация доступа и контроль действий специалистов в рабочих средах.</p> <p>Важно понимать, что сегодня вопрос безопасности зависит не столько от формата сотрудничества, сколько от зрелости процессов. Многие крупные аутсорсинговые компании проходят сертификацию по международным стандартам информационной безопасности и работают с требованиями, сопоставимыми с внутренними корпоративными политиками крупных заказчиков.</p> <h3>Коммуникация и взаимодействие</h3> <p>Даже лучшие специалисты не смогут эффективно работать без качественной коммуникации. Внутренняя команда находится в едином информационном пространстве с разработчиками и аналитиками, что ускоряет принятие решений и снижает количество недопониманий.</p> <p>При аутсорсинге могут возникать сложности, связанные с часовыми поясами, различиями в корпоративной культуре и языковыми барьерами. Особенно заметно это становится на сложных проектах с быстро меняющимися требованиями.</p> <p>Однако практика показывает, что правильно организованные процессы способны нивелировать эти риски. Многие компании успешно работают с распределенными командами на протяжении многих лет без существенного влияния на качество продукта.</p> <p>Показателен пример рынка электронной коммерции. Крупные интернет-магазины нередко используют гибридную модель: внутренняя команда отвечает за ключевые пользовательские сценарии и знание продукта, а внешние специалисты подключаются перед крупными распродажами для проведения нагрузочного тестирования и масштабной регрессии. Такой подход позволяет справляться с сезонными пиками нагрузки без необходимости содержать большой штат сотрудников круглый год.</p> <h3>Как сделать правильный выбор</h3> <p>Универсального ответа на вопрос, что лучше — тестирование ПО in-house или аутсорсинг, не существует. Решение должно основываться на конкретных бизнес-задачах.</p> <p>Перед выбором стоит ответить на несколько вопросов:</p> <ul> <li> Насколько ограничен бюджет проекта?</li> <li> Требуется ли быстрое масштабирование команды?</li> <li> Есть ли повышенные требования к безопасности?</li> <li> Нужна ли специализированная экспертиза?</li> <li> Планируется ли долгосрочное развитие продукта?</li> </ul> <p>#IMAGE_234954#</p> <p>Для стартапов и SaaS-компаний выбор часто склоняется в сторону аутсорсинга. На ранних этапах развития продукта важно быстро проверять гипотезы и выводить новые функции на рынок. В этих условиях содержание большого QA-отдела может замедлить развитие бизнеса.</p> <p>Именно поэтому многие технологические компании используют комбинированную модель: несколько внутренних специалистов отвечают за стратегию качества и знание продукта, а автоматизация, тестирование производительности или аудит безопасности привлекаются извне. Такой подход позволяет получать доступ к узкопрофильной экспертизе без существенного увеличения постоянных расходов. На практике самый устойчивый подход — не выбирать между in-house и аутсорсингом, а строить QA-модель вокруг рисков продукта, скорости релизов и стоимости ошибки для бизнеса.</p> <h3>Заключение</h3> <p>Выбор между собственной командой тестирования и аутсорсингом нельзя свести к простому сравнению стоимости услуг. На решение влияют зрелость продукта, требования к безопасности, доступность кадров, скорость развития бизнеса и множество других факторов.</p> <p>Интересно, что рынок постепенно движется не к доминированию одной из моделей, а к их сочетанию. По отраслевым оценкам, до <nobr>60-70%</nobr> компаний сегодня используют смешанную модель QA, оставляя внутри управление качеством и передавая подрядчикам специализированные задачи. Компании все чаще оставляют внутри стратегические компетенции и знания о продукте, а внешних специалистов привлекают для решения специализированных задач или быстрого масштабирования ресурсов.</p> <p>Поэтому главный вопрос сегодня звучит уже не как «in-house или аутсорсинг», а как «какое сочетание этих подходов позволит бизнесу быстрее достигать своих целей без потери качества продукта». Именно такой взгляд становится определяющим для современных CTO, ИТ-директоров и руководителей цифровых продуктов.</p> <p>#IMAGE_234953#</p> Практически каждая компания, которая развивает цифровой продукт, рано или поздно сталкивается с одним и тем же … article Ирина Зверева, директор по маркетингу компании “Точка качества” https://www.itweek.ru/themes/detail.php?ID=234949 Thu, 04 Jun 2026 09:25:51 +0300 <p>Управление качеством — один из самых болезненных процессов на любом производственном предприятии. Его автоматизация уже давно перестала быть данью моде: речь идет о прямых потерях от брака, рисках рекламаций, неликвидных остатках и, в конечном счете, о доверии заказчиков. Однако на практике выбор подхода к автоматизации качества оказывается мучительным компромиссом между «быстро и дешево», «гибко, но дорого» и «стандартно, но сыро».</p> <p>#IMAGE_234951#</p> <p>В этой статье — анализ возможных стратегий построения системы контроля качества на базе современной ERP, их преимуществ, ограничений и рекомендаций по выбору. Только те моменты, с которыми производители действительно сталкиваются прямо сейчас.</p> <h2>Основные этапы построения системы качества в ERP</h2> <p>Учет качества в любой крупной учетной системе можно выстроить по-разному. Все зависит от сложности решаемых задач и финансовых возможностей компании. Можно обойтись встроенными механизмами, можно заказать доработку «под себя», а можно внедрить специализированный лабораторный модуль. Рассмотрим три основных пути — от наиболее простого к сложному.</p> <h3>1. Базовые возможности ERP (работа «из коробки»)</h3> <p>В стандартной версии практически любой серьезной ERP уже есть все необходимые инструменты для организации входного контроля. Однако отдельной «кнопки» или готового комплексного сценария именно под входной контроль, как правило, не предусмотрено — этот процесс нужно настраивать под задачи конкретного предприятия. При этом имеющегося функционала достаточно, чтобы выстроить полноценный входной контроль без дополнительных систем.</p> <p>Для организации процесса пользователям приходится комбинировать типовые объекты: создавать отдельные позиции для брака, использовать партии (серии) с признаками годности и выделять специальные склады-карантины для некачественной продукции.</p> <h3>2. Доработка системы под собственные нужды</h3> <p>Часто встроенного функционала недостаточно, компании дорабатывают систему. Это может включать:</p> <ul> <li> улучшение пользовательского интерфейса (чтобы контролерам было удобнее);</li> <li> изменение логики (переключение между статусами, блокировки, маршрутизация);</li> <li> добавление новых аналитических отчетов (для анализа показателей);</li> <li> интеграцию (связка с другими программными продуктами).</li> </ul> <p>Успех такой доработки полностью зависит от профессионализма команды: сначала анализ, затем четкое техническое задание, потом разработка, тестирование и лишь после этого — внедрение в промышленную эксплуатацию.</p> <h3>3. Специализированные решения (для сложных задач)</h3> <p>В случае необходимости автоматизировать работу собственной лаборатории (когда к качеству продукции предъявляются особые требования), на рынке существуют готовые лабораторные модули. Как правило, такие модули могут быть интегрированы с основной ERP-системой, однако это отдельный продукт, который требует дополнительных лицензий и бюджета на внедрение.</p> <p>Такие решения позволяют управлять пробами, автоматически собирать данные с измерительных приборов и формировать протоколы испытаний, а также паспорта качества.</p> <p>Кроме того, существуют отраслевые сборки (например, для молочной, фармацевтической или металлургической отраслей), в которые уже «зашиты» типовые методики проверок и обязательные отчеты по отраслевым стандартам.</p> <h2>Сравнительный анализ методов управления качеством</h2> <p>При выборе автоматизации многие оказываются в затруднении: хватит ли стандартного функционала, стоит ли заказывать доработки или лучше сразу присматриваться к профессиональным решениям?</p> <p>Ниже представлена таблица, в которой наглядно видны отличия подходов, их задачи и типичные сценарии применения.</p> <div class="block-scroll"> <table> <tbody> <tr> <th> Подход/Решение </th> <th> Описание и основные возможности </th> <th> Преимущества </th> <th> Недостатки и риски </th> <th> Кому подходит </th> </tr> <tr> <td> <p>Использование типового функционала ERP</p> </td> <td> <p>Выделение брака через:</p> <p> 1. Карточки номенклатуры с градациями «новый», «не годен», «ограниченно годен». </p> <p>2. Серии с соответствующими свойствами «не годен», «ограниченно годен» и т. д.</p> <p>3. Размещения не проверенной либо не годной номенклатуры на выделенном складе.</p> <p>4. Комбинации способов между собой.</p> </td> <td> <p>1. Минимальные затраты на внедрение.</p> <p>2. Полная поддержка и обновления от вендора.</p> </td> <td> <p>1. Настройка существующего функционала для входного контроля.</p> <p>2. Ограниченная гибкость и скудная отчетность.</p> <p>3. Риск «обхода» процедур пользователями (например, списание не проверенного сырья).</p> </td> <td> <p>Предприятия с простыми процессами контроля, где достаточно базовой фиксации брака и выполнения контрольных операций.</p> </td> </tr> <tr> <td> <p>Специализированный лабораторный модуль, интегрированный с ERP</p> </td> <td> <p>Полный цикл: от заявки на испытания и регистрации проб до формирования протоколов и передачи результатов в отчет.</p> <p>Включает управление оборудованием, реактивами, контрольные карты. </p> </td> <td> <p>1. Глубокая и бесшовная интеграция (единая среда, обмен данными).</p> <p>2. Снижение человеческого фактора, автоматический сбор данных с приборов.</p> <p>3. Готовые отчеты для регуляторов, соответствие требованиям стандартов (ISO 17025, GxP).</p> </td> <td> <p>1. Стоимость лицензий и внедрения выше, чем у типового функционала.</p> <p>2. Избыточность, если на предприятии нет развернутой лабораторной службы.</p> </td> <td> <p>Производственные предприятия с аккредитованной или сильной внутренней лабораторией, где качество напрямую зависит от результатов испытаний (пищевая, химическая, фармацевтическая промышленность).</p> </td> </tr> <tr> <td> <p>Отраслевые решения</p> </td> <td> <p>Специализированные конфигурации или модули, расширяющие ERP под нужды конкретной отрасли.</p> <p>Учитывают отраслевую специфику, нормативную базу и типовые методики контроля.</p> </td> <td> <p>1. Быстрое внедрение — многие процессы и справочники уже настроены.</p> <p>2. Учет уникальных требований отрасли (температура, соматические клетки, микробиология и т. д.).</p> </td> <td> <p>1. Ориентация на конкретную отрасль — минус для диверсифицированных производств.</p> <p>2. Зависимость от вендора решения и его политики обновлений.</p> </td> <td> <p>Предприятия четко определенной отрасли (молочной, нефтегазовой и др.), стремящиеся к быстрому получению «коробочного» решения.</p> </td> </tr> <tr> <td> <p>Комплексная система собственной разработки</p> </td> <td> <p>Модуль управления качеством, разработанный с нуля или на основе платформы, включающий: журнал лабораторных испытаний, учет несоответствий с корректирующими действиями, блокировку отгрузки брака, отчеты по качеству выпуска.</p> </td> <td> <p>1. Максимальная гибкость и полное соответствие любым требованиям.</p> <p>2. Создание уникальных конкурентных преимуществ.</p> </td> <td> <p>1. Высокая стоимость и длительные сроки разработки/ внедрения.</p> <p>2. При большом количестве требований — усложнение долгосрочной поддержки. Для снижения нагрузки при обновлениях могут использоваться расширения и/или отдельные АРМ.</p> </td> <td> <p>Крупные компании с эксклюзивными процессами и значительным бюджетом, для которых качество — ключевой стратегический фактор.</p> </td> </tr> </tbody> </table> </div> <h2>Подведем итоги: что важно учесть</h2> <p>Выбор оптимального пути автоматизации контроля качества в ERP — это стратегическое решение, которое должно базироваться на тщательном анализе текущих и будущих потребностей бизнеса.</p> <ul> <li><strong> Начните с анализа типового функционала.</strong> Прежде чем инвестировать, детально изучите стандартные возможности вашей ERP в части управления качеством. Во многих случаях грамотной настройки может оказаться достаточно.</li> <li><strong> Рассмотрите готовые решения перед заказом разработки.</strong> Если типовых функций не хватает, следующим шагом становится выбор готового решения под задачи предприятия. Здесь важно разделять разные уровни автоматизации. Специализированный лабораторный модуль подходит для учета и контроля внутри лаборатории, где выполняются измерения и испытания. Если же требуется выстроить учет и управление процессами на уровне всего предприятия, подойдет отраслевое решение, которое при необходимости может включать и лабораторный контур. Как правило, такие продукты внедряются быстрее и обходятся дешевле, чем индивидуальная разработка, а их поддержка при обновлениях более предсказуема.</li> <li><strong> Доработки — для уникальных процессов.</strong> К кастомизации стоит прибегать, когда ни стандартный, ни готовый функционал не может закрыть специфическую задачу компании. Ключевой критерий успеха здесь — выбор надежной, сертифицированной команды разработчиков, которая использует безопасные методы (например, расширения без изменения ядра) и следует профессиональному процессу внедрения.</li> <li><strong> Делайте ставку на интеграцию</strong>. Эффективная система качества — это не изолированный модуль, а часть единого информационного контура предприятия. Решения, обеспечивающие бесшовный поток данных между производством, лабораторией, складом и бухгалтерией, приносят наибольшую ценность, ликвидируя «информационные острова» и ручной ввод данных.</li> </ul> <p>#IMAGE_234950#</p> Управление качеством — один из самых болезненных процессов на любом производственном предприятии. Его … article Иван Герасимчук, бизнес-аналитик ООО “Индустрия Информатики” (бренд ГЭНДАЛЬФ) https://www.itweek.ru/themes/detail.php?ID=234948 Wed, 03 Jun 2026 16:23:31 +0300 <p>Департамент информационных технологий города Москвы представил обзор Open Source в России, подготовленный совместно с отраслевой площадкой ICT.Moscow. В нем собраны и проанализированы оценки, исследования и публикации, касающиеся отечественной индустрии за последние годы.</p> <p>Исследование рассматривает роль российского сегмента разработки открытого кода на мировой арене, описывает ключевые группы участников сообщества и особенности локального развития этого направления.</p> <p>Авторы также ретроспективно изучили программы и инициативы, создаваемые в разное время для открытого кода в стране. Отдельно приводятся мнения о прогнозах, барьерах и аспектах, стимулирующих интерес к этому направлению у его участников.</p> <p>«При формировании долгосрочной стратегии развития экосистемы „МосТех“ и входящей в нее платформы для разработчиков „Мос.Хаб“ нам очень важно иметь четкое представление о специфике внутреннего рынка, который прошел через разные этапы в последние годы, а также о реальных барьерах и мотиваторах российского сообщества Open Source. Все это позволяет опираться на подлинные данные, учитывать разные взгляды и подходы. При этом Open Source имеет все шансы стать естественной частью разработки в России», — рассказал Алексей Анисимов, заместитель руководителя Департамента информационных технологий города Москвы.</p> <p>В основе документа — наиболее заметные оценки, исследования и публикации о рынке открытого исходного кода с 2023 года. Такой подход позволяет составить панорамное представление о текущем состоянии и перспективах Open Source.</p> <p>«Несмотря на то, что при анализе мировых технологических трендов этого года не прослеживается какой-то особый интерес авторов к теме Open Source, его роль может быть сильно недооценена. Многие эксперты сходятся в том, что синергия искусственного интеллекта и открытого программного кода способна оказать существенное влияние на ИТ. В последнее время в России мы наблюдаем исследования, которые освещают Open Source скорее фрагментарно, поэтому есть необходимость посмотреть на тему с разных сторон», — пояснили представители аналитического хаба ICT.Moscow.</p> <p>Обзор Open Source в России можно изучить по <a href="https://ict.moscow/analytics/open-source-2026/">ссылке</a>.</p> Департамент информационных технологий города Москвы представил обзор Open Source в России, подготовленный совместно … message https://www.itweek.ru/themes/detail.php?ID=234946 Wed, 03 Jun 2026 13:00:01 +0300 <p>Компания BSS и Центр развития перспективных технологий (ЦРПТ) стали победителями престижной Премии в области искусственного интеллекта AI-Олимп в номинации «Решение года», категория «Голосовые помощники». Награждение состоялось 27 мая в центре событий РБК Москва в рамках форума «Время Цифры».</p> <p>Проект, реализованный в партнёрстве с системным интегратором ITFB Group, признан эталонным примером внедрения коммуникативного ИИ в условиях высокой регуляторной нагрузки и масштабных пользовательских потоков.</p> <p>«Уникальность этого проекта — не только в передовых технологиях, но и в способности интегрировать их в жесткий контур государственной системы с высочайшими требованиями к надежности и безопасности. Как системный интегратор, мы обеспечили бесшовную связку ИИ-решений BSS с действующей инфраструктурой „Честного знака“, где цена ошибки критически высока. Именно глубокое понимание отраслевой специфики и регуляторных ограничений позволило нам создать отказоустойчивый инструмент, который уже сегодня работает на стыке технологий, закона и многомиллионной пользовательской базы», — прокомментировала Наталья Романова, директор по развитию бизнеса ITFB Group.</p> <p>Система маркировки «Честный знак» — одна из ключевых инфраструктур цифровой экономики России. Ежедневно в контакт-центр системы поступает около 10 000 обращений от более чем 1 млн зарегистрированных участников, включая представителей бизнеса и 38 млн пользователей мобильного приложения Честный ЗНАК. Поддержка охватывает более 50 товарных групп, в которых уже запущены обязательные требования или идет добровольный и бесплатный эксперимент — операторы должны одновременно разбираться в технических нюансах маркировки и юридических требованиях законодательства.</p> <p>«Задача нашего контактного центра — предоставлять точные ответы в кратчайшие сроки. Помимо линии техподдержки, которая работает в режиме 24/7, в постоянном контакте с бизнесом остаются команды всех маркируемых товарных групп, включая их руководителей. Кроме того, регулярно проводим для предпринимателей обучающие вебинары, рабочие группы, публикуем справочные материалы и инструкции на нашем портале. Главная цель — понятность и простота работы с маркировкой с полным доверием системе», — отметил руководитель клиентского сервиса ЦРПТ Илья Грознов.</p> <p>Для решения этой задачи было внедрено комплексное решение на базе ИИ-платформы BSS, включающее:</p> <ul> <li>речевую аналитику для автоматического анализа 100% звонков;</li> <li>голосового робота для первичной маршрутизации и сбора данных;</li> <li>Copilot для операторов с интеграцией в CRM и базой знаний;</li> <li><nobr>LLM-модули</nobr> для семантического анализа сложных диалогов.</li> </ul> <p>Реализованный проект вывел ключевые показатели контакт-центра на новый уровень. Вероятность обнаружения «проблемных» диалогов выросла с 2,5% до 100%, доля диалогов со словами-паразитами снизилась в шесть раз, а показатель First Call Resolution превысил 80%. Производительность контролёров качества увеличилась на 20%.</p> <p>«Мы не просто автоматизировали процессы — мы создали обучающуюся экосистему, которая постоянно адаптируется под изменения в законодательстве и поведении пользователей. Уникальность проекта в том, что нам удалось объединить речевую аналитику, голосового робота и <nobr>LLM-модели</nobr> в единый контур без усложнения ИТ-инфраструктуры», — прокомментировала Оксана Станевич, представитель компании BSS.</p> <p>Ранее проект уже получил публичное признание: по итогам 2025 года команда контакт-центра «Честного знака» стала лауреатом отраслевой премии CCGuru Awards «Хрустальная Гарнитура» в номинации «Лучшая работа с обратной связью, жалобами и претензиями». Также проект выдвинут на конкурс «Проект года» Global CIO.</p> <p>Для BSS это не первая победа в области ИИ-решений: компания неоднократно становилась лауреатом Национальной банковской премии, FINAWARD, Fintech Awards и других отраслевых наград, подтверждая статус технологического лидера в сегменте коммуникативного ИИ.</p> Компания BSS и Центр развития перспективных технологий (ЦРПТ) стали победителями престижной Премии в области … message https://www.itweek.ru/themes/detail.php?ID=234944 Wed, 03 Jun 2026 09:12:05 +0300 <p>DevRel-специалист говорит на одном языке с разработчиками и клиентами, разбирается в коде и выступает лицом компании. Рассмотрим, какие навыки нужны для этой работы, и почему техподдержка — один из самых подходящих бэкграундов для профессии.</p> <h3>Кто такой DevRel и что он делает</h3> <p>Слово DevRel — это сокращение от Developer Relations и переводится как «отношения с разработчиками». Должность объединяет обязанности из областей PR, маркетинга и технологий.</p> <p>Классический DevRel-специалист занимается популяризацией компании с технологической стороны. Это значит выступать на конференциях, писать статьи, рассказывать людям с разным опытом о том, чем занимается компания и как её продукты полезны потенциальным клиентам.</p> <p>Ещё DevRel часто помогает внутренней и внешней командам разработки синхронизироваться по рабочим вопросам и находить решения. Это может выглядеть так: внешняя команда программистов работает с технологиями компании и находит ошибку в одной из частей системы. Они приходят с этой ошибкой к DevRel, а ему нужно передать проблему внутренней команде, но при этом помочь разобраться и объяснить, что именно не так. Поэтому DevRel должен тоже работать с кодом: поискать проблему, протестировать сценарии работы, попробовать отладить и посмотреть на результаты. И уже с более полной картиной прийти к внутренним программистам компании.</p> <p>Главная и основная задача — это популяризация бренда. Если люди ассоциируют компанию с определённым техническим специалистом, и это создаёт бизнесу хороший имидж, значит, DevRel работает успешно.</p> <h3>Откуда приходят в DevRel и почему нужен технический бэкграунд</h3> <p>В российских компаниях DevRel сегодня чаще всего появляется внутри компании, когда кто-то из специалистов нарабатывает достаточный набор навыков и переходит на новую должность. Реже в DevRel нанимают людей со стороны: с 2021 по 2025 годы на hh.ru количество вакансий оставалось на уровне <nobr>30-50 позиций.</nobr></p> <p>Люди приходят в эту специальность из очень разных сфер: технической поддержки, разработки, тестирования, аналитики. Важно развить достаточный уровень инженерной экспертизы и опыта. Классический DevRel не может быть без технического бэкграунда, потому что нужно понимать не только клиентов и партнёров, но и разработчиков.</p> <p>В отличие от мидлов и сеньоров в программировании, DevRel может не иметь коммерческого опыта разработки. Для опытного инженера коммерческий опыт служит доказательством, что он умеет работать с реальным продуктом и отвечать за код в рабочих условиях. Для DevRel такой опыт в разработке полезен, но не всегда обязателен, потому что его основная ценность в понимании технического контекста, коммуникации и переводе между разными участниками процесса.</p> <h3>Какие софт-скиллы нужны DevRel</h3> <p>Важно правильно доносить мысли и уметь работать в команде. Переводить мысль на разные языки — возможно, главный навык хорошего DevRel-специалиста. Он должен не просто понимать техническую часть, а уметь превратить это понимание в коммуникацию, которая помогает людям решить задачу.</p> <p>Другое важное умение — организованность. Чаще всего DevRel решает задачи не один, а в контакте с другими сотрудниками. Нужно координировать разные команды и людей: прийти к внутренней команде, договориться о приоритете, получить ответ, вернуться к внешним разработчикам и объяснить, что изменилось. Может понадобиться провести встречу, презентацию, обучение.</p> <p>Спокойствие и конфликтоустойчивость тоже важны. DevRel работает в том числе с людьми, у которых что-то не получается. А когда у людей что-то не получается, они не всегда формулируют проблему спокойно и корректно.</p> <p>Большой опыт публичных выступлений нужен не всегда, потому что обязанности DevRel в разных компаниях сильно отличаются друг от друга. Но ответственность за публичное слово всё равно нужно уметь нести.</p> <h3>Почему опыт техподдержки особенно хорошо подходит</h3> <p>Работа в технической поддержке — один из самых релевантных опытов для DevRel-позиции. Эти две профессии похожи, потому что в поддержке специалист тоже является посредником: между клиентом и своей командой разработки. Поэтому человек быстро учится понимать проблемы обеих сторон и решить их так, чтобы по возможности все были в выигрыше.</p> <p>В техподдержке развивается и другой важный навык: умение переводить с технического языка на нетехнический и обратно. В компанию может написать программист, у которого не работает интеграция между приложениями, а может и обычный пользователь, который не видит нужную кнопку. В обоих случаях нужно понять, что стоит за обращением или за проблемой, найти техническую причину, иногда вместе с командой разработки, и всё исправить.</p> <p>Коммуникацию нужно уметь поддерживать и между инженерами: у программистов нет какого-то универсального технического языка, у каждого может быть своё видение, опыт и стек технологий. Из-за этих отличий и DevRel-специалист, и сотрудник поддержки должны уметь построить диалог между разными разработчиками.</p> <p>У DevRel и техподдержки есть пересекающиеся задачи. Например, написать документацию по части сервиса для внешних команд партнёров или подрядчиков. Если DevRel-специалист до этого работал в поддержке, он уже погружён в продукт, разбирался в устройстве или даже знает, как работает код нужной части системы. Тогда задачу можно выполнить, не подключая команду разработки.</p> <h3>Что нужно развивать дополнительно</h3> <p>Это не значит, что после <nobr>2-3</nobr> лет работы в техподдержке специалист становится полностью готовым к DevRel. Один из главных навыков, который нужно поменять — мышление. Например, поддержка работает с запросами локально: задача специалистов в том, чтобы решить запрос и не думать, с чем он может быть связан. DevRel должен мыслить более глобально и мыслить стратегически: как влияет эта проблема на работу компании? Нужно ли её исправлять, улучшать или изменять другим путём? Какие риски могут быть связаны с работой над конкретной задачей?</p> <p>Полезного DevRel-специалиста отличает умение доходить до источника проблемы. Поэтому любопытство и желание досконально разобраться тоже нужно развивать. Это не совсем хард-скилл и не совсем софт-скилл. Скорее рабочая привычка: не останавливаться на статусе «работает» или «не работает», а найти первопричину.</p> <h3>Стоит ли DevRel специально идти в поддержку</h3> <p>Это вопрос, который каждый решает для себя самостоятельно, но у работы в техподдержке много плюсов для будущего DevRel.</p> <p>Главное — это опыт, который сложно получить где-то ещё. Если начинать с разработки или тестирования, скорее всего нужно будет работать с отдельными модулями и компонентами. В техподдержке нужно знать всё, пусть и не на таком же глубоком уровне. Но для работы в поддержке тоже важно иметь нужные качества: желание помогать людям, техническая база и достаточный уровень эмпатии.</p> <p>#IMAGE_234945#</p> DevRel-специалист говорит на одном языке с разработчиками и клиентами, разбирается в коде и выступает … article Владимир Верхотуров, тимлид отдела “Продуктовый DevRel” компании ”Битрикс24” https://www.itweek.ru/themes/detail.php?ID=234942 Wed, 03 Jun 2026 08:58:19 +0300 <p><em>То, как сегодня агентный искусственный интеллект используется в разработке ПО, является предвестником более широких изменений в модели разработки, пишут в корпоративном блоге партнеры McKinsey Джаред Мун и Адам Теллуолл (Лондон), Рори Уолш (Дублин) и Вито Ди Лео (Цюрих).</em></p> <p>В 9:00 утра владелец продукта заходит в систему, чтобы проверить прогресс, достигнутый ее командой за ночь. Она видит, что функция перешла от структурированных требований к протестированному коду. Отмечены граничные случаи. Она отмечает, что архитектурные зависимости проверены. Краткое резюме описывает компромиссы и нерешенные вопросы.</p> <p>Никто не работал допоздна. Работали агенты ИИ.</p> <p>К середине утра команда проверяет результаты, уточняет контрольные точки и пересматривает приоритеты бэклога. К вечеру следующие структурированные входные данные ставятся в очередь для работы агентов ИИ в течение очередного ночного цикла.</p> <p>Эта <nobr>24-часовая</nobr> модель работы больше не является теоретической. Ведущие организации уже перестраивают процесс разработки, ориентируясь на почти непрерывное выполнение. Модель разработки ПО быстро развивается, и многие компании уже видят, как она обеспечивает трех-пятикратное повышение производительности при сокращении численности команды на 60%. Организации добиваются этих результатов не просто за счет внедрения агентов ИИ, а за счет перестройки операционной модели таким образом, чтобы люди и агенты могли сотрудничать 24 часа в сутки.</p> <h3><nobr>24-часовой</nobr> спринт: проектирование для непрерывной производительности</h3> <p>Ведущие компании переходят к модели ежедневного спринта, которая сочетает в себе человеческое суждение с ночным выполнением задач агентами — значительное сокращение типичных двухнедельных циклов спринта. В течение дня люди сосредотачиваются на проверке результатов, разрешении неясностей, укреплении архитектурных ограничений и согласовании с заинтересованными сторонами. Всё чаще их роль сводится не столько к созданию артефактов, сколько к надзору и совершенствованию системы, которая их создаёт.</p> <p>Ночью агенты выполняют структурированную работу в масштабе. Их задачи включают в себя обогащение требований, проверку архитектуры, генерацию и тестирование кода, а также упаковку результатов для проверки.</p> <p>Эта модель работает только при наличии нескольких практических основ. Во-первых, у бизнеса должно быть чёткое видение того, что нужно построить (это может быть дорожная карта продукта или стандарт, на основе которого будет строиться), чтобы они могли оценивать требования, сгенерированные агентами, на предмет качества и соответствия этому видению.</p> <p>Затем базовая технологическая среда должна быть стандартной и согласованной (например, с использованием общих фреймворков и модульных архитектур), чтобы решения могли масштабироваться, а компоненты могли повторно использоваться, а не изобретаться заново каждый раз.</p> <p>В-третьих, путь от требований к коду должен следовать стандартной структуре, чтобы агенты могли надёжно интерпретировать входные данные и получать предсказуемые результаты в разных проектах.</p> <p>И в-четвёртых, одни и те же ключевые заинтересованные стороны должны оставаться вовлеченными на протяжении всего потока создания ценности, чтобы избежать несогласованности и постоянных переделок.</p> <p>Без такого уровня согласованности и ясности результаты работы агентов будут фрагментированными, и им будет трудно доверять.</p> <p>Главный вывод: непрерывная <nobr>24-часовая</nobr> доставка достижима, но только при наличии архитектурной дисциплины и стандартизированных рабочих процессов, чтобы агенты могли надежно работать в масштабе.</p> <h3>Расширьте автоматизацию, чтобы исключить передачу задач от человека к человеку</h3> <p>Традиционная автоматизация непрерывной интеграции и непрерывной доставки (CI/CD) в значительной степени сосредоточена на тестировании и развертывании. Хотя затраты на это варьируются, наш опыт показывает, что они могут составлять до 30% от общих затрат на технологии. Бóльшая часть усилий, сосредоточенных на требованиях и кодировании, остается ручной и требует интенсивной интерпретации. Именно здесь накапливаются трения, и ценность достигает плато.</p> <p>В большинстве организаций требования, стандарты, архитектурные спецификации и пользовательские истории существуют в разрозненных документах и ​​инструментах. Каждый переход вносит неоднозначность. Люди многократно переводят намерения из одного артефакта в другой.</p> <p>#IMAGE_234943#</p> <p>Агентная модель устраняет эти трения, структурируя артефакты для передачи задач от машины к машине. Функциональные описания, нефункциональные требования, ограничения, диаграммы последовательностей и репозитории кодифицируются в стандартизированных, машиночитаемых форматах. В результате конвейер может выполняться от начала до конца за несколько часов, при этом вмешательство человека происходит только на определенных этапах проверки, а не в качестве посредника.</p> <p>Главный вывод: масштабирование ИИ требует применения инженерных методов к самой системе разработки, что делает процесс повторяемым и автоматизирует передачу задач.</p> <h3>Создание инфраструктуры знаний для обеспечения автономности агентов</h3> <p>Для получения точных результатов фабрикам агентов необходимы организационный контекст и память. Ведущие компании создают графы знаний, которые функционируют как слой памяти ИИ на протяжении всего жизненного цикла разработки ПО (SDLC) для каждой области. Эти графы связывают элементы, которые агенты должны понимать, такие как отзывы клиентов, архитектурные решения, проектная документация, заявки, активность в GitHub, отчеты об инцидентах и ​​обобщенные правила соответствия нормативным требованиям. В результате получается семантически связанная система (то есть, способ для агентов понимать значение данных, чтобы лучше выполнять свои задачи).</p> <p>Такое влияние является преобразующим. На вопросы, которые раньше требовали недель интервью с многочисленными экспертами в предметной области, агент-«библиотекарь» может ответить за минуты, используя структурированную институциональную память. Каждое решение становится отслеживаемым. Если заинтересованная сторона спрашивает, почему функция была отложена, ответ может быть напрямую связан с источником, например, данными опросов клиентов или аналитикой использования. Неявные знания, накопленные в рамках сообщества, становятся явными и объяснимыми, сокращая время адаптации для новых членов команды и укрепляя управление.</p> <p>Важно отметить, что это не должно начинаться с масштабной, нисходящей разработки онтологии. Граф должен органично развиваться вокруг приоритетных областей и действующих программ, накапливая ценность с течением времени. По мере масштабирования знания становятся производственной инфраструктурой, а не статической документацией, и устойчивым источником конкурентного преимущества.</p> <p>Главный вывод: структурированные, взаимосвязанные знания — это основа автономии агентов. Рассматривайте свою архитектуру знаний как стратегическую инфраструктуру.</p> <h3>Получение выгоды: изменение размеров команд и перепроектирование портфеля</h3> <p>Агентный SDLC может существенно повысить производительность, поскольку теперь меньшие команды могут выполнять бóльшие объемы работы. Первые внедрения показывают, что большие команды из <nobr>8-12</nobr> штатных сотрудников могут уступить место меньшим группам высококвалифицированных специалистов, контролирующих выполнение задач с помощью агентов. Результатами являются сокращение сроков и снижение затрат или увеличение производительности.</p> <p>Для получения выгоды организациям следует сосредоточиться на трех приоритетах. Во-первых, это переквалификация персонала. В то время как центральной команде необходимы навыки для разработки и поддержки фабрик агентов (обеспечение стандартизации и соответствия нормативным требованиям, внедрение передовых методов и т. д.), инженерам-программистам по всей организации необходимо развивать навыки принятия решений, код-ревью и управления агентами, с которыми они работают. Роли смещаются от ручной координации и тестирования к обеспечению согласованности архитектуры, моделированию предметной области и управлению ИИ.</p> <p>Во-вторых, необходимо обеспечить участие в агентной разработке всех «внешних» звеньев — специалистов по поддержке и соблюдению нормативных требований в отделах рисков, юриспруденции, тестирования и закупок. Без этого ускоренный SDLC не приведет к ускорению прогресса. Агенты и автоматизация (например, с помощью политики как кода) могут помочь гарантировать, что эти механизмы контроля не станут узкими местами, одновременно повышая качество, согласованность, полноту и отслеживаемость. Эти механизмы контроля должны быть заложены в основу проекта, а не становиться препятствием в конце процесса.</p> <p>И третье — это перепроектирование распределения ресурсов таким образом, чтобы повышение производительности приводило к созданию новой ценности. Освобожденные ресурсы часто реинвестируются для ускорения реализации дорожных карт, модернизации платформ или запуска новых продуктов.</p> <p>Главный вывод: повышение производительности может быть преобразовано в структурные изменения портфеля. Измените размер команд и сознательно перераспределите ресурсы, чтобы получить максимальную выгоду.</p> <p>Трансформация должна начинаться там, где ее влияние наиболее велико. В большинстве технологических организаций бóльшая часть общих расходов приходится на небольшое количество крупных программ. Целенаправленное выполнение этих инициатив — будь то модернизация унаследованных систем, переделка существующих объектов или запуск новых продуктов — максимизирует видимый эффект и ускоряет обучение.</p> <p>Если агенты возьмут на себя выполнение задач в масштабе и будут создавать надежный и стабильно безопасный код, роль человека будет концентрироваться в архитектуре, оценке продукта и проектировании систем, что сделает институциональные знания и техническую согласованность решающими факторами дифференциации. Организации, которые начнут развивать эти возможности в рамках более широких усилий по перестройке своей операционной модели, не просто будут двигаться быстрее; они переосмыслят то, как ПО создает ценность.</p> То, как сегодня агентный искусственный интеллект используется в разработке ПО, является предвестником более широких … article https://www.itweek.ru/themes/detail.php?ID=234940 Tue, 02 Jun 2026 16:12:14 +0300 <p>Axiom JDK объявила о выпуске Axiom Trusted Images — линейки доверенных контейнерных образов для разработки и промышленной эксплуатации приложений в Kubernetes и cloud-native инфраструктуре. Впервые продукт был представлен 2 июня в Москве на конференции «БеКон», посвященной безопасному использованию контейнеров и контейнерных сред.</p> <p>Новый продукт помогает компаниям снизить риски безопасности в контейнерной инфраструктуре и ускорить вывод цифровых сервисов в промышленную эксплуатацию. Axiom Trusted Images предоставляют проверенный базовый слой контейнеров вместо разрозненных публичных образов с непрозрачным составом, лишними компонентами и уязвимостями, которые требуют дополнительного анализа со стороны ИБ, DevOps и разработки.</p> <p>Выпуск Axiom Trusted Images стал развитием продуктовой экосистемы Axiom JDK. Исторически компания решает задачи безопасной эксплуатации Java-приложений. Но современные корпоративные системы состоят из разных технологических компонентов: NGINX, Node.js, Go, C, C++, специализированных runtime-сред и контейнерной инфраструктуры. Каждый из этих компонентов становится частью контура промышленной эксплуатации, поэтому бизнесу нужен единый подход к безопасности базовых контейнерных образов независимо от языка разработки и типа сервиса.</p> <p>Axiom Trusted Images помогают компаниям получить несколько ключевых бизнес-преимуществ:</p> <ul> <li>снизить поверхность атаки за счёт минимального состава контейнерных образов и вариантов поставки под разные сценарии: shell, distroless, rootless;</li> <li>сократить количество CVE в базовом слое за счёт удаления лишних компонентов, постоянного мониторинга и регулярного обновления образов;</li> <li>упростить подготовку к требованиям ИБ, регуляторов и внутреннего аудита благодаря SBOM, цифровой подписи и подтверждённому происхождению образов;</li> <li>ускорить прохождение проверок безопасности перед запуском продуктов за счёт прозрачного состава, фиксированных версий и понятного процесса устранения уязвимостей;</li> <li>высвободить время разработчиков, DevOps и платформенных команд, которые вместо ручного сопровождения базовых образов могут сосредоточиться на запуске новых сервисов;</li> <li>стандартизировать контейнерный слой для разных команд и технологических стеков за счёт готовых доверенных образов для NGINX, Node.js, Go, C, C++ и других сценариев.</li> </ul> <p>«Контейнеры ускорили разработку и сделали доставку приложений в эксплуатацию более гибкой, но одновременно усложнили контроль того, что именно попадает в промышленную среду. Для бизнеса это уже не только технический вопрос, но и вопрос скорости релизов, управляемости рисков и готовности к аудиту. Axiom Trusted Images позволяют сделать базовый контейнерный слой прозрачным, минимальным и сопровождаемым, чтобы команды могли быстрее выводить новые продукты на рынок без компромиссов по безопасности», — отметил Роман Карпов, генеральный директор Axiom JDK.</p> <p>В состав линейки входят доверенные образы для разных технологических стеков, включая NGINX, Node.js, Go, C, C++. Для Java-сценариев в экосистеме Axiom JDK доступен отдельный продукт — Axiom Runtime Container Pro, предназначенный для экономичного и безопасного запуска Java-приложений в контейнерной среде.</p> <p>Основа Axiom Trusted Images — Axiom Linux, специализированный лёгкий дистрибутив для контейнеров, который поставляется в вариантах musl и glibc. Он используется как компактный базовый слой для защищённых образов под разные технологические стеки.</p> <p>Решение поддерживает платформы x86_64 и ARM64, а также развёртывание на российских Linux-дистрибутивах и Kubernetes-платформах. Axiom Trusted Images можно использовать как замену стандартных базовых образов: обычно для подключения достаточно изменить ссылку на базовый образ в Dockerfile.</p> <p>Axiom JDK регулярно проверяет представляемые образы на известные уязвимости и устраняет их в рамках SLA. Это делает работу с CVE более предсказуемой и снижает нагрузку на команды эксплуатации.</p> <p>Актуальность решения подтверждается ростом внимания к безопасности контейнеров и DevSecOps-практикам. По данным State of DevOps Russia 2025, 46,8% респондентов уже используют сканеры уязвимостей контейнерных образов, а 35,6% — анализаторы конфигураций Kubernetes. При этом внедрение ИБ-инструментов остаётся сложной задачей: 45,5% участников отмечают нехватку технической экспертизы, 42,2% — проблемы совместимости, а 26,8% признают, что результаты проверок им непонятны. Для контейнерной инфраструктуры это особенно критично: недостаточно просто запустить сканирование образов, нужно интерпретировать CVE, понимать состав базового слоя, оценивать риски, пересобирать образы и готовить доказательную базу для ИБ и аудита. Такой процесс требует значительных ресурсов и отвлекает DevOps, ИБ и разработку от вывода новых продуктов на рынок.</p> <p>Axiom Trusted Images особенно актуальны для организаций, развивающих Kubernetes-платформы, микросервисную архитектуру, внутренние платформы разработки, а также для компаний с повышенными требованиями к информационной безопасности, аудиту и промышленной эксплуатации. </p> Axiom JDK объявила о выпуске Axiom Trusted Images — линейки доверенных контейнерных образов для разработки … message https://www.itweek.ru/themes/detail.php?ID=234939 Tue, 02 Jun 2026 16:09:48 +0300 <p>Yandex B2B Tech обновила ИИ-помощника для анализа и визуализации данных — Нейроаналитика. Агент стал умнее: теперь он не просто делает выводы по готовым дашбордам, а может напрямую обращаться к сырым корпоративным данным компании и самостоятельно создавать аналитические отчеты. Это позволит бизнесу ускорить и улучшить аналитику на базе искусственного интеллекта в организации. Обновленный ИИ-агент доступен всем пользователям в BI-системе Yandex DataLens.</p> <p>Раньше Нейроаналитик работал только с готовыми отчётами: пользователь заранее строил графики, а агент помогал в них разобраться — подсказывал формулы, находил инсайты. Теперь достаточно задать вопрос в свободной форме на естественном языке — агент сам найдёт нужные данные в корпоративном источнике и создаст подробные визуализации с выводами. Так, например, можно узнать, как менялась выручка конкретного менеджера в определённом городе за последний месяц. Нейроаналитик работает с корпоративными данными внутри DataLens в рамках прав доступа, которые настроены в системе для каждого пользователя.</p> <p>По данным отраслевых исследований, специалисты по работе с данными тратят до 20 часов в неделю на доступ, объединение и подготовку данных вместо непосредственного анализа. При этом 92% аналитиков предпочли бы заниматься другими задачами вместо подготовки данных, но 65% всё равно проводят за ней минимум половину рабочего времени. Нейроаналитик забирает эту нагрузку на себя: специалисты по данным могут сосредоточиться на более сложных задачах — определять ключевые вопросы, выбирать нужные разрезы и формулировать гипотезы — а бизнес-пользователи получают ответы быстро, без необходимости знать формулы или структуру данных.</p> <p>В Yandex DataLens появился виджет с готовыми подсказками от ИИ-помощника прямо на аналитическом дашборде. Теперь пользователю не нужно каждый раз писать сложные промпты к дашбордам и обновлять их, достаточно один раз дать агенту простую инструкцию на естественном языке. При каждом открытии дашборда агент анализирует нужные данные и показывает актуальный статус. Это удобно для сотрудников, которые не занимаются аналитикой профессионально: например, оператор склада без сложных промптов понимает, есть ли проблемы с текущими заказами.</p> <p>«Самый сложный момент в аналитике — это осмысление данных, время, которое порой уходит на то, чтобы предподготовить их и оформить в нужном представлении. Мы движемся к модели, в которой пользователь сможет работать с данными через единый интерфейс напрямую и быстро: задавать вопросы к анализу, получать предподготовленные данные и способы их визуализации моментально, оставляя механистичный труд Нейроаналитику», — рассказал технический директор Yandex Cloud Иван Пузыревский.</p> <p>В будущем у Нейроаналитика появится еще больше обновлений. В новых версиях агент сможет помогать пользователям искать нужные дашборды и отвечать на вопросы по работе с Yandex DataLens на основе документации сервиса и внутренней базы знаний компании.</p> Yandex B2B Tech обновила ИИ-помощника для анализа и визуализации данных — Нейроаналитика. Агент стал умнее: теперь … message https://www.itweek.ru/themes/detail.php?ID=234937 Tue, 02 Jun 2026 11:27:10 +0300 <p>Эксперты компании «Информзащита» зафиксировали рост активности атак на корпоративные учетные записи с использованием техники распыления паролей. По данным исследований компании, в 2026 году злоумышленники ежемесячно задействуют более 12000 уникальных spray IP, каждый из которых атакует не менее 10 учетных записей. По сравнению с концом 2025 года число таких IP увеличивается в среднем на 11% месяц к месяцу, а доля неуспешных попыток входа в корпоративные сервисы держится на уровне <nobr>28-30%.</nobr> Для бизнеса это означает, что атака на идентификационные данные фактически превратились в постоянный фоновый процесс: злоумышленники не ждут отдельного повода, а регулярно проверяют облачные сервисы, почтовые системы и удаленные рабочие контуры на слабые пароли и у компаний нет периодов, когда риск можно считать низким.</p> <p>Техника распыления паролей отличается от классического перебора тем, что атакующий не сосредотачивается на одной учетной записи. Вместо тысяч попыток входа к одному пользователю он берет ограниченный набор популярных, утекших или сгенерированных паролей и последовательно проверяет их на большом массиве сотрудников. Попытки распределяются по разным IP-адресам, странам, автономным системам и временным интервалам. В журналах безопасности такая активность выглядит как множество несвязанных между собой отказов, а не как очевидная брутфорс-атака. Именно поэтому простые правила блокировки по числу ошибок с одного адреса уже не дают нужного эффекта: при использовании только таких порогов распределенные атаки закономерно проходят мимо системы мониторинга и воспринимаются как «нормальный» фон.</p> <p>Рост таких атак связан с доступностью инфраструктуры. Атакующие используют облачные серверы, прокси-сети, скомпрометированные домашние маршрутизаторы, а также одноразовые узлы, которые быстро выводятся из кампании после попадания в списки блокировки. На практике один и тот же сценарий может одновременно затрагивать десятки организаций, но в каждой из них оставлять лишь слабый след. Отдельную роль играет качество парольных словарей, так как злоумышленники часто формируют их не только из открытых утечек, но и с учетом региональной лексики, названий компаний, корпоративных шаблонов и типовых правил сложности пароля. В результате снижается объем шума, но повышается шанс успешного входа.</p> <p>В 2026 году техника распыления паролей используется как первый этап цепочки. После успешной аутентификации атакующий проверяет почтовый ящик, создает правила пересылки, пытается получить доступ к файловым хранилищам, внутренним чатам и административным панелям. В ряде случаев за первичным входом следует попытка захвата сессии и изменения параметров MFA, затем — подключение сторонних приложений через OAuth или проверка устаревших протоколов, где многофакторная аутентификация работает неполноценно . По оценке «Информзащиты», доля инцидентов, в которых после распыления паролей фиксировались признаки дальнейшего движения по облачной среде, выросла с 18% в конце 2025 года до 27% в первом полугодии 2026 года, что говорит не только о росте количества атак, но и о большей «глубине» их развития внутри облачной инфраструктуры</p> <p>По отраслевой структуре чаще всего такие атаки затрагивают финансовые организации и страховые компании: на них приходится около 24% наблюдаемых случаев. ИТ-компании и сервисные провайдеры занимают 19%, ритейл и e-commerce — 17%, промышленность и логистика — 14%, профессиональные сервисы и консалтинг — 11%, образовательные организации — 8%, здравоохранение — 7%. У каждой отрасли свой фактор риска. В финансах атакующих привлекают платежные процессы и доступ к клиентским данным, в ИТ — возможность выйти на инфраструктуру заказчиков, в ритейле — высокая доля внешних сервисов и сезонные пики нагрузки, в промышленности — сложная сеть подрядчиков и удаленного доступа, что также говорит о том, что злоумышленники чаще переходят от проверки учетной записи к полноценному движению внутри облачной инфраструктуры.</p> <p>Разбивка по векторам атак показывает, что техника распыления паролей занимает около 38% попыток первичного доступа к корпоративным аккаунтам. На credential stuffing с использованием утекших баз приходится 24%, на атаки через устаревшие протоколы — 14%, на AiTM-фишинг и повторное использование токенов — 11%, на злоупотребление OAuth-разрешениями и device code flow — 7%, на MFA fatigue — 4%, на атаки через сервисные учетные записи, API-ключи и другие non-human identities — около 2%. Эти цифры показывают, что пароль остается удобной точкой входа, но сам инцидент почти всегда развивается шире: от проверки учетной записи до закрепления в почте, облаке или бизнес-приложении, поэтому фокус мониторинга только на этапе аутентификации уже недостаточен.</p> <p>Для снижения рисков компаниям в первую очередь следует отключать устаревшие протоколы там, где они не нужны бизнесу, вводить phishing-resistant MFA для привилегированных, финансовых и административных ролей, регулярно проверять корпоративные пароли на наличие в утечках и исключать повторное использование паролей между сервисами. Отдельного контроля требуют успешные входы после серии отказов, смена MFA-параметров, создание правил пересылки в почте, выдача OAuth-разрешений, входы с новых устройств и активность из нетипичных регионов. Простых блокировок по числу ошибок уже недостаточно: техника распыления паролей как раз рассчитана на обход таких порогов. Рабочая защита строится на корреляции событий, поведенческой аналитике, контроле сессий, инвентаризации сервисных учетных записей и быстрой проверке каждого успешного входа, которому предшествовала распределенная подозрительная активность. В противном случае атака так и останется в логах в виде набора несвязанных между собой «обычных» событий.</p> Эксперты компании «Информзащита» зафиксировали рост активности атак на корпоративные учетные записи с использованием … message https://www.itweek.ru/themes/detail.php?ID=234936 Tue, 02 Jun 2026 11:24:14 +0300 <p>Компания BSS и Федеральное государственное бюджетное образовательное учреждение высшего образования «Ижевский государственный технический университет имени М.Т. Калашникова» (ИжГТУ) заключили партнерское соглашение о сотрудничестве в сфере подготовки кадров для цифровой экономики.</p> <p>Партнерство направлено на интеграцию актуальных отраслевых знаний и практического опыта в образовательный процесс, а также на создание для студентов прямого пути к стажировкам и трудоустройству в технологической компании. Документ подписан в рамках исполнения требований постановления Правительства РФ и закрепляет долгосрочное взаимодействие вуза и ИТ-бизнеса.</p> <p>Взаимодействие сторон будет строиться на взаимовыгодных основах и конкретных обязательствах, нацеленных на практический измеримый результат. Сотрудничество сфокусируется на следующих направлениях:</p> <ol> <li>преподавание экспертов BSS в ИжГТУ. Специалисты компании — практики в области искусственного интеллекта, больших языковых моделей (LLM), технологии RAG и речевой аналитики — будут проводить лекции, практические занятия и мастер-классы для студентов ИжГТУ по ИТ-дисциплинам;</li> <li>стажировки и трудоустройство в BSS. Лучшие студенты получат возможность пройти стажировку в BSS с назначением персональных наставников и последующим рассмотрением кандидатур для трудоустройства;</li> <li>разработка образовательных программ. Эксперты BSS примут участие в актуализации рабочих программ дисциплин, программ практик и учебно-методических материалов, обеспечивая их соответствие актуальным требованиям рынка труда.</li> </ol> <p>«Для BSS образование — это стратегическая инвестиция в будущее отрасли. Мы видим высокий потенциал у студентов ИжГТУ и готовы делиться с ними экспертизой, накопленной за 30 лет разработки программного обеспечения и работы с крупнейшими предприятиями. Наши технологии — это не просто код, это решения, которые уже сегодня автоматизируют контакт-центры, улучшают клиентский опыт и трансформируют бизнес-процессы. Мы хотим, чтобы выпускники вуза приходили к работодателям с пониманием реальных задач и готовыми компетенциями», — отметил Георгий Кравченко, Генеральный директор BSS.</p> <p>Партнерство BSS, обладающей уникальной экспертизой, с ИжГТУ позволит студентам получить доступ к передовым технологиям ИИ, речевым платформам и современным инструментам по созданию ИИ-агентов и мультиагентных систем. Соглашение призвано способствовать укреплению связей между академическим сообществом и технологическим бизнесом, что критически важно для подготовки кадров для цифровой экономики.</p> <p>ИжГТУ имени М.Т. Калашникова — один из ведущих технических вузов Приволжского федерального округа, реализующий программы подготовки по IT-направлениям «Информационные системы и технологии», «Прикладная информатика», «Программная инженерия». Университет активно развивает цифровую образовательную среду и сотрудничает с индустриальными партнерами для обеспечения практической ориентированности обучения.</p> <p>«Цифровизация инженерного образования — наш приоритет. Партнерство с BSS открывает для студентов уникальную возможность работать с технологиями уровня enterprise, участвовать в реальных проектах и формировать портфолио еще до выпуска. Это именно тот формат „университет 4.0“, к которому мы стремимся», — подчеркнул заведующий кафедрой «Информационные системы» Максим Горохов, ответственный за взаимодействие с индустриальным партнером в лице BSS от ИжГТУ.</p> Компания BSS и Федеральное государственное бюджетное образовательное учреждение высшего образования «Ижевский … message https://www.itweek.ru/themes/detail.php?ID=234935 Tue, 02 Jun 2026 09:18:01 +0300 <p><em>В условиях роста сетевых заторов ИТ-командам необходимо сокращать дублирование инструментов, контролировать затраты и готовиться к AIOps и агентам искусственного интеллекта, пишет на портале </em><em>InformationWeek</em> <em>Мэри Шеклет, президент консалтинговой компании Transworld Data.</em></p> <p>Затор (logjam) определяется как «непреодолимое скопление или клубок логов», подобно тому, как бревна накапливаются в реке и перекрывают ее. В сети, которая сама по себе является рекой коммуникаций, сетевые сотрудники также сталкиваются со своего рода заторами.</p> <p>Они тонут в океане избыточных логов. Избыточное сетевое журналирование перегружает процессоры, переполняет память и сбивает с толку сетевых сотрудников, которые пытаются расшифровать, какие логи являются — и должны быть — пригодными для использования.</p> <p>Между тем, ежедневные заторы данных и рабочих процессов превращаются в более серьезную проблему, поскольку сетевые сотрудники стремятся объединить инструменты, которые стандартный сетевой мониторинг, наблюдаемость, AIOps и теперь агенты ИИ навязали им для мониторинга телеметрии и других сетевых событий на все более детальном уровне.</p> <p>Эти технологии пересекаются друг с другом, и дублирование приводит к неэффективному расходованию корпоративных ИТ-ресурсов. Как ИТ-службы могут контролировать затраты? И как сетевым сотрудникам избежать дублирования усилий, когда они все еще пытаются понять, какие инструменты следует использовать и для чего?</p> <h3>Понимание типов сетевых проблем, требующих решения</h3> <p>Современные ИТ-сети охватывают центральные ИТ-подразделения, периферийные узлы, облачные локации, а также удаленные домашние и полевые офисы. Стандартные инструменты мониторинга сети, которые до сих пор используются многими подразделениями, были разработаны для монолитных сетей, таких как единая корпоративная сеть масштаба предприятия. Они не могут справиться со сложностями гибридной сетевой топологии, выходящей за пределы предприятия.</p> <p>Подразделения это понимают, как и поставщики сетевого оборудования. И те, и другие видят необходимость обновления планов развития средств управления сетью, поскольку почти никто больше не работает с монолитными корпоративными сетями.</p> <p>Перед ними стоит вопрос: какие надлежащие инструменты и методологии следует обновить — и какие существующие инструменты можно исключить?</p> <h3>Навигация по инструментам</h3> <p>Существуют четыре категории инструментов мониторинга и предотвращения сбоев в сети:</p> <ol> <li><strong> Стандартный мониторинг сети. </strong>Стандартный мониторинг сети самодостаточен, поскольку это зрелая технология, и сотрудники хорошо с ней знакомы. Он использует метрики сетевого трафика, использования ЦП и ресурсов хранения, допустимых ошибок и времени отклика, но ИТ-специалисты должны предварительно определить эти метрики. Инструменты мониторинга выдают оповещения, когда происходит превышение этих предопределенных метрик, и затем задача ИТ-специалистов — найти и устранить проблемы.</li> <li><strong> Наблюдаемость. </strong>Стандартный мониторинг сети недостаточен, поскольку он сообщает только о том, что ИТ-специалисты предварительно для него определили. Наблюдаемость идет глубже. Она сообщает не только о нарушениях метрик, но и о том, где и почему произошло нарушение. Она предоставляет эту информацию, анализируя метрики, журналы и трассировки — и соответствующее ПО может делать это автономно. Это дает ИТ-специалистам преимущество в решении проблем.</li> <li><strong> AIOps. </strong>Цель AIOps — расширить возможности наблюдаемости за счет применения ИИ и автоматизации для решения проблем. Недостаток AIOps заключается в том, что при анализе данных эта методология имеет ограниченное представление о контексте сетевого события. Она даже не может определить, являются ли анализируемые телеметрические данные достоверными. Именно здесь по-прежнему должна вмешиваться ИТ-служба, поскольку для подтверждения достоверности результатов AIOps и применения исправлений требуются специалисты по сетям.</li> <li><strong> Сетевые ИИ-агенты.</strong> Новая волна инструментов в виде сетевых ИИ-агентов пытается еще больше автоматизировать решение проблем там, где есть необходимость вмешательства сетевого персонала. ИИ-агенты автоматически обнаруживают и устраняют проблемы. Они делают это, используя машинное обучение для изучения истории производительности сети, чтобы получить бизнес-контекст того, как сеть должна функционировать.</li> </ol> <h3>Пять лучших практик управления переходом</h3> <p>Переход от стандартного мониторинга сети к наблюдаемости, затем к AIOps, а затем к сетевым ИИ-агентам — это естественное развитие ПО для управления сетями. Компании и поставщики это понимают, поэтому была определена эволюционная дорожная карта управления сетями.</p> <p>Но прежде чем они смогут приступить к реализации этой дорожной карты с использованием новых технологий, компании должны оценить, на каком этапе пути они находятся с точки зрения инструментов, персонала, бизнес-требований и затрат. Вот пять лучших практик:</p> <p><strong>1. Оцените свой текущий набор инструментов. </strong>Для многих сотрудников ИТ-подразделений, занимающихся сетевыми технологиями, разбор используемых в настоящее время инструментов — и тех, которые были забыты и лежат на полке — является колоссальной задачей. Но сейчас самое время этим заняться.</p> <p>Инструменты управления сетью должны быть учтены во всех сетях предприятия, независимо от того, находятся ли сети локально в дата-центре, на периферии предприятия или в облаке.</p> <p>Инструменты должны быть классифицированы по функциям, чтобы исключить любые дублирования. Если разные инструменты используются для одних и тех же функций в разных местах сети, эти инструменты должны быть стандартизированы в единый набор инструментов. Это упростит работу персонала, уточнив, какие инструменты следует использовать и как проводить обучение.</p> <p><strong>2. Встретьтесь с поставщиками для оценки их планов развития.</strong> Часть процесса инвентаризации и оценки инструментов — это взаимодействие с поставщиками инструментов, чтобы узнать, в каком направлении они движутся со своими планами развития.</p> <p>План развития средств управления сетью ясен: от стандартного мониторинга сети к наблюдаемости, затем к AIOps и, наконец, к сетевым ИИ-агентам.</p> <p>Если у поставщиков эта эволюция не отражена в их планах, пора искать тех, у кого она отражена.</p> <p><strong>3. Займитесь повышением квалификации персонала по AIOps. </strong>Большинство сотрудников, занимающихся корпоративными сетями, хорошо владеют стандартным мониторингом и уже работают с наблюдаемостью.</p> <p>Следующий шаг — внедрение автоматизации в наблюдаемость с помощью AIOps, что все еще находится в процессе, поскольку требует перестройки и, в некоторых случаях, переосмысления рабочих процессов сети.</p> <p>Сетевые сотрудники должны изучить новые инструменты AIOps, а также способы интеграции дополнительной AIOps-автоматизации в рабочие процессы сети и повседневные операции.</p> <p>Эти изменения должны быть задокументированы, а документация — слабое место в сетевых операциях.</p> <p>Чтобы обеспечить соответствие оперативной документации изменениям в рабочих процессах, целесообразно привлечь внешних аудиторов для проверки документации и операций, чтобы выявить и исправить любые несоответствия.</p> <p><strong>4. Очень осторожно внедряйте агентов ИИ. </strong>Концепция полностью автоматизированных сетевых операций с использованием агентов ИИ пока остается скорее теорией, чем фактом.</p> <p>Тем не менее, некоторые организации уже пробуют свои силы в этом направлении.</p> <p>Сетевые агенты ИИ используют машинное обучение для изучения прошлой производительности сети, чтобы получить бизнес-контекст для своей автоматизации. Но у них нет практических знаний и опыта, которыми обладают сотрудники сетевой службы.</p> <p>Рекомендуется первоначально внедрять сетевых ИИ-агентов в хорошо предсказуемых и контролируемых сетях с низким риском изменений или аномалий.</p> <p><strong>5. Оцените ценность унаследованных технологий. </strong>Унаследованные технологии означают не только старость, но и проверенность, надежность и долговечность.</p> <p>Существуют инструменты управления сетью, которые выдержали испытание временем и продолжают хорошо работать.</p> <p>При анализе имеющихся инструментов организациям следует внимательно изучить, что продолжает приносить пользу. Безусловно, следует совершенствовать инструменты и навыки, но не стоит выбрасывать то, что по-прежнему хорошо работает.</p> В условиях роста сетевых заторов ИТ-командам необходимо сокращать дублирование инструментов, контролировать затраты … article https://www.itweek.ru/themes/detail.php?ID=234933 Tue, 02 Jun 2026 09:04:12 +0300 <p>Представьте типичную ситуацию: компания закупает корпоративный ИИ-инструмент, проводит обучение, запускает пилот. Через три месяца — <nobr>5-10%</nobr> активных пользователей, остальная команда возвращается к привычным инструментам. Формально внедрение состоялось, но реального эффекта нет.</p> <p>По данным McKinsey   Company, большинство компаний до сих пор не получают системного результата от внедрения ИИ, несмотря на рост инвестиций. И дело здесь не в качестве самих инструментов.</p> <p>Главная причина в другом: то, что принято называть «саботажем», на самом деле является рациональной реакцией системы на плохо выстроенное внедрение.</p> <p>Сотрудники не игнорируют ИИ — они выбирают способ работы, который дает предсказуемый результат и не создает дополнительных рисков. Чтобы понять это поведение, важно посмотреть не только на людей, но и на то, как именно компания внедряет изменения.</p> <h3>Саботаж — это не проблема сотрудников</h3> <p>В большинстве компаний саботаж объясняют через психологию: страх, нежелание меняться, сопротивление новому. На практике это поверхностное объяснение.</p> <p>Сотрудник не обязан использовать инструмент только потому, что он «внедрен». Он оценивает его с точки зрения своей ежедневной работы: ускоряет ли инструмент задачи, снижает ли риски ошибок, делает ли результат более предсказуемым.</p> <p>Если ответ отрицательный, отказ от использования — рациональный выбор.</p> <p>Поэтому не стоит считать саботаж сбоем в поведении людей. Это сигнал: система внедрения ИИ не создает достаточной ценности в реальной работе.</p> <h3>Почему люди не доверяют ИИ</h3> <p>Ключевая причина сопротивления кроется не в страхе как таковом — все дело в незнании. Человек не понимает, как новый инструмент работает, где допускает ошибки, можно ли ему доверять. В такой ситуации любое использование ИИ воспринимается как риск, и первое же закономерное желание, которое возникает у сотрудника — отказаться от него вовсе.</p> <p>Это универсальный механизм: люди боятся не технологий, а неопределенности. Чем лучше человек понимает систему, тем ниже уровень сопротивления. И наоборот — отсутствие понимания почти неизбежно приводит к отказу от использования.</p> <h3>Два типа сотрудников</h3> <p>После появления ИИ команды почти всегда делятся на две группы. Первая — любопытные. Они начинают экспериментировать, тестируют сценарии, адаптируют инструмент под свои задачи и быстро усиливают свою эффективность.</p> <p>Вторая — нелюбопытные. Они не пытаются разобраться, занимают позицию «докажите, что это работает» и в итоге выпадают из процесса.</p> <p>Это не вопрос квалификации — это вопрос поведения. И именно от соотношения этих двух групп во многом зависит успех внедрения. Если нелюбопытных сотрудников оказывается больше, внедрить новую технологию очень тяжело. Речь не только об ИИ — такие члены команды, как правило, не заинтересованы в любых изменениях.</p> <h3>Главный риск — не сотрудники, а руководство</h3> <p>Отдельный специалист в команде может не использовать ИИ. Система это переживет — и, более того, однажды просто «переварит» такого человека, потому что он закономерно будет отставать от остальных.</p> <p>Если же внедрению искусственного интеллекта сопротивляется руководитель, ситуация сразу осложняется. Он задает норму, от его действий не в последнюю очередь зависит, как быстро сотрудники освоят новую технологию. Когда руководитель сам не применяет ИИ в работе и не верит в него, инициативы будут блокироваться, а внедрение фактически остановится.</p> <p>Поэтому основная трудность — не сопротивляющиеся сотрудники, а отсутствие поддержки изменений на уровне управления.</p> <h3>Как проявляются психологические барьеры</h3> <p>Психологические барьеры сотрудников, которые стоят между ними и освоением ИИ, выражаются в виде поведенческих сигналов. Если научиться их распознавать, будет легко понять, что именно тревожит члена команды.</p> <ul> <li> Страх потери экспертизы. Сотрудники опасаются, что их знания обесценятся. Это снижает готовность делиться опытом и пробовать новые инструменты.</li> <li> Недоверие к качеству результатов. Разовые ошибки или галлюцинации быстро формируют устойчивое ощущение, что инструмент требует больше времени на проверку, чем дает выгоды.</li> <li> Страх контроля. Если непонятно, что логируется и как используется, сотрудники начинают избегать корпоративных инструментов.</li> <li> Усталость от изменений. Каждый новый инструмент требует времени на освоение. Без явной ценности он воспринимается как дополнительная нагрузка.</li> </ul> <p>Важно, что эти препятствия усиливаются, если компания не задает понятных правил и сценариев работы.</p> <h3>Организационные барьеры: где ломается система</h3> <p>Возможно, сотрудники готовы активно использовать ИИ, но система не дает им делать это эффективно. Можно выделить несколько основных трудностей:</p> <ul> <li> Нет владельца со стороны бизнеса. Типичная ситуация: «ИТ внедрило, бизнес не использует». Без бизнес-владельца инструмент не привязан к реальным задачам.</li> <li> Нет четких сценариев использования. Формулировка «давайте внедрим ИИ» не работает — нужны конкретные кейсы с понятными метриками.</li> <li> Инструмент не встроен в процессы. Отдельный чат-бот почти всегда проигрывает привычным инструментам. ИИ должен работать внутри CRM, IDE или документов.</li> <li> Нет данных и контекста. Без доступа к корпоративным знаниям ИИ дает общие ответы, которые требуют ручной проверки.</li> <li> Безопасность блокирует внедрение. Если правила появляются в конце, запуск останавливается на этапе согласований.</li> <li> Нет поддержки после запуска. Разовое обучение не работает. Без постоянной помощи сотрудники возвращаются к старым инструментам.</li> <li> Неверные метрики. MAU показывает активность, но не эффективность. Важно измерять влияние на процесс: скорость, качество, нагрузку.</li> </ul> <h3>Почему «хорошая технология» не становится инструментом</h3> <p>Даже сильные решения не приживаются без системной встройки.</p> <p>Во-первых, у инструмента часто нет конкретной «работы», которую он должен выполнять. Он воспринимается как универсальный помощник, но не решает конкретную задачу.</p> <p>Во-вторых, пилот не превращается в процесс. На этапе тестирования все держится на энтузиастах, но после запуска отсутствуют роли, правила и поддержка.</p> <p>В-третьих, отсутствуют стимулы. Если KPI не меняются, сотрудники продолжают работать по-старому — это логично.</p> <p>И, наконец, нет итераций. Промпты, сценарии и базы знаний не улучшаются, и качество быстро перестает соответствовать ожиданиям.</p> <h3>Все упирается в управление изменениями</h3> <p>Ключевая проблема большинства внедрений в том, что ИИ воспринимается как инструмент, а не как изменение системы. Тогда как при трансформации по правилам change management, или управления изменениями, было бы правильно:</p> <ul> <li> сформировать рабочую группу;</li> <li> задать план внедрения;</li> <li> определить метрики;</li> <li> выделить бюджет и время;</li> <li> назначить ответственных.</li> </ul> <p>В результате команда получает новый инструмент, но не новую норму работы. А успех внедрения зависит именно от нормы — от того, донесут ли ее принципы и правила до команды, сможет ли команда приспособиться к ее условиям.</p> <h3>Как вести себя лидеру</h3> <p>Любое внедрение ИИ — это управляемое изменение, и у него должен быть лидер. Его задача заключается не в том, чтобы пассивно ждать, пока команда разберется сама и освоит новую технологию. Лидер задает направление — а значит, формулирует правила, объясняет, где и как использовать искусственный интеллект, поддерживает команду на этапе адаптации.</p> <p>Важно, что на этом этапе лидер фактически «верит за команду». Сотрудники могут относиться к идее внедрить ИИ скептически и быть не готовыми к изменениям, и задача лидера — зарядить их, направить в нужное русло. Если он сам не настроен на перемены, ничего не выйдет.</p> <h3>Нужно помнить, что сопротивление — нормальная часть процесса</h3> <p>Любая система сопротивляется изменениям, это не сбой. Очень редко бывает так, что людям предлагают попробовать что-то новое, и они сразу же радостно соглашаются.</p> <p>В случае с внедрением ИИ возможны два варианта развития событий:</p> <ul> <li> сотрудники начинают активно использовать ИИ-инструменты, адаптируются, наращивают экспертизу и усиливаются;</li> <li> сотрудники продолжают игнорировать изменения, отказываются от них — и в итоге выходят из системы, потому что становятся для нее либо слабым звеном, которое справляется со своими задачами, просто работает медленнее остальных, либо балластом, которые вообще не могут поддерживать темп команды.</li> </ul> <p>Компании, которые достигают успехов, учитывают это заранее и строят процессы с учетом неизбежного сопротивления.</p> <h3>Что в итоге</h3> <p>Саботаж искусственного интеллекта — это не проблема сотрудников и не признак их нежелания меняться. Это следствие того, что система не дает им понятного и безопасного способа, как использовать на практике новый инструмент.</p> <p>Важно помнить, что ИИ внедряется через процессы, новые нормы и грамотное управление изменениями. Здесь недостаточно обучения и лицензий хотя бы потому, что невозможно заставить сотрудников учиться, если они этого не желают.</p> <p>Без правильного внедрения команда возвращается к проверенным вариантам — тому, что работает. И будет странно требовать от них иного.</p> <p>#IMAGE_234934#</p> Представьте типичную ситуацию: компания закупает корпоративный ИИ-инструмент, проводит обучение, запускает пилот. Через три … article Константин Попандопуло, технический директор Umbrella IT https://www.itweek.ru/themes/detail.php?ID=234928 Mon, 01 Jun 2026 13:30:21 +0300 <p>Центр стратегических разработок опубликовал ежегодное исследование российского рынка информационной безопасности по итогам 2025 года и подготовил прогноз его развития до 2031 года. По оценке экспертов, рынок сохраняет устойчивую положительную динамику — выше среднемировых показателей и темпов роста большинства сегментов российского ИТ-сектора.</p> <p>«Рынок информационной безопасности в России демонстрирует стабильный рост. По итогам 2025 года рост составил 16,1% по сравнению с годом ранее. Это превышает глобальные тенденции и динамику большинства сегментов российского ИТ-сектора. Если текущие условия сохранятся, то к 2031 году рынок может превысить 1 трлн рублей, а среднегодовой темп роста в период с 2026 по 2031 годы составит 19,4%», — отметила заместитель генерального директора ЦСР Екатерина Кваша.</p> <p>Основу рынка формируют средства защиты информации (СЗИ) — 74% совокупного объема, или 271 млрд рублей (+18,1%). Крупнейшие категории — сетевая безопасность, защита инфраструктуры и защита конечных точек. Наибольшие темпы роста (+45,6 п.п. год к году) зафиксированы в сегменте защиты приложений (application security), что указывает на повышение значимости обеспечения безопасности прикладных контуров. Рынок услуг ИБ достиг 93,5 млрд рублей (+10,7%): острый дефицит квалифицированных специалистов продолжает стимулировать спрос на управляемые сервисы — MSS, MDR, SOC-as-a-Service.</p> <p>По объемам продаж средств защиты информации лидирует «Лаборатория Касперского» с долей 20,1% рынка (+0,5 п.п. год к году). Наиболее заметное усиление позиций показала Positive Technologies: доля компании выросла на 3,2 п.п., составив 16,8%. Среди ключевых игроков также ГК «Солар» и BI.ZONE, специализирующиеся на сервисах ИБ, и производители средств сетевой безопасности — «ИнфоТеКС», «Код Безопасности» и UserGate. Доля отечественных поставщиков на рынке СЗИ превысила 94%.</p> <p>В целом, российский рынок кибербезопасности сохраняет устойчивую положительную динамику сразу по нескольким направлениям. Первоначальная волна импортозамещения — когда организации в срочном порядке закрывали разрывы в защитном контуре — сменяется более зрелым подходом: компании переходят к системной перестройке ИБ-архитектур с акцентом на управляемость, интегрированность и доказуемую эффективность вложений. Параллельно меняется само восприятие кибербезопасности: из набора технических мер она превращается в элемент операционной устойчивости бизнеса — способность выдерживать атаки, сохранять непрерывность процессов и минимизировать финансовый ущерб.</p> <p>Дефицит кадров и регуляторное давление усиливают спрос на управляемые сервисы и платформенные решения, позволяющие быстро получить доступ к экспертизе без создания дорогостоящей внутренней инфраструктуры. Активное внедрение облачных технологий и ИИ расширяет цифровые возможности организаций, но одновременно увеличивает поверхность атаки и формирует новые классы рисков, требующих соответствующих подходов к защите.</p> Центр стратегических разработок опубликовал ежегодное исследование российского рынка информационной безопасности по итогам … message https://www.itweek.ru/themes/detail.php?ID=234926 Mon, 01 Jun 2026 00:00:00 +0300 <p>Многие компании верят: если мы внедрили CI/CD и наняли десяток DevOps-инженеров, мы стали Agile. На практике же TTM (Time-to-Market) часто не только не падает, но и растет. Почему? Потому что была совершена подмена понятий. Изначально, DevOps задумывался как способ <em>стереть границу</em> между кодом и инфраструктурой, сократить время ожидания разработчика на готовое окружение для разработки. В итоге мы построили новую <em>«админскую стену»,</em> только теперь обложенную YAML-файлами.</p> <p>В среде современного DevOps часто господствует «админский» подход. Люди месяцами спорят о выборе между Terraform, Pulumi, Helm, Kustomize или Ansible, выбирая «марку молотка», в то время как дом всё ещё не построен, а чертежи никто не видел. Забывается главная цель DevOps — сокращение TTM. Если выбор инструмента не ускоряет доставку фич, спор становится пустым: ресурсы тратятся на освоение инструментария, а не на доставку ценности. Такой подход заставляет внедрять решение просто потому, что команда его знает, а не потому, что оно оптимально (например, тащить Ansible туда, где достаточно простого Containerfile или Dockerfile). В этих спорах теряется принцип Shared Responsibility: важно не то, насколько красив манифест, а может ли разработчик самостоятельно внести в него правки, не дожидаясь администратора.</p> <p>Проблема усугубляется еще тем фактом, что многие компании создают «DevOps-подразделения», которые на самом деле являются просто отделами администрирования. Нередко это происходит так: руководство читает отчеты Gartner и видит, что «успешные компании используют Kubernetes и Terraform». В итоге покупается дорогой «молоток», нанимаются «мастера молотка», но гвоздей в компании нет. Инженерам приходится придумывать себе работу, создавая сложнейшие абстракции над простыми вещами, чтобы оправдать свое существование. Нередко автоматизируются те процессы, которые вообще не должны были существовать, или тратится время на написание сложных абстракций в каком-нибудь Helm, которые никто кроме автора не может понять. Но DevOps — это про коммуникацию, а не про то, как вы лихо умеете писать плейбуки в Ansible.</p> <p>Между тем, мы убили SysOps, заменив его эфемерным DevOps’ом. В компаниях, где нет своего кода, своей разработки, мы наблюдаем парад абсурда: люди внедряют технологии для <em>Continuous Deployment</em> туда, где деплоить нечего. Тратятся бюджеты на поддержку инфраструктуры для автоматизации самой автоматизации, стыдливо избегая честного слова «эксплуатация». Сейчас, признать, что вам нужен просто надежный SysOps — значит разрушить сложившийся миф и признать, что половина ваших модных инструментов — это просто балласт.</p> <p>Признать, что вам нужен качественный SysOps вместо карго-культового DevOps — это не шаг назад. Это шаг к эффективности. Ведь в конечном итоге бизнесу нужны работающие сервисы, а не красивые графики в ArgoCD, за которыми скрывается пустота.</p> <p>А что же не так с компаниями, в которых явно присутствует этап разработки программного обеспечения, теми компаниями, которые можно смело отнести к ISV? В компаниях-разработчиках админский DevOps нередко превращается в изощренную форму саботажа. Здесь выбор «марки молотка» напрямую бьет по прибыли: пока инженеры по эксплуатации полируют свои идеальные пайплайны, разработчики бьются лбом об ограничения инфраструктуры, которые им навязали «для их же блага». В итоге мы получаем продукт, который оброс костылями не из-за плохого кода, а из-за того, что его пытались засунуть в чуждую ему, избыточно сложную среду.</p> <p>Почему же DevOps стал инструментом администраторов, ведь CI/CD задумывался как способ дать разработчику контроль над доставкой кода (Self-Service)? Одна из причин заключается в том, что технологический порог входа стал так высок, что инструмент оказался в руках специалистов по инфраструктуре. Разработчикам становится всё сложнее поддерживать YAML-файлы на тысячи строк, они теперь должны быть наполовину системными программистами. Вместо написания бизнес-логики разработчики ПО вынуждены изучать HCL, копаться в репозиториях инфраструктуры и ждать завершения CI/CD-пайплайна, который падает из-за лишнего пробела. Кроме того, на российском рынке в крупных корпорациях (банки, госсектор) разделение на «тех, кто пишет» и «тех, кто катит» до сих пор сильнее, чем на Западе, из-за жестких требований безопасности и бюрократии. К тому же сложившийся дефицит кадров привел к тому, что проще нанять одного «звездного» DevOps-инженера, который настроит всё для десятка разработчиков, чем обучать всю команду нюансам инфраструктуры. В итоге, для разработчика программного обеспечения самообслуживание превратилось в самоистязание.</p> <p>В современных условиях DevOps-команда должна перестать быть «обслуживающим персоналом» или «хранителями ключей». Она должна стать <em>продуктовой командой</em>, чей продукт — это платформа, а ее клиент — это разработчик ПО. Целью должно стать создание условий, чтобы разработчик мог развернуть необходимый ему сервис, не вникая в YAML-описания конфигурации развертывания, без знания какая «марка молотка» использована под капотом. Необходимо выстраивание Internal Developer Platform (IDP), где разработчик нажимает кнопку «Создать среду» и получает готовое окружение за минуты, а не часы или даже дни. Необходимо перестать мерить успех количеством «закрытых тикетов» или «написанных скриптов». Метрикой успеха должно стать время, потраченное разработчиком на инфраструктуру. Если он тратит более 5% — модель DevOps убыточна. Переход к платформенной модели способен сократить цикл разработки с недель до часов. Это прямое снижения операционных расходов и реальный рывок в капитализации.</p> <p>Автоматизация ради автоматизации — это дорогое хобби, которое бизнес больше не может себе позволить. Настоящий DevOps начинается не с выбора между Terraform и Pulumi, а с вопроса: «Как это изменение поможет нам доставлять код быстрее и надежнее?». Если внедрение нового инструмента увеличивает TTM и строит новые заборы между командами — значит, вы просто сменили вывеску «Системное администрирование» на более модную, сохранив старые проблемы. Пора перестать коллекционировать «молотки» и начать, наконец, забивать гвозди. Чтобы ваша автоматизация не превратилась в «новые грабли», проведите ревизию процессов прямо сейчас:</p> <ul> <li> <strong>Упрощайте.</strong> Если задачу можно решить простым Containerfile, не тащите туда сложный Helm.</li> <li><strong>Стирайте границы</strong>. Разработчик должен иметь возможность сам управлять окружением. Используйте rootless-решения, которые позволяют запускать контейнеры без прав суперпользователя — это дает командам автономность, не создавая дыр в безопасности и лишних тикетов на админов.</li> <li><strong>Считайте метрики.</strong> Главный показатель успеха — это сокращение времени от идеи до выпуска в промышленную эксплуатацию, а не количество закрытых задач по автоматизации. DevOps — это мост, а не новая стена. Не дайте технологическому стеку стать препятствием на пути к здравому смыслу.</li> </ul> <p>#IMAGE_234927#</p> Многие компании верят: если мы внедрили CI/CD и наняли десяток DevOps-инженеров, мы стали Agile … article Дмитрий Гаврилов, основатель ООО “Открытые Технологии Виртуализации” https://www.itweek.ru/themes/detail.php?ID=234925 Mon, 01 Jun 2026 00:00:00 +0300 <p><em>Поскольку агентов ИИ на порядки больше, чем людей, устаревшие системы безопасности дают сбой. Джастин Долли, директор по работе с клиентами и безопасности компании Ory, рассказывает на портале </em><em>The</em> <em>New</em> <em>Stack</em> <em>о том, как защитить свою инфраструктуру с помощью системы управления идентификацией и доступом агентов (</em><em>Agent</em> <em>IAM).</em></p> <p>Переход от традиционных веб-приложений к агентным экосистемам — это не просто изменение пользовательского интерфейса; это фундаментальный сдвиг в модели угроз Интернета. Мы переходим из мира, где неправильный ввод создает неправильные данные, в мир, где неправильный ввод создает неправильные действия. В условиях, когда агенты ИИ эволюционируют от простых чат-ботов до автономных контроллеров, способных вызывать API, читать конфиденциальные файлы и отправлять электронные письма, наши устаревшие модели безопасности не выдерживают давления.</p> <p>Поскольку агентов уже на порядки больше, чем людей, если вы сегодня создаете или развертываете агентов ИИ, вы, вероятно, сталкиваетесь с замаскированной проблемой IAM. Согласно недавнему глобальному опросу Enterprise Management Associates (EMA) «Agentic AI Identities», 95% респондентов используют ИИ-агентов в производственной среде или ограниченных пилотных программах.</p> <p>Рассмотрим, как осуществить переход от человекоцентричной безопасности к эре Agent IAM.</p> <h3>1. В чем проблема: идентификационный вакуум</h3> <p>Основная проблема заключается в том, что агенты ИИ в настоящее время работают в условиях идентификационного вакуума. В большинстве производственных сред агентам предоставляется общий, унаследованный доступ. Они работают как служебные учетные записи с широкими правами доступа или, что еще хуже, наследуют полные права доступа пользователя, который их запустил.</p> <p>Это создает три критические уязвимости:</p> <ul> <li><strong> Модель угроз, основанная на действиях (</strong><strong>Action</strong><strong>-</strong><strong>Based</strong> <strong>Threat</strong> <strong>Model</strong><strong>).</strong> В отличие от традиционных приложений, агенты что-то «делают». Если большую языковую модель (LLM) обманут с помощью инъекции промпта, она не просто отобразит неправильный ответ; она выполнит вызов вредоносного инструмента. 80% респондентов <a href="https://www.osohq.com/learn/why-your-authorization-model-wont-survive-agentic-ai">сообщают</a> о случаях, когда приложения действуют за пределами предполагаемых границ.</li> <li><strong> Поверхность атаки системы RAG. </strong>Системы генерации с расширенной выборкой (RAG) уязвимы для косвенной инъекции промптов. Если агент получает документ, содержащий вредоносные инструкции, этот документ становится новым владельцем («мастером») агента, игнорируя меры защиты разработчиков.</li> <li><strong> Взрывной рост использования нечеловеческих идентификаторов (NHI).</strong> Мы наблюдаем массовый всплеск роста API, сервисов и автономных агентов, которым не хватает централизованного источника достоверной информации об идентификации. 39% респондентов опроса SailPoint «AI agents: The new attack surface» сообщают об инцидентах несанкционированного доступа агентов, и у большинства команд нет возможности отозвать доступ отдельного агента, не нарушив работу всего сервиса.</li> </ul> <h3>2. Почему это важно: растущий разрыв в устранении уязвимостей</h3> <p>Недавнее появление Claude Mythos от Anthropic <a href="https://www.ory.com/blog/anthropic-mythos-iam-identity-security-risk">повысило ставки</a>. Модель выявила тысячи уязвимостей нулевого дня в основных ОС и браузерах, включая ошибки, которые пережили более 20 лет проверки людьми.</p> <p>Это важно, потому что ИИ теперь является множителем силы для обнаружения уязвимостей. Хотя ИИ может находить ошибки со скоростью машины, люди по-прежнему устраняют их в «человеческом темпе» (совещания, бэклоги, циклы обновления).</p> <p>Если ваша инфраструктура IAM является собственной разработкой или неуправляемым Open Source, вы не сможете достаточно быстро обновлять ее, чтобы угнаться за злоумышленником, использующим ИИ. Идентификация — наиболее уязвимый уровень, поскольку это плоскость управления; если идентификация агента скомпрометирована, вся инфраструктура становится открытой для горизонтального перемещения. Исследование SailPoint показывает, что 33% респондентов сталкивались с ненадлежащим обращением агентов с данными с ограничен доступом.</p> <h3>3. Как решить проблему: план управления идентификацией и доступом для агентов</h3> <p>Для решения проблемы агентной безопасности необходимо перенести ограничительные механизмы с <nobr>LLM-промптов</nobr> на инфраструктуру. Вы не можете уговорить агента действовать безопасно; вы должны авторизовать его действовать безопасно. Усугубляет проблему агентной безопасности тот факт, что большинство участников опроса EMA считают, что их IAM-решения не готовы к новой реальности:</p> <ul> <li> 62% заявляют о неготовности к отказоустойчивости агентов;</li> <li> 49% утверждают, что не готовы к соответствию нормативным требованиям для агентов;</li> <li> 62% сообщают о неготовности к масштабируемости агентов;</li> <li> 59% заявляют о неготовности к безопасности агентов.</li> </ul> <p><strong>Относитесь к агентам как к первоклассным идентификаторам. </strong>Агенты должны рассматриваться как первоклассные нечеловеческие идентификаторы. Это означает:</p> <ul> <li><strong> Аутентификация.</strong> Агенты должны проходить аутентификацию у провайдера идентификации, используя учетные данные с ограниченной областью действия.</li> <li><strong> Токены с коротким сроком действия.</strong> Используйте OAuth2 для выдачи токенов, ограниченных областью взаимодействия. Если агент скомпрометирован, токен быстро истекает, ограничивая окно эксплуатации уязвимости.</li> <li><strong> Управление доступом на основе отношений (ReBAC).</strong> Используйте модель разрешений на основе графа, чтобы точно определить, к чему может получить доступ агент.</li> <li><strong>Согласование извлечения с авторизацией. </strong>В системах RAG разрешение на «просмотр» должно соответствовать разрешению на «извлечение». Прежде чем агент получит документ для размещения в его контекстном окне, система должна проверить: имеет ли этот конкретный Agent ID разрешение на просмотр этого Document ID? Если нет, документ никогда не будет получен, что предотвратит просмотр агентом вредоносного кода и его воздействие на него.</li> <li><strong>Инженеры как дирижеры. </strong>Измените свой инженерный подход. Перестаньте пытаться жестко запрограммировать каждое действие агента. Вместо этого действуйте как дирижер, управляя агентами с помощью политики как кода. Используйте инструменты для визуализации этих сложных цепочек разрешений, чтобы точно видеть, как отношения между агентами разрешаются в «РАЗРЕШИТЬ» или «ОТКАЗАТЬ».</li> </ul> <h3>Подводные камни и как их избежать</h3> <p>Даже при наличии продуманного плана часто возникают скрытые издержки и технические ловушки:</p> <ul> <li><strong> Ловушка унаследованного доступа:</strong> <ul> <li> Проблема: разработчики часто предоставляют агентам права администратора для упрощения разработки.</li> <li> Решение: внедрите принцип минимальных привилегий с самого начала. Если агенту нужно только читать маркетинговые документы, не предоставляйте ему доступ ко всему бакету S3.</li> </ul> </li> <li><strong> Задержка обратной связи:</strong> <ul> <li> Проблема: по мере добавления уровней безопасности задержка агента увеличивается, что заставляет пользователей обходить безопасность ради скорости.</li> <li> Решение: используйте высокопроизводительные механизмы управления разрешениями, которые могут обрабатывать сложные запросы за миллисекунды, гарантируя, что безопасность не ухудшает пользовательский опыт.</li> </ul> </li> <li><strong> Агенты-призраки:</strong> <ul> <li> Проблема: агенты создаются для задачи, задача завершается, но учетные данные остаются активными.</li> <li> Решение: внедрите автоматическое управление жизненным циклом. Используйте отзыв цепочки токенов, чтобы, если родительский агент-оркестратор помечен как проблемный, все токены дочерних агентов мгновенно аннулировались.</li> </ul> </li> <li><strong> Слепота:</strong> <ul> <li> Проблема: модели разрешений для сотен агентов становятся слишком сложными для восприятия человеком.</li> <li> Решение: используйте инструменты визуализации для аудита ваших моделей. Если вы не видите граф, вы не можете обеспечить его безопасность.</li> </ul> </li> </ul> <h3>Резюме: идентификация — это отправная точка</h3> <p>Безопасность — это процесс, а не продукт. Хотя ограничительные механизмы LLM и защита на уровне промптов важны, их легко обойти. Единственная жесткая граница, которая остается неизменной перед лицом автономного агента, — это граница авторизации.</p> <p>Относитесь к своим агентам как к идентификаторам, определяйте их окружение с помощью ReBAC и обеспечьте профессиональное управление вашим стеком IAM, чтобы идти в ногу с темпами обнаружения, обусловленными ИИ. Будущее Интернета связана с агентами; убедитесь, что ваша безопасность тоже.</p> Поскольку агентов ИИ на порядки больше, чем людей, устаревшие системы безопасности дают сбой. Джастин Долли, директор … article https://www.itweek.ru/themes/detail.php?ID=234923 Mon, 01 Jun 2026 00:00:00 +0300 <p>К началу 2026 года корпоративная ИТ-инфраструктура на базе Windows 10 и вышедших в то же время сопутствующих продуктах фактически оказалась в зоне риска: поддержка устаревших решений Microsoft завершена, безопасных способов оставаться на привычной ИТ-инфраструктуре практически не осталось. В ближайшее время злоумышленники начнут активно эксплуатировать уязвимости, исправлений для которых нет в результате отмены поддержки.</p> <h3>Тихий кризис, который больше не тихий</h3> <p>Окончание поддержки Windows 10 и серверных продуктов Microsoft стало точкой отсчета существенного увеличения рисков для корпоративной ИТ-инфраструктуры. В октябре 2025 Microsoft официально прекратила поддержку Microsoft Exchange Server 2016 и 2019, а вместе с ними и других ключевых сервисов своей экосистемы, на которой десятилетиями строились корпоративная почта, адресные книги, календарь и другие элементы системы коммуникации.</p> <p>На первый взгляд, это очередное обновление продуктовой политики вендора. Но для России, где по оценкам экспертов, подавляющее большинство организаций по-прежнему живет на этой версии операционной системы и связанных с ней офисных приложениях, речь идет о стратегической угрозе.</p> <p>Это не метафора, а вполне конкретная техническая реальность. Если раньше уязвимость уровня ProxyShell закрывалась в течение считанных дней, то теперь исправление таких проблем может существенно затягиваться, если вообще быть возможным, вследствие чего злоумышленники получают возможность либо начинать максимально быстро эксплуатировать уязвимости после их обнаружения, либо изучать унаследованный стек, а компании лишаются возможности хоть как-то повлиять на уровень защищенности своих почтовых серверов. Именно поэтому речь идет о наступлении периода, в котором сама архитектура корпоративной почты начинает терять целостность и устойчивость.</p> <p>В удобстве экосистемы Windows кроется ее главная уязвимость: зависимость от продуктов западного недружественного нам вендора, контроль над которыми теперь окончательно уходит за пределы российского ИТ-контурa.</p> <h3>В кризис: медленно, но верно</h3> <p>Важно понимать, что развитие ситуации не будет мгновенным: никто не столкнется с внезапных отказом сервисов. Однако существует опасность другого рода: продукты, на которых строится безопасная офисная работа — Windows 10, Microsoft Office 2016 и 2019, Microsoft Exchange Server 2016 и 2019, перестанут получать обновления. Это означает, что каждая найденная проблема безопасности, останется открытой на непрогнозируемое время.</p> <p>То, что происходит дальше, технически предсказуемо. Exchange, Outlook и связанный с ними серверный стек — не автономные приложения, а цепочка взаимозависимых механизмов, работа которых базируется на постоянном обновлении криптографических библиотек, протоколов аутентификации и транспортных модулей.</p> <p>После остановки поддержки эта цепочка начинает постепенно рассыпаться:</p> <ul> <li> устаревают версии протоколов, на которых держатся внешние и внутренние соединения;</li> <li> MAPI и EWS продолжают функционировать, но без актуальных исправлений остаются уязвимы к перехвату сессий и манипуляциям с заголовками;</li> <li> подсистема обработки вложений в Outlook превращается в потенциальную точку входа для вредоносного кода;</li> <li> AD остаётся без обновлений версий Kerberos, из-за чего возрастает риск атак типа Pass-the-Ticket и Pass-the-Hash.</li> </ul> <p>На поверхности все выглядит рабочим, но скрыто развивается характерный процесс деградации: система перестает адаптироваться к новым угрозам и постепенно превращается в статичную конструкцию, не способную сопротивляться современному уровню автоматизированных атак.</p> <p>На горизонте в полгода, пока исследователи и киберпреступники будут изучать продукт в поисках новых слабых мест, риски возрастут экспоненциально. Корпоративная почта, через которую ежедневно проходят финансовые документы, персональные данные и конфиденциальные переписки, превратятся в мишень кибермошенников.</p> <p>В эпоху, когда атаки все чаще совершаются с применением ИИ и автоматизированных инструментов подбора эксплойтов, это сродни вождению автомобиля без тормозов: пока дорога ровная, кажется, что можно ехать, но одна непредсказуемая яма способна обернуться катастрофой.</p> <h3>«Костыли» не помогут</h3> <p>Сейчас становится очевидно, что попытки «кустарного устранения» системных рисков сторонними средствами приводят к предсказуемым последствиям: каждое «временное исправление» порождает каскад проблем, включая функциональную несовместимость и рост операционных издержек.</p> <p>До недавнего времени компании могли позволить себе стратегию «отложенной миграции». Существовали обходные пути, неофициальные обновления, возможность продлить жизнь старым лицензиям. Но теперь сам вендор меняет правила игры. Microsoft уходит от бессрочных лицензий, делая ставку на модель подписки. В угоду обеспечения безопасности (в ее прочтении от вендора) компании вынуждены ежегодно платить за доступ к собственным данным, а фактически — арендовать собственный ИТ-контур.</p> <p>Поэтому попытка заменить один элемент этой системы неизбежно вскрывает ее внутренние сцепления: любое отклонение от штатного поведения приводит к проблемам совместимости, нарушению адресных книг, сбоям в механизмах автодискавери и неконтролируемому росту нагрузки на серверы.</p> <p>Для российских пользователей эта перемена имеет особый смысл. Если раньше можно было зафиксировать систему на стабильном релизе, то теперь отказ от подписки ведет к полному выбытию продукта как из правового, так и из технологического поля.</p> <p>Любая попытка сохранить привычную инфраструктуру превратится в рискованную игру с лицензиями, VPN, серыми обновлениями и искусственными схемами поддержки. И самое главное — все эти усилия не решают корневую проблему: ни одна из них не способна вернуть безопасность и предсказуемость в среду, которая живет вне воли разработчика.</p> <h3>Почему «пересидеть» не получится</h3> <p>С каждым месяцем инфраструктура, построенная на устаревших продуктах Microsoft, будет терять устойчивость. Уязвимости будут множиться, а ряды специалистов, способных поддерживать старые системы, будут истощаться.</p> <p>На практике это означает, что привычные для специалистов по информационной безопасности сценарии атак станут значительно проще в реализации. Скомпрометированный почтовый ящик превращается в идеальную точку входа для фишинга внутри периметра: злоумышленник получает возможность рассылать письма от имени сотрудников, менять реквизиты в финансовых документах, перехватывать цепочки согласований.</p> <p>Через устаревшие версии EWS и MAPI становится возможным извлекать токены доступа и хешированные пароли, а затем использовать их для постепенного перемещения по инфраструктуре в сторону более критичных систем. Не менее опасны сервисные учетные записи, которые часто используются для автоматизации бизнес-процессов: потеря контроля над ними открывает путь к вмешательству в CRM, ERP и другие ключевые приложения.</p> <p>Таким образом, риск уже не ограничивается «взломом почты» как таковым: устаревший Exchange превращается в платформу для комплексных атак, последствия которых затрагивают финансовые операции, клиентские данные и процессы принятия решений на уровне всей компании.</p> <p>Новое поколение администраторов не будет иметь возможность проходить официальное обучение у вендора. Так рушится преемственность опыта. В какой-то момент в компании просто некому будет обслуживать старую инфраструктуру.</p> <p>Именно поэтому переход на отечественные решения перестает быть вопросом удобства — это вопрос выживания. Сегодня бизнес еще может планомерно выбрать партнера, протестировать импортонезависимые продукты, выстроить плавный переход. Завтра все это придется делать в пожарном режиме, под давлением инцидентов и требований службы безопасности.</p> <h3>Что делать в 2026 году</h3> <p>Отказ от поддержки устаревших версий Windows — не катастрофа, а момент стратегического выбора. И выбор этот состоит не в том, уходить ли от западных вендоров, а в том, каким образом выстраивать новую архитектуру корпоративных коммуникаций.</p> <p>На практике этот выбор инфраструктуры неизбежно сводится к стратегии миграции, и здесь у компаний фактически есть лишь несколько реалистичных сценариев:</p> <ul> <li> параллельный запуск новой платформы рядом с существующим Exchange;</li> <li> для организаций с большим количеством филиалов подходит поэтапный перенос групп сотрудников с сохранением обратимой конфигурации и возможностью отката;</li> <li> миграция с переключением, как вынужденная мера для инфраструктур в критическом состоянии.</li> </ul> <p>Ключевой принцип при выборе любой модели: в приоритете контролируемость, а не скорость. Платформа должна поддерживать доменную аутентификацию, корректно работать с существующими политиками безопасности, обеспечивать импорт PST-данных и прозрачную маршрутизацию писем на период сосуществования двух систем.</p> <p>Отдельного внимания требуют мобильные клиенты: их подключение через ActiveSync или его аналоги должно проходить без изменения привычного опыта сотрудников. Все эти параметры — практические критерии, по которым следует оценивать зрелость решений и способность конкретного вендора обеспечить действительно бесшовный переход.</p> <p>* * *</p> <p>Российский рынок не стоит на месте. За последние три года отечественные разработчики проделали путь, который в нормальных условиях занял бы десятилетие. Кроме того, на рынке есть зрелые, надежные программные продукты, готовые заменить не только почтовые сервисы, но и часть инфраструктуры, на которой держится корпоративные коммуникации.</p> <p>Архитектура многих российских решений позволяет не обрывать связи с текущими ИТ-системами, а сосуществовать с ними, запускаться параллельно с Microsoft Exchange, постепенно перемещая данные пользователей, минимизируя стресс для бизнеса и обычных сотрудников.</p> <p>Точка невозврата уже пройдена. Вопрос теперь стоит не в том, произойдет ли переход на отечественные решения, а в том, насколько контролируемым он будет.</p> <p>#IMAGE_234924#</p> К началу 2026 года корпоративная ИТ-инфраструктура на базе Windows 10 и вышедших в то же время … article Александр Буравцов, директор по ИБ CommuniGate Pro https://www.itweek.ru/themes/detail.php?ID=234922 Fri, 29 May 2026 10:44:26 +0300 <p>Объем российского B2B- и B2G-рынка видеонаблюдения по итогам 2025 года достиг 67,6 млрд рублей, более чем удвоившись с 2021 года. Среднегодовой темп роста (CAGR) отрасли составил 23,4%. Согласно новому аналитическому отчету компании ivideon, поставщика облачного видеонаблюдения и интеллектуальной видеоаналитики, к 2030 году емкость рынка может удвоиться и достигнуть отметки в 135 млрд рублей. Ключевыми драйверами столь высокой динамики стали развитие государственных инфраструктурных проектов, процессы импортозамещения, а также активное внедрение видеоконтроля в распределенном бизнесе.</p> <p>В своем отчете компания ivideon исследовала рынок видеонаблюдения и видеоаналитики на основе публичной финансовой отчетности 237 юридических лиц: в емкость включены 107 компаний, формирующих 93 уникальных бренда. Исследование охватывает профессиональный сегмент видеонаблюдения для бизнеса и государства (B2B/B2G) и учитывает «чистую» выручку профильных игроков. Рынок нередко оценивают шире — около 100 млрд рублей; такие оценки могут включать интеграционные проекты, перепродажу оборудования, потребительский сегмент и смежные элементы инфраструктуры безопасности. В выборку вошли ведущие игроки рынка; анализ строился на операционных юридических лицах и структуре групп компаний по публичным данным, что обеспечивает репрезентативность оценки.</p> <p>Несмотря на устойчивое доминирование традиционных локальных систем видеонаблюдения (сегмента on-premise — оборудование и ПО, развернутые на стороне клиента), на которые по итогам года пришлось 51,5 млрд рублей (76,2% рынка), отрасль переживает структурный сдвиг в сторону облачных и ИИ-решений. Классическое аппаратно-программное обеспечение показывает прирост на уровне 17% в год, при этом облачное видеонаблюдение (VSaaS) и системы на базе нейросетевой видеоаналитики растут кратно быстрее базового оборудования — на 26% и 40% соответственно. </p> <p>Видеоаналитика стремительно выделяется в самостоятельный рынок ПО для анализа видео — отдельный от камер и оборудования. По оценке Ivideon, в 2025 году объем этого сегмента достиг 9,4 млрд рублей против 4 млрд рублей четырьмя годами ранее. Динамику сегмента задают удешевление вычислений на стороне устройства (EdgeAI) и расширение сценариев использования видео: системы выходят за рамки контура безопасности и становятся инструментами операционного управления бизнесом. Ожидается, что к 2030 году он вырастет до 31 млрд рублей. В топ-5 игроков сегмента видеоаналитики вошли разработчики алгоритмов computer vision NVI Solutions, NtechLab, VisionLabs, ЦРТ (Визирь) и Netris.</p> <p>Динамику рынка в 2025 году поддерживали: импортозамещение; рост спроса на облачные сервисы и подписочные модели; расширение применения видеоаналитики в B2B и B2G-сегментах; развитие AI/EdgeAI и повышение точности аналитических сценариев; запрос бизнеса на снижение издержек, централизацию управления и повышение эффективности операций. Дополнительный импульс рынку дают B2B- и B2G-проекты, а также спрос со стороны retail, HoReCa, логистики, промышленности и девелопмента, где видеонаблюдение все чаще рассматривается не только как элемент безопасности, но и как инструмент управления бизнес-процессами.</p> <p>Характерной чертой российского рынка видеонаблюдения остается его фрагментированность. Исследование не выявило крупного игрока, доминирующего во всех категориях; позиции строго распределены по технологическим нишам. В сегменте классических внедрений лидируют вендоры комплексных платформ Trassir, Rubezh, Bolid и Байтэрг; в крупнейшем B2G-сегменте on-premise значимую роль играет Ростелеком через программу «Цифровой регион». </p> <p>Первую строчку в сфере облачного видеонаблюдения среди независимых игроков занимает компания Ivideon; у Ростелекома — собственная платформа, а телеком-операторы (Уфанет, Дом.ру, МТС, Билайн, Мегафон) формируют значительную часть сегмента. </p> <p>В государственном секторе доля российских производителей последовательно растет: с 2027 года Минпромторг вводит балльную систему оценки локализации, и к 2030 году их доля в B2G ожидается на уровне 90%+. Реестр отечественного ПО расширяется параллельно — это меняет конкурентную карту в пользу локализованных игроков и в оборудовании, и в софте.</p> <p>«Рынок видеонаблюдения в России проходит этап качественной трансформации. Если раньше выбор определяли цена камеры и стоимость хранения архива, то сегодня заказчики ищут операционную эффективность, прикладную аналитику и управляемость распределенной инфраструктуры», — отметил Заур Абуталимов, генеральный директор Ivideon. — «Видео перестает быть архивом для безопасности и становится сенсорным слоем бизнеса — стандарты сервиса, шоплифтинг, скорость обслуживания, очереди, выкладка. Рынок превращается из инфраструктурного сегмента в технологическую платформу, в которой все большую ценность формируют облачные сервисы, аналитика и интеллектуальные функции, гибридные решения, объединяющие безопасность, автоматизацию и бизнес-эффективность».</p> Объем российского B2B- и B2G-рынка видеонаблюдения по итогам 2025 года достиг 67,6 млрд рублей, более чем удвоившись … message https://www.itweek.ru/themes/detail.php?ID=234920 Fri, 29 May 2026 10:39:21 +0300 <p>Строительный сектор становится одним из драйверов потребления высокопроизводительных ресурсов. Синергия технологии информационного моделирования (BIM) и облака становится стандартом индустрии, обеспечивающим прозрачность и эффективность на всех этапах жизненного цикла объекта. Владимир Лебедев, директор по развитию бизнеса сервис-провайдера M1Cloud, рассказал, почему BIM-модель в строительстве эволюционировала от локальных чертежей к комплексным облачным экосистемам.</p> <p>По данным Expert Market Research (Claight), объем мирового рынка информационного моделирования зданий достиг $11,17 млрд в 2025 году. Ожидается, что в период с 2026 по 2035 год рынок будет расти в среднем на 16,4% в год и к 2035 году достигнет $51 млрд. И российский рынок демонстрирует высокую динамику, поддерживаемую государственным регулированием. По данным Минстроя РФ, доля застройщиков, применяющих технологии информационного моделирования, по итогам I квартала 2026 года достигла 47%. Это на три процентных пункта выше показателя за IV квартал 2025 года.</p> <p>По мере детализации строительного проекта объем данных растет экспоненциально — это колоссальный массив данных, включающий архитектурные, инженерные и экономические параметры, что делает локальную инфраструктуру «узким местом». Облачная среда общих данных гарантирует, что все участники проекта работают с актуальной версией модели в режиме реального времени. Помимо этого, рендеринг и инженерные расчеты требуют значительных мощностей (в том числе GPU и CPU). Облако позволяет динамически выделять их под конкретные задачи, избавляя компанию от капитальных затрат на дорогостоящее оборудование. При этом провайдеры обеспечивают защиту данных и отказоустойчивость, которые сложно реализовать внутри корпоративной ИТ-службы.</p> <p>С точки зрения рентабельности, облачные решения показывают прямой экономический эффект — использование облачной платформы для управления BIM-моделями позволяет сократить трудозатраты BIM-отдела и уменьшить время проверки моделей.</p> <p>При проектировании автоматическая проверка проекта в облаке выявляет ошибки до начала работ. Совместная работа сокращает сроки согласования проектных решений. В ходе строительства инженеры получают доступ к модели через мобильные устройства. Любое изменение в офисе мгновенно отображается на стройке, что исключает ошибки из-за неактуальных чертежей. Интеграция с данными со стройки позволяет вести мониторинг прогресса в реальном времени. На этапе ввода в эксплуатацию заказчик получает цифровую модель, интегрированную с облачными системами управления зданием. Это позволяет оптимизировать энергопотребление и планировать ремонты на основе реальных данных.</p> <p>Интеграция BIM с облаком открывает путь для ИИ-аналитики. Искусственный интеллект, работающий на облачных мощностях, способен анализировать тысячи проектов, предсказывая задержки в графиках или дефицит материалов. В <nobr>2026-2030</nobr> годах аналитики M1Cloud ожидают массового перехода к «предиктивному строительству», где облачный провайдер выступает фундаментом для интеллектуальной аналитики и интернета вещей (IIoT).</p> <p>Переход строительной отрасли в облако — это смена парадигмы управления. Облачные платформы делают BIM масштабируемым и по-настоящему коллективным инструментом. Сегодня успех в девелопменте принадлежит тем, кто умеет управлять информацией, и облако — единственный инструмент, способный обеспечить необходимую для этого скорость и надежность.</p> Строительный сектор становится одним из драйверов потребления высокопроизводительных ресурсов. Синергия технологии … message https://www.itweek.ru/themes/detail.php?ID=234919 Fri, 29 May 2026 10:38:20 +0300 <p>Институт статистических исследований и экономики знаний (ИСИЭЗ) НИУ ВШЭ с помощью системы iFORA картировал точки разломов — необратимых изменений, которые под влиянием ИИ уже произошли в системе управления, экономике и социальной сфере и будут лишь усиливаться в дальнейшем.</p> <p>В системе управления ключевой сдвиг связан не с автоматизацией рутин, а с встраиванием ИИ в ядро принятия решений. Управленческий цикл ускоряется, точность контроля процессов растет, а решения все чаще принимаются на основе больших данных. Интеллектуализация охватывает основные этапы — от стратегического планирования до операционного контроля и мониторинга в реальном времени. В управленческой сфере, где ошибка в данных может обернуться искажением не отдельного показателя, а всей цепочки принятия решений, критическим становится качество данных. Их дефицит, а также проблемы подготовки и обработки остаются для компаний серьезным вызовом наряду с организационными барьерами внедрения ИИ. Сохраняется институционально нерешенная проблема размытой ответственности за рекомендации и действия, сформированные с использованием ИИ: ее сложно определить, когда результат зависит одновременно от человека, качества данных, ИИ-моделей и организационных процессов. По мере того как алгоритмические системы все глубже встраивают в контур управления, их надежность становится одним из ключевых условий безопасности. Уязвимость модели, данных или инфраструктуры превращается в уязвимость всей организации.</p> <p>В экономике ИИ перестает играть сугубо прикладную роль и становится частью процессов создания стоимости — от разработки продукта до взаимодействия с клиентом. Автоматизация все более широкого круга функций, включая роботизацию бизнес-процессов, меняет структуру издержек и подходы к организации деятельности. Производительность растет за счет оптимизации ресурсов и управления данными, при этом функции все чаще перераспределяются между человеком и алгоритмами. Одновременно на базе ИИ формируются новые бизнес-модели. В платформенной экономике — от электронной коммерции до финансовых сервисов — конкурентное преимущество все больше зависит от способности анализировать поведение пользователей, персонализировать предложения и управлять клиентским опытом в реальном времени. В этой логике данные перестают быть сопутствующим ресурсом, превращаясь в часть продукта, основу монетизации и инструмент долгосрочного удержания клиентов. ИИ уже используется в широком спектре бизнес-процессов, а его внедрение сопровождается трансформацией структуры занятости и спроса на навыки. Речь идет не столько о сокращении занятости, сколько о снижении доли рутинных задач, перераспределении функций и быстрой смене требований к компетенциям, в частности возрастает значимость навыков, связанных с работой с данными, применением аналитических инструментов и разработкой ИИ-решений. Облачная инфраструктура и распределенная архитектура позволяют быстро масштабировать продукты и сервисы на базе ИИ, снижать барьеры входа и ускорять коммерциализацию новых решений. Одновременно необходимым условием развития ИИ становится доступ к хранилищам, центрам обработки данных и специализированному оборудованию. Зависимость от поставщиков вычислительных мощностей и инфраструктуры создает предпосылки концентрации данных, технологий и алгоритмов у крупных игроков.</p> <p>В общественной сфере ИИ выступает не столько инструментом автоматизации, сколько триггером пересборки базовых практик производства знаний, коммуникации и социализации. На наших глазах происходит масштабный сдвиг в сторону массовой генерации контента: благодаря ИИ практически исчезают барьеры входа в создание текстов, изображений и видео, усиливаются позиции отдельных авторов и малых команд. Генеративный ИИ в России уже применяет каждый шестой интернет-пользователь, что указывает на значительный потенциал дальнейшего распространения технологии, появления мультимодального контента и новых форм самовыражения. Наряду с трансформацией творческого процесса ИИ меняет и сферу образования. В цифровой среде активно развиваются адаптивные образовательные системы, позволяющие сделать обучение более персонализированным и непрерывным. Интеграция ИИ в социальные и контентные платформы усиливает роль алгоритмов в формировании информационной повестки и структуры социальных связей. При этом массовое производство синтетического контента повышает риски распространения фейковых новостей, затрудняет оценку достоверности информации и снижает доверие к ней. Значительная часть пользователей ИИ уже связывают его развитие с усилением зависимости от алгоритмов и ростом возможностей для манипулирования общественным мнением, около 30% испытывают тревогу по поводу растущего влияния ИИ. Одновременно обостряются вопросы уязвимости цифровой среды, конфиденциальности и безопасности персональных данных: расширение использования ИИ сопровождается экспоненциальным ростом объемов информации, превращая ее защиту в системный риск. Рост доступности инструментов генерации контента размывает границы авторства и прав интеллектуальной собственности.</p> <p>Резюме: ИИ выходит за рамки прикладных задач и отдельных индустриальных решений, меняя саму логику функционирования систем управления, экономики и общества. Все трансформации тесно переплетены: изменения в сфере управления создают новые экономические условия, которые, в свою очередь, влияют на социальные нормы и институты; а на их стыке проявляются глубокие структурные сдвиги и разломы. В совокупности эти процессы указывают на формирование новой социальной среды, в которой ключевое значение приобретает не только доступ к передовым технологиям, но и способность общества выстраивать механизмы доверия, контроля и распределения ответственности в условиях повсеместного присутствия ИИ.</p> <p>«Развитие ИИ характеризуется сочетанием двух встречных процессов. С одной стороны, технология становится массовым инструментом: порог входа снижается, в разработку и применение вовлекаются новые участники. С другой стороны, контроль над данными, вычислительными мощностями, инфраструктурой и моделями все заметнее концентрируется у ограниченного числа технологических лидеров. На уровне социума ИИ расширяет возможности коммуникации, самовыражения, образования, способы производства и распространения знаний, но также усложняет механизмы доверия, побуждая общество заново определять, какую информацию считать достоверной и заслуживающей внимания. В сфере управления ИИ открывает возможности перехода от реактивной модели к предиктивной, при которой решения принимаются не постфактум, а на основе раннего выявления изменений в поведении рынков, граждан и производственных систем. На макроуровне ИИ становится инфраструктурой новой производительности и, подобно электричеству или интернету, постепенно проникает во все сектора, меняя логику взаимодействия экономических агентов. Экономический эффект ИИ при этом распределяется неравномерно: в выигрыше оказываются не те, кто внедряет точечные решения, а те, кто перестраивает бизнес-модели, организационные процессы, управление данными и компетенции работников вокруг мультиагентных ИИ-систем. Выполненное с помощью системы iFORA картирование ключевых разломов показывает, что речь уже идет не о трансформации отдельных отраслей под влиянием ИИ, а о глубокой перестройке системы управления, экономики и общественных отношений. Результативность этой ИИ-трансформации будет зависеть от того, смогут ли институты превратить ИИ из инновации в надежную инфраструктуру развития с прозрачными правилами, механизмами ответственности и управления рисками», — отметил Константин Вишневский директор Центра стратегической аналитики и больших данных ИСИЭЗ НИУ ВШЭ.</p> Институт статистических исследований и экономики знаний (ИСИЭЗ) НИУ ВШЭ с помощью системы iFORA картировал точки … message https://www.itweek.ru/themes/detail.php?ID=234918 Fri, 29 May 2026 10:31:28 +0300 <p>«Яндекс» представил новую нейросеть Alice AI LLM Flash — это быстрая языковая модель, которая оптимизирована под наиболее популярные задачи бизнеса. Она хорошо работает с текстами и документами — а это почти 60% от всех b2b-запросов к моделям Яндекса. С помощью новой модели компании смогут решать эти задачи быстрее и почти в 5 раз дешевле, чем ранее. Новая модель уже доступна бизнесу в Yandex AI Studio.</p> <p>Alice AI LLM Flash эффективна в задачах, которые требуют качественного ответа при высокой скорости отклика — например, в диалогах или при обработке большого количества данных. Она подойдет для модерации контента на сайте, классификации обращений в техподдержку или диалога с клиентом. Новая модель позволит малому бизнесу использовать нейросети с минимальными финансовыми затратами, в то же время она поможет крупным компаниям сэкономить на обработке массовых запросов, сохранив хорошее качество и высокую скорость ответов. Она будет востребована у банков, ритейлеров, телеком-операторов и других компаний с большим объемом однотипных задач, в которых критически важна скорость ответа.</p> <p>Alice AI LLM Flash в 56% случаев превосходит нейросеть GPT-5.4 mini по качеству решения бизнес‑задач. При этом она сохраняет все преимущества флагманской модели Alice AI LLM: она превосходит западную модель в диалоговых сценариях (лучше в 73% случаев), обобщении и структуризации текста (66%) и в поиске данных по файлам и базам знаний (61%).</p> <p>«Яндекс выходит на новый для себя рынок моделей, созданных специально под запросы бизнеса. Alice AI LLM Flash поможет российским компаниям перейти на российские нейросети для автоматизации работы с огромными объемами данных. Новая модель — это собственная разработка, прошедшая полный цикл обучения на данных Яндекса. Она сопоставима по стоимости с ближайшим западным аналогом GPT-5.4 mini, при этом мы также обеспечиваем безопасность обрабатываемых данных и стабильную работу в России», — рассказал руководитель платформы Yandex AI Studio Артур Самигуллин.</p> <p>Также на платформе открыли доступ к опенсорсной модели DeepSeek V4 Flash. Это первая в России доступная в облаке модель с контекстным окном в 1 млн токенов. Ее можно использовать для разработки корпоративных ИИ-агентов, анализа больших документов и решения сложных многоэтапных задач. При этом она в полтора раза дешевле предыдущей версии DeepSeek V3.2.</p> «Яндекс» представил новую нейросеть Alice AI LLM Flash — это быстрая языковая модель, которая оптимизирована под … message https://www.itweek.ru/themes/detail.php?ID=234917 Fri, 29 May 2026 10:29:57 +0300 <p>Компания МУЛЬТИФАКТОР, российский разработчик ИБ- и ИТ-решений, объявила о масштабном обновлении сервиса распределённого мониторинга MULTISTATUS.</p> <p>Теперь компании могут полностью контролировать доступность своих интернет-ресурсов. Благодаря новым улучшениям они получают возможность мгновенно запускать непрерывный мониторинг, создавать публичные статусные страницы и использовать инструменты для расчёта SLA. А расширенная сеть точек проверки и гибкая система уведомлений позволяют проактивно выявлять сбои на региональном уровне и оперативно реагировать на инциденты.</p> <p>Реализована возможность перевода ресурсов с разовых проверок на непрерывный круглосуточный контроль. Пользователи могут непрерывно отслеживать состояние сервисов по отдельным типам проверок или использовать комплексные сценарии контроля инфраструктуры.</p> <p>Что доступно: мониторинг HTTP/HTTPS, Ping, TCP-портов, SSL-сертификатов и доменов.</p> <p>Появился новый функционал для ускорения запуска мониторинга. В рамках пилотного внедрения специалисты анализируют связанную инфраструктуру заказчика (домены и поддомены), определяют ресурсы, требующие контроля, и формируют рекомендации по настройке.</p> <p>Главное преимущество этой функции — заказчик может перейти к тестированию платформы и постановке ресурсов на мониторинг без длительной ручной настройки, существенно сокращая время внедрения. В дальнейшем этот инструмент (инструмент автоматического обнаружения веб-ресурсов) будет доступен как дополнительная автоматическая опция.</p> <p>MULTISTATUS автоматически рассчитывает показатели доступности сервисов на основе настроенных правил инцидентов и позволяет анализировать уровень доступности за различные периоды времени. Пользователи могут анализировать уровень доступности, отслеживать время простоя и визуализировать данные через настраиваемые дашборды.</p> <p>Увеличилось количество точек проверки до восьми локаций в России, Казахстане и Европе. А для заказчиков стала доступна возможность подключения кастомных локаций.</p> <p>Расширение географии мониторинга позволяет быстрее выявлять региональные проблемы доступности, сбои у операторов связи или деградацию работы сервисов в отдельных сегментах сети.</p> <p>В новой версии MULTISTATUS появились публичные статусные страницы, которые можно использовать для внешнего информирования заказчиков и партнёров о состоянии инфраструктуры.</p> <p>Пользователи могут публиковать страницы со статусом сервисов, отображать SLA. В ближайшее время планируется поддержка размещения таких страниц на собственном домене компании-заказчика.</p> <p>Теперь сервис поддерживает группировку оповещений по ресурсам и сценариям инцидентов с отправкой уведомлений через электронную почту, Telegram или голосовые звонки дежурным специалистам. Такой подход позволяет выстраивать разные сценарии реагирования в зависимости от критичности инцидента.</p> <p>Отдельно стоит отметить запуск полноценного личного кабинета. Администраторы получили единое пространство для управления ресурсами, мониторингом, дашбордами, правилами инцидентов и API-интеграциями.</p> <p>Компания МУЛЬТИФАКТОР представила новый сайт MULTISTATUS и пересмотрела условия использования сервиса. Стоимость теперь рассчитывается прозрачно — исходя из количества контролируемых ресурсов, частоты и географии проверок.</p> <p>Одной из ключевых особенностей MULTISTATUS остаётся собственный механизм оценки доступности инфраструктуры с точки зрения конечного пользователя.</p> <p>Сервис использует сети мониторинговых агентов, размещённых в различных дата-центрах и регионах. Этот подход помогает выявлять локальные сетевые проблемы и оперативно реагировать на инциденты до того, как они повлияют на бизнес-процессы.</p> Компания МУЛЬТИФАКТОР, российский разработчик ИБ- и ИТ-решений, объявила о масштабном обновлении сервиса … message https://www.itweek.ru/themes/detail.php?ID=234916 Fri, 29 May 2026 10:26:51 +0300 <p>Мобильное приложение банка ВБРР, разработанное на базе системы ДБО BSS, укрепило позиции в рейтинге RuStore.</p> <p>Команда ВБРР реализовала программу по изучению клиентского опыта и анализу лучших рыночных практик, уделив особое внимание развитию платежных сервисов и удобству ежедневных операций, а BSS обеспечила необходимые технологические доработки и развитие платформы. </p> <p>Дополнительным фактором роста пользовательской оценки стало внедрение SDK Review, который позволил банку выстроить более системную работу с обратной связью клиентов. </p> <p>В результате приложение банка ВБРР получило оценку 4,4 на основе более чем 14 тысяч отзывов и преодолел отметку в 400 тысяч скачиваний. За последнее время рейтинг приложения вырос на 1,6 пункта. </p> <p>Клиенты отмечают повышение стабильности и удобства приложения, а также качество работы поддержки. </p> <p>ВБРР онлайн — ключевой канал взаимодействия с клиентами, банк последовательно инвестирует в его развитие и пользовательский опыт. Рост рейтинга и положительная обратная связь подтверждают эффективность цифровой стратегии ВБРР онлайн и технологического партнерства с BSS</p> <p>«Проект с ВБРР показывает, что современные технологии и постоянная работа с обратной связью клиентов позволяют банкам успешно конкурировать с крупнейшими игроками рынка. По уровню пользовательских оценок приложение ВБРР сегодня опережает приложения ряда крупнейших игроков рынка. Мы рады, что наша технологическая поддержка и экспертиза помогают партнерам достигать таких результатов», — прокомментировал Виталий Патешман, директор по продажам компании BSS.</p> Мобильное приложение банка ВБРР, разработанное на базе системы ДБО BSS, укрепило позиции в рейтинге RuStore. Команда … message https://www.itweek.ru/themes/detail.php?ID=234914 Fri, 29 May 2026 09:15:54 +0300 <p>Когда-то производители соревновались за объемы сырья и дешевизну рабочих рук, теперь же борьба идет за чистые данные и обучающие алгоритмы. Перемены видны в заводских цехах, логистических хабах и на фермах, хотя многие участники рынка все еще скептически поглядывают на «умные» технологии. Пока одни примеряют на себя роль цифровых первопроходцев, другие продолжают жить по старинке, полагаясь на интуицию технолога и записи в бумажных журналах.</p> <p>В этой статье мы будем использовать термин «нейроаналитика» расширительно: под ним понимаются любые технологии искусственного интеллекта, применяемые в пищевой промышленности и смежных отраслях, — от компьютерного зрения и предиктивных моделей до генеративных сетей и оптимизационных алгоритмов. Главный объединяющий признак — работа с данными, а не жестко заданные правила.</p> <h3>Еда по алгоритмам</h3> <p>Современный ИИ в пищевой индустрии — это не только футуристичные роботы-повара, которые, к слову, уже существуют. Речь о разросшемся семействе технологий, готовых взять на себя массу типовых операций и совершать их на высоких скоростях. Компьютерное зрение контролирует уровень налива и целостность этикетки, предиктивная аналитика предугадывает спрос на молоко за месяц вперед, алгоритмы логистики выстраивают маршруты так, чтобы творог не превращался в просрочку, а генеративные модели позволяют технологам разрабатывать новые рецептуры без увеличения себестоимости. По оценкам аналитиков «Яков и Партнеры», совокупный экономический потенциал подобных решений в российском АПК и пищепроме достигает 6 млрд. долл. ежегодно. И крупные игроки уже научились превращать алгоритмы в живые деньги. Один из лидеров отечественной мясопереработки фиксирует порядка 300 млн. руб. ежегодной экономии и дополнительный рост выручки на <nobr>1,5-2%</nobr> исключительно за счет прироста производительности, который обеспечило внедрение ИИ.</p> <p>Согласно данным Аналитического центра при Правительстве РФ, внедрение ИИ в отрасли позволяет в среднем:</p> <ol> <li> снизить операционные расходы (OPEX) в среднем на <nobr>10-15%,</nobr> а в отдельных проектах — до 25%;</li> <li> сократить потери сырья и списания готовой продукции до 30%;</li> <li> повысить производительность труда на <nobr>15-40%</nobr> за счет автоматизации рутины.</li> </ol> <p>Впрочем, от осознания выгод до их воплощения в живых деньгах — пропасть. И переступить через нее способны лишь те, кто определил зоны максимальной окупаемости (еще на стадии планирования).</p> <h3>Зоны максимальной окупаемости</h3> <p>Сетевой ритейл задает в этом смысле собственный темп: вложенный рубль возвращается за полгода-год, что по меркам промышленного внедрения ощущается почти мгновенно. Огромные массивы данных и низкая маржинальность <nobr>(2-5%)</nobr> вынуждают ритейлеров выжимать резервы отовсюду. Нейросети, умеющие переваривать погодные сводки, промо-календарь и историю продаж, подходят для такой задачи как нельзя лучше. Одна федеральная сеть уже отдала под управление алгоритмов 80% заказов для своих магазинов — в результате утилизация нераспроданного товара пошла вниз, а полки перестали пустовать. Сервисы быстрой доставки еды шагнули еще дальше, доверив искусственному интеллекту маршрутизацию курьеров и сборку заказов, и теперь время ожидания исчисляется минутами — такими же стремительными, как сам сервис.</p> <p>В сегменте товаров с коротким сроком годности цена ошибки прогноза равна полному списанию продукта. Крупный молочный производитель добился роста точности прогнозов более чем на 3 процентных пункта и сократил списания на треть. Годовая экономия оценивается в <nobr>40-50 млн.</nobr> руб. Масштабный проект реализован и на одном из крупных хлебозаводов: нейросети взяли на себя контроль входящих документов объемом 2 млн. страниц в месяц. Время проверки сократилось с недель до одной рабочей смены, а объем ручной обработки снизился на 40%.</p> <p>Производственный опыт, накопленный десятилетиями, сталкивается с ограничениями при масштабировании. Нейроаналитика позволяет оцифровать интуицию технолога и превратить сенсорный контроль в стандартизированный процесс. При массовом производстве (десятки тысяч единиц в сутки) разница между интуитивными решениями и решениями на основе данных оборачивается миллионами рублей недополученной прибыли.</p> <h3>От поля до конвейера — скрытые резервы</h3> <p>Нейроаналитика обнаруживает то, что долго ускользало от внимания, — чаще всего в устоявшихся процессах (без планов на изменения). Речь о полях, фермах, конвейерных линиях и курьерских маршрутах — словом, обо всей цепочке, проходя по которой сырье превращается в готовый продукт и добирается до конечного потребителя. Скрытые резервы редко заметны сразу — их выявляют алгоритмы, анализирующие данные с датчиков и камер (обученные находить статистические аномалии).</p> <h3>Самые заметные зоны, где нейросетям делегированы задачи</h3> <ul> <li> <strong>Агрохолдинги</strong><strong>.</strong> ИИ переводит управление посевами и поголовьем на потоковую аналитику. Вместо усредненных календарных планов и решений «по погоде» алгоритмы ежедневно пересчитывают дозу удобрений, опираясь на спутниковые снимки и данные почвенных датчиков; в животноводстве же предиктивные модели предупреждают о риске заболевания у конкретного животного за несколько дней до первых симптомов.</li> <li><strong>Переработка</strong><strong>.</strong> Нейросеть встраивает оптический контроль на линиях упаковки, розлива и сортировки, где плотность потока превышает сотни единиц в минуту. Камеры с ИИ-обработкой кадра непрерывно проверяют геометрию изделия, читаемость кода, отсутствие вмятин и корректность маркировки.</li> <li><strong>Общепит и доставка готовой еды</strong><strong>.</strong> Программа берет на себя задачи ценообразования и оптимизации маршрутов «последней мили», она в режиме реального времени агрегирует и анализирует данные по спросу, дорожной ситуации и загрузке курьеров, гарантируя соблюдение целевого показателя среднего времени ожидания.</li> </ul> <p>Крупные хозяйства сегодня поставляют не только зерно или мясо, но и гигабайты данных телеметрии. Начинать анализ лучше всего с животноводческих комплексов — там окупаемость заметна сразу. «Умные» ошейники на коровах — это уже не забава и не игрушка, а инструмент, который круглосуточно отслеживает здоровье и период половой охоты. Результат: рост надоев и снижение падежа без привлечения дополнительных специалистов. От фермы маршрут анализа естественно уходит в поле, где на смену ошейникам приходят оптические датчики и спутниковая навигация. Система автопилотирования ведет комбайн вдоль кромки с точностью до 10 см, не «слепнет» при потере спутникового сигнала и даже способен распознавать препятствия. Экономия на каждом комбайне превышает 2 млн. руб. с тысячи гектаров, на тракторах — свыше 2,6 млн. руб. Агрохолдинг с парком в 500 машин способен сберечь за сезон порядка 450 млн. руб. Практика внедрена в более чем 1,2 тыс. фермерских хозяйств и у трех десятков крупнейших игроков. Опыт этих предприятий постепенно экспортируется, сообщают разработчики систем автопилотирования. По окончании работы техники расчет урожайности выполняется нейросетями. На Кубани два года испытывают модель, которая на основе текущих методов внесения удобрений корректирует их дозировку (по итогам испытаний на 17 полях урожайность выросла на 6,3% при средней экономии 24 кг удобрений на гектар и общем эффекте в 1,86 млн. руб.).</p> <blockquote> <p><em>Реактивное управление — это фиксация потерь постфактум. Предиктивная аналитика переносит фокус внимания менеджмента на опережение событий. Прогноз спроса, выполненный в отдельных категориях на коротком горизонте с точностью до 85</em><em>-</em><em>90%, снимает необходимость держать раздутые страховые запасы, высвобождая оборотный капитал, который можно направить на развитие продуктовой линейки.</em></p> </blockquote> <h3>Препятствия, знакомые каждому, кто запускал пилот</h3> <p>При обилии успешных примеров и наличии государственной поддержки (в рамках нацпрограммы «Цифровая экономика»: субсидии до 50% затрат на ПО, льготные займы РФРИТ) некоторые предприятия среднего и крупного сегмента замедляют свое движение. Многие из ограничений носят организационный характер.</p> <ul> <li> <strong>Качество первичных данных</strong><strong>.</strong> Нейросеть использует оцифрованную, структурированную информацию. Если показатели хранятся в бумажных журналах, Excel-таблицах или памяти технологов, алгоритм не может на них обучиться. Попытки дать ИИ неочищенные или недостоверные сведения не принесут ожидаемого результата.</li> <li> <strong>Кадровый дефицит на стыке отраслей</strong><strong>.</strong> Рынку нужны специалисты, одинаково хорошо понимающие специфику пищевых технологий и методы машинного обучения (пока в стране таких немного).</li> <li><strong>Адаптация к санкционным условиям</strong><strong>.</strong> Закупка прецизионных датчиков и камер сопряжена с объективными сложностями — рынок переориентируется на азиатских и отечественных производителей, однако логистические цепочки пока нестабильны.</li> <li><strong>Инерция управленческого мышления</strong><strong>.</strong> Собственник или технолог с <nobr>30-летним</nobr> стажем склонен доверять личному опыту больше, чем непрозрачному для него алгоритму. Опасение утратить контроль над процессом блокирует запуск пилотных проектов.</li> </ul> <blockquote> <p><em>Собирать модель машинного обучения с нуля совсем не обязательно — на рынке уже хватает тиражируемых решений, которые без особого драматизма встраиваются в действующий ИТ-ландшафт. С ними предприятие не строит исследовательский R&D-контур и не нанимает команду MLOps-инженеров до того, как получен первый экономический результат. Цифровизация сводится к подбору, адаптации и запуску готового решения, а стартовая экспертиза ограничивается умением интегратора развернуть модель на существующих данных и привязать ее к заводской учетной системе.</em></p> </blockquote> <h3>Анатомия управленческого решения</h3> <p>Любой разговор о цифровизации рано или поздно упирается в человека, который принимает окончательное решение, и здесь нейроаналитика сталкивается с самым неудобным барьером — многолетней привычкой полагаться на собственный опыт и чутье. Технолог с тридцатилетним стажем или собственник, построивший завод с нуля, редко готовы променять интуицию на график, сгенерированный моделью, в чью внутреннюю механику они не могут заглянуть. Спорить с таким оппонентом на языке алгоритмов бессмысленно, а вот предъявить цифры с одной-единственной линии после двухнедельного пилота — работает почти безотказно. Параметры просты и не требуют интерпретации: процент снижения незапланированных остановок, объем возвратов, килограммы списанного сырья. Дальше решение о масштабировании рождается уже не в кабинете, а в цехе, где начальник смены, увидевший результат своими глазами, становится самым убедительным сторонником перемен.</p> <p>Когда технология встраивается в ежедневный контур, следом меняется система координат для персонала. Освобожденные от рутины люди переключаются на анализ отклонений и настройку процесса, а директор завода вместо утренней сводки о ночных происшествиях получает набор сценариев на ближайшую смену и рекомендации по загрузке мощностей. Система KPI перестраивается незаметно, но основательно. Раньше эффективность начальника цеха мерили скоростью реакции на сбой, теперь — умением этот сбой предотвратить. Вся управленческая конструкция смещается из реактивного режима в профилактический; этот сдвиг, пожалуй, и есть главный финансовый итог внедрения.</p> <blockquote> <p><em>Отсрочка внедрения аналитических систем обходится бизнесу дороже инвестиций в их установку. Каждый месяц работы предприятия на исторических данных, без прогностических моделей, консервирует перерасход сырья и неотлаженную логистику. Обострение дефицита рабочих рук оставляет производителям два сценария: роботизация и нейросетевое управление либо постепенная потеря рыночной доли.</em></p> </blockquote> <h3>Основные выводы</h3> <ol> <li> Технологии промышленной нейроаналитики приносят измеряемый финансовый результат в горизонте <nobr>6-12</nobr> месяцев для ритейла и <nobr>1-2</nobr> года для переработки и АПК. Снижение OPEX на <nobr>10-25%</nobr> становится не столько поводом для гордости, сколько базовым ориентиром.</li> <li> Массивы исторической информации, очищенные и размеченные, превращаются в материальный ресурс предприятия наравне с оборудованием и сырьем. Инвестиции в их упорядочивание определяют скорость и качество внедрения ИИ.</li> <li> Конкурентное преимущество получают компании, которые выращивают или привлекают специалистов, способных одновременно разобраться и в технологии производства, и в логике построения моделей.</li> <li> Тиражируемые «коробочные» продукты позволяют начинать цифровую трансформацию, не дожидаясь формирования собственной команды разработчиков.</li> <li> Прорыв случается, когда руководитель начинает использовать нейроаналитику как стратегический актив, а не просто ИТ-сервис.</li> </ol> <p>Скорее всего в ближайшие <nobr>5-7</nobr> лет российский пищевой сектор незаметно для внешнего наблюдателя пересмотрит собственное представление о норме. Компании, успевшие сделать ставку на data-driven-менеджмент, перестанут обсуждать искусственный интеллект как нечто внешнее — нейроаналитика станет такой же рутиной, как ежемесячный отчет о прибылях и убытках, и будет вызывать примерно столько же споров. Те, кто отложит цифровизацию до лучших времен, в какой-то момент обнаружат, что соревнуются уже не с соседним заводом, а с полностью автоматизированной системой, где каждое действие просчитано на несколько шагов вперед.</p> <p>#IMAGE_234915#</p> Когда-то производители соревновались за объемы сырья и дешевизну рабочих рук, теперь же борьба идет за чистые … article Константин Деревсков, генеральный директор ООО “Старт Качества” https://www.itweek.ru/themes/detail.php?ID=234913 Fri, 29 May 2026 09:08:28 +0300 <p><em>Один и тот же набор данных не должен существовать дважды, чтобы быть полезным. Однако в большинстве сред это происходит. Одна версия хранится в файловой системе, предназначенной для корпоративных пользователей и приложений, которые ожидают путей, каталогов и изменяемого состояния. Другая версия экспортируется в объектное хранилище, чтобы распределенные движки и конвейеры искусственного интеллекта могли эффективно ее обрабатывать. Эти копии создаются не намеренно. Они являются артефактами несовместимых интерфейсов хранения, пишет на портале </em><em>BigDataWire</em> <em>Арон Бранд, технический директор CTERA.</em></p> <p>В небольших масштабах это дублирование допустимо. В масштабах ИИ оно становится структурной неэффективностью. Объемы хранения увеличиваются быстрее, чем сами данные, конвейеры накапливают логику синхронизации, а вычисления все больше зависят от перемещения данных, а не от их обработки.</p> <p>Почему это происходит?</p> <h3>Две модели, два предположения о данных</h3> <p>Файловые системы и объектные хранилища не являются взаимозаменяемыми абстракциями. Они кодируют принципиально разные предположения о том, как ведут себя данные.</p> <p>Файловые системы отдают приоритет структуре, координации и изменяемости. Объектное хранилище отдает приоритет экзабайтному масштабу, простоте и параллелизму.</p> <p>Ни одна из моделей не является ошибочной. Каждая оптимизирована для разных классов рабочих нагрузок. Проблема в том, что современные конвейеры данных требуют одновременного применения обеих моделей.</p> <h3>Рабочие нагрузки ИИ охватывают оба мира</h3> <p>Конвейеры ИИ не всегда четко согласуются с одной из парадигм.</p> <p>Обучение и крупномасштабная аналитика хорошо работают с семантикой объектного хранилища: высокопроизводительное параллельное чтение на распределенных вычислительных узлах. В то же время исходные данные часто создаются в средах, зависящих от семантики файлов, где структура, инкрементальные обновления, блокировка и обеспечение соблюдения политик имеют важное значение.</p> <p>Это создает постоянное несоответствие.</p> <p>На практике организации компенсируют это перемещением данных. Файловые наборы данных экспортируются в объектное хранилище для аналитики. Объектные данные восстанавливаются в файловых системах для последующих рабочих процессов. Конвейеры расширяются, включая этапы подготовки, копирования и преобразования в качестве основных шагов. То, что начинается как интеграция, превращается в зависимость, и в конечном итоге конвейер формируется скорее ограничениями хранилища, чем логикой данных.</p> <h3>Объектное хранилище как плоскость данных ИИ</h3> <p>Объектное хранилище стало основой по умолчанию для крупномасштабной аналитики и ИИ, поскольку оно соответствует поведению современных вычислительных систем.</p> <p>Распределенные задачи обучения, механизмы запросов и конвейеры обработки признаков предполагают параллельный доступ, взаимодействие без сохранения состояния и большие последовательные операции чтения на неизменяемых наборах данных. Объектное хранилище естественным образом удовлетворяет этим предположениям.</p> <p>Недавние достижения укрепили эту роль. Высокопроизводительное объектное хранилище все чаще поддерживает прямые пути передачи данных, такие как S3 через RDMA, что снижает участие ЦП и позволяет данным перемещаться непосредственно в память графического процессора. На этом этапе пропускная способность хранилища — это не просто фоновая проблема. Она напрямую определяет использование вычислительных кластеров.</p> <p>Это имеет архитектурные последствия. При пропускной способности в сотни Гбит/с любой слой, который перехватывает или преобразует операции ввода-вывода между вычислительными ресурсами и объектным хранилищем, вносит накладные расходы на ЦП и ограничивает пропускную способность. В масштабах ИИ эти накладные расходы уже не являются незначительными. Часто они становятся узким местом.</p> <h3>Файлы как интерфейс для агентов ИИ</h3> <p>Если объектное хранилище становится плоскостью данных, то файлы вновь становятся плоскостью управления для систем, управляемых ИИ, в рамках федеративной ткани данных.</p> <p>Агенты ИИ обладают состоянием. Они создают контекст, сохраняют промежуточные результаты и координируют действия во времени. Файловая система поддерживает это естественным образом: каталоги организуют работу, пути кодируют связи, а само пространство имен становится общей памятью, в которой могут перемещаться как люди, так и агенты.</p> <p>В отличие от этого, объектное хранилище является плоским. Агенты должны восстанавливать структуру, выводить связи и управлять состоянием извне, что добавляет сложности.</p> <p>Файловая система делает контекст явным и непосредственно используемым. Это особенно важно для мультиагентных рабочих процессов. Файлы выступают в качестве уровня координации, где агенты взаимодействуют, читая и записывая артефакты, организуя задачи и отслеживая прогресс в общем рабочем пространстве.</p> <p>Сдвиг происходит не в плане ухода от объектного хранилища, а в сторону наложения на него семантики файлов. Объектное хранилище остается масштабируемой основой, в то время как файлы обеспечивают интерфейс, который лучше соответствует тому, как работают агенты: управление контекстом, памятью и взаимодействием.</p> <h3>Компромиссные подходы создают новые узкие места</h3> <p>Исторически усилия по унификации доступа к файлам и объектам принимали две формы.</p> <p>Подходы, основанные на копировании, экспортируют данные в объектное хранилище для аналитики. Это сохраняет производительность вычислительных нагрузок, но приводит к задержкам, дублированию и фрагментации управления.</p> <p>Подходы, основанные на шлюзах, преобразуют протоколы в реальном времени, предоставляя доступ к файловым данным через объектные API. Это позволяет избежать дублирования, но вносит накладные расходы на преобразование, зависящие от ЦП, и ограничивает пропускную способность.</p> <p>Оба подхода решают часть проблемы, но усиливают другую. Один оптимизирует формат данных, другой — согласованность доступа. Ни один из них не устраняет фундаментальное несоответствие.</p> <h3>К унифицированной архитектуре хранения</h3> <p>В современных платформах данных наблюдается тенденция к конвергенции, а не к трансляции.</p> <p>Конвергентная архитектура рассматривает файловые и объектные интерфейсы как два представления одних и тех же данных. Данные записываются один раз, хранятся в формате, непосредственно используемом объектно-ориентированными вычислениями, и предоставляются через файловую семантику там, где это необходимо. Нет дублирования, нет конвейера экспорта и нет трансляции протоколов на критическом пути.</p> <p>Разница очевидна и существенна. Промежуточные этапы исчезают. Данные не нужно перемещать, изменять или повторно предоставлять, прежде чем их можно будет использовать.</p> <p>Хранилище перестает быть чем-то, вокруг чего работают конвейеры, и становится тем, с чем они работают напрямую. Для инженеров данных это коренным образом меняет проектирование конвейеров. Вместо того чтобы рассматривать перемещение данных как необходимое условие, конвейеры могут работать непосредственно с авторитетным набором данных. Доступ заменяет извлечение в качестве первого шага. Преобразование и анализ выполняются без промежуточных этапов.</p> <p>Это снижает сложность конвейера, повышает актуальность данных и уменьшает накладные расходы на хранение. Что еще важнее, это восстанавливает согласованность между вычислительными ресурсами и данными. Рабочие нагрузки выполняются там, где данные уже существуют, вместо того, чтобы ждать их перемещения.</p> <p>Это также открывает новые возможности для взаимодействия. Существующие наборы объектных данных могут быть немедленно доступны в виде файловых систем без миграции. Данные, создаваемые приложениями, могут использоваться конвейерами ИИ в режиме реального времени. Агенты могут работать непосредственно с живыми наборами данных, используя файловую семантику для навигации и одновременно объектное хранилище для масштабируемости.</p> <h3>Заключение</h3> <p>Файловое и объектное хранение не являются конкурирующими парадигмами. Это взаимодополняющие абстракции, которые развивались в различных условиях.</p> <p>Изменилась природа рабочих нагрузок. Системы ИИ, и все чаще агенты ИИ, требуют и того, и другого. Им необходима масштабируемость и параллелизм объектного хранилища, а также структура и доступность файловых систем.</p> <p>Поддержание их в качестве отдельных систем заставляет инженеров данных преодолевать разрыв посредством копирования, преобразования и оркестровки. Такой подход не масштабируется. Сейчас наметился способ решения этой проблемы. Благодаря конвергенции доступа к файлам и объектам в единую, федеративную ткань данных, хранилище данных становится соответствующим тому, как на самом деле работают современные системы. Оно перестает быть чем-то, что конвейеры обходят стороной. Оно становится частью самой модели выполнения.</p> Один и тот же набор данных не должен существовать дважды, чтобы быть полезным. Однако в большинстве сред это … article https://www.itweek.ru/themes/detail.php?ID=234906 Thu, 28 May 2026 09:56:49 +0300 <p><em>Инфраструктура современного оператора связи стала слишком динамичной и многослойной, чтобы управлять ею через ручные сверки, локальные таблицы и несвязанные учетные процессы. Физические ресурсы, логические каналы, виртуальные функции, сервисные зависимости, склад и договоры меняются быстрее, чем обновляются данные о них. Из-за этого учет перестает быть технической формальностью. Для крупного оператора нормально, что информация о ресурсах и связанных с ними объектах распределена между разными системами. Критично другое: выстроены ли между этими системами интеграции и включено ли обновление данных в эксплуатационные процессы. Перед подключением, ремонтом или модернизацией специалисты должны проверить доступность ресурса, его связи с услугами и зону ответственности. В управляемой модели они получают эту информацию в системе до начала работ, а не восстанавливают ее вручную по таблицам, документам и ситуации на объекте.</em></p> <p><em>Для ИТ-директора это не вопрос аккуратности справочников, а вопрос управляемости. Несогласованные данные увеличивают трудозатраты, замедляют изменения, увеличивают время восстановления при авариях и риск штрафов за нарушение SLA, а также могут привести к ошибкам при оценке технической возможности подключения. В итоге бизнес получает дублирующие закупки, простаивающее оборудование, неиспользуемые лицензии и теневую инфраструктуру. </em><em>Рассмотрим</em><em>, почему ручной и фрагментированный учет больше не справляется с инфраструктурой современных операторов связи и какие риски это создает для эксплуатации и бизнеса</em><em>.</em></p> <h3>Проблема 1. Нет единого источника доверия по данным инфраструктуры</h3> <p>В телекоме проблема начинается не с самого факта, что данные распределены между OSS, ERP, системами техподдержки, складом и локальными учетными решениями. Для крупного оператора это нормальный ИТ-ландшафт: разные контуры отвечают за эксплуатацию, финансы, закупки, сервисные процессы и SLA.</p> <p>Риск возникает, когда между этими контурами нет согласованной модели данных и надежной синхронизации. Один и тот же объект сети существует сразу в нескольких ролях: как технический ресурс, бухгалтерский актив, элемент сервиса, складская позиция или объект обслуживания. Если статусы, связи и параметры обновляются несинхронно, оператор получает несколько версий одной инфраструктуры.</p> <p>Дальше это напрямую влияет на процессы. Перед подключением клиента, модернизацией участка сети или устранением аварии командам приходится вручную сверять данные: где ресурс реально находится, свободен ли он, на каком он балансе, какие сервисы от него зависят и кто отвечает за его состояние. Большая часть времени уходит не на выполнение работ, а на восстановление актуальной картины сети.</p> <p>Решение не в том, чтобы заменить все системы одним монолитом. Современный подход: модульный ИТ-ландшафт, где каждый контур сохраняет свою функцию, но работает через стандартизированные интерфейсы и опирается на единую модель инфраструктурных данных. Тогда у оператора появляется не набор разрозненных «версий правды», а управляемый контур данных о ресурсах, их статусе, связях, загрузке и жизненном цикле.</p> <h3>Проблема 2. Критичные знания об инфраструктуре остаются вне системы</h3> <p>Excel остается удобным инструментом для разовых задач, но плохо работает как основной контур учета инфраструктуры. Проблема быстро выходит за пределы самого файла: таблицы начинают жить на локальных компьютерах, в почте, на сетевых дисках и в личных папках сотрудников.</p> <p>В телеком-инфраструктуре это особенно рискованно, потому что критичные знания о сети фактически закрепляются не за системой, а за конкретными людьми. Кто-то знает, где лежит актуальная версия таблицы. Кто-то помнит, почему ресурс отмечен как занятый. Кто-то вручную сверяет данные после аварии, модернизации или подключения. Пока эти сотрудники доступны, процесс может выглядеть рабочим. Но при отпуске, увольнении, смене подрядчика или аварийной ситуации компания теряет не только человека, но и часть операционной памяти.</p> <p>Дальше ручной учет начинает тормозить эксплуатацию. Перед выездом бригады, ремонтом, переключением или подключением клиента приходится проверять не только состояние ресурса, но и актуальность самой информации. Часть данных может быть в схемах, таблице, часть в письмах, часть в голове инженера, часть в устаревшей выгрузке из другой системы.</p> <p>Из-за этого растет доля скрытых трудозатрат. Инженеры и технические службы тратят время не на работу с сетью, а на поиск файлов, сверку версий, уточнение статусов и восстановление истории изменений. Для оператора это превращается в операционный риск: в критический момент нельзя быстро понять, какие ресурсы реально доступны, какие работы уже выполнены и на какие данные можно опираться.</p> <h3>Проблема 3. Учет не отражает сетевые и сервисные зависимости</h3> <p>Универсальные учетные системы могут фиксировать оборудование, стоимость, владельца, складской статус или заявку. Но для управления сетью этого недостаточно: телеком-ресурс важен не сам по себе, а через связи с другими ресурсами, сервисами и эксплуатационными процессами.</p> <p>Один и тот же элемент инфраструктуры может быть частью маршрута, участвовать в оказании нескольких услуг, зависеть от физического оборудования, логического ресурса, виртуальной функции и внешнего подрядчика. Если система видит его только как инвентарную единицу или актив, она не показывает главное: какие сервисы завязаны на этот ресурс, что изменится при его переключении, какие SLA могут быть затронуты и кто должен участвовать в работах.</p> <p>Из-за этого часть решений снова уходит в ручной режим. Перед модернизацией, ремонтом или подключением нового клиента командам приходится отдельно восстанавливать зависимости: проверять схемы, уточнять маршруты, сверять данные с эксплуатацией и искать владельцев смежных контуров. Формально учет есть, но он не дает ответа на вопросы, от которых зависит работа сети.</p> <p>Для оператора это означает, что система хранит данные об объектах, но не описывает инфраструктуру как связанную среду. В такой модели сложно оценить влияние изменений, управлять SLA, планировать загрузку ресурсов и быстро разбирать инциденты. Телекому нужна не просто база активов, а модель сети, где физические, логические, виртуальные и сервисные уровни связаны между собой.</p> <h3>Проблема 4. Цифровая модель сети не успевает за изменениями</h3> <p>В операторской сети изменения происходят непрерывно: меняются трассы кабеля, порты на оборудовании, VLAN, IP-адресация, логические каналы, параметры клиентских подключений, состав сервисных цепочек. Часть изменений проходит в рамках плановых работ, часть возникает при авариях, временных переключениях или срочных подключениях клиентов.</p> <p>Проблема появляется, когда факт изменения уже произошел в сети, но еще не отражен в учетной системе. Например, инженер переключил клиента на другой порт, чтобы обойти неисправный участок, но информация осталась только в наряде или комментарии к заявке. В учете прежний порт по-прежнему считается занятым, новый не связан с сервисом, а сама схема подключения уже не соответствует реальности.</p> <p>Такие расхождения быстро накапливаются. Один временный кросс остается постоянным, резервная линия продолжает числиться свободной, демонтированное оборудование остается в модели сети, а освобожденная емкость не возвращается в доступный ресурс. В результате система показывает не текущее состояние инфраструктуры, а ее состояние на момент последней ручной актуализации.</p> <p>Это напрямую влияет на эксплуатацию. При новом подключении оператор может зарезервировать ресурс, который фактически уже используется, и ошибиться в оценке технической возможности. При аварии несоответствие между учетной моделью и реальной конфигурацией увеличивает время поиска поврежденного участка, затронутых услуг и доступного варианта переключения. При модернизации риск возникает не в самих изменениях, а в том, что фактически выполненные работы могут отклониться от запланированной схемы и остаться без корректного отражения в системе.</p> <p>Поэтому актуализация данных должна быть частью эксплуатации, но управление изменениями не должно начинаться с фиксации уже выполненных работ. В управляемой модели сначала в системе проектируется целевая конфигурация: рассчитываются ресурсы, прокладываются маршруты, определяются связи с услугами и формируется задание на выполнение работ. Затем изменения реализуются на объекте, в том числе силами подрядчика, после чего фактический результат сверяется с проектной моделью. Если работы выполнены с отклонениями, они фиксируются в системе и становятся основанием для корректировки данных, оценки последствий и, при необходимости, предъявления требований исполнителю.</p> <p>При таком подходе качество данных становится ответственностью не отдельного сотрудника, который обновляет учет после завершения работ, а всей команды, участвующей в планировании, выполнении и приемке изменений. Цифровая модель сети в этом случае используется не только для отражения текущего состояния инфраструктуры, но и для контроля того, как сеть должна измениться и насколько фактический результат соответствует плану.</p> <h3>Проблема 5. Бизнес не видит фактическую загрузку и доступность ресурсов</h3> <p>Когда учет не отражает фактическое состояние сети, бизнес перестает понимать, какие ресурсы у него реально есть, где они используются и какую нагрузку несут. На уровне эксплуатации это выглядит как техническая проблема, но на уровне управления превращается в прямые потери.</p> <p>Например, в сети может стоять оборудование, которое физически работает, но не связано в учетной системе с конкретным сервисом, площадкой или ответственным подразделением. Или наоборот: ресурс давно выведен из эксплуатации, но продолжает числиться занятым. То же самое происходит с портами, каналами, IP-адресами, лицензиями, стойками, кроссовым оборудованием и складскими остатками.</p> <p>Из-за этого компания начинает закупать то, что уже есть, но не видно в доступном ресурсе: заказывать новые порты, когда свободная емкость есть на соседнем узле, продолжать оплачивать лицензии, которые не используются, держать оборудование в резерве «на всякий случай», потому что нет доверия к данным о фактической загрузке. В итоге CAPEX и OPEX растут не из-за развития сети, а из-за непрозрачности ресурсов.</p> <p>Отдельная проблема — теневая инфраструктура. Это ресурсы, которые появились после временных подключений, аварийных переключений, модернизаций или локальных решений на местах, но не попали в управляемый контур. Они могут работать и даже обслуживать клиентов, но для планирования, финансового учета, аудита и управления рисками фактически остаются невидимыми.</p> <p>В такой ситуации бизнес не может точно оценить утилизацию активов, планировать закупки, управлять запасами и считать экономику модернизации. Формально инфраструктура есть, но ее реальная доступность, загрузка, стоимость владения и жизненный цикл остаются непрозрачными.</p> <h3>Заключение</h3> <p>Все пять проблем сходятся в одной точке: оператор теряет доверие к данным об инфраструктуре. Когда разные системы показывают разные версии сети, часть информации остается в таблицах и у сотрудников, а учет не отражает связи между ресурсами, услугами и зонами ответственности, данные перестают быть основой для решений.</p> <p>Для операторов и служб связи это означает, что проблему нельзя решить очередной инвентаризацией или переносом таблиц в новую систему. Если данные обновляются отдельно от реальных работ в сети, они снова начнут устаревать. Поэтому ключевая задача не в том, чтобы один раз собрать полную базу ресурсов, а в том, чтобы встроить учет в ежедневные процессы: подключение, ремонт, переключение, модернизацию, вывод оборудования из эксплуатации.</p> <p>Такой контур должен фиксировать не только наличие ресурса, но и его статус, связи, загрузку, владельца, историю изменений и влияние на услуги. Тогда перед новым подключением, аварийными работами или плановой модернизацией команда видит не разрозненные записи в разных системах, а актуальную модель инфраструктуры, на которую можно опираться.</p> <p>Но эта модель становится рабочей только в том случае, если ей доверяют сотрудники, которые планируют, выполняют и принимают работы на сети. Система должна помогать им заранее проверить ресурсы и зависимости, зафиксировать фактический результат, увидеть отклонения от плана и актуализировать данные без дополнительных ручных сверок. Иначе даже современный учетный контур начнут обходить через таблицы, перепроверки и локальные договоренности. Поэтому для оператора важно не только внедрить систему, но и правильно встроить ее в ИТ-архитектуру и процессы эксплуатации: настроить интеграции, закрепить порядок актуализации данных и сделать систему рабочим инструментом для всей команды. Только тогда актуальные данные действительно начинают использоваться в ежедневной работе и становятся надежной основой для управления инфраструктурой.</p> <p>#IMAGE_234907#</p> Инфраструктура современного оператора связи стала слишком динамичной и многослойной, чтобы управлять ею через ручные … article Евгений Мошняцкий, коммерческий директор НТЦ АРГУС https://www.itweek.ru/themes/detail.php?ID=234905 Thu, 28 May 2026 09:17:59 +0300 <p><em>Команды разработчиков могут укрепить доверие к коду, сгенерированному агентами искусственного интеллекта, с помощью четырехэтапного фреймворка цикла разработки, ориентированного на агентов (</em><em>Agent</em> <em>Centric</em> <em>Development</em> <em>Cycle</em><em>,</em><em> AC/DC): «направление», «генерация», «проверка» и «исправление» (</em><em>guide</em><em>, </em><em>generate</em><em>, </em><em>verify</em> <em>and</em> <em>solve</em><em>), пишет на портале </em><em>The</em> <em>New</em> <em>Stack</em> <em>Маниш Капур, старший директор по техническому маркетингу продуктов компании Sonar.</em></p> <p>Большая часть дискуссий об ИИ-кодировании по-прежнему сосредоточена на том, насколько быстро машины могут создавать код. Но объем кода — это не то же самое, что прогресс в разработке ПО. Поскольку команды полагаются на агентов для выполнения больших объемов работы, более сложный вопрос заключается в том, могут ли они создать повторяемую систему для управления, проверки и исправления созданного машинами кода, до того, как он создаст риски в дальнейшем.</p> <p>Один из полезных способов осмысления этой системы — это фреймворк AC/DC. В основе AC/DC лежат четыре этапа, которые определяют, как на самом деле работает агентная разработка в масштабе: «направление», «генерация», «проверка», «исправление». Из этих этапов наибольшее внимание рынка привлекает этап генерации кода агентами ИИ. Но на практике успех или провал фреймворка зависит от силы окружающих его слоев. При слабом руководстве агенты начинают с неверных предположений. При слабой проверке ошибки незаметно накапливаются. При слабом решении проблем команды получают в наследство растущую очередь проблем, для решения которых нет масштабируемого способа.</p> <h3>Почему проверка выходит на первый план</h3> <p>В течение многих лет современная разработка ПО была организована в соответствии с человеческим темпом работы. Разработчики писали код относительно небольшими итерациями. Коллеги по команде проверяли его. Конвейер валидировал его. Проблемы обычно выявлялись после того, как код уже был написан, но до того, как они становились слишком большими для понимания.</p> <p>Агентная разработка меняет эти условия. Вместо нескольких сотен строк, сформированных в результате непрерывного взаимодействия людей, команды теперь могут получать тысячи строк, созданных в более длительных циклах рассуждений, охватывающих несколько файлов и уровней стека. В таком масштабе традиционные методы проверки начинают испытывать слишком высокую нагрузку. Бремя понимания изменений возрастает гораздо быстрее, чем скорость генерации.</p> <p>Это создает проблему управления. Если организации продолжат рассматривать проверку как контрольную точку на поздней стадии, они обнаружат, что генерация кода опередила их способность обеспечить доверие. Именно здесь многие команды впервые почувствуют реальные трудности разработки с использованием ИИ: не в момент создания, а когда их попросят утвердить, объединить и поддержать созданный код.</p> <h3>Направление: задавайте агентам границы, а не просто промпты</h3> <p>Первое требование в агентном рабочем процессе — это задание направления. Не общих промптов, а структурированного контекста.</p> <p>Агенты должны понимать не только задачу, стоящую перед ними. Они должны понимать среду, в которой эта задача выполняется: архитектурные границы, инженерные стандарты, ожидания соответствия нормативным требованиям, соглашения об именовании и практические ограничения, которые редко умещаются в одном документе. Без этого агент может создать что-то, что кажется правильным локально, но при этом оказывается неправильным для более широкой системы.</p> <p>Это одно из главных заблуждений в современных дискуссиях об инструментах ИИ. Многие команды предполагают, что более сильные модели естественным образом уменьшают потребность в явном руководстве. В действительности часто верно обратное. Чем больше работы делегируется агентам, тем важнее становится четко определить область применения. Направление — это то, что уменьшает неизбежный дрифт до того, как он попадет в кодовую базу.</p> <p>В этом смысле этап «направление» — это не просто подготовка. Это первый уровень контроля.</p> <h3>Проверка: уровень, превращающий скорость в доверие</h3> <p>Проверка — это этап, на котором агентная разработка становится либо управляемой, либо хрупкой.</p> <p>Системы ИИ часто дают сбои, которые трудно обнаружить на ранних стадиях: скрытые логические ошибки, проблемы с надежностью, проблемы безопасности или затраты на обслуживание, которые проявляются только позже. Поскольку модели являются вероятностными и контекстно-зависимыми, проверка не может быть поверхностным код-ревью. Она должна быть основной функцией цикла разработки.</p> <p>Это означает, что проверка должна происходить в двух местах: внутри рабочего цикла, пока агент еще генерирует данные, и снова после того, как агент сочтет, что работа завершена. Первый этап выявляет ошибки на ранней стадии и помогает направлять следующий шаг. Второй этап проверяет, действительно ли результат удовлетворяет функциональным, нефункциональным и организационным требованиям.</p> <p>Это меняет роль обратной связи. Вместо того чтобы выявлять проблемы только после того, как большой запрос на изменение попадает к человеку-рецензенту, проверка становится активной частью рабочего процесса.</p> <p>Она также должна быть объяснимой и воспроизводимой. Детерминированный анализ, проверки безопасности, анализ сложности и тестирование создают доказательства. Они показывают, что было проверено, что прошло успешно, что не прошло и почему. В корпоративных условиях такая прозрачность является основой подотчетности.</p> <p>Качество кода все больше влияет на экономику разработки с использованием ИИ. В контролируемом <a href="https://arxiv.org/abs/2605.20049">исследовании</a>, проведенном компанией Sonar с использованием согласованных пар репозиториев с одинаковыми внешним поведением, архитектурой, зависимостями и тестовым покрытием, агенты, работающие с кодовыми базами более высокого качества, в среднем использовали примерно на 7% меньше входных токенов, на 8% меньше выходных токенов и на 11% меньше усилий по рассуждениям. Они также перечитывали файлы на 34% реже, что является полезным сигналом того, что более понятный код снижает неопределенность и позволяет агентам более уверенно вносить изменения. Другими словами, качество кода больше не является просто вопросом поддерживаемости. Оно начинает выглядеть как переменная эффективности инфраструктуры ИИ.</p> <h3>Исправление: замкнуть цикл вместо увеличения бэклога</h3> <p>Уровень проверки полезен только в том случае, если он приводит к действиям.</p> <p>Вот почему этап «исправление» так важен в модели AC/DC. Когда выявляются проблемы, процессу необходим систематический способ их устранения, повторной проверки исправлений и извлечения уроков из результатов. В противном случае проверка становится механизмом отчетности, а не оперативным механизмом. Это особенно важно в средах, где ИИ увеличивает общий объем проверяемого кода. Без механизма исправления любая система обнаружения в конечном итоге превращается в генератор бэклога.</p> <p>«Исправление» предотвращает этот режим сбоев, превращая обнаружение проблем в итеративный цикл. Предлагаются исправления, они перепроверяются и передаются в следующий цикл, так что система со временем улучшается. В зрелых рабочих процессах это означает, что разработчики тратят меньше энергии на решение повторяющихся проблем и больше энергии на архитектуру, оценку и проектные решения более высокого порядка.</p> <h3>Реальный сдвиг</h3> <p>Практический вывод прост. В агентной модели разработки основная задача больше не состоит в написании кода; она заключается в создании системы, которая делает сгенерированный код надежным.</p> <p>Командам по-прежнему нужны сильные модели и полезные инструменты, но реальным отличием является все, что окружает генерацию: качество контекста, который получают агенты, сила уровня проверки и способность достаточно быстро исправлять проблемы, чтобы успевать за машинным выводом.</p> <p>Организации, которые адаптируются быстрее всего, будут не теми, кто генерирует больше всего кода. Они смогут последовательно превращать этот код в ПО, которое будет понятным, управляемым и готовым к внедрению в производство.</p> <p>В эпоху программных агентов реальное преимущество будет заключаться не только в генерации кода. Оно будет заключаться в создании дисциплины для этого процесса.</p> Команды разработчиков могут укрепить доверие к коду, сгенерированному агентами искусственного интеллекта, с помощью … article https://www.itweek.ru/themes/detail.php?ID=234901 Wed, 27 May 2026 15:07:57 +0300 <p>Компания «Аладдин» сообщила о том, что система защиты информации на рабочих станциях и серверах Secret Disk для Linux сертифицирована во ФСТЭК России. Срок действия сертификата — до 26 января 2029 года.</p> <p>Согласно полученному сертификату, Secret Disk для Linux официально сертифицирован как программное средство со встроенными средствами защиты от несанкционированного доступа к информации, не являющейся государственной тайной. Также сертификат подтверждает, что Secret Disk реализует функции идентификации и аутентификации, управления доступом и регистрации событий безопасности. Решение соответствует требованиям документа «Требования по безопасности информации, устанавливающие уровни доверия к средствам технической защиты информации и средствам обеспечения безопасности информационных технологий» (ФСТЭК России, 2020) — по 4 уровню доверия и технических условий. </p> <p>Secret Disk для Linux — сертифицированная система защиты информации на рабочих станциях и серверах. Шифрование помогает избежать компрометации чувствительных к утечке конфиденциальных данных: злоумышленник не может воспользоваться данными, хранящимися в зашифрованном виде, даже если получит доступ к файлам.</p> <p>Решение обеспечивает защиту от несанкционированного доступа к информации, хранящейся и обрабатываемой на встроенных носителях, защиту от утечки информации при доступе посторонних лиц, в том числе при сервисном обслуживании, утере корпоративных ноутбуков, а также контроль доступа пользователей к защищённым данным. Система использует двухфакторную аутентификацию с применением ключевого контейнера пользователя и разграничение прав доступа между администраторами ИТ и ИБ. </p> Компания «Аладдин» сообщила о том, что система защиты информации на рабочих станциях и серверах Secret Disk для … message https://www.itweek.ru/themes/detail.php?ID=234899 Wed, 27 May 2026 12:56:02 +0300 <p>Представьте: клиент оставил заявку. Она пришла на почту менеджеру, тот переслал её в чат, коллега из другого отдела увидел сообщение через час, уточнил детали ещё через два — и только тогда процесс сдвинулся с места. Всё это время компания формально работала: системы работали, люди работали. Но заявка просто ждала.</p> <p>Именно так выглядит автоматизация без выстроенного процесса.</p> <h3>Когда инструментов много, а результата мало</h3> <p>Большинство компаний среднего размера сегодня неплохо оснащены технически. Есть CRM, куда попадают сделки. Есть ERP, где живут заказы и финансы. Есть мессенджеры, почта, таск-трекеры, иногда — отдельные интеграции между системами. Казалось бы, цифровой контур выстроен.</p> <p>Но стоит посмотреть не на список инструментов, а на то, как реально движется конкретная задача от момента возникновения до результата, — картина меняется.</p> <p>Входящий запрос поступил. Кто-то должен его заметить. Кто-то — решить, кому передать. Кто-то — уточнить статус через три дня, потому что ответа не было. Кто-то — вручную собрать информацию из двух систем, чтобы просто понять, на каком этапе вещи находятся.</p> <p>Работа идёт. Но значительная её часть — это не сама работа, а управление движением задачи между людьми.</p> <h3>Где на самом деле теряется время</h3> <p>Есть распространённое заблуждение: бизнес теряет эффективность там, где что-то делается медленно или плохо. На самом деле в большинстве случаев потери сосредоточены не внутри шагов, а между ними.</p> <p>Возьмём простой пример — согласование договора. Сам процесс проверки юристом занимает час. Но договор может лежать в очереди два дня, потому что никто не знал, что он уже готов к проверке. Потом ещё день — потому что юрист в отпуске, а регламента передачи нет. Потом ещё полдня — потому что правки вернулись не туда.</p> <p>Итог: работа на час растянулась на неделю. И ни один инструмент в этой цепочке не был сломан.</p> <p>То же самое происходит с закупками, которые тормозят из-за одного неотвеченного письма. С клиентскими обращениями, которые зависают между отделами. С внутренними заявками, которые маршрутизируются через переписку и устные договорённости.</p> <p>Проблема не в скорости исполнения. Проблема в том, что нет механизма, который сам знает, что должно произойти дальше.</p> <h3>Что значит «автоматизировать процесс», а не «автоматизировать действие»</h3> <p>Здесь важно разграничить два подхода, которые на первый взгляд выглядят похоже.</p> <p>Автоматизация действия — это когда система делает что-то конкретное: отправляет письмо, создает задачу, записывает данные. Полезно, но изолированно. Каждое действие существует само по себе.</p> <p>Автоматизация процесса — это когда заранее описана вся логика: что запускает процесс, какие условия проверяются, кто подключается на каком этапе, когда срабатывает следующий шаг, как контролируются сроки и где фиксируется результат.</p> <p>Разница принципиальная. В первом случае компания автоматизирует точки. Во втором — маршрут целиком.</p> <p>Именно поэтому компании с большим количеством внедрённых инструментов нередко работают медленнее, чем хотелось бы: каждый инструмент делает своё дело, но никто не управляет переходами между ними. Этим управляют люди — вручную, по памяти, через мессенджеры.</p> <h3>Почему новые технологии не решают эту проблему сами по себе</h3> <p>Последние пару лет бизнес активно интересуется AI-инструментами, умными интеграциями, предиктивной аналитикой. И всё это действительно может давать эффект — но только при одном условии: если сам процесс уже выстроен.</p> <p>Если между событием и результатом нет чёткой логики — что происходит, кто отвечает, в какой момент, при каких условиях, — то новый инструмент просто ускоряет существующий хаос. Быстрее уведомление уйдёт не туда. Быстрее задача окажется у человека, который не знает, что с ней делать.</p> <p>В практике работы компаний из разных отраслей — от логистики до финансовых сервисов — этот паттерн повторяется. Бизнес говорит «нам нужна автоматизация» и в ходе разбора выясняется, что сначала нужно ответить на более простой вопрос: а как процесс должен работать в принципе? Кто за что отвечает? Что должно происходить, если что-то пошло не так?</p> <p>Пока этого описания нет, автоматизировать нечего.</p> <p>Здесь важно разграничить роли, которые часто путают: AI-агент может усилить процесс — подсказать, классифицировать, снять рутину, ускорить шаг. Но он не выстраивает процесс. Если нет понятного маршрута, ролей, правил и точек контроля — агенту просто не на что опереться. В таком случае он не устраняет хаос, а действует быстрее внутри него.</p> <p>Поэтому правильная последовательность выглядит так: сначала выстроить логику процесса, потом убрать из него рутину и только затем усиливать отдельные этапы интеллектуальными инструментами там, где это действительно даёт эффект. Это намного практичнее, чем искать, куда «прикрутить ИИ» просто потому, что это модно.</p> <h3>С чего начинать</h3> <p>Хорошая новость в том, что выстраивание логики процесса — это не многомесячный проект и не задача только для ИТ-отдела. Это в первую очередь управленческая работа.</p> <p>Практически для любого повторяющегося процесса можно задать несколько ключевых вопросов:</p> <ul> <li> Что является сигналом к началу процесса?</li> <li> Кто и в какой момент должен быть подключён?</li> <li> Какие условия влияют на маршрут?</li> <li> Где нужен контроль сроков?</li> <li> Как выглядит завершение и что фиксируется?</li> </ul> <p>Когда ответы на эти вопросы есть — процесс можно описать, передать в систему и запускать автоматически. Workflow в этом смысле не про технологию. Это про то, что процесс перестаёт держаться на памяти конкретных людей и неформальных договорённостях.</p> <p>Вот как это выглядит на примере одной управляющей компании, обслуживающей несколько объектов коммерческой недвижимости. Заявки от арендаторов приходили по-разному: кто-то писал в Telegram, кто-то на почту, кто-то звонил. Диспетчеры вручную разбирали поток, определяли категорию, передавали исполнителю, отдельно следили за сроками.</p> <p>Формально всё работало. Но путь от обращения до исполнения занимал в среднем <nobr>4-6 часов.</nobr> Не потому что работа была сложной. А потому что большую часть этого времени заявка просто ждала: пока диспетчер увидит, пока классифицирует, пока передаст, пока исполнитель подтвердит получение. Сама работа занимала куда меньше времени — потери накапливались между шагами.</p> <p>Когда специалисты компании прошли по пяти вопросам выше и выстроили логику процесса — определили точку входа, условия маршрутизации, зоны ответственности, контроль срока реакции и автоматическую эскалацию — ничего принципиально нового не появилось. Появилась структура, которой раньше не было.</p> <p>В результате среднее время обработки сократилось до <nobr>40-50 минут.</nobr> Нагрузка на диспетчеров снизилась вдвое. Не потому что люди стали работать быстрее — просто перестали тратить время на координацию, которую теперь делает система.</p> <p>Но главный эффект часто не в том, что процесс пошёл быстрее. Важнее другое: у компании появляется видимость там, где раньше была зависимость от людей и ручного контроля.</p> <p>Когда процесс выстроен в единую логику, становится понятно: где именно возникают задержки, какие шаги чаще всего требуют вмешательства, на каких людях завязаны маршруты, где повторяются одни и те же сбои. Это и есть наблюдаемость процесса — возможность не просто исполнять, но видеть и управлять.</p> <p>Без неё управляемость, как показывает практика, иллюзией. Процесс вроде бы идёт — но куда именно и с какими потерями, никто точно не знает.</p> <h3>Главное</h3> <p>Автоматизация сама по себе не делает бизнес быстрее и управляемее. Это делает выстроенный процесс — и уже потом автоматизация, которая его поддерживает.</p> <p>Большинство компаний идут в обратном порядке: сначала внедряют инструменты, потом удивляются, почему задачи всё равно теряются. Выход не в том, чтобы добавить ещё один сервис. Выход в том, чтобы сначала ответить на вопрос: а как этот процесс вообще должен работать?</p> <p>#IMAGE_234900#</p> Представьте: клиент оставил заявку. Она пришла на почту менеджеру, тот переслал её в чат, коллега из другого … article Иван Лашков, руководитель отдела маркетинга платформы STAQ https://www.itweek.ru/themes/detail.php?ID=234898 Wed, 27 May 2026 11:20:38 +0300 <p>Российский вендор Deckhouse представил итоги развития своей платформы за последние полгода. Основные изменения коснулись управляющего слоя и безопасности Deckhouse Kubernetes Platform (DKP), виртуализации в рамках решения, а также развития линейки управляемых сервисов. Кроме того, обновление затронуло возможности наблюдаемости, работу с данными и инструменты обучения специалистов.</p> <p>В центре управления кластерами DKP, Deckhouse Commander, реализованы биллинг и управление затратами. Новый инструмент позволяет перевести потребление ресурсов (CPU, память, хранилище) в понятные бизнес-показатели по проектам, командам и кластерам. Это делает расходы на инфраструктуру прозрачными и предсказуемыми для компаний.</p> <p>Платформа переходит на новый уровень безопасности модулей. Внедрена система контроля целостности модулей на базе файловой системы EROFS и технологии <nobr>dm-verity.</nobr> Это гарантирует защиту компонентов платформы от несанкционированных изменений на уровне ядра ОС.</p> <p>Кроме того, использование distroless-образов в CNI Cilium сокращает поверхность потенциальных атак на платформу, а новые политики не позволяют рабочим нагрузкам размещаться на системных узлах и получать избыточные привилегии. Это исключает человеческий фактор при настройке размещения нагрузок и избавляет ИБ-специалистов от ручной проверки манифестов.</p> <p>Также компания переоформила сертификат ФСТЭК России № 4860: теперь он распространяется не только на контейнеризацию, но и на виртуализацию. В результате продукт DKP Certified Security Edition Pro позволяет управлять контейнерами и виртуальными машинами в рамках единой защищённой платформы. Подробнее об обновлении сертификата — в записи вебинара. </p> <p>Платформа предоставляет командам доступ к семи управляемым сервисам для работы с данными, включая PostgreSQL, Kafka и Valkey. Managed-модель снижает операционную нагрузку на инфраструктурную команду и ускоряет запуск новых бизнес-приложений.</p> <p>Deckhouse позволяет управлять виртуальными машинами (ВМ) в общем контуре с контейнерами. Платформа обеспечивает единый подход к управлению любыми пользовательскими нагрузками, сквозную наблюдаемость и общие инструменты безопасности.</p> <p>В обновлении добавлены функции: клонирование ВМ, выбор конкретного сервера при миграции ВМ, работа с внешними USB-устройствами и оптимизированная работа с хранилищем образов. В сочетании с полноценным API и единым веб-интерфейсом это позволяет автоматизировать работу с виртуальными машинами так же легко, как и с контейнерами. Такой подход избавляет от дублирования инфраструктуры, снижает операционные расходы и ускоряет развёртывание приложений.</p> <p>Запуск AI/ML-нагрузок любой сложности. DKP обеспечивает более гибкое распределение ресурсов GPU под разные типы нагрузок на одном узле с помощью покарточной настройки MIG.</p> <p>Актуальные версии Kubernetes. Разработчики DKP добавили в платформу поддержку версий Kubernetes 1.34 и 1.35, а также внедрили инструменты для гибкого управления доступностью экспериментальных возможностей Kubernetes. Это позволяет командам раньше пробовать инновационные технологии Kubernetes в своих задачах.</p> <p>Встроенный реестр образов (Registry). Появилась возможность использовать внутренний реестр вместо внешнего — как для образов платформы, так и для прикладной нагрузки. Это избавляет от необходимости настраивать сторонние инструменты и экономит ресурсы на их поддержку.</p> <p>Разделение прав доступа в UI. В интерфейсе провели деление платформы на административную (система) и пользовательскую (проекты) части. Правила доступа позволяют чётко разделить доступные операции на уровне всей системы или отдельного проекта — теперь и в UI.</p> <p>Развитие универсальной интеграции. Deckhouse Kubernetes Platform работает в любых окружениях: от публичных облаков до физических серверов. В новом релизе возможности интеграции расширены для VMware Cloud Director, vSphere и zVirt. Единый стандарт управления позволяет переносить нагрузки между разными провайдерами через настройку конфигурации — без сложной архитектурной перестройки системы.</p> <p>Упрощение эксплуатации и повышение наблюдаемости. Настраивать условия алертов и создавать собственные метрики стало проще и быстрее. Все действия доступны из одного окна — это сокращает время настройки, снижает «порог входа» для специалистов и сокращает время на диагностику сбоев.</p> <p>Понятная документация и обучение. Команда Deckhouse добавила материалы и актуализировала разделы в документации, чтобы сделать её удобнее и практичнее для команд внедрения и эксплуатации. В Deckhouse Академии запущены новые курсы по безопасности и наблюдаемости, а также открыта профессиональная сертификация для ИБ-инженеров.</p> <p>«Развивая Deckhouse Kubernetes Platform как открытый индустриальный стандарт, за последние полгода мы значительно расширили функциональность платформы. Особое внимание уделили прозрачности расходов и информационной безопасности: биллинг в Deckhouse Commander даёт чёткое понимание стоимости каждого проекта, а новые уровни защиты повышают устойчивость к современным угрозам. Мы упрощаем пользовательский путь и добавляем управляемые сервисы: в последнем обновлении это семь сервисов, закрывающих основные сценарии работы с данными и очередями. При этом DKP остаётся единым слоем управления, одинаково стабильно работающим в облаках и частных контурах вне зависимости от вендора», — прокомментировал Карапет Манасян, директор по продукту Deckhouse Kubernetes Platform.</p> Российский вендор Deckhouse представил итоги развития своей платформы за последние полгода. Основные изменения коснулись … message https://www.itweek.ru/themes/detail.php?ID=234897 Wed, 27 May 2026 11:14:39 +0300 <p>ICT.Moscow проанализировал перспективы развития проектов с открытым исходным кодом (Open Source) в 2026 году, опросив более 300 представителей ИТ-сферы. Прогнозируется, что российские аналоги будут чаще выбирать в качестве замены зарубежным платформам для хранения кода.</p> <p>По данным ICT.Moscow, специалисты станут все активнее пробовать российские платформы для проектов Open Source. По результатам опроса, в котором приняли участие 307 представителей ИТ-сферы, 36% респондентов считают, что такие ресурсы в 2026 году будут охотнее выбирать в качестве альтернативы зарубежным репозиториям. При этом 14% отмечают растущий интерес к гибридным и коммерческим бизнес-моделям распространения открытых решений.</p> <p>Согласно проведенному исследованию влияние искусственного интеллекта (ИИ) на развитие Open Source в России становится все более очевидным. 46% участников опроса полагают, что эта технология будет ключевым фактором для увеличения числа открытых проектов как в России, так и за ее пределами.</p> <p>35% респондентов рассчитывают, что в стране появятся центры экспертизы на стыке индустрии, науки и сообществ открытого кода. Причем разработчики и контрибьюторы не обязательно будут объединяться вокруг успешных проектов — в такой сценарий верят только 10% опрошенных.</p> <p>Часть ожиданий связана с участием государства в судьбе сферы открытого кода: по мнению 35% опрошенных, в 2026 году могут быть внедрены национальные стандартов качества и безопасности продуктов Open Source, в то время как 15% надеются на новые инициативы в регулировании этой индустрии.</p> <p>Несмотря на преобладание оптимистичных прогнозов, 28% опрошенных не ждут значительных изменений в сфере открытого софта в России, указывая на неясность относительно будущего локального развития. 21% участников выражают опасения, что темпы роста проектов замедлятся, и 12% предполагают, что тенденция к закрытию репозиториев может усилиться, в том числе через распространение лишь частично открытых лицензий на ПО (Source Available).</p> <p>Опрос проводился командой аналитического хаба ICT.Moscow в апреле 2026 года. Участникам предлагалось выбрать несколько вариантов ответа на вопрос о том, чего они ожидают от российского Open Source в ближайшей перспективе.</p> ICT.Moscow проанализировал перспективы развития проектов с открытым исходным кодом (Open Source) в 2026 году … message https://www.itweek.ru/themes/detail.php?ID=234896 Wed, 27 May 2026 11:13:12 +0300 <p>Эксперты компании «Информзащита» выявили тенденцию роста инцидентов безопасности, связанных с использованием AI-агентов в корпоративной среде: в 2026 году с такими событиями столкнулись 42% организаций против 31% годом ранее. По оценке специалистов, рост связан с тем, что компании стали чаще выводить AI-агентов за пределы пилотных проектов — в ИТ, инженерные команды, клиентский сервис, безопасность, закупки и внутренние операционные процессы. Данные опроса фиксируют, что 58% респондентов указывают, что обнаружение и реагирование занимает более пяти часов. Основная причина задержки — отсутствие сквозного журналирования цепочки решений агента: команда видит итоговое действие, но не видит, какой промпт, какой инструмент и какие данные привели к этому действию. Российская динамика согласуется с глобальным трендом, но пока отстает по проявлениям.</p> <p>Главная сложность в том, что AI-агент отличается от обычного чат-бота или аналитического инструмента. Он использует API, создает задачи, редактирует документы, запускает скрипты, пересылает данные, подключается к CRM, SIEM, тикетным системам и репозиториям. При недостаточной настройке прав такой агент начинает действовать шире, чем предполагали владельцы процесса. Около 53% организаций сталкивались с ситуациями, когда AI-агенты превышали заданные полномочия, например, обращались к учетным записям и хранилищам, не входившим в исходную задачу.</p> <p>На динамику 2026 года повлияла децентрализация внедрения. Только 5% компаний используют единую платформу для AI-агентов, тогда как 44% работают сразу с двумя-тремя платформами, а 43% — с четырьмя и более. Внутренний контроль при такой модели быстро теряет полноту: часть агентов создается бизнес-подразделениями без согласования с ИБ, часть появляется в рамках low-code-сценариев, часть подключается к SaaS-сервисам через личные или групповые токены, нередко с избыточными правами на запись. Отдельная техническая проблема состоит в том, что AI-агент с точки зрения целевых систем выглядит как обычная учетная запись, при этом ни инструменты IAM, ни процессы согласования доступа изначально не проектировались под нечеловеческие идентичности с автономным поведением. По данным исследований, организации, последовательно применяющие принцип минимально необходимого доступа к AI-агентам, фиксируют инциденты в 17% случаев, против 76% у компаний без такой практики — это самое крупное единичное снижение риска среди всех контролируемых мер. Дополнительный фактор риска — появление в <nobr>2025-2026</nobr> годах открытых протоколов взаимодействия агентов с инструментами (Model Context Protocol, MCP) и между собой (Agent-to-Agent, A2A): они ускоряют интеграцию, но создают новый слой доверительных отношений, которым по умолчанию не управляет ни одна классическая система защиты. По оценке «Информзащиты», в компаниях с численностью от 1000 сотрудников доля неинвентаризированных AI-агентов в 2026 году достигает 27%, а в организациях с активным использованием low-code и no-code платформ — до 39%. Это не всегда прямое нарушение политики, но именно такие зоны чаще становятся источником утечек, ошибочных действий и неконтролируемого обмена данными.</p> <p>Разбивка по векторам атак показывает, что наиболее заметную долю занимают злоупотребления правами и выход за пределы разрешенного сценария — 31% выявленных событий. В декабре 2025 года OWASP выпустила отдельный Top 10 for Agentic Applications, ASI (Top 10 для агентных приложений), в котором классические <nobr>LLM-риски</nobr> переосмыслены под автономное исполнение: prompt injection (инъекция в запрос) превращается в Agent Goal Hijack (перехват цели агента), excessive agency (избыточные полномочия) — в вектор privilege escalation (эскалации привилегий), data poisoning (отравление данных) — в memory poisoning (долговременную порчу памяти агента). Структура инцидентов, фиксируемая «Информзащитой», соответствует этой классификации. На prompt injection и подмену инструкций приходится 24%, на утечки через подключенные коннекторы и корпоративные хранилища — 18%, на shadow AI-агентов без владельца и формального учета — 14%, на компрометацию токенов, API-ключей и сервисных учетных записей — 9%, на атаки через сторонние плагины и цепочки поставки — 4%.</p> <p>Наиболее уязвимыми оказались финансовые организации, на которые приходится 26% зарегистрированных инцидентов с AI-агентами. В зоне повышенного риска также находятся ИТ- и телеком-компании с долей 21%, промышленность и энергетика — 17%, ритейл и e-commerce — 14%, медицинские и фармацевтические организации — 11%, логистика и транспорт — 7%, профессиональные услуги и консалтинг — 4%. Финансовый сектор лидирует из-за высокой плотности интеграций, большого числа регуляторных требований и активного использования автоматизации в антифроде, клиентской поддержке и обработке документов. В ИТ и телекоме риск усиливается из-за доступа агентов к репозиториям, CI/CD и системам управления инфраструктурой. В промышленности проблема чаще связана с подключением AI-инструментов к данным мониторинга, техдокументации и сервисным контурам.</p> <p>Картину 2026 года уже сформировали несколько публично раскрытых инцидентов. В апреле 2026 года компания Vercel подтвердила компрометацию через сторонний AI-инструмент Context.ai с ущербом около $2 млн, развивавшуюся по классическому supply-chain-сценарию: от личного аккаунта сотрудника в AI-сервисе, к корпоративному Google Workspace и далее к внутренним средам. Уязвимость EchoLeak в Microsoft 365 Copilot (CVE-2025-32711) показала возможность zero-click-эксфильтрации данных через скрытую инструкцию в письме, без действий пользователя. Отдельный класс рисков иллюстрируют инциденты с агентами разработки: задокументированы случаи, когда автономный кодинговый агент за секунды удалял рабочие базы данных и резервные копии, реагируя на типовую техническую ошибку.</p> <p>«Компания может видеть выполнение задачи, но не видеть всю цепочку решений, которая к ней привела. В 2026 году мы ожидаем, что число инцидентов будет расти прежде всего там, где агенты внедряются быстрее, чем появляются владельцы, журналы действий и правила остановки», — прокомментировал Анатолий Песковский, директор Департамента наступательной безопасности компании «Информзащиты».</p> <p>По рекомендациям экспертов, компаниям необходимо вести полный реестр агентов, фиксировать владельца каждого сценария, ограничивать права по принципу минимально необходимого доступа, разделять доступ к данным и действиям, контролировать использование токенов и сервисных учетных записей, а также внедрять журналирование на уровне промптов, инструментов, API-вызовов и итоговых операций. Для сценариев с доступом к персональным данным, финансовой информации, исходному коду и производственным системам нужен отдельный процесс согласования, тестирование на prompt injection и регулярная проверка фактических полномочий. Дополнительный слой защиты дают runtime-политики: ограничение списка доступных инструментов и внешних доменов, обязательное подтверждение операций с высоким риском, изоляция секретов от контекста модели, выполнение действий агента в изолированной среде (sandboxing) и заранее настроенный механизм принудительной остановки — kill switch на уровне платформы оркестрации. Отдельным направлением становится инвентаризация и управление нечеловеческими идентичностями (NHI): каждому агенту присваивается собственная учетная запись с уникальными правами, отделенная от учетных записей разработчиков и сервисных аккаунтов общего назначения. Параллельно формируется практика «надзорных агентов» (guardian agents), которые в реальном времени отслеживают поведение основных агентов и блокируют действия, выходящие за установленные политики. Практика показывает, что наибольший эффект дает связка инвентаризации, runtime-контроля, DLP, мониторинга аномального поведения и заранее описанных процедур отключения агента при выходе за допустимый контур. Без такой дисциплины автономность агентов начинает работать против бизнеса: скорость операций растет, но вместе с ней увеличивается окно, в котором ошибка агента или точная атака превращается в полноценный инцидент. «Информзащита» рекомендует встраивать AI-агентов в стандартные циклы управления уязвимостями, инцидентами и доступом с самого начала проекта, а не после первого инцидента: издержки на «догоняющий» контроль, по нашим наблюдениям, кратно превышают стоимость превентивного внедрения.</p> Эксперты компании «Информзащита» выявили тенденцию роста инцидентов безопасности, связанных с использованием AI-агентов … message https://www.itweek.ru/themes/detail.php?ID=234895 Wed, 27 May 2026 11:12:17 +0300 <p>Компании, выстраивающие системный подход к управлению опытом сотрудников (Employee Experience, EX) на основе данных, могут достигать роста общей продуктивности до 15%, увеличивать вовлеченность до 75%, снижать текучесть кадров до 35% и ускорять ключевые бизнес-процессы до 25%. К такому выводу пришли аналитики консалтинговой технологической компании Axenix по итогам исследования, посвященного влиянию EX на рост и эффективность бизнеса.</p> <p>В условиях замедления экономического роста и ограниченных ресурсов, компании усиливают фокус на повышении производительности команд. Одновременно растут ожидания сотрудников к качеству взаимодействия с работодателем, что требует более системного подхода к управлению человеческим капиталом. </p> <p>По данным Axenix, 56% HR-директоров планируют усиливать программы организационной эффективности, пересматривать структуру нагрузки и искать способы ускорения работы с использованием ИИ-инструментов. HRD отмечают, что продолжат усилия для удержания, однако речь все чаще идет о прагматичных решениях: создании условий для самых результативных сотрудников, оценке реальной эффективности применяемых инструментов. Тенденция постепенно переходит из массовых кампаний борьбы за кадры к аналитическому и адресному подходу.</p> <p>Стратегическим ответом на этот запрос становится выстраивание системы управления опытом сотрудников на основе данных. В ее основе — цифровой профиль сотрудника, объединяющий HR-метрики, поведенческие данные и обратную связь. </p> <p>Модель Axenix включает восемь взаимосвязанных элементов и превращает EХ в масштабируемую систему:</p> <ul> <li>сегментация по рабочим контекстам и поведенческим профилям;</li> <li>путь сотрудника — синергия опыта и функциональных процессов;</li> <li>три среды: цифровая, физическая, взаимодействия;</li> <li>точки контакта как кросс-функциональная экосистема сервисов;</li> <li>методология: EJM (карта пути сотрудника), пульс-опросы, Voice of Employee (голос сотрудника);</li> <li>технологии HCM-платформ с ИИ-надстройкой;</li> <li>система измеримости через HR- и бизнес-метрики.</li> </ul> <p>Опыт сотрудников рассматривается как фактор, влияющий на вовлеченность, удержание персонала и производительностью труда в компании. Улучшение взаимодействия с компанией — от доступа к инструментам и информации до качества управленческих практик — позволяет устранять организационные барьеры и повышать согласованность работы команд, а также отражается на качестве клиентского взаимодействия и бизнес-результатах компании.</p> <p>Практика Axenix показывает, что внедрение данного подхода на пилотных сегментах позволяет уже на раннем этапе фиксировать ускорение процессов на <nobr>10-15%</nobr> и рост удовлетворенности сотрудников до 20%, а также получать возврат инвестиций в течение одного квартала без существенных затрат.</p> <p>«Качественный EX снижает текучесть, ускоряет бизнес-процессы и повышает лояльность сотрудников, обеспечивая понятную связь между операционной эффективностью и ростом выручки и маржи: „оптимизация барьеров-скорость и производительность команд-качество <nobr>CX-рост</nobr> выручки/снижение OPEX-ROI HR-инициатив“. Управление опытом сотрудников следует рассматривать не как набор отдельных HR-практик, а как целостную систему, в которой важны согласованность, измеримость и связь с бизнес-результатом», — прокомментировала Ирина Чистова, директор практики «Стратегический консалтинг», направление «Клиенто-центричные трансформации» Axenix.</p> <p>«Управление опытом сотрудников требует не отдельных инициатив, а координации между HR, IT, административными и бизнес-функциями. В рамках проектов мы видим, что многие барьеры возникают именно на стыке процессов и зон ответственности. Компании, которым удается выстраивать более согласованную среду взаимодействия, получают более устойчивые команды, предсказуемые процессы и высокий уровень вовлеченности сотрудников», — отметила Анастасия Сидакова, менеджер практики «Стратегический консалтинг», направление «Люди и организация» Axenix.</p> <p>Исследование основано на серии из 25 глубинных интервью с HR-директорами крупных компаний и бенчмарк-анализе практик рынка и проектного опыта Axenix, сформированного в ходе реализации EX-проектов в различных отраслях. Такой подход позволил сопоставить управленческие решения с их влиянием на HR- и бизнес-показатели.</p> Компании, выстраивающие системный подход к управлению опытом сотрудников (Employee Experience, EX) на основе данных … message https://www.itweek.ru/themes/detail.php?ID=234894 Wed, 27 May 2026 11:10:54 +0300 <p>Облачный провайдер mClouds ввел в эксплуатацию обновленную GPU-платформу на серверах Dell R7725 с процессорами последнего поколения AMD EPYC 9555 4,2 ГГц и памятью DDR5-6400. Решение ориентировано на ускорение в сфере AI, 3D-моделирования, сложных инженерных расчетов и работой с нагруженными базами данных.</p> <p>Ключевой особенностью платформа стала её гибридная направленность. Платформа позволяет как работать с GPU, так и размещать бизнес-критичные задачи, требующие высокой скорости от всех подсистем облака. Кластер укомплектован графическими ускорителями NVIDIA L4 24 ГБ, NVIDIA A16 64 ГБ и NVIDIA RTX 6000 PRO 96GB. В обновленном кластере осуществен переход на PCIe Gen 5, что обеспечило максимальные скорости работы для локальных NVMe дисков, позволяя ускорять работу с загрузкой данных в GPU-кластере. </p> <p>Процессоры EPYC 9555 с 64 ядрами. Каждый вычислительный хост кластера оснащен двумя процессорами AMD EPYC 9555, что в сумме дает 128 физических ядер, работающих на частоте 4,2 ГГц. Оптимально для ресурсоемких задач: размещение рабочих мест VDI с GPU, повышенная производительность для задач 1С Предприятия, сложных инженерных расчетов в CAD и BIM средах и работе с нейросетями.</p> <p>Оперативная память. Быстрая DDR5-6400 для высокочастотных нагрузок, до 30% рост пропускной способности, в сравнении с DDR5-4800.</p> <p>Дисковая подсистема. Перешла на PCIe Gen 5 со скоростями выше 10 ГБ/с и обеспечивает высокую скорость передачи данных при загрузке и сохранении сложных CAD-моделей, обучении нейросетей, обработке больших массивов данных.</p> <p>Кроме того, новый кластер предлагает три конфигурации видеокарт, что позволяет гибко подобрать ресурсы под свои задачи:</p> <ul> <li>NVIDIA A16 64 Гб с 5120 ядрами CUDA и 160 тензорными ядрами ориентирована на профессиональные BIM- и CAD-расчеты, обеспечивает высокую плотность виртуальных рабочих мест в системах проектирования;</li> <li>NVIDIA L4 24 Гб оснащена 7680 ядрами CUDA, 60 RT-ядрами и 240 тензорными ядрами — эта конфигурация обеспечивает высокую производительность в проектах инференса нейросетей, работе с графикой и требовательных задачах VDI;</li> <li>NVIDIA RTX 6000 PRO 96GB оснащена 24 064 ядрами CUDA, 188 RT-ядрами и 752 тензорными ядрами — обеспечивает оптимальную экономику при работе с моделями, требующих 96GB памяти.</li> </ul> <p>Новый кластер на базе AMD EPYC 9555 уже доступен для заказа.</p> <p>Александр Иванников, директор по развитию провайдера облачной инфраструктуры mClouds, отметил: «В последние годы вычислительная мощность становится ключевым драйвером роста для бизнеса, особенно в области AI-технологий. Мы постоянно развиваем наши платформы и стремимся предоставлять клиентам все необходимые инструменты для успешной реализации проектов, сохраняя сбалансированный подход к ценообразованию. Новый кластер уже прошел тестирование и показывает до <nobr>30–40%</nobr> роста по сравнению с платформой предыдущего поколения — компании смогут выйти на новый уровень производительности».</p> Облачный провайдер mClouds ввел в эксплуатацию обновленную GPU-платформу на серверах Dell R7725 с процессорами … message https://www.itweek.ru/themes/detail.php?ID=234893 Wed, 27 May 2026 09:06:50 +0300 <p><em>Руководители предприятий потратили два года и сотни миллиардов долларов на искусственный интеллект. Результаты оказались неоднозначными. Согласно глобальному опросу McKinsey 2024 года, менее одной трети компаний сообщили, что их инвестиции в ИИ принесли значимую и устойчивую бизнес-ценность. Демонстрации, как правило, впечатляют, а производственная эксплуатация — разочаровывает, пишет на портале </em><em>BigDataWire</em> <em>Сохам Мазумдар, соучредитель и генеральный директор WisdomAI.</em></p> <p>Чаще всего предлагается диагноз: модель недостаточно хороша, инфраструктура данных недостаточно зрелая или сотрудники не прошли обучение. Этот диагноз в значительной степени неверный или, по крайней мере, неполный.</p> <p>Настоящая проблема заключается в контексте, а именно в отсутствии устойчивого, динамического слоя корпоративного контекста, расположенного между ИИ и данными. Пока организации не поймут, что это значит, и не начнут действовать соответствующим образом, модернизация моделей и инвестиции в инфраструктуру не устранят этот пробел.</p> <h3>Пробел в контексте</h3> <p>Каждая корпоративная система ИИ, будь то инструмент разговорной аналитики, агент финансового планирования или оптимизатор цепочки поставок, работает путем преобразования человеческого вопроса в задачу, выполняемую машиной. Для точного преобразования система должна понимать бизнес, значение данных, как определяются метрики, какие бизнес-правила применяются и как эти правила развивались с течением времени.</p> <p>Именно это понимание мы подразумеваем под контекстом. В большинстве корпоративных внедрений он либо отсутствует, либо неполный, либо устаревает быстрее, чем кто-либо успевает его отслеживать.</p> <p>Рассмотрим пример глобального производителя из списка Global 2000, внедряющего систему ИИ для финансовой аналитики. Система может получать доступ к хранилищу данных и выполнять запросы. Но может ли она точно рассчитать валовую прибыль по бизнес-подразделениям, если правила должны учитывать внутрикорпоративные переводы, региональное распределение затрат и исключения, сделанные в ходе двух последних приобретений? Эти правила существуют в головах нескольких старших финансовых аналитиков. Они существуют в электронных таблицах, в трехлетних обсуждениях в Slack, в недокументированной институциональной памяти. Когда аналитики меняют роли или уходят на пенсию, знания исчезают, и система ИИ, лишённая этого контекста, начинает генерировать ответы, которые точны, но неверны.</p> <p>Это не проблема качества данных. Это проблема контекста, и она проявляется во всех отраслях.</p> <h3>Четыре измерения, в которых руководители ошибаются</h3> <p>Существует четыре структурных требования для эффективного контекстного слоя, и большинство организаций не справляются со всеми из них.</p> <p><strong>1. Контекст должен быть самообучающимся. </strong>Наиболее распространённая ошибка — рассматривать контекст как разовую реализацию. Организации вкладывают значительные средства в первоначальные усилия по сбору контекста, помечая метаданные, документируя бизнес-определения, каталогизируя утверждённые запросы, а затем считают процесс завершенным, чего никогда не бывает.</p> <p>Контекст постоянно и часто незаметно разрушается. Схемы меняются по мере того, как инженерные команды развивают модель данных. Происходит дрифт данных, поскольку источники данных меняются способами, о которых никто официально не объявляет. Бизнес-метрики переопределяются, «ARR» означает что-то другое после приобретения или изменения модели ценообразования. Бизнес-процессы реорганизуются, и логика, лежащая в основе панелей мониторинга за прошлый квартал, незаметно становится неверной. К тому времени, когда ошибка проявляется, контекст часто устаревает уже несколько месяцев.</p> <p>Если слой контекста зависит от людей, которые его поддерживают, люди становятся узким местом, и они всегда будут терять позиции. Эффективный механизм контекста должен постоянно обучаться на основе моделей использования, проверенных ответов и исправлений, внесенных людьми, улучшаясь со временем, а не деградируя.</p> <p><strong>2. Контекст многомерен и не может быть зафиксирован в одном месте.</strong> Корпоративные знания не хранятся в одной системе. Они одновременно существуют в схемах, в логике, закодированной в проверенных за много лет запросах аналитиков, в формальной и неформальной документации, в семантическом слое и слое метаданных, а также в неявных знаниях, которые существуют только в головах людей.</p> <p>Ошибка большинства предприятий заключается в том, что они стремятся к одному источнику контекста — каталогу метаданных, семантическому слою, словарю данных — и ожидают, что он возьмет на себя всю нагрузку. Ни один отдельный слой не может этого сделать. Утвержденные запросы, которые эксперт-аналитик совершенствовал в течение пяти лет, кодируют бизнес-логику, которую невозможно полностью задокументировать. Слой метаданных фиксирует структуру, но не смысл. Семантический слой фиксирует определения, но не решения, принимаемые в процессе применения этих определений.</p> <p>Эффективный контекстный слой должен одновременно охватывать все эти измерения и поддерживать согласованность между ними по мере независимого развития каждого из них.</p> <p><strong>3. Контекстный слой должен быть архитектурно независим от базовых платформ данных. </strong>Это наиболее важное архитектурное решение, к которому большинство организаций относятся недостаточно серьезно.</p> <p>Когда контекст создается внутри конкретной платформы, будь то облачное хранилище данных, облако-хранилище данных или семантический слой, специфичный для поставщика, он переплетается с проприетарными структурами и API этой платформы. Контекстный слой — это самый ценный интеллектуальный актив, создаваемый организацией, работающей с данными. Он кодирует многолетнюю бизнес-логику, проверенные запросы и институциональные знания. Когда этот актив зависит от платформы, организация теряет свою архитектурную гибкость и переговорные возможности.</p> <p>Ситуацию усугубляет реальность, с которой уже сталкивается большинство предприятий: данные редко хранятся в одном месте. Типичная компания из списка Global 2000 работает в гетерогенной среде: Snowflake для корпоративного хранилища данных, Databricks для рабочих нагрузок анализа данных, Salesforce для CRM, SAP для ERP и длинный хвост унаследованных и ведомственных систем, которые в ближайшее время не будут объединены. Контекстный слой, встроенный в любую из этих платформ, фиксирует то, что видит эта платформа, и ничего больше. Наиболее важные бизнес-вопросы, связывающие показатели выручки с операционными данными и поведением клиентов, требуют контекста, охватывающего все эти аспекты.</p> <p>Таким образом, абстрагирование — это не просто защита от будущих изменений платформы, это единственная архитектура, которая может соответствовать реальности того, как корпоративные данные существуют сегодня. Стеки данных развиваются, миграции происходят, и платформа, оптимальная сегодня, может перестать быть оптимальной через три года. Организации, которые абстрагировали свой контекстный слой, теперь могут обслуживать весь спектр своих данных и осуществлять переход на новые платформы без необходимости начинать все заново, в то время как те, кто этого не сделал, ограничены в обоих измерениях, часто обнаруживая издержки только тогда, когда миграция уже началась.</p> <p><strong>4. Каждый ИИ-агент наследует проблему контекста и усугубляет ее. </strong>Четвертое измерение становится актуальным только сейчас, когда предприятия переходят от "вторых пилотов и чат-ботов к автономным агентам.</p> <p>При использовании копилота в цикле участвует человек. Аналитик читает ответ, выносит суждение, выявляет ошибку. Цикл обратной связи достаточно гибок. Отличительной же характеристикой агентного ИИ является то, что он работает без постоянного контроля со стороны человека. Агенты выполняют запросы, синтезируют данные, генерируют отчеты и запускают последующие рабочие процессы автономно, в масштабе и непрерывно.</p> <p>Эта автономность является ценностным предложением, и именно поэтому высокое качество базового контекстного слоя становится обязательным.</p> <p>Плохо настроенная панель мониторинга выдает неверную цифру одному человеку на одном совещании. Агент, работающий с устаревшим или неполным контекстом, распространяет эту ошибку на десятки нижестоящих систем и решений, прежде чем кто-либо поймет, что что-то пошло не так. Автономия, которая делает агентов ценными, — это то же самое свойство, которое делает плохой контекст таким опасным. Каждый агент, развернутый организацией, заслуживает доверия лишь настолько, насколько хорош контекст, лежащий в его основе, а уверенные, но неверные ответы, предоставляемые со скоростью машины и встроенные в автоматизированные рабочие процессы, представляют собой потенциальный сбой в управлении.</p> <h3>Структура для принятия инвестиционных решений</h3> <p>Для руководителей высшего звена, оценивающих инвестиции в ИИ, стоит задать поставщикам четыре прямых вопроса:</p> <ul> <li><strong> Обучается ли система или требует ручного обслуживания?</strong> Контекстный слой, зависящий от человеческого контроля, будет разрушаться, поэтому стоит конкретно спросить поставщиков, как контекст обновляется с течением времени и какие человеческие усилия требуются для поддержания его точности.</li> <li><strong> Сколько измерений контекста она охватывает?</strong> Решения, которые рассматривают только один слой — метаданные, семантические определения или историю запросов — в отрыве от контекста, следует рассматривать со скептицизмом. Более надежные системы интегрируют несколько измерений контекста и поддерживают их согласованность по мере развития каждого из них.</li> <li><strong> Переносим ли контекст?</strong> Если организации потребуется сменить платформу данных через два года, что произойдет с созданным ею контекстом? Ответ на этот вопрос покажет, насколько сильно в архитектуре заложена стратегическая привязка к поставщику.</li> <li><strong> Какова модель управления агентами?</strong> Перед развертыванием автономных агентов организации должны иметь возможность четко определить, в каком контексте эти агенты работают, как этот контекст проверяется и какие механизмы существуют для обнаружения и исправления ошибок до их распространения.</li> </ul> <h3>Стратегические последствия</h3> <p>Схема, наблюдаемая в успешных внедрениях ИИ на предприятиях, остается неизменной. Организации, создающие долгосрочную ценность, не обязательно обладают самыми большими моделями или наибольшим объемом данных. Это те, кто инвестирует в живой, многомерный, платформенно-независимый контекстный слой и рассматривает его как стратегический актив, а не как деталь реализации.</p> <p>Для предприятий создание и поддержание этого контекстного слоя — это инвестиции в ИИ. Организации, которые осознают это сейчас, получат накопительное преимущество, в то время как те, кто продолжит рассматривать это как второстепенный аспект, окажутся в дорогостоящем и повторяющемся цикле пилотных проектов, которые впечатляют на демонстрациях и разочаровывают в производственной среде.</p> Руководители предприятий потратили два года и сотни миллиардов долларов на искусственный интеллект. Результаты … article https://www.itweek.ru/themes/detail.php?ID=234890 Tue, 26 May 2026 10:25:56 +0300 <p>В GreenData проанализировали восемь классов отечественных бизнес-критичных систем по уровню проникновения low-code. Эксперты выяснили, что low-code в России развивается неравномерно: в процессных системах он стал архитектурным ядром, а в «тяжелых» транзакционных и аналитических системах чаще остается слоем надстройки.</p> <p>В GreenData сравнили зрелость low-code в системах управления бизнес-процессами, продажами и клиентскими отношениями, корпоративными сервисами, ресурсами предприятия, аналитикой, документами, планированием, а также рисками и комплаенсом. В основу оценки легли десять архитектурных слоев: интерфейс, модель данных, бизнес-правила, workflow, интеграции, отчетность, контроль версий, безопасность, DevOps и совместимость обновлений.</p> <p>По каждому слою продуктам присваивалась оценка от 0 (только через код) до 3 (low-code как платформенный слой, пригодный для масштабной разработки без помощи ИТ). Суммарный балл определял уровень зрелости: <nobr>80-100 —</nobr> low-code платформа/работает в платформенной логике, <nobr>55-79 —</nobr> продукт с глубокой настройкой или продукт на low-code платформе; <nobr>30-54 —</nobr> low-code конструктор поверх коробки, а ниже 30 — low-code в основном декларативный. </p> <p>Наиболее зрелыми с точки зрения low-code эксперты назвали BPM-системы: глубину проникновения low code здесь оценили в <nobr>70-85%.</nobr> Практически все заметные игроки рынка уже работают с low-code по платформенной логике. Граница между классическими системами управления бизнес-процессами и LCAP (Low-code Application Platform) размывается.</p> <p>В сегменте ESM/ITSM проникновение low-code оценили в <nobr>60–75%.</nobr> Причем для ESM характерен показатель ближе к верхней границе, для классического ITSM — скорее к середине диапазона. Многие современные российские платформы изначально проектировались с фокусом на low-code. А часть популярных продуктов предлагают широкие возможности настройки, хотя их нельзя назвать классическими LCAP. </p> <p>Близкий уровень зрелости показывают CRM-системы <nobr>(55–70%).</nobr> CRM-сегмент в России активно смещается в сторону платформенной гибкости, но на рынке по-прежнему значительна доля продуктовых, отраслевых и коробочных решений, где low-code присутствует, но не на уровне архитектурного слоя. Наиболее развитые решения российского рынка сильны в сценариях быстрых настроек, smart-процессов, воронок и виджетов, однако, LCAP-платформами не являются. </p> <p>Замыкают список low-code лидеров риск-системы/GRC — здесь уровень проникновения аналитики оценили в <nobr>50-55%.</nobr> В риск-системах low-code используется как базовый механизм адаптации: он востребован для оперативного изменения моделей рисков, контрольных процедур, комплаенс-правил, матриц полномочий и индикаторов риска. У части отечественных продуктов просматривается платформенная логика по правилам, процессам, интеграциям и аудиту. Тем не менее в ряде решений low-code выступает скорее как надстройка, но их можно гибко адаптировать к изменениям регуляторики и внутренних политик. </p> <p>Среди догоняющих — рынок ECM/CSP/СЭД <nobr>(35–50%).</nobr> Low-code здесь активно используется для моделирования маршрутов документов, настройки карточек, бизнес-правил, согласований. Однако в большинстве платформ он все еще остается скорее мощным инструментом конфигурирования и кастомизации, чем полноценным архитектурным ядром. Ядро системы (хранение больших объемов документов, сложный поиск, механизмы версионности) по-прежнему в значительной степени опирается на традиционную разработку. В классических СЭД low-code представлен слабее всего, в ECM — тормозится монолитной архитектурой и сложностью адаптации. Значительно лучше ситуация с CSP, хотя весь сегмент движется в сторону процессов, форм, порталов и гибких настроек.</p> <p>А вот в «тяжелых» транзакционных и аналитических системах картина принципиально иная. В ERP проникновение low-code составляет всего <nobr>5-15%,</nobr> в BI — <nobr>15-30%,</nobr> а в IBP/CPM — <nobr>25-40%.</nobr> В этих классах low-code преимущественно используется как надстройка для self-service аналитики, работы с отчетами и дашбордами, настройки расширений, простых бизнес-правил. При этом он почти не затрагивает ядро: модели данных, сложные расчеты, высоконагруженные транзакции и механизмы обеспечения целостности. </p> <p>В ERP нет убедительных примеров полноценных low-code платформ или low-code конструкторов (класс слишком тяжелый для этого), хотя достаточно много продуктов с глубокой настройкой.</p> <p>Объяснить такой разрыв можно тем, что в ERP, BI и IBP критически высока доля сложной доменной логики, жестких транзакционных зависимостей, детализированных расчетов и глубоко проработанных отраслевых моделей данных. Здесь ошибки обходятся слишком дорого, а требования к надежности, производительности и безопасности значительно выше. Кроме того, в BPM, CRM и ESM/ITSM уже сформировалась культура платформенного подхода, DevOps-практики. В ERP и BI этот переход идет медленнее из-за масштаба внедрений, длительных жизненных циклов проектов и высокой инертности легаси-архитектур.</p> <p>«Российский рынок массово использует термин low-code, но за ним скрываются совершенно разные технологические подходы: от полноценной платформенной разработки бизнес-критичных приложений до кастомизации готовых продуктов. Поэтому ключевой вопрос не в наличии low-code-инструментов, а в глубине их проникновения в архитектуру. И здесь картина крайне неоднородна: в таких классах, как BPM, CRM, ESM/ITSM и риск-системы, low-code уже выступает как базовый архитектурный слой. А вот в ERP, BI и IBP он чаще остается на уровне „надстройки“ или ограничивается лишь визуализацией», — считает Денис Голдобин, управляющий директор-партнер GreenData. </p> <p>В ближайшее время, по прогнозам GreenData, именно преодоление этого разрыва станет главным драйвером развития российского low-code рынка. Вендоры «тяжелых» систем будут постепенно переходить к модульной архитектуре, в которой low-code помогает выстраивать процессы и логику, бизнес-правила и пользовательский опыт, а высоконагруженное ядро по-прежнему останется на специализированных технологиях и классической разработке.</p> В GreenData проанализировали восемь классов отечественных бизнес-критичных систем по уровню проникновения low-code … message https://www.itweek.ru/themes/detail.php?ID=234889 Tue, 26 May 2026 10:25:17 +0300 <p>Клиентам Банка Русский Стандарт из сегмента микро- и малого бизнеса стал доступен функционал Автоматизированной упрощенной системы налогообложения (АУСН), внедренный компанией BSS на базе ее промышленного решения.</p> <p>Банк Русский Стандарт развернул сервис Автоматизированной упрощенной системы налогообложения (АУСН) от компании BSS. Теперь клиенты — предприниматели и малый бизнес — могут подключить новый бездекларационный налоговый режим прямо в Интернет-банке RSB Business Online и управлять им непосредственно в интерфейсе системы дистанционного банковского обслуживания, а передача данных о доходах для расчета налога будет происходить автоматически. Предоставление клиентам возможностей АУСН соответствует стратегии банка по активному развитию цифровых сервисов для бизнеса и расширению каналов взаимодействия.</p> <p>При выборе технологического партнера для внедрения АУСН Банк Русский Стандарт отдал предпочтение экспертизе и опыту компании BSS и ее решению как наиболее функциональному и проверенному на рынке. На сегодняшний день модуль АУСН от BSS уже функционирует в восьми российских банках, включая Банк Русский Стандарт. Все финансовые организации, внедрившие решение BSS, успешно прошли аккредитацию Федеральной налоговой службы и включены в реестр уполномоченных кредитных организаций.</p> <p>Решение BSS, построенное на платформе Digital2Go, представляет собой готовый промышленный тиражируемый российский продукт, не имеющий аналогов на рынке. В отличие от самостоятельной разработки «с нуля» (сроки — от года, бюджет — десятки миллионов рублей), клиенты BSS используют испытанное коробочное решение с тремя ключевыми компонентами: клиентским интерфейсом в ДБО, интеграционным адаптером для обмена данными и аналитической системой для разметки операций и расчета НДФЛ.</p> <p>Клиенты банка получают возможность автоматической передачи транзакций в налоговую службу для расчета налога без представления декларации, а также полный спектр функций для оплаты налогов, передачи сведений о сотрудниках и мониторинга кассовых операций.</p> <p>«Внедрение тиражируемого решения BSS по АУСН в Банке Русский Стандарт еще один успешный кейс решения потребности банка в короткие сроки с гарантированным результатом. Мы предлагаем готовое промышленное решение для использования АУСН в банковском ДБО, полностью протестированное. Наша команда сопровождает банки на всех этапах: от развертывания до прохождения аккредитационных испытаний. Такой подход позволяет нашим партнерам запускать сервис в <nobr>3–5</nobr> раз быстрее и с существенно меньшими затратами по сравнению с собственной разработкой», — подчеркнула Юлия Савинова, руководитель направления по развитию цифровых продуктов Центра цифровых решений для бизнеса компании BSS.</p> <p>Запуск АУСН в Банке Русский Стандарт открывает новые возможности для привлечения и удержания клиентов МСБ: переход на данный налоговый режим возможен исключительно при обслуживании в уполномоченном банке. Решение BSS, доказавшее свою надежность на практике, позиционируется как наиболее предсказуемый путь для финансовых организаций, стремящихся минимизировать риски при прохождении аккредитации.</p> Клиентам Банка Русский Стандарт из сегмента микро- и малого бизнеса стал доступен функционал Автоматизированной … message https://www.itweek.ru/themes/detail.php?ID=234887 Tue, 26 May 2026 09:34:12 +0300 <p><em>Еще два года назад корпоративное внедрение искусственного интеллекта в большинстве российских компаний выглядело скорее экспериментом, чем полноценной бизнес-практикой. Нейросети использовались точечно: маркетологи тестировали генерацию текстов, HR — автоматический подбор резюме, отделы поддержки — чат-ботов с заранее прописанными сценариями.</em></p> <p><em>Сегодня рынок вступает в другую фазу. Компании все чаще рассматривают ИИ не как отдельный инструмент, а как инфраструктурный слой, встроенный в ежедневные процессы. Причина проста: давление на эффективность растет, а количество рутинных операций продолжает увеличиваться.</em></p> <p>На этом фоне бизнес постепенно смещает фокус с демонстрационных сценариев — вроде генерации изображений или маркетинговых текстов — к более прикладным задачам: автоматизации документооборота, управлению знаниями, внутренним консультациям и сокращению операционной нагрузки.</p> <p>Переход от экспериментального использования ИИ к встроенным бизнес-инструментам подтверждается и динамикой рынка. По <a href="https://www.mckinsey.com/capabilities/quantumblack/our-insights/the-state-of-ai">данным McKinsey</a>, в 2025 году уже более 70% компаний в мире использовали искусственный интеллект хотя бы в одной бизнес-функции, а наиболее активно ИИ внедряется в процессы, связанные с клиентским сервисом, маркетингом, аналитикой и управлением знаниями.</p> <p>Особенно заметно этот тренд проявляется в средах с высокой сложностью принятия решений — там, где сотрудники ежедневно работают с большим объемом регламентов, процедур и повторяющихся запросов.</p> <h3>Почему сложные процессы становятся идеальной средой для ИИ</h3> <p>Во многих компаниях значительная часть рабочего времени уходит не на принятие решений, а на поиск информации, сверку нормативных требований, интерпретацию внутренних правил, повторяющиеся консультации и навигацию по системам. Фактически специалист часто становится посредником между сотрудником и корпоративным знанием.</p> <p>Особенно остро эта проблема проявляется в сферах, где ошибки дорого стоят: финансах, логистике, юридической функции, соблюдении нормативных требований и закупках.</p> <p>Закупочная функция — один из наиболее показательных примеров. Работа с закупками, особенно в сегменте регулируемых процедур, требует постоянной работы с нормативной базой, документацией, сроками, техническими требованиями и внутренними регламентами. Даже опытные специалисты регулярно сталкиваются с необходимостью уточнять детали процедур, проверять требования или консультироваться по нестандартным ситуациям.</p> <p>В результате бизнес сталкивается сразу с несколькими издержками:</p> <ul> <li> сотрудники тратят значительное время на поиск информации;</li> <li> возрастает нагрузка на внутреннюю поддержку;</li> <li> новые специалисты дольше проходят адаптацию;</li> <li> ошибки в документации приводят к дополнительным затратам.</li> </ul> <p>Именно в таких процессах ИИ становится особенно полезным, поскольку позволяет работать с объемом информации, который сложно обработать вручную в ограниченные сроки. Алгоритмы способны быстро анализировать документацию, выявлять закономерности, сопоставлять данные и находить потенциальные риски. В отличие от последовательного человеческого анализа, ИИ обрабатывает множество параметров одновременно, что ускоряет подготовку к закупкам и снижает вероятность пропустить важные детали.</p> <h3>От чат-бота к рабочему инструменту</h3> <p>Дискуссия вокруг корпоративного ИИ во многом все еще сводится к чат-ботам, хотя бизнес уже движется в сторону более глубокой интеграции интеллектуальных инструментов в рабочие процессы.</p> <p>Если ранний этап внедрения был связан преимущественно с внешними интерфейсами взаимодействия — отдельными помощниками, работающими по принципу «вопрос — ответ», — то новая модель строится вокруг встроенных ИИ-ассистентов, интегрированных непосредственно в корпоративную среду.</p> <p>Изменение здесь носит не косметический, а архитектурный характер. Искусственный интеллект постепенно становится интерфейсом доступа к корпоративным знаниям, внутренним регламентам и функциональности цифровых систем. ИИ меняет саму логику поиска информации. Раньше сотрудник тратил время на поиск источников и понимание, где именно искать ответ. Теперь система анализирует данные сразу по всему информационному пространству и выдает готовый результат. В этих условиях фокус смещается: важнее становится не поиск как таковой, а умение точно формулировать запросы и проверять корректность ответов, которые предлагает ИИ.</p> <p>Подобная модель уже формируется в CRM-системах, ERP-платформах, корпоративном документообороте и сервисных решениях. Постепенно аналогичный подход распространяется и на более специализированные отраслевые процессы — в том числе на закупочную функцию, где скорость доступа к информации напрямую влияет на качество решений и операционную эффективность.</p> <h3>Как ИИ начинает менять закупки по <nobr>223-ФЗ</nobr></h3> <p>Закупочная функция в сегменте <nobr>223-ФЗ</nobr> долгое время оставалась одной из наиболее сложных сред для интеллектуальной автоматизации. Высокая регуляторная нагрузка, объемная документация и значительная стоимость ошибки ограничивали возможности для масштабного внедрения ИИ в процессах, где ошибка может повлечь нарушение требований или срыв процедуры, бизнес традиционно осторожно относится к автоматизации.</p> <p>Ситуация начала меняться по мере развития корпоративных ИИ-инструментов. Если ранние сценарии ограничивались точечными консультационными сервисами или навигацией пользователей внутри отдельных процедур, то сегодня рынок постепенно движется к более глубокой интеграции интеллектуальных ассистентов непосредственно в рабочую среду закупок.</p> <p>Практический смысл таких решений связан прежде всего с оптимизацией рутинной интеллектуальной работы. Закупочным специалистам ежедневно приходится одновременно учитывать требования законодательства, внутренние регламенты, сроки, закупочную документацию и функциональность электронных систем. Значительная часть времени при этом расходуется на поиск, сверку и интерпретацию информации, а не на принятие решений как таковых.</p> <p>В электронных закупках интеллектуальные ассистенты берут на себя часть рутинной навигации и поддержки пользователя. Они могут объяснить условия закупки, помочь разобраться в требованиях документации, подсказать релевантные сервисы платформы, ответить на вопросы по процедурам и нормативным требованиям, а также быстро находить нужную информацию без ручного поиска по базе знаний или инструкциям. Это меняет сам сценарий взаимодействия с системой: вместо поиска ответа пользователь сразу работает с готовой информацией в контексте своей задачи.</p> <h3>Что получает бизнес на практике</h3> <p>Главный эффект подобных решений заключается не в технологической новизне, а в перераспределении времени сотрудников. Когда специалист перестает тратить часы на поиск информации, повторяющиеся консультации и ручную навигацию по сложным интерфейсам, появляется возможность перераспределить ресурсы в пользу задач с более высокой добавленной стоимостью.</p> <p>На практике компании обычно рассчитывают сразу на несколько эффектов:</p> <ul> <li> сокращение времени поиска информации;</li> <li> ускорение адаптации новых сотрудников;</li> <li> снижение числа типовых ошибок;</li> <li> уменьшение нагрузки на внутреннюю поддержку;</li> <li> более быстрое принятие решений.</li> </ul> <p>Рост интереса бизнеса к ИИ-ассистентам объясняется и экономикой процессов. По разным оценкам, автоматизация повторяющихся интеллектуальных операций позволяет сотрудникам экономить до <nobr>20-30%</nobr> рабочего времени, особенно в функциях с высокой административной нагрузкой. Для компаний это означает не только рост производительности, но и снижение стоимости адаптации новых сотрудников, ускорение внутренних процессов и меньшую зависимость от экспертных знаний отдельных специалистов.</p> <p>Для руководителей это означает заметное снижение зависимости процессов от конкретных сотрудников — особенно в функциях, где накоплен значительный объем внутренней экспертизы. Именно поэтому ИИ-ассистенты уже начинают менять не только рабочие процессы, но и структуру команд. Когда часть рутинных задач автоматизируется, а выполнение операций становится более прозрачным, руководители получают возможность точнее оценивать эффективность работы и реальный вклад сотрудников. В таких условиях спрос смещается в сторону специалистов, чья работа создает более высокую ценность для бизнеса — через экспертизу, принятие решений и контроль качества результатов, в том числе предоставляемых ИИ.</p> <h3>От ассистентов к полуавтоматическим решениям</h3> <p>Текущий этап внедрения ИИ в корпоративные процессы, вероятно, станет промежуточным. Следующий шаг — переход к более активной роли искусственного интеллекта.</p> <p>В закупках это может означать автоматическую подготовку части документации, предварительную проверку соответствия требованиям, рекомендации по процедурам, интеллектуальный поиск рисков и развитие аналитических сценариев.</p> <p>Иными словами, рынок постепенно движется от модели «ИИ отвечает на вопрос» к модели «ИИ помогает выполнять работу».</p> <p>Для бизнеса внедрение ИИ означает не только перераспределение задач, но и изменение требований к персоналу. Когда выполнение процессов становится измеримым, а рутинные операции — автоматизированными, руководители получают более четкое понимание эффективности команд и вклада каждого сотрудника. В таких условиях большую ценность приобретают специалисты, способные работать со сложными задачами, принимать решения и усиливать результат бизнеса, а не выполнять повторяющиеся операции.</p> <p>Именно в прикладных сценариях, где ИИ способен снижать операционную нагрузку, ускорять принятие решений и повышать управляемость процессов, будет определяться его реальная ценность для бизнеса. Вероятно, именно здесь искусственный интеллект окончательно перейдет из категории технологического эксперимента в статус базовой корпоративной инфраструктуры.</p> <p>#IMAGE_234888#</p> Еще два года назад корпоративное внедрение искусственного интеллекта в большинстве российских компаний выглядело скорее … article Дмитрий Чукин, генеральный директор ”Торги223” https://www.itweek.ru/themes/detail.php?ID=234886 Tue, 26 May 2026 09:26:01 +0300 <p><em>Следующий этап развития корпоративного искусственного интеллекта может определяться не столько возможностями моделей, сколько физической инфраструктурой и операционной дисциплиной, необходимыми для его поддержки. В то же время амбиции индустрии ИИ в отношении инфраструктуры начинают сталкиваться с физической реальностью, отмечают опрошенные порталом </em><em>InformationWeek</em> <em>эксперты.</em></p> <p>Опубликованные в последние недели многочисленные отчеты указали на задержки и ограничения, влияющие на расширение мощностей для ИИ, от проблем со строительством дата-центров до растущей обеспокоенности по поводу доступности электроэнергии. Недавний <a href="https://am.jpmorgan.com/wr/en/asset-management/institutional/insights/market-insights/market-updates/on-the-minds-of-investors/energy-infrastructure-ais-power-play/">анализ</a> JPMorgan показал растущее давление на энергетическую инфраструктуру по мере ускорения связанного с ИИ спроса на электроэнергию. Кроме того, юридические споры, задержки с получением разрешений и сложность контрактов все больше замедляют развитие новых дата-центров для ИИ-нагрузок.</p> <p>В то же время крупные технологические компании продолжают увеличивать свои расходы на инфраструктуру ИИ, что подтверждает ожидания того, что спрос предприятий на вычислительные ресурсы также будет продолжать резко расти.</p> <p>Для CIO эту проблему становится все труднее игнорировать. Дискуссия об ИИ сейчас в основном сосредоточена на моделях, приложениях и повышении производительности. Гораздо меньше внимания уделяется инфраструктуре, необходимой для поддержания масштабного внедрения ИИ на предприятиях, а также тому, что произойдет, если эта инфраструктура окажется ограниченной, с задержками или регионально неравномерной.</p> <p>Дэвид Линтикум, основатель Linthicum Research и бывший управляющий директор Deloitte, считает, что отрасль уже сталкивается с «классическим несоответствием между объявленными инвестициями и развертываемыми мощностями».</p> <p>Непосредственный риск заключается не обязательно в резком дефиците мощностей для ИИ. Более вероятен постепенный переход к более ограниченной операционной среде, где инференс становится дороже, доступ менее предсказуемым, а решения о приоритизации все более неизбежными. Эта перспектива уже побуждает некоторых технологических лидеров переосмыслить предположения, лежащие в основе их планов развития ИИ.</p> <h3>Разрыв между инвестициями в ИИ и операционными мощностями</h3> <p>Масштабы инвестиций, направляемых в инфраструктуру ИИ, остаются огромными, при этом гиперскейлеры и поставщики ИИ продолжают тратить миллиарды в погоне за будущим объемом вычислений. Но некоторые эксперты заявляют, что отрасль, возможно, недооценивает, насколько сложно преобразовать капитальные затраты в операционные мощности для ИИ. По их мнению, проблема заключается в том, что масштабирование физической инфраструктуры происходит гораздо медленнее, чем того требует ПО.</p> <p>«Капиталовложения попадают в заголовки новостей, но доступность электроэнергии, получение разрешений, модернизация сетей, вопросы охлаждения, поставка специализированного оборудования и сроки строительства замедляют реальную реализацию, — отмечает Линтикум. — Деньги движутся быстрее, чем инфраструктура».</p> <p>Эдвард Либиг, CEO и CISO Yoink Industries и адъюнкт-профессор Вашингтонского университета в Сент-Луисе, подчеркивает, что проблема выходит за рамки доступности вычислительных ресурсов. «Кривая спроса на инфраструктуру ИИ, похоже, опережает не только строительство дата-центров, но и доступность электроэнергии, охлаждение, масштабируемость межсоединений и операционную интеграцию, необходимые для надежного запуска этих сред», — говорит он.</p> <p>Однако Либиг также предостерегает от того, чтобы рассматривать ограничения инфраструктуры исключительно как проблему ее предоставления. По его мнению, это давление выявляет слабые места в подходах самих предприятий к развертыванию ИИ. «Мы начинаем видеть, как ограничения инфраструктуры выявляют, есть ли у организаций стратегия дисциплинированной работы с ИИ или это просто совокупность разрозненных инициатив в области ИИ, конкурирующих за ресурсы», — говорит он.</p> <p>Это различие может становиться все более важным по мере того, как предприятия расширяют внедрение ИИ в различных отделах. Многие организации одновременно экспериментируют с «вторыми пилотами», рабочими процессами с поддержкой ИИ, аналитическими инструментами, системами поиска и агентными системами, часто без централизованного управления или операционной приоритизации. Либиг описывает результат всего этого как «разрастание ИИ», когда спрос на инфраструктуру растет быстрее, чем измеримая бизнес-ценность. «Организации, наиболее страдающие от нехватки мощностей для ИИ, могут быть не теми, у кого меньше всего инфраструктуры, а теми, у кого меньше всего операционной дисциплины в отношении развертывания ИИ», — говорит он.</p> <h3>Как могут проявляться инфраструктурные ограничения</h3> <p>Не все эксперты считают, что предприятия столкнутся с немедленным кризисом мощностей для ИИ. Дональд Фармер, футуролог из Tranquilla AI, занимает более взвешенную позицию, утверждая, что у многих CIO может быть больше времени, чем кажется. «Мы ожидаем, что основным двигателем внедрения в корпоративной среде станет агентный ИИ, а не генеративный ИИ, — говорит он, ссылаясь на исследование TDWI, которое показывает, что только 31% компаний считают, что внедрение агентного ИИ происходит уже сейчас, тогда как 49% прогнозируют, что это займет от 1 до 5 лет. — Поэтому я подозреваю, что у производства электроэнергии еще есть время для ускорения этого процесса».</p> <p>Фармер также указывает на повышение эффективности как моделей, так и оборудования, что снизит вычислительную нагрузку. Тем не менее, несколько экспертов сходятся во мнении, что ограничения, вероятно, будут возникать неравномерно, при этом средние предприятия могут столкнуться с наибольшим давлением в периоды пиковой нагрузки.</p> <p>«Я подозреваю, что нагрузкам обучения ничего не грозит, — говорит Фармер. — В условиях, когда мощности ограничены, гиперскейлеры, предположительно, будут отдавать приоритет своим собственным рабочим нагрузкам ИИ и своим крупнейшим корпоративным клиентам».</p> <p>Линтикум аналогично формулирует проблему не как явный дефицит, а скорее как периодическую нестабильность. «Самый большой риск заключается не в том, что ИИ не сможет работать, ​​а в том, что доступ станет дороже, будет страдать задержками или будет неравномерным в зависимости от региона и поставщика», — говорит он.</p> <p>Это различие важно, поскольку многие корпоративные стратегии в области ИИ в настоящее время предполагают относительно беспрепятственный доступ к вычислительным ресурсам. Организациям, разрабатывающим планы по быстрому экспериментированию, инференсу в реальном времени и постоянно доступным сервисам ИИ, возможно, потребуется подготовиться к более ограниченной среде, чем они первоначально предполагали.</p> <p>«Один из возникающих рисков заключается в том, что организации могут непреднамеренно выстроить бизнес-процессы, предполагающие бесконечную доступность ИИ и бесконечную скорость обработки инференса, — говорит Либиг. — Физическая инфраструктура может поставить под сомнение это предположение раньше, чем многие ожидают».</p> <h3>Управление ИИ становится инфраструктурной проблемой</h3> <p>Перспектива ограниченных возможностей ИИ также начинает менять дискуссии об управлении и приоритизации.</p> <p>Либиг утверждает, что предприятия, ориентированные на операционную надежность и отказоустойчивость, в конечном итоге могут оказаться в более выгодном положении в периоды давления на инфраструктуру, поскольку они, как правило, более обдуманно расширяют ИИ. Эти компании, как правило, отдают приоритет критически важным для операционной деятельности сценариям использования и расширяют их постепенно после подтверждения ценности, управления и контроля.</p> <p>«Ограниченное расширение создает устойчивость, поскольку организации могут расставлять приоритеты для наиболее важных функций ИИ, когда условия инфраструктуры ужесточаются», — говорит Либиг.</p> <p>Такой подход также меняет то, как CIO оценивают инвестиции в ИИ внутри компании. Центральный вопрос смещается от приобретения дополнительных мощностей для ИИ к определению того, для каких рабочих нагрузок оправдан приоритетный доступ к ограниченной инфраструктуре.</p> <p>Линтикум описывает аналогичную необходимость в операционной дисциплине. Он утверждает, что CIO должны начать разделять инициативы в области ИИ на уровни — критически важные, важные и экспериментальные, — чтобы распределение инфраструктуры стало целенаправленным, а не реактивным. «Предприятия без планов на случай непредвиденных обстоятельств наиболее уязвимы», — говорит он.</p> <p>Этот сдвиг может также заставить организации стать более избирательными в отношении того, где действительно необходимы передовые модели ИИ. Фармер отмечает, что многие предприятия уже добиваются успеха с небольшими локальными моделями, работающими на стандартном оборудовании, особенно в средах, где вопросы управления, соответствия нормативным требованиям или стоимости делают зависимость от облачных технологий менее привлекательной. «Не все должно работать на самой последней и лучшей модели», — говорит он.</p> <h3>Что CIO должны спрашивать у поставщиков сейчас</h3> <p>По мере того, как ограничения инфраструктуры становятся все более очевидными, CIO также должны начать рассматривать возможности ИИ как вопрос устойчивости и непрерывности, а не просто как вопрос закупок, считают эксперты. Чтобы предотвратить потенциальные проблемы, ИТ-руководству нужна ясность в отношении текущих поставок.</p> <p>Линтикум отмечает, что предприятиям необходима от поставщиков гораздо большая прозрачность в отношении того, как управляется дефицит мощностей. «Они должны очень прямо спрашивать о гарантиях пропускной способности, региональной доступности, приоритизации очередей, волатильности цен, вариантах резервирования и переносимости между средами», — говорит он.</p> <p>Фармер также утверждает, что обсуждения должны все больше фокусироваться на операционной надежности, а не на наборе функций. Среди вопросов, которые он предложил CIO задавать поставщикам, есть следующие:</p> <ul> <li> Каковы ваши договорные обязательства по доступности пропускной способности в пиковые периоды?</li> <li> Если я беру на себя обязательства по многолетнему резервированию пропускной способности, что это дает мне с точки зрения приоритета по сравнению с клиентами, использующими ресурсы по запросу?</li> </ul> <p>Либиг идет дальше, утверждая, что CIO должны требовать прозрачности в отношении того, как сами поставщики ведут себя в условиях ограниченного ресурса: «Как определяется приоритетность рабочих нагрузок в пиковые периоды спроса? Могут ли сервисы корректно снижать производительность при росте нагрузки на инфраструктуру? Какие существуют зависимости от общих пулов графических процессоров или сторонних поставщиков моделей?».</p> <p>Эти вопросы отражают более широкие изменения, происходящие в стратегии корпоративного ИИ. Доступность инфраструктуры, которая когда-то рассматривалась в основном как абстрактная проблема гиперскейлеров, все чаще становится операционной зависимостью. При разработке планов развития ИИ для предприятий необходимо учитывать не только то, что они хотят видеть в системах ИИ, но и то, сможет ли базовая инфраструктура надежно поддерживать эти амбиции в масштабе.</p> Следующий этап развития корпоративного искусственного интеллекта может определяться не столько возможностями моделей … article https://www.itweek.ru/themes/detail.php?ID=234884 Mon, 25 May 2026 18:03:16 +0300 <p>Компания Avanpost, российский разработчик решений для управления доступом и защиты цифровых идентичностей, объявляет о запуске облачного сервиса Avanpost Identity Cloud. Открыто публичное тестирование сервиса.</p> <p>Участники программы получают пробный период с доступом ко всем функциям сервиса до 1 сентября — с неограниченным числом пользователей — и возможность выстроить защиту корпоративного доступа: от базовой многофакторной аутентификации до тарифа «E-Passport» без капитальных затрат и длительного внедрения. После окончания пробного периода действуют выгодные условия с тарификацией за пользователя.</p> <h3>Эталонная безопасность облака</h3> <p>Avanpost Identity Cloud создан не как «упрощённый» SaaS, а как продолжение зрелой on-premise практики Avanpost, которой много лет доверяют крупные геораспределённые компании с высокими требованиями к кибербезопасности и отказоустойчивости. Возможности и архитектурные принципы корпоративного решения перенесены в облако без потери уровня защиты.</p> <p>Ключевые архитектурные особенности сервиса:</p> <p>● Изоляция тенантов. Для каждого клиента разворачивается независимый tenant: отдельный контур, база данных и политики доступа. Инциденты, ошибки конфигурации или пиковые нагрузки у одного клиента не влияют на других. Уровень изоляции сопоставим с выделенным on-premise решением, но без затрат на собственную инфраструктуру.</p> <p>● Компонент Access Bridge обеспечивает защищённую интеграцию платформы Identity Cloud с корпоративными системами заказчика, сохраняя полный контроль над данными и периметром безопасности.</p> <p>● Гибкость развёртывания. Решение отличается гибкостью развертывания и адаптируется под любую архитектуру — от централизованной до распределённой в изолированных сегментах.</p> <p>● Непрерывность бизнеса. Поддержка офлайн-аутентификации гарантирует непрерывность бизнес-процессов даже при сбоях связи, а централизованное управление из единой административной консоли значительно упрощает внедрение и эксплуатацию.</p> <p>● Простота внедрения. Централизованное управление через единую административную консоль реализует принцип plug-and-play, исключая необходимость ручной настройки локальных компонентов и значительно упрощая внедрение.</p> <p>● Безопасность. При этом критически важные секреты приложений (LDAP, RADIUS) обрабатываются исключительно внутри контура заказчика и не передаются за его пределы, обеспечивая высокий уровень безопасности.</p> <h3>Поэтапная защита: единая платформа с четырьмя тарифами</h3> <p>Avanpost Identity Cloud построен как ступенчатая модель: любая компания может стартовать с базового второго фактора и без смены платформы дорастать до Zero Trust по мере зрелости и появления новых задач бизнеса.</p> <p>Тарифы:</p> <p><strong>Start</strong>. Быстрый уход от одной только парольной защиты для VPN, веб-приложений и типовых корпоративных сценариев. Поддержка SSO для веб-приложений, широкий набор методов 2FA (Push в мобильный аутентификатор, программный и аппаратный TOTP, аппаратные OTP-токены), интеграция по OpenID Connect, SAML, RADIUS и LDAP, удобный самостоятельный первый вход пользователя.</p> <p><strong>Expert</strong>. Адаптивная и контекстная аутентификация: способ проверки подстраивается под IP-адрес, группу пользователя, сценарий входа и уровень риска. Разные правила для обычных сотрудников, подрядчиков, администраторов и привилегированных учётных записей — с возможностью усиления проверки физическим фактором (аппаратные токены, смарт-карты) для критичных операций. Базовая риск-ориентированная защита и расширенные сценарии аварийного и офлайн-входа.</p> <p><strong>E-passport</strong>. Реализация с Unified SSO — единая защищённая сессия между приложениями, десктоп-приложениями, инфраструктурными и legacy-сценариями. Поддержка аппаратных факторов и электронной подписи, криптографически защищённая сессия, кросс-протокольный SSO.</p> <p><strong>Zero Trust.</strong> Непрерывная проверка доступа с учётом пользователя, устройства, контекста и риска. Идентификация и профилирование устройств, политики доверия, риск-ориентированные решения о доступе, усиление проверки при смене контекста или устройства. Особенно актуально для распределённой работы и BYOD. Самый надёжный доступ к корпоративным ресурсам.</p> <h3>Кому подойдёт сервис</h3> <p>Защита с использованием дополнительных факторов аутентификации и систем единого входа (SSO) становится неотъемлемым элементом базовой кибергигиены современной компании.</p> <p>Сервис Avanpost Identity Cloud ориентирован на широкий круг организаций — от среднего до крупного бизнеса — особенно тех, кто использует гибридные или облачные ИТ-ландшафты.</p> <p>Продукт представляет ценность как для собственников бизнеса, заинтересованных в снижении рисков и защите активов, так и для ИТ- и ИБ-специалистов, отвечающих за надежность инфраструктуры. Отдельное внимание уделено удобству сотрудников: реализован безопасный и интуитивно понятный единый доступ ко всем корпоративным системам, что повышает продуктивность и снижает вероятность ошибок при работе с учетными данными.</p> <p>В рамках программы доступны все функции максимального тарифа, без ограничений по количеству пользователей. С 1 сентября 2026 года доступна выгодная ежемесячная тарификация по уникальным пользователям — оплата осуществляется по факту использования сервиса.</p> <p>«Мы намеренно пошли ’’снизу вверх’’ — от on-premise к облаку, а не наоборот. За годы работы с крупными заказчиками мы хорошо понимаем, какие требования бизнес предъявляет к кибербезопасности, отказоустойчивости и изоляции данных, и заложили это в архитектуру Avanpost Identity Cloud с первого дня. Изоляция тенантов, Access Bridge с защищённым хранением секретов, поддержка корпоративных протоколов в одной точке — всё это отличает enterprise-облако от типового MFA-сервиса. При этом мы хотим, чтобы средний бизнес и привлекаемые в роли подрядчиков компании получили возможность стартовать быстро: поэтому мы открываем пробный период всех функций сервиса. Каждая компания сможет попробовать и выстроить защиту — от базовых механизмов до полноценной модели Zero Trust — на единой платформе», — пояснила Надежда Поленовская, директор партнерского и клиентского маркетинга Avanpost.</p> Компания Avanpost, российский разработчик решений для управления доступом и защиты цифровых идентичностей, объявляет … message https://www.itweek.ru/themes/detail.php?ID=234879 Mon, 25 May 2026 08:58:11 +0300 <p><em>Forrester прогнозирует, что к 2030 г. искусственный интеллект приведет к исчезновению 49% существующих рабочих мест в сфере обслуживания клиентов, пишут в корпоративном блоге вице-президенты и главные аналитики </em><em>Forrester</em> <em>Кейт Леггетт и Лаура Рамос.</em></p> <p>Мы уже видим, как контакт-центры оптимизируют свои организационные структуры, сокращая количество руководителей групп. ИИ берет на себя работу по обучению и планированию. Когда это переход завершится, основная задача человеческого труда сместится от реактивного взаимодействия с клиентами к прямому управлению ИИ, который с ними взаимодействует. Изменятся и выполняемые задачи. В частности:</p> <ul> <li> Руководители службы поддержки клиентов будут использовать ИИ для смещения стратегии в сторону создания ценности для клиента, а не только операционного совершенства. Они будут отвечать за создание большей ценности для клиента и рост доходов. Этот сдвиг уже происходит: согласно последнему отчету Salesforce «State of Service», 85% лиц, принимающих решения, ожидают, что служба поддержки внесет больший вклад в выручку.</li> <li> Деятельность представителей службы поддержки клиентов (customer service representatives, CSR) расширится, и она станет более специализированной. Вместо непосредственного решения запросов клиентов, CSR низшего звена будут управлять командами ИИ-агентов, помогать им решать вопросы, требующие участия человека, и предоставлять ИИ обратную связь для оптимизации его результатов. CSR более высокого звена также будут специализироваться: некоторые займут более технические должности, будут экспертами по политике или возьмут на себя больше обязанностей по управлению взаимоотношениями с клиентами.</li> <li> Операционные роли получат стратегический импульс благодаря помощи ИИ. Инсайты о клиентах, полученные с помощью разговорного ИИ и анализа диалогов, позволят службе поддержки клиентов стимулировать инновации в процессах и продуктах. Команды аналитиков начнут проводить детальный анализ реальной производительности и стоимости операций, вплоть до стоимости автоматизации конкретного намерения.</li> <li> ИТ-роли расширятся для поддержки маховика инноваций, которым движет ИИ. Инструменты low-code сделают настройку и оптимизацию ИИ-агентов доступными для гражданских разработчиков. Это откроет новые «легкие технологические» профессии по созданию ИИ-агентов, а также другие профессии, которые управляют качеством результатов и процессов ИИ. ИИ также сохранит традиционные ИТ-должности, отвечающие за интеграцию инструментов и агентов ИИ в более широкую инфраструктуру обслуживания клиентов, бэк-офис и системы телефонии.</li> </ul> <p> #IMAGE_234880#</p> <h3>Что моделирование Forrester говорит о влиянии ИИ на должностные роли в ближайшие годы</h3> <p>Самые важные вопросы сегодня: какие должности в сфере обслуживания клиентов пострадают больше всего? Как быстро произойдет сокращение этих должностей? И превзойдет ли обычная текучесть кадров способность руководства переквалифицировать или повысить квалификацию оставшихся сотрудников?</p> <p>Forrester проанализировала потенциальное влияние ИИ на организации, занимающиеся обслуживанием клиентов. Мы сделали некоторые предположения о соотношении численности персонала и темпов сокращения. Мы использовали эти данные для создания двух моделей, отражающих сценарии численности персонала на двух- и пятилетнем временных горизонтах. Результаты моделирования выделяют важные изменения, которые руководители служб поддержки клиентов должны учитывать в своих сценариях:</p> <ul> <li> В контакт-центрах с большим объемом работы будет наблюдаться пропорционально большее сокращение персонала. На основе нашего исследования потенциала автоматизации с помощью ИИ мы ожидаем, что организации, обрабатывающие в месяц сотни тысяч запросов и более — как правило, B2C-организации — столкнутся с наибольшим сокращением штата. Организации с меньшим объемом запросов — как правило, из сферы B2B — увидят меньший процент первичных обращений, обработанных ИИ, из-за более длительных рабочих процессов с бóльшим количеством исключений.</li> <li> Руководителям службы поддержки клиентов потребуются новые способы оценки производительности и влияния на клиентов. Для прогнозирования будущих уровней штатного персонала ведущие команды проводят имитационные упражнения, моделирующие увеличение показателей удержания с помощью ИИ при сохранении стабильного объема взаимодействий. Они рассматривают более широкое влияние человеческого взаимодействия на удовлетворенность клиентов, удержание и доход. Они также включают прогнозы заработной платы для определения реальной рентабельности инвестиций в ИИ.</li> </ul> <p>Этот переход в сфере управления персоналом будет невероятно сложным. Вы должны понимать навыки, необходимые для каждой задачи. Используйте эту информацию для переквалификации или повышения квалификации ваших сотрудников. Вам придется активно заниматься управлением изменениями. Вам также придется переосмыслить организационные структуры и ответственность организации за операции, выполняемые ИИ.</p> Forrester прогнозирует, что к 2030 г. искусственный интеллект приведет к исчезновению 49% существующих … article https://www.itweek.ru/themes/detail.php?ID=234878 Mon, 25 May 2026 08:48:44 +0300 <p><em>По мере роста корпоративных проектов в области искусственного интеллекта компаниям необходимо оценить, может ли существующая сетевая инфраструктура поддерживать растущие потребности ИИ. Мэри Шеклет, президент консалтинговой компании Transworld Data, предлагает на портале </em><em>InformationWeek</em> <em>пять шагов, которые помогут руководителям сетевых подразделений подготовиться к рабочим нагрузкам ИИ.</em></p> <p>Предприятия вкладывают значительные средства в инструменты и проекты ИИ, но модернизация сети слишком часто остается вне списка инвестиций. Современные сети были созданы для быстрой обработки транзакций, электронной почты, веб-браузинга, передачи файлов и запросов к базам данных — но смогут ли они справиться с ежедневным использованием ИИ в корпоративных и периферийных теневых сетях, и что теперь должны делать CIO и сетевые администраторы?</p> <h3>Оцените свою текущую сеть</h3> <p>Из-за недостатка эмпирических данных никто точно не знает, как ИИ повлияет на ИТ или сети. С точки зрения сети, ИИ потребует пропускной способности для больших объемов данных, и поскольку подразделения по всей компании, вероятно, будут использовать ИИ в режиме по запросу, сетевому персоналу будет сложно заранее настроить пропускную способность сети и приоритеты среды исполнения на основе регулярного и предсказуемого графика.</p> <p>Вот почему крайне важно каталогизировать и оценить текущие возможности сети. Как работает сеть с точки зрения пропускной способности, задержки, безопасности, надежности, качества обслуживания и сетевого управления? Есть ли узкие места в производительности? Обновлены ли маршрутизаторы, серверы и точки доступа?</p> <p>Проведение оценки сети дает организациям понимание базового уровня, на основе которого они могут планировать модернизацию сети для рабочих нагрузок ИИ.</p> <h3>Пообщайтесь с заинтересованными в ИИ сторонами</h3> <p>Практически само собой разумеется, что почти каждый отдел в организации будет использовать ту или иную форму генеративного ИИ, даже если это всего лишь коммерчески доступная версия ChatGPT. Однако в компании будут подразделения, которые решат пойти гораздо дальше. Они захотят приобрести или создать системы ИИ, которые смогут прогнозировать производительность цепочки поставок, ставить медицинские диагнозы или оценивать финансовые риски.</p> <p>Исторически сложилось так, что бизнес-аналитики и ИТ-разработчики встречались с пользователями на ранних этапах концептуальной разработки проектов, но, учитывая жизненно важную роль, которую сеть будет играть в предоставлении ИИ, сейчас для сетевых администраторов не время оставаться в стороне.</p> <p>Вместо этого они должны настаивать на участии в ранних этапах создания концепции и планирования разработки систем ИИ, поскольку эти проекты, вероятно, потребуют модернизации сети. Им также следует разработать способы объяснения технических требований сети простым языком другим лицам, принимающим решения, чтобы все понимали и были согласны с любыми первоначальными инвестициями в сеть, необходимыми для поддержки ИИ.</p> <h3>Инвестируйте в масштабируемые технологии</h3> <p>Возьмем, к примеру, технологию 5G. К концу 2025 г. она приближалась к 100%-ному покрытию в Северной Америке, но некоторые компании все еще отставали, используя маршрутизаторы и коммутаторы, несовместимые с 5G. Если сети должны быть готовы к ИИ, используемые ими маршрутизаторы и коммутаторы должны, как минимум, поддерживать связь 5G и, в идеале, быть модернизируемыми до 6G, когда она станет доступна.</p> <p>То же самое относится к ПО, которое управляет сетью. Если у существующих поставщиков компании отсутствуют планы по масштабированию своей продукции для ИИ, следует рассмотреть новые масштабируемые продукты. Установленные серверные базы, а также системы хранения данных SAN и NAS также должны быть модернизированы для ИИ.</p> <p>Во всех случаях цель сетевых администраторов состоит в том, чтобы запрашивать обновления технологий, готовых к внедрению ИИ, со сроком службы не менее пяти лет, поскольку никто не хочет через год-два обращаться к высшему руководству с просьбой о новом обновлении.</p> <h3>Рассмотрите облачный подход к ИИ</h3> <p>Один из способов решения проблемы масштабируемости — развертывание ИИ в облаке, где вы можете постепенно масштабировать свои сетевые ресурсы по мере необходимости. Этот подход имеет смысл по двум причинам:</p> <ol> <li> Уже существует опыт масштабирования компаниями своих облачных ресурсов и расходов, который, похоже, приемлем для руководства.</li> <li> Поскольку никто точно не знает, какие ресурсы потребуются для корпоративного ИИ, вы можете масштабировать их вверх или вниз в облаке без риска приобретения сетевых активов, которые вам могут не понадобиться.</li> </ol> <p>Облачный ИИ может быть развернут в виде частного облака для подразделений, которым необходима надежная защита и контроль безопасности для своего ИИ. В облаке компании также имеют возможность разделять ресурсы и расходы с другими. Аналогичным образом, можно масштабировать варианты поддержки ИИ в облаке. Эти варианты варьируются от выбора собственного сетевого персонала для поддержки своей инфраструктуры ИИ в облаке до передачи этой функции облачному провайдеру.</p> <h3>Защитите ИИ</h3> <p>Компаниям, использующим ИИ в нескольких отделах, следует рассмотреть возможность внедрения сетей с нулевым доверием, если у них их еще нет. Сеть с нулевым доверием не предоставит пользователю доступ, если у него отсутствуют необходимые учетные данные и разрешения. Концепция нулевого доверия также включает встроенные возможности аудита, которые автоматически оповещают сетевой персонал при обнаружении добавления, удаления или изменения каких-либо ИТ-активов в сети.</p> <p>Сети с нулевым доверием тесно связаны с надежным управлением идентификацией и доступом пользователей, перемещающихся между локальными и мультиоблачными данными для использования в ИИ. Существует три отдельных технологии управления идентификацией, которые следует рассмотреть сетевым администраторам:</p> <ul> <li> Управление идентификацией и доступом (IAM), которое уже используется на большинстве площадок, администрирует и отслеживает действия пользователей и доступ в локальных сетях.</li> <li> Управление правами доступа к облачной инфраструктуре (CIEM), которое выполняет те же функции, что и IAM, только в облаке.</li> <li> Управление идентификацией и администрированием (IGA), которое выступает в качестве общей структуры и единой панели управления, в рамках которых работают как IAM, так и CIEM.</li> </ul> <h3>Действуйте на опережение</h3> <p>Сетевые администраторы стремятся к упреждающему подходу к ИИ, предоставляя масштабируемые, гибкие и оптимизированные сети, способные выдерживать нагрузки ИИ. В то же время у них мало опыта работы с ИИ и понимания того, как он повлияет на сети.</p> <p>Заблаговременное участие в обсуждениях и проектах, связанных с ИИ, позволяет сетевым администраторам лучше подготовиться к тому, чтобы сеть, предназначенная для обработки и передачи данных с ИИ, соответствовала поставленным задачам.</p> По мере роста корпоративных проектов в области искусственного интеллекта компаниям необходимо оценить, может ли … article https://www.itweek.ru/themes/detail.php?ID=234875 Fri, 22 May 2026 16:18:13 +0300 <p>CICADA8, компания по управлению уязвимостями и цифровыми угрозами в реальном времени, представила масштабное обновление первого в России решения для оценки безопасности подрядчиков и дочерних организаций CICADA8 CyberRating, благодаря которому борьба с атаками через партнеров выходит на новый уровень. Теперь российские компании могут проводить всесторонний автоматизированный аудит контрагентов на базе ИИ, от оценки защищенности внешнего ИТ-периметра до анализа зрелости их внутренних процессов ИБ.</p> <p>Новая версия решения дополнена модулем «Опросы» и технологией интеллектуального анализа на базе искусственного интеллекта, которые позволяют автоматизировать аудит внутренних процессов информационной безопасности подрядчиков, контрагентов и дочерних зависимых обществ. Обновленная платформа CICADA8 CyberRating представляет собой комплексный инструмент, который в режиме единого окна объединяет объективный технический скоринг внешнего периметра, включая автоматизированный интеллектуальный поиск сетевой инфраструктуры (доменов и адресов) с глубоким аудитом внутренних процессов компании. </p> <p>Оценка рисков третьих сторон стала критической необходимостью для бизнеса, что напрямую подтверждается позицией регулятора. В конце 2025 года представители ФСТЭК России официально отнесли отсутствие контроля за подрядчиками к числу самых частых типовых нарушений кибербезопасности. С вступлением в силу нового Приказа ФСТЭК № 117 в марте 2026 года требования к защите инфраструктуры при работе с контрагентами стали обязательными.</p> <p>По оценке аналитиков CICADA8, более трети инцидентов в 2025 году были связаны со взломом партнеров и подрядчиков, имеющих доступ в инфраструктуры заказчиков. Крупные компании, стремящиеся контролировать уровень защищенности своих подрядчиков, обычно ограничиваются мониторингом их внешнего ИТ-периметра. Однако за надежно защищенным периметром может скрываться исключительно формальный подход к защите данных: отсутствие внутренних политик информационной безопасности и управления доступом. </p> <p>До сих пор оценка внутренних процессов партнёров оставалась трудоёмкой и плохо масштабируемой задачей: компании обменивались Excel-таблицами, специалисты вручную выверяли сотни ответов и неделями анализировали десятки страниц нормативных документов. Масштабировать такой процесс было сложно, а управлять им в реальном времени — практически невозможно. Поэтому этот аспект информационной безопасности третьих сторон обычно оставался «слепой зоной».</p> <p>Обновленная платформа CICADA8 CyberRating решает эту проблему, впервые объединяя обе вертикали оценки контрагентов в режиме единого окна. Новый модуль «Опросы» превращает рутинный комплаенс в гибкий, прозрачный и управляемый процесс. Платформа уже содержит готовые анкеты, разработанные на основе лучших мировых практик ИБ, а встроенный конструктор позволяет создать индивидуальный опрос с нуля под специфические требования организации. </p> <p>Пользователи могут формировать смысловые блоки, использовать различные типы вопросов, настраивать ветвление сценариев в зависимости от ответов, а также задавать индивидуальный вес и логику расчёта для каждого параметра. При этом весь операционный цикл — от рассылки анкет и контроля сроков до сбора данных и первичной математической интерпретации результатов — выполняется системой автоматически с помощью технологий искусственного интеллекта.</p> <p>В рамках релиза CICADA8 CyberRating также реализован модуль интеллектуального анализа, который решает главную проблему любого аудита — обработку неструктурированных данных. Искусственный интеллект, встроенный в платформу, способен распознавать и анализировать ответы контрагента, данные в свободной форме, оценивая их смысловую полноту. Модуль выполняет семантический анализ загруженных документов и нормативных актов подрядчика — политик парольной защиты, положений о коммерческой тайне, планов аварийного восстановления — и проверяет их на предмет соответствия корпоративным требованиям заказчика. </p> <p>CICADA8 CyberRating мгновенно выявляет логические нестыковки, после чего формирует карту потенциальных рисков и список экспертных рекомендаций. Компании фактически получают продвинутого аудитора, который за секунды обрабатывает объем информации, на анализ которого у специалистов ранее уходили недели ручного труда.</p> <p>«В совокупности автоматизированное анкетирование, ИИ-аудит документов и непрерывный технический мониторинг внешнего периметра формируют комплексную модель безопасности третьих сторон на 360 градусов. Платформа показывает, как контрагент или дочерняя организация защищены технически, как выстроены его внутренние процессы и насколько зрелыми являются его политики и регламенты. Все результаты сводятся в единый интуитивно понятный интерфейс, позволяющий выстроить полностью управляемый процесс взаимодействия с контрагентами непосредственно в платформе», — рассказал Никита Котиков, руководитель продукта CyberRating CICADA8.</p> CICADA8, компания по управлению уязвимостями и цифровыми угрозами в реальном времени, представила масштабное … message