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=235806 Fri, 23 Oct 2026 13:52:02 +0300 <p>Компания Security Vision сообщила о выходе новой версии продукта CMDB Configuration Management Database — база данных управления конфигурациями со встроенным контролем ИТ-изменений. Продукт Security Vision CMDB объединяет централизованное управление конфигурационными единицами и процессами ИТ-изменений. Решение автоматизирует сбор данных об ИТ-ландшафте и обеспечивает системный контроль технических изменений, сохраняя непрерывность и доступность критических бизнес-сервисов. Продукт ориентирован на enterprise-сегмент и помогает перейти от разрозненных списков ИТ-компонентов к управляемой ресурсно-сервисной модели.</p> <p>В распределенной enterprise-среде обновления систем, обслуживание серверов и сетевые перенастройки нередко согласуются без наглядного понимания сквозных взаимосвязей. Накладки в расписании, пересечение параллельных задач смежных команд и нарушение регламентных окон обслуживания могут приводить к каскадным сбоям зависимых систем и незапланированным простоям бизнес-сервисов. Для бизнеса это означает задержки в выполнении операций и дополнительные расходы на восстановление — даже если сами технические работы были плановыми.</p> <p>Продукт Security Vision CMDB связывает актуальную цифровую модель инфраструктуры, процессные механизмы контроля и автоматизацию в единый контур. Каждое планируемое изменение сопоставляется с ресурсно-сервисной моделью на интерактивном графе зависимостей. Платформа определяет потенциальный масштаб воздействия и автоматически включает в маршрут авторизации непосредственных владельцев затронутых бизнес-сервисов. Таким образом, в согласовании участвуют руководители, отвечающие за работу затронутых сервисов. Они могут заранее учесть последствия для своих подразделений и определить приемлемое время проведения работ.</p> <p>Интерактивный граф визуализирует топологию ИТ-среды от компонентов инфраструктуры (серверы, сеть, СХД) до баз данных, прикладного ПО и конечных бизнес-сервисов с указанием их критичности и владельцев.</p> <p>Встроенный модуль автоматически определяет затрагиваемые системы при планировании изменений, сопоставляет графики работ смежных подразделений для исключения конфликтов и контролирует соблюдение регламентных окон обслуживания.</p> <p>В платформе реализованы готовые процессы, которые позволяют регулярно по заданному расписанию выполнять поиск и обнаружение новых активов в ИТ-ландшафте, проводить их идентификацию, инвентаризацию, собирать сведения о конфигурации, а также сопоставлять проведенные плановые и фактические изменения. Данные объединяются из сетевых источников, гипервизоров и систем мониторинга через готовые коннекторы, а встроенные механизмы нормализации устраняют дубликаты и формируют эталонную карточку каждого объекта с ведением прозрачной истории модификаций.</p> <p>Это сокращает объем ручной сверки данных и помогает принимать решения на основании фактического состояния инфраструктуры Наличие объективной цифровой модели позволяет согласовывать изменения с точным пониманием реальной конфигурации систем.</p> <p>При возникновении сбоев сервисные службы получают мгновенный доступ к истории недавних технических изменений по всей цепочке зависимостей аварийного сервиса. Это связывает эксплуатационные инциденты с реальными вмешательствами в инфраструктуру, существенно упрощая поиск первопричин и ускоряя восстановление услуг.</p> <p>В продукте предусмотрены готовые процессы для Стандартных (типовые, предварительно авторизованные), Нормальных (полный цикл технической экспертизы и оценки рисков) и Экстренных изменений (ускоренный маршрут для устранения аварий).</p> <p>No-Code кастомизация: возможность без написания программного кода создавать собственные типы изменений и гибко настраивать политики согласования с учетом параметров запроса, типа конфигурационной единицы или критичности затронутого сервиса. Встроенные конструкторы позволяют настраивать интеграции, реализовывать автоматизированный сбор данных и взаимодействие с любыми системами внутри корпоративного ИТ-ландшафта, адаптировать процессы под внутренние регламенты и формировать произвольные форматы отчетности, принятые в организации. Набор конструкторов, встроенных в платформу, позволяет в режиме No-Code добавлять новые действия и самостоятельно корректировать все встроенные процессы и алгоритмы.</p> <p>Для ИТ-директоров продукт обеспечивает управляемость сложной инфраструктуры и помогает ускорить выпуск изменений без конфликтов между командами. Для руководителей информационной безопасности — обеспечивает контроль безопасности любых изменений в инфраструктуре и позволяет мгновенно оценивать периметр влияния инцидентов на связанные системы. Для технических директоров — обеспечивает предсказуемость регламентных процедур и защищает инфраструктуру от непредвиденных сбоев на основе точной карты взаимосвязей.</p> <p>Продукт продолжает развитие экосистемы решений Security Vision Enterprise. Единая база конфигураций и регламентированный процесс согласования изменений помогают оптимизировать эксплуатационные расходы и гарантировать непрерывность бизнес-процессов. Благодаря открытому API и встроенному конструктору интеграций продукт бесшовно интегрируется в существующий ландшафт заказчика, включая внешние Service Desk-системы сторонних разработчиков.</p> Компания Security Vision сообщила о выходе новой версии продукта CMDB Configuration Management Database — база данных … message https://www.itweek.ru/themes/detail.php?ID=235805 Fri, 23 Oct 2026 12:41:30 +0300 <p>Рынок коммерческих центров обработки данных в Московском регионе проходит этап структурной перестройки. Устойчивый спрос на размещение оборудования сталкивается с ограниченной доступностью электрических мощностей, которая сдерживает строительство новых объектов. В этих условиях определяющим фактором развития становится не только наличие площадки, но и возможность обеспечить ее надежным энергоснабжением. Девелоперы и операторы пересматривают энергетические решения, а часть спроса постепенно перераспределяется в регионы.</p> <p>По оценке аналитиков CORE.XP, среднегодовая потребность в мощности ЦОД в Москве и Московской области составляет около 70 МВт, тогда как доступное предложение остается крайне ограниченным. В 2026 году ряд новых проектов получил отказы в заключении договоров на технологическое присоединение: свободные мощности либо уже используются, либо зарезервированы крупными участниками рынка на <nobr>2026–2028 годы.</nobr> Это ограничивает реализацию новых крупных объектов и увеличивает неопределенность сроков их запуска.</p> <p>При этом российский рынок коммерческих ЦОД продолжает расти. Согласно данным CORE.XP и iKS-Consulting, максимальная электрическая мощность объектов в 2025 году составила 877 МВт. По прогнозу, к 2027 году показатель достигнет 1 048 МВт, увеличившись примерно на 10% относительно уровня 2026 года. Однако рост совокупной мощности не устраняет локальный дефицит: возможность размещения оборудования зависит от географии доступного предложения и сроков ввода конкретных площадок.</p> <p>Ограничения энергоснабжения усиливаются высокой стоимостью заемного финансирования и ростом капитальных затрат. По данным Invest Projects за сентябрь 2026 года, в России заморожено 38 проектов ЦОД с общим объемом заявленных инвестиций 188 млрд рублей. Аналитики CORE.XP выделяют три основных фактора приостановки проектов: дорогой кредит, ограниченный доступ к электрической мощности и сложность масштабирования без ухудшения экономики объекта. Для коммерческих центров обработки данных такая комбинация факторов особенно критична: рост инвестиций неизбежно отодвигает срок выхода на доход.</p> <p>Дисбаланс спроса и предложения отражается в стоимости услуг. По оценке CORE.XP, в отдельных случаях рост стоимости размещения оборудования в расчете на 1 кВт за период <nobr>2025–2026</nobr> годов мог достигать 40%. Этот показатель не характеризует весь рынок, но демонстрирует ценовое давление в условиях ограниченной доступности мощностей. При этом предложение также расширяется: по данным iKS-Consulting, среднегодовой прирост количества стоек в <nobr>2016–2026</nobr> годах составил 11,4%. Таким образом, увеличение числа стоек само по себе не компенсирует ограничения по энергоснабжению и рост себестоимости новых объектов.</p> <p>Одним из ключевых направлений адаптации становится собственная генерация. Большинство игроков, по оценке CORE.XP, прорабатывают возможность использования газопоршневых и газотурбинных установок либо оценивают альтернативные схемы электроснабжения. Собственная генерация требует более высоких первоначальных вложений, однако позволяет снизить зависимость от доступности сетевой мощности. Более низкие эксплуатационные расходы в перспективе могут частично компенсировать дополнительные капитальные затраты, но итоговая экономика зависит от условий конкретной площадки.</p> <p>Для Московского региона газовая генерация становится альтернативой длительному ожиданию технологического присоединения. Возможность реализации такой модели определяется доступом к газопроводу, стоимостью топлива и оборудования, схемой резервирования, а также экологическими и эксплуатационными ограничениями. Дополнительное преимущество газопоршневых и газотурбинных решений — возможность поэтапного ввода мощности по мере увеличения вычислительной нагрузки.</p> <p>Переход на собственное энергоснабжение, однако, требует времени на проектирование, согласования и строительство. Поэтому, по прогнозу аналитиков CORE.XP, часть объектов, ранее заявленных к вводу в <nobr>2028–2029 годах,</nobr> может быть запущена позднее. Это будет поддерживать дефицит качественного предложения в Московском регионе и инвестиционную привлекательность проектов, для которых вопрос энергоснабжения уже решен.</p> <p>Параллельно расширяется предложение коммерческих ЦОД за пределами столичного региона. Новые площадки появляются в Санкт-Петербурге, Екатеринбурге, Новосибирске и Красноярске. Региональные объекты могут обеспечивать более быстрое размещение оборудования и доступ к мощности без ограничений, характерных для Москвы и Московской области. При этом выбор локации зависит не только от энергетических ресурсов, но и от качества каналов связи, требований к задержке передачи данных и близости к потребителям.</p> <p>«Рынок ЦОД переходит от выбора площадки к выбору энергетической модели. Высокий спрос сам по себе уже не гарантирует реализацию проекта: критическое значение имеют подтвержденный доступ к мощности, сроки подключения и возможность масштабирования. Для Московского региона собственная генерация становится одним из способов преодолеть ограничения, но требует более сложной оценки капитальных и эксплуатационных затрат. Преимущество будут получать проекты с предсказуемыми сроками запуска и надежным энергоснабжением, тогда как часть спроса продолжит перераспределяться на региональные площадки», — прокомментировал Антон Алябьев, старший директор, руководитель отдела складской и индустриальной недвижимости CORE.XP.</p> <p>Таким образом, дефицит электрической мощности меняет не только сроки ввода ЦОД, но и географию, структуру затрат и критерии инвестиционного отбора проектов. На первый план выходит энергообеспеченность площадки: именно она определяет возможность удовлетворить спрос и сохранить устойчивую экономику объекта.</p> Рынок коммерческих центров обработки данных в Московском регионе проходит этап структурной перестройки. Устойчивый спрос … message https://www.itweek.ru/themes/detail.php?ID=235803 Fri, 23 Oct 2026 10:51:05 +0300 <p><em>Координация работы роботов и автономных систем станет ключевым фактором для полноценного внедрения физического ИИ (Physical AI), однако пока неясно, как скажется отсутствие совместимости на его распространении, отмечают опрошенные порталом </em><em>AI</em> <em>Business</em> <em>эксперты.</em></p> <p>Технологии физического ИИ все активнее внедряются на заводах, складах и других производственных объектах. Gartner включила это направление в список главных стратегических технологических трендов-2026. Тем не менее, восприятие физического ИИ как единой технологической категории может помешать компаниям извлечь из него максимальную пользу. По мнению Gartner, бизнесу следует сместить фокус с отдельных устройств на системы, которые координируют их работу, — область, которая на данный момент развита недостаточно.</p> <p>«Поставщики робототехники стремятся позиционировать свои предложения как комплексные решения, зачастую представляя свои продукты как автономные единицы, которые можно легко интегрировать в существующие рабочие процессы. На деле это совсем не так», — отмечает аналитик Gartner Билл Рэй.</p> <p>По его словам, существующие платформы оркестрации обладают ограниченным функционалом и ориентированы преимущественно на те сферы, где уже взаимодействуют целые парки роботов — например, на складские комплексы.</p> <p>«Сейчас мы наблюдаем лишь разрозненные попытки решения этой задачи, однако существует огромный нереализованный потенциал для создания полноценных систем оркестрации. По мере роста числа роботов и других систем физического ИИ потребность в них будет только увеличиваться», — считает Рэй.</p> <h3>Выход за рамки отдельных роботов</h3> <p>Оркестрация подразумевает наличие программного уровня, который связывает системы управления парками роботов друг с другом, а также с общей инфраструктурой предприятия или здания.</p> <p>Как отмечает Рэй, поставщики робототехники продолжат предлагать собственное ПО для управления парками машин, в то время как уровень оркестрации будет координировать задачи между роботами, не взаимодействуя напрямую с каждым отдельным устройством.</p> <p>В качестве примера такого подхода он приводит решение Physical AI Orchestrator компании Accenture. Ожидается, что на рынок выйдут и другие провайдеры с платформами оркестрации, адаптированными для конкретных отраслей.</p> <p>Впрочем, Ян Липхардт, доцент кафедры биоинженерии Стэнфордского университета, участвующий также в разработке ПО для робототехники в компании OpenMind, подчеркивает, что обеспечение надежного взаимодействия между роботами остается сложнейшей задачей. «Отсутствие совместимости компьютеров, людей и роботов — это серьезный пробел, — говорит он. — В промышленных условиях добиться того, чтобы разные роботы работали вместе надежно, бывает очень сложно, дорого и долго».</p> <p>По его словам, в ряде случаев на то, чтобы заставить роботов от двух разных поставщиков скоординировано выполнять задачи, могут уйти месяцы или даже целый год. Это открывает возможности для технологий, упрощающих интеграцию, хотя эксперт предостерегает: отрасль, возможно, еще не готова к тому, чтобы оркестрация стала ключевым аспектом при любом внедрении робототехники.</p> <p>«Добиться эффективной работы одного робота — непростая задача; заставить слаженно функционировать роботов разных типов — еще сложнее; а если речь идет о роботах от разных производителей, то задача становится и вовсе крайне трудной», — отмечает он.</p> <p>Липхардт говорит, что существует значительный интерес к протоколам, призванным решить эти проблемы, однако сама задача пока несколько опережает текущие рыночные реалии. «В среднесрочной и долгосрочной перспективе — скажем, к середине следующего года — это направление, вероятно, приобретет исключительную важность», — добавляет он.</p> <h3>Отсутствие интероперабельности — не единственное препятствие</h3> <p>Не все аналитики считают отсутствие интероперабельности главным барьером на пути внедрения физического ИИ.</p> <p>Марк Беккью, аналитик компании Omdia, утверждает, что бизнес чаще сталкивается с ограничениями существующей инфраструктуры и нехваткой профильных компетенций, чем с отсутствием стандартов совместимости. «Я не думаю, что стандартизация совместимости станет основным драйвером внедрения. Ускорить этот процесс поможет использование инструментов, навыков и моделей с открытым исходным кодом — подход, который активно продвигает Nvidia», — считает он.</p> <p>По его словам, главная проблема заключается в недостаточной гибкости унаследованных систем для интеграции новейших технологий и подходов. Вторая по значимости сложность — несоответствие квалификации персонала: отсутствие в штате организации специалистов, обладающие знаниями, необходимыми для работы с системами конкретных поставщиков.</p> <p>Иными словами, даже при наличии инструментов оркестрации компаниям все равно необходимы соответствующие инфраструктура, навыки и операционные процессы для успешного внедрения физического ИИ.</p> <p>Еще одна, более насущная задача — интеграция автономных систем в уже существующую рабочую среду. Внедрение роботов и автономных транспортных средств может потребовать изменения планировки помещений и рабочих процессов — особенно в тех случаях, когда машины должны безопасно функционировать в одном пространстве с людьми. «Если возникает необходимость изолировать роботов и автономные транспортные средства от людей, это может требовать реорганизации пространства: нужно продумать, как сохранить текущие рабочие процессы, одновременно изменив маршруты передвижения персонала, — отмечает Рэй. — Стоимость подобных преобразований очень легко недооценить».</p> <p>Компаниям также необходимо определить, как распределить задачи между людьми и машинами, вместо того чтобы исходить из предположения, что автоматизировать нужно абсолютно всё.</p> <p>Иными словами, интеграция технологий в текущие рабочие процессы не менее важна, чем сами технологии; неверный выбор может привести к тому, что компания окажется в числе отстающих.</p> <p>«Уровень оркестрации станет критически важным элементом инфраструктуры — сменить поставщика будет крайне сложно, а с каждой новой интеграцией — всё сложнее, поэтому важно принять верное решение как можно раньше», — говорит Рэй.</p> <h3>Взгляд в будущее</h3> <p>По мере расширения внедрения физического ИИ понимание того, как роботы, корпоративные системы и человеческие рабочие процессы взаимодействуют друг с другом, позволит компаниям более эффективно масштабировать свои технологии.</p> <p>«Первый шаг — и это касается внедрения любых технических инноваций — заключается в разработке комплексного бизнес-обоснования, — говорит Беккью. — Спросите себя: какую проблему мы пытаемся решить? Каковы единовременные и текущие затраты? Каков ожидаемый возврат инвестиций (ROI) — включая расчеты чистой приведенной стоимости (NPV), внутренней нормы доходности (IRR) или срока окупаемости?».</p> <p>Липхардт предлагает более оперативный подход: компаниям следует начать экспериментировать с физическим ИИ уже сейчас, даже если вопросы совместимости, форматов данных и зависимости от конкретного поставщика пока остаются открытыми. «Моя рекомендация сегодня, в конце 2026 г., такова: чем бы вы ни занимались — производством, перемещением, транспортировкой, склеиванием, шитьем или сборкой — пробуйте различные решения, причем сделать это нужно было еще вчера, — говорит он. — На данном этапе на ваших предприятиях уже должны быть запущены пилотные проекты, чтобы вы были максимально осведомлены о технологии, которая развивается невероятно быстро».</p> Координация работы роботов и автономных систем станет ключевым фактором для полноценного внедрения физического ИИ … article https://www.itweek.ru/themes/detail.php?ID=235799 Fri, 23 Oct 2026 09:56:18 +0300 <p>Промышленная автоматизация долгое время строилась по принципу разделения уровней. На полевом уровне датчики преобразовывали физическую величину в унифицированный сигнал. Контроллеры обрабатывали данные и принимали решения. Системы управления занимались координацией и аналитикой. Такая архитектура была оправдана, когда вычислительные ресурсы были дорогими и централизованными, а от диагностики требовалось лишь зафиксировать отказ.</p> <p>Сегодня требования изменились. Industry 4.0 и IIoT предполагают сквозную цифровизацию: данные должны собираться на нижнем уровне и без потерь доходить до аналитических платформ. Но на практике многие предприятия сталкиваются с парадоксом. Внедрено множество цифровых систем, но единого информационного пространства нет, и главная причина тут архитектурная. Разрывы возникают не на уровне MES или ERP, а на стыке между датчиком и системой сбора данных.</p> <p>Традиционная цепочка «датчик → модуль ввода-вывода → контроллер → SCADA → аналитика» содержит несколько точек преобразования. На каждом переходе данные не только меняются, но и теряют часть информации. Диагностические регистры датчика, параметры качества линии связи, статистика наработки недоступны либо доступны фрагментарно и с задержкой. В результате верхние уровни работают с упрощённой картиной, что снижает достоверность предиктивной аналитики и цифровых двойников.</p> <h3> Ограничения традиционных интерфейсов</h3> <p>Чтобы понять, почему цифровой полевой уровень стал необходимостью, посмотрим на эволюцию интерфейсов.</p> <p>Аналоговая токовая петля 4...20 мА долгое время была основой измерений. Она проста, помехоустойчива и хорошо защищена от электромагнитных помех. Но её информационная ёмкость ограничена одним числом. Диагностики как отдельного потока данных нет. Верхний уровень видит только ток и не может отличить реальное изменение параметра от неисправности датчика. Питание по той же паре возможно, но мощность ограничена. При большом числе точек растёт стоимость кабельной инфраструктуры, а для интеграции с ИТ-системами нужны дополнительные преобразователи.</p> <p>HART добавил цифровой канал поверх аналоговой петли. Но скорость обмена, равная 1,2 кбит/с, слишком мала для полноценной диагностики в реальном времени. Мультиплексирование позволяет опрашивать несколько приборов, но увеличивает время цикла. HART — протокол, скорее, для настройки и калибровки, чем для потоковой передачи данных о состоянии прибора.</p> <p>RS-485 с Modbus даёт полноценный обмен, но работает по опросной модели. Чем больше узлов на шине, тем больше время цикла. Нужно отдельное питание, критичны топология и согласование линии. Для интеграции с ИТ-инфраструктурой требуются шлюзы, а это дополнительные уровни преобразования и потенциальные точки отказа.</p> <p>Классический Ethernet быстр и имеет нативную IP-адресацию. Но на полевом уровне он ограничен дистанцией 100 метров и четырьмя парами проводов. На распределённых объектах приходится строить промежуточную инфраструктуру: коммутаторы, медиаконвертеры, шкафы, что увеличивает капитальные и эксплуатационные затраты.</p> <p>Вывод прост. Традиционные интерфейсы решали задачи своего времени, но сегодня они ограничивают объём данных, диагностику и сквозную интеграцию. Аналоговая петля и HART не дают нужного количества информации. RS-485 плохо масштабируется и требует шлюзов. Классический Ethernet не подходит для распределённых объектов без промежуточной инфраструктуры.</p> <h3>Сквозной Ethernet по двум проводам</h3> <p>Интерфейс Single Pair Ethernet (SPE) устраняет вышеперечисленные ограничения архитектурно. Технология базируется на стандарте 10BASE-T1L (IEEE 802.3cg-2019) и предлагает передачу данных со скоростью до 10 Мбит/с по одной витой паре, питание устройства по той же паре (PoDL) мощностью до 50 Вт и дальность связи до 1 километра без промежуточных повторителей.</p> <p>Таким образом, SPE делает Ethernet по-настоящему сквозным: от облачного сервера или локальной SCADA до отдельного датчика на дальнем участке трубопровода. Каждый прибор получает собственный IP-адрес и может напрямую поддерживать OPC UA, MQTT, предоставлять веб-интерфейс для настройки и диагностики. Это уже не пассивный источник сигнала, а активный сетевой узел.</p> <p>Переход на SPE — это не замена физического уровня, а изменение архитектурной роли полевого устройства. Датчик перестаёт быть пассивным источником скалярного сигнала и становится активным сетевым узлом, обладающим собственным IP-адресом, вычислительными ресурсами и информационной моделью. SPE-датчик позволяет отслеживать предотказовые состояния: снижение точности чувствительного элемента, рост внутренней температуры, ухудшение изоляции линии, увеличение джиттера, накопление ошибок CRC. Это соответствует концепции RCM (Reliability-Centered Maintenance) и позволяет реализовать стратегию предиктивного обслуживания.</p> <p>#IMAGE_235801#</p> <p>С точки зрения информационной архитектуры SPE устраняет разрыв между OT (Operational Technology) и ИТ. Датчик становится полноценным участником сети TCP/IP, что позволяет интегрировать его в корпоративные системы мониторинга без промежуточных шлюзов. Уменьшается количество уровней преобразования, снижается задержка, повышается достоверность данных.</p> <p>Отмечу, что базовый SPE не обеспечивает искробезопасность, что ограничивает его применение в нефтегазовой, химической и горнодобывающей отраслях. Стандарт Ethernet-APL (Ethernet Advanced Physical Layer) решает эту задачу путём ограничения энергии в линии до безопасного уровня. Технически это реализуется через барьеры искрозащиты и специальные требования к кабельным линиям. Ethernet-APL сохраняет все преимущества SPE: дальность до 1000 метров, скорость 10 Мбит/с, питание по линии, IP-адресацию. Это делает цифровой полевой уровень универсальным для всей промышленности.</p> <h3>Поэтапная модернизация и преодоление цифрового разрыва</h3> <p>Переход на SPE не означает обязательную полную замену действующей АСУ ТП. Для российских предприятий, где одновременно работает оборудование разных поколений, реалистичнее поэтапная модернизация с сохранением совместимости с существующей инфраструктурой. Я рассматриваю цифровую трансформацию как последовательное построение сквозной инфраструктуры данных, где идти нужно снизу вверх.</p> <p>На первом этапе важно обеспечить достоверный автоматизированный сбор параметров. Это могут быть изначально цифровые каналы или оцифровка существующих аналоговых сигналов. Далее сформировать инфраструктуру передачи данных, которая позволит объединять участки и масштабировать систему. Следующий уровень — единая точка сбора, хранения и визуализации: контроллер, SCADA или другая система верхнего уровня. И уже на накопленной качественной информации можно строить предиктивную аналитику, цифровые модели и более сложные сервисы.</p> <p>Такой подход снижает риск цифрового разрыва между крупными и небольшими предприятиями. Размер компании перестаёт быть абсолютным ограничением, потому что различаться будут только масштаб и скорость трансформации. Для крупного предприятия это может быть единая корпоративная программа, для небольшого производства — несколько последовательных проектов с заранее определённым результатом.</p> <p>Принципиально важно, чтобы каждый следующий проект не становился очередным изолированным «островком автоматизации», а развивал общую архитектуру. Именно поэтому при выборе решений важны не только начальная стоимость, но и совместимость с действующей инфраструктурой, открытость интерфейсов и возможность дальнейшего масштабирования.</p> <p>#IMAGE_235800#</p> Промышленная автоматизация долгое время строилась по принципу разделения уровней. На полевом уровне датчики … article Ярослав Лоскутов, менеджер продукта направления “Датчики давления” компании ОВЕН https://www.itweek.ru/themes/detail.php?ID=235796 Fri, 23 Oct 2026 09:47:34 +0300 <p>Еще недавно корпоративный ИИ обсуждали через сценарии: где он заменит ручной труд, как ускорит аналитику, какие процессы можно отдать моделям. Теперь разговор быстро смещается в более приземленную плоскость: где взять вычислительные мощности и сколько они будут стоить через месяц. По данным <a href="https://www.kommersant.ru/doc/8711218">«Коммерсанта»</a>, средняя месячная стоимость выделенной инфраструктуры с GPU-ускорителями для задач ИИ и машинного обучения за пять месяцев 2026 года выросла на 64% год к году и достигла 2,3 млн. рублей. Годом ранее показатель составлял около 1,4 млн. рублей. Уже 33% заказов на GPU-серверы приходится на ИИ и ML, еще значительная часть спроса связана с рендерингом, разработкой и обработкой данных.</p> <p>Это важный сдвиг для рынка. Компании переходят от пилотов к промышленному использованию ИИ, а значит им нужны не абстрактные «мощности», а конкретные GPU-конфигурации: с ускорителями, памятью, питанием, охлаждением, понятной логистикой и сроками поставки. Чем сложнее становятся задачи, тем быстрее растет цена входа. На практике это уже видно в расчетах проектов. Если месяц назад одна высокопроизводительная видеокарта могла стоить условные $50 тыс., то через несколько недель цена способна вырасти до $75 тыс. И это не весь сервер, а только один из его ключевых компонентов. В одной конфигурации таких карт может быть несколько, поэтому итоговый бюджет меняется не на проценты, а сразу на миллионы рублей.</p> <h3>Почему спрос обгоняет поставки</h3> <p>Причина не только в том, что компаний, которые хотят использовать ИИ, стало больше. Сильно изменился сам характер задач. Раньше многие проекты оставались на уровне тестов: проверить гипотезу, обучить небольшую модель, запустить пилот на ограниченном наборе данных. Теперь бизнес чаще приходит к промышленным сценариям, где модель должна работать стабильно, быстро обрабатывать большие объемы данных и выдерживать постоянную нагрузку.</p> <p>Для таких задач обычной серверной инфраструктуры уже недостаточно. Нужны GPU-серверы с мощными ускорителями, большим объемом видеопамяти, быстрым обменом данными между картами, правильным охлаждением и запасом по электропитанию. Чем тяжелее модель и чем больше данных проходит через систему, тем выше требования к конфигурации.</p> <p>Здесь и появляется узкое место. GPU-ускорители нужны всем одновременно: облачным провайдерам, крупным промышленным компаниям, банкам, разработчикам ИИ-сервисов, научным центрам, производственным предприятиям. Спрос растет глобально, а число производителей таких компонентов ограничено. Быстро нарастить выпуск нельзя: это сложное производство, завязанное на передовые техпроцессы, память, платы, цепочки поставок и сборку.</p> <p>Поэтому рынок GPU-серверов отличается от обычной закупки оборудования. Компания покупает не просто сервер, который можно быстро заменить аналогом. Она покупает дефицитный вычислительный ресурс, вокруг которого затем строится вся ИИ-инфраструктура: обучение, дообучение, запуск моделей, хранение данных, сеть, питание и охлаждение. Чем позже начинается проектирование такой архитектуры, тем выше риск, что нужная конфигурация станет дороже или уйдет в более длинные сроки поставки.</p> <h3>Почему GPU-серверы дорожают быстрее обычного оборудования</h3> <p>У GPU-серверов другая экономика. В обычном сервере стоимость распределена между процессором, памятью, дисками, платой, корпусом, блоками питания. В сервере под ИИ большую часть цены могут формировать ускорители. Одна карта стоит как отдельный сервер, а в рабочей конфигурации таких карт может быть несколько.</p> <p>Поэтому рост цены на один компонент сразу меняет бюджет всего проекта. Если видеокарта за месяц дорожает с $50 тыс. до $75 тыс., компания получает не небольшую корректировку сметы, а новый финансовый расчет. Для конфигурации на четыре или восемь ускорителей разница становится слишком заметной, чтобы ее можно было закрыть внутри прежнего бюджета.</p> <p>Есть еще одна неприятная деталь: коммерческое предложение в таких проектах быстро устаревает. Пока компания согласует закупку, уточняет архитектуру, проверяет лимиты и проходит внутренние процедуры, цена может измениться. Иногда меняется и срок поставки, потому что нужная партия уже ушла другому покупателю или поставщик пересобрал условия.</p> <p>На этом фоне привычная логика «подождем, рынок остынет» работает плохо. GPU-ускорители дорожают не из-за разового всплеска интереса, а из-за одновременного давления с нескольких сторон: промышленное внедрение ИИ, рост облаков, дефицит производственных мощностей, подорожание памяти и более сложная логистика. Пока эти факторы сохраняются, ждать резкого отката цен рискованно.</p> <h3>Кому GPU-мощности нужны в первую очередь</h3> <p>Первыми дефицит чувствуют компании, у которых ИИ уже вышел за рамки эксперимента.</p> <p>Это банки, промышленные предприятия, телеком, ритейл, разработчики ИИ-сервисов, научные и инженерные центры. Им нужны мощности не для демонстрации возможностей модели, а для рабочих процессов: анализа больших массивов данных, компьютерного зрения, прогнозирования, обработки документов, инженерных расчетов, цифровых двойников, контроля качества на производстве. В таких сценариях система должна работать регулярно, с понятной скоростью и предсказуемым результатом.</p> <p>Отдельная история, крупные инфраструктурные и промышленные проекты. Там вычисления нужны еще до запуска объекта: рассчитать конструкцию, смоделировать нагрузки, проверить варианты проектных решений, обработать данные с датчиков и геоинформационных систем. Чем сложнее объект, тем выше требования к вычислительной базе.</p> <p>Есть и регуляторный слой. Если компания работает с чувствительными данными, КИИ или государственными проектами, ей не всегда подходит внешняя инфраструктура. Часть нагрузок приходится держать в собственном контуре или в среде, где понятны юрисдикция, требования к хранению данных и ответственность за доступ.</p> <p>Поэтому спрос на GPU-серверы растет не как модная закупка «под ИИ». Он растет из практической потребности: бизнес хочет запускать модели в работу, а для этого ему нужна инфраструктура, которую нельзя заменить презентацией, пилотом или обещанием «докупить позже».</p> <h3>Свой контур или аренда: где запускать нагрузку</h3> <p>Когда GPU-мощности становятся частью рабочих процесса, следующий вопрос возникает почти сразу: где все это размещать. Купить собственный сервер, арендовать выделенную конфигурацию или уйти в облако?</p> <p>Для пилотов облако выглядит естественным первым шагом. Компания может быстро проверить гипотезу, понять требования модели к видеопамяти, оценить скорость обработки данных и не покупать дорогое оборудование до того, как сценарий доказал пользу. Это удобно, когда нагрузка нерегулярная: сегодня нужно обучить модель или протестировать прототип, а завтра вычисления почти не используются.</p> <p>Но по мере взросления проекта логика меняется. Если модель работает постоянно, обрабатывает большие объемы данных и встроена в производственный или клиентский процесс, аренда перестает быть просто удобной. Она становится регулярной статьей расходов, причем с теми же рыночными рисками: стоимость GPU-мощностей растет, доступные конфигурации ограничены, а тяжелые ресурсы могут быть заняты.</p> <p>Собственный контур чаще выбирают там, где важны предсказуемость и контроль. Например, если компания работает с чувствительными данными, промышленными системами, КИИ, внутренними документами, инженерными расчетами или клиентской информацией. В таких случаях вопрос не сводится к цене сервера. Важно понимать, где находятся данные, кто имеет доступ к инфраструктуре, как устроены резервирование, обслуживание, обновления и защита.</p> <p>При этом собственная инфраструктура тоже не универсальный ответ. Ее нужно проектировать заранее: считать питание, охлаждение, место в стойках, сеть, хранение данных, отказоустойчивость. GPU-сервер сам по себе не решает задачу, если вокруг него нет среды, в которой модель сможет стабильно работать.</p> <p>Поэтому рынок приходит к более сложной картине. Одни нагрузки остаются в облаке, другие переносятся в собственный контур, третьи требуют промежуточного варианта: локальной или суверенной облачной инфраструктуры с понятной юрисдикцией. И именно здесь тема GPU-мощностей начинает пересекаться с другим трендом, который быстро набирает вес, с геопатриацией данных и приложений.</p> <h3>Геопатриация: почему важна не только цена GPU</h3> <p>Вопрос размещения ИИ-нагрузок уже не сводится к выбору между «купить сервер» и «арендовать мощности». На него все сильнее влияет то, где физически находятся данные, кто управляет инфраструктурой, какие законы действуют на площадке и что произойдет, если доступ к внешнему сервису станет ограниченным. Gartner <a href="https://www.gartner.com/en/articles/top-technology-trends-2026">называет </a>этот тренд геопатриацией: компании переносят данные и приложения из глобальных публичных облаков в локальные варианты, включая суверенные облака, региональных провайдеров и собственные ЦОДы. По прогнозу аналитиков, к 2030 году более 75% компаний Европы и Ближнего Востока переведут виртуальные нагрузки в решения, которые снижают геополитические риски. Для российского рынка это усиливает спрос не просто на GPU, а на управляемую инфраструктуру под ИИ. Компаниям нужно понимать, где будут храниться данные, как соблюдаются требования регуляторов и можно ли сохранить контроль над критическими нагрузками, не теряя доступ к вычислительным ресурсам.</p> <h3>Чек-лист: что проверить до закупки GPU-инфраструктуры</h3> <p>Перед закупкой GPU-инфраструктуры важно зафиксировать не только бюджет, но и саму задачу. Иначе компания рискует купить дорогую конфигурацию, которая не подходит под реальную нагрузку или быстро упрется в ограничения по питанию, охлаждению и обслуживанию.</p> <ul> <li> <strong>Сценарий использования.</strong> Нужно заранее понять, для чего нужны мощности: обучение модели, дообучение, инференс, компьютерное зрение, инженерные расчеты, аналитика или несколько задач сразу.</li> <li><strong> Объем видеопамяти.</strong> Для одних сценариев достаточно более простой конфигурации, для других критичен объем памяти на каждой карте. Это влияет и на производительность, и на стоимость.</li> <li><strong> Количество GPU.</strong> Важно считать не «сервер вообще», а конфигурацию под нагрузку: две, четыре, шесть или восемь карт дают разную цену, энергопотребление и требования к охлаждению.</li> <li><strong> Питание и охлаждение.</strong> GPU-сервер нельзя просто поставить вместо обычного. Нужно проверить стойки, электропитание, тепловыделение, кондиционирование и готовность площадки к постоянной высокой нагрузке.</li> <li><strong> Сроки поставки и срок действия цены.</strong> Для таких проектов коммерческое предложение быстро теряет актуальность. Лучше сразу уточнять, сколько действует цена и что произойдет, если поставка сдвинется.</li> <li> <strong>Происхождение оборудования.</strong> Нужно понимать, по каким каналам приходит оборудование, можно ли подтвердить его характеристики и соответствует ли оно заявленной конфигурации.</li> <li><strong> Новое или восстановленное.</strong> Восстановленное оборудование может быть рабочим вариантом только тогда, когда компания осознанно соглашается на этот риск и видит это в документах. Подмена нового оборудования восстановленным, это уже не экономия, а проблема.</li> <li><strong> Гарантия и ЗИП.</strong> В GPU-проектах отказ одной карты может остановить критичную нагрузку. Поэтому заранее нужны условия гарантии, доступность запасных компонентов и понятный порядок замены.</li> <li><strong> Возможность масштабирования.</strong> Если ИИ-проект пойдет в промышленную эксплуатацию, нагрузка почти наверняка вырастет. Лучше сразу проверить, можно ли расширить конфигурацию без полной перестройки инфраструктуры.</li> </ul> <h3>Заключение: почему откладывать закупку может быть дороже</h3> <p>Не каждый ИИ-проект требует мощностей GPU-сервера. Если сценарий еще не подтвержден, данные не подготовлены, а нагрузка непонятна, логичнее начать с тестов и расчетов. Ошибка здесь может стоить дорого: мощная конфигурация без понятной задачи быстро превращается в дорогой простаивающий ресурс. Но если сценарий уже определен, нагрузка посчитана, а инфраструктурные требования понятны, затягивать с решением становится рискованно. Рынок GPU-серверов сейчас живет в условиях дефицита: ускорители дорожают, сроки поставки меняются, а доступные конфигурации разбирают быстрее, чем компании проходят внутренние согласования.</p> <p>Поэтому главный вопрос для бизнеса звучит не как «покупать или подождать», а как «готова ли компания уже сейчас зафиксировать архитектуру, бюджет и сроки». Если ответ положительный, ожидание может не снизить расходы, а увеличить их. В ближайшее время GPU-инфраструктура останется одним из самых дорогих и ограниченных ресурсов для внедрения ИИ, и это стоит учитывать до того, как проект перейдет из обсуждения в срочную закупку.</p> <p> #IMAGE_235797#</p> Еще недавно корпоративный ИИ обсуждали через сценарии: где он заменит ручной труд, как ускорит аналитику, какие … article Мария Соловьева, руководитель направления серверной инфраструктуры и систем хранения данных компании ”ГИГАНТ — Компьютерные системы” https://www.itweek.ru/themes/detail.php?ID=235810 Thu, 22 Oct 2026 00:00:00 +0300 <p>Компания «Шаркс ДЦ» — вендор инфраструктурного программного обеспечения и компания «ЕСМ-Консалтинг», разработчик платформы цифровых архивов, расширяют технологический стек совместимых продуктов и официально объявляют о завершении цикла испытаний и подтверждении полной технологической совместимости своих решений — Sharx Base и М1:Архив.</p> <p>Связка М1:Архив и система серверной виртуализации Sharx Base закрывает актуальную потребность рынка в защищенной и масштабируемой платформе для работы с электронными документами.</p> <p><strong>Ключевые преимущества совместного решения:</strong></p> <ul> <li> <strong>Мультисервисная архитектура и катастрофоустойчивость.</strong> Платформа М1:Архив обладает распределенной архитектурой, которая позволяет масштабировать серверную часть, в том числе на несколько территориально распределенных центров обработки данных (ЦОДов). Развертывание платформы на базе Sharx Base обеспечивает гибкое управление вычислительными ресурсами и сетевой связанностью между площадками.</li> <li> <strong>Линейная масштабируемость.</strong> Мультисервисная архитектура М1:Архив позволяет увеличивать мощности по мере роста данных, а Sharx Base гарантирует эффективное распределение этих нагрузок на уровне гипервизора виртуализации и программно-определяемой системы хранения.</li> <li><strong>Единый импортонезависимый контур.</strong> Весь жизненный цикл данных, от создания и обработки до долгосрочного хранения, работает в доверенной среде. Оба продукта включены в Единый реестр российского ПО: М1:Архив (реестровый № 11091) и Sharx Base (реестровый № 4445).</li> <li><strong>Оптимизация хранения данных (тиринг).</strong> Ранее была подтверждена совместимость М1:Архив и Sharx Storage (решение для хранения данных с поддержкой S3-протокола). Сертификация М1:Архив с продуктами компании «Шаркс ДЦ» позволяет реализовать многоуровневое хранение. Редко используемые документы можно перемещать на более эффективные по стоимости носители, а оперативные данные остаются на быстрых дисках.</li> </ul> <p>«Подтверждение совместимости с М1:Архив — это важный шаг для расширения сценариев применения нашей платформы в корпоративных и ведомственных инфраструктурах. Использование связки Sharx Base и М1:Архив помогает упростить внедрение архитектур, рассчитанных на длительное хранение и быстрый доступ к документам» — подчеркнул Константин Шамрай, генеральный директор «Шаркс ДЦ».</p> <p>«Технологическая связка М1:Архив и Sharx Base позволяет добиться максимальной плотности размещения данных без потери производительности. Мы минимизируем накладные расходы на аппаратное обеспечение за счет гиперконвергентной системы Sharx Base, теперь заказчики могут более эффективно использовать ее преимущества для реализации оптимального хранения в М1:Архиве» — отметил Игорь Кнышев, технический директор «ЕСМ-Консалтинг».</p> Компания «Шаркс ДЦ» — вендор инфраструктурного программного обеспечения и компания «ЕСМ-Консалтинг», разработчик … message https://www.itweek.ru/themes/detail.php?ID=235794 Thu, 22 Oct 2026 14:48:17 +0300 <p>Российский VAD-дистрибутор ITOREX заключил соглашение с компанией «С-Терра СиЭсПи» и начал поставки ее продуктов для защиты сетевой инфраструктуры.</p> <p>В портфель ITOREX вошли «С-Терра Шлюз» для организации защищенных VPN-соединений, межсетевой экран нового поколения «С-Терра Экран-М», система обнаружения вторжений «С-Терра СОВ» и система управления «С-Терра ГСУ». </p> <p>С-Терра проведет обучение технической команды ITOREX по сценариям применения продуктов и подбору конфигураций. После подготовки специалисты дистрибутора смогут самостоятельно разбирать первичные запросы партнеров. К более сложным задачам будут подключаться эксперты разработчика.</p> <p>«В проектах по защите распределенной инфраструктуры требуется решать сразу несколько связанных задач: защищать каналы связи, контролировать сетевой трафик и выявлять атаки. Соглашение с С-Терра позволяет нам дополнить предложение российскими продуктами для каждого из этих направлений», — прокомментировал Дмитрий Крайненко, директор по работе с вендорами ITOREX.</p> <p>«Соглашение с ITOREX позволит большему числу интеграторов включать продукты С-Терра в проекты уже на этапе проектирования системы защиты. Наибольший потенциал мы видим в регионах, а также в госсекторе и промышленности», — отметил Алексей Трофимов, руководитель отдела по работе с партнерами «С-Терра СиЭсПи».</p> Российский VAD-дистрибутор ITOREX заключил соглашение с компанией «С-Терра СиЭсПи» и начал поставки ее продуктов … message https://www.itweek.ru/themes/detail.php?ID=235793 Thu, 22 Oct 2026 14:47:08 +0300 <p>POWERCOM, международный разработчик и производитель источников бесперебойного питания, объявил о масштабном обновлении ассортимента однофазных ИБП. Компания выпустила пять новых серий: Raptor Plus, Raptor Plus LCD, FLY, Macan Plus и Spider, которые получили улучшенные технические характеристики, повышенную мощность и расширенный функционал при сохранении конкурентной стоимости.</p> <p>Ранее POWERCOM уже анонсировал выпуск ИБП Raptor Plus, Raptor Plus LCD и FLY, финальным аккордом масштабного обновления стал выпуск серий Macan Plus и Spider. Эти две линейки полностью закрывают потребности бизнеса любого масштаба: от комплексной защиты серверного оборудования и дата-центров (ЦОД) до обеспечения стабильного питания отдельных рабочих мест в офисе.</p> <p>Серия Macan Plus выполнена по онлайн-топологии с двойным преобразованием напряжения и выходным коэффициентом мощности PF=1. На корпусе — ЖК-дисплей. В серию входят восемь моделей:</p> <ul> <li>четыре модели с евророзетками мощностью 1000, 1500, 2000 и 3000 ВА;</li> <li>четыре модели с розетками IEC аналогичной мощности.</li> </ul> <p>ИБП Macan Plus рассчитаны на технику, для которой сбой питания обходится дороже всего: серверы, оборудование центров обработки данных, компьютеры высокого класса. Они защищают от перегрузок и короткого замыкания, понижения и повышения напряжения, а также полного его пропадания в электросети. Преимущества серии:</p> <ul> <li>двойное преобразование — подключенное оборудование получает стабильное напряжение независимо от качества сети, а переход на батареи проходит без разрыва питания;</li> <li>выходной коэффициент мощности PF=1 — активная мощность равна полной: модель на 3000 ВА отдает нагрузке до 3000 Вт;</li> <li>широкий диапазон входного напряжения <nobr>120–276 В —</nobr> ИБП реже переходит на батареи при сильных просадках и скачках в сети;</li> <li>быстрая зарядка батарей — до 90% емкости за 4 часа;</li> <li>режим высокой эффективности — при стабильной сети ИБП расходует меньше электроэнергии и меньше греется;</li> <li>ЖК-дисплей — параметры работы ИБП видны сразу, без подключения к компьютеру;</li> <li>современный дизайн корпуса.</li> </ul> <p>Spider — <nobr>8-розеточный</nobr> ИБП линейно-интерактивной топологии с возможностью настенного монтажа. Модели оснащены светодиодной индикацией и цифровым дисплеем. В серию входят четыре модели мощностью 550, 750, 900 и 1100 ВА.</p> <p>ИБП защищают компьютер, рабочую станцию, модем, роутер, сетевое хранилище данных и другое коммуникационное оборудование, а также серверы с импульсными блоками питания. Восемь розеток позволяют подключить к одному ИБП весь комплект техники на рабочем месте. Преимущества серии:</p> <ul> <li>четыре евророзетки с батарейной поддержкой и четыре евророзетки с фильтрацией;</li> <li>работа без задействования батареи даже при 140 В;</li> <li>функция Green Mode (сбережение энергии) — ИБП автоматически отключается, если подключенное оборудование потребляет мало энергии или не подключено вовсе. Так экономятся заряд аккумуляторов и электроэнергия;</li> <li>функция Cold Start («холодный старт») — ИБП можно включить и питать подключенное оборудование при полном отсутствии напряжения во внешней сети;</li> <li>защита телефона, факса, модема и локальной сети, EMI/RFI-фильтрация;</li> <li>USB-порт для связи с ПК;</li> <li>возможность настенного монтажа.</li> </ul> <p>Выпуск новых серий однофазных ИБП завершает масштабное обновление однофазных решений POWERCOM и предлагает бизнесу современные, отказоустойчивые инструменты для защиты электрооборудования различного уровня сложности. Новые модели уже доступны для заказа у официальных дистрибьюторов.</p> POWERCOM, международный разработчик и производитель источников бесперебойного питания, объявил о масштабном обновлении … message https://www.itweek.ru/themes/detail.php?ID=235792 Thu, 22 Oct 2026 14:43:35 +0300 <p>ГК «Аквариус» объявила о выводе на рынок Wi-Fi оборудования и программного обеспечения (ПО) для создания решения по построению корпоративных беспроводных сетей передачи данных. Решение включает в себя ПО контроллера беспроводной сети Aquarius Wireless LAN Controller (AQ-WLC) и точки доступа Aquarius серии AQ-W6.</p> <p>ПО контроллера и точки доступа внесены в соответствующие реестры Министерства цифрового развития, связи и массовых коммуникаций и Министерства промышленности и торговли Российской Федерации, что подтверждает их российское происхождение и открывает заказчикам доступ к применению на регулируемом рынке.</p> <p>Линейка точек доступа серии AQ-W6 представлена моделями, работающими в стандартах Wi-Fi 6 и Wi-Fi 6E. </p> <p>Точки доступа с поддержкой Wi-Fi 6E рассчитаны на объекты с высокой плотностью пользователей — кампусы, конференц-залы, медицинские центры, производственные корпуса. Диапазон 6 ГГц, в отличие от традиционных 2,4 ГГц и 5 ГГц, практически свободен от помех со стороны бытовых устройств, что обеспечивает стабильную работу при большом количестве одновременных подключений. </p> <p>Совокупная пропускная способность таких точек доступа достигает 8353 Мбит/с, что позволяет работать с потоковым видео сверхвысокой четкости, большими массивами данных и критически важными сервисами.</p> <p>Точки доступа серии AQ-W6 моделей AQ-W6P201I, AQ-W6P301I, AQ-W6P301E, AQ-W6P301C, AQ-W6PE401I, AQ-W6PE401E, AQ-W6PE401C, AQ-W6PE101I, AQ-W6P101I предназначены для установки в офисных и административных зданиях. Модель AQ-W6O202E в защищенном корпусе класса IP67, сохраняющая работоспособность при перепадах температур, высокой влажности, осадках и запыленности, позволяет строить беспроводную сеть передачи данных на открытых территориях, парковках, складских и логистических комплексах. </p> <p>Точки доступа работают под управлением контроллера беспроводной сети AQ-WLC, который обеспечивает централизованное управление всей инфраструктурой: автоматически настраивает радиоканалы и распределяет нагрузку между точками доступа. Контроллер интегрируется с корпоративными системами авторизации, что позволяет использовать единые учетные данные и политики доступа.</p> <p>Контроллер поддерживает до 5000 точек доступа Aquarius серии AQ-W6 и до 32000 одновременно подключенных клиентских устройств. Его возможности включают современные стандарты безопасности, управление роумингом по стандартам 802.11r/v/k, управление радиоресурсами (Radio Resource Management, RRM), отказоустойчивость 1:1 Hot Standby, а также гибкость настройки и вариативность установки.</p> <p>«Вывод на рынок Wi-Fi оборудования корпоративного уровня открывает новый этап в развитии телекоммуникационного направления „Аквариуса“. Контроллер AQ-WLC и точки доступа серии AQ-W6 позволяют решить задачу любого масштаба — от компактного офиса до производственных площадок. Мы сделали акцент на производительности, отказоустойчивости и эффективности управления. Используя наше решение, заказчики получат беспроводную сеть, которая работает стабильно и не требует компромиссов между масштабом, надежностью и удобством эксплуатации», — прокомментировал Артем Дрожжин, директор бизнес-юнита «Телекоммуникационные решения» компании «Аквариус».</p> ГК «Аквариус» объявила о выводе на рынок Wi-Fi оборудования и программного обеспечения (ПО) для создания … message https://www.itweek.ru/themes/detail.php?ID=235790 Thu, 22 Oct 2026 12:31:03 +0300 <p>Формулу «кто не внедрит искусственный интеллект, тот умрет» уверенно повторяют со сцен бизнес-конференций уже несколько лет. Но статистика показывает, что ИИ в работе применяет примерно каждая двадцатая крупная и средняя организация страны, и остальные девятнадцать с рынка никуда не делись. Вымирания отстающих в этих цифрах пока не видно. Различия между компаниями при этом растут: сильные специалисты постепенно переходят туда, где ИИ уже внедрен, и следом, с высокой вероятностью, туда же уйдут клиенты и выручка.</p> <p>Обсудим, кто не внедряет ИИ и почему, что происходит с такими компаниями и кому откладывать внедрение рискованно.</p> <h3>Девятнадцать из двадцати работают без ИИ</h3> <p>Технологии ИИ <a href="https://issek.hse.ru/news/1139129178.html">используют</a> 4,8% крупных и средних российских организаций. Среди организаций, где работает больше 500 человек, ИИ применяют 14,9%, а среди тех, где заняты 100 человек и меньше, 4,1%, то есть в 3,6 раза реже. Внедрение ИИ в малых предприятиях изучить сложнее, поэтому по экономике в целом разрыв, скорее всего, еще больше.</p> <p>В Евросоюзе доля выше при похожей структуре. В 2025 году ИИ <a href="https://ec.europa.eu/eurostat/statistics-explained/index.php?title=Use_of_artificial_intelligence_in_enterprises">использовали</a> 20% предприятий с численностью от десяти человек против 13,5% годом раньше. Среди крупных компаний от 250 человек, доля составила 55%, среди малых предприятий до 50 человек — 17%. По отраслям расхождение еще сильнее: в ИТ-сфере ИИ используют 62,5% предприятий, в строительстве — 10,8%.</p> <p>Рост идет быстро и неравномерно. Внедряют эти технологии в первую очередь крупные компании и те, кто работает с информацией, а низкая доля держится в строительстве, на транспорте и в общепите, и таких компаний в экономике большинство. Гибели отстающих в этих цифрах пока не видно, однако отчетливо видно расслоение по размеру и отрасли.</p> <h3>Три причины, по которым компании не внедряют ИИ</h3> <p>Первая группа <strong>отказывается от ИИ сознательно</strong>, чаще по инициативе (или точнее сказать ее отсутствию) сотрудников. Недавно проведенный опрос, который охватил 23,7 тыс. работающих американцев, в компаниях которых ИИ внедрен, показал, что 46% <a href="https://www.gallup.com/workplace/704252/workplace-separates-adopters-holdouts.aspx">предпочитают</a> работать привычным способом и 43% отказываются по этическим соображениям.</p> <p>Вторая группа<strong> не внедряет ИИ ввиду ограничений и правил безопасности</strong>. Госсектор, оборонная промышленность и любая компания с закрытым контуром передать эти данные внешнему ИИ-сервису не могут. Среди европейских предприятий, которые рассматривали ИИ и отказались от этой идеи, 52,5% <a href="https://ec.europa.eu/eurostat/statistics-explained/index.php?title=Use_of_artificial_intelligence_in_enterprises">назвали</a> причиной непрозрачные правовые последствия и 48,8% — защиту данных. Чаще всего, в 70,9% случаев, компании ссылаются на нехватку собственных компетенций в этой области.</p> <p>Третья группа <strong>не видит для ИИ задачи</strong>. В пекарне, автосервисе или небольшом производстве узкое место находится у печи и у рук мастера, а тексты и таблицы занимают небольшую часть времени. Об отсутствии потребности в технологиях ИИ <a href="https://issek.hse.ru/news/1083541394.html">заявили</a> 48% крупных и средних российских организаций, и это компании с собственной бухгалтерией и отделом продаж, а у домашней пекарни таких задач еще меньше. Удешевление инструментов картину почти не меняет, потому что доля операционных задач в выручке пекарни от цены ИИ не зависит.</p> <h3>Теневое использование ИИ</h3> <p>Запреты не всегда работают так, как написано в регламенте. Там, где ИИ запрещен на бумаге и при этом результат требуют к завтрашнему дню, сотрудники находят обход, обычно через личный аккаунт ИИ-сервиса. По результатам крупного международного исследования исследования, почти половина сотрудников, работающих с ИИ, <a href="https://kpmg.com/xx/en/media/press-releases/2025/04/trust-of-ai-remains-a-critical-challenge.html">делает</a> это вопреки правилам своей компании, включая загрузку рабочих данных в публичные сервисы, и 57% скрывают использование или выдают результат за собственный.</p> <p>В России картина похожая. Использование ИИ от руководства <a href="https://incrussia.ru/news/opros-pokazal-chto-kazhdyj-tretij-rossiyanin-skryvaet-ispolzovanie-ii-ot-rabotodatelya/">скрывают</a> 35% работников, чаще всего это молодые специалисты, которые опасаются, что признание сочтут признаком некомпетентности.</p> <p>Официальная статистика и опросы сотрудников расходятся, потому что измеряют разное. Росстат считает организации, где ИИ внедрен как технология по решению руководства, опросы показывают реальный факт использования. Судя по данным опросов, ИИ работает и во многих из тех девятнадцати компаний, которые в статистику не попали, силами сотрудников и без ведома службы безопасности.</p> <h3>Что стало с компаниями, которые не вышли в интернет</h3> <p>Ни одна технологическая волна не заканчивалась стопроцентным охватом. Сайт в 2025 году <a href="https://ec.europa.eu/eurostat/statistics-explained/index.php?title=E-business_integration">был</a> у 79% предприятий Евросоюза с численностью от десяти человек, системы управления ресурсами использовали 46%. Интернету в бизнесе около тридцати лет, и каждое пятое предприятие до сих пор обходится без сайта.</p> <p>Предприятия без сайта потеряли долю рынка, но сам рынок у них остался, потому что хлеб выбирают по хлебу, а машину чинят у того, кто чинит машины. Ниша сужается там, где конкурент с помощью ИИ закрывает ту же потребность клиента дешевле, и это условие проверяется по каждой компании отдельно.</p> <p>Что именно произойдет с теми, кто не внедрил ИИ, посчитать пока нельзя, потому что таких расчетов нет ни у сторонников вымирания, ни у их оппонентов. Есть замеры по тем, кто внедрил. Экономисты связали опросы 25 тыс. работников из 7 тыс. предприятий Дании с административными данными о занятости и <a href="https://www.nber.org/papers/w33777">не нашли</a> значимого эффекта от использования ИИ-моделей на выручку и эффективность труда через два года после появления ChatGPT, с точностью, исключающей эффект больше 2%. Экономия времени по оценке самих пользователей составила около 3%. Единственный эффект, подтвержденный в рамках исследования — освоившие ИИ переходят в профессии, где он полезнее и где больше платят, но их пока слишком мало, чтобы это отразилось на средних заработках.</p> <p>Датские данные описывают массовое внедрение ИИ-моделей для побочных задач, и нулевой результат для такого сценария закономерен, потому что выгода появляется там, где компания закрывает с помощью ИИ узкое место, а три процента рабочего времени такой выгоды не дают. Судьбу не внедривших компаний считать рано, потому что измеримый разрыв не возник даже там, где ИИ внедрило большинство.</p> <h3>Кому внедрять все-таки нужно</h3> <p>Отраслевой список здесь не работает, потому что внутри одной отрасли компании находятся в разном положении. Вместо списка компания должна ответить себе на три вопроса:</p> <ol> <li><strong>Где находится узкое место? </strong>Если это интеллектуальная рутина — тексты, код, поддержка клиентов— компания может решить эти задачи ее с помощью ИИ, и внедрять его нужно сейчас. Если узкое место у печи, станка или лицензии, внедрение принесет издержки без преимущества. </li> <li><strong>Сможет ли конкурент с помощью ИИ делать то же самое дешевле и в большем объеме? </strong>Если сможет, времени на ответ остаются месяцы, потому что клиенты быстро уйдут туда, где дешевле. Если конкурент ограничен тем же временем печи и тем же числом мастеров, спешка ничего не дает. </li> <li><strong>Запрет идет от закона или от политики самой компании? </strong>Если от закона, остаются два варианта: развернуть модель на своих серверах внутри контура или честно не внедрять. Если от политики: теневое внедрение уже идет, и выбор здесь только между управляемым и неуправляемым. Выдать сотрудникам разрешенный инструмент будет дешевле, чем узнать о об использовании постфактум.</li> </ol> <p>Ответы на эти вопросы стоит записать и пересматривать раз в год, потому что за год меняются и цена инструментов, и само узкое место. Пекарню такой пересмотр, скорее всего, не сдвинет, а компанию на границе между группами он сдвинуть может.</p> <p> #IMAGE_235791#</p> Формулу «кто не внедрит искусственный интеллект, тот умрет» уверенно повторяют со сцен бизнес-конференций уже несколько … article Олег Строкатый, руководитель направления контроля качества ”Битрикс24” https://www.itweek.ru/themes/detail.php?ID=235788 Thu, 22 Oct 2026 12:20:41 +0300 <p>Датчик зафиксировал отклонение, система мониторинга вывела предупреждение на дашборд, но ремонтная служба узнала о неисправности только после остановки оборудования. Такая ситуация возможна даже на предприятии с развитой ИТ-инфраструктурой. Информация доступна, однако ее передачу исполнителю по-прежнему обеспечивает человек. Опираясь на свой профессиональный опыт, я расскажу, как платформенный подход помогает связать обнаружение проблемы с ее устранением и оценить результат в показателях бизнеса.</p> <p>Российские компании уже давно используют ERP, CRM, SCADA, сервис-дески и другие цифровые инструменты. Каждый из них отвечает за определенный участок работы. При этом выполнение одной задачи часто требует участия нескольких подразделений и доступа к разным системам. Чтобы организовать ремонт, нужно проверить историю оборудования, уточнить наличие запчастей, назначить инженера и согласовать время работ. Если эти этапы связаны только перепиской и звонками, скорость процесса зависит от того, как быстро сотрудники передадут друг другу информацию.</p> <p>По мере роста компании такая координация становится сложнее. Появляются новые объекты, подрядчики и приложения, меняются зоны ответственности. Даже небольшая корректировка процесса может потребовать доработки нескольких интеграций. Руководителю все труднее понять, почему работа задерживается: заявку поздно заметили, передали не тому специалисту или оставили без необходимых данных.</p> <p>Я предлагаю оценивать цифровую зрелость компании по тому, насколько последовательно задача проходит весь путь от возникновения до подтвержденного выполнения. Такой взгляд помогает обнаружить потери, которые незаметны в отчетности отдельных подразделений. Например, инженер укладывается в норматив ремонта, но до назначения исполнителя заявка несколько часов ожидает обработки.</p> <p>Платформенный подход позволяет задать общую логику этого пути: событие, правило реакции, задача, ответственный, исполнение и результат. При поступлении сигнала система определяет дальнейшие действия, создает задание и передает его сотруднику вместе с информацией об объекте. Сроки контролируются автоматически. Если исполнитель не принял задачу или не завершил ее вовремя, запускается предусмотренный порядок эскалации. Подтверждение выполненной работы сохраняется в истории объекта.</p> <p>Эту логику можно выстроить с сохранением действующих корпоративных систем. ERP продолжит обеспечивать учет ресурсов, CRM — работу с клиентами, а платформа свяжет необходимые данные и действия между ними. Отдельные приложения при необходимости можно заменить. На производстве управление технологическим процессом и противоаварийная защита сохраняются в соответствующих системах автоматизации.</p> <p>При этом правила работы определяет сама компания. До настройки платформы необходимо договориться, кто отвечает за процесс целиком, какие исключения возможны и по каким признакам задача считается выполненной. Техническая интеграция даст эффект, когда участники одинаково понимают свои обязанности и порядок взаимодействия.</p> <p>Такая задача встречается в разных отраслях. Например, при обслуживании микромаркетов компания привязала заявки и чек-листы к конкретным торговым объектам. Посещения мерчендайзеров стали подтверждать разовыми QR-кодами, расчет заработной платы автоматизировали. Руководители получили возможность сопоставлять присутствие сотрудника с выполненными работами и оценивать качество обслуживания каждой точки.</p> <p>В другом проекте крупный продуктовый ритейлер объединил в одной системе обращения сотрудников из почты, веб-портала и мессенджера. Переписка и сведения, необходимые для решения вопроса, стали доступны в карточке заявки. База знаний помогла сократить повторные уточнения. Показатель контроля исполнения заявок вырос на 98% относительно исходного уровня заказчика, а время на уточнение деталей сократилось на 45%. Потери обращений были исключены.</p> <p>Промышленное предприятие сначала изменило порядок обходов. Оборудование промаркировали NFC-метками, бумажные записи заменили мобильными маршрутами и цифровыми чек-листами. Сведения о дефекте стали поступать в систему непосредственно с места осмотра, с привязкой к конкретному объекту. Проект охватил 1700 единиц оборудования на площади 17 000 м². Время реакции на дефекты сократилось в два-три раза, просрочки их устранения практически исчезли.</p> <p>Производителю пищевой продукции нужно было обеспечить непрерывный температурный контроль подвижного оборудования разных производителей. Специалисты компании подключили к платформе беспроводные датчики, настроили регистрацию инцидентов, уведомления ответственных и контроль устранения нарушений. Мониторинг охватил все оборудование в рамках проекта. Потери продукции из-за нарушения температурного режима при хранении сократились на 90%, среднее время реакции персонала — на 43%. Более 90% таких отклонений система автоматически фиксирует и передает ответственным без участия диспетчера. Устранением неисправностей занимается персонал.</p> <p>Общий механизм этих изменений состоит в том, что сотрудник получает подготовленную задачу в нужный момент, а руководитель видит ее движение и результат. На этой основе можно определить, какие этапы целесообразно дополнительно поручить искусственному интеллекту.</p> <p>Например, сервисная компания организовала на платформе управление инцидентами для 60 клиентов, заменив Jira Service Desk. ИИ классифицирует обращения, проводит первичную оценку и маршрутизирует заявки между командами. В результате проекта время реакции на инциденты сократилось втрое, первичный анализ ускорился в три-четыре раза. Система обрабатывает более 100 заявок в день. Эти показатели отражают эффект всего внедрения, включая изменение процесса обработки обращений.</p> <p>Пользу ИИ я предлагаю оценивать через работу, которую он помогает выполнить. Доступ к истории объекта, предыдущим инцидентам и базе знаний позволяет находить похожие случаи, готовить краткое описание проблемы и предлагать следующий шаг. Качество этой помощи зависит от полноты и актуальности корпоративных данных. Если одно оборудование числится под разными названиями, а результаты ремонтов не фиксируются, возможности анализа будут ограничены.</p> <p>Для самостоятельных действий ИИ заранее задаются полномочия. Классификацию обращения и передачу заявки можно автоматизировать в пределах согласованных правил. Решения, влияющие на технологический процесс, остаются под контролем уполномоченного сотрудника. Платформа должна сохранять права доступа и историю действий, чтобы можно было проверить основания рекомендации и порядок ее исполнения.</p> <p>Выбирать первый процесс для внедрения я рекомендую по пяти шагам:</p> <p>1. Найти повторяющуюся задачу с понятными потерями: простоями, просрочками, повторными выездами или большим объемом ручной координации.</p> <p>2. Проследить передачу информации между участниками и определить этапы, на которых возникают задержки.</p> <p>3. Зафиксировать исходные показатели, целевой результат и источники данных для проверки.</p> <p>4. Провести пилот на одном объекте или в одном подразделении.</p> <p>5. Подтвердить эффект и оценить условия его повторения на других площадках.</p> <p>Измерения стоит разделить на четыре группы. Скорость покажет время от события до регистрации задачи, назначения исполнителя и завершения работы. Надежность — долю просрочек, соблюдение SLA и количество повторных инцидентов. Трудозатраты — сколько часов уходит на диспетчеризацию, согласования и отчетность. Экономика — как изменились стоимость выполнения процесса, потери от простоев, брака и внеплановых ремонтов.</p> <p>После пилота показатели сравнивают при сопоставимом объеме и составе работ, учитывая сезонность и другие изменения на предприятии. Для проверки используют журналы событий, историю заявок, показания датчиков и фактические данные о потерях. В экономический расчет включают расходы на внедрение, интеграции и сопровождение.</p> <p>Перед масштабированием желательно проследить несколько реальных задач от первого сигнала до подтвержденного результата. По каждой должно быть понятно, где сократилось ожидание, какие ручные действия удалось убрать и сколько стоило это изменение. Такая проверка дает предметное основание для решения о дальнейшем развитии платформы.</p> <p> #IMAGE_235789#</p> Датчик зафиксировал отклонение, система мониторинга вывела предупреждение на дашборд, но ремонтная служба узнала … article Иван Лашков, руководитель отдела маркетинга STAQ https://www.itweek.ru/themes/detail.php?ID=235785 Thu, 22 Oct 2026 09:09:02 +0300 <p><em>Стать ИИ-компанией — это не о технологиях. Валид Абу-Хадба, генеральный директор компании Precision, приводит на портале </em><em>The</em> <em>New</em> <em>Stack</em> <em>четыре урока лидерства, которые помогут упростить работу и получить реальную ценность для бизнеса.</em></p> <p>Каждая компания находится под давлением, чтобы стать «ИИ-компанией». В течение последних нескольких месяцев мы проводили эту трансформацию в своей органиации, меняя то, как мы строим, работаем и измеряем прогресс.</p> <p>Этот опыт кое-что прояснил для меня: самые сложные этапы становления ИИ-компании относительно мало связаны с технологиями. ИИ может помочь организации двигаться быстрее, автоматизировать работу, увеличить производительность и фундаментально изменить возможности людей. Но ни одна из этих вещей не гарантирует более высокую эффективность бизнеса.</p> <p>Из нашего опыта были извлечены четыре урока лидерства:</p> <ol> <li> Начните с бизнес-цели.</li> <li> Упростите, прежде чем ускориться.</li> <li> Измените то, как работают люди.</li> <li> Измеряйте результаты, которые имеют значение.</li> </ol> <h3> Начните с бизнес-цели </h3> <p>Во-первых, разберитесь, чего пытается достичь бизнес: рост, ускорение инноваций, укрепление отношений с клиентами, улучшение продуктов, увеличение прибыли или что-то еще, что имеет значение для стратегии.</p> <p>ИИ значительно расширяет возможности. Это делает фокусировку критически важной. Руководители должны установить четкие приоритеты: что необходимо улучшить, что организации следует начать делать и, что не менее важно, что ей следует прекратить делать. Эта ясность определит, куда инвестировать, какие процессы изменить и где ИИ может создать наибольшую ценность.</p> <p>Без этого ИИ может увеличить сложность, а не уменьшить ее. Организации могут развертывать больше инструментов, запускать больше агентов и генерировать больше активности без четкой связи с бизнес-результатами, которых они пытаются достичь.</p> <p>Вот почему я считаю ИИ операционной моделью, а не стратегией. Стратегия определяет, куда движется бизнес и почему. ИИ может изменить скорость и эффективность достижения цели.</p> <h3>Упростите, прежде чем ускориться</h3> <p>Как только цель ясна, лидерам необходимо изучить, как выполняется работа. ИИ может заставить практически всё двигаться быстрее. Это и возможность, и проблема.</p> <p>Примените ИИ к процессу, который больше не добавляет ценности, и вы просто заставите плохой процесс работать быстрее. Автоматизируйте один шаг, оставив вокруг него одни и те же ненужные утверждения, передачи, встречи и точки принятия решений, и узкое место переместится из одной точки в другую.</p> <p>Я видел это воочию. Поскольку ИИ ускоряет такие области, как разработка ПО, ограничения часто смещаются на рабочие процессы. Если инженер может генерировать код в четыре раза быстрее, но этот код по-прежнему ожидает в тех же очередях и проходит те же этапы передачи, то организация не создает в четыре раза больше ценности.</p> <p>Развиваться должна вся система.</p> <p>Принцип прост: устраните то, что не добавляет ценности; упростите то, что приносит пользу; затем используйте ИИ для ускорения процесса.</p> <h3>Измените то, как работают люди</h3> <p>Технология сама по себе не трансформирует организацию. Люди должны изменить то, как они работают.</p> <p>Я увидел это в неожиданном месте — нашей летней программе стажировок.</p> <p>Наши стажеры прибыли с разным уровнем опыта работы с ИИ и разными представлениями о том, что это может значить для их карьеры. В течение десяти недель я наблюдал, как меняется их восприятие. Как только они смогли применить ИИ в реальной работе, они начали действовать быстрее, глубже исследовали проблемы и стали более уверены в своих силах.</p> <p>Больше всего меня поразило то, как быстро изменилось их представление о том, на что они способны, и насколько заразительной стала эта уверенность.</p> <p>Этот опыт укрепил то, что, по моему мнению, руководители должны понимать в отношении ИИ: базовые показатели того, чего люди могут достичь, меняются. И это касается далеко не только людей, пополняющих ваш штат.</p> <p>Поскольку ИИ берет на себя больше исполнительской и рутинной работы, у людей на каждом уровне появляется больше возможностей задавать направление, оценивать результаты, решать сложные проблемы, выстраивать отношения и применять суждения и опыт.</p> <p>Это имеет серьезные последствия в плане того, что руководители думают о рабочих местах, навыках и развитии. Предположения, которые мы построили относительно того, как выглядит должностная роль, сколько времени нужно человеку, чтобы стать профессиональным, и какой вклад могут внести люди на разных этапах карьеры, должны будут измениться.</p> <p>Рабочие процессы также должны развиваться. Предоставление сотрудникам доступа к ИИ и отслеживание того, как они им пользуются — это лишь первый шаг. Руководителям необходимо изучить, как должна измениться сама работа: какое место в этом процессе занимает ИИ, что он может взять на себя, где человеческое суждение остается важным и чего люди теперь могут достичь с помощью возможностей, создаваемых ИИ.</p> <p>Наши стажеры дали мне первое представление о том, как это может выглядеть. Задача руководства состоит в том, чтобы создать условия для того, чтобы такой же сдвиг произошел во всей организации.</p> <h3>Оценивайте отдачу для бизнеса</h3> <p>Наконец, руководители должны подходить к измерению прогресса системно и дисциплинированно.</p> <p>В какой-то момент внедрение ИИ стало бизнес-показателем. Организации отслеживают, сколько сотрудников используют ИИ, сколько интеллектуальных агентов развернуто, сколько токенов задействуется.</p> <p>Эти цифры показывают, пользуются ли люди ИИ, но не говорят о том, создает ли он реальную ценность.</p> <p>Мы никогда не измеряли окупаемость инвестиций (ROI) в электронную почту. Мы не следили за тем, насколько активно используются электронные таблицы, и не требовали еженедельных отчетов о количестве документов, созданных в Word. Мы воспринимали эти инструменты как часть инфраструктуры, а оценивали то, что бизнес с их помощью достигает.</p> <p>Внедрение — это лишь начало, а не конечный результат.</p> <p>Повышение продуктивности должно создавать дополнительный потенциал. Этот потенциал позволяет командам работать быстрее, раньше выводить идеи на рынок, уделять больше времени задачам, требующим профессионального суждения и экспертизы, а также улучшать клиентский опыт. В конечном итоге такие достижения должны трансформироваться в рост и более высокие бизнес-показатели.</p> <p>Именно поэтому, на мой взгляд, руководителям стоит рассматривать ИИ как возможность сделать больше, располагая теми же ресурсами, а не как способ сделать больше, сократив их.</p> <p>Если ваша стратегия в области ИИ нацелена на уменьшение численности персонала, вы воспринимаете ИИ лишь как инструмент повышения операционной эффективности. Это может снизить затраты в краткосрочной перспективе, но не создает долгосрочной ценности. Гораздо более значимая возможность заключается в расширении того, чего организация может достичь силами уже имеющихся сотрудников и их компетенций.</p> <h3>Задача для руководителей</h3> <p>Я с оптимизмом смотрю на то, как ИИ изменит работу.</p> <p>Технологии всегда трансформировали деятельность людей и расширяли границы возможного. ИИ придает этому процессу дополнительное ускорение.</p> <p>Однако само по себе наличие технологии еще не обеспечивает конкурентного преимущества.</p> <p>Ключевым фактором успеха станет то, как именно организации ее используют.</p> <p>А значит следует сохранять фокус на бизнес-целях; устранять излишнюю сложность, прежде чем ускорять процессы; перестраивать работу с учетом того, что люди и ИИ могут совершить вместе; и оценивать трансформацию через призму конкретных бизнес-результатов.</p> <p>Истинный показатель эффективности ИИ — это то, что ваш бизнес теперь может делать, хотя раньше это было невозможно.</p> Стать ИИ-компанией — это не о технологиях. Валид Абу-Хадба, генеральный директор компании Precision, приводит … article https://www.itweek.ru/themes/detail.php?ID=235783 Wed, 21 Oct 2026 15:34:02 +0300 <p>Кибериспытания в 2026 году стали одной из наиболее востребованных услуг по информационной безопасности. По оценке специалистов «Кросстех», порядка 80% ИБ-команд заказчиков в полной мере не справляются с противодействием команде атакующих.</p> <p>Неудачей по результатам Red Teaming считается нулевая или околонулевая детектируемость, когда защищающиеся не выявляют активность в инфраструктуре и позволяют пентестерам реализовывать сценарии, приводящие к недопустимым событиям. К признакам неэффективной работы команды защиты также относятся несвоевременное реагирование на инциденты, отсутствие скоординированных действий, а также применение мер реагирования, приводящих к нарушению работы критически важных сервисов. При этом сам факт проникновения не всегда считается неудачей ИБ-команды, так как вредоносные действия могли быть реализованы не из-за ошибок, а из-за архитектурных особенностей инфраструктуры компании.</p> <p>Чаще всего синие команды сталкиваются с трудностями при распознавании скрытых и бесшумных атак с использованием легитимных инструментов. Дополнительные сложности возникают при корреляции событий из большого количества разных источников, из-за ошибок в анализе данных и задержек при выявлении взаимосвязанных действий: защитникам сложно своевременно обнаружить развивающийся инцидент. Еще один вызов для команд — высокая нагрузка на системы мониторинга из-за большого количества ложных срабатываний, на фоне которых реальная угроза может остаться незамеченной.</p> <p>Отдельным вектором атак, который зачастую позволяет красной команде достигать поставленных целей, остается социальная инженерия. ИБ-команда не может вовремя зафиксировать факт компрометации учетных данных на раннем этапе, вследствие чего атакующие получают дополнительное время для развития атаки и продвижения по инфраструктуре.</p> <p>При этом, эксперты по анализу защищенности «Кросстех» указывают, что уровень подготовки ИБ-команд постепенно растет — среди команд, которые проходят повторные кибериспытания, порядка 50% улучшают свои показатели. Это связано как с развитием компетенций специалистов за счет обучения и привлечения новых сотрудников, так и с совершенствованием технических и организационных процессов: настройкой сбора и корреляции событий, расширением покрытия средствами мониторинга и повышением качества выявления атак.</p> <p>«Киберучения и кибериспытания крайне востребованы, потому что помогают увидеть реальный уровень готовности ИБ-команд и эффективности работы системы информационной безопасности у заказчика. Важно понимать, что если синие и допустили проникновение и реализацию недопустимого события, это не означает их полную неготовность к атаке. Важно учитывать, что уровень навыков профессиональных пентестеров значительно выше, чем средний уровень хакеров, особенно в последнее время с учетом снижение порога входа в киберпреступную деятельность из-за искусственного интеллекта и распространения платформ Cybercrime-as-a-Service», — отметила Анастасия Мельникова, руководитель департамента оценки защищенности «Кросстех».</p> Кибериспытания в 2026 году стали одной из наиболее востребованных услуг по информационной безопасности … message https://www.itweek.ru/themes/detail.php?ID=235782 Wed, 21 Oct 2026 15:33:08 +0300 <p>Компания «Хи-Квадрат» реализовала в платформе XSQUARE поддержку СУБД MySQL — одной из наиболее распространенных баз данных в мире. Ранее с MySQL не работала ни одна из российских low-code-платформ. Теперь компании, в том числе использующие эту СУБД, могут разрабатывать сайты и корпоративные приложения на стеке, аналогичном международному стандарту LAMP, где прикладной слой обеспечивает отечественная платформа.</p> <p>LAMP — это связка из операционной системы Linux, веб-сервера Apache, базы данных MySQL и языка PHP. Все четыре компонента бесплатны и открыты, поэтому собрать на них работающий сайт или сервис могла компания любого размера, не покупая лицензий. До середины <nobr>2010-х</nobr> такая связка оставалась фактическим стандартом веб-разработки — на ней построена значительная часть публичных сайтов и клиентских личных кабинетов, созданных до <nobr>2010–2015 годов.</nobr> Многие из этих систем эксплуатируются до сих пор. </p> <p>В стеке на базе XSQUARE каждому элементу классической связки соответствует своя альтернатива. Операционной системой выступает Debian, вместо веб-сервера Apache используется NGINX, базы данных MySQL — MariaDB, а прикладного слоя на PHP — сама платформа XSQUARE. Первые компоненты остаются международными открытыми продуктами, российским в этой конструкции является прикладной слой — уровень, на котором выстраивается бизнес-логика.</p> <p>Переход на отечественный прикладной слой позволяет бизнесу сократить затраты на разработку. В классическом стеке LAMP разработчику необходимо владеть несколькими технологиями сразу: PHP на стороне сервера, JavaScript на стороне клиента и языком запросов SQL. На XSQUARE достаточно знания SQL, а сама разработка ведется преимущественно визуальными средствами, без ручного написания кода. По расчетам компании, задача, для которой на LAMP требуется команда из трех разработчиков, закрывается силами одного, а с учетом скорости разработки стоимость сопоставимого объема работ снижается более чем на 80%.</p> <p>Воспользоваться этим преимуществом до сих пор не могли компании, которые использовали MySQL, поскольку для замены прикладного слоя требовалась платформа, совместимая с этой СУБД. По данным аналитического сервиса 6sense, MySQL занимает первое место среди реляционных СУБД по числу использующих ее компаний — то есть речь шла о значительной части бизнеса. Поддержка MySQL платформой XSQUARE снимает это ограничение. Компании могут перейти на новый технологический стек, начиная с прикладного ПО, и затем постепенно переносить данные в новую СУБД. </p> <p>Целевой базой данных в стеке «Хи-Квадрат» выступает MariaDB — форк MySQL, созданный командой его основателей. Технически это тот же MySQL, но полностью открытый и без коммерческой составляющей, тогда как MySQL принадлежит корпорации Oracle и, несмотря на открытую версию, развивается в первую очередь как коммерческий enterprise-продукт. </p> <p>«Мировой стек веб-разработки долгое время держался на связке открытых компонентов и одного языка программирования. На российском рынке отечественной альтернативы прикладному слою этого стека не было — сейчас она появилась. Наша платформа позволяет создавать внутренние корпоративные системы, публичные сайты, а также работать с MySQL. По сути, мы собрали отечественный аналог LAMP для тех же задач», — подчеркнул технический директор «Хи-Квадрат» Константин Ващенков. </p> Компания «Хи-Квадрат» реализовала в платформе XSQUARE поддержку СУБД MySQL — одной из наиболее распространенных … message https://www.itweek.ru/themes/detail.php?ID=235781 Wed, 21 Oct 2026 15:32:12 +0300 <p>Сбер представил GreenWAM — модель искусственного интеллекта, которая умеет формировать команды для робота и предсказывать, как изменится окружающая сцена после его движений. Разработка объединяет две способности: моделирование происходящего и управление действиями. Её проверили в виртуальных средах и на человекоподобном роботе Грине.</p> <p>GreenWAM продолжает направление исследований Сбера в области искусственного интеллекта для роботов, к которому относится и Green-VLA. В новой работе акцент сделан на предсказании последствий действий: модель одновременно учится управлять роботом при выполнении задания и предсказывать, как изменится мир в результате его действий. И в прогнозе, и в управлении GreenWAM показала результаты на уровне ведущих мировых разработок, причём одна способность усиливает другую.</p> <p>Эксперты Сбера обучили GreenWAM на данных 20 семейств роботов — от двуруких манипуляторов до антропоморфных роботов с кистями. Для этого действия всех роботов описали в едином представлении, а в архитектуру добавили отдельный модуль, отвечающий за выбор действий.</p> <p>По заданным действиям робота GreenWAM способна предсказать до минуты видео. В международном тесте WorldArena 1.0 модель показала второй результат среди 128 моделей рейтинга по сходству прогноза с реальной записью и точнее воспроизвела геометрию сцены, чем модели мира NVIDIA, Стэнфордского университета и AgiBot.</p> <p>В управлении роботом GreenWAM выступает на уровне лучших мировых моделей и опережает большинство из них, включая π0.5 от Physical Intelligence. В тесте RoboTwin 2.0 доля успешно выполненных задач составила 67,5% против 58,4% у π0.5, а в знакомых для модели условиях — 87%: выше этого результата в официальном рейтинге лишь две модели. В тесте LIBERO-plus, где у робота меняют освещение, положение камер, фон и формулировку команды, GreenWAM без дополнительного обучения выполнила 86,8% задач — больше, чем π0.5 и аналогичные модели NVIDIA и AgiBot.</p> <p>Модель также испытали на человекоподобном роботе Грине, которого создал Сбер. По сравнению с моделью NVIDIA Cosmos 3 Edge, обученной на тех же данных, доля успешно выполненных задач выросла с 88,9% до 95,6% в знакомых для модели условиях. В новых условиях этот показатель повысился с 80% до 84%.</p> <p>Эксперименты показали, что две способности модели усиливают друг друга. Обучение на данных роботов сделало прогноз модели точнее и одновременно повысило долю успешно выполненных задач — как в виртуальных тестах, так и на реальном роботе. А если при обучении управлению сохранить у модели умение предсказывать изменения мира, она заметно чаще справляется с задачами в незнакомых условиях. Большинство ошибок в таких условиях возникает, когда модель неверно представляет себе изменившуюся сцену.</p> <p>Для работы в реальном времени разработчики создали ускоренную версию модели. Она работает в 12,3 раза быстрее исходной, а доля успешно выполненных задач на роботе при этом снизилась лишь с 95,6% до 91,1%. Это важно, когда робот должен быстро реагировать на изменения обстановки.</p> <p>Андрей Белевцев, старший вице-президент, руководитель блока «Технологическое развитие» Сбербанка, отметил: «Для практического применения роботов искусственный интеллект должен распознавать окружающие объекты, выполнять команды и прогнозировать последствия своих действий. Особенно это важно в меняющихся условиях, когда роботу нужно оценивать новую обстановку и корректировать свои движения. В GreenWAM мы объединили эти возможности в одной модели. Дополнительное обучение на робототехнических данных помогло улучшить и прогнозирование, и качество управления. Результаты испытаний показывают, что такой подход эффективен не только в виртуальной среде, но и при управлении реальным роботом».</p> Сбер представил GreenWAM — модель искусственного интеллекта, которая умеет формировать команды для робота … message https://www.itweek.ru/themes/detail.php?ID=235780 Wed, 21 Oct 2026 15:30:35 +0300 <p>Компания «Лаборатория Виртуализации» выпустила версию 3.1.0 платформы Inscale — российского решения для серверной виртуализации и инфраструктуры виртуальных рабочих столов (VDI). В релизе четыре крупных блока: отказоустойчивые хранилища Fibre Channel, встроенное управление сертификатами, оверлейные сети VXLAN и веб-версия панели управления.</p> <p>Хранилища Fibre Channel с резервированием путей. Платформа распознаёт несколько физических подключений к одному FC LUN и объединяет их в одно отказоустойчивое multipath-устройство. Хранилища типа FC-multipath создаются из интерфейса, включая монтирование блочных устройств и развёртывание файловой системы. Состояние дисков и путей непрерывно опрашивается на каждом сервере кластера, а при сбое подключение восстанавливается автоматически или вручную через инструмент Datastore Doctor.</p> <p>Встроенная инфраструктура открытых ключей. При развёртывании создаётся корневой сертификат инсталляции, сертификаты узлов выпускаются автоматически при добавлении сервера в кластер и удаляются при его выводе. Сертификаты обновляются до истечения срока действия без участия администратора. Для шлюзов подключения выпускаются персональные сертификаты с привязкой к сетевым адресам.</p> <p>Оверлейные сети VXLAN. Администратор создаёт подсети с произвольным идентификатором VNI и настраиваемым MTU, назначает интерфейсы серверов в качестве VTEP, а туннели и правила OpenFlow формируются автоматически при подключении групп портов. Поддерживается взаимодействие с внешним сетевым оборудованием и сторонними VTEP, а служебные интерфейсы серверов можно размещать в VXLAN-сетях для изоляции технологического трафика.</p> <p>Веб-версия панели управления. Управление виртуализацией доступно через стандартный браузер по HTTPS, без установки отдельного приложения администратора.</p> <p>Обновлён клиент VDI: состояние клавиш NumLock и CapsLock синхронизируется с виртуальной машиной, комбинация Ctrl+Alt+Ins передаётся внутрь машины как Ctrl+Alt+Del, кнопки панели инструментов получили подписи, клиент запоминает размер и положение окна. В панели администратора появился поиск по пользователям, а ресурсы, на которые у пользователя нет прав, больше не показываются в списках и навигации. Закрыты 24 ошибки в панели администратора, виджетах, средстве просмотра рабочих столов, синхронизации каталога и работе RADIUS со шлюзами.</p> <p>Обновление устанавливается через Центр обновлений платформы. Полный список изменений: https://docs.inscale.ru/rn-2026/ . Новость на сайте разработчика: https://inscale.ru/inscale-3-1-0/</p> <p>Inscale — платформа серверной виртуализации и VDI на ядре KVM с собственным протоколом доставки рабочего стола. Гипервизор устанавливается на «голое железо», серверы и рабочие места управляются из единой консоли. Платформа применяется для замещения VMware, Citrix и Microsoft Hyper-V и поставляется через сеть авторизованных партнёров и дистрибьюторов.</p> Компания «Лаборатория Виртуализации» выпустила версию 3.1.0 платформы Inscale — российского решения для серверной … message https://www.itweek.ru/themes/detail.php?ID=235775 Wed, 21 Oct 2026 11:51:36 +0300 <p><em>Команды, создающие платформу разработки с нуля, гораздо чаще сообщают об отсутствии четкой стратегии. Поскольку искусственный интеллект упрощает создание платформы, обоснование подхода имеет большее значение, чем когда-либо, пишет на портале The New Stack Шарлотта Флеминг, исследователь индустрии разработки в Octopus Deploy.</em></p> <p>Выбор между созданием и покупкой обычно рассматривается как инженерный компромисс, где время разработчиков сопоставляется с затратами на интеграцию и миграцию, а также с контролем и бременем обслуживания индивидуальной сборки. Когда мы готовили <a href="https://i.octopus.com/whitepapers/2026-future-of-platform-engineering.pdf">отчет</a> «2026 Future of Platform Engineering», мы не пытались разрешить этот компромисс; мы пытались выяснить, раскрывают ли решения о выборе поставщиков функций платформы что-либо о команде, работающей над платформой. Оказывается, раскрывают. На основе ответов 379 специалистов по платформам мы обнаружили, что команды, преимущественно создающие платформу с нуля, реже имеют четкую стратегию и достигают меньшего количества целей, поставленных перед платформой.</p> <p>Этот выбор значительно изменился с появлением ИИ. Агенты сделали создание платформы проще, чем когда-либо; внутренний инструмент, на создание которого раньше уходили месяцы, теперь можно собрать за один день. Но ИИ избавляет от необходимости писать код, а не от работы по его управлению. Поддержка, обновления и контроль, связанные с функцией, созданной с нуля, остаются, в то время как объем изменений, проходящих через конвейер, увеличивается. Это делает вопрос «создать или купить» более актуальным, чем когда-либо.</p> <p>Мы спросили платформенные команды, как они поддерживают каждую функцию, которой владеют: созданную с нуля, созданную на основе существующего шаблона или приобретенную в качестве базового инструмента. Команды, чей основной подход — создание с нуля, гораздо чаще сообщают об отсутствии четкой стратегии для своей платформы. Эта взаимосвязь выражена ярко, однако ситуация не сводится к простой формуле: «разработка с нуля означает отсутствие плана».</p> <h3>Большинство команд покупают и выбирают осознанно</h3> <p>Мы обнаружили, что использование базового инструмента является наиболее распространенным среди функций, которыми владеют платформенные команды,: 51,3% респондентов заявили, что это их основной подход, далее следуют создание на основе существующего шаблона (31,2%) и создание с нуля (17,5%). Высокоэффективные команды чаще используют инструменты (58,8%), чем создают решения на основе шаблонов (47,8%) или с нуля (33,3%). Это может отражать более широкую тенденцию достижения зрелости: по мере того, как архитектурные решения в области платформенной инженерии становятся более четкими, команды все чаще стандартизируют инструменты, а не поддерживают собственные. Дэвид Туит <a href="https://roadie.io/blog/platform-engineering-in-2026-why-diy-is-dead/">описал</a> эту альтернативу как «ловушку создать или купить», когда команды, вынужденные поддерживать пользовательские интерфейсы, тратят от 6 до 18 месяцев на обновления и операционные издержки вместо того, чтобы приносить пользу.</p> <p>#IMAGE_235776#</p> <p>Исключения — вот где начинается самое интересное. Локальные среды разработки, проекты, создаваемые в один клик, и временные (эфемерные) среды чаще используют шаблоны, чем инструменты, поскольку они привязаны к определенному технологическому стеку и «золотым путям», которые редко предоставляют готовые инструменты. Временные среды заслуживают внимания, поскольку они также показывают, где ИИ хорошо себя зарекомендовал. Команды, чьи платформы предоставляют такие возможности, гораздо чаще сообщали о положительном влиянии ИИ на скорость и стабильность разработки ПО; то же самое касалось покрытия кода и контроля затрат. Среди команд, сообщивших об исключительно положительном эффекте, более трех четвертей имели временные среды разработки.</p> <p>Эта взаимосвязь, вероятно, отражает скорее особенности платформы, чем саму функцию. Команды с временными средами разработки, как правило, работают на широких платформах с различными возможностями автоматизированной разработки, и эта широта сама по себе коррелирует с положительным влиянием ИИ на разработку. Таким образом, временные среды разработки могут быть признаком достаточно зрелой платформы, способной поглощать объем и изменения, генерируемые ИИ, без потери стабильности. Это согласуется с результатами отчета DORA «2025 State of AI-assisted Software Development», согласно которым выгоды для организаций от ИИ зависят от качества платформы: сильные платформы усиливают эффект, а более слабые — ослабляют его.</p> <p>#IMAGE_235777#</p> <p>Функции, которые нарушают эту закономерность, отражают скорее соответствие шаблону, чем нежелание покупать, и доводы, стоящие за этими решениями, подтверждают это. Когда респондентов попросили объяснить логику выбора между созданием и покупкой, наиболее распространенным ответом был анализ затрат и выгод (29,6%), за которым следовали предпочтение открытого исходного кода (28,6%), оценка соответствия требованиям (22,4%), предпочтение коммерческих инструментов (22,4%) и разработка для обеспечения ключевой дифференциации (16,3%). Как резюмировал один из респондентов: «Создавайте то, что делает вас уникальными, покупайте или адаптируйте то, что является стандартом, и всегда учитывайте долгосрочные затраты и привязку к поставщику». Это та же центральная идея, что и в предметно-ориентированном проектировании, которое выделяет основную область, где заказная разработка создает конкурентное преимущество, от вспомогательных и общих областей, где она в основном добавляет сложность и обслуживание тому, что можно было бы купить.</p> <p>#IMAGE_235778#</p> <h3>Подход «создание с нуля»</h3> <p>Учитывая, насколько взвешенно большинство команд подходит к выбору, вопрос формирования стратегии представляет особый интерес. Если классифицировать команды по преобладающему методу, то те, кто создает решения с нуля, примерно в 3,5 раза чаще называют препятствием отсутствие четкой стратегии (57,9%), чем команды, использующие шаблоны (15,6%) или готовые базовые инструменты (16,7%).</p> <p>Здесь также прослеживается связь с использованием ИИ: команды, предпочитающие создание с нуля, чаще применяют ИИ (умеренно или активно) для модернизации унаследованных систем и миграции на другие языки программирования. Налицо четкая закономерность: именно создатели собственных решений активнее всего полагаются на ИИ при их последующем сопровождении. Дело не в том, что они в целом используют ИИ чаще: показатели внедрения, реального влияния и ожидаемых результатов у них такие же, как и у остальных. Разница заключается именно в задачах, возникающих после создания кастомного функционала.</p> <p>#IMAGE_235779#</p> <h3> Сначала создание, решение — потом </h3> <p>Одно из возможных объяснений таково: сначала определяется стратегия, а затем принимается решение о покупке или создании. У команды без четкого вектора развития нет оснований для выбора готового продукта, поэтому она по умолчанию выбирает путь создания. Другая точка зрения гласит, что создание и есть стратегия, а не признак ее отсутствия. Процесс создания помогает выявить проблему и продемонстрировать прогресс еще до того, как команда окончательно определится с назначением платформы.</p> <p>Это интересная трактовка, однако имеющиеся данные не позволяют однозначно сказать, какой подход верен. В <a href="https://www.cio.com/article/196094/an-introduction-to-wardley-value-chain-mapping.html">работе</a> Саймона Уордли, посвященной картированию (mapping), описывается схожая закономерность: команды, не осведомленные о существующих инструментах, склонны создавать собственные решения для проблем, которые уже были более эффективно решены другими.</p> <p>С появлением ИИ разрыв между возникновением идеи и получением работающего инструмента практически исчез. Теперь ИИ-агент может создать специализированный инструмент для управления инцидентами еще до того, как кто-либо вообще задастся вопросом о его необходимости. Создавать стало проще, но вот поддерживать созданные решения — нет. Исследование DORA объясняет, почему это важно: качественные платформы предоставляют определенные возможности и одновременно задают границы их использования — и в условиях разработки с применением ИИ эти границы могут играть решающую роль. В готовые инструменты такие ограничения уже заложены, тогда как платформа, собранная из отдельных компонентов, обладает лишь теми ограничениями, которые кто-то догадался предусмотреть.</p> <p>В любом случае эта закономерность сохраняется. Проблема не в самом создании с нуля. Стратегический просчет возникает тогда, когда создание с нуля выбирается по умолчанию, без веских на то оснований.</p> <h3>Более важный вопрос, чем «создавать или покупать»</h3> <p>Речь не идет о том, чтобы покупать абсолютно всё: мы выяснили, что некоторые функции необходимо создавать с учетом специфики конкретной организации. Важен осознанный подход к покупке. Если команда создает решение с нуля, на это должна быть причина. Когда же команды приобретают готовый инструмент, причина обычно очевидна: практически все покупают решения для четко определенных компонентов платформы, и по мере того, как ИИ-агенты пишут всё больше кода, ценность инструментов, эффективно решающих подобные задачи, только возрастает.</p> Команды, создающие платформу разработки с нуля, гораздо чаще сообщают об отсутствии четкой стратегии. Поскольку … article https://www.itweek.ru/themes/detail.php?ID=235773 Wed, 21 Oct 2026 11:13:51 +0300 <p>Обновление платформы виртуализации часто планируют как небольшую аварию: назначают ночное окно, предупреждают пользователей и надеются к утру вернуть всё в рабочее состояние. Для инфраструктуры, на которой держатся приложения и рабочие места, это слишком высокая цена за обычную эксплуатационную задачу. Стоит стремиться к другому сценарию: службы обновляются по очереди, виртуальные машины продолжают работать, а при ошибке платформа сама возвращается в рабочее состояние. Администратору остаётся устранить причину и повторить попытку.</p> <p>Такое поведение нужно закладывать в архитектуру. Микросервисы позволяют уменьшить масштаб изменений, проверки и автоматический откат ограничивают последствия ошибки. За результат отвечают и разработчик платформы, и тот, кто её эксплуатирует.</p> <h3>Обновлять службы по отдельности</h3> <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> <h3>Если сервер перестал отвечать</h3> <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> <h3>Как разделить ответственность</h3> <p>Разработчик отвечает за поведение продукта: какие изменения применяются отдельно, как проверяется совместимость, что произойдёт при потере связи и как вернётся работоспособность. Если ошибка возникла в поддерживаемом сценарии, заказчик не должен восстанавливать систему в одиночку. Вендор должен предусмотреть автоматический возврат, а за его пределами обеспечить процедуру восстановления и инженерную помощь. Тогда администратор сможет устранить исходную проблему и продолжить обновление.</p> <p>Пользователь отвечает за условия эксплуатации: поддерживаемую конфигурацию, исправную сеть и хранилище, резервные копии, свободные ресурсы и соблюдение порядка обновления. Начинать стоит со стенда с нагрузкой, похожей на рабочую, затем переходить к ограниченной части производственной среды. Расширять обновление можно после проверки результата. Запас мощности для миграции нужен до начала работ.</p> <p>Если исправление безопасности требует нового запуска ВМ или перезапуска узла, отсрочка может сохранять уязвимость. Срок применения нужно выбирать с учётом риска, согласовывать с владельцами приложений и заранее сообщать пользователям. Установленный пакет ещё не означает, что защита уже действует.</p> <p>У поставщика стоит просить показать весь процесс: подготовку, переключение службы, потерю связи с узлом и восстановление. Проверить, что происходит с приложениями, что видно в консоли и что потребуется от администратора. Это делает границы ответственности конкретными до первой нештатной ситуации.</p> <p>Для критичной инфраструктуры обновление без прерывания сервиса должно стать требованием к архитектуре и эксплуатации. Микросервисы позволяют менять платформу небольшими частями, автоматический откат возвращает её в рабочее состояние при предусмотренных сбоях. А согласованные процедуры и участие вендора помогают сохранить контроль там, где автоматика закончилась.</p> <p>#IMAGE_235774#</p> Обновление платформы виртуализации часто планируют как небольшую аварию: назначают ночное окно, предупреждают пользователей … article Линар Ихсанов, директор по продукту “Лаборатории Виртуализации” https://www.itweek.ru/themes/detail.php?ID=235771 Tue, 20 Oct 2026 16:34:58 +0300 <p>Институт статистических исследований и экономики знаний (ИСИЭЗ) НИУ ВШЭ проанализировал на основе данных Росстата по итогам 2025 года, как организации распределяют затраты на инновационную деятельность.</p> <p>В 2025 г. крупные и средние российские организации продолжили активно инвестировать в инновации: объем таких затрат достиг 4,5 трлн руб. Их интенсивность (отношение к общему объему продаж) составила 2,7% — выше, чем в большинстве европейских стран: например, в Финляндии она равна 2,1%, во Франции — 2%, в Австрии и Норвегии — 1,9%, в Италии — 0,9%.</p> <p>Затраты на инновации в 2025 г. почти поровну распределились между сферой услуг (49,7%) и промышленным производством (48,4%); на сельское хозяйство и строительство пришлось чуть менее 2%. Среди отраслей сферы услуг по объему инвестиций лидируют научные исследования и разработки (19,5% всех затрат на инновации) и телекоммуникации и ИТ (19%). Среди обрабатывающих отраслей выделяются производители компьютеров, электронных и оптических изделий (6,3%), химических веществ и продуктов (5,9%), кокса и нефтепродуктов (5,8%) и др.</p> <p>В целом крупные и средние организации прежде всего закупают машины и оборудование (38,8% затрат на инновации); на исследования и разработки приходится 29,2% средств. Обратное соотношение — в высокотехнологичных отраслях обрабатывающей промышленности и сфере услуг: здесь на научную деятельность направляют 44,7% и 36,2% затрат соответственно, а на обновление материально-технической базы — менее 30%.</p> <p>Собственные средства организаций остаются главным источником финансирования инноваций: в 2025 г. на них пришлось 62,4% затрат (в промышленном производстве — 67,9%). Бюджетные средства обеспечивают свыше пятой части затрат: 20% поступает из федерального бюджета, еще 2,6% — из региональных и местных бюджетов. Кредиты и займы покрыли 9,2% расходов на инновации. Вклад остальных источников минимален.</p> <p>Несмотря на сохраняющийся высокий уровень затрат на инновации, финансовые ограничения остаются одним из главных препятствий для дальнейшего расширения инновационной деятельности крупных и средних организаций. Высокую стоимость нововведений и нехватку собственных средств назвали значимыми сдерживающими факторами более трети организаций. Трудности с привлечением внешнего финансирования — государственной поддержки и заемных средств — компании отмечали заметно реже.</p> Институт статистических исследований и экономики знаний (ИСИЭЗ) НИУ ВШЭ проанализировал на основе данных Росстата … message https://www.itweek.ru/themes/detail.php?ID=235770 Tue, 20 Oct 2026 10:06:06 +0300 <p><em>На виртуальном аналитическом саммите, проведенном 8 октября Linux Foundation под эгидой ценности технологий, Фонд объединил токеномику, FinOps, управление ИТ-активами (ITAM) и открытую спецификацию затрат и использования FinOps (FinOps Open Cost and Usage Specification, FOCUS) вокруг более масштабного вопроса: как предприятия могут связать стоимость искусственного интеллекта с создаваемой им бизнес-ценностью? Кевин Огунсуа, главный аналитик </em><em>Forrester</em><em>, выделяет в корпоративном блоге семь обсуждавшихся тем.</em></p> <h3>1. TCA может стать преемником TCO для ИИ</h3> <p>Возможно, наиболее полезным новым термином, введенном на саммите, является TCA (Total Cost of AI, общая стоимость ИИ). Ключевая идея заключается в том, что токены составляют лишь от 10 до 25% от общих затрат на ИИ, если учитывать более широкий спектр затрат. TCA расширяет общий знаменатель до инфраструктуры, энергии, капитала, ПО и лицензирования, рабочей силы и других затрат, необходимых для производства и потребления ИИ.</p> <p>На протяжении десятилетий технологические лидеры полагались на TCO (Total Cost of Ownership, общая стоимость владения). Однако TCA может стать более актуальной концепцией для ИИ, поскольку ИИ — это не просто актив, которым можно владеть. Это динамичная система производства и потребления, экономика которой охватывает инфраструктуру, интеллект, людей и результаты.</p> <p>Более того, дискуссия перекочевывает в кабинет финансового директора. Организаторы мероприятия отметили растущее участие CFO в руководстве направления токеномики Фонда и усиление акцента на преобразовании потребления технологий в результаты, которые можно представить в финансовом выражении. Кроме того, Фонд объявил, что предстоящий форум для финансовых директоров будет проходить 8 декабря по правилу Чатем-Хауса (Chatham House Rule), он предоставит важную площадку для финансовых лидеров, чтобы обсудить вопросы распределения затрат, доходов и ценности ИИ.</p> <h3>2. Токеномика — это производство, потребление и ценность, а не только токены</h3> <p>Формирующееся определение токеномики ИИ охватывает все этапы: от преобразования энергии и капитала в возможности ИИ, через потребление этого интеллекта, до получения измеримой бизнес-ценности. Таким образом, инфраструктура, центры обработки данных, ПО, рабочая сила и результаты — все это находится внутри этой экономической системы.</p> <h3>3. У ИИ проблема скорее с ценностью, чем со стоимостью</h3> <p>В <a href="https://www.tokeneconomics.com/state-of-tokenomics/">исследовании</a> «The State of Tokenomics, 2026» приняли участие 472 респондента из 11 отраслей, их суммарная выручка составила 4,6 трлн. долл. Что еще важнее, главный вопрос исследования заключается в том, могут ли предприятия связать потребление и инвестиции в ИИ с измеримыми бизнес-результатами.</p> <p>Это меняет тему обсуждения с «Насколько дешево мы можем использовать ИИ?» на «Какую бизнес-ценность приносят инвестиции?»</p> <h3>4. Мультимодельный ИИ превращает экономику в архитектурное решение</h3> <p>Предприятия больше не используют ИИ через один канал. Фактически, согласно опросу, 96% используют передовые модели, 87% — облачных провайдеров, а 64% — ИИ, встроенный в существующие продукты, причем половина работает как минимум по четырем из шести каналов ИИ.</p> <p>По мере фрагментации ИИ выбор модели, маршрутизация, архитектура, производительность и экономика все чаще становятся неотъемлемой частью принятия правильного архитектурного решения, оптимизирующего инициативу.</p> <h3>5. Маршрутизация моделей становится рычагом повышения ценности</h3> <p>Маршрутизация моделей обеспечивает механизм сопоставления рабочих нагрузок с соответствующими моделями, а не автоматическую отправку каждой задачи наиболее эффективному или дорогому варианту. Соответственно, согласно материалам саммита, 86% компаний оценивают или используют маршрутизаторы моделей.</p> <p>Открывающаяся возможность заключается в динамической оптимизации по показателям стоимости, производительности, риска и ценности.</p> <h3>6. FinOps, управление ИТ-финансами и токеномика сближаются</h3> <p>ИИ выходит за рамки традиционных границ управления технологиями. В частности, FinOps рассматривает потребление и оптимизацию; ITAM включает в себя активы, контракты, лицензии и права; управление ИТ-финансами (ITFM) связывает экономику технологий с финансовым менеджментом; токеномика расширяет взгляд на производство, потребление и ценность ИИ. В результате дискуссия расширяется до управления ценностью технологий, а не заменяет одну дисциплину другой.</p> <h3>7. FOCUS становится финансовым уровнем данных для ИИ</h3> <p>Управлению затратами и ценностью необходимы нормализованные данные. В этом контексте FOCUS — это открытая спецификация, унифицирующая биллинговые данные в сферах ИИ, облачных технологий, дата-центров и решений различных вендоров, что позволяет снизить сложность и обеспечить единый подход к оценке ценности технологий. Она обеспечивает важную основу для связи затрат, использования, ценообразования, атрибуции и, в конечном итоге, финансовой подотчетности. Однако следующая задача — перевести эти данные на язык, понятный финансовому отделу: бизнес-единицы, центры затрат, продукты, правила распределения, план счетов и, в конечном итоге, главная книга. На саммите был явно поднят вопрос о сопоставлении общих прямых и косвенных затрат с главной книгой и планом счетов для сокращения ручного распределения в конце месяца.</p> <h3>Итог: цель — управление ценностью ИИ</h3> <p>В конечном счете, главный посыл саммита выходит за рамки токеномики. Компаниям необходимо связать воедино этапы производства и потребления, а также показатели затрат и ценности. Методология TCA позволяет использовать более полный знаменатель для расчетов, в то время как стандарт FOCUS помогает унифицировать исходные данные. Такие дисциплины, как FinOps, ITAM, ITFM и токеномика, служат важными дополнениями к этому подходу. Наконец, вовлечение финансового директора обеспечивает финансовую подотчетность.</p> <p>Таким образом, следующим рубежом становится управление ценностью ИИ — связывание совокупных затрат на ИИ с измеримой ценностью, которую он создает.</p> На виртуальном аналитическом саммите, проведенном 8 октября Linux Foundation под эгидой ценности технологий, Фонд … article https://www.itweek.ru/themes/detail.php?ID=235768 Tue, 20 Oct 2026 09:45:21 +0300 <p>Мы живем в интересное время. С одной стороны, российские компании ускоренно мигрируют с SAP, Microsoft Dynamics и других западных платформ на «1С», «Галактику» и нишевые отечественные решения. С другой — спор о том, стоит ли менять и когда менять, не утихает. По<a href="https://www.tadviser.ru/a/56070" title="https://www.tadviser.ru/a/56070"> данным</a> TAdviser, в сегменте крупных коммерческих предприятий значительную долю занимают ERP-решения от SAP и Microsoft. Это означает, что больше половины компаний по-прежнему работают на «недружественных» платформах. Но арифметика миграции сложнее, чем кажется.</p> <h3>Почему импортозамещение ERP буксует</h3> <p>После разговора с рядом экспертов и ИТ-руководителей картина становится ясной. Главный тормоз — не технологическая неспособность, а отсутствие четкой бизнес-цели на старте. Если заказчик приходит и говорит: «Сделайте нам как в SAP, только на „1С“» — проект почти гарантированно выходит за бюджет в полтора раза и за календарь — минимум на треть. Миграция без бизнес-цели умирает еще на старте, просто этого никто не замечает до середины проекта.</p> <p>Проблема глубже, чем кажется. Многие компании привыкли идти за платформой: работая на SAP, они пытались адаптировать бизнес под его стандартные процессы, хоть это почти никогда не получалось, ведь по статистике каждое корпоративное внедрение SAP кастомизировано на десятки процентов по сравнению с типовым решением. Переходя на «1С», компании пытаются заставить платформу имитировать «старую». Повторить SAP на «1С» невозможно. SAP — процессно-ориентированная система, «1С» — объектно-ориентированная. Попытка копирования дает результат, который не похож ни на SAP, ни на «1С». Платформы разные, и пытаться воспроизвести старую систему на новой — нерационально, бессмысленно.</p> <p>Еще одна ловушка — тотальный перенос исторических данных. Иллюзия, что все данные за десять лет пригодятся в новой системе, не оправдывается статистикой потребления. По моему опыту, используется от силы <nobr>10-20%.</nobr> Разумная альтернатива — упаковать старую систему в режим архивного чтения и открывать ее по мере необходимости. Полная миграция истории — это десятки миллионов рублей и месяцы работы, которые почти никогда не окупаются.</p> <p>Отдельная история — архитектура. Если привлекать моновендорных подрядчиков, ориентированных только на «1С», они построят архитектуру, привязанную к конкретному технологическому партнеру. Это работает до первого серьезного изменения регуляторики или бизнес-модели. Выход — работать либо с крупным интегратором, умеющим строить корпоративную архитектуру без привязки к одной платформе, либо с командой из профессионального консалтинга. Но думать об этом нужно до старта, а не в момент, когда идет приемка результатов проекта.</p> <h3>Кейс, который сработал</h3> <p>Приведу пример успешной миграции. Крупная транспортная компания, оказывающая услуги производственного характера, вынужденно уходила с SAP. Проект стартовал «в огне», с болью и слезами у бизнеса. Однако менее чем за год был обеспечен перевод регламентированного периметра так, чтобы вести учет уже в новой системе. Еще примерно полгода у компании ушло на стабилизацию и дообогащение нереализованными в «старой» системе бизнес-процессами. Ключевое решение — параллельно с миграцией был сформирован собственный центр компетенций. Логика простая — ИТ-директор понимал, что нельзя полагаться только на команду интегратора. Подрядчик должен уйти, а система — не упасть.</p> <p>Другой пример — «Ригла», сеть из более чем 7000 аптек. Компания <a href="https://www.retail.ru/cases/10-tysyach-tochek-za-3-dnya-rigla-sokratila-srok-zakrytiya-rsbu/" title="https://www.retail.ru/cases/10-tysyach-tochek-za-3-dnya-rigla-sokratila-srok-zakrytiya-rsbu/">мигрировала</a> с Microsoft Navision на «1С», но не стала просто переносить систему. Вместо этого был спроектирован единый информационный ландшафт. Шесть разрозненных баз «1С» свели в одну, интегрировали обмен с операционными системами. Результат — закрытие месяца сократилось с 15 рабочих дней до 6, с целевым показателем в 3 дня. Численность финансовой команды не выросла, хотя сеть продолжала расти.</p> <h3>Почему привычная модель расчета ТСО не работает</h3> <p>Теперь о деньгах. Традиционно проекты миграции оценивают через TCO (совокупную стоимость владения). Метод полезный, но у него есть фундаментальный изъян: он считает только затраты, но не считает ценность. TCO отвечает на вопрос: «Сколько будет стоить переход?», но не отвечает на вопрос: «Что мы потеряем, если не перейдем?».</p> <p>Приведу конкретный пример: кассовое решение, написанное на устаревшем стеке. Вендоров нет, компаний, поддерживающих решение, — тоже нет. Чтобы оно продолжало функционировать, нужен штат разработчиков и сопровождения. При этом с 1 сентября вышло требование поддержать мессенджер MAX как средство авторизации в программе лояльности на кассе. До этого — маркировка, еще раньше — <nobr>54-ФЗ,</nobr> <nobr>152-ФЗ,</nobr> ТТТ. Каждое регуляторное изменение — это новые человеко-часы. Если посчитать суммарно, вендорское решение, пусть и с vendor lock, оказывается дешевле в этом узком сегменте. Поддержка включена в лицензионный контракт, а регуляторные изменения приходят «в коробке».</p> <p>Есть и формула для такого расчета. Риск наступления критического события умножается на вероятность и на сумму вероятных потерь. Полученная цифра становится обоснованием инвестиций. В текущих условиях вероятность реализации инфраструктурных рисков выросла кратно, поэтому защищать проекты модернизации стало проще. TCO в такой логике считается более агрессивно. Нужно учитывать влияние госорганов, скорость выпуска изменений, риски, связанные с текущим временем.</p> <p>Но остается вопрос — как учитывать в TCO недополученную прибыль из-за того, что бизнес не успевает за изменениями? Однозначного ответа нет. Это та зона, где цифры заканчиваются и начинается управленческое суждение.</p> <h3>TVO как альтернатива ТСО</h3> <p>Как мы видим TCO — это серьезное упрощение. Если менеджер живет только по логике TCO, он упускает стратегическую перспективу. Давайте попробуем рассмотреть понятие Total Value of Opportunity (TVO). Это методология оценки ИТ-проектов, разработанная Gartner в начале <nobr>2000-х.</nobr> Она оценивает проект по пяти измерениям — стратегическое соответствие, влияние на бизнес-процессы, прямая финансовая отдача, архитектурное соответствие и риск. TVO не пытается свести все к одной цифре. Оно создает структуру для разговора между бизнесом и ИТ, где обе стороны говорят на одном языке.</p> <p>Ключевое отличие TVO от TCO — оно допускает, что ценность у разных компаний разная. Для сети магазинов это может быть рост продаж за счет точности пополнения полок. Для фармкомпании — высвобождение людей за счет сокращения времени подготовки регуляторной отчетности. TCO оперирует одним числом. TVO позволяет обсуждать несколько чисел, включая те, что не поддаются немедленной квантификации, но стратегически критичны.</p> <p>Конечно, можно жить в парадигме «пока не припрет — не надо импортозамещаться». Стратегия — это зона компетенции менеджера, но это и ставка. Ты видишь образ будущего и ставишь на него репутацию, карьеру, деньги. Модель «ждать, пока петух клюнет» — самая комфортная для менеджера, но самая невыгодная для бизнеса.</p> <h3>Цена ожидания</h3> <p>Бесспорно, стратегия подождать — это тоже решение, и у него есть своя цена. Она не видна в TCO, потому что не отражена в бюджете. Но она проявляется в трех плоскостях.</p> <p>Первая — регуляторная. Каждый год выходят новые требования. Старая система либо адаптируется (это дорого), либо компания работает вне закона (это риск). Вторая — кадровая. По рыночным оценкам, в России более 300 тыс. «1С»-специалистов, но на рынке их не найти. Когда компания решает мигрировать, ей нужны не просто «1С»-специалисты, а архитекторы, способные спроектировать корпоративный ландшафт. Таких людей на рынке единицы, и они уже заняты. Третья — рыночная. Пока компания ждет, конкуренты перестраивают процессы, сокращают издержки, ускоряют отчетность. Разрыв накапливается.</p> <p>Не надо забывать, что помимо замещения нужно очень быстро бежать, хотя бы для того, чтобы оставаться на месте. Потому что нас нагоняют новые технологии, новые изменения регуляторов, бизнес-процессов и всего остального.</p> <h3>Что делать</h3> <p>Инвестировать нужно не в покупку софта, а в выращивание собственных специалистов, которые будут хотеть работать с вами и смогут аккумулировать знания так, чтобы они использовались повторно. Формировать центр компетенций параллельно с проектом миграции, а не после. Считать не только TCO, но и TVO — особенно когда речь идет о стратегических решениях, где цена ошибки выше цены экономии. При выборе подрядчика смотреть не на бренд и список проектов, а на конкретные ФИО, которые участвовали в этих проектах. Отраслевая экспертиза в любой отрасли приходит с конкретными физическими лицами из компании в компанию.</p> <p>И главное — определять бизнес-цель до старта проекта. Не перейти на «1С», потому что SAP ушел, а сократить закрытие месяца до трех дней или обеспечить бесперебойную работу касс при смене регуляторных требований. Без этого любая миграция — просто смена вывески.</p> <p>Но остается открытым вопрос: если рынок отраслевого софта еще не сформирован и сам вынужден трансформироваться под влиянием искусственного интеллекта, может ли компания вообще позволить себе ждать, пока этот стандарт появится?</p> <p>#IMAGE_235769#</p> Мы живем в интересное время. С одной стороны, российские компании ускоренно мигрируют с SAP, Microsoft … article Алексей Стоянов, руководитель практики “1С” компании “Рексофт” https://www.itweek.ru/themes/detail.php?ID=235765 Mon, 19 Oct 2026 16:01:31 +0300 <p>СберТех расширил функциональность своей флагманской системы управления базами данных (СУБД) Platform V Pangolin DB с учетом потребностей крупного бизнеса. В решении реализован новый механизм хранения данных, который позволяет сократить занимаемый объём на серверах до двух раз, а использование дискового пространства под журнал фиксации транзакций — от пяти до двадцати раз.</p> <p>Обновление актуально для компаний, строящих ИТ-инфраструктуру на базе PostgreSQL-совместимых СУБД. Новый способ хранения снижает объём обращений к диску и объём хранения за счёт исключения дублирования данных и индексов, выноса неактуальных версий строк в отдельный журнал. Это позволяет эффективнее использовать установленное серверное оборудование, формировать запас производительности для пиковых нагрузок и ускоряет восстановление системы после сбоя.</p> <p>Максим Тятюшев, генеральный директор СберТеха, отметил: «С новой функциональностью Platform V Pangolin DB отлично подойдет для оптимизации массивов корпоративных данных на предприятиях из разных отраслей промышленности, ОПК, госсектора, финансов, телекоммуникаций, ретейла и онлайн-торговли. Решение помогает высвободить внутренние ресурсы для хранения растущих объемов информации и повышения производительности систем. На базе СУБД компании смогут развивать свой ИТ-ландшафт без избыточных ресурсозатрат на расширение и обслуживание серверного парка».</p> <p>Platform V Pangolin DB — реляционная СУБД для высоконагруженных систем с повышенными требованиями к безопасности и надёжности, входит в продуктовый портфель СберТеха по работе с данными. Решение разработано на основе PostgreSQL и содержит ряд важных доработок, позволяющих его использовать в масштабах корпораций. СУБД внесена в реестр российского ПО, сертифицирована ФСТЭК и уже доказала свою эффективность работой в ряде крупнейших компаний России. Более 150 тысяч инсталляций Platform V Pangolin DB успешно эксплуатируются в составе сервисов и приложений с различным уровнем нагрузки и критичности.</p> СберТех расширил функциональность своей флагманской системы управления базами данных (СУБД) Platform V Pangolin … message https://www.itweek.ru/themes/detail.php?ID=235764 Mon, 19 Oct 2026 16:00:17 +0300 <p>Эксперты STAQ, российской платформы для цифровизации бизнес-процессов, выделили пять ошибок при выборе платформенных решений в 2026 году, которые могут увеличить расходы, затянуть внедрение и снизить эффект автоматизации. В их число вошли выбор по списку функций, недостаточная проверка интеграций, оценка только начальной стоимости, завышенные ожидания от ИИ и невнимание к условиям внедрения и поддержки.</p> <p>Выбор платформы затрагивает работу ряда подразделений. Производству нужно обслуживать оборудование, сервисной службе — распределять заявки и курировать сроки, руководству — видеть результаты и затраты. ИТ-команда отвечает за совместимость с системами и устойчивость инфраструктуры. Если все требования не согласовать до покупки, ограничения могут обнаружиться после запуска, и устранение потребует дополнительных ресурсов.</p> <p>Первая ошибка — сравнивать возможности продуктов, не определив, какой процесс нужно улучшить. Наличие мобильного приложения, аналитики или конструктора процессов не объясняет, как изменится работа сотрудников. Например, предприятие выбирает платформу для ускорения ремонта, но оценивает только удобство регистрации заявок. Основное время уходит на согласование работ и поиск запчастей. После внедрения обращения создаются быстрее, но длительность простоя остается прежней. Для избежания такой ситуации, нужно заранее описать путь задачи от возникновения до выполнения, найти причины задержек, выбрать показатели для оценки результата.</p> <p>Вторая ошибка — откладывать проверку интеграций до начала внедрения. Заявленную возможность подключения к ERP, сервис-деску или оборудованию необходимо проверить в условиях заказчика. Значение имеют версии систем, состав передаваемых данных, права доступа и порядок работы при потере связи. Если эти вопросы остаются без внимания, могут возникнуть дубли заявок, расхождения в статусах и задержки уведомлений. Сотрудникам придётся перепроверять информацию вручную, а ИТ-службе — выполнять незапланированные доработки. До покупки важно проверить полный сценарий: от поступления события из внешней системы до назначения исполнителя и передачи результата выполненной работы. </p> <p>Третья ошибка — оценивать решение только по начальной стоимости. При сравнении предложений компания может ориентироваться на цену лицензии, не учитывая перенос данных, настройку интеграций, обучение и сопровождение. Дополнительные расходы становятся особенно заметны при подключении новых подразделений и площадок. Проект, который укладывался в бюджет на старте, требует новых вложений, а его расширение приходится откладывать. Снизить этот риск помогает расчёт полной стоимости владения за одинаковый период для всех рассматриваемых решений. </p> <p>Четвёртая ошибка — выбирать платформу ради ИИ, не оценив готовность собственных данных. Интеллектуальный помощник может классифицировать обращения, находить похожие инциденты и предлагать дальнейшие действия. Для этого ему нужны корректные сведения об объектах, история заявок и результаты работ. Если информация неполна или противоречива, сотрудники будут тратить время на исправление маршрутизации и проверку рекомендаций. До выбора решения следует определить задачу для ИИ и проверить её выполнение на данных компании. Оценивать нужно правильность обработки обращений, число ручных исправлений и изменение сроков работы. </p> <p>Пятая ошибка — недостаточно оценивать команду, которая будет внедрять и сопровождать платформу. Для запуска необходимо обследовать процессы, подготовить данные и обучить пользователей. Если обязанности заказчика, вендора и интегратора не распределены, часть работ может остаться без ответственного. Это приводит к переносу сроков, спорам при приёмке и дополнительной нагрузке на внутреннюю ИТ-службу после запуска. При выборе поставщика важно оценить его опыт в похожих проектах, доступность специалистов и готовность помочь с проработкой требований. </p> <p>Причины таких ошибок связаны с нехваткой времени на подготовку, недостаточным опытом внедрения и разным представлением участников о будущем процессе. Каждое подразделение хорошо знает собственный участок, но может не учитывать, какие сведения и действия нужны коллегам. </p> <p>STAQ рекомендует начинать выбор с формирования рабочей группы, в которую входят владелец процесса, представители ИТ, информационной безопасности и будущие пользователи. Вместе с поставщиком они должны определить границы проекта, интеграции, ожидаемый результат и порядок его проверки. </p> <p>Следующий этап — пилот на одном объекте. До запуска фиксируют исходные показатели, потом оценивают изменения при сопоставимой нагрузке: время обработки задач, соблюдение сроков, объём ручной работы и затраты. </p> <p>«Я бы предложил заказчику проверить, как платформа поведёт себя, когда привычный порядок работы изменится: сменится подрядчик, появится новая площадка или потребуется пересмотреть правила обслуживания. В этот момент станет понятно, насколько компания свободна в развитии своего решения и сколько ей будет стоить следующий шаг. Задача вендора — заранее объяснить эти условия, включая ограничения продукта. Заказчик должен понимать, какие изменения он сможет провести своими силами и где ему потребуется наша помощь», — прокомментировал Евгений Гусев, генеральный директор STAQ.</p> Эксперты STAQ, российской платформы для цифровизации бизнес-процессов, выделили пять ошибок при выборе платформенных решений … message https://www.itweek.ru/themes/detail.php?ID=235762 Mon, 19 Oct 2026 10:29:47 +0300 <p><em>Использование искусственного интеллекта в государственном секторе расширяется, однако проблемы с данными, устаревшими системами и механизмами управления сдерживают эффективное масштабирование этой технологии, отмечают опрошенные порталом </em><em>AI</em> <em>Business</em> <em>эксперты.</em></p> <p>Государственные структуры переходят от экспериментов с ИИ к его полномасштабному внедрению, отчасти под давлением общественного запроса на более оперативное оказание услуг и ощутимые результаты — запроса, темпы роста которого опережают возможности самих ведомств.</p> <p>Согласно недавнему глобальному <a href="https://www.capgemini.com/wp-content/uploads/2026/09/CRI_Data-and-AI-in-Public-Sector_Research-Brief.pdf">исследованию</a> Capgemini Research Institute «Data and AI in government», охватившему 600 руководителей высшего звена организаций госсектора, чуть более половины государственных организаций изучают возможности, проводят пилотные проекты или уже внедряют агентный ИИ (системы, способные самостоятельно принимать решения и выполнять действия).</p> <p>Тем не менее, темпы внедрения зачастую опережают развитие систем управления и контроля, необходимых для регулирования работы таких ИИ-агентов: менее четверти респондентов заявили, что их практики ответственного использования ИИ успевают за скоростью развертывания этих инструментов.</p> <p>Марк Рейнхардт, руководитель глобального направления по работе с государственным сектором компании Capgemini, отмечает, что корни этой проблемы уходят в давние трудности, связанные с государственными технологическими системами. «Организации госсектора годами сталкиваются с проблемами устаревшей инфраструктуры, использованием унаследованных систем, сложностями обеспечения совместимости и вопросами управления, — поясняет он. — С появлением ИИ, и в особенности агентного ИИ, решение этих задач стало критически важным».</p> <h3>Управление агентным ИИ</h3> <p>По словам Рейнхардта, главным препятствием является отсутствие надлежащего фундамента данных. В случае с агентным ИИ эта проблема может усугубляться, поскольку таким системам требуется доступ к широкому спектру информации и других систем.</p> <p>Лора Гилберт, руководитель программы " AI for Government" в лондонском Tony Blair Institute for Global Change, соглашается с тем, что проблема кроется в данных, лежащих в основе моделей. «По моему опыту, правительства сдерживает вовсе не сама технология, — отметила она. — Настоящий разрыв наблюдается на уровне фундаментальных основ».</p> <p>Она также указывает на проблему нехватки компетенций и неуверенности в собственных силах: «Многие правительства передали значительную часть своих технических функций на аутсорсинг, из-за чего им трудно оценить, что реально осуществимо, что безопасно, а что им навязывают с преувеличенными обещаниями. Никто точно не знает, как решить вопрос ответственности при использовании агентного ИИ: кто отвечает за действия, совершенные ПО? У государственных служащих отсутствуют стимулы идти на риск и внедрять инновации». Поэтому ведомствам необходимо внедрить адресные механизмы контроля, ограничивающие сферу действия ИИ-агентов и снижающие риски, но не препятствующие их эффективному использованию. На практике это означает, что государственные органы должны четко определить, какие решения агент может принимать самостоятельно, к каким данным и системам он имеет доступ и в каких случаях управление необходимо передать человеку.</p> <p>«Правительствам следует сосредоточиться на создании систем управления данными, механизмов контроля и подотчетности, которые позволят ответственно масштабировать технологии ИИ и обеспечивать ощутимую пользу для общества, — считает Рейнхардт. — Кроме того, разумеется, необходимо модернизировать устаревшие системы — особенно те, архитектура которых изначально не предусматривала взаимодействия через API и, следовательно, интеграции с агентами».</p> <h3>Сферы внедрения ИИ-агентов в госсекторе</h3> <p>На данном этапе наиболее подходящими сферами применения могут стать задачи, где агенты способны автоматизировать повторяющиеся процессы с большими объемами данных, не принимая при этом решений, способных существенно повлиять на жизнь граждан.</p> <p>В качестве примеров таких задач Рейнхардт называет административные процедуры, обработку документов, ведение дел, внутренние ИТ-процессы, а также выполнение рутинных рабочих операций и согласование документов.</p> <p>Гилберт также высказывается в пользу начала работы с процессов, характеризующихся низким уровнем риска и большими объемами операций. По ее словам, такие внутренние задачи, как обработка корреспонденции, первичная сортировка дел или обобщение доказательной базы, отлично подходят для получения необходимого опыта, «поскольку ошибки здесь можно исправить, а экономия времени очевидна».</p> <p>Это позволит сформировать необходимую уверенность и доказательную базу для перехода к более ответственным задачам, непосредственно затрагивающим интересы граждан. «На начальном этапе важно понять разницу между ситуациями, которые можно сравнить с дверью, открывающейся в обе стороны (ошибки обратимы), и ситуациями, напоминающими дверь, открывающуюся только в одну сторону (ошибки необратимы)», — поясняет Гилберт.</p> <p>Однако уровень риска существенно варьируется в зависимости от сценария использования, а сохранение доверия общественности является для государственных органов ключевой задачей. «Ошибки ИИ, затрагивающие жизнь и благополучие граждан, подрывают доверие к государственным институтам и службам и, вероятно, могут затормозить дальнейшее внедрение этой важнейшей технологии, помогающей административным органам справляться с высокой нагрузкой», — подчеркивает Рейнхардт.</p> <p>Следовательно, меры контроля должны соответствовать уровню риска: степень надзора должна зависеть от масштаба последствий и критической важности конкретной задачи, а также — что особенно важно — от потенциальных рисков для граждан.</p> <p>Гилберт выделяет, помимо начала работы с малых и низкорисковых задач, еще один важный приоритет: формирование собственных компетенций внутри организации. «Вам не нужна армия специалистов, — говорит она, — но вам необходима ключевая команда людей, способных создавать, тестировать и подвергать критическому анализу, а также работающих в непосредственной близости от тех, кто принимает решения».</p> Использование искусственного интеллекта в государственном секторе расширяется, однако проблемы с данными, устаревшими … article https://www.itweek.ru/themes/detail.php?ID=235760 Mon, 19 Oct 2026 10:11:36 +0300 <p>Руководитель поручил ИИ-агенту запустить рекламную кампанию. Через минуту получил ответ: «Готово». Возникают вопросы: в каком кабинете появилась кампания, какой бюджет установлен, начались ли показы и где посмотреть подтверждение? При передаче работы человеку эти детали обычно входят в постановку задачи и приёмку. Для ИИ они столь же важны.</p> <p>Агент может быстро прочитать отчёты, подготовить варианты объявлений и выполнить доступные ему операции. Вместе с доступом он получает возможность ошибиться в выборе объекта, неверно понять поручение или повторить действие после сбоя. Уверенный тон ответа ничего из этого не исключает. Контроль целесообразно выстроить вокруг пяти проверок.</p> <h3>1. Определите, что именно вы поручили</h3> <p>Фраза «займись рекламой» оставляет слишком много решений открытыми. Человеку приходится уточнять продукт, бюджет и цель; агенту тоже нужны эти условия. Запишите результат в одной фразе: например, «подготовить три варианта объявления для согласования» или «возобновить одну ранее настроенную кампанию с сохранением её бюджета».</p> <p>Следом укажите границы: какие кабинеты разрешены, какие действия доступны, какие параметры сохраняются и в какой момент работа должна остановиться. Для первого знакомства достаточно анализа и подготовки предложений. Доступ к изменениям можно расширять по мере проверки рабочих сценариев.</p> <p>Такая запись полезна и для команды. Маркетолог понимает, какой результат принимает, технический специалист видит требования к доступам, а руководитель знает, за какие решения отвечает сам.</p> <h3>2. Сверьте кабинет и объект</h3> <p>У агентства могут быть десятки клиентов с похожими названиями кампаний. Вчера помощник работал с одним магазином, сегодня получил поручение по другому. Даже правильное действие в чужом кабинете создаёт проблему.</p> <p>До изменения попросите показать название клиента, конкретную кампанию и её текущее состояние. Название стоит дополнить устойчивым идентификатором из системы. Для руководителя это может выглядеть как короткая карточка: «клиент, кабинет, кампания, действие, бюджет».</p> <p>Важна свежесть сведений. За время подготовки коллега мог изменить настройки. Поэтому окончательная проверка объекта выполняется непосредственно перед действием. Если состояние отличается от согласованного, дальнейший шаг требует уточнения.</p> <h3> 3. Сделайте пределы измеримыми </h3> <p><strong>«</strong>Сильно бюджет не повышать» каждый понимает по-своему. У поручения должны быть конкретные числовые границы и период, к которому они относятся. Отдельно фиксируются доступные операции: подготовка, запуск, остановка, изменение параметров.</p> <p>Условный пример: разрешено подготовить новую кампанию, сохранить её без запуска и показать варианты объявлений. Следующая стадия начнётся после проверки посадочной страницы, целей и суммы расходов. Такой порядок позволяет принять каждую часть работы отдельно.</p> <p>Письменное поручение желательно подкрепить настройками самого подключения: выдать нужные роли, ограничить доступные действия и сохранить журнал. Инструкция в чате помогает объяснить правило, а технические настройки определяют, какие операции действительно доступны.</p> <h3>4. Принимайте результат по фактам</h3> <p>Сообщение агента об успехе полезно как краткая сводка. Для приёмки нужны данные из системы после выполнения. Попросите показать объект, время проверки и изменившиеся параметры. По рекламной кампании это может быть состояние запуска, установленный бюджет и отсутствие лишних изменений.</p> <p>Операцию и её деловой результат стоит проверять отдельно. Кампания может быть создана и при этом ожидать модерации. Разрешённый запуск также не подтверждает получение заявок. Для каждого этапа нужен свой признак: настройки сохранены, показы начались, обращения поступили, качество обращений проверено.</p> <p>Удобный отчёт занимает несколько строк: «что было поручено, что выполнено, чем подтверждено, что ещё ожидается». Если система недоступна, это тоже должно остаться в отчёте. Пробел в проверке важнее красивого завершения разговора.</p> <h3>5. Заранее договоритесь о действиях при сбое</h3> <p>Самая опасная ситуация возникает, когда связь оборвалась в момент изменения. Запрос мог выполниться, хотя ответ до агента не дошёл. Повторная попытка способна создать второй объект или повторить операцию.</p> <p>Поэтому для каждого поручения полезно различать три исхода: выполнение подтверждено, действие точно не выполнено, результат пока неизвестен. В третьем случае сначала проверяют систему и журнал операций. Продолжение зависит от найденного фактического состояния.</p> <p>Для восстановления сохраните исходные параметры и сведения об изменениях. Назначьте человека, который принимает решение при спорном результате, и укажите, как остановить автоматическую работу. Это стоит обсудить до первой операции в рабочем кабинете.</p> <h3>Как начать в своей компании</h3> <p>Выберите один повторяющийся сценарий с понятным результатом. Например, подготовку вариантов объявлений, сбор еженедельной сводки или проверку настроек одной кампании. Описывайте доступы и ожидаемый итог так, чтобы работу мог принять другой сотрудник.</p> <p>На первом этапе сравните результат агента с ручной проверкой. Зафиксируйте, где потребовалось уточнение и сколько времени заняли подготовка, выполнение и приёмка. Расширение доступа имеет смысл после нескольких воспроизводимых рабочих прогонов.</p> <p>Пять вопросов для итоговой проверки: какая задача поручена, в каком объекте выполняется, какие пределы установлены, где подтверждение результата и как действовать при сбое. Ответы превращают работу ИИ в управляемый процесс и помогают команде понимать, где заканчиваются полномочия помощника.</p> <p>#IMAGE_235761#</p> Руководитель поручил ИИ-агенту запустить рекламную кампанию. Через минуту получил ответ: «Готово». Возникают вопросы … article Дмитрий Лукашов, эксперт по искусственному интеллекту Русской школы управления https://www.itweek.ru/themes/detail.php?ID=235757 Fri, 16 Oct 2026 16:45:09 +0300 <p>Институт статистических исследований и экономики знаний (ИСИЭЗ) НИУ ВШЭ проанализировал приоритеты и особенности инновационной деятельности в России и европейских странах по итогам 2025 г.</p> <p>В России уровень инновационной активности определяется преимущественно продуктовыми инновациями — более масштабными и дорогостоящими нововведениями, связанными непосредственно с выпуском новых видов товаров и услуг. Расходы на них в 2,4 раза превышают затраты на процессные инновации, направленные на усовершенствование в основном текущих бизнес-процессов.</p> <p>В европейских странах, напротив, высокий уровень инновационной активности зачастую связан с активной реализацией процессных инноваций, требующих гораздо меньших капитальных вложений. Так, в Германии и Хорватии доля организаций, осуществлявших процессные инновации, практически вдвое выше реализовывавших продуктовые (в Польше — в 2,5 раза, Австрии, Бельгии, Италии — в 1,6, Испании — в 1,5, Финляндии — в 1,3 раза).</p> <p>Интенсификация процессных инноваций может рассматриваться как резерв для роста инновационной активности в отечественной экономике. В России доля организаций, реализующих различные их типы, в <nobr>1,3–2,6</nobr> раза отстает от среднего показателя по ЕС.</p> <p>Приоритеты отечественных и зарубежных организаций при реализации процессных инноваций несколько различаются. В России наиболее распространены нововведения, связанные с разработкой и внедрением новых или усовершенствованных методов обработки и передачи информации в части поддержания и обеспечения информационных и коммуникационных систем (33,3% организаций, имевших завершенные инновации); производства товаров и услуг (31,6%); ведения бизнеса, корпоративного управления, бухгалтерского и финансового учета (24,9%).</p> <p>В среднем по странам ЕС эти типы инноваций также популярны, однако здесь гораздо чаще, чем в России, востребованы и менее затратные типы процессных инноваций — направленные на реализацию организационных и маркетинговых нововведений. Так, новые методы управления трудовыми ресурсами в среднем по странам ЕС внедряли 40,9% организаций, имевших завершенные инновации (против 17,2% в России); маркетинговые методы продвижения, представления и ценообразования товаров — 32,6% (в России — 12,7%); практики деловых отношений и внешних связей — 30,5% (в России — 11,6%).</p> <p>Потенциал развития процессных инноваций в России связан прежде всего с более широким внедрением логистических методов. С учетом географических и климатических особенностей страны это направление особенно актуально, однако такие методы применяют лишь 13,8% инноваторов против 23,2% в среднем по ЕС.</p> <p>Инновационная деятельность в России отличается стремлением к более крупным продуктовым инновациям, обеспечивающим скорейшее обновление выпускаемой продукции и повышение технологической независимости страны. В то же время устойчивый рост инновационной активности во многом зависит и от реализации процессных инноваций. Более интенсивное их внедрение — прежде всего в части логистики и маркетинга — позволило бы значительно поднять общий уровень инновационной активности отечественных организаций.</p> Институт статистических исследований и экономики знаний (ИСИЭЗ) НИУ ВШЭ проанализировал приоритеты и особенности … message https://www.itweek.ru/themes/detail.php?ID=235756 Fri, 16 Oct 2026 16:43:47 +0300 <p>Сбер на конференции ГигаКонф для инженеров объявил об обновлении агентного конвейера GitVerse — в него добавили около 20 новых востребованных разработчиками функций. Агентный конвейер реализован внутри интерфейса GitVerse и поддерживает модель Bring Your Own Key (BYOK). Благодаря ей снижается порог входа в разработку: к новой функциональности получают доступ частные лица и небольшие команды. Теперь они могут вести проекты, используя те же профессиональные инструменты, что и крупный бизнес.</p> <p>Агентный конвейер позволяет автоматизировать цикл разработки с помощью ИИ. Ранее продукт был доступен только крупным организациям в локальной версии (on-premise). Теперь он появился в облачной версии и для физических лиц в формате раннего доступа, который уже знаком пользователям платформы. Для запуска им нужен только API-ключ от моделей. </p> <p>В рамках функционального обновления GitVerse повысилась прозрачность при работе с кодом. Помимо автономного решения задач, появилась интерактивная поддержка агентных сессий. Пользователям видят структуру файлов, с которыми взаимодействует агент, могут загрузить документы или изображения, чтобы, например, строить интерфейсы по макетам. Также предусмотрен выбор нужной <nobr>LLM-модели</nobr> из набора под конкретную задачу.</p> <p>Андрей Белевцев, старший вице-президент, руководитель блока «Технологическое развитие» Сбербанка, отметил: «Рынок разработки меняется стремительно: возможности моделей растут, а требования к скорости выпуска продуктов постоянно повышаются. Наша задача как продуктовой команды — делать технологии максимально удобными и полезными для пользователей — от крупных компаний до стартапов и индивидуальных разработчиков. Агентный конвейер GitVerse предоставляет всем единый набор надёжных инструментов, помогая быстрее создавать, проверять и выпускать качественные продукты».</p> <p>Чтобы начать работу с агентным конвейером, необходимо зайти в раздел задач, выбрать нужный проект и ветку, после чего можно назначить исполнителем не человека, а ИИ-агента — сессия запустится автоматически. Инструменты агента интегрированы во все основные потоки работы: от написания кода и исправления ошибок до запуска приложений и сквозного (end-to-end) тестирования. Сессию с агентом также можно открыть через привычный чат или CI/CD-воркфлоу. </p> <p>Одновременно с конвейером улучшилась работа с задачами. В обновленном трекере стали доступны: управление проектами и досками, настройка статусов и порядка выполнения задач, контрольные вехи с едиными сроками и целями. Появились публичное API задач, обновленная система меток, массовые операции, улучшенные связи между задачами, работа с файлами в комментариях и выгрузка списка задач в табличном виде.</p> Сбер на конференции ГигаКонф для инженеров объявил об обновлении агентного конвейера GitVerse — в него … message https://www.itweek.ru/themes/detail.php?ID=235755 Fri, 16 Oct 2026 16:41:36 +0300 <p>На крупнейшем мероприятии для профессионалов розничной торговли BSS провела секцию, где лидеры ритейла — Спортмастер, SELA, РОЛЬФ и другие — поделились своими кейсами применения ИИ. Эксперты BSS продемонстрировали ИИ-платформу по управлению клиентским опытом, которая находит скрытые сигналы клиентов и превращает их в выручку.</p> <p><nobr>7–8</nobr> октября на Коннектед Ритейл Форуме около 2 000 представителей ритейла, e-commerce и FMCG-брендов обсудили, как выделяться на рынке в 2026 году, привлекать новых покупателей и удерживать существующих.</p> <p>На эти вопросы команда BSS предложила посмотреть через призму ИИ-технологий: оба дня форума на нашем стенде гости знакомились с <nobr>CX-платформой —</nobr> эксперты BSS демонстрировали, как она помогает превращать сигналы клиентов в конкретные действия для роста продаж, удержания и лояльности. </p> <p>Подробнее о том, как устроена работа <nobr>CX-платформы,</nobr> рассказала руководитель направления по развитию голосовых цифровых технологий BSS Валерия Учайкина на секции, организованной совместно с BSS, «ИИ-студия: сквозная ИИ-стратегия в ритейле и на маркетплейсах».</p> <p>Представим: покупатель спрашивает, где его заказ. Звучит как рядовое обращение, которое можно закрыть простым ответом, но <nobr>CX-платформа</nobr> видит и другие сигналы — например, клиент несколько раз заходил в раздел отмены заказа, бросил корзину и после задержки доставки стал реже пользоваться приложением. В совокупности эти признаки могут указывать на риск оттока.</p> <p>Платформа связывает данные из разных каналов, находит закономерности и предлагает действия: например, кому из клиентов стоит позвонить сегодня, кому предложить компенсацию, а кому — персональную скидку на следующую покупку. Она помогает сотрудникам отрабатывать новые сценарии с помощью ИИ-суфлера и агент-тренера, а затем оценивает, изменилось ли поведение покупателей после принятых мер. Часть задач могут выполнять ИИ-агенты, оставляя сотрудникам контроль над важными решениями и работу со сложными случаями.</p> <p>Доклад Валерии стал частью дискуссии, на которой лидеры ритейла из разных сегментов рынка делились опытом применения ИИ. Модератором выступил заместитель генерального директора BSS Василий Жилов — вместе с участниками он обсудил, как внедрять технологии так, чтобы они помогали и бизнесу, и клиентам. </p> <p>Среди представленных кейсов — ИИ-аватары и автоматизация маркетинга, динамическая персонализация ценовых предложений, умные примерочные, онлайн-анализ состояния кожи для подбора косметики, сортировка сырья с помощью компьютерного зрения. Своим опытом поделились представители «Спортмастера», ГК «РОЛЬФ», SELA, 11i Professional, Openface. </p> <p>Компания BSS благодарит коллег за интересные кейсы и всех гостей форума — за продуктивное общение, готовность делиться опытом и интерес к инновациям. Именно так разговоры об ИИ превращаются в конкретные проекты, которые уже повышают продажи и лояльность покупателей!</p> На крупнейшем мероприятии для профессионалов розничной торговли BSS провела секцию, где лидеры ритейла — Спортмастер … message https://www.itweek.ru/themes/detail.php?ID=235754 Fri, 16 Oct 2026 14:30:11 +0300 <p>На ГигаКонф для инженеров Сбер представил единый дистрибутив среды разработки GigaIDE, сделав востребованную функциональность доступной для индивидуальных разработчиков и небольших команд.</p> <p>Благодаря единому дистрибутиву легко переключаться между режимами Pro и Community: достаточно активировать trial или подписку — и среда мгновенно получает Pro-функциональность без переустановки. Корпоративные пользователи могут гибко управлять затратами: инженер для повседневной работы остаётся в Community, а для отладки нагруженного модуля переключается в режим Pro.</p> <p>До выпуска единого дистрибутива GigaIDE предлагалась в двух обособленных форматах. Режим Community давал только базовую поддержку Java, Python и JavaScript и работу с базами данных. Он подходил для повседневного кодинга, пет-проектов и обучения, но продвинутые инструменты были доступны только в Pro-лицензии. Pro-режим, включающий интеграцию с корпоративными контурами безопасности, локальным и облачным хранением кода, маркетплейсом проверенных плагинов и расширенными средствами для СУБД, в свою очередь, был открыт исключительно для корпоративных клиентов. </p> <p>Андрей Белевцев, старший вице-президент, руководитель блока «Технологическое развитие» Сбербанка, отметил: «GigaIDE объединяет персональную и корпоративную разработку в единой среде. Разработчик или студент получает те же базовые возможности для отладки, тестирования и контроля безопасности, что и команды крупных компаний. Это упрощает повседневную работу: не нужно отдельно настраивать окружение, подбирать инструменты и вручную выстраивать процессы проверки кода. В результате больше времени остаётся на саму задачу, а начинающие специалисты и небольшие команды получают возможность работать по тем же практикам, что используются в промышленной разработке».</p> <p>Единый дистрибутив размещён на ИИ-платформе GitVerse. Pro-функциональность для физических лиц будет разворачиваться постепенно и станет доступна в полном объёме до конца 2026 года. Уже сейчас индивидуальным пользователям доступны готовые инструменты для Java, фреймворк для сайтов на Python (Django), всё необходимое для работы с веб-интерфейсами, встроенный редактор запросов к базам данных и расширения для них.</p> На ГигаКонф для инженеров Сбер представил единый дистрибутив среды разработки GigaIDE, сделав востребованную … message https://www.itweek.ru/themes/detail.php?ID=235753 Fri, 16 Oct 2026 14:27:03 +0300 <p>Positive Technologies представила коммерческую версию PT Security Lakehouse, решения для хранения и анализа больших данных, на котором два года работают собственные продукты компании. Заказчики смогут развернуть его в своей инфраструктуре. Платформа собирает в одном месте данные из разных средств защиты и дает работать с ними аналитикам SOC, разработчикам и ИИ-моделям.</p> <p>В большинстве компаний данные ИБ разнесены по разным системам: у каждого средства защиты своя база, а в SIEM могут попадать не все события. Из-за этого сложно увидеть атаку, которая проявляется на стыке сегментов. Например, когда программа на рабочей станции устанавливает сетевое соединение по нехарактерному для нее протоколу, заметить это можно, только если одновременно видеть поведение на устройстве и сетевую активность. Та же разрозненность ограничивает ИИ-агентов: чтобы самостоятельно расследовать инцидент, агенту нужен доступ к полной истории событий из всех источников, а не к выборке из одной системы.</p> <p>«Данные ИБ в компаниях живут в отдельных системах, и каждая видит только свой участок. Именно в это упираются и расследование атак, которые проходят через несколько сегментов, и работа ИИ-агентов. Два года Security Lakehouse уже работает внутри компании с нашими продуктами, и теперь заказчики смогут развернуть ту же платформу у себя», — рассказал Олег Кочергин, директор департамента управления данными Positive Technologies.</p> <p>Внутри Positive Technologies платформа принимает в пике до миллиона событий в секунду, в сутки в нее поступает более 50 млрд обезличенных записей. На ее данных работают PT AF Cloud, облачные детекты PT NAD. На этой же платформе компания строит следующее поколение продуктов, включая MaxPatrol O2.</p> <p>PT Security Lakehouse рассчитана на крупные компании с собственными центрами мониторинга и на провайдеров ИБ-услуг, которым нужно хранить и анализировать большие объемы событий за длительный период. Первые пилотные проекты уже идут в нефтегазовой отрасли, металлургии и банковском секторе.</p> <p>PT Security Lakehouse построена на открытой архитектуре. Данные хранятся в S3-совместимом хранилище в открытых форматах, поэтому заказчик не привязан к вендору и может подключать к ним собственные аналитические инструменты. Вычисления отделены от хранения, что позволяет изолировать нагрузку от разных систем и пользователей, а также эластично масштабироваться под растущее число запросов от ИИ-агентов. Платформа устанавливается в инфраструктуре заказчика и работает как на собственных серверах, так и в частных, публичных и гибридных облаках. Она поддерживает ролевые и атрибутные политики доступа и разграничение доступа на уровне отдельных строк и колонок. С продуктами Positive Technologies у нее есть встроенные возможности интеграции, сторонние средства защиты подключаются через открытые протоколы.</p> Positive Technologies представила коммерческую версию PT Security Lakehouse, решения для хранения и анализа больших … message https://www.itweek.ru/themes/detail.php?ID=235752 Fri, 16 Oct 2026 14:25:33 +0300 <p>46% крупнейших российских компаний стремятся уйти от закупок впрок и выжимать максимум из имеющегося оборудования на фоне ужесточения требований к окупаемости ИТ-проектов. Об этом говорят результаты совместного исследования аналитического портала «ИТ-инфраструктура» и разработчика ПО Orion soft, которое представили на ИТ-конференции «Большая игра».</p> <p>В исследовании приняли участие ИТ-руководители 120 российских компаний с выручкой от 2 млрд рублей из нефтегазовой, промышленной, финансовой, телекоммуникационной отраслей, ритейла. Был проведен анализ более 3000 открытых тендеров в области ИТ-инфраструктуры, а также 14 глубинных интервью CIO, CTO и директоров по инфраструктуре крупнейших компаний.</p> <p>Основным вызовом развития инфраструктуры в 2026 году стала средняя стоимость вычислительного оборудования, которая с 2022 по 2025 годы повысилась на 209%. Кратный рост вызван общим удорожанием компонентов, дефицитом отдельных деталей и переходом на российские серверы, которые в среднем на <nobr>30–50%</nobr> дороже зарубежных аналогов. Темпы роста цен на «железо» опередили увеличение бюджетов: сегодня компании могут закупить на 35% меньше оборудования по сравнению с 2020 годом.</p> <p>Значимым фактором подорожания оборудования стал бум внедрения ИИ. Отдельный бюджет на него есть у 44% компаний, выделенная инфраструктура — у 34%. При этом с каждым новым поколением GPU стоимость ИИ-серверов увеличивается, а устаревающие модели не всегда подходят под новые нагрузки и большие языковые модели. Это приводит к постоянно растущему спросу на все более дорогостоящие модели оборудования.</p> <p>Основной задачей Enterprise-сегмента в сложившейся ситуации становится переход от наращивания мощностей к более эффективному управлению ими. 43% технических лидеров считают, что самый перспективный способ сократить затраты на «железо» — повышение утилизации уже имеющегося парка оборудования. Средний уровень утилизации среди компаний-участников исследования составил 54%: половина их ресурсов простаивает без полезной нагрузки. </p> <p>Наиболее экономически эффективной является утилизация на уровне <nobr>80-85%,</nobr> которая достижима при автоматическом перераспределении ресурсов. При этом 69% компаний не отслеживают утилизацию системно или делают это крайне редко, раз в <nobr>9-12 месяцев,</nobr> а те, кто делает это, зачастую используют неэффективные методы, например, вручную рассчитывают утилизацию в Excel или проводят разовые поиски неудаленных ресурсов.</p> <p>Максимальное использование имеющегося оборудования стало основной стратегией рынка в «годы эффективности» — 46% компаний пытаются повысить утилизацию и продлить срок службы текущего парка серверов. Второй по популярности стратегией стала более строгая приоритизация ИТ-проектов — 26% компаний замораживают или отменяют проекты с низким ROI или высокой капиталоемкостью. Помимо них в топ-5 стратегий эффективного управления инфраструктурой вошли гибкие модели закупок и ставка на HaaS-инфраструктуру, использование инфраструктурных платформ для автоматизации управления ресурсами, а также дифференциация требований к надежности и мощности под разные типы систем.</p> <p>Основным инструментом объединения всех пяти стратегий и управления ими стало частное облако — оно является ключевой платформой для 38% крупнейших компаний с выручкой больше 500 млрд рублей. Ключевые преимущества его внедрения, по мнению технологических лидеров, — повышение управляемости и безопасности инфраструктуры, стандартизация конфигурации и окружений, повышение утилизации существующего парка оборудования. </p> <p>«В 2026 году частное облако становится инструментом повышения экономической эффективности инфраструктуры. Оно централизует управление мощностями, и становится понятно, кто, как и чем пользуется. Биллинг становится одним из стимулов не тратить лишнее, а когда новую инфраструктуру можно быстро создать, ненужный ресурс становится проще выключить или удалить. Это все приводит к тому, что оборудование утилизируется эффективнее. Целевая утилизация зависит от конкретной системы, но, например, в наших кейсах мы приходили к уровню <nobr>80–85%», —</nobr> рассказал Сергей Мерещенко, руководитель направления Orion Private Cloud Orion soft.</p> <p>«В год оптимизации бюджетов главный вопрос — как получать максимальную отдачу от уже сделанных инвестиций: в управлении инфраструктурой, в распределении мощностей и ресурсов. Для этого нужны прозрачные метрики и стандартизированные процессы: вложения следует оценивать через четкие KPI и измеримые критерии отдачи, чтобы бизнес мог принимать обоснованные решения», — подчеркнула Елена Ляховицкая, советник по развитию АНО «Исследовательский центр «ИТ-Атлас». </p> 46% крупнейших российских компаний стремятся уйти от закупок впрок и выжимать максимум из имеющегося оборудования … message https://www.itweek.ru/themes/detail.php?ID=235751 Fri, 16 Oct 2026 14:21:14 +0300 <p>Провайдер решений в области кибербезопасности и доставки контента CURATOR представил систему управления безопасным доступом (IdP) CURATOR.IDENTITY. Решение разработано совместно с российским разработчиком систем аутентификации и управления доступом Avanpost и встроено в облачную экосистему CURATOR. Клиенты могут управлять DDoS-защитой, безопасностью веб-приложений, поиском уязвимостей и защищённым доступом к корпоративным системам в едином личном кабинете.</p> <p>CURATOR.IDENTITY позволяет компаниям-клиентам облачной экосистемы CURATOR быстро запускать многофакторную аутентификацию (MFA) и единый вход (SSO), усиливать контроль устройств и пользовательских сессий, а также последовательно выстраивать архитектуру защищённого доступа — от базовой MFA до зрелых сценариев Zero Trust. Решение защищает доступ к веб-приложениям, VPN, корпоративным порталам, инфраструктурным сервисам, а также desktop- и legacy-приложениям. Централизованные политики аутентификации и доступа помогают снизить риски компрометации учётных записей, кражи пользовательских сессий и несанкционированного доступа к критически важным системам.</p> <p>Современные атаки все чаще начинаются не с классического взлома внешнего периметра: украденные логины и пароли, скомпрометированные токены, cookie или перехваченные сессии позволяют злоумышленнику получить доступ к системам под видом легитимного пользователя. В результате даже компании с выстроенной сетевой защитой, WAF и мониторингом остаются уязвимы: злоумышленник может войти в систему как обычный сотрудник, подрядчик или администратор. CURATOR.IDENTITY закрывает подобный риск за счёт централизованного управления доступом, усиленной аутентификации, единого входа, контроля сессий и учёта контекста входа — пользователя, группы, IP-адреса, устройства и сценария доступа.</p> <p>Решение CURATOR.IDENTITY работает по модели облачного SaaS: оно подключается из облака CURATOR и не требует развёртывания отдельной инфраструктуры на стороне клиента. Для безопасного подключения внутренних систем может использоваться компонент Access Bridge, который связывает облачную платформу с инфраструктурой клиента без публикации внутренних сервисов в интернете. CURATOR.IDENTITY поддерживает стандартные протоколы и сценарии интеграции с корпоративной инфраструктурой, включая OpenID Connect, SAML, RADIUS и LDAP, а также работу с ADFS и Keycloak.</p> <p>«Объединение экспертизы Avanpost в управлении доступом и аутентификации с облачной инфраструктурой CURATOR даёт клиентам возможность запустить MFA и SSO без тяжёлого on-premise проекта и постепенно двигаться к модели Zero Trust. Для бизнеса это означает более быстрый результат и меньшую нагрузку на ИТ-команду», — отметила Алина Куракина, генеральный директор Avanpost.</p> <p>«Периметр перестал быть единственной точкой входа для атакующих. Даже хорошо защищённая инфраструктура остаётся уязвимой, если злоумышленник получает возможность войти в неё с легитимной учётной записью. Партнёрство с Avanpost расширяет наш подход к обеспечению безопасности: наши клиенты получают не только защиту от DDoS-атак и уязвимостей на периметре, но и контроль над тем, кто и как получает доступ к их корпоративным системам», — прокомментировал Дмитрий Ткачёв, генеральный директор CURATOR. </p> Провайдер решений в области кибербезопасности и доставки контента CURATOR представил систему управления безопасным … message https://www.itweek.ru/themes/detail.php?ID=235750 Fri, 16 Oct 2026 14:19:32 +0300 <p>Компания Avanpost, российский разработчик решений для управления доступом и защиты цифровых идентичностей, объявила о запуске в коммерческую эксплуатацию Avanpost Identity Cloud, облачного сервиса для защищенного доступа корпоративных ресурсов для сотрудников и подрядчиков на базе безопасной облачной архитектуры. До этого сервис проходил тестирование с 1 июня по 1 октября 2026 года. </p> <p>Avanpost Identity Cloud представлен для MSSP-партнеров в двух вариантах: сервис-провайдер и реселлер. Модель «сервис-провайдер» предусматривает развертывание автоматизированного комплекса Avanpost Identity Cloud в экосистеме партнера: он осуществляет эксплуатацию, администрирование и работу с заказчиками с помощью готовых бизнес-инструментов (личного кабинет, биллинга) и технологических решений (независимого тенанта для каждого клиента, архитектурного компонента Access Bridge). Партнер может продавать сервисы под своим брендом, все технологические и административные инструменты предоставляются партнеру в пакете. Эта модель позволяет компаниям, для которых сфера информационной безопасности не является профильным бизнесом, работать на этом рынке с минимальными вложениями, повышая монетизацию существующей клиентской базы. Для Avanpost такой формат сотрудничества охватает новые, более массовые сегменты корпоративного рынка и открывает путь к клиентам, которых объединяет экосистема бренда партнера. Вторая программа, реселлер, подразумевает продажу лицензий сервисов, развернутых непосредственно в облаке Avanpost Identity Cloud. </p> <p>Avanpost Identity Cloud cоздан на базе решений Avanpost IAM (Identity Access Management), которым доверяют более 150 крупнейших компаний России с геораспределенной инфраструктурой и высокими требованиями к кибербезопасности и отказоустойчивости. Возможности и архитектурные принципы корпоративного решения перенесены в облако без потери уровня защиты. Для каждого клиента разворачивается независимый тенант: отдельный контур, база данных и политики доступа. Инциденты, ошибки конфигурации или пиковые нагрузки у одного клиента не влияют на других. Архитектурный компонент Access Bridge обеспечивает простую и защищённую интеграцию платформы Avanpost Identity Cloud с корпоративными системами заказчика, сохраняя полный контроль над данными и периметром безопасности. Для непрерывной работы при сбоях связи реализована офлайн-аутентификация. Сервисные учетные записи и инфраструктурные секреты не требуют публикации наружу и остаются внутри контролируемого контура. </p> <p>C Avanpost Identity Cloud IAM-решения стали доступнее для массового сегмента бизнеса. Благодаря облачной модели для организации снимаются барьеры по внедрению IAM-проекта: отсутствие ресурсов, сложные интеграции и высокие цены на внедрение. При этом, безопасность соответствует enterprise-практикам. Сам сервис построен как ступенчатая модель: любая компания может стартовать с защиты второго фактора для ключевых приложений и без смены платформы дорастать до Zero Trust подхода по мере зрелости и появления новых задач бизнеса. Стоимость подписки на Avanpost Identity Cloud составляет от 168 рублей в месяц за одного пользователя, а время на подключение составляет от 15 минут. </p> <p>Провайдер решений в области кибербезопасности и доставки контента CURATOR оценил потенциал Avanpost Identity Cloud как драйвера рынка защиты identity и развернул в своей облачной инфраструктуре решение под брендом CURATOR IDENTITY для управления безопасным доступом и аутентификацией (IdP) как дополнительный сервис для своих клиентов. </p> <p>Ключевые архитектурные особенности сервиса Avanpost Identity Cloud</p> <ul> <li>изоляция тенантов. Для каждого клиента разворачивается независимый tenant: отдельный контур, база данных и политики доступа. Инциденты, ошибки конфигурации или пиковые нагрузки у одного клиента не влияют на других. Уровень изоляции сопоставим с выделенным on-premise решением, но без затрат на собственную инфраструктуру;</li> <li>компонент Access Bridge обеспечивает защищённую интеграцию Avanpost Identity Cloud с корпоративными системами заказчика, сохраняя полный контроль над данными и периметром безопасности;</li> <li>гибкость развёртывания. Решение отличается гибкостью развертывания и адаптируется под любую архитектуру — от централизованной до распределённой в изолированных сегментах;</li> <li>непрерывность бизнеса. Поддержка офлайн-аутентификации гарантирует непрерывность бизнес-процессов даже при сбоях связи, а централизованное управление из единой административной консоли значительно упрощает внедрение и эксплуатацию;</li> <li>простота внедрения. Централизованное управление через единую административную консоль реализует принцип plug-and-play, исключая необходимость ручной настройки локальных компонентов и значительно упрощая внедрение;</li> <li>безопасность. Критически важные секреты приложений (LDAP, RADIUS) обрабатываются исключительно внутри контура заказчика и не передаются за его пределы, обеспечивая высокий уровень безопасности.</li> </ul> <div><br/> </div> Компания Avanpost, российский разработчик решений для управления доступом и защиты цифровых идентичностей, объявила … message https://www.itweek.ru/themes/detail.php?ID=235746 Fri, 16 Oct 2026 12:42:07 +0300 <p><em>Новые западные модели с открытыми весами могут предоставить предприятиям альтернативу китайскому и проприетарному ИИ, но больший контроль также влечет за собой новую ответственность, считают опрошенные порталом </em><em>AI</em> <em>Business</em> <em>эксперты.</em></p> <p>Предприятиям, стремящимся размещать, настраивать и управлять собственным ИИ, все чаще приходится сопоставлять гибкость моделей с открытыми весами от китайских компаний с проприетарными западными моделями, которые предоставляют поставщикам больший контроль над разработкой и развертыванием моделей.</p> <p>Но этот выбор начал расширяться. Компания Reflection AI, поддерживаемая Nvidia, недавно запустила свою модель Beam с открытыми весами, а французская ИИ-лаборатория Mistral представила свою новую модель Large 4, предоставив предприятиям новые западные варианты на рынке моделей с открытыми весами.</p> <p>Для предприятий важность этих запусков выходит за рамки того, как модели показывают себя в бенчмарках. Если модели окажутся достаточно эффективными, они могут предоставить организациям, которые избегали китайских систем из-за вопросов безопасности, обработки данных, происхождения, юрисдикции или соответствия нормативным требованиям, западную альтернативу для рабочих нагрузок, которые они хотят запускать на основе моделей с открытыми весами.</p> <p>«Главное изменение заключается в том, что модели с открытыми весами становятся реальным вариантом закупок для западных предприятий, а не просто чем-то, с чем экспериментируют исследовательские группы, — говорит Джит Паттанаик, основатель и технический директор Glokal AI, поставщика решений для корпоративного ИИ. — Это смещает вопрос с того, могут ли предприятия использовать модели с открытыми весами, на то, какие рабочие нагрузки им следует на них запускать».</p> <p>По его словам, до сих пор самые сильные модели с открытыми весами были в основном китайскими, что создавало проблемы для таких организаций, как банки, страховые компании и государственные органы, которые сталкиваются с ограничениями, связанными с происхождением моделей и соответствием нормативным требованиям.</p> <h3>Лидерство Китая в области открытых моделей не будет вечным</h3> <p>Китайские компании заняли лидирующие позиции в области ИИ с открытыми весами, при этом модели от Alibaba, DeepSeek, Moonshot и Z.ai набирают популярность благодаря своим возможностям и относительно низким операционным расходам.</p> <p>Counterpoint Research <a href="https://counterpointresearch.com/ins...et-q3-2024/insights/Moonshot-AI-Kimi-K3-shockwave-chinese-dominate-open-frontier-models">определила</a> китайские модели, включая Kimi и GLM, как одни из лучших систем с открытыми весами на рынке.</p> <p>Принс Коли, президент и генеральный директор Sauce Labs, облачной платформы для тестирования ПО, работающей с поставщиками моделей с открытыми весами, считает, что раннее лидерство китайских разработчиков отчасти обусловлено необходимостью. Ограниченность ресурсов подтолкнула их к снижению затрат и повышению эффективности оборудования, в то время как западные компании, занимающиеся ИИ, сосредоточили больше ресурсов на производительности передовых моделей.</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> <p>«Вы не можете проверить вероятность, поэтому элементы управления должны находиться вне модели, независимо от того, открыта она или закрыта», — говорит Паттанаик.</p> <p>Таким образом, открытые веса не являются кратчайшим путем для обеспечения управления ИИ. Предприятиям по-прежнему необходимы элементы контроля модели для обеспечения безопасности, оценки, обновлений и других процессов управления.</p> <h3> Истинной проверкой является внедрение на предприятии </h3> <p>Reflection AI и Mistral не обязательно должны постоянно обгонять китайских разработчиков, чтобы предприятия могли извлечь выгоду из более сильного западного открытого рынка. Их успех будет зависеть от того, найдут ли предприятия модели достаточно производительными, надежными и заслуживающими доверия для реальных рабочих нагрузок.</p> <p>Это может изменить подход предприятий к закупкам моделей. Вместо того, чтобы выбирать между проприетарными западными моделями и китайскими моделями с открытыми весами, организации могут использовать более широкий набор моделей в зависимости от рабочей нагрузки, нормативных требований и необходимого им уровня контроля.</p> <p>Коли ожидает, что по мере сближения возможностей западных и китайских моделей, более важную роль во внедрении будут играть другие факторы, включая качество, надежность, стоимость и доверие. По его словам, как только стоимость токенов станет достаточно близкой, у предприятий будет больше оснований оценивать, насколько стабильно работают модели и могут ли они полагаться на политику поставщика и происхождение данных.</p> <p>«Предприятиям нужны предсказуемые результаты, высокая производительность в сложных сценариях использования и гибкость выбора модели, а не привязка к одному поставщику, — говорит Коли. — Кроме того, они должны доверять источнику данных и политике поставщика».</p> Новые западные модели с открытыми весами могут предоставить предприятиям альтернативу китайскому … article https://www.itweek.ru/themes/detail.php?ID=235744 Fri, 16 Oct 2026 11:55:15 +0300 <p><em>ИИ в кибербезопасности может быть не только <a href="https://www.itweek.ru/security/article/detail.php?ID=235359">мечом</a>, но и щитом. Рассмотрим, как именно он помогает защищать инфраструктуру, приложения и данные.</em></p> <h3>Хайпа нет, полет нормальный</h3> <p>Искусственный интеллект вошел в арсенал информационной безопасности не вчера и не сегодня. Пока защита самих ИИ-систем становится отдельным направлением рынка, а использование ИИ злоумышленниками активно обсуждается, машинное обучение в средствах защиты давно стало привычным инструментом. Модель в продукте сама по себе уже мало кого удивляет. Заказчику важнее не то, используется ли внутри ИИ, а какую задачу он решает: помогает ли быстрее обнаруживать угрозы, снижать нагрузку на аналитиков или точнее выделять подозрительную активность. И отсутствие ажиотажа здесь скорее хороший знак. На первый план выходит результат, который можно измерить.</p> <p>Особенно заметен этот эффект там, где приходится работать с большими потоками событий. Например, SIEM собирает и сопоставляет данные из разных источников, а NGFW анализирует сетевой трафик и применяет политики безопасности. Модели машинного обучения могут дополнять традиционные правила: выявлять аномалии, находить нетипичные последовательности действий и помогать расставлять приоритеты среди срабатываний. Но обещать, что одна только модель автоматически повысит и скорость, и точность, было бы неправильно. Результат зависит от качества данных, выбранного сценария и того, как модель встроена в продукт. Сильный эффект появляется тогда, когда аналитик тратит меньше времени на шум и больше — на действительно значимые события.</p> <p>Еще одно направление — безопасность приложений. Инструменты статического анализа исходного кода (SAST) могут выдавать много находок, которые требуют дополнительной проверки. Здесь ИИ полезен для первичного разбора: он помогает группировать схожие результаты, учитывать контекст кода, предполагать вероятность ложного срабатывания и формировать очередь для проверки специалистом. Вместо неструктурированного перечня из сотен находок команда получает более понятную картину рисков. Важная оговорка: низкий приоритет не означает, что уязвимости точно нет. Поэтому автоматически отбрасывать результаты только на основании вывода модели нельзя, особенно когда речь идет о критичных приложениях.</p> <p>Отдельная тема — ложные срабатывания. Иногда можно услышать, что ИИ обязательно делает детектирование менее предсказуемым, но и обратное обещание, будто модель сама устранит весь шум, столь же неверно. Ложные срабатывания и пропущенные угрозы возможны как у правил, так и у моделей. Их соотношение зависит от данных, порогов детектирования, условий эксплуатации и регулярной проверки качества. Поэтому оценивать ИИ нужно не по красивой демонстрации, а по метрикам в реальной среде: сколько полезных сигналов он выделил, сколько ложных тревог добавил и что мог пропустить.</p> <h3>Сначала — цель, потом — внедрение</h3> <p>Несмотря на зрелость отдельных сценариев машинного обучения в киберзащите, внедрение ИИ не гарантирует улучшения продукта. Модель может решить действительно дорогую для заказчика задачу, а может добавить задержки, стоимость эксплуатации, новые зависимости и риски без заметной пользы. Поэтому начинать нужно с простого вопроса: какую именно проблему мы собираемся решить? А уже затем выбирать технологию и определять, как измерим результат.</p> <p>На практике обычно сталкиваются два подхода. Первый — внедрить ИИ, потому что он уже есть у конкурентов. Второй — увидеть конкретную проблему: например, аналитики слишком долго разбирают однотипные срабатывания, а разработчики теряют время на ручную сортировку находок. И только после этого проверить, поможет ли здесь модель. Причем иногда достаточно правил, статистических методов или давно проверенных алгоритмов машинного обучения. Большая языковая модель (LLM) нужна далеко не в каждом сценарии: для детектирования аномалий и для понятного объяснения срабатывания пользователю могут потребоваться совершенно разные решения.</p> <p>Именно на этой развилке продуктовые команды часто ошибаются. Если добавлять LLM ради самого факта ее наличия, легко получить усложнение архитектуры, рост стоимости и задержек, а также дополнительные требования к безопасности и контролю качества ответов. У ИИ может быть и вспомогательная роль, и самостоятельная продуктовая функция. Вопрос в другом: становится ли защита лучше для конкретного пользователя? Если мы можем показать, что сократилось время расследования, улучшилась приоритизация уязвимостей или снизилась доля бесполезных срабатываний без неприемлемого роста пропусков, внедрение имеет смысл. Если таких результатов нет, самая современная модель остается лишь дорогой галочкой в списке возможностей продукта.</p> <p>#IMAGE_235745#</p> ИИ в кибербезопасности может быть не только мечом, но и щитом. Рассмотрим, как именно он помогает … article Светлана Газизова, владелец продукта по безопасности ИИ в компании UserGate https://www.itweek.ru/themes/detail.php?ID=235741 Thu, 15 Oct 2026 15:44:23 +0300 <p>Институт статистических исследований и экономики знаний (ИСИЭЗ) НИУ ВШЭ продолжает изучать практики применения ИИ в ключевых отраслях промышленности и связанные с этим эффекты, в частности для кадровой политики. Как показал анализ, в химической промышленности ключевую роль играет безопасность: ИИ применяют чаще всего на отдельных участках производства в рамках четких ограничений, а системно развивают кадровый потенциал в области ИИ лишь немногие предприятия.</p> <p>Наиболее востребованы на предприятиях химпрома ИИ-решения для обработки визуальных данных и текста (их используют 10,7% и 10,5% обследованных организаций соответственно). Заметно реже применяют передовые решения, к которым относятся большие языковые / генеративные модели (6%) и ИИ-агенты (1,6%). Среди организаций, планирующих внедрение ИИ или считающих его перспективным, наибольший потенциал видят в приложениях для интеллектуальной поддержки принятия решений и управления (32,7%).</p> <p>В химической промышленности ИИ применяют главным образом для моделирования продукции и процессов (более 40% организаций, использующих ИИ) и управления оборудованием <nobr>(28–33%).</nobr> В отраслевом разрезе общий профиль применения сходен, но есть и некоторые отличия: промышленная безопасность входит в число наиболее распространенных задач применения ИИ производителей химических веществ и продуктов (28,2%), а логистика и хранение — производителей резиновых и пластмассовых изделий (27,9%). Среди потенциальных областей применения ИИ чаще всего называют диагностику оборудования и предупреждение поломок (58,2 %). Эти задачи относятся к предиктивной аналитике — одному из наиболее быстрорастущих направлений мировой химической промышленности.</p> <p>К моменту проведения обследования эффекты от применения ИИ получили почти четверть предприятий химпрома, использующих технологию. Из основных результатов — улучшение качества и потребительских характеристик продукции, включая возможность адаптировать ее с учетом географии поставок, запросов потребителей, регуляторных норм и других требований. Каждое пятое предприятие-пользователь отметило снижение потребления ресурсов, в том числе энергетических. В ближайшие годы более двух третей предприятий рассчитывают с помощью ИИ сократить брак и число поломок, снизить аварийность и повысить производительность оборудования.</p> <p>К наиболее быстро проявляющимся кадровым эффектам от внедрения ИИ в химической промышленности относятся экономия времени работников и автоматизация рутинных задач: их отметили около четверти обследованных организаций-пользователей ИИ. Усиления этих эффектов в среднесрочной перспективе ожидают три из пяти предприятий, начавших внедрение ИИ. Предприятий, прогнозирующих рост численности персонала под влиянием ИИ, вдвое больше ожидающих сокращения штатов. Крупные организации реже других видят в ИИ угрозу занятости, в отраслевом разрезе такую оценку реже всего дают производители лекарственных средств и материалов, применяемых в медицинских целях и ветеринарии. Наиболее благоприятная ситуация на рынке труда химической промышленности, ожидаемо, складывается для специалистов по ИКТ и занятых непосредственно в производстве и разработке продукции. Наиболее пессимистично организации оценивают перспективы служащих, занятых подготовкой и оформлением документации, учетом и обслуживанием.</p> <p>У трети предприятий химпрома, использующих ИИ, есть собственные разработчики ИИ-приложений и аналитики ПО. Однако численность таких специалистов, как правило, недостаточна. Политику по развитию кадрового потенциала в области ИИ проводит лишь небольшая часть компаний химпрома. Только каждая пятая поощряет использование ИИ на рабочем месте. Еще более редкая практика — взаимодействие с образовательными учреждениями, готовящими специалистов с навыками работы с ИИ.</p> <p>Для предприятий химической промышленности важна не только ожидаемая отдача от ИИ, но и возможность безопасно встроить его в сложные и зачастую опасные производственные процессы. Почти две трети организаций, уже использующих ИИ, считают безопасность ИИ-систем критически важным условием расширения их применения. Она предполагает, в частности, стабильность работы систем и их устойчивость к внешним воздействиям. В общей выборке обследованных организаций химпрома почти четверть отмечают среди условий внедрения появление инструментов обеспечения безопасности ИИ-систем и оценки их соответствия установленным требованиям (например, сертификацию решений); около трети — повышение рентабельности основной деятельности.</p> Институт статистических исследований и экономики знаний (ИСИЭЗ) НИУ ВШЭ продолжает изучать практики применения ИИ … message https://www.itweek.ru/themes/detail.php?ID=235740 Thu, 15 Oct 2026 15:40:33 +0300 <p>Cloud.ru, провайдер облачных сервисов и ИИ-технологий, представил RepoWiki — новую функцию в составе сервиса Evolution Repo, которая автоматически анализирует кодовую базу и формирует структурированную документацию проекта.</p> <p>Evolution Repo — облачный сервис для хранения репозиториев кода, <nobr>ML-моделей</nobr> и датасетов. Сервис хранит модели и датасеты в одном хранилище и помогает управлять большими файлами через Git LFS, версионировать <nobr>ML-модели</nobr> и просматривать файлы-тензоры. Синхронизация и обмен артефактами работает через API, совместимое с популярной библиотекой моделей Hugging Face.</p> <p>RepoWiki встроен непосредственно в облачный репозиторий. Разработчикам больше не нужно переносить код в сторонний ИИ-сервис: репозиторий, документация и работа с кодовой базой теперь собраны в едином пространстве. Сервис работает на базе Evolution ManagedRAG и AI Agents. Перед генерацией самой документации пользователю на согласование отправляется предварительный список разделов и страниц, который можно редактировать. </p> <p>Обычно, приступая к новой задаче, разработчику или ИИ-агенту необходимо погрузиться в контекст: понять, что делает проект, как устроена архитектура, где находится нужный код. Если проект не подготовлен заранее, возникают ограничения: агент видит отдельные файлы, но не понимает их роль в системе, не осознает неявные зависимости, а контекстное окно не позволяет охватить кодовую базу целиком.</p> <p>RepoWiki устраняет эти ограничения: система самостоятельно анализирует структуру проекта, выявляет взаимосвязи между модулями и генерирует документацию, которая отражает реальное устройство кодовой базы. При использовании RepoWiki ручная работа с документацией сокращается в среднем на 30% (по результатам тестов на реальных проектах).</p> <p>С технической точки зрения, RepoWiki использует мультиагентный подход к созданию документации. Внутри системы анализ кода разбивается на последовательные этапы: планирование, анализ архитектуры, написание и верификация содержимого. Это помогает обрабатывать проекты масштаба крупных корпоративных репозиториев, где единовременный анализ всей кодовой базы невозможен из-за ограничений контекстного окна. Решение поддерживает инкрементные обновления: при изменении кода документация обновляется, а не создается заново.</p> <p>Функция поможет разработчикам, изучающим незнакомые модули или подключающимся к существующим проектам: RepoWiki сокращает время входа в контекст и рабочую нагрузку. Техническим лидерам и руководителям, организующим передачу знаний функция поможет для управления знаниями, снижения риски ухода ключевых сотрудников и ускорения адаптации команды.</p> <p>«С RepoWiki вместо того, чтобы вручную описывать модули, поддерживать актуальность файлов и собирать знания по крупицам из комментариев и переписок, ИТ-команда получает автоматически сгенерированное описание проекта. Разработчик может задавать вопросы по кодовой базе в чате вместо изучения десятков разрозненных файлов. Это особенно ценно при работе с незнакомыми модулями, при подключении к существующим проектам и при разборе legacy-кода, где документация либо отсутствует, либо давно устарела», — сказала директор блока разработки платформы Cloud.ru Evolution Анастасия Тафеенко.</p> Cloud.ru, провайдер облачных сервисов и ИИ-технологий, представил RepoWiki — новую функцию в составе сервиса … message https://www.itweek.ru/themes/detail.php?ID=235739 Thu, 15 Oct 2026 10:40:24 +0300 <p><em>На октябрьской конференции Open Source Summit Europe 2026 в Праге неоднократно звучал один и тот же тезис: организации и правительства, которые просто используют </em><em>Open</em> <em>Source</em><em>, остаются зависимыми от других в формировании своего будущего. Те, кто управляет, поддерживает, обеспечивает безопасность и развивает экосистемы </em><em>Open</em> <em>Source</em><em>, получают влияние, устойчивость, суверенитет и стратегическое преимущество. Дискуссия о суверенитете развивается как внутри, так и за пределами сообщества </em><em>Open</em> <em>Source</em><em>: вопрос не в том, как защитить себя от внешней зависимости, а в том, как стать незаменимым участником экосистем, от которых зависит цифровое будущее, пишет в корпоративном блоге Дарио Маисто, главный аналитик </em><em>Forrester</em><em>.</em></p> <h3>Open Source стал критически важной инфраструктурой</h3> <p>Open Source больше не является просто моделью разработки. Он лежит в основе облачных платформ, систем искусственного интеллекта, инструментов кибербезопасности и цифровых государственных услуг. Тем не менее, многие проекты, поддерживающие цифровую экономику, по-прежнему зависят от небольших групп разработчиков, которые сталкиваются с растущим давлением со стороны угроз кибербезопасности, управления уязвимостями, необходимости соответствия нормативным требованиям и ожиданий сообщества.</p> <p>Одной из повторяющихся проблем, отмеченных на саммите, была устойчивость работы сопровождающих проектов (мейнтейнеров). Нагрузка на безопасность продолжает расти, в то время как многим проектам не хватает достаточной поддержки. Документация стала важной проблемой. Мейнтейнеры неоднократно отмечали, что улучшенная документация снижает трудозатраты, повышает уровень внедрения проектов и позволяет сосредоточить ограниченные ресурсы на более ценной работе.</p> <p>Если Open Source является критически важной инфраструктурой, его поддержка должна стать общей ответственностью, а не бременем нескольких добровольцев.</p> <h3>Суверенитет требует участия, а не изоляции</h3> <p>Саммит подтвердил тезис, который Forrester распространяет уже довольно давно: суверенитет не достигается изоляцией. Сильные нации и организации не уходят из экосистем. Они вносят в них свой вклад, формируют их и помогают управлять ими. Другими словами, влияние имеет такое же значение, как и контроль.</p> <p>Одна из наиболее убедительных концепций, представленных на саммите, описывает четыре составляющих суверенитета:</p> <ol> <li><strong>целостность:</strong> защита данных и обеспечение доверия;</li> <li><strong>устойчивость:</strong> сокращение уязвимостей и укрепление операций;</li> <li><strong>непрерывность:</strong> поддержание контроля над инфраструктурой и цепочками поставок;</li> <li><strong>взаимозависимость:</strong> укрепление внутренних сильных сторон при участии в глобальных экосистемах в качестве равноправного партнера.</li> </ol> <p>Основные выводы о суверенитете и Open Source:</p> <ul> <li><strong> Вклад без управления создает разрыв.</strong> Вот статистика, которая нашла отклик на протяжении всего мероприятия: Европа вносит примерно 40% вклада в деятельность Open Source-проектов, оставаясь при этом недостаточно представленной в структурах управления и лидерства. Это расхождение имеет значение. Вклад в код ценен, но управление определяет направление проекта, приоритеты финансирования, инвестиции в безопасность и долгосрочные планы развития.</li> <li><strong> Активное участие обеспечивает умножение отдачи.</strong> Организации, стремящиеся к большему цифровому суверенитету, должны измерять не только то, сколько открытого исходного кода они потребляют или в который вносят вклад, но и то, участвуют ли они в фондах, руководящих комитетах, программах поддержки и инициативах по лидерству в экосистеме. Активное участие обеспечивает умножение отдачи. Оно создает влияние, которое выходит за рамки строк кода и становится источником рычага воздействия.</li> <li><strong> Поддержка апстрима создает бóльшую ценность, чем поддержка частных форков.</strong> Докладчики неоднократно подчеркивали, что организации не могут пассивно обеспечивать безопасность цепочек поставок ПО. Внесение исправлений, финансирование разработчиков, улучшение документации и участие в управлении укрепляют экосистему для всех. В отличие от этого, поддержка изолированных частных форков может быть дорогостоящей: по оценкам одного из докладчиков, поддержание частного форка может стоить до 250 тыс. евро.</li> <li> <strong>Open</strong> <strong>Source</strong> <strong>не устраняет зависимость автоматически.</strong> Open Source-лицензия может обеспечить прозрачность и переносимость, но она не устраняет зависимость автоматически. Проекты, в которых доминирует один поставщик, по-прежнему могут создавать риск концентрации из-за контроля со стороны управления, влияния на дорожную карту или доминирования в экосистеме. Поэтому технологические лидеры должны оценивать не только лицензии, но и разнообразие участников, модели управления, надзор со стороны фондов и долгосрочную устойчивость.</li> <li> <strong>Open</strong> <strong>Source</strong> <strong>— это стратегическая зависимость, которой необходимо активно управлять.</strong> Цифровой суверенитет теперь является приоритетом на уровне совета директоров, в то время как Open Source-компоненты интегрированы во все современные технологические стеки. Организациям необходима прозрачность в отношении ПО, от которого они зависят, сообществ, которые его поддерживают, и рисков, связанных с критически важными зависимостями.</li> </ul> <h3>Будущее суверенитета в сфере Open Source — за влиянием на экосистему</h3> <p>Появление крупных альянсов в области ИИ, инициатив под эгидой профильных фондов и технологий, ориентированных на работу с ИИ-агентами, указывает на то, что в эпоху ИИ активное участие станет еще более важным. Организации, участвующие в создании, управлении и развитии этих экосистем, получат больше возможностей влиять на стандарты, инновации и вектор развития рынка. Главный вывод конференции Open Source Summit Europe 2026 прост: цифровой суверенитет для Open Source-сообщества определяется тем, что его участники помогают формировать, а не только тем, что они способны контролировать. Будущее принадлежит не тем, кто просто использует Open Source, а тем, кто активно способствует его успеху.</p> На октябрьской конференции Open Source Summit Europe 2026 в Праге неоднократно звучал один и тот же тезис … article https://www.itweek.ru/themes/detail.php?ID=235735 Thu, 15 Oct 2026 10:28:38 +0300 <p><em>С осени 2025 года у Apache Flink есть подпроект Flink Agents, который встраивает нейросети прямо в потоковую обработку данных. Что это меняет и сможет ли нейросеть заменить дежурного инженера?</em></p> <h3>Проблема, которую все знают, но терпят</h3> <p>Типичная ситуация: ночью срабатывает алерт — дежурный инженер должен устранить неполадки. Чтобы добраться до проблемы, ему нужно проснуться, войти во внутреннюю сеть компании, открыть графики и логи, понять, какое приложение сломалось и почему. На это уходит много времени.</p> <p>Решение при этом чаще всего простое: перезапустить приложение, выделить ему больше ресурсов или откатить на предыдущую версию. Почти всё время тратится на подход к исправлению, а не на само решение. На проблему, которую можно было решить за секунды, тратятся десятки минут, иногда дольше.</p> <p>Системы усложняются с каждым годом, связей между приложениями становится больше, и сбой в одном месте всё чаще тянет за собой проблемы в другом. Индустрия вкладывает много сил в отказоустойчивость: системы дублируют и разносят по разным площадкам. А вот реакция на аварию почти не изменилась: дежурный по-прежнему смотрит на проблему своими глазами, разбирается и действует. В такой ситуации он становится «узким местом». Аварии случаются под нагрузкой, когда каждая минута простоя стоит дороже всего. После такой ночи инженер не высыпается и на следующий день работает хуже, поэтому одна авария обходится компании дважды.</p> <h3>Инструкции устаревают быстрее, чем их пишут</h3> <p>Чаще всего дежурному помогают плейбуки. Идея понятная: записать опыт один раз, чтобы им воспользовался любой инженер. Однако плейбук устаревает почти сразу: системы меняются каждую неделю, а инструкции в лучшем случае правят раз в год. Несколькими плейбуками современную систему не покрыть: нужна целая энциклопедия, которую никто не успевает поддерживать.</p> <p>Я не помню, когда последний раз вообще видел плейбуки, но точно знаю: системы, для которых их писали, были гораздо проще и менялись гораздо реже, чем нынешние. На вопрос «А где же ваши плейбуки?» сегодня нередко можно услышать, что их либо нет, либо те, что есть, безнадёжно устарели.</p> <p>Логичный следующий шаг — прикладывать к каждому алерту пояснение, что он означает и что делать. Но на практике этот подход быстро упирается в противоречие:</p> <ul> <li><strong> Узкие алерты</strong> привязаны к конкретной причине. Представим кластер Flink, на котором работают десятки джоб. Каждая может упасть по-своему: ошибка в пользовательском коде, некорректное сообщение в Kafka, потеря соединения с базой данных, нехватка ресурсов, сбой Kubernetes, ошибка JVM. Под каждую причину легко написать инструкцию, но такие ошибки часто приходят группой, и одна проблема — джоба перестала обрабатывать данные — превращается в пять алертов. Внимание дежурного размазывается, и главное теряется в шуме.</li> <li><strong> Общие алерты</strong> описывают симптом, а не причину, например «джоба не обрабатывает данные». На одну проблему приходит один алерт, и дежурный сразу видит, что сломалось. Но к такому алерту уже не напишешь инструкцию: у симптома может быть десяток причин.</li> </ul> <p>Поэтому многие команды в итоге переходят на общие алерты: внимание дежурного не размазывается, а одна проблема — это один сигнал. От формальных инструкций при этом приходится отказаться, и новых дежурных учат через наставничество. Решение неидеальное, но на практике оно работает лучше остальных. Но главная беда никуда не девается: чтобы понять, что случилось, по-прежнему нужно много времени.</p> <h3>Что изменилось</h3> <p>Данных для разбора аварии у инженеров обычно достаточно. Логи приложений стекаются в единую систему передачи сообщений, например Kafka. К ней подключают потоковый обработчик — джобу на Apache Flink, которая читает логи в реальном времени.</p> <p>Раньше такой обработчик выполнял только заранее прописанные реакции: например, если за минуту пришло больше ста ошибок нехватки памяти, перезапусти приложение. Это тот же плейбук, только в коде. Он быстрее бумажного, потому что убирает человека из цепочки, но устаревает так же: система меняется, а правила остаются.</p> <p>Теперь в тот же поток можно встроить языковую модель и дать ей инструменты через MCP (Model Context Protocol) — стандартный протокол, через который модель обращается к внешним системам. Модель понимает текст ошибки, сама запрашивает метрики, историю релизов, состояние приложения в Kubernetes и по ним предлагает, что делать. В этом и состоит сильная сторона нейросетей: они быстро собирают разнородные данные в одну картину.</p> <p>Время реакции сокращается с десятков минут примерно до минуты. Большую часть этого времени занимает накопление событий перед отправкой в модель. Ответ модели и пара обращений к инструментам занимают секунды.</p> <h3>Как это устроено</h3> <p>Разберём на примере <a href="https://flink.apache.org/2026/06/19/apache-flink-agents-0.3.0-release-announcement/">Apache Flink Agents</a> — подпроекта Flink, в котором агент становится обычным шагом потоковой обработки.</p> <p>Если упростить, конвейер состоит из трёх ступеней:</p> <p> #IMAGE_235737#</p> <p><strong>1. Дешёвый предфильтр без модели.</strong> Предфильтр группирует логи из Kafka по приложению и накапливает их в окне на <nobr>30-60 секунд.</nobr> Он сворачивает одинаковые ошибки в одну, считает их частоту, сохраняет начало и конец сообщения об ошибке. В модель уходит одно «происшествие» на приложение вместо тысячи строк лога. Это главный способ сэкономить деньги и время: модель не видит шум, который обычный код отсекает.</p> <p><strong>2. Агент.</strong> Агент состоит из событий и действий. Событие — сигнал, что что-то произошло, например пришло новое происшествие. Действие — небольшой фрагмент логики, который запускается на определённое событие и порождает новое. Для типовых шагов есть готовые события: вход, запрос к модели, ответ модели и выход. Если модели нужны инструменты, фреймворк сам вызывает их и возвращает результат, пока у модели не будет готового ответа.</p> <p>Разработчик описывает всё, чем агент пользуется, отдельно от логики, как набор ресурсов: какая модель, какой промпт, какие инструменты, какие MCP-серверы. Ресурсы выносят в конфигурационный файл и, например, меняют поставщика модели, не трогая код.</p> <p>Фреймворк поддерживает два стиля: workflow-агент, где маршрут задаёт разработчик, и ReAct-агент, где модель сама решает, какой инструмент вызвать следующим. Для аварий удобнее первый: каркас жёсткий, а свободу выбирать инструменты модель получает только на шаге диагностики.</p> <p>Здесь важны три вещи.</p> <ul> <li><strong> Модель сама ничего не меняет.</strong> Ей доступны только инструменты на чтение. Исправление выполняет наш собственный код, и только если предложенное действие есть в белом списке, а лимит не исчерпан. Модель советует, код действует.</li> <li><strong> Ответ модели — в строгом формате.</strong> Модель возвращает заранее описанную структуру: что случилось и какое действие она предлагает. Всё, что код не смог разобрать, автоматически уходит человеку.</li> <li><strong> Действие не выполнится дважды.</strong> Flink Agents запоминает результат действия во внешнем хранилище (Kafka или Apache Fluss), поэтому, если джоба упадёт и восстановится, повторного перезапуска не будет. Для самого неприятного случая, когда перезапуск уже выполнен, а записать результат система не успела, можно задать отдельную проверку: при восстановлении фреймворк сначала спросит у Kubernetes, в каком состоянии приложение.</li> </ul> <p><strong>3. Выход.</strong> Агент отправляет результат в отдельный топик Kafka, а оттуда он попадает в систему оповещений и в тикет. Если агент справился сам, в журнале появляется запись. Если нет, дежурный получает алерт с приложенными метриками, последними релизами и гипотезой модели о том, что случилось.</p> <h3>Где граница доверия?</h3> <p>У этого подхода есть обратная сторона: доверие к нейросети. Очевидный ответ такой: машине отдаём только то, что безопасно и легко откатить, всё остальное она готовит, а решает человек. Нейросеть заменяет рутину инженера. Самого инженера она заменить не может. Границу удобно описать таблицей прав (цифры приведены для примера):</p> <table> <tbody> <tr> <th>Действие</th> <th>Кто выполняет</th> <th>Ограничения</th> </tr> <tr> <td> Сбор данных: метрики, логи, релизы, состояние в Kubernetes</td> <td> Агент сам</td> <td> Только MCP-сервер на чтение, отдельная служебная учётная запись</td> </tr> <tr> <td> Перезапуск приложения</td> <td> Агент сам</td> <td> Не чаще 2 раз в час на приложение; не помогло — зовём человека</td> </tr> <tr> <td> Масштабирование</td> <td> Агент сам</td> <td> В пределах квоты, например не больше чем +50% копий приложения</td> </tr> <tr> <td> Откат релиза</td> <td> Агент в узких рамках, иначе человек</td> <td> Только на предыдущую версию и только для свежего релиза</td> </tr> <tr> <td> Конфигурация, базы данных, сеть, удаление ресурсов</td> <td> Только человек</td> <td> Агент прикладывает собранные данные и предложение</td> </tr> </tbody> </table> <p>Чтобы эта схема работала, нужно несколько вещей.</p> <ul> <li><strong>Права ограничиваются в инфраструктуре.</strong> Flink Agents автоматически подтягивает все инструменты подключённого MCP-сервера. Список в настройках определяет, какие из них увидит модель, но это одна строчка, в которой легко ошибиться. Надёжнее, когда опасных операций на сервере нет вообще, а служебная учётная запись имеет права только на чтение.</li> <li><strong>Лимиты против зацикливания.</strong> Если перезапуск не помог, второй и третий, скорее всего, тоже не помогут, зато замаскируют настоящую проблему. Поэтому поток хранит счётчик действий по каждому приложению в своём состоянии, и при превышении лимита агент обязан позвать человека.</li> <li><strong>Маленькие модели.</strong> Если отправлять каждое событие в самую мощную модель, мы либо разоримся, либо будем подолгу ждать ответа. Поэтому здесь обычно работают небольшие модели: большой контекст им не нужен, но и доверить им можно далеко не всё.</li> <li><strong>Уверенность модели не равна вероятности.</strong> Если попросить обычную языковую модель оценить свою уверенность, она вернёт число, которое, по сути, сама и придумала. Поэтому решение «чинить самому или звать человека» стоит строить на белом списке и лимитах, а не на такой оценке. Здесь интересен новый класс моделей, которые не пишут текст, а выбирают из заданных вариантов. Пример — <a href="https://www.llmreference.com/model/jev/typesafe-ai">Jev от TypeSafe AI</a>, вышедшая 15 сентября 2026 года. Ей передают собранные данные и варианты вроде «перезапустить», «добавить ресурсов», «позвать человека», а она возвращает выбор с вероятностью, которую разработчик называет калиброванной, причём, <a href="https://thursdai.news/companies/typesafe-ai">по его данным</a>, за <nobr>70-500 мс.</nobr> Сама за данными Jev не ходит, так что собирает их по-прежнему языковая модель с инструментами, а Jev достаётся только выбор действия. Ограничения: не больше 255 вариантов и <a href="https://www.trendingtopics.eu/jev-warum-dieses-neuartige-ki-modell-gerade-entwickerinnen-begeistert/">никакого текстового объяснения</a>. Сейчас готовой интеграции в выпущенных версиях Flink Agents нет, а цифры скорости и калибровки пока в основном от самого разработчика, но сама концепция многообещающая.</li> <li><strong>Теневой режим.</strong> Начинать стоит с режима, в котором агент предлагает, а действует человек. Пару недель мы сравниваем решения агента с решениями дежурных и только потом включаем автоматику по одному типу действий, начиная с самого безопасного.</li> </ul> <p>Главное правило: никаких неограниченных прав. Иначе однажды мы проснёмся и узнаем, что нейросеть сочла проблемой всю нашу систему и аккуратно её устранила. Это шутка, но с долей правды: агент может ровно то, что ему разрешили.</p> <h3>Плейбук, который пишет себя сам</h3> <p>Вернёмся к ночи из начала. В логах одного из сервисов начинают сыпаться ошибки. Предфильтр сворачивает их в одно происшествие. Агент запрашивает метрики, видит, что потребление памяти дошло до лимита, а новых релизов за сутки не было, и предлагает перезапуск. Перезапуск есть в белом списке, лимит не исчерпан, поэтому код выполняет его сам. С первой ошибки проходит около минуты, и дежурный даже не просыпается.</p> <p>Утром инженер видит отметку «авария устранена» и полный след решения: что пришло на вход, какие инструменты вызвал агент и что они вернули, почему он выбрал перезапуск. Flink Agents пишет каждое событие, включая обращения к модели и инструментам, в журнал, который с версии 0.3 по умолчанию виден в веб-интерфейсе Flink. Длинные записи в нём по умолчанию сокращаются, поэтому для полного следа нужен подробный режим.</p> <p>Это плейбук нового типа. Инструкция выполняется в момент проблемы и смотрит на систему в реальном времени, а документ поддерживать не нужно.</p> <p>Поддерживать что-то всё-таки придётся: короткий список разрешённых действий, лимиты и промпт. Энциклопедия на сотни страниц не нужна. Такой список легко проверять на ревью, хранить в git и прогонять на записанных прошлых инцидентах.</p> <h3>Сколько подъёмов на самом деле требовали человека?</h3> <p>Нейросети уже забрали у инженеров много шума — работы, которая требует много сил, но даёт мало результата: тесты, документацию, мелкие исправления. Дежурство — тоже шум, только дорогой. Каждая такая ночь стоит компании денег, а инженеру — сил.</p> <p>Проверить, сколько такого шума, просто. Откроем историю инцидентов за последний квартал и посчитаем, сколько из них закончились перезапуском, масштабированием или откатом. Это и есть доля ночей, в которых человек был нужен только для того, чтобы нажать кнопку.</p> <p>Речь не о том, чтобы убрать дежурного, а о том, чтобы изменить его работу. Базовые случаи может закрывать сама система, а человеку остаётся то, что действительно требует опыта, и проектирование системы, которая реагирует сама. Это интереснее, чем вставать в три часа ночи ради одной команды.</p> <p> #IMAGE_235736#</p> С осени 2025 года у Apache Flink есть подпроект Flink Agents, который встраивает нейросети прямо в потоковую … article Алексей Перминов, технический лидер в Exness https://www.itweek.ru/themes/detail.php?ID=235734 Wed, 14 Oct 2026 16:18:42 +0300 <p>Автономная некоммерческая организация «Национальный центр компетенций по информационным системам управления холдингом» (АНО «НЦК ИСУ») проанализировала практики крупнейших российских корпораций и выявила ключевой тренд в области применения генеративного искусственного интеллекта в ИТ-разработке. Им стал переход от «вайб-кодинга» (vibe-coding) как индивидуального инструмента сотрудника к созданию корпоративных агентских платформ, которые снизят стоимость разработки в 10 раз в перспективе нескольких лет, и мультиагентных команд. Тренды применения ИИ в корпоративной ИТ-разработке были представлены на сессии «Эффекты применения ИИ в системах управления ресурсами: метрики, кейсы, масштабирование», которую организовала «НЦК ИСУ» в рамках форума «Цифровые решения».</p> <p>По мнению корпоративных заказчиков, стратегия простого предоставления сотрудникам доступа к <nobr>LLM-инструментам</nobr> не дает ожидаемого эффекта в промышленных масштабах: выдача сотен доступов приводит лишь к росту затрат без значимого прироста эффективности. В отраслевой практике происходит разграничение: «вайб-кодинг» позиционируется как инструмент непрофессиональной разработки, тогда как «агентская разработка» становится дисциплиной для профессиональных команд, в которой ИИ-агенты выполняют исполнительские функции, а человек отвечает за архитектуру и постановку задач.</p> <p>Ключевым сдвигом становится использование агентных платформ корпоративного уровня во внутреннем контуре, позволяющих автономно охватить весь процесс разработки — от постановки задачи до поддержки готового решения. Такой подход демонстрирует потенциал существенного снижения себестоимости доработки корпоративных информационных систем. Если ранее на это требовались месяцы, сотни миллионов рублей и большие ИТ-команды, то сегодня развивать системы можно за недели и силами двух-трех высокоуровневых ИТ-специалистов и <nobr>25–30 ИИ-агентов.</nobr> Целевой ориентир корпораций — снижение себестоимости разработки ИТ-решений от 2 до 10 раз к 2030 году.</p> <p>Меняется и операционная модель ИТ-разработки. На смену традиционным ролям разработчика, аналитика, архитектора и тестировщика приходит фигура «соло-инженера» — специалиста, который проектирует систему, формулирует техническое задание и проверяет качество сгенерированного кода. К концу десятилетия классические роли в разработке могут исчезнуть, а весь ландшафт корпоративных систем будет переведен на агентские платформы вплоть до полного отказа от написания кода вручную.</p> <p>Трансформация затрагивает не только ИТ-подразделения, но и бизнес. Бизнес-заказчики получают возможность самостоятельно создавать работающие прототипы с помощью «вайб-кодинга» и приходить в ИТ-команду не просто с техническим заданием, а с полуготовым решением. Это меняет культуру взаимодействия: сотрудников учат «нанимать» цифровых сотрудников, ставить им задачи, контролировать их и объединять в сквозные процессы. Ожидаемый эффект — автоматизация непроизводственных функций с помощью ИИ-агентов с потенциалом роста производительности труда от 15% до 70% в зависимости от функции.</p> <p>Однако не все участники рынка видят мгновенный бизнес-эффект. На масштабе крупной компании значимого прироста в time-to-market пока нет. Главное достижение — резкое снижение стоимости экспериментов, что позволяет многократно тестировать гипотезы. Стоимость токенов становится значимой статьей бюджета. Кроме того, остаются барьеры в виде регуляторики и сертификации, а также сложности с переписыванием legacy-систем.</p> <p>«Корпоративная ИТ-разработка сегодня требует наличия платформы, которая позволяет автоматизировать с помощью ИИ-агентов весь процесс. Несколько инженеров, управляющие агентами, уже переписывают системы, на которые раньше уходили годы и сотни миллионов рублей. При этом ключевым становится не код, а инженерная экспертиза. Мы видим рождение новой роли инженера, управляющего мультиагентной командой. Через несколько лет такие специалисты полностью изменят ландшафт корпоративной разработки», — отметила заместитель генерального директора АНО «НЦК ИСУ» Екатерина Хитрова.</p> Автономная некоммерческая организация «Национальный центр компетенций по информационным системам управления холдингом» (АНО … message https://www.itweek.ru/themes/detail.php?ID=235732 Wed, 14 Oct 2026 10:06:37 +0300 <p><em>Примерно шесть из десяти организаций заявляют, что их стратегия в области искусственного интеллекта трансформирует бизнес, однако исследование IDC «</em><em>MaturityScape</em> <em>Benchmark</em><em>: </em><em>AI</em><em>-</em><em>Fueled</em> <em>Organization</em> <em>Worldwide</em><em>, 2026» показывает, что лишь 15,1% из них обладают соответствующими возможностями. Райан Смит, директор по контент-маркетингу IDC, рассказывает в корпоративном блоге, как компания измеряла этот разрыв, и предлагает четыре вопроса для проверки вашей организации перед тем, как сделать следующий шаг по шкале зрелости внедрения ИИ.</em></p> <p>Исследование IDC было направлено на то, чтобы выяснить, соответствуют ли реальные возможности заявлениям организаций; оказалось, что у примерно пяти из шести организаций такого соответствия пока нет.</p> <h3> Как IDC оценивала зрелость внедрения ИИ </h3> <p>Опрос, проведенный в мае 2026 г., охватил 1900 организаций на 20 рынках и включал вопросы двух типов.</p> <p>Первый тип — это самооценка организацией своего подхода к ИИ; на основе этих данных IDC разделила респондентов на две группы:</p> <ul> <li> «Выживающие» (Survivors): находящиеся в ситуации, когда либо отсутствует общекорпоративная стратегия ИИ (проекты ведутся разрозненными командами), либо стратегия ограничена лишь отдельными функциями или сферами бизнеса. Их описания соответствуют первым трем стадиям зрелости.</li> <li> «Преуспевающие» (Thrivers): имеют общекорпоративную стратегию, которая либо внедряет ИИ во все сферы бизнеса для трансформации операционной модели, либо развивает сценарии использования ИИ для переосмысления продуктов и услуг. Их описания соответствуют двум высшим стадиям зрелости.</li> </ul> <p>Второй тип — это детальные вопросы о возможностях организации в четырех аспектах: стратегия, управление, персонал и технологии. IDC оценила ответы, чтобы определить, на какой из пяти стадий зрелости находится каждая организация.</p> <p>Сравнение результатов по этим двум типам вопросов показывает, насколько заявления руководителей соответствуют реальным возможностям их организаций.</p> <h3>Каковы пять стадий зрелости внедрения ИИ</h3> <p>Стадии варьируются от «ситуативного подхода» (Ad hoc) до «оптимизации» (Optimized); высшую стадию IDC называет «организацией, работающей на основе ИИ» (AI-fueled organization).</p> <ul> <li> Ситуативность (Ad hoc): разрозненные пилотные проекты, отсутствие общекорпоративной стратегии или централизованного руководителя направления ИИ.</li> <li> Фрагментированность (Opportunistic): неформальная группа кураторов формирует стратегию вокруг нескольких сценариев использования, обещающих высокую отдачу.</li> <li> Воспроизводимость (Repeatable): центр компетенций с назначенным руководителем по ИИ разрабатывает дорожную карту для всей организации, а процессы управления формализуются.</li> <li> Управляемость (Managed): ИИ трансформирует операционную модель; появляются новые продукты и источники дохода, основанные на технологиях ИИ.</li> <li> Оптимизированность (Optimized): широкое распространение получают автономные агенты, а контроль и управление осуществляются в режиме реального времени.</li> </ul> <h3>На каком этапе модели зрелости ИИ находится большинство организаций</h3> <p>Половина организаций находится на этапе использования возможностей, а 61,3% — на двух начальных этапах с наименьшей зрелостью. Лишь 12,8% достигли двух наиболее зрелых этапов: 3,1% находятся на этапе оптимизации, а 9,7% — на этапе управляемости.</p> <p>За средним показателем скрывается неоднородность ситуации. Среднемировой показатель вырос с 2,39 до 2,43, при этом доля организаций на этапе оптимизации увеличилась с 0,4 до 3,1% — почти в восемь раз. IDC расценивает это как признак того, что группа лидеров начинает отрываться от основной массы, в то время как «широкая середина» движется вперед медленно.</p> <p>Что происходит при сопоставлении самооценки с результатами анализа</p> <p>Из 1149 организаций, отнесших себя к категории «процветающих» — что составляет около 60% выборки, — лишь 15,1% по результатам оценки попали на этапы управляемости или оптимизированности. По оценке IDC, это означает, что примерно пять из шести таких компаний по-прежнему действуют как «выживающие»: остальные 84,9% оказались на этапах ситуативности, фрагментированности или воспроизводимости.</p> <p>Тем не менее, самооценка не лишена смысла. Вероятность достижения двух высших этапов зрелости у «процветающих» примерно в 1,5 раза выше, чем у «выживающих»; IDC связывает это с наличием скоординированной корпоративной стратегии. Впрочем, абсолютные показатели в обеих группах невелики, а уверенность в себе и реальные возможности коррелируют слабо: 10,1% «выживающих» все же достигают двух высших этапов.</p> <h3>Почему амбиции в сфере ИИ опережают реальные возможности</h3> <p>Согласно анализу IDC, стратегию проще всего декларировать, но сложнее всего реализовать в масштабах всей организации. Разрыв между желаемым и действительным проявляется в тех аспектах, которые труднее всего переоценить или приукрасить. IDC выделяет следующие проблемы:</p> <ul> <li> отсутствие формализованных механизмов управления, которые можно было бы реально применять на практике;</li> <li> недостаточно надежные фундаменты данных и платформ, не способные обеспечить работу в промышленных масштабах;</li> <li> персонал, не прошедший необходимую переподготовку и адаптацию к изменениям.</li> </ul> <p>В результате организация может позиционировать себя «работающей на основе ИИ», но на деле ее деятельность все еще соответствует лишь стадии фрагментированности.</p> <p>Оценки по отдельным направлениям подтверждают эту картину. Технологический аспект характеризуется наименьшей зрелостью: 66,5% организаций находятся на двух начальных стадиях развития в этой сфере. Зрелость персонала чаще всего соответствует стадии фрагментированности (51,2%). Наибольший прогресс наблюдается в сфере управления — именно здесь наиболее «процветающие» вырываются вперед: 20,1% из них достигают двух высших стадий зрелости управления, тогда как среди «выживающих» этот показатель составляет 12,2%. Тем не менее, 57,2% всех организаций по-прежнему остаются на двух начальных стадиях развития в области ИИ.</p> <p>Андреа Сивьеро, вице-президент IDC по стратегиям развития бизнеса на базе ИИ, характеризует эту ситуацию как разрыв, при котором стратегия опережает практическую реализацию, а главным препятствием становится нехватка квалифицированных кадров.</p> <h3>Как продвигаться по модели зрелости в сфере ИИ</h3> <p>Начните с оценки своей организации по четырем ключевым направлениям:</p> <ul> <li> Кто на уровне совета директоров отвечает за ИИ и как часто предоставляются отчеты?</li> <li> Какие механизмы управления и контроля реально работают в вашей компании уже сегодня?</li> <li> Позволяют ли ваши данные и платформы внедрить в промышленную эксплуатацию следующий сценарий использования ИИ?</li> <li> Какая доля сотрудников прошла переобучение для работы с технологиями ИИ?</li> </ul> Примерно шесть из десяти организаций заявляют, что их стратегия в области искусственного интеллекта трансформирует … article https://www.itweek.ru/themes/detail.php?ID=235730 Wed, 14 Oct 2026 09:54:17 +0300 <p>По данным OWASP, инъекция промптов (prompt injection) уже несколько лет стабильно занимает первую строчку в списке угроз для <nobr>LLM-приложений.</nobr> И это неудивительно: в 2026 году ИИ-агенты — это уже не просто чат-боты, а полноценные участники бизнес-процессов с доступом к корпоративным API, базам данных и внутренним сервисам.</p> <p>Если вы уже задумались о защите или даже выбрали решение — отлично. Но внедрить ограничительные барьеры (guardrail) — это только первый шаг. Гораздо важнее понять, насколько они действительно эффективны: какие атаки пропускают, насколько замедляют работу моделей и как быстро адаптируются к новым техникам обхода.</p> <p>Классические метрики информационной безопасности здесь работают не всегда. Количество заблокированных угроз или время отклика — привычные ориентиры, но в мире ИИ-агентов картина сложнее. Модель генерирует текст на естественном языке, атака может быть замаскирована под обычный запрос, а задержка в 200 мс, незаметная для веб-приложения, способна заметно повлиять на пользовательский опыт в диалоговом интерфейсе.</p> <p>Чтобы оценить защиту ИИ-агентов по достоинству, стоит смотреть на другие цифры. Вот пять метрик, которые помогут быстро и системно разобраться в возможностях решения.</p> <h3>Метрика 1: качество детекции с детализацией ошибок</h3> <p>Оценивать защиту только по абстрактной «точности» — не самый надёжный путь. Гораздо информативнее смотреть сразу на два показателя:</p> <p><strong>ASR (Attack Success Rate)</strong> — доля атак, которые защита пропустила.</p> <p><strong>FPR (False Positive Rate)</strong> — доля обычных запросов, которые защита заблокировала по ошибке.</p> <p>В корпоративных сценариях важно, чтобы инъекции не проходили — ASR должен стремиться к нулю. Но если защита при этом блокирует каждый третий легитимный запрос, сотрудники быстро найдут способ ее обойти. Задача — найти баланс, при котором защита надежна, но не мешает работе.</p> <h3>Метрика 2: инференс-задержка</h3> <p>Это время, которое защитный шлюз тратит на анализ контента. В диалоговых сценариях счёт идёт на миллисекунды, и здесь ключевой показатель — TTFT (Time to First Token), то есть время до появления первого токена ответа модели.</p> <p>Защитный прокси не должен заметно замедлять стриминг ответа. При этом важно смотреть не только на средние значения, но и на P95/P99 — как ведёт себя решение под пиковой нагрузкой, когда в очередь выстраиваются сотни запросов. Именно эти хвосты распределения показывают, сохранится ли комфортный пользовательский опыт в часы максимальной активности.</p> <h3>Метрика 3: пропускная способность и масштабируемость</h3> <p>Решение должно горизонтально масштабироваться под рост числа одновременных сессий — без потерь во времени отклика и без потери контекста запросов.</p> <p>Особенно это важно в агентных сценариях, когда один запрос пользователя запускает цепочку внутренних вызовов между моделями и инструментами (tool calling). Если на каждом из нескольких шагов срабатывает проверка guardrail, задержка суммируется. Хорошее решение учитывает эту специфику и не превращает пятисекундную задачу агента в заметно более долгую из-за накладных расходов на безопасность.</p> <h3>Метрика 4: кросс-языковое и мультимодальное покрытие</h3> <p>Уязвимости часто эксплуатируются через низкоресурсные языки, транслитерацию, смену кодировок (Base64, циклические сдвиги), гомоглифы или встраивание инструкций в изображения и аудио.</p> <p>Инструмент защиты должен покрывать всё входное пространство модальностей, доступное целевой модели. Если фильтр безопасности работает только с английским текстом, а модель принимает другие языки или изображения, — защита получается неполной. Удобный ориентир здесь — процент покрытия модальностей и методов обфускации: защита должна видеть то же самое, что и сама модель.</p> <h3>Метрика 5: скорость адаптации к новым векторам атак</h3> <p>Jailbreak-техники эволюционируют ежедневно. Ключевой индикатор зрелости решения — время от появления новой техники обхода до момента, когда защита начинает её распознавать.</p> <p>Стоит уточнить у вендора, как именно обновляется guardrail: доставляются новые сигнатуры, обновляются правила или пересобирается классификатор, отсекающий опасные запросы. И главное — происходит ли это без остановки сервиса. Если обновление правил занимает недели или требует простоя, это сигнал пересмотреть подход.</p> <h3>Как применить это на практике для безопасности ИИ-агентов</h3> <p>Эти пять метрик — готовый чек-лист для диалога с вендорами и внутренней оценки. Их можно заложить в требования к PoC, сравнить несколько решений между собой или провести аудит уже работающей защиты.</p> <p>Рынок AI Security только формируется, и у компаний сейчас отличная возможность выстроить архитектуру защиты ИИ-агентов правильно с самого начала. Те, кто уже сегодня начнут применять системный подход и измерять эффективность защиты конкретными цифрами, через год получат не только снижение рисков, но и реальное конкурентное преимущество — ведь в эпоху автономных ИИ-систем выигрывает тот, кто умеет ими безопасно управлять.</p> <p> #IMAGE_235731#</p> По данным OWASP, инъекция промптов (prompt injection) уже несколько лет стабильно занимает первую строчку в списке … article Максим Горшков, технический директор “СофтМедиаЛаб” https://www.itweek.ru/themes/detail.php?ID=235728 Tue, 13 Oct 2026 18:12:48 +0300 <p><nobr>18-19</nobr> сентября в Москве прошёл форум ProcessTech 2026, организованный компанией «Инфомаксимум». Форум был посвящен актуальным аспектам технологий процессной аналитики (Process Mining) и майнинга задач (Task Mining) и собрал более 550 участников.</p> <p>Главным трендом года в данной области, по мнению организаторов форума, стал переход от преимущественно ретроспективного анализа процессов к опережающему управлению ими: мониторингу процессов в реальном времени, оценке рисков возможных отклонений от запланированных сценариев и предложению действий до превращения рисков в убытки. Данные Process Mining, использующего журналы событий корпоративных систем, и Task Mining, анализирующего действия сотрудников за ПК, становятся контекстом для LLM и ИИ-агентов, а на смену традиционным дашбордам приходят мультиагентные ИИ-системы, выдающие гипотезы на естественном языке. Потенциал использования такого подхода «Инфомаксимум» оценивает в <nobr>2,5-3 трлн.</nobr> руб. в год.</p> <p>Рассказывая о фирменной платформе Proceset, генеральный директор компании «Инфомаксимум» Александр Бочкин подчеркнул, что единицей автоматизации должна быть не операция, а бизнес-результат, например оформление заказа или урегулирование претензии. «Цифровой сотрудник» сам предлагает варианты автоматизации с обоснованием, к примеру, подготовить черновик заказа в системе «1С» после анализа 18,5 тыс. заявок и задаёт условия передачи кейса человеку, например при противоречии в данных, юридических рисках или низкой уверенности модели в результате.</p> <p>По его словам, ИИ это трактор, которому нужен маршрут, задаваемый контекстом бизнес-процессов: фактические последовательности выполнения процессов восстанавливаются с помощью Process Mining, действия сотрудников анализируются с помощью Task Mining, а теперь используются также регламенты и пары «документы на входе и на выходе» для реверс-инжиниринга процессов. Набор специализированных инструментов-вызовов для нейросетей сокращает разработку в <nobr>5-10 раз,</nobr> а система диспетчеризации ИИ-агентов с «верификатором» и «судьёй» доводит многонедельный план до реализации без участия людей.</p> <p>Как рассказал представитель «Билайна» Расул Булатов, в его компании вопрос «как автоматизировать то, что делает человек» заменили вопросом «должна ли такая работа вообще существовать». Там, где есть цифровой след, Process Mining строит модель фактического выполнения процесса и находит лишние согласования; где следа недостаточно, Task Mining помогает выявить ручные этапы, такие как переключение между окнами, копирование данных, использование Excel. Детерминированную рутину можно передавать роботам RPA и другим средствам автоматизации, а ситуации, требующие дополнительного контекста или решения, нужно оставлять за человеком. За полтора года в «Билайне» проведен редизайн более 35 процессов, годовой эффект от этого превысил 80 млн. руб., time-to-market сокращён на <nobr>10-50%,</nobr> выявлено 45 тыс. часов рутины.</p> <p>Как сообщил Рамазан Абакаров («РусГидро ИТ сервис»), в его компании применили Process Mining к закупкам на пятилетних данных SAP и системы документооборота LanDocs — от заявок до исполнения договора и оплаты. Процессы связали с бизнес-результатом: модель выявляет нарушения сроков поставок и оплаты, расхождения плановых и фактических объёмов закупок, незакрытые обязательства (например, 20,5% счетов-фактур регистрируются с задержкой более недели). Task Mining в общем центре обслуживания позволяет сопоставить фактическую длительность операций с нормативами.</p> <p>В планах — наблюдение за процессами в реальном времени: использование данных Process Mining и Task Mining как контекста для ИИ, оценка вероятности нарушения сроков и выбор реагирования. Пока это только направление развития, в котором ИИ, как подчеркнул Рамазан Абакаров, должен оставаться помощником человека.</p> <p>Павел Лабазнов (ФНС России) рассказал, что из 354 ключевых процессов в ФНС процесс-майнингом сегодня охвачено 100 (28,2%). До 90% трудозатрат уходит на подготовку данных. Чтобы ускориться, в Службе дописали к базовой платформе собственные модули.</p> <p>Гибридная аналитика, сопоставляя события Task Mining с журналом Process Mining, нашла жалобы, по которым проект решения пересылается в Word и перепечатывается. Имитационное моделирование «в два-три клика» показало, что автоматизация одного шага сократит процесс по упрощенной системе налогообложения с 5 дней 17 часов до 5 дней 6 часов. Анализ корневых причин автоматически ранжирует атрибуты, статистически связанные с длительностью процесса, а матрица отклонений выявляет редкие, зацикленные и нерегламентные события.</p> <p>С созданием 13 центров компетенций число гипотез выросло с 798 в 2024 г. до 3898 в <nobr>2026-м.</nobr> В планах создание «магазина цифровых следов», машиночитаемого регламента, приёмки проекта анализа вместе с новым ПО и подсказчика в будущей АИС «Налог-4».</p> <h3>Актуальные проблемы и тренды Process Mining и Task Mining</h3> <p>Одна из актуальных проблем процессной аналитики — качество и разрозненность данных: логи из разных систем не согласуются между собой, часть процессов вообще не оставляет логов. По словам Александра Бочкина, проблема сохраняется, но возможности исследовать фактическую работу у компаний расширились. Системные логи фиксируют только часть происходящего. Например, между регистрацией заявки и её согласованием сотрудник может сверять сведения в нескольких программах, переносить их в таблицу, исправлять ошибки. В журнале событий будут видны начало и конец этапа, а работа между ними — нет.</p> <p>«Мы решаем эту задачу с помощью Task Mining, которая автоматически выявляет бизнес-операции на основе действий сотрудников за компьютером. Система находит повторяющиеся последовательности, показывает, сколько времени занимает работа и какие затраты с ней связаны. При этом компания может обнаружить операции, которые заранее не описала, — сказал Александр Бочкин. — Конечно, Task Mining не отменяет проверки качества данных. Заказы, платежи и другие объекты по-прежнему нужно корректно связывать между системами, а офлайн-активность — дополнительно исследовать. Но отсутствие логов уже не означает, что эту часть работы нельзя изучить».</p> <p>Есть и другая причина, по которой проекты не дают ожидаемого результата: компания увидела потери, но ничего не изменила. По словам Александра Бочкина, чтобы внедрить автоматизацию, ей ещё нужно подготовить задание, найти разработчиков, дождаться реализации. «Мы сокращаем этот путь: данные о фактической работе становятся основой задания для ИИ, который создает автоматизацию, — отметил он. — При этом сначала нужно определить, какие операции можно автоматизировать и где это экономически оправданно. Ускорение редкой операции с небольшими трудозатратами может не окупить даже стоимость разработки».</p> <p>Другая проблема: как обеспечить условия для самостоятельного выполнения ИИ-агентами рабочих процессов? По словам Александра Бочкина, прежде всего агентам не хватает контекста конкретной компании. «Регламенты помогают далеко не всегда: реальная работа отличается от описаний и меняется быстрее, чем их успевают обновлять. Если передать ИИ устаревший регламент, можно быстро получить автоматизацию, которая воспроизводит ненужные действия или пропускает важные, — сказал он. — Process Mining и Task Mining помогают восстановить фактический порядок работы. Это дает основу для разработки, но цели и допустимые правила по-прежнему определяет человек».</p> <p>Как отметил Александр Бочкин, даже при наличии точных данных модель может ошибиться или пропустить обязательный шаг. «Поэтому мы разделяем создание автоматизации и её исполнение. ИИ помогает разрабатывать приложения и скрипты, взаимодействующие с корпоративными системами через API. Затем работа выполняется по заранее заданному и проверенному сценарию. К нейросети обращаются на тех этапах, где нужны её возможности. Это ограничивает влияние ошибок ИИ на выполнение процесса», — пояснил он.</p> <p>Task Mining предполагает наблюдение за работой персонала. Как индустрия балансирует между глубиной аналитики и доверием людей, действия которых подвергаются анализу? «Доверие зависит от того, какую задачу ставит руководство и что происходит после анализа. Людям важно заранее объяснить, зачем собирают данные, какие действия изучают и какие решения будут принимать. Обещание повысить эффективность слишком абстрактно. Гораздо понятнее конкретная задача: выяснить, почему при обработке одного обращения сотрудник трижды вводит одни и те же сведения», — отметил Александр Бочкин.</p> <p>По его словам, количество кликов ничего не говорит о пользе сотрудника: один обрабатывает типовые обращения, другой разбирается со сложными случаями. Поэтому результаты нужно обсуждать с участниками процесса — они могут объяснить причины действий, которые в данных выглядят лишними.</p> <p>«Не менее важно, чтобы сотрудники увидели результат исследования в своей работе: исчез двойной ввод, сократилась подготовка документов, стало меньше ручных проверок. Это даёт понятный ответ на вопрос, зачем проводился анализ, — сказал Александр Бочкин. — При этом польза от анализа не оправдывает сбор любых данных. Собирать нужно только то, что требуется для задачи: без личных сведений, с защитой чувствительной информации, ограниченным доступом и сроком хранения. Если достаточно данных по операции или подразделению, оценивать отдельных сотрудников незачем».</p> <p>Объектно-ориентированный процессный майнинг (OCPM, одновременное отслеживание и увязывание множества разных объектов) рассматривают как следующий шаг эволюции направления. Насколько это актуальный тренд?<strong> «</strong>Я ожидаю постепенного распространения этой модели. В первую очередь она полезна компаниям, которым для решения конкретных задач уже недостаточно анализа отдельных процессов. Например, один заказ исполняется несколькими поставками, а один платёж закрывает несколько счетов. Объектно-ориентированный подход позволяет сохранить эти связи и исследовать, как задержка одной части работы отражается на других», — считает Александр Бочкин.</p> <p>По его словам, практическую пользу анализа таких связей показывает проект hh.ru: с помощью мультипроцессной аналитики компания объединила пять бизнес-процессов из трёх информационных систем, охватив <nobr>5,3-5,4 млн.</nobr> кейсов. Единого идентификатора в системах не было, поэтому события сопоставляли по косвенным признакам — датам, идентификаторам клиентов и исполнителей. Это позволило измерить время между этапами в разных системах и долю ручных операций. Подготовленный дашборд сократил предварительное исследование процесса с месяца до двух—пяти дней.</p> <p>«Готовность здесь определяется качеством данных и самой задачей. Недостаточно связать объекты из разных систем — нужно понимать, какие решения компания сможет принимать на основе такого анализа. Если ради дополнительной детализации приходится усложнять модель, а практической пользы от неё нет, затраты не окупятся. Поэтому даже внутри одной компании такой подход имеет смысл сначала проверить на конкретной задаче, оценить результат и затем решать, где ещё его применять» — полагает Александр Бочкин.</p> Параллельно развивается и аналитика операций: уже применяется Multi Task Mining, который объединяет отдельные операции в сквозные процессы и позволяет оценить затраты на каждом этапе. Компания может увидеть, во сколько ей обходится весь процесс и где сосредоточена самая дорогая ручная работа. «Сейчас бизнес ищет, где сократить расходы без потери качества и объемов работы. Для этого нужно понимать, из чего складывается стоимость процесса и какие затраты можно убрать. Такая аналитика помогает обосновать конкретные изменения: что упростить, что автоматизировать и какую экономию это даст», — пояснил Александр Бочкин. 18-19 сентября в Москве прошёл форум ProcessTech 2026, организованный компанией «Инфомаксимум». Форум был посвящен … message Валерий Васильев https://www.itweek.ru/themes/detail.php?ID=235723 Tue, 13 Oct 2026 14:35:45 +0300 <p>Сбер представил GigaPlatform AI Studio — бесплатный сервис для тех, кто хочет попробовать ИИ на своих задачах и собрать собственного агента без программирования. Студия создана для частных пользователей и подходит как для личных дел, так и для работы. В ней можно расшифровать запись лекции, озвучить текст или разобраться в сложной теме. Можно также проверить идею для рабочего проекта или собрать помощника, который отвечает по загруженным документам. В одном интерфейсе собраны модели GigaChat, инструменты для их настройки, работа с голосом и документами и визуальный конструктор агентов из готовых блоков. Путь от идеи до рабочего прототипа занимает часы вместо недель разработки.</p> <p>В AI Studio доступны все актуальные версии ИИ-моделей Сбера, включая флагманскую GigaChat 3.5 Reasoning. В будущем разработчики смогут прямо в студии получить собственный ключ доступа к текстовым моделям GigaChat и бесплатно попробовать их в своих проектах через API.</p> <p>Проверка ИИ-гипотезы обычно занимает недели и требует привлечения программистов: для каждой технологии нужно писать код, а предпросмотра будущего решения, как правило, нет. Из-за этого путь от идеи до первой версии растягивается на месяцы, а инструменты приходится тестировать в разных средах. GigaPlatform AI Studio решает эти сложности. Например, в ней можно самостоятельно проверить жизнеспособность рабочей идеи — теперь это займет один день вместо недель или месяцев. Визуальный конструктор ИИ-агентов подойдёт тем, кто только знакомится с технологией и пока не знает, как сформулировать задачу в чате, чтобы агент выполнил её правильно. Сервис доступен бесплатно, вход — по Сбер ID. </p> <p>Антон Фролов, старший вице-президент, руководитель блока «Развитие генеративного ИИ» Сбербанка, отметил: «Лучше всех свою задачу знает тот, кто сталкивается с ней каждый день: студент перед сессией, менеджер, который тонет в почте, автор подкаста, которому нужен второй голос. Раньше, чтобы поручить такую задачу ИИ, нужно было уметь программировать или привлечь профессионала. В GigaPlatform AI Studio человек может сам попробовать разные модели, собрать своего помощника из готовых блоков и сразу проверить его в деле. Мы хотим, чтобы путь от идеи до работающего решения занимал один вечер, а ИИ стал таким же привычным инструментом, как текстовый редактор или таблицы».</p> <p>В GigaPlatform AI Studio доступны модели семейства GigaChat и инструменты для их настройки: можно одновременно отправить один запрос разным версиям модели и сравнить ответы, задать системные инструкции, изменить параметры генерации и проверить результат в чате. К модели можно подключить свои документы или собственную базу знаний — тогда она будет отвечать с опорой на эти материалы, например, в роли HR-консультанта, техподдержки первой линии или помощника отдела продаж. </p> <p>Для сложных исследовательских задач есть режим Deep Research — он изучает открытые источники, сопоставляет данные и собирает структурированный отчёт со ссылками. Можно задать или исключить определенные источники, загрузить собственные файлы и сохранить результат в PDF, HTML или Markdown. Диалог с моделью и ее настройки можно выгрузить в формате JSON — поделиться с коллегами или использовать как контекст для других ИИ-сервисов.</p> <p>Отдельное направление — работа с голосом: модели распознают речь и озвучивают текст с настройкой пауз, ударений и интонации, а специальная разметка позволяет создавать диалоги с разными голосами, например, в формате подкаста. Агента можно собрать без кода и запустить прямо в студии. Для этого в визуальном конструкторе достаточно соединить блоки: модель, базу знаний, голосовые настройки и сценарии диалога, а затем сразу протестировать и запустить. В студии можно создать агентов для работы с данными и таблицами, генерацией изображений, проверки почты, синтеза речи и других задач. Начинающие пользователи могут взять один из готовых шаблонов или собрать из блоков или при помощи ИИ-ассистента.</p> <p>В AI Studio есть встроенный помощник: он объясняет, что происходит на экране, и анализирует загруженные файлы. Для разбора документа достаточно загрузить его и нажать «Проанализировать» — помощник подготовит краткое содержание и ответит на вопросы. Ещё один инструмент студии — бесплатное приложение для компьютера, которое помогает со встречами. Оно распознаёт начало звонка, предлагает записать разговор, расшифровывает его и подводит итоги, причём ничего не отправляет в облако.</p> <p>Какие задачи можно решить в GigaPlatform AI Studio:</p> <ul> <li>работать с разными моделями без технической подготовки: задавать вопросы на интересные темы, визуализировать код, озвучивать тексты и расшифровывать аудио;</li> <li>снять с себя рабочую рутину без привлечения разработчиков: например, создать HR-консультанта, первую линию техподдержки или помощника по продажам на основе своей базы знаний;</li> <li>быстро проверить гипотезу, прежде чем писать код: собрать рабочий прототип, протестировать промпты и параметры перед интеграцией;</li> <li>познакомиться с технологиями Сбера: сравнить ответы разных версий GigaChat, попробовать голосовые модели и собрать первого агента из готового шаблона.</li> </ul> Сбер представил GigaPlatform AI Studio — бесплатный сервис для тех, кто хочет попробовать ИИ на своих задачах … message https://www.itweek.ru/themes/detail.php?ID=235722 Tue, 13 Oct 2026 14:29:57 +0300 <p>Институт статистических исследований и экономики знаний (ИСИЭЗ) НИУ ВШЭ изучает распространение практик применения ИИ в машиностроении. Как показали результаты анализа, предприятия отрасли демонстрируют прагматичный подход к внедрению технологии в производственной деятельности: используют ее для решения конкретных задач, умеренно оценивают текущие и ожидаемые эффекты и прогнозируют рост спроса на цифровые и производственные компетенции работников.</p> <p>Среди наиболее распространенных в машиностроении технологий — решения для обработки визуальных данных и текста, в том числе чат-боты и виртуальные ассистенты, помогающие экономить время на рутинных операциях в производственных и бизнес-процессах. К 2027 г. почти два из пяти обследованных предприятий планируют внедрить или считают перспективными технологии интеллектуальной поддержки принятия решений и управления, а каждое третье — ИИ-агентов.</p> <p>Предприятия машиностроения чаще всего применяют ИИ для моделирования продукции и процессов, проведения исследований и испытаний (37,8% организаций, использующих ИИ), диагностики оборудования (29,2%), планирования и контроля работ (26,7%). Более половины предприятий считают перспективным внедрение ИИ для контроля выполнения требований безопасности, управления промышленной безопасностью и работы с документацией.</p> <p>Эффекты от применения ИИ в машиностроении пока больше ожидают, чем фиксируют: к моменту проведения обследования в 2025 г. те или иные эффекты отметило примерно каждое пятое предприятие, использующее ИИ; в <nobr>2026–2027 гг.</nobr> получить эффекты рассчитывают более половины таких предприятий. Среди основных уже полученных результатов — снижение брака (18,8%) и сокращение времени операций с ростом производительности оборудования (17,6%). Ожидаемые эффекты чаще всего связывают с оптимизацией ИКТ-инфраструктуры (61%), а также снижением аварийности и повышением безопасности труда (60,7%).</p> <p>Большинство организаций отрасли, использующих ИИ, не ожидают, что внедрение технологии приведет к радикальному изменению общей потребности в работниках, в частности к сокращению персонала. При этом они прогнозируют рост спроса на цифровые и производственные компетенции, а также на работников всех категорий, кроме занятых рутинными административными функциями. Наиболее позитивные прогнозы касаются специалистов по ИКТ и квалифицированных рабочих.</p> <p>В каждой пятой обследованной организации машиностроения есть специалисты по работе с ИИ. Более 80% организаций-пользователей, в которых работают такие специалисты, испытывают дефицит этой категории кадров. Примерно каждая седьмая организация машиностроения (15%) поощряет сотрудников применять ИИ, а 9% взаимодействуют с образовательными организациями для подготовки специалистов с соответствующими навыками. Масштабы поддержки зависят от размера компании и отраслевой специфики.</p> <p>Ключевые технические требования к решениям на основе ИИ в машиностроении — безопасность, объяснимость (интерпретируемость) рекомендаций, выдаваемых ИИ-системой, и их точность. К числу условий расширения использования ИИ почти четверть обследованных предприятий относят регуляторную определенность в отношении применения ИИ и повышение рентабельности бизнеса. Для дальнейшего внедрения и применения ИИ необходима планомерная технологическая модернизация отрасли, которая возможна только в условиях расширения внутреннего спроса на отечественные машины и оборудование.</p> Институт статистических исследований и экономики знаний (ИСИЭЗ) НИУ ВШЭ изучает распространение практик применения ИИ … message https://www.itweek.ru/themes/detail.php?ID=235721 Tue, 13 Oct 2026 14:25:34 +0300 <p>Аналитика данных стала стратегическим приоритетом для большинства российских компаний. Однако используемые ими аналитические решения и СУБД для хранения данных не всегда обеспечивают необходимую производительность и масштабируемость при приемлемых затратах. Это один из ключевых выводов исследования рынка аналитических решений, проведённого компанией Postgres Professional среди более 300 представителей российских компаний из ИТ и разработки, финансового сектора, телекома, промышленности, ритейла и e-commerce, нефтегаза, энергетики и других отраслей.</p> <p>Согласно исследованию, 92% компаний уже рассматривают аналитику как стратегический ИТ-актив либо целенаправленно развивают её в этом качестве. При этом 80% респондентов продолжают использовать зарубежные аналитические решения — активно или для отдельных задач.</p> <p>Рост бюджетов на аналитику выводит на первый план внедрение и поддержку. </p> <p>Аналитика стала одним из драйверов ИТ-инвестиций: 36% опрошенных компаний увеличили бюджеты на нее за последние два года. При выборе решений компании учитывают не только стоимость лицензий, но и совокупную стоимость владения аналитическим стеком.</p> <p>«Сегодня компании всё внимательнее считают полную стоимость владения аналитического стека: помимо лицензий, она включает внедрение, интеграцию, масштабирование, поддержку и работу смежных команд. Поэтому при выборе аналитической СУБД на первый план выходит способность решения ускорять работу с данными и одновременно делать эксплуатацию более простой и предсказуемой. Именно этот запрос мы положили в основу развития наших аналитических продуктов», — комментирует Эльмира Рахматулина, руководитель продукта Postgres Pro AXE.</p> <p>Переход к новым аналитическим платформам определяется не только задачами импортозамещения. 47% участников исследования называют производительность на больших объёмах данных главным триггером для перехода на новую аналитическую СУБД.</p> <p>Компании оценивают аналитические СУБД по практическому эффекту: способность работать с растущими объёмами данных, встраиваться в действующий ИТ-контур, масштабироваться без остановки процессов и обеспечивать прогнозируемую стоимость эксплуатации — всё это становится весомее абстрактных технических характеристик при выборе решения. </p> <p> </p> Аналитика данных стала стратегическим приоритетом для большинства российских компаний. Однако используемые ими аналитические … message https://www.itweek.ru/themes/detail.php?ID=235720 Tue, 13 Oct 2026 10:40:54 +0300 <p><em>Искусственный интеллект берет на себя все больше задач начального уровня, заставляя организации переосмыслить то, как младшие сотрудники получают опыт и профессиональные навыки, необходимые для перехода на старшие должности, сообщает портал </em><em>AI</em> <em>Business</em><em>.</em></p> <p>Компании рассчитывают, что ИИ возьмет на себя значительную часть работы, которую раньше выполняли люди. Однако именно в процессе выполнения этих задач сотрудники зачастую и учатся своей профессии.</p> <p>Проблема становится все более актуальной по мере того, как ИИ начинает выполнять задачи, традиционно поручаемые младшим специалистам. Если ИИ способен справляться с рутинной работой быстрее или дешевле, компаниям может потребоваться меньше персонала для ее выполнения.</p> <p>Но у работы начального уровня есть и другая цель: она позволяет сотрудникам набраться опыта и развить профессиональные навыки, прежде чем перейти на более высокие должности.</p> <p>Финансовый директор компании Teikametrics Брайан Бопре посвятил первые десять лет своей карьеры построению финансовых моделей и изучению цифр, лежащих в основе ключевых бизнес-решений. Сегодня, по его словам, значительную часть этой работы может выполнять ИИ. Его беспокоит, что молодые сотрудники могут лишиться того опыта преодоления трудностей, который учил предыдущие поколения распознавать ошибочные решения.</p> <p>Схожие перемены могут ожидать и сферу кибербезопасности. Опрос сотрудников центров мониторинга и реагирования на инциденты (SOC) Swimlane «The New SOC Career Ladder» показал, что ИИ, вероятно, приведет к сокращению ряда должностей начального уровня в этих подразделениях, одновременно открыв возможности для перехода специалистов на более стратегические позиции.</p> <p>Это ставит перед работодателями сложную задачу: как готовить сотрудников к выполнению стратегических задач в условиях, когда исчезает работа, ранее обеспечивавшая необходимый для этого опыт?</p> <p>Навыки работы с ИИ становятся еще одним фактором, разделяющим рабочую силу. Новый опрос PwC «Global Workforce Hopes and Fears Survey 2026», проведенный среди почти 50 000 работников, показал, что 56% из них относятся к категории, которую компания назвала «машинным отделением» (engine room): это сотрудники, не обладающие специализированными навыками и не продвинувшиеся в изучении ИИ. Лишь половина из них уверена в стабильности своей занятости; кроме того, представители этой группы (одной из четырех, выделенных PwC) реже всего заявляли о готовности к адаптации.</p> <p>Разрыв может усугубиться из-за различий в оплате труда.</p> <p>Недавний отчет компании Payscale показал, что 61% работодателей пересматривают должностные инструкции из-за внедрения ИИ, однако менее половины из них заявили, что системы оплаты труда меняются соответствующим образом. Исследователи предупреждают о риске «мины замедленного действия» в вопросе удержания персонала: это может произойти, если компании будут предлагать более высокую зарплату новым сотрудникам с навыками работы с ИИ, не поощряя при этом должным образом действующих сотрудников, которые также осваивают эти компетенции. В совокупности всё это — не просто признаки того, что ИИ меняет характер работы. Эти факты указывают на более фундаментальную проблему для компаний: им придется пересмотреть подходы к профессиональному развитию сотрудников.</p> <p>Долгие годы корпоративная карьерная лестница строилась на принципе обучения в процессе работы. Начинающие специалисты выполняли задачи начального уровня, приобретали профессиональные навыки и учились принимать решения, постепенно беря на себя всё большую ответственность. Если же ИИ начнет выполнять значительную часть таких задач, компаниям придется искать иные способы обеспечения необходимого опыта.</p> <p>Некоторые компании уже предпринимают такие попытки. Например, Бопре объединяет в пары опытных сотрудников и новичков, которые лучше владеют инструментами ИИ. Старшие сотрудники объясняют логику принятия решений, а молодые специалисты помогают им работать с технологиями ИИ. Цель такого подхода — сохранить те элементы профессионального обучения, которые могли бы быть утрачены, если бы ИИ просто выдавал готовый результат.</p> <p>Однако этот переход не произойдет сам собой. Если компании исключат задачи начального уровня, не предложив сотрудникам альтернативных путей обучения, они рискуют лишиться возможностей для подготовки опытных специалистов, которые в конечном счете им понадобятся.</p> ИИ, возможно, и не уничтожит корпоративную карьерную лестницу, но вполне может устранить многие из тех ступеней, по которым люди традиционно Искусственный интеллект берет на себя все больше задач начального уровня, заставляя организации переосмыслить то, как … article https://www.itweek.ru/themes/detail.php?ID=235718 Tue, 13 Oct 2026 10:20:55 +0300 <p>На рынке труда сложилась странная на первый взгляд картина: компании продолжают сокращать целые команды, но при этом говорят о дефиците кадров и месяцами ищут специалистов. На самом деле никакого противоречия здесь нет.</p> <p>PwC в «Global AI Jobs Barometer 2026» <a href="https://www.pwc.com/gx/en/services/ai/ai-jobs-barometer.html">пишет</a>, что джуниор-роли, на которые сильнее всего повлиял ИИ, в семь раз чаще требуют навыков, прежде считавшихся сеньорскими — лидерства, стратегического мышления, способности принимать решения.</p> <p>Бизнес больше не хочет нанимать людей, чью работу можно поручить модели, а вот специалистов, которые умеют управлять процессом получения результата этой работы, ценит высоко. Рассмотрим, что делать компаниям и какие они — сотрудники, которым сейчас будут рады почти везде.</p> <h3>Дефицит кадров стал точнее</h3> <p>Раньше кадровый дефицит в ИТ описывали довольно широко: не хватает разработчиков, аналитиков, тестировщиков, DevOps’ов. Компании нанимали джунов, устраивали стажировки, чтобы вырастить людей внутри — и закрывали потребность в нужных специалистах.</p> <p>Сейчас эта схема работает хуже. Искусственный интеллект забирает часть задач, которые прежде считались входом в профессию: написать простой модуль, собрать черновой тест, подготовить документацию, найти типовую ошибку, предложить вариант реализации.</p> <p>Из-за этого изменилась сама ценность специалиста. На рынке может быть много свободных разработчиков и одновременно мало тех, кто действительно нужен компаниям. Дефицит все меньше проходит по грейдам и больше — по способности принимать инженерные решения.</p> <h3>Кто оказывается в зоне риска</h3> <p>Сильнее всего ИИ давит на роли, где много повторяемой работы и мало самостоятельных решений. Такие задачи обычно помогают человеку расти. Например, джун пишет код, получает замечания на ревью, видит последствия ошибок — и постепенно учится думать как инженер.</p> <p>Часть этого пути сокращается, когда агент пишет типовые фрагменты или находит баги вместо сотрудника. Но специалист должен понимать, что именно происходит внутри машины.</p> <p>Из-за этого в зоне риска оказываются те члены команды, которые не переходят от исполнения к управлению сложностью — не джуны как класс и не мидлы как уровень. Условный мидл, который просто хорошо пишет код, теперь конкурирует не только со специалистами, но и с ИИ-инструментами.</p> <h3>Нужный майндсет — какой он?</h3> <p>Пользоваться ИИ сейчас умеют многие, поэтому просто знать, как с ним работать, мало — нужно понимать, как продукт работает и где он может ошибиться. Для этого необходим подходящий майндсет, то есть тип мышления и восприятия.</p> <p>Он складывается из нескольких вещей:</p> <ul> <li> понимание архитектуры и взаимодействия компонентов;</li> <li> умение отличать рабочий результат от качественного;</li> <li> привычка проверять ограничения, а не только функциональность;</li> <li> способность задавать правила для ИИ-инструментов;</li> <li> ответственность за сопровождение результата;</li> <li> готовность разбираться, а не механически выполнять инструкцию.</li> </ul> <p>Разница проявляется еще до начала работы. Инженер сперва определяет стек, архитектуру, ограничения и правила проверки — и только потом подключает нейросети. Человек без такой базы сначала выполняет задачу, а затем уже разбирает, что у него вышло.</p> <p>Представьте сотрудника, который потратил недельный лимит токенов за один день — это как раз пример из второй категории. Он получил нужный результат, но использовал слишком дорогие модели. Где-то хватило бы более простых, а часть задач вообще стоило передать другим инструментам.</p> <p>Это похоже на попытку забить гвоздь микроскопом. Да, лучше, чем лбом — но инструмент все равно используется неправильно.</p> <h3>Почему вайбкодеры не заменят инженеров</h3> <p>Люди, которые еще вчера не умели писать код, а сегодня с помощью нейросетей запускают приложения, создают много шума. Это они чаще всего кричат, что разработчики больше не нужны — ведь у них-то получилось сделать рабочий сервис. И для бизнеса такая скорость тоже полезна: можно быстро проверять гипотезы и закрывать часть задач, не перегружая команду.</p> <p>На самом деле достаточно задать простой вопрос: «Если собрать таким же образом автопилот для самолета, вы полетите на нем?» В этот момент становится четко видно различие между прототипом и рабочим продуктом.</p> <p>Вайбкодинг может дать рабочий результат. Однако он быстро превращается в риск, если его нужно защищать, масштабировать, развивать и встраивать в рабочий контур без инженерной культуры.</p> <h3>Новых сеньоров сложнее растить</h3> <p>Самая большая кадровая проблема компаний — не в сокращениях джунов. Просто через несколько лет можно обнаружить, что не из кого растить сеньоров. Долгие годы путь был понятным: человек приходит на младшую позицию, много пишет сам, работает в ограничениях, получает замечания на ревью, видит последствия плохих решений — и только потом усиливается с помощью ИИ-инструментов.</p> <p>Теперь представьте, что человек с минимальным опытом сразу приходит в компанию и получает в распоряжение нейросеть. Получится ли у него увидеть, что технология предлагает рабочее, но в перспективе опасное решение? Едва ли.</p> <p>Пока рынок спасает кадровый запас инженеров, которые успели нарастить опыт до массового внедрения ИИ. Но этот резерв конечен. Если перестать пополнять его, поиск подходящего сотрудника станет сложнее.</p> <p>World Economic Forum в «Future of Jobs Report 2025» отмечает, что 63% работодателей уже <a href="https://www.weforum.org/press/2025/01/future-of-jobs-report-2025-78-million-new-job-opportunities-by-2030-but-urgent-upskilling-needed-to-prepare-workforces/">считают</a> дефицит навыков главным барьером для трансформации бизнеса, а 59% работников к 2030 году будут нуждаться в переобучении или повышении квалификации.</p> <h3>Сеньоры становятся бутылочным горлышком</h3> <p>В новой модели сеньор или тимлид управляет инженерной рамкой, в которой работают специалисты и ИИ-агенты. Он задает архитектурные правила, контролирует качество, понимает, какие задачи можно автоматизировать, а какие требуют человека.</p> <p>Раньше тимлид видел плохое решение на код-ревью и объяснял разработчику, как его исправить. Сейчас часть этой работы происходит раньше: руководитель группы задает правила агентам, чтобы они сразу работали по нужным стандартам и в нужной архитектуре.</p> <p>Следующий слой специалистов тоже выращивают именно сеньоры и тимлиды. Но здесь возникают сложности:</p> <ul> <li> некоторые сотрудники в какой-то момент понимают, что, занимаясь обучением, они снижают собственную уникальность на рынке и повышают конкуренцию. На этом их энтузиазм обычно и заканчивается;</li> <li> хороший инженер не значит хороший наставник. Уметь делать самому и учить этому других — разные навыки, и не у всех есть способности педагога. К тому же обучать чему-то взрослых людей куда сложнее, чем школьников.</li> </ul> <p>Если бизнес хочет растить людей новой формации, это должно стать частью системы — с выделенным временем и нормальной управленческой поддержкой.</p> <h3>Кадровый резерв не пополняется автоматически</h3> <p>Сократить входные позиции проще всего, ведь часть типовой работы уже и правда автоматизирована. Но с этой работой исчезают задачи, на которых прежде росли будущие сильные инженеры.</p> <p>Возникает отсроченная проблема. Сегодня бизнес экономит на исполнении — завтра столкнется с еще более явным дефицитом людей, способных принимать решения и управлять работой ИИ.</p> <p>Новая технология изменила саму экономику труда. Типовые задачи дешевеют, а все, что связано с контролем, архитектурой и сопровождением, дорожает. Поэтому рынок жестче разделяет специалистов по умению работать со сложностью — и те, кто не способен учиться и перестраиваться, по итогу начнут выпадать из сильных команд.</p> <h3>Что делать компаниям: памятка</h3> <p>Главная ошибка — одним махом сократить джунов и думать, что это решило проблему. В моменте такое решение может дать экономию, но в долгую разрушит кадровую воронку.</p> <p>Как можно действовать:</p> <ul> <li> менять формат развития джунов вместо того, чтобы отказываться от них полностью;</li> <li> давать младшим специалистам задачи на понимание кода и не ограничиваться только генерацией;</li> <li> учить работать с ИИ через ограничения и правила;</li> <li> закреплять за сеньорами и тимлидами наставничество как полноценную часть их ролей;</li> <li> оценивать способность сопровождать результат, а не только скорость выполнения задач;</li> <li> создавать внутренние правила использования ИИ-инструментов;</li> <li> развивать у сотрудников инженерное мышление и не учить их просто писать промпты.</li> </ul> <p>Развитие кадров в эпоху искусственного интеллекта не ограничивается разовой программой обучения. Это управляемая система, где у человека есть причина расти и понятные требования — и где он постоянно получает поддержку.</p> <h3>Подведем итоги</h3> <p>Сокращения и дефицит кадров могут происходить одновременно, ведь бизнес избавляется не от профессий — от старых ожиданий к ним. Работа, которую можно автоматизировать, становится нужна меньше, зато растет потребность в людях, способных управлять результатом этой автоматизации.</p> <p>Людей, которые умеют пользоваться нейросетями, уже много — и будет еще больше. В дефиците окажутся специалисты, которые понимают архитектуру, качество, риски и сопровождение, умеют задавать правила для ИИ и отвечать за итоговый продукт.</p> <p>Поэтому сегодня не так важно, сколько джунов можно заменить агентами. Важнее понять, из кого за несколько лет вырастет сеньор, способный этими агентами управлять.</p> <p>#IMAGE_235719#</p> На рынке труда сложилась странная на первый взгляд картина: компании продолжают сокращать целые команды, но при … article Константин Попандопуло, технический директор Umbrella IT https://www.itweek.ru/themes/detail.php?ID=235717 Mon, 12 Oct 2026 14:48:14 +0300 <p>Компания Security Vision представила обновление пятой версии своей Low-code/No-code платформы автоматизации процессов обеспечения информационной безопасности — Security Vision 5 (SV5). Новая версия помогает командам ИБ экономнее использовать хранилище событий, быстрее получать контекст при разборе алертов и сокращать объём работ по настройке платформы. Обновление также расширяет возможности визуализации данных и упрощает работу со связанными объектами.</p> <p>Для событий определённых типов в SV5 добавлено сжатие при хранении: стандартное с использованием LZ4 или максимальное с использованием zlib. Это позволяет уменьшить объём данных на диске и сдерживать потребность в дополнительном пространстве для хранения по мере роста потока событий. Кроме того, фильтрацию и сортировку в типе события теперь можно включать и выключать без реиндексации хранилища. Администратору не требуется перестраивать индекс ради изменения этих настроек — плановые изменения можно выполнять с меньшими затратами времени и ресурсов.</p> <p>При разборе алерта аналитик теперь видит в его карточке информацию о хосте, с которым связаны исходные события. Для свойств «Ссылка на объект» и «Ссылка на справочник» можно открыть краткую карточку связанного объекта, не закрывая текущий объект или представление. Специалисту проще проверить сведения, необходимые для оценки срабатывания, не теряя контекст и не возвращаясь к уже открытым карточкам.</p> <p>В графе появились правила отображения по свойствам и колонкам справочника, указанным в связях других правил. Также добавлены сохранение и поиск в графе, обновлена панель инструментов. Это помогает находить нужные элементы в схеме связей и использовать её при анализе данных. В аналитических виджетах «Таблица», «Текст с параметрами» и «Последовательность» теперь можно настраивать формы вывода значений, чтобы показатели было удобнее считывать и сравнивать в повседневной работе.</p> <p>Обновление затронуло и формы ввода. Для свойства «Да/Нет» добавлена форма «Иконка», позволяющая компактно разместить поле в карточке и обозначить его значение визуально. Многострочное поле «Строка» автоматически расширяется при вводе до заданного количества строк: пользователь видит больше текста и тратит меньше времени на прокрутку при заполнении длинных описаний.</p> <p>Обновлён интерфейс расписаний запуска рабочих процессов, создания отчётов и запуска коннекторов. В разделе организационной структуры переработаны оформление и расположение элементов меню. Администраторам проще ориентироваться в настройках регулярных запусков и находить нужные элементы — это особенно важно, когда количество настроенных процессов и задач увеличивается.</p> <p>Обновление SV5 объединяет изменения, которые помогают командам ИБ в повседневной работе: экономнее хранить события, получать нужный контекст при разборе алертов и настраивать платформу без лишних операций.</p> Компания Security Vision представила обновление пятой версии своей Low-code/No-code платформы автоматизации процессов обеспечения … message https://www.itweek.ru/themes/detail.php?ID=235716 Mon, 12 Oct 2026 10:33:03 +0300 <p><em>Угрозы со стороны искусственного интеллекта требуют наступательного подхода к безопасности. Хаим Мазаль, </em><em>CISO</em> <em>компании GitLab, рассказывает на портале </em><em>The</em> <em>New</em> <em>Stack</em> <em>о том, как команды, возглавляемые инженерами, используют проактивную автоматизацию для остановки киберпреступников.</em></p> <p>В июне Five Eyes («Пять глаз», разведывательный альянс пяти англоязычных стран<strong>:</strong> Австралии, Канады, Новой Зеландии, Великобритании и США) выпустил редкое совместное <a href="https://www.cisa.gov/news-events/news/five-eyes-cyber-security-agencies-statement">заявление</a>. Они предупредили, что передовые модели ИИ, как ожидается, «превзойдут текущие отраслевые ожидания, коренным образом трансформируя как наступательные, так и оборонительные возможности кибербезопасности».</p> <p>Это не теория; злоумышленники доказали свою способность обходить средства защиты. Уровень сложности для неискушенных злоумышленников, желающих осуществлять все более изощренные атаки, будет продолжать снижаться.</p> <p>Для защитников предупреждение «Пяти глаз» сигнализирует о том, что существующие подходы к безопасности не соответствуют экспоненциальному росту скорости и масштабов действий злоумышленников. В этой среде защита поверхностей атаки не сработает. Нужно переходить в наступление.</p> <h3>Лучшая защита — это хорошее нападение</h3> <p>Специалисты по безопасности инстинктивно воспринимают появление мощных моделей как сугубо плохую новость. Но переживания по поводу темпов развития возможностей ИИ ничего не изменят в программе обеспечения безопасности. Практически все средства защиты изначально создавались как инструменты эксплуатации уязвимостей, и команды безопасности перепрофилировали их для защиты. Логика, лежащая в основе большинства используемых сегодня коммерческих инструментов безопасности, применима и здесь, и защитники также имеют право на использование передовых технологий.</p> <p>Если злоумышленники теперь могут использовать ИИ для анализа активов организации и совершения атак на каждую уязвимость, защитникам необходим образ мышления, который заставит их сначала проанализировать свою собственную среду, используя ту же технологию. Этот инстинкт естественным образом вытекает из профессионального опыта, а не из осознанного выбора или метода.</p> <h3>Разные пути, разные подходы</h3> <p>CISO занимают свои должности несколькими разными путями. Некоторые приходят из отделов управления, рисков и соответствия требованиям, которые уже отвечают за риски. Некоторые приходят из ИТ-отделов, унаследовав безопасность вместе с остальной технологической инфраструктурой. Некоторые — из области архитектуры безопасности, они понимают, как фактически создавались системы. В последнее время всё большее число таких специалистов приходит из инженерных специальностей. Каждый путь формирует своё мировоззрение.</p> <p>Опыт в сфере соответствия нормативным требованиям или ИТ, как правило, формирует оборонительное мышление: ждать, пока логирование, мониторинг или инцидент покажут, куда инвестировать. Инженерный опыт, особенно в компаниях-разработчиках ПО, как правило, формирует наступательно мышление: активный поиск уязвимостей во всей программе, подобно злоумышленнику.</p> <p>Именно такое мышление нам сейчас нужно.</p> <h3>Мыслить как злоумышленник</h3> <p>Команды с наступательным мышлением видят себя создателями масштабируемых решений, которые автоматизируют результаты для бизнеса, постоянно выявляя потенциальные недостатки в программе, ландшафте угроз, инфраструктуре и каталоге активов.</p> <p>Для этого требуется настоящая любознательность; понимание того, как всё устроено, почему всё устроено именно так и что может пойти не так. Это основа исследований в области безопасности в целом: огромное любопытство к тому, как всё работает, как должно себя вести и как можно получить результаты, выходящие за рамки предполагаемых пользовательских кейсов.</p> <p>Изменения, которые я внес в свои команды, приближают нас к функциям, ориентированным на результат и управляемым инженерами. Каждая команда поддерживает автоматизированных агентов, которые выявляют риски, оценивают их, устраняют и сообщают о них в соответствии с конкретным бизнес-результатом. Безопасность приложений фокусируется на обеспечении инженерной поддержки, создании агентов, которые выполняют задачи от начала до конца на протяжении всего жизненного цикла разработки ПО. Команды по управлению и рискам становятся командами по обеспечению доверия и устойчивости бизнеса, ориентированными на постоянное подтверждение безопасности организации.</p> <h3>Создание правильного преимущества ИИ</h3> <p>Чтобы это работало, сосредоточьтесь на двух практических шагах.</p> <p>Во-первых, нейтральность относительно моделей. Создавайте рабочие процессы, которые не привязаны к одной модели или поставщику, поскольку лучшие сегодня модели и инструменты ИИ могут оказаться неподходящими через шесть месяцев. Нейтральность относительно модели также означает нейтральность относительно развертывания, что дает командам по безопасности возможность запускать модели в изолированных или самостоятельно управляемых средах, когда этого требуют условия размещения данных или защита интеллектуальной собственности, а не только возможность смены поставщика.</p> <p>Во-вторых, фокусировка. Делайте задачи агентов узкими и четко определенными. Если вы дадите агенту большую, расплывчатую задачу, он будет хорошо работать некоторое время, а затем потеряет ориентир и начнет генерировать все, что, по его мнению, удовлетворит запрос. Дайте ему конкретную задачу и уделите приоритетное внимание заблаговременному предоставлению правильного контекста, чтобы он мог более стабильно добиваться успеха. Именно так вы оркестрируете интеллектуальные результаты, не жертвуя точностью.</p> <p>Не каждая программа готова с первого же дня перестроиться на работу с агентами, и это нормально. Если программа находится на начальном этапе этого пути, не стоит усложнять задачу: проанализируйте каждое ключевое направление, определите желаемый конкретный результат и двигайтесь в обратном направлении, используя уже имеющиеся инструменты, — не нужно сразу полагать, что вам необходим совершенно новый технологический стек.</p> <h3>Пришло время переосмыслить подход</h3> <p>Самый большой риск на данном этапе — это «паралич анализа». Планка, которую нужно преодолеть злоумышленникам, постоянно снижается, тогда как требования к защите, напротив, растут. Мы больше не можем позволить себе роскошь ждать инцидента или выпуска патча от вендора. Наши системы безопасности должны соответствовать вызовам времени, если мы не хотим стать жертвами того, что наши противники меняют тактику и методы атак.</p> Угрозы со стороны искусственного интеллекта требуют наступательного подхода к безопасности. Хаим Мазаль, CISO компании … article