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=234997 Thu, 11 Jun 2026 09:44:30 +0300 <p><em>Стивен Эллиот, вице-президент группы </em><em>IDC</em> <em>по инфраструктуре и операциям, облачным операциям и DevOps, рассказывает в корпоративном блоге, как руководители предприятий могут снизить риски и превратить системы искусственного интеллекта в конкурентное преимущество.</em></p> <p>Эра ИИ-помощников подходит к концу.</p> <p>Чат-боты, помощники, составители резюме — полезны, да, но это разминка. Следующим шагом станет агентный ИИ: системы, которые не просто реагируют на запросы, но и планируют, рассуждают и выполняют работу в ваших системах, рабочих процессах и на ваших данных, с участием человека или без него. Сегодня руководители предприятий ставят агентный ИИ в центр своих бизнес-трансформаций, переосмысливая то, как люди взаимодействуют с рабочими процессами на основе ИИ.</p> <blockquote> <p><em>IDC прогнозирует развертывание к 2029 г. 1,15 млрд. активных агентов, выполняющих 217 млрд. действий в день, что в 40 раз больше показателя 2025 г.</em></p> <p>#IMAGE_234998#</p> </blockquote> <h3>Ставки не теоретические</h3> <p>Бизнес-модели, навыки, экономика, управление, соответствие нормативным требованиям и требования к безопасности быстро меняются, создавая масштабные и быстро развивающиеся риски. Цифры из опроса IDC «State of Enterprise Agent Adoption 2025» это подтверждают:</p> <ul> <li> Более 30% предприятий уже внедрили формальные метрики ценности ИИ.</li> <li> До 20% компаний из списка G1000 могут к 2030 г. столкнуться с юридическими и управленческими последствиями из-за плохо управляемых агентов.</li> <li> 60% компаний из списка G2000 к 2028 г. внедрят формальный жизненный цикл разработки агентов.</li> </ul> <p>Генеральные директора, члены совета директоров и акционеры требуют результатов от ИИ уже сейчас. Ожидание затормозит рост доли рынка, возможностей для роста и инноваций. Первые добившиеся успеха расширят свои преимущества, применяя проверенные знания ИИ в новых сценариях использования. В ИИ-экономике непрерывное обучение обеспечивает скорость и кумулятивные результаты.</p> <h3>Это не апгрейд. Это новая операционная модель</h3> <p>Если «второй пилот» составляет электронное письмо, то агент управляет всем рабочим процессом: сбором данных, принятием решений, эскалацией исключений, замыканием цикла. Автономно. Постоянно. В разных системах. С участием человека или без него. Это требует от руководителей перепроектирования процессов с ИИ в центре, не как дополнительной функцией, а как сердцем каждого рабочего процесса.</p> <p>По данным IDC, к 2027 г. предприятиям потребуются архитектуры, поддерживающие синхронное перемещение данных, приложений, рабочих процессов и агентов. Если ваша текущая система не была разработана для этого, время уже идет.</p> <blockquote> <p><em>Агентные системы создают принципиально иной профиль риска, чем инструменты ИИ, которые большинство предприятий развернули в 2023 и 2024 гг.</em></p> </blockquote> <p>Последствия выходят за рамки архитектуры. Копилоты работали под наблюдением человека — каждый результат проверялся, каждое действие подтверждалось. Агенты работают иначе: они инициируют, объединяют решения и действуют в разных системах в режиме реального времени. Неправильно настроенный агент не просто выдает неправильный ответ; он принимает неверное решение, потенциально в больших масштабах, прежде чем кто-либо это заметит. Именно этот переход от результатов, проверенных человеком, к автономным действиям приводит к полному краху систем управления, созданных для эпохи помощников. Управление, безопасность и координация являются критически важными инвестиционными требованиями, а не второстепенным аспектом для эффективных и результативных результатов ИИ. Управление и безопасность должны быть заложены с самого начала, поскольку риски для бизнеса и карьеры слишком высоки, чтобы рассматривать их как второстепенные. Каждый цифровой работник будет управляться как обычный сотрудник.</p> <p>Руководители, которые осознают это различие на раннем этапе, получат структурное преимущество. Они будут не просто быстрее развертывать системы — они создадут операционные возможности, инфраструктуру аудита и системы доверия, необходимые для безопасного масштабирования. Те, кто рассматривает агентный ИИ как продолжение своей стратегии «второго пилота», столкнутся с растущими затратами на исправление ошибок по мере роста портфелей агентов и расширения пробелов в управлении.</p> <p>Конкурентный разрыв, формирующийся сейчас, — не между компаниями, которые используют ИИ, и теми, которые его не используют. Речь идёт о противостоянии организаций, которые научились дисциплинированно внедрять агентов, и тех, кто всё ещё импровизирует. Скорость без структуры — это уязвимость. Структура без скорости — это неактуальность. Руководители, которые ориентируются в обоих аспектах, устанавливают правила игры.</p> <h3>Семь областей. Одна структура</h3> <p>Предлагаемая IDC структура внедрения ИИ выявляет семь областей, где ранние решения оказывают огромное влияние на последующие этапы. Правильно их примите, и вы нарастите темп:</p> <ul> <li> Бизнес-результаты.</li> <li> Проектирование рабочих процессов.</li> <li> Готовность данных.</li> <li> Архитектура среды выполнения.</li> <li> Управление.</li> <li> Операционная модель.</li> <li> Кадры.</li> </ul> <p>В каждой области выделены ключевые моменты, которые руководители должны учитывать для оценки своей готовности к внедрению и управлению ИИ. После проведения самооценки исследование предоставляет подробный анализ критически важных областей трансформации — разработка ПО, выбор партнёров и инфраструктуры ИИ, а также ИТ-операции. Эти рекомендации служат руководством для обсуждения вашего пути внедрения агентного ИИ.</p> <h3>Ключевые выводы для руководителей</h3> <ul> <li> Рассматривайте агентный ИИ как новую операционную модель, а не как обновление вашей стратегии «второго пилота».</li> <li> Управление и безопасность теперь являются конкурентным преимуществом, а не просто мерами по обеспечению соответствия ИТ-требованиям.</li> <li> Семидоменная структура — это ваша шпаргалка: используйте её, чтобы снизить риски развертывания и извлечь выгоду за счет накопления ценности.</li> <li> Те, кто первыми начнут, установят правила игры. Ожидание — это не нейтральная позиция, а стратегическая уступка.</li> </ul> Стивен Эллиот, вице-президент группы IDC по инфраструктуре и операциям, облачным операциям и DevOps, рассказывает … article https://www.itweek.ru/themes/detail.php?ID=234995 Thu, 11 Jun 2026 09:39:00 +0300 <p>В классической ИТ-архитектуре понятие Disaster Recovery (DR), как правило, является синонимом «запасного плана». Это страховка, которая требует огромных капитальных вложений, но остается пассивной до самого момента аварии. Однако в настоящее время в ключевых отраслях — таких как непрерывное производство, финансовый сектор, государственное управление, электронные госуслуги и здравоохранение — предъявляются повышенные требования к отказоустойчивости бизнес-процессов в режиме 24/7/365.</p> <p>Необходимость повышения экономической эффективности заставляет рынок пересматривать этот классический подход. Сегодня мы наблюдаем тектонический сдвиг: переход от ИТ-инфраструктуры «пассивного ожидания» к распределенным зонам доступности (Availability Zones).</p> <h3>Эволюция стратегий: От «холодного» резерва к «живому» облаку</h3> <p>Для сравнения эффективности подходов рассмотрим три основные модели организации инфраструктуры.</p> <p><strong>1.</strong> <strong>Классический DR (Active-Passive). </strong>Это традиционная модель: основной центр обработки данных (ЦОД А) несет 100% полезной нагрузки, а резервный (ЦОД B) находится в режиме ожидания. Данные между ними реплицируются синхронно или асинхронно. Преимущество такого подхода заключается в относительно простой настройке. В то же время схеме присущ серьезный недостаток: оборудование резервного ЦОДа простаивает, но при этом требует постоянного технического обслуживания и лицензирования программного обеспечения. Кроме того, Active-Passive несет в себе скрытые риски — в частности, риск сбоя при переключении на резервную площадку из-за рассинхронизации настроек системного ПО или человеческого фактора.</p> <p><strong>2. Две «площадки» (Active-Active). </strong>Инфраструктура распределена между двумя площадками, каждая из которых активно обрабатывает транзакции. Ключевые преимущества этой модели — 100%-ное использование доступных ресурсов и отсутствие рисков, связанных с ручным или автоматическим переключением нагрузок: при аварии «выживший» ЦОД просто продолжает работу.</p> <p>Однако подход имеет ряд серьезных ограничений. Первая проблема — сугубо технологическая: эффект «расщепления мозга» (split-brain). В случае разрыва связности между ЦОДами возникает риск того, что сервисы на обеих площадках начнут считать себя изолированными мастерами, что неизбежно ведет к консистентным сбоям и повреждению данных. Для предотвращения split-brain требуется третья независимая сторона — арбитр (Quorum Witness). Вторая сложность носит экономический характер: при отказе одного из дата-центров вся нагрузка локализуется на оставшейся площадке. Чтобы минимизировать дефицит производительности и пропускной способности в момент аварии, компании приходится постоянно держать до 50% вычислительных ресурсов в горячем резерве на каждом узле.</p> <p><strong>3. </strong><strong>Три зоны доступности — три «площадки» (Multi-AZ/3-site). </strong>Это «золотой стандарт» современной ИТ-отрасли. Инфраструктура распределяется по трем независимым локациям с минимальными задержками (latency) между ними. Схема обладает рядом неоспоримых преимуществ.</p> <p>Первое — технологическое: наличие кворума по умолчанию. Система всегда имеет математическое «большинство». Если одна из площадок выходит из строя, две оставшиеся подтверждают целостность и непротиворечивость данных, продолжая работу без риска рассинхронизации. Второе преимущество — нулевое окно обслуживания. Вы можете полностью остановить одну из зон для планового обновления программного или аппаратного обеспечения, пока система сохраняет высокую доступность (High Availability) за счет двух оставшихся площадок. Наконец, третье преимущество — экономическое, которое часто упускают из виду. Чтобы минимизировать дефицит производительности при отказе одного плеча, в модели Multi-AZ достаточно иметь всего порядка <nobr>8-10%</nobr> избыточных мощностей на каждой из площадок. Подобный резерв, чаще всего, у компаний уже заложен под пиковые нагрузки или под будущий рост бизнеса.</p> <h3>Почему стоит выбрать концепцию трех зон доступности?</h3> <ol> <li><strong> Математическая гарантия целостности данных. </strong>В бизнес-транзакциях — будь то бухгалтерская проводка или межбанковский перевод — «потерять» или «удвоить» запись абсолютно недопустимо. Трехзонная архитектура на базе алгоритмов распределенного консенсуса (таких как Raft или Paxos) гарантирует, что любая транзакция будет подтверждена как минимум двумя вычислительными узлами, физически расположенными в разных дата-центрах.</li> <li><strong> Соответствие жестким требованиям КИИ и регуляторов. </strong>Для объектов критической информационной инфраструктуры (КИИ) требование устойчивости к региональным и техногенным катастрофам становится обязательным. Развертывание в трех зонах доступности позволяет разнести оборудование на безопасное географическое расстояние, полностью сохраняя непрерывную репликацию данных и гарантируя их постоянную доступность.</li> <li><strong> Экономика масштабируемых систем. </strong>Современные программно-определяемые технологии (SDS/SDN) позволяют строить распределенную отказоустойчивую сеть на базе стандартного серверного оборудования (Commodity Hardware). Отказ от покупки дорогостоящих проприетарных СХД для организации репликации делает трехзонную модель Active-Active сопоставимой по стоимости владения (TCO) с классическим пассивным DR, но при этом в разы более эффективной.</li> </ol> <h3>Резюме</h3> <p>Переход на архитектуру трех зон доступности (Multi-AZ) — это стратегический сдвиг от <em>реактивной</em> модели управления (когда инфраструктуру приходится восстанавливать после аварии) к <em>превентивной</em> (когда система физически не замечает отказа отдельных узлов или площадок). По сути, это полная смена парадигмы управления рисками. Для предприятий и организаций такой подход означает гарантированное сохранение лояльности клиентов, минимизацию рисков простоя критических технологических циклов и прямую экономию на потенциальных штрафах регуляторов. Сегодня, в 2026 году, современное предприятие уже не может позволить себе тратить время на то, чтобы «восстанавливаться» после сбоя. Оно должно этот сбой просто игнорировать, непрерывно продолжая работу в распределенной среде.</p> <p>#IMAGE_234996#</p> В классической ИТ-архитектуре понятие Disaster Recovery (DR), как правило, является синонимом «запасного плана». Это … article Дмитрий Гаврилов, основатель ООО “Открытые Технологии Виртуализации” https://www.itweek.ru/themes/detail.php?ID=234993 Thu, 11 Jun 2026 09:32:41 +0300 <p>За последние два года искусственный интеллект превратился из экспериментальной технологии в обязательный пункт корпоративной стратегии. Практически каждая крупная компания уже запустила пилот, тестирует генеративный ИИ или заявляет о намерении автоматизировать часть бизнес-процессов. На рынке сформировалось ощущение, что внедрение ИИ — вопрос конкурентоспособности и выживания.</p> <p>Однако за громкими анонсами скрывается менее привлекательная реальность. Большинство проектов так и не доходят до промышленной эксплуатации. По данным ряда международных исследований, подавляющая часть инициатив в области генеративного ИИ не демонстрирует ожидаемого экономического эффекта и остается на уровне экспериментов.</p> <p>Парадокс заключается в том, что проблема редко связана с самими технологиями.</p> <h3>Бизнес пытается автоматизировать не процессы, а надежды</h3> <p>Каждый новый технологический цикл рождает собственный набор иллюзий. В эпоху CRM считалось, что достаточно внедрить систему управления клиентами, чтобы автоматически выросли продажи. Позже аналогичные ожидания связывали с большими данными, RPA и цифровой трансформацией.</p> <p>Сегодня такая же судьба постигла генеративный ИИ.</p> <p>Во многих компаниях решение о внедрении принимается не потому, что существует конкретная бизнес-проблема, а потому что технология находится на пике внимания. В результате организации начинают создавать универсальных ИИ-агентов, не понимая, какую именно задачу те должны решать и каким образом будет измеряться результат.</p> <p>На практике искусственный интеллект часто становится новым интерфейсом для старых неэффективных процессов. Если компания не понимает собственную клиентскую воронку, не знает структуру обращений и не может определить стоимость одного контакта, то ИИ не устранит эти проблемы. Он лишь ускорит их масштабирование.</p> <p>Автоматизация хаоса остается хаосом.</p> <h3>Самый дорогой риск — человеческий</h3> <p>Существует еще одна причина, о которой редко говорят публично.</p> <p>Руководители контакт-центров и клиентских служб оцениваются не по количеству внедренных инноваций, а по отсутствию ошибок. Любое решение, способное создать дополнительный риск для клиентского опыта, воспринимается крайне осторожно.</p> <p>Когда ошибается оператор, организация воспринимает это как рабочий процесс. Когда ошибается ИИ, инцидент воспринимается как системная проблема.</p> <p>В результате компании предъявляют к ИИ более жесткие требования, чем к людям.</p> <p>Представим контакт-центр, где сотрудники допускают ошибки в <nobr>10-15%</nobr> нестандартных обращений. Это считается допустимым уровнем. Но если ИИ-агент ошибается в одном разговоре из ста пятидесяти, обсуждение быстро смещается от экономического эффекта к вопросу о том, можно ли вообще использовать такую технологию.</p> <p>Подобная логика понятна с точки зрения личной ответственности менеджеров, но часто приводит к отказу от проектов, которые уже доказали свою экономическую эффективность.</p> <h3>Почему большинство компаний оценивают не те показатели</h3> <p>Еще одна распространенная ошибка — выбор неправильных метрик.</p> <p>Во многих проектах успех ИИ измеряется временем ответа, количеством обработанных запросов или стоимостью токена. Эти показатели удобны для разработчиков, но практически ничего не говорят бизнесу.</p> <p>Клиентский сервис существует не для того, чтобы быстро отвечать на вопросы. Его задача — решать проблемы клиентов.</p> <p>Поэтому для оценки ИИ-агентов гораздо важнее показатели уровня решенных обращений без участия оператора, точность ответов, количество повторных контактов и стоимость обработки одного запроса.</p> <p>Когда компания начинает смотреть на эти метрики, выясняется, что эффективность ИИ определяется не качеством модели как таковой, а глубиной интеграции в реальные бизнес-процессы.</p> <h3>Где экономика ИИ действительно работает</h3> <p>При этом говорить о том, что генеративный ИИ не окупается, было бы ошибкой.</p> <p>Существуют сегменты, где экономический эффект уже подтверждается практикой. В первую очередь это клиентский сервис крупных B2C-компаний, контакт-центры, страхование, телеком, банковский сектор, девелопмент и подписочные сервисы.</p> <p>Общая черта таких проектов — высокая стоимость человеческого труда и большой объем однотипных коммуникаций.</p> <p>Например, в девелопменте ИИ может работать со «спящей» клиентской базой, которую компания физически не способна регулярно обрабатывать силами операторов. В страховании — автоматизировать первую линию поддержки. В фитнес-индустрии — заниматься пролонгацией абонементов и реактивацией клиентов.</p> <p>Во всех этих сценариях ценность создается не за счет замены людей, а за счет возможности выполнять работу, которая ранее вообще не выполнялась из-за ограниченности ресурсов.</p> <p>Именно поэтому многие успешные проекты связаны не с сокращением штата, а с масштабированием бизнеса без пропорционального роста расходов.</p> <h3>Главный вопрос — не «какая модель», а «какой процесс»</h3> <p>Рынок искусственного интеллекта постепенно проходит классический цикл взросления.</p> <p>Фокус смещается с обсуждения моделей и параметров на вопросы экономики и операционной эффективности. Компании начинают понимать, что ценность создается не в момент запуска пилота, а в момент интеграции технологии в ежедневную работу бизнеса.</p> <p>Для этого необходимы три вещи.</p> <p>Во-первых, внедрение должно начинаться с <em>конкретной бизнес-задачи</em>, а не с желания использовать модную технологию.</p> <p>Во-вторых, <em>проект должен иметь владельца</em> внутри компании, отвечающего за бизнес-результат, а не только за техническую реализацию.</p> <p>В-третьих, ИИ необходимо <em>рассматривать как постоянно развивающуюся систему</em>, а не как программный продукт, который можно внедрить один раз и забыть о нем.</p> <h3>От хайпа к эффективности</h3> <p>Сегодня рынок находится в точке, когда первая волна энтузиазма начинает уступать место прагматизму.</p> <p>Компании больше не спрашивают, нужен ли им искусственный интеллект. Они задают гораздо более важный вопрос: способен ли он приносить деньги.</p> <p>Именно этот вопрос в ближайшие годы разделит рынок на две группы. Одни организации продолжат собирать коллекцию пилотных проектов и презентаций для совета директоров. Другие научатся превращать ИИ в инструмент повышения выручки и снижения издержек.</p> <p>Разница между ними будет определяться не качеством используемой модели и не объемом инвестиций.</p> <p>Разница будет заключаться в способности связать технологию с реальными бизнес-процессами и измеримым экономическим результатом.</p> <p>#IMAGE_234994#</p> За последние два года искусственный интеллект превратился из экспериментальной технологии в обязательный пункт … article Андрей Зименков, фаундер и CEO targetai https://www.itweek.ru/themes/detail.php?ID=234992 Wed, 10 Jun 2026 17:54:53 +0300 <p>Аналитическое агентство Apple Hills Digital совместно с Selectel, Cloud.ru и VK Tech презентуют результаты исследования трендов облачного потребления в корпоративном секторе России. Согласно результатам опроса, 65% компаний увеличили инвестиции в IT в 2026 году, а внедрение искусственного интеллекта стало главным направлением развития.</p> <p>По результатам исследования, 65% компаний сообщили об увеличении инвестиций в IT в 2026 году, из которых 48% увеличили бюджеты в пределах 15%, а 17% компаний — более чем на 15%. При этом 24% компаний сохраняют бюджет на уровне 2025 года и только 12% планируют его сокращать.</p> <p>Среди драйверов роста инвестиций в IT компании отмечают развитие бизнеса (39%), рост объема данных (33%), модернизацию инфраструктуры (32%), а также рост требований в сфере информационной безопасности (30%).</p> <p>Среди направлений инвестиций компании чаще всего отмечают развитие искусственного интеллекта (35%), обеспечение кибербезопасности (34%) и использование облачной IT-инфраструктуры (23%).</p> <p>При этом почти половина российских компаний (46%) использует облачную инфраструктуру для задач искусственного интеллекта, тестирует такие решения или планирует их внедрение в течение ближайшего года. Одновременно с этим 11% компаний предпочитают развертывать ИИ локально на собственных мощностях. Еще 7% используют искусственный интеллект по модели SaaS (Software-as-a-Service). </p> <p>Главными причинами использования облака для задач искусственного интеллекта являются доступ к готовым ИИ-моделям и сервисам (36%) и возможность ускорить запуск экспериментов (32%). Также компании отмечают преимущества облачной инфраструктуры в обеспечении безопасности ИИ-проектов (27%), масштабировании решений (23%) и снижении стоимости разработки (20%).</p> <p>Александр Тугов, директор AI-вертикали Selectel, отметил: «Сегодня для большинства компаний развертывать ИИ в облачной инфраструктуре выгоднее, чем строить собственный контур. Рынок развивается настолько быстро, что GPU морально устаревают за два-три года, а потребности бизнеса постоянно меняются. Облако позволяет быстро проверить гипотезу, масштабировать успешные кейсы и гибко управлять ресурсами без крупных капитальных затрат и риска ошибиться с выбором оборудования.</p> <p>При этом локальная инфраструктура по-прежнему остается востребованной в отраслях с повышенными требованиями к безопасности и регуляторике. Для таких сценариев Selectel предоставляет выделенные серверы с GPU, включая варианты размещения оборудования на площадке заказчика, что позволяет внедрять искусственный интеллект без выноса данных за пределы собственного контура».</p> Аналитическое агентство Apple Hills Digital совместно с Selectel, Cloud.ru и VK Tech презентуют результаты … message https://www.itweek.ru/themes/detail.php?ID=234991 Wed, 10 Jun 2026 17:53:47 +0300 <p>Эксперты компании «Информзащита» зафиксировали рост обращений, связанных с проверкой npm-зависимостей и расследованием подозрительной активности в цепочках поставки ПО. В январе-мае 2026 года их количество выросло на 42% по сравнению с аналогичным периодом 2025 года. Изменился и характер запросов: компании стали чаще обращаться не после подтвержденной компрометации, а на этапе раннего анализа риска, когда вредоносная версия уже появилась в экосистеме, но еще не успела попасть в продуктивный контур. По данным анализа «Информзащиты», доля таких превентивных запросов выросла с 31% до 54%, а число случаев, где потенциально опасный пакет удавалось изолировать до использования в production-сборке, увеличилось на 38%.</p> <p>Такая динамика показывает не только рост активности злоумышленников, но и более зрелое отношение бизнеса к open source-рискам. npm остается одной из самых удобных для атакующих экосистем из-за большого числа транзитивных зависимостей, автоматического выполнения lifecycle-скриптов и высокой скорости распространения новых версий. Команда разработки может не устанавливать вредоносный пакет напрямую: он попадает в проект через служебную библиотеку, клиент API, компонент сборки или optional-зависимость. Внешне процесс выглядит штатно, поэтому классические проверки на уровне периметра часто не дают нужного контекста. Защита начинает работать эффективнее там, где контроль зависимостей встроен в пайплайн, а не проводится вручную уже после инцидента.</p> <p>В 2026 году атаки на npm все чаще нацелены не на конечное приложение, а на среду разработки. Вредоносные пакеты ищут npm-токены, GitHub PAT, SSH-ключи, переменные окружения, cloud credentials, секреты GitHub Actions, GitLab CI, CircleCI, Vercel, Netlify и других платформ. По оценке «Информзащиты», в 61% проанализированных случаев подозрительный пакет пытался получить доступ сразу к нескольким классам секретов. В 34% случаев код содержал признаки самораспространения через публикацию новых версий пакетов от имени скомпрометированного мейнтейнера. В 22% случаев вредоносная активность маскировалась под телеметрию, загрузку runtime-компонентов или стандартные операции сборочного пайплайна. При наличии мониторинга поведения в CI/CD такие сценарии можно выявлять раньше, чем они превращаются в масштабную компрометацию.</p> <p>Ключевая причина роста таких атак — разрыв между скоростью разработки и глубиной контроля supply chain. Во многих компаниях SBOM формируется ближе к релизу, хотя вредоносный пакет может выполниться еще в тестовой или сборочной среде. Lock-файлы используются не во всех проектах, а npm install по-прежнему встречается в пайплайнах там, где должен применяться npm ci. CI/CD-раннеры нередко имеют избыточный доступ к секретам, а права на сборку, публикацию и работу с облаками объединены в одном контуре. Отдельный риск связан с доверием к формальным признакам легитимности. Подпись пакета и корректный provenance помогают подтвердить происхождение артефакта, но не отвечают на главный вопрос: что делает код при установке, сборке и запуске в CI/CD. Поэтому эти механизмы должны дополнять анализ lifecycle-скриптов, изменений в зависимостях, сетевой активности и доступа к секретам, а не заменять его. Компании, которые совмещают анализ пакетов, контроль секретов и мониторинг поведения сборочной инфраструктуры, сокращают окно риска без остановки разработки.</p> <p>В отраслевом разрезе наиболее заметная доля обращений пришлась на технологические компании и разработчиков SaaS-решений — 26%. Финансовый сектор занял 19%, в основном из-за развитых внутренних frontend-платформ, SDK и автоматизированных пайплайнов поставки. На ритейл и e-commerce пришлось 16% случаев: риск повышают распределенные веб-команды, подрядчики и большое число клиентских интеграций. Промышленность и энергетика составили 14%, где npm-зависимости чаще встречаются во внутренних порталах, системах мониторинга и сервисах аналитики. Телеком занял 11%, логистика и транспорт — 8%, медиа и образовательные платформы — 6%. Такая картина показывает, что npm-риски перестали быть вопросом только для производителей программного обеспечения. Под удар попадает любой бизнес, где разработка связана с облаками, CI/CD, внешними пакетами и автоматизированной доставкой кода.</p> <p>«Главная сложность npm-атак в том, что они редко выглядят как классическое заражение. Разработчик запускает обычную установку зависимости, CI получает привычный набор команд, пакет может быть подписан и опубликован из легитимного аккаунта. Проблема становится заметной позже, когда токен уже использован для доступа к репозиторию или публикации следующей вредоносной версии. Во второй половине 2026 года мы ожидаем больше комбинированных сценариев: компрометацию мейнтейнеров, отравление CI/CD-кеша и злоупотребление доверенными publisher-механизмами. Если компания проверяет только имя пакета и наличие подписи, она увидит атаку слишком поздно», — прокомментировал Анатолий Песковский, директор Департамента наступательной безопасности компании «Информзащита». </p> <p>Для снижения риска компаниям необходимо выстроить управляемую модель доверия к npm-зависимостям и сборочной инфраструктуре. Новые версии пакетов стоит помещать в карантин на <nobr>24-72</nobr> часа и пропускать в продуктивные сборки только после проверки изменений в package.json, lifecycle-скриптов, резких скачков размера файлов и появления новых внешних соединений. В CI/CD важно ограничить доступ раннеров к секретам по принципу минимальных привилегий, разделить права на сборку и публикацию, использовать lock-файлы и npm ci вместо npm install, отключать install-скрипты там, где это допустимо, контролировать egress-трафик и направлять загрузку зависимостей через приватный registry или прокси с политиками блокировки. После любого подозрения на компрометацию зависимости требуется ротация npm-токенов, GitHub PAT, SSH-ключей и облачных секретов. Такой подход не останавливает разработку, а переводит open source-компоненты в контролируемый процесс, где риск можно обнаружить до влияния на бизнес-системы.</p> Эксперты компании «Информзащита» зафиксировали рост обращений, связанных с проверкой npm-зависимостей и расследованием … message https://www.itweek.ru/themes/detail.php?ID=234989 Wed, 10 Jun 2026 15:04:55 +0300 <p>Подписав соглашение о стратегическом партнерстве, «Группа Астра» и компания «Аладдин» объявили о подготовке к выпуску на рынок первого совместно разработанного продукта — Astra Server Core.</p> <p>Ключевые свойства нового продукта, как пояснили на его презентации директор серверного ПО «Группы Астра» Алексей Фоменко и генеральный директор компании «Аладдин» Сергей Груздев, заключаются в возможности закрыть актуальную потребность заказчиков в доверенной самодостаточной корпоративной инфраструктурной ИТ-платформе, способной заместить комплекс решений ОС Windows + AD + SCCM + CA, который до сих пор доминирует во многих российских компаниях.</p> <p>Как полагают разработчики Astra Server Core, новый продукт позволяет сформировать новый стандарт построения зрелой, доверенной, безопасной и надежной корпоративной ИТ-инфраструктуры. Продукт включает в себя серверную ОС Astra Linux Server, службу каталога корпоративного класса ALD Pro, менеджер конфигураций Astra Configuration Manager и корпоративный центр сертификации Aladdin Enterprise CA. Как заявляют «Аладдин» и «Группа Астра», все компоненты соответствуют актуальной нормативной баз; в первую очередь они обращают внимание на соответствие <nobr>117-му</nobr> приказу ФСТЭК России.</p> <p>Создатели Astra Server Core объявили, что все компоненты решения доступны для пользователей прямо «из коробки», что избавляет их от необходимости самостоятельно собирать ядро своих корпоративных ИТ-инфраструктур из решений разных вендоров и тестировать их на совместимость. Они также обещают, что техподдержка пользователей Astra Server Core будет реализована партнерами в режиме единого окна.</p> <p>Рассказывая о нынешних возможностях Astra Server Core и планах развития партнерства, Сергей Груздев пояснил, что сразу после выхода на рынок продукт будет на базе перечисленных выше компонентов обеспечивать выдачу машинных и программных сертификатов для сервисов. В дальнейшем будет создана платформа, ориентированная в своем функциональном наполнении в большей мере на клиентскую часть инфраструктуры: на доверенную загрузку, прозрачное шифрование данных, двухфакторную и строгую аутентификации... Фактически, по словам Сергея Груздева, партнеры намерены в недалеком будущем реализовать «из коробки» соответствие регуляторным требованиям.</p> Подписав соглашение о стратегическом партнерстве, «Группа Астра» и компания «Аладдин» объявили о подготовке … message Валерий Васильев https://www.itweek.ru/themes/detail.php?ID=234985 Wed, 10 Jun 2026 13:14:25 +0300 <p>Рассмотрим, почему поддержка корпоративных систем больше не может ограничиваться «закрытием заявок» и как выбрать подрядчика, который отвечает за стабильность бизнес-процессов, а не только за отдельные ИТ-компоненты.</p> <p>Российский бизнес все чаще сталкивается с кибератаками, сбоями и дефицитом ИТ-компетенций. Для компаний, в которых ERP-система, СУБД, серверы и интеграции поддерживают закупки, производство, финансы и отчетность, любой cбой превращается в операционные и финансовые потери.</p> <p>Высоки риски для предприятий из ключевых отраслей: уязвимость в приложении, СУБД, операционной системе или сетевой инфраструктуре может привести к потере контроля над бизнес-приложениями, уничтожению данных, остановке процессов и прямым убыткам. Поддержка ИТ-ландшафта — один из элементов устойчивости бизнеса.</p> <h3>Безопасность систем — следствие зрелости бизнеса</h3> <p>Подход к защите данных напрямую зависит от зрелости ИТ-контура и управленческой зрелости бизнеса. Рост последней делает более понятными ИТ-стратегию, критичные процессы, целевую архитектуру, зоны ответственности, требования к доступности и восстановлению систем.</p> <p>Если ИТ-стратегии нет, а информационная безопасность финансируется по остаточному принципу, выбор между собственной командой и внешним подрядчиком не решит проблему. Риск потери данных и нарушения целостности систем снижается, когда есть регламенты, контроль изменений, резервное копирование, понятные целевые показатели восстановления (RTO/RPO) и регулярная проверка готовности к инцидентам.</p> <p>Меры безопасности часто внедряются уже после сбоя или атаки. Компаниям, в которых ИТ не является основным бизнесом, сложно постоянно держать внутри всю экспертизу: отслеживать новые угрозы, проверять гипотезы защиты, обновлять регламенты и обучать команду. В этой ситуации внешнее сопровождение может дать эффект, если оно встроено в управление рисками.</p> <h3>Что должен обеспечивать внешний поставщик?</h3> <p>Ценность внешнего подрядчика поддержки заключается в том, чтобы заранее выстроить процессы, которые снижают вероятность критичных событий и ускоряют восстановление.</p> <p>Первая задача провайдера — собрать компетенции и ресурсы, которые обеспечивают непрерывность работы всего ИТ-ландшафта: от бизнес-приложений до инфраструктуры, на которой они работают.</p> <p>Для этого аутсорсер отслеживает технологические тренды и реальные инциденты, обучает специалистов, формирует регламенты, выстраивает процессы поддержки, развивает мониторинг, базы знаний, инструменты управления изменениями и техническую инфраструктуру сопровождения. Для многих компаний реального сектора поддерживать такой набор компетенций внутри экономически сложно.</p> <p>Клиент в этой модели получает людей «на линию», накопленные практики, экспертизу и готовые сценарии решения типовых проблем. По нашему опыту, в большинстве случаев проблему можно решать по уже апробированному сценарию, а уровень сервиса должен быть закреплен соглашением об уровне обслуживания (SLA) и финансовой ответственностью поставщика.</p> <h3>Комплексный подход как залог эффективности поддержки</h3> <p>Оптимальная модель — целостное сопровождение, когда один провайдер отвечает и за бизнес-приложения, и за платформенные компоненты: серверы, операционные системы, СУБД, интеграции, мониторинг и резервное копирование. Защита исключительно прикладного слоя недостаточна: сбой инфраструктуры неизбежно приведет к остановке бизнес-системы.</p> <p>На реальных инцидентах видно, что приложение, база данных, серверная инфраструктура и процессы эксплуатации тесно связаны. Поэтому устойчивость ИТ-ландшафта лучше обеспечивать через единый подход, единое окно взаимодействия и понятную модель ответственности. Это снижает риск «мертвых зон» на стыке ERP-системы и инфраструктурных компонентов.</p> <p>С этой целью сопровождение целесообразно строить вокруг трех направлений: техническое администрирование; функциональная поддержка и развитие; поддержка пользователей и сервисов данных.</p> <p>Техническое администрирование охватывает приложения ERP-системы, СУБД, операционную среду и инфраструктурные компоненты. Его цель — стабильность, производительность, информационная безопасность и управляемая стоимость владения.</p> <p>Ключевые принципы технического администрирования:</p> <ul> <li> актуализируемая база знаний об угрозах, инцидентах и методах их предотвращения;</li> <li> проактивный мониторинг доступности, производительности и потенциальных сбоев;</li> <li> документирование работ и контроль жизненного цикла изменений;</li> <li> перенос в продуктив только согласованных и протестированных изменений;</li> <li> разграничение прав доступа и регулярный пересмотр ролей;</li> <li> экспертный совет для диагностики повторяющихся и критичных проблем;</li> <li> подключение специалистов по любому элементу технологического стека — от ERP-системы до СУБД и инфраструктуры;</li> <li> отсутствие мертвых зон на стыке технологий и единая ответственность за результат;</li> <li> закрепление уровня сервиса в SLA, включая приоритеты, время реакции, эскалацию и отчетность;</li> <li> регулярная проверка резервного копирования и сценариев восстановления для критичных систем.</li> </ul> <p>По нашим данным, применение этих принципов в среднем по проектам позволяет сократить количество нештатных ситуаций до 70%, время их устранения — до 60%, а затраты на обслуживание — до 30%. Эти показатели зависят от исходной зрелости ИТ-контура и состава обслуживаемых систем.</p> <p>Практический набор услуг включает настройку, администрирование и восстановление работоспособности поддерживаемого ПО, предоставление новых версий, консультации по документации, настройку общесистемного ПО и СУБД под требования бизнес-приложений. Сопровождение должны вести специалисты с подтвержденной экспертизой по технологическим вопросам, а при необходимости — профильные инженеры по смежным компонентам.</p> <p>SLA важно строить как управленческий инструмент. Критичные процессы и приложения должны иметь более высокий приоритет, понятные сроки реакции и восстановления, а менее критичные — экономически обоснованный уровень сервиса. Такой подход помогает одновременно защищать бизнес и контролировать бюджет.</p> <p>Функциональная поддержка и развитие отвечают за то, чтобы корпоративная система соответствовала бизнес-процессам. Подрядчик должен контролировать и документировать этапы разработки, целостно проектировать изменения, проводить нагрузочное тестирование и опираться на рекомендации производителей ПО.</p> <p>Команда поддержки должна сочетать техническую экспертизу и понимание предметной области. Консультанты выступают бизнес-аналитиками: помогают уточнять требования, оценивать влияние изменений и предлагать решения, которые улучшают работу пользователей.</p> <p>По нашему опыту, такой подход может повышать производительность пользователей до 30%, сокращать время реализации изменений до 80% и снижать затраты на обслуживание ИТ-систем и компонентов до 60%. Отдельный эффект возникает за счет того, что компании не нужно держать в резерве полный набор редких и дорогостоящих компетенций.</p> <p>Поддержка пользователей и сервисов данных обеспечивает ежедневную работу сотрудников с корпоративными системами, качеством информации, отчетностью и смежными сервисами. Важны понятное единое окно, гарантированное время реакции, контроль жизненного цикла обращений, быстрая эскалация и фокус на решении бизнес-проблемы пользователя.</p> <p>С точки зрения бюджета для ряда компаний эффективна модель фиксированной цены — особенно когда периметр работ, уровень обслуживания (SLA), метрики качества и порядок изменения объема услуг описаны заранее. В такой схеме провайдер заинтересован в снижении количества инцидентов, длительности простоев и повторяемости типовых проблем.</p> <p>Еще один критерий зрелого подрядчика — способность масштабировать и перенастраивать сервис под изменения бизнеса. Провайдер берет на себя подбор, обучение, замену и перераспределение специалистов, а клиент получает более гибкую модель управления ресурсами без необходимости постоянно держать избыточный штат внутри.</p> <p>По нашему опыту, при внедрении такой модели удовлетворенность пользователей может повыситься до 30%, время ответа на обращения — снизиться до 50%, а количество обращений — сократиться до 30%. Как и в случае с другими метриками, эффект зависит от стартового состояния процессов и качества внедрения.</p> <h3>Чек-лист выбора подрядчика</h3> <p>Перед передачей сопровождения на аутсорсинг стоит проверить не только стоимость услуг, но и управляемость будущего сервиса. Минимальный чек-лист может выглядеть так:</p> <ul> <li> Есть ли у подрядчика единая ответственность за приложения, СУБД, инфраструктуру и интеграции?</li> <li> Кто является единым окном и сервис-менеджером со стороны поставщика?</li> <li> Как в SLA описаны приоритеты, время реакции, время восстановления, эскалация и отчетность?</li> <li> Определены ли целевые показатели восстановления (RTO/RPO) для критичных систем и проверяются ли эти сценарии?</li> <li> Как устроены мониторинг, управление изменениями, разграничение доступов и база знаний?</li> <li> Какие метрики поставщик регулярно показывает бизнесу: количество инцидентов, среднее время восстановления (MTTR), повторяемость проблем, удовлетворенность пользователей, динамика затрат?</li> <li> Есть ли у команды подтвержденная экспертиза по ERP-системе и смежным технологическим компонентам?</li> </ul> <h3>Практические шаги к внешнему сопровождению</h3> <p>Переход на поддержку силами внешнего подрядчика редко бывает одномоментным. Бывают ситуации, когда ИТ-ландшафт нужно взять в сопровождение немедленно — например, во время активного инцидента, но в штатном сценарии поспешность повышает риски.</p> <p>Переход занимает несколько недель или месяцев: срок зависит от масштаба компании, количества систем, уровня документации, интеграций, доступности данных и готовности внутренней команды передать знания. Важно дать подрядчику возможность разобраться в процессах и архитектуре.</p> <p>Базовая стратегия — поэтапная передача ИТ-решений на сопровождение. Сначала провайдер изучает процессы, системы, интеграции и инфраструктурные компоненты, затем встраивает сервис в процессы клиента и готовит дорожную карту. В ней должны быть описаны целевая модель поддержки, зоны ответственности, необходимые изменения, требования к ПО и оборудованию, а также план стабилизации.</p> <p>Затем начинается этап стабилизации: команда усиливается экспертами, накапливается база знаний, уточняются регламенты, выявляются критичные проблемы и устраняются повторяющиеся причины сбоев. На этапе штатного сервиса компания получает поддержку с согласованным объемом и качеством, регулярную отчетность, оценку удовлетворенности и управление отклонениями.</p> <p>Такой подход особенно важен при восстановлении после кибератак и крупных сбоев. Действия компании только собственными силами и без заранее отработанных регламентов могут занимать от недели до месяца. В это время часть процессов выполняется вручную, растет риск ошибок и задержек. При внешнем сопровождении с проработанными регламентами, резервным копированием и проверенными сценариями восстановления потери можно существенно снизить. Например, допустимый объем потери данных может измеряться минутами, а не неделями.</p> <p>Квалифицированный подрядчик работает на долгосрочную перспективу: планирует обновления, контролирует работоспособность приложений и инфраструктуры, поддерживает средства защиты, развивает базу знаний и регулярно пересматривает SLA под задачи бизнеса. Главная «банальная истина» проста: устойчивость ERP и корпоративной инфраструктуры появляется не в момент аварии, а задолго до нее — через системное сопровождение, понятную ответственность и проверенные регламенты.</p> <p>#IMAGE_234988#</p> Рассмотрим, почему поддержка корпоративных систем больше не может ограничиваться «закрытием заявок» и как выбрать … article Максим Гришин, начальник отдела “Лаборатория сервисов” IBS https://www.itweek.ru/themes/detail.php?ID=234984 Wed, 10 Jun 2026 11:03:10 +0300 <p>Компания «Спикател» совместно с партнерами провела исследование защищенности API в российском финансовом секторе. Данные получены на основе мониторинга, опросов руководителей ИБ-подразделений и анализа инцидентов. Опрос охватывал период последних 12 месяцев — с июня 2025 по май 2026 включительно.</p> <p>По данным опроса, 98% финансовых организаций зафиксировали как минимум один инцидент, связанный с безопасностью API, за последние 12 месяцев. Это соответствует международной статистике — по данным Akamai, аналогичный показатель в мире составляет 96%. Под инцидентами безопасности мы понимаем случаи, когда злоумышленники использовали API (программный интерфейс) для атаки на инфраструктуру финансовой организации: веб-атаки, нацеленные на конечные точки API, проникновение программ-вымогателей через API эксплуатация «неинвентаризованных» API, «тихие» атаки на бизнес-логику, атаки через незащищенные тестовые контуры мобильных банков.</p> <p>«Глобальная цифра в 96% выглядит устрашающе, но российская специфика диктует почти стопроцентную гарантию инцидента. Ключевой фактор — скорость. В стремлении быстрее вывести на рынок отечественные аналоги ушедших вендоров, безопасность API на этапе разработки зачастую приносится в жертву функциональности», — прокомментировал ведущий аналитик центра мониторинга киберугроз «Спикатела» Алексей Козлов. </p> <p>На финансовый сектор пришлось 85% всех веб-атак на российские организации и 90% атак, направленных на конечные точки API. Вероятно, это связано с тем, что в РФ ускоренными темпами формируется экосистема открытых API (в рамках инициатив ЦБ РФ по Open Banking), и злоумышленники активно изучают уязвимости новых, зачастую «сырых», микросервисных архитектур.</p> <p>За последние 12 месяцев 85% опрошенных финансовых организаций столкнулись с атаками программ-вымогателей и попытками шифрования данных. Также зафиксирован рост векторов проникновения через API мобильных приложений и партнерских интеграций.</p> <p>Злоумышленники все чаще используют API как точку входа в инфраструктуру, минуя классические периметры защиты. Фиксировались случаи, когда вымогатели проникали через незащищенные тестовые контуры мобильных банков.</p> <p>При этом уровень внедрения передовых средств защиты (WAF нового поколения, API Security Gateways) в российском финтехе оценивается лишь в <nobr>35–40%.</nobr> Многие организации до сих пор полагаются на устаревшие модели безопасности периметра, не справляясь с «тихими» атаками логического уровня.</p> <p>«Спикател» прогнозирует рост числа инцидентов, связанных с эксплуатацией неинвентаризованных API, на 40% к концу 2026 года. Факторы роста: расширение числа интеграций по модели Open Banking и увеличение количества публикуемых API.</p> Компания «Спикател» совместно с партнерами провела исследование защищенности API в российском финансовом секторе … message https://www.itweek.ru/themes/detail.php?ID=234983 Wed, 10 Jun 2026 09:23:58 +0300 <p><em><nobr>2026-й</nobr> уже близок к середине, но впереди нас ждет еще много интересного — и, к счастью, не все это — чепуха про искусственный интеллект для сетей. Что точно не будет чепухой, так это продолжающиеся рост и внедрение сетевых платформ, пишет в корпоративном блоге Андре Кинднесс, главный аналитик </em><em>Forrester</em><em>.</em></p> <p>Эта идея может показаться запоздалой по сравнению с рынком безопасности (и да, меня это раздражает как сетевого аналитика), но производители решений в области безопасности — особенно в сфере SASE — уже показали, на что способны платформы. Такие вендоры, как Netskope и Zscaler, выпустили платформы, которые управляют и контролируют устройства безопасности и сетевое оборудование, ПО и сервисы через единый облачный интерфейс. И это только в области безопасности.</p> <p>Длинный список других продуктов для управления технологиями и не только уже совершил этот переход. Теперь и сетевые вендоры наконец-то начинают конкурировать и на уровне платформ. Но этот важнейший сдвиг трудно заметить на фоне маркетинговой шумихи вокруг ИИ, затмевающей этот важнейший момент.</p> <p>Надо признать, что развитие сетей идёт медленно, и переименование существующих вещей под эгидой ИИ — слишком распространённое явление на каждом рынке прямо сейчас. Если вы думаете: «Разве мы этого раньше не слышали? Разве это не просто приукрашивание действительности? Будут ли вообще команды мотивированы использовать эти платформы?», то это может так ощущаться — но на этот раз есть важное отличие.</p> <h3>Что осталось прежним</h3> <p>Клиенты по-прежнему хотят единую систему управления и мониторинга, которая позволит их сетям перейти к автономной работе. Идея платформы покажется знакомой любому, кто слышал рекламную кампанию «единой консоли» в течение последних десяти с лишним лет. Однако тогда это был в основном слоган. Немногие клиенты видели реальную ценность, потому что эти инструменты были сосредоточены почти исключительно на задачах «нулевого дня», с ограниченной общей функциональностью в рамках одного и того же ПО управления.</p> <p>Проводные инструменты управления были сложны в использовании и не обладали широкими возможностями беспроводной связи. Проводное и беспроводное управление на локальных серверах часто в сумме давали очень мало пользы. В действительности менее 10% сетевых команд приобретали инструменты управления сетью (не считая контроля доступа к сети) у того же поставщика, что и для коммутации. Беспроводные сети были исключением — выбора было немного — но даже в этом случае лишь небольшая часть организаций фактически использовала эти инструменты для управления проводной частью сети. Мониторинг и аналитика были в лучшем случае элементарными.</p> <h3>Что нового</h3> <p>Большие перемены произошли с появлением управления на основе SaaS. Aerohive (теперь часть Extreme Networks) и Meraki (теперь часть Cisco) доказали, что управление сетью может быть проще и эффективнее при предоставлении из облака. Это положило начало более широкому переходу к облачному управлению. Затем Mist снова подняла планку, показав, как богатая телеметрия в сочетании с большой вычислительной платформой может обеспечить значимые операции в Day 1 и Day 2.</p> <p>Объединив видимость LAN, WLAN и WAN, системы управления сетью начали превращаться в нечто большее: настоящие единые панели управления, теперь известные как платформы. Cisco, Extreme и Juniper осознали, что объединение данных из всей сети может вывести управление за пределы отдельных доменов (кампус, филиал, удаленный офис) на уровень всей корпоративной сети. Именно здесь ИИ начинает играть реальную роль. При наличии достаточного количества данных и контекста, платформы наконец могут обеспечить реальную операционную ценность. Как рассказал генеральный директор Extreme Networks Эд Мейеркорд, один из клиентов увидел, как время выполнения задач сократилось с 6 часов до 6 минут благодаря такой платформе.</p> <h3>Что это значит для рынка</h3> <p>Все это приводит к значительному сдвигу на рынке — и открывает возможности для поставщиков, которые предлагают действительно зрелые, унифицированные платформы. Эти новые платформы выйдут за рамки операционной инфраструктуры и предоставят многократно используемые возможности — декларативные модели, программируемые намерения и непрерывное отслеживание состояния — которые другие смогут использовать для построения и автоматизации на протяжении всего жизненного цикла, от проектирования до управления и вывода из эксплуатации. Крайне важно, чтобы платформа управлялась как продукт, а не как инструмент, с четкими результатами, ограничениями и ответственностью, потому что больше функций или вспомогательных средств ИИ не сделают платформу полноценной, если они существенно не улучшат результаты бизнеса.</p> <p>После приобретения Juniper компанией HPE, на рынке локальных сетей за пределами центров обработки данных образовалась большая ниша, которую необходимо заполнить. HPE предстоит некоторое время заниматься оптимизацией продуктовых линеек, переработкой ПО для поддержки своих амбиций в области дата-центров, основанных на GreenLake, и интеграцией двух крупных портфелей. Cisco, тем временем, все еще устраняет сложности в продуктах Meraki, Catalyst и своих WAN-решениях — и растущий спрос на решения, ориентированные на суверенитет, не облегчит эту задачу. Extreme имеет хорошие позиции для того, чтобы с помощью Platform ONE сделать в офисных зданиях и на удаленных площадках то, что Arista сделала в дата-центрах, став гигантом и маяком для этого сегмента рынка.</p> <p>Вывод прост: платформы не новы, но на этот раз они реальны. И это меняет направление развития конкуренции в сфере сетевых технологий.</p> 2026-й уже близок к середине, но впереди нас ждет еще много интересного — и, к счастью, не все … article https://www.itweek.ru/themes/detail.php?ID=234982 Tue, 09 Jun 2026 15:47:43 +0300 <p>Эксперты компании «Информзащита» выявили резкое сокращение окна между публикацией CVE и появлением рабочего эксплойта: по итогам анализа открытых баз уязвимостей, данных о публичных proof-of-concept и собственных кейсов реагирования среднее время снизилось со 125,3 дня в январе 2025 года до 0,5 дня к апрелю 2026 года. За первые пять месяцев 2026 года доля уязвимостей, по которым признаки эксплуатации или готовый PoC появлялись в первые сутки после раскрытия, достигла 38% против 12% за сопоставимый период 2025 года.</p> <p>Основная проблема заключается в том, что превратить информацию об ошибке в готовую атаку стало почти так же просто, как её прочитать. Для злоумышленников опубликованное исправление стало техническим указателем: сравнив старую и новую версии кода, можно восстановить логику ошибки и собрать рабочий пример атаки быстрее, чем организация успевает согласовать обновление. Раньше бюллетень производителя, запись в базе CVE и выпущенное исправление давали специалистам по ИБ несколько недель, иногда месяцев на инвентаризацию активов, оценку применимости и планирование обновления. Теперь этот интервал часто укладывается в одну рабочую смену. Для злоумышленников исправление стало не только способом закрыть проблему со стороны производителя, но и технической подсказкой: по сравнению изменений в коде можно восстановить логику ошибки, определить уязвимый участок, сопоставить его с типовыми приемами эксплуатации и собрать рабочий пример быстрее, чем крупная организация успеет пройти полный цикл согласования изменений.</p> <p>Дополнительное ускорение дали инструменты автоматизированного анализа кода и ассистенты на базе больших языковых моделей. Они не заменяют сильного специалиста по эксплуатации уязвимостей, но снимают значительную часть рутинной работы: помогают сравнивать версии, выделять изменения, связанные с безопасностью, подбирать входные данные, искать похожие ошибки в старых уведомлениях производителей и формировать черновики демонстрационного кода. В результате снизился порог входа для воспроизведения уже раскрытой уязвимости. По оценке экспертов, в 2026 году в 31% исследованных кейсов первые публичные примеры эксплуатации имели признаки ускоренной сборки на базе уже опубликованных исправлений, а в 18% случаев код атаки появлялся раньше, чем у крупных поставщиков средств сканирования и управления уязвимостями выходили стабильные проверки.</p> <p>На стороне бизнеса ситуацию осложняют кадровый дефицит и неоднородность инфраструктуры. Даже зрелые команды не всегда могут быстро ответить на базовый вопрос, где именно используется уязвимый компонент. В одной организации он может находиться в коммерческом продукте, контейнерном образе, внутренней разработке, устаревшем сервисе на периметре сети или в системе подрядчика. К этому добавляется разрыв между публикацией CVE и появлением качественного правила обнаружения в сканерах: часть проверок выходит с задержкой, часть покрывает только отдельные версии продукта, часть требует проверки с учетными данными, которую компании не всегда включают из-за рисков для рабочих систем. Команды привыкли закрывать уязвимости в плановом режиме — раз в неделю, иногда реже. Это работало, пока атака готовилась месяцами. Сейчас тот же процесс просто не успевает: к моменту, когда задача попадает в спринт, окно уже закрыто — но не в пользу защитников. </p> <p>Наиболее заметная концентрация риска в 2026 году наблюдается в отраслях, где сочетаются крупный внешний периметр, множество прикладных систем и жесткие ограничения на простои. По данным анализа обращений и расследований, на финансовый сектор пришлось 24% кейсов, связанных с эксплуатацией CVE в первые 72 часа после раскрытия, на промышленность и энергетику — 19%, на ИТ и телеком — 17%, на розничную торговлю и интернет-продажи — 14%, на транспорт и логистику — 10%, на государственные и окологосударственные организации — 9%, на медицину и фармацевтику — 7%. В финансах и интернет-торговле злоумышленников привлекает доступ к платежной инфраструктуре и персональным данным, в промышленности — длительные циклы обновления и зависимость от поставщиков, в телеком-сегменте — высокая плотность сетевых сервисов и большое число пограничных компонентов.</p> <p>Данные сканеров стоит дополнять ведомостью состава программного обеспечения, анализом состава приложений, мониторингом данных о киберугрозах и проверкой доступности систем с внешнего периметра сразу после публикации значимых CVE. Для критичных систем нужен заранее согласованный порядок экстренного обновления, приоритизация по фактической доступности актива из сети и сценарии временного снижения риска: отключение уязвимой функции, ограничение доступа по спискам контроля, усиление правил межсетевого экрана веб-приложений, изоляция сегмента, перевод сервиса за дополнительный контроль аутентификации. Отдельного внимания требует ретроспективный поиск признаков компрометации: при появлении эксплойта через несколько часов после раскрытия исправление уязвимости уже не гарантирует, что злоумышленники не успели закрепиться в системе до установки обновления.</p> Эксперты компании «Информзащита» выявили резкое сокращение окна между публикацией CVE и появлением рабочего эксплойта … message https://www.itweek.ru/themes/detail.php?ID=234981 Tue, 09 Jun 2026 15:47:00 +0300 <p>Промсельхозбанк вывел на российский рынок платежный сервис «Pay in Russia» (Плати в России) — иностранные туристы смогут открыть карту онлайн и пополнить ее удобным способом. Решение реализовано менее чем за 5 месяцев на базе платформы ДБО для физлиц от BSS, которая позволяет быстро доработать функционал под бизнес-идеи банка и бесшовно интегрировать различные сервисы для клиентов.</p> <p>Промсельхозбанк внедрил первый полноценный платежный сервис «Pay in Russia» (Плати в России) для иностранных туристов на базе системы дистанционного банковского обслуживания для физлиц от BSS. </p> <p>Новое решение позволяет гостям из других стран оплачивать товары и услуги по QR-коду как онлайн, так и офлайн. Онлайн-счет заводится в несколько кликов, и пополнять его клиент может прямо со своих зарубежных карт. </p> <p>Сервис реализован на базе платформы Digital2Retail — команда BSS расширила ее функциональность под задачи сервиса: обеспечила выпуск виртуальных карт для пользователей, реализовала сценарии работы с идентификацией и без нее, внедрила распознавание и поддержку паспортов различных стран, а также предусмотрела ряд других возможностей.</p> <p>Ключевое преимущество платформы BSS — гибкость и возможность развития: система позволяет быстро адаптироваться и реализовывать новые требования заказчика, дорабатывать функциональность под новые продукты и бесшовно интегрироваться с внешними сервисами через ТИР.</p> <p>Председатель Правления Промсельхозбанка Владимир Курстак прокомментировал: «Новое решение упростит расчеты и сделает уровень сервиса для туристов в российских городах еще комфортнее. Для бизнеса это дополнительный драйвер роста: сервис снимает барьеры на финальном этапе оплаты и помогает сократить упущенную выгоду, которая, по оценкам экспертов, исчислялась миллиардами рублей».</p> <p>Равшан Рахманов, директор по развитию продуктов Центра разработки продуктов для физических лиц компании BSS, рассказал: «Благодаря гибкости нашей системы ДБО банки могут как вносить точечные доработки, так и создавать новые цифровые сервисы под конкретные бизнес-задачи заказчика, соблюдая Time To Market. Наглядный пример — платежный сервис „Pay in Russia“ (Плати в России), при реализации которого были учтены уникальные бизнес-процессы и требования Банка, и который при этом реализован менее чем за пять месяцев с момента старта проекта».</p> Промсельхозбанк вывел на российский рынок платежный сервис «Pay in Russia» (Плати в России) — иностранные … message https://www.itweek.ru/themes/detail.php?ID=234980 Tue, 09 Jun 2026 09:17:57 +0300 <p><em>Согласно Gartner «1H26 CIO Report», 77% </em><em>CIO</em> <em>называют безопасность и риски главными препятствиями для масштабирования автономных технологий. Некоторые из них, тем не менее, находят способы ускорить этот процесс, сообщает портал </em><em>InformationWeek</em><em>.</em></p> <p>Автономный искусственный интеллект выходит от стадии эксперимента и становится приоритетом предприятия. Модели достаточно точны. Экономическое обоснование очевидно. Советы директоров стремятся к ускорению. Но большинство CIO сдерживают проблемы безопасности, а не технические ограничения.</p> <p>Действительно, 77% из более чем 11 тыс. CIO, опрошенных Gartner, заявили, что безопасность и риски являются главными препятствиями для масштабирования автономных технологий. Их опасения обоснованы: автономные агенты ИИ могут допускать утечки данных, совершать дорогостоящие ошибки и создавать проблемы с аудитом.</p> <p>Но все большее число CIO находят способы ускорить процесс, не жертвуя безопасностью. Ответ, по их словам, кроется в защитных ограничениях, управлении и ином типе партнерства между CIO и руководителями, отвечающими за безопасность и конфиденциальность.</p> <h3>Растущее давление со стороны автономного ИИ</h3> <p>Согласно <a href="https://www.gartner.com/en/newsroom/press-releases/2026-04-23-gartner-survey-reveals-80-percent-of-ceos-say-artificial-intelligence-will-force-operational-capability-overhauls">опросу</a> Gartner, проведенному в апреле 2026 г. среди 469 руководителей компаний, примерно восемь из десяти из них ожидают, что к 2030 г. автономный бизнес будет доминировать в их отрасли. Советы директоров и руководство, осознавая конкурентные риски, подталкивают CIO идти в ногу с этими изменениями.</p> <p>«Наши команда руководителей и совет директоров относительно хорошо разбираются в ИИ, — говорит Кит Фултон, директор по данным поставщика ПО для финансовых учреждений Jack Henry. — Они видят потенциал ИИ. И спрашивают: „Как мы можем ускорить процесс?“. Я отвечаю: „Я тоже хочу ускорить процесс. Но мы хотим быть осторожными“».</p> <p>Это напряжение между давлением бизнеса и дисциплиной в области безопасности проявляется во всех отраслях. Опрос Sembi «Software Quality Pulse Report», проведенный среди почти 3800 руководителей компаний-разработчиков ПО, показал, что 86% как минимум иногда задерживают выпуск релизов из-за проблем безопасности, а 63% называют проблемы конфиденциальности и безопасности препятствиями для внедрения ИИ.</p> <p>«Сейчас со всех сторон бизнеса оказывается реальное давление с целью ускорения внедрения ИИ, и команды безопасности [и ИТ] не могут просто сказать „нет“, — отмечает Ринки Сети, CISO компании Upwind Security и бывший руководитель служб безопасности в Twitter, Rubrik и BILL. — Разговор сместился с блокирования инноваций на их ответственное внедрение».</p> <h3>Главные проблемы с агентным ИИ</h3> <p><strong>Утечка данных.</strong> По словам многих руководителей, основная проблема — это видимость, точнее её отсутствие. «Большинство организаций до сих пор не до конца понимают, к чему имеют доступ агенты ИИ, на какие действия они способны и как они ведут себя после развертывания в производственных средах, — говорит Сети. — Утечка данных — это серьезная проблема, особенно когда агенты могут получать доступ к внутренним системам или перемещать информацию между средами без четкого контроля».</p> <p>Фултон проводит различие между кибербезопасностью и безопасностью данных: «На самом деле, самая большая проблема — это не кибербезопасность. А безопасность денег и данных. Мы должны быть уверены, что персональные данные не покидают здание, когда мы общаемся с агентами гиперскейлеров».</p> <p><strong>Ошибочность агентов.</strong> Проблема усугубляется ошибочностью агентного ИИ. «Агенты достигли точности <nobr>80-99%.</nobr> Они становятся лучше, но точны не на 100%, — говорит Фултон. — Если бы у вас была электронная таблица Excel, и 1% возвращаемых ею данных были бы вымышленными, никто бы ею не пользовался. Но агенты страдают именно этим».</p> <p><strong>Теневой ИИ.</strong> Дополнительную сложность добавляет рост теневого ИИ. «Сотрудники внедряют инструменты ИИ, потому что они повышают производительность, и большинство групп по безопасности обнаруживают их использование постфактум, а не через формальные процессы утверждения, — говорит Сети. — Однако решение не в том, чтобы запрещать всё подряд, потому что это обычно загоняет деятельность ещё глубже в подполье».</p> <h3>Безопасность в ИИ с самого начала</h3> <p>Организации, которые продвигаются быстрее всего, не добавляют безопасность после развертывания. Они строят её с самого начала.</p> <p>«Безопасность не является для нас тормозом, — говорит Чейз Кристенсен, CIO сегмента и вице-президент по корпоративным решениям компании Jabil, предоставляющей производственные услуги. — Она замедляет процесс только тогда, когда мы не закладываем ее в наши процессы. Мы же встраиваем безопасность на начальном этапе жизненного цикла разработки ПО (SDLC). Это устраняет все препятствия и позволяет нам быстро масштабироваться».</p> <p>Он также переосмыслил подход Jabil к теневым ИТ и ИИ. «Мы не говорим о теневых ИТ — мы говорим о демократизации ИТ, — поясняет он. — Корпоративные ИТ-службы могут работать медленно. Наша задача — предоставить платформы. Когда мы обеспечиваем правильные данные и правила использования, то, что выглядит как теневые ИТ, становится двигателем роста организации».</p> <p>Сети соглашается с тем, что ранняя интеграция имеет важное значение. «Организации, которые успешно это делают, с самого начала рассматривают системы ИИ как производственные нагрузки, а не как экспериментальные побочные проекты, — говорит она. — Добавление системы безопасности после развертывания редко бывает эффективной, потому что к этому моменту система ИИ уже интегрирована в рабочие процессы, API и среды данных, которые трудно распутать».</p> <h3>Правильные ограничения для ИИ: принцип собачьей площадки</h3> <p>Фултон рассматривает ограничения не как препятствия, а как факторы, ускоряющие процесс. «Я часто обращаюсь к аналогии с собачьей площадкой, — говорит он. — Я вожу туда своего щенка, потому что хочу, чтобы у нее была свобода, но я не хочу, чтобы она бегала по улице. Она видит забор и не выходит за него. Она может резвиться, и я знаю, что с ней все в порядке. Ключ к быстрому прогрессу — это наличие правильных ограничений».</p> <p>Уровень риска определяет ограничения. «У нас есть критерии для оценки уровня риска действий, которые может предпринять агент, — говорит Фултон. — В зависимости от уровня риска мы применяем разные ограничения. Перемещение денег очень сложно отменить. Ограничения в этом случае должны быть очень осторожными и строгими по сравнению с ограничениями для „второго пилота“, помогающего составить документ Word».</p> <p>Ответственность не подлежит обсуждению. «Каждый агент должен отслеживаться, проверяться и быть привязан к конкретному человеку, ответственному за его поведение, — считает Фултон. — Нельзя посадить агента в тюрьму. Каждое действие агента должно быть отслежено до человека, ответственного за него».</p> <h3>Непрерывная видимость развертывания ИИ</h3> <p>Для Сети самым большим изменением является переход от статических проверок политик к мониторингу в режиме реального времени. «Безопасность становится тормозом, когда команды полагаются на традиционные модели управления, которые не были созданы для автономных систем реального времени, — говорит она. — Организации, которые продвигаются быстрее всего, — это те, которые при развертывании ИИ с самого начала обеспечивают видимость и контекст в режиме реального времени, вместо того чтобы пытаться добавить элементы управления позже».</p> <p>Это означает переосмысление того, что такое «достаточно хорошая» безопасность. «Если вы не можете ответить на вопрос, к каким данным агент имеет доступ, какие действия он может предпринять или отклонилось ли его поведение от нормальных шаблонов, вы не готовы к масштабированию, — отмечает Сети. — Ошибка заключается в том, чтобы рассматривать развертывание ИИ как требующее разовой проверки безопасности, а не как постоянное обязательство по мониторингу».</p> <h3>Изменение взаимоотношений между CIO и CISO</h3> <p>Многие руководители указывают на динамику отношений между CIO и CISO как на критически важный фактор — или узкое место — в области автономного ИИ.</p> <p>«ИИ делает отношения между CIO и CISO гораздо более тесно переплетенными в операционном плане, — говорит Сети. — Исторически безопасность и ИТ могли работать параллельно, но автономные системы требуют гораздо более тесной координации, поскольку инфраструктура, управление данными, разработка приложений и безопасность теперь глубоко взаимосвязаны».</p> <p>Разговоры также изменились. «Речь теперь идет не столько о контрольных списках соответствия, сколько об операционной устойчивости, прозрачности и управлении бизнес-рисками со скоростью автоматизации, — отмечает Сети. — Во многих организациях CIO и CISO теперь совместно несут ответственность за безопасное внедрение ИИ, а не рассматривают безопасность как функцию утверждения на последующем этапе».</p> <p>Роль директора по конфиденциальности (CPO). По словам Фултона, традиционное партнерство CIO и CISO — это лишь часть картины. «CPO может быть вовлечен больше, чем CISO, — говорит он. — Речь идёт об уважении конфиденциальности клиентов и заказчиков — и о том, чтобы не доверять их данные гиперскейлерам».</p> <p>Организации, масштабирующие автономный ИИ, не игнорируют безопасность. Они просто перестали позволять ей быть причиной того, что все останавливается. «Не ждите идеального управления, прежде чем двигаться вперёд, потому что бизнесу надо идти вперёд, — советует Сети. — Скорость без видимости создаёт риск, тогда как видимость даёт вам уверенность в том, что вы можете ответственно двигаться быстрее».</p> Согласно Gartner «1H26 CIO Report», 77% CIO называют безопасность и риски главными препятствиями для масштабирования … article https://www.itweek.ru/themes/detail.php?ID=234978 Tue, 09 Jun 2026 09:03:59 +0300 <p><em>На рынке труда в ИТ сложилась странная ситуация: резюме много, подходящих людей — по</em><em>-</em><em>прежнему мало. Повышать зарплаты бизнес не может — компании оптимизируются в связи с охлаждением экономики. </em><em>Рассмотрим, к</em><em>ак балансировать между дефицитом сильных специалистов и ограниченным бюджетом так, чтобы ИТ-команда работала на бизнес-результат.</em></p> <p>Еще несколько лет назад ИТ-директор мог закрывать большинство кадровых задач деньгами и массовым аутсорсингом. Теперь таких бюджетов нет, а те специалисты, которые действительно двигают продукт и инфраструктуру вперед, дороги и штучны. Реальный спрос смещается в сторону узких и сложных ролей — архитекторов, техлидов, экспертов в доменах (финтех, HR-tech, логистика, e-commerce) и специалистов по современным стекам и инструментам.</p> <p>Воронка резюме расширяется, но большинство кандидатов не дотягивают по глубине экспертизы. При этом на рынке мало аутсорс-команд, которые действительно разбираются в конкретном бизнес-домене заказчика. Ожидания сильных специалистов по зарплате выросли и уперлись во внутренние ограничения компаний. В результате ИТ-директора зажаты с двух сторон: с одной — «зарплатный потолок» и жесткий бюджет, с другой — дефицит тех, кто реально тянет сложные проекты.</p> <h2>От количества к компетенциям</h2> <p>Раньше, чтобы быстрее показать результат, нанимали больше людей. Сегодня такая логика не работает: набор еще десятка мидлов без доменной экспертизы не решает задач бизнеса. Поэтому полезно ввести несколько новых принципов найма.</p> <ul> <li> <strong>Доменные знания как обязательное требование.</strong> Если продукт в HR, нужен человек, который понимает HR-процессы, если система для финтеха — специалист, который разбирается в финансовых инструментах и регуляторике. Универсальные разработчики все хуже попадают в сложные вертикали.</li> <li> <strong>Глубина компетенций важнее широты.</strong> В условиях жестких бюджетов компании ищут людей, которые могут спроектировать устойчивую архитектуру, закрыть вопросы безопасности, обеспечить сложные интеграции и взять на себя ответственность за решения, от которых зависит работа систем.</li> <li><strong>Не нанимать, если можно автоматизировать.</strong> Рутинная работа в разработке, тестировании и поддержке постепенно уходит в автоматизацию — от CI/CD-пайплайнов до самообслуживания в поддержке.</li> </ul> <h2>Сегментация команды</h2> <p>Структура ИТ-команд часто выглядит как «линейка грейдов»: джуны, мидлы, сеньоры, тимлиды — без явной бизнес-логики распределения ресурсов. Сегодня стоит перейти к более жесткой сегментации. Бюджет и усилия по удержанию распределяются по трем уровням.</p> <h3>Уровень 1: незаменимые эксперты и архитекторы</h3> <p>Это небольшой слой людей, без которых бизнес перестает работать. Архитекторы, ведущие эксперты по основным продуктам, системам и платформам, люди, которые держат в руках критичные участки — от ядра продукта до стратегических интеграций.</p> <ul> <li> Им платят заметно больше среднего по рынку.</li> <li> С ними работают точечно по вовлеченности и удержанию.</li> <li> Их риски ухода — под постоянным управлением: от преемственности до распределения знаний внутри команды.</li> </ul> <p>Потеря одного такого человека может «заморозить» проект на месяцы и обойтись компании в миллионы.</p> <h3>Уровень 2: сильные исполнители</h3> <p>Сюда попадает основной массив разработчиков, аналитиков, тестировщиков, тимлидов, которые обеспечивают стабильную работу и развитие продуктов.</p> <ul> <li> Главное для этого слоя — предсказуемость и стабильность: понятные процессы, прозрачные правила игры, адекватный менеджмент.</li> <li> Текучка должна быть управляемой: массовый отток мидлов и синьоров бьет по скорости поставки и качеству.</li> </ul> <p>Для сотрудников второго уровня компания не всегда может существенно увеличивать сумму вознаграждения, поэтому конкурентоспособность часто обеспечивается за счет условий: гибкий формат работы, понятные карьерные треки, обучение и участие в интересных проектах.</p> <h3>Уровень 3: джуниоры и аутсорс</h3> <p>Это слой, где допускается высокая текучка и максимальная автоматизация. Речь идет о начинающих ролях, а также внешних подрядчиках, которые закрывают типовые задачи — поддержка, доработки, неключевые проекты.</p> <ul> <li> Здесь важно выстроить процессы так, чтобы уход одного человека минимально влиял на бизнес.</li> <li> Любые рутинные операции должны быть максимально описаны и автоматизированы.</li> <li> Новые люди должны быстро входить в контур, а действующие — легко заменяться.</li> </ul> <p>Такой подход к сегментации позволяет ИТ-директору честно ответить на вопросы: «На кого мы тратим больше всего денег?», «Кого мы ни в коем случае не можем потерять?», Где мы можем позволить себе текучку?".</p> <h2>Роль ИТ-директора в достижении бизнес-результата</h2> <p>ИТ-директор становится одним из профильных руководителей, влияющих на бизнес-результат. Однако рассчитывать точное влияние ИТ на P&L (отчет о прибылях и убытках) — сложно, а интерпретация может быть субъективной: слишком много факторов влияют на итоговую картину (от автоматизации до прямых доходов), и легко нарисовать желаемые цифры, которые далеки от реальности. Поэтому лучше также показывать результат через надежные метрики, которые в свою очередь влияют на P&L. Это управляемость процессов, пользовательский и клиентский опыт, скорость вывода продуктов.</p> <p>Например, при разворачивании системы мультиканального общения сотрудников чистая экономия в деньгах не сойдется. Зато улучшения в управляемости и пользовательском опыте принесут бизнесу реальный эффект.</p> <p>Таким образом, для влияния на P&L ИТ-директор может:</p> <ul> <li> снижать расходы за счет автоматизации процессов и оптимизации поддержки;</li> <li> контролировать фонд оплаты труда, перераспределяя задачи между сотрудниками разного уровня, снижая зависимость от дорогих специалистов и выстраивая осознанную политику аутсорса;</li> <li> увеличивать выручку и скорость вывода продуктов за счет грамотной структуры команды, которая может быстро запускать и масштабировать решения.</li> </ul> <p>По сути, ИТ-директор сегодня отвечает не только за технологии, но и за то, как эти технологии превращаются в деньги и экономию для бизнеса.</p> <h2>Что делать ИТ-директору уже сейчас</h2> <ol> <li><strong>Провести инвентаризацию команды.</strong> Честно разделить сотрудников на три уровня — понять, кто действительно незаменим, какие позиции нужно усилить, кого перевести в другой формат работы.</li> <li><strong>Пересобрать структуру затрат.</strong> Сфокусировать бюджет на удержании ключевых экспертов и архитекторов, заложить стабильные условия для ядра специалистов второго уровня, выстроить экономную модель третьего уровня.</li> <li><strong>Усилить доменную экспертизу.</strong> Пересмотреть требования к найму: ввести обязательный фильтр по доменным знаниям, добавить кейсы на понимание конкретного бизнеса, уделять внимание не только стеку, но и пониманию предметной области.</li> <li><strong>Ускорить автоматизацию.</strong> Проанализировать, какие функции можно отдать скриптам, платформам и сервисам — и сократить зависимость от ручного труда там, где он не создает уникальной ценности.</li> <li><strong>Связать ИТ с бизнес-результатом.</strong> Показать бизнесу, как реструктуризация команды и автоматизация позволяют ускорять запуск новых продуктов, улучшать управляемость в командах и пользовательский опыт.</li> </ol> <p>#IMAGE_234979#</p> На рынке труда в ИТ сложилась странная ситуация: резюме много, подходящих людей — по-прежнему мало. Повышать … article Дмитрий Махлин, партнер и директор по развитию HRlink https://www.itweek.ru/themes/detail.php?ID=234974 Mon, 08 Jun 2026 11:06:28 +0300 <p>Сбер выпустил новую версию ИИ-ассистента GigaCode, которая работает и запускается из командной строки независимо от типа среды разработки (IDE) и операционной системы</p> <p>GigaCode CLI — это мультиагентная система, ориентированная на автономную генерацию кода. Она позволяет запускать задачи прямо из терминала, работать в привычном репозитории, автоматизировать сборку, тестирование и внесение изменений в код, а также искать уязвимости, рефакторить код, писать тесты. Основная ценность GigaCode CLI в ускорении выполнения типовых операций в защищенном контуре организации.</p> <p>Использование GigaCode CLI локально (on-premise) — это ответ на запрос крупных корпоративных клиентов. Им важно ускорять разработку с помощью искусственного интеллекта, сохраняя полный контроль над данными и инфраструктурой внутри собственного периметра. Автономность разработки критична, в частности, для банков, промышленности, телеком- и государственных организаций, где требования к информационной безопасности и локализации данных стоят на первом месте.</p> <p>Андрей Белевцев, старший вице-президент, руководитель блока «Технологическое развитие» Сбербанка, отметил: «Наши внутренние тесты показали, что использование CLI в GigaCode повышает производительность инженеров на <nobr>30-70%</nobr> в зависимости от их задач. Глобально уменьшаются затраченные человеко-часы и растет качество ПО за счет лучшей проверки кода и поиска уязвимостей. Развитие GigaCode, расширение его функциональности и дальнейшая интеграция в разработку на стороне клиентов позволяет не просто автоматизировать задачи заказчиков, а кардинально сократить время вывода продуктов на рынок, обеспечить безопасность кода и совершить качественный скачок в трансформации всей ИТ-инфраструктуры».</p> <p>Помимо ключевого обновления в виде локального <nobr>CLI-агента,</nobr> в GigaCode стал доступен расширенный набор больших языковых моделей. Оплата за них осуществляется в рублях. Таким образом, клиенты смогут продолжать пользоваться наиболее современными и мощными нейросетями для разработки.</p> Сбер выпустил новую версию ИИ-ассистента GigaCode, которая работает и запускается из командной строки независимо … message https://www.itweek.ru/themes/detail.php?ID=234973 Mon, 08 Jun 2026 11:04:55 +0300 <p>За последние годы искусственный интеллект из прикладного инструмента превратился в один из ключевых факторов трансформации науки. На примере стран, наиболее активно внедряющих ИИ в научную деятельность, Институт статистических исследований и экономики знаний (ИСИЭЗ) НИУ ВШЭ изучил разные модели развития и регулирования данной сферы.</p> <p>Американская модель делает ставку на расширение доступа исследователей к данным, вычислительным ресурсам и ИИ-инструментам. Эту задачу решают такие крупные инфраструктурные инициативы, как Национальный ресурс для исследований ИИ (NAIRR) и программа Genesis. Государство выступает главным образом в роли координатора и инвестора, а регулирование остается преимущественно мягким и основывается на добровольных стандартах и инструментах оценки рисков. Важную роль в развитии системы играют также принципы открытой науки, предполагающие обмен данными и моделями.</p> <p>Китайская модель отличается значительным масштабом инвестиций и высокой степенью централизации. Государство координирует развитие вычислительной инфраструктуры, научных данных и кадрового потенциала, а финансирование осуществляется через крупные госпрограммы. Например, Национальная система скоординированных инноваций интегрированных центров больших данных поддерживает работу распределенной вычислительной инфраструктуры и сети из восьми опорных вычислительных хабов, ежегодно обеспечивающих ресурсами сотни исследовательских проектов. Такой подход позволяет концентрировать ресурсы на приоритетных направлениях и ускорять их развитие.</p> <p>Европейская модель сочетает масштабные инвестиции в инфраструктуру и научную кооперацию с одной из наиболее развитых систем регулирования ИИ. Значительные средства направлены на создание единого исследовательского пространства, объединяющего данные, вычислительные мощности и научные коллективы стран ЕС. Одновременно действуют обязательные требования к аудиту высокорисковых систем ИИ и использованию персональных данных, обеспечивающие прозрачность и безопасность применения технологии.</p> <p>Британская модель обеспечивает развитие вычислительной инфраструктуры и адресную поддержку проектов и исследовательских коллективов даже при более ограниченных объемах государственных инвестиций. Доступ к вычислительным ресурсам реализуется через специализированную инфраструктуру, ключевую роль в которой играет программа AI Research Resource, предоставляющая научным коллективам мощности для обучения и использования ИИ-моделей.</p> <p>Опыт ведущих стран показывает, что конкуренция в сфере ИИ для науки разворачивается не столько на уровне отдельных разработок, сколько в плоскости создания устойчивых научно-технологических экосистем. Несмотря на различия в моделях регулирования, государства используют схожий набор инструментов поддержки: развивают вычислительную инфраструктуру и ресурсы научных данных, поддерживают исследовательские проекты и подготовку кадров, внедряют принципы ответственного использования ИИ. Для России это означает необходимость комплексного подхода, объединяющего развитие инфраструктуры, кадрового потенциала и механизмов взаимодействия науки и индустрии с формированием национальных стандартов применения ИИ.</p> За последние годы искусственный интеллект из прикладного инструмента превратился в один из ключевых факторов … message https://www.itweek.ru/themes/detail.php?ID=234972 Mon, 08 Jun 2026 11:03:31 +0300 <p>Вышла новая версия Luxms BI v12. Платформа включает ИИ-функциональность, расширение возможностей программируемой аналитики и глубокой адаптации под корпоративные задачи. Обновление затрагивает ключевые уровни системы — технологический стек, пользовательский интерфейс и внутреннюю логику работы с данными.</p> <p>Одним из ключевых обновлений Luxms BI v12 стала поддержка ИИ-сценариев. В платформе появился ИИ-аналитик — интеллектуальный ассистент, встроенный непосредственно в BI-среду.</p> <p>Пользователь может общаться с ним на естественном языке без специальных промтов. ИИ понимает структуру аналитической модели, работает с существующими показателями, фактами и размерностями и помогает выполнять повседневные задачи аналитики.</p> <p>ИИ-аналитик может:</p> <ul> <li>создавать кубы и аналитические модели данных;</li> <li>самостоятельно формировать дэшборды и отчеты по запросу пользователя;</li> <li>объяснять полученные результаты и помогать интерпретировать показатели;</li> <li>ускорять работу с данными и создание аналитических решений.</li> </ul> <p>ИИ-аналитик позволяет автоматизировать и ускорить работу дата-инженера и аналитика — от подключения источника, при наличии подключения к каталогу данных*, и подготовки модели данных до готового отчета и аналитического вывода.</p> <p>Luxms BI позволяет подключать различные <nobr>LLM-модели</nobr> непосредственно в аналитические процессы. Особое внимание уделено безопасности — поддерживается использование локальных моделей, когда данные остаются внутри корпоративного контура компании.</p> <p>При этом платформа не ограничивается готовыми функциями вроде чат-ботов или встроенных ассистентов. Сегодня это может быть ИИ-аналитик, а завтра любой другой интеллектуальный сценарий, необходимый бизнесу.</p> <p>ИИ-функциональность доступна начиная с версии 12 как дополнительное расширение платформы и требует отдельного лицензирования.</p> <p>Одним из важных обновлений в версии 12 стало развитие LPE — внутреннего языка платформы.</p> <p>LPE по-прежнему остается удобным языком формул и расчетов, постоянно развивается и пополняется новым функционалом. Но теперь LPE стал еще и мощным языком программирования, который управляет поведением системы. Он связывает данные, расчеты, визуализации, фильтры, пользовательское поведение и интерфейс единой логикой. LPE в версии 12 позволяет:</p> <ul> <li>динамически изменять структуру и отображение дэшбордов;</li> <li>управлять состояниями, фильтрами и пользовательскими сценариями;</li> <li>адаптировать интерфейс под контекст и действия пользователя;</li> <li>реализовывать сложную бизнес-логику без внешней разработки.</li> </ul> <p>LPE в 12 версии дает возможность настроить бизнес-логику, которая не закладывалась вендором, путём написания кода с использованием специально разработанных для этого функций. </p> <p>Один интерфейс может адаптироваться под различные сценарии использования, менять набор визуализаций, компоновку, фильтры и аналитику в зависимости от контекста. Например, при снижении продаж на дэшборде показывается детализация каналов продвижения, а при перерасходе бюджета — структуру затрат и эффект.</p> <p>Раньше такая задача решались бы через набор отдельных дэшбордов, а сейчас — внутри одного интерфейса. Дэшборд может динамически менять свое содержимое в зависимости от состояния — фильтров, пользовательских действий, прав или даже размера экрана. Фактически — набор различных сценариев в одном интерфейсе.</p> <p>По сути, Luxms BI формирует собственный слой программируемой логики внутри платформы. LPE выступает как специализированный предметно-ориентированный язык для управления логикой и поведением внутри платформы. Такой подход позволяет реализовывать сложные сценарии, сохраняя преимущества коробочного решения — безопасность, управляемость и совместимость при обновлениях системы. Компании получают гибкость кастомизации без типичных проблем глубокой разработки на JavaScript, где обновления со временем приводят к рискам несовместимости и усложнению поддержки решений.</p> <p>В планах развития — развитие интерфейса для настройки логики с LPE, усиления подхода к переиспользованию через Init.LPE и упрощение создания сложных сценариев.</p> <p>Но при этом LPE это также и язык формул, как и раньше. Простой пользователь может ограничиться расчетами, а продвинутый аналитик — использовать его как полноценный скриптовый язык. Это важный шаг в сторону self-service — аналитики получают больше контроля без необходимости полноценной разработки. В результате платформа становится расширяемой не только со стороны вендора, но и со стороны пользователя.</p> <p>Важной частью обновления стал переход платформы на React 19. Для Luxms BI это стратегическое обновление технологического стека, которое влияет на производительность, стабильность и дальнейшее развитие интерфейсов платформы.</p> <p>Новая версия React обеспечивает:</p> <ul> <li>более высокую отзывчивость интерфейсов;</li> <li>стабильную работу сложных дэшбордов и больших объемов данных;</li> <li>снижение нагрузки на браузер;</li> <li>улучшенную обработку состояний и ошибок;</li> <li>совместимость с современными библиотеками и инструментами разработки.</li> </ul> <p>Переход на актуальную версию React также формирует основу для ускоренного развития пользовательских интерфейсов и внедрения новых возможностей платформы в будущих релизах.</p> <p>White label и развитие корпоративных BI-платформ</p> <p>В новой версии Luxms BI появилась поддержка white label — возможность разворачивать платформу как собственное BI-решение компании.</p> <p>Компании могут использовать Luxms BI как технологическую основу собственной BI-платформы, адаптируя интерфейс, визуальный стиль и пользовательский опыт под собственный бренд и корпоративные стандарты. Такой подход особенно востребован в крупных организациях, где усиливается тренд на развитие внутренних цифровых платформ и независимых ИТ-экосистем.</p> <p>White label позволяет объединить преимущества готовой промышленной BI-платформы с гибкостью собственного решения без необходимости разрабатывать систему с нуля.</p> <p>С версии 12 документация становится версионной — теперь можно выбирать нужный вариант базы знаний в соответствии с версией системы, с которой работаете. Также в документации к версии 12.0.0 появились новые разделы:</p> <ul> <li>руководство по LPE для фронтенда;</li> <li>руководство по управлению отчетами;</li> <li>руководство прикладного администратора.</li> </ul> <p>Luxms BI v12 — это не просто очередное обновление функциональности. Новая версия усиливает платформу сразу на нескольких уровнях — архитектуры, интерфейсов, логики и возможностей кастомизации, и предлагает основу для дальнейшего развития интеллектуальной аналитики.</p> Вышла новая версия Luxms BI v12. Платформа включает ИИ-функциональность, расширение возможностей программируемой аналитики … message https://www.itweek.ru/themes/detail.php?ID=234971 Mon, 08 Jun 2026 11:01:22 +0300 <p>«Яндекс» разработал ультрамалую нейросетевую модель для голосового управления в носимых ИИ-устройствах. Размер модели удалось сократить без потери качества примерно до 200 Кб — это меньше объёма одной фотографии на смартфоне. Информацией об этом поделился Дмитрий Солодуха, руководитель направления голосовой активации в «Яндексе».</p> <p>Подход к голосовому управлению в носимых устройствах отличается от подхода, используемого в умных колонках или смартфонах. Компактные гаджеты сильнее ограничены по ёмкости аккумулятора, объёму памяти и вычислительной мощности процессора. При этом система голосовой активации должна постоянно анализировать аудиопоток и обрабатывать его локально в ожидании ключевой команды, не создавая заметной нагрузки на устройство и не сокращая время его автономной работы. Для решения этой задачи команда Яндекса создала систему обработки голоса на нескольких уровнях — от аппаратной части до самой нейросетевой модели.</p> <p>Инженеры применили двухэтапную систему обработки аудиосигнала. Сначала лёгкая модель определяет наличие речи в потоке звука и практически не нагружает устройство. Основная модель запускается только после этого и проверяет, была ли произнесена ключевая голосовая команда. Такой подход позволяет снизить постоянную вычислительную нагрузку и расход энергии.</p> <p>Отдельной задачей стала оптимизация самой нейросетевой модели, поскольку именно непрерывная работа системы голосовой активации, которая ждет команду, создаёт основную нагрузку на аккумулятор устройства. Команда сократила число параметров модели примерно в 10 раз за счёт более компактной архитектуры нейросети, которая требует меньше вычислений без существенной потери качества распознавания. Это позволяет выполнять распознавание голосовой команды локально — без постоянной передачи аудиосигнала в облако. За счёт этого снижается энергопотребление устройства и уменьшается задержка при обработке команд.</p> <p>Одним из решений проблемы стало использование чипов с NPU — специализированным нейропроцессором для ускорения вычислений нейросетей с меньшим энергопотреблением по сравнению с CPU.</p> <p>По словам Дмитрия Солодухи, такой подход может использоваться в разных устройствах с обработкой речи в реальном времени — например, в наушниках, умных часах и других компактных носимых устройствах с ИИ-функциями.</p> «Яндекс» разработал ультрамалую нейросетевую модель для голосового управления в носимых ИИ-устройствах. Размер модели … message https://www.itweek.ru/themes/detail.php?ID=234969 Mon, 08 Jun 2026 08:43:11 +0300 <p><em>Три четверти руководителей предприятий сообщают, что они внедряют агентный искусственный интеллект. Но лишь небольшое меньшинство использует его в реальных производственных условиях, за исключением «агентных» чат-ботов, а по-настоящему масштабируемые мультиагентные системы встречаются еще реже. В этом разрыв между погоней и достижением результата, и это история 2026 г. Технология ИИ — это неуправляемый поезд. А предприятие — это тяжелый груз, который оно должна тянуть, пишут в корпоративном блоге авторы нового отчета </em><em>Forrester</em> <em>«</em><em>The</em> <em>State</em> <em>Of</em> <em>Agentic</em> <em>AI</em><em>, 2026</em><em>».</em></p> <p> #IMAGE_234970#</p> <p>В основе нового исследования Forrester лежат интервью с архитекторами, создающими агентные системы. Авторы отчета также проанализировали данные опроса, чтобы подкрепить эту историю фактами. Общий вывод таков: технология уже появилась, но готовность предприятий к её внедрению пока отстает. Это никого не должно удивлять. Мы уже видели подобную историю. Более сложный вопрос заключается в том, сможет ли готовность когда-либо догнать технологию, развивающуюся так быстро.</p> <h3>Ждать агентов больше не нужно</h3> <p>Возможности ИИ уже есть, и они появились быстрее, чем кто-либо ожидал. Рынок поставщиков в режиме реального времени перестраивается вокруг агентов. Агенты теперь работают часами, днями, даже месяцами. OpenAI уже несколько месяцев использует внутренний рабочий процесс разработки ПО с минимальным вмешательством. Cursor развернула агентов, работающих в режиме длительного кодирования. Anthropic продемонстрировала агентов для многодневных исследований. Доказательства применимости технологии получены.</p> <p>Агент, работающий в режиме длительного кодирования, не ведёт себя как чат-бот. Она ведёт себя как распределённая система, а распределённые системы требуют оркестровки, идентификации и дисциплины контекста, которые большинство компаний никогда не создавали. Масштабирование терпит неудачу из-за сложности задач, а не из-за количества агентов, и большинство команд вообще не управляют этой сложностью. Объедините десяток изолированных агентов без общих реестров или маршрутизации, и координация развалится на дублирование и расхождение.</p> <h3>Погоня проста — добыча дорога</h3> <p>Интерес есть повсюду. Масштабирование — редкость. Причины этого упорно остаются неизменными, и начинаются они с денег. Неопределённость рентабельности инвестиций загоняет амбиции предприятий в режим пилотного проекта, потому что большинство компаний не могут обосновать производственные выгоды за пределами узкого повышения эффективности. Пробелы в управлении приводят к разрастанию агентной сети. Более половины предприятий сообщают об этом даже после принятия NIST AI RMF, потому что документ с политикой не может контролировать автономную систему, использующую инструменты. А путаница с платформами замораживает обязательства, пока команды спорят о том, стоит ли делать ставку на SaaS-агента, систему, построенную системным интегратором, или на собственную разработку.</p> <p>В основе всего этого лежит налог доверия. Каждое автономное действие должно быть зафиксировано и обосновано аудитором, и сейчас эта стоимость слишком высока. Даже руководители это чувствуют. Банк Нью-Йорка находится на самом переднем крае как регулируемое предприятие, и он до сих пор не в полной мере ощутил на себе потенциал агентных систем. Но у него есть то, чего нет у большинства. Его сотрудники готовы управлять высокоавтономными агентами в условиях жесткого регулирования бизнеса. Эта готовность бесценна.</p> <h3>Управление рисками — это реальное ограничение</h3> <p>Это та часть, которую недооценивают руководители. Автономные системы, которые действуют непрерывно, преодолевая границы, которые человек не может отслеживать в режиме реального времени, одновременно многообещающи и опасны. В исследовании Forrester «Security Survey 2026» 49% лиц, принимающих решения в области безопасности, назвали агентный ИИ проблемой. Эти угрозы носят новый характер, а не только масштаб. Агенты могут выдавать себя друг за друга и повышать свои привилегии, потому что идентификация нечеловеческих объектов все еще находится в запутанном состоянии. Их численность растет быстрее, чем кто-либо может за ней уследить, и когда нарушается координация, небольшая ошибка в оценке приводит к сбою.</p> <p>Безопасности нельзя добиться ежеквартальными обзорами. Управление осуществляется с помощью инструментов, работающих параллельно с агентом, при этом идентификация и политики обеспечиваются в виде кода, а не прописаны и рассчитаны на желаемый результат.</p> <h3>Как начать двигаться вперед</h3> <p>Компании, которые опережают конкурентов, — это не те, у кого больше всего агентов. Это те, кто прокладывает путь, по которому будет двигаться поезд. Три шага наиболее важны:</p> <ul> <li><strong> Инвестируйте в оркестровку, прежде чем добавлять агентов.</strong> Общие реестры и схемы передачи задач имеют решающее значение для того, чтобы агенты и традиционные системы работали как единое целое.</li> <li><strong> Перепроектируйте работу, а не только инструменты. </strong>Агенты, прикрученные к устаревшим рабочим процессам, работающим в ручном темпе, обеспечивают экономию задач, а не кардинальные изменения. Выберите несколько рабочих процессов с высокой степенью сложности и перестройте роли и утверждения вокруг автономности.</li> <li><strong> Рассматривайте каждого агента как управляемую идентичность.</strong> Предоставьте ему уникальные учетные данные, принцип наименьших привилегий, полное логирование и именованного владельца, который управляет его жизненным циклом. Никакой бесконтрольной автономности.</li> </ul> <p>Затем масштабируйте поэтапно. Начните с ограниченных задач с путями утверждения и отката. Расширяйте автономию только тогда, когда это оправдано надлежащими средствами управления.</p> <p>Поезд движется, и быстро. Теперь вопрос только в том, направляется ли он туда, куда вы хотите.</p> Три четверти руководителей предприятий сообщают, что они внедряют агентный искусственный интеллект. Но лишь небольшое … article https://www.itweek.ru/themes/detail.php?ID=234967 Mon, 08 Jun 2026 08:33:00 +0300 <p>Страхование долго развивалось как отрасль, которая подключается после наступления события: аварии, болезни, повреждения имущества, кибератаки или перерыва в деятельности компании. Логика проста: клиент покупает полис, страховщик оценивает риск, а затем компенсирует ущерб, если страховой случай произошел. Искусственный интеллект постепенно меняет эту модель. Страховая компания становится не только плательщиком по факту убытка, но и начинает быть участником системы прогнозирования, профилактики и раннего реагирования.</p> <p>Этот сдвиг уже заметен на международном рынке. <a href="https://www.mckinsey.com/industries/financial-services/our-insights/the-future-of-ai-in-the-insurance-industry">McKinsey</a> отмечает, что ИИ применяется почти во всех ключевых зонах страхового бизнеса: продажах, персонализации, андеррайтинге, урегулировании убытков, клиентском сервисе и бэк-офисе. По оценке <a href="https://www.eiopa.europa.eu/publications/traditional-ai-generative-ai-implications-insurance-sector_en">EIOPA</a>, в Европе технологии ИИ уже используют 50% страховщиков non-life-сегмента и 24% страховщиков life-сегмента. Отечественный рынок — в той же практической повестке: <a href="https://www.cbr.ru/Content/Document/File/185193/Consultation_Paper_20112025.pdf">по данным опроса Банка России 2025 года</a>, 60% страховщиков сообщили об использовании ИИ на постоянной основе. Поэтому вопрос для отрасли постепенно смещается с «нужен ли ИИ» к «где он реально меняет экономику риска, сервиса и урегулирования».</p> <h3>Андеррайтинг становится точнее</h3> <p>Одна из первых зон, где ИИ дает заметный эффект, — оценка риска. В классической модели андеррайтер работает с заявкой, историей клиента, документами, правилами и экспертными допущениями. Сегодня к этому добавляются модели, которые могут анализировать большие массивы структурированных и неструктурированных данных: документы, изображения, историю убытков, внешние факторы, поведенческие признаки.</p> <p>По данным <a href="https://www.capgemini.com/news/press-releases/insurance-leaders-optimistic-about-ais-impact-on-underwriting-quality-and-fraud-reduction-but-underwriter-confidence-lags/">Capgemini</a>, 62% руководителей страховых компаний считают, что искусственный интеллект и машинное обучение повышают качество андеррайтинга и помогают снижать мошенничество. Однако только 43% андеррайтеров регулярно доверяют автоматическим рекомендациям predictive analytics. Это важная метрика: потенциал уже очевиден, но страхование все еще остается отраслью, где решение должно быть объяснимым, проверяемым и профессионально интерпретируемым.</p> <p>При этом отмечу, что сам ИИ не отменяет роль андеррайтера, а меняет ее. Специалист меньше времени тратит на сбор и первичную обработку информации и больше — на оценку сложных случаев, исключений и нестандартных рисков. <a href="https://www.munichre.com/ca-life/en/perspectives/2024/large-language-models-in-underwriting-and-claims.html">Munich Re</a> отдельно отмечает потенциал больших языковых моделей в работе с неструктурированными данными: медицинскими заключениями, описаниями убытков, договорами, правилами страхования и внутренними регламентами.</p> <h3>Урегулирование убытков ускоряется</h3> <p>Вторая большая зона трансформации — управление урегулированием страховых случаев (claims management). Для клиента это — один из важнейших и самых щепетильных моментов: именно здесь страховая компания либо подтверждает свою ценность, либо разрушает доверие.</p> <p>ИИ помогает автоматизировать первичную обработку заявлений, распознавать документы, классифицировать обращения, проверять комплектность пакета и извлекать данные из актов, счетов, справок, фотографий и медицинских заключений. <a href="https://www.bcg.com/publications/2023/the-future-of-insurance-claims">BCG</a> пишет, что генеративный ИИ может применяться для оценки повреждений, выявления мошенничества, обработки обращений, поддержки сотрудников и получения аналитических выводов на основе данных.</p> <p><a href="https://www.cnews.ru/news/line/2024-10-17_alfastrahovanie_ureguliruet">АльфаСтрахование сообщает</a>, что ИИ помогает закрывать значительную часть обращений по ОСАГО без ручной обработки: около 60% таких кейсов компания урегулирует автоматически, а в Московском регионе этот показатель приближается к 70%.</p> <h3>Антифрод становится технологической гонкой</h3> <p>Страховое мошенничество всегда было одной из ключевых проблем отрасли, но генеративный ИИ сделал ее сложнее. С одной стороны, алгоритмы помогают страховщикам выявлять подозрительные сценарии: повторяющиеся паттерны убытков, связи между участниками, аномальные суммы, несоответствия в документах и изображениях. С другой — те же технологии дают злоумышленникам новые инструменты.</p> <p><a href="https://www.swissre.com/institute/research/sonar/sonar2025/how-deepfakes-disinformation-ai-amplify-insurance-fraud.html">Swiss Re</a> указывает, что дипфейки, сгенерированные документы и дезинформация усиливают риски страхового мошенничества и повышают нагрузку на операционные процессы страховщиков. Поэтому антифрод постепенно превращается из проверки отдельного кейса в непрерывный анализ контекста: истории обращений, поведения клиента, цифровых следов, документов, изображений и связей между событиями.</p> <h3>Страхование становится персональным</h3> <p>ИИ меняет и сам страховой продукт. Раньше клиент чаще выбирал из нескольких стандартных программ. Теперь страховщик может точнее учитывать ситуацию человека или компании — от профиля риска и истории обращения до состояния объекта и особенностей бизнеса.</p> <p><a href="https://insuranceblog.accenture.com/guide-generative-ai-insurance">Accenture</a> видит один из главных потенциалов генеративного ИИ в андеррайтинге, дистрибуции и урегулировании. Компания также отмечает, что значительная часть времени андеррайтеров уходит на административные задачи, которые можно автоматизировать или усилить с помощью ИИ. Для клиента это может означать более точный тариф, более релевантное покрытие, быстрый сервис и профилактические рекомендации.</p> <p>Именно здесь страхование начинает смещаться от модели «постфактум» к профилактической. В автостраховании это может быть анализ стиля вождения и рекомендации по снижению аварийности. В ДМС — более точная маршрутизация к специалистам и управление медицинскими программами. В корпоративном страховании — анализ структуры убытков и рекомендации по снижению операционных рисков.</p> <h3>ИИ меняет работу сотрудников</h3> <p>Отдельный пласт изменений связан с «внутренней кухней» страховых компаний. ИИ-ассистенты могут помогать операторам, агентам, андеррайтерам и специалистам по убыткам: искать информацию в базе знаний, готовить ответы, суммировать документы, подсказывать следующий шаг и проверять комплектность данных.</p> <p>Но масштабирование таких решений упирается не только в технологию. <a href="https://www.deloitte.com/us/en/insights/industry/financial-services/scaling-gen-ai-insurance.html">Deloitte</a>, опросив 200 руководителей страховых компаний в США, отмечает, что 76% уже внедрили генеративный ИИ в одной или нескольких функциях. При этом среди барьеров остаются качество данных, устаревшая ИТ-инфраструктура, управление рисками и недостаточная связка между бизнесом и технологиями.</p> <p>Подобные выводы мы фиксировали и в собственном исследовании экономики страховых процессов: 83,3% респондентов назвали сбор и интеграцию данных из информационных систем одной из основных сложностей внедрения аналитических инструментов. Это важный барьер и для ИИ-проектов: ассистенту недостаточно просто «подключиться» к рабочему месту сотрудника, ему нужны качественные данные, понятная логика процесса и корректно связанные системы.</p> <p>Почему это важно в страховании? Здесь много регламентов, исключений, документов и чувствительных клиентских ситуаций. Роль сотрудника становится более экспертной.</p> <h3>Почему страхованию нужен осторожный ИИ</h3> <p>Страхование — щепетильная отрасль. Ошибка алгоритма может повлиять на стоимость полиса, доступность продукта, решение по выплате или качество клиентского сервиса. Поэтому вместе с ИИ растут требования к управлению моделями.</p> <p>Поэтому главный вопрос для страховщика сегодня не только «где внедрить ИИ?», но и «как подготовить бизнес к этому шагу?». Без качественных данных, понятных процессов, предварительной аналитики и прозрачной логики технология может не ускорить развитие компании, а масштабировать ее старые ошибки.</p> <p>Здесь особенно важна предварительная диагностика: прежде чем автоматизировать процесс с помощью ИИ, нужно понять, как он фактически выполняется, где возникают отклонения, задержки и ручные доработки. <a href="https://infomaximum.ru/blog/process-task-mining-v-strvakhovanii?ysclid=mpf8c5r0oz440837045">В нашем исследовании 100% респондентов </a>указали, что используют аналитику бизнес-операций (Task Mining) для оценки себестоимости операций и выявления потенциала автоматизации, а 75% — для выявления операций с потенциалом роботизации и внедрения ИИ. Это показывает, что для страхового рынка предварительная аналитика становится способом выбрать участки, где ИИ действительно даст измеримый эффект.</p> <p>Страхование строится на доверии: клиент должен понимать, что его риск оценен справедливо, обращение рассмотрено корректно, а решение можно объяснить. Поэтому наиболее устойчивый эффект получат не те компании, которые быстрее всех внедрят отдельные ИИ-инструменты, а те, кто сумеет встроить их в систему управления данными, процессами и ответственностью.</p> <p>#IMAGE_234968#</p> Страхование долго развивалось как отрасль, которая подключается после наступления события: аварии, болезни, повреждения … article Александр Бочкин, генеральный директор “Инфомаксимум” 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 Константин Деревсков, генеральный директор ООО “Старт Качества”