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=235310 Fri, 07 Aug 2026 13:32:20 +0300 <p>В совместном исследовании DDoS-Guard и FirstVDS проанализировали более 7,5 млн атак за три года, провели опрос более 200 владельцев бизнеса и выявили новые тренды: смещение фокуса злоумышленников на игровую индустрию (+310%) и рост распределенности атак на 480%.</p> <p>«Раньше DDoS требовал ресурсов и подготовки — сегодня он покупается как сервис: достаточно указать адрес, остальное делает автоматика. Порог входа почти нулевой. Отсюда и смещение рисков. — считает директор по продукту FirstVDS, Никита Попов. — Под ударом те, у кого простой мгновенно конвертируется в деньги, — игровые сервисы традиционно, интернет-магазины, SaaS-платформы. И отдельно те, где атака работает как инструмент давления: госсектор, телеком, финансы. Пока на стороне атакующего автоматизация и DDoS как услуга, а на стороне бизнеса — сутки простоя и разбирательства с клиентами, спорить о целесообразности защиты бессмысленно. Считать надо не вероятность атаки, а стоимость часа недоступности. У большинства проектов эта цифра выше, чем стоимость годовой защиты».</p> <p>«Мы видим несколько устойчивых трендов: растет распределенность вредоносного трафика, все чаще применяется тактика Pulse Wave, которая дезориентирует автоматические системы защиты. Злоумышленники круглосуточно сканируют интернет в поисках свежих адресов — это делает новые проекты особенно уязвимыми в первые месяцы после запуска. В таких условиях классические фаерволы и геоблокировки малоэффективны, требуется фильтрация L7-трафика с поведенческим анализом», — отметил Казбек Мамакаев, тимлид команды разработки защиты на уровне веб-приложений DDoS-Guard.</p> <p>Основные факты:</p> <ul> <li>игровые сервисы — лидеры по приросту числа атак: за год показатель вырос на 310%. В топе также госсектор (+249,6%), телеком (+80,8%) и финансовый сектор (+45,4%);</li> <li>40% атак приходятся на первые два месяца после запуска сервера — новый проект автоматически становится целью для ботнетов;</li> <li>каждая третья атака длится более суток. Раньше DDoS считался краткосрочным ударом, теперь это затяжной прессинг;</li> <li>за два года число уникальных IP-адресов в одной атаке выросло с 353 тыс. до более чем 2 млн, а в первом квартале 2026 года зафиксирована атака с 3,1 млн источников;</li> <li>атаки приводят к критичным последствиям — почти половина опрошенных (48,62%) пережили полные простои сервисов. 44,6% считают, что риск DDoS-атак для их отрасли вырос;</li> <li>основные источники атак — Россия, США, страны Латинской Америки и Юго-Восточной Азии. В 2026 году к списку добавился Бангладеш.</li> </ul> В совместном исследовании DDoS-Guard и FirstVDS проанализировали более 7,5 млн атак за три года, провели опрос … message https://www.itweek.ru/themes/detail.php?ID=235308 Fri, 07 Aug 2026 09:48:56 +0300 <p>Менять подрядчика у работающей веб-системы — не то же самое, что передавать новый проект. Пока команды разбираются с кодом и доступами, через систему продолжают идти заказы, заявки, платежи и документы. Поставить её на паузу на неделю, чтобы новая команда освоилась, бизнес не может.</p> <p>Код при этом можно передать за день. Настоящие проблемы обнаруживаются позже: во время первого сбоя, срочной доработки, продления сертификата или восстановления базы данных. Если без прежнего подрядчика новая команда не может собрать релиз, найти причину ошибки и вернуть систему в рабочее состояние, передача существует только на бумаге.</p> <h3>Начинать нужно с критичных процессов</h3> <p>В одной веб-системе могут одновременно работать оформление заказов, личный кабинет, внутренние справочники и отчётность. Но последствия сбоя у них разные. Если перестали оформляться заказы, компания сразу теряет выручку. Обновление внутреннего отчёта во многих случаях может подождать несколько часов или дней.</p> <p>Поэтому до передачи определяют, какие пользовательские действия нельзя останавливать и какие модули, интеграции, фоновые задания и внешние сервисы обеспечивают их работу. Заодно договариваются, сколько может продлиться простой и какой объём данных допустимо потерять. В ИТ-документации эти ограничения обычно обозначают как RTO (время восстановления) и RPO (допустимый период потери данных).</p> <p>Назначать одно значение для всей системы не верно. Заказы, платежи и уведомления могут требовать восстановления за минуты, а внутренняя статистика — за часы. Такая расстановка приоритетов особенно важна в первые недели: при сбое новая команда сразу понимает, какой процесс возвращать в работу первым.</p> <h3>Как выбрать сценарий передачи</h3> <ul> <li><strong>Параллельная работа команд</strong> — самый надёжный вариант для критичной системы. На первом этапе новая команда наблюдает, как выпускаются обновления и разбираются инциденты, затем делает это сама под контролем прежней. Здесь важно заранее разделить ответственность. У каждого релиза и инцидента должен быть один владелец, иначе обе команды будут ждать действий друг от друга.</li> <li><strong>Поэтапная передача</strong> подходит, если систему можно разделить на относительно самостоятельные части. Например, сначала передать личный кабинет, затем интеграционный модуль и административную панель. Вместе с каждым модулем передают его зависимости, мониторинг и порядок поддержки. Один только код не поможет, если новая команда не видит, как модуль обменивается данными с соседними системами.</li> <li><strong>Экстренный переход</strong> приходится проводить, когда прежний подрядчик недоступен или есть риск потерять контроль над инфраструктурой. В этом случае сначала получают административные доступы, фиксируют текущее состояние системы, подключают мониторинг и проверяют резервные копии. Новые функции временно отходят на второй план: главная задача — вернуть систему под контроль.</li> </ul> <p>Если в этот момент уже произошёл сбой, порядок ещё жёстче: сначала тушат пожар — локализуют проблему, восстанавливают критичный процесс и ограничивают ущерб. Полное обследование архитектуры и разбор причин проводят после стабилизации. Иначе время, потраченное на изучение системы, превращается в прямой убыток для заказчика.</p> <p>При любом сценарии нужен отдельный план перехода. Дата окончания договора сама по себе ничего не говорит о готовности новой команды.</p> <h3>Вернуть заказчику контроль над системой</h3> <p>Самые неприятные сюрпризы часто находятся не в репозитории. Домен может быть зарегистрирован на сотрудника подрядчика, уведомления об ошибках — приходить только в его мессенджер, а сборка приложения — зависеть от файла на ноутбуке конкретного разработчика. Формально код уже у заказчика, но управлять системой без прежней команды он всё ещё не может.</p> <p>Чтобы увидеть такие зависимости, составляют общий список ресурсов, от которых зависит система. В него входят репозитории, серверы и облачные аккаунты, домены и настройки DNS, базы данных, хранилища, сертификаты, лицензии, почтовые и СМС-сервисы. Для каждого ресурса указывают владельца, администраторов, способ восстановления доступа и срок оплаты или действия сертификата. Это может быть обычная таблица — сложная система учёта здесь не нужна.</p> <p>Отдельно проверяют технические доступы: SSH-ключи, токены системы автоматической сборки и развёртывания (CI/CD), API-ключи и доступы к внешним сервисам. Новой команде выдают собственные права и проверяют, что они работают. Только после этого доступы прежнего подрядчика отзывают, а известные ему пароли, токены и ключи заменяют. Обратный порядок опасен: можно остановить интеграцию или лишиться единственного рабочего способа развернуть приложение.</p> <p>Сам по себе список доступов ещё ничего не гарантирует. Новая команда должна собрать приложение в чистом окружении, развернуть тестовую версию, выпустить небольшое обновление и при необходимости вернуться к предыдущей версии. Такая проверка быстро находит то, чего нет в инструкциях: локальные файлы, закрытые библиотеки, ручные операции и пропущенные настройки.</p> <p>То же относится к мониторингу и резервным копиям. Оповещения должны приходить новой команде. И команда должна уметь в них видеть не только техническую ошибку, но и её последствие: перестали создаваться заказы, не формируются документы, не обновляются статусы доставки. Резервной копии тоже нельзя доверять, пока данные из неё не восстановили в отдельной среде и не проверили. Заодно становится понятно реальное время восстановления, а не цифра из регламента.</p> <h3>Документацию нужно проверять в работе</h3> <p>Схема архитектуры и подробная инструкция полезны, но сами по себе ничего не доказывают. Документ может быть устаревшим, а важная операция — держаться на памяти одного специалиста. Поэтому знания передают через конкретные действия: новая команда пытается совершить действие и в случае проблем обращается к предыдущей.</p> <p>Минимальная практическая проверка — разобраться со сбоем интеграции по логам, выпустить небольшое изменение, выполнить откат и восстановить данные из резервной копии. После каждого действия корректируют рабочую инструкцию: где начинать диагностику, какие показатели смотреть, кому сообщать о проблеме и когда принимать решение об откате.</p> <p>Если прежний подрядчик в передаче не участвует, устройство системы приходится восстанавливать по истории изменений и задач, настройкам CI/CD, тестам, логам и прошлым инцидентам. До принятия обычных обязательств по поддержке новая команда проводит обследование и честно фиксирует, за что уже может отвечать, а где пока остаются неизвестные зависимости.</p> <p>Но речь идёт о плановом переходе. Если критичная ситуация уже случилась, нельзя откладывать восстановление до момента полного понимания устройства системы. Сначала решают проблему, фиксирую предпринятые для восстановления шаги. Причину сбоя и устройство затронутых компонентов подробно разбирают уже после того, как ситуация перестала приносить бизнесу убытки.</p> <h3>Первый релиз новой команды</h3> <p>После обследования почти всегда появляется длинный список накопившихся проблем: устаревшие зависимости, ручные операции, нехватка тестов, пробелы в документации. Возникает желание сразу всё исправить. Для переходного периода это плохая стратегия: чем больше изменений вносится одновременно, тем труднее понять причину нового сбоя.</p> <p>Сначала устраняют то, что угрожает данным и непрерывности работы: активные уязвимости, отсутствие резервного копирования, невозможность собрать или развернуть систему, отсутствие мониторинга и рабочего плана отката. Рефакторинг и архитектурные улучшения можно запланировать после стабилизации.</p> <p>Первый релиз лучше сделать небольшим, но полноценным. Команда меняет код, проводит тестирование, выпускает обновление, проверяет его в рабочей среде и при необходимости откатывает. При этом задача не должна быть крупной, чтобы возможная ошибка не повлияла на работу всей системы.</p> <h3>Где переход чаще всего срывается</h3> <p>Чаще всего проблемы возникают из-за спешки. Договор с прежней командой уже завершён, а новая ещё не успела проверить, как система ведёт себя в работе. На переходном этапе новой команде не стоит сразу перестраивать систему и обещать прежний уровень поддержки. Крупные изменения усложнят поиск причин возможных сбоев, а гарантировать прежний уровень сервиса можно только после проверки всех процессов.</p> <p>Поэтому передачу ответственности лучше отделить от больших изменений и предусмотреть время на стабилизацию. Это не означает, что развитие системы нужно полностью остановить. На переходном этапе можно выпускать небольшие изменения. Но крупные доработки, перестройку архитектуры и обновление ключевых компонентов лучше отложить. Если после них возникнет сбой, новой команде будет сложнее понять, связан он со старой проблемой или с внесёнными изменениями.</p> <p>Нередко проблемы случаются из-за отсутствия плана и четкой фиксации детальных фактов передачи. Здесь новая команда может говорить, что она уже все приняла и эксплуатирует, а на деле оказывается, что некоторые компоненты системы не были должным образом приняты: артефакты по ним не были получены, детали не были уточнены и выяснены. Бизнес может не понимать, что для стабильной работы системы и снижения рисков требуется потратить достаточно времени и уделить достаточно внимания процессу передачи. Желание бизнеса поскорее поставить точку может обернуться спешкой на уровне технической эксплуатации и невнимательностью, что в итоге создает риски.</p> <h3>Когда переход действительно завершён</h3> <p>Окончание договора и фактическая передача системы редко совпадают день в день. Для критичной системы ориентироваться лучше не на дату в календаре, а на несколько проверяемых признаков:</p> <ul> <li> компания контролирует код, инфраструктуру, домены, данные и внешние сервисы;</li> <li> новая команда получает оповещения и может самостоятельно найти причину сбоя;</li> <li> проверены сборка, выпуск обновления и откат;</li> <li> данные успешно восстановлены из резервной копии, а время восстановления измерено;</li> <li> критичные пользовательские сценарии и интеграции работают;</li> <li> известные риски, временные ограничения и ответственные за них зафиксированы.</li> </ul> <p>Если для диагностики, релиза или восстановления по-прежнему нужен специалист прежнего подрядчика, переход ещё не закончен. Подписанный акт этого не меняет.</p> <p>Передача заканчивается не в момент получения архива с кодом и документацией. Она заканчивается тогда, когда новая команда может самостоятельно поддерживать систему, а бизнес больше не зависит от знаний, доступов и решений прежнего подрядчика.</p> <p>#IMAGE_235309#</p> Менять подрядчика у работающей веб-системы — не то же самое, что передавать новый проект. Пока команды … article Надежда Кадырлеева, исполнительный директор DIGITAL SECTOR https://www.itweek.ru/themes/detail.php?ID=235286 Fri, 07 Aug 2026 00:00:00 +0300 <p><em>Сейчас в каждой отраслевой дискуссии об искусственном интеллекте, кажется, повторяется одно и то же предупреждение: ИИ будет выполнять бóльшую часть рутинной работы, доходы от услуг сократятся, а бизнес-модели, основанные на численности персонала, должны измениться, чтобы оставаться конкурентоспособными, пишут в корпоративном блоге Шилпи Ханда, заместитель директора IDC по исследованиям (регион META), и Шари Лава, вице-президент группы IDC по ИИ, данным и автоматизации.</em></p> <p>Это предупреждение не ошибочно. Но это лишь половина истории. Оно описывает только то, что ИИ может отнять у рынка по мере трансформации бизнеса. Почти никто не говорит о том, что ИИ создает одновременно: большой, устойчивый, пока невостребованный спрос на специфическую функцию проверки правильности выполнения работы ИИ.</p> <p>Существует исследование <nobr>40-летней</nobr> давности из области, не имеющей ничего общего с ПО, которое точно предсказало то, что происходит сейчас. В 1983 г. когнитивный психолог Лизанн Бейнбридж опубликовала короткую статью под названием «Ирония автоматизации», основанную на многолетнем изучении диспетчерских пунктов промышленных процессов. Ее вывод был таков: чем более комплексно вы автоматизируете систему, тем более, а не менее, востребованной становится роль человека. Почему? Потому что людям приходится выполнять именно те задачи, которые никто не смог автоматизировать, плюс совершенно новую работу, к которой их никто не готовил: контролировать систему, сбои в которой они больше не видят достаточно часто, чтобы их распознавать. Навыки, которые остаются без практики, ухудшаются. Опытный оператор, который проводит свои дни, наблюдая за работой автоматизации, вместо того, чтобы выполнять работу самому, незаметно превращается в неопытного оператора, даже не замечая этого перехода. Автоматизация же обычно работает правильно до того дня, когда перестает работать.</p> <p>Авиационная отрасль продемонстрировала реальную значимость этой идеи. В 1987 г. самолет Northwest Airlines разбился при взлете из Детройта, погибли 154 из 155 человек на борту. Экипаж привык к автоматизированной системе, которая проверяла правильность настройки закрылков и предкрылков для взлета. В тот день автоматическая проверка была отключена из-за сработавшего выключателя. Экипаж, привыкший к тому, что машина обнаруживает эту ошибку, не стал проверять её вручную. Самолёт пытался взлететь без настройки и не смог. В тот день ничего необычного не произошло: просто ординарная, очень человеческая ошибка — нежелание провести проверку, которую автоматизация незаметно сделала ненужной.</p> <p>Это закономерность. И она снова проявляется прямо сейчас во всех областях, где широко используются ИИ-помощники, и люди уже сталкиваются с этим. Молодые юристы перекладывают на ИИ юридические исследования и первые черновики — именно те упражнения, которые раньше формировали способность к юридическому суждению, — и фирмы открыто обеспокоены тем, что их новые сотрудники вообще не развивают способность оценивать результаты работы ИИ.</p> <p>Несколько отраслевых исследований 2026 г. в области разработки ПО указывают на аналогичную проблему: младшие разработчики, не имеющие базовых знаний в области архитектуры и безопасности, не могут надёжно судить о качестве кода, написанного ИИ, и по умолчанию доверяют ИИ больше, чем своим собственным инстинктам, которые так и не развились. На отраслевых мероприятиях по безопасности об этом было сказано более прямо: начинающие инженеры, выросшие на программировании с использованием ИИ, все чаще испытывают недостаток базовых знаний в области сетей и протоколов, до такой степени, что командам трудно даже объяснить внутреннюю угрозу безопасности, не говоря уже о ее выявлении.</p> <p>Итак, вопрос, который задают люди, но на который очень немногие дают ответ: да, рутинные, повторяющиеся задачи будут автоматизированы, эта часть истории верна и не вызывает сомнений, но у кого будут навыки проверки того, что сгенерировал ИИ? Кто сможет, взглянув на результат работы автономной системы, понять, правилен ли он, опираясь на реальный практический опыт? И когда что-то пойдет не так, когда ИИ нужно будет остановить, исправить или перезапустить посреди задачи, у кого еще останется мышечная память для этого? Все стремятся создать автоматизацию. А кто создаст возможности для ее проверки?</p> <h3>Версия этой проблемы, связанная с кибербезопасностью</h3> <p>Кибербезопасность — это наиболее острая версия этой проблемы на данный момент, потому что автоматизация в области кибербезопасности не просто на очереди, она уже здесь, работает без контроля, в производственной среде.</p> <p>Каждая крупная платформа SOC переходит от «второго пилота» (ИИ отвечает на вопросы, человек действует) к «агентному ИИ» (ИИ действует, человек получает уведомление после этого). Автономные агенты сортировки теперь самостоятельно закрывают оповещения о низком риске и запускают действия по локализации с высокой, по их собственным оценкам, точностью, измеряемой, естественно, поставщиком, разработавшим систему, на основе собственных размеченных данных этого поставщика. В настоящее время нет независимой стороны, проверяющей эти данные. И среди специалистов явно существуют разногласия относительно того, насколько им можно доверять: сейчас часто можно услышать, как команды безопасности признаются, что они игнорируют рекомендации, сгенерированные ИИ, вместо того, чтобы действовать в соответствии с ними, потому что результат звучит уверенно, даже когда он иногда оказывается неверным. ИИ обучается на основе научных статей, поэтому в нем заложена предвзятость в сторону уверенности.</p> <p>Та же картина наблюдается и в тестировании. Автономные ИИ-агенты тестирования теперь находят и сообщают о реальных уязвимостях быстрее, чем это могла бы сделать любая человеческая команда. Это настоящее достижение. Но это уже нарушило конвейер обнаружения уязвимостей: по крайней мере, одна крупная платформа по поиску ошибок приостановила давно действующую программу поощрений и сократила выплаты после того, как исследования с помощью ИИ увеличили объем заявок далеко за пределы того, что могли обрабатывать сопровождающие, а несколько Open Source-проектов приостановили свои программы вознаграждений из-за потока правдоподобно звучащих, низкокачественных отчетов, созданных ИИ. Ограничения в наступательной безопасности заметно сместились с поиска проблем на их проверку, но почти никто не продает услуги проверки.</p> <p>Это, совершенно точно, пробел, и в сфере кибербезопасности для него пока нет названия. Итак, давайте дадим ему два.</p> <ul> <li><strong>AVaaS (</strong><strong>AI Validation-as-a-Service</strong><strong>): </strong><strong>валидация</strong> <strong>ИИ</strong> <strong>как</strong> <strong>услуга</strong><strong>. </strong>Название позаимствовано по аналогии с PTaaS (пентест как услуга) и MDR (управляемое обнаружение и реагирование), которые уже привычны для покупателей услуг в области безопасности, и применено к категории, у которой пока нет названия. Задача независимой стороны — сверить то, что на самом деле решил ваш ИИ, с тем, что, по его словам, он решил. Это означает, что автономные действия SOC будут сравниваться с эталонными данными, которые не создавались ИИ. Это означает, что результаты автономного пентеста будут проверяться так же, как старший тестировщик со скепсисом относится к отчёту младшего: не только на предмет того, попал ли он в цель, но и на предмет того, был ли путь к цели верным. Это не оценка и не использование большой языковой модели в качестве судьи под новым названием. AVaaS — это независимая и подотчётная проверка, проводимая человеком. Это именно то, что требуется регулятору, совету директоров или клиенту, и именно то, для чего никогда не предназначалась оценка.</li> <li><strong>AJQ (</strong><strong>AI</strong> <strong>Judgment</strong> <strong>Quotient</strong><strong>)</strong><strong>: оценка суждений ИИ.</strong> Индивидуальная версия той же идеи: способ обозначить конкретный навык, который можно развить, — умение понимать, когда стоит доверять выводам ИИ, а когда — оспаривать их, отдельно от умения правильно формулировать запросы к ИИ, которым сейчас все одержимы. Умение формулировать промпты позволяет получить более качественный и быстрый ответ, как если бы вы задали вопрос человеку. AJQ — это то, что позволяет понять, правильный ли получен ответ. Пока никто не нанимает людей с таким навыком. Но это ненадолго.</li> </ul> <h3>Попутный аспект комплаенса, который почти никто не учитывает</h3> <p>Есть также регуляторный аспект, и его стоит уточнить, поскольку обобщенная версия этого аргумента его преувеличивает. Большинство повседневных применений ИИ в сфере кибербезопасности, например, «второй пилот» SOC, занимающийся сортировкой фишинга, или агент пентестинга, сканирующий SaaS-приложение, автоматически не подпадают под правила высокого риска Закона ЕС об ИИ. Но одна категория в рамках этого закона напрямую относится к кибербезопасности. Это системы ИИ, используемые в качестве компонента безопасности при управлении и эксплуатации критической цифровой инфраструктуры: коммунальные предприятия, операционные технологии и системы управления промышленными процессами, где сбой системы безопасности или обнаружения аномалий может иметь физические последствия. По умолчанию это системы высокого риска, и закон требует реального, работающего человеческого контроля: человека, который может отслеживать, понимать, отключать и останавливать систему на практике, причем эта возможность должна быть продемонстрирована, а не предполагаться.</p> <p>Регуляторы не будут удовлетворены политикой, которая гласит, что существует аварийный выключатель. Они будут спрашивать, пытался ли кто-нибудь его активировать под давлением и подтвердил ли он его работоспособность. Это конкретное, проверяемое утверждение, и его легко продать. Крайний срок просто перенесли на декабрь 2027 г. Эта более поздняя дата дает запас времени, чтобы стать очевидным, заслуживающим доверия и подтвержденным поставщиком в этой области, прежде чем каждая консалтинговая фирма в мире начнет демонстрировать тот же самый слайд.</p> <p>Это реальная ниша. Оригинальная рыночная категория, без существующих игроков, созданная на основе трех вещей, которые, независимо друг от друга, проверяемо верны прямо сейчас: ИИ уже принимает неконтролируемые решения по безопасности в производственной среде; люди, которые исторически могли выявлять его ошибки, — это те же самые люди, чьи базовые навыки незаметно разрушаются из-за бездействия; и регулятор вот-вот начнет письменно спрашивать, проверял ли кто-нибудь это на самом деле. Итак, посмотрим, кто создаст этот рынок первым.</p> Сейчас в каждой отраслевой дискуссии об искусственном интеллекте, кажется, повторяется одно и то же … article https://www.itweek.ru/themes/detail.php?ID=235304 Thu, 06 Aug 2026 16:31:10 +0300 <p>Весной 2026 года правоохранительные органы США, Канады и Германии провели скоординированную <a href="https://www.securityweek.com/aisuru-and-kimwolf-ddos-botnets-disrupted-in-international-operation/">операцию</a> против инфраструктуры нескольких крупных DDoS-ботнетов, включая Aisuru и KimWolf. Примерно в тот же период на инфраструктуре CURATOR было отмечено заметное сокращение размера крупнейшего ботнета, зафиксированного при нейтрализации L7-атак в сети CURATOR: с рекордных 13,5 млн. устройств в первом квартале 2026 года до 2,09 млн. во втором — почти в шесть с половиной раз меньше. На первый взгляд, это выглядит как безусловная победа правоохранителей. Но у экспертов по сетевой инфраструктуре есть все основания считать её временной.</p> <h3>Одна операция не решает проблему</h3> <p>Резонно предположить, что снижение размера ботнета — прямое следствие операции правоохранителей. Отчасти это действительно так. Но это лишь одна из причин, и, вероятно, не главная. Значительная часть заражённых устройств сосредоточена в развивающихся регионах — Латинской Америке и Юго-Восточной Азии, где массово используются уязвимые Android-приставки для стриминга. Плановая замена оборудования интернет-провайдерами, обновления прошивок и изменения сетевых политик сами по себе постепенно вымывают часть заражённых хостов из ботнета — вне всякой связи с конкретной правоохранительной операцией. Так что говорить, что зачистка «выключила» ботнет, было бы упрощением: снижение его размера — результат наложения нескольких процессов, один из которых — резонанс вокруг операции, заставивший вендоров, провайдеров и CERT-группы активнее заниматься ремедиацией уязвимых устройств.</p> <p>Крупные правоохранительные операции, безусловно, приносят пользу, но они едва ли способны дать долгосрочное решение проблемы киберпреступности в принципе. Причина — в самой архитектуре интернета.</p> <p>Фундаментальная сложность заключается в том, что интернет децентрализован, а киберпреступность представляет собой глобальную проблему, тогда как полномочия правоохранительных органов по-прежнему ограничены национальными юрисдикциями. Кибератаки давно перестали считаться с государственными границами, а вот расследования и судебные процессы — нет.</p> <p>Свою роль играет и политический фактор: в ряде стран определённые группы действуют в интересах государственных или иных политических структур, они получают финансирование, накапливают экспертизу, разрабатывают новые инструменты и техники атак. Со временем эти наработки выходят за пределы первоначального контекста и расходятся по теневым площадкам, закрытым сообществам и криминальным экосистемам — так продвинутые возможности становятся доступны гораздо более широкому кругу злоумышленников.</p> <p>Ещё одна системная сложность — в том, что жертва, атакующая инфраструктура и сам оператор атаки нередко находятся в разных юрисдикциях. Организацию атакуют в одной стране, инфраструктура для атаки размещена в другой, а операторы — в третьей. Сбор доказательств, координация расследования и последующее привлечение виновных к ответственности превращаются в крайне сложную международную процедуру.</p> <h3>Технологии меняют баланс сил</h3> <p>Проблему усугубляет то, что новые технологии всё сильнее смещают баланс сил в пользу атакующих. Современные блокчейн-платформы, например, технически позволяют использовать зашифрованные смарт-контракты и другие децентрализованные механизмы для распространения команд и координации ботнетов. Эти подходы пока только формируются, но уже способны сделать вредоносную инфраструктуру значительно более устойчивой и куда менее уязвимой для выявления и атрибуции — в отличие от классических C2-серверов, которые можно относительно легко обнаружить и отключить.</p> <p>Параллельно ИИ заметно упрощает и ускоряет сам процесс поиска и компрометации уязвимых устройств: автоматизированная разведка, обнаружение уязвимостей и приоритизация целей позволяют злоумышленникам восполнять пул заражённых устройств быстрее, чем раньше.</p> <p>Здесь, пожалуй, уместна аналогия из физического мира: появился принципиально новый тип угрозы, под который существующие механизмы обнаружения и реагирования изначально не проектировались. Технологии развиваются заметно быстрее, чем регуляторная база и возможности правоприменения — из-за этого разрыва между атакующими и защитниками неизбежно возникает период асимметрии, и текущий момент — как раз такой период.</p> <h3>Расслабляться не стоит</h3> <p>Разовая, пусть и крупная, правоохранительная операция снижает размер конкретного ботнета, но не меняет структурных предпосылок его появления: дешёвые уязвимые устройства, растущая доступность ИИ-инструментов для автоматизации атак и переход операторов к более устойчивым и децентрализованным схемам управления. Именно поэтому мы не ожидаем долгосрочного эффекта от подобных зачисток. Конкретный ботнет может и не восстановиться в прежнем виде, однако на его месте будут появляться новые сети — потенциально быстрее, чем раньше, и с более устойчивой архитектурой управления. </p> <p>Для бизнеса вывод из этой ситуации достаточно прост: уменьшение одного крупного ботнета нельзя воспринимать как общее снижение потенциального риска. Компаниям необходимо исходить не из размеров конкретной обнаруженной сети, а из того, что инструменты создания и восстановления атакующей инфраструктуры становятся доступнее. Защита от DDoS должна рассматриваться не как реакция на отдельные инциденты, а как постоянная часть управления операционной устойчивостью — с регулярным тестированием инфраструктуры, пересмотром сценариев атак и оценкой способности провайдера защиты справляться не только с ростом интенсивности, но и с изменением самих методов атак.</p> <p>В конечном счёте разговор стоит вести не в логике «полиция против хакеров», а в логике безопасности всей экосистемы. Долгосрочный прогресс будет зависеть не только от того, насколько успешно ботнеты демонтируют уже после их появления, но и от того, удастся ли сократить число уязвимых устройств, подключённых к интернету, повысить базовые требования к безопасности у производителей, укрепить сотрудничество между вендорами, интернет-провайдерами, компаниями из сферы кибербезопасности и правоохранительными органами. Главный показатель успеха — не количество уничтоженных ботнетов, а то, насколько сложно и дорого злоумышленникам становится создавать новые.</p> <p>#IMAGE_235305#</p> Весной 2026 года правоохранительные органы США, Канады и Германии провели скоординированную операцию против инфраструктуры … article Дмитрий Ткачёв, генеральный директор CURATOR https://www.itweek.ru/themes/detail.php?ID=235303 Thu, 06 Aug 2026 16:26:27 +0300 <p>Технологическая компания YADRO (входит в ИКС Холдинг) открыла прием заказов на новую, старшую модель в линейке специализированных систем резервного копирования — TATLIN.BACKUP.L. Новая модель отличается увеличенным объемом полезной емкости более 1 Пб и двумя контроллерами хранения для дополнительной отказоустойчивости. Решение разработано специально для крупных корпоративных сред с повышенными требованиями к доступности данных и объему их хранения.</p> <p>Выход модели TATLIN.BACKUP.L приурочен к релизу масштабного обновления ПО v1.5 для всей линейки систем хранения резервных копий. В дополнение к технологиям дедупликации и компрессии данных, в системе появилась асинхронная репликация на уровне виртуальных файловых систем. Технология позволяет регулярно передавать данные на удаленную площадку для гарантированного восстановления в случае аварии на основном ЦОД. Также упростилась процедура самостоятельной замены дисков (CRU). Кроме того, был расширен комплекс мер безопасности, улучшен аудит логов при подключении по протоколу T-BOOST и обновлены инструменты мониторинга и управления системой. Это обеспечивает надежное и эффективное хранение огромных массивов информации и упрощает администрирование.</p> <p>Помимо новых функциональных возможностей, с выходом обновления v1.5 заказчикам стали доступны оптимизированные конфигурации систем TATLIN.BACKUP, оснащенные контроллерами хранения с 1,5 Тб оперативной памяти. Благодаря программным доработкам производительность системы сопоставима с конфигурациями с 2 Тб оперативной памяти в малых инсталляциях полезной емкостью до 380 Тб. При дальнейшем росте объемов данных и расширении ИТ-сценариев рекомендуется использовать максимальную конфигурацию с 2 Тб оперативной памяти.</p> <p>«Обновление 1.5 — один из самых масштабных и значимых релизов в истории TATLIN.BACKUP. Старшая модель TATLIN.BACKUP.L создавалась специально для крупнейших ИТ-инфраструктур с бескомпромиссными требованиями к доступности данных. В то же время новые конфигурации TATLIN.BACKUP оптимизируют стоимость владения решением без компромиссов в производительности, что особенно важно в условиях роста цен на электронные компоненты. Отдельное ключевое направление этого релиза — репликация. Она повышает сетевую эффективность, безопасность и киберустойчивость системы, а также формирует технологическую основу для режима „Бункер“, который мы реализуем в следующей версии 1.6», — отметил Владислав Леонтьев, старший менеджер продукта TATLIN.BACKUP компании YADRO.</p> <p>В дальнейших планах YADRO — развитие интеграций репликации с решениями технологических партнеров в сегменте программного обеспечения для резервного копирования. Кроме того, в будущих обновлениях инженерная команда продолжит развивать механизмы защиты резервных копий, включая поддержку неизменяемых резервных копий WORM и режим «Бункер».</p> <p>Новая старшая модель TATLIN.BACKUP.L уже доступна для демонстрационного тестирования. Подать заявку, ознакомиться с техническими характеристиками и получить консультацию экспертов можно на странице линейки TATLIN.BACKUP на сайте YADRO.</p> Технологическая компания YADRO (входит в ИКС Холдинг) открыла прием заказов на новую, старшую модель в линейке … message https://www.itweek.ru/themes/detail.php?ID=235302 Thu, 06 Aug 2026 16:20:34 +0300 <p>Институт статистических исследований и экономики знаний (ИСИЭЗ) НИУ ВШЭ на основе опросов ученых и руководителей организаций сферы науки изучил, какую роль они отводят государству в поддержке ИИ и какую именно помощь ожидают.</p> <p>Более двух третей опрошенных ученых (67%) и руководителей организаций сферы науки (72%) считают, что государство должно прежде всего создавать благоприятные условия для применения ИИ в исследованиях.</p> <p>Столь же согласованны позиции респондентов в отношении жестких мер, таких как ограничения на использование ИИ в науке, введение целевых показателей в данной сфере и мониторинг их достижения. Эти меры не поддерживают около 70% ученых и 60% руководителей организаций.</p> <p>Относительно допустимых форм госрегулирования ИИ в науке у академического сообщества нет единой позиции. Невмешательство государства в выбор технологий и способы их применения поддерживают 58% ученых и 36% руководителей организаций. В то же время около 40% опрошенных в обеих группах выступают за более активное участие государства, в том числе за контроль в этой сфере. Расхождение может отражать сохраняющуюся неопределенность относительно оптимальных механизмов госучастия в отсутствие единой стратегии ИИ-трансформации науки.</p> <p>В целом респонденты в обеих группах ожидают положительного эффекта от перспективных мер поддержки, прежде всего направленных на расширение ресурсных возможностей научных организаций. Более 80% респондентов позитивно оценивают: централизованный доступ к вычислительным мощностям и целевое финансирование закупок оборудования для их расширения; поддержку междисциплинарных команд, объединяющих специалистов по ИИ и исследователей-предметников; оплату подписок на ИИ-сервисы для государственных вузов и НИИ; долгосрочное финансирование проектов с применением ИИ; создание репозиториев датасетов и ИИ-моделей.</p> <p>Несколько сдержаннее респонденты оценивают институциональные меры — разработку единых стандартов качества датасетов и официальных рекомендаций по ответственному и корректному использованию ИИ. Тем не менее около 70% опрошенных ожидают, что и эти инициативы улучшат условия проведения исследований.</p> <p>Неоднозначную реакцию вызывает только предложение создать систему оценки эффективности использования ИИ в научных исследованиях. Положительного эффекта от нее ожидают менее половины ученых и руководителей организаций. В то же время 29% ученых и 22% руководителей считают, что такая система, напротив, ухудшит условия выполнения исследований и разработок.</p> <p>Опросы ИСИЭЗ НИУ ВШЭ показали, что академическое сообщество ожидает от государства прежде всего доступа к инфраструктуре, финансированию, сервисам и данным, но не жесткого контроля, ограничений и директивных показателей. Такая поддерживающая модель соответствует подходам стран — научных лидеров, принявших национальные стратегии ИИ-трансформации науки. Активное применение ИИ для повышения качества и эффективности исследований и разработок относится к приоритетам, закрепленным в Стратегии научно-технологического развития РФ.</p> Институт статистических исследований и экономики знаний (ИСИЭЗ) НИУ ВШЭ на основе опросов ученых и руководителей … message https://www.itweek.ru/themes/detail.php?ID=235301 Thu, 06 Aug 2026 16:19:07 +0300 <p>В 2026 году бизнес стал активнее выносить ИИ-нагрузки в облако, чтобы не строить собственный GPU-кластер, а использовать мощности провайдера по запросу. Глобальный рынок GPU-as-a-Service достиг $6,07 млрд в 2025 году и растет темпами 44% ежегодно, по оценкам Fortune Business Insights, но параллельно растет и объем финансовых потерь — по данным аналитиков M1Cloud, до трети всех облачных расходов могут быть потрачены неэффективно на неиспользуемые или неоптимально сконфигурированные ресурсы. Для GPU-инфраструктуры, где стоимость одного часа вычислений в разы выше обычных серверов, цена ошибки пропорционально больше. Владимир Лебедев, директор по развитию бизнеса M1Cloud, рассказал, что для облачной ИИ-инфраструктуры требуются зрелые практики управления облачными затратами.</p> <p>На российском рынке доступ к новейшим GPU ограничен логистическими сложностями, а стоимость собственного оборудования включает существенную наценку за поставку. Компания, решившая построить собственный GPU-кластер, сталкивается не только с капитальными затратами, но и с риском технологического устаревания: цикл смены поколений GPU сократился до 18 месяцев, и кластер, закупленный сегодня, через полтора года будет уступать по производительности на затраченную единицу энергии. Облачный провайдер аккумулирует GPU-ресурсы и обеспечивает их высокую утилизацию за счет мультитенантности.</p> <p>Когда компания запускает ИИ-проект, основное внимание обычно сосредоточено на обучении модели — и именно под эту задачу планируется бюджет на облако. Но обучение — это конечный этап: недели или месяцы интенсивных вычислений, после которых модель готова к работе. А дальше начинается инференс — обработка реальных запросов пользователей, которая длится годами и может составить от 80 до 90% совокупных затрат на ИИ-систему за весь ее жизненный цикл. По данным Polaris Market Research, глобальный рынок ИИ-инференса оценивался в $106 млрд в 2025 году, с темпом роста в среднем на 19,4%. Для облачного провайдера это означает, что основной спрос на GPU-мощности генерируется не разработчиками моделей, а бизнесом, который эксплуатирует ИИ в продакшене — и именно этот бизнес нуждается в совершенно иной модели потребления облачных ресурсов.</p> <p>Обучение модели — это предсказуемая нагрузка: команда знает объем данных и тип GPU. Под такую задачу легко зарезервировать ресурсы и спрогнозировать бюджет. Нагрузка инференса зависит от числа пользователей, времени суток, сезонности, маркетинговых кампаний. Утром чат-бот обрабатывает 500 запросов в минуту, в обед — 5000, ночью — 50. Облачная инфраструктура должна обеспечивать масштабирование, чтобы бизнес не платил за простаивающие GPU в часы минимальной нагрузки и не терял клиентов из-за нехватки мощностей в пиковые моменты. Именно здесь проявляется ключевое преимущество облачной модели перед собственной инфраструктурой: провайдер распределяет пиковые нагрузки множества заказчиков по общему пулу ресурсов, обеспечивая каждому эластичность, которую практически невозможно получить на собственном оборудовании.</p> <p>По данным FinOps Foundation, в 2026 году 98% компаний управляют не только облачными затратами, но и ИИ-расходами — против 31% всего два года назад. Этот взрывной рост отражает масштаб проблемы: средняя утилизация GPU-инстансов в корпоративных средах составляет порядка <nobr>20-30%,</nobr> что означает, что компании арендуют в облаке втрое больше мощностей, чем реально используют, потому что зачастую разработчики резервируют GPU с запасом, забытые тестовые среды продолжают потреблять ресурсы, отсутствует автоматическое выключение инстансов после завершения задач.</p> <p>Зрелые провайдеры проводят аудит ресурсов и дают рекомендации по оптимизации (переход на меньший инстанс, использование spot-мощностей для некритичных задач, снижение требований к GPU). Фактически провайдер берет на себя роль FinOps-консультанта, помогая заказчику оптимизировать облачные ресурсы.</p> <p>Помимо этого, опытный провайдер помогает правильно выбрать конфигурацию облачной инфраструктуры под конкретный тип ИИ-нагрузки и под разные сценарии. Обучение крупной модели требует кластера с высокоскоростным интерконнектом между GPU и большим объемом видеопамяти. Инференс, напротив, чаще всего работает на одиночных GPU или даже на специализированных ускорителях с меньшей памятью, но более высокой пропускной способностью.</p> <p>Модели в продакшене генерируют логи, метрики, результаты инференса, которые необходимо хранить для мониторинга качества и дообучения. Объем этих данных растет пропорционально числу запросов, и через несколько месяцев эксплуатации затраты на хранение могут сравняться с затратами на сами вычисления. Провайдер, предлагающий интегрированную экосистему — GPU-вычисления, хранилище, инструменты мониторинга в рамках единого биллинга — избавляет заказчика от необходимости собирать инфраструктуру из разрозненных сервисов и контролировать затраты в нескольких системах одновременно.</p> <p>Сегодня облачная инфраструктура для ИИ — это комплексная услуга, включающая эластичное масштабирование под непредсказуемые инференс-нагрузки, подбор оптимальных конфигураций под тип задачи, инструменты финансового управления затратами, экспертизу в оптимизации потребления и защиту от рисков технологического устаревания. Провайдер, который выстраивает эту экосистему, становится для заказчика не поставщиком ресурсов, а стратегическим партнером в построении экономически устойчивой ИИ-стратегии.</p> В 2026 году бизнес стал активнее выносить ИИ-нагрузки в облако, чтобы не строить собственный GPU-кластер … message https://www.itweek.ru/themes/detail.php?ID=235300 Thu, 06 Aug 2026 16:13:26 +0300 <p>Компания Innostage существенно обновила Innostage TDIR — решение для интеллектуальной автоматизации деятельности центров мониторинга и реагирования на инциденты информационной безопасности (SOC). Версия 1.0.0 получила множество улучшений, касающихся интеграции с SOAR, генерации запросов в SIEM, проверки инцидентов и рекомендациям по реагированию, взаимодействия с ИИ-чатом и другие.</p> <p>Innostage TDIR — решение, разработанное на базе искусственного интеллекта, которое развертывается On-Premise и работает в связке с SIEM и SOAR-системами организации, усиливая их эффективность за счет снижения количества ложноположительных срабатываний и исторической корреляции событий.</p> <p>Расширены возможности автоматизированной обработки инцидентов информационной безопасности, включая интеграцию с SOAR-системами: скорректирована логика обработки поля DeviceAddress из TSV-файла, реализован парсинг дополнительных полей и их использование при обработке инцидентов. Улучшен механизм определения геолокации IP-адресов при обогащении объектов, а в интерфейсе теперь отображается объект, для которого было выполнено обогащение. Кроме того, доработана логика отображения блока «Исходные события», его содержимое теперь зависит от фактического количества событий.</p> <p>Помимо этого, модернизированы процессы автоматизированной генерации запросов в SIEM: скорректирован алгоритм запросов для инцидентов «Спам-рассылка» и для случая множественных вхождений объектов, исправлена ошибка при формировании запросов по превентивным мерам. </p> <p>Улучшены функции интеллектуальной проверки инцидентов: фильтрации ложноположительных срабатываний (AntiFP), рекомендаций по реагированию. Усовершенствованы размышления LLM по индикаторам компрометации (IoC/POSH). В части работы с базой знаний MITRE ATT&CK — обновлены справочники по теме разделения митигаций и техник, улучшено предоставление ответов ИИ-ассистента. </p> <p>Взаимодействие пользователей с ИИ-чатом для поиска информации в области ИБ стало удобнее: реализована отмена генерации ответа по кнопке, исправлена ошибка «OpenTIP request timed out» при редиректе. В версии 1.0.0 обновлена большая языковая модель (LLM): осуществлен переход с Qwen 2.5 на Qwen 3.x. </p> <p>Кроме того, реализован ряд доработок интерфейса: исключен блок «Аналитический отчет», который дублировал информацию отчета по инциденту, улучшен внешний вид раздела «Накопленная база правил», скорректировано визуальное отображение тегов на инцидентах, улучшен механизм переключения темы (темная, светлая, системная). </p> <p>Новая версия решения уже внедрена и успешно функционирует в контуре заказчика — крупном российском предприятии химической отрасли. </p> <p>«Innostage TDIR — решение, которое объединяет в себе функциональность по усилению существующих SIEM/SOAR-систем и интеллектуальную аналитику. Благодаря этому оно повышает эффективность работы специалистов SOC по выявлению и предотвращению актуальных угроз, а также значительно снижает нагрузку на команду, позволяя компаниям масштабировать процессы кибербезопасности», — прокомментировал Искандер Тиморшин, владелец продукта Innostage TDIR.</p> <p>«Применение Innostage TDIR напрямую влияет на ключевые операционные показатели SOC-команд: аналитики избавляются от большого объема рутины, тем самым снижается риск профессионального выгорания. Процессы становятся более оперативными и упорядоченными, внутри команд формируется и быстро накапливается экспертиза, что является надежной базой для дальнейших расследований», — добавил Никита Радионов, заместитель директора по развитию продуктов Innostage.</p> Компания Innostage существенно обновила Innostage TDIR — решение для интеллектуальной автоматизации деятельности центров … message https://www.itweek.ru/themes/detail.php?ID=235299 Thu, 06 Aug 2026 16:10:02 +0300 <p>Система защиты от утечек информации (DLP) «СёрчИнформ КИБ» расширила возможности ИИ-Ассистента: теперь умный модуль позволяет ИБ-специалистам самостоятельно создавать промпты для поиска инцидентов. Это поможет адаптировать инструмент под индивидуальные задачи заказчиков.</p> <p>Пользовательские промпты пишутся в интерфейсе КИБ на естественном языке без кода и регулярных выражений. В системе есть пример наиболее эффективной структуры, содержания и объема промпта. Запрос для нейросети будет работать как ИИ-политика безопасности: автоматически проверять коммуникации сотрудников и уведомлять службу ИБ о нарушениях. Функция дополняет набор преднастроенных ИИ-политик в КИБ: по поиску утечек, корпоративного мошенничества и контролю групп риска.</p> <p>«Кастомизация запросов к ИИ-Ассистенту в КИБ помогает решить нестандартные задачи и делает инструмент гибче. Если нужно найти обсуждения тем, характерных для конкретной отрасли, выявить подозрительные манипуляции с данными при их пересылке и так далее. Готовые ИИ-политики „отрабатывают“ темы, актуальные для любой компании. А с помощью пользовательских промптов можно будет сузить фокус для персонализированных расследований, — объяснил начальник отдела безопасности „СёрчИнформ“ Алексей Дрозд. — Промпт может быть любым, дальше все зависит от мощности оборудования и объема данных, которые попадут под проверку ИИ. Создать свой промпт просто, если воспользоваться встроенными в интерфейс рекомендациями».</p> <p>Задать фокус для ИИ-политик можно с помощью фильтров. В обновлении появилась возможность выбирать, в каких мессенджерах и соцсетях нужно анализировать чаты, а также исключать из проверки информационные каналы. Похожая логика работает для почты: теперь ИБ-специалисты могут указать, какие почтовые ящики проверять или не проверять по ИИ-политикам.</p> <p>ИИ-Ассистент появился в КИБ в начале 2026 года. Это встраиваемый компонент на основе большой языковой модели (LLM), который бесшовно интегрируется в систему и работает в ее интерфейсе. Инструмент позволяет обнаруживать скрытые и замаскированные инциденты безопасности, которые невозможно найти классическими алгоритмами. Также ИИ-Ассистент составляет краткие резюме цепочек писем, чатов и документов, которыми обмениваются пользователи, и в реальном времени переводит со 120 языков. Инструмент разворачивается локально, так что корпоративные данные не покидают корпоративный периметр.</p> Система защиты от утечек информации (DLP) «СёрчИнформ КИБ» расширила возможности ИИ-Ассистента: теперь умный модуль … message https://www.itweek.ru/themes/detail.php?ID=235284 Thu, 06 Aug 2026 00:00:00 +0300 <p><em>Искусственный интеллект больше не является функцией будущего в области безопасности приложений (AppSec); он быстро становится основной частью того, как AppSec-инструменты выявляют, приоритизируют и устраняют риски. Тем не менее, несмотря на активные инвестиции поставщиков, внедрение по-прежнему сдерживается опасениями по поводу доверия, вопросами ценности и неопределенностью в отношении моделей ценообразования, пишут в корпоративном блоге Джанет Уортингтон, старший аналитик </em><em>Forrester</em><em>, Сэнди Кариелли, вице-президент и главный аналитик </em><em>Forrester</em><em>, и Элли Меллен, главный аналитик </em><em>Forrester</em><em>.</em></p> <p>В новом отчете Forrester «The State Of Artificial Intelligence In Security Tools: Application Security» мы проанализировали ответы 31 поставщика решений в области безопасности приложений, чтобы понять, где ИИ приносит пользу сегодня и куда движется рынок.</p> <p>Вот три ключевых вывода.</p> <h3>1. Отсутствие доверия остается самым большим препятствием для внедрения</h3> <p>Рынок безопасности приложений находится в необычном положении. Поставщики стремятся внедрить возможности ИИ в свои продукты, в то время как многие покупатели по-прежнему скептически относятся к результатам.</p> <p>Команды AppSec проявляют особую осторожность, поскольку многие функции, использующие ИИ, требуют доступа к конфиденциальному проприетарному коду или должны давать рекомендации, которые могут повлиять на производственные системы. Хотя организации стремятся повысить эффективность и сократить трудозатраты, они также балансируют между вопросами точности, конфиденциальности, управления и объяснимости. В результате доверие по-прежнему важнее технических возможностей как основной фактор, определяющий внедрение.</p> <p>Задача для поставщиков больше не состоит в том, чтобы доказать, что ИИ может генерировать результаты. Задача состоит в том, чтобы доказать, что пользователи могут полагаться на эти результаты.</p> <h3>2. Ценность ИИ сосредоточена в практических улучшениях на уровне рабочих процессов</h3> <p>Несмотря на ажиотаж вокруг автономных систем, наиболее успешные сегодня функции ИИ отличаются исключительной практичностью.</p> <p>Наше исследование показало, что поставщики видят наибольшее внедрение клиентами таких возможностей, как анализ данных, обобщение информации, рекомендации по правилам и рекомендации по реагированию. Эти функции помогают командам безопасности и разработки разобраться в огромных массивах данных по безопасности и сократить трудозатраты на выполнение рутинных задач.</p> <p>Приведенная ниже диаграмма иллюстрирует важную динамику, указывая на возможность для поставщиков, которые сегодня этого не делают, использовать ИИ для предоставления рекомендуемых ответов или правил и добавлять эти функции в свои предложения для повышения ценности для клиентов.</p> <p>#IMAGE_235285#</p> <p>Победителями в сфере ИИ для безопасности приложений не обязательно станут поставщики с наибольшим количеством функций. Это будут поставщики, которые помогут командам принимать более эффективные решения быстрее.</p> <h3>3. Ценообразование становится конкурентным дифференциатором</h3> <p>Один из наиболее неожиданных выводов исследования касается подхода поставщиков к монетизации.</p> <p>Многие поставщики решений в области безопасности приложений в настоящее время включают возможности ИИ в свои существующие предложения, а не взимают за них отдельную плату. Другие экспериментируют с гибридными подходами, моделями дополнений и ценообразованием на основе потребления для более продвинутых возможностей, таких как автоматическое устранение неполадок, анализ с интенсивным рассуждением или агентные рабочие процессы.</p> <p>Конкретные варианты ценообразования разнообразны, но общий вывод очевиден: рынок еще не определился с единой стратегией монетизации. Руководителям служб безопасности, оценивающим AppSec-продукты с использованием ИИ, следует смотреть дальше заявленной функциональности и тщательно оценивать, насколько цена соответствует ожидаемому использованию, ценности и операционным результатам.</p> <h3>Что дальше?</h3> <p>Сегодня возможности ИИ в области безопасности приложений в основном носят вспомогательный характер. Но поставщики уже смотрят дальше обобщения и рекомендаций в сторону агентных рабочих процессов, автоматизации и, в конечном итоге, автономных операций по обеспечению безопасности.</p> <p>Ключевой вопрос для руководителей служб безопасности больше не в том, станет ли ИИ частью программ обеспечения безопасности приложений. Вопрос в том, какие возможности обеспечивают значимую коммерческую ценность сегодня, а какие остаются нереализованными.</p> Искусственный интеллект больше не является функцией будущего в области безопасности приложений (AppSec); он быстро … article https://www.itweek.ru/themes/detail.php?ID=235297 Wed, 05 Aug 2026 16:45:27 +0300 <p>Компании АТОЛ и «Актив» подтвердили совместимость кассового программного обеспечения SIGMA Касса с активными ключевыми устройствами из линейки Рутокен ЭЦП 3.0. Тестирование производилось на смарт-терминалах: АТОЛ SIGMA 7, SIGMA 10, АТОЛ СТБ 5 и СТБ 6.</p> <p>Совместимость подтверждена для ПО SIGMA Касса версии 3.34.0.0 с модулем «Маркировка» на ОС АТОЛ ОС 7 и АТОЛ ОС 13 на базе Android 7 и 13. </p> <p>Что это дает пользователям:</p> <ul> <li>устройства Рутокен подписывают УПД (универсальный передаточный документ) при обмене данными с системой «Честный знак», что критично для торговли товарами, подлежащими обязательной маркировке;</li> <li>подписание и шифрование документов происходит с использованием неизвлекаемых ключей на сертифицированных носителях Рутокен, что исключает риски компрометации данных;</li> <li>использование Рутокен для входа в сервисы АТОЛ и для работы с API «Честного знака» упрощает администрирование и повышает уровень контроля доступа;</li> <li>интеграция работает «из коробки» на всех устройствах SIGMA с версией ПО 3.34.0.0 и не требует установки дополнительных драйверов или модулей.</li> </ul> <p>Таким образом, пользователи SIGMA Касса получают удобные средства подписания и шифрования документов, а также надежный способ аутентификации без усложнения ИТ-инфраструктуры и дополнительных затрат. </p> <p>Игорь Вааг, заместитель генерального директора АТОЛ, отметил: «Рутокен — надежный инструмент для криптографических операций, который мы используем в наших устройствах уже давно. Получение сертификата совместимости подтверждает высокий уровень интеграции и дает нашим клиентам уверенность в том, что работа с электронной подписью, маркировкой и ЭДО на устройствах АТОЛ SIGMA полностью соответствует требованиям безопасности и законодательства».</p> <p>Павел Анфимов, заместитель директора по управлению продуктами компании «Актив», отметил: «Сотрудничество с АТОЛ — яркий пример того, как современные криптографические решения применяются в бизнес-системах для широкого круга бизнес-пользователей. Подтверждение совместимости Рутокен с линейкой смарт-терминалов SIGMA — это закономерный итог нашей совместной работы. Мы рады, что наши устройства помогают обеспечивать безопасность при работе с маркировкой, электронным документооборотом и авторизацией в сервисах. Для нас важно, чтобы наши общие заказчики получали надежный и сертифицированный инструмент защиты ключевых бизнес-процессов без дополнительных сложностей при внедрении».</p> Компании АТОЛ и «Актив» подтвердили совместимость кассового программного обеспечения SIGMA Касса с активными ключевыми … message https://www.itweek.ru/themes/detail.php?ID=235294 Wed, 05 Aug 2026 13:44:10 +0300 <p>Институт статистических исследований и экономики знаний (ИСИЭЗ) НИУ ВШЭ по данным Роспатента проанализировал динамику государственной регистрации программ для ЭВМ, баз данных и топологий интегральных микросхем за последнее десятилетие, а также основные направления цифровых разработок и состав правообладателей.</p> <p>На программы для ЭВМ приходится более четырех из пяти регистраций по трем рассматриваемым видам объектов. В 2025 г. в Роспатент поступило 38,6 тыс. заявок на их регистрацию, зарегистрировано 38,1 тыс. программ. За год число зарегистрированных программ увеличилось на 17,5%, а по сравнению с 2015 г. — в 2,8 раза.</p> <p>Почти все заявки (свыше 99,9%) на регистрацию программ для ЭВМ в 2025 г. подали отечественные разработчики. Среди регистрируемых решений представлены системы автоматизированного проектирования (САПР) и инженерного моделирования, технологии искусственного интеллекта и машинного обучения, системы управления технологическими процессами, медицинские информационные системы, ПО для энергетики и нефтегазового комплекса, образовательные платформы и финансово-аналитические продукты.</p> <p>Масштабы регистрации баз данных значительно ниже, чем программ для ЭВМ, однако в последнее десятилетие эти показатели в целом устойчиво росли. В 2015 г. в России было подано порядка 1,7 тыс. заявок на регистрацию баз данных, в 2025 г. — уже 6,7 тыс., то есть почти в 4 раза больше. Число зарегистрированных баз данных за этот период выросло более чем в 3,6 раза — с 1,8 тыс. в 2015 г. до 6,6 тыс. в 2025 г.</p> <p>Почти все зарегистрированные базы данных также принадлежат российским правообладателям. Значительную часть баз составляют наборы данных, накопленные в ходе медицинских и биологических исследований: регистры пациентов, результаты диагностики, геномные и микробиологические коллекции. Широко представлены образовательные и экологические ресурсы, геопространственные и статистические данные. Присутствуют также размеченные датасеты для задач машинного обучения.</p> <p>Самый заметный рост в 2025 г. отмечен в сегменте топологий интегральных микросхем (ИМС)— наиболее редких среди рассматриваемых объектов: по сравнению с 2024 г. число заявок увеличилось с 324 до 478, а регистраций — с 286 до 452. По сравнению с 2015 г. оба показателя выросли более чем втрое.</p> <p>Доля иностранных решений в данной категории тоже ограничена, но чуть выше, чем в программах для ЭВМ и базах данных: порядка 4% заявок в среднем в течение всего рассматриваемого периода. Многие разработки ориентированы на импортозамещение компонентной базы. Большинство регистрируемых топологий относится к силовой и аналоговой, сверхвысокочастотной электронике, цифровым и смешанным схемам. Отдельные направления — сенсорные, оптоэлектронные, радиационно-стойкие микросхемы.</p> <p>За период <nobr>2015–2025 гг.</nobr> существенно выросла активность российских правообладателей в отношении регистрации программ для ЭВМ, баз данных и топологий ИМС. Особенно заметный рост начался после 2020 г., когда на фоне пандемии COVID-19 усилился спрос на цифровые решения. Санкционное давление дополнительно стимулировало развитие отечественной микроэлектроники. При этом три сегмента различаются по составу наиболее активных правообладателей. Программы для ЭВМ часто регистрируют государственные структуры и компании с госучастием, базы данных — университеты и научные организации, топологии микросхем — специализированные предприятия микроэлектроники. В последнем случае важную роль играет государство как заказчик НИОКР, за которым нередко закрепляются права на полученные результаты.</p> Институт статистических исследований и экономики знаний (ИСИЭЗ) НИУ ВШЭ по данным Роспатента проанализировал динамику … message https://www.itweek.ru/themes/detail.php?ID=235293 Wed, 05 Aug 2026 13:41:38 +0300 <p>Компания «Блазар» продолжает реализовывать стратегию развития системы контроля сетевого доступа Blazar NAC, ориентируясь на потребности крупных корпоративных клиентов. В версии Blazar NAC 3.0 осуществлена возможность развёртывания системы в территориально распределённой инфраструктуре с помощью создания федерации из независимых равноправных узлов. Такое решение учитывает архитектуру сети предприятия, позволяет оперативно реагировать на её изменения и обеспечивает технологическую основу для централизованного управления сетевым доступом в геораспределённой корпоративной сети.</p> <p>Контроль соответствия рабочих станций, работающих под управлением операционной системы MacOS, установленным в организации внутренним правилам ИБ расширяет функциональные возможности Blazar NAC 3.0.</p> <p>Реализованный в системе централизованный сбор структурированных логов предоставляет администратору единую точку контроля и структурированные данные для быстрой аналитики, упрощения диагностики и расследования инцидентов.</p> <p>Расположение становится новым критерием и позволяет учитывать локацию подключения пользователя и устройства как один из факторов при принятии решения о предоставлении доступа.</p> <p>«Мы развиваем наш продукт с учетом запросов корпоративных клиентов. Новая версия Blazar NAC 3.0 заметно расширяет возможности управления доступом в сложных распределённых средах, — отметил генеральный директор АО „Блазар“ Александр Черных. — Реализованные обновления — это инструменты под реальные задачи бизнеса: они учитывают особенности работы в территориально разнесённой инфраструктуре, разнородную среду и разные сценарии эксплуатации, обеспечивая при этом прозрачность для команд ИБ».</p> Компания «Блазар» продолжает реализовывать стратегию развития системы контроля сетевого доступа Blazar NAC, ориентируясь … message https://www.itweek.ru/themes/detail.php?ID=235287 Wed, 05 Aug 2026 00:00:00 +0300 <p><em>Интерактивные виджеты в iOS появились ещё в 2023 году, но компании до сих пор регулярно сталкиваются с одними и теми же проблемами при их разработке: кнопка не реагирует, данные показывают не то, что есть на самом деле, действия дублируются. Рассмотрим, почему причина этих проблем почти никогда не кроется в самом интерфейсе.</em></p> <h3>Виджет живёт отдельно от приложения</h3> <p>WidgetKit работает в отдельном процессе и не имеет прямого доступа к основному приложению. Это первое, что нужно понимать про архитектуру виджета: он не часть приложения в техническом смысле, а отдельная программа, которая время от времени получает данные со стороны. После нажатия кнопки сначала запускается обработчик действия (AppIntent), затем выполняется бизнес-логика, после чего поставщик временной шкалы (TimelineProvider) формирует новое состояние виджета (TimelineEntry). Только после этого WidgetKit может обновить интерфейс. Между этими этапами нет прямой синхронизации — каждый выполняется независимо.</p> <p>Команды часто проектируют виджет так, будто он может напрямую использовать состояние приложения. На практике же получается иначе: приложение хранит данные в одном месте, виджет использует другое хранилище, а сервер работает уже с третьей версией состояния. Пока пользователь работает только с приложением, это разделение незаметно — все три части обновляются последовательно, без видимых противоречий.</p> <h3>Разделение становится проблемой только с появлением кнопки</h3> <p>Всё меняется, когда у пользователя появляется возможность что-то нажать прямо в виджете. Пользователь выполняет действие через виджет, сервер обрабатывает запрос, приложение получает новое состояние — а сам виджет ещё некоторое время продолжает показывать старые данные. Технически операция выполнена корректно, но пользователь видит это как сбой. Он происходит потому, что изменение данных и обновление самого виджета — два независимых процесса. Даже если данные уже изменились, пользователь может ещё некоторое время видеть предыдущее состояние интерфейса.</p> <p>Здесь и кроется главная ошибка в восприятии задачи: интерактивный виджет часто проектируют как статический, к которому просто добавили кнопку. Но как только пользователь получает возможность совершить действие, виджет перестаёт быть просто экраном с данными и становится частью бизнес-процесса — с теми же рисками, что и любой другой шаг в цепочке обработки операции.</p> <h3>Почему действие может выполниться дважды</h3> <p>Раз виджет, приложение и сервер хранят свои версии состояния отдельно, между ними неизбежно возникают гонки: обновления приходят в разном порядке, случаются повторные вызовы одного и того же действия, происходит частичная запись данных. Приложение уже получило новую информацию, а виджет ещё работает со старой версией.</p> <p>По сути, интерактивный виджет — это распределённая система с несколькими участниками: пользователь, WidgetKit, приложение, серверная часть и механизмы синхронизации между ними. Если архитектура не защищает от повторных операций и рассинхронизации данных, продукт начинает вести себя непредсказуемо — независимо от того, насколько хорошо написан код самой кнопки. Именно поэтому действие может выполняться дважды.</p> <h3>У WidgetKit есть два разных ограничения</h3> <p>К рассинхронизации данных добавляются ограничения самой платформы. Обычно о них говорят как об одной проблеме — «Apple ограничивает обновления виджетов». На самом деле речь идёт о двух разных механизмах.</p> <p>Первый влияет на выполнение действия. После нажатия кнопки запускается AppIntent. Он работает в отдельном процессе, которому система выделяет ограниченные ресурсы. Из-за этого выполнение бизнес-логики или сетевого запроса может занять больше времени, чем ожидает пользователь.</p> <p>Второй механизм влияет на обновление интерфейса. Даже если операция уже завершилась и новое состояние готово, разработчик не может заставить WidgetKit сразу перестроить виджет. Можно лишь отправить запрос на обновление. Когда именно система его выполнит, решает уже iOS. Она же ограничивает количество обновлений, доступных виджету.</p> <p>Путать эти ограничения нельзя. Одно определяет, когда завершится операция, второе — когда пользователь увидит её результат. Поэтому после успешного выполнения действия виджет ещё некоторое время может отображать старые данные.</p> <p>Попытка обновлять интерфейс после каждого действия проблему не решает. Виджет — не обычный экран приложения, которым разработчик управляет напрямую. Лишние запросы только увеличивают нагрузку и не гарантируют, что пользователь быстрее увидит изменения.</p> <p>Рабочий подход другой. Данные готовят заранее, а виджет получает уже сформированный снимок состояния от TimelineProvider. Запрос на обновление отправляется сразу после изменения данных, но момент, когда пользователь увидит новую информацию, всё равно определяет система. Поэтому основную бизнес-логику выносят за пределы виджета, оставляя внутри только отображение уже подготовленного состояния.</p> <h3>Чем выше цена ошибки, тем строже правила</h3> <p>Эта же логика подтверждённых состояний становится критичной, когда виджет показывает баланс счёта, статус заказа или показатели мониторинга. Частая ситуация: виджет показывает результат операции раньше, чем система получила окончательное подтверждение. Пользователь видит успешный статус, а через несколько секунд операция завершается ошибкой.</p> <p>Для пользователя это выглядит как недостоверность данных, для бизнеса — как рост обращений в поддержку и потеря доверия к продукту. Поэтому в таких сценариях виджет не должен показывать информацию, которая ещё находится в процессе согласования: если операция выполняется, пользователь видит промежуточный статус, а при отсутствии подтверждения — последнее подтверждённое состояние с указанием времени его обновления. В итоге, можно избежать ситуации, когда устаревшие данные выглядят актуальными. Пользователь понимает, что операция ещё не завершена, а не воспринимает задержку как ошибку системы.</p> <h3>Лёгкий виджет ведёт себя стабильнее</h3> <p>Та же проблема — перенос логики приложения внутрь виджета — встречается и на уровне производительности. Если внутри виджета остаются сложные вычисления, подготовка данных и обращения к серверу, со временем накапливаются задержки обновления и нестабильная работа интерактивных сценариев, даже если изначально всё работало корректно.</p> <p>Решение то же самое, что и для синхронизации состояний: подготовка данных переносится заранее — в приложение или на сервер, — а сам виджет получает уже готовый снимок и выполняет минимум собственной логики. TimelineProvider строит интерфейс уже по подготовленной модели данных, а не выполняет тяжёлые вычисления в момент обновления. Чем меньше работы виджет делает самостоятельно, тем стабильнее он ведёт себя в реальных условиях эксплуатации.</p> <h3>Почему к виджету предъявляют более высокие требования</h3> <p>Все перечисленные сложности соединяются в одном простом факте: виджет находится на первом экране взаимодействия с продуктом, а не открывается после запуска и авторизации, как основное приложение. Он постоянно находится перед глазами пользователя и должен корректно работать в любой момент времени.</p> <p>Если внутри приложения произойдёт сбой, пользователь часто может повторить действие или обновить экран — и не заметит проблему как системную. Если же некорректно ведёт себя виджет, это видно сразу и напрямую влияет на восприятие всего продукта. Именно поэтому распределённую природу виджета нельзя игнорировать на этапе проектирования: кнопка на экране — лишь видимая часть процесса, а всё остальное нужно строить как систему с несколькими источниками данных, а не как элемент дизайна.</p> <p>#IMAGE_235288#</p> Интерактивные виджеты в iOS появились ещё в 2023 году, но компании до сих пор регулярно сталкиваются … article Алексей Артамонов, директор Nord Clan https://www.itweek.ru/themes/detail.php?ID=235283 Wed, 05 Aug 2026 00:00:00 +0300 <p><em>Тим Янг, директор по маркетингу Vespa.ai, рассказывает на портале </em><em>The</em> <em>New</em> <em>Stack</em> <em>о том, как оптимизация оркестровки рабочих процессов обеспечивает контекст, необходимый автономным агентам.</em></p> <p>Публичные ИИ-помощники стали настолько распространены, что поставщики ПО все чаще добавляют в свои приложения поиск с использованием искусственного интеллекта, диалоговые возможности и ИИ-агентов. От электронной коммерции и поддержки клиентов до корпоративного ПО, ИИ быстро становится основным интерфейсом для многих приложений.</p> <p>Компании, которые создают продукты на основе собственной информации, особенно хорошо подготовлены к тому, чтобы извлечь выгоду из этого сдвига. Независимо от того, предоставляют ли они финансовую аналитику, аналитику рынка, юридические исследования, научные публикации или деловую информацию, их продукты помогают профессионалам принимать более обоснованные решения, преобразуя достоверную информацию в действенные инсайты.</p> <p>ИИ позволяет этим организациям предоставлять эту экспертизу благодаря совершенно новым пользовательским интерфейсам. Все чаще они конкурируют не только по качеству своей собственной информации, но и по тому, насколько интеллектуально они ее извлекают, понимают и преобразуют в ценность для клиента.</p> <p>Появляется новое поле конкурентной борьбы. Поскольку ИИ становится основным интерфейсом для доступа к корпоративным знаниям, способность извлекать, проверять, ранжировать и собирать информацию становится почти столь же важной, как и сама корпоративная информация.</p> <p>Значительная часть внимания отрасли сосредоточена на все более совершенных языковых моделях, но эффективность этих моделей зависит от контекста, который они получают. Разработка рабочих процессов извлечения, которые постоянно предоставляют достоверную, релевантную и актуальную информацию, быстро становится одной из определяющих инженерных задач для ИИ-нативных приложений.</p> <h3>Инженерия извлечения информации: оптимизация рабочего процесса</h3> <p>На протяжении десятилетий инженерия извлечения информации была сосредоточена на том, чтобы помочь людям найти нужную информацию. Будь то поиск на веб-сайте, в юридической базе данных или на платформе финансовых исследований, задача заключалась в том, чтобы получить наиболее релевантные результаты, балансируя при этом конкурирующие приоритеты, такие как релевантность, задержка, масштабируемость и стоимость. Задача поисковой системы заключалась в извлечении релевантной информации. Задача человека заключалась в ее оценке.</p> <p>ИИ коренным образом меняет роль поисковой системы.</p> <p>Вместо того чтобы извлекать информацию для оценки людьми, системы поиска все чаще собирают контекст, который большие языковые модели и агенты ИИ используют для исследований, рассуждений и действий. Каждое решение об извлечении информации теперь становится частью автоматизированного рабочего процесса, в котором релевантность, актуальность, задержка и доверие напрямую влияют на конечный ответ.</p> <p>Это смещает инженерную задачу с отдельных технологий на сам рабочий процесс извлечения. Цель больше не состоит в простом поиске релевантных документов, а заключается в оркестрации поиска, ранжирования, фильтрации, инференса и обновлений в реальном времени, чтобы они эффективно работали вместе. Мы считаем, что эта новая дисциплина заслуживает собственного названия: инжиниринг извлечения информации (Retrieval Engineering). Промпт-инижиниринг влияет на то, как языковая модель рассуждает. Инжиниринг извлечения информации определяет, о чем ей нужно рассуждать. Оба аспекта важны, но по мере того, как приложения ИИ становятся все более автономными, качество извлечения все больше определяет качество результата.</p> <p>По мере того, как приложения ИИ развиваются от разговорных помощников до систем глубокого исследования и автономных агентов, оптимизация рабочих процессов, а не отдельных компонентов, становится все более важной. Один запрос пользователя может запустить десятки — или даже сотни — операций извлечения, прежде чем будет сгенерирован ответ.</p> <h3>Проблема не в векторном поиске</h3> <p>Векторные базы данных решили важную проблему, сделав семантический поиск практичным в масштабе. Но это лишь один этап гораздо более масштабного рабочего процесса.</p> <p>В производственных приложениях ИИ все чаще сочетается векторное сходство с поиском по ключевым словам, структурированной фильтрацией, бизнес-правилами, персонализацией, ранжированием на основе машинного обучения и инференсом в реальном времени для формирования контекста, от которого зависят языковые модели. Инженерная задача больше не заключается в выборе лучшей технологии извлечения — она заключается в оркестрации все более сложных рабочих процессов извлечения, которые остаются точными, отзывчивыми и экономически эффективными.</p> <p>Многие организации решают эту проблему, комбинируя специализированные технологии. Векторная база данных обеспечивает семантический поиск. Поисковая система обрабатывает лексическое соответствие. Дополнительные сервисы обеспечивают переранжирование, персонализацию и инференс. Вначале это работает хорошо, но каждый дополнительный компонент добавляет еще один сетевой узел, еще одну операционную зависимость и еще один источник задержки. Проблема больше не в векторном поиске. Она заключается в разработке эффективной архитектуры извлечения.</p> <h3>От компонентов к платформам</h3> <p>Этот сдвиг меняет подход к проектированию инфраструктуры извлечения информации. Вместо оптимизации отдельных компонентов в отрыве от контекста, инженерным командам все чаще необходимо оптимизировать рабочий процесс извлечения как целостную систему — балансируя качество извлечения, задержку, актуальность, масштабируемость и стоимость инфраструктуры.</p> <p>Именно поэтому появляются платформы поиска на основе ИИ. Вместо того чтобы объединять извлечение, ранжирование, инференс и обслуживание из нескольких независимых сервисов, они выполняют рабочий процесс в рамках единой распределенной архитектуры. Проблема оптимизации смещается от интеграции компонентов к проектированию самого рабочего процесса.</p> <p>ИИ трансформировал пользовательский интерфейс. Теперь он трансформирует и инфраструктуру извлечения информации, лежащую в его основе. Для организаций, создающих приложения на основе собственных знаний, следующее конкурентное преимущество будет заключаться не только в более крупных языковых моделях или лучших векторных вложениях. Оно будет заключаться в создании рабочих процессов извлечения, которые последовательно предоставляют достоверный, релевантный и своевременный контекст в масштабе.</p> <p>Инженерия извлечения информации стремительно становится одной из дисциплин, определяющих следующее поколение ИИ-нативных приложений.</p> Тим Янг, директор по маркетингу Vespa.ai, рассказывает на портале The New Stack о том, как оптимизация оркестровки … article https://www.itweek.ru/themes/detail.php?ID=235292 Tue, 04 Aug 2026 14:00:12 +0300 <p>Компания «СиСофт Девелопмент» выпустила масштабное обновление линейки Model Studio CS и CADLib Модель и Архив. Новая версия стала очередным этапом развития отечественной платформы технологий информационного моделирования (ТИМ), ориентированной на управление инженерными данными на всех этапах жизненного цикла объекта — от проектирования и согласования до строительства и эксплуатации.</p> <p>Продукт совершенствуется не как набор отдельных функций, а как единая цифровая среда для промышленного и гражданского проектирования и строительства. Если еще недавно одной из главных задач было обеспечить технологическую независимость российских предприятий и заменить зарубежные САПР, то сегодня акцент смещается на повышение эффективности работы инженеров, интеграцию данных и сокращение ручного труда. </p> <p>Такой подход отражен и в долгосрочной дорожной карте развития продуктов. На протяжении последних нескольких лет последовательно расширяются возможности совместной работы, обмена инженерными данными, автоматизации проектирования и поддержки различных инженерных дисциплин. Сегодня в центре внимания находится реализация подхода, при котором информационная модель становится единым источником достоверных сведений для всех участников проекта. Это позволяет не только повысить качество проектирования, но и выстроить непрерывный процесс передачи информации между всеми стадиями жизненного цикла объекта.</p> <p>Очередной релиз развивает сразу несколько ключевых направлений, связанных с постепенным переходом от отдельных функций к единой цифровой среде. В частности, заметно расширены возможности CADLib как среды общих данных: улучшены механизмы управления доступом и ролями пользователей, появились новые инструменты ручной проверки моделей, расширены возможности публикации и обмена данными. Дальнейшее развитие получили средства коллективной работы с информационной моделью. Пользователям стали доступны дополнительные механизмы контроля изменений, управления параметрами проекта, проверки моделей и подготовки данных для разных участников жизненного цикла объекта.</p> <p>Существенные изменения коснулись программных продуктов линейки Model Studio CS. Главная цель этих обновлений — избавить инженера от ручного труда, повысить точность и ускорить проектирование. Так, в Model Studio CS Генплан появились новые средства формирования цифровых геологических моделей (скважины, коридоры, грунты). Расширен блок проектирования автодорог: автоматизировано создание сложных пересечений, водоотводных лотков, нанесение разметки, расстановка знаков и даже учет путей миграции животных.</p> <p>В Model Studio CS Строительные решения обновлены инструменты моделирования металлоконструкций, многослойных стен, витражных систем и отделки. Доработки в генерации строительной документации (например, автоматический подсчет объемов профилей и оптимизация сварных швов) позволяют свести к минимуму объем ручных корректировок на чертежах.</p> <p>В Model Studio CS Трубопроводы значительно улучшен блок генерации изометрических схем. Автоматическая разбивка таблиц, нумерация и фильтры ускоряют выпуск рабочей документации. В Model Studio CS Отопление и вентиляция усовершенствованы встроенные расчеты и доработан подбор прямоугольных тройников по миникаталогу.</p> <p>Для инфраструктурных и энергетических объектов реализованы уникальные расчетные функции. Так, в программном комплексе Model Studio CS ЛЭП автоматизирован подсчет площадей отвода земли и вырубки насаждений, а в Model Studio CS Кабельное хозяйство добавлена генерация кабельных траншей и интеллектуальная раскладка с учетом двухфакторного резервирования. В Model Studio CS Электрика значительно расширен функционал по расчетам в рамках команды Расчет освещения точечным методом, а также добавлены новые элементы для генерации однолинейной схемы.</p> <p>В приложении Model Studio CS ОПС реализована автоматическая расстановка пожарных извещателей и расчет 3D-зон обзора камер видеонаблюдения.</p> <p>Во многих инженерных разделах были расширены средства автоматизации проектирования, формирования спецификаций, проверки на коллизии и подготовки исполнительной документации. Существенно обновлен и общий функционал системы: улучшены инструменты работы с проекциями, импортом/экспортом IFC, редактором оборудования, средствами оформления документации; появилась поддержка новой графической платформы nanoCAD 26. Также добавлена поддержка импорта облаков точек в форматах E57 и LAS, что упрощает использование результатов лазерного сканирования при реконструкции и сопровождении объектов.</p> <p>Большинство изменений новой версии основано на запросах проектных организаций и промышленных предприятий, использующих продукты «СиСофт Девелопмент» в реальных проектах. Такой подход помогает выстраивать продукт не путем механического наращивания функциональности, а последовательно совершенствовать инженерные процессы, опираясь на реальные сценарии применения и запросы отрасли.</p> <p>Новая версия отражает общую эволюцию российских ТИМ-решений. Если несколько лет назад основной задачей было импортозамещение зарубежных САПР, то сегодня развитие идет уже в направлении построения единой среды управления инженерными данными на протяжении всего жизненного цикла объекта. В «СиСофт Девелопмент» отмечают, что архитектура системы изначально проектируется так, чтобы одинаково эффективно работать и в крупных промышленных холдингах, и в небольших проектных организациях.</p> <p>С подробной информацией о функциональных возможностях программных продуктов линейки Model Studio CS можно ознакомиться в описаниях к ним на сайте компании.</p> Компания «СиСофт Девелопмент» выпустила масштабное обновление линейки Model Studio CS и CADLib Модель и Архив … message https://www.itweek.ru/themes/detail.php?ID=235291 Tue, 04 Aug 2026 13:56:38 +0300 <p>Разработчик экосистемы ПО для инфраструктуры Orion soft представил обновление GitOps-платформы Hyperdrive 1.5. В новой версии решения вендор добавил функционал внутреннего портала разработчика (Internal Developer Platform, IDP).</p> <p>Скорость разработки за последний год значительно выросла с распространением ИИ-инструментов. Прогнозы аналитиков говорят о том, что к 2027 году более половины разработчиков ПО будет применять искусственный интеллект или машинное обучение в работе. При этом, другие процессы в инфраструктуре, например, предоставление доступов, настройка DNS и выдача сертификатов развиваются не так быстро. Скорость запуска новых продуктов растет значительно медленнее, чем темпы создания кода. </p> <p>В новой версии GitOps-платформы Hyperdrive реализован функционал IDP. Решение помогает сократить этот разрыв, автоматизировать инфраструктуру и ускорить инфраструктурные процессы. Каталог инструментов самообслуживания помогает командам разработки самостоятельно выстроить прозрачный процесс запуска новых продуктов и получить необходимые ресурсы и доступы. В свою очередь, команда инфраструктуры, ИБ- и DevOps-специалисты концентрируются на своих процессах и развитии систем. Таким образом, бизнес может значительно сократить Time-to-Market.</p> <p>Обновленная GitOps-платформа позволяет создать «золотой путь» процесса вывода новых продуктов на рынок с помощью стандартизации и автоматизации рутинных операций. Благодаря этому Hyperdrive объединяет разрозненные ИТ-команды: каждый отдел получает готовые шаблоны и сервисы для своей работы. Полученные результаты объединяются в конечном продукте. Кроме того, все пользователи платформы могут отслеживать состояние своих проектов с помощью метрик и логов. </p> <p>Версия 1.5 теперь также поддерживает полный цикл управления компонентами Kubernetes-платформы Nova. Появился единый центр инфраструктурного мониторинга для контейнеров Nova, виртуализации zVirt и балансировщиков нагрузки. Реализовано централизованное управление кластерами и доступом, а также добавлена поддержка разделяемых кластеров. Это особенно востребовано для больших инсталляций, где риск ошибки и сложность ручных операций растет.</p> <p>«IDP — востребованный класс решений на международном ИТ-рынке. Крупный современный бизнес активно развивается в этом направлении, и мы уже видим первые успешные кейсы с промышленности и финансах. Мы разрабатываем GitOps-платформу Hyperdrive на основе лучших мировых практик, чтобы предоставить российским заказчикам передовое решение для эволюции ИТ-инфраструктуры», — отметил Павел Лавров, лидер продукта Hyperdrive в Orion soft.</p> <p>В планах вендора развитие инструментов для безопасной разработки в концепции DevSecOps. Это позволит внедрять Hyperdrive как инфраструктурную основу для организации процессов безопасной разработки и соблюдения требований российских регуляторов.</p> Разработчик экосистемы ПО для инфраструктуры Orion soft представил обновление GitOps-платформы Hyperdrive 1.5 … message https://www.itweek.ru/themes/detail.php?ID=235290 Tue, 04 Aug 2026 13:54:54 +0300 <p>Сбер выпустил семейство генеративных моделей Kandinsky WM 1.0. Они обучены генерировать видео, более точно соответствующие законам физики и пригодные для обучения систем Physical AI. В основе моделей нейросеть Kandinsky 5.0 Video Lite, дополнительно обученная на видео с камер роботов, беспилотных автомобилей и записях промышленных процессов. Особенно ценны модели будут там, где реальные съёмки невозможны или сильно затруднены: они могут генерировать видео редких, сложных или опасных сценариев для тренировки роботов и беспилотного транспорта. Код и веса нейросетей опубликованы под лицензией MIT — и доступны всем разработчикам мира бесплатно.</p> <p>Physical AI или физический ИИ — класс систем искусственного интеллекта, которые способны воспринимать физический мир, понимают его динамику и могут управлять реальными устройствами. В отличие от языковых моделей, для физического ИИ просто нет открытых обучающих данных в достаточном масштабе. Собирать такие данные очень сложно и дорого: нужны устройства, датчики, операторы, контролируемая среда. Автомобиль с камерами и датчиками накапливает порядка 5000 часов записей в год, тогда как современным моделям нужны миллионы часов. А многие редкие и сложные сценарии, например, ДТП, экстремальную погоду, отказы оборудования — вообще нельзя воспроизвести вживую.</p> <p>По оценке Яна Лекуна, лауреата премии Тьюринга и одного из «отцов» глубокого обучения, четырёхлетний ребёнок только через зрение получает больше информации, чем содержится во всех текстах, на которых обучены крупнейшие языковые модели. Поэтому следующий рубеж физического ИИ — обучение на видео, а синтетические данные становятся ключевым способом закрыть разрыв в объёмах.</p> <p>Создаваемые моделями Kandinsky WM видео длятся около 5 секунд и отражают отдельные действия: манипуляции с предметами (взял, положил, разрезал), дорожные ситуации (перестроение, проезд перекрёстка), этапы производственных процессов — базовые «кирпичики», из которых складывается обучение автономных систем. Это первое поколение нейросетей на пути к полноценным моделям мира — системам, способным моделировать развитие сцены во времени и служить симуляторами для обучения и тестирования роботов. Кроме генерации данных, такие нейросети могут выступать основой для систем управления: выученная при генерации видео физическая интуиция, переносится в модели действий роботов.</p> <p>Базовые модели генерации видео иногда нарушают простые физические законы: объекты деформируются, перспектива искажается, движения выглядят неестественно. Чтобы повысить физическую достоверность, команда дообучила Kandinsky 5.0 Video Lite на нескольких миллионах реальных видеосцен — автомобили, роботы, промышленные процессы, сложные движения объектов. Отдельные направления, например автомобильные сцены, дополнительно улучшили с помощью обучения с подкреплением: специальные модели оценивали ролики на предмет сохранения формы объектов, геометрии и естественности движения. На основе этой обратной связи Kandinsky учился создавать более физически правдоподобные видео. Подробности о разработке команда написала в статье на Хабре.</p> <p>Kandinsky WM 1.0 — первое открытое семейство российских моделей для генерации физически достоверных данных. В мире таких систем единицы. Модели пригодятся разработчикам беспилотного транспорта, от легковых автомобилей до грузовиков и роботакси, компаниям в сфере промышленной автоматизации: производителям манипуляторов, промышленных, сервисных и антропоморфных роботов, командам, внедряющим компьютерное зрение на производствах и складах. Не меньше они полезны исследователям, университетам и стартапам, которых важно экономить ресурсы при сборе обучающих данных.</p> <p>Модели уже применяет Центр робототехники Сбера для обучения собственных роботов, а также институт AIRI в своем дорожном симуляторе.</p> <p>Денис Димитров, CTO Kandinsky, управляющий директор по исследованию данных Сбера, отметил: «Стремясь понять устройство нашего мира, лучшие умы человечества тысячелетиями открывали физические законы. Но знать нужное уравнение и уметь предсказать реальное событие — это совершенно разные вещи. Чтобы просчитать, как поведёт себя коробка на мокром конвейере, нужно знать огромное количество параметров, которых у нас нет. Есть кейсы, которые вообще не описывается уравнениями, например, поведение пешехода перед беспилотным автомобилем. Человек решает эту задачу не вычислением, а интуицией, накопленной из опыта. Наши модели учатся так же — на видео реального мира — и позволяют „прожить“ виртуально даже те сценарии, которые опасно или невозможно воспроизвести. Это шаг к моделям мира — системам, которые понимают физическую реальность, предсказывают, что произойдёт дальше, и могут действовать в ней самостоятельно».</p> Сбер выпустил семейство генеративных моделей Kandinsky WM 1.0. Они обучены генерировать видео, более точно соответствующие … message https://www.itweek.ru/themes/detail.php?ID=235289 Tue, 04 Aug 2026 13:52:36 +0300 <p>Институт статистических исследований и экономики знаний (ИСИЭЗ) НИУ ВШЭ изучил факторы, которые препятствуют более активному использованию технологий искусственного интеллекта (ИИ) в академической сфере.</p> <p>Несмотря на высокий интерес академического сообщества к ИИ (более 90% ученых, применяющих генеративный ИИ, считают, что он уже приносит пользу для развития их научной области), распространение данной технологии в российской науке пока не стало повсеместным. Ключевые барьеры различаются на уровне организаций и отдельных исследователей.</p> <p>Среди государственных вузов и НИИ более четверти (28%) не используют ИИ. Почти половина из них (45%) объясняют это опасениями получить неверные результаты. К числу наиболее значимых барьеров также относятся нехватка квалифицированных кадров (36%), вычислительных мощностей (33%) и высокие затраты на внедрение технологий (31%). Почти четверть организаций в ИИ не видят потребности (24%) либо не сталкиваются с задачами, которые можно было бы решать с помощью ИИ (23%).</p> <p>Среди ученых, не использующих генеративный ИИ (16% опрошенных), более половины (55%) не считают технологию необходимой для их работы. Еще по 23% называют ее бесполезной либо объясняют отказ от использования отсутствием необходимых навыков. Технические ограничения играют значительно меньшую роль: лишь 9% не применяют генеративный ИИ из-за отсутствия доступа к необходимым сервисам, столько же считают их использование небезопасным. Показательно, что среди тех, кто пока не работает с генеративным ИИ, освоить эти сервисы хотел бы лишь каждый второй (49%), тогда как среди уже использующих их 80% стремятся расширить практику применения.</p> <p>Набор барьеров зависит и от типа ИИ. Для более активного использования генеративного ИИ ключевыми ограничениями становятся недостаток навыков (48%) и времени на освоение технологий (34%). Существенное влияние также оказывают сложности с оплатой (39%) и высокая стоимость подписок на зарубежные ИИ-сервисы (37%), правовая неопределенность их применения в исследованиях (32%), а также опасения, связанные с загружаемыми в ИИ данными и работой с чувствительной информацией (по 29%).</p> <p>Почти треть ученых используют специализированные ИИ-решения: собственные или адаптированные модели, методы и алгоритмы. При этом каждый второй из них (51%) хотел бы расширить их применение. Главными препятствиями остаются нехватка навыков (57%) и времени на освоение технологий (50%), ограниченный доступ к необходимым инструментам (39%), недостаток оборудования (25%) и вычислительных мощностей (20%). Ситуацию усугубляют проблемы, связанные с данными, включая их недостаточный объем (19%), качество (18%) и высокие затраты на сбор и обработку (19%); недостаточное финансирование научных проектов с применением ИИ (25%); а также правовые ограничения на обмен данными между организациями и странами (19%).</p> <p>Проведенные ИСИЭЗ НИУ ВШЭ опросы показали, что и научные организации, и сами исследователи заинтересованы в более широком применении ИИ, однако сталкиваются с теми или иными барьерами. На институциональном уровне основными ограничениями остаются опасения относительно надежности результатов и дефицит ресурсов, тогда как на уровне ученых ключевую роль играют нехватка компетенций и времени на освоение технологий. Преодоление этих барьеров станет важным условием перехода от отдельных практик использования ИИ к его системному внедрению в российской науке.</p> Институт статистических исследований и экономики знаний (ИСИЭЗ) НИУ ВШЭ изучил факторы, которые препятствуют более активному … message https://www.itweek.ru/themes/detail.php?ID=235282 Tue, 04 Aug 2026 00:00:00 +0300 <p><em>Дебора Камбе, менеджер по маркетингу продуктов компании PagerDuty, рассказывает на портале </em><em>The</em> <em>New</em> <em>Stack</em> <em>о том, как с помощью пяти практических шагов реализовать сервисную архитектуру, повысить операционную устойчивость, оптимизировать управление инцидентами и усилить ИИ-триаж (использование искусственного интеллекта для сортировки, оценки и приоритизации разных задач или инцидентов).</em></p> <p>Когда операционные группы получают оповещение, прежде чем предпринимать какие-либо действия, им необходимо получить ответы на три вопроса:</p> <ol> <li> Что сломалось?</li> <li> Что от этого зависит?</li> <li> Кто за это отвечает?</li> </ol> <p>Без четкой карты взаимосвязей бизнес- и технических сервисов поиск ответов на эти вопросы может превратиться в часы проб и ошибок, разочарование клиентов и даже потерю дохода.</p> <p>Картирование сервисов и проектирование сервисной архитектуры имеют решающее значение для минимизации сбоев в работе сервисов и ускорения восстановления после инцидентов, поскольку они позволяют быстрее и точнее мобилизовать ресурсы и более эффективно проводить анализ первопричин.</p> <p>По мере того, как все больше работы по триажу переходит от людей к автоматизированным и управляемым ИИ системам, становится еще более очевидным, что эти системы хороши настолько, насколько хороша карта сервисов, на основе которой они строят рассуждения.</p> <p>Грамотно спроектированная сервисная архитектура начинается с четкого понимания того, что такое сервис — самодостаточная единица функциональности с одной командой-владельцем. Также важно различать технические и бизнес-сервисы:</p> <ul> <li> Технические сервисы: API, базы данных, системы аутентификации и микросервисы, обеспечивающие работу цифровых операций.</li> <li> Бизнес-сервисы: возможности, ориентированные на клиента и построенные на основе технических сервисов.</li> </ul> <p>Короче говоря, технические сервисы показывают, как все работает «под капотом», а бизнес-сервисы показывают, что фактически испытывает клиент.</p> <p>Для функционирования одного бизнес-сервиса может потребоваться несколько базовых технических сервисов, в то время как один технический сервис может обеспечивать работу нескольких бизнес-сервисов. Именно эта сложность замедляет управление инцидентами, но ее можно устранить с помощью правильного сопоставления сервисов.</p> <h2>Пять шагов для проектирования сервисной архитектуры</h2> <p>Организации могут предпринять следующие шаги для структурирования своих бизнес- и технических сервисов с помощью четкого архитектурного проекта:</p> <h3>1. Начните с бизнес-сервисов, ориентированных на клиента</h3> <p>Начните с сервисов, которые наиболее важны для клиентов, а не рискуйте увязнуть в сложной сети базовых технических компонентов. Это может быть система онлайн-оформления заказов поставщика услуг электронной коммерции или функция обработки страховых случаев в страховой компании. Суть в том, что это то, что клиенты получают и на что они полагаются. В первую очередь команды должны определить эти сервисы и составить их карту, поскольку это поможет инженерам и операционным группам — а также любым автоматизированным системам, работающим от их имени, — определить и приоритизировать базовые технические сервисы, если что-то пойдет не так.</p> <h3>2. Составьте карту поддерживающих технических сервисов</h3> <p>Следующий шаг — понимание того, какие базовые компоненты составляют каждый бизнес-сервис. Без четкого представления об этих зависимостях управление инцидентами становится вопросом догадок, что затягивает сбои, подрывает лояльность клиентов и негативно влияет на доходы в долгосрочной перспективе.</p> <p>Точная карта, связывающая бизнес-сервисы с техническими, предоставляет инженерам и командам цифровых операций мощный аналитический инструмент, позволяющий отсеять лишнюю информацию из оповещений и сузить круг причин сбоя сервиса.</p> <p>Например, сервис банковских переводов может поддерживаться несколькими техническими сервисами, включая сервис авторизации транзакций, API обнаружения мошенничества, сервис платежного шлюза, сервис уведомлений и т. д. Если операционные группы (и автоматизированные системы, призванные им помогать) не видят последствий сбоя в работе сервиса денежных переводов, они рискуют действовать вслепую.</p> <p>Регуляторы по всему миру все чаще формализуют это требование. Например, от финансовых компаний в Евроcоюзе теперь требуется продемонстрировать способность идентифицировать критически важные сервисы и их зависимости, а также восстанавливать их в пределах заданных допусков.</p> <p>Это означает, что хорошая сервисная архитектура становится обязательной для соблюдения нормативных требований в некоторых отраслях.</p> <h3>3. Четко распределите ответственности</h3> <p>Каждый сервис должен иметь одну ответственную команду. Назначьте по одной команде каждой бизнес-функции, чтобы инциденты имели определенный путь реагирования, и обеспечьте наличие одного ответственного для каждого технического сервиса.</p> <p>Это не означает, что команда не может «владеть» несколькими сервисами, но это означает, что если что-то пойдет не так, сразу будет ясно, кого нужно мобилизовать. Такая конкретика снижает операционные затраты на каждый инцидент и уменьшает ненужные привлечения экспертов в предметной области, которые могут быть не в состоянии помочь.</p> <p>Команды, не обладающие такой ясностью, несут как операционные, так и человеческие издержки: сотрудники, неоднократно получающие уведомления об одной и той же нерешенной проблеме, гораздо более подвержены выгоранию.</p> <h3>4. Используйте циклы развертывания в качестве ориентира</h3> <p>Если что-то развертывается независимо, команды должны рассматривать это как автономный сервис и использовать это эмпирическое правило, когда границы технических сервисов не очевидны.</p> <p>Разделение технических компонентов на отдельные сервисы обеспечивает более точное понимание операционных процессов. Благодаря этому при возникновении проблемы легче определить причину и соответствующую команду. Если сервис слишком широк, то сбой остается скрытым.</p> <h3>5. Соедините операционные данные</h3> <p>Последний шаг — объединить операционные данные в единый надежный источник достоверной информации. Интеграции должны объединять сигналы мониторинга, а каталог сервисов должен быть синхронизирован с порталом разработчиков, чтобы сервисная архитектура, графики дежурств и данные об инцидентах находились в одном месте. Кроме того, подключите существующие данные управления конфигурацией к уже существующим источникам данных о сервисах и зависимостях.</p> <p>Цель — единая, постоянно обновляемая система, которая связывает инженеров, операционные группы и любые слои ИИ или автоматизации с необходимыми данными.</p> <h2>Начните с малого, чтобы добиться постепенных успехов</h2> <p>Если все это кажется значительной дополнительной нагрузкой к повседневной работе, лучше разбить задачу на небольшие части. Выберите один из наиболее важных бизнес-сервисов организации и составьте карту его базовых технических сервисов. Определите ответственных, установите политики эскалации и подключите инструменты мониторинга. Затем повторите на другом сервисе.</p> <p>После завершения создания сервисной архитектуры она предоставляет командам цифровых операций контекст, позволяющий оценить масштаб последствий инцидента и определить, какие команды следует мобилизовать. Стоимость каждого последующего инцидента снижается, и создается более прочная основа для операционной устойчивости. По мере автоматизации процесса реагирования на инциденты, именно это сопоставление предоставляет инструментам на основе ИИ необходимый контекст для корректной работы, делая сервисную архитектуру не только решением сегодняшних проблем, но и фундаментом для будущего операционной деятельности.</p> Дебора Камбе, менеджер по маркетингу продуктов компании PagerDuty, рассказывает на портале The New Stack о том … article https://www.itweek.ru/themes/detail.php?ID=235281 Mon, 03 Aug 2026 14:28:33 +0300 <p>AppSec Solutions, российский разработчик решений в области кибербезопасности, объявила о выходе крупного обновления платформы управления безопасной разработкой AppSec.Hub. Релиз направлен на повышение эффективности взаимодействия с инструментами анализа безопасности и предоставление пользователям большей гибкости при настройке процессов DevSecOps.</p> <p>Ключевая задача AppSec.Hub — устранять противоречия между скоростью выпуска цифровых продуктов и требованиями кибербезопасности. Обновленная версия приложения заметно расширяет экосистему интеграций и оптимизирует механизмы контроля качества кода. Команда платформы сфокусировалась на поддержке современных релизов инструментов сканирования и повышении качества данных, поступающих в AppSec.Hub.</p> <p>«Обновление делает AppSec.Hub еще более мощным инструментом для оркестрации DevSecOps-процессов. Мы стремимся к тому, чтобы наши пользователи могли бесшовно интегрировать лучшие решения по ИБ в свой CI/CD, не замедляя при этом цикл разработки и сохраняя полный контроль над безопасностью своих продуктов», — отметили в команде разработки AppSec.Hub.</p> <p>В обновлении расширена совместимость AppSec.Hub с наиболее востребованными инструментами анализа кода: обновлена интеграция с Solar appScreener до версии 3.16 с поддержкой ИИ-модуля для автоматизации триажа уязвимостей, добавлена функция исключения файлов и папок через формат .gitignore в PT Application Inspector, обеспечена поддержка актуальной версии PT BlackBox 3.2. Кроме того, улучшена работа с Aqua Security (автоматическое использование CVSS v2 при отсутствии CVSS v3 от сканера) и YouTrack (ускоренная синхронизация дефектов и автоматическая активация новых конфигураций).</p> <p>В новой версии оптимизирована работа внутренних продуктов экосистемы AppSec.Track и AppSec.Wave — обновлены интеграции, ускорен импорт данных и добавлена выгрузка отчётов по отдельным веткам и проектам. В частности, выбор режимов «информирование» и «блокирование» теперь доступен на всех уровнях иерархии, от компании до конкретного пайплайна, что позволяет точечно настраивать политики безопасности без остановки разработки. Добавлен фильтр по автору изменения статуса и сняты ограничения на смену триажа для уязвимостей, поступающих из внешних инструментов. Внедрили и интуитивный онбординг: подключение организаций теперь выполняется по названию, а карточки сканов дополнены прямыми ссылками на отчеты инструментов анализа.</p> <p>Обновление позволяет существенно сократить время и затраты на внедрение DevSecOps, а управление безопасной разработкой делает более прогнозируемым.</p> AppSec Solutions, российский разработчик решений в области кибербезопасности, объявила о выходе крупного обновления … message https://www.itweek.ru/themes/detail.php?ID=235280 Mon, 03 Aug 2026 14:26:48 +0300 <p>VK и JUG Ru Group провели опрос среди Java-разработчиков. ИИ-инструменты используют 95% разработчиков, 53% обращаются к ним ежедневно.</p> <p>Чаще всего разработчики применяют ИИ для поиска информации — так ответили 74% участников опроса. Для 73% он стал заменой крупнейшей в мире платформы вопросов и ответов Stack Overflow. Также специалисты используют ИИ для написания и проверки кода и генерации тестов. </p> <p>При этом сокращается количество IT-специалистов, участвующих в open-source проектах (проекты с открытым исходным кодом) для обмена опытом. 70% опрошенных не участвуют в таких проектах. В свободное время ими занимаются 16% разработчиков, в рамках рабочих задач — 6%.</p> <p>«ИИ перестал быть для разработчиков экспериментальным инструментом и стал частью ежедневной работы. Более половины респондентов ежедневно используют ИИ для поиска информации и решения технических задач. Для VK важно следить за тем, как меняются подходы Java-сообщества, поскольку этот язык используется в разработке наших высоконагруженных продуктов», — отметил технический директор VK Сергей Ляджин.</p> <p>«95% — это точка, после которой спор о том, войдёт ли ИИ в профессию разработчика, уже закончен. Теперь вопрос в другом: что происходит с инженерной работой, когда агенту можно передать целую задачу — от исследования и планирования до реализации и проверки результата? Кто формулирует намерение, даёт контекст, устанавливает критерии и принимает ответственность? Именно этот разговор станет центральным на нашей осенней Java-конференции 2026», — отметил продюсер JUG Ru Group Алексей Федоров.</p> <p>В исследовании State of Java Insights 2026 приняли участие более 700 Java-разработчиков из разных компаний страны.</p> VK и JUG Ru Group провели опрос среди Java-разработчиков. ИИ-инструменты используют 95% разработчиков, 53% … message https://www.itweek.ru/themes/detail.php?ID=235279 Mon, 03 Aug 2026 14:25:08 +0300 <p>Команда ученых Центра практического искусственного интеллекта Сбербанка опубликовала в открытом доступе библиотеку SIRIN (Semantic Inconsistency Recognition and Inspection Nexus, «Обнаружение и анализ семантических несоответствий»). Она помогает делать ИИ-агентов и языковые модели надежнее: находить в их ответах вымышленные или не подтвержденные исходными данными факты.</p> <p>SIRIN объединяет в одном инструменте разные методы проверки ответов. Разработчики могут сравнивать их, комбинировать и выбирать подходящий вариант для своей задачи. Библиотека умеет проверять как весь ответ целиком, так и отдельные фрагменты текста, показывая, где именно модель могла ошибиться. Кроме того, SIRIN может заранее определить, достаточно ли у ИИ-агента информации для ответа. Это позволяет не только находить ошибки, но и предотвращать их — например, попросить дополнительные данные или отказаться от неподтвержденного ответа.</p> <p>В основе библиотеки лежат исследования Сбера в области детекции галлюцинаций. В частности, учёные из команды исполнительного директора по исследованию данных Центра практического ИИ Сбербанка Максима Макаренко разработали метамодели, которые позволяют повысить точность обнаружения ошибок почти на 30%, используя для обучения всего 250 примеров.</p> <p>Сергей Рябов, старший управляющий директор, директор по AI-трансформации Сбербанка, отметил: «Мы внедряем ИИ на системном уровне и уже обладаем одной из самых сильных экспертиз на рынке благодаря масштабу наших решений. Для повышения надёжности работы моделей мы представили библиотеку SIRIN, которая анализирует обоснованность их ответов. Этот подход уже показал свою эффективность внутри компании в сервисах для работы с клиентами. Мы приняли решение открыть SIRIN для всех компаний, чтобы способствовать развитию рынка. Библиотека доступна всем желающим для использования в своих проектах».</p> <p>Любой разработчик может встроить SIRIN в своего ассистента за несколько минут. Инструмент будет полезен бизнесу, который внедряет большие языковые модели и хочет следить за качеством диалогов с пользователем. Также он пригодится разработчикам ИИ-ассистентов, RAG-систем и ИИ-агентов. Исследователи найдут здесь базу для тестирования новых алгоритмов.</p> <p>Библиотека доступна на российской платформе GitVerse, а также на GitHub. На Hugging Face опубликовано веб-демо.</p> Команда ученых Центра практического искусственного интеллекта Сбербанка опубликовала в открытом доступе библиотеку SIRIN … message https://www.itweek.ru/themes/detail.php?ID=235278 Mon, 03 Aug 2026 09:31:22 +0300 <p><em>Выпуск компанией Moonshot AI модели Kimi K3 возобновил споры о том, кто имеет право создавать продвинутый искусственный интеллект и может ли несанкционированная дистилляция дать правительству США основания для ограничения использования моделей с открытыми весами. Арнал Даяратна, вице-президент </em><em>IDC</em> <em>по исследованиям в области разработки ПО, приводит в корпоративном блоге доводы в пользу того, что открытые веса в сочетании с открытой инфраструктурой для пост-обучения — это основа для более масштабной экосистемы разработки ИИ, а не угроза для неё.</em></p> <p>Выпуск модели Kimi K3 усилил споры об открытых моделях и регулировании в сфере передового ИИ, вызвав новую волну критики в связи с сообщениями о том, что OpenAI и Anthropic обратились к правительству США с просьбой ограничить выпуск открытых моделей, которые связывают с несанкционированной дистилляцией. Возможность того, что правительство США может ограничить или запретить использование таких моделей, вызвала бурную реакцию в отрасли. Коалиция, в которую вошли NVIDIA, Microsoft, IBM, Dell Technologies, Palantir, Hugging Face, Mistral, Mozilla и другие технологические компании, подписала письмо, в котором призвала политиков избегать преждевременных ограничений в отношении моделей с открытыми весами и отличать законную дистилляцию от неправомерного использования. Решение о том, стоит ли запрещать использование открытых моделей, таких как Kimi K3, определит, останется ли разработка продвинутого ИИ прерогативой небольшого числа лабораторий или станет доступной для более широкой экосистемы разработчиков.</p> <p>Более перспективная возможность — создать будущее, в котором возможности ИИ станут доступными, дешевыми, многовариантными и разнородными. Такое будущее зависит от расширения участия в разработке за пределами узкого круга передовых лабораторий и предоставления большему числу организаций возможности развивать ИИ на своих условиях. Открытые веса моделей — это основа, а открытая инфраструктура для пост-обучения — путь от простого доступа к инновациям. Ограничения на публикацию открытых моделей послужат сохранению дефицита в то время, когда начинают формироваться технические основы для создания более широкой и генеративной экосистемы.</p> <h3>Ограничения на использование открытых моделей защитят существующие компании от конкуренции</h3> <p>Запросы от OpenAI и Anthropic представляют дистилляцию как проблему, требующую вмешательства на государственном уровне для ограничения распространения моделей, разработанных другими организациями. Дистилляция — это практика использования результатов работы более мощной модели для обучения или улучшения менее мощной модели. Субъект, который активно обращается к передовой модели в течение многих сеансов, может использовать эти взаимодействия для создания второй модели, которая будет обладать некоторыми возможностями исходной системы. Эта вторая модель будет работать вне поля зрения, контроля доступа и системы безопасности исходного поставщика. OpenAI и Anthropic утверждают, что несанкционированная дистилляция их систем является кражей интеллектуальной собственности и что доступ к открытым моделям, созданным в результате такого копирования, должен быть запрещен.</p> <p>Однако провайдеры закрытых моделей уже контролируют доступ к системам, из которых происходит предполагаемая дистилляция. Они определяют, кто может использовать их модели, какой уровень доступа предоставляется пользователям, какие интерфейсы доступны, какие условия прописаны в договоре и какие виды автоматизированной деятельности влекут за собой принудительные меры. Провайдеры, считающие дистилляцию существенной угрозой, могут усилить аутентификацию, ввести ограничения на количество запросов, выявлять необычные шаблоны запросов, приостанавливать действие аккаунтов, ограничивать автоматическое извлечение данных и менять дизайн интерфейсов, чтобы скрыть особо ценные обучающие сигналы. Они также могут применять договорные права в отношении пользователей, нарушающих четко прописанные условия предоставления услуг. Вопрос о том, почему эти компании добиваются защиты со стороны регулирующих органов в отношении проблемы, которую они в состоянии решить с помощью собственной инфраструктуры, заслуживает пристального внимания.</p> <p>OpenAI и Anthropic добиваются вмешательства регулирующих органов в связи с тем, что модели общего назначения становятся все более доступными. Разрыв в возможностях между передовыми и открытыми моделями сокращается во все большем количестве областей, и предприятиям становится все проще заменять одну систему на другую. Открытые модели позволяют предприятиям размещать их у себя и адаптировать под свои нужды, а в перспективе — создавать специализированные системы для решения задач, для которых провайдеры закрытых моделей не разрабатывали свои продукты. </p> <p>Провайдеры закрытых моделей имеют больше возможностей для установления цен, поскольку немногие другие системы могут обеспечить сопоставимые результаты. Этот авторитет снижается, когда предприятия могут выбирать между несколькими проприетарными сервисами или использовать открытую модель, которую они могут модифицировать и применять в своей инфраструктуре. Даже если организация никогда не внедряла открытую модель, такая модель, оказывает конкурентное давление: сам факт ее существования дает клиентам альтернативу постоянной зависимости от одного поставщика.</p> <p>Не стоит считать, что открытая модель является результатом несанкционированной дистилляции только из-за того, что она открыта. Эффективная открытая модель может быть результатом государственных исследований, независимых экспериментов, использования синтетических и открытых наборов данных, повышения эффективности обучения или совокупной работы более широкого технического сообщества. Схожесть моделей сама по себе не является доказательством неправомерного заимствования. Регулирование, при котором схожесть возможностей рассматривается как доказательство кражи, позволит действующим поставщикам заявлять о своих исключительных правах на различные формы поведения моделей и общий технический прогресс. Государство не должно превращать опасения закрытых провайдеров по поводу контроля доступа в ограничения для открытой конкуренции.</p> <h3>Открытые модели обеспечивают конкуренцию и возможность создавать</h3> <p>Открытые модели дают организациям прямой доступ к системам ИИ, позволяющий проверять и адаптировать их, а затем использовать их там, где это необходимо. Если организация владеет весами модели, она может оценивать ее поведение напрямую, не полагаясь на доступ, предоставляемый небольшим числом частных лабораторий. Такой прямой доступ обеспечивает возможность кастомизации, локального развертывания, воспроизводимости, независимой проверки безопасности, а также организационный контроль над данными и управлением. Участие в разработке ИИ расширяется, когда все больше организаций могут создавать и тестировать системы, а затем совершенствовать их в соответствии со своими требованиями, а не в рамках ограничений, установленных поставщиком.</p> <p>Ни один управляемый сервис не может обеспечить такой же уровень контроля, как открытые модели. Государственные и регулируемые организации получают возможность контролировать условия развертывания, границы доступа к данным и соблюдение нормативных требований в рамках используемой ими инфраструктуры. Исследователи получают возможность изучать поведение моделей, тестировать их на безопасность и публиковать результаты без необходимости получать разрешение от разработчика системы. Независимые разработчики получают возможность развивать технические направления, представляющие значительную ценность в конкретной области или сообществе, даже если они не представляют особого коммерческого интереса для передовой лаборатории. Эти возможности зависят от того, кто владеет весами, а не от доступа к интерфейсу поставщика.</p> <p>Передовой API предоставляет организации доступ к возможностям на условиях, определяемых поставщиком: доступная модель, разрешенные формы использования, ценообразование, ограничения по скорости, политика хранения данных, меры безопасности и сроки внесения будущих изменений. Открытые модели дают другой уровень полномочий. Они позволяют организации проверять модель, использовать ее в рамках подконтрольной ей инфраструктуры, изменять процесс ее обучения, проводить собственные оценки и развивать направления, которые не были предусмотрены первоначальным поставщиком. Разница заключается в том, что в первом случае мы просто потребляем возможности, а во втором — обладаем средствами для их дальнейшего развития. Открытые модели превращают потребителей интеллектуальных технологий в их создателей.</p> <h3>Одних открытых весов недостаточно: пост-обучение тоже должен быть открытым</h3> <p>Пост-обучение — это этап, на котором передовые лаборатории обретают большую часть своего практического преимущества. Без открытой инфраструктуры для пост-обучения открытые веса остаются статичными артефактами. Организация, которая загружает открытую модель, но не имеет инструментов, сред, оценок и воспроизводимых методов, необходимых для ее пост-обучения, может использовать модель в том виде, в котором она была выпущена, но не может изменить ее функциональные возможности. На практике OpenAI, Anthropic и Google, похоже, удерживают свои позиции не столько за счет масштабов предварительного обучения или весов модели, сколько за счет того, что происходит после: масштабируемое обучение с подкреплением, обусловливание использования инструментов, восстановление после сбоев в многоэтапных рабочих процессах, моделирование вознаграждений и накопленный опыт, необходимый для превращения базовой модели в систему, которая надежно работает в производственной среде. Что отличает передовые лаборатории, так это полный набор средств разработки, связанных с этими опубликованными методами: качество обучающих данных, дизайн среды выполнения задач, точность оценок, формирование сигналов вознаграждения и решения команд, которые провели тысячи экспериментов и извлекли уроки из каждой неудачи.</p> <p>Таким образом, экосистема открытой модели должна включать не только загружаемые контрольные точки. Она должна включать инструменты, среду, оценки и воспроизводимые практики, необходимые для проведения полноценного пост-обучения. Без этих компонентов разрыв между использованием модели и развитием на ее основе специализированных возможностей для большинства организаций остается непомерно большим.</p> <p>Эта инфраструктура начинает обретать форму. Открытый проект NeMo RL от NVIDIA предоставляет масштабируемую инфраструктуру для обучения с подкреплением и пост-обучения, а NeMo Gym — среды, которые объединяют наборы данных, средства управления агентами, верификаторы и состояния для обучения и оценки. TRL от Hugging Face поддерживает контролируемую тонкую настройку, обучение с подкреплением, оптимизацию предпочтений и моделирование вознаграждений. OpenEnv предоставляет стандартизированные среды для выполнения агентных задач. Open-R1 предлагает общие обучающие скрипты, наборы данных, инструменты оценки, конвейеры для работы с синтетическими данными и методики разработки, которые другие команды могут воспроизвести и адаптировать под свои нужды. В совокупности эти проекты показывают, что открытое пост-обучение — это уже не просто идея. Многие из его составляющих уже существуют, хотя им ещё предстоит объединиться в единый, широко распространённый и воспроизводимый стек разработки.</p> <p>Сейчас приоритетной задачей является расширение доступности полноценных проектов пост-обучения, которые объединяют модели, наборы данных, среды, функции вознаграждения, инструменты оценки и экспериментальные данные в воспроизводимой форме. Такие проекты позволяют другим командам изучать процесс разработки, воспроизводить его результаты и адаптировать методы под другую модель или область. ПО с открытым исходным кодом стало базовой инфраструктурой именно благодаря такому накопительному эффекту. </p> <p>Открытое пост-обучение не сделает разработку продвинутых моделей лёгкой. Организациям по-прежнему будут требоваться значительные вычислительные мощности, высококачественные данные, эксперты-оценщики, специализированные среды и технические знания для диагностики неудачных запусков обучения. Важность этого подхода заключается в том, что он позволяет разорвать замкнутый круг, в котором знания, необходимые для создания продвинутого ИИ, сосредоточены в небольшом количестве лабораторий.</p> <h3>Экосистема открытых моделей позволяет развиваться множеству видов ИИ</h3> <p>Открытые модели и анализ открытого пост-обучения раскрывают важную истину, которую часто скрывает нынешняя структура рынка: у ИИ нет единого направления развития. Передовые модели от OpenAI, Anthropic и Google представляют собой особую и коммерчески выгодную концепцию развития ИИ, в которой упор делается на программирование, математические и научные методы, широкий охват знаний и гибкую работу в различных областях. Эта концепция занимает важное место в более широком поле исследований в области ИИ. Но возможности, которым отдают приоритет несколько передовых лабораторий, не должны становиться универсальным стандартом, по которому оцениваются все ИИ-достижения.</p> <p>Различные виды ИИ — это разные конфигурации знаний, восприятия, суждений и практических навыков, которые соответствуют разным стандартам совершенства. Научный ИИ выявляет закономерности в структуре белков или определяет перспективные направления в сложной области исследований. Инженерный ИИ учитывает физические ограничения, требования безопасности, эффективность и технологичность. Другие виды ИИ придают большее значение эстетическому суждению, внимательности, культурной компетентности, педагогике, вкусу или практической мудрости. Дизайнерский ИИ создает дом, отражающий воспоминания, потребности и повседневные ритмы людей, которые в нем живут. Культурный ИИ организует витрину книжного магазина, которая вызывает неожиданные ассоциации и приглашает к открытиям. Развивающий ИИ помогает семье выбрать медиа, подходящие для конкретного ребенка. Практический, или реляционный ИИ формирует семейный отдых, в котором сбалансированы финансовые аспекты, энергозатраты, доступность, конкурирующие интересы и впечатления, которые запомнятся разным людям.</p> <p>Каждый из этих видов ИИ предполагает различное сочетание фактических знаний, восприятия, эмпатии, понимания контекста, технической компетентности и здравого смысла. Некоторые формы ИИ отдают предпочтение математической правильности, научной обоснованности или инженерной точности. Другие отдают предпочтение красоте, согласованности, заботе, приспособленности, доверию, удовольствию или пониманию того, что будет работать у конкретных людей в конкретных условиях. Система может превосходно соответствовать одному набору стандартов и оставаться непримечательной по сравнению с другим, даже если она демонстрирует высокие результаты по широкому кругу критериев.</p> <p>Уважение к множественному ИИ остается совместимым со строгими стандартами достоверности, доказательности, компетентности, последовательности и совершенства. Различные точки зрения не стирают различия между правдой и ложью. Каждая форма ИИ должна соответствовать стандартам, соответствующим ее заявлениям и целям. Достоверный ИИ может принимать различные формы, служить различным целям и не поддаваться сведению к единой иерархии, определяемой эффективностью модели общего назначения.</p> <p>Таким образом, рынок ИИ с многообразной структурой будет иметь множество научных, технических, культурных, коммерческих и практических аспектов. Поставщики услуг общего назначения будут продолжать конкурировать за широкий кругозор, надежность и качество управляемых услуг. Специализированные разработчики, учреждения и сообщества могли бы создавать возможности, основанные на знании предметной области, эстетических суждениях, культурных знаниях, практическом опыте и различных концепциях успеха. Экосистема открытых моделей дает этим формам ИИ возможность развиваться, проходить испытания и доказывать свою ценность — процветая или нет, на их собственных условиях.</p> <h3>Выбор между дефицитом и изобилием</h3> <p>По мере того как уровень моделей становится все более доступным, а разрыв в возможностях сокращается, передовые разработки будут все больше отличаться по эксплуатационным качествам, которые требуются предприятиям: предсказуемость, задержка, время безотказной работы, региональная доступность, безопасность и соответствие нормативным требованиям — все это зависит от уровня управления, которое может обеспечить только поставщик с хорошими ресурсами. Эти характеристики оправдывают масштабные корпоративные закупки и зависят от объема капиталовложений, доступа к вычислительным ресурсам и инвестиций в инфраструктуру, для поддержки которых у передовых лабораторий есть уникальные возможности. Открытые модели и многовалентные формы ИИ расширяют рынок, предоставляя возможность развивать дифференцированный потенциал более широкому кругу организаций, в то время как передовые поставщики конкурируют за предоставление надежных, управляемых систем общего назначения корпоративного масштаба. В результате возникает экономика ИИ с бóльшим количеством разработчиков, новыми формами интеллекта и усилением конкурентного давления на всех уровнях.</p> <p>Споры об открытых моделях — это нечто большее, чем дискуссии о дистилляции или разногласия по поводу политики доступа. Они касаются того, останется ли возможность разрабатывать продвинутый ИИ в руках узкого круга поставщиков или же она станет более доступной, дешевой и будет охватывать весь спектр областей и организаций, которые в ней нуждаются. Запрет на открытые релизы сохранят дефицит в тот момент, когда начинают складываться условия для изобилия. Открытые модели — это основа. Открытое пост-обучение — это путь развития. От того, какое решение будет принято сейчас, зависит, какое будущее нас ждет.</p> Выпуск компанией Moonshot AI модели Kimi K3 возобновил споры о том, кто имеет право создавать продвинутый … article https://www.itweek.ru/themes/detail.php?ID=235276 Mon, 03 Aug 2026 09:11:07 +0300 <p><em>Более 70% крупных российских компаний используют искусственный интеллект в рабочих процессах. Публичные ИИ-сервисы изначально не предназначены для работы с корпоративными и персональными данными, поэтому бесконтрольное внедрение технологии создает для бизнеса скрытые угрозы.</em></p> <p><em>Рассмотрим главные риски и способы их снизить.</em></p> <h3>Утечки конфиденциальных данных</h3> <p>Сотрудники регулярно загружают в открытые ИИ-сервисы рабочие документы: договоры, финансовые отчеты, планы запусков. Информация попадает в среду, которую компания не контролирует. Техника промпт-инъекций позволяет злоумышленникам извлекать из моделей чужие конфиденциальные данные: достаточно сформировать набор специальных запросов, и нейросеть с определенной вероятностью выдаст сведения, которые ранее по невнимательности загрузил другой пользователь.</p> <p>Риск возрастает, когда компания бесконтрольно подключает ИИ-агента к бизнес-процессам и потокам корпоративных данных. В этом случае утечка может произойти через самого агента: он получает широкий доступ к внутренним системам, действия его при этом почти никто не отслеживает.</p> <h3>Советы без учета контекста</h3> <p>Нейросеть не знает внутренних процессов конкретной компании. Она опирается на обобщенные данные из открытых источников, поэтому ее рекомендации могут оказаться нерелевантными. Например, модель способна предложить исключить необходимый технологический процесс или подтолкнуть к неэффективным инвестициям, поскольку не погружена в нюансы устройства бизнеса.</p> <p>Любой совет, стратегию или документ, сгенерированный ИИ, нужно верифицировать с учетом реальной ситуации в бизнесе. Модель выдает правдоподобный текст, однако полная ответственность за решение всегда остается на сотруднике.</p> <h3>Юридические и репутационные риски</h3> <p>Контент, созданный нейросетями, не имеет исчерпывающей правовой защиты и может нарушать авторские права третьих лиц. Помимо проверки качества контента, перед использованием таких материалов также необходимо проверять информацию на соответствие законодательству и уточнять ее юридический статус.</p> <p>Отдельная зона риска связана с репутацией. ИИ может предлагать маркетинговые стратегии, которые нарушают этические нормы или опираются на стереотипы, неприменимые к целевой аудитории. Публикация подобных материалов оборачивается для бренда репутационными потерями. Валидировать информацию от ИИ должен человек, который понимает ценности компании и особенности ее клиентов.</p> <h3>Как снизить риски</h3> <p>Безопаснее всего использовать ИИ-инструменты, размещенные в контуре компании или у доверенного сервис-провайдера: бизнес либо самостоятельно управляет моделью, либо контролируемо делегирует ИИ-функции третьей стороне с защищенной обработкой данных.</p> <p>Снизить угрозы помогает набор базовых правил:</p> <ul> <li> определить, какие данные запрещено загружать в публичные ИИ-сервисы, и закрепить это в регламенте;</li> <li> использовать корпоративные ИИ-решения с защищенной обработкой данных без их сохранения и использования для обучения моделей;</li> <li> ограничить доступ ИИ-агентов к внутренним системам и логировать их действия;</li> <li> верифицировать сгенерированный контент: проверять факты, юридический статус и соответствие ценностям бренда;</li> <li> обучать сотрудников правилам работы с нейросетями и разбирать реальные инциденты.</li> </ul> <p>Искусственный интеллект стоит воспринимать как мощный инструмент, требующий тех же правил гигиены, что и любая корпоративная система. При работе с ней необходимо выстроить иерархию доступов, регламенты работы с данными, обучение сотрудников. Тогда технология будет приносить пользу без скрытых издержек.</p> <p>#IMAGE_235277#</p> Более 70% крупных российских компаний используют искусственный интеллект в рабочих процессах. Публичные ИИ-сервисы … article Леонид Плетнев, бизнес-партнер по информационной безопасности “1С-Битрикс” https://www.itweek.ru/themes/detail.php?ID=235274 Fri, 31 Jul 2026 12:39:15 +0300 <p>Аналитическая компания Apple Hills Digital опубликовала отчёт «Рынок IaaS в России: прогноз до 2030 года и позиционирование лидеров» и впервые — карту ключевых игроков. В фокус исследования вошли восемь крупнейших провайдеров публичной облачной инфраструктуры: Cloud.ru, K2 Cloud, MWS, РТК ЦОД / Турбо Облако, Selectel, T1 Cloud, VK Cloud, Yandex Cloud.</p> <p>Рынок продолжает расти на фоне цифровизации и импортозамещения. Объём рынка публичного IaaS в России в 2025 году составил 96 млрд рублей.</p> <p>При среднегодовом темпе роста около 20% объем рынка к 2030 году более чем удвоится и достигнет 241 млрд рублей. Рост поддерживают цифровизация отраслей, потребность в гибком доступе к вычислительным ресурсам без капитальных вложений и импортозамещение. Среди сдерживающих факторов — высокая совокупная стоимость владения и низкая зрелость Developer Experience (удобство и скорость работы инженерных команд с облачной платформой — от развёртывания «из коробки» до готовых инструментов интеграции).</p> <p>AI/ML и гибридная инфраструктура — новые поля конкуренции.</p> <p>Исследование выявило ключевые тенденции рынка:</p> <ul> <li>надёжность остаётся приоритетом № 1. 72% заказчиков называют надёжность и стабильность инфраструктуры главным критерием выбора провайдера. Безопасность и соответствие стандартам ставят на второе место 54% респондентов;</li> <li>конкуренция смещается в сторону AI. Свыше 80% компаний отмечают влияние AI/ML на потребление ресурсов, а 24% фиксируют резкий рост использования GPU-инстансов. Среди тех, кто планирует увеличить бюджет на IaaS, 42% закладывают в него именно AI/ML-нагрузки;</li> <li>гибрид и cloud-native становятся нормой. 52% компаний используют гибридную инфраструктуру, а Managed Kubernetes, инфраструктура как код (IaC) и self-service вошли в базовый набор инструментов для пользователей облака. Популярность гибридной инфраструктуры растёт на фоне потребности бизнеса в гибком доступе к вычислительным ресурсам без крупных капитальных вложений в собственную инфраструктуру. Дополнительный фактор — требования к локализации данных на территории РФ;</li> <li>контроль затрат — узкое место рынка. 75% компаний пока не автоматизируют контроль облачных расходов, и это одна из главных точек роста для всего рынка. Так, среди компаний, планирующих увеличить бюджет на IaaS, 34% отдельно закладывают в приоритеты аудит и оптимизацию расходов. Не последнюю роль играет и зрелость инструментов самих провайдеров — прозрачность биллинга и удобство тегирования расходов пока не везде реализованы на достаточном уровне.</li> </ul> <p>Отчёт рассматривает восемь ключевых провайдеров IaaS на одной позиционной карте рынка по двум независимым осям: горизонтальная «Стратегия, инновации и надёжность» и «Технологические возможности». Критерии оценки были взвешены в соответствии с результатами опроса корпоративных заказчиков по приоритетным требованиям к провайдеру IaaS. </p> <p>Исследование основано на трёх источниках: детализированных данных, предоставленных провайдерами для целей исследования, интервью с руководством провайдеров, количественном опросе корпоративных пользователей облачной инфраструктуры и экспертной оценке аналитиков AHD.</p> <p>«По мере повышения зрелости рынка конкуренция между лидерами принимает более многоплановую форму. Исследование показало, что цена уже не является главным фактором выбора провайдера: компании переносят в облако все более серьезные нагрузки и чувствительные данные, и применяют широкий набор критериев выбора, отдавая приоритет надёжности, безопасности и удобства интеграции облачного сегмента в свой ИТ-ландшафт», — отметил Василий Пименов, руководитель программы исследований российского рынка Apple Hills Digital</p> <p> </p> Аналитическая компания Apple Hills Digital опубликовала отчёт «Рынок IaaS в России: прогноз до 2030 года … message https://www.itweek.ru/themes/detail.php?ID=235271 Fri, 31 Jul 2026 11:39:23 +0300 <p><em>Low-code снижает нагрузку на ИТ-команды и ускоряет решение задач. Однако без правильного управления изменениями с этой платформой бизнес получает «зоопарк» приложений и постепенно теряет контроль над собственным цифровым контуром. Рассмотрим, почему портфель low-code может превратиться в технический долг и как этого избежать.</em></p> <h3>Обратная сторона быстрых изменений</h3> <p>Технологию low-code часто начинают внедрять с рациональной управленческой мотивацией: бизнесу нужно быстрее запускать изменения, проверять гипотезы, автоматизировать локальные процессы и снижать нагрузку на традиционные ИТ-команды. На уровне отдельных проектов положительный эффект такого подхода очевиден: приложения выпускаются быстрее, и бизнес раньше получает результат. Однако у повышенной скорости есть обратная сторона.</p> <p>Low-code ускоряет не только создание решений, но и накопление изменений в компании. Если ими не управлять, через некоторое время вместо гибкого цифрового контура можно получить «зоопарк» приложений: множество локальных решений с разными владельцами, правами доступа, интеграциями, версиями, правилами сопровождения и уровнями качества.</p> <p>Такая ситуация складывается не из-за проблем в каждом конкретном приложении. По отдельности решения могут успешно выполнять полезные функции — например, управлять согласованием, обрабатывать заявки, автоматизировать отчетность или связывать несколько внутренних систем. Риски возникают на уровне совокупности.</p> <p>Когда на базе low-code появляются десятки или сотни приложений, компания должна понимать, где они находятся, какие данные обрабатывают, кто ими владеет, какие процессы от них зависят, кто имеет доступ к решениям, как они обновляются и что будет происходить при сбоях. В противном случае low-code постепенно превращается в технический долг, причем это может происходить не только из-за некачественного кода.</p> <h3>Механизм накопления технического долга</h3> <p>Технический долг появляется везде, где в бизнес-процесс входит low-code-решение без полноценного жизненного цикла. Это значит, что приложение создали, запустили, начали использовать, но не включили в реестр, не назначили владельца, не описали интеграции, не согласовали правила доступа, не определили порядок поддержки и вывода из эксплуатации.</p> <p>На ранней стадии это почти незаметно: приложение работает, пользователи довольны, а бизнес-заказчик быстро получает нужные результаты. Но совсем скоро могут появиться серьезные трудности, если изменится процесс, уйдет сотрудник, который понимает логику решения, обновится платформа, появится новое требование безопасности или перестроится интеграция со смежной системой. В таком случае критичный участок процесса будет зависеть от приложения, которое никто не будет полноценно сопровождать.</p> <p>Для крупных компаний это особенно чувствительно. В них даже небольшое локальное решение может быть связано с клиентскими данными, финансовыми операциями, договорным контуром, внутренними согласованиями или требованиями регуляторов. Если таких решений много и они не описаны, поверхность риска особенно велика, но руководители могут ее не замечать.</p> <p>Агенты на базе искусственного интеллекта усиливают потенциал развития негативных факторов на фоне пробелов в управлении изменениями. Если low-code ускоряет создание приложений и автоматизацию процессов, то ИИ-инструменты позволяют быстрее формировать сценарии действий в корпоративных системах. Это может быть полезно, только если компания понимает, какие действия выполняются, от чьего имени, с какими правами и цифровым следом. Без такого контроля скорость начинает работать против управляемости.</p> <h3>Пять признаков неуправляемости</h3> <p> Можно выделить пять основных признаков неуправляемого «зоопарка» low-code-решений:</p> <ul> <li> <strong>Дублирование функций</strong><strong>.</strong> Например, оно возникает, если разные подразделения создают похожие приложения для заявок, отчетности, согласований или контроля задач. Каждое из них решает локальную проблему, но вместе они усложняют архитектуру, размывают стандарты и мешают масштабировать эксплуатацию компонентов.</li> <li> <strong>Неизвестные владельцы</strong><strong>.</strong> Бывает так, что приложение используется, но непонятно, кто отвечает за его развитие, поддержку, данные и принятие решений при изменении процесса. В результате ИТ-команда становится заложником уже работающего решения: бизнес требует стабильности, но формальной ответственности и ресурсов на сопровождение нет.</li> <li> <strong>Неописанные интеграции</strong><strong>.</strong> Low-code-решения могут быть связаны с CRM (системой управления взаимоотношениями с клиентами), ERP (системой планирования ресурсов предприятия), документооборотом, хранилищем данных, почтой, календарями или внешними сервисами. Если эти связи не зафиксированы, любое изменение в смежной системе может привести к сбою, который сложно быстро диагностировать.</li> <li> <strong>Разная зрелость доступа и безопасности</strong><strong>.</strong> Например, такая проблема возникает, если в одном приложении права настраивают оптимально, в другом их выдают слишком широко, а в третьем используют временные учетные записи, которые становятся постоянными. Пока решений мало, можно вручную обеспечивать безопасность в подобных ситуациях. Когда приложений становится много, ручной контроль перестает работать.</li> <li> <strong>Отсутствие правил вывода из эксплуатации</strong><strong>.</strong> В компаниях часто описывают процедуры запуска новых решений, но гораздо реже — регламенты их закрытия. В результате старые приложения продолжают работать, хранить данные, применять права доступа и зависеть от платформы — даже после изменения бизнес-потребности.</li> </ul> <h3>Пять составляющих управляемого контура</h3> <p>Зрелый подход к low-code начинается не с запретов и попыток вернуть все изменения в зону классической разработки. Это было бы неправильно: компаниям действительно нужна скорость, просто ее необходимо встроить в управляемый контур. Он формируется из пяти основных составляющих:</p> <ul> <li> <strong>Единый реестр low-code-приложений</strong><strong>.</strong> Бизнес должен владеть информацией не только о крупных системах, но и обо всех прикладных решениях, которые создаются на платформах low-code. Должны быть доступны сведения о назначении, владельцах, пользователях, подключенных данных, интеграциях, критичности, статусе, версиях и правилах поддержки приложений.</li> <li> <strong>Модель владельцев</strong><strong>.</strong> У каждого решения должен быть бизнес-владелец, отвечающий за цель, процесс и эффект. Также необходимо описывать технический контур ответственности для всех low-code-приложений: кто их сопровождает, обновляет, проверяет безопасность и принимает решения при изменениях.</li> <li> <strong>Архитектурные ограничения</strong><strong>.</strong> Не все задачи подходят для исполнения на базе low-code. В одних случаях эта платформа дает быстрый и качественный результат, а в других решения лучше реализовывать иначе. Провести такую границу помогут заранее разработанные критерии применимости. Они должны отвечать на вопросы, какие процессы можно автоматизировать в контуре low-code, какие данные допустимо обрабатывать, какие интеграции разрешены и какие сценарии требуют участия архитектора или службы безопасности.</li> <li> <strong>Правила сопровождения</strong><strong>.</strong> Работа над приложением не заканчивается в момент запуска. Его нужно обновлять, тестировать, поддерживать, контролировать доступ, отслеживать инциденты и стоимость владения. Без этих составляющих можно оценить только скорость разработки без учета всех факторов, влияющих на цену решения.</li> <li> <strong>Управление портфелем</strong><strong>.</strong> Low-code-приложения нужно рассматривать не как набор разрозненных инициатив, а как портфель изменений. В нем видны повторяющиеся сценарии, потенциальные типовые компоненты, решения с высоким риском, устаревшие приложения и зоны, в которых нужен не локальный инструмент, а системная автоматизация.</li> </ul> <h3>От количества к качеству</h3> <p>В повышении управляемости портфеля low-code важную роль играет центр компетенций. Его задача совсем не в том, чтобы оттянуть на себя все процессы разработки и превратиться в бюрократический фильтр. Он должен задавать правила, помогать бизнесу выбирать правильные сценарии, поддерживать каталог решений, развивать типовые шаблоны, контролировать качество и снижать риски масштабирования.</p> <p>Зрелая работа с low-code в крупной корпорации требует комплексного подхода и при вовлечении системного интегратора. Его участие не сводится к внедрению платформы или сборке первых приложений. Он должен выступать как партнер, который помогает выстроить управляемую систему: от обследования и создания архитектурных правил до разработки ролевой модели, интеграций, сопровождения и развития портфеля решений.</p> <p>Low-code действительно может ускорить изменения в компании, но если у приложений нет владельцев, реестра, правил обновления, архитектурных ограничений и понятного места в ИТ-ландшафте, эта платформа станет не драйвером цифровизации, а скорее источником будущих инцидентов. Поэтому главный вопрос не в том, сколько приложений компания может быстро создать на базе low-code, а в том, сколько из них она сможет безопасно сопровождать, развивать и контролировать через год, два или три. Именно это отделяет эксперимент с технологией от реализации полноценной системы корпоративных изменений.</p> <p>#IMAGE_235272#</p> Low-code снижает нагрузку на ИТ-команды и ускоряет решение задач. Однако без правильного управления изменениями … article Михаил Миронов, директор отделения low-code-решений группы компаний IBS https://www.itweek.ru/themes/detail.php?ID=235264 Fri, 31 Jul 2026 00:00:00 +0300 <p><em>Автономный бизнес будущего вовсю строится. Определенные навыки уже пользуются высоким спросом — и они могут помочь вам выделиться, рассказывают опрошенные порталом </em><em>ZDNet</em> <em>эксперты.</em></p> <p>Искусственный интеллект поддерживает развитие автономного бизнеса, где некоторые роли, которые мы сегодня считаем само собой разумеющимися — от базовых операционных задач до принятия решений — выполняются агентами, способными обнаруживать, вести переговоры и совершать сделки.</p> <p>Широко распространены опасения, что эта эпоха автономии будет означать меньше работы для профессионалов, особенно в ИТ-отделах. Однако, как постепенно становится ясно, будущее работы потребует тщательного сочетания человеческого опыта и возможностей ИИ, когда профессионалы будут эффективно и продуктивно работать со своими коллегами-агентами.</p> <p>Итак, какие навыки помогут вам преуспеть на агентном рабочем месте будущего? Эксперты предполагают, что лучшие перспективы будут иметь три типа профессионалов: технически подкованные специалисты по поддержке, корректировщики курса агентов и ориентированные на результат сотрудники.</p> <h3>1. Технологически подкованные специалисты по поддержке</h3> <p>Хотя сегодня основное внимание уделяется автономной работе агентов, для максимального использования возможностей ИИ необходимы сильные внутренние технические возможности, считает Алекс Рид, старший менеджер по корпоративным продуктам в области данных энергетической компании EDF UK.</p> <p>Его команда по работе с данными помогает более чем 1000 пользователям использовать агентный ИИ в масштабах всей компании. Эта команда находится в центре федеративной модели «хаб-узлы» (hub-and-spoke), где специалисты по данным и цифровым технологиям сосредоточены на технологической поддержке, а бизнес-подразделения — на создании ценности.</p> <p>«Контекст — это главное для ИИ, — говорит Рид. — Нашим инженерам в работе с агентными и ИИ-ориентированными сервисами необходима высокая квалификация для создания вспомогательных возможностей, взаимодействующих с этими сервисами».</p> <p>Его команда использует технологии Snowflake, такие как Semantic Tables и Horizon Data Catalogs, для определения ресурсов данных и обеспечения их понятности для агентов ИИ. Затем команда создает возможности, используя агент по кодированию Snowflake CoCo на основе платформы данных этой компании.</p> <p>Один из примеров — инструмент, помогающий сотрудникам сервисного центра обрабатывать запросы клиентов. Команда Рида разработала с использованием CoCo агента, который извлекает информацию из платформы данных Snowflake и предоставляет аналитические данные в пользовательском интерфейсе Slack для сотрудников. «Инженер берет то, что производит такой инструмент, как CoCo, и немного улучшает это или, возможно, адаптирует для повышения точности», — рассказывает он.</p> <p>Самир Вуйюру, директор по ИИ и продуктам компании Capita, — еще один лидер в цифровой сфере, изучающий, как его организация может использовать агентные технологии, и квалифицированные специалисты также играют в этом процессе особую роль.</p> <p>Capita создала стек AI Catalyst, который фокусируется на наблюдаемости процессов и показывает, как автоматизация рабочих процессов может повысить операционную эффективность.</p> <p>По словам Вуйюру, эти исследования привели его к выводу о необходимости оттачивать свои технические навыки уже сейчас и искать способы сочетать свой опыт с агентными инструментами для создания сервисов нового поколения, приносящих бизнесу ценность. «Начните работать с ИИ каждый день, — советует он. — Мы сделали значительные инвестиции в предоставление каждому из тысяч наших сотрудников доступа к инструментам ИИ. И те, кто освоил ИИ, а это подавляющее большинство, к моему удивлению, в восторге от него и используют ежедневно».</p> <h3>2. Корректировщики курса агентов</h3> <p>Однако, хотя профессионалы могут повысить свою производительность, используя новые технологии, агентный ИИ не может работать в полной изоляции.</p> <p>Рид отмечает, что лучшие ИТ-специалисты работают с экспертами в предметной области, обладающими глубокими знаниями бизнеса, чтобы обеспечить эффективную работу агентов.</p> <p>«Хотя я с восторгом говорю о таких инструментах, как CoCo и Semantic Tables, мы по-прежнему полагаемся на ведущих экспертов, обладающих 20-30-летним опытом работы в энергетической отрасли, — говорит он. — Успех невозможен без применения этих экспертных знаний, чтобы помочь агентам ИИ быть более продуктивными и точными. Кроме того, когда возникают технические проблемы или, возможно, неточности, вам нужен кто-то, кто понимает технические и предметные возможности для корректировки курса».</p> <p>Это мнение разделяет и Стивен Вуд, операционный директор Rathbones Asset Management, который считает, что профессионалам в эпоху агентов — будь то в ИТ-отделе или в бизнес-функциях — необходимо перейти к новому способу работы.</p> <p>Хаотичные, импровизированные структуры традиционного офиса, где люди работают над задачами и стремятся к достижению целей проекта, уходят в прошлое. На смену им приходит новая система взаимоотношений, в которой профессионалы контролируют своих коллег-агентов.</p> <p>Отмечая сложную природу процессов совместной работы, Рид говорит, что «сейчас нам действительно нужны эксперты, которые знают свое дело, участвуют в процессе и осуществляют окончательный контроль и ставят галочку».</p> <p>По словам Вуда, подобный контроль является естественным элементом в его строго регламентированном и ориентированном на процессы бизнесе. Однако он признает, что трансформация рабочего места в основанное на агентном взаимодействии создаст значительные проблемы для всех. «Это будет совершенно другой способ ведения дел, — сказал он. — Поэтому возникнет некоторое трение, верно? Но успех будет сопутствовать тем компаниям и те людям, которые примут агентный ИИ, поймут его и захотят вывести его на новый уровень».</p> <h3>3. Сотрудники, ориентированные на результат</h3> <p>Признание потенциальной мощи ИИ — это только отправная точка. Четкое понимание долгосрочной бизнес-цели имеет решающее значение для внедрения агентов. По словам Дэна Чероубриера, технического директора Formula E, преуспевать будут профессионалы с таким подходом. Люди, обладающие этими навыками, помогут своим организациям получать экономическую выгоду от ИИ</p> <p>«Неудачниками окажутся те компании, которые берут свои существующие процессы, построенные вокруг людей, отделов и разрозненных структур, и пытаются создавать агентов для этих процессов, а не для достижения желаемых бизнес-результатов», — говорит Чероубриер.</p> <p>Он приводит пример разработки ПО, в которой агентный ИИ трансформирует традиционные методы. Талантливые инженеры концентрируют свои экспертизу на начале процесса разработки, чтобы направить агентов в нужное русло, не ожидая более поздних этапов.</p> <p>«Если говорить о результате при написании приложения, то раньше экспертные знания подключались в последнюю очередь — кодирование в конце и тестирование в некоторой степени, — говорит Чероубриер. — Теперь, с агентами, эти знания должны применяться на начальном этапе, при определении требований. Если вы с самого начала не понимаете, что вам нужно сделать, то, я думаю, у вас возникнут трудности».</p> <p>Мурали Сваминатан, технический директор компании Freshworks, также подчеркивает важность четкого определения бизнес-целей. Он считает, что квалифицированные специалисты должны сначала убедиться, что агенты обеспечивают правильные результаты, прежде чем применять технологию к бизнес-процессам. «Удостоверьтесь, что всё действительно работает, воспроизводимо, а затем включите технологию, — говорит он. — Вместо того чтобы попытаться включить всё сразу и столкнуться с тоем, что это не работает, следует попробовать несколько вариантов, добиться успеха, укрепить уверенность и доверие, а затем внедрить сервис для всех».</p> <p>Таким образом, агентам потребуется тщательное руководство. И хорошая новость для профессионалов, по словам Луизы Ньюбери-Смит, руководителя подразделения Zoom в Великобритании и Ирландии, заключается в том, что успешное достижение целей с помощью агентных технологий будет в значительной степени человекоцентричным процессом.</p> <p>«Вы должны лично вкладываться в любую деятельность, которую вы выполняете, и в цели, которых вы стремитесь достичь. Речь идёт о том, чтобы ИИ расширял возможности человека, а не заменял его. Именно такой подход позволяет всем оставаться востребованными и создавать будущее», — говорит она.</p> Автономный бизнес будущего вовсю строится. Определенные навыки уже пользуются высоким спросом — и они могут помочь вам … article https://www.itweek.ru/themes/detail.php?ID=235270 Thu, 30 Jul 2026 14:14:02 +0300 <p>После анализа индивидуальных практик использования искусственного интеллекта российскими учеными Институт статистических исследований и экономики знаний (ИСИЭЗ) НИУ ВШЭ впервые оценил, насколько эти технологии интегрированы в деятельность государственных организаций сферы науки — вузов и НИИ.</p> <p>ИИ находит широкое применение в деятельности организаций сферы науки, оптимизируя их бизнес-процессы и практики. ИИ-решения используются в 72% государственных вузов и НИИ, чаще всего — для проведения научных исследований (62% организаций).</p> <p>Вузы внедряют ИИ-решения в целом несколько активнее, чем НИИ (75% против 67%). Наиболее заметны различия в административных и коммуникационных процессах. Так, ИИ используют для внешних коммуникаций, включая продвижение результатов исследований, 40% вузов и лишь 18% НИИ, для управления организацией — 24% и 10% соответственно, для управления персоналом — 12% и 2%. При этом непосредственно в научных исследованиях различия практически отсутствуют: ИИ применяют 60% вузов и 64% НИИ.</p> <p>Чем крупнее организация, тем активнее она внедряет ИИ. Во внутренних процессах эти технологии используют 63% организаций с численностью до 500 сотрудников; 73% организаций, где работают <nobr>501–1000 человек;</nobr> 82% организаций с численностью <nobr>1001–2000 сотрудников;</nobr> и 92% крупнейших организаций (2000+ сотрудников). Во многом это связано с состоянием цифровой инфраструктуры. Крупные организации значительно чаще располагают облачными сервисами (69% против 49% среди остальных), серверными кластерами (73% против 35%), собственными центрами обработки данных (37% против 11%) и суперкомпьютерами (37% против 5%).</p> <p>Индивидуальное использование ИИ заметно опережает институциональное. По оценкам руководителей, ученые используют ИИ уже в 94% организаций, однако в большинстве случаев — на уровне отдельных исследователей. Только 4% руководителей считают, что ИИ используют большинство сотрудников их организации, еще в 27% — значительная часть коллектива, в 63% — лишь некоторые исследователи.</p> <p>ИИ пока остается прежде всего вспомогательным инструментом. В 43% организаций, сотрудники которых применяют ИИ в научных исследованиях, к нему обращаются главным образом для подготовки текстов, перевода, поиска литературы и других сопутствующих задач. В 22% ИИ используется как инструмент для анализа данных, моделирования и решения научных задач. Для четверти организаций (26%) обе функции одинаково значимы. Лишь 2% руководителей считают, что в их организациях ИИ является неотъемлемой частью научного процесса.</p> <p>В организациях, где исследователи используют ИИ, значительно чаще применяют готовые решения, российские — в 81% организаций, зарубежные — в 71%. Дообученные или адаптированные модели применяют 22% организаций, примерно столько же разрабатывают собственные модели; и сосредоточены такие проекты главным образом в естественных (68%) и технических (41%) науках, тогда как в гуманитарных они пока единичны (5%).</p> <p>Руководители ожидают дальнейшего распространения ИИ. По их оценкам, через пять лет почти в половине организаций (46%) ИИ будут использовать все или большинство исследователей, еще в 38% — их значительная часть. Лишь 16% считают, что ИИ останется инструментом отдельных исследователей, а 1% полагают, что его не будут использовать вовсе.</p> <p>Результаты двух опросов ИСИЭЗ НИУ ВШЭ показывают, что ИИ уже широко используется в российской науке как отдельными исследователями, так и организациями. Институциональное внедрение отстает от индивидуального использования, однако руководители государственных вузов и НИИ ожидают, что в ближайшие годы этот разрыв будет сокращаться, а ИИ станет привычным элементом исследовательской и организационной деятельности.</p> После анализа индивидуальных практик использования искусственного интеллекта российскими учеными Институт статистических … message https://www.itweek.ru/themes/detail.php?ID=235269 Thu, 30 Jul 2026 14:11:56 +0300 <p>По данным опроса Nexign, СУБД от отечественных вендоров доминируют в инфраструктуре российских компаний — об их использовании сообщили 66% респондентов. 54% опрошенных применяют решения с открытым исходным кодом, 40% продолжают эксплуатировать зарубежные системы, еще 6% затруднились с ответом.</p> <p>Такие результаты отражают переходный характер текущего этапа развития ИТ-ландшафта в России. Существенная доля зарубежных решений объясняется значительным объемом устаревшей инфраструктуры в слое прикладных корпоративных систем. Многие бизнес-критичные приложения исторически разрабатывались и внедрялись в тесной связке с конкретными СУБД. Пока прикладной слой не модернизирован или не заменен, полная миграция баз данных зачастую оказывается либо технически сложной, либо экономически неоправданной.</p> <p>По данным исследования, компании в среднем используют более одного типа СУБД, комбинируя вендорские продукты и системы с открытым исходным кодом. Такой подход продиктован несколькими важными факторами. Во-первых, бизнес стремится снизить риски зависимости от вендора. Во-вторых, значительная часть существующих систем не может быть быстро выведена из эксплуатации без ущерба для бизнес-процессов. В-третьих, использование различных СУБД позволяет компаниям балансировать между стоимостью владения, доступностью квалифицированной поддержки и надежностью решения. Также наличие открытого кода дает необходимую гибкость и свободу в настройке, в то время как вендорские решения обеспечивают формальные гарантии и SLA.</p> <p>Однако гибридный подход несет и определенные риски. Главный из них — возрастающая сложность администрирования и поддержки разнородной инфраструктуры. Кроме того, усложняется мониторинг и обеспечение безопасности: при неграмотном использовании открытого кода в системе могут образовываться серьезные уязвимости. Существует также риск непредсказуемого роста совокупной стоимости владения при недостаточно продуманной архитектуре.</p> <p>Если говорить о критериях, на которые заказчики обращают внимание при выборе СУБД, то для 68% опрошенных компаний ключевыми требованиями являются отказоустойчивость, поддержка кластеризации и возможность быстрого восстановления после сбоев. Для 66% важны поддержка высокой нагрузки и масштабируемость, включая горизонтальное масштабирование и репликацию. Соответствие требованиям ФСТЭК и Роскомнадзора, а также наличие сертификации по защите данных указывают своим приоритетом 38% опрошенных. Это говорит о том, что для заказчиков становятся важны не только функциональность СУБД, но и технические характеристики, которым ранее уделялось меньше внимания. Компаниям сейчас не нужен «комбайн» со множеством новых функций. Прежде всего они ждут, что СУБД легко впишется в текущий ИТ-ландшафт и обеспечит безболезненный перенос данных. </p> <p>«Российский бизнес демонстрирует прагматичный подход к трансформации СУБД-ландшафта, строя гибридные инфраструктуры, которые позволяют сочетать надежность, гибкость и экономическую эффективность. Оптимальная стратегия сейчас — сегментировать системы и данные по критичности, определить, какие из них можно мигрировать быстро, и выстроить дорожную карту перехода к единой отечественной СУБД. Поэтапный и стратегически выверенный подход позволит компаниям снизить риски, сохранить устойчивость ИТ-инфраструктуры и обеспечить технологический суверенитет в долгосрочной перспективе», — считает Максим Нартов, директор по развитию бизнеса Nexign.</p> По данным опроса Nexign, СУБД от отечественных вендоров доминируют в инфраструктуре российских компаний — … message https://www.itweek.ru/themes/detail.php?ID=235268 Thu, 30 Jul 2026 14:10:48 +0300 <p>Компания Postgres Professional представила новую версию платформы для управления и мониторинга баз данных Postgres Pro Enterprise Manager (PPEM) 2.8. В релиз вошли новые инструменты для управления отказоустойчивыми кластерами, централизованной настройки инфраструктуры и оптимизации запросов СУБД.</p> <p>Одним из ключевых нововведений стала поддержка настройки кворумной синхронной репликации для BiHA-кластеров через графический интерфейс. Новый механизм позволяет гибко выбирать баланс между скоростью обработки транзакций и защитой данных, упрощая построение отказоустойчивой инфраструктуры без ручной настройки.</p> <p>В новой версии также расширены возможности централизованного управления конфигурацией. Администраторы могут просматривать и изменять параметры кластеров и отдельных узлов через веб-интерфейс, в том числе задавать различные настройки для разных серверов в рамках одной операции.</p> <p>PPEM 2.8 получил поддержку Adaptive Query Optimization (AQO) — технологии адаптивной оптимизации запросов, которая помогает автоматически исправлять планы запросов основываясь на статистике предыдущего выполнения и таким образом повышать производительность высоконагруженных систем.</p> <p>Кроме того, в платформе появились средства управления параметрами сбора метрик и журналов для pgpro-otel-collector, раздел для работы с пользовательскими профилями и активными сессиями, новые возможности мониторинга, а также ряд улучшений интерфейса и механизмов обслуживания репозитория.</p> <p>Postgres Pro Enterprise Manager входит в состав всех редакций СУБД Postgres Pro и предоставляет единый веб-интерфейс для мониторинга, администрирования и диагностики баз данных.</p> Компания Postgres Professional представила новую версию платформы для управления и мониторинга баз данных Postgres Pro … message https://www.itweek.ru/themes/detail.php?ID=235263 Thu, 30 Jul 2026 00:00:00 +0300 <p><em>Поскольку агенты искусственного интеллекта берут на себя выполнение задач, человеческая роль становится ключевой. Ману Нараян, </em><em>CIO</em> <em>компании GitLab, рассказывает на портале </em><em>The</em> <em>New</em> <em>Stack</em> <em>о том, как преуспеть в условиях перехода к нелинейному росту производительности.</em></p> <p>Более десяти лет лидеры используют термин «будущее работы», чтобы описать, как технологии трансформируют бизнес. SaaS заменил локальное ПО. Облако заменило физическую инфраструктуру. Инструменты для совместной работы заменили офис как место, где мы выполняем задачи.</p> <p>Технологии переживают очередной период революционных изменений. На этот раз темпы этих изменений еще выше, чем в предыдущие периоды. Например, возможности ИИ по решению все более сложных задач в разработке ПО <a href="https://arxiv.org/abs/2503.14499">удваиваются</a> примерно каждые семь месяцев. Мы вот-вот станем свидетелями значительного сдвига в сторону нелинейного роста производительности, когда ИИ переосмыслит саму работу. Это порождает новые вопросы о том, кто или что выполняет работу.</p> <h3>Пришло время для работы, ориентированной на цель</h3> <p>ИИ-трансформация требует от нас нового подхода. Нынешний способ организации работы, измерения производительности и развития талантов предполагает, что человек, который производит больше всех, работает быстрее всех и знает больше всех, является лучшим сотрудником. Это предположение никуда не денется, но одного его уже недостаточно.</p> <p>Генеральный директор NVIDIA Дженсен Хуанг четко изложил, как переосмыслить нашу работу с ИИ, <a href="https://www.youtube.com/watch?v=k-xtmISBCNE&t=543s">противопоставив</a> задачи и цель. В каждой работе есть задачи. Для инженера-программиста кодирование — это задача. Но цель разработки ПО заключается в том, чтобы решать проблемы с помощью технологий и находить новые задачи, которые стоит решать. В этом новом мире ИИ, когда задач для человека становится все меньше, цель становится для него все более важной.</p> <p>Короче говоря, задачи инженера, аналитика или даже рекрутера все чаще могут выполняться агентами ИИ. Но цель, стоящая за каждой из этих ролей, остается, потому что цель коренится в ценности, которую мы придаем работе, а не в ее выполнении. Это различие можно обобщить на любую бизнес-функцию. Вопрос больше не в том, «как мне сделать это лучше?». Вместо этого работникам нужно задать себе вопрос: «Как мне руководить командой агентов, чтобы они справились с этим, чтобы я мог сосредоточиться на реальной ценности своей роли?».</p> <p>В новой модели взаимодействия человека и агента мы определяем цель. Каждый становится менеджером, задавая намерения, определяя результаты, делегируя выполнение агентам, оценивая результаты и корректируя курс с помощью суждений, которые ни одна модель не может воспроизвести.</p> <h3>Как на самом деле выглядит нелинейная производительность</h3> <p>Нам также пора переосмыслить наше понимание производительности, основанной на ИИ. Мне нравится думать об этом так: Томас Эдисон не стал решать проблему тусклого света свечи, создав лучшие свечи. Он изобрел лампочки. Точно так же речь идет не о 5% или 10% повышения производительности, а скорее об изменении качества; это как переход от света свечи к электричеству, а не от тусклой свечи к яркой.</p> <p>Рассмотрим инженера-программиста, готовящегося к выпуску новой функции. Сегодня они переключаются между трекером проекта для требований, вики для архитектурных решений, репозиторием кода для последних изменений и чатами для открытых вопросов от продуктовой команды. Только на переключения может уходить несколько часов, и это повторяется в каждом спринте.</p> <p>Теперь представьте себе команду агентов, выполняющих эти задачи параллельно: сбор требований, выявление архитектурных конфликтов, обобщение последних изменений, сканирование на наличие уязвимостей и составление первоначального плана реализации. Инженер проверяет и сразу приступает к работе.</p> <p>Примените ту же логику к другим задачам:</p> <p>• Команда поддержки сокращает время решения проблем на 50%, потому что агенты собирают контекст и составляют ответы до того, как человек коснется заявки.</p> <p>• Юридическая команда проверяет контракт за минуты вместо дней, при этом агент-исследователь собирает прецеденты, агент по соблюдению нормативных требований выявляет пункты, касающиеся рисков, а агент по составлению документов предлагает правки, оставляя юристу возможность сосредоточиться на стратегии переговоров и принятии решений, требующих экспертных знаний.</p> <h3>Это не учебная практика</h3> <p>Этот сдвиг уже происходит. EY недавно <a href="https://www.ey.com/en_us/newsroom/2025/12/ai-driven-productivity-is-fueling-reinvestment-over-workforce-reductions">объявила</a>, что почти все опрошенные ею крупные организации сообщили о повышении производительности за счет ИИ, причем около половины заявили о значительном росте, и что эти достижения были реинвестированы в развитие, а не в сокращение штата. Этот импульс реален, но он также повышает ставки: самый большой риск в настоящее время при внедрении ИИ — это слишком медленный темп.</p> <p>ИИ-нативные компании уже выпускают продукты быстрее и без тех накладных расходов, которые присущи большинству корпоративных организаций. Для стартапов часть этого преимущества обусловлена ​​размером. Но значительная часть носит структурный характер: они по необходимости создают продукты с ИИ в их основе, а не как дополнительный слой. Им не пришлось ничего перестраивать, потому что ИИ был партнером с самого начала.</p> <p>Это означает, что операционная задержка, которая ставит многие крупные организации в невыгодное положение, становится на порядок хуже.</p> <p>Организации, которые вырвутся вперед, создадут базовую структуру, которая позволит агентам действовать быстро и безопасно. Это включает в себя четкое распределение ответственности за решения ИИ, общий контекст и масштабируемые механизмы защиты. Без этого внедрение раздробится на отдельные подразделения и вовлечет людей в эксперименты, отвлекающие от действительно важной работы.</p> <h3>Забудьте о том, что вы, как вам кажется, знаете о работе</h3> <p>Чтобы правильно ориентироваться в этом вопросе, нам нужно отказаться от многих предвзятых представлений о работе. Для корпоративных организаций это будет гораздо сложнее, учитывая темпы развития ИИ.</p> <p>Окно возможностей закрывается, но мы не можем просто двигаться быстрее; нам нужно двигаться по-другому. В условиях, когда цель становится все более важной, рассудительность и интуиция, которые делают нас всех людьми, никогда не были так ценны. Чтобы извлечь выгоду из нелинейных преимуществ, которые обещает ИИ, нам всем нужно будет понимать цель работы лучше, чем когда-либо прежде.</p> Поскольку агенты искусственного интеллекта берут на себя выполнение задач, человеческая роль становится ключевой. Ману … article https://www.itweek.ru/themes/detail.php?ID=235267 Wed, 29 Jul 2026 17:42:09 +0300 <p>SimpleOne (направление прикладных бизнес-систем корпорации ITG) выпустила обновление одноименной Low-code платформы версии 1.34.0. Новая функциональность позволяет закрыть такие задачи бизнеса, как сокращение времени реакции на критичные события, снижение риска недопонимания между подразделениями, а также безопасное проведение аудитов без угрозы несанкционированных изменений в системе.</p> <p>В версии 1.34.0 SimpleOne добавила в платформу поддержку нативных браузерных пуш-уведомлений. Теперь пользователь может получать оповещения о критичных событиях на разных устройствах и в поддерживаемых браузерах, без необходимости следить за почтой или мессенджерами. При этом доставка пуш-уведомлений изолирована от основной платформы: ее сбои или рост нагрузки не влияют на работу системы.</p> <p>Дополнительно была переработана Лента активности: вместо обычного текстового поля теперь работает визуальный редактор форматирования (WYSIWYG). Исполнители и бизнес-пользователи могут форматировать сообщения — добавлять полужирный и курсивный текст, списки, цитаты, гиперссылки и изображения прямо в карточке заявки. Ранее созданные текстовые сообщения платформа отображает без изменений, обратная совместимость сохранена. При этом форматирование доступно не только в ленте активности, администратор может преобразовать существующие колонки типа Text в тип WYSIWYG с сохранением данных — например, текст в описании задачи или пользовательском поле. Свойства колонки при этом не меняются, не нужно создавать новое поле и переносить значения вручную.</p> <p>Третье изменение касается администрирования: в систему добавлена роль «Аудитор». Она открывает доступ на чтение ко всем таблицам системы, в том же объеме, что у администратора, но без права изменений. Это позволяет проводить проверки и расследования, не нарушая принцип разделения обязанностей.</p> <p>«Мы последовательно закрываем те точки, где промедление и непрозрачность обходятся бизнесу дороже всего. В 1.34 это два прямых ответа: критичное событие доходит до исполнителя сразу, а не когда он откроет почту, а проверяющий получает доступ на чтение ко всем данным без права что-либо изменить — раньше ради этого приходилось выдавать избыточные права», — рассказал Илья Радченко, директор по платформенным продуктам SimpleOne, корпорация ITG.</p> <p>Новая версия платформы доступна текущим пользователям SimpleOne по запросу.</p> SimpleOne (направление прикладных бизнес-систем корпорации ITG) выпустила обновление одноименной Low-code платформы версии … message https://www.itweek.ru/themes/detail.php?ID=235266 Wed, 29 Jul 2026 17:40:11 +0300 <p>Российский ИТ-бренд Nerpa модернизировал линейку ленточных библиотек начального и среднего уровня NERPA TL. Оборудование предназначено для безопасного и экономичного хранения данных в компаниях любого масштаба: от малого и среднего бизнеса до крупных организаций. Все решения поставляются через официального дистрибьютора бренда — компанию OCS.</p> <p>Обновление затронуло базовые платформы для автозагрузчиков NERPA TL AL1U и NERPA TL AL2U и повысило надёжность, безопасность и эффективность решений. Встроенные возможности библиотек по управлению и обслуживанию были модернизированы, в том числе — расширена функциональность для защиты данных. Старшая модель линейки, ленточная библиотека NERPA TL AL707, теперь поддерживает работу с новым поколением картриджей LTO-10 с нативной ёмкостью хранения 40 ТБ.</p> <p>Обновлённая линейка ленточных библиотек поможет компаниям быстро разворачивать ресурсы для хранения большого объёма данных в условиях их постоянного роста. Также оборудование подойдёт для создания автономных и защищённых хранилищ данных, которые соответствуют требованиям регуляторов. Решения Nerpa имеют сертификаты совместимости с отечественным программным обеспечением для резервного копирования, включённым в реестр российского ПО: «Кибер Бэкап» и RuBackup.</p> <p>Ленточные библиотеки Nerpa представлены широкой линейкой оборудования: от доступных стримеров и автозагрузчиков до продуктов уровня предприятий. Все решения проходят обязательное тестирование, а их техническая поддержка осуществляется с учётом специфики и требований индустрии ленточных библиотек. В программу сервисной поддержки оборудования включён гибкий выбор регламентов обслуживания.</p> <p>«Спрос на автозагрузчики и ленточные библиотеки растёт у компаний из разных отраслей. В условиях роста цен на СХД этот сегмент становится всё более востребованным для долгосрочного хранения данных. Технологические возможности таких решений активно развиваются — обновление линеек даст нашим партнёрам доступ к современным и актуальным продуктам. Автозагрузчики и универсальные ленточные библиотеки Nerpa помогут компаниям безопасно управлять данными и соблюдать регуляторные требования к хранению информации. А расширенная экспертиза в поддержке проектов и программы сервисного обслуживания сделают работу с решениями ещё более комфортной для наших партнёров», — отметил Алексей Мосин, руководитель направления развития продукции Nerpa.</p> <p>Автозагрузчики и ленточные библиотеки Nerpa в наличии на складе OCS, также решения доступны под заказ. На оборудование распространяется стандартная гарантия сроком на один год с возможностью расширения до трёх лет.</p> Российский ИТ-бренд Nerpa модернизировал линейку ленточных библиотек начального и среднего уровня NERPA TL. Оборудование … message https://www.itweek.ru/themes/detail.php?ID=235265 Wed, 29 Jul 2026 17:36:14 +0300 <p>Рейтинговое агентство RAEX представило результаты ежегодного рэнкинга крупнейших ИТ-компаний России, зафиксировав первое за 12 лет сокращение роста отечественного ИТ-рынка.</p> <p>На фоне общеотраслевого замедления и жесткой оптимизации бюджетов заказчиков компания BSS продемонстрировала устойчивость, сохранив за собой <nobr>24-е</nobr> место в сводном Топ-25. Удержание высоких позиций во всех ключевых сегментах — от разработки ПО до дистрибуции — стало прямым следствием зрелости бизнес-модели BSS и высокого доверия со стороны корпоративных клиентов. Эти результаты подчеркивают стратегическую силу компании и ее серьезный потенциал для дальнейшего роста в любых макроэкономических условиях. </p> <p>Опубликованная детализация рэнкинга показывает, что минувший год стал для отрасли периодом жесткой бюджетной политики заказчиков, переноса сроков реализации крупных проектов и влияния накопленного технологического долга. Номинальный рост суммарных доходов участников рынка замедлился до исторических минимумов. На этом фоне сбалансированное присутствие BSS сразу в нескольких специализированных списках RAEX доказывает: в условиях неопределенности рынок делает выбор в пользу проверенных партнеров, способных гарантировать бесперебойный результат.</p> <p>Помимо общего рэнкинга, RAEX формирует специализированные списки по ключевым направлениям ИТ-деятельности. Компания BSS демонстрирует уверенное и стабильное присутствие во всех основных сегментах:</p> <ul> <li>в разработке программного обеспечения BSS стабильно удерживает <nobr>12-е</nobr> место (2025 год — <nobr>12-е</nobr> место), подтверждая статус одного из ведущих технологических архитекторов страны;</li> <li>в предоставлении ИТ-услуг BSS занимает <nobr>22-е</nobr> место (2025 год — <nobr>21-е</nobr> место), сохраняя высокие объемы экспертного сопровождения и успешного внедрения сложных инфраструктурных решений;</li> <li>в дистрибуции BSS уверенно удерживает <nobr>4-е</nobr> место (2025 год — <nobr>4-е</nobr> место), демонстрируя одну из лучших в классе эффективность логистических, интеграционных и партнерских процессов.</li> </ul> <p>На протяжении многих лет BSS входит в топ рейтингов от RAEX, что подтверждает эффективность и инвестиционную привлекательность компании на ИТ-рынке. Подчеркивает ее технологический суверенитет и серьезный потенциал для дальнейшего роста. Компания продолжает оставаться надежным стратегическим партнером для крупнейших предприятий финансового, телекоммуникационного и государственного секторов, предлагая проверенные решения для цифровой трансформации.</p> <p>Приоритетным направлением является создание и развитие инновационных решений для цифровизации бизнеса, включая платформы на базе речевых технологий, искусственного интеллекта и LLM. В центре — <nobr>CX-платформа</nobr> для системного управления клиентским опытом. Она охватывает ключевые бизнес-задачи: от автоматизации сервиса до проактивного удержания, поддержки продаж и развития команд. Это даёт возможность работать на опережение — предвидеть желания клиентов, предотвращать отток, повышать конверсию и масштабировать успешные практики.</p> Рейтинговое агентство RAEX представило результаты ежегодного рэнкинга крупнейших ИТ-компаний России, зафиксировав первое … message https://www.itweek.ru/themes/detail.php?ID=235262 Wed, 29 Jul 2026 09:26:30 +0300 <p><em>По мере развития искусственного интеллекта меняется и подход организаций к обеспечению безопасности корпоративных данных, пишет на портале </em><em>Information</em> <em>Age</em> <em>Стюарт Ханвик, технический директор Dell Technologies по платформам и решениям для хранения данных.</em></p> <p>ИИ оказывает на корпоративные данные давление нового типа. В тот самый момент, когда организации пытаются извлечь больше пользы из своих данных, они также концентрируют все больше этих данных в общих хранилищах, базах знаний и конвейерах ИИ.</p> <p>По мере перехода ИИ от экспериментов к производству, наборы данных, которые ранее были разделены по бизнес-функциям, уровню конфиденциальности или операционному использованию, все чаще объединяются для обучения моделей и поддержки принятия решений в режиме реального времени.</p> <p>Этот сдвиг меняет подход организаций к своей инфраструктуре данных. То, что когда-то было в основном платформой для хранения и восстановления информации, все чаще становится точкой консолидации, управления и доступа к данным ИИ, что влечет за собой новые вопросы отказоустойчивости, соответствия нормативным требованиям и безопасности.</p> <p>Большая часть дискуссий об инфраструктуре ИИ по-прежнему сосредоточена на моделях и вычислениях. Это важные соображения, но они могут заслонить более фундаментальный вопрос: насколько хорошо подготовлена основа данных, которая их поддерживает?</p> <p>Вот пять способов, которыми ИИ меняет безопасность корпоративных хранилищ.</p> <h3>1. ИИ объединяет данные новыми способами</h3> <p>Обучение базовой модели или ее тонкая настройка обычно означает объединение интеллектуальной собственности, регулируемых данных клиентов, внутренних знаний и контента, такого как текст, документы, фотографии, аудио и видео, в единое хранилище, открытое для запросов. Это именно тот тип концентрированной цели, который позволяет злоумышленникам быстро повышать градус, как только они получат к ней доступ. Контроль этого риска начинается еще до того, как данные будут сохранены. Сегментация обучающих данных и анонимизация или удаление конфиденциальных входных данных, где это возможно, ограничивают уязвимость, создаваемую таким агрегированием, а блокировка наборов данных с помощью неизменяемых версий снижает риск скрытого вмешательства.</p> <h3>2. Генерация с расширенными возможностями извлечения (RAG) делает хранилище активным участником, а не пассивным архивом</h3> <p>Подключите большую языковую модель к корпоративной базе знаний, и хранилище перестанет быть чем-то, к чему пользователи получают прямой доступ. Это становится частью каждого взаимодействия системы ИИ. Неправильно настроенный контроль доступа к индексу RAG может раскрыть конфиденциальную информацию через совершенно корректный запрос, что делает аудит крайне важным. Регистрация того, к каким данным осуществляется доступ и какие данные отображаются, поддерживает расследование и соблюдение нормативных требований, но, что более важно, предотвращает структурные уязвимости, которые легко пропустить, пока они не будут раскрыты.</p> <h3>3. Рабочие нагрузки инференса создают проблему скорости, которую ручной контроль не может решить</h3> <p>Производственные системы, такие как агенты ИИ или системы обнаружения мошенничества, зависят от непрерывного доступа к данным с низкой задержкой. Конвейеры, обеспечивающие это, работают с такой скоростью, что ручной мониторинг становится нецелесообразным, подобно тому, как горизонтальное перемещение по сети может оставаться незамеченным в течение нескольких дней, если не установлены соответствующие средства контроля. Защита этих систем требует обеспечения безопасности данных при передаче, применения контроля доступа во время выполнения и обеспечения достаточной устойчивости систем хранения данных, чтобы инцидент безопасности не перерос в операционный инцидент.</p> <h3>4. Отсутствие видимости — это пробел, который не устранен в большинстве организаций</h3> <p>Исследование Dell Technologies «Innovation Catalyst» показало, что 82% лиц, принимающих решения в сфере ИТ, признают данные ключевым фактором интеграции ИИ и считают, что их необходимо защищать соответствующим образом. Однако только каждый третий утверждает, что может преобразовать эти данные в инсайты реального времени. Большая часть этого пробела связана с уровнем хранения данных, и от этого может зависеть, удастся ли быстро локализовать проблему или она останется нерешенной на несколько дней. Без устранения этого пробела системы управления и политики контроля работают на основе неполной информации, как бы хорошо они ни были разработаны на бумаге.</p> <h3>5. Восстановление необходимо перестраивать с учетом зависимостей ИИ</h3> <p>Организации должны задать себе вопрос: могут ли их системы ИИ быстро возобновить доверенную работу? Это означает восстановление правильных наборов данных и версий моделей, перестройку конвейеров обработки данных и тестирование восстановления на реальных рабочих нагрузках, а не на стандартных резервных копиях системы. Технически успешное восстановление, в результате которого возвращается не та версия модели или нарушается работа конвейера, все равно является сбоем во всех важных для бизнеса аспектах.</p> <h3>Практические последствия</h3> <p>Хранение данных стало основным уровнем контроля рисков, связанных с ИИ. Основы хорошей безопасности, видимости, неизменяемости, сегментации, концепции нулевого доверия и устойчивого восстановления не изменились. Изменилось лишь то, где и как именно их необходимо применять. Например, британские регуляторы все чаще ожидают именно такой специфичности: решение правительства добавить «сбой цифровой устойчивости» в Национальный реестр рисков в июле 2026 г. свидетельствует о том, насколько серьезно к этому относятся на национальном уровне.</p> <p>Организации, которые понимают потоки данных ИИ, обеспечивают надлежащую защиту хранилищ и согласовывают механизмы контроля с рабочими нагрузками ИИ, будут лучше подготовлены к снижению рисков, выполнению требований регулирующих органов и укреплению обоснованного доверия к своим системам ИИ по мере расширения их внедрения.</p> По мере развития искусственного интеллекта меняется и подход организаций к обеспечению безопасности корпоративных … article https://www.itweek.ru/themes/detail.php?ID=235260 Wed, 29 Jul 2026 09:11:43 +0300 <p>Искусственный интеллект становится новой инфраструктурой высшего образования. Нейросети уже меняют подходы к обучению, подготовке учебных материалов, научной работе и взаимодействию университетов с работодателями. По данным исследования ИТМО, «Яндекс Образования» и Yandex Cloud, 66% преподавателей и исследователей российских вузов используют генеративный искусственный интеллект в работе, а 84% отмечают, что технологии помогают ускорять исследовательские задачи. При этом, по данным исследования Высшей школы экономики, использование генеративного ИИ среди студентов уже стало массовой практикой: значительная часть обучающихся применяет такие инструменты для подготовки учебных материалов, поиска информации и решения практических задач.</p> <p>Нейросети перестали быть экспериментом — они становятся частью образовательного процесса. Вместе с новыми возможностями появляется и новый риск — неравный доступ университетов к современным технологиям.</p> <p>Этот риск можно обозначить как «ИИ-феодализм». Речь идет о ситуации, когда доступ к мощным языковым моделям, качественным данным, вычислительным ресурсам и экспертным компетенциям распределяется крайне неравномерно. В результате преимущества получают университеты, которые уже обладают развитой цифровой инфраструктурой и возможностями для внедрения ИИ, тогда как остальные рискуют оказаться в роли догоняющих.</p> <p>Проблема заключается не только в финансировании. Технологический разрыв складывается из нескольких факторов: доступа к современным моделям искусственного интеллекта, наличия специалистов, способных внедрять новые решения, готовности преподавателей использовать инструменты ИИ и способности университетов быстро обновлять образовательные программы.</p> <p>Сегодня этот вопрос выходит далеко за пределы образовательной сферы. По оценкам экспертов, к 2030 году большинство профессий будут в той или иной степени связаны с использованием технологий искусственного интеллекта. По данным исследования «Future of Jobs» Всемирного экономического форума, около 40% ключевых навыков работников изменятся в ближайшие годы из-за развития технологий, а способность эффективно использовать ИИ станет одной из базовых компетенций на рынке труда.</p> <p>Для России этот вопрос напрямую связан с подготовкой кадров для технологического развития. Согласно целям национального проекта «Экономика данных», стране необходимо обеспечить массовое внедрение цифровых технологий и подготовку специалистов, способных работать с ними. Однако без равномерного развития ИИ-компетенций в университетах существует риск, что новые возможности будут концентрироваться только в ведущих образовательных центрах.</p> <p>Уже сегодня можно наблюдать разные скорости адаптации вузов. Одни университеты создают собственные лаборатории, внедряют ИИ-ассистентов, развивают программы подготовки специалистов в области искусственного интеллекта и выстраивают партнерства с технологическими компаниями. Другие находятся только на этапе формирования базовой цифровой инфраструктуры. В перспективе этот разрыв может стать одним из факторов, определяющих качество подготовки выпускников.</p> <p>Особенность текущего этапа заключается в том, что искусственный интеллект меняет не только инструменты обучения, но и саму модель высшего образования. Университет больше не является единственным источником знаний: студент получает доступ к огромному объему информации через цифровые системы. Поэтому ценность преподавателя постепенно смещается от передачи информации к наставничеству, развитию критического мышления и формированию способности работать со знаниями.</p> <p>Одновременно меняется система оценки компетенций. Письменные экзамены, эссе, курсовые работы и другие традиционные форматы контроля все чаще не позволяют объективно оценить уровень подготовки студента, поскольку значительную часть таких задач способны выполнять генеративные модели. Университетам предстоит переходить от оценки конечного результата к оценке способности человека анализировать информацию, объяснять ход рассуждений, принимать решения и эффективно использовать искусственный интеллект как профессиональный инструмент.</p> <p>Эти изменения напрямую связаны с рынком труда. Работодатели все чаще ожидают от выпускников не только фундаментальных знаний, но и способности повышать собственную эффективность с помощью ИИ. Владение такими инструментами постепенно превращается в базовую компетенцию — аналогично тому, как ранее обязательными стали навыки работы с компьютером и цифровыми сервисами.</p> <p>При этом без системной политики технологический разрыв между университетами может только увеличиваться. Для его сокращения необходим комплекс мер: развитие региональных программ внедрения ИИ, поддержка вузов в создании цифровой инфраструктуры, подготовка преподавателей и формирование ИИ-грамотности на всех уровнях образования — от школы до университета.</p> <p>Одновременно важно избежать другой крайности — избыточного регулирования. Искусственный интеллект развивается быстрее, чем традиционные механизмы управления успевают адаптироваться к изменениям. Ограничительные меры без понимания природы технологии могут не снизить риски, а наоборот — замедлить внедрение решений, которые становятся частью образовательной и профессиональной среды.</p> <p>В ближайшие годы конкурентоспособность университетов будет определяться не только качеством преподавания и научными достижениями, но и способностью эффективно использовать искусственный интеллект. Главный вызов заключается не в том, чтобы внедрить отдельные цифровые инструменты, а в том, чтобы обеспечить равный доступ к возможностям новой технологической эпохи. В противном случае образовательное неравенство может перерасти в кадровое — и стать фактором, влияющим на конкурентоспособность экономики.</p> <p>#IMAGE_235261#</p> Искусственный интеллект становится новой инфраструктурой высшего образования. Нейросети уже меняют подходы к обучению … article Эдуард Хисюков, руководитель агентства “ЭдуТрек”, старший преподаватель кафедры инженерной кибернетики НИТУ МИСИС https://www.itweek.ru/themes/detail.php?ID=235259 Tue, 28 Jul 2026 15:09:26 +0300 <p>Компания PIX Robotics, разработчик программных решений для повышения эффективности и цифровой трансформации бизнеса, объявила о выходе на рынок нового продукта PIX FlexForms — отечественной CPM-платформы, объединяющей в единую цифровую экосистему функционал совместного корпоративного планирования с возможностями встроенной бизнес-аналитики. Решение закрывает широкий диапазон сценариев управления корпоративной эффективностью: от управляемого сбора, проверки, согласования и консолидации многомерных данных, до поддержки автоматизированных процессов совместного планирования, бюджетирования и бизнес-моделирования в режиме «одного окна». Внедрение платформы позволяет компаниям отказаться от разрозненных Excel-файлов и ручных коммуникаций в пользу централизованной и прозрачной работы с данными непосредственно в PIX FlexForms.</p> <p>«Запрос на отказ от Excel в критически важных процессах бизнес-планирования и моделирования звучит сегодня от большинства наших клиентов, и PIX FlexForms дает решение — поддержка корпоративных CPM-сценариев в едином управляемом контуре, — отметил Алексей Шумаков, владелец продукта PIX FlexForms в PIX Robotics. — Для бизнеса это означает меньше ручной работы, унифицированные расчеты, прозрачное согласование и получение готовых к анализу данных без лишних промежуточных шагов и потери качества. В ближайших планах — усиление расчетного движка, глубокая кастомизация интерфейсов под роли пользователей и внедрение элементов генеративного ИИ для интеллектуальной помощи в работе с данными».</p> <p>До выхода в открытый релиз FlexForms проходит пилотное внедрение у одного из ключевых заказчиков продуктов экосистемы PIX — Светогорского ЦБК. По предварительным итогам пилота FlexForms подтвердил свою способность выстраивать структурированный сбор данных, выполнять высокопроизводительные расчёты целевых показателей, упрощать процесс согласования и существенно сокращать время подготовки консолидированной отчётности.</p> <p>«Начало работы с PIX FlexForms — это качественно новый шаг в развитии нашей аналитики данных: мы получаем возможность оценивать показатели не только в состоянии „как есть“, но и моделировать сценарии, строить динамические прогнозы и выбирать из них оптимальные. В качестве пилотного проекта совместно с PIX Robotics мы находимся в процессе реализации сложного многокомпонентного MRP-продукта на базе FlexForms для оптимизации планирования закупок химикатов и упаковки, при этом уже видим большой потенциал решения в автоматизации финансового планирования и анализе производственных и коммерческих данных. Ключевое преимущество для пользователей — в одном интерфейсе они смогут работать одновременно с инструментами лучшей российской BI-системы и полноценного CPM-продукта», — прокомментировал Максим Буянов, руководитель департамента цифровизации Светогорского ЦБК.</p> <p>Запуск PIX FlexForms позволяет клиентам PIX сформировать бесшовный дата-контур, объединяющий бизнес-аналитику, управление данными и корпоративной эффективностью, обеспечивая единую точку входа для совместного планирования, моделирования, анализа и принятия управленческих решений. </p> Компания PIX Robotics, разработчик программных решений для повышения эффективности и цифровой трансформации бизнеса … message https://www.itweek.ru/themes/detail.php?ID=235258 Tue, 28 Jul 2026 15:08:10 +0300 <p>Главным направлением релиза стало развитие возможностей RooX UIDM для выполнения требований российских регуляторов в области защиты информации. Версия 25.2 расширяет механизмы аутентификации, повышает безопасность платформы и упрощает эксплуатацию и интеграцию с корпоративной ИТ-инфраструктурой.</p> <p>В части поддержки мер идентификации и аутентификации (ИАФ) в рамках релиза расширена поддержка современных методов многофакторной аутентификации, включая WebAuthn, аппаратные токены и аутентификацию по клиентскому сертификату (mTLS). Кроме того, реализована интеграция с ЕСИА через типовые решения для сценариев OAuth 2.0.</p> <p>По мерам регистрации событий безопасности (РСБ) расширен состав данных, фиксируемых в событиях аудита, а также возможности их поиска и анализа. Это позволит специалистам по информационной безопасности быстрее выявлять подозрительную активность и проводить расследование инцидентов.</p> <p>Наиболее существенные изменения коснулись функций, поддерживающих реализацию мер защиты управления доступом (УПД). В RooX UIDM появился модуль управления пользователями, ролями и доступами, позволяющий автоматизировать жизненный цикл учетных записей и централизованно управлять правами доступа. Он дает возможность управлять доступами, не опираясь на корпоративные каталоги пользователей, благодаря чему может использоваться и как хранилище пользователей, и как <nobr>IDM-блок.</nobr> Кроме того, модуль поддерживает интеграцию с внешними системами по открытому протоколу SCIM. </p> <p>«Для многих организаций соответствие требованиям ФСТЭК — обязательное условие выбора платформы управления доступом. Поэтому в версии 25.2 мы сосредоточились на реализации необходимых механизмов защиты и запустили процесс сертификации RooX UIDM по четвертому уровню доверия. При этом все изменения одновременно делают платформу безопаснее и удобнее в эксплуатации», — отметил генеральный директор RooX Алексей Хмельницкий.</p> <p>Помимо реализации мер защиты, в версии RooX UIDM 25.2 улучшена работа с внешними каталогами Active Directory и FreeIPA, повышена надежность синхронизации пользователей, расширены возможности настройки пользовательских интерфейсов аутентификации. </p> <p>Компоненты нового релиза платформы поставляются в вариантах, совместимых с сертифицированными средами развертывания.</p> <p>На базе версии RooX UIDM 25.2 выпускаются решения для управления доступом сотрудников (Workforce IAM) и внешних пользователей (CIAM).</p> Главным направлением релиза стало развитие возможностей RooX UIDM для выполнения требований российских регуляторов … message https://www.itweek.ru/themes/detail.php?ID=235257 Tue, 28 Jul 2026 10:52:23 +0300 <br/> <p><em>Данные исследования РУССОФТ показывают, что к концу 2026 года использовать генеративный ИИ в разработке ПО будет не менее 93% российских софтверных компаний. Почти три четверти его уже внедрили в производственный процесс. Однако явных признаков экономической эффективности применения ИИ в целом пока еще не выявлено.</em></p> <p>Использование генеративного искусственного интеллекта (ИИ) в разработке ПО стало предметом изучения в рамках ежегодного Исследования РУССОФТ с 2024 года. Опрос софтверных компаний позволял определять долю компаний, у которых ИИ уже применяется, и выявлять масштабы планируемого внедрения. Кроме того, респонденты оценивали фактический эффект использования ИИ в разработке в прошедшем и текущем году. Фактические показатели по итогам 2024 года оказались намного выше прогнозируемых, что бывает крайне редко (как правило, часть опрошенных компаний поставленных целей не достигает). То же самое повторилось при подведении итогов 2025 года.</p> <p>Опрос, проведенный весной 2026 года, показал, что проигнорировали просьбу сообщить об использовании генеративного ИИ в разработке ПО только 13,3% респондентов. Ответы остальных распределились следующим образом: </p> <p>«Использовали в 2025 г. и будем дальше использовать» — 72,85%</p> <p>«Не использовали, но планируем использовать в 2026 г.» — 20,35%</p> <p>«Не использовали в 2025 г. и не планируем использовать в 2026 г.» — только 6,8%</p> <p><strong>Применение российскими софтверными компаниями генеративного ИИ в разработке ПО в <nobr>2022-2026</nobr> годах</strong> </p> <table> <tbody> <tr> <td> <br/> </td> <td> <p>2022 г.</p> </td> <td> <p>2023 г.</p> </td> <td> <p>2024 г.</p> </td> <td> <p>2025 г.</p> </td> <td> <p>2026 г. (прогноз)</p> </td> </tr> <tr> <td> <p>Доля софтверных компаний, использующих генеративный ИИ</p> </td> <td> <p>12,7%</p> </td> <td> <p>24,9%</p> </td> <td> <p>45,4%</p> <p>(32,6%)*</p> </td> <td> <p>72,4%</p> <p>(55,6%)*</p> </td> <td> <p>92,8%</p> </td> </tr> <tr> <td> <p>Выполненный ИИ объем работ, измеряемый в тысячах человеко-лет</p> </td> <td> <p>0,8</p> </td> <td> <p>1,7</p> </td> <td> <p>19,5</p> <p>(2,8)*</p> </td> <td> <p>41</p> <p>(34)*</p> </td> <td> <p>63</p> </td> </tr> </tbody> </table> <p>* в скобках прогнозная величина, основанная на ожиданиях компаний, опрошенных весной того же года</p> <h3>Эффективно ли использование ИИ в разработке?</h3> <p>Согласно данным опроса РУССОФТ, эффект от внедрения генеративного ИИ в разработку также значительно вырос. Эффект оценили 143 из 300 опрошенных компаний (48%). Если экстраполировать полученные расчеты на всю софтверную индустрию, то численность сотрудников, которая бы потребовалась дополнительно для решения тех же задач, но без использования генеративного ИИ, составила по итогам 2025 года 41 тыс. чел. Этот показатель вырос за год более чем в 2 раза. Для софтверной индустрии, в которой работает примерно 265 тыс. профильных технических специалистов, а кадровый дефицит так и не удается перебороть, это значительная величина.</p> <p>Такая высокая эффективность должна была бы проявляться и в других показателях — прежде всего, в финансовых. Например, можно было бы предположить либо больший произведенный объем ПО при том же количестве сотрудников, либо неизменный объем разработанного ПО, но произведенный меньшими силами разработчиков. Однако позитивных изменений, которые можно было объяснить внедрением генеративного ИИ в процесс разработки ПО, ни по опрошенным компаниям, ни во всей софтверной индустрии не выявлено.</p> <p>Совокупный оборот в 2025 году вырос как раз больше у компаний, которые не использовали ИИ — на 14,1%, в то время как у тех, кто применял ИИ в разработке ПО, увеличение оборота значительно меньше — 7,5%. Выручка на одного сотрудника у компаний, которые использовали генеративный ИИ в 2025 году, также ниже, чем у компаний, давших отрицательный ответ на соответствующий вопрос — ₽5,13 млн против ₽5,19 млн.</p> <p>Дополнительное деление компаний по глубине использования ИИ с выделением тех компаний, которые чаще используют все его имеющиеся возможности, также не позволило сделать вывод о том, что генеративный ИИ в разработке обеспечил какие-то финансовые выгоды. Возможно, требуется намного больше данных, чтобы выявить доказательства экономической эффективности от использования генеративного ИИ в разработке ПО. Однако уже имеющейся информации должно было бы хватить, чтобы констатировать явную и значительную эффективность, если бы это было так. </p> <p>Пока можно констатировать, что экономической эффективности применения ИИ пока не выявлено или же ее чрезмерно трудно определить.</p> <p>Почему же опрошенные компании так высоко оценивают объем работ, который выполняется благодаря генеративному ИИ? По-видимому, представленные экспертные оценки отражают видимый и ощутимый эффект от того, как этот ИИ выполняет определенные задачи при программировании. При этом не учитывалось, что затем появляется необходимость верифицировать результаты его применения, исправлять ошибки, осуществлять дополнительную проверку, предотвращать другие возможные негативные последствия.</p> <p>Можно предположить, что респонденты оценивали эффект, полученный в процессе разработки ПО, а не экономический эффект для всего бизнес-процесса в целом. Можно также предположить завышение оценки выполненного объема работ с использованием ИИ при отсутствии качественных методик измерения эффективности. Не исключено, что благодаря использованию ИИ у разработчиков появилось больше свободного времени, а этот ресурс пока не удавалось использовать в интересах бизнеса из-за непростой ситуации в экономике.</p> <p>Результаты некоторых исследований позволяют считать обоснованными сделанные выше предположения о наличии рисков возникновения негативных последствий применения ИИ в разработке ПО в текущей ситуации. </p> <p>Например, согласно данным американской компании Apiiro, специализирующейся на разработке ПО в сфере кибербезопасности, применение ИИ-ассистентов помогает программистам писать код быстрее в три-четыре раза, но также ведет к закладыванию в него трудноустранимых проблем безопасности, которые в сгенерированном коде встречаются чаще, чем написанном разработчиками вручную.</p> <p>Результаты исследования, которое провела в ноябре 2025 года российская компания IT_ONE совместно с Фондом «Сколково» и «Сколтехом», показали, что несмотря на активное использование генеративного ИИ в разработке ПО, только четверть крупных компаний используют специальные метрики для измерения реального эффекта от внедрения ИИ.</p> <p>В то же время, можно предположить, что эффект от применения ИИ в разработке ПО представляется респондентам в перспективе настолько значимым, что устранение вызванным им проблем расценивается в качестве вторичного и временного фактора, который может быть нивелирован в течение достаточно короткого времени.</p> <h3>ИИ как замена джунов</h3> <p>К тому же опрос 2026 года показал, что доля компаний, внедривших ИИ в разработку ПО хотя и велика, но глубина использования ИИ в среднем еще невысока. Если говорить обо всех возможных областях применения ИИ в разработке ПО, то подавляющее большинство компаний используют ИИ в разработке ПО частично, находятся в начальной стадии его использования или вовсе еще не используют в ряде потенциальных областей применения. Соответственно, если говорить обо всей индустрии, то в настоящее время еще продолжается период тестирования, внедрения и отладки.</p> <p><strong>Области применения генеративного ИИ в разработке ПО с распределением по области применения (% опрошенных компаний)</strong> </p> <table> <tbody> <tr> <td> <br/> </td> <td> <p>Используем <br/> все возможности </p> </td> <td> <p>Используем частично</p> </td> <td> <p>В начальной стадии, пробуем</p> </td> <td> <p>Не используется</p> </td> </tr> <tr> <td> <p>Поиск причин возникающих ошибок или способов разрешения затруднений</p> </td> <td> <p>26,6%</p> </td> <td> <p>30,7%</p> </td> <td> <p>30,7%</p> </td> <td> <p>12,1%</p> </td> </tr> <tr> <td> <p>Документирование и анализ</p> </td> <td> <p>25,7%</p> </td> <td> <p>36,9%</p> </td> <td> <p>22,9%</p> </td> <td> <p>14,5%</p> </td> </tr> <tr> <td> <p>Помощь при самостоятельном написании кода (co-pilot)</p> </td> <td> <p>23,2%</p> </td> <td> <p>41,4%</p> </td> <td> <p>23,2%</p> </td> <td> <p>12,3%</p> </td> </tr> <tr> <td> <p>Тестирование и отладка (генерация тестов, автоматизация)</p> </td> <td> <p>17,7%</p> </td> <td> <p>36,3%</p> </td> <td> <p>29,3%</p> </td> <td> <p>16,7%</p> </td> </tr> <tr> <td> <p>Генерация кода без инженера</p> </td> <td> <p>14,4%</p> </td> <td> <p>29,7%</p> </td> <td> <p>28,7%</p> </td> <td> <p>27,2%</p> </td> </tr> <tr> <td> <p>Рефакторинг и оптимизация</p> </td> <td> <p>11,2%</p> </td> <td> <p>34,5%</p> </td> <td> <p>31,1%</p> </td> <td> <p>23,3%</p> </td> </tr> <tr> <td> <p>Проектирование, анализ <br/> и управление процессами </p> </td> <td> <p>10,5%</p> </td> <td> <p>25,8%</p> </td> <td> <p>39,2%</p> </td> <td> <p>24,4%</p> </td> </tr> <tr> <td> <p>Миграция и модернизация</p> </td> <td> <p>8,5%</p> </td> <td> <p>23,6%</p> </td> <td> <p>30,2%</p> </td> <td> <p>37,7%</p> </td> </tr> </tbody> </table> <p>Больше всего компании используют все возможности ИИ в таких областях его применения как «Поиск причин возникающих ошибок или способов разрешения затруднений» и «Документирование и анализ» (примерно четверть опрошенных компаний). Большинство использует ИИ частично или только начинает использовать (более 50% в каждой из областей применения). Таким образом применение генеративного ИИ в разработке ПО широкое, но в среднем еще не очень активное.</p> <p>Самое интенсивное использование ИИ с почти одинаковым показателем интенсивности имеется в следующих областях: «Помощь при самостоятельном написании кода», «Документирование и анализ», «Поиск причин возникающих ошибок».</p> <p>Если сравнивать средний показатель интенсивности применения ИИ для разных моделей бизнеса, то значительное преимущество имеют компании, специализирующиеся на предоставлении услуг по разработке ПО и других ИТ-услуг. Разработчики программных продуктов менее нацелены на стоимость человеко-часа. Для них важнее налаживание продаж и маркетинг. При этом стоит отметить, что сервисная модель в России находится в кризисе, поэтому она же требует более глубокого использования ИИ в разработке ПО для повышения ее экономической эффективности. Поэтому можно предположить, что невысокие темпы роста выручки при наличии глубокого использования ИИ в разработке связаны с общими проблемами предприятий, специализирующихся на заказной разработке, а не с самим фактором применения ИИ.</p> <p>Сравнение по обороту по итогам 2025 г. показывает, что самая высокая интенсивность применения ИИ в разработке ПО отмечается у компаний с оборотом более ₽1,5 млрд. Только в области «Документирование и анализ» есть совсем небольшое преимущество у компаний с оборотом от ₽375 млн до ₽1,5 млрд.</p> <h3>Основная угроза связана с безопасностью кода</h3> <p>Почти половина опрошенных компаний оценила как не актуальные следующие угрозы, связанные с использованием генеративного ИИ в разработке ПО: «Преднамеренная модификация кода зарубежными платформами», «Непреднамеренное использование материалов, защищенных авторским правом», «Социальные проблемы». К потенциальным угрозам их все же относит от 30% до почти 40% ответивших на этот вопрос респондентов.</p> <p>Самые большие риски применения ИИ респонденты связывают с «Проблемами безопасности кода». Для почти 22% эти проблемы считаются серьезными или даже критически значимыми, что делает невозможным использование не «доверенного» ИИ в разработке ПО для объектов КИИ. Не актуальна эта проблема только для 14% респондентов.</p> <p><strong>Отношение к возможным негативным последствиям, связанным с использованием генеративного ИИ в разработке ПО (% всех опрошенных компаний</strong>) </p> <table> <tbody> <tr> <td> <br/> </td> <td> <p>Не актуально</p> </td> <td> <p>Потенциальная угроза</p> </td> <td> <p>Сталкиваемся, но управляем</p> </td> <td> <p>Серьёзная проблема</p> </td> <td> <p>Критическая проблема, блокирует использование ИИ</p> </td> </tr> <tr> <td> <p>Риск преднамеренной модификации кода зарубежными платформами</p> </td> <td> <p>49,3%</p> </td> <td> <p>37,6%</p> </td> <td> <p>4,4%</p> </td> <td> <p>7,3%</p> </td> <td> <p>1,5%</p> </td> </tr> <tr> <td> <p>Непреднамеренное использование Вашей компанией материалов, защищенных авторским правом</p> </td> <td> <p>48,5%</p> </td> <td> <p>38,2%</p> </td> <td> <p>6,4%</p> </td> <td> <p>4,4%</p> </td> <td> <p>2,5%</p> </td> </tr> <tr> <td> <p>Социальные проблемы <br/> из-за невостребованности выпускников вузов, которые прежде легко находили работу </p> </td> <td> <p>47,1%</p> </td> <td> <p>29,6%</p> </td> <td> <p>7,3%</p> </td> <td> <p>14,1%</p> </td> <td> <p>1,9%</p> </td> </tr> <tr> <td> <p>Необходимость сложной <br/> и слишком быстрой пере-стройки всей системы обучения новых специа-листов и взаимодействия <br/> с учебными заведениями </p> </td> <td> <p>43,8%</p> </td> <td> <p>26,0%</p> </td> <td> <p>17,8%</p> </td> <td> <p>10,1%</p> </td> <td> <p>2,4%</p> </td> </tr> <tr> <td> <p>Потеря контроля над процессом создания ПО</p> </td> <td> <p>41,1%</p> </td> <td> <p>33,0%</p> </td> <td> <p>16,7%</p> </td> <td> <p>6,7%</p> </td> <td> <p>2,4%</p> </td> </tr> <tr> <td> <p>Кража Вашей интеллектуальной собственности</p> </td> <td> <p>36,1%</p> </td> <td> <p>48,8%</p> </td> <td> <p>2,9%</p> </td> <td> <p>9,8%</p> </td> <td> <p>2,4%</p> </td> </tr> <tr> <td> <p>Организационные <br/> и человеческие факторы, связанные с изменением поведения разработчиков </p> </td> <td> <p>28,7%</p> </td> <td> <p>27,3%</p> </td> <td> <p>29,6%</p> </td> <td> <p>13,9%</p> </td> <td> <p>0,5%</p> </td> </tr> <tr> <td> <p>Ошибки конфигурации <br/> и развёртывания <br/> (ИИ не учитывает отраслевую специфику) </p> </td> <td> <p>25,1%</p> </td> <td> <p>32,0%</p> </td> <td> <p>30,6%</p> </td> <td> <p>10,0%</p> </td> <td> <p>2,3%</p> </td> </tr> <tr> <td> <p>Потраченное время на неудовлетворительный результат</p> </td> <td> <p>23,6%</p> </td> <td> <p>28,7%</p> </td> <td> <p>38,0%</p> </td> <td> <p>7,4%</p> </td> <td> <p>2,3%</p> </td> </tr> <tr> <td> <p>Проблемы <br/> безопасности кода </p> </td> <td> <p>14,8%</p> </td> <td> <p>38,4%</p> </td> <td> <p>25,0%</p> </td> <td> <p>15,3%</p> </td> <td> <p>6,5%</p> </td> </tr> </tbody> </table> <p>Исходя из результатов опроса, меньше всего опрошенные компании боятся нарушить чьи-то авторские права и подвергнуться риску модификации кода зарубежными ИИ-платформами при использовании их ИИ-решений в своей разработке ПО. При этом парадоксально проблемы обеспечения безопасности кода при использовании ИИ в разработке ПО в целом оцениваются респондентами как максимальная угроза. Можно предположить, что такие противоположные мнения высказываются респондентами, работающими или не работающими с КИИ.</p> Данные исследования РУССОФТ показывают, что к концу 2026 года использовать генеративный ИИ в разработке ПО … message https://www.itweek.ru/themes/detail.php?ID=235256 Tue, 28 Jul 2026 09:08:00 +0300 <p><em>Инструменты для кодирования с помощью искусственного интеллекта стали общедоступными. Сегодня для </em><em>CIO</em> <em>важна не только скорость разработки, но и то, как формируются команды, как оценивается работа и кто обучает следующее поколение инженеров, считают опрошенные порталом </em><em>InformationWeek</em> <em>эксперты.</em></p> <p>Согласно <a href="https://survey.stackoverflow.co/2025">опросу</a> Stack Overflow, в котором приняли участие более 49 тыс. разработчиков, около 84% респондентов сейчас используют или планируют использовать инструменты ИИ. В то же время, согласно исследованию DX Research, проведенному в 2026 г., рост производительности стабилизировался на уровне около 10%, даже несмотря на то, что 93% из 121 тыс. опрошенных разработчиков стремятся использовать ИИ.</p> <p>Эти цифры должны обеспокоить любого CIO, который одобрил внедрение ИИ-кодирования, ожидая резкого повышения производительности.</p> <p>Цифры производительности рассказывают лишь часть истории. Они являются симптомом более глубокого сдвига: ИИ меняет не только скорость разработки ПО. Он меняет то, чем занимаются разработчики, как структурируются команды и — что наиболее важно — как следующее поколение инженеров осваивает ремесло.</p> <p>Кай Чуанг, CIO компании Circles, занимающейся сервисами для рабочих мест, наблюдает это воочию, поскольку работа его разработчиков смещается от непосредственного кодирования к проектированию и системной архитектуре. Они тратят меньше времени «на буквальное программирование» и больше времени на определение того, что нужно построить, и тестирование работоспособности. Темпы изменений впечатляют. По словам Чуанга, как только разработчики начали доверять результатам, «переход к почти полной ИИ-генерации кода произошел быстро сам собой», без какого-либо директивного указания сверху.</p> <p>Дефицитным навыком теперь является не написание кода. «Речь идет о знании того, что нужно построить, как это должно быть спроектировано, безопасно ли это и действительно ли это способствует достижению бизнес-результатов», — отмечает Эрик Браун, старший партнер консалтинговой фирмы West Monroe.</p> <p>Вместо того чтобы просто писать больше кода, «компании, которые все сделают правильно, перестроят жизненный цикл разработки ПО вокруг ИИ. Те, кто просто предоставит разработчикам инструменты, получат больше активности, но не обязательно лучшие результаты», — говорит он.</p> <h3>Разработчики становятся дизайнерами и рецензентами</h3> <p>Новое разделение труда уже стало нормой в UiPath, компании, занимающейся разработкой ПО для автоматизации предприятий, где «значительная часть кода, развернутого в производственной среде, уже написана агентами-кодерами», — рассказывает главный технический и продуктовый директор UiPath Паркси Мальпани.</p> <p>«Разработчики трансформируются из писателей кода в рецензентов и системных дизайнеров. Они определяют намерения, проверяют результаты и выпускают больше кода быстрее, вместо того чтобы писать каждую строку кода», — говорит он, называя это «сдвигом в одном из основных аспектов идентичности разработчика».</p> <p>Когда кодирование перестает быть медленным этапом, узкое место перемещается вверх по цепочке — к проектированию, которое также перестраивается под воздействием ИИ. Это предъявляет новые требования к бизнес-аналитикам и менеджерам по продуктам, требуя от них, по словам Чуанга, «готовых к реализации» концепций. Использование ИИ для изучения сценариев использования и создания макетов интерфейсов до привлечения разработчиков позволяет им «предоставлять гораздо более качественный и продуманный дизайн», — отмечает он.</p> <h3>Помимо показателей производительности</h3> <p>Если кажется, что производительность не меняется, CIO следует сначала оценить, измеряют ли они правильные показатели. По словам директора по технологиям и инновациям консалтинговой фирмы Cornerstone Research Фила Лесли, проанализировав более миллиона записей о рабочем времени они получили «по сути отрицательный ответ» о росте производительности благодаря ИИ. Но этот вывод, несмотря на точные данные, также вводит в заблуждение.</p> <p>«Использование ИИ не привело к заметному сокращению рабочего времени аналитиков, — говорит он. — Но оно изменило структуру: аналитики сообщают о меньшем времени, затрачиваемом на кодирование и отладку, и большем — на интерпретацию, методологию и размышления. Работа выглядит по-другому, хотя количество рабочих часов не изменилось».</p> <p>Некоторые организации сообщают о значительном росте производительности благодаря кодированию с помощью ИИ. Однако даже в этом случае технологические руководители утверждают, что рост производительности — не самое важное изменение.</p> <p>Например, в Bank of America, который ежегодно инвестирует в технологии почти 14 млрд. долл., использование ИИ для помощи в кодировании, применяемой более чем 18 тыс. разработчиками, обеспечивает повышение эффективности более чем на 20%. Но дело не в чистой скорости, говорит Хари Гопалкришнан, директор банка по технологиям и информации: «Потребность в талантливых людях, способных решать сложные проблемы, принимать взвешенные решения и выстраивать отношения, останется критически важной».</p> <h3>Показатели активности vs. бизнес-результаты</h3> <p>Большинство стандартных показателей ИИ-кодирования по-прежнему учитывают усилия, а не результаты: развернутые рабочие места, использованные токены, сгенерированные строки кода, самостоятельно заявленная экономия часов. «Это показатели активности, — отмечает Браун. — Лучше спросить, изменились ли бизнес- и инженерные результаты».</p> <p>Он рекомендует дашборд, который не похож на счетчик токенов и отслеживает время цикла от идеи до производства, частоту развертывания, процент неудачных релизов, скрытые дефекты, уязвимости безопасности и долю сгенерированного ИИ кода, требующего существенной коррекции человеком. «Цель не в увеличении количества кода, — поясняет Браун. — А в более быстрой, безопасной и качественной доставке, ориентированной на бизнес-результаты».</p> <p>Данные исследований демонстрируют, почему качество имеет значение. Анализ 211 млн. строк кода, проведенный компанией GitClear, производителем инструментов для разработчиков, показал, что объем изменений кода почти удвоился в период с 2020 по 2024 гг., в то время как рефакторинг снизился с 25% до менее чем 10%. Согласно исследованию софтверной компании Opsera, проведенному в 2026 г., запросы на слияние, сгенерированные ИИ, проверяются в 4,6 раза дольше и содержат на <nobr>15-18%</nobr> больше уязвимостей безопасности, чем код, написанный человеком. Сэкономленное на написании кода время часто сгорает позже в очередях на проверку и исправлениях безопасности.</p> <h3>Бомба замедленного действия для начинающих разработчиков</h3> <p>Однако самый серьезный риск проявится не в показателях этого года. Он станет явным через два-три года. Рутинная работа, которую сейчас берет на себя ИИ — исправление ошибок, документирование и тестовое покрытие — это именно то, на чем начинающие разработчики оттачивают свои навыки. Заберите это у них «без новой модели ученичества, которая бы заменила это», и компании создадут дефицит кадров через два-три года, предупреждает Браун.</p> <p>Сокращение вакансий начального уровня на основании теории о том, что ИИ заменит начинающих разработчиков, — это «почти билет в один конец», считает Лесли: «Необходима модель ученичества — это то, как почти в каждой профессии развивается способность принимать решения, на которую в конечном итоге полагаются опытные специалисты».</p> <p>Решение заключается не в прекращении найма начинающих разработчиков, а в переосмыслении этой роли. Лучшие начинающие разработчики «будут знать не только как писать код — они будут знать, как задавать правильные вопросы, понимать бизнес-цель, лежащую в основе ПО, и оценивать, действительно ли сгенерированный ИИ код результат решает проблему», — говорит Браун.</p> <p>Меняется и подход к найму. Чуанг теперь отдает предпочтение разработчикам, которые «более междисциплинарны и интересуются решением основных бизнес-задач». По мере удешевления программирования «умение определять, что и как кодировать, становится ценным активом», причем наибольшую ценность приобретают разработчики, которые понимают проектирование систем и могут обеспечивать «безопасность, соответствие нормативным требованиям и удобство сопровождения» автоматизированных процессов в течение длительного времени, отмечает Мальпани.</p> <h3>Управление смещается в центр</h3> <p>По мере распространения кода, генерируемого ИИ, контроль перемещается с периферии в ядро ​​работы. «Акцент смещается с проверки каждой строки написанного вручную кода на управление всем жизненным циклом ПО: тестированием, развертыванием, правами доступа, возможностью аудита и поведением во время выполнения», — говорит Мальпани.</p> <p>По его словам, предприятиям потребуются платформы, обеспечивающие последовательный контроль, отслеживаемость и мониторинг независимо от того, какой агент по кодированию создал код. Он подчеркивает, что агентам «необходимы механизмы контроля и опытные рецензенты».</p> <p>Это парадоксальный урок. Агенты-кодеры «не устранили необходимость в платформах разработки low-code или корпоративных платформах разработки, — отмечает Мальпани. — Они сделали эти платформы более ценными. Более быстрая генерация кода увеличивает потребность в проверках, оценке, управлении и сотрудничестве».</p> <p>Скорость — это часть выгоды. Но полная ценность инструментов ИИ-кодирования проявляется только тогда, когда меняется подход к разработке ПО в том, как формируются команды, как оценивается работа и как следующее поколение учится оценивать результаты работы машин.</p> Инструменты для кодирования с помощью искусственного интеллекта стали общедоступными. Сегодня для CIO важна не только … article https://www.itweek.ru/themes/detail.php?ID=235254 Tue, 28 Jul 2026 08:48:37 +0300 <p>Раньше нам было достаточно просто задавать ИИ вопросы. Теперь мы можем назначить ему цель — и он сам достигнет результата. Такой ИИ называют агентом.</p> <p>Можно написать в чат-бот, чтобы он подготовил текст ответа клиенту. А можно доверить всё агенту — он сам найдёт обращение, проверит CRM, запросит недостающее, сформирует ответ и передаст сотруднику или отправит, если это разрешено.</p> <p><a href="https://www.mckinsey.com/capabilities/quantumblack/our-insights/seizing-the-agentic-ai-advantage">McKinsey описывает</a> развитие агентных технологий как переход от реактивных инструментов к проактивным системам, способным самостоятельно двигаться к заданной цели.</p> <p>Поэтому главный вопрос для бизнеса постепенно меняется. Раньше компании выясняли, может ли ИИ выполнить задачу в принципе. Теперь определяют, какие действия можно поручить ИИ-агенту без постоянной верификации человеком.</p> <p>Спойлер: универсального ответа пока нет. Начинается всё с контекста: если системе не хватает данных о процессе, об автономности говорить рано. А когда контекст есть, мера самостоятельности зависит от трёх вещей — цены ошибки, возможности исправить последствия и насколько формализуемо конкретное действие.</p> <h3>От анализа после события — к действию в моменте</h3> <p>Классический анализ бизнес-процессов (Process Mining) больше про ретроспективу. Сначала нарушается срок, растёт очередь или возникает лишняя доработка. Бизнес восстанавливает ход процесса и находит причину. Без такого анализа невозможно понять фактическую работу компании, но он отвечает на вопрос «почему возникла проблема», когда последствия уже наступили.</p> <p>Следующий уровень — контроль во время выполнения процесса. Система видит, что заявка приближается к предельному сроку, документ повторно возвращается на доработку или нагрузка на участок превышает его возможности. Она собирает контекст и сообщает ответственному сотруднику, что произошло, почему возник риск и какие действия доступны. Система здесь как помощник: готовит решение и отдает его человеку.</p> <p>На третьем уровне система сама корректирует — запрашивает недостающие сведения, повторно запускает техническую проверку, меняет приоритет или передает заявку свободному специалисту. Это — та самая агентная история.</p> <p>В большинстве корпоративных проектов, с которыми мы сталкиваемся, пока преобладает второй уровень.</p> <h3>Не все действия требуют одинакового контроля</h3> <p>Частая ошибка — обсуждать автономность как единый режим, то есть либо система действует сама, либо каждое ее решение подтверждает человек.</p> <p>На практике полномочия нужно определять для каждого действия отдельно. Есть три критерия:</p> <ul> <li> Масштаб последствий. Автоматическая отправка напоминания и изменение условий договора несут разный риск, даже если технически выполняются одним агентом.</li> <li> Обратимость. Ошибочно изменённый приоритет заявки можно быстро вернуть. Проведённую выплату, раскрытые данные или принятое юридически значимое решение отменить намного сложнее.</li> <li> Формализуемость. Можно ли однозначно описать правила действия, получить необходимые данные, учесть основные исключения и проверить результат? Чем больше решение зависит от неоднозначной оценки, профессионального суждения или неполного контекста, тем меньше оснований для полной автономности.</li> </ul> <p>Низкорисковые и обратимые действия система может выполнять сама. Например, запросить отсутствующий документ, повторно провести техническую проверку или перенаправить обращение по установленному правилу. Если последствия заметны, но действие можно исправить, возможен автоматический запуск с последующим контролем. Ответственный сотрудник получает информацию о выполненной операции и вмешивается только при отклонении.</p> <p>Для решений с высокой ценой ошибки нужно сохранить предварительное подтверждение человека. Это касается ситуаций, влияющих на права клиента, крупные финансовые обязательства, условия договора или безопасность.</p> <h3>Что нужно определить до передачи полномочий</h3> <p>Чтобы ИИ мог действовать самостоятельно, недостаточно добиться высокой точности модели. Бизнесу нужно подготовить сам сценарий:</p> <ul> <li> Процесс должен иметь понятные границы. Система должна знать, какое событие запускает работу, каких целей нужно достичь и в какой момент задача считается выполненной. Например, формулировка «следить за качеством обслуживания» слишком абстрактная, а вот «обнаруживать обращения, которые могут выйти за установленный срок, и перераспределять их по заданным правилам» уже можно контролировать.</li> <li> Для действия нужен контекст. ИИ должен получать данные не только о текущей операции, но и о предшествующих событиях, ограничениях и возможных последствиях. Заявку нельзя автоматически перенаправлять только потому, что один сотрудник свободен. Нужно учитывать его полномочия, специализацию, текущую загрузку, приоритет клиента и влияние на другие задачи. Если система видит лишь часть процесса, автономное действие может устранить локальную проблему и создать новую на следующем этапе.</li> <li> Результат должен быть проверяемым. Нужно заранее определить, по каким признакам компания поймёт, что действие было корректным. Система перераспределила заявки — изменилось ли число нарушений срока? Запросила недостающие сведения — сократилось ли количество возвратов? Повысила приоритет — не выросла ли очередь по другим категориям? Без этого бизнес контролирует сам факт выполнения операции, но не её влияние на процесс.</li> <li> Каждое действие должно оставлять след. Для автономной системы необходимо фиксировать, что она сделала, на основании каких данных, какие правила применила и к какому результату пришла. Без истории действий невозможно разобрать ошибку, определить её источник и изменить сценарий.</li> <li> У процесса должен оставаться владелец. Нужно конкретно определить, кто утверждает границы полномочий агента, кто имеет право остановить сценарий, кто разбирает ошибки и кто отвечает за решения с существенными последствиями.</li> </ul> <p>В добровольной <a href="https://www.nist.gov/itl/ai-risk-management-framework">рамке NIST по управлению рисками ИИ</a> отдельно оговаривается необходимость разграничивать роли тех, кто использует систему, и тех, кто контролирует её работу. Я бы добавил сюда еще одну роль — кто отвечает за решения, принятые на основании результатов. Без такого разделения ответственность быстро становится фактически ничьей.</p> <p>Для корпоративного применения возможности наблюдать и останавливать систему должны быть базовыми.</p> <h3>Автономность нужно увеличивать постепенно</h3> <p>Передавать системе сразу весь сценарий необязательно. Надёжнее последовательно расширять ее полномочия.</p> <ul> <li> Сначала ИИ обнаруживает отклонение и собирает контекст. Ответственный сотрудник самостоятельно выбирает действие.</li> <li> Затем система начинает предлагать конкретную реакцию и объяснять, почему считает её подходящей.</li> <li> После проверки на реальном потоке ей можно разрешить выполнять действие с предварительным подтверждением.</li> <li> Следующий этап — самостоятельное выполнение обратимых операций с последующим контролем.</li> </ul> <p>Такой подход может показаться осторожным, но на практике он позволяет быстрее расширять автоматизацию. Компания накапливает историю решений, видит реальные исключения и понимает, какие ограничения можно ослабить без увеличения риска.</p> <h3>Человек перестаёт контролировать каждую операцию</h3> <p>Рост автономности меняет роль человека в процессе. Вместо ручной проверки каждого случая сотрудник:</p> <ul> <li> формулирует цель;</li> <li> задаёт правила и ограничения;</li> <li> определяет допустимый риск;</li> <li> контролирует исключения;</li> <li> оценивает сквозной результат;</li> <li> корректирует сценарий по мере изменения процесса.</li> </ul> <p>Агент берет на себя наблюдение, сбор информации и стандартные действия. Человек сохраняет экспертизу и ответственность там, где решение нельзя свести к устойчивому и проверяемому правилу.</p> <p>Поэтому я бы не ставил перед бизнесом цель добиться максимальной автономности. Более зрелая задача — добиться минимального ручного участия при сохранении управляемости.</p> <p>Уровень развития ИИ-системы определяется тем, насколько точно компания провела границу между разрешенным автоматическим действием и обязательной человеческой ответственностью.</p> <p>#IMAGE_235255#</p> Раньше нам было достаточно просто задавать ИИ вопросы. Теперь мы можем назначить ему цель — и он сам … article Александр Бочкин, генеральный директор “Инфомаксимум” https://www.itweek.ru/themes/detail.php?ID=235253 Mon, 27 Jul 2026 18:04:55 +0300 <p>Компания «Аладдин» сообщила о получении нового сертификата ФСБ России № СФ/124-5574 на СКЗИ «Aladdin CryptoFlash», защищённый флеш-накопитель со встроенным аппаратным шифрованием данных. Срок действия нового сертификата — до 16 июля 2029 года.</p> <p>Новый сертификат выдан с учётом новых функций в Aladdin CryptoFlash:</p> <ul> <li>добавлены РЕД ОС 7.3 и 8, Альт 8 СП, рабочая станция, «Альт Рабочая станция» 10, а также ОС «Московской электронной школы» в список поддерживаемых операционных систем семейства Linux;</li> <li>увеличена скорость чтения/записи до 11 МБ/с;</li> <li>улучшен графический интерфейс.</li> </ul> <p>Сертификат подтверждает, что СКЗИ «Aladdin CryptoFlash» соответствует требованиям ФСБ России к СКЗИ по классам KC1/KC2, предназначенным для защиты информации, не содержащей сведений, составляющих государственную тайну. При этом сертификат ФСБ России № СФ/124-5342 от 15 декабря 2025 г. на Aladdin CryptoFlash сроком до 15 декабря 2028 г. остаётся без изменений и продолжает своё действие.</p> <p>Aladdin CryptoFlash — защищённый USB флеш-накопитель со встроенным аппаратным шифрованием данных (российский алгоритм «Магма»). Продукт предназначен для безопасного хранения и переноса данных, включая информацию ограниченного распространения (служебной тайны, конфиденциальной информации с отметкой ДСП). Aladdin CryptoFlash относится к классу устройств Clientless и обеспечивает возможность работы с ним без установки на компьютер какого-либо дополнительно программного обеспечения. Аппаратно реализованный в устройстве алгоритм шифрования «Магма» показывает достаточно высокую скорость работы — 11 Мб/с.</p> Компания «Аладдин» сообщила о получении нового сертификата ФСБ России № СФ/124-5574 на СКЗИ «Aladdin CryptoFlash» … message https://www.itweek.ru/themes/detail.php?ID=235252 Mon, 27 Jul 2026 18:03:06 +0300 <p>Вайбкодинг — создание работающих приложений с помощью ИИ-агентов по текстовому описанию задачи — превратился в России из эксперимента в устойчивую практику разработки со своим стеком, экономикой и типовыми барьерами. Битрикс24 опросила активных практиков среди представителей бизнеса и выяснила: 81% из них не называют разработку своей основной ролью. Ядро сообщества составляют предприниматели (44%) и руководители (12%), далее идут аналитики (7%), продакт-менеджеры и маркетологи (по 5%). Профессиональным разработчиком по уровню подготовки назвал себя лишь каждый шестнадцатый (6%), а 52% пришли в практику фактически с нуля — с нулевыми навыками программирования или умением править только HTML-разметку.</p> <p>Практика при этом молодая и интенсивная одновременно: 61% занимаются вайбкодингом меньше полугода, но 62% делают это почти каждый день, а 88% — не реже нескольких раз в неделю. За короткий срок у 69% участников появилось от двух до пяти полноценно работающих проектов, ещё у 13% — шесть и более. 72% сообщили, что их приложения функционируют почти без вмешательства человека, а пользуются ими прежде всего коллеги (61%) и клиенты (59%) авторов — то есть созданный «неразработчиками» софт уже находится в реальной эксплуатации и обслуживает чужие задачи.</p> <p>Инструментальный стандарт сложился вокруг агентных сред: Claude Code используют 55% опрошенных, OpenAI Codex — 54%. Классические редакторы с ИИ-надстройками отошли на второй план — VS Code с AI-расширениями применяют 26%, Cursor — 24%, ещё 22% обходятся обычным ChatGPT без среды разработки. Инструменты предыдущей волны занимают нишевые позиции: Google Antigravity — 6%, GitHub Copilot — 4%, Lovable — 3%, Replit — 1%.</p> <p>Модельный стек мультивендорный: большинство участников применяют несколько LLM параллельно. Лидируют OpenAI (71%) и Claude (58%), за ними — DeepSeek (34%) и Qwen (24%). Российский BitrixGPT применяет почти каждый четвёртый (23%) — прежде всего благодаря интеграции в корпоративную экосистему. Gemini или Gemma используют 21%, ещё 11% работают с локальными моделями — как правило, из соображений контроля и приватности. </p> <p>Барьеры практики исследование фиксирует вполне инженерные. Чаще всего процесс «ломается» на том, что ИИ неверно понимает задачу (37%), на сопровождении проекта после запуска (32%) и на безопасности (27%). Среди навыков сложнее всего оказалось довести проект до конца (36%), обеспечить безопасность (33%) и разобраться в архитектуре (32%).</p> <p>Безопасность при этом остаётся главным системным риском. 54% участников проверяют сгенерированный код на уязвимости средствами самого же ИИ — то есть делегируют аудит тому же классу инструментов, который этот код создал. Ещё 28% не проверяют код вовсе, осознавая риск, 4% не знают, как это делать, и лишь 11% проводят ручной аудит. Среди тех, чьими проектами уже пользуются клиенты, вручную код проверяют только 14%.</p> <p>Влияние на профессию разработчика участники оценивают радикально: 73% заявили, что вайбкодинг заменил им разработчика, а среди предпринимателей и руководителей эта доля достигает 80%. Одновременно каждый третий (33%) пришёл к противоположному выводу — в сложных задачах без инженеров по-прежнему не обойтись. Меняются и сами практики: 38% стали лучше формулировать технические задания, 37% — «думать как разработчик». Роль профессионального инженера смещается от написания кода к архитектуре, ревью и разбору нестандартных ситуаций.</p> <p>«Мы наблюдаем повторение истории low-code, но на другой скорости и без порога входа. Разработка перестаёт быть исключительной функцией ИТ-отдела и становится компетенцией владельца процесса. Для ИТ-директоров это развилка: либо практика останется теневой — с кодом, который никто не ревьюит, либо сотрудники получат управляемую среду, где безопасность и контроль качества встроены по умолчанию. Самый дефицитный навык здесь уже не знание синтаксиса, а умение корректно поставить задачу и валидировать результат», — прокомментировал Александр Вартанян, директор по маркетингу Битрикс24.</p> <p>В необратимости сдвига участники практически уверены: 39% считают, что будущее, в котором каждый сотрудник самостоятельно собирает мини-приложения под рабочие задачи, уже наступило, ещё 30% ожидают массового перехода к такой практике в ближайшие один-два года. Для ИТ-департаментов это означает, что новая категория разработки возникает снизу и вне их контура — и вопрос смещается с «разрешать или запрещать» на «как управлять».</p> Вайбкодинг — создание работающих приложений с помощью ИИ-агентов по текстовому описанию задачи — превратился … message https://www.itweek.ru/themes/detail.php?ID=235251 Mon, 27 Jul 2026 18:00:17 +0300 <p>SimpleOne (направление прикладных бизнес-систем корпорации ITG) выпустила ITSM 2.0.0. Продукт получил значительное обновление — ИИ-помощник на сервисном портале самообслуживания: пользователи описывают свои запросы в свободной форме, а система сама находит нужную услугу, статью базы знаний или известную ошибку и готовит предзаполненную форму обращения нужного типа.</p> <p>ИИ-помощник работает с данными, которые уже есть в системе: каталогом услуг, моделями типовых запросов, базой знаний, объявлениями и известными ошибками. Пользователь описывает ситуацию своими словами — система понимает смысл запроса, находит подходящий материал и помогает дойти до результата: показывает обходное решение, объявление о плановых работах или помогает заполнить обращение. Внедрение не требует перестройки процессов — ИИ-помощник усиливает то, что уже настроено. Теперь не важно, насколько сложно устроен портал, ИИ-помощник найдет то, что нужно пользователю и поможет сформировать обращение наиболее эффективным образом.</p> <p>Для бизнеса это меняет экономику поддержки: типовые вопросы закрываются через самообслуживание, известные проблемы не порождают повторных инцидентов, а сложные обращения приходят к специалистам сразу с заполненными полями и полным контекстом. Нагрузка на первую линию снижается без роста штата. Для сотрудников и клиентов портал становится более понятным — достаточно описать ситуацию своими словами, и помощник сам найдёт ответ, подберёт услугу или подготовит форму обращения. Для поставщика услуг простые задачи решаются на раннем этапе и не доходят до специалистов, а ресурсы, которые раньше уходили на рутину, можно направить на развитие услуг. При этом ИИ-помощник одинаково применим для любого сервисного подразделения — ИТ, HR, бухгалтерии, юридического отдела.</p> <p>«Много лет мы ждали технологию, которая решит проблему портала. Чат-боты не подошли — они оказались слишком примитивными. Генеративный искусственный интеллект с технологией поиска по корпоративным данным — это именно то, что нужно. Он говорит на языке пользователя и понимает контекст компании. Совершенно неважно, как выглядит ваш сервисный портал и как там организована информация — теперь для потребителя ваших услуг всё будет работать максимально эффективно», — прокомментировал Андрей Вишняков, директор по бизнес-продуктам компании SimpleOne, корпорация ITG, ITIL 4 Master, ITIL 3 Expert, Practitioner, автор РИТМ.</p> <p>В версию также вошла база данных известных ошибок (KEDB) на портале: она уменьшает время простоя услуг, дает пользователям возможность самостоятельно минимизировать последствия распространенных неполадок, а также помогает снизить количество обращений в службу поддержки. Оценки и отзывы по каждой статье накапливаются в системе и позволяют улучшать базу на основе реальной обратной связи.</p> <p>Расширена возможность коммуникации и работы специалистов. Комментарии из мессенджера и электронной почты теперь добавляются в ленту записи от имени пользователя, а если отправитель не зарегистрирован в системе — по его письму автоматически создаётся пользовательский вопрос. При массовом завершении инцидентов и запросов специалисты теперь могут одновременно оставить служебную заметку ко всем закрываемым записям. Форма инцидента получила виджет сервисных отношений, контекстные обязательные поля — при переводе в статусы «Внешняя обработка» и «Отложено» — и защиту автозаполняемых полей дочерних инцидентов от случайного редактирования.</p> SimpleOne (направление прикладных бизнес-систем корпорации ITG) выпустила ITSM 2.0.0. Продукт получил значительное … message https://www.itweek.ru/themes/detail.php?ID=235249 Mon, 27 Jul 2026 15:22:30 +0300 <p>С глубоким прискорбием сообщаем, что на <nobr>93-м</nobr> году жизни после тяжёлой болезни скончался <strong>Леонид Абрамович Теплицкий</strong>, замечательный и отзывчивый человек, мудрый руководитель, специалист по вычислительной технике, лауреат Государственной премии СССР, генеральный директор СК Пресс, соавтор «Англо-русского толкового словаря по искусственному интеллекту и робототехнике» (4400 статей) и «Большого англо-русского толкового словаря по вычислительной технике и информационным технологиям», который регулярно пополняется и в настоящее время содержит свыше 55 тыс. тысяч статей, являясь самым большим словарём этого типа в мире. Леонид Абрамович является также соавтором «Англо-русского словаря по информационной безопасности» (6200 словарных статей).</p> <p>В 1956 году Леонид Абрамович окончил факультет приборостроения МВТУ им. Н. Э. Баумана по специальности «инженер-механик». Затем более 35 лет <nobr>(1956–1992 гг.)</nobr> работал на Московском Заводе счетно-аналитических машин (САМ), пройдя путь от инженера до заместителя главного конструктора по производству вычислительных машин и главного специалиста по супер-ЭВМ. </p> <p>Непосредственно участвовал в разработке и создании легендарных советских ЭВМ и вычислительных комплексов: М-20, «БЭСМ-6», АС-6, а также многопроцессорного вычислительного комплекса «Эльбрус» (МКП). За заслуги в области отечественной вычислительной техники был удостоен Государственной премии СССР, награждён медалью «За трудовое отличие» и другими государственными наградами.</p> <p>С <nobr>1960-х</nobr> активно сотрудничал с издательством «Мир» и Всесоюзным центром переводов (ВЦП) в качестве переводчика и научного редактора компьютерной литературы. В <nobr>1992–1994 гг.</nobr> работал в журнале PC Magazine/Russian Edition (научный редактор, главный редактор). В 1994 г. стал генеральным директором Издательского дома «СК Пресс», выпускавшем PC Magazine/RE; PC Week/RE (c 2018 г. itWeek); CRN/RE (c 2022 г. IT Channel News) и ряд других изданий.</p> <p>Леонид Абрамович был уникальным человеком, отличавшимся феноменальным трудолюбием и дружественностью общения. Для всех работавших с ним и близко его знавшим это тяжёлая утрата.</p> <p>Выражаем искренние соболезнования родным, близким, друзьям и коллегам Леонида Абрамовича.</p> <p><em><strong>Редакция</strong></em></p> С глубоким прискорбием сообщаем, что на 93-м году жизни после тяжёлой болезни скончался Леонид Абрамович Теплицкий … message https://www.itweek.ru/themes/detail.php?ID=235247 Mon, 27 Jul 2026 09:42:17 +0300 <p>Выполнение нормативных требований — одна из важнейших задач служб информационной безопасности. А сами проверки контролирующих органов могут стать «испытанием на прочность» для системы ИБ в организации. Например, в 2025 году более 77% операторов персональных данных <a href="https://www.securitylab.ru/news/570501.php">заявили</a>, что обнаружение нарушений при проверке Роскомнадзора является для них главным риском с точки зрения ИБ.</p> <p>Регуляторы же продолжают усиливать контроль. Например, ФСТЭК России в 2024 году проведено <a href="https://tass.ru/ekonomika/23062459">около 170</a> проверок субъектов КИИ, а в <nobr>2025-м —</nobr> уже <a href="https://telecomdaily.ru/news/2026/01/28/fstek-v-2026-godu-uvelichitsya-chislo-proverok">более 700</a> и по их итогам на организации заведено более 600 дел об административных правонарушениях, а в 2026 году служба планирует дополнительно нарастить количество контрольных мероприятий.</p> <p>Расскажу, с какими проверками ИБ могут столкнуться организации, на что обращают внимание различные органы и какие факторы могут привести к «провалу», а какие — наоборот, покажут добросовестность организации.</p> <h3>Кто и как проводит проверки</h3> <p>Проверки информационной безопасности в организациях могут проводить несколько регуляторов, у каждого из них — своя специфика.</p> <ul> <li><strong>ФСБ России</strong>: проверяют защиту информации с помощью криптографических средств, соблюдение правил использования СКЗИ, защиту периметра информационной системы, выявление атак, взаимодействие с ГосСОПКА. Проверки, как правило, выездные и инициируются в случае ИБ-инцидентов.<br/> <br/> ФСБ контролирует организации, работающие с государственной тайной, субъекты КИИ, операторов ГИС и ИСПДн, пользователей криптографии. В сфере внимания — выполнение требований <nobr>187-ФЗ</nobr> и ведомственных актов (например, приказов № 547, 378), а также <nobr>149-ФЗ,</nobr> <nobr>152-ФЗ,</nobr> ППРФ № 1119 в части применения криптографии.<br/> <br/> В ходе проверок оценивают реализацию процессов защиты информации (например, учет и хранение СКЗИ, взаимодействие с ГосСОПКА, выполнение пентестов), анализируют произошедшие инциденты, проверяют документы в части ИБ и их соответствие реальной ситуации в организации.<br/> <br/> Средняя продолжительность проверки — 2 недели. </li> <li><strong>Роскомнадзор</strong>: проверяет любые организации в части выполнения требований к обработке и защите персональных данных. Контролируют соблюдение требований к работе с ПДн: сроки их хранения, локализацию, порядок уничтожения, разграничение доступа, соответствие целям обработки, обеспечение безопасности ИСПДн. Также проверяют соответствие сайтов организаций требованиям <nobr>152-ФЗ:</nobr> наличие форм согласий, применение российских сервисов, использование данных о пользователях, генерируемых сайтами (cookies).<br/> <br/> Проверка может проходить в документарном или выездном формате, а также в виде анализа сайта организации. Приказ с перечнем подлежащих проверке организаций в 2026 году размещен <a href="https://rkn.gov.ru/activity/prevention-violations/">в открытом доступе</a>.<br/> <br/> Средний срок — 20 рабочих дней. </li> <li><strong>Прокуратура РФ</strong>: контролирует исполнение законодательства РФ в целом, в том числе и законов, регулирующих вопросы ИБ. Могут проверить любую организацию вне зависимости от отрасли, на основании жалобы о нарушении законодательства, выявленного факта нарушения или поручения Генерального прокурора. Также контролируют исполнение предписаний других органов власти. Прокурорские проверки могут быть комплексными, то есть затрагивать вопросы не только соблюдения требований в части ИБ, но и других положений законодательства.<br/> <br/> Проводят выездные и документарные проверки. Сведения о плановых проверках <a href="https://proverki.gov.ru/portal">размещены в открытом доступе</a>.<br/> <br/> Средний срок — 30 календарных дней. </li> <li><strong>ФСТЭК России</strong>: контролируют исполнение требований к защите КИИ, ГИС, ИСПДн, государственной тайны. Проверяют состав мер технической защиты информации, документы в части ИБ, контролируют выявление, категорирование объектов КИИ, соответствие требуемому уровню защищенности, контролируют аттестацию соответствия систем ИБ-требованиям.<br/> <br/> В сфере внимания регулятора — выполнение требований его актов: приказов № 239, 235, 21, 117 и иных. Проверки, как правило, выездные и могут стать для организации неожиданностью, поскольку их планов нет в открытом доступе. Публикуют планы проверок ИБ только для организаций, лицензированных на техническую защиту информации или разработку СЗИ.<br/> <br/> Проверки длятся в среднем около 3 недель. </li> <li><strong>Банк России</strong>: его контрольные мероприятия актуальны для финансовых учреждений. Проверяют все аспекты ИБ в организациях финсектора: состояние технической защиты информации, наличие внутренних документов и их соответствие реальному ИБ- и ИТ-ландшафту, порядок составления ИБ-отчетности и взаимодействия с ФинЦЕРТ, соблюдение требований законодательства, актов Правительства, ИБ-регуляторов, ведомственных актов ЦБ (например, Положений № <nobr>757-П,</nobr> <nobr>851-П,</nobr> Указания № <nobr>7219-У)</nobr> и стандартов ИБ в финсекторе (например, ГОСТ 57580).<br/> <br/> Проводить проверки могут с помощью запроса документов напрямую или через портал ЦБ, так и в выездном формате.<br/> <br/> В среднем, проверка длится около 1 месяца. </li> </ul> <p>Контролировать выполнение одних и тех же норм могут разные органы, а проверки быть совместными. Например, возможны ситуации, когда в финансовой организации проводится проверка Банка России на предмет выполнения требований ФСТЭК или по сообщению об утечке данных в организацию выезжает проверка одновременно Прокуратуры и Роскомнадзора.</p> <h3>Как можно провалить проверку</h3> <p>В последние годы регуляторы отошли от проверки формального соблюдения требований. Сейчас внимание контролирующих органов фокусируется не просто на наличии в организации необходимых документов, персонала и технических средств, а на соответствии декларируемого ландшафта ИБ фактической ситуации. Важно, чтобы организация выполняла ИБ-мероприятия на практике и была готова к реальным действиям при угрозе ИБ.</p> <p>В конце прошлого года руководитель <nobr>8-го</nobr> Управления ФСТЭК России сообщила о наиболее распространенных нарушениях, которые обнаруживаются при проверках со стороны этого регулятора.</p> <ol> <li><strong>Несоответствие реального состава объектов КИИ данным, включенным в реестр таких объектов.</strong> Это могут быть и невыявление объектов КИИ, и присвоение им более низкой категории значимости, и нарушение требования по повторному категорированию ИТ-объектов.</li> <li><strong>Отсутствие контроля за действиями подрядчиков, имеющих доступ к информационным системам организации</strong>. Цепочки поставок в последние годы часто становятся целью для атак, в том числе, на стратегически важные организации. В связи с этим, регуляторы повышают внимание к защите от угроз при работе с подрядчиками. В частности, в последних документах ФСТЭК, например, в приказе № 117 и методических рекомендациях по его выполнению, значительно расширены блоки требований по безопасному взаимодействию с контрагентами.</li> <li><strong>Отсутствие системной работы по обнаружению и «закрытию» уязвимостей на значимых объектах КИИ</strong> и применение уязвимого ПО на этих объектах, отсутствие обновления баз средств защиты, администрирование ИБ-решений с мест без защищенного доступа в Интернет, отсутствие компенсирующих ИБ-мер.</li> </ol> <p>Область контроля <nobr>8-го</nobr> Управления ФТСЭК — все субъекты КИИ. Поэтому эти сценарии актуальны для многих компаний и учреждений из разных отраслей. Однако, и для других организаций, контролирующих ИБ, такие ошибки — фактор «провала» проверки.</p> <p>Также на практике при ИБ-проверках часто встречаются:</p> <ul> <li> <strong>Нарушение требований к физической защите информации</strong> (отсутствие или несоблюдение правил пользования металлических хранилищ, опечатывания помещений, контроля доступа к физическим носителям данных).</li> <li> <strong>Отсутствие или нарушение поэкземплярного учета средств криптографической защиты</strong>.</li> <li><strong>Отсутствие или недостаточная квалификация сотрудников, ответственных за обеспечение ИБ</strong>.</li> </ul> <p>Все эти нарушения связаны с более глубокими проблемами организации и оснащения ИБ-служб, их включения в бизнес-процессы организации. В первую очередь, это «бумажная безопасность», когда есть документы для формального соответствия требованиям без реализации ИБ-мероприятий на практике. В подобных случаях техническая защита отсутствует или базируется на ограниченном количестве решений в устаревших версиях, ИБ-служба «отключена» от участия в бизнес-процессах и не участвует в создании или модернизации ИТ-систем, а менеджмент сокращает финансирование ИБ или не выделяет его вовсе.</p> <p>Такая стратегия рассчитана на то, чтобы пройти плановую документарную проверку регулятора. Однако всего один ИБ-инцидент, который неизбежен в такой ситуации, — это гарантированный повод для выездных контрольных мероприятий. Так, основные регуляторы ИБ — ФСБ и ФСТЭК — проводят проверки исключительно в выездном формате. Результатами таких мероприятий, как правило, становится предписание об устранении нарушений. Это предписание повлечет незапланированные затраты на срочное выполнение прикладных ИБ-мер, закупку средств защиты или ИБ-услуг.</p> <p>Кроме этого, регуляторы заявляют об ужесточении итогов «проваленных» проверок: в 2026 году ожидается применение мер административной ответственности в отношении организаций и сотрудников, допустивших ИБ-нарушения.</p> <h3>Как успешно пройти проверку</h3> <p>Проверки регуляторов проходят комплексно и нацелены на выявление ошибок, которые провоцируют инциденты ИБ. Поэтому организациям следует придерживаться системного подхода к обеспечению информационной безопасности.</p> <p>В первую очередь необходимо провести инвентаризации имеющихся ИТ-активов и анализ нормативных ИБ-требований. Важно определить, какие ИТ-объекты относятся к КИИ, какие используются для обработки персональных данных или должны быть защищены согласно требованиям к ним.</p> <p>Одновременно с этим проводится аудит систем ИБ. В ходе такого аудита изучаются ИБ-аспекты в организации: наличие ответственных за ИБ-задачи, порядок реагирования на инциденты и взаимодействия с регуляторами, выделение материальных, аппаратных и людских ресурсов для нужд ИБ-службы. Кроме того, важно оценить состав и наличие ИБ-средств, статус их обновления, наличие сертификации на них и соответствие требуемому уровню доверия.</p> <p>По итогам этих мероприятий составляется «матрица соответствия». В ней отражаются:</p> <ul> <li> ИБ-требования по каждому из актуальных для организации актов регуляторов;</li> <li> Реализованные для их выполнения меры (составление локальных актов, создание и комплектование ИБ-подразделений, внедрение технических средств защиты, аудит ИТ-активов и иные);</li> <li> Статус выполнения: выполнено, частично выполнено, не выполнено, не применимо.</li> </ul> <p>Данные из матрицы позволяют спланировать дальнейшие ИБ-мероприятия по нескольким направлениям:</p> <ul> <li> Внедрение технических средств и выполнение технических задач (например, закрытие уязвимостей и пентест).</li> <li> Разработка документов (например, стандартов и регламентов защиты информации согласно требованиям приказа ФСТЭК № 117).</li> <li> Организационные задачи (например, проведение учений для персонала организации, повышение квалификации ИБ-службы, оценка защищенности, выделение дополнительных ресурсов на обеспечение ИБ).</li> </ul> <p>При анализе «матрицы соответствия» может выясниться, что ИБ-задач много и выполнить их одновременно не удастся. В таком случае лучше начать не с составления больших документов, чтобы «прикрыть» все возможные недостатки, а сосредоточиться на отдельных рисках безопасности. Например, сначала провести категорирование объектов КИИ, потом найти и исключить все уязвимости, избыточные доступы и пароли «по умолчанию», затем обновить все средства защиты информации, докупить необходимые и наладить с их помощью процессы ИБ-мониторинга.</p> <p>Итогами работы по подготовке к ИБ-проверкам должны стать:</p> <ul> <li> Взаимное соответствие ИБ-документов в организации, процессов ИБ и фактического состояния информационных систем.</li> <li> «Закрытие» уязвимостей, исключение паролей «по умолчанию» на объектах ИС.</li> <li> Исключение нарушений физической безопасности информации и информационных систем.</li> <li> Внедрение и практическое применение средств защиты информации, обучение ИБ-специалистов работе с ними, выявление, регистрация и ликвидация ИБ-инцидентов с помощью ИБ-решений.</li> <li> Реализация полного цикла контроля и мониторинга безопасности информационных систем.</li> <li> Непрерывное (в идеале, автоматизированное) взаимодействие с регуляторами.</li> </ul> <p>В таком случае, когда регулятор увидит системную работу ИБ-службы и готовность к отражению реальных киберугроз, шансы успешно пройти проверку значительно повышаются. Сами контрольные мероприятия при этом станут не фактором риска, а возможностью дополнительно усовершенствовать систему ИБ, получить ценные прикладные рекомендации и выполнить их в размеренном плановом режиме.</p> <p>#IMAGE_235248#</p> Выполнение нормативных требований — одна из важнейших задач служб информационной безопасности. А сами проверки … article Дмитрий Вощуков, специалист по связям с государственными органами “СёрчИнформ” https://www.itweek.ru/themes/detail.php?ID=235246 Fri, 24 Jul 2026 17:00:14 +0300 <p>Технологическая компания YADRO (входит в ИКС Холдинг) объявила о раннем доступе к новому инженерному решению для эффективного охлаждения высоконагруженных центров обработки данных и AI-кластеров. Особую актуальность представленному решению придают неуклонно растущие требования к вычислительным мощностям, вызванные повышенным спросом на цифровые сервисы. ЦОД становятся все более производительными, и выделяемое тепло необходимо эффективно отводить для обеспечения бесперебойной работы ИТ-инфраструктуры.</p> <p>Новое решение представляет собой готовую архитектуру гибридной системы охлаждения ЦОД, объединяющую преимущества воздушного и жидкостного типов охлаждения. Оно состоит из инженерного контура BOREY «Посейдон», включающего драйкулер с гидравликой и блок распределения охлаждающей жидкости, а также вычислительных комплексов RACKSCALE с водоподготовкой. </p> <p>Ключевыми особенностями решения являются применение технологии Direct Liquid Cooling, позволяющей точечно отводить тепло от CPU и GPU, а также блок распределения охлаждения БРО-300, равномерно подающий охлаждающую жидкость между серверными стойками. Выделяемое тепло при этом отводится из машинных залов ЦОД и передается далее на радиатор драйкулера, расположенного снаружи ЦОД, где эффективно рассеивается в атмосферу. </p> <p>Решение поставляется полностью подготовленным и протестированным инженерами YADRO, что значительно сокращает сроки ввода в эксплуатацию. За счёт дублирования всех ключевых узлов блока БРО-300 архитектура гибридного охлаждения может быть развёрнута в ЦОД уровня Tier 3 с повышенными требованиями к отказоустойчивости. В качестве типовых сценариев внедрения возможны модернизация существующих ЦОД с воздушным охлаждением, строительство новых площадок, а также повышение энергоэффективности стандартной вычислительной инфраструктуры — не только в AI-кластерах, но и в универсальных вычислительных средах.</p> <p>«Рост плотности вычислений меняет требования к проектированию ЦОД: заказчикам нужно заранее учитывать тепловую нагрузку серверов, доступность энергомощностей и стоимость эксплуатации. Интеграция вычислительного оборудования и инженерных систем в едином решении снижает риски несовместимости и ускоряет развертывание инфраструктуры. Для задач искусственного интеллекта это особенно важно: жидкостное охлаждение помогает поддерживать стабильную работу серверов при длительных циклах обучения моделей и инференса», — отметил Ратмир Трошин, директор департамента инженерных решений YADRO.</p> <p>Управление инженерным контуром реализовано на базе разработанных в России аппаратных и программных компонентов, включая контроллер системы. Программное обеспечение включено в реестр российского ПО Минцифры России и интегрировано с платформой мониторинга YADRO СУПРИМ. Это позволяет получать телеметрию, контролировать параметры работы оборудования и оперативно реагировать на изменения в инфраструктуре.</p> <p>В III квартале 2026 года YADRO планирует открыть демонстрационную зону и испытательную лабораторию для решений на базе жидкостного охлаждения. На площадке партнеры и заказчики смогут проверить работу платформы в условиях, приближенных к промышленной эксплуатации, и оценить применимость решения для высокоплотных вычислительных кластеров.</p> Технологическая компания YADRO (входит в ИКС Холдинг) объявила о раннем доступе к новому инженерному решению для … message https://www.itweek.ru/themes/detail.php?ID=235238 Fri, 24 Jul 2026 00:00:00 +0300 <p>Как мы можем определить достаточность систем охлаждения при проектировании? Посчитать требуемую холодопроизводительность, предусмотреть «запас», посчитать расстояние затухания струй при подаче холодного воздуха в рабочую зону. Это рабочие инструменты для комфортного кондиционирования, где цена ошибки сравнительно невысока, а конфигурация рабочей зоны и направление потоков достаточно предсказуемы.</p> <p>Для ЦОДов же ситуация несколько иная. В случае локального повышения температуры из-за образования застойной зоны есть риск повредить крайне дорогостоящее оборудование и «положить» всю систему. Посчитать всё «на коленке» не представляется возможным, и тут на помощь приходят они — программы моделирования.</p> <h3>Что это такое?</h3> <p>Модели Computational Fluid Dynamics (CFD) — это разновидность трёхмерного моделирования аэродинамических и теплообменных процессов. Осуществляется на базе метода конечных элементов, то есть когда заданы условия сред на каких-то начальных и конечных участках. И тут как раз кроется главный подводный камень: точность модели зависит от того, насколько корректно заданы начальные условия и описаны процессы для каждого объекта.</p> <p>#IMAGE_235240#</p> <p>Для того чтобы глубже копнуть эту тему, стоит упомянуть программные продукты, которые наиболее распространены и способны решить подобную задачу. Это Ansys, SolidWorks HVAC и DataCenter Design (ранее 6Sigma Room).</p> <p>Ansys представляет собой очень сложный расчётный продукт, который позволяет анализировать детали и конструкции, выстраивать сложные деревья проекта, учитывая не только аэродинамические или гидравлические характеристики сред, но и тепломассообменные процессы, нестационарность сред и тому подобное. Но, с другой стороны, из-за своей сложности, очень высокого порога вхождения и отсутствия собственного графического интерфейса данный софт не очень подходит для анализа помещений с достаточно нелинейными процессами и большим количеством объектов, влияющих на процесс.</p> <p>Плагин SolidWorks HVAC уже больше подходит для анализа именно систем охлаждения для помещений, но всё же имеет очень малую базу готовых элементов и требует ручной настройки и точного понимания, где задавать рабочие плоскости, какие процессы и параметры там необходимо задавать и так далее.</p> <p>И последний представитель — Data Center Design. Как видно из названия, данный продукт разрабатывался именно для анализа ЦОДов. Здесь представлен достаточно простой графический инструмент, который позволяет оперативно выстроить 3D-модель на базе CAD-чертежей. При этом он имеет интегрированные библиотеки с оборудованием для ЦОДов (пусть и несколько устаревшие). Плюс имеются определенные инструменты, специфичные именно для систем в ЦОДах.</p> <p>#IMAGE_235241#</p> <h3>Что это даёт?</h3> <p>С помощью предварительного CFD-моделирования с определенной точностью можно определить достаточность подобранной системы охлаждения, температурный режим работы каждого конкретного блока или стойки, проанализировать подвижность воздуха в тех или иных зонах, влияние препятствий на пути доставки холода и так далее. Также можно заранее посмотреть на состояние систем в рабочем и аварийных режимах, составить тепловые карты в вертикальных и горизонтальных проекциях и получить развёрнутый отчёт о «самочувствии» активного оборудования вплоть до уровня юнита.</p> <p>Конечно, нельзя утверждать, что модель на 100% достоверно показывает, какая ситуация будет в будущем ЦОДе, но она дает возможность определить потенциально проблемные места и провести корректирующие меры на ранней стадии.</p> <p>Еще одним важным фактором является уровень квалификации специалиста, который разрабатывает модель. Отнюдь не всегда получается решить задачу путем использования стандартных блоков. А в любой ситуации, когда идёт отступление от параметров, заложенных в каталожной «болванке», необходимо точно понимать, какой параметр на что влияет, что означает и как повлияет на общую картину.</p> <p>#IMAGE_235242#</p> <h3>Плюсы и минусы</h3> <p>Несомненным плюсом создания CFD-модели является возможность спрогнозировать и избежать различных недочетов в качестве, количестве и мощности систем охлаждения. При этом чем точнее и полнее исходные данные при разработке модели, тем выше ее достоверность.</p> <p>Минусом является то, что такой инструмент оставляет простор для ошибки и искажения результатов из-за неправильного задания начальных и конечных условий, взаимодействия блоков и просто неправильного понимания физики процессов.</p> <h3>Заключение</h3> <p>Назвать CFD-моделирование панацеей нельзя. Это просто дополнительный инструмент в копилку специалистов как на стороне исполнителя, так и на стороне заказчика. Как я уже говорил выше, он может быть полезен в руках опытных специалистов и дать общее представление о ситуации на будущем объекте, но не стоит возводить его в абсолют и считать какой-то непреложной истиной.</p> <p>#IMAGE_235239#</p> Как мы можем определить достаточность систем охлаждения при проектировании? Посчитать требуемую холодопроизводительность … article Кирилл Дмитриев, ведущий архитектор инженерных систем ГК “УльтимаТек” https://www.itweek.ru/themes/detail.php?ID=235225 Fri, 24 Jul 2026 00:00:00 +0300 <p><em>Он никогда и не должен был этого делать, пишет в корпоративном блоге Мануэль Гейтц, главный аналитик </em><em>Forrester</em><em>.</em></p> <p>Скорость не заменяет четкого направления.</p> <p>Из-за шумихи вокруг ИИ может сложиться впечатление, что он переписал правила корпоративной трансформации. Но это не так. Он лишь ускорил ее, подкрепил новым жаргоном и (на короткое время) убедил некоторых руководителей в том, что фундаментальные принципы больше не работают.</p> <p>Автономные агенты могут выполнять работу со скоростью машины, вынуждая CIO управлять ценностью, рисками и согласованностью действий в режиме, близком к реальному времени. Это, конечно, важно, но по сути это старая схема, на которую оказывается давление, и ничего принципиально нового в ней нет.</p> <h3>Критически важные составляющие успешной трансформации остаются прежними</h3> <p>Стратегия по-прежнему на первом месте, просто теперь плохая стратегия приводит к провалу быстрее. Измеримые результаты по-прежнему определяют доверие к компании, только теперь ожидается, что они будут достигаться быстрее. Оценка возможностей по-прежнему важна, но теперь компании включают в свой набор инструментов генеративный ИИ и сопутствующие технологии. Короче говоря, изменился язык. Но суть осталась прежней.</p> <p><strong>Семь основных шагов программы корпоративной трансформации:</strong></p> <ul> <li><strong> Шаг 1. Бизнес-стратегия.</strong> Прежде всего ИИ — это мощный инструмент, но не стратегия. Называть его стратегией — значит путать корпоративные амбиции с промышленной политикой на государственном уровне. Правительства могут стремиться к победе в сфере ИИ. Компании же должны решить, в чем их конкурентное преимущество. Это могут быть цена, скорость, опыт или что-то, что сложнее скопировать.</li> <li><strong> Шаг 2. Результаты.</strong> Любая стратегия должна иметь измеримое определение успеха. Пока желаемые результаты не определены четко, стратегия остается скорее стремлением, а не операционным инструментом. Если вы не сможете измерить стратегически значимые результаты и отчитаться о них, поддержка трансформации сойдет на нет. По мере того как с развитием ИИ растет число возможных инициатив, сценариев использования и технологических решений, четко определенные результаты обеспечивают стратегическую направленность, которая позволяет отличить реальную ценность для бизнеса от экспериментов и имитации инноваций.</li> <li><strong> Шаг 3. Ресурсы.</strong> Корпорациям по-прежнему необходимо оценить и собрать воедино ресурсы, которые помогут им реализовать выбранную стратегию и достичь поставленных целей. ИИ пополняет арсенал инструментов облачными технологиями, данными и автоматизацией. Но он не заменяет собой весь арсенал. ИИ может сократить разрыв между принятием решения и его реализацией, но это не отменяет необходимости доказывать ценность. Скорее наоборот, он поднимает планку.</li> <li><strong> Шаг 4. Операционная модель.</strong> Операционные модели переживают период переосмысления. Идея использования смешанной человеко-машинной рабочей силы звучит радикально. Это не так. Работа всегда перераспределялась с появлением новых инструментов. Разница в том, что на этот раз перераспределение носит когнитивный характер. Рутинное принятие решений автоматизируется, остальные решения становятся более ценными. Однако кто-то все равно должен нести ответственность за решения. На данный момент управление ИИ не может быть обеспечено технически, оно остается за операционной моделью.</li> <li><strong> Шаг 5. Дорожные карты.</strong> ИИ меняет скорость трансформации, а не основы. И он, конечно же, не делает возможными масштабные преобразования. Чем больше технологий, тем больше возможности выбора и взаимозависимости усложняют, а не упрощают реализацию. Поэтапные, ориентированные на конечный результат дорожные карты становятся еще более ценными как средство снижения сложности и управления рисками. Цикл ускоряется, и неудачи становятся все более частыми. Решение заключается не в ослаблении дисциплины, а в том, чтобы усилить ее.</li> <li><strong> Шаг 6. Управление изменениями и рассказывание историй.</strong> И, несмотря на все этим аспекты, остается в силе одна истина. Технологии меняются быстро. Люди движутся медленно. Организации почти не меняются. До тех пор, пока люди остаются вовлеченными (подсказка: так и будет), трансформация остается делом, ориентированным в первую очередь на людей. Необходимо менять навыки, адаптировать методы работы, согласовывать стимулы и преодолевать сопротивление. Ни одна модель, какой бы совершенной она ни была, не сделает это за вас.</li> <li><strong> Шаг 7. Управление реализацией.</strong> И наконец, неприятная правда о производительности. Системные интеграторы, с которыми мы общались, сообщают о росте производительности благодаря ИИ примерно на 20% даже в более контролируемых средах, таких как модернизация технологий. Полезно? Безусловно. Преобразующе? Нет. На данный момент ИИ не стал той панацеей, на которую надеялись те, кто отставал в цифровой трансформации.</li> </ul> <h3>Что же тогда является новым?</h3> <ul> <li><strong> Доверие. Или его отсутствие.</strong> Каждая проблема, связанная с ИИ, — это проблема с данными? Безусловно. Но не в первую очередь. Прежде всего, это проблема доверия. Согласно результатам опроса Forrester «2026 State of AI Survey», в качестве препятствий на пути внедрения ИИ респонденты чаще всего называли безопасность, риски и недоверии к автономным системам. Основная задача компаний — выстроить в рамках своих операционных моделей структуры принятия решений и подотчётности таким образом, чтобы решить проблему доверия, которая является одним из главных препятствий на пути внедрения ИИ.</li> <li><strong> Темп. И ожидания, связанные с темпом.</strong> ИИ заставляет принимать решения, воплощать их в жизнь и оценивать их эффективность в более тесной связке. Он повышает цену неопределённости и снижает терпимость к неэффективному управлению. ИИ позволит организациям выйти на беспрецедентный уровень наблюдаемости и непрерывной обратной связи при выполнении задач, а также обеспечит практически автономную ребалансировку портфеля. Вместо того чтобы упростить трансформацию, ИИ делает ее более требовательной.</li> </ul> <p>Каким бы многообещающим ни был генеративный ИИ, правила успешной трансформации остаются прежними: определитесь с направлением, сформулируйте цели, оцените свои возможности, продумайте процесс принятия решений в рамках операционной модели, внедряйте изменения постепенно и вовлекайте в процесс всю организацию.</p> <p>Успеха добьются те, кто будет делать обычные вещи на высочайшем уровне. Только быстрее и без лишних оговорок.</p> Он никогда и не должен был этого делать, пишет в корпоративном блоге Мануэль Гейтц, главный аналитик … article