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=235145 Thu, 09 Jul 2026 14:33:12 +0300 <p>Innostage представила новую версию Innostage PAM 1.7.0 — решения для управления привилегированным доступом в корпоративных инфраструктурах. В новой версии доработаны сценарии, от которых зависит повседневная эксплуатация PAM в крупных корпоративных инфраструктурах: подключение к ресурсам в сетях с пересекающейся адресацией, прозрачность аутентификации и управляемость при хранении событий.</p> <p>Одно из ключевых обновлений касается работы с RDP-подключениями. В версии 1.7.0 появился портал выбора ресурсов для клиентских подключений, реализована поддержка VRF (Virtual Routing and Forwarding) и Kerberos для RDP Web и RDP Client. Также добавлен пароль временного токена и реализован его запрос при подключении. Эти изменения помогают адаптировать Innostage PAM к инфраструктурам со сложной сетевой архитектурой и сделать подключение к целевым ресурсам более удобным и безопасным для пользователей.</p> <p>Отдельный блок изменений связан с контролем аутентификации. В Innostage PAM появилась фиксация неуспешных попыток входа по сертификатам X.509. Также расширен контроль смарт-карт и токенов при подключении. Это повышает прозрачность входа по сертификатам, токенам и смарт-картам, что позволяет внедрить подходы беспарольной аутентификации. </p> <p>В версии 1.7.0 администратор может выбирать алгоритмы генерации SSH-ключей при ротации ключей, создании привилегированных учетных записей (ПУЗ) и при создании ключей для входа в Innostage PAM. Это усиливает безопасность процессов аутентификации с помощью SSH-ключей.</p> <p>Помимо этого, в новой версии улучшен функционал по защите данных доступа к внутренней БД, реализована маскировка паролей в фиксируемых командах для Web Proxy и исправлены ошибки при работе с Elasticsearch. Эти изменения повышают управляемость при эксплуатации PAM-системы и хранении событий.</p> <p>Отдельно Innostage начала работу над модулем поведенческой аналитики привилегированных пользователей. Модуль будет автоматически выявлять нетипичные действия без ручного анализа логов, формировать профиль поведения на основе статистических и математических методов, обнаруживать отклонения, деструктивные действия и признаки компрометации учетных записей. Данный модуль помогает ускорить выявление инцидентов безопасности и проведение расследований.</p> <p>«В проектах по внедрению и сопровождению PAM-систем сложность часто возникает не в настройке самого контроля, а в его ежедневном использовании: подключениях через разные сегменты сети, работе с токенами и смарт-картами, анализе большого объема событий. Если эти процессы неудобны, PAM быстро становится формальным контуром. В версии 1.7.0 мы доработали именно такие участки, чтобы контроль привилегированного доступа работал в реальной инфраструктуре заказчика, а не только на схеме внедрения», — отметил Игорь Еньков, владелец продукта Innostage PAM. </p> Innostage представила новую версию Innostage PAM 1.7.0 — решения для управления привилегированным доступом … message https://www.itweek.ru/themes/detail.php?ID=235144 Thu, 09 Jul 2026 14:29:24 +0300 <p>Обновление в последней версии СЭД Directum Lite для среднего и малого бизнеса поможет быстрее и без разработчиков автоматизировать внутренние обращения и пользовательские сервисы.</p> <p>С помощью инструмента «Диалоги» в Directum Lite можно создавать документы, запускать задачи, добавлять записи в справочники в ускоренном режиме. Пользователю больше не нужно разбираться, как правильно формировать запросы, по какому процессу идти и куда отправлять задачи. «Диалоги» упрощают получение данных. Сотрудники вводят информацию в одном окне с минимальным количеством кликов и ошибок. Благодаря этому бизнес может быстрее внедрять изменения и сократить затраты на разработку.</p> <p>Раньше администратору в no-code-редакторе, чтобы добавить новые поля и собрать формализованную информацию, требовалась помощь разработчиков для создания специальной формы. С помощью инструмента «Диалоги» администратор может настроить ПО так, чтобы у пользователя появилось всплывающее окно. В нем система сама запросит информацию и подтверждение действия.</p> <p>Чтобы при запуске нового инструмента пользователю было понятно, что от него требуется, у администратора есть возможность настроить инструкцию. В нее можно добавить подсказки по заполнению полей и ссылки на внутренние регламенты.</p> <p>Обновления доступны в облачной и локальной версиях системы Directum Lite.</p> Обновление в последней версии СЭД Directum Lite для среднего и малого бизнеса поможет быстрее и без разработчиков … message https://www.itweek.ru/themes/detail.php?ID=235143 Thu, 09 Jul 2026 11:00:31 +0300 <p><em>Инженеры и эксперты говорят, что проверка кода (</em><em>code</em> <em>review</em><em>) редко выявляет ошибки — её настоящая задача состоит в том, чтобы помечать код, который трудно поддерживать в дальнейшем, сообщает портал The New Stack.</em></p> <p>Рецензирование программного кода — это систематическая процедура обеспечения качества, в которой участвуют коллеги разработчика. Она предполагает тщательную проверку кода, когда разработчик отправляет запрос на изменение или слияние.</p> <p>Плохие процедуры проверки кода часто критикуют за неизбежные задержки и возможность создания узких мест из-за незначительных мелочей, зато, по идее, хорошая проверка кода выявляет ошибки на ранних стадиях, способствует развитию наставнических отношений и рассматривается как демократичный способ распределения ответственности. Хорошо, если бы все так и было.</p> <p>По словам старшего инженера-программиста Марка Доминуса, хотя многие компании, очевидно, проводят проверку кода, они не «четко формулируют, каким должен быть результат проверки», и это проблема. «Представьте, что вы начинающий инженер, и вам впервые поручают провести проверку кода. Каков должен быть результат вашей работы? Во многих местах, где я работал, этому вопросу не хватало четкости», — отмечает он.</p> <p>В своем посте на Mastodon на эту тему Доминус <a href="https://mathstodon.xyz/@mjd/115096720350507897">пишет</a>, что «любой, кто полагается на проверку кода для поиска ошибок, живет в мире иллюзий», главным образом потому, что в целом невозможно найти ошибки, просто изучая код. Он подчеркивает, что основная цель проверки кода — найти код, который будет сложно поддерживать в будущем.</p> <h3>Верный путь к плохим результатам проверки кода</h3> <p>Доминус отмечает, что в сценариях, когда от инженера-программиста ожидают неспешный просмотр изменений и указания на то, что ему не нравится, это приводит к плохим результатам, то есть побуждает людей пытаться навязывать свои собственные предпочтения относительно того, как все должно быть сделано, и тогда обычно возникают споры.</p> <p>«Иногда начальник дает младшему инженеру малоинформативное задание, например: „Попробуй найти какие-нибудь ошибки“, и это ставит джуниора в неприятное положение, — поясняет Доминус. — Может быть, он и найдет ошибку, отлично! Но что, если нет? Найти ошибки, просто изучив набор изменений, крайне сложно и требует определенной доли удачи».</p> <p>Он предлагает другой подход, при котором проектные тимлиды дают примерно такие указания: «Изучайте код два часа, записывайте все, что вам непонятно, и если вы не дочитали до конца, отметьте, где остановились».</p> <h3>Путь к получению реальной ценности</h3> <p>«Если рецензенту не хватит времени просмотреть всё, это уже ценный результат: изменения слишком велики или сложны, чтобы их можно было понять за два часа. Возможно, набор изменений следует разбить на два или более вариантов поменьше, которые следует рассматривать отдельно. Тогда независимо от того, насколько неопытен, некомпетентен или страдает от похмелья рецензент, он сможет выполнить поставленную задачу, и то, что он сделает, будет иметь реальную инженерную ценность», — объясняет Доминус.</p> <p>В данном случае реальная инженерная ценность — это отрицательный результат. Команда выявила код, который другой член команды не может понять, или набор изменений слишком громоздкий для текущего процесса проверки кода... или и то, и другое.</p> <h3>Проверка кода — это скорее театральное представление</h3> <p>Согласный в целом с этими утверждениями, Михаил Голиков, инженер по обеспечению качества в компании, занимающейся высоконагруженными платформами электронной коммерции, говорит, что «проверка кода — это своего рода театр», если команда полагается на неё для выявления ошибок.</p> <p>«Человек, бегло просматривающий diff, не может увидеть состояние гонки или скидку, которая становится отрицательной под нагрузкой. Проверка предназначена для выявления кода, который вы будете ненавидеть поддерживать позже; тесты — для кода, который не работает сейчас, — подчеркивает он. — Рецензент читает чистый diff, видит осмысленные имена и аккуратные функции и нажимает „одобрить“. Но ничто из этого не говорит вам о том, что ключевая часть приложения неисправна и предоставляет пользователю неработоспособный сервис».</p> <p>Голиков, который также является мейнтейнером Open Source-инструментов тестирования Python, объясняет, что ошибки, вызывающие сбои, находятся не в коде, который могут прочитать разработчики. Они возникают в состояниях, в которых код находится во время выполнения.</p> <h3>Не испытывайте чувство удовлетворения, не получив каких-либо доказательств</h3> <p>«Когда команда рассматривает проверку как фильтр ошибок, она выпускает проект с чувством удовлетворения и без каких-либо доказательств, а затем обнаруживает ошибки в продакшене, — отмечает Голиков. — Проверка кода предназначена для того, чтобы задавать вопросы типа: „Буду ли я ненавидеть поддерживать это через шесть месяцев?“ и „Действительно ли это работает?“, когда тест проводится на реальных входных данных, а не для того, чтобы человек бегло просматривал запрос на слияние под конец рабочего дня».</p> <p>Среди разработчиков и поставщиков практически нет споров о том, что процессы проверки кода нуждаются в изменениях, особенно в эпоху ИИ с растущим распространением агентных инструментов кодирования.</p> <p>Джуда Тауб, управляющий партнер Hetz Ventures, согласен с этим мнением и отмечает, что на протяжении многих лет инженерные команды рассматривали проверку кода как последнюю линию защиты от ошибок, но это никогда не было ее сильной стороной.</p> <p>«Проверка кода выявляет стиль, архитектуру, читаемость и удобство сопровождения, — говорит он. — Тесты выявляют ошибки. В производственной среде обнаруживается все остальное. Лучшие инженерные организации не полагаются на то, что другой разработчик обнаружит едва заметный крайний случай, скрытый в сотнях строк кода — они создают системы, которые автоматически проверяют корректность задолго до того, как запрос на слияние попадет к другому человеку. Проверка кода призвана обеспечить бесшовную работу над кодом следующего инженера».</p> <h3>Будущее проверки кода</h3> <p>Поскольку в игру вступает код, сгенерированный ИИ, Тауб считает, что неизбежно новой нормой станет ситуация, когда люди будут меньше напрямую проверять код и все больше — код, проверенный ИИ.</p> <p>«Роль инженера продолжает смещаться от самого кодирования к проверке архитектуры, намерений и бизнес-логики. В будущем даже это может быть автоматизировано», — предсказывает он.</p> <p>Здесь, безусловно, видна важная тенденции, позволяющая сказать, что командам разработчиков определенно нужно выйти из девяностых, если они сейчас там находятся.</p> <p>Совокупные революции нативных облачных технологий, платформенной инженерии и переходящего в агентное кодирование вайб-кодинга (можно добавить большие данные, DevOps и стандартизацию в сторону корпоративного Open Source, если хотите) изменили способ работы разработчиков ПО. Поэтому, очевидно, должны произойти и соответствующие изменения в способах проверки кода.</p> Инженеры и эксперты говорят, что проверка кода (code review) редко выявляет ошибки — её настоящая задача состоит … article https://www.itweek.ru/themes/detail.php?ID=235142 Thu, 09 Jul 2026 10:13:44 +0300 <p><em>В условиях развития агентного искусственного интеллекта плохое управление (</em><em>governance</em><em>) данными рискует усилить предвзятость и ошибочные решения. Управление должно стать основой для надежного ИИ реального времени, пишет на портале </em><em>InformationWeek</em> <em>Эрин Хамм, директор по данным в DataBee, принадлежащей компании Comcast.</em></p> <p>В течение многих лет управление рассматривалось как налог, который вы платите, чтобы избежать проблем — это было что-то, что вы делали реактивно, минимально и в основном для удовлетворения требований аудиторов. Это уже была неэффективная модель, но теперь агентный ИИ сделал ее неприемлемой.</p> <p>Развитие ИИ, особенно агентного, коренным образом изменило ожидания в отношении управления данными. Речь идет уже не только о соблюдении нормативных требований и ответственном управлении, но и об обеспечении надежных результатов ИИ.</p> <p>Теперь, когда ИИ получил широкое распространение, предприятия выходят за рамки экспериментов и начинают внедрять агентный ИИ и автономную бизнес-аналитику (BI) в операционные рабочие процессы и отчетность. Эти технологии выступают в качестве интеллектуальных «вторых пилотов» для автоматизации повторяющихся задач, проактивного выявления закономерностей и даже инициирования действий на основе предопределенных параметров управления и рисков.</p> <p>Однако успех зависит от готовности данных. Агентный ИИ процветает благодаря контекстно-насыщенным, высококачественным данным. Современным организациям необходимо уделять гораздо больше внимания данным, используемым для построения моделей ИИ, чтобы гарантировать их точность и происхождение. Без надежной архитектуры данных и управления ими эти системы рискуют усилить предвзятость или принятие бизнес-решения на основе неполной информации.</p> <h3>Расширение сферы управления</h3> <p>По мере распространения ИИ в организациях становится ясно, что необходим более строгий подход к управлению. Эта новая волна внедрения ИИ высвечивает необходимость расширения сферы деятельности команд управления, включая:</p> <ul> <li><strong> Контроль за предвзятостью и справедливостью. </strong>Наборы данных, используемые для ИИ, должны быть репрезентативными и свободными от системной предвзятости, однако большинство организаций не знают, что содержится в их обучающих наборах. Это не провал науки о данных, а скорее ситуация, когда управление должно вмешаться и помочь им получить необходимые знания.</li> <li><strong> Происхождение данных и прозрачность.</strong> Если команды не могут отследить происхождение данных, они не могут защитить результаты ИИ. Надлежащая политика обеспечит четкую видимость происхождения данных и их преобразования до того, как они достигнут систем ИИ.</li> <li><strong> Динамическое управление рисками.</strong> ИИ вносит новые риски, такие как дрейф моделей и галлюцинации, которые требуют тесного сотрудничества команд управления с командами безопасности и управления рисками. Это уже не только ИТ-проблемы; это проблемы управления рисками — и командам управления необходимо место за этим столом.</li> </ul> <p>За последние пару лет работа по управлению эволюционировала от преимущественно ориентированной на соответствие нормативным требованиям к стратегическому компоненту цифровой трансформации. Эффективные команды управления теперь тесно сотрудничают с командами безопасности, ИИ/машинного обучения и облачных операций для управления рисками и обеспечения инноваций во всей организации. Аналогичным образом, вместо реактивных аудитов после завершения цикла, управление может быть интегрировано в процессы жизненного цикла данных, уменьшая трение и повышая гибкость.</p> <h3>Проблема неоперационализированного управления</h3> <p>Наиболее распространенный вид неудачи — это не сопротивление внедрению ИИ, а управление посредством служебной записки. Когда речь идет об ИИ и его эффективном использовании, организации выигрывают от подхода, ориентированного на управление, с четко определенными ролями и обязанностями, а также ясной структурой использования ИИ в повседневной работе. Организациям может быть проще просто сказать «нет» ИИ, но это было бы ошибкой. Вместо этого им следует продумать все аспекты и разработать руководящие принципы, позволяющие людям использовать инструменты ИИ для повышения производительности.</p> <p>Организации со зрелыми, интегрированными практиками управления должны увидеть значительные улучшения. Они лучше подготовлены к ответственному использованию ИИ, снижению регуляторных рисков и поддержанию доверия клиентов при одновременном ускорении получения инсайтов.</p> <h3>Управление с включением ИИ в цикл</h3> <p>Эффективность и безопасность в управлении данными все чаще обеспечиваются интеграцией и автоматизацией. Организации, которые правильно подходят к этому вопросу, внедряют следующее:</p> <ul> <li><strong> Унифицированная видимость данных.</strong> Команды не могут управлять тем, чего не видят. Переходите к платформам, которые объединяют данные из нескольких источников в единое, нормализованное представление. Это уменьшает разрозненность и упрощает последовательное применение политик управления.</li> <li><strong> Политика как код. </strong>Применение правил в режиме реального времени всегда превосходит ретроспективные проверки. Внедряйте правила управления непосредственно в конвейеры обработки данных, обеспечивая реагирование в режиме реального времени, а не проверки постфактум.</li> <li><strong> Управление с приоритетом безопасности. </strong>С учетом стремительного роста объемов данных в гибридных и мультиоблачных средах происходит конвергенция управления с кибербезопасностью. Команды должны уделять приоритетное внимание безопасному обмену данными и мониторингу аномалий в рамках рабочих процессов управления.</li> <li><strong> Управление с помощью ИИ.</strong> ИИ следует использовать для классификации данных, выявления пробелов в соответствии нормативным требованиям и выработки рекомендаций по их устранению, освобождая человеческие команды для принятия более важных решений. Цель состоит не в замене команд управления на ИИ, а в том, чтобы прекратить заваливать их ручной работой.</li> </ul> <p>Управление имеет возможность стать фактором, способствующим развитию бизнеса, а не узким местом. Когда управление автоматизировано и интегрировано с безопасностью, организации могут быстрее внедрять инновации, сохраняя при этом доверие и соответствие нормативным требованиям.</p> <h3>ИИ в управлении станет конкурентным преимуществом</h3> <p>Организации, которые сейчас опережают конкурентов, — это не те, у кого самый сложный ИИ. Это те, чьи данные действительно готовы к его использованию: нормализованы, отслеживаемы, управляются в режиме реального времени и связаны во всех рабочих процессах безопасности. Эта готовность возникла не случайно, а благодаря архитектурным решениям, принятым задолго до того, как были определены сценарии использования ИИ.</p> <p>Устаревшие системы, которые не могут поддерживать обмен данными в режиме реального времени или автоматизацию управления, не только замедляют работу, но и создают накопленный риск, который усугубляется с каждой последующей ИИ-инициативой. Поэтому предприятиям следует уделять больше внимания нативным облачным архитектурам, тканям данных и экосистемам на основе API, поскольку это необходимые условия для масштабируемого ИИ.</p> <p>Готовое к ИИ управление не является необязательным, оно является основополагающим. Отстающие проигрывают не потому, что выбрали неправильную модель, а потому, что построили ее на основе данных, которым не могут доверять.</p> В условиях развития агентного искусственного интеллекта плохое управление (governance) данными рискует усилить предвзятость … article https://www.itweek.ru/themes/detail.php?ID=235139 Wed, 08 Jul 2026 15:28:27 +0300 <p>Российский разработчик СУБД Postgres Professional представил Postgres ProGate 1.3.0 — обновление продукта для миграции и репликации данных. В новой версии появилась поддержка распределённой реляционной СУБД Postgres Pro Shardman, отказоустойчивый режим работы prosync для непрерывной репликации и расширенные возможности безопасности.</p> <p>Postgres ProGate предназначена для проектов миграции, разового переноса данных и непрерывной репликацей между СУБД. Продукт помогает автоматизировать ключевые этапы работы с данными: первичную загрузку, синхронизацию изменений в режиме, близком к реальному времени, и проверку корректности переноса. Версия 1.3.0 расширяет сценарии использования ProGate для крупных распределённых систем, где важны не только скорость миграции, но и надёжность репликации, управляемость, отказоустойчивость и контроль качества данных.</p> <p>«В крупных проектах всё чаще требуется не просто перенести данные в новую СУБД, а обеспечить их непрерывную синхронизацию и встроить целевую систему в масштабируемую, отказоустойчивую архитектуру. В ProGate 1.3.0 мы добавили поддержку Postgres Pro Shardman как целевой системы, усилили отказоустойчивость prosync и расширили инструменты безопасности. Это помогает делать проекты миграции и репликации более предсказуемыми и надёжными для заказчиков с большими объёмами данных и критичными нагрузками», — отметил Евгений Кривов, руководитель продукта Postgres ProGatel.</p> <p>Ключевым нововведением ProGate 1.3.0 стала поддержка Postgres Pro Shardman в качестве приёмника данных. Теперь Shardman можно использовать как целевую СУБД как при разовом переносе данных с помощью procopy, так и при непрерывной репликации через prosync.</p> <p>В релизе появилась маршрутизация строк по шардам: данные из таблицы-источника можно распределять между сегментами Shardman-кластера по заданным условиям. Это позволяет управлять распределением данных уже на этапе миграции и готовить целевую систему к работе с большими объёмами и растущей нагрузкой.</p> <p>В prosync, утилите для <nobr>CDC-репликации,</nobr> появился режим высокой доступности. Несколько экземпляров prosync с одинаковой конфигурацией могут работать как кластер: один узел выполняет роль лидера, остальные находятся в резерве и готовы продолжить репликацию при отказе основного узла.</p> <p>Такой подход снижает риски остановки синхронизации данных во время длительных миграционных проектов и повышает надёжность непрерывной репликации в промышленных средах.</p> <p>Список поддерживаемых СУБД-источников расширен за счёт Oracle 11g. Теперь procopy и prosync поддерживают Oracle 11g, 12c, 18c и 19c.</p> <p>Также в новой версии улучшена работа с Oracle Real Application Clusters и сценариями обратной миграции PostgreSQL → Oracle. Это делает ProGate более гибким инструментом для сложных инфраструктур, где миграция может включать несколько типов источников и направлений переноса данных.</p> <p>В ProGate 1.3.0 усилены механизмы безопасности: увеличены требования к длине пароля, ограничено число попыток входа, добавлена обязательная валидация email, расширен журнал аудита, а после смены пароля администратором пользователь должен обновить пароль при следующем входе.</p> <p>Улучшения также затронули procheck — утилиту для проверки корректности переноса данных. В ней появились аутентификация, события безопасности, автоматическое определение кодировок источника и приёмника, а также исправления для более стабильной работы с пользовательскими типами, XML, геометрическими данными и объектами Oracle.</p> <p>Все утилиты ProGate теперь поддерживают подстановку переменных окружения в конфигурационных файлах. Это упрощает использование платформы в контейнерных и автоматизированных средах, где чувствительные параметры — например пароли и адреса хостов — не должны храниться напрямую в конфигурации.</p> Российский разработчик СУБД Postgres Professional представил Postgres ProGate 1.3.0 — обновление продукта для миграции … message https://www.itweek.ru/themes/detail.php?ID=235138 Wed, 08 Jul 2026 15:25:34 +0300 <p>Линейка продуктов на базе платформы «АКСИОМА» дополнена новым решением — «АКСИОМА ИскИн». «АКСИОМА» уже зарекомендовавшей себя на российском рынке как эффективный инструмент управления активами/ТОиР. Интеллектуальная система призвана стать удобным инструментом для анализа производственной информации, работы с корпоративными знаниями и поддержки принятия решений на промышленных предприятиях и объектах энергетики.</p> <p>Объём данных, с которыми ежедневно работают промышленные предприятия, растёт экспоненциально: эксплуатационная документация, регламенты, отчёты технических служб, журналы ремонтов, нормативные справочники. В этом потоке теряется главное — способность быстро находить нужную информацию и видеть связи между разрозненными фактами. Именно эту задачу решает «АКСИОМА ИскИн».</p> <p>Система объединяет разрозненные источники корпоративных данных в единое информационное пространство. Инженер, технолог или руководитель может задать вопрос на естественном языке — и получить не просто ссылку на документ, а структурированный ответ, основанный на данных из технической документации, инструкций и внутренних баз знаний. При этом каждый ответ сопровождается ссылками на исходные источники, что реализует принцип объяснимого искусственного интеллекта.</p> <p>Технологической основой решения служит корпоративный граф знаний. Он связывает оборудование, технологические процессы, документы, нормативные требования и производственные данные, позволяя выявлять неочевидные взаимосвязи между объектами и событиями. Это превращает разрозненные архивы в работающий интеллектуальный актив.</p> <p>«АКСИОМА ИскИн» предназначена для работы в цифровой среде самого предприятия — данные остаются в закрытом контуре организации. Это важно для объектов критической информационной инфраструктуры и предприятий, работающих в условиях строгих требований к технологическому суверенитету. Благодаря такой интеграции с существующими корпоративными системами решение не требует кардинальной перестройки ИТ-инфраструктуры, что обеспечивает быстрый старт и минимальные риски.</p> <p>Среди ключевых результатов внедрения — сокращение времени поиска информации, ускорение подготовки ответов на технические вопросы, повышение доступности корпоративных знаний и создание единой среды для работы специалистов. Наибольший эффект «АКСИОМА ИскИн» принесёт в энергетике, нефтегазовой отрасли, металлургии, химической промышленности, машиностроении и транспортной инфраструктуре. </p> Линейка продуктов на базе платформы «АКСИОМА» дополнена новым решением — «АКСИОМА ИскИн». «АКСИОМА» уже … message https://www.itweek.ru/themes/detail.php?ID=235137 Wed, 08 Jul 2026 15:24:08 +0300 <p>Эксперты компании «Информзащита» выявили рост спроса на гибридную модель проверки AI-систем: в 2026 году только 9% организаций готовы полностью доверить пентесты AI-автоматизации. Годом ранее такой подход поддерживали 29% респондентов. За двенадцать месяцев доля сторонников полного автономного тестирования сократилась на 20 процентных пунктов, тогда как число компаний, предпочитающих использовать автоматические средства для некритичных активов, а критичные системы проверять вручную, выросло на 22 процентных пункта — до 47%.</p> <p>Автоматические средства быстро находят известные ошибки конфигурации, проблемы с внешней поверхностью атаки, повторяемые недостатки в API и нарушения базовых политик безопасности. Однако AI-приложение редко ограничивается типовой веб-логикой. Поведение LLM зависит от системных инструкций, контекста диалога, версии модели, подключенных источников данных, прав пользователя, списка доступных агенту инструментов и ограничений, заданных в оркестраторе. Уязвимость может проявиться только при определенной последовательности действий, которую невозможно получить одиночным тестовым запросом. </p> <p>Разбивка по векторам уже зафиксированных AI-инцидентов подтверждает, что риск не ограничивается ошибками одной модели. В 44% случаев причиной становился shadow AI — использование сотрудниками несанкционированных внешних инструментов с передачей чувствительных данных. По 41% пришлось на отравление данных и моделей, а также на небезопасную обработку ответов LLM. Уязвимости в цепочке поставок были названы в 35% инцидентов, prompt injection — в 34%, ошибки LLM и слабости векторных баз и эмбеддингов — в 32% каждый. Далее следуют чрезмерные полномочия агентов и утечки системных промптов — по 24%, дезинформация — 20%, неограниченное потребление ресурсов — 15%. Автоматизированные средства полезны для регулярного контроля многих из этих направлений, но не способны самостоятельно подтвердить безопасность сложной связки между моделью, данными и бизнес-процессом.</p> <p>В исследовании 78% команд сообщили, что сталкивались с пропуском критичных уязвимостей автоматизированными средствами. Для AI-сервисов это особенно чувствительно: ошибка может находиться не в самом запросе к модели, а в том, как она интерпретирует данные из RAG-базы, вызывает внешние API, получает доступ к внутреннему контуру или действует от имени сотрудника. Механическая проверка не всегда способна увидеть связь между отдельными элементами такой архитектуры и оценить последствия их сочетания. </p> <p>«Снижение доверия к полной автоматизации не означает отказа от AI-инструментов в пентесте. Компании увидели пределы их применимости: сканер способен быстро проверить большую поверхность атаки, но не всегда распознает многошаговую цепочку, где результат зависит от контекста диалога, прав агента, подключенных данных и логики бизнес-процесса. Для критичных AI-систем автоматизация должна сокращать время на рутинные проверки, а итоговую оценку риска должны давать специалисты, способные воспроизвести действия атакующего», — объяснил Анатолий Песковский, директор Департамента наступательной безопасности компании «Информзащита». </p> <p>Наиболее показательный пример — prompt injection. В изолированной среде модель может корректно отклонять вредоносные инструкции, но изменить поведение после обработки специально подготовленного документа, сообщения из внешней системы или фрагмента истории диалога. Аналогично проявляются риски избыточной агентности: модель получает доступ к почте, CRM, файловому хранилищу или корпоративному API, а ошибка в разграничении прав позволяет выполнить действие, которое не должно быть доступно в данном контексте. Для проверки таких сценариев нужно моделировать действия атакующего, тестировать обход защитных ограничений, анализировать бизнес-логику и оценивать фактический объем полномочий AI-агента.</p> <p>Эти сценарии хорошо ложатся на классы рисков OWASP Top 10 for LLM Applications: prompt injection, data/model poisoning, improper output handling, supply-chain weaknesses, excessive agency, system prompt leakage, vector and embedding weaknesses и unbounded consumption. Автоматизация может обнаружить часть таких проблем, но не подтверждает безопасность всей цепочки от источника данных до бизнес-действия, которое модель выполняет после обработки запроса.</p> <p>Разбивка инцидентов по векторам атак подтверждает, что проблема не сводится к одному классу уязвимостей. В 44% случаев причиной становился shadow AI — использование сотрудниками несанкционированных внешних AI-сервисов и передача им чувствительных данных. По 41% инцидентов пришлось на отравление данных и моделей, а также на некорректную обработку ответов LLM. Уязвимости цепочки поставок фигурировали в 35% случаев, prompt injection — в 34%, ошибки LLM и слабости векторных баз и эмбеддингов — в 32%. Избыточные полномочия агентов и утечки системных промптов отмечались в 24% инцидентов, дезинформация — в 20%, неограниченное потребление ресурсов — в 15%. Автоматизация может обнаружить часть этих проблем, но не способна самостоятельно подтвердить безопасность всей цепочки от источника данных до бизнес-действия, которое модель выполняет после обработки запроса.</p> <p>Отраслевой разрез исследования не ранжирует сферы по уровню доверия к полной автоматизации и не дает статистики инцидентов для каждой вертикали. Однако состав выборки показывает, где вопрос особенно актуален: разработка ПО представлена 27% респондентов, здравоохранение — 21%, финансовые и страховые организации — 14%, информационные сервисы — 10%, другие отрасли — 27%. В разработке ПО AI-инструменты часто подключают к репозиториям, средам разработки и CI/CD-конвейерам, поэтому ошибка в правах агента может затронуть исходный код или цепочку поставки. В здравоохранении основной риск связан с обработкой медицинских данных и интеграциями с профильными системами. Для финансового сектора критичны операции с платежной информацией, персональными данными и сервисами, которые участвуют в принятии решений по клиентам. Информационные сервисы чаще работают с внешними запросами, большими массивами контента и поисковыми системами, что повышает значимость контроля источников данных и RAG-контуров. Указанные проценты отражают структуру выборки, а не уровень уязвимости отраслей. </p> <p>Сложность проверки усугубляется тем, что найденные проблемы не всегда быстро устраняются. В 2026 году AI- и <nobr>LLM-приложения</nobr> показали самую низкую долю закрытых высокорисковых уязвимостей среди всех типов пентестов — 38,4%. Годом ранее показатель составлял 21,1%, однако даже после роста он остается существенно ниже, чем у веб-приложений с 73,7% и API с 77,3%. При этом 77% организаций уже регулярно проводят оценки безопасности и пентесты AI-продуктов, а 59% используют red teaming или adversarial testing с фокусом на LLM. Проверок становится больше, но возможности команд по устранению сложных находок растут медленнее. </p> <p>Эксперты «Информзащиты» рекомендуют использовать автоматизацию для задач, где она дает стабильный и проверяемый результат: непрерывного мониторинга внешней поверхности, контроля конфигураций, инвентаризации сервисов, поиска повторяемых ошибок и повторных проверок после устранения уязвимостей. AI-системы, работающие с внутренними данными, персональной информацией, платежными операциями или действиями от имени сотрудника, должны проходить ручной пентест и red teaming до ввода в эксплуатацию, а затем — после изменения модели, системного промпта, RAG-базы, набора интеграций или прав доступа. Полная инвентаризация AI-сервисов, контроль shadow AI, отдельные сценарии для prompt injection и утечек через RAG, прозрачные SLA для ИБ, разработки и владельцев продукта помогут сделать результаты тестирования частью реального управления рисками, а не формальным отчетом.</p> Эксперты компании «Информзащита» выявили рост спроса на гибридную модель проверки AI-систем: в 2026 году только 9% … message https://www.itweek.ru/themes/detail.php?ID=235135 Wed, 08 Jul 2026 09:42:12 +0300 <p><em>Работа будущего, вероятно, потребует тщательного сочетания человеческих навыков и агентов искусственного интеллекта. Опрошенные порталом </em><em>ZDNet</em> <em>эксперты рассказывают, как успешно работать со своими коллегами-агентами.</em></p> <p>Беспокойство о том, насколько профессионально выполняет свою работу человек рядом с вами, больше не является вашей единственной заботой. Команда тех, кто хочет достигать срочных целей и добиваться отличных результатов, скорее всего, будет включать в себя широкий спектр коллег-людей и агентов ИИ.</p> <p>Мы вступаем в эпоху автономного бизнеса, где новые сочетания технологий и данных означают, что некоторые роли, которые мы сегодня считаем само собой разумеющимися — от базовых операционных задач до принятия решений — выполняются агентами, которые автономно обнаруживают, обсуждают и совершают действия.</p> <p>Gartner предполагает, что компании увеличат свои инвестиции в агентов, при этом расходы на ПО для ИИ-агентов, <a href="https://www.gartner.com/en/newsroom/press-releases/2026-05-05-gartner-says-autonomous-business-and-artificial-intelligence-layoffs-may-create-budget-room-but-do-not-deliver-returns">по прогнозам</a>, в 2027 г. достигнут <nobr>206,5-376,3 млрд.</nobr> долл. по сравнению с 86,4 млрд. долл. в <nobr>2025-м.</nobr></p> <p>Некоторые компании уже успешно используют агентов в своей операционной деятельности. Отвечая на вопросы ZDNet, представители трех из них выделили три ключевых фактора успеха: сравнительный анализ агентов, открытость к новым идеям и сосредоточение на правильных областях.</p> <h3>Сравнительный анализ инструментов</h3> <p>Мадлен Уонт, вице-президент по данным в спортивной платформе Fanatics, признала, что достижение отличных результатов с помощью и агентов, и людей — непростая задача, поэтому ее организация отслеживает и анализирует достижения сообщества специалистов по работе с данными.</p> <p>Она рассказала, что Fanatics активно и одной из первых внедряет ИИ для работы с данными, тестируя инструменты, сравнивая функции, проводя предварительные просмотры и развивая партнерские отношения в области дизайна: «Мы сравниваем, как вы используете эти инструменты, для каких задач вы их используете, сколько времени, по вашему мнению, они вам экономят, и что вы делаете с этим временем — ответы на все эти вопросы помогают в самостоятельной оценке ценности».</p> <p>По словам Уонт, которая руководит инженерией данных, наукой о данных и машинным обучением в подразделении ставок и игр, результаты тестов показывают, что использование ИИ-агентов экономит время людей.</p> <p>«Каждый бизнес-аналитик скажет вам что-то вроде: „Я бы хотел заниматься более стратегической работой, но я погряз в рутинной отчетности“. Мы видим, что именно рутинные задачи по составлению отчетов лучше всего поддаются автоматизации с помощью ИИ, и в результате сотрудники экономят время и затем используют его для более человеческой и стратегической работы, что является своего рода наилучшим результатом, на который можно надеяться», — сказала она.</p> <p>Уонт отметила, что успешное применение агентного ИИ заключается в получении более совершенных инструментов для работы, чтобы можно было самим не выполнять необходимые части работы и сосредоточиться на более интересных областях, в которых вы преуспеваете.</p> <p>Однако, хотя некоторые инструменты могут работать уже сейчас, она признала, что агентный ИИ — это незавершенный проект, и стремление ее компании к внедрению и тестированию таких инструментов в первую очередь означает, что специалисты могут регулярно знакомиться с новыми сервисами.</p> <p>По словам Уонт, философский подход ее организации к агентам означает, что внедрение предполагает процесс обмена информацией между менеджерами и специалистами по мере открытия новых способов работы с использованием ИИ.</p> <p>«Нужно быть готовым к тому, что это не традиционный многолетний проект по трансформации корпоративных технологий», — сказала она, посоветовав другим специалистам быть открытыми к исследованиям и переменам.</p> <p>«Мы не внедряем хорошо проверенные, заезженные технологии, которые, будучи внедренными, никогда не будут отменены. Сейчас ИИ находится на экспериментальной стадии, поэтому внедряйте его как можно раньше и пробуйте разные варианты, но также относитесь к этому осторожно, потому что нужно оставаться гибкими», — посоветовала Уонт.</p> <h3>Открытость для новых идей</h3> <p>Мэтт Луиззи, вице-президент по аналитике компании Whoop, специализирующейся на носимых технологиях, еще до внедрения агентного ИИ стремился помочь своей команде более эффективно использовать свое время.</p> <p>«Я пытался понять, на что тратит время моя команда, и люди говорили, что от 50 до 60% времени уходит на ответы на случайные вопросы из разных отделов компании, — сказал он. — Каковы были продажи вчера? Чем они отличаются по регионам? Почему у нас увеличилось количество веб-сессий? Это задачи, от которых люди хотят избавиться. Это задачи, от которых люди были бы рады избавиться. Именно в этом сейчас преуспевают агенты».</p> <p>По словам Луиззи, его компания заметила, что внедрение агентов позволяет сотрудникам-людям уделять больше времени стратегической работе, приносящей дополнительную ценность: «Мы уже видим реальное влияние этой технологии на доходы, поскольку люди могут заблаговременно определять проблемы, выявлять их первопричины, устранять неполадки и принимать меры гораздо быстрее, еще до того, как ситуация выйдет из-под контроля».</p> <p>Он считает, что развитие агентного ИИ будет продолжать набирать обороты, особенно для задач, которые легко автоматизировать. «Мы будем и дальше наблюдать прогресс, открывающий новые возможности там, где люди тратят свое время, но нам нужно продолжать расширять границы», — сказал он.</p> <p>В связи с этим Луиззи предположил, что ни один сотрудник, вероятно, не обладает ключом к успеху агентного ИИ. Отличные идеи могут возникать где угодно, и все специалисты должны быть готовы внести свой вклад. «Некоторые организации будут развиваться снизу вверх, где сотрудники младшего уровня будут осваивать новые технологии, рисковать и высвобождать время, — сказал он. — Некоторые из этих инициатив будут исходить сверху вниз, от руководителей, которые посещают конференции и узнают, что делают другие организации. Они смогут распространять эти знания по всей организации, выявляя и сопоставляя, как они помогают решать проблемы, с которыми сталкивается их команды».</p> <h3>Поиск новых проблем для решения</h3> <p>Шрирам Ситараман, CIO софтверной компании Synopsys, управляет довольно большими объемами инженерных и корпоративных данных. По его словам, в обеих областях агенты демонстрируют способность помочь повысить возможности человека.</p> <p>«Если вы посмотрите на объем доступных данных, то концепция наилучшего следующего действия, которое вы можете предпринять, раньше предполагала обсуждение группой людей, исходя их текущих приоритетов, — сказал он. — Теперь, благодаря ИИ, вы можете действительно принимать решения, основанные на данных и приносящие прибыль».</p> <p>Ситараман рассказал, что его компания осознала потенциал агентов ИИ для выполнения задач младших сотрудников, таких как выполнение быстрых запросов, создание графиков и получение инсайтов.</p> <p>Он также привел пример процесса принятия решения о том, какие новые функции следует разработать для приложения: сотрудники могут работать бок о бок со своими коллегами-агентами для отбора идей и выявления коммерчески жизнеспособных предложений. «Вам не нужна целая команда людей, ведущих обсуждение. Достаточно небольшой группы, анализирующие большой объем данных, — сказал он. — Многие усилия по согласованию источников данных для принятия решений сейчас сосредоточены на том, как людям получить преимущество от использования ИИ. Эти усилия направлены на сокращение больших объемов данных до достаточных для выполнения конкретных шагов».</p> <p>По опыту Ситарамана, агентный ИИ экономит время сотрудников. Например, беря на себя задачи сортировки и отбора данных первого уровня, персонал может перейти к более сложной, создающей ценность работе.</p> <p>«Это иерархическая система. Модели будут передавать задачи ИИ, и по мере совершенствования моделей сложность задач, с которыми может справиться ИИ, будет возрастать, — сказал он. — Так что через полгода ИИ будет решать иные задачи — не те же, что сейчас, а другого типа, и эта эволюция будет происходить постоянно».</p> Работа будущего, вероятно, потребует тщательного сочетания человеческих навыков и агентов искусственного интеллекта … article https://www.itweek.ru/themes/detail.php?ID=235133 Wed, 08 Jul 2026 09:26:44 +0300 <p><em>Когда HR приходит к ИТ-директору с запросом на автоматизацию найма, за этим, как правило, стоит не техническая задача, а управленческая. Рассмотрим, где такие проекты проваливаются, сколько реально стоят и как организовано внедрение, которое приносит измеримый результат.</em></p> <h3>Главное, что нужно проверить до старта</h3> <p>Большинство проектов по автоматизации найма не дают ожидаемого эффекта по одной причине: процесс, который пытаются автоматизировать, не описан. Нет чёткой последовательности шагов, непонятно, кто за что отвечает, информация между участниками передаётся устно и теряется по дороге.</p> <p>Здесь важно понимать: автоматизация не исправляет процесс — она его закрепляет. Если внутри беспорядок, система просто зафиксирует этот беспорядок в цифровом виде, и он никуда не денется. Именно поэтому до выбора любого инструмента стоит честно ответить на простой вопрос: может ли HR-блок описать процесс найма пошагово, назвать ответственного на каждом этапе и объяснить, как принимается решение по кандидату? Если ответ неуверенный — сначала нужно выстроить сам процесс, и только потом искать под него инструмент автоматизации.</p> <h3>Роль HR: от исполнителя к владельцу продукта</h3> <p>HR-система сегодня — это не отдельное приложение, которое работает само по себе. Она встраивается в существующую инфраструктуру компании: интегрируется с кадровыми системами, корпоративным порталом, внутренними коммуникациями и почтой. Вместе с этой интеграцией сразу возникает вопрос, который раньше HR-проектов не касался: где и как хранятся данные. По требованиям <nobr>152-ФЗ</nobr> данные кандидатов должны размещаться либо на локальных серверах в контуре компании, либо в сертифицированных облачных решениях. Штрафы за утечку персональных данных за последние годы выросли существенно, и игнорировать этот вопрос на этапе выбора платформы уже не получится.</p> <p>Всё это изменило не только технические требования к проекту, но и состав команды, которая принимает решение о внедрении. Раньше HR-директор выбирал систему самостоятельно — в лучшем случае согласовывал бюджет с финансами. Сейчас в проект входят юристы, безопасники, системные администраторы и аналитики. Сам HR-руководитель в этой команде занимает принципиально иную позицию. Всё чаще он выступает в роли product owner: формулирует требования, управляет внедрением как проектом и отвечает за результат перед бизнесом. Это принципиально другой уровень ответственности и другой уровень компетенций, который от него теперь требуется.</p> <h3>Где реально экономятся деньги</h3> <p>Многие компании ожидают, что после внедрения системы автоматизации стоимость подбора снизится. Через год обнаруживают, что цифра в бюджете осталась прежней — просто деньги переложились из одной строки в другую. Раньше уходили на джоб-борды, теперь уходят на лицензии, поддержку, интеграцию и обучение.</p> <p>Реальная экономия достигается иначе — через скорость закрытия вакансий. Чем быстрее закрыта позиция, тем меньше часов рекрутер тратит на каждого кандидата и тем раньше новый сотрудник начинает приносить компании результат. На линейных позициях это особенно ощутимо: каждая незакрытая ставка напрямую влияет на операционные показатели, и потери от простоя легко посчитать в деньгах.</p> <p>Проверить, происходит ли эта экономия на самом деле, можно одним вопросом: изменилось ли количество рекрутеров, которые нужны компании для обработки того же объёма вакансий? Если число осталось прежним, автоматизации не произошло. Система сделала работу рекрутеров чуть удобнее, но реальной эффективности компания не получила.</p> <p>Именно поэтому метрики успеха нужно определять до старта, а не после. Для ИТ-директора важно ещё на этапе подготовки проекта определить метрики успеха: сколько компании стоит закрытие вакансии, сколько времени занимает найм, какой объём ручной работы выполняют рекрутеры, сколько систем участвует в процессе и во сколько обходится их поддержка. Без этих исходных данных оценить результат внедрения после запуска сложно.</p> <h3>Децентрализованная структура: как не утонуть в зоопарке систем</h3> <p>Компании с филиальной структурой сталкиваются с типичной картиной: у каждого подразделения своя система, свои данные, свои процессы найма. Один филиал работает в одной CRM, другой ведёт всё в Excel, третий вообще не знает, что у соседей что-то автоматизировано. Такое встречается уже в компаниях от 800 человек — это не история про корпорации-гиганты.</p> <p>Попытка решить эту проблему одним махом — привести всё к единому стандарту одновременно — почти всегда заканчивается провалом. Подразделениям навязывают чужие процессы, и в ответ получают саботаж. Гораздо эффективнее начать с одного-двух департаментов, отладить там процесс, получить измеримый результат — и дать этим людям самим рассказать об опыте коллегам. Каждое следующее внедрение идёт быстрее: уже есть внутренние сторонники с живыми цифрами, и сопротивления значительно меньше.</p> <p>При этом успех масштабирования во многом определяется архитектурой самой платформы. Важно выбирать систему, которая изначально рассчитана на такую гибкость: позволяет настраивать разные процессы для разных подразделений, не заставляя всех работать по единому шаблону. Но гибкость процессов не должна означать раздробленность данных. Для ИТ-директора принципиально, чтобы при различии процессов данные оставались централизованными. В противном случае компания получает не единую систему подбора, а ещё один набор несвязанных между собой баз данных и интеграций.</p> <h3>Внутренняя база кандидатов — недооценённый ресурс</h3> <p>У большинства крупных компаний накоплены базы кандидатов, которые не используются повторно. Люди подавали заявки год, два, три назад — их данные хранятся в системе, но в подборе не участвуют. Это одновременно юридический риск — избыточные персональные данные сверх минимума, установленного законом, — и упущенная возможность сократить затраты на привлечение новых кандидатов.</p> <p>Между тем работа с внутренней базой даёт вполне конкретный эффект. В ритейле, например, при открытии новой точки географическая близость кандидата к месту работы — один из ключевых факторов успешного найма. Если данные о местоположении собраны, можно точечно реактивировать тех, кто живёт рядом, вместо того чтобы тратить бюджет на широкий таргет на внешних площадках.</p> <p>В вахтовом найме работает другая логика, но результат тот же. Люди, которые уже работали в компании, возвращаются значительно охотнее новых кандидатов — просто потому что знают, чего ожидать. На практике работа с такой базой добавляет около 15% к воронке найма без дополнительных затрат на привлечение.</p> <p>Для ИТ-директора это в первую очередь вопрос к архитектуре системы: умеет ли платформа работать с накопленными данными, строить по ним выборки и запускать автоматические сценарии повторного вовлечения кандидатов. Если нет — данные так и будут копиться мёртвым грузом, создавая юридические риски, но не принося никакой пользы.</p> <h3>Где сейчас граница между ИИ и человеком в найме</h3> <p>Во многих компаниях ИИ уже не просто помогает отбирать резюме — он ведёт первичный контакт с кандидатом: переписку, первые вопросы, проверку базовых критериев. Следующий уровень — уже не переписка, а полноценный анализ поведения кандидата в реальном времени. Системы анализируют видеоинтервью: отслеживают реакции кандидата, тембр голоса, эмоциональные маркеры и на основе этого формируют рекомендацию. Такие решения уже есть на рынке и активно внедряются.</p> <p>При всём этом финальное решение о найме остаётся за человеком — и, судя по всему, останется там ещё долго. Задача ИИ в этой цепочке — собрать полную картину по кандидату, структурировать данные и подсветить ключевые факты. Задача рекрутера и нанимающего менеджера — принять взвешенное решение на их основе. Рутинная фильтрация уходит на сторону системы, а за рекрутером остаётся то, что алгоритм пока не умеет: оценивать человека в контексте команды и культуры компании.</p> <p>Для ИТ-директора это означает, что запрос на интеграцию ИИ-инструментов в HR-контур — уже не вопрос будущего. Компании, которые сегодня внедряют автоматизацию найма, завтра придут с запросом на диалоговых агентов, видеоанализ и предиктивную аналитику по кандидатам. Инфраструктура должна быть к этому готова.</p> <p>А значит, проекты автоматизации подбора давно вышли за рамки HR-функции. Они становятся частью общей цифровой архитектуры компании, а их эффективность зависит не только от возможностей системы, но и от того, насколько органично она встроена в существующие процессы, данные и корпоративные сервисы.</p> <p>#IMAGE_235134#</p> Когда HR приходит к ИТ-директору с запросом на автоматизацию найма, за этим, как правило, стоит … article Татьяна Бабич, владелец продукта KitBot компании Nord Clan https://www.itweek.ru/themes/detail.php?ID=235131 Tue, 07 Jul 2026 14:04:07 +0300 <p>Несмотря на стремительный рост популярности ИИ-ассистентов, многие продолжают использовать их неэффективно. По результатам опроса Faves Communications и LibraChat , 7 из 10 россиян признались, что не используют возможности ИИ в своей работе в полной мере. Завышенные ожидания, поверхностная оценка возможностей и неправильная постановка задач приводят к тому, что полученные результаты не соответствуют запросам. Марианна Базаркулова, эксперт по практическому применению ИИ в бизнесе платформы искусственного интеллекта LibraChat, назвала три самые распространенные ошибки, которые мешают получать от ИИ максимальную пользу.</p> <h3> 1. Ожидать, что искусственный интеллект полностью сделает за тебя всю работу</h3> <p>Самое распространенное заблуждение — воспринимать ИИ как полноценную замену сотрудника. На самом деле ИИ — это инструмент, который помогает выполнять задачи быстрее, но не способен самостоятельно принимать стратегические решения. ИИ не владеет тем пониманием бизнеса, продукта и целевой аудитории, которое есть у опытного специалиста. Если человек сам не способен разобраться в задаче, то и ИИ вряд ли справится с ней на высоком уровне.</p> <p>Аналогично и с бизнес-процессами. Если в компании отсутствуют маркетинговая стратегия, аналитика, регламенты или четкое описание процессов, искусственный интеллект не создаст их «из воздуха». Он способен усиливать уже существующую систему, но не заменять ее.</p> <h3>2. Оценивать ИИ по одной небольшой задаче</h3> <p>Многие делают выводы о возможностях искусственного интеллекта, ограничиваясь одним простым запросом вроде «напиши пост» или «подготовь рассказ», но такой подход редко позволяет увидеть реальную ценность технологии. </p> <p>Максимальный эффект от ИИ раскрывается при работе с большими объемами информации и выполнении повторяющихся операций, например, при анализе сотен публикаций, обработке массивов данных, мониторинге информационного поля, генерации множества вариантов контента, классификации обращений клиентов или поиске закономерностей для аналитических сводок. Именно на масштабных задачах ИИ существенно экономит время, снижает операционные издержки и повышает производительность команды.</p> <h3>3. Использовать ИИ без качественного промптинга и контроля результатов</h3> <p>Качество результата работы ИИ напрямую зависит от четкости поставленной задачи: даже самая передовая модель не сможет предложить эффективное решение, если запрос лишен конкретных деталей. Практика показывает, что пользователи нередко допускают типичные ошибки — дают слишком общие формулировки, не раскрывают контекст (особенности компании, продукта и целевой аудитории) и не обозначают критерии качества. </p> <p>Чтобы добиться максимального эффекта, можно выстроить систему проверки и уточнения результатов: после первичной генерации материала стоит дать ИИ дополнительные указания — исключить шаблонные фразы, усилить аргументацию, подкрепить тезисы конкретными данными либо скорректировать тональность текста. Многоэтапный подход в работе с ИИ существенно повышает ценность итогового продукта. </p> <p>При этом важно осознавать границы возможностей технологии: задачи, где критически важны профессиональное чутье и человеческий опыт, не подлежат полной автоматизации. К ним относятся, в частности, разработка стратегических решений, управление репутационными рисками, создание креативных концепций, ведение переговоров и принятие управленческих решений — здесь ключевую роль продолжает играть сам человек.</p> Несмотря на стремительный рост популярности ИИ-ассистентов, многие продолжают использовать их неэффективно … message https://www.itweek.ru/themes/detail.php?ID=235130 Tue, 07 Jul 2026 10:26:22 +0300 <p>ИТ-компания IT_ONE представила систему мониторинга процессов разработки Gradient — инструмент для комплексного управления ИТ-командами и принятия решений на основе достоверных данных. Система не только аккумулирует и визуализирует метрики эффективности из различных инструментов команды разработки, но также анализирует их, подсвечивает узкие места и дает рекомендации по оптимизации процесса, исправлению ошибок и снижению операционных рисков.</p> <p>Система Gradient автоматически собирает исходные данные из Jira, Git, BitBucket, CI/CD и любых других систем, применяемых продуктовыми командами (репозиториев, тест-трекеров, аналитических инструментов), обрабатывает их, вычисляет показатели производительности и строит интерактивные дашборды. </p> <p>Для мониторинга в Gradient специалисты IT_ONE отобрали те метрики, которые позволяют наиболее точно и объективно оценить скорость, предсказуемость и эффективность процесса разработки, а также качество кода. Среди них, например, lead time (время от создания до завершения задачи), velocity (среднее количество дней, затраченное на итерацию), coding time (время от первого коммита до создания pull request), review count (количество проведенных ревью) и другие — всего более 15 показателей. Метрики и способы их расчета могут быть адаптированы под уникальные процессы команд и управленцев. У пользователей системы есть возможность добавлять любые новые метрики, отсутствующие в библиотеке Gradient.</p> <p>За визуализацию этих показателей отвечают гибко настраиваемые дашборды команд разработки, руководителей ИТ-департаментов и топ-менеджмента. С помощью этих отчетов ответственные специалисты видят единую, понятную картину всех процессов, получают объективные данные о нагрузке в разрезе команд, проектов и отдельных сотрудников, динамике разработки и качестве изменений, скорости решения отдельных рабочих задач, появлении узких мест в процессах, отклонений и аномалий. При этом им не нужно искать, выгружать и обрабатывать какие-либо данные вручную.</p> <p>Ключевое преимущество системы Gradient — в способности грамотно интерпретировать полученные данные, формировать на их основе предупреждения. За счет этого она становится главным помощником руководителей разного уровня. Также важно отметить, что для внедрения системы не нужно трансформировать процесс работы команды. Решение гибко встраивается в текущие реалии и при первом же сканировании выдает базовый аудит собираемых данных, необходимых для доверенного сбора метрик.</p> <p>«Команды разработки в своей деятельности используют разные инструменты. Чтобы сформировать и проанализировать необходимые метрики эффективности, им, как правило, приходится собирать данные из этих систем в некое хранилище, над которым строится визуализация с помощью BI и любых других систем. Однако аналитические возможности BI и аналогов сильно ограничены, там нет контроля качества данных, обратной связи и других полезных функций. Поэтому главная ценность Gradient в том, что ему можно доверять. Наша система агрегирует данные, анализирует их и оценивает, насколько они пригодны, и полны для формирования метрик и аналитики по работе команд производства», — объяснил Дмитрий Немов, директор по развитию продуктов холдинга IT_ONE.</p> <p>По прогнозам IT_ONE, система Gradient позволит на <nobr>10-20%</nobr> повысить продуктивность команд за счет постоянного мониторинга и своевременного выявления узких мест, на <nobr>5-15%</nobr> снизить расходы на управление за счет автоматизации сбора метрик, аналитики и сокращения ручной отчетности, на 15% оптимизировать использование ресурсов благодаря аналитике загрузки и более точному распределению задач. </p> <p>Отдельно стоит отметить, что Gradient повышает прозрачность процессов, помогает выявлять риски и отклонения задолго до срыва сроков. Благодаря системе алертов и прогнозирования команда сможет отреагировать на инцидент задолго до того, как проблема станет критической. </p> <p>Функционально и архитектурно система отвечает всем требованиям информационной безопасности. Gradient предоставляет каждому сотруднику доступ только к тем данным, которые он использует в своей работе — таким образом сильно снижается вероятность утечки конфиденциальной информации. Также система может быть развернута on-premise, в том числе в закрытом контуре заказчика. </p> <p>«Система Gradient трансформирует сырые цифры, собираемые в различных системах, в целостную картину процесса разработки, которая позволяет экспертам принимать осознанные управленческие решения на основе понятных и достоверных данных, поставленных в нужный контекст. Благодаря ей они могут всегда оценить, что происходит в команде разработки в данный момент, почему так происходит, какие рациональные меры предпринять для улучшения процесса», — прокомментировал Андрей Комраков, ведущий руководитель программы разработок IT_ONE.</p> <p>В IT_ONE фиксируют высокий спрос на систему Gradient: на данный момент запущено несколько пилотных проектов ее внедрения у заказчиков разных сфер деятельности, в том числе в финсекторе и ритейле. Особенно актуален этот продукт для средних и крупных компаний с большими подразделениями разработки ПО, занятыми в сложных длительных проектах.</p> ИТ-компания IT_ONE представила систему мониторинга процессов разработки Gradient — инструмент для комплексного управления … message https://www.itweek.ru/themes/detail.php?ID=235129 Tue, 07 Jul 2026 09:48:41 +0300 <p><em>Искусственный интеллект открывает новую эру аварийного восстановления, и предприятиям необходимо понять, как обновить свои стратегии для поддержания устойчивости, считают опрошенные порталом </em><em>InformationWeek</em> <em>эксперты.</em></p> <p>До нынешней волны внедрения ИИ аварийное восстановление фокусировалось на резервном копировании и восстановлении корпоративных приложений, баз данных и всех компонентов традиционной ИТ-инфраструктуры.</p> <p>Это остается актуальным и сегодня, но предприятиям теперь также необходимо подумать о моделях ИИ, промптах и агентах. Можно ли восстановить эти ресурсы, и как предприятия могут убедиться в их надежности после восстановления?</p> <p>«Вообще говоря, планы аварийного восстановления большинства организаций в этой области отстают от внедрения ИИ на годы», — говорит Грег Сарич, CIO компании Quest Software.</p> <p>Если CIO и CISO хотят помочь своим предприятиям наверстать упущенное, они должны понять, как обновить свои планы аварийного восстановления и протестировать их на реальных инцидентах.</p> <h3>Катастрофа в эпоху ИИ</h3> <p>Когда предприятие сталкивается с инцидентом безопасности или сбоем в современной среде, насыщенной ИИ, команде по восстановлению после катастроф приходится учитывать множество факторов, в том числе:</p> <ul> <li> Были ли скомпрометированы данные, используемые для обучения систем ИИ?</li> <li> Были ли они украдены?</li> <li> Были ли отравлены модели ИИ?</li> <li> Были ли скомпрометированы промпты?</li> </ul> <p>Обеспечение необходимой прозрачности для ответа на эти вопросы является сложной задачей, учитывая, насколько сильно ИИ затрагивает технологические стеки предприятия.</p> <p>«Если вы используете Claude, он может затрагивать вашу систему Salesforce и SharePoint, вашу систему Outlook и другие данные, которые у вас могут быть, скажем, в Snowflake, или что-то еще, где у вас есть критически важные для бизнеса данные, — поясняет Сарич, иллюстрируя, как ИИ создает сеть взаимосвязанных зависимостей. — Речь идет не только о защите этих систем, но и обо всех этих небольших пересечениях, которые он затрагивает на пути к возможности извлечения данных и последующего создания результата».</p> <p>В условиях, когда ИИ все больше интегрируется в бизнес-процессы, предприятия рискуют столкнуться с остановкой работы, особенно если их команды больше не могут вернуться к ручным методам. «Если ИИ-помощник или чат-бот выйдет из строя, мы потеряем доступ к институциональным знаниям, на которые полагаются наши сотрудники», — говорит Мехди Худайги, главный специалист Deloitte по кибербезопасности ИИ.</p> <p>Риск сохраняется и после восстановления работы ИИ-ресурсов после инцидента. Предприятия должны проверять целостность этих ресурсов, но обнаружение компрометации базовых данных, промптов или моделей может быть затруднительным. «ИИ может продолжать работать. И неподготовленному глазу может казаться, что он выдает уверенные ответы, но эти ответы могут быть неверными, неполными или сфальсифицированными», — отмечает Худайги.</p> <p>Предприятие может, например, восстановить работу чат-бота, но катастрофа продолжится, если люди будут действовать на основе скомпрометированной информации, которую он предоставляет.</p> <p>Радиус поражения может быть значительно больше при наличии агентов ИИ. «В зависимости от сложности агента, он уже не ограничивается одной системой, способной выполнять свои задачи. Потенциально он может охватывать несколько систем», — добавляет Худайги.</p> <p>Ущерб может сохраняться еще долго после того, как группы аварийного восстановления очистят скомпрометированные агенты ИИ, работающие на нескольких системах.</p> <p>«Если наши сотрудники, наши организации теряют доверие к самим инструментам, возникает большой разрыв в дальнейшем внедрении», — отмечает Сарич.</p> <h3>Разработка плана аварийного восстановления ИИ</h3> <p>Для CIO и CISO, рассматривающих, как должны развиваться их планы аварийного восстановления в ответ на ИИ, есть несколько основных шагов, которые помогут им начать:</p> <ul> <li><strong>Каталогизируйте свои ИИ-активы.</strong> С распространением ИИ в различных бизнес-подразделениях — и появлением теневого ИИ, добавляющего еще один уровень сложности — бывает трудно полностью понять, какие инструменты используются в каком месте.<br/> <br/> «Начните с инвентаризации активов ИИ. Если у вас ее нет, вам нужно быстро ее создать, — говорит Сарич. — Вы не сможете восстановить то, что не каталогизировали». </li> <li><strong>Определите критичность каждого актива для бизнеса. </strong>«Все, что в работе бизнеса связано с ИИ или имеет ИИ в своей основе, должно быть приоритетом номер один или считаться высоким уровнем опасности», — говорит Крис Миллингтон, руководитель направления решений Hitachi Vantara в области данных и киберустойчивости.<br/> <br/> По словам Сарича, инструменты, ориентированные на клиентов, и те, которые влияют на выручку, имеют более высокий приоритет. </li> <li><strong>Составьте карту зависимостей.</strong> Если ИИ глубоко интегрирован в рабочие процессы предприятий, крайне важно понимать его зависимости. «Какие данные он использует? На какую модель он опирается? Какой поставщик или поставщики участвуют? К каким системам он может получить доступ? И самое главное, какие учетные данные он использует?», — приводит перечень главных вопросов Худайги.</li> <li><strong>Оцените права доступа. </strong>Для эффективного восстановления руководителям служб ИТ и безопасности необходимо знать права доступа агентов и инструментов ИИ и иметь возможность отзывать учетные данные и завершать определенные задачи. После выполнения этих действий данные ИИ-ресурсы необходимо оценить, прежде чем их можно будет восстановить и снова предоставить им права доступа.<br/> <br/> «Проверка того, что агент работает в рамках так называемых утвержденных границ, прежде чем он снова будет задействован, имеет решающее значение с точки зрения аварийного восстановления», — говорит Худайги. </li> <li><strong>Определите целевые показатели восстановления.</strong> Организации должны определить целевое время восстановления и целевую точку восстановления, отмечает Худайги. Какой объем данных и времени простоя, связанных с ИИ-ресурсами, предприятие может позволить себе потерять? Каковы последние известные доверенные версии моделей, промптов и данных?<br/> <br/> Планы аварийного восстановления также должны определять необходимые этапы тестирования и проверки перед восстановлением и повторным подключением инфраструктуры ИИ к сети.<br/> <br/> «В системах ИИ задействовано значительно больше этапов из-за присущей им сложности, просто из-за их вероятностной природы», — поясняет Худайги. </li> <li><strong>Тестирование и проверка.</strong> План аварийного восстановления мало кому пригодится, если он пылится на полке до тех пор, пока не случится катастрофа. Тестирование имеет ключевое значение, но ежегодные или ежеквартальные тесты недостаточны, учитывая темпы развития ИИ. Новые инструменты, новые зависимости и новые риски — неотъемлемая часть эпохи ИИ.<br/> <br/> При проведении тестирования предприятиям необходимо учитывать все потенциальные пробелы в своих планах аварийного восстановления и устранять их.<br/> <br/> «Спросите себя, что произойдет, если база знаний будет повреждена или если мы потеряем доступ к одной из больших языковых моделей, когда API будут недоступны по какой-либо причине? Что произойдет, если агент будет вести себя неожиданно или если у нас реализуются случаи потенциального компрометирования, когда мы не сможем доверять журналам? Ответы на эти вопросы помогут довольно быстро выявить пробелы», — говорит Худайги. </li> </ul> <h3>Когда случается катастрофа</h3> <p>Несмотря на то, что ИИ меняет операционную деятельность, старая поговорка в области кибербезопасности «Это вопрос не „если“, а „когда“» остается актуальной. Если внедрение ИИ будет продолжать опережать надлежащее управление, инциденты, которые возникают и затрагивают агентов и инструменты, будут неизбежно происходить.</p> <p>Согласно недавнему исследованию Proofpoint «<em>2026 AI and Human Risk Landscape</em>», 42% из 1400 опрошенных специалистов по безопасности сталкивались с инцидентами, связанными с ИИ, как подозрительными, так и подтвержденными. Кроме того, 52% респондентов заявили, что не полностью уверены в способности средств защиты их организаций обнаружить скомпрометированный ИИ.</p> <p>Предприятия уже сталкиваются с инцидентами, влияющими на их ИИ-ресурсы, и Сарич предполагает, что рано или поздно произойдет крупное событие, которое выведет восстановление после ИИ-сбоев на первый план. «Я уверен, что в недалеком будущем мы станем свидетелями чего-то масштабного», — говорит он.</p> <p>Независимо от того, будет ли это крупное публичное событие или нет, предприятиям придется обратиться к своим планам аварийного восстановления, проработать их, а затем провести анализ причин сбоя, чтобы сделать этот план более надежным для следующего инцидента. По словам Миллингтона, корпоративным командам предприятий придется искать ответы на такие ключевые вопросы, как: «На каком этапе мы восстановились, и было ли это приемлемо, или это можно оптимизировать еще больше?».</p> <h3>Недостающий показатель устойчивости ИИ</h3> <p>В условиях, когда стратегии аварийного восстановления совершенствуются в ответ на сложность корпоративного ИИ, остается без ответа важный вопрос: могут ли предприятия количественно оценить потери, связанные со сбоем, нарушением безопасности или другим инцидентом, затрагивающим их ИИ-ресурсы?</p> <p>Худайги утверждает, что в отрасли еще не достигнуто согласие относительно того, как количественно оценивать киберриски ИИ, не говоря уже о потерях, связанных с ИИ. В то же время, по его словам, у отрасли в целом есть возможность и необходимость взглянуть на то, каковы поддающиеся количественной оценке потери или риски воздействия этих систем.</p> <p>По мере того, как предприятия будут получать более четкое понимание операционных и финансовых последствий инцидентов, связанных с ИИ, аспекты стоимости аварийного восстановления и устойчивости, наконец, могут начать догонять внедрение ИИ.</p> Искусственный интеллект открывает новую эру аварийного восстановления, и предприятиям необходимо понять, как обновить свои … article https://www.itweek.ru/themes/detail.php?ID=235127 Tue, 07 Jul 2026 09:26:03 +0300 <p><em>Злоумышленники все чаще атакуют не рядовых сотрудников, а администраторов, имеющих широкие полномочия. Используются письма с поддельными уведомлениями от службы поддержки, запросами на смену пароля, фальшивыми обновлениями ПО. При этом традиционные тренировки уже не защищают ИТ-персонал от таких атак на 100%. </em><em>Рассмотрим</em><em>, как строить комплексную защиту от мошенников для ИТ-отделов.</em></p> <h3>Почему злоумышленники переключились на ИТ-отделы</h3> <p>По данным исследования Positive Technologies, в половине успешных кибератак в 2025 году <a href="https://ptsecurity.com/research/analytics/trendy-atak-v-2026-godu/#id33">применялись</a> методы социальной инженерии. В среднем 35% сотрудников <a href="https://www.it-world.ru/news-company/ilfpeqjrgj4ssg400kgkkgo8sowogoc.html">переходят </a>по фишинговым ссылкам, 21% — вводят свои учетные данные, и всего 2% сообщают о своих подозрениях в службу ИБ.</p> <p>При этом еще несколько лет назад фишинговые рассылки были в основном нацелены на специалистов, далеких от ИТ — бухгалтерию, секретарей или рядовых менеджеров. С одной стороны, их было проще ввести в заблуждение. С другой — полезный эффект от атак не всегда был высоким, ведь у рядовых сотрудников обычно сильно ограничены права доступа.</p> <p>Поэтому в последние годы злоумышленники активнее переключились на ИТ-отделы. Обмануть технических специалистов сложнее, но в случае успеха мошенников последствия для компании куда серьезнее. Один скомпрометированный сотрудник с правами администратора домена или доступом к критическим сервисам может дать ключ ко всей инфраструктуре компании.</p> <h3>Кто в группе риска внутри ИТ-отдела </h3> <p>Чтобы обмануть рядового сотрудника не из ИТ-департамента, может хватить обычной массовой рассылки со стандартными сценариями. Например, их просят срочно перейти по ссылке, иначе их рабочий аккаунт удалят или заблокируют.</p> <p>При таком массовом фишинге ИТ-специалисты сталкиваются с теми же базовыми триггерами. Обычно это стандартные уведомления о проблемах с аккаунтами или доступностью сервисов: требуют срочно сменить пароль либо предупреждают о том, что почтовое или локальное хранилище переполнено.</p> <p>Однако, как правило, такие методы малоэффективны для работы с ИТ-сотрудниками — они уже готовы к стандартным сценариям мошенников. Поэтому основной упор злоумышленников теперь смещается на таргетированные атаки, тщательно адаптированные под профиль конкретного сотрудника, его поведение и контекст работы. При этом не все администраторы привлекательны для атак с точки зрения хакера. Среди самых уязвимых категорий сотрудников можно выделить:</p> <ul> <li> Администраторов домена и идентичности — у них полный контроль над всеми сотрудниками и системами.</li> <li> Администраторов облачных сервисов (M365, AWS, Google Workspace).</li> <li> Системных администраторов, отвечающих за резервные копии и мониторинг. Через них можно легально отключить защиту или восстановить доступ к зашифрованным данным.</li> </ul> <p>Зная внутреннюю структуру компании, хакеры могут переписать текст письма под конкретные обязанности человека — это логичный шаг при подготовке атаки. Но на практике выяснить, за какую именно систему отвечает конкретный сотрудник, удается крайне редко. Такая информация стоит дорого, поэтому мошенники почти не подбирают индивидуальные триггеры под каждый тип администратора.</p> <h3>Как выглядит реальный сценарий атаки на системного администратора</h3> <p>Сегодня типичная атака состоит из нескольких этапов::</p> <ol> <li><strong> Разведка.</strong> Хакеры собирают цифровые следы ИТ-специалистов в компании, чтобы понять их зоны ответственности и права доступа. Они ищут утечки токенов и ключей в репозиториях кода, вычисляют имена тестовых серверов и аккаунты сервисов. Возможны сценарии, когда специалисты сами оставляют зацепки: на конференциях случайно рассказывают об особенностях своей инфраструктуры, а на форумах и в каналах в мессенджерах делятся защищаемыми активами инфраструктуры.</li> <li><strong> Подготовка инфраструктуры.</strong> Для писем хакеры регистрируют домены, запускают почтовые узлы и верстают фишинговые страницы. Иногда используют ресурсы крупных провайдеров — открытые серверы рассылок и IPFS-хранилища. Средства защиты информации более лояльно обрабатывают подобные сервисы, поэтому чаще рискуют пропустить фишинговый контент.</li> <li> <strong>Атака.</strong> Используя собранные данные, злоумышленники отправляют подготовленные письма и вредоносные файлы.</li> <li><strong> Закрепление и развитие.</strong> Скомпрометировав права, хакеры прописывают новые правила доступа, оставляют бэкдоры. Если захваченный аккаунт быстро заблокируют, у них все равно останется лазейка для входа.</li> <li> <strong>Результат.</strong> Дальше все зависит от целей хакеров. Они могут украсть данные, потребовать выкуп, сохранить доступы для следующих атак.</li> </ol> <p>Как это выглядит на практике, показывают результаты недавних киберучений в одной из компаний. Организаторы отправили тестовую фишинг-рассылку и так собрали у невнимательных сотрудников логины, пароли и коды второго фактора от почт. Они зашли в аккаунты и разослали в службу поддержки архивы с вредоносным кодом и припиской: «Посмотри, пожалуйста, почему архив не распаковывается».</p> <p>Сотрудники хелпдеска пытались открыть файл, но видели ошибку и пересылали его коллегам с той же просьбой. Так как у техподдержки есть права отключать антивирус, специалисты пытались это сделать, чтобы все-таки запустить содержимое. В итоге из-за одной ошибки под угрозой оказалась практически вся инфраструктура компании. И хорошо, что это были всего лишь киберучения! В случае реальной кибератаки такие действия привели бы к необратимым последствиям.</p> <p>Другой показательный случай произошел также во время киберучений, когда проверяли реакцию сисадминов на популярную у пентестеров тактику «низко висящих фруктов». На парковке офиса раскидали флешки с вредоносным ПО. Один из администраторов подобрал устройство и, понимая опасность, не стал включать ее на рабочем месте. Он принес флешку домой и подключил к домашнему ПК. Но админ не учел, что на его личном компьютере запущен VPN для удаленной работы. В результате пентестеры без труда проникли во внутренний периметр организации.</p> <h3>Как защитить ИТ-отдел</h3> <p>Одним из ключевых элементов эффективной защиты компании традиционно считается обучение персонала практикам кибербезопасности. По <a href="https://www.knowbe4.com/press/knowbe4-report-reveals-security-training-reduces-global-phishing-click-rates-by-86">данным KnowBe4</a>, треть (33%) сотрудников также взаимодействуют с имитацией фишинга перед тем, как пройти обучение. После внедрения обучения процент сотрудников, которые могут стать жертвами социальной инженерии или фишинговых атак, за год снижается сразу на 86%. Важно разбирать именно практические кейсы и ошибки — для этого можно использовать специальные онлайн-полигоны, на которых имитируются реальные атаки на инфраструктуру.</p> <p>При этом само по себе обучение не может полностью исключить человеческий фактор. Часть людей все равно перейдет по ссылке или скачает вредоносный файл — в спешке или по невнимательности. Для доставки вредоносного ПО мошенники используют различные коммуникационные каналы: электронную почту, сайты, мессенджеры и социальные сети. Поэтому первый шаг для снижения вероятности утечек — минимизировать саму возможность успешной доставки вредоносного ПО (ВПО). Для этого можно: </p> <ul> <li> использовать почтовые шлюзы и песочницы, проверяющие вложения и ссылки в электронных письмах в режиме реального времени;</li> <li> внедрить NGFW и прокси-сервисы с функцией категоризации сайтов и фильтрацией трафика;</li> <li> контролировать каналы обмена файлами внутри организации, включая мессенджеры, где возможна доставка ВПО с использованием социальной инженерии;</li> <li> регулярно тестировать параметры шлюзов и фильтров с помощью специализированных решений, имитирующих реальные сценарии доставки ВПО.</li> </ul> <p>Также нужно отметить, что число атак с распространением ВПО через легитимные сервисы продолжает расти. Поэтому разработчикам нужно внимательно относиться к используемым репозиториям и менеджерам пакетов в своих проектах и внедрять инструменты безопасной разработки и контроля цепочки поставок.</p> <p>Кроме того, важно следить за всеми возможными точками входа в инфраструктуру, включая давно неиспользуемые. Забытые сервисы, неучтенные устройства, теневые системы и устаревшие компоненты — все это становится потенциальными источниками уязвимости, которые нужно своевременно обновлять или отключать.</p> <p> #IMAGE_235128#</p> Злоумышленники все чаще атакуют не рядовых сотрудников, а администраторов, имеющих широкие полномочия. Используются … article Федор Гришаев, ведущий специалист группы исследования фишинговых угроз департамента киберразведки Positive Technologies https://www.itweek.ru/themes/detail.php?ID=235126 Mon, 06 Jul 2026 16:13:48 +0300 <p>Аналитики проекта STAQ, предназначенного для цифровизации бизнеса в России, определили ключевые рабочие процессы, которые отечественные компании предпочитают выполнять с использованием платформенных решений в 2026 году. Также эксперты проанализировали данные российских компаний из нескольких ведущих отраслей и выделили процессы, которые чаще всего становятся точкой входа в платформенную автоматизацию и дают наиболее измеримый эффект в каждой конкретной индустрии. Для анализа были использованы данные клиентов STAQ.</p> <p>Вне зависимости от отрасли есть задачи, которые сегодня массово переводятся на платформенные решения. Эти задачи объединяет высокая частота повторений, большое количество участников, четкие сроки и необходимость фиксировать каждый шаг. Управление сервисными заявками является одним из самых важных запросов. Платформа превращает поток обращений в структурированный процесс: единая точка входа, автоматическая маршрутизация по типу и приоритету, контроль SLA, эскалация при нарушении сроков. Еще одна задача — техническое обслуживание и ремонт (ТОиР). Платформенные решения переводят ТОиР из аварийного режима в плановое автоматическое формирование нарядов по расписанию или показателям с датчиков, назначение исполнителей, контроль выполнения, история по каждой единице оборудования. </p> <p>Кроме того, в списке подобных задач есть управление выездным персоналом. Платформа решает задачу на уровне логики процесса: учет геолокации, квалификации и загрузки специалистов, автоматическое назначение заявки ближайшему доступному исполнителю, мобильное приложение для фиксации работ на месте, автоматическое закрытие наряда после подтверждения. Важная задача — управление инцилентами и эскалациями. Любая операционная деятельность создает нештатные ситуации. Важно, как быстро о них узнают нужные люди и что будет дальше. Платформа задает этот маршрут заранее: по типу и критичности инцидента автоматически назначается ответственный, запускается таймер, при нарушении срока — эскалация на следующий уровень. Это превращает реакцию на инциденты из хаотичной в предсказуемую.</p> <p>Главный запрос в ритейле — централизация сервисных процессов при сохранении гибкости на уровне отдельного объекта. Это означает единую платформу, где сотрудники любой точки подают заявки на ремонт, расходные материалы, технических специалистов, единый контроль SLA по всей сети, автоматические уведомления и эскалации, если объект не получит ответ в срок. Второй по востребованности процесс — обслуживание торгового оборудования. Кассы, холодильники, торговые автоматы, вентиляционные системы — в крупной сети это тысячи единиц со своим регламентом обслуживания. Платформа обеспечивает автоматические наряды, историю по каждому устройству, контроль сроков, интеграцию с IoT-датчиками для предиктивного обслуживания. Третий сценарий, набирающий популярность — управление внешними подрядчиками. Платформа позволяет включить подрядчиков в единый контур: они получают заявки в той же системе, фиксируют выполнение, проходят оценку качества. </p> <p>В производстве также есть ключевые задачи, которые чаще всего решаются с помощью платформенных решений. Наиболее запрашиваемый блок — управление производственными заданиями и сменными отчетами. Платформа уровня MES позволяет переводить плановые задания в цифровые наряды для каждой смены и участка, фиксировать фактическое выполнение в реальном времени, автоматически сравнивать план и факт, видеть причины отклонений без разбора бумажных журналов постфактум. Второй процесс — мониторинг оборудования и контроль технологических режимов. Интеграция с IoT-датчиками позволяет платформе получать данные о состоянии оборудования в режиме реального времени. На основе данных формируются предиктивные задания на обслуживание. Третий процесс — управление качеством и несоответствиями. Выявленный брак, несоответствие стандарту запускают цепочку действий. Платформа превращает этот процесс из бумажного в цифровой. </p> <p>Ключевой запрос в логистике — управление парком техники и планирование работ. Единая платформа аккумулирует данные о техническом состоянии каждой единицы, истории обслуживания, пробеге и наработке моточасов. На основе этих данных формируются планы ТОиР и заявки на внеплановый ремонт. Второй востребованный процесс — диспетчеризация и контроль выполнения рейсов. Платформа позволяет фиксировать маршрут, время отправления и прибытия, отклонения от плана, статус груза на каждом этапе. Это не только операционный контроль — это данные для последующей аналитики. Третий процесс, который заметно активизировался в последний год, — управление подрядными перевозками. Когда часть маршрутов отдана на аутсорс, важно включить подрядчиков в единый цифровой контур., где есть постановка задания, подтверждение принятия, фиксация выполнения, оценка. </p> <p>В 2026 году платформенный подход продолжает набирать популярность в России, и это вполне объяснимо. Платформенный подход позволяет объединить системы в единую архитектуру управления, обеспечивая прозрачность, экономию и гибкость. Кроме того, он помогает компаниям запустить процессы по цифровой трансформации бизнеса. Переход от десятков сервисов к единой платформе — это важная стратегическая трансформация. Для компаний это означает больше, чем просто удобство. В данном случае речь про новый уровень управляемости, прозрачности и контроля.</p> Аналитики проекта STAQ, предназначенного для цифровизации бизнеса в России, определили ключевые рабочие процессы, которые … message https://www.itweek.ru/themes/detail.php?ID=235125 Mon, 06 Jul 2026 16:12:41 +0300 <p>Cloud.ru расширил возможности Evolution Data Platform, добавив новые инструменты для работы с данными в облаке. Сервис Evolution Managed Airflow для оркестрации рабочих процессов перешел в коммерческую эксплуатацию, а Evolution Managed Flink для распределенной обработки потоковых и пакетных данных стал доступен в режиме публичного тестирования. Оба решения интегрированы с другими компонентами платформы и работают в едином контуре.</p> <p>Evolution Managed Airflow построен на основе открытого ПО Apache Airflow. Сервис помогает в управлении ETL-процессами (Extract Transform Load, извлечение, преобразование и загрузка данных для аналитики): пользователю достаточно определить параметры и последовательность выполнения задач, сервис автоматически организует их выполнение. Managed Airflow подходит не только для ETL-процессов, но и для автоматизации других задач. Например, генерации и отправки отчетов, управления инфраструктурой, проведения <nobr>ML-экспериментов.</nobr></p> <p>Также для пользователей Cloud.ru стал доступен Evolution Managed Flink — управляемый PaaS-сервис на базе Apache Flink для обработки потоковых и пакетных данных в реальном времени. Он позволяет реагировать на события сразу после их появления — например, обрабатывать поток данных из Kafka и в этот же момент обновлять дашборды, оповещения и витрины данных. Это делает его пригодным для мониторинга инцидентов, аналитики поведения пользователей, финансовой аналитики для предотвращения мошенничества и оценки маркетинговых кампаний для корректировки стратегии.</p> <p>Новые сервисы встроены в экосистему Evolution Data Platform. Такой подход позволяет реализовывать сквозные сценарии работы с данными: например, данные могут поступать в платформу через Managed Flink, обрабатываться и обогащаться в Managed Spark, храниться в Managed ArenadataDB, а затем использоваться для аналитики и визуализации в Managed BI. Единые механизмы мониторинга, контроля доступа, управления метаданными и ресурсами в облаке позволяют командам сосредоточиться на работе с данными, а не на сопровождении инфраструктуры.</p> <p>«Мы последовательно развиваем Evolution Data Platform как единую платформу, которая покрывает весь цикл работ с данными. В результате пользователи получают не набор разрозненных инструментов, а готовую экосистему для хранения, обработки и анализа данных в одном контуре. Это снижает затраты на интеграцию решений и упрощает управление инфраструктурой. Также платформа открывает новые сценарии работы с ИИ. Например, данные из корпоративных систем могут использоваться для обучения моделей, создания интеллектуальных помощников и ИИ-агентов, которые помогают искать информацию, анализировать документы и получать ответы на вопросы на естественном языке», — сказала Ася Грибанова, директор департамента разработки Evolution Data Platform. </p> Cloud.ru расширил возможности Evolution Data Platform, добавив новые инструменты для работы с данными в облаке. Сервис … message https://www.itweek.ru/themes/detail.php?ID=235124 Mon, 06 Jul 2026 16:12:00 +0300 <p>Россиянам стала доступна новая флагманская модель GigaChat 3.5 Ultra. Она стала умнее, генерирует длинный текст до 4х раз быстрее, потребляет меньше ресурсов и почти вдвое компактнее предыдущей версии. Обновлённая модель лучше решает задачи, связанные с написанием кода, математикой, работой с длинными текстами и автономными агентными сценариями. В основе модели — собственная отечественная архитектура с технологией линейного внимания, разработанная командой Сбера.</p> <p>Улучшенной моделью может пользоваться любой желающий. В ИИ-помощнике ГигаЧат она доступна всем, кто хочет применять ИИ для личных и рабочих задач. В Open Source она бесплатно доступна разработчикам по всему миру для встраивания в свои сервисы и создания ИИ-агентов.</p> <p>Кодирование и математика — модель увереннее генерирует и проверяет код, точнее решает математические задачи и финансовые расчёты, работает с числами. Ответы стали точнее, структурнее и удобнее для восприятия. Все это позволяет встраивать модель в реальный рабочий процесс разработчика, аналитика или инженера.</p> <p>Чтение и анализ длинных текстов — эффективно анализирует контракты, техрегламенты, отчёты и другие объёмные документы без потери точности и контекста — за счёт архитектуры линейного внимания она не перечитывает текст заново, а накапливает контекст постепенно, как человек, который помнит суть разговора. Скорость работы с длинными текстами выросла до четырёх раз.</p> <p>Автономность и ИИ-агенты — модели можно поставить задачу, и она сама найдёт информацию, напишет и выполнит код, обратится к нужному сервису и вернёт готовый результат. Это позволяет автоматизировать рутину: мониторинг, обработку данных, подготовку отчётов по расписанию.</p> <p>На тестах, которые измеряют способность ИИ решать задачи по программированию, математике, выполнению сложных многошаговых заданий и качество русскоязычного диалога, GigaChat 3.5 Ultra превзошла предыдущую флагманскую модель Сбера. А по ряду показателей приблизилась к результатам сильных открытых моделей, например, к DeepSeek 3.2, при этом будучи почти вдвое компактнее.</p> <p>Антон Фролов, старший вице-президент, руководитель блока «Развитие генеративного ИИ» Сбербанка, отметил: «Мы живём в момент, когда разрыв между человеком и возможностями ИИ резко сокращается. GigaChat 3.5 Ultra — наш шаг к тому, каким должен быть ИИ-инструмент для решения реальных задач: полноценный партнёр, способный мыслить в логике конкретного процесса, а не просто отвечать на вопросы. Чтобы разработать такую модель, нужно постоянно экспериментировать и пробовать то, чего до тебя не делал никто — количество наших экспериментов выросло более чем вдвое, до 1500. Мы доказали, что создать модель сильную модель можно на собственной архитектуре и с принципиально меньшими ресурсами. Хотим, чтобы наши решения становились основой для новых продуктов и исследований, выходящих далеко за пределы Сбера».</p> <p>GigaChat 3.5 Ultra — результат разработки Сбера: команда создала уникальную архитектуру с применением технологии линейного внимания. В отличие от классического «внимания» ИИ-моделей, которое при каждом новом слове заново сверяет его со всем предыдущим текстом, линейное внимание один раз «запоминает» суть прочитанного и дальше просто дополняет эту память — примерно как человек, который держит в голове краткий пересказ книги, а не перелистывает её с начала при каждой странице. GigaChat 3.5 Ultra — одна из самых больших моделей с линейным вниманием среди всех, что выходили в опенсорс.</p> <p>При обучении модели акцент сделан на натуральных, созданных человеком текстах, прошедших многоуровневую классификацию и фильтрацию — собранный увеличенный датасет позволил достичь лучших метрик. Модель построена по архитектуре MoE (Mixture of Experts) и примерно вдвое компактнее предыдущей версии GigaChat Ultra, что снижает потребление вычислительных ресурсов и позволяет разворачивать её на более доступном оборудовании — а значит, больше компаний и разработчиков смогут запускать модель самостоятельно.</p> Россиянам стала доступна новая флагманская модель GigaChat 3.5 Ultra. Она стала умнее, генерирует длинный текст … message https://www.itweek.ru/themes/detail.php?ID=235123 Mon, 06 Jul 2026 16:10:25 +0300 <p>Согласно данным исследования компании «Информзащита», актуальным на июль 2026 года, 76,8% компаний закладывают на восстановление всей ИТ-инфраструктуры из резервных копий более четырех часов. В установленный четырехчасовой интервал укладываются только 17% респондентов, а еще 4,2% вообще не могут оценить срок возврата среды в работу. До восьми часов требуется 19,6% организаций, до 12 часов — 17%, до суток — 20,6%; еще 21,6% рассчитывают на восстановление от двух суток до недели и более. Одновременно доля компаний, столкнувшихся с вымогателями, выросла с 22% в 2025 году до 25% в <nobr>2026-м.</nobr></p> <p>Резервные копии есть у большинства, но сами по себе они не гарантируют быстрого возврата сервисов в работу. Логический или физический air gap используют 75,6% организаций, неизменяемые копии есть у 62,8%. Однако после крупной атаки требуется восстановить не один сервер и не отдельную базу данных. В работу нужно вернуть виртуализацию, сеть, доменную инфраструктуру, системы аутентификации, средства защиты, прикладные сервисы, базы данных, интеграции с контрагентами, сертификаты, ключи шифрования и учетные записи администраторов. Сбой на любом из этих уровней сдвигает запуск зависимых систем, даже когда данные уже доступны.</p> <p>Почти половина компаний, 48,2%, установили RTO менее четырех часов. Полное восстановление ИТ-среды за тот же срок подтверждают только 17%. Эти цифры показывают разницу между нормативом для отдельного сервиса и реальной готовностью вернуть в работу весь технологический контур. Разрыв в 31 процентный пункт — это разница между тем, что написано в политике непрерывности, и тем, что происходило в последнем реальном инциденте. В последнем тесте или инциденте 26,8% организаций не уложились в собственный RTO. Чаще всего проблема проявляется не в скорости развертывания резервной копии, а на этапе проверки целостности данных, синхронизации зависимых систем и подтверждения, что среда не содержит следов компрометации.</p> <p>Проверку восстановления из резервных копий за последние 12 месяцев проводили 50,8% организаций. Сценарий восстановления после кибератаки тестировали лишь 34,6%. Разница существенна: отказ оборудования и компрометация инфраструктуры требуют разных действий. Почти треть компаний, планируя DR, репетирует не тот сценарий: развернуть бэкап после сгоревшего диска и развернуть бэкап, в котором, возможно, сидит шифровальщик, — разные по сложности задачи, а тестируют обычно только первую. После аппаратной аварии ИТ-команда может развернуть известную рабочую конфигурацию. После ransomware, захвата привилегированных учетных записей или внутреннего инцидента сначала приходится устанавливать масштаб проникновения, изолировать скомпрометированные сегменты, менять пароли и ключи, проверять резервные копии на отсутствие вредоносного кода. Среди организаций, которые высоко оценивают свою способность противостоять ransomware, 57% вообще не тестировали восстановление после кибератаки.</p> <p>Векторы атак дополнительно усложняют расчеты. С вредоносным ПО столкнулись 42,6% участников исследования, с фишингом — 30,6%, с ИИ-атаками и дипфейками — 24,6%, с ransomware — 22,4%, с социальной инженерией — 21%, с внутренними нарушениями — 15,2%, с DDoS — 14,4%. Из всех векторов ИИ-угрозы выросли быстрее прочих — вдвое за год, обогнав по динамике даже ransomware. Тревожно не количество дипфейков, а то, что они бьют по самому слабому месту DR-плана — верификации личности при восстановлении привилегированного доступа. Вредоносное ПО и шифровальщики ставят под вопрос чистоту резервных копий. Фишинг и социальная инженерия нередко дают злоумышленникам доступ к административным учетным записям, поэтому восстановление приходится начинать с контура идентификации и управления доступом. DDoS не повреждает данные, но может заблокировать внешние каналы и помешать возвращать клиентские сервисы в штатный режим. Внутренний нарушитель способен изменить конфигурации, удалить журналы событий и нарушить работу самих процессов резервного копирования.</p> <p>Сложность ИТ-ландшафта назвали главным препятствием для повышения устойчивости 38% организаций. Дефицит специалистов мешает 32,4% компаний, недостаточная интеграция процессов устойчивости — 29,2%, зависимость от поставщиков — 26,4%, устаревшие системы — 26%. Каждый внешний элемент в цепочке восстановления — облачная консоль, лицензионный сервер, API подрядчика — точка, где план может остановиться не по вине ИТ-команды, а потому что нужный человек у вендора недоступен в 3 часа ночи. . Почти половина участников исследования, 44%, уже переносили часть данных или систем из публичного облака в частную или локальную среду ради контроля, безопасности либо устойчивости. Еще 30,8% рассматривают такой перенос в ближайшие 12 месяцев.</p> <p>В выборке наиболее широко представлены технологические компании — 40,4%, банковский и финансовый сектор — 9,2%, ритейл — 8,6%, производство — 7,8% и профессиональные услуги — 6%. Цена часа простоя разная по отраслям: для ритейла это остановленная касса и склад, для банка — недоступные платежи, для производства — стоящий конвейер. Одинаковый RTO в четыре часа означает разный уровень ущерба в зависимости от того, что именно стоит. </p> <p>Главный вывод исследования не в том, что нужно чаще делать бэкапы, а в том, что компании тестируют не тот сценарий, который реально случится. Первый шаг — не инвентаризация ради инвентаризации, а честный ответ: если завтра зашифруют домен-контроллер, кто и в каком порядке поднимает инфраструктуру, и проверялось ли это хотя бы раз за год. Компании необходимо разделить рабочие нагрузки по приоритету, закрепить достижимые RTO и RPO, определить порядок запуска систем и заранее проверить, какие сервисы нельзя вернуть без внешних поставщиков. Резервные копии стоит регулярно разворачивать в изолированной среде, а учения проводить по сценариям шифрования, компрометации учетных записей, удаления конфигураций и недоступности облачного провайдера. Отдельного контроля требуют административные учетные записи, ключи шифрования, средства мониторинга и журналы событий. Время восстановления должно измеряться не до момента запуска виртуальной машины, а до подтвержденного возвращения бизнес-сервиса в рабочее состояние.</p> Согласно данным исследования компании «Информзащита», актуальным на июль 2026 года, 76,8% компаний закладывают … message https://www.itweek.ru/themes/detail.php?ID=235121 Mon, 06 Jul 2026 09:27:03 +0300 <p><em>Мария Ягнюк — аналитик-исследователь </em><em>IDC</em><em> в области данных и аналитики, обсуждает в корпоративном блоге, о чем говорят 640 млрд. долл., которые будут тратиться на ПО для цифровой трансформации (</em><em>DX</em><em>), и секторах, лидирующих в изменениях, связанных с искусственным интеллектом.</em></p> <p>Глобальные расходы на ПО для DX к 2029 г. достигнут 640 млрд. долл., и направления этих инвестиций быстро меняются. Последний отчет <a name="OLE_LINK21">IDC «</a>Worldwide Digital Transformation Spending Guide (V1 2026)» показывает, что ИИ переносит ценность из инфраструктуры и в приложения, причем темпы этого сдвига резко различаются в зависимости от сектора. Исследованием было охвачено 27 отраслей, 12 технологических рынков и географических регионов.</p> <h3>ПО становится основным двигателем цифровой трансформации</h3> <p>DX — это масштабный переход организаций к внедрению технологий на каждом уровне своей деятельности, взаимодействия с клиентами и бизнес-моделей. Она охватывает аппаратное обеспечение, услуги и ПО. Данные показывают, что инвестиции в DX все чаще концентрируются в области ПО.</p> <p>Среди трех групп технологий, составляющих расходы на DX, ПО является самой быстрорастущей. Его доля в общих затратах на DX вырастет с 32% в 2026 г. до 36% к <nobr>2029-му,</nobr> при среднегодовом темпе роста 21,7%, опережая как услуги (10,6% в год), так и оборудование (19,8% в год). Этот импульс все больше обусловлен масштабированием ИИ, который быстро переносит ценность из инфраструктуры в приложения и ускоряет спрос на программные возможности, основанные на ИИ.</p> <p>К 2029 г. на ИИ будет приходиться примерно 40% мировых инвестиций в ПО для DX, что является значительным изменением по сравнению с сегодняшним днем. Остальные 60% будут по-прежнему направляться в бизнес-приложения, системную инфраструктуру, а также платформы разработки и развертывания. Инвестиции в ИИ, представленные во всех секторах этого анализа, не являются изолированными. Они работают поверх уже существующих базовых уровней, и во многих случаях они зависят от этих уровней для обеспечения какой-либо ценности. В шести проанализированных секторах темпы внедрения ИИ значительно различаются, и эти различия тесно связаны с тем, насколько зрелым уже является базовый программный стек. ИИ появляется повсюду, но он внедряется поверх того, что организации уже создали.</p> <p> #IMAGE_235122#</p> <h3>Шесть секторов. Значительный масштаб. Разные приоритеты</h3> <p>В IDC «Worldwide Digital Transformation Spending Guide (V1 2026)» отслеживаются расходы на ПО для DX в шести основных отраслевых секторах (розничная торговля и услуги, финансовые услуги, производство и активы, здравоохранение, инфраструктура и энергетика, а также государственный сектор). В целом инвестиции в ПО сильно растут во всех шести секторах, и доля ИИ в них увеличивается — но темпы, масштабы и приоритеты использования значительно различаются в зависимости от сектора. То, что движет расходами на DX в розничной торговле и сфере услуг, отличается от того, что движет производством или финансовыми услугами. Секторальный контекст имеет значение.</p> <blockquote> <p><em>Рост расходов на ПО для </em><em>DX</em> <em>носит широкомасштабный характер. Это не просто волна расходов на ИИ. Организации инвестируют в весь стек ПО, чтобы трансформировать свою деятельность, и ИИ является ускоряющейся частью этого процесса, но не определяет его полностью.</em></p> </blockquote> <p>Рассмотрим три из шести секторов, проанализированных в отчете.</p> <p><strong>1. Розничная торговля и услуги. </strong>Этот сектор лидирует по общим расходам на ПО для цифровой трансформации. Он охватывает как розничных продавцов, так и широкий спектр видов деятельности, таких как гостиничный бизнес, туризм, услуги и многое другое. Управление клиентами возглавляет список приоритетов инвестиций: взаимодействие с клиентами по всем каналам, в режиме реального времени, с персонализированным и последовательным обслуживанием. На втором месте — омниканальная коммерция и платформы предоставления услуг, поскольку как розничные продавцы, так и поставщики услуг теперь работают одновременно в физическом, цифровом и мобильном сегментах.</p> <p>Третий приоритет — оперативная аналитика: управление энергопотреблением, планирование рабочего времени и инструменты повышения эффективности, которые в равной степени применимы как к работе магазинов, так и к операциям обслуживания. Многие из этих инвестиций сосредоточены в приложениях и инфраструктурных уровнях ПО для DX — платформах клиентских данных, системах управления персоналом и интеграционных уровнях, которые делают ИИ полезным, когда он появляется. Прогнозируется, что к 2029 г. доля ИИ в расходах на ПО для DX в этом секторе достигнет 42%, опираясь непосредственно на эту операционную основу.</p> <p><strong>2. Финансовые услуги.</strong> Этот сектор имеет самую высокую долю ИИ среди всех секторов, и более широкая картина инвестиций в DX объясняет, почему это произошло. Безопасность возглавляет список сценариев использования ИИ: обнаружение киберугроз и предотвращение мошенничества — это области, где инвестиции в ПО приносят четкую, измеримую отдачу, что делает их естественными опорными точками для расходов на DX на ранних этапах. Следующим шагом станет автоматизация основных бизнес-операций, поскольку финансовые учреждения заменяют ручные, основанные на правилах процессы системами, которые могут адаптироваться и масштабироваться.</p> <p>Здесь прослеживается тренд интеграции. ИИ встраивается в существующие программы DX, в те же основные приложения и инфраструктурные платформы, которые учреждения модернизируют уже много лет. Именно поэтому расходы остаются на стабильном уровне: они связаны с операционными результатами, которые уже показали свою важность для финансовых учреждений.</p> <p><strong>3. Производство и ресурсы. </strong>В настоящее время производственный сектор имеет самую низкую долю ИИ среди всех секторов с точки зрения DX, что также делает его одним из наиболее интересных для наблюдения. Инвестиции в DX здесь обусловлены очень практическими факторами: устаревающее оборудование, нехватка опытных инженеров и все более сложные цепочки поставок. Наибольшие инвестиции направлены на автономные операции, производственные среды переходят к системам, которые могут самостоятельно отслеживать и корректировать процессы, восстанавливаясь после большинства сбоев без участия человека.</p> <p>За ними следуют самовосстанавливающиеся активы и расширенное техническое обслуживание. Третий приоритет, менее очевидный, но набирающий обороты, — это управление клиентами: производители все чаще инвестируют в понимание и обслуживание конечных потребителей напрямую, а не только в оптимизацию внутренних операций. В совокупности эти приоритеты описывают этот сектор, как использующий инвестиции в DX для снижения операционных рисков, продления срока службы активов и построения более тесных рыночных отношений.</p> <blockquote> <p><em>Невысокую долю ИИ в производственном секторе сегодня не следует воспринимать как низкие амбиции. Сценарии применения, стимулирующие инвестиции в </em><em>DX</em><em>, — это автономные операции, поддержание работоспособности активов, близость к клиентам — именно здесь ИИ обеспечивает устойчивую, измеримую ценность. Траектория роста это отражает.</em></p> </blockquote> <h3>Три действия, которые стоит предпринять поставщикам технологий</h3> <p>Полученные данные о ПО для DX имеют очевидные последствия для поставщиков технологий и платформ. Это не пассивные тенденции, за которыми нужно следить, — это сигналы, которые должны определять ваше позиционирование, продажи и поддержку клиентов.</p> <p><strong>Помогите своим клиентам понять, где они находятся. </strong>Большинство организаций не имеют четкого представления о том, как их инвестиции в ПО соотносятся с инвестициями конкурентов в их секторе. Используйте данные о расходах на DX на уровне сектора, чтобы показать им, где концентрируются инвестиции, где они могут отставать и какие сценарии использования приносят результаты аналогичным организациям. Затем порекомендуйте инструменты, которые соответствуют их текущему этапу развития.</p> <p><strong>Обоснуйте необходимость платформенной интеграции, используя доказательства.</strong> Организации, которые полагаются на разрозненные точечные решения, сталкиваются с растущей сложностью по мере масштабирования программ DX и, как следствие, с более медленными результатами внедрения ИИ. Многие из них еще не осознали этого. Используйте данные о тенденциях расходов, чтобы наглядно показать клиентам, что платформенная интеграция дает лучшие результаты и почему консолидация является более практичным путем развития.</p> <p><strong>Рассматривайте готовность данных как вопрос успеха клиента, а не как обязательное условие.</strong> Результаты DX и результаты применения ИИ зависят от качества и доступности базовых данных. Предлагайте поддержку в области качества и управления данными в рамках взаимодействия с клиентами, чтобы они могли подготовиться к работе с данными.</p> Мария Ягнюк — аналитик-исследователь IDC в области данных и аналитики, обсуждает в корпоративном блоге … article https://www.itweek.ru/themes/detail.php?ID=235119 Mon, 06 Jul 2026 08:58:26 +0300 <p><em>Видеоконференции (Zoom, MS Teams, </em><em>Cisco Webex,</em> <em>TrueConf</em><em>, </em><em>IVA</em><em>, </em><em>Jitsi</em><em>)</em><em> — это настоящий кошмар для инфраструктуры виртуальных рабочих столов (VDI). Если видео и звук обрабатываются в виртуальной машине пользователя, это приводит к «сжиганию» колоссальны</em>х<em> вычислительных ресурсов серверов </em><em>VDI</em> <em>и забивает канал связи без возможности управления ее качеством (</em><em>QoS</em><em>).</em></p> <p>За последние два года мы получили сразу несколько параллельных трендов. Это массовый переход на отечественные решения VDI и ВКС, рост доли удаленной работы и повсеместное использование видеоконференций. По нашим наблюдениям, сегодня более 90% сотрудников регулярно используют ВКС, и почти в каждой инфраструктуре VDI эти сценарии уже стали критически важными.</p> <p>При этом именно видеоконференции оказались самым болезненным типом нагрузки для виртуальных машин. Использование ВКС в VDI часто ухудшает пользовательский опыт и влияет на эффективность цифровых рабочих мест. Мы решили разобраться почему и что с этим можно сделать.</p> <h3>Почему VDI «не тянет» видеоконференции</h3> <p>На этапе проектирования <nobr>VDI-инфраструктуры</nobr> обычно используется модель переподписки ресурсов (resource overcommitment). Ее суть заключается в том, что суммарный объем виртуальных процессоров, выделенных виртуальным рабочим местам, превышает количество физических ядер сервера. Например, на сервере с 64 физическими ядрами может быть размещено <nobr>40-60</nobr> виртуальных рабочих мест, каждому из которых выделено по 4 vCPU вместо 16 виртуальных машин, если бы на каждую выделялось строго по 4 vCPU. Поскольку пользователи редко создают максимальную нагрузку одновременно, вычислительные ресурсы могут эффективно распределяться между виртуальными машинами по мере необходимости.</p> <p>Для большинства типовых офисных сценариев такая модель оправдана и экономически эффективна. Работа с электронной почтой, корпоративными порталами, офисными документами, CRM-системами, браузером и другими бизнес-приложениями не требует постоянного выделения вычислительных ресурсов в режиме реального времени. Даже кратковременные задержки в предоставлении процессорного времени обычно остаются незаметными для пользователя.</p> <p>Однако видеоконференцсвязь относится к другому классу нагрузок. Обработка аудио- и видеопотоков происходит непрерывно и предъявляет жесткие требования к производительности, задержкам и стабильности выделения ресурсов.</p> <p>Клиент ВКС внутри виртуальной машины одновременно выполняет несколько ресурсоемких задач. Приложение кодирует и декодирует видео, обрабатывает аудиопоток, рендерит пользовательский интерфейс, а также принимает и передает данные от камеры, микрофона и гарнитуры пользователя. В отличие от большинства офисных приложений, все эти операции должны выполняться непрерывно и в режиме, приближенном к реальному времени.</p> <p>При этом программный клиент ВКС, работающий внутри виртуальной машины, не имеет объективной информации о фактически доступных ему ресурсах. Операционная система сообщает приложению, что в его распоряжении находятся выделенные ресурсы с фиксированными характеристиками: определённое количество процессорных ядер, память и сетевой интерфейс. Но в реальности эти ресурсы распределяются гипервизором между множеством виртуальных машин и предоставляются по мере доступности.</p> <p>В результате, при возникновении пиковых нагрузок на сервер виртуализации, клиент ВКС продолжает работать исходя из предположения, что вычислительная среда остается стабильной. Приложение пытается обрабатывать мультимедийные потоки с прежними параметрами качества и не может своевременно компенсировать ухудшение условий. С учетом особенностей среды это неизбежно приводит к деградации качества связи, что проявляется в искажениях звука, артефактах видеопотока, выпадении отдельных кадров и фрагментов речи.</p> <p>Одним из характерных симптомов становится рост джиттера (jitter), то есть колебаний времени доставки и потери сетевых пакетов. При стабильной работе системы ожидается, что они должны поступать через равные промежутки времени и с минимальными потерями. Если же интервалы начинают меняться в широком диапазоне, клиенту ВКС становится сложнее поддерживать непрерывное воспроизведение мультимедиа. Из-за этого «заикается» звук, нарушается синхронизация аудио и видео. Для коммуникационных сервисов такие отклонения критичны. Однако, джиттер и потери пакетов являются лишь внешним проявлением проблемы, которая на самом деле лежит на уровне архитектуры.</p> <p>Как показали наши исследования, клиент ВКС, работающий в виртуальной машине, не способен корректно оценивать и компенсировать изменения характеристик вычислительной среды. В отличие от физического рабочего места, где приложение напрямую взаимодействует с процессором, памятью, сетью и периферийными устройствами, в <nobr>VDI-среде</nobr> все эти ресурсы предоставляются через дополнительный слой виртуализации. Именно поэтому без специальных механизмов оптимизации даже современная <nobr>VDI-инфраструктура</nobr> не гарантирует качественную работу мультимедиа.</p> <h3>Как работают привычные подходы «добавить ресурсов» и «облегченные режимы»</h3> <p>При возникновении проблем с ВКС в VDI команды, отвечающие за инфраструктуру, в первую очередь предлагают увеличить объем ресурсов. Например, добавить виртуальные процессоры, память или расширить вычислительные мощности серверов виртуализации. На первый взгляд такой подход выглядит логичным, однако на практике он редко устраняет первопричину.</p> <p>Более того, подобное решение часто оказывается экономически неэффективным, потому что происходит перенос затрат из одного центра затрат в другой. Каждый вычислительный ресурс, который не удалось сэкономить за счет оптимизации работы ВКС-клиента или инфраструктуры видеоконференцсвязи, приходится компенсировать дополнительными ресурсами <nobr>VDI-платформы.</nobr> По оценкам специалистов, для достижения качества связи, сопоставимого с работой на физическом рабочем месте, может потребоваться выделение нескольких дополнительных vCPU на стороне фермы виртуальных рабочих мест. В результате стоимость инфраструктуры растет значительно быстрее, чем качество пользовательского опыта.</p> <p>Проблема в том, что в сценариях ВКС в VDI редко существует единственное узкое место. Как правило, на качество связи одновременно влияют несколько факторов: конкуренция виртуальных машин за процессорное время, особенности работы протоколов удаленного доступа, способ обработки мультимедийных потоков, а также сетевые характеристики, критичные для сервисов реального времени, — задержка, джиттер и потери пакетов. Поэтому простое увеличение ресурсов виртуальной машины можно сравнить с попыткой ехать быстрее на старом «Запорожце» через увеличение мощности двигателя автомобиля, не меняя качество дороги и организацию движения (на гоночном треке — тестовой среде — такой «Франкенштейн» может и покажет достойный результат, но в городе — в реальных условиях эксплуатации — так и будет ехать от светофора до светофора, регулярно догоняя конец пробки).</p> <p>Второй распространенный подход решения проблем с ВКС в VDI — это использование облегченных режимов работы программного клиента ВКС. В этом случае отдельные функции отключаются или упрощаются для снижения нагрузки на виртуальную машину. Однако сам клиент видеоконференцсвязи по-прежнему не получает достоверной информации о доступных ресурсах и текущем состоянии сети. Он не может учитывать реальные значения задержки, джиттера и потерь пакетов, а значит, не способен корректно адаптировать параметры обработки мультимедиа под условия виртуализированной среды. В дополнение, если в компании используется гибридный подход, то создаётся разрыв в пользовательском опыте при подключении к ВКС с ПК и при подключении к ВКС с тонких клиентов.</p> <p>Как следствие применения второго подхода незначительно снижается нагрузка на инфраструктуру виртуализации рабочих столов, но корневая причина остается, так как архитектура не меняется.</p> <p>Поэтому ни наращивание вычислительных ресурсов, ни использование облегченных режимов не позволяют обеспечить стабильно высокое качество видеоконференцсвязи в <nobr>VDI-среде</nobr> без специализированных механизмов оптимизации.</p> <h3>Где реальное узкое место при обработке мультимедиа</h3> <p>Критическое значение имеет место обработки мультимедийных потоков, а не объем выделенных ресурсов. Если кодирование и декодирование аудио и видео выполняются внутри виртуальной машины, все ограничения <nobr>VDI-инфраструктуры</nobr> начинают напрямую влиять на качество видеоконференцсвязи. Переподписка процессорных ресурсов, особенности работы гипервизора, конкуренция виртуальных машин за вычислительное время, сетевые задержки и потери пакетов в этом случае не действуют изолированно, а усиливают влияние друг друга.</p> <p>Дополнительная сложность проявляется в том, что программный клиент ВКС, работающий внутри виртуальной машины, не обладает полной информацией о фактическом состоянии вычислительной среды. Он не видит реальную загрузку хоста виртуализации, доступную вычислительную мощность в конкретный момент времени и характеристики сетевого соединения, критичные для сервисов реального времени. Соответственно, приложение не может своевременно скорректировать параметры обработки мультимедиа, например, изменить качество видеопотока, разрешение изображения или интенсивность кодирования в ответ на ухудшение условий выполнения.</p> <p>Для оценки влияния этих факторов были проведены испытания, моделирующие работу <nobr>VDI-инфраструктуры</nobr> при различных коэффициентах переподписки ресурсов и росте числа одновременных сеансов видеоконференцсвязи. Результаты показали устойчивую зависимость между увеличением нагрузки на сервер виртуализации и ухудшением качества мультимедийного трафика.</p> <p>По мере роста числа участников видеоконференций увеличивался джиттер, возрастало количество потерь пакетов и снижалась стабильность передачи аудио- и видеопотоков. При этом ухудшение пользовательского опыта наблюдалось даже в тех случаях, когда средняя загрузка процессоров оставалась в допустимых пределах. Пользователи сталкивались с искажениями звука, выпадением отдельных фраз, артефактами изображения и нестабильной работой видео.</p> <p>Полученные результаты показали, что проблему создает сама архитектура обработки мультимедиа внутри виртуальной машины. Пока клиент ВКС остается зависимым от ресурсов <nobr>VDI-среды</nobr> и не имеет возможности учитывать их реальное состояние, обеспечить качество связи, сопоставимое с физическим рабочим местом, крайне сложно.</p> <h3>Что на самом деле означает оптимизация ВКС для VDI</h3> <p>За последние годы ведущие разработчики <nobr>VDI-платформ</nobr> пришли к одинаковому выводу. Они считают, что обеспечить качество видеоконференцсвязи, сопоставимое с физическим рабочим местом, можно только в случае, если мультимедийный трафик перестает проходить через виртуальную машину пользователя.</p> <p>Поэтому в Citrix, VMware Horizon и других зрелых <nobr>VDI-решениях</nobr> используются механизмы выноса обработки мультимедиа на клиентское устройство (media offloading). Их задача — перенести обработку аудио- и видеопотоков на конечное устройство пользователя, оставив виртуальной машине только функции отображения интерфейса и выполнения бизнес-логики приложения.</p> <p>В такой архитектуре камера, микрофон и гарнитура взаимодействуют непосредственно с локальным устройством, а медиапоток передается напрямую между клиентом ВКС и сервером видеоконференцсвязи. Виртуальная машина исключается из критического пути и наиболее ресурсоемкой части процесса.</p> <p>Для этого используются специальные клиенты ВКС, оптимизированные для работы в <nobr>VDI-среде.</nobr> В отличие от стандартных приложений, они способны определить, что работают в виртуализированной инфраструктуре, и автоматически перенаправить обработку мультимедиа на устройство пользователя.</p> <p>Результат такого подхода хорошо заметен на практике. Если обработка видео и аудио выполняется внутри виртуальной машины, загрузка процессора может достигать <nobr>40-70%.</nobr> При использовании механизмов media offloading этот показатель обычно снижается до <nobr>3-4%,</nobr> а требования к серверной инфраструктуре сокращаются в несколько раз. Максимальный же эффект достижим при условии, что решение ВКС использует стандартные кодеки, которые могут быть декодированы на аппаратном уровне на устройстве пользователя (например, H.264, AV1 и т. д.). Использование исключительно программно-декодируемых кодеков возвращает нас к ситуации, когда мы снова переносим нагрузку из одной точки в другую — для таких решений говорить о полноценной оптимизации не приходится.</p> <p>При этом важно отличать полноценную оптимизацию ВКС от частичного ускорения отдельных компонентов. Некоторые решения ограничиваются оптимизированной передачей потоков от камеры и микрофона, но продолжают обрабатывать аудио- и видеоданные внутри виртуальной машины. Это может снизить нагрузку на отдельные элементы инфраструктуры, однако не устраняет фундаментальную причину и не обеспечивает качество связи, которое достигается при полном выносе обработки мультимедиа на клиентское устройство.</p> <h3>В чем подвох проброса камеры</h3> <p>Перенос обработки медиапотока на сторону клиента действительно решает проблему производительности, но здесь важно не путать технологии. Оптимизированный проброс камеры в сессию VDI не равноценен полноценной разгрузке серверов. По сути, проброс камеры — это вынужденная полумера, компромиссный вариант, который лишь частично сглаживает ограничения среды. Реальная оптимизация предполагает принципиально иной класс решений, в котором захват, обработка и маршрутизация видеопотока происходят локально на конечном устройстве пользователя, полностью минуя виртуальную машину.</p> <p>Такой подход исключает задержки, минимизирует паразитный трафик и делает работу ВКС предсказуемой. Максимальный эффект достигается в сценариях, где виртуальная среда отвечает исключительно за отрисовку интерфейса и бизнес-логику, а вся тяжелая работа с мультимедиа вынесена за пределы VDI. На практике это обеспечивает кратное падение серверной нагрузки, так утилизация CPU снижается с <nobr>40-70%</nobr> до <nobr>3-4%.</nobr> При этом качество видеосвязи выравнивается до уровня, полностью идентичного работе на физическом ПК.</p> <h3>Почему совместимость является главным барьером</h3> <p>Отдельной и часто недооцененной проблемой остается совместимость <nobr>VDI-платформ</nobr> и систем видеоконференцсвязи. Мировые лидеры, такие как Citrix и VMware, решали эту задачу совместно с разработчиками ВКС на протяжении многих лет. В результате появились механизмы оптимизации мультимедиа, позволяющие сохранять качество связи в виртуализированной среде на уровне, близком к физическому рабочему месту.</p> <p>В российских реалиях ситуация складывалась иначе. Многие отечественные ВКС-решения изначально разрабатывались без учета особенностей работы в <nobr>VDI-инфраструктурах.</nobr> А разработчики российских <nobr>VDI-платформ,</nobr> когда в 2022 году начался их бум, стремились заместить базовые возможности Citrix и VMware. Лишь со временем стало очевидно, что ключевым критерием зрелости VDI является не только виртуализация рабочего места, но и способность корректно поддерживать различные классы приложений, включая системы видеоконференцсвязи.</p> <p>Дополнительную сложность создает отсутствие единых механизмов взаимодействия между ВКС и VDI. Поэтому каждая комбинация продуктов требует отдельной адаптации и тестирования. В результате качество связи определяется не только возможностями самих решений, но и тем, насколько корректно они работают друг с другом. Поэтому сочетание VDI и ВКС от разных производителей нередко приводит к ухудшению пользовательского опыта.</p> <h3>Что это значит для ИТ-команд</h3> <p>Если на предприятии внедрен VDI, пользователи регулярно используют ВКС и жалуются на качество связи, то проблема почти наверняка кроется в мультимедийной нагрузке внутри виртуальной машины. Такие ситуации часто проявляются через взаимодействие ИТ-подразделений. ВКС и VDI, как правило, внедряют разные специалисты, и в результате каждая команда оценивает ситуацию в границах своей зоны ответственности. Команда VDI считает, что «ресурсов достаточно», а команда ВКС — что «клиенту не хватает производительности». Если возникают такие симптомы, это означает, что VDI используется в сценарии, для которого она изначально не оптимизирована. И этот вопрос касается всей ИТ-архитектуры.</p> <h3>Практические советы</h3> <ol> <li> При планировании <nobr>VDI-инфраструктуры</nobr> учитывайте, какое прикладное ПО будет работать в виртуальной среде. Если простые офисные задачи не накладывают особых требований к коэффициенту переподписки, то для ВКС без механизмов оптимизации корректное планирование ресурсов становится критичным.</li> <li> Используйте механизмы переноса обработки медиапотоков на клиентские устройства (offloading). Это дает максимальный эффект по снижению нагрузки.</li> <li> Используйте механизмы QoS и приоритизацию трафика. Без этого ВКС всегда проигрывает в конкуренции за ресурсы.</li> <li>Контролируйте сетевые параметры. Джиттер должен оставаться ниже 50 мс, это критический порог.</li> <li>Для снижения проектных рисков отдавайте предпочтения решениям, для которых производители подтвердили совместную работу VDI и ВКС в типовых корпоративных сценариях, а для сжатия аудио и видео используют стандартные аудио и видео кодеки, для которых большинство современных ПК и ТК обеспечат декодирование на аппаратном уровне.</li> </ol> <p>Мы видим, что рынок VDI в России неизбежно будет расти, и вместе с этим будет расти и нагрузка от мультимедиа. Следующим этапом развития станут клиентские решения, которые выносят медиапоток из ВМ, обеспечивают стабильное качество ВКС и работают независимо от конкретной связки VDI и ВКС.</p> <p>Мы рассматриваем это направление как ключевое. Потому что в любой комбинации — российский VDI с иностранным ВКС либо российский ВКС с российским VDI — компании получают проблему. И сегодня главный вопрос уже не в том, «как развернуть VDI», а в том, как сделать его эффективным для реальной коммуникации.</p> <p>#IMAGE_235120#</p> Видеоконференции (Zoom, MS Teams, Cisco Webex, TrueConf, IVA, Jitsi) — это настоящий кошмар для инфраструктуры … article Василий Шубин, директор по управлению продуктовым портфелем компании Getmobit https://www.itweek.ru/themes/detail.php?ID=235118 Fri, 03 Jul 2026 14:10:25 +0300 <p>МТС Линк, платформа для бизнес-коммуникаций, обучения и совместной работы, запустила маркетплейс ИИ-агентов для решения рабочих задач. Согласно опросу МТС Линк, 67% россиян хотели бы делегировать ИИ-агентам рутинные действия.</p> <p>Маркетплейс встроен в единое коммуникационное приложение МТС Линк. Одним из сервисов, доступных в его рамках, стал «Ваш помощник» — агент, представленный разработчиком около года назад. Сегодня он выполняет функцию цифровой памяти сотрудника: ему можно задать любой вопрос по содержанию встреч и чатов, к которым у пользователя есть доступ. Кроме того, в первой версии маркетплейса будут доступны ассистенты, настроенные под определенные роли и функции. В частности, среди них есть редактор для HR (составляет и улучшает описание вакансий), эксперт по продажам (пишет скрипты продаж и прорабатывает возражения клиентов), маркетолог (оптимизирует тексты для SEO, готовит карточки продуктов для маркетплейсов) и SMM-менеджер (составляет контент-планы, пишет посты и разрабатывает стратегию продвижения в соцсетях). </p> <p>Список доступных на маркетплейсе агентов будет постоянно расширяться. В ближайших планах — запуск ИИ-секретаря, который сможет находить и бронировать свободное время в календарях коллег и назначать им онлайн-встречи.</p> <p>Клиенты МТС Линк уже сегодня могут интегрировать собственных агентов в корпоративный мессенджер. В будущих обновлениях они смогут самостоятельно добавлять их на маркетплейс МТС Линк — это позволит сотрудникам быстро находить нужных им агентов. Также компании получат возможность через маркетплейс предлагать своих агентов другим организациям, в том числе платно.</p> <p>«Каждый день команды сталкиваются с однотипными задачами, и всё чаще сотрудники начинают использовать публичные ИИ-модели для их решения. Это увеличивает риск утечки конфиденциальной информации. ИИ-помощники и агенты, доступные в рамках платформы корпоративных коммуникаций, снижают эти риски. А формат взаимодействия в единой среде напоминает взаимодействие с коллегами: вы можете легко найти их по имени или аватарке и написать в корпоративном мессенджере», — отметил директор по продукту МТС Линк Сергей Тарасенко.</p> <p>По данным опроса МТС Линк, 13% россиян, знакомых с ИИ, утверждают, что в их компаниях уже применяют ИИ-агентов. Самый распространенный вид агента — ИИ—секретарь, который следит за календарем, заметками, планами, протоколирует мероприятия, рассылает итоги встреч участникам и ставит задачи в календарь (он есть у 57% из тех, кто применяет агентов. На втором месте — помощник в составлении отчетов, который готовит текстовое представление данных и презентации.</p> <p>В настоящее время треть россиян, применяющих ИИ, всё ещё считает, что ИИ-агенты им не нужны. Остальные респонденты уже готовы передать им широкий спектр задач. Помимо ИИ-секретаря и составителя отчетов, каждого из которых хотели бы иметь 30% респондентов, были отмечены ассистент по ответам на электронную почту (22%) и агент-офис-менеджер, который заказывает канцелярские и офисные принадлежности (15%). Также опрошенные хотели бы делегировать ИИ подбор персонала и бронирование билетов (по 12%).</p> <p>В исследовании МТС Линк приняли участие 1010 респондентов из России, из которых 78% хотя бы иногда применяют ИИ. Опросы проведены во втором квартале 2026 года.</p> МТС Линк, платформа для бизнес-коммуникаций, обучения и совместной работы, запустила маркетплейс ИИ-агентов для решения … message https://www.itweek.ru/themes/detail.php?ID=235117 Fri, 03 Jul 2026 12:42:32 +0300 <p>Эксперты компании «Информзащита» выявили, что в 2026 году 32% уязвимостей, обнаруженных при пентестах AI- и <nobr>LLM-приложений,</nobr> относятся к высокорисковым. По всем классам активов тот же показатель составляет около 12%, поэтому риск-профиль AI-приложений в 2,7 раза выше среднего. За второй год наблюдений эта пропорция не изменилась, что исключает версию о временном эффекте раннего внедрения технологии. Одновременно медианный срок устранения серьезных находок увеличился с 19 дней в 2025 году до 36 дней в <nobr>2026-м.</nobr></p> <p>У AI-систем одновременно работают два слоя риска: базовое веб- или API-приложение сохраняет привычные проблемы с аутентификацией, авторизацией, инъекциями, доступом к секретам и обработкой пользовательского ввода; поверх них появляются сценарии, связанные с поведением модели и ее интеграциями. Prompt injection, небезопасная обработка ответа LLM, утечка системного промпта, отравление данных, ошибки в RAG-контурах, нарушения в векторных хранилищах и отказ в обслуживании на уровне модели формируют широкое поле для атак. Разработчики часто подключают модель к корпоративным данным, API, CRM, базе знаний или инструментам автоматизации, чтобы получить полезный прикладной результат. Вместе с доступом модель получает возможность влиять на процессы, а ошибка в разграничении прав или в логике вызовов превращает ответ чат-бота в точку входа во внутренние системы.</p> <p>Проверить такую архитектуру стандартным сканером непросто, поскольку многие уязвимости проявляются только в цепочке событий. Для успешного prompt injection может понадобиться несколько сообщений, специально подготовленный документ в базе знаний, определенная роль пользователя и доступ агента к внешнему сервису. Избыточная агентность зависит от сочетания системного промпта, доступных инструментов, прав учетной записи и правил оркестратора. Участники исследования подтверждают границы автоматизации: 78% команд обнаруживали, что автоматические средства пропускали критичные уязвимости. На этом фоне готовность полностью доверить пентесты автономным инструментам за год сократилась с 29% до 9%, а 47% организаций выбрали гибридную модель, в которой автоматические проверки применяются к некритичным активам, а критичные системы проверяют специалисты.</p> <p>Разбивка инцидентов по векторам атак показывает, что у AI-продуктов нет единственной доминирующей точки отказа. Среди организаций, столкнувшихся с инцидентами, в 44% случаев причиной стал shadow AI: сотрудники использовали несанкционированные внешние сервисы, и чувствительные данные оказались за пределами контролируемого контура. По 41% пришлось на отравление данных и моделей и на небезопасную обработку ответов LLM. Уязвимости цепочки поставок указали в 35% случаев, prompt injection — в 34%, ошибки LLM и слабости векторных баз и эмбеддингов — по 32%. Далее следуют избыточная агентность и утечка системных промптов — по 24%, дезинформация — 20%, неограниченное потребление вычислительных ресурсов — 15%. Такая картина требует проверять не только модель, но и источники данных, плагины, цепочки поставки, права доступа, журналы действий и правила, по которым агент вызывает инструменты.</p> <p>Отраслевой разрез отчета не ранжирует сектора по числу высокорисковых уязвимостей, поэтому называть одну сферу наиболее подверженной было бы некорректно. В выборке 2026 года, включившей 455 ИБ-специалистов из компаний с численностью от 500 сотрудников, разработка ПО представлена 27% респондентов, здравоохранение — 21%, финансовый и страховой сектор — 14%, информационные сервисы — 10%, прочие отрасли — 27%. Для разработки ПО приоритетны риски генерации кода и доступа модели к репозиториям, конвейерам CI/CD и средам разработки. В здравоохранении цена ошибки связана с медицинскими данными и интеграциями с профильными информационными системами; в финансовом секторе — с платежной информацией, решениями, затрагивающими клиентов, и операциями с повышенными требованиями к контролю доступа. Информационные сервисы чаще используют AI для обработки массивов пользовательских запросов и корпоративного контента, поэтому нуждаются в контроле источников данных и фильтрации выдачи.</p> <p> Сложность состоит не только в поиске уязвимости, но и в ее устранении. В 2026 году организации закрывали 38,4% высокорисковых находок в AI/LLM-приложениях против 21,1% годом ранее, однако это все равно самый низкий показатель среди типов тестирования. Для desktop-приложений уровень устранения составил 40,2%, для веб-приложений — 73,7%, для API — 77,3%. Исправление AI-уязвимостей требует совместной работы ИБ, разработки, архитекторов, владельцев данных и иногда поставщика базовой модели. Управленческий контур нередко не успевает за этой связностью: 57% руководителей считают, что компания стабильно соблюдает SLA на устранение уязвимостей, тогда как среди практиков с этим согласны только 15%. При разрыве в 42 процентных пункта бизнес может недооценивать объем незакрытого риска и откладывать необходимые изменения в процессах.</p> <p>Снизить эту экспозицию можно через отдельную программу безопасности AI, встроенную в жизненный цикл продукта. Эксперты «Информзащиты» рекомендуют начать с инвентаризации моделей, агентов, подключенных инструментов, внешних сервисов и источников данных, а затем установить обязательные контрольные точки перед вводом каждого AI-решения в эксплуатацию. Для моделей, работающих с внутренними данными или способных выполнять действия от имени пользователя, необходимы ручной пентест и red teaming с проверкой многошаговых атак, prompt injection, разграничения прав, сценариев утечки через RAG и последствий небезопасного вызова инструментов. Автоматизация сохраняет ценность для регулярных проверок, инвентаризации и поиска повторяемых ошибок, но не заменяет экспертную оценку бизнес-логики и архитектуры. Общие для ИБ, разработки и руководства SLA, понятный порядок эскалации, контроль shadow AI и приоритизация устранения по реальному влиянию на данные и процессы позволяют сократить период, в течение которого высокая уязвимость остается доступной для эксплуатации.</p> Эксперты компании «Информзащита» выявили, что в 2026 году 32% уязвимостей, обнаруженных при пентестах AI- … message https://www.itweek.ru/themes/detail.php?ID=235114 Fri, 03 Jul 2026 12:17:05 +0300 <p>Компания BSS представила новую версию Чат-платформы, в которой поддерживается глобальный тренд на гиперперсонализацию и автоматизацию рутинных процессов. Ключевым вектором обновления стала глубокая интеграция генеративного ИИ для помощи операторам, а также расширение экосистемы корпоративных каналов связи.</p> <p>Российский разработчик BSS, известный своими решениями в области речевых технологий и ИИ, анонсировал выход версии 2.5 омниканальной чат-платформы. Обновление превращает стандартный АРМ оператора в гибридный интеллектуальный интерфейс, где классические каналы связи дополняются продвинутыми ИИ-инструментами, функцией совместного просмотра экрана и гибкими сценариями персонализации.</p> <p>Новая версия платформы BSS делает акцент на предиктивной поддержке оператора и бесшовной интеграции. Ключевым улучшением стала встроенная генерация подсказок на основе RAG (Retrieval-Augmented Generation) — система автоматически подтягивает релевантные фрагменты базы знаний прямо в окно диалога, реализуя полный цикл работы с RAG без необходимости переключения между системами. Для повышения скорости ответа добавлены настраиваемые шаблоны сообщений и пользовательские команды, адаптируемые под специфику веб-виджета и мессенджеров. Что касается последних, то добавлена поддержка корпоративных мессенджеров VK Teams и Slack.</p> <p>С технической стороны релиз 2.5 закрывает запросы бизнеса на гибкость: появилась возможность интеграции мобильных приложений через REST API без обязательного использования WebSocket, реализован b2b-адаптер для работы через сторонний бэкенд, а также расширены сценарии авторизации клиентов, обращающихся к веб-виджету — от JS callback с настраиваемыми полями до bearer token-инициализации виджета. Внимание разработчиков также привлекли функции управления жизненным циклом данных: теперь администраторы могут настраивать периоды очистки и архивации диалогов и отчетов прямо через веб-интерфейс чат-платформы.</p> <p>Для операторов добавлены важные тактические инструменты: отдельные кнопки для запроса номера телефона и геолокации абонента, режим приватного обмена сообщениями между сотрудниками, отложенные сообщения и точное отображение времени ожидания в очереди. Возможность повторного открытия сессии с закреплением за тем же оператором и кобраузинг (совместный просмотр экрана) в веб-виджете существенно повышают NPS и снижают число повторных обращений.</p> <p>«Новая версия чат-платформы отражает наш подход к построению интеллектуальной <nobr>CX-платформы</nobr> нового уровня. Мы интегрируем ИИ не как „замену человека“, а как усиление его компетенций — через RAG-подсказки, сценарные автозаполнения и адаптивный интерфейс. Это позволяет нашим заказчикам кратно сокращать время решения инцидентов и использовать единое окно для управления всеми клиентскими коммуникациями, будь то мессенджер, веб-сайт или мобильное приложение», — прокомментировал Александр Крушинский, директор департамента голосовых цифровых технологий BSS.</p> <p>Чат-платформа BSS — это единый интерфейс взаимодействия с клиентом, который повышает эффективность работы сотрудников, улучшает качество обслуживания и оптимизирует рабочие процессы. Решение органично встраивается в существующий ИТ-ландшафт, настраивается без программирования и закрывает потребности как крупных b2b-корпораций, так и сервисных операторов. Экспертиза BSS как лидера отечественного рынка речевых технологий, ИИ-агентов и мультиагентных систем позволяет говорить о новом витке развития омниканальных платформ, где на первый план выходит не просто связь, а интеллектуальный контекст диалога.</p> Компания BSS представила новую версию Чат-платформы, в которой поддерживается глобальный тренд на гиперперсонализацию … message https://www.itweek.ru/themes/detail.php?ID=235113 Fri, 03 Jul 2026 09:43:18 +0300 <p><em>Пал Нараянан, директор по цифровым и информационным технологиям логистической компании Kenco, рассказывает на портале </em><em>InformationWeek</em> <em>о том, почему последние 20% проекта внедрения имеют решающее значение и как извлекать уроки из неудач.</em></p> <p>Любой ИТ-руководитель скажет вам, что внедрить новую технологию — это как сдвинуть гору. Нужно найти бюджет, обосновать расходы и заручиться поддержкой руководства. И это еще до того, как будут проведены переговоры с поставщиками или начнется разработка инструмента собственными силами. А после того, как продукт будет куплен или разработан, его внедрение может либо оправдать, либо не оправдать ожидания руководства.</p> <p>Для CIO и других руководителей соблюдение ряда правил при внедрении корпоративных ИТ-решений, ориентированных на сотрудников, может стать решающим фактором, который поможет командам принять новый инструмент или, наоборот, заставит их его игнорировать.</p> <h3>Важные правила</h3> <p>Помните о следующих трех вещах:</p> <p><strong>Адаптируйтесь к рабочим процессам, а не наоборот. </strong>От этого никуда не деться: рядовые сотрудники, привыкшие к своим рабочим процессам, скорее всего, отнесутся к внедрению новых ИТ-решений со скептицизмом. Дело не в самом новом инструменте, а в изменениях, которые неизбежно происходят при его внедрении.</p> <p>Возьмем, к примеру, мою отрасль — цепочки поставок. Сотрудники знают, по каким маршрутам нужно двигаться, чтобы забрать товары с определенных складских полок и доставить их на определенные упаковочные станции. Такая последовательность позволяет сборщикам максимально эффективно выполнять свою работу. Любой инструмент, требующий от сотрудников изменения подхода к работе, существенно повлияет на производительность в краткосрочной перспективе, даже если внедрение не встретит сопротивления.</p> <p>Кроме того, ИТ-команды должны учитывать, что не каждый инструмент подходит для любого здания. У каждого объекта свои эксплуатационные требования, уникальная планировка и особые потребности клиентов, которые влияют на внедрение новых ИТ-инструментов. Если внедрять универсальные технологии, то на одних объектах производительность повысится, а на других — снизится.</p> <p>Независимо от отрасли, ИТ-служба должна решить, внедрение каких технологий оправдывает краткосрочные разрушительные последствия ради долгосрочной выгоды, а какие следует адаптировать под существующие рабочие процессы. Цель должна заключаться в бесшовной интеграции, которая сокращает количество шагов, необходимых для выполнения задачи, без создания дополнительных сложностей на начальном этапе.</p> <p><strong>Не пренебрегайте последними 20% процесса управления изменениями. </strong>Когда компании внедряют какой-либо ИТ-инструмент, 80% плана внутренних коммуникаций строится на нисходящих стратегиях, таких как общее собрание с участием CIO, письмо от генерального директора или список часто задаваемых вопросов с ответами, который рассылается сотрудникам через интранет. Такие меры обычно направлены на то, чтобы ответить на самые распространенные возможные вопросы, и укладываются в схему четкого информирования.</p> <p>Но самая важная работа приходится на оставшиеся 20%: это личное общение руководителей с рядовыми сотрудниками во время и после внедрения ИТ-инструментов. Это может проходить не очень гладко, потому что у сотрудников появляется возможность рассказать о любых препятствиях или разочарованиях, с которыми они столкнулись. В такой момент сложно сформулировать выверенное сообщение.</p> <p>ИТ-службам следует поощрять такие обсуждения, а не избегать их. Через несколько месяцев после запуска руководству следует напрямую связаться с рядовыми сотрудниками, чтобы узнать, как изменилась или не изменилась их работа благодаря новой технологии. Возможно, у компании нет ресурсов, чтобы устранять все неполадки, но искреннее сопереживание может во многом помочь сотрудникам адаптироваться к изменениям.</p> <p>Такие разговоры полезны для обеих сторон. ИТ-руководители могут найти новые способы использования технологий, наблюдая за тем, как сотрудники взаимодействуют с ними в режиме реального времени.</p> <p><strong>Принимайте неудачи, не игнорируйте их. </strong>От ИТ-руководителей требуют отчета за потраченные деньги. С появлением на рынке множества новых технологий, основанных на ИИ, выбор подходящего продукта и обоснование решения о покупке могут стать непростой задачей.</p> <p>Приходится выбирать между расходами на обеспечение бесперебойной работы существующих систем и расходами на внедрение новых инструментов. Если внедрение ИТ-решений идет не так, как планировалось, у команд может возникнуть соблазн закрыть глаза на проблемы, чтобы оправдать свои вложения.</p> <p>Но хотя некоторые инвестиции настолько масштабны, что важно, чтобы они окупились, ИТ-службы не должны бояться признать, что сравнительно небольшой проект провалился, пока он не поглотил весь бюджет. Чем дольше вы будете пытаться исправить ситуацию, тем больше недоверия вы вызовете у рядовых сотрудников и тем больше времени вам понадобится, чтобы найти другой ИТ-инструмент или вернуть работу в прежнее русло.</p> <p>Вместо того чтобы просто счесть проект провальным, ИТ-службам следует тщательно проанализировать, что пошло не так, и использовать полученные уроки для дальнейших инноваций. Потраченные деньги не являются потерей, если процесс привел команду к гораздо большей эффективности при следующем запуске. Главное — честно разобраться в том, что сработало, а что нет, и какие шаги следует предпринять, чтобы избежать повторения ошибок.</p> <h3>Речь идет о честности и прозрачности</h3> <p>Всякий раз, когда компания объявляет о внедрении нового инструмента, часто возлагаются большие надежды на то, как это может упростить работу или повысить производительность. Но руководству следует быть осторожным и не позволять радужным надеждам затмевать реальность внедрения технологии на предприятии.</p> <p>Если сделать инструменты максимально простыми в освоении, напрямую обсуждать с сотрудниками, что можно улучшить, и честно рассказывать компании об успехах и неудачах, связанных с новыми инструментами, то можно сформировать коллектив, который будет поддерживать инновации и работать сообща, чтобы внедрение новых инструментов прошло успешно.</p> Пал Нараянан, директор по цифровым и информационным технологиям логистической компании Kenco, рассказывает … article https://www.itweek.ru/themes/detail.php?ID=235110 Fri, 03 Jul 2026 09:20:29 +0300 <p>Интерес бизнеса к искусственному интеллекту продолжает расти, однако количество успешных внедрений остается значительно ниже числа запущенных инициатив. Мы видим, что проблема чаще всего кроется не в качестве моделей, данных или уровне технологий. Основные ошибки возникают гораздо раньше — на этапе постановки задачи и расчета экономического эффекта.</p> <p>Мы смотрим на ИИ-проекты с разных сторон: один из нас регулярно сталкивается с компаниями, которые приходят за внедрением или пытаются реанимировать уже запущенные инициативы, второй — отвечает за развитие ИИ-продуктов и финансовый результат крупных цифровых сервисов. Несмотря на разный опыт, мы сходимся в одном: большинство проектов терпят неудачу из-за отсутствия понятной экономической модели. Значительная часть инициатив не доходит до промышленной эксплуатации, оставаясь на стадии пилотов и красивых презентаций, так как не удается доказать их ценность для бизнеса в понятных финансовых показателях.</p> <h3>Почему технологии не гарантируют результат</h3> <p>Традиционно неудачи ИИ-проектов объясняют техническими факторами: качеством данных, ошибками моделей или требованиями безопасности. Эти проблемы действительно встречаются, но мы наблюдаем парадокс: технологии становятся доступнее и эффективнее с каждым годом, а количество успешных кейсов растет медленно.</p> <p>Причина в том, что многие компании начинают проект с обсуждения «железа», моделей и архитектуры, оставляя вопрос о конкретной бизнес-задаче и финансовом результате на потом. В итоге оценка эффективности происходит тогда, когда бюджет уже потрачен, а остановка проекта воспринимается как признание поражения. Проект продолжают развивать по инерции, пока руководство не задает прямой вопрос об окупаемости.</p> <h3>Три модели окупаемости: почему важно выбрать одну</h3> <p>Разговор об эффективности ИИ бессмысленен, пока компания не определила, как именно технология будет приносить деньги. Мы предлагаем рассматривать ИИ-инициативы через три базовые модели создания ценности. Важно не смешивать их, так как они реализуются по разным механизмам:</p> <ol> <li><strong>Снижение издержек.</strong> ИИ берет на себя рутину: обработку документов, модерацию, типовые ответы. Эффект здесь прямой: замещение человеко-часов. При расчетах важно учитывать не только экономию на ФОТ, но и сопутствующие расходы (инфраструктура, ИБ), которые могут нивелировать результат.</li> <li><strong>Масштабирование принятия решений.</strong> Есть процессы, которые не растут вместе с увеличением штата. Ценность ИИ здесь — не в экономии, а в радикальном повышении скорости и охвата. Ключевая метрика — дополнительная выручка за счет обработки большего числа операций и снижение рисков благодаря глубокой аналитике.</li> <li><strong>Влияние на продажи.</strong> Рекомендательные системы, персонализация и скоринг напрямую повышают конверсию, средний чек и удержание аудитории. В этих проектах связь между алгоритмами и прибылью наиболее очевидна.</li> </ol> <p>Проблемы начинаются, когда компания пытается реализовать всё и сразу. Это размывает цели. Если нет одной главной бизнес-метрики, невозможно объективно оценить результат. Поэтому еще до старта необходимо зафиксировать основной источник экономического эффекта.</p> <h3>Как говорить с финансовым директором</h3> <p>Даже самый совершенный проект не получит поддержки, если его ценность выражена в технических терминах. Финансового директора не интересует рост точности модели (F1-score), ему важны сроки окупаемости, экономия и прирост выручки.</p> <p>Успешные команды переводят метрики на «финансовый язык»: не «точность выросла на 15%», а «экономия составит 20 млн. рублей в год». Мы настаиваем на том, чтобы расчеты велись интегратором совместно с заказчиком. Когда бизнес самостоятельно участвует в формировании исходных данных по процессам, обсуждение становится конструктивным, а ответственность за результат — общей.</p> <h3>Экономика как инструмент переговоров</h3> <p>Правильно рассчитанная экономика помогает выстроить честные отношения при согласовании стоимости внедрения. Обсуждение перестает быть торгом за цену разработки — в центре внимания оказывается создаваемая ценность. Однако здесь важно избегать завышенных ожиданий: они помогают получить бюджет на старте, но неизбежно ведут к потере доверия, если реальные показатели не совпадут с прогнозом.</p> <h3><strong>Почему сложно обещать фиксированный бюджет</strong></h3> <p>Индустрия ИИ меняется быстро. Новые модели требуют обновления инфраструктуры, а расходы на информационную безопасность только растут. В таких условиях рассчитывать на жесткий фиксированный бюджет в долгосрочной перспективе нереалистично.</p> <p>Более устойчивый подход — сценарное планирование. Оно включает базовую оценку затрат, учет рисков (рост цен на ИБ и «железо») и создание резервного фонда на случай изменения технологического ландшафта.</p> <h3>In-house или SaaS: вопрос контроля</h3> <p>Часто компании думают, что создают собственное решение, хотя по факту используют внешние сервисы. Проблемы начинаются, когда поставщик меняет тарифы или условия.</p> <p>Мы советуем оценивать этот выбор через критичность процесса:</p> <ul> <li> Если технология влияет на ключевую выручку или лежит в основе продукта — ее нужно развивать in-house, сохраняя контроль над архитектурой.</li> <li> Если задача типовая — SaaS-модель часто выгоднее.</li> </ul> <p>Главный вопрос: что будет, если поставщик исчезнет или увеличит цены в несколько раз? </p> <h3>Итог: экономика важнее технологий</h3> <p>Успешность ИИ-проекта определяется не выбором модели, а качеством его экономического обоснования. Если работа начинается с расчета эффекта, даже неудачный эксперимент становится полезным опытом — вы получаете данные о том, какие гипотезы не подтвердились.</p> <p>Поэтому главный вопрос до запуска любого проекта звучит не «какую модель выбрать», а «какую ценность она создаст для бизнеса и как мы будем ее измерять». Именно это отделяет работающий бизнес-инструмент от дорогостоящей презентации.</p> <p>#IMAGE_235111#</p> <p>#IMAGE_235112#</p> Интерес бизнеса к искусственному интеллекту продолжает расти, однако количество успешных внедрений остается значительно ниже … article Валерий Котелов, CEO digital-интегратора KOTELOV, Павел Боюка, директор по ИИ-продуктам ООО “Оператор Газпром ИД” https://www.itweek.ru/themes/detail.php?ID=235107 Thu, 02 Jul 2026 15:05:45 +0300 <p>Группа Arenadata представила новую версию системы потоковой передачи и обработки данных Arenadata Streaming (ADS). В релизе 4.0.0.b1 реализована поддержка спецификации Apache Iceberg V3, обновлён коннектор для работы с Arenadata DB и инструменты мониторинга.</p> <p>В новой версии расширена функциональность Iceberg Sink Connector, который теперь поддерживает спецификацию Iceberg V3. Это позволяет использовать современные возможности табличного формата без потери производительности — работать с типами данных VARIANT и UNKNOWN, временными метками с точностью до наносекунд, векторами удаления (Deletion Vectors) и ключами шифрования метаданных.</p> <p>Обновлён NiFi ADB Connector — в его состав включён процессор GetGreengageRecord, предназначенный для загрузки данных из Greengage DB через протокол gpfdist. Процессор поддерживает режим пошаговой выгрузки, предполагающий чтение только вновь появившихся диапазонов данных, что позволяет снизить нагрузку на СУБД и NiFi, в том числе в сценариях реального времени. Кроме того, теперь NiFi ADB Connector «из коробки» поддерживает работу с Arenadata DB (ADB) 7.</p> <p>В релизе добавлена поддержка операционной системы Astra Linux 1.8. Появилась возможность использования мастера ADCM Wizard для установки ADS: он позволяет развернуть кластер с предварительной настройкой конфигураций безопасности — SSL, Kerberos, плагинов Ranger или их комбинацией. Реализована поддержка мониторинга на базе VictoriaMetrics с использованием кластера Arenadata Monitoring (ADM). </p> <p>Обновлены версии сервисов экосистемы Kafka и NiFi, коннекторов Debezium и Iceberg, а также сервиса Arenadata Monitoring. </p> <p>Arenadata Streaming — масштабируемая отказоустойчивая система для потоковой обработки данных в режиме реального времени, адаптированная для корпоративного использования и построенная на базе Apache Kafka и NiFi. Продукт включает графический пользовательский веб-интерфейс для управления кластерами потоковой передачи (ADS Control, ADSC), поддержку расширенной безопасности (Arenadata Platform Security, ADPS), а также ряд дополнительных инструментов для реализации репликации, проверки качества данных и других необходимых для продуктовой эксплуатации функций.</p> <p>Arenadata Streaming позволяет:</p> <ul> <li>в реальном времени строить потоковые конвейеры данных, надёжно передающих данные между системами или приложениями;</li> <li>в реальном времени разрабатывать потоковые приложения, преобразующие потоки данных или реагирующие на них;</li> <li>хранить потоки записей отказоустойчивым долговечным способом;</li> <li>разграничивать права доступа к потокам данных.</li> </ul> <p>На Arenadata Streaming получено свидетельство о государственной регистрации программы для ЭВМ. Продукт включён в единый реестр российских программ для электронных вычислительных машин и баз данных.</p> Группа Arenadata представила новую версию системы потоковой передачи и обработки данных Arenadata Streaming (ADS … message https://www.itweek.ru/themes/detail.php?ID=235106 Thu, 02 Jul 2026 14:37:02 +0300 <p>Генеративный ИИ уже заметно ускоряет работу исследователей, однако его влияние на конечные научные результаты пока остается ограниченным. Институт статистических исследований и экономики знаний (ИСИЭЗ) НИУ ВШЭ изучил, как российские ученые оценивают эффекты применения генеративных ИИ-сервисов в своей деятельности.</p> <p>Большинство российских ученых, применяющих генеративный ИИ в своей работе, уже видят практическую пользу, а в перспективе ожидают дальнейшего усиления его роли. Каждый второй пользователь считает, что такие технологии способствуют развитию его области науки (52%), еще 41% оценивают их влияние неоднозначно.</p> <p>Наиболее высоко вклад генеративного ИИ оценивают представители медицинских наук (64%), наиболее сдержанно — гуманитарных (41%). Женщины-исследователи, использующие генеративный ИИ, чаще мужчин считают его одновременно полезным и бесполезным для своей области науки (46% против 36%). При этом возраст ученых практически не влияет на оценку воздействия этих сервисов.</p> <p>Основные эффекты генеративного ИИ сегодня проявляются на уровне исследовательского процесса, а не его конечных результатов. Пользователи отмечают, что такие технологии прежде всего сокращают время на поиск научной литературы (71%), анализ данных (65%) и подготовку текстов на иностранном языке (64,5%), одновременно улучшая качество выполнения этих задач. Вместе с тем около 60% не наблюдают изменений в собственной публикационной активности, а оценки влияния ИИ на качество научных результатов разделились практически поровну (42% против 47%).</p> <p>Несмотря на существующие ограничения, генеративный ИИ, по мнению опрошенных ученых, пока практически не создает негативных эффектов для исследовательской деятельности. Лишь 5% пользователей отмечают ухудшение качества поиска научной литературы, около 3% — снижение скорости такого поиска, а по большинству остальных параметров доля негативных оценок не превышает 2%.</p> Генеративный ИИ уже заметно ускоряет работу исследователей, однако его влияние на конечные научные результаты пока … message https://www.itweek.ru/themes/detail.php?ID=235105 Thu, 02 Jul 2026 14:33:10 +0300 <p>Провайдер облачной сетевой инфраструктуры и решений в области кибербезопасности и доставки контента CURATOR, специализирующийся на обеспечении доступности интернет-ресурсов, нейтрализации DDoS-атак и защите веб-приложений, в рамках развития технологического сотрудничества с ИБ-компанией Alpha Systems, представил CURATOR.SCANNER — решение для регулярного выявления уязвимостей во внешней инфраструктуре компании, интегрированное непосредственно в личный кабинет платформы CURATOR.</p> <p>CURATOR.SCANNER выявляет открытые сетевые сервисы, определяет версии программного обеспечения, обнаруживает известные уязвимости, ошибки конфигурации и потенциальные векторы атак, а также помогает приоритизировать найденные риски и получить рекомендации по их устранению. Для запуска CURATOR.SCANNER достаточно задать объект проверки — домен, IP-адрес, диапазон адресов или веб-приложение — и подходящий шаблон сканирования прямо в интерфейсе платформы CURATOR: установка дополнительного программного обеспечения не требуется.</p> <p>Решение поддерживает несколько типов проверок: активное сканирование, обнаружение веб-компонентов, определение версий программного обеспечения и их сопоставление с базами известных уязвимостей, сканирование веб-приложений, выявление уязвимостей класса SQL Injection и других распространенных веб-рисков. Также CURATOR.SCANNER может определять наличие WAF и учитывать особенности его работы при проверке веб-приложений.</p> <p> «Часто успешные атаки начинаются с эксплуатации конкретной уязвимости во внешнем периметре. При этом многие компании либо не проверяют периметр регулярно, либо используют для этого отдельные инструменты, которые требуют значительных ресурсов на внедрение и сопровождение. CURATOR.SCANNER закрывает этот пробел: клиент получает возможность регулярно проверять свои ресурсы прямо из личного кабинета, без лишних затрат на инфраструктуру», — поделился Дмитрий Ткачев, генеральный директор CURATOR.</p> <p>«Партнерство с CURATOR позволило нам объединить возможности непрерывного мониторинга доступности и защиты интернет-ресурсов с инструментами анализа уязвимостей и конфигурационных ошибок. В результате пользователи платформы получают единый контур контроля внешнего периметра: от выявления рисков и оценки потенциальных векторов атак до защиты ресурсов от реальных угроз», — отметил Игорь Смирнов, генеральный директор Alpha Systems.</p> <p>Для большинства найденных уязвимостей автоматически применяется безопасная валидация, которая помогает отделить подтвержденные риски от потенциальных и сфокусировать ресурсы команды на наиболее значимых проблемах.</p> <p>Результаты каждого сканирования отображаются в личном кабинете CURATOR. Для каждой обнаруженной уязвимости указываются уровень критичности, описание проблемы, затронутый объект и рекомендации по устранению. Уязвимости распределяются по четырем уровням критичности — от критического до низкого, что позволяет выстраивать приоритизированный план исправлений.</p> <p>CURATOR.SCANNER дополняет существующий портфель облачных решений CURATOR. DDoS-защита помогает обеспечивать доступность интернет-ресурсов, WAF снижает риск эксплуатации уязвимостей веб-приложений, а сканер помогает заранее выявлять слабые места в заданном внешнем периметре клиента — не только на уровне веб-приложений, но и на уровне открытых сетевых сервисов.</p> <p>Результаты сканирования могут использоваться не только для устранения уязвимостей в приложениях и инфраструктурных компонентах, но и для настройки защитных механизмов CURATOR. Если уязвимость нельзя устранить оперативно, WAF может применяться как компенсирующая мера: для настройки новых правил, оптимизации существующих политик фильтрации и снижения вероятности эксплуатации до исправления первопричины. Таким образом, клиент получает в одном личном кабинете инструменты для обеспечения непрерывной доступности, фильтрации вредоносного трафика и регулярного контроля защищенности интернет-периметра.</p> Провайдер облачной сетевой инфраструктуры и решений в области кибербезопасности и доставки контента CURATOR … message https://www.itweek.ru/themes/detail.php?ID=235104 Thu, 02 Jul 2026 14:31:18 +0300 <p>Бизнес в России активно переходит от пилотных проектов искусственного интеллекта к его промышленной эксплуатации, однако вместе с ростом внедрения резко увеличиваются и риски: модели становятся привлекательной целью для киберпреступников. По словам Владимира Лебедева, директора по развитию бизнеса M1Cloud, защищенное облако перестает быть просто «местом хранения мощностей» и превращается в полноценную платформу для цифровой ИИ-трансформации.</p> <p>Уже в 2026 году искусственный интеллект в промышленности широко применяется для предиктивного обслуживания оборудования, оптимизации производственных процессов, контроля качества и создания цифровых двойников.</p> <p>По данным НИР Груп, количество успешных атак на ИИ-модели в 2025 году выросло на 48% по сравнению с предыдущим годом. По данным «Кросс технолоджис», в первой половине 2025 года количество атак на ИИ-системы производственных предприятий составило 19% от общего числа киберугроз.</p> <p>Промышленный ИИ оперирует критически важными данными, такими как показания датчиков, технологические параметры и цепочки поставок. При этом он сталкивается с целым рядом специфических угроз: к основным векторам атак относятся состязательные (adversarial) атаки, при которых небольшие и незаметные искажения входных данных заставляют модель принимать неверные решения — например, пропускать брак на конвейере или вызывать ложное срабатывание защиты оборудования. Серьезную опасность представляет отравление данных (poisoning) на этапах обучения или дообучения модели. Кроме того, существуют инверсионные атаки, позволяющие восстановить конфиденциальную информацию о производственном процессе, а также внедрение вредоносных инструкций (prompt injection) в агентные системы, управляющие робототехникой и логистикой.</p> <p>Для промышленных компаний последствия таких инцидентов могут быть катастрофическими и выражаться не только в многодневном простое производственной линии стоимостью в десятки миллионов рублей в сутки, но и в утечке уникальных технологий или нарушении строгих требований промышленной безопасности.</p> <p>Облачные платформы позволяют выносить мониторинг ИИ-моделей на инфраструктурный уровень. Вместо разрозненных средств защиты предприятия получают централизованную систему, которая анализирует поведение моделей в реальном времени (drift detection), сравнивает входные данные с baseline-профайлами, автоматически изолирует подозрительные запросы, а также интегрируется с решениями специализированных вендоров по защите ИИ (например, платформой типа СЗИИ).</p> <p>Облако дает преимущество эластичности в моменты пиковых нагрузок (масштабное дообучение моделей) ресурсы GPUaaS выделяются автоматически, а чувствительные данные остаются в изолированных контурах, соответствующих требованиям регуляторов.</p> <p>Защищенное облако позволяет промышленным компаниям перейти от операционной автоматизации к стратегическому использованию ИИ. Ключевыми направлениями на <nobr>2026–2028</nobr> годы станут создание цифровых двойников предприятий и отдельных агрегатов, внедрение многоагентных систем, координирующих работу цехов и цепочек поставок, а также развитие предиктивной аналитики для прогнозирования спроса, износа оборудования и рисков.</p> <p>По прогнозам аналитиков M1Cloud, российский рынок ИИ в промышленности продолжит уверенный рост, следуя за глобальным трендом высоких темпов развития отрасли, где доминируют масштабируемые облачные решения. К 2028 году ожидается массовый переход к гибридным архитектурам: критически важные модели будут работать в защищенном облаке, а часть вычислений переместится на edge-устройства непосредственно на производстве.</p> <p>В 2026 году значительно выросли вложения в инструменты ИИ для информационной безопасности. Наблюдается переход от отдельных моделей к полноценным AI-native производственным системам, а также популяризация мультиклауд-подходов для баланса между безопасностью и стоимостью.</p> <p>К <nobr>2027–2028</nobr> годам ожидается ужесточение регуляторных требований к безопасности искусственного интеллекта на критически важных объектах. Компании, которые уже сейчас строят защиту на уровне инфраструктуры, получат значительное преимущество: они смогут быстрее проходить аудиты, снижать страховые риски и масштабировать ИИ-проекты опережающими темпами.</p> <p>Промышленные предприятия, использующие защищенное облако, смогут не только оперативно реагировать на киберугрозы, но и превращать данные в стратегическое конкурентное преимущество — точнее прогнозировать простои, оптимизировать энергопотребление и повышать общую эффективность производства на <nobr>10-20%</nobr> и более.</p> <p>Компании, которые сегодня внедряют мониторинг атак на искусственный интеллект и выстраивают стратегию на горизонте <nobr>3–5 лет,</nobr> будут готовы к новым регуляторным и рыночным вызовам.</p> Бизнес в России активно переходит от пилотных проектов искусственного интеллекта к его промышленной эксплуатации … message https://www.itweek.ru/themes/detail.php?ID=235102 Thu, 02 Jul 2026 09:42:01 +0300 <p><em>По мере того как внедрение искусственного интеллекта набирает обороты в корпоративном секторе, организации усваивают важный урок: поверхностного обучения, привязанного к отдельным сценариям использования, недостаточно. Чтобы добиться успеха, организации должны рассматривать грамотность в области ИИ как стратегически важный навык для всего предприятия, пишет в корпоративном блоге Джина Смит, директор </em><em>IDC</em> <em>по исследованиям в области ИТ-навыков для цифрового бизнеса.</em></p> <p>Это означает, что обучение работе с ИИ должно стать частью корпоративной культуры, структуры управления, процесса адаптации новых сотрудников и требований к эффективности работы. Это также означает отказ от подхода, ориентированного на пилотные проекты, и создание систематических программ с постоянной поддержкой со стороны руководства, учебных программ с учетом должностных обязанностей и реальной дисциплины управления изменениями.</p> <p>Исследование IDC выявило существующий разрыв в этой области.</p> <blockquote> <p><em>Согласно опросу IDC «2026 Global IT Skills Survey», только треть мировых ИТ-руководителей и бизнес-лидеров утверждают, что полностью готовы внедрить ИИ в повседневную работу. Около 93% ИТ-руководителей считают владение ИИ самым важным корпоративным навыком, однако многие организации еще не приступили к обучению сотрудников работе с ИИ.</em></p> </blockquote> <p>Тем временем компании продолжают реализовывать свои планы по внедрению ИИ. В результате многие сотрудники вынуждены импровизировать, используя те инструменты, на которые делают ставку их компании. Добрые намерения не заменят реальных организационных знаний о том, что может и чего не может ИИ, а также о том, как его лучше всего использовать.</p> <p>Как показало недавнее исследование IDC «Foundation AI Literacy», посвященное базовым компетенциям, необходимым каждому сотруднику для ответственного и эффективного использования ИИ, обучением работе с ИИ должны быть охвачены все, а не только технические специалисты. Масштабирование здесь означает переход от обучения на пилотных проектах и по конкретным сценариям использования к многоуровневой программе, охватывающей весь коллектив. Начните с основ для всех сотрудников: что такое ИИ и чем он не является, правила ответственного использования и основные риски, в том числе предвзятость, галлюцинации, нарушение конфиденциальности и утечка данных. Затем расскажите о преимуществах, возможностях для расширения функционала и повышения производительности. Большинство сотрудников не имеют систематической академической подготовки в области ИИ, поэтому важно, чтобы обучение было доступным и учитывало должностные обязанности.</p> <p>Вот шесть практик, которые отличают успешные инициативы в области ИИ в международных организациях.</p> <p>#IMAGE_235103#</p> <h3>1. Заручитесь поддержкой руководства</h3> <p>Успешные программы начинаются с видимой и постоянной поддержки со стороны высшего руководства. Когда генеральный или операционный директор ясно дает понять, что ответственное использование ИИ является приоритетом для бизнеса, внедрение ИИ ускоряется. Рассматривайте грамотность в вопросах ИИ как стратегический навык сотрудников, напрямую связанный с целями организации, системами управления рисками и приоритетами в области корпоративного управления. Он должен быть частью системы управления ИИ и соблюдения нормативных требований, а не существовать отдельно от них.</p> <h3>2. Адаптируйте программу под конкретные роли</h3> <p>После того как будет заложена основа, добавьте модули, ориентированные на конкретные роли. Бизнес-руководителям необходимы навыки принятия стратегических решений, контроля и оценки рисков. Техническим командам нужны навыки внедрения, проверки и мониторинга. Добавьте к этому обучение на основе сценариев: реалистичные отраслевые кейсы и примеры эффективного использования, взятые из вашей среды, по возможности в смоделированных условиях. Чем ближе обучение к реальной работе, тем лучше оно усваивается.</p> <h3>3. Внедрите принципы управления</h3> <p>Принципы ответственного использования ИИ, справедливости, прозрачности, подотчетности и конфиденциальности не должны быть отдельным модулем. Включите их в программу обучения. Обучение должно быть направлено на закрепление внутренних политик использования ИИ, стандартов классификации данных, процедур эскалации и контроля, а также требований к документации. Используйте реальные примеры из вашей отрасли. Конкретные примеры реальных последствий — как положительных, так и отрицательных — вот что помогает внедрить систему управления.</p> <h3>4. Закрепляйте и измеряйте результаты</h3> <p>Одноразовое обучение не дает результата, поскольку возможности, риски и политики, связанные с ИИ, постоянно меняются. Включите в программу периодические новшества, проверку знаний, обратную связь и постоянные обновления, а также внедрите закрепление материала непосредственно в повседневные рабочие процессы, чтобы повысить уровень усвоения. Оценивайте не только процент прохождения обучения. Отслеживайте изменения в поведении и их влияние. Внедрение одобренных ИИ-инструментов, сокращение нарушений правил, улучшение качества документации, а также повышение производительности и качества могут и должны быть связаны с ответственным подходом к использованию ИИ. Эти показатели дают уверенность в том, что программа действительно работает, а также доказательства, необходимые для сохранения инвестиций в нее.</p> <h3>5. Используйте разные способы обучения</h3> <p>Разные форматы закрепляют разные модели поведения, и зрелые программы не ограничиваются одним форматом. Они сочетают в себе самостоятельное электронное обучение, очные семинары, микрообучение, практические занятия и подсказки в приложениях. Встречаться с людьми там, где они работают, в процессе их деятельности, гораздо эффективнее, чем проводить разовые мероприятия.</p> <h3>6. Руководите и поддерживайте</h3> <p>Все это не сработает без видимой и постоянной поддержки со стороны руководства. Относитесь к грамотности в области ИИ как к базовой, обязательной компетенции для всех сотрудников, как к обучению по вопросам кибербезопасности или конфиденциальности данных. Четкая коммуникация помогает: делайте акцент на том, что ИИ — это инструмент, а не цель, подчеркивайте приверженность организации ответственному использованию ИИ и то, как грамотность в этой области помогает выполнять миссию, управлять ресурсами и рисками. Грамотное управление изменениями снижает неопределенность. Кроме того, это препятствует использованию теневого ИИ, когда люди прибегают к неутвержденным инструментам, потому что никто не показал им одобренный путь.</p> <p>Вывод прост. Организации, которые рассматривают грамотность в области ИИ как стратегический потенциал, смогут сократить разрыв между инвестициями в ИИ и результатами его применения. Те же, кто пренебрегает этой дисциплиной, столкнутся с растущим разрывом между амбициями и готовностью к переменам.</p> По мере того как внедрение искусственного интеллекта набирает обороты в корпоративном секторе, организации усваивают … article https://www.itweek.ru/themes/detail.php?ID=235100 Thu, 02 Jul 2026 09:32:44 +0300 <p><em>Low-code часто обсуждают в контексте скорости создания решений, и это действительно важное преимущество технологии. Однако настоящая проверка low-code начинается после запуска. Рассмотрим, как выстроить надежный ИТ-сервис с понятным жизненным циклом.</em></p> <h3>Почему low-code нельзя оставлять без системы управления</h3> <p>На этапе пилотного проекта low-code-решение часто находится в неформальной модели поддержки. Команда небольшая, пользователи известны, процесс ограничен, а изменения происходят быстро. Если возникают сбои, понятно, к кому обратиться. Если нужна доработка, ее можно обсудить напрямую.</p> <p>Как только приложение попадает в промышленную эксплуатацию, оно становится частью ИТ-сервиса. Количество обращений резко возрастает вместе с увеличением числа пользователей, при этом команде необходимо оперативно реагировать на инциденты, решать вопросы с доступами и заниматься обновлениями.</p> <p>Для промышленного low-code нужен выстроенный процесс управления ИТ-услугами (IT Service Management, ITSM): каталогизация сервисов, управление инцидентами и изменениями, контроль доступов, планирование релизов, ведение базы знаний и прозрачный жизненный цикл решений.</p> <p>Когда low-code становится корпоративным инструментом, появляются вопросы, которые нельзя решать в ручном режиме:</p> <ul> <li> куда пользователь обращается при ошибке;</li> <li> кто классифицирует инцидент;</li> <li> какой уровень поддержки у приложения;</li> <li> кто технический и бизнес-владелец;</li> <li> кто согласует изменение;</li> <li> как фиксируются доработки;</li> <li> какие системы и данные затрагивает приложение;</li> <li> как проверяется влияние обновлений платформы;</li> <li> кто управляет доступами;</li> <li> где хранится документация;</li> <li> как решение выводится из эксплуатации.</li> </ul> <p>Если ответов нет, low-code-портфель оказывается в серой зоне. Формально приложения работают, бизнес ими пользуется, процессы начинают от них зависеть, но в операционной модели ИТ они не отражены как управляемые сервисы. Для бизнеса это означает непредсказуемость: непонятно, кто отвечает за сбой и сколько времени займет восстановление, что будет при обновлении платформы и можно ли рассчитывать на решение в критичный момент.</p> <h3>Low-code-приложение как ИТ-сервис</h3> <p>При зрелом подходе промышленное low-code-приложение рассматривается не как быстрая автоматизация, а как ИТ-сервис с жизненным циклом.</p> <p>Он обладает понятными атрибутами:</p> <ul> <li> назначение;</li> <li> технический и бизнес-владелец;</li> <li> пользователи;</li> <li> критичность;</li> <li> уровень поддержки;</li> <li> связанные системы;</li> <li> данные и интеграции;</li> <li> правила доступа;</li> <li> порядок обработки инцидентов;</li> <li> порядок внесения изменений;</li> <li> требования к обновлениям;</li> <li> документация;</li> <li> условия вывода из эксплуатации.</li> </ul> <p>Это не значит, что даже небольшое low-code-решение должно сопровождаться как крупная ERP-система, но все решения должны быть классифицированы. Для простой внутренней формы можно использовать облегченный маршрут поддержки. Приложение, которое влияет на клиентский процесс или операционную цепочку, должно находиться в более строгой модели: с SLA, регламентом изменений, тестированием, контролем доступов и планом восстановления.</p> <h3>Каталог low-code-сервисов</h3> <p>Первый элемент ITSM-контура — каталог low-code-сервисов. Компания должна понимать, какие low-code-решения она использует, какие процессы они поддерживают и кто за них отвечает.</p> <p>Этот каталог может быть частью базы данных управления конфигурациями (CMDB), каталога ИТ-сервисов или отдельного реестра, который интегрирован с ITSM-процессами. Главное, чтобы low-code-решения не существовали отдельно от общей картины ИТ-ландшафта.</p> <p>Без каталога невозможно управлять портфелем. Если нет владельца, неясно, кто принимает решение о развитии. Если не указаны зависимости, обновление платформы может неожиданно затронуть бизнес-процесс. Когда неизвестна критичность, невозможно правильно расставить приоритеты при инциденте.</p> <h3>Управление инцидентами</h3> <p>Второй элемент — управление инцидентами. У пользователя должен быть понятный канал обращения. Ошибка не должна решаться через личные сообщения разработчику или случайный чат проектной команды. Инцидент должен попадать в общий процесс поддержки: регистрироваться, классифицироваться, назначаться ответственному, получать приоритет и закрываться с фиксацией результата.</p> <p>Для low-code особенно важно правильно определить источник проблемы. Сбой может быть связан не с самим приложением, а с платформой, интеграцией или другими факторами. Без классификации поддержка начинает работать вслепую. Пользователь видит одно: «приложение не работает», но для устранения причины нужно понять, где именно нарушился контур.</p> <p>Для low-code полезно выделять отдельные категории инцидентов:</p> <ul> <li> ошибка пользовательского сценария;</li> <li> ошибка бизнес-логики;</li> <li> проблема доступа;</li> <li> проблема интеграции;</li> <li> недоступность платформы;</li> <li> ошибка внешней системы;</li> <li> проблема данных;</li> <li> последствия обновления;</li> <li> ошибка ИИ-сценария или агента.</li> </ul> <p>Такая классификация помогает быстрее маршрутизировать обращения и видеть повторяющиеся проблемы.</p> <h3>Управление изменениями</h3> <p>Low-code создает ощущение, что изменения можно вносить почти мгновенно. Но если приложение уже используется в промышленной среде, любая доработка может повлиять на пользователей, данные, интеграции и смежные процессы. Поэтому изменение должно быть управляемым, даже если оно небольшое.</p> <p>Необязательно каждую правку проводить через длительные согласования. Однако нужно знать, кто инициировал изменение, какую проблему оно решает и кто согласовал бизнес-логику. Важно также понимать, когда изменение будет опубликовано, каких пользователей затронет, нужно ли тестирование и кто отвечает за откат, если что-то пойдет не так.</p> <p>Для простых изменений может быть легкий маршрут. Например, при добавлении поля без влияния на интеграции или настройке уведомлений. Однако для изменений, которые затрагивают права, данные, интеграции, критичные процессы или ИИ-агентов, нужен более строгий контроль.</p> <h3>Управление доступами</h3> <p>Low-code-решения работают с корпоративными данными, бизнес-процессами и интеграциями, поэтому доступы нельзя выдавать по принципу «попросили в чате — добавили». Должен быть понятный процесс: кто может запросить доступ, кто его утверждает и как он отзывается при смене роли сотрудника.</p> <p>Помимо пользовательских доступов, важно управлять сервисными учетными записями, интеграционными правами и правами ИИ-агентов. Если агент или автоматический сценарий может выполнять действия в системе, его права должны быть описаны так же строго, как права пользователя-человека: что он может видеть и менять, какие действия требуют подтверждения и где фиксируется цифровой след.</p> <h3>Релизы, обновления и уязвимости</h3> <p>Low-code-платформы постоянно развиваются: появляются новые компоненты, коннекторы, ИИ-функции и обновления безопасности. Каждое такое изменение может повлиять на работающие приложения. Если компания не знает, какие компоненты и интеграции используются в ее приложениях, обновление становится лотереей.</p> <p>В ITSM-контуре обновление должно проходить как управляемое изменение. Сначала оценивается его влияние и определяются затронутые сервисы, выполняется тестирование и оповещение владельцев, после чего проходит установка, проверка и фиксация результата.</p> <p>Для критичных уязвимостей нужен ускоренный маршрут. Откладывать исправления до удобного момента опасно: известные уязвимости быстро анализируются и используются злоумышленниками., но ускоренный маршрут не означает хаотичный. В любом случае он должен включать оценку риска, приоритизацию, тестовый контур, проверку ключевых сценариев и план отката.</p> <h3>База знаний и поддержка</h3> <p>Чтобы low-code-портфель сопровождался устойчиво, знания не должны замыкаться на отдельных разработчиках или подрядчиках.</p> <p>По каждому значимому решению нужны минимальные материалы: описание назначения, схема процесса, основные роли, типовые ошибки, инструкция для первой линии поддержки, контакты владельцев, список интеграций, правила доступа, сценарии восстановления и история изменений.</p> <p>Быстрые решения часто документируются хуже классических проектов. Пока рядом команда внедрения, проблема незаметна. Через полгода—год отсутствие знаний превращается в риск сопровождения. База знаний снижает зависимость от конкретных сотрудников и помогает встроить low-code в операционную поддержку.</p> <h3>Жизненный цикл и вывод из эксплуатации</h3> <p>Не каждое low-code-решение рассчитано на долгую эксплуатацию. Часть из них создается как минимально жизнеспособный продукт (MVP), часть — для закрытия временных потребностей. Некоторые приложения дублируют функциональность, которая позже появляется в основной корпоративной системе. Другие устаревают вместе с процессом.</p> <p>Если решения не выводить из эксплуатации, портфель начинает разрастаться. Поддерживать приходится все — от старых форм и неактуальных интеграций до устаревших доступов и приложений без владельца. Поэтому в ITSM-контуре должен быть статус жизненного цикла: пилот, промышленная эксплуатация, развитие, ограниченная поддержка, архивирование, вывод из эксплуатации.</p> <p>Вывод решения из эксплуатации — тоже управляемый процесс. Нужно понять, кто использует приложение, какие данные нужно сохранить, какие интеграции отключить, кого уведомить и чем заменить функцию. Без этого low-code превращается в накопитель технологического долга.</p> <h3>Как связать ITSM и центр компетенций</h3> <p>ITSM-контур не должен существовать отдельно от центра компетенций low-code. Центр компетенций отвечает за методологию, архитектурные правила, каталог компонентов, качество и развитие практики. ITSM берет на себя эксплуатационную дисциплину: инциденты, изменения, доступы, релизы, знания, SLA и жизненный цикл.</p> <p>Вместе они дают полноценную модель. Центр компетенций помогает определить, как low-code-приложение должно создаваться, а ITSM обеспечивает его работу после запуска. Если эти функции не связаны, возникает разрыв: проекты быстро создаются по методологии, но потом выпадают из поддержки. Возможна и обратная ситуация: поддержка пытается сопровождать приложения, о которых нет систематизированной архитектурной и продуктовой информации.</p> <p>В зрелой модели каждое промышленное low-code-решение попадает из проектного контура в операционный: с владельцем, документацией, уровнем поддержки, регламентом изменений и записью в каталоге сервисов.</p> <h3>Роль интегратора</h3> <p>Для крупного бизнеса роль интегратора не заканчивается разработкой приложения. Он помогает выстроить весь его жизненный цикл: от выбора сценариев и архитектуры до промышленной эксплуатации, поддержки и развития портфеля. В контексте ITSM это означает помощь в создании каталога low-code-сервисов, описании моделей поддержки, настройке процессов инцидентов и изменений, регламентах обновлений, базе знаний и выводе решений из эксплуатации.</p> <p>Low-code-направление может быть полезно не только как команда быстрой разработки, но также как партнер, способный встроить технологию в зрелую операционную модель ИТ. Это особенно важно для ИТ-директоров. Помимо скорости сборки, их волнует, как приложение будет поддерживаться, кто за него отвечает и как портфель решений будет жить через год.</p> <p> #IMAGE_235101#</p> Low-code часто обсуждают в контексте скорости создания решений, и это действительно важное преимущество технологии … article Михаил Миронов, директор отделения low-code-решений группы компаний IBS https://www.itweek.ru/themes/detail.php?ID=235099 Wed, 01 Jul 2026 16:30:06 +0300 <p>Научные открытия по-прежнему делают люди, но значительную часть работы с растущими потоками данных все чаще выполняют с помощью искусственного интеллекта. Институт статистических исследований и экономики знаний (ИСИЭЗ) НИУ ВШЭ проанализировал масштабы и направления использования этой технологии российскими учеными.</p> <p>Главные выводы:</p> <ul> <li>85% опрошенных ученых уже применяют ИИ-решения в своей работе;</li> <li>основным форматом взаимодействия с ИИ стали генеративные сервисы: ими пользуются 99% ученых, работающих с ИИ (84% всех ученых). Специализированные инструменты применяют около трети пользователей ИИ (32%), или 27% всех опрошенных ученых;</li> <li>ИИ быстро проходит путь от новой технологии к повседневному инструменту исследователя. Притом что генеративные сервисы большинство респондентов (76%) освоили лишь в последние два года, уже более двух третей их пользователей (68%) обращаются к ним не реже раза в неделю, в том числе 35% — ежедневно. Еще треть (32%) используют такие сервисы несколько раз в месяц или реже;</li> <li>генеративный ИИ широко распространен во всех областях науки: среди представителей социальных наук его используют 89% исследователей, технических, медицинских и естественных наук — <nobr>84–87%,</nobr> гуманитарных и сельскохозяйственных — <nobr>76–77%.</nobr> При этом дисциплинарные различия проявляются прежде всего в характере использования таких инструментов. Так, для работы с кодом генеративный ИИ применяют около трети представителей естественных и технических наук (по 32%), тогда как в гуманитарных науках — лишь 4%. В отношении специализированных инструментов значимые дисциплинарные различия почти не наблюдаются. Единственное исключение — гуманитарные науки, среди представителей которых только 16% применяют ИИ такого типа (против 29% в среднем по другим областям);</li> <li>возрастные различия также выражены умеренно: среди ученых до 44 лет ИИ используют около 90% респондентов, в группах <nobr>45–69</nobr> лет — <nobr>83–86%,</nobr> среди ученых 70 лет и старше — 71%. При этом молодые исследователи заметно чаще обращаются к ИИ для генерации и доработки кода, а представители старших возрастных групп — для перевода текстов и подготовки презентаций;</li> <li>генеративные ИИ-сервисы востребованы практически на всех этапах научной работы: не менее пятой части опрошенных их применяют для решения 16 из 19 исследовательских задач. Наиболее частыми сценариями использования ИИ стали поиск и отбор информации, работа с научной литературой и перевод текстов с русского на иностранные языки (каждую из этих задач с помощью ИИ решают более половины пользователей). Реже такие инструменты применяются для генерации и доработки кода, обобщения ненаучной информации и подготовки экспертных заключений.</li> </ul> Научные открытия по-прежнему делают люди, но значительную часть работы с растущими потоками данных все чаще выполняют … message https://www.itweek.ru/themes/detail.php?ID=235097 Wed, 01 Jul 2026 16:23:42 +0300 <p>На международной конференции по клиентскому сервису от CCGuru «Передовой опыт контактных центров — Excellence in Customer Contacts — 2026» эксперты BSS на кейсах показали, как устранить разрыв между данными и действиями, избежать бесконечных пилотов и сократить путь от проблемы до действия до одного дня. Компания также продемонстрировала ИИ-инструменты для управления клиентским опытом в действии.</p> <p>XVI конференции «Передовой опыт контактных центров — Excellence in Customer Contacts — 2026» собрала представителей крупнейших ИТ-компаний и руководителей контакт-центров из финансового сектора, телекома, розницы, логистики, государственного сектора и других отраслей. </p> <p>Компания BSS представила на мероприятии <nobr>CX-платформу</nobr> для управления клиентским опытом и выступила с экспертизой: эксперты поделились кейсами и организовали круглый стол для обсуждения актуальных вызовов отрасли.</p> <p>О главной дилемме клиентского обслуживания рассказал руководитель направления по развитию ИИ-продуктов компании BSS Михаил Воронин: «Большинство организаций умеют собирать данные о клиентах. Немногие умеют превращать эти данные в согласованные действия сотрудников и всей организации».</p> <p><nobr>CX-платформа</nobr> объединяет данные, аналитику и управленческие решения в единой среде — работа строится в несколько этапов:</p> <ol> <li>сбор сигналов клиентов: платформа фиксирует все, что происходит с клиентом или сотрудниками — темы обращений, поведенческие паттерны, отклонения KPI. То есть отвечает на вопрос: что происходит сейчас?</li> <li>ИИ-анализ: интеллектуальный модуль выявляет аномалии, определяет вероятные причины проблем и потребности клиентов. Появляется ответ на вопрос: что это значит для бизнеса и клиента?</li> <li>рекомендации: по результатам анализа система предлагает Next Best Action, которое может быть направлено и на развитие отношений с клиентом (например, персональные предложения), и на усиление сотрудника (например, подсказки или тренинги), и на развитие бизнеса (например, сигнал о необходимости автоматизировать процесс). Это уже ответ на вопрос: что делать?</li> <li>выполнение рекомендаций: например, если ИИ определил, что основной предиктор оттока — проблемы с информированием о статусе заказа, то предложенным решением может быть автоматизация через ИИ-агентов, которые будут самостоятельно проверять статусы заказов и отвечать клиенту. После внедрения изменений компания может оперативно оценить их результативность благодаря ИИ-модулю. Так можно быстро узнать: решена ли проблема?</li> </ol> <p>Как запускать пилотные проекты так, чтобы они переходили в промышленную эксплуатацию, рассказала ведущий аналитик по контактным центрам департамента голосовых технологий компании BSS Дарья Громова.</p> <p>Проблема традиционных пилотов в том, что они демонстрируют возможности инструмента, но не отвечают на главный вопрос бизнеса: какой результат он принесет компании. В них не тестируют показатели, на базе которых считают ROI — в итоге заказчику сложно принять решение о масштабировании, а внедрение откладывается на неопределенный срок.</p> <p>«Альтернатива — пилот с фиксированным KPI, где главным критерием успеха становится конкретный бизнес-показатель, который должна улучшить система. Например, в пилоте речевой аналитики с МТБ была поставлена цель за три месяца снизить AHT на 3%. В результате показатель удалось сократить на 8%», — рассказала Дарья Громова.</p> <p>Как ИИ-модуль в речевой аналитике позволяет бизнесу адаптироваться к постоянным изменениям рынка и проверять гипотезы за нескольких дней рассказала владелец продукта «Речевая аналитика» компании BSS Анна Ивлева.</p> <p>До недавних пор на проверку гипотез уходили недели: нужно было собрать данные, подготовить отчет, провести обсуждение и только потом запускать проект. Сегодня важным показателем зрелости компании становится скорость верификации идей — то, насколько быстро она может превратить вопрос в действие и оценить результат.</p> <p>Благодаря ИИ цикл проверки гипотез может выглядеть так:</p> <ul> <li>1 час — собрать и проанализировать данные;</li> <li>4 часа — выявить причины проблемы;</li> <li>8 часов — принять решение;</li> <li><nobr>1–3</nobr> дня — проверить эффект изменений.</li> </ul> <p>Анна Ивлева привела пример из практики BSS: «После того, как мы выявили низкий CSI в одной службе доставки, ИИ-агенты нашли паттерны в клиентских диалогах и определили основные причины недовольства: отсутствие связи с курьером, неясные формулировки на сайте и недостаток вариантов доставки. На их основе они тут же предложили рекомендации: предоставить клиентам выбор временного интервала доставки, упростить тексты на сайте и запустить программу лояльности. В результате CSI вырос с 5,7 до 6,5 всего за две недели».</p> <p>Во второй день ИИ-эксперты BSS провели круглый стол «От концепции к действиям: как CX‑платформа меняет управление контактным центром здесь и сейчас», где вместе с коллегами из контакт-центров обсудили ожидания клиентов, новые KPI и главное — как сделать так, чтобы ценные инсайты не терялись по пути к тем, кто принимает решения.</p> <p>Компания BSS благодарит всех, кто пришел на выступления, участвовал в дискуссиях, подходил знакомиться с <nobr>CX-платформой</nobr> и входящими в нее решениями, делился опытом, задачами и взглядом на развитие клиентского сервиса. Только вместе можно сделать CX умнее, технологичнее и эффективнее!</p> На международной конференции по клиентскому сервису от CCGuru «Передовой опыт контактных центров — Excellence … message https://www.itweek.ru/themes/detail.php?ID=235096 Wed, 01 Jul 2026 12:45:14 +0300 <p>Polywell Computers представила UC300L2V4M3 — высокопроизводительный мини-ПК на платформе Intel Core Ultra Series 3 (Panther Lake). Система предназначена для периферийных ИИ-вычислений, многоэкранной визуализации, систем мониторинга и управления, интерактивных терминалов, инженерных рабочих мест и специализированных коммерческих приложений, которым требуются высокая вычислительная производительность, быстрое локальное хранилище, гибкие сетевые возможности и широкий набор интерфейсов в компактном корпусе.</p> <p>UC300L2V4M3 поддерживает широкий выбор процессоров Intel Core Ultra Series 3: от энергоэффективных Core Ultra 5 до высокопроизводительных Core Ultra X9. В зависимости от выбранного процессора система может оснащаться графикой Intel Arc B390/B370 либо Intel Graphics, что позволяет подобрать оптимальное соотношение вычислительной мощности, графической производительности и стоимости.</p> <p>Благодаря поддержке до четырёх дисплеев через HDMI 2.1, DisplayPort 1.4 и два порта Thunderbolt 4, UC300L2V4M3 хорошо подходит для инсталляций, которым нужны несколько экранов высокого разрешения, высокоскоростное подключение периферии и удобная установка в условиях ограниченного пространства.</p> <p>UC300L2V4M3 расширяет ассортимент мини-ПК Polywell системой, рассчитанной на современные задачи периферийных вычислений, мультимедиа и визуализации:</p> <ul> <li>процессоры Intel Core Ultra Series 3 на платформе Panther Lake;</li> <li>графика Intel Arc B390/B370 в отдельных конфигурациях;</li> <li>Intel Graphics в других вариантах процессоров;</li> <li>до 64 Гб памяти LPDDR5X-8533;</li> <li>поддержка до четырёх дисплеев;</li> <li>HDMI 2.1 и DisplayPort 1.4 с поддержкой разрешения до 8K при 60 Гц;</li> <li>Два порта Thunderbolt 4: передача данных до 40 Гбит/с, DisplayPort Alt Mode и выход Power Delivery до 15 Вт;</li> <li>три слота M.2 2280 для NVMe SSD: один PCIe 5.0×4 и два PCIe 4.0×4;</li> <li>стандартная конфигурация с двумя портами 2.5GbE LAN;</li> <li>опциональная конфигурация с одним портом 2.5GbE и одним портом 10GbE;</li> <li>слот M.2 Key-E 2230 для опционального модуля Wi-Fi 6E / Wi-Fi 7 и Bluetooth;</li> <li>опциональное расширение OCuLink;</li> <li>поддержка крепления VESA и настенного монтажа;</li> <li>компактный корпус размером 205 × 192 × 70 мм;</li> <li>создан для продвинутых проектов визуализации и периферийных вычислений.</li> </ul> <p>UC300L2V4M3 ориентирован на заказчиков, которым недостаточно обычного офисного мини-ПК. Сочетание процессоров Core Ultra, современной интегрированной графики, поддержки нескольких экранов, Thunderbolt 4, высокоскоростного NVMe-хранилища и опциональной сети 10GbE делает систему подходящей для проектов, где важны функциональная насыщенность и широкий набор интерфейсов.</p> <p>Для визуальных задач система может использовать до четырёх дисплеев через HDMI, DisplayPort и Thunderbolt 4. Это делает её хорошим выбором для цифровой рекламы, интерактивных экранов, рабочих мест мониторинга, видеостен, систем отображения показателей и коммерческих визуальных решений.</p> <p>Архитектура хранения также даёт интеграторам возможность создавать более производительные локальные системы. Один слот M.2 PCIe 5.0×4 и два слота M.2 PCIe 4.0×4 позволяют использовать быстрые накопители для медиаконтента, ИИ-моделей, локального сбора данных, аналитики и одновременной работы нескольких приложений.</p> <p>Для сетевых приложений стандартная конфигурация предлагает два порта 2.5GbE LAN. В проектах, где требуется более высокая пропускная способность проводной сети, доступна опция с одним портом 2.5GbE и одним портом 10GbE. Поддержка Wi-Fi 6E или Wi-Fi 7 доступна опционально и даёт дополнительную гибкость там, где прокладка кабеля затруднена или нежелательна.</p> <p>Фактическое число одновременно подключённых дисплеев и их максимальное разрешение зависят от выбранного процессора, конфигурации дисплеев, операционной системы и графического драйвера.</p> <p>UC300L2V4M3 — удачный выбор для заказчиков, которым нужны компактные системы с высокой производительностью, несколькими дисплеями, быстрым хранилищем и гибким набором интерфейсов:</p> <ul> <li>сстемы цифровой рекламы и мультимедийного воспроизведения с несколькими дисплеями;</li> <li>интерактивные киоски и терминалы самообслуживания;</li> <li>периферийные ИИ- и AIoT-приложения;</li> <li>коммерческие решения для визуализации и отображения данных;</li> <li>системы мониторинга, информационные панели и диспетчерские;</li> <li>видеостены и сети распространения информации;</li> <li>интеллектуальная розничная торговля, гостиничный бизнес, образование и корпоративная среда;</li> <li>сетевые коммерческие устройства;</li> <li>платформы для разработки, интеграции и демонстрации;</li> <li>высокопроизводительные компактные настольные системы.</li> </ul> Polywell Computers представила UC300L2V4M3 — высокопроизводительный мини-ПК на платформе Intel Core Ultra Series 3 … message https://www.itweek.ru/themes/detail.php?ID=235094 Wed, 01 Jul 2026 12:39:46 +0300 <p>Postgres Professional представила Postgres Pro Enterprise 18.4.1 — обновление флагманской коммерческой СУБД на базе PostgreSQL. Новый релиз расширяет возможности горизонтального масштабирования читающей нагрузки, развивает встроенные механизмы отказоустойчивости и добавляет инструменты для контроля целостности данных и администрирования.</p> <p>Postgres Pro Enterprise предназначена для крупных корпоративных систем, где важны высокая производительность, отказоустойчивость, безопасность и предсказуемая эксплуатация.</p> <p>«В Postgres Pro Enterprise 18.4.1 мы сделали акцент на задачах, которые сейчас особенно актуальны для крупных инфраструктур: более эффективном использовании серверного оборудования и обеспечении надёжности, включая геораспределённую катастрофоустойчивость. Работа с временными объектами на standby-серверах и новая функциональность Proxima позволяют активнее использовать резервные узлы, а новые возможности BiHA и инструменты администрирования делают эксплуатацию сложных систем более гибкой и устойчивой», — отметил Василий Чепцов, Директор департамента разработки продуктов.</p> <p>Ключевым изменением версии 18.4.1 стала возможность полноценной работы с временными объектами на резервных серверах. Теперь на репликах поддерживаются операции чтения и записи для временных таблиц, последовательностей и представлений, а также создание и вызов временных функций. Это позволяет расширять сценарии горизонтального масштабирования без создания отдельных копий баз данных, например, для генерации сложных отчётов на standby-серверах, в том числе, для систем 1С.</p> <p>Развитие получило расширение Proxima, объединяющее функциональность прокси-сервера, балансировщика нагрузки и пула соединений:</p> <ul> <li>добавлены адаптивные алгоритмы распределения запросов к репликам с учётом потребления памяти и интенсивности дискового ввода-вывода;</li> <li>реализована возможность размещения Proxima на лёгковесном узле‑рефери кластера BiHA.</li> </ul> <p>В расширении BiHA (Built-in High Availability), для построения геораспределенных кластеров реализован новый механизм многоуровневой катастрофоустойчивости, позволяющий объединить узлы в логические сегменты, которые можно расположить в разных ЦОДах. Между сегментами используется каскадная репликация с автоматическим перестроением репликации в случае сбоя любого из узлов.</p> <p>В версию 18.4.1 вошло расширение pgpro_iheap для ускорения последовательного сканирования таблиц, а модуль автоматического подбора планов AQO обновлён до версии 4.1: оптимизирована внутренняя структура хранилища данных и улучшены механизмы выделения разделяемой памяти, что снижает вероятность блокировок в высоконагруженных сессиях.</p> <p>Также получило существенное развитие расширение pgpro_gbtree для работы с глобальными индексами на секционированных таблицах. Теперь поддерживаются совместимость глобальных уникальных индексов с конструкцией ON CONFLICT, создание глобального индекса по столбцу, входящему в состав первичного ключа, операции создания и перестроения индексов с параметром CONCURRENTLY, возможность использовать автоочистку (AUTOVACUUM) для глобальных индексов, указывать ссылки из дочерних таблиц на глобальный индекс при помощи внешнего ключа и добавлены настройки планировщика, управляющие использованием глобальных индексов.</p> <p>Также оптимизирована работа с системными ресурсами на секционированных таблицах: реализовано кеширование дескрипторов файлов для каталогов в директории PGDATA, что снижает нагрузку на процессор при планировании SQL-запросов. </p> <p>В состав Postgres Pro Enterprise 18.4.1 вошли новые инструменты для администраторов: pgpro_logical_slot для управления слотами логической репликации, pgpro_temp_stats для сбора статистики по временным таблицам и pgpro_validate для проверки физической и логической целостности данных экземпляра СУБД.</p> <p>Postgres Pro Enterprise 18.4.1 уже доступна пользователям. Подробные инструкции по установке обновления и миграции данных представлены в официальной документации к выпуску.</p> Postgres Professional представила Postgres Pro Enterprise 18.4.1 — обновление флагманской коммерческой СУБД … message https://www.itweek.ru/themes/detail.php?ID=235093 Wed, 01 Jul 2026 12:37:51 +0300 <p>DатаРу представила новое поколение корпоративных СХД. Обновленная линейка включает три продукта: «ДатаРу ПС1500», «ДатаРу ПС5500» и «ДатаРу ПС9500». В серии «Элит» усовершенствована архитектура СХД: используются современные низкопрофильные твердотельные накопители форм-фактора E3, а также средства интеллектуального управления. Предусмотрен плановый рост производительности систем в три этапа до 2036 года.</p> <p>Новое поколение СХД от DатаРу отличается высокой плотностью хранения, масштабируемостью и возможностью модернизации систем без остановки сервисов и миграции данных. Для этого полностью пересмотрена архитектура СХД. </p> <p>Системы «ДатаРу ПС1500», «ДатаРу ПС5500» и «ДатаРу ПС9500» построены на процессорах Intel с аппаратным ускорением QuickAssist Technology. Сетевой периметр выполнен по стандарту OCP 3.0 с возможностью замены модулей прямо во время работы системы, без отключения питания и использования инструментов. </p> <p>СХД поддерживают высокоскоростную технологию передачи данных Fibre Channel до 64 Гбит/с с возможностью расширения до 128 Гбит/с. Также СХД поддерживает Ethernet-подключения со скоростью портов 10/25/100 Гбит/с в зависимости от конфигурации и с резервом для роста до 200/400 Гбит/с.</p> <p>Одно из ключевых изменений в сравнении с предыдущим поколением СХД — переход на низкопрофильные твердотельные накопители форм-фактора E3. Использование современных SSD позволило увеличить плотность хранения в два раза и размещать до 40 накопителей в 3U. </p> <p>Предусмотрено до 40 портов на одно устройство — в среднем на 60% больше, чем у аналогов на рынке. Это дает значительный запас для роста трафика. При этом в архитектуре не используются выделенные служебные модули NVRAM — все слоты задействованы под накопители с данными. Эффективная емкость каждого устройства с учетом технологий экономии пространства достигает 5,8 петабайт. </p> <p>Кроме того, производитель берет на себя гарантию коэффициента сжатия данных 6:1. То есть на каждый 1 ТБ физически занятого пространства система в среднем может разместить около 6 ТБ пользовательских данных за счет механизмов сжатия и дедупликации. Такой подход, как рассчитывает вендор, позволит заказчикам точнее планировать развитие инфраструктуры и сократить избыточные затраты на расширение хранилищ.</p> <p>Отдельное внимание в новой линейке уделено автоматизации. Среди доступных возможностей — автоматическое развертывание NVMe/TCP через SmartFabric, проактивное выделение ресурсов и встроенные механизмы защиты от киберугроз. Опционально доступен модуль Cyber Detect на базе AI и аналитики, который проверяет целостность данных и помогает быстрее восстановиться после атаки. Все это заметно сокращает трудозатраты ИТ-отдела на администрирование СХД и повышает надежность хранения.</p> <p>Для защиты инвестиций заказчиков предусмотрена программа Lifecycle Extension. Она предполагает обновление вычислительной части без замены корпуса и дисковой подсистемы. Обновление контроллеров может выполняться без остановки сервисов или необходимости переноса данных на другое хранилище. В компании подчеркивают, что платформа рассчитана на три плановых повышения производительности до 2036 г.</p> <p>Упрощен и переход с ранее установленных решений. Для заказчиков, использующих СХД DатаРу предыдущих поколений, предусмотрено автоматическое добавление новой системы в кластер без перенастройки хостов. Также заявлена возможность объединения массивов Gen 1, Gen 2 и Gen 3 в единой среде с перераспределением текущих нагрузок между узлами. Ранее внедренные системы могут использоваться в качестве узлов репликации или дополнительных хранилищ. При этом все три поколения СХД работают под управлением единой программной платформы DатаРу, что должно упростить администрирование и перенос нагрузок между устройствами</p> <p>«При выпуске нового поколения СХД мы ставили перед собой задачу переосмыслить экономику хранения данных для российского бизнеса. Для нас было важно, чтобы заказчик получал современную с технологической точки зрения систему и одновременно — понятную модель развития инфраструктуры. Поэтому мы сосредоточились на повышении производительности СХД, более эффективном управлении нагрузками и возможности поэтапной модернизации без остановки критически важных сервисов», — прокомментировал Роман Гоц, генеральный директор ГК DатаРу. </p> DатаРу представила новое поколение корпоративных СХД. Обновленная линейка включает три продукта: «ДатаРу ПС1500», «ДатаРу ПС5500» … message https://www.itweek.ru/themes/detail.php?ID=235091 Wed, 01 Jul 2026 12:33:45 +0300 <p>Российский разработчик ПО СберТех объявил о выводе на рынок векторной системы управления базами данных (СУБД) Platform V Vector DB. Решение ориентировано на промышленное применение в корпоративных сценариях искусственного интеллекта. Оно дает возможность бизнесу работать с векторными представлениями информации и на их основе запускать надежные прикладные сервисы: семантический поиск и интеллектуальных помощников. Новая СУБД поможет компаниям обрабатывать сложные клиентские запросы, оптимизировать нагрузку на сотрудников и повышать эффективность бизнес-процессов.</p> <p>Platform V Vector DB создана для крупных предприятий, которым необходимо управлять большими объемами данных. Решение подходит финансовым, телекоммуникационным, логистическим организациям, ритейлерам и государственным структурам, где важны производительность и эксплуатационная зрелость программных продуктов. СУБД располагает инструментами для контроля безопасности и работоспособности, упрощенной интеграции в корпоративную инфраструктуру и предсказуемого сопровождения.</p> <p>Максим Тятюшев, генеральный директор СберТеха, отметил: «Мы разработали векторную СУБД, сочетающую в себе функциональность, надежность и управляемость, с фокусом на эксплуатации в высоконагруженных системах. Platform V Vector DB позволит бизнесу эффективно внедрять семантический поиск и ИИ-агентов для различных корпоративных сценариев: точного поиска по документам и базам знаний, быстрого реагирования на инциденты, детальной проработки клиентских обращений. Это поможет компаниям снизить эксплуатационные и инфраструктурные риски, усилить контроль безопасности, а также сократить путь от пилотного проекта до полноценного внедрения».</p> <p>Platform V Vector DB поставляется отдельным дистрибутивом для установки на серверах клиента, что актуально для компаний с высокими требованиями к безопасности и проверяемости программного обеспечения. Ранее Сбер представил руководство по AI-трансформации разработки и бизнеса в новой технологической реальности. Оно поможет переформатировать работу компаний в парадигме, где ИИ является базой, а не надстройкой.</p> Российский разработчик ПО СберТех объявил о выводе на рынок векторной системы управления базами данных (СУБД … message https://www.itweek.ru/themes/detail.php?ID=235090 Wed, 01 Jul 2026 10:18:20 +0300 <p><em>Исследование </em><em>GitLab</em><em> «</em><em>The</em> <em>2026 </em><em>AI</em> <em>Accountability</em> <em>Report</em><em>» показывает, почему для ускорения разработки ПО с использованием искусственного интеллекта необходим контроль инфраструктуры и надежное управление для смягчения растущего технического долга, пишет на портале </em><em>The</em> <em>New</em> <em>Stack</em> <em>Манав Хурана, директор по продуктам и маркетингу компании GitLab.</em></p> <p>В течение последних двух лет в дискуссиях о разработке ПО с использованием ИИ доминировала скорость. Новый опрос GitLab, проведенный среди 1528 разработчиков и технологических лидеров, показал, что у 60% респондентов рентабельность инвестиций в ИИ-кодирование уже превзошла ожидания, а 78% сообщают, что их команды пишут и фиксируют код быстрее после внедрения инструментов ИИ.</p> <p>Но скорость без контроля — это проблема.</p> <p>Большинство организаций внедряют агентную инженерию, добавляя инструменты ИИ-кодирования поверх своей существующей инфраструктуры. Агенты кодирования обеспечивают скорость, но эта скорость не распространяется на весь жизненный цикл ПО: только 21% респондентов сообщают о повышении производительности за пределами самой генерации кода.</p> <p>Проблема инфраструктуры гораздо глубже. Бэкенды, наборы инструментов и системы управления Git были созданы для параллельной обработки данных в масштабах, сопоставимых с человеческими. Агенты же работают в масштабах машин, и это несоответствие проявляется быстро. Надежность платформы снижается, когда миллионы агентных сессий обращаются к одному и тому же бэкенду, риски безопасности возрастают, поскольку агенты затрагивают зависимости в больших масштабах, а перерасход средств увеличивается, поскольку агенты неэффективно используют токены на инфраструктуре, которая не была создана для них.</p> <h3>Внедрение агентов опередило управление ими</h3> <p>Кривая внедрения инструментов ИИ-кодирования опередила разработку необходимых мер защиты: 80% организаций заявили, что внедрили инструменты ИИ быстрее, чем разработали политики управления ими, а 82% сообщили, что сгенерированный ИИ код рискует создать новую форму технического долга, с которым их организации не готовы справиться.</p> <p>На практике это означает проблемы с надежностью платформы при агентных нагрузках, риски безопасности и соответствия нормативным требованиям, которые возрастают, поскольку агенты в больших объемах затрагивают зависимости, и работу агентов с искусственной уверенностью из-за отсутствия полного контекста. Только 28% организаций заявили, что их инструменты управления жизненным циклом разработки ПО полностью интегрированы с общими данными и рабочими процессами, а это значит, что большинство команд пытаются управлять действиями агентов с помощью цепочек инструментов, которые никогда не были для них предназначены.</p> <h3>Для агентной инженерии необходима агентная инфраструктура</h3> <p>Агентная инженерия требует двух вещей: агентного кодирования и агентной инфраструктуры. У большинства организаций есть первое, но отсутствует второе.</p> <p>Агентная инфраструктура охватывает четыре области: уровень выполнения, уровень контекста, уровень управления и уровень оркестрации, работающие вместе.</p> <ol> <li><strong> Выполнение в машинном масштабе.</strong> Бэкенды, конвейеры CI/CD и системы развертывания Git были разработаны для разработки в темпе человека. В эпоху агентов они должны обрабатывать миллионы сеансов агентов без сбоев. Когда происходит инцидент в производственной среде, путь от симптома до источника должен занимать минуты, а не дни.</li> <li><strong> Контекст, который передается вместе с кодом.</strong> «Эффективность агента зависит от контекста и семантики, которые ему предоставляются», — отметил Бастиан Стамер, руководитель подразделения разработки ПО для автомобилей в Mercedes-Benz, на одной из недавних панельных дискуссий. Граф контекста, связывающий код, рабочие элементы, конвейеры, результаты проверки безопасности и производственные сигналы, делает агентов действительно полезными в масштабе и позволяет держать искусственную уверенность под контролем.</li> <li><strong> Управление, встроенное в поток.</strong> Действия агента должны быть привязаны к идентификатору, регистрироваться в соответствии с политикой и быть доказуемыми для проверяющего. Изменения с низким риском выполняются быстро, в то время как изменения с более высоким риском инициируют проверку. Наример, для Mercedes, работающей в соответствии с автомобильными нормативными стандартами, требующими полной отслеживаемости и ответственности человека, необходима плоскость управления, где эта ответственность и находится.</li> <li><strong> Оркестрация.</strong> Эффективность выполнения, контекста и управления зависит от системы, которая их координирует. Уровень оркестрации координирует действия агентов на протяжении всего жизненного цикла ПО в соответствии с политиками, установленными командами, определяя, какие агенты и в каком порядке запускаются и как обрабатываются сбои и передачи задач. Без него агентная инфраструктура представляет собой набор независимых возможностей, а не работающую систему.</li> </ol> <h3>Что дальше?</h3> <p>Согласно мнению 85% респондентов, следующий этап развития ИИ в разработке ПО будет меньше фокусироваться на генерации кода и больше на его управлении. Этот сдвиг отражает то, как предприятия совершенствуют свое мышление об ИИ, превращая его из инструмента повышения производительности в базовую возможность, которой необходимо доверять, отслеживать и поддерживать в масштабе.</p> <p>Когда управление встроено в платформу, скорость и контроль больше не находятся в противоречии. Отслеживаемость становится конкурентным преимуществом. Контекст становится институциональной памятью. А кодовая база, вместо того чтобы накапливать невидимый риск, становится активом, который со временем становится более надежным.</p> Исследование GitLab «The 2026 AI Accountability Report» показывает, почему для ускорения разработки ПО … article https://www.itweek.ru/themes/detail.php?ID=235089 Wed, 01 Jul 2026 10:16:33 +0300 <p><em>Нечеткие идентификаторы тормозят работу агентов искусственного интеллекта на этапах проверки безопасности. Джексон Коннелл, старший менеджер по маркетингу продуктов IBM, рассказывает на портале </em><em>The</em> <em>New</em> <em>Stack</em> <em>о четырех решениях, которые необходимо принять для обеспечения безопасности агентных систем на уровне платформы.</em></p> <p>Многие агентные проекты могут успешно пройти этап разработки. Затем они попадают на этап проверки безопасности — и именно здесь все может остановиться. Нечеткие модели идентификации и слишком широкие разрешения быстро становятся препятствием.</p> <p>Вы, вероятно, видели это: агент службы поддержки клиентов работает хорошо; он обрабатывает заявки и возвраты средств, обеспечивает без сбоев весь рабочий процесс. Затем служба безопасности задает простой вопрос: под чьим идентификатором это работает? Ответ останавливает процесс: это общая учетная запись с широкими разрешениями, без четкого владельца, без журнала аудита и без контроля минимальных привилегий.</p> <p>Коренная проблема несложная. Это неопределенная идентификация и плохо определенные разрешения. И эта проблема быстро усугубляется. <a href="https://www-api.ibm.com/adobe/assets/urn:aaid:aem:65c0601b-d998-408d-bb69-4dfb31ff4642/original/as/2026-tech-leader-study-redefining-the-tech-leader-s-mandate-report.pdf">Исследование</a> «Tech Leader Study 2026», проведенное Oxford Economics и IBM, показывает, что опрошенные предприятия планируют развернуть в среднем 1661 ИИ-агента, что на 38% больше, чем сегодня. Каждый новый агент добавляет еще одну идентификацию, которую необходимо защитить, и без четких ограничений проблема быстро усугубляется.</p> <p>В результате многие агентные системы фокусируются на том, что агенты могут делать, не определяя, что они должны делать и под чьим руководством. Агенты также не обладают фиксированным набором разрешений. Они запрашивают доступ, вызывают новые инструменты и принимают на себя роли в процессе работы, поэтому пути доступа усложняются способами, которые никто явно не предоставлял и не проверял. Без проверяемой идентификации отсутствует подотчетность, что затрудняет обеспечение минимальных привилегий, отслеживаемость и реагирование на инциденты.</p> <p>Для решения этих проблем разработчики, архитекторы и DevOps-инженеры, создающих агентные системы, а также ИТ-руководители, ответственные за их утверждение, могут воспользоваться следующим руководством.</p> <h3>Четыре решения по идентификации, которые требуются каждой агентной системе</h3> <p>Решения по идентификации нельзя рассматривать как второстепенный вопрос. Идентификация определяет, как агенты проходят аутентификацию, к чему они имеют доступ и как их действия контролируются и проверяются с течением времени. Если допустить ошибку на раннем этапе, вы будете строить на шатком фундаменте.</p> <p>Вот четыре наиболее важных выбора, которые необходимо сделать:</p> <p><strong>Идентификация рабочей нагрузки </strong><strong>vs</strong><strong>. общие учетные записи служб.</strong> Общие учетные записи служб просты в использовании, и именно это делает их опасными. Когда несколько агентов действуют под одной учетной записью, становится трудно определить, что произошло и что пошло не так после этого. Если учетная запись будет скомпрометирована или использована не по назначению, все, чего она касалась, будет раскрыто.</p> <p>Идентификация рабочей нагрузки назначает каждому агенту свою собственную идентификацию. Разрешения остаются ограниченными, а действия можно атрибутивировать. Это требует большей настройки, но создает изоляцию и возможность аудита.</p> <p><strong>Статические ключи API </strong><strong>vs</strong><strong>. краткосрочные учетные данные. </strong>Статические ключи API, как правило, остаются навсегда. Они жестко закодированы в приложениях, передаются между системами и редко меняются — это делает их постоянной уязвимостью, ожидающей эксплуатации.</p> <p>Краткосрочные учетные данные работают иначе. Они выдаются по запросу, привязаны к конкретной задаче и автоматически истекают. На практике это часто основано на федерации идентификации (например, с использованием токенов OIDC) в сочетании с системами, которые могут выдавать динамические учетные данные во время выполнения, а не хранить долговременные секреты в коде или конфигурации.</p> <p><strong>Прямая передача учетных данных </strong><strong>vs</strong><strong>. доступ через брокера. </strong>Передача учетных данных непосредственно агенту проста. Она также непрозрачна. У вас нет естественной точки для оценки политики или понимания того, что происходит в реальном времени.</p> <p>Доступ через брокера вводит в поток контрольную точку. Запросы проходят через брокера, политики оцениваются в реальном времени, и для каждой сессии выдаются временные учетные данные. Это добавляет инфраструктуру, но восстанавливает прозрачность и обеспечение соблюдения политик.</p> <p><strong>Фрагментированное логирование </strong><strong>vs</strong><strong>. полная история идентификации.</strong> Большинство систем регистрируют то, что произошло. Гораздо меньше систем фиксируют, кто инициировал действие или как оно распространялось по цепочке агентов и служб.</p> <p>Полная история идентификации связывает каждый шаг. Вы можете отслеживать операцию от триггеров до результатов, что может ускорить отладку и обеспечить более надежное реагирование на инциденты. Однако загвоздка в том, что это требует последовательного распространения идентификационных данных и структурированного логирования с самого начала — это сложно внедрить позже.</p> <h3>Когда компромиссы становятся реальными рисками</h3> <p>Это не абстрактные архитектурные предпочтения. Они проявляются как конкретные уязвимости.</p> <p>Nightfall AI сообщает, что организации ежегодно раскрывают почти 350 секретов на 100 сотрудников, при этом 35% раскрытых ключей API все еще активны. В сочетании с постоянными учетными данными и общими идентификаторами потенциальный радиус атаки быстро растет.</p> <p>Закономерность остается неизменной: общие учетные записи и долгосрочные ключи быстрее создавать, но их сложнее защитить. Идентификация рабочей нагрузки и краткосрочные учетные данные требуют бóльших первоначальных инвестиций, но могут обеспечить бóльшую безопасность в долгосрочной перспективе.</p> <h3>Отладка нарушений на интуитивном уровне</h3> <p>Рассмотрим ситуацию, когда агент, работающий под общей учетной записью с долгосрочным ключом, внезапно резко увеличивает доступ к данным. Это ошибка? Нарушение? Обычное поведение? Сложно сказать. Отзыв ключа может решить проблему, но при этом может нарушить работу полудюжины несвязанных рабочих процессов. Так вы отлаживаете на интуитивном уровне.</p> <p>Быстрые пути уменьшают трение на начальном этапе и накапливают риски со временем.</p> <h3>Стандартизация идентификации на уровне платформы</h3> <p>Решение не в том, чтобы заново создавать аутентификацию, авторизацию и аудит для каждого выпускаемого агента. Это не масштабируемо.</p> <p>Вместо этого стандартизируйте идентификацию на уровне платформы — с помощью централизованных поставщиков идентификационных данных, механизмов управления политиками и брокера учетных данных, чтобы обеспечить безопасные настройки по умолчанию и упростить соблюдение нормативных требований, избавив от необходимости постоянно вести переговоры.</p> <p>Агентный ИИ работоспособен в производственной среде, если идентификация проектируется заранее и обеспечивается во время выполнения, а не предполагается на основе предыдущего входа в систему. Когда проекты рассматриваются как второстепенные, они застопориваются. Агенты могут действовать с тем уровнем контроля, который требуется в производственной среде, если это заложено намеренно.</p> Нечеткие идентификаторы тормозят работу агентов искусственного интеллекта на этапах проверки безопасности. Джексон Коннелл … article https://www.itweek.ru/themes/detail.php?ID=235088 Tue, 30 Jun 2026 16:06:10 +0300 <p>НКК Машиностроение объявляет о выходе релиза ПО САРУС+ 2026.2. Ключевое обновление помогает пользователям осуществлять плавный переход из систем зарубежных разработчиков в российский PLM-продукт. Для этого создан механизм совместной работы в САРУС+ CAD и Siemens NX, который дает возможность открывать и проводить изменения в электронном макете изделия. Бесшовная интеграция между PLM-системой и САРУС+ CAD выстроена как единое целое, пользователь не должен заботиться о том, где он начал работать и как будут синхронизированы данные: САРУС+ отследит изменения, где бы они не возникли, и, автоматически, без дополнительных действий пользователя, синхронизирует информацию между PLM и CAD.</p> <p>Главные возможности релиза:</p> <ul> <li>бесшовная двунаправленная интеграция PLM — CAD и совместная одновременная работа в САРУС+ CAD и Siemens NX облегчат переход с иностранных систем в российский продукт;</li> <li>импорт данных из сторонних PLM-систем (иностранных и российских) на основе PLMXML и CSV с сопоставлением типов, атрибутов и отношений позволит перенести «исторические» данные без потерь. Маппинг данных настраивается один раз и может быть использован многократно;</li> <li>управление электронной структурой изделия. Ревизионное конфигурирование на основе правил (с визуализацией геометрического представления изделия) и по применяемости (финальное изделие, серийный номер, дата), добавление компонентов с учётом правил вхождений — обеспечат гибкое и ясное определение состава узлов и агрегатов изделия, технологических данных, требований и любых других конфигурируемых структур;</li> <li>визуализация 3D-моделей и 2D-данных в веб-клиенте с измерениями, сечениями, 3D-пометками и кросс-подсветкой решит задачу удобного просмотра 2D- и 3D-документации;</li> <li>управление изменениями. Полная взаимосвязь извещений об изменении с изменяемыми и заменяемыми объектами, работа с применяемостью по датам или по изделиям, а также автоматический пересчёт планируемой применяемости — гарантируют полный контроль над изменениями;</li> <li>быстрое получение информации о связях. Навигатор связей поможет проследить прямые и обратные взаимосвязи между объектами, отфильтровать и выделить нужные, а также позволит редактировать эти данные прямо в дереве графа;</li> <li>инструменты для управления и расширения модели данных, а также визуального проектирования интерфейса САРУС+ обеспечат пользователю возможность удобно работать с разнородными данными в минимальном количестве окон;</li> <li>система как конструктор. Возможность кастомизации интерфейса, простые инструменты для формирования собственного интерфейса системы вплоть до каждого пользователя удовлетворят запрос на собственное удобство и эргономику рабочего пространства;</li> <li>система как платформа. Документированный API для собственной разработки функционала или модификации существующего отроют путь к расширению возможностей системы под потребности предприятия.</li> </ul> НКК Машиностроение объявляет о выходе релиза ПО САРУС+ 2026.2. Ключевое обновление помогает пользователям осуществлять … message https://www.itweek.ru/themes/detail.php?ID=235087 Tue, 30 Jun 2026 13:35:24 +0300 <p>Selectel, крупнейший независимый провайдер IT-инфраструктуры в России, объявил о запуске новой версии собственной серверной операционной системы SelectOS. В новой версии системы на пакетной базе Debian 13 c использованием ядра Linux 6.12.86 улучшен пользовательский опыт, полученный в ходе работы с предыдущими версиями продукта, и учтены требования для сертификации во ФСТЭК. Всё это обеспечивает более высокий уровень поддержки современного оборудования и драйверов.</p> <p>Ключевым преимуществом обновленной SelectOS 2.0 является сочетание актуальной технологической базы и удобной модели эксплуатации. Для команд, работающих в экосистеме Debian и Ubuntu, это позволяет развивать серверную инфраструктуру без сложных миграций на другие семейства дистрибутивов, сохраняя привычные подходы к управлению пакетами, обновлениям и администрированию. Такой подход снижает операционные риски, сокращает затраты на обучение специалистов и упрощает внедрение системы в существующие IТ-процессы. Отдельное внимание в SelectOS 2.0 уделено готовности к AI-нагрузкам: система протестирована на совместимость с драйверами ведущих производителей GPU и может использоваться как основа для инфраструктуры машинного обучения, работы с нейросетевыми моделями и сервисами генеративного AI.</p> <p>Важным аспектом новой версии является внедрение управляемой цепочки поставок: собственные репозитории с GPG-подписью обеспечивают контроль происхождения каждого пакета, а серверный фокус дистрибутива, исключающий лишние десктопные компоненты, существенно сокращает поверхность атаки за счет минимизации потенциально уязвимого кода. Для специалистов по информационной безопасности SelectOS 2.0 предлагает отдельный канал для security-обновлений и гарантирует прозрачность изменений, что критически важно для соблюдения корпоративных ИБ-политик и регуляторных норм. </p> <p>«Для бизнеса операционная система — это не просто технологическая база, а часть критической IТ-инфраструктуры, от которой зависят бесперебойная работа сервисов, информационная безопасность и скорость развития компании. SelectOS 2.0 позволяет обновлять серверный стек без прерывания привычных процессов эксплуатации: команды получают знакомую Debian-среду, вендорскую поддержку, прозрачное происхождение пакетов и управляемый цикл обновлений. Мы создали эту версию с учетом требований корпоративных клиентов, регуляторной среды и задач долгосрочного развития инфраструктуры. Для компаний это надежная российская альтернатива внешним дистрибутивам и технологическая основа, на которую можно опираться в ближайшие годы», — отметил Кирилл Дмитриев, директор департамента системного ПО Selectel.</p> <p>SelectOS доступна для работы в формате ISO для физических серверов и виртуальных машин, в QCOW2 для облачных сред, а также в контейнерных образах, что позволяет компаниям стандартизировать развертывание в различных контурах и упростить процессы аудита и поддержки. Операционная система входит в Реестр российского программного обеспечения и доступна на облачных и выделенных серверах Selectel, обеспечивая работу в полностью контролируемой инфраструктуре с поддержкой на всех уровнях.</p> Selectel, крупнейший независимый провайдер IT-инфраструктуры в России, объявил о запуске новой версии собственной … message https://www.itweek.ru/themes/detail.php?ID=235086 Tue, 30 Jun 2026 13:33:38 +0300 <p>Компания «Райтек ДТГ», разработчик APS-системы RaytecAPS, выпустила новую версию продукта 1.5. Обновление направлено на повышение удобства сотрудников отдела планирования, расширение инструментов анализа рассчитанного плана и контроля обеспеченности заказов.</p> <p>RaytecAPS — система для предприятий с дискретным и гибридным типами производства. Решение позволяет автоматически рассчитывать производственный план с учетом доступности оборудования, доступности материалов, учитывать технологические ограничения, графики ремонтов оборудования, персонал и другие факторы. Программный продукт внесен в реестр российского программного обеспечения и может использоваться как отечественная альтернатива зарубежным APS-решениям, таким, как Opcenter APS и DELMIA Ortems.</p> <p>В версии RaytecAPS 1.5 появились новые механизмы визуального контроля результатов расчета плана, в том числе отображаемых на диаграмме Ганта. Новые инструменты анализа помогают плановикам быстрее и удобнее оценить обеспеченность производственного плана, увидеть опаздывающие операции и ошибки в расписании, которые могли быть вызваны ручными корректировками плана. Для быстрой оценки обеспеченности клиентских заказов и заявок добавлены статусы их обеспечения, а также плановая дата производства. Сведения отображаются непосредственно в списке заявок, в том числе с использованием цветовой подстветки.</p> <p>Расширены функции инструментов контроля и корректировки производственных расписаний. В новой версии реализована цветовая схема для выявления ошибок на диаграмме Ганта и функция автоматического исправления нарушенных технологических последовательностей производства, которые могли появится в результате ручных корректировок плана. Для ручного редактирования плана добавлена возможность снимать с диаграммы часть операций до указанной операции или после нее. Это позволяет более гибко выстраивать планирование, в том числе отталкиваясь от «узкого места» производства. Также расширены возможности анализа причин неразмещения операций на диаграмме Ганта. </p> <p>В RaytecAPS версии 1.5 расширены возможности работы с календарными состояниями оборудования. Теперь длительность операции корректно рассчитывается не только по состояниям «работает» и «поломка», но и с календарными периодами, эффективность которых ниже 100%. Это позволяет построить план с учетом износа оборудования или учесть интервалы выхода на режим, после переналадки или технического обслуживания линии.</p> <p>Для демонстрационных сценариев и самостоятельного старта работы с системой реализована возможность создания заказов на производство с учетом незавершенного производства. Благодаря этому, можно более эффективно проводить моделирование работы в системе RaytecAPS, выполнять расчет потребности к производству при изменении клиентских заказов, спецификаций и фактического выполнения производственных заданий.</p> <p>«Базовая функциональность RaytecAPS уже закрывает ключевые задачи оперативного планирования, поэтому в версии 1.5 мы сосредоточились на повышении удобства работы с планом. Для производственных предприятий важно не просто получить план, а быстро понять, какие заказы обеспечены, где возникают отклонения, какие заказы не размещены и по каким причинам. Новые инструменты визуального контроля, анализа обеспеченности и корректировки диаграммы Ганта помогают плановикам быстрее принимать решения и эффективнее управлять производственным контуром», — прокомментировал Антон Власов, руководитель практики цифровизации производственных предприятий «Райтек ДТГ».</p> <p>В дальнейших планах развития RaytecAPS — повышение удобства работы с системой: расширение модуля проверки нормативно-справочной информации на наличие ошибок, а также развитие инструментов анализа производственного плана — от оперативного на ближайший период, до долгосрочного.</p> Компания «Райтек ДТГ», разработчик APS-системы RaytecAPS, выпустила новую версию продукта 1.5. Обновление направлено … message https://www.itweek.ru/themes/detail.php?ID=235084 Tue, 30 Jun 2026 09:16:49 +0300 <p>Ещё несколько лет назад вход в личный кабинет банка, маркетплейса или оператора связи выглядел предельно просто: ввёл номер телефона, получил СМС с кодом, подтвердил вход. Эта модель была настолько привычной, что о её альтернативах мало кто задумывался.</p> <p>Но в последний год-два российский рынок авторизации начал меняться заметно быстрее, чем раньше. И дело не только в безопасности — у СМС как у технологии появились вполне конкретные деньги и инфраструктурные проблемы, которые бизнес уже не может игнорировать.</p> <h3>СМС подорожали и стали менее предсказуемыми</h3> <p>Раньше стоимость одного СМС-кода была для бизнеса почти незаметной строчкой расходов. Сейчас всё иначе: по оценкам участников рынка, с 2022 года стоимость СМС-сообщений в России выросла более чем в два раза, а операторы всё активнее переводят клиентов с фиксированной оплаты на пакетные тарифы по объёму трафика. Для сервиса, который отправляет миллионы кодов подтверждения в месяц — а это типичная ситуация для банков, маркетплейсов и доставки — даже небольшое удорожание одного сообщения превращается в заметную статью бюджета.</p> <p>Есть и вторая проблема — техническая. С августа 2025 года в России заработали нормы, позволяющие абонентам отказаться от массовых рассылок и звонков от компаний. Идея понятная — защитить людей от спама и мошенников. Но на практике операторы связи, выполняя требования закона, начали фильтровать вообще весь автоматический трафик от организаций для тех, кто подал такой отказ — включая коды подтверждения для входа и подтверждения операций. Получается, что пользователь, который хотел избавиться от рекламных СМС, неожиданно для себя перестаёт получать и коды от своего банка. Для бизнеса это значит, что доставка одноразового пароля стала менее предсказуемой: код может прийти с задержкой, а может не прийти вообще.</p> <h3>Банки сами просят отказаться от обязательной привязки к СМС</h3> <p>Показательная история произошла вокруг законопроекта «Антифрод 2.0», который должен был обязать подтверждать онлайн-операции одновременно через СМС и государственный мессенджер Max. Банковское сообщество в лице Национального совета финансового рынка выступило против этой нормы. Аргумент был довольно прямым: завязка на один канал создаёт «единую точку отказа» для всей системы онлайн-операций, а сама мера не особо повышает защиту, потому что современное мошенничество чаще строится на социальной инженерии, а не на нехватке способов подтверждения. Банки предложили альтернативу — пуш-уведомления, одноразовые TOTP-коды и биометрию, назвав их более надёжными способами подтверждения, чем СМС.</p> <p>Это важный сигнал: о ненадёжности СМС как канала подтверждения сегодня говорят не теоретики кибербезопасности, а крупные финансовые организации, для которых технология должна защищать деньги клиентов. СМС-код можно перехватить через подмену сим-карты или социальную инженерию, тогда как пуш-уведомление привязано к конкретному устройству — украсть его сложнее.</p> <p>Поэтому крупные банки уже на практике предлагают клиентам бесплатные пуш-уведомления вместо платных СМС-информирований. И эта замена работает не только для уведомлений об операциях по карте, но всё чаще и для самой авторизации.</p> <h3>Что стоит за безопасным входом по биометрии</h3> <p>Когда сервис предлагает войти по отпечатку пальца или лицу без пароля и СМС, обычно за этим стоит стандарт ВебАус (Webauthn). Работает он не так, как может показаться на первый взгляд: отпечаток пальца или фото лица никуда не передаются и не хранятся на сервере банка или сервиса. При первой настройке устройство — смартфон или ноутбук — создаёт пару криптографических ключей. Открытый ключ отправляется на сервер, а закрытый остаётся внутри защищённого чипа самого устройства и никогда его не покидает.</p> <p>При каждом следующем входе сервер присылает на устройство случайный запрос, который нужно подписать закрытым ключом, а подтвердить, что устройство держите именно вы, нужно отпечатком, лицом или пин-кодом — без набора кода и без ожидания СМС. Есть и встроенная защита от фишинга: ключ привязан к конкретному домену сервиса, поэтому даже идеальная копия сайта банка не получит рабочую подпись — устройство просто откажется её создавать для чужого адреса. СМС-код в этом смысле куда уязвимее: это обычный текст, который можно перехватить при подмене сим-карты или выманить через социальную инженерию.</p> <h3>Что уже работает в России</h3> <p>Российские экосистемы уже несколько лет выстраивают собственную инфраструктуру авторизации, и результаты заметны.</p> <p>Сервис авторизации ВК (VK ID) к концу 2025 года довела долю беспарольных входов — через QR-код, автологин и биометрию — до 90% от всех авторизаций, с охватом порядка 50 миллионов пользователей. Сбер ID работает по похожему принципу единого профиля: внутри приложения вход всё чаще подтверждается отпечатком пальца или сканом лица, а не кодом из СМС. Яндекс объединил свой генератор одноразовых кодов «Яндекс Ключ» с центром управления аккаунтом в единое приложение Яндекс ID, где можно включить вход по лицу или отпечатку — без пароля и без СМС-кода. Похожим путём идёт и Газпром ID — единая платформа авторизации внутри экосистемы Газпрома. Здесь уже работает биометрический быстрый вход, построенный именно на ВебАус: пользователь подтверждает вход отпечатком или лицом, а пароль и СМС-код в этом сценарии вообще не участвуют — ровно тот механизм, что описан выше.</p> <p>Отдельный уровень — государственная инфраструктура. На портале Госуслуг подтверждённую учётную запись имеют уже больше 120 миллионов человек, а Единая биометрическая система (ЕБС) постепенно становится основой межбанковской идентификации: если вы один раз пришли в отделение банка, показали паспорт и сдали биометрию, в перспективе другие банки смогут заочно подтверждать, что вы — это вы, без участия СМС.</p> <h3>СМС не умрут, но перестанут быть главным способом входа</h3> <p>Из всего этого не следует, что СМС исчезнут как технология. Слишком много людей по-прежнему пользуются кнопочными телефонами или просто не хотят разбираться в новых способах входа, поэтому СМС ещё долго останутся резервным каналом — для восстановления доступа, для пользователей без смартфона, для разовых операций с высоким риском.</p> <p>Но их роль точно меняется. Рынок движется к модели, в которой основной вход подтверждается пуш-уведомлением, биометрией или доверенным устройством, а СМС становится тем самым «запасным выходом» — на случай, если основной способ недоступен. Для бизнеса это означает одновременно экономию на инфраструктуре и более устойчивую, предсказуемую авторизацию — то, чего пользователям порой не хватало в последние пару лет.</p> <p>#IMAGE_235085#</p> Ещё несколько лет назад вход в личный кабинет банка, маркетплейса или оператора связи выглядел предельно просто: ввёл номер … article Вадим Иванков, руководитель цифровых продуктов по авторизации и аутентификации пользователей ООО “Оператор Газпром ИД” https://www.itweek.ru/themes/detail.php?ID=235083 Tue, 30 Jun 2026 08:57:58 +0300 <p><em>Сегодня можно утверждать, что сегмент SaaS не умирает, а претерпевает кардинальную трансформацию, и что модель оплаты за рабочее место уходит в прошлое, пишет в корпоративном блоге Бо Люккегор, заместитель вице-президента </em><em>IDC</em> <em>по исследованиям ПО в Европе.</em></p> <p>Резкое падение рыночной капитализации поставщиков SaaS-решений за последние 9 месяцев, иногда называемое «SaaS-апокалипсисом», частично связано с тем, что инвесторы учитывают опасения, что SaaS-приложения скроются за слоем агентов искусственного интеллекта. Это сделает их невидимыми поставщиками функций («featureware»), а агенты возьмут на себя отношения с пользователями, рабочие процессы и, в конечном итоге, бюджеты.</p> <p>Ниже будет показано, что корпоративные покупатели теперь ожидают от своих поставщиков ПО предоставления агентов и того, что они будут выступать в качестве надежного источника данных и контекста для агентов, созданных на заказ и сторонними разработчиками. Это естественный следующий этап развития для поставщиков SaaS-решений, и он открывает привлекательные рыночные возможности.</p> <p>Чтобы избежать путаницы, приведу определения, связанные с ИИ, от IDC. ИИ-помощник ведёт диалог и работает как инструмент человека. ИИ-агент автономен, использует другие инструменты и переносит память и контекст между задачами. Агентный рабочий процесс — это бизнес-процесс, который агент выполняет от начала до конца с ограниченным участием человека.</p> <h3>Поставщики SaaS сталкиваются с двойной угрозой, отсюда и «SaaS-апокалипсис»</h3> <p>Первая угроза заключается в том, что организации просто будут писать собственный софт вместо того, чтобы покупать стандартные SaaS-приложения. Эта угроза спровоцировала резкое обесценивание акций поставщиков SaaS в феврале, когда Anthropic продемонстрировала возможности Code. Разговоры с CIO в крупных компаниях частично подтверждают эти опасения. Хотя они не планируют создавать основные приложения для бухгалтерского учёта или управления персоналом, они могут разрабатывать, а не покупать вспомогательные приложения в таких областях, как планирование, управление производительностью, управление компенсациями, планирование логистики и т. д. В областях применения, где требования клиентов сильно различаются и где юридическая сложность низка, организации постепенно переходят от покупки к собственной разработке.</p> <p>Вторая угроза заключается в том, что агентные наложения будут все чаще обрабатывать взаимодействие с пользователем, в то время как агенты ИИ будут получать доступ к приложениям SaaS через API для выполнения транзакций от имени пользователя. Это означает, что ключевые факторы, обосновывающие цену приложений SaaS, такие как интерфейс, широкий функционал и бренд, постепенно исчезнут из поля зрения пользователей. Это также означает, что ценообразование за рабочее место перестанет иметь смысл, когда люди перестанут быть основными пользователями приложений SaaS.</p> <h3>Внедрение агентов ИИ уже прошло переломный момент</h3> <p>Согласно апрельскому опросу IDC «Future Enterprise Resiliency and Spending», проведенном среди организаций с численностью сотрудников 500 и более человек, 74% респондентов уже внедрили как минимум одного агента, 15% проводили пилотные проекты, и только 1% сообщил, что не использует и не планирует использовать агентов ИИ. Те же респонденты ожидают, что количество типов агентов в эксплуатации примерно утроится с 24 в марте 2026 г. до 62 к 2027 г. Покупатели не оценивают целесообразность вступления в эру агентов. Они решают, какие части своей деятельности передать им в первую очередь, и операционные и основные бизнес-данные являются для них высшим приоритетом.</p> <p>Большой вопрос заключается в том, кто будет предоставлять этих агентов ИИ. Большинство организаций внедрили стандартные инструменты ИИ и провели пилотные проекты, но лишь немногие перепроектировали основные процессы для масштабного использования ИИ. Результаты опроса показывают, что большинство организаций используют готовые агенты везде, где это возможно, вместо того, чтобы создавать собственные.</p> <h3>Где выигрывают агенты, предоставляемые поставщиками</h3> <p>IDC выделяет четыре типа агентов в зависимости от того, кто их создает и как покупатель их получает. Агенты, встроенные в приложение, поставляются в комплекте с приложением, и покупатель просто их использует. Low-code/no-code-агенты настраиваются покупателем в визуальном конструкторе, предоставляемом поставщиком. Самостоятельные (standalone) агенты — это сторонние продукты, которые покупатель внедряет вместе с существующими приложениями. Агенты, созданные на заказ, собираются внутренними командами с использованием полностековых фреймворков оркестрации.</p> <p>Данные опроса, которые фокусируются на количестве агентов ИИ, а не на затратах, указывают направления роста. Два типа агентов, которые поставщики предлагают напрямую — встроенные в приложение и low-code/no-code-конструкторы — имеют наибольшую инсталлированную базу и растут быстрее всего. Агенты, разработанные на заказ, демонстрируют самый медленный рост, поскольку требуемая для них оркестрация сложнее и требует больше внутренних навыков для создания. Покупатели предпочитают внедрять или настраивать агента, который уже понимает их данные и соблюдает их права доступа, вместо того, чтобы создавать его с нуля.</p> <h3>Приложения SaaS как поставщики доверенных данных и контекста для заказных агентов</h3> <p>IDC также наблюдает широкий спрос на заказных агентов ИИ, особенно для основных бизнес-процессов, уникальных для отрасли или организации. Самостоятельные продукты и заказные агенты будут работать в рамках одного предприятия, и им потребуются данные и контекст, которые находятся внутри вашего приложения.</p> <p>Заказной или сторонний агент, получающий доступ к данным «откуда угодно», по-прежнему нуждается в месте, где данные корректны, процесс соответствует нормативным требованиям, права доступа соблюдаются, а выполнение транзакции гарантировано. Поставщик SaaS-решений может предложить проверенные бизнес-процессы, управляемые данные и журналы аудита для использования заказными ИИ-агентами. По мнению IDC, это ключевая роль для SaaS-приложений в будущем.</p> <h3>Как выглядит SaaS-приложение, ориентированное на ИИ</h3> <p>Интерфейс перестает быть одним экраном и становится несколькими режимами, обслуживающими одни и те же процессы: традиционный пользовательский интерфейс, диалоговый интерфейс, интерфейс рабочего процесса, встроенный туда, где пользователь уже работает, и машинные интерфейсы, позволяющие внешним агентам напрямую и безопасно вызывать приложение.</p> <p>Переход к ИИ требует от поставщиков SaaS полного переосмысления рабочего процесса, что затрагивает весь стек: базовые модели, слой вложений, векторную базу данных, генерацию с расширенными возможностями поиска, слой оркестрации, механизмы защиты, мониторинг и управление версиями. Поставщик также должен предоставить покупателям собственный набор агентных инструментов, чтобы low-code/no-code-конфигурирование, которое все чаще требуют покупатели, происходило внутри управляемой среды поставщика, а не за ее пределами.</p> <p>Что касается региональных особенностей, то европейские поставщики, например, предъявляют дополнительные требования, которые при правильном подходе становятся конкурентным преимуществом. Соответствие GDPR, NIS2 и Закону ЕС об ИИ, гарантии резидентности данных и суверенного облака, подлинная многоязычная производительность модели и прозрачность в том, как ИИ принимает решение, — все это условия продажи для европейских покупателей, чувствительных к вопросам комплаенса.</p> <p>SaaS не умер, и игроки рынка не обречены. Однако актив, оправдывающий существование поставщика, смещается от экрана, на который смотрит пользователь, к агентам, которые этот поставщик предоставляет, и управляемым данным, на которые полагаются эти и другие агенты. Ваши клиенты уже ожидают, что вы будете их поставщиком агентов. Вопрос лишь в том, опережаете ли вы этот тренд или реагируете на него.</p> Сегодня можно утверждать, что сегмент SaaS не умирает, а претерпевает кардинальную трансформацию, и что модель … article https://www.itweek.ru/themes/detail.php?ID=235082 Mon, 29 Jun 2026 14:20:45 +0300 <p>Российская компания «Атомик Софт», специализирующаяся на разработке ПО для автоматизации промышленных и гражданских объектов, представила новый компонент своей платформы SCADA — Alpha.SmartControl. Это решение ориентировано на предприятия, которым необходимы отдельные функции системы управления производственными процессами MES (Manufacturing Execution System, система управления производственными процессами), но внедрение полноценного MES-решения является избыточным или требует значительных финансовых и временных вложений.</p> <p>Alpha.SmartControl представляет собой модульный инструмент, позволяющий заказчикам выбирать только необходимые функции, избегая переплат за неиспользуемый функционал. Компонент собирает данные из разнородных систем предприятия: АСУ ТП, MES, ERP и СУБД. На основе собранной информации формируются аналитические дашборды, рассчитываются ключевые показатели эффективности производства, а также предоставляются инструменты для оперативного управления — от цифровых бланков переключений до расчета остаточного ресурса оборудования.</p> <p>Alpha.SmartControl предлагает широкий спектр сценариев использования: от стандартных отчетов по ходу технологического процесса до углубленной аналитики состояния оборудования. Система позволяет рассчитывать наработку оборудования с отображением графиков режимов работы и остаточного ресурса, а также вычислять коэффициенты использования и простоев. Для оперативного управления предусмотрено ведение цифровых бланков переключений с контролем шагов и сигнализацией. Кроме того, доступен план-факт-анализ для сопоставления плановых и фактических показателей, а также формирование суточных ведомостей с основными показателями предприятия, заметками персонала и сравнением задания с фактом.</p> <p>Ключевые преимущества</p> <ul> <li>консолидация данных из разнородных систем в едином пространстве;</li> <li>три режима формирования отчетов — по запросу, по расписанию или при выполнении заданных условий;</li> <li>единая система безопасности с ПО «Альфа платформа» — разграничение прав доступа, групп и ролей пользователей в соответствии с политиками предприятия;</li> <li>граничные вычисления (edge computing) — обработка данных на уровне технологических сетей, а не в корпоративной сети, что повышает оперативность и снижает нагрузку на инфраструктуру.</li> </ul> <p>«Промышленности мало просто отчетов. Нужна аналитика, на которую можно опереться при принятии решений. Alpha.SmartControl как раз для этого: мы собрали в одном месте сбор данных, расчет эффективности и удобные инструменты для персонала — от оператора до главного инженера. Пользователь получает реальную картину производства», — прокомментировал Денис Алексеев, менеджер продуктового маркетинга «Атомик Софт».</p> <p>«Атомик Софт» планирует расширять функциональность Alpha.SmartControl модулями для расчета материальных и энергетических балансов, а также инструментами описания модели предприятия с нормативно-справочной информацией для упрощения генерации новых шаблонов отчетов.</p> Российская компания «Атомик Софт», специализирующаяся на разработке ПО для автоматизации промышленных … message https://www.itweek.ru/themes/detail.php?ID=235080 Mon, 29 Jun 2026 14:18:39 +0300 <p>«Яндекс Браузер» для организаций научился автоматически реагировать на действия, которые могут свидетельствовать о кибератаке или утечке данных. Новый инструмент активной защиты от киберугроз может в режиме реального времени анализировать события в Браузере, автоматически ограничивать доступ к веб-ресурсам или сообщать об этом сотрудникам информационной безопасности в соответствии с политиками. Это позволяет обнаруживать потенциально небезопасные действия до того, как их заметят специалисты информационной безопасности (СИБ) и усилить таким образом защиту организаций от потенциальных киберугроз.</p> <p>При настройке Браузера для организаций ИТ-администраторы могут самостоятельно настроить события-триггеры — потенциально небезопасные действия. Например, если на устройстве сотрудника запустится программа для удалённого управления, Браузер для организаций автоматически заблокирует доступ к корпоративному веб-ресурсу и очистит браузерные данные, если это предусмотрено политиками безопасности. Также компании могут выбрать конкретную реакцию на триггер — например, Браузер для организаций автоматически заблокирует страницу для сотрудника и сообщит о возможном инциденте в СИБ.</p> <p>Кроме этого, теперь Браузер для организаций анализирует не только URL, который открывает сотрудник, но и IP-адрес, на котором расположен сайт. Если система обнаружит, что IP-адрес может быть связан с распространением вредоносного программного обеспечения или с другой подозрительной активностью, она заблокирует загрузку страницы и уведомит специалистов по информационной безопасности компании. Такой подход позволяет выявлять потенциально опасные ресурсы ещё до того, как они успеют повлиять на работу корпоративной инфраструктуры.</p> <p>Новые возможности доступны в расширенной версии «Яндекс Браузера» для организаций при наличии действующей лицензии. </p> «Яндекс Браузер» для организаций научился автоматически реагировать на действия, которые могут свидетельствовать … message https://www.itweek.ru/themes/detail.php?ID=235078 Mon, 29 Jun 2026 14:17:11 +0300 <p>Консалтинговая технологическая компания Axenix провела исследование влияния искусственного интеллекта на процессы разработки программного обеспечения и кадровую ситуацию в ИТ-сегменте. Эксперты пришли к выводу, что внедрение ИИ в полный цикл разработки ПО — от генерации кода до тестирования и сопровождения — удваивает продуктивность разработки, но ожидаемого эффекта в ускорении вывода продуктов на рынок не происходит. При этом использование ИИ меняет требования к командам и требует пересмотра кадровой стратегии компаний.</p> <p>Согласно данным StackOverflow, сегодня инструменты ИИ используют 84% разработчиков на мировом рынке, с его помощью создается более 40% программного кода, при этом его генерация ускоряется в <nobr>2-3 раза.</nobr> Автоматизируются также создание документации, тестирование и другие задачи. В результате опытный ИТ-специалист, использующий современные ИИ-инструменты, способен выполнять объем работы, который ранее распределялся между двумя или тремя junior-работниками. </p> <p>Средняя экономия при отказе от найма одного начинающего специалиста может достигать <nobr>1-1,5</nobr> годовых оклада без учета налоговых отчислений. Вполне логично, что компании и в России, и в других странах снижают набор молодых сотрудников.</p> <p>При этом исследование показало, что рост производительности отдельных этапов разработки не всегда приводит к сокращению сроков вывода продукта на рынок. «Бутылочным горлышком» становится верификация сгенерированного кода, написанного с помощью ИИ, так как senior-специалисты тратят на эту работу до 70% своего времени.</p> <p>По мнению экспертов Axenix, долгосрочный риск для отрасли формируется под влиянием двух основных факторов. Во-первых, обеспокоенность вызывает качество сгенерированного кода. Так, в исследовании говорится, что команды с активным использованием ИИ накапливают технический долг значительно быстрее, чем при традиционном подходе к разработке.</p> <p>В частности, за последние годы в несколько раз увеличился показатель churn rate — доля кода, который переписывается в течение короткого времени после создания. Высокий churn rate означает, что код принимается в систему, но вскоре оказывается некорректным или не соответствующим требованиям. Из-за этого его приходится перерабатывать. Т.е., речь идет не просто об увеличении объема переделок, которое могло бы объясняться ростом общего объема разработки, а именно об ухудшении качества нового кода. Во-вторых, из-за активного внедрения ИИ senior-специалисты все больше времени тратят на проверку и исправление сгенерированного кода, тогда как новых кадров для их замены становится меньше. </p> <p>Поскольку компании все активнее замещают junior-позиции ИИ-инструментами и нанимают меньше молодых специалистов, воронка профессионального роста сужается уже сейчас. Некому проходить путь от junior до middle и senior. Учитывая, что этот путь традиционно занимает <nobr>10-15 лет,</nobr> последствия проявятся не сразу. Но через годы рынок столкнется с острым дефицитом опытных специалистов, которые смогли бы отвечать за развитие сложных цифровых продуктов. По мнению экспертов Axenix, формируется риск разрыва «кадрового конвейера». Если в 2020 году junior-разработчики составляли около 40% кадровой структуры, то в 2026 году их доля снизилась до 30%.</p> <p>«С точки зрения бизнеса краткосрочная экономия выглядит убедительно. Однако такая стратегия создает риск дефицита квалифицированных кадров на рынке и роста стоимости высококлассных специалистов. Через десять лет при текущем темпе развития вайбкодинга сами инструменты разработки и ИИ могут кардинально измениться. И если отрасль перестанет системно выращивать специалистов, способных понимать технологии на глубоком уровне, есть риск, что сложные продукты постепенно превратятся в „черные ящики“. Понимание того, как системы устроены в целом и как ими управлять, начнет утрачиватьcя. ИИ способен существенно повысить эффективность работы, но не может заменить систему подготовки экспертов, которая формировалась десятилетиями», — прокомментировал Андрей Толстов, старший менеджер Axenix. </p> <p>Наиболее эффективной стратегией, по его словам, является сочетание ИИ-инструментов разработки и сохранения программ подготовки junior-специалистов. Таким образом, компании и сокращают издержки, и сохраняют преемственность кадров.</p> <p>Кроме того, исследование указывает на дополнительный источник кадров для технических и архитектурных ролей — через переобучение системных аналитиков. ИИ снижает технический барьер входа в архитектуру: с его помощью проще генерировать прототип, оценить производительность решения, разбираться в чужой кодовой базе. Аналитики с <nobr>5-7</nobr> годами опыта уже успешно переходят на позиции технических аналитиков и младших архитекторов.</p> Консалтинговая технологическая компания Axenix провела исследование влияния искусственного интеллекта на процессы разработки … message https://www.itweek.ru/themes/detail.php?ID=235077 Mon, 29 Jun 2026 14:15:57 +0300 <p>«Гармония» обновила систему Arenadata Harmony MDM (AD.MDM). Среди ключевых изменений — наследование признаков по иерархии классов, автоматическая генерация наименований по шаблонам и асинхронная выгрузка отчетов через реплику базы данных. Поиск теперь поддерживает транслитерацию, а пакет записей или весь справочник можно рассылать по нескольким клиентским системам одной командой. Обновление повышает скорость работы с данными, делая процессы более гибкими, коммуникации — быстрее, а контроль качества — глубже.</p> <p>Arenadata Harmony MDM — российская система enterprise-уровня для управления мастер-данными, разработанная компанией «Решения «Гармония» (входит в группу Arenadata). Она предназначена для централизации управления нормативно-справочной информацией, нормализации данных из разрозненных источников и обеспечения их качества даже в сложных ИТ-ландшафтах с большим количеством корпоративных систем. </p> <p>Обновление Arenadata Harmony MDM нацелено на повышение удобства работы в системе, ее производительности и скорости обработки данных. Ключевое новшество в версии 3.1.1 — механизм наследования атрибутов по иерархии классов, поддерживающий обязательное, частичное и переопределяемое наследование. Теперь при настройке классификаторов можно выбрать, как именно дочерний класс будет наследовать признаки родительского. Нововведение приближает систему к полноценному объектному моделированию данных — это минимизирует необходимость ручных настроек.</p> <p>Для упрощения рутинных операций в версии 3.1.1 добавлена генерация текстовых атрибутов по шаблонам. <nobr>MDM-специалист</nobr> может задать правила формирования полей — например, «Полное наименование» — на основе данных классификации без написания скриптов и привлечения разработчиков. </p> <p>Улучшен и поисковой механизм. Система распознает различные варианты написания одного и того же слова с учетом транслитерации: к примеру, «шкаф», «shkaf» или «skaf» будут идентифицированы как один объект. Это исключает как потерю информации, так и дублирование данных.</p> <p>Для ускорения процессов информацию теперь можно отправлять сразу по нескольким клиентским системам одной командой. Массовая рассылка данных во внешние системы экономит время пользователей и снижает вероятность ошибок при ручной обработке записей. Это особенно важно для компаний с развитой ИТ-инфраструктурой, где требуется синхронизация НСИ между множеством ИТ-решений.</p> <p>Наконец, в фокусе Arenadata Harmony MDM 3.1.1 — расширение возможностей для работы с отчетностью. Система поддерживает подключение кастомных отчетов, что позволяет компаниям расширять стандартную аналитику под свои потребности. А для работы с большими объемами данных внедрена асинхронная выгрузка: решение использует механизм очередей для балансировки запросов, не блокируя интерфейс. Пользователь получает уведомление о готовности файла и может просмотреть его на отдельной странице.</p> <p>Для тяжелых запросов используется реплика базы данных, чтобы не нагружать основную базу и не замедлять работу остальных пользователей — это крайне важно для крупных компаний. Механизм позволяет обеспечить стабильную работу MDM вне зависимости от сложности запросов и количества сотрудников, использующих систему. </p> <p>«Arenadata Harmony MDM 3.1.1 оптимально подходит для решения задач крупного бизнеса. Гибкость моделирования дает возможность быстро реагировать на изменения бизнеса и рыночных условий, а архитектура системы гарантирует производительность даже в самых сложных enterprise-контурах. Мы даем таким компаниям фундамент для построения data-driven культуры без технических ограничений», — отметил Евгений Обелов, технический директор Arenadata Harmony MDM. </p> <p>AD. MDM обладает открытой архитектурой для интеграции с корпоративным ИТ-ландшафтом и внешними источниками, такими как ЕФРСБ, ФИАС, ЕГРЮЛ, НРД. Кроме того, решение разработано по модели low-code, что делает его доступным для бизнес-пользователей, не имеющих продвинутых навыков программирования.</p> «Гармония» обновила систему Arenadata Harmony MDM (AD.MDM). Среди ключевых изменений — наследование признаков … message https://www.itweek.ru/themes/detail.php?ID=235075 Mon, 29 Jun 2026 09:14:48 +0300 <p><em>Дебора Камбе, менеджер по маркетингу продуктов компании PagerDuty, рассказывает на портале </em><em>The</em> <em>New</em> <em>Stack</em> <em>о том, как операционный долг разрушает стратегии в области искусственного интеллекта, и предлагает четыре важнейших шага для построения долгосрочной операционной устойчивости.</em></p> <p>Давление, требующее быстрых действий, никогда не было таким сильным. Однако скорость без устойчивости — это обуза. По мере перехода ИИ от пилотных проектов к производству, он не просто увеличивает преимущества; он увеличивает количество точек отказа.</p> <p>Согласно опросу <a href="https://investor.pagerduty.com/news/news-details/2025/Three-Quarters-of-Companies-Now-Consider-AI-Essential-to-Operations-PagerDuty-Survey-Reveals/">PagerDuty «AI Resilience Survey</a>», 84% компаний уже столкнулись как минимум с одним сбоем, связанным с ИИ. Тем не менее, большинство по-прежнему справляются с этими сбоями с помощью процессов, разработанных для более медленной, ориентированной на человека эпохи. Финансовые риски делают это неприемлемым: в отчете PagerDuty «<a href="https://www.pagerduty.com/state-of-ai-first-operations/">2026 PagerDuty State of AI-First Operations</a>» говорится, что 68% организаций теряют более 300 тыс. долл. в час, когда системы выходят из строя. И по мере роста сложности ИИ радиус поражения каждого сбоя также увеличивается.</p> <p>В спешке внедрения новых инструментов и функций организации рискуют оказаться в уязвимом положении, когда их операционная инфраструктура не справляется. Успех ИИ-инициативы зависит от понимания того, где может накапливаться операционный долг. Первая проблема: признание того, что эти сбои обнаружить сложнее, чем ожидает большинство команд.</p> <h3>Почему сбои ИИ сложнее обнаружить</h3> <p>Большинство организаций знают, что что-то идет не так: фактически, 85% говорят, что им нужны более эффективные способы обнаружения сбоев в инструментах ИИ. Но осведомленность — это не действие.</p> <p>Сбои ИИ ведут себя не так, как традиционные инциденты. Модели дрейфуют. Агенты неправильно интерпретируют контекст. Первопричины сложнее отследить, а окно для локализации ущерба короче. Организации, которые по-прежнему рассматривают ИИ-инциденты как частные случаи, накапливают технический долг, который они не заложили в бюджет. Специальные процессы управления инцидентами, разработанные специально для режимов сбоев ИИ, больше не являются необязательными.</p> <p>Чтобы справиться с этим эффективно, сначала нужно знать, где скрывается долг.</p> <h3>Три типа операционного долга, замедляющего ваш прогресс</h3> <p><strong>1. Технический долг и долг автоматизации. </strong>Устаревшие инструменты, ручные операции, которые никогда не были автоматизированы, нестандартизированные процессы в разных командах — они накапливаются незаметно и быстро увеличиваются в размерах. Но именно здесь ИИ и приносит свои плоды. При правильном применении ИИ может анализировать рабочие процессы, выявлять возможности автоматизации и постепенно устранять рутинную работу, а не просто отмечать её.</p> <p>«Постепенно» — ключевое слово. Организации, получающие наиболее быструю отдачу, не внедряют ИИ сразу повсюду. Они начинают с хорошо понятных, повторяющихся задач, укрепляют уверенность и расширяются дальше.</p> <p>Но одной автоматизации недостаточно. Если лежащие в её основе системы не связаны, выгода остаётся локальной.</p> <p><strong>2. Долг интеграции. </strong>Это тихий множитель. Встройте инструменты ИИ в изолированные среды, и вы не сможете сопоставлять сигналы, обмениваться контекстом или действовать на основе полной картины. Без надлежащей интеграции между инструментами, сервисами и источниками данных даже лучшие инвестиции в ИИ не смогут масштабироваться или обеспечивать ожидаемую рентабельность инвестиций.</p> <p>Вместо того чтобы добавлять больше инструментов, попробуйте улучшить связи между ними. Серверы Model Context Protocol (MCP) стали практичным решением, предоставляющим агентам ИИ безопасный доступ в режиме реального времени к источникам данных без многомесячных проектов интеграции. Данные опроса подтверждают это: 54% организаций связывают повышение отказоустойчивости с инструментами, поддерживающими полный жизненный цикл инцидента, а 51% — с объединением нескольких инструментов в единую платформу.</p> <p>Тем не менее, улучшенная интеграция инструментов все равно не спасет вас, если не решен вопрос с человеческим фактором.</p> <p><strong>3. Долг партнерства человека и ИИ. </strong>Самые дорогостоящие ошибки ИИ — не технические, а организационные. Если команды не определили, какие решения должны приниматься машинами, а какие людьми, они либо чрезмерно автоматизируют процесс и теряют контроль, либо недостаточно автоматизируют и теряют ценность.</p> <p>Решить эту проблему помогает трехуровневая модель:</p> <ul> <li> Рутинные, хорошо понятные задачи могут быть полностью автоматизированы.</li> <li> Частично понятные задачи выигрывают от сотрудничества ИИ и человека, где ИИ занимается анализом и рекомендациями, но окончательное решение остается за людьми.</li> <li> Новые или сложные задачи требуют глубоких человеческих знаний, а ИИ играет лишь вспомогательную роль.</li> </ul> <p>Команды, которые могут четко определить эти границы, создают убедительное обоснование для более широких инвестиций в ИИ.</p> <h3>Четыре шага к повышению операционной устойчивости</h3> <p>Определение долга — это половина работы. Другая половина — это четкий план устранения проблем.</p> <ol> <li><strong>Создайте систему управления инцидентами, специфичную для ИИ.</strong> Четко определите ответственность и пути эскалации и разработайте инструкции специально для режимов отказа ИИ, а не занимайтесь адаптацией устаревших правил. Рассматривайте управление инцидентами как межфункциональную дисциплину, а не как второстепенную ИТ-задачу.</li> <li><strong> Определите операционные границы ИИ.</strong> Используйте трехуровневую модель, описанную выше, чтобы определить, какие задачи ИИ может безопасно автоматизировать, а какие требуют человеческого суждения. Это основа для более быстрых операций и устойчивой ценности ИИ.</li> <li><strong> Инвестируйте в мониторинг ИИ. </strong>Традиционные инструменты мониторинга не были созданы для выявления деградации моделей или непреднамеренных решений агентов. Специализированные LLMOps-решения могут обнаруживать эти предупреждающие знаки до того, как проблемы достигнут клиентов.</li> <li><strong> Внедрите непрерывное обучение в процесс.</strong> Каждый инцидент должен предоставлять обратную связь для руководств по устранению неполадок, правил автоматизации и логики эскалации. Именно так организации снижают риски с течением времени, а не просто реагируют на них.</li> </ol> <h3>Операционная устойчивость как конкурентное преимущество</h3> <p>По мере роста внедрения ИИ во все большее число критически важных процессов растет и стоимость сбоев. Поэтому вот что стоит сделать: перестаньте рассматривать устойчивость как средство минимизации ущерба и начните рассматривать ее как накапливающийся актив. Каждый устраненный инцидент становится оперативной аналитикой. Каждый выявленный шаблон становится основой для будущей автоматизации.</p> <p>Со временем это обеспечит не просто более быстрое восстановление: это основа автономных операций, где машины выполняют рутинные задачи, а люди сосредотачиваются на том, что действительно продвигает бизнес вперед. Организации, которые начинают заниматься этим раньше, первыми достигают цели.</p> Дебора Камбе, менеджер по маркетингу продуктов компании PagerDuty, рассказывает на портале The New Stack о том … article https://www.itweek.ru/themes/detail.php?ID=235074 Fri, 26 Jun 2026 13:32:39 +0300 <p>Хостинг-провайдер SpaceWeb запустил Serverless — сервис автоматического деплоя приложений из GitHub и GitLab. Сервис создан для размещения приложений без управления серверной инфраструктурой. Пользователь подключает репозиторий GitHub или GitLab, выбирает проект и ветку, задает параметры сборки, после чего сервис автоматически собирает приложение и выдает ссылку на рабочую версию.</p> <p>Сервис закрывает один из самых частых барьеров при запуске веб-проектов: код уже готов, но его еще нужно развернуть, настроить окружение, домен, SSL/TLS-сертификат, переменные и процесс обновления. В сервисе эти шаги собраны в одном интерфейсе. Веб-мастерам доступна конфигурация с 2 CPU, 4 ГБ RAM и 2 ГБ SSD. Решение поддерживает проекты на Static HTML/CSS/JS, Python, Node.js, Next.js, Flask и FastAPI. </p> <p>«Рынок разработки ускоряется: команды хотят проверять гипотезы и выводить продукты в продакшен за часы, а не недели. Но на практике их тормозит не код, а сама инфраструктура. Наша цель — убрать этот барьер и сделать запуск приложений таким же простым, как работа с репозиторием. Serverless — это шаг к тому, чтобы любой разработчик мог сосредоточиться на продукте, а не на настройке окружения», — прокомментировал Егор Шилов, руководитель продуктового направления SpaceWeb. </p> <p>Serverless продолжает развитие линейки готовых решений SpaceWeb для разработки. Ранее в каталоге VPS появились инструменты для Python- и веб-разработки, командной работы, мониторинга, управления доступами и DevOps-задач. Новый сервис дополняет эти решения на этапе деплоя: если готовые образы помогают быстрее подготовить окружение, то Serverless позволяет быстрее опубликовать проект из репозитория и обновлять его без ручной настройки серверов. </p> Хостинг-провайдер SpaceWeb запустил Serverless — сервис автоматического деплоя приложений из GitHub и GitLab … message https://www.itweek.ru/themes/detail.php?ID=235073 Fri, 26 Jun 2026 13:30:58 +0300 <p>Компания «Перфоманс Лаб» представила новый выпуск Russia Quality Report 2026 — ежегодного аналитического обзора рынка тестирования и обеспечения качества в российских IT-компаниях.</p> <p>Ключевые выводы:</p> <ul> <li>QA становится управляемой функцией. 60% компаний называют свои процессы управляемыми, еще 31% — оптимизированными. При этом эффективность QA всё чаще оценивают через бизнес-показатели: 62% смотрят на инциденты в продуктовой среде, 39% — на удовлетворенность пользователей, 34% — на скорость вывода продукта на рынок;</li> <li>главный приоритет рынка — автоматизация. На ней сейчас фокусируются 67% компаний. Следом идут взаимодействие с разработкой и бизнесом (35%), внедрение ИИ в QA (31%), развитие метрик качества (25%) и подготовка специалистов QA (25%);</li> <li>интерес к ИИ высокий, но рынок пока осторожен. Только 15% компаний активно используют ИИ в продуктивных QA-процессах, 21% ведут пилотные проекты, 30% изучают сценарии применения. В сумме 36% рынка уже перешли от интереса к практическому движению. Самый популярный сценарий использования ИИ — генерация тест-кейсов из требований (52%);</li> <li>импортозамещение стало системным процессом. К концу 2025 года в реестре отечественного ПО более 29 тысяч продуктов и 10,8 тысячи вендоров. За три года сформировалась переходная модель, когда в одних сегментах отечественные решения закрепились, в других зависимость от зарубежного стека остается высокой. Наиболее заметный прогресс произошел в области систем управления тестированием;</li> <li>автоматизация воспринимается как базовая практика, но ее развитие упирается в зрелость инфраструктуры. 67% компаний считают ее фокусным направлением, но среди трудностей называют дефицит компетенций (37%), нестабильность тестовой среды (31%), интеграцию инструментов (23%) и качество тестовых данных (23%). Главный измеримый эффект автоматизации — сокращение времени выполнения регрессионного тестирования (68%);</li> <li>32% компаний уже отлавливают большинство потенциальных инцидентов с помощью мониторинга и алертинга. За три года доля компаний, где есть инструкции, но нет командной работы, сократилась с 17 до 3%, а доля тех, кто с трудом восстанавливает работу, — с 13,6 до 1,8%;</li> <li>прогнозы 2023 года сбылись неравномерно. Shift-Left вырос быстрее ожиданий — с 29 до 48% при прогнозе 42%. QAOps достиг 23% вместо ожидаемых 27%, а ИИ/ML в тестировании — 23% вместо прогнозных 38%. Главный будущий приоритет — ИИ в тестировании: его планируют развивать 43% компаний.</li> </ul> <p>«Новый выпуск готовился более полугода. Наша команда собрала и проанализировала ответы сотен специалистов из самых разных сфер бизнеса, провела глубинные интервью с руководителями и практиками из компаний-лидеров. Всё это позволило нам составить объективную картину того, как сегодня устроено тестирование в российских IT-организациях, куда направляются тренды и что мешает отрасли двигаться быстрее. Лейтмотив этого выпуска — искусственный интеллект как новая реальность QA. Мы наблюдаем, как <nobr>LLM-модели</nobr> и ИИ-инструменты превращаются в полноценную часть рабочих процессов тестировщиков. Среди самых востребованных инструментов — OpenAI ChatGPT/GPT-4.5, Claude, GigaChat, YandexGPT и opensource решения, такие как Qwen и Mistral. Важно при этом, что ИИ не вытесняет тестировщика — он меняет его роль, усиливает возможности и поднимает планку ожиданий от специалиста», — прокомментировал Александр Канатов, Руководитель бизнес-юнита «Функциональное тестирование» в «Перфоманс Лаб»</p> <p>Скачать Russia Quality Report 2026 можно на сайте компании «Перфоманс Лаб».</p> Компания «Перфоманс Лаб» представила новый выпуск Russia Quality Report 2026 — ежегодного аналитического обзора рынка … message