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=234748 Wed, 29 Apr 2026 16:50:50 +0300 <p>Разработчик экосистемы инфраструктурного ПО для Enterprise-бизнеса Orion soft выпустил масштабное обновление своего флагманского продукта по виртуализации zVirt 5.0. Решение перевели на новую минималистичную гипервизорную ОС собственной сборки, повысив его стабильность, производительность и безопасность. Также в zVirt добавили возможность живой миграции виртуальных машин между центрами данных, планировщик задач виртуальных машин по расписанию, усовершенствовали функциональность SDN.</p> <p>Крупнейшим обновлением в истории системы стал переход на новую гипервизорную платформу zVirt Node 2.0, специально разработанную под задачи системы виртуализации. Она собрана на базе менеджера пакетов RPM и отличается обновленным системным стеком, «облегченной» архитектурой и уменьшенным объемом кода. Новая платформа обеспечивает контроль над составом системы, версиями компонентов и процессом обновления.</p> <p>«В zVirt Node 2.0 мы оставили только те пакеты, которые необходимы непосредственно для работы виртуализации. Это легковесный гипервизор, который можно ставить прямо на „железо“, чтобы получить более стабильную и предсказуемую работу системы, адаптированную под задачи виртуализации. По такому же принципу VMware строила свой гипервизор ESXi. Кроме того, за счет уменьшенного объема кода повышается защищенность решения, так как сокращается площадь потенциальной атаки», — объяснил Максим Березин, директор по развитию бизнеса Orion soft.</p> <p>В релизе 5.0 также появилась значимая для работы крупных инфраструктур функция миграции виртуальных машин между различными центрами данных. Она работает даже в случае, когда у центров нет общего хранилища данных. Миграция доступна как в онлайн-режиме — до двух виртуальных машин одновременно, так и в офлайн-режиме — до 32 объектов одновременно. В результате этого обновления zVirt закрыла все возможные сценарии миграции виртуальных машин, которые раньше предоставляла VMware.</p> <p>В системе также доработали планировщик задач виртуальных машин по расписанию. Он позволяет автоматизировать рутинные операции, такие как запуск, выключение и перезагрузка виртуальных машин, создание и удаление снимков. Управление планированием происходит через понятный для администраторов веб-интерфейс Hosted Engine.</p> <p>В обновление 5.0 разработчик включил также дополнительные возможности SDN: балансировка трафика на уровнях L3-L4, поддержка протокола BGP для динамической маршрутизации, поддержка трансляции портов на логическом маршрутизаторе. Эти функции обеспечивают сокращение накладных расходов при обработке трафика, высокую отказоустойчивость, гибкость и доступность виртуальной сетевой инфраструктуры.</p> <p>Orion soft продолжает развивать zVirt как решение, которое закрывает комплекс инфраструктурных задач. В 2026 году у платформы появится собственный встроенный инструмент для резервного копирования и функциональность для работы с программно-определяемыми хранилищами (SDS), которая позволит строить гиперконвергентные инфраструктуры. Также разработчик выпустит zVirt Special Edition — сертифицированную ФСТЭК редакцию платформы, максимально приближенную по функциональности к коммерческой версии.</p> Разработчик экосистемы инфраструктурного ПО для Enterprise-бизнеса Orion soft выпустил масштабное обновление своего … message https://www.itweek.ru/themes/detail.php?ID=234747 Wed, 29 Apr 2026 16:47:23 +0300 <p>BSS и НТЦ АРГУС провели вебинар «Триединство технологий: Как AI-аналитика речи и WFM (система управления персоналом) создают идеальный контакт-центр нового поколения».</p> <p>Около 70 представителей контакт-центров собрались послушать, как эффективнее планировать работу с помощью ИИ-анализа и данных из системы управления персоналом. Об этом рассказали Product Owner системы Речевая Аналитика в БСС ИИ Анна Ивлева и Руководитель направления WFM CC в НТЦ АРГУС Никита Городчиков. </p> <p>НТЦ Аргус — ведущий разработчик системы управления персоналом, с которым BSS объединила технологии и создает единый комплекс оптимизации персонала.</p> <p>Эксперты обозначили новые ориентиры в клиентском сервисе и управлении персоналом — и рассказали, как связка речевой аналитики и WFM помогает их достичь. </p> <p>Так, технологии позволяют глубже понять потребности клиентов, выявить точки роста и определить, какие запросы нужно автоматизировать, а также выстроить график, который будет оптимальным и для оператора, и для контакт-центра. </p> <p>Спикеры продемонстрировали три примера, как использовать речевую аналитику и WFM-данные для повышения эффективности контакт-центра и благополучия сотрудников. </p> <p>Анализ коммуникаций покинувших компанию сотрудников показал: примерно за месяц до ухода поведение сотрудника меняется. В оценке учитываются речевые особенности — например, инсайт-режим выявил, что выгоревшие операторы чаще используют формулировки вроде «я просто оператор». Кроме того, анализируются данные WFM (график, стаж работы, опоздания) и показатели эффективности (AHT, процент тишины и другие).</p> <p>Исследование включало анализ данных WFM о формате работы и анализ речевых паттернов — например, изучались реакции оператора на негатив со стороны клиентов. Оказалось, что удаленные сотрудники более лояльны компании по сравнению с офисными коллегами.</p> <p>На основе метрик эффективности, уровня выгорания, удовлетворенности клиентов и данных WFM о графике работы сотрудника система может предсказать, сколько диалогов в месяц обработает конкретный оператор. Это помогает более точно планировать работу контакт-центра и распределять сотрудников по каналам с учетом их сильных сторон.</p> <p>При корректной постановке задачи и понимании бизнес-контекста инсайты можно получить всего за <nobr>10–15 минут.</nobr></p> <p>Участники активно обсуждали подходы к управлению персоналом и организации аналитических процессов. Так выяснилось, что одновременно речевую аналитику и WFM-систему использует лишь каждая шестая компания, а еще 40% пока планируют их внедрить. Более половины применяют хотя бы одну из систем, но при оценке выгорания многие по-прежнему опираются на HR-опросы и ручную аналитику. </p> BSS и НТЦ АРГУС провели вебинар «Триединство технологий: Как AI-аналитика речи и WFM (система управления персоналом … message https://www.itweek.ru/themes/detail.php?ID=234743 Wed, 29 Apr 2026 09:58:21 +0300 <p><em>Недавно мы опубликовали отчет «</em><em>Advocating</em> <em>For</em> <em>Revenue</em> <em>Enablement</em><em>: </em><em>A</em> <em>Practitioner</em><em>’</em><em>s</em> <em>Guide</em> <em>To</em> <em>Executive</em> <em>Communications</em><em>», основанный на знакомом разочаровании: команды по обеспечению бизнеса (</em><em>revenue</em> <em>enablement</em><em>) постоянно приносят пользу, но испытывают трудности с завоеванием устойчивого влияния на высшее руководство. Однако эта проблема не уникальна: один из ближайших функциональных партнеров уже справился с ней, пишет в корпоративном блоге Питер Остроу, вице-президент и главный аналитик </em><em>Forrester</em><em>.</em></p> <p>Десять лет назад ИТ-безопасность столкнулась с аналогичной проблемой. Эта работа была важной, глубоко оперативной и в значительной степени незаметной, если выполнялась хорошо. Команды безопасности привлекались к обсуждениям с руководством только после того, как что-то пошло не так, и это было далеко не весело. Изменилась не важность безопасности, а то, как соответствующие руководители научились отстаивать интересы этой функции на высоком ровне. Функция обеспечения бизнеса может извлечь уроки из этой эволюции.</p> <h3>Урок номер один: профилактика создает ценность, но не обеспечивает влияние</h3> <p>На ранних этапах команды безопасности фокусировались на действиях: устранение уязвимостей, мониторинг систем, предотвращение инцидентов. Все они были важны, но ни одно из них не было достаточно впечатляющим для руководителей, решающих, куда инвестировать дальше. Лидеры в области безопасности поняли, что одной лишь профилактики, хотя она и ценна, недостаточно для привлечения внимания руководства. Влияние службы безопасности проявилось только тогда, когда она начала переводить свою работу на язык, который был важен для руководителей: бизнес-риски, компромиссы и уязвимости: не «Сколько угроз было заблокировано?», а «Что произойдет, если мы не будем действовать?».</p> <p>Функция обеспечения бизнеса часто попадает в ту же ловушку. Эти команды демонстрируют реализованные программы, развернутый контент, пройденные сертификации или внедренные инструменты. Но, как показывают наши исследования, руководители не вознаграждают за объем; они реагируют на актуальность. Функция обеспечения бизнеса привлекает внимание, когда она связывает свою работу с результатами, за которые руководители уже несут ответственность, такими как продуктивность продавцов, риски выполнения, поведенческая стагнация, плохое управление изменениями и стоимость бездействия.</p> <h3>Урок номер два: зрелые функции балансируют между операционным совершенством и стратегическим прогнозированием</h3> <p>Современные лидеры в области ИТ-безопасности понимают важность баланса. Примерно 80% их усилий направлены на фундаментальные и превентивные задачи: поддержание стабильности систем, обеспечение соблюдения стандартов, снижение известных рисков. Эта работа является обязательной и необходимой. Но оставшиеся 20% — это то, что обеспечивает им место за столом переговоров. Они предвидят возникающие угрозы, консультируют по вопросам будущих инвестиций и помогают высшему руководству понимать риски, которые еще не отображаются на панели мониторинга. Влияние службы безопасности заключается не в более быстрой реакции, а в помощи бизнесу предвидеть будущие события.</p> <p>Функция обеспечения бизнеса уже преуспевает в этих фундаментальных 80%: адаптация новых сотрудников, постоянное привлечение новых сотрудников, укрепление навыков и выполнение программ. Возможность — и урок, извлеченный из опыта службы безопасности, — заключается в целенаправленном инвестировании в оставшиеся 20%. Это включает в себя прогнозирование изменений в поведении покупателей, подготовку продавцов к новым тенденциям до того, как их эффективность снизится, и консультирование руководителей о том, что потребуется для «хороших» продаж в следующем году. Функция обеспечения бизнеса не станет влиятельной, отказавшись от своей сервисной роли. Она обеспечит влияние, дополнив выполнение задач способностью к прогнозированию.</p> <h3>Урок номер три: поддержка приходит благодаря вкладу, а не благодаря видимости</h3> <p>Служба безопасности не приобрела значимость для руководителей, просто прося приглашать её на важные совещания. Она заслужила своё место, сделав руководителей более компетентными в принятии решений. Со временем CISO перешли от уведомления об инцидентах к консультированию по стратегии, помогая руководителям взвешивать скорость и риск, а также инновации и потенциальные риски.</p> <p>Функция обеспечения бизнеса сталкивается с тем же выбором. Ожидание ежеквартальных обзоров результатов или бюджетных циклов для обоснования проделанной работы редко способствует укреплению влияния. Как отмечается в нашем отчете, руководители, занимающиеся обеспечением бизнеса и вносящие свой вклад на более ранних этапах, представляя свои инсайты как исходные данные для планирования и принятия решений, переводят разговор с атрибуции на доверие. Как выразился Бен Пуртон, старший менеджер Zoom по развитию бизнеса в сфере выхода на международный рынок, «без атрибуции мы теряем прозрачность. А без прозрачности развитие бизнеса сокращается в трудные времена». Урок из сферы безопасности ясен: для продвижения нужно не просить о внимании, а быть полезными в процессе принятия решений.</p> <h3>Доверие руководства создаётся, а не запрашивается</h3> <p>Функции обеспечения бизнеса не обязательно превращаться в службу ИТ-безопасности, чтобы извлечь ее уроки. Однако эволюция безопасности предлагает мощный план действий: выйти за рамки обычной активности, сбалансировать профилактику с прогнозированием и вовлечь руководителей в обсуждение вопросов, которые им необходимо учитывать, чтобы не возникли проблемы.</p> <p>Путь вперед заключается не в усилении отчетности или расширении видимости. Он заключается в более четкой актуальности, основанной на результатах, согласованной с приоритетами руководства и ориентированной на помощь бизнесу в достижении успеха завтра, а не просто на объяснение того, что произошло вчера. Именно так зарабатываются влияние.</p> Недавно мы опубликовали отчет «Advocating For Revenue Enablement: A Practitioner’s Guide To Executive … article https://www.itweek.ru/themes/detail.php?ID=234741 Wed, 29 Apr 2026 09:49:53 +0300 <p>После ухода SAP с российского рынка перед компаниями встал вполне прагматичный вопрос: что делать с уже внедренными системами. Ожидания были понятны — быстрый переход на альтернативы, постепенный отказ от SAP. Но прошло почти четыре года, и реальность оказалась куда более сдержанной: массового перехода не случилось, и SAP по-прежнему остается ядром ключевых бизнес-процессов во многих компаниях.</p> <p>Это означает только одно — вопрос поддержки никуда не делся, более того, с каждым годом он становится все острее. Если в функциональной части специалистов на рынке еще достаточно, то в технической, базисной поддержке постепенно формируется дефицит, и именно эта часть сегодня начинает напрямую влиять на устойчивость системы.</p> <p>На первый взгляд все может выглядеть стабильно: пользователи работают, процессы идут, финансовые периоды закрываются, зарплата начисляется, товары отгружаются, закупки осуществляются — система жива. Но проблема SAP сегодня в том, что риски накапливаются не сразу, а постепенно, и часто остаются незаметными до первого серьезного сбоя. Это создает опасную иллюзию: кажется, что система работает нормально, хотя внутри уже формируется набор уязвимостей и ограничений, которые в какой-то момент проявятся одновременно.</p> <h3>Факторы, которые формируют риски</h3> <ul> <li><strong>Один из ключевых факторов — безопасность. </strong>SAP продолжает выявлять уязвимости как в HANA, так и в ABAP-коде, и даже изолированные системы не защищены полностью: внутренние утечки и атаки остаются реальной угрозой.</li> <li><strong>Второй фактор — обновления. </strong>Патчи продолжают выходить, но их получение и применение становятся отдельной нетривиальной и часто трудозатратной задачей, которую откладывают, чтобы не трогать «работающую» систему или из-за наличия более приоритетных задач. В результате в ней постепенно накапливаются слабые места.</li> <li><strong>Третий фактор — технический долг. </strong>Большинство SAP-систем развивались годами, и сегодня это сложные архитектуры с высоким уровнем интеграции и большим количеством взаимосвязей, где любое изменение может повлиять на десятки процессов и требует крайне трудозатратного тестирования.</li> </ul> <p>Отдельную нагрузку создают <strong>регулярные изменения в законодательстве</strong>. Если раньше значительную часть требований закрывал вендор, сейчас компании вынуждены самостоятельно адаптировать системы, что требует дополнительных ресурсов и повышает риск ошибок.</p> <p>На этом фоне многие компании начали оптимизировать расходы на поддержку SAP. Это выглядит логично, но на практике часто приводит к обратному эффекту: экономия увеличивает вероятность инцидентов. А любой серьезный сбой — это уже не локальная ИТ-проблема, а остановка бизнес-процессов с прямыми финансовыми последствиями.</p> <p>В этих условиях подход «и так работает» становится все более рискованным, потому что речь идет не о текущем состоянии системы, а о том, насколько она готова к следующему инциденту.</p> <p>Главный риск сегодня заключается не в том, что система перестанет работать, а в том, что она продолжит работать до момента, когда сбой окажется критическим.</p> <h3>Какие стратегии выбирают компании</h3> <p>После ухода SAP компании оказались в ситуации, где необходимо определить дальнейший путь: развивать систему, замораживать ее или постепенно заменять. Со временем стало понятно, что универсального решения нет, и каждая компания выстраивает свою стратегию в зависимости от бизнес-задач, ресурсов и уровня зрелости внутренней ИТ-организации. Тем не менее на практике сформировалось несколько типовых сценариев.</p> <ul> <li> <strong>Развитие. </strong>Несмотря на ограничения, многие компании продолжают дорабатывать систему, поскольку она глубоко интегрирована в бизнес-процессы, а полноценной замены часто нет. Однако здесь быстро возникает ограничение по ресурсам: внутренние команды перегружены, часть специалистов переключается на другие задачи, а объем работ, включая требования законодательства, только увеличивается. В результате развитие замедляется или почти останавливается, а технический долг продолжает расти.</li> <li> <strong>Удержание и оптимизация. </strong>В этом случае компании стараются не расширять систему, а максимально продлить срок ее жизни, контролируя расходы и инфраструктуру. На первый план выходят задачи, которые раньше воспринимались как второстепенные: управление объемом данных, архивирование и оптимизация производительности. При этом именно здесь часто скрывается значительный потенциал: грамотная работа с данными и использованием ресурсов позволяет снизить нагрузку на систему, сократить затраты и ускорить выполнение операций.</li> <li> <strong>Гибридная модель. </strong>Система остается ядром, но окружение постепенно заменяется: интеграционные решения, аналитика, отдельные функциональные блоки. Это позволяет снизить зависимость без резких изменений, но требует аккуратной работы с архитектурой и глубокого понимания всех взаимосвязей. При переходе к такой модели возникает ряд вопросов, не всегда очевидных на этапе планирования. Замена отдельных компонентов приводит к необходимости заново оценивать поведение всей архитектуры в условиях реальной нагрузки.</li> </ul> <p>Ключевой риск связан не столько с функциональностью новых решений, сколько с их работой в составе существующего ИТ-ландшафта. Выдержит ли новая система прежний объем операций? Как изменится время отклика? Как поведут себя смежные системы при одновременной нагрузке?</p> <p>В таких условиях снова становится актуальной практика комплексного нагрузочного и интеграционного тестирования с фокусом на сквозные процессы. Это позволяет воспроизвести реальные сценарии, оценить влияние каждого компонента и выявить узкие места до того, как они проявятся в эксплуатации.</p> <p>Отдельно стоит отметить, что независимо от выбранной стратегии, большинство компаний сталкивается с одной и той же проблемой — нехваткой опыта. Внутренние команды хорошо знают свою систему, но редко сталкиваются с большим количеством различных сценариев и инцидентов.</p> <p>При этом именно опыт и накопленная практика позволяют не только реагировать на проблемы, но и заранее выявлять их предпосылки, корректно оценивать поведение системы под нагрузкой и принимать решения без дополнительных рисков для бизнеса.</p> <p>Одна из самых распространенных ошибок — воспринимать поддержку лишь как процесс «закрытия заявок». В текущих условиях это уже полноценный инструмент управления рисками, от которого напрямую зависит стабильность бизнеса.</p> <p>Устойчивость системы определяется не столько выбранной стратегией, сколько глубиной экспертизы и способностью работать с ней в условиях постоянных изменений.</p> <h3>Когда система работает на пределе</h3> <p>Поддержка обычно воспринимается как стабильный процесс до тех пор, пока система не начинает работать на пределе. Именно в такие моменты становится видно, насколько критична способность быстро находить первопричины проблем, а не просто реагировать на их внешние проявления.</p> <p>На практике проблемы редко выглядят как классические аварии. Чаще это накопленные перегрузки, деградация производительности или сбои в отдельных бизнес-процессах, которые постепенно приводят к остановке системы.</p> <p>Несмотря на различный характер таких ситуаций — повышенное потребление ресурсов, снижение производительности или сбои в процессах, все они сводятся к одному фактору. Решающее значение имеет не тип инцидента, а способность быстро проанализировать поведение системы, выявить первопричину и устранить ее без дополнительных рисков для бизнеса.</p> <p>Именно здесь ключевую роль играет опыт работы с критическими системами, знание архитектуры и практика решения нестандартных задач в условиях ограниченного времени.</p> <h3>Поддержка как элемент устойчивости бизнеса</h3> <p>Сегодня поддержка — это уже не вспомогательный сервис, а инструмент обеспечения стабильности бизнеса на горизонте ближайших лет. Пока компании находятся в процессе выбора долгосрочной стратегии развития ИТ-ландшафта, система должна оставаться работоспособной и предсказуемой.</p> <p>Поэтому ключевой задачей становится не только реакция на инциденты, но и их предотвращение через анализ текущего состояния системы.</p> <p>#IMAGE_234742#</p> После ухода SAP с российского рынка перед компаниями встал вполне прагматичный вопрос: что делать с уже внедренными … article Артем Редьков, директор дирекции премиальных сервисов и поддержки “ТерраЛинк” https://www.itweek.ru/themes/detail.php?ID=234740 Tue, 28 Apr 2026 15:18:40 +0300 <p>Специализированный облачный провайдер mt cloud (компания Movetel) и Deckhouse, разработчик решений для enterprise-инфраструктуры, объявили о стратегическом партнерстве и запустили сервис KaaS (Kubernetes as a Service). В рамках сотрудничества клиентам становится доступна платформа Deckhouse Kubernetes Platform, развернутая на высокопроизводительной инфраструктуре провайдера по модели управляемого сервиса.</p> <p>Платформа позволяет компаниям значительно оптимизировать эксплуатацию контейнерных сред и автоматизировать ключевые процессы эксплуатации. В результате сокращается время подготовки инфраструктуры и сред разработки до 15 раз и обеспечивается целевой уровень доступности SLA 99,99%. </p> <p>Синергия технологий Deckhouse и экспертизы mt cloud направлена на переход к максимально автоматизированному управлению Kubernetes-кластерами. Решение позволяет сократить долю ручных операций и обеспечить высокий уровень автоматизации в управлении ИТ-системами.</p> <p>Новый сервис KaaS на базе Deckhouse Kubernetes Platform ориентирован на средний и крупный бизнес, которому требуется предсказуемое поведение инфраструктуры в условиях реальной эксплуатации. В отличие от типовых управляемых решений, платформа предлагает целостный подход: обновления, безопасность и администрирование автоматизированы на уровне системы. В результате внедрения у бизнеса можно снизить совокупную стоимость владения ИТ-активами более чем на 30% и автоматизировать до 80% рутинных операций по эксплуатации.</p> <p>Ключевым преимуществом партнерства является глубокая интеграция платформы с выделенной инфраструктурой mt cloud. Подобная синергия обеспечивает ряд уникальных возможностей для заказчиков:</p> <ul> <li>высокая производительность: использование NVMe-хранилищ и сети 25 Гбит/с в сочетании с программно-определяемой сетью VMware NSX-T для стабильной работы кластеров;</li> <li>георезервирование: архитектура распределена между двумя независимыми площадками Tier III, что гарантирует низкий показатель RTO и устойчивость к локальным сбоям;</li> <li>изоляция сред: возможность создания полностью обособленных контуров для устранения влияния посторонних нагрузок, что критично для высоконагруженных промышленных систем;</li> <li>гибридные сценарии: обеспечена поддержка интеграции с локальными мощностями заказчика и адаптация конфигураций под специфические задачи бизнеса.</li> </ul> <p>Применение KaaS на базе Deckhouse позволяет ускорить вывод продуктов на рынок в <nobr>2–15 раз.</nobr> Команды разработки получают возможность развернуть кластер примерно за 30 минут через инструменты самообслуживания. Для специалистов по информационной безопасности предусмотрена встроенная защита по умолчанию, включая централизованный аудит, сбор журналов событий и автоматическое применение политик. </p> <p>«Мы стремимся изменить сценарииуправления Kubernetes, переходя от ручной настройки и фрагментированного контроля к модели „автопилота“. Данное решение обеспечивает единый жизненный цикл кластера со сквозными обновлениями, что исключает конфликты компонентов. Подобный метод автоматизации позволяет командам разработки фокусироваться на написании кода приложений, а не на обслуживании системной среды. Совместно с mt cloud мы предоставляем рынку решение, где эксплуатационная сложность полностью скрыта под капотом автоматизации», — отметил Андрей Радыгин, руководитель направления «Облачное партнерство» Deckhouse компании «Флант».</p> <p>«Задача mt cloud — предоставить такую среду, в которой возможности Deckhouse раскрываются без ограничений типовых массовых облаков. За счёт экспертизы в построении инфраструктуры корпоративного уровня реализовано решение с гибкой настройкой сети, ресурсов и изоляции сред под конкретные задачи. Это позволяет использовать Kubernetes в составе сложных инфраструктурных сценариев, включая высоконагруженные системы, гибридные архитектуры и интеграцию с on-prem решениями. Такая модель даёт бизнесу управляемый Kubernetes, адаптированный под реальные требования инфраструктуры и особенности задач», — прокомментировал Тимур Чубарин, генеральный директор mt cloud.</p> Специализированный облачный провайдер mt cloud (компания Movetel) и Deckhouse, разработчик решений для … message https://www.itweek.ru/themes/detail.php?ID=234738 Tue, 28 Apr 2026 10:05:03 +0300 <p><em>Новый <a href="https://www.datadoghq.com/state-of-ai-engineering/">отчет</a> Datadog «2026</em> <em>State</em> <em>of</em> <em>AI</em> <em>Engineering</em><em>» указывает на измеримую проблему сбоев в корпоративных системах искусственного интеллекта. Примерно 1 из 20 запросов уже завершается с ошибкой в ​​производственной среде, однако системы продолжают работать и возвращать результаты, которые кажутся правильными, что затрудняет обнаружение этих сбоев. 5% сбоев в производственной среде ИИ — это, по инженерным стандартам, очень высокий показатель, сообщает портал Bigdatawire.</em></p> <p>Наряду с ростом числа сбоев, в отчете также подчеркивается растущая сложность и нестабильность производственных сред. Речь идет не о сбоях систем, а о том, что системы продолжают работать, становясь при этом менее достоверными.</p> <p>В отчете особенно бросается в глаза столкновение одновременно нескольких тенденций. Использование ИИ быстро переходит в производство, частота сбоев начинает проявляться все более отчетливо, а проектирование систем становится все более сложным, поскольку команды объединяют несколько моделей, источников данных и инструментов в единый конвейер. Datadog отмечает, что около 70% организаций уже используют три или более моделей в производственной среде, что добавляет еще один уровень координации.</p> <p>В некоторых случаях поверх добавляются рабочие процессы на основе агентов, что вносит еще большую вариативность. Каждый из этих слоев расширяет возможности, но также увеличивает вероятность того, что что-то пойдет не так, не будучи сразу видимым, и именно здесь начинает проявляться проблема «тихих сбоев».</p> <p>«ИИ начинает очень напоминать ранние дни облачных технологий, — говорит Яньбин Ли, директор Datadog по продуктам. — Облако сделало системы программируемыми, но гораздо более сложными в управлении. Теперь ИИ делает то же самое с уровнем приложений. Компании, которые добьются успеха, будут не просто создавать лучшие модели — они будут строить вокруг них операционный контроль. В эту новую эпоху наблюдаемость ИИ становится такой же важной, как наблюдаемость облачных технологий десять лет назад».</p> <p>Что делает эти выводы еще более значимыми, так это источник данных. Datadog не проводит опросы разработчиков и не собирает мнения. Компания анализирует телеметрию производственных процессов тысяч компаний, использующих системы ИИ в режиме реального времени. Это включает в себя растущее число сред на основе агентов, где модели не просто генерируют выходные данные, но и управляют многоэтапными рабочими процессами.</p> <p>В отчете указывается, что основной преградой на пути надежного масштабирования ИИ является операционная сложность, поскольку большинство организаций уже используют несколько моделей в производственной среде. По мере расширения этих систем задача состоит уже не в том, чтобы заставить их работать, а в том, чтобы сделать их понятными и управляемыми после развертывания.</p> <p>«Следующая волна сбоев агентов будет связана не с тем, что агенты не могут делать, а с тем, что команды не могут наблюдать, — говорит Гильермо Раух, генеральный директор компании Vercel, стоящей за Next.js и ведущей платформой для создания веб-приложений на основе ИИ. — Агентам необходимы те же циклы обратной связи в производственной среде, что и отличному ПО. В отличие от традиционного ПО, управление потоком данных в агентах осуществляется самой большой языковой моделью (LLM), что делает наблюдаемость не просто полезной, но и необходимой».</p> <p>Еще одна закономерность, обнаруженная исследователями, заключается в том, что многие из этих сбоев вызваны не качеством модели, а ограничениями инфраструктуры. Большая часть ошибок связана с ограничениями скорости запросов, и миллионы таких событий регистрируются в производственных системах. По мере роста использования системы все чаще достигают пределов пропускной способности провайдера, что приводит к всплескам сбоев, которые трудно предсказать. На практике надежность определяется не только тем, насколько хорошо работает модель, но и тем, как команды управляют нагрузкой, повторными попытками и параллельным выполнением задач.</p> <p>Согласно отчету Datadog, контролировать затраты и задержку становится все сложнее. Использование токенов увеличилось более чем вдвое для типичных рабочих нагрузок и еще больше для сценариев с высокой интенсивностью использования. Причиной этого роста является не только пользовательский ввод, но и расширяющийся слой системных промптов, политик и инструкций инструментов, которые многократно обрабатываются в каждом запросе. Эти фоновые токены теперь составляют значительную долю общего использования, а это значит, что затраты могут расти даже тогда, когда спрос пользователей кажется стабильным.</p> <p>Несмотря на все эти аспекты, основные преимущества в плане эффективности часто упускаются. В отчете показано, что кэширование промптов по-прежнему используется недостаточно, и большинство систем повторно обрабатывают один и тот же контекст между вызовами. Это указывает на разрыв между тем, как создаются системы ИИ, и тем, как они оптимизируются в производственной среде. По мере расширения контекстных окон и увеличения объема промптов задача смещается от насыщения модели бóльшим количеством данных к определению того, какая информация действительно имеет значение.</p> Новый отчет Datadog «2026 State of AI Engineering» указывает на измеримую проблему сбоев в корпоративных … article https://www.itweek.ru/themes/detail.php?ID=234736 Tue, 28 Apr 2026 09:45:59 +0300 <p><em>Компании вкладываются в нейросети, запускают пилоты, получают первые результаты, но вместо роста производительности — бесконечная доводка скриптов, вместо масштабирования — сломанные пайплайны и разочарованные команды. Рассмотрим, почему так происходит и как превратить ИИ из игрушки в рабочий инструмент.</em></p> <h3>Разрыв между пилотами и реальной пользой</h3> <p>Сегодня подавляющее большинство российских компаний уже <a href="https://ufa.plus.rbc.ru/news/69721e0e7a8aa9bcd48b0d54">работает</a> с ИИ, но формализованную стратегию <a href="https://www.cnews.ru/news/line/2026-03-03_97_krupnyh_rossijskih_kompanij">имеет</a> лишь четверть — разрыв между пилотными проектами и промышленным масштабированием остается ключевой сложностью. GenAI-зрелость <a href="https://www.finmarket.ru/main/article/6584687">оценивается</a> всего на 2,0 из 5, а главным барьером становится не бюджет, а сопротивление изменениям. Компании всё чаще отказываются от стратегии «собери сам» в пользу готовых инфраструктурных решений.</p> <p>Разбираемся, как превратить нейросети в работающий бизнес-инструмент и в чем могут помочь такие сервисы ИИ-платформы.</p> <h3>Почему «собери сам» — это ловушка для бизнеса</h3> <p>Когда компания решает внедрить ИИ, первое желание — взять всё под контроль и собрать решение самостоятельно. Типичный путь выглядит обнадеживающе просто: взяли мощности в аренду, подняли модель, прикрутили поиск по внутренней базе знаний. А потом всё падает под нагрузкой. Запросы начинают виснуть, модель забывает контекст после третьего сообщения, а на пике тестирования система просто умирает.</p> <p>Проблема в том, что самые сложные вопросы не видны на старте. Как управлять несколькими моделями сразу, когда одна считает быстрее, а вторая точнее? Как сохранять историю настроек, если бизнес-логика меняется каждый спринт? Как отслеживать, что ответы модели не начали «плыть», когда вчера она отвечала на вопрос «да», а сегодня — «нет» без видимых причин? И главное — как при этом не раскрыть конфиденциальные данные в процессе работы поиска по документам? На каждый такой вопрос Open Source-сообщество предлагает по три библиотеки. Однако склеить их в единую работающую систему, которая не рассыплется в первый же рабочий день — это задача для вендора или исследовательской лаборатории, а не для ИТ-отдела бизнес-компании.</p> <p>В результате продакшн-инженеры отвлекаются от своих прямых задач, подход к управлению ИИ-пайплайнами распадается на набор скриптов-героев, а документация размазана по пяти репозиториям и чату в Телеграме. Команды, которые пробуют собрать этот стек из открытых компонентов вручную, обычно заканчивают одинаково: либо через месяц бросают, либо получают конструкцию, которая работает не всегда. Это путь для тех, кто продает платформы, или для исследователей, которым интересно разбираться в этом. Для бизнеса, которому нужен предсказуемый результат, работающая система и контроль над данными, это почти всегда ловушка.</p> <h3>Что дает ИИ-платформа: от мощностей до готового программного интерфейса за один шаг</h3> <p>Хорошая платформа — это не просто «аренда железа». Это среда, где вся сложность уже упакована в готовый продукт. Вы получаете не разрозненные компоненты, которые нужно клеить руками, а единое пространство, где модели, данные и вычислительные мощности работают как часы. В такую платформу обычно входит аренда серверов с ускорителями вычислений, готовый доступ к моделям через программный интерфейс, визуальные инструменты для сборки пайплайнов без кода, а также вся сопутствующая инфраструктура: хранилища, очереди задач, конструкторы чат-ботов. Всё это позволяет не тратить месяцы на настройку и написание однотипного кода, а сосредоточиться на том, ради чего всё затевалось — на бизнес-логике и пользовательских сценариях.</p> <p>Чем платформа отличается от голой аренды вычислительных мощностей? Тем, что не нужно думать о том, как масштабировать модель при растущем потоке запросов, версионировать настройки вручную, балансировать нагрузку между несколькими экземплярами — всё это уже сделано. Вы просто загружаете данные, настраиваете сценарий в визуальном интерфейсе или через API и получаете работающее решение. Для компании с высокими требованиями к безопасности данных — это критически важно: информация никуда не уходит за пределы вашего контура. А для команды без штатных специалистов по машинному обучения — это возможность запустить проект не за квартал, а за неделю.</p> <p>И вот здесь как раз нужна не просто «аренда железа», а платформа, где всё уже собрано в одном месте. Такие платформы превращают ИИ в работающий инструмент.</p> <h3>Как перейти от пилота к продукту: три шага</h3> <p>Платформа сама по себе не решает бизнес-задачу. Она убирает технические барьеры, чтобы команда могла сосредоточиться на главном — на сценариях, которые приносят пользу. Вот как выглядит путь от идеи до работающего инструмента.</p> <p><strong>Шаг первый: выбрать сценарий, который уже работает у других.</strong> Не нужно изобретать велосипед. Поиск по внутренним документам с персональными данными, помощник для первой линии техподдержки, генерация и проверка документов по внутренним правилам — всё это задачи, которые команды уже решают с помощью ИИ. Вы выбираете то, что болит именно у вас. Например, отдел поддержки тонет в однотипных вопросах, а старшие специалисты отвлекаются от сложных задач. Значит, начинаем с автоматизации ответов на частые запросы.</p> <p><strong>Шаг второй: собрать пайплайн в визуальной среде без программирования.</strong> Вы берете готовую модель из каталога платформы — их уже настроили до вас. Подключаете внутреннее хранилище с документами: инструкциями, историями тикетов, регламентами. Настраиваете механизм поиска по этим документам через простой визуальный интерфейс — указываете, откуда брать данные, как их резать на куски, как подавать в модель. И получаете готовый программный интерфейс через пару дней.</p> <p><strong>Шаг третий: обеспечить безопасность и контроль.</strong> Данные не покидают ваш доверенный периметр — это главное требование для компаний с чувствительной информацией. Все компоненты работают внутри изолированного облачного контура, который соответствует требованиям регуляторов. Также необходимо настроить процесс поставки обновлений в продуктовую среду.</p> <p>Так, разрыв между «поиграли с промптами в ChatGPT» и «у нас работает автоматическая проверка договоров» преодолевается не магией и не наймом большого количества специалистов, а правильной инфраструктурой, где сложность уже спрятана, а бизнес-сценарий становится главным героем. ИИ-платформа — это именно такая инфраструктура.</p> <p>#IMAGE_234737#</p> Компании вкладываются в нейросети, запускают пилоты, получают первые результаты, но вместо роста … article Евгений Мартынов, директор по информационным технологиям Рег.облака https://www.itweek.ru/themes/detail.php?ID=234731 Mon, 27 Apr 2026 15:56:15 +0300 <p>Компания CURATOR, специализирующаяся на обеспечении доступности интернет-ресурсов и нейтрализации DDoS-атак, подвела итоги первого квартала 2026 года. По данным инфраструктуры защиты компании, наблюдается устойчивый рост интенсивности, сложности и географического охвата кибератак.</p> <p>Распределение атак по отраслям в первом квартале 2026 года остаётся устойчивым: почти три четверти всех инцидентов приходится на финтех (44,2%), ИТ и телеком (19,3%) и онлайн-ставки (10,0%). В детальной разбивке лидируют банки (22,8%), платёжные системы (15,9%) и онлайн-букмекеры (10,0%).</p> <p>Сегмент онлайн-ставок заслуживает отдельного внимания: помимо роста общего числа инцидентов, именно здесь были зафиксированы самая интенсивная и самая продолжительная DDoS-атака квартала.</p> <p>Если ещё год назад атаки терабитного класса были единичным явлением (так в первом квартале 2025 года CURATOR не фиксировала ни одной атаки интенсивностью свыше 1 Тбит/с), то в первом квартале 2026 года подобных атак уже отмечено четыре. Наиболее показательный случай — атака на компанию из сегмента онлайн-ставок в середине марта, её пиковая мощность превысила 2 Тбит/с, а высокоинтенсивная фаза продолжалась свыше 40 минут — нетипично долго для атак такого масштаба. За это время наблюдалось 11 всплесков, при этом атакующие пытались адаптировать тактику в режиме реального времени и поддерживать длительное давление на инфраструктуру. Атака была нейтрализована без ущерба для доступности сервиса.</p> <p>Одновременно усложняется структура атак: доля мультивекторных инцидентов выросла с 8,0% до 10,7%, а доля атак, одновременно задействующих сетевой уровень и уровень приложений, увеличилась с 3,6% до 6,2%.</p> <p>Еще один из наиболее тревожных трендов квартала — стремительный рост крупнейшего DDoS-ботнета, за которым CURATOR ведёт наблюдение с марта 2025 года. За год его размер увеличился более чем в десять раз: с 1,33 млн до 13,5 млн заражённых устройств.</p> <p>Принципиально изменилась и география ботнета. Если год назад в нём преобладали устройства из Бразилии (51,1%), то сейчас первое место занимают США (16,0%). За ними следуют Бразилия (13,6%), Индия (6,5%), Великобритания (4,8%) и Турция (3,2%). Операторы ботнета не только активно расширяют его за счёт новых заражённых устройств, но и диверсифицируют географию. В результате простые геоблокировки становятся неэффективными: атакующие могут в любой момент использовать IP-адреса из разных стран.</p> <p>Среднемесячный объём заблокированных запросов вредоносных ботов в первом квартале 2026 года составил 2,5 млрд — на 40% больше, чем в аналогичном периоде прошлого года.</p> <p>Традиционные лидеры по объёму бот-атак — электронная коммерция (40,2%) и онлайн-ставки (27,1%) — сохраняют свои позиции. Однако заметно новым явлением стал сегмент транспорта и логистики: он вышел на третье место по общему объёму бот-активности, а доля вредоносных запросов в его трафике достигла 19,17% — то есть практически каждый пятый запрос к ресурсам этого сегмента исходил от ботов.</p> <p>Самая продолжительная бот-атака в 1 квартале 2026 года длилась более двух недель и сгенерировала свыше 178 млн вредоносных запросов на ресурсы компании из сегмента электронной коммерции.</p> <p>«К сожалению, терабитные атаки на наших глазах становятся обычной практикой — только в первом квартале этого года на своей инфраструктуре мы зафиксировали несколько таких случаев. Картина такова: крупный ботнет за год увеличился на порядок, атаки стали продолжительнее и сложнее. В таких условиях вопрос уже не в том, случится ли инцидент, а в том, как быстро бизнес сможет его пережить без остановки операций. Киберустойчивость — это не альтернатива защите, это её логичное продолжение, и мы видим, что способность работать даже в момент атаки становится для бизнеса не опцией, а условием выживания», — отметил Дмитрий Ткачев, генеральный директор CURATOR.</p> <p>Подробная иллюстрированная информация со статистикой по DDoS-атакам, активности вредоносных ботов и сбоям в маршрутизации BGP за январь—март 2026 года приведена в отчете CURATOR, ознакомиться с ним можно на сайте компании.</p> Компания CURATOR, специализирующаяся на обеспечении доступности интернет-ресурсов и нейтрализации DDoS-атак, подвела … message https://www.itweek.ru/themes/detail.php?ID=234730 Mon, 27 Apr 2026 15:53:56 +0300 <p>В экосистеме мобильных решений ГК «Электронные Офисные Системы» — очередное обновление. Новая версия кроссплатформенного приложения EOSmobile 4.16 сделает вашу работу с документами и задачами в СЭД комфортнее и быстрее. В новой версии сделано множество улучшений для удобства пользователей EOSmobile на смартфонах, стало больше настроек для адаптации под ваши текущие задачи и привычки. Доработаны ранее реализованные функции, процессы, элементы интерфейса, добавлены новые возможности.</p> <p>Ключевые изменения:</p> <ul> <li>работа с PDF стала удобнее. Теперь можно копировать текст, переходить по ссылкам в документе одним кликом и увеличивать масштаб при просмотре файла до 800%, чтобы прочитать даже самый мелкий шрифт;</li> <li>улучшено управление функционалом ЭП. Появилась возможность загружать сертификаты напрямую с устройства, получать лицензии КриптоПро из СМР (Сервер Мобильных Решений) и использовать простую электронную подпись;</li> <li>доработаны навигация и интерфейс. Пользователям приложения на смартфонах стало проще взаимодействовать с диалоговыми окнами, календарями и кнопками операций. Обновлены окна выбора дат, исполнителей и контролеров поручений. Новые настройки отображения папок и размера текста делают повседневную работу удобнее, сохраняют ваше зрение, экономят время, страхуют от ошибок и потерь важной информации.</li> </ul> <p>EOSmobile 4.16 совместимо с СМР 4.10. Совместимость с более ранними версиями СМР не гарантируется. Поддерживаемые версии СЭД ДЕЛО — 24.3, 25.3, версии операционных систем Android 11 — 16.х, Aurora от 5.1.0, Windows 10.х или 11.х, iOS/iPadOS 16.2 — 26.x. Приложение кроссплатформенное, функционал и интерфейс для всех поддерживаемых ОС практически идентичны.</p> <p>Подписывайте и аннотируйте документы, утверждайте отчеты, создавайте резолюции и управляйте поручениями везде, где бы вы ни находились: в дороге, в командировке, в офисе заказчика, на выездном совещании, дома. Приложение работает как онлайн, так и в автономном режиме. Вы не выпадаете из текущих дел и задач даже при отсутствии стабильного интернета или оффлайн.</p> <p>Для использования 100% новых возможностей EOSmobile 4.16 необходимо обновить СМР до версии 4.10. </p> В экосистеме мобильных решений ГК «Электронные Офисные Системы» — очередное обновление. Новая версия … message https://www.itweek.ru/themes/detail.php?ID=234729 Mon, 27 Apr 2026 15:52:19 +0300 <p>Технологическая компания YADRO (входит в ИКС Холдинг) вывела на рынок оптимизированные версии систем хранения данных TATLIN.AFA и TATLIN.BACKUP. Новое предложение позволяет снизить стоимость хранения данных без снижения ключевых эксплуатационных параметров СХД.</p> <p>Представленные конфигурации стали ответом на глобальное удорожание и снижение доступности компонентов для серверов и СХД. Главные причины увеличения их стоимости — рыночная турбулентность, ограничения логистики, таможенные и санкционные барьеры, а также резкий рост спроса из-за глобального развития ИИ.</p> <p>В этих условиях бизнесу необходимо одновременно решать две задачи: обновлять и масштабировать ИТ-инфраструктуру и при этом сохранять инвестиции в разумных пределах. Новые версии TATLIN.AFA и TATLIN.BACKUP расширяют возможности выбора конфигурации под прикладные сценарии и бюджет заказчика.</p> <p>Оптимизированная конфигурация TATLIN.AFA с объемом оперативной памяти 1 ТБ не уступает по производительности флагманской версии с 2 ТБ и в то же время более доступна по стоимости. При этом обе модификации получат полный функционал релизов программного обеспечения версий 4.0 и 4.1, включая поддержку ожидаемых технологий онлайн-компрессии данных и асинхронной репликации, поддержку NVMe и RoCE, а также другие полезные возможности.</p> <p>Новая конфигурация позволит заметно сократить первоначальные вложения в решение. При этом флагманская версия TATLIN.AFA с 2 ТБ оперативной памяти сохраняет преимущества в сценариях, где особенно важны более высокие коэффициенты дедупликации: максимальный объем кэш-памяти обеспечивает больший потенциал системы в таких задачах.</p> <p>Также YADRO представляет обновленную конфигурацию специализированной системы резервного копирования TATLIN.BACKUP с 1,5 ТБ оперативной памяти. За счет программных доработок новая версия сопоставима по производительности с конфигурацией на 2 ТБ в малых системах с полезной емкостью до 380 ТБ. При дальнейшем увеличении дисковой емкости и расширении функциональных возможностей системы рекомендуется перейти на классическую флагманскую конфигурацию с объемом оперативной памяти 2 ТБ.</p> <p>Следующим шагом в повышении эффективности СХД станет выпуск технологии компрессии данных для TATLIN.AFA и TATLIN.UNIFIED. Это решение позволит ещё более эффективно использовать полезную емкость систем и дополнительно снизить стоимость хранения данных. Функциональность находится на финальной стадии разработки и войдет в релиз программного обеспечения TATLIN 4.1. Уже сейчас технологию можно протестировать на реальных данных с помощью эмулятора, доступного по запросу через коммерческих представителей компании.</p> <p>Представляя новые решения, Егор Литвинов, директор продуктового направления TATLIN компании YADRO, отметил: «Мы видим, что для заказчиков все более приоритетными становятся стабильность поставок и обслуживания, а также баланс между производительностью и экономической целесообразностью. Компания YADRO заранее сформировала запас комплектующих и ключевых компонентов для систем хранения данных на 2026 год и часть 2027 года. Это позволяет отгружать оборудование в сроки, не зависящие от текущей рыночной ситуации. Собственный штат инженеров и склад запчастей обеспечивают непрерывность работы инфраструктуры заказчиков, а локальные разработка и производство позволяют контролировать себестоимость решений еще на этапе их создания. Это дает нам возможность удерживать цены на рыночном уровне и предлагать заказчикам максимально гибкие конфигурации».</p> <p>Ознакомиться с системами хранения данных TATLIN, подать заявку на демонстрационное тестирование и получить рекомендации экспертов можно на сайте YADRO.</p> Технологическая компания YADRO (входит в ИКС Холдинг) вывела на рынок оптимизированные версии систем хранения данных … message https://www.itweek.ru/themes/detail.php?ID=234728 Mon, 27 Apr 2026 15:48:53 +0300 <p>Компания «Хи-Квадрат» представила обновленный автономный REST API сервер XDAC (XSQUARE-DAC). В версии 6.0 добавлена поддержка Yandex Database и <nobr>DML-операций</nobr> для всех баз данных, а также реализована роль Database Reverse Proxy Server, улучшена производительность и исправлен ряд ошибок. Полный список изменений размещен на сайте компании.</p> <p>XSQUARE-DAC автоматизирует процесс создания REST API, предоставляя доступ к хранимым процедурам и функциям на стороне PostgreSQL. Решение поддерживает все системы управления базами данных (СУБД) и ориентировано в первую очередь на организации, которым хотят открыть доступ к корпоративным данным для внешних систем, мобильных приложений или внутренних сервисов без разработки отдельного серверного приложения.</p> <p><nobr>DML-операции</nobr> доступны для всех баз данных, с которыми работает XDAC. Теперь через REST API пользователи могут выполнять не только вызовы хранимых процедур и функций, но и прямые операции с данными: вставку, обновление, удаление и выборку записей.</p> <p>Помимо расширения типов запросов, добавлена возможность сопоставления URL-роутинга и конфигураций баз данных. Это позволяет использовать один экземпляр XDAC для работы с несколькими СУБД одновременно и превращает его в единую точку маршрутизации запросов к базам данных.</p> <p>В обновлении также исправлены ошибки при вызове процедур и функций для MSSQL и Oracle. Для операции SELECT реализована выгрузка больших объемов данных в форматах JSON и CSV — миллионы строк и до тысячи столбцов без предварительной загрузки всего результата в память.</p> <p>XDAC требует минимальных ресурсов для работы — 15 МБ оперативной памяти для обслуживания 10 HTTP-клиентов и 100 МБ для 1000 клиентов. Создание простого сервиса для получения данных по клиенту занимает около 10 минут. Для обеспечения высокой производительности используется прогретый пул соединений. Решение поддерживает все распространенные архитектуры процессоров — x86, ARM, «Эльбрус» (e2k) и LoongArch.</p> <p>«Первоначально мы создавали этот продукт как отдельный инструмент для компаний, которые намерены предоставить оперативный доступ к данным, но не хотят выстраивать для этого отдельный слой разработки. В шестой версии мы развили эту логику, поскольку добавили возможности, которые раньше требовали дополнительного кода. И это полностью отвечает актуальным потребностям бизнеса — получить результат, задействуя минимально возможные ресурсы», — отметил технический директор компании «Хи-Квадрат» Константин Ващенков.</p> Компания «Хи-Квадрат» представила обновленный автономный REST API сервер XDAC (XSQUARE-DAC). В версии 6.0 добавлена … message https://www.itweek.ru/themes/detail.php?ID=234727 Mon, 27 Apr 2026 15:48:03 +0300 <p>Вопрос защиты ПДн не сходит с повестки дня, из компаний продолжают утекать персональные данные. Санкции за это заметно выросли с мая 2025 года. Но пока рынок адаптируется к новым правилам и суды не назначали огромных штрафов. Однако уже во второй половине 2026 года все может измениться.</p> <p>Компания ARinteg представила еще одну свою разработку «Мастер ПДн» — решение, которое полностью закрывает организационные требования <nobr>152-ФЗ</nobr> и подзаконных актов, работая с любой системой кадрового учета. Разработка призвана облегчить учёт процессов обработки персональных данных (ПДн), снизить риски утечек ПДн и, как следствие, избежать штрафов до 500 млн руб, которые предполагаются за халатное отношение к требованиям регуляторов.</p> <p>«Мастер ПДн предназначен для разработки документов, необходимых при обработке персональных данных. В нем построение структуры документов отталкивается от процессов обработки персональных данных как того требует Роскомнадзор, и в этом основное преимущество нашего решения, — рассказал заместитель технического директора по консалтингу и аудиту ARinteg Олег Нестеровский. — Проверки регуляторов уже идут. Компаниям важно сформировать доказательную базу в подтверждение того, что она предприняла все возложенные на нее законом меры по защите ПДн, и мы ее даем».</p> <p> У ARinteg уже есть решение — Модуль УПДн, совместимый с «1С: ЗУП».</p> <p>Новый продукт Мастер ПДн — его полноценный апгрейд, который:</p> <ul> <li>автоматически формирует номенклатуру согласий для каждого субъекта ПДн, исходя из целей обработки;</li> <li>генерирует набор согласий для каждого сотрудника с учётом его должностного регламента (согласие на обработку, передачу, распространение);</li> <li>позволяет получить готовые к утверждению организационно-распорядительные документы (ОРД) с учетом последних изменений в законодательстве.</li> </ul> <p>Основные возможности Мастера ПДн включают учет процессов обработки ПДн, ведение и создание перечня обрабатываемых ПДн, определение уровней защищенности ИСПДн и ведение ОРД по обработке и защите таких данных.</p> <p>Решение сокращает время подготовки регламентной документации для работы с персональными данными до 90%. С «Мастер ПДн» организации перестают тратить ресурсы юристов и кадровиков на рутину. С этим решением компания документарно на 100% готова к проверке регуляторов. </p> Вопрос защиты ПДн не сходит с повестки дня, из компаний продолжают утекать персональные данные. Санкции … message https://www.itweek.ru/themes/detail.php?ID=234724 Mon, 27 Apr 2026 09:59:24 +0300 <p><em>В новом <a href="https://www.capgemini.com/wp-content/uploads/2026/04/CRI_Physical-AI-Report-Final-web-version.pdf">отчете</a> «</em><em>Physical</em> <em>AI</em><em>: </em><em>Taking</em> <em>human</em><em>-</em><em>robot</em> <em>collaboration</em> <em>to</em> <em>the</em> <em>next</em> <em>level</em><em>» </em><em>французской ИТ-консалтинговой компании Capgemini говорится, что предприятия быстро переходят от экспериментов к внедрению физического искусственного интеллекта — технологии, которая наделяет машины более человекоподобными способностями к восприятию и рассуждению, сообщает портал </em><em>AI</em> <em>Business</em><em>.</em></p> <p>После многих лет инноваций физический ИИ вступает в более практическую фазу, поскольку быстрые темпы развития ИИ делают масштабирование проектов более осуществимым.</p> <p>В отчете, основанном на опросе 1678 руководителей из 16 стран, говорится, что подавляющее большинство респондентов (80%) уже используют физический ИИ в той или иной форме, хотя только 4% заявили, что он работает в полномасштабном режиме.</p> <p> #IMAGE_234725#</p> <p>Этот разрыв между интересом и внедрением подчеркивает давнюю проблему в развертывании робототехники, поскольку быстрое развитие технологий часто опережает способность компаний интегрировать их.</p> <p>Однако в отчете утверждается, что барьеры для широкомасштабного внедрения снижаются благодаря улучшению базовых моделей, инструментам моделирования, сокращающим циклы обучения, снижению стоимости оборудования и достижениям в области периферийных вычислений.</p> <p>Кроме того, в Европе и США ускоряются процессы реиндустриализации, что одновременно приводит к росту инвестиций в физический ИИ. Действительно, две трети организаций теперь считают физический ИИ приоритетной задачей в своей программе автоматизации на следующие три-пять лет.</p> <p>Более половины бизнес-руководителей назвали автономные мобильные роботы, промышленные роботизированные манипуляторы и коллаборативные роботы (коботы) самыми быстрорастущими сегментами — значительно опережающими гуманоидов. Хотя коботы привлекают все больше внимания СМИ и вызывают ажиотаж, техническая незрелость, стоимость и проблемы с обучением остаются препятствиями для внедрения этой технологии.</p> <p>Нехватка рабочей силы также играет свою роль. В отчете отмечается, что основной причиной инвестиций в физический ИИ является не столько стоимость, сколько трудности с поиском работников, особенно в отраслях с ручным трудом, таких как сельское хозяйство, складское хозяйство и логистика.</p> <p>«Робототехника имеет долгую историю завышенных обещаний, поскольку ранние прорывы создавали ожидания, которым технология еще не могла соответствовать, — говорит Паскаль Бриер, директор Capgemini по инновациям. — Сегодня ситуация меняется не из-за ажиотажа, а из-за конвергенции ИИ, данных и инженерной зрелости».</p> <p>Хотя две трети руководителей заявили, что ожидают масштабирования физического ИИ в течение следующих пяти лет, путь к этому не будет простым. Проблемы интеграции, неясная рентабельность инвестиций и вопросы общественного принятия (особенно в отношении человекоподобных роботов) остаются серьезными препятствиями.</p> <p>«Возможность реальна, при условии, что мы сосредоточимся на том, что работает в масштабе, — отмечает Бриер. — Ответственное, безопасное и постепенное внедрение физического ИИ будет иметь важное значение для построения доверия, при этом в основе устойчивого сотрудничества человека и робота будут лежать безопасность, заложенная на этапе проектирования, прозрачность и человеческий контроль».</p> В новом отчете «Physical AI: Taking human-robot collaboration to the next level» французской ИТ-консалтинговой компании … article https://www.itweek.ru/themes/detail.php?ID=234723 Mon, 27 Apr 2026 09:54:38 +0300 <p><em>Разработанный десять дет назад современный стек данных не был построен неправильно. Он был создан для решения проблемы, существовавшей в то время, пишет на портале Big</em><em>D</em><em>ata</em><em>W</em><em>ire Сохам Мазумдар, соучредитель и генеральный директор WisdomAI.</em></p> <p>Недавно я был на встрече с вице-президентом по данным в компании среднего размера, и то, что она сказала, заставило меня задуматься. Мы обсуждали квартальный план ее команды, и она сделала паузу и сказала, почти про себя: «У нас конвейеры обработки данных работают быстрее, чем когда-либо, но почему-то на принятие решений все равно уходит неделя». Она не была расстроена своей командой. Она просто размышляла вслух о том, что не совсем сходилось.</p> <p>Я часто веду подобные разговоры. Инфраструктура данных улучшилась. Скорость принятия решений — нет. И чем больше времени я провожу на предприятиях, тем очевиднее становится причина. Современный стек никогда не предназначался для поддержки принятия решений. Он был разработан для хранения и перемещения данных, но в какой-то момент все предположили, что остальное уладится само собой.</p> <p>Этого не произошло.</p> <p>Та архитектура имела смысл. Пока это не изменилось.</p> <p>Современная архитектура обработки данных не была построена неправильно. Она была создана для решения проблемы, существовавшей десять лет назад — централизации. Данные существовали в разных операционных системах, в журналах, и аналитики могли их надежно запрашивать. Каждый уровень стека отражает эту цель, от сбора данных и их преобразования до панели мониторинга в конце, на которую может посмотреть пользователь.</p> <p>Система заканчивается там, где начинается человек. Это было хорошо, когда доступ к данным был ограничен, а аналитические вопросы поступали медленно. Это становится узким местом, когда организации необходимо постоянно принимать решения в быстро меняющихся условиях, в сроки, которые не позволяют обрабатывать трехдневную очередь запросов аналитиков.</p> <p>Теперь инфраструктура обрабатывает данные за секунды. При этом уровень интерпретации не изменился.</p> <h3>Разрастание SaaS-сервисов усугубило ситуацию</h3> <p>Один операционный директор прямо описал проблему: «У нас 14 систем, каждая из которых имеет немного разное определение дохода. И мои аналитики тратят половину своего времени на то, чтобы выяснить, какой из них можно доверять, прежде чем они смогут ответить на какой-либо вопрос». Это не проблема качества данных. Это проблема архитектуры. Современное предприятие работает с CRM-системами, биллинговыми платформами, конвейерами телеметрии продуктов, системами обработки заявок и бухгалтерскими системами, каждая из которых по-своему определяет одни и те же бизнес-концепции. Инструменты ETL централизовали данные. Но они не решили проблему семантических различий. Они переместили их вниз по потоку, в хранилище данных, где они стали проблемой аналитика.</p> <p>По мере того, как стек становился технически более совершенным, нагрузка на людей, работающих с ним, росла вместе с этим. Понимание того, каким таблицам можно доверять, какие определения применимы в конкретном контексте и как метрики соотносятся между системами, требует институциональных знаний, которые накапливаются годами. Аналитик становится интерпретатором системы — это роль, которая никогда не упоминается в презентации поставщика.</p> <h3>Во сколько на самом деле обходятся медленные решения</h3> <p>Сигналы появляются в корпоративных данных раньше, чем в самом бизнесе. Проблема с продуктом, изменение поведения клиентов, снижение вовлеченности — эти вещи сначала проявляются в данных об использовании и активности службы поддержки. Стек данных их фиксирует. Но затем ничего не происходит, потому что кто-то должен их заметить, запросить информацию, проверить определения, собрать контекст и донести его до нужных людей.</p> <p>К тому времени, как организация начинает действовать, ситуация обычно уже обостряется. Один вице-президент рассказал, что узнал о серьезном риске оттока клиентов через три недели после того, как сигналы впервые появились в данных. «Все было налицо, — сказал он. — Мы просто этого не заметили».</p> <p>Это не проблема конвейера данных. Это проблема инфраструктуры принятия решений.</p> <h3>Предположение, которое необходимо изменить</h3> <p>Большинство попыток исправить ситуацию сосредоточены на производительности инфраструктуры, более быстрых конвейерах данных, более масштабируемых хранилищах данных, улучшенных панелях мониторинга. Эти улучшения важны. Но они оставляют основное предположение нетронутым.</p> <p>Архитектура предполагает, что процесс принятия решений инициируется аналитиком-человеком. Кто-то должен задать вопрос, прежде чем что-либо произойдет. Другая модель исходит из противоположной предпосылки. Решения должны приниматься, когда появляются сигналы, а не когда кто-то проведет плановый анализ.</p> <p>Для этого необходимы системы, способные анализировать данные из различных источников в режиме реального времени, понимать взаимосвязь сигналов в разных областях и реагировать при выполнении условий. Это не требует предварительного объединения всех систем в единое хранилище данных. Необходимый контекст часто существует на разных операционных платформах, которые организации никогда не смогут полностью унифицировать, а ожидание идеальной централизации — это бесконечное ожидание. Настоящая работа заключается в обеспечении возможности анализа данных в этих системах в их нынешнем виде, а не в том, какими мы хотели бы их видеть.</p> <h3>Измерение не того, что нужно</h3> <p>Организации, с которыми я работаю, оценивают свою инфраструктуру данных с помощью технических метрик, надежности конвейеров данных, производительности хранилища данных, задержки запросов. Это полезно для инженеров. Но это не те показатели, которые важны для бизнеса.</p> <p>Для него важно, сколько проходит времени между появлением сигнала и реакцией на него. Именно этот интервал определяет, насколько быстро организация реагирует на проблему клиента, операционный сбой или временное окно, которое не будет открытым долгое время.</p> <p>Большинство компаний вложили значительные средства в сокращение задержки в конвейерах данных. Очень немногие коснулись задержки принятия решений. Вице-президент, озадаченная тем, почему принятие решений по-прежнему занимает неделю, несмотря на самые быстрые конвейеры данных, которые у нее когда-либо были, получила инструменты, оптимизированные не для того, что нужно. Те, кто это осознал, теперь имеют время что-то с этим сделать. Те, кто будет ждать, потратят следующие несколько лет на строительство более быстрых дорог к той же самой пробке.</p> Разработанный десять дет назад современный стек данных не был построен неправильно. Он был создан для решения проблемы … article https://www.itweek.ru/themes/detail.php?ID=234721 Mon, 27 Apr 2026 09:42:49 +0300 <p>Искусственный интеллект уже стал частью повседневной работы — от генерации кода до анализа требований и тестирования. Но основной сдвиг происходит не столько в инструментах, сколько в том, как устроена сама работа команды.</p> <p>По данным McKinsey   Company, генеративный ИИ повышает продуктивность разработчиков на <nobr>20-45%,</nobr> а эксперименты GitHub показывают ускорение выполнения задач до 55%.</p> <p>Однако эти цифры описывают отдельные операции, а не процесс в целом. На уровне команды происходит более глубокое изменение: если раньше узким местом было производство кода, то теперь им становится коммуникация — способность договориться, передать контекст и быстро принимать решения.</p> <p>Из такого сдвига и вытекают изменения ролей. Рассмотрим, как это работает и как можно подготовиться к переменам.</p> <h3>Почему старые роли больше не работают</h3> <p>Классическая модель разработки строилась на разделении функций: аналитик формирует требования, разработчик пишет код, тестировщик проверяет результат, менеджер координирует процесс. Такая схема позволяла масштабировать команды, но имела свою цену — рост затрат на коммуникацию и синхронизацию.</p> <p>С появлением ИИ производство ускорилось: код генерируется быстрее, тестирование частично автоматизируется. При этом сами процессы часто остаются прежними.</p> <p>В результате узкое место смещается. Теперь ограничением становится не скорость выполнения задач, а взаимодействие между людьми. Чем больше команда, тем сложнее удерживать единое понимание задачи.</p> <p>Поэтому большие команды начинают проигрывать — не из-за качества работы, а из-за стоимости коммуникации.</p> <h3>Новый тренд: команды становятся меньше</h3> <p>На этом фоне становится заметен тренд на уменьшение команд. Еще несколько лет назад команда из <nobr>10-15</nobr> человек считалась нормой, а сейчас ее назовут скорее избыточной.</p> <p>Небольшие команды из <nobr>5-6</nobr> специалистов работают быстрее не потому, что делают больше, а потому что теряют меньше времени на согласования. Им проще удерживать контекст, быстрее принимать решения и реже возвращаться к уже обсужденным вопросам.</p> <p>ИИ ускоряет выполнение задач, но не снижает стоимость общения между людьми. Поэтому команды начинают сжиматься как более устойчивая и управляемая модель.</p> <h3>Роли не исчезают — они расширяются</h3> <p>Сейчас каждый сотрудник берет на себя более широкий набор функций, чем раньше, и выдает больший результат. Аналитика, разработка, тестирование, управление — все это остается. Но распределяется между меньшим числом людей.</p> <p>Один человек все чаще закрывает сразу несколько зон ответственности, и нужда в строгом разделении ролей попросту отпадает. Например, разработчик может одновременно участвовать в тестировании и настройке инфраструктуры, а менеджер — глубже погружаться в аналитику.</p> <p>Вместе с этим растет и ответственность за итог: если зона роли становится шире, уже сложнее сослаться на то, что ошибка возникла «на другом этапе». Специалист отвечает не только за свой участок работы, но и за то, каким получается конечный результат.</p> <p>Из-за этого возрастает и ценность понимания бизнес-контекста. Раньше глубокое погружение в смысл задачи в большей степени требовалось от менеджера или аналитика. Теперь этого ждут почти от каждой роли: без понимания целей, ограничений и логики продукта невозможно ни корректно поставить задачу ИИ, ни проверить, что полученный результат действительно полезен бизнесу.</p> <p>Таким образом, ИИ расширяет роли и создает ролевые пересечения — и при этом повышает эффективность.</p> <h3>Разработчик: от исполнителя к проверяющему</h3> <p>Наиболее заметные изменения происходят в роли разработчика. В старой парадигме его основной задачей было написание кода. Сейчас это скорее правильная постановка задачи, приемка результата и умение грамотно его анализировать.</p> <p>Разработчик формирует контекст для ИИ, управляет агентами, комбинирует решения и проверяет их корректность. По сути, он начинает выполнять управленческую функцию в своей зоне ответственности. Это меняет и требования к роли. Ошибка ИИ уже не воспринимается как «сбой инструмента» — это результат некорректной постановки задачи или недостаточной проверки.</p> <p>Таким образом, разработчик становится не просто исполнителем, а тем, кто управляет процессом получения результата.</p> <h3>Менеджер: от более точечных задач — к перестройке системы требований</h3> <p>Роль менеджера не исчезает, но расширяется довольно заметно. И дело не в том, что он «меньше координирует». Менеджер и раньше не был просто координатором процесса — его работа всегда заключалась в управлении ожиданиями, интересами и договоренностями между людьми, удержании общего вектора и сборке результата из разных точек зрения. Среда меняется, инструменты меняются, но люди в системе остаются — а значит, эта часть роли никуда не уходит.</p> <p>Важно, что теперь менеджеру нужно раньше и лучше остальных понимать, как именно ИИ повлиял на команду, что изменилось в ролях и где проходит новая норма. Если часть задач делается быстрее, функции расширяются, а один человек начинает закрывать больший объем работы, то и требования к команде нужно выставлять по-новому. Менеджер должен понимать, что действительно можно требовать от роли, где граница реалистичных ожиданий и как меняется ответственность внутри команды.</p> <p>По сути, менеджер берет на себя более высокий уровень настройки системы. Он глубже работает с требованиями, бизнес-контекстом и рисками, следит за тем, чтобы задача была поставлена корректно, а результат соответствовал ожиданиям бизнеса. То есть он управляет не только людьми и не только процессом, а тем, как в новых условиях должна работать вся команда целиком.</p> <h3>Вся команда — в чем-то менеджеры</h3> <p>Одно из ключевых изменений связано с самой природой работы.</p> <p>Прежде задача заключалась в том, чтобы выполнить определенный объем действий. Теперь — в том, чтобы правильно сформулировать задачу, получить результат и оценить его. Это управленческая логика.</p> <p>В результате каждый участник команды в той или иной степени начинает выполнять функции менеджера: разработчик управляет агентами, QA управляет качеством, менеджер — всей системой.</p> <h3>Бизнес-контекст — задача всей команды</h3> <p>В рамках ИИ-трансформации растут требования к пониманию бизнес-контекста. Раньше его можно было «сконцентрировать» в роли менеджера проектов, но сейчас этого недостаточно, особенно если учесть, как расширяются роли и как на это влияет искусственный интеллект.</p> <p>Здесь стоит учитывать важный нюанс: ИИ усиливает того, кто умеет правильно формулировать задачу. Эксперты Gartner еще два года назад отметили, что главное ограничение для внедрения генеративного ИИ — качество входного контекста, и нельзя сказать, что за прошедшее время проблема полностью исчезла.</p> <p>Что это означает на практике:</p> <ul> <li> разработчик, который не понимает бизнес-цель, не сможет использовать искусственный интеллект корректно;</li> <li> QA может во время проверки упустить какой-то пользовательский сценарий;</li> <li> аналитик не сумеет делегировать свои задачи инструменту без потери смыслов.</li> </ul> <p>ИИ снижает порог выполнения задач, но не снижает требований к их пониманию. Поэтому бизнес-контекст становится общей ответственностью команды.</p> <h3>Новая модель команды: меньше ролей — больше ответственности</h3> <p>Когда часть задач закрывается с помощью ИИ, длинная цепочка ролей начинает работать хуже. Проблема не в количестве людей как таковом, а в стоимости синхронизации: каждая передача задачи требует времени, уточнений и повторного погружения в контекст. Пока главным узким местом был код, это было оправданно. Но когда производство ускорилось, основные потери сместились в коммуникацию.</p> <p>Отсюда и сдвиг к более компактным командам. Небольшой группе проще удерживать общий контекст, быстрее договариваться и меньше терять на передаче информации. Это не означает, что функции исчезают. Аналитика, разработка, тестирование и управление остаются, но больше не живут как изолированные этапы — они схлопываются и распределяются между меньшим числом людей.</p> <p>Поэтому «меньше ролей» не значит «проще». Скорее наоборот: чем компактнее команда, тем выше требования к каждому участнику. Спрятать ошибку за процессом становится сложнее, а личной ответственности — больше. В этом и состоит новая модель: не убрать роли, а сделать их шире.</p> <p>Именно здесь и возникает следующий эффект. Когда функций на одном человеке становится больше, а сама команда работает быстрее, резко растет цена ошибки. Раньше часть проблем можно было поймать на следующем этапе или в другой роли. Теперь таких промежуточных точек контроля становится меньше. Поэтому вместе с ускорением почти неизбежно встает вопрос: успевает ли система контроля за новой скоростью работы?</p> <h3>Риск: скорость растет быстрее контроля</h3> <p>Главный эффект от внедрения ИИ — рост скорости. Но именно это и формирует новые риски. Команда начинает делать больше задач за меньшее время, а система контроля часто остается прежней. В результате ошибки не исчезают, а масштабируются.</p> <p>На практике это выглядит так:</p> <ul> <li> ответ или решение выглядят логично, но содержат ошибку;</li> <li> непонятно, кто именно должен был проверить результат;</li> <li> дефекты и неточности быстрее попадают в прод;</li> <li> задач становится больше, но узкие места в согласованиях и данных никуда не деваются.</li> </ul> <p>Проблема здесь не только в самих ошибках, но и в их незаметности. ИИ создает ощущение, что задача уже решена, потому что результат получен быстро и выглядит убедительно. Поэтому принцип простой: если скорость растет, контроль должен расти быстрее.</p> <h3>Что делать бизнесу прямо сейчас</h3> <p>Переход к новой модели работы с ИИ не происходит автоматически. Недостаточно просто дать команде новые инструменты и ожидать, что процесс сам станет быстрее и лучше. Если роли, ответственность и логика взаимодействия остаются прежними, ИИ чаще дает локальный эффект, а не системное ускорение.</p> <p>В первую очередь важно пересмотреть роли и зоны ответственности. Речь идет не о сокращении функций, а об их объединении и перераспределении внутри команды. Нужно заранее понимать, кто теперь отвечает за требования, кто проверяет результат работы ИИ и на каком этапе принимается итоговое решение.</p> <p>Второй шаг — работа с размером команды. Снижение затрат на коммуникацию становится критическим фактором эффективности. Чем длиннее цепочка передач, тем выше вероятность, что часть контекста потеряется, а решение придется пересобирать заново. Поэтому бизнесу важно смотреть не только на загрузку специалистов, но и на то, сколько времени команда тратит на согласования.</p> <p>Третий — развитие универсальности специалистов. Чем шире зона понимания, тем эффективнее используется ИИ. Это не означает, что каждый должен уметь все, но узкой экспертизы уже недостаточно: нужно лучше понимать смежные зоны и общий контекст задачи.</p> <p>Наконец, меняется сам фокус работы. Ключевым навыком становится не выполнение задач, а умение их формулировать и принимать результат. Поэтому бизнесу важно развивать не только технические навыки команды, но и способность работать с ожиданиями, контекстом и критериями качества.</p> <h3>Подведем итоги</h3> <p>ИИ не убирает роли, но меняет их содержание. Функции остаются, однако распределяются иначе: команды становятся компактнее, зоны ответственности — шире, а требования к уровню участников — выше. Работа все меньше сводится к выполнению отдельной операции и все больше — к управлению результатом.</p> <p>Это значит, что ценность специалиста теперь определяется не только его узкой экспертизой, но и способностью работать с контекстом, формулировать задачу, проверять результат и брать на себя больше функций, чем раньше. В этой логике выигрывают те команды, которые быстрее адаптируются: пересматривают роли, сокращают лишние передачи между участниками и учатся работать с ИИ как с частью системы, а не как с отдельным инструментом.</p> <p>#IMAGE_234722#</p> Искусственный интеллект уже стал частью повседневной работы — от генерации кода до анализа требований … article Алексей Феофанов, директор по развитию бизнеса Umbrella IT https://www.itweek.ru/themes/detail.php?ID=234719 Fri, 24 Apr 2026 09:44:23 +0300 <p><em>McKinsey выделяет четыре скоординированных шага, которые связывают стратегию, технологию и людей для создания прочного фундамента данных, сообщает портал </em><em>ZDNet</em><em>.</em></p> <p>Gartner <a href="https://www.gartner.com/en/newsroom/press-releases/2026-1-15-gartner-says-worldwide-ai-spending-will-total-2-point-5-trillion-dollars-in-2026">прогнозирует</a>, что в 2026 г. мировые расходы на искусственный интеллект составят 2,5 трлн. долл., что на 44% больше, чем в прошлом году. Расходы на платформы ИИ для науки о данных и машинного обучения достигнут 31 млрд. долл., а расходы на данные для ИИ — 3 млрд. долл.</p> <p>По данным Deloitte Digital, к концу 2026 г. глобальный рынок агентного ИИ достигнет 8,5 млрд. долл. и вырастет почти до 40 млрд. долл. к 2030 г. Организации быстро ускоряют внедрение агентов ИИ, при этом, согласно исследованию MuleSoft 2026, в настоящее время средний уровень их использования составляет 12 агентов на организацию. Прогнозируется, что этот темп увеличится на 67% в течение следующих двух лет, достигнув среднестатистического использования на уровне 20 агентов ИИ.</p> <p>Согласно данным IDC, в 2026 г. 40% всех должностей в компаниях из списка Global 2000 будут связаны с работой с ИИ-агентами, что изменит традиционные позиции начального, среднего и высшего звена. Но этот путь не будет гладким. В 2027 г. компании, которые не уделяют приоритетного внимания высококачественным данным, готовым к использованию в ИИ, столкнутся с трудностями в масштабировании генеративного ИИ и агентных решений, что приведет к снижению производительности на 15%. Если <nobr>2025-й</nobr> был годом пилотных экспериментов и небольших внедрений агентного ИИ в производство, то <nobr>2026-й</nobr> обещает стать годом масштабирования агентного ИИ. А для этого, согласно прогнозу IDC, компаниям потребуются надежные, доступные и качественные данные.</p> <p>По данным исследования McKinsey, масштабирование внедрения агентного ИИ в бизнесе требует прочного фундамента данных. Компании могут с помощью агентов создавать высокоэффективные рабочие процессы, но для этого им необходимо модернизировать свою архитектуру данных, улучшить качество данных и усовершенствовать свои операционные модели.</p> <p>Исследование McKinsey показало, что почти две трети предприятий по всему миру экспериментировали с агентами, но менее 10% масштабировали их до уровня, обеспечивающего измеримую ценность. Самым большим препятствием для масштабирования внедрения агентов является низкое качество данных — восемь из десяти компаний называют ограничения данных препятствием для масштабирования агентного ИИ.</p> <p>McKinsey определила основные ограничения данных как главные препятствия, с которыми сталкиваются компании при масштабировании ИИ, включая: ограничения операционной модели и кадрового потенциала, ограничения данных, неэффективное управление изменениями и ограничения технологической платформы.</p> <h3>Данные — основа агентного ИИ</h3> <p>Исследование McKinsey показывает, что агентному ИИ необходим постоянный поток высококачественных, достоверных данных для точной автоматизации сложных бизнес-процессов. Успешный агентный ИИ также зависит от архитектуры данных, которая может поддерживать автономность — выполнение задач без вмешательства человека.</p> <p>Эксперты выделяют две модели использования агентов: одноагентные рабочие процессы (один агент использует несколько инструментов) и мультиагентные рабочие процессы (специализированные агенты сотрудничают). В каждом сценарии агенты будут полагаться на доступ к высококачественным данным. Разрозненные и фрагментированные данные приведут к ошибкам и некачественному принятию решений агентами.</p> <h3>Четыре шага для подготовки данных</h3> <p>McKinsey выделила четыре скоординированных шага, которые связывают стратегию, технологию и людей для создания прочной основы для работы с данными.</p> <ol> <li><strong> Определите наиболее важные рабочие процессы для «агентизации». </strong>Сосредоточьтесь на высокодетерминированных, повторяющихся задачах, которые приносят ценность и являются сильными кандидатами для использования агентов ИИ.</li> <li><strong> Модернизируйте каждый уровень архитектуры данных для агентов. </strong>Модернизация должна поддерживать совместимость, легкий доступ и управление данными между системами. Подавляющее большинство бизнес-приложений не обмениваются данными между платформами. Согласно исследованию MuleSoft, организации быстро внедряют автономные системы. В среднем предприятие сейчас управляет 957 приложениями — и это число возрастает до 1057 для тех, кто продвинулся дальше в своем пути к внедрению агентного ИИ. Только 27% этих приложений в настоящее время связаны между собой, что создает серьезную проблему для ИТ-руководителей, стремящихся достичь своих краткосрочных целей внедрения ИИ.</li> <li><strong> Обеспечьте качество данных.</strong> Предприятия должны обеспечить соответствие как структурированных, так и неструктурированных данных, а также данных, генерируемых агентами, единым стандартам точности, происхождения и управления. Доступ к надежным данным является ключевым препятствием. В настоящее время ИТ-команды в среднем тратят 36% своего времени на проектирование, создание и тестирование новых пользовательских интеграций между системами и данными. Индивидуальная работа не поможет масштабировать внедрение ИИ. Наиболее значительным препятствием для успешного развертывания ИИ или агентов ИИ является качество данных, которое 25% организаций называют главной проблемой. Кроме того, почти все организации (96%) испытывают трудности с использованием для инициатив в области ИИ данных из всех подразделений компании.</li> <li><strong> Создайте операционную и управленческую модель для агентного ИИ.</strong> Речь идет о переосмыслении того, как выполняется работа. Роль человека сместится от выполнения к надзору и координации рабочих процессов, управляемых агентами. В гибридной рабочей среде управление будет определять, как агенты могут работать автономно, надежным, прозрачным и масштабируемым образом.</li> </ol> <h3>Работа, порученная агентам ИИ</h3> <p>McKinsey подчеркивает важность определения нескольких критически важных рабочих процессов, которые могли бы стать областью ответственности агентов ИИ. Для начала, составление сквозной карты рабочих процессов помогло бы выявить возможности для использования агентов. McKinsey обнаружила, что внедрение ИИ возглавляют отделы обслуживания клиентов, маркетинга, управления знаниями и ИТ. Важно определить четкие метрики, подтверждающие эффективность. Команды должны определить данные, которые можно повторно использовать в различных задачах и рабочих процессах.</p> <p>McKinsey заключает, что доступ к высококачественным данным является стратегическим конкурентным преимуществом в эпоху агентного ИИ. Поскольку агенты будут генерировать огромные объемы данных, качество данных, их происхождение и стандартизация станут еще более важными в агентном предприятии. И по мере масштабирования агентных систем управление становится основным уровнем контроля. Фундамент данных станет конкурентным преимуществом в эпоху агентного ИИ.</p> McKinsey выделяет четыре скоординированных шага, которые связывают стратегию, технологию и людей для создания прочного … article https://www.itweek.ru/themes/detail.php?ID=234716 Thu, 23 Apr 2026 16:22:21 +0300 <p>Институт статистических исследований и экономики знаний (ИСИЭЗ) НИУ ВШЭ изучает аспекты цифровой трансформации химической промышленности, в том числе оценивает необходимый для этого ресурсный, в частности кадровый, потенциал организаций отрасли, а также их текущий уровень использования цифровых технологий и перспективный спрос.</p> <p>37% организаций химпрома считают внедрение цифровых технологий стратегическим приоритетом; 30% изучают и ориентируются на лучшие отраслевые практики их использования; 26% связывают с ними свою конкурентоспособность; четверть ожидают значительных изменений бизнес-процессов под влиянием цифровых технологий в ближайшие три года.</p> <p>В настоящее время 91% предприятий химпрома используют хотя бы одну цифровую технологию. В среднем в одной организации внедрены четыре цифровых технологии. Наиболее востребованы на предприятиях химпрома системы автоматизации производственных процессов: их используют 41% организаций. Планируют освоить новые цифровые решения или видят в них потенциал каждые четыре из пяти респондентов.</p> <p>Затраты на внедрение и использование цифровых технологий заметно коррелируют с размером компаний. Почти половина предприятий химпрома на эти статьи расходуют не более 1 млн руб.; четверть — до 10 млн руб. Инвестпроекты объемом более 50 млн или 100 млн руб. реализует примерно каждая шестая и десятая соответственно среди обследованных организаций отрасли, большинство из которых — крупные.</p> <p>В качестве барьера использования цифровых технологий организации химпрома чаще всего указывают сложность интеграции новых технологий с имеющейся инфраструктурой и отсутствие свободных ресурсов.</p> <p>Цифровые навыки сотрудников четыре из пяти компаний оценили как достаточные для выполнения текущих должностных обязанностей, для внедрения новых цифровых технологий — менее чем в трети.</p> <p>Последняя оценка выше (так, ее выбрали три из пяти предприятий) в отношении ИКТ-специалистов. Уровень компетенций работников данной, ключевой для цифровой трансформации, категории почти все обследованные предприятия считают достаточным для выполнения текущих обязанностей. Для трети обследованных организаций их общая численность соответствует потребности. Примерно сопоставимые доли респондентов испытывают существенный или незначительный дефицит хотя бы одной категории специалистов по ИКТ.</p> <p>Около трети организаций указали, что специалисты, занятые в разработке и производстве, владеют достаточными компетенциями для работы со всеми цифровыми технологиями, используемыми в производственном процессе предприятия. Почти в такой же доле организаций специалистам недостаточно навыков для работы хотя бы с одной технологией.</p> <p>Предприятия химпрома нацелены на развитие цифровых навыков персонала. Более чем в половине обследованных организаций руководители и сотрудники постоянно совершенствуют свои цифровые навыки, еще в 38% — наличие цифровых навыков учитывается при принятии кадровых решений.</p> Институт статистических исследований и экономики знаний (ИСИЭЗ) НИУ ВШЭ изучает аспекты цифровой трансформации химической … message https://www.itweek.ru/themes/detail.php?ID=234715 Thu, 23 Apr 2026 16:16:42 +0300 <p>Центр стратегических разработок опубликовал ежегодное исследование рынка систем управления базами данных (СУБД) и инструментов обработки данных за 2025 год и подготовил прогноз его развития до 2032 года. По оценке экспертов, объем рынка прибавил по сравнению с предыдущим годом и после значительного роста <nobr>2023–2024</nobr> годах рынок перешел к фазе стабилизации.</p> <p>В 2025 году объем рынка достиг 101,9 млрд рублей, увеличившись на 13,9%. В период с 2025 по 2032 годы среднегодовой рост рынка превысит 15%, что превышает как мировые показатели, так и темпы развития российского ИТ-сектора, отметила заместитель генерального директора ЦСР Екатерина Кваша.</p> <p>Один из главных показателей — уверенный рост импортозамещения: по расчетам экспертов ЦСР, доля иностранных решений в новых продажах продолжит снижаться и достигнет 1% к 2032 году. В свою очередь участники рынка убеждены, что возвращение к прежней модели зависимости от зарубежных технологий вероятно, но малоперспективно с коммерческой точки зрения.</p> <p>«Исследование показало, что 80% рынка составляют продажи программного обеспечения, а оставшиеся 20% — это услуги. В части продаж систем управления базами данных крупнейшая доля приходится на СУБД общего назначения (51%) и аналитические СУБД (38%)», — подчеркнула Екатерина Кваша.</p> <p>По объемам продаж, связанных с продуктами собственной разработки, на первом месте находится Группа Arenadata с долей 8,6% рынка, следом идет компания Postgres Pro с долей в 6,5%, далее — Yandex B2B Tech — 2,8%, DIS Group −2,7%, Тантор Лабс — 1,3%.</p> <p>«В настоящее время рынок переживает значительные изменения: от фрагментированных решений и ускоренного импортозамещения к созданию полноценных платформ для управления данными. Конкуренция сдвигается в сторону экосистемного подхода, где основное внимание уделяется комплексным предложениям, включающим транзакционную и аналитическую обработку, инструменты управления данными и интегрированные ИИ-механизмы. Также наблюдается формирование нового сегмента решений, направленных на безопасную обработку данных в сочетании с СУБД. Ожидается консолидация рынка и постепенный отход заказчиков от „in-house“ разработок в пользу коммерческих платформ», — констатировал заместитель генерального директора ЦСР.</p> <p>В целом российский рынок СУБД в период до 2032 годов будет активно развиваться благодаря политике обязательного импортозамещения, ужесточению требований к безопасности данных, особенно в критической информационной инфраструктуре, устойчивому спросу на системы управления базами данных в связи с ростом цифровизации и объемов данных, внедрению искусственного интеллекта и разработке новых архитектурных решений. Существенное влияние на этот процесс окажут государственные инвестиции, направляемые на реализацию цифровых программ.</p> Центр стратегических разработок опубликовал ежегодное исследование рынка систем управления базами данных (СУБД … message https://www.itweek.ru/themes/detail.php?ID=234713 Thu, 23 Apr 2026 16:14:06 +0300 <p>Российский разработчик UDV Group представил новый релиз своего продукта для контроля версий и централизованного хранения проектов ПЛК — UDV DATAPK Version Control 3.1.</p> <p>UDV DATAPK Version Control — это первое и на сегодняшний день единственное на рынке РФ специализированное решение для хранения версий проектов ПЛК и отслеживания изменений в них. Продукт решает ключевые инженерные задачи в работе с ПЛК ведущих зарубежных и российских производителей (Siemens, Schneider Electric, Allen Bradley, Овен, Регул, ТРЭИ и других) в одном окне, помогая обеспечивать непрерывность технологического процесса:</p> <ul> <li>отслеживание изменений в проектах ПЛК, сравнение версий и отображение различий — система фиксирует, кто, когда и что именно менял в проекте;</li> <li>централизованное хранение версий — инженеры всегда знают, где лежат актуальные проекты;</li> <li>быстрое восстановление — при возникновении сбоя в производственном процессе можно быстро отследить цепочку изменений и восстановить последнюю рабочую версию проекта.</li> </ul> <p>Улучшенный контроль версий ПЛК в релизе 3.1 позволяет видеть не только кто и когда внес изменения, но и конкретные блоки и теги в проекте, которые были отредактированы, а также сопоставлять версии проекта ПЛК в репозитории и на самом контроллере, чтобы убедиться, что на ПЛК загружена именно та версия, которая считается эталонной.</p> <p>Кроме того, в UDV DATAPK Version Control 3.1 появился ряд обновлений, делающих работу с решением удобнее. Теперь инженер может задать тип проекта ПЛК, чтобы избежать версионирования временных файлов, возникающих при открытии/закрытии среды разработки, а также — быстро скачать актуальную версию десктоп-приложения продукта и логи для облегчения обновления и обслуживания.</p> <p>«UDV DATAPK Version Control дает предприятию не просто замену иностранного продукта, а собственный рабочий контур для управления проектами ПЛК. И это не архив и не классический бэкап. У предприятия появляется единая точка хранения, понятная история правок, сравнение версий и быстрый путь возврата к рабочей конфигурации после сбоя или ошибки. Для АСУ ТП сегодня это уже не дополнительная функциональность, а фундаментальный элемент безопасности и непрерывности технологического процесса, который должен находиться в предсказуемой и управляемой среде», — прокомментировал директор Лаборатории кибербезопасности UDV Group Владислав Ганжа.</p> Российский разработчик UDV Group представил новый релиз своего продукта для контроля версий и централизованного хранения … message https://www.itweek.ru/themes/detail.php?ID=234712 Thu, 23 Apr 2026 09:59:04 +0300 <p><em>Исследование PagerDuty «2026 State of AI-First Operations» показывает, что сбои в ИТ-инфраструктуре обходятся крайне дорого и приводят к выгоранию разработчиков. Манди Уоллс, специалист по DevOps компании PagerDuty, рассказывает на портале </em><em>The</em> <em>New</em> <em>Stack</em> <em>о том, как использовать автоматизацию на основе искусственного интеллекта для повышения надежности.</em></p> <p>Безотказная работа ИТ прочно утвердилась в качестве приоритета на уровне совета директоров. Это неудивительно, поскольку организации платят высокую цену за цифровые сбои. Недавнее исследование PagerDuty показывает, что 68% глобальных организаций теряют более 300 тыс. долл. в час во время ИТ-инцидентов.</p> <p>Это плохо не только для лояльности клиентов и прибыли. 42% руководителей операциями признают, что сбои также могут способствовать выгоранию разработчиков. Но, эффективно сочетая человеческие команды и автономные инструменты ИИ, организации могут снизить нагрузку на специалистов по реагированию, что, в свою очередь, может помочь повысить устойчивость, операционную зрелость и инновационность.</p> <h2>Откуда берется усталость?</h2> <p>Усталость разработчиков — это цена, которую платят глобальные компании за безупречный, ориентированный на цифровые технологии опыт, который они обещают клиентам. Инженерные команды постоянно находятся под давлением необходимости выпускать обновления, но сложные, ненадежные архитектуры, с которыми они работают, делают инциденты неизбежными. Каждый новый релиз приносит новые зависимости и потенциальные источники сбоев.</p> <p>Когда что-то идет не так, инженеров отвлекают от важной работы для расследования и устранения неполадок. Ситуацию усугубляет то, что разрозненные инструменты, которые они вынуждены использовать, не могут подавлять лишние оповещения, интеллектуально маршрутизировать инциденты или заблаговременно находить и исправлять хорошо известные проблемы. Среднестатистической команде приходится обрабатывать тысячи ежедневных оповещений, многие из которых нерелевантны или дублируются.</p> <p>Автоматизация может помочь, но она также может увековечивать организационные барьеры, приводить к вводящим в заблуждение результатам и создавать дополнительную работу, если требуются команды для отладки скриптов и управления исключениями. В результате падает моральный дух, наступает истощение, и тушение пожаров становится важнее инноваций.</p> <p>Есть способы избежать этой участи. ИИ потенциально может принести значительную выгоду организациям, которые разберутся, как использовать его в интересах разработчиков.</p> <p>Рассмотрите следующие три шага:</p> <h3>1. Формирование доверия среди разработчиков</h3> <p>Без доверия к ИИ невозможно продвижение к более зрелой и удобной для разработчиков модели. Уверенность в технологии ИИ высока среди ИТ-руководителей и бизнес-лидеров. Исследования показывают, что 59% лиц, принимающих решения в ИТ-сфере, ожидают, что ИИ улучшит показатели времени простоя и восстановления более чем на 20%. Однако разработчики, похоже, не разделяют этого энтузиазма: только 37% согласны с этим. Поэтому изменение этих представлений является критически важным первым шагом к снижению выгорания.</p> <p>Организациям необходимо продвигать ИИ и помогать командам понять, как он может помочь им в личном и профессиональном плане. Ключевым моментом является демонстрация того, как ИИ может устранить рутинную работу и освободить их для выполнения более творческих и полезных задач.</p> <p>Однако нет двух одинаковых членов команды. Некоторых потребуется убеждать больше, чем других, потому что они не уверены в ценности ИИ, беспокоятся о стабильности работы или и о том, и о другом. Важно проявлять эмпатию. Руководители поймут, что эти усилия приносят результаты, если члены команды начнут посещать факультативные семинары, пробовать новые инструменты и делиться полученными знаниями без просьбы.</p> <h3>2. Повышение квалификации существующих команд</h3> <p>Пожалуй, самая сложная часть проекта заключается в следующем этапе: получении командами разработчиков навыков использования инструментов ИИ в их повседневной работе. Около половины (51%) мировых организаций планируют нанимать или переобучать сотрудников для внедрения систем обнаружения инцидентов и реагирования на них с помощью ИИ.</p> <p>Ключевой момент заключается не в том, чтобы записывать их на общие учебные курсы, которые дадут лишь поверхностные знания. Вместо этого повышение квалификации должно быть актуальным для каждого человека и включать в себя используемые им инструменты, языки программирования и рабочие процессы.</p> <p>Начните с основных навыков, необходимых для овладения ИИ. Это может включать в себя декомпозицию проблем, разбиение задач на отдельные компоненты, которые может обрабатывать ИИ. Или побудите инженеров эффективно взаимодействовать с системами ИИ и понимать, как различные модели интерпретируют входные данные. Разработчикам также необходимы базовые знания в области оценки качества, позволяющие им эффективно определять, когда результат работы ИИ достаточно хорош, а когда требуется участие человека. Далее, адаптируйте учебные программы, чтобы сделать практические курсы актуальными для конкретных ролей. Используйте те же инструменты, данные и рабочие процессы, чтобы сделать курсы максимально контекстно релевантными. Помните, что все это требует времени, и обучение следует рассматривать как непрерывный процесс.</p> <h3>3. Эффективное сочетание людей и агентов ИИ</h3> <p>Как бы ни был важен ИИ в снижении рабочей нагрузки команд разработчиков, это не панацея. Осторожность остается нормой для многих организаций, особенно при оценке автономных, агентных систем ИИ. Почти две трети (62%) стремятся к сбалансированному сочетанию работы людей и агентов ИИ в течение следующих трех лет. Это делает крайне важным четкое определение того, когда требуется участие человека.</p> <p>Один из способов сделать это — следовать трехступенчатой ​​модели.</p> <p>Первый этап включает в себя рутинные проблемы с известными способами решения. ИИ обрабатывает все эти проблемы, от обнаружения до устранения. Люди требуются только для проверки отчетов и совершенствования процессов после инцидента, чтобы учиться и улучшать свою работу. На другом конце спектра находятся новые или сложные проблемы, требующие экспертных знаний и творческого подхода к решению. Люди всегда будут играть здесь ведущую роль, используя ИИ только для сбора контекста, данных и обработки рутинных коммуникаций.</p> <p>Между двумя крайностями находятся знакомые инциденты с элементами неопределенности. На этом этапе ИИ может быть задействован в детальном анализе, корреляции данных и генерации рекомендаций. Однако окончательное решение по исправлению ситуации будет приниматься людьми, которые в конечном итоге станут надзирать за работой ИИ.</p> <h2>Расширение команды</h2> <p>Для запуска этих проектов организациям необходимо пройти несколько этапов.</p> <p>Сначала это налаживание управления, затем обучение пользователей и определение того, когда следует привлекать людей к процессу. Далее организациям необходимо установить ограничения для лимитирования автономии агентов и механизмы для логирования решений, создания аудиторских следов и повышения прозрачности.</p> <p>Наконец, необходимо отслеживать множество показателей для мониторинга и постоянного улучшения производительности ИИ. Дополнительным преимуществом этой структуры является то, что она помогает укрепить доверие инженеров к инструментам ИИ.</p> <p>Агентов ИИ следует рассматривать как новых членов команды, поэтому их влияние необходимо оценивать так же, как и влияние их коллег-людей. Если эти усилия будут успешными, организации получат выгоду от более довольных команд, меньшего выгорания и более устойчивых цифровых операций.</p> Исследование PagerDuty «2026 State of AI-First Operations» показывает, что сбои в ИТ-инфраструктуре обходятся крайне … article https://www.itweek.ru/themes/detail.php?ID=234709 Wed, 22 Apr 2026 13:58:12 +0300 <p>Объем российского рынка офисного программного обеспечения до 2030 года будет расти со среднегодовым темпом в 9%. При этом, по итогам 2025 года 37% рассматриваемого рынка занимают российские продукты. Такие данные приводят эксперты компании «Системный софт». Они ожидают, что в ближайшие несколько лет перераспределение долей рынка в пользу отечественных производителей будет продолжаться. При сохранении текущих тенденций, к концу 2030 года российские вендоры будут обеспечивать более половины всех продаж офисного ПО.</p> <p>На фоне стабильной динамики <nobr>2022–2024</nobr> годов (рост на <nobr>12–14%</nobr> в год) 2025 год стал переломным для сегмента офисных приложений. По итогам прошлого года рынок показал значительное ускорение, увеличившись по сравнению с 2024 годом более чем на 25%. По оценкам экспертов «Системного софта», объем рынка превысил 100 млрд рублей, а структура распределилась следующим образом: зарубежное ПО — 49%, российское — 37%, свободное — 14%. При сохранении заметной доли иностранного ПО, бизнес ускоренно двигается в сторону отечественных решений и продуктов с открытым исходным кодом.</p> <p>Ключевым драйвером роста стало совпадение регуляторных и экономических факторов. С сентября 2025 года компаниям с госучастием и субъектам КИИ запрещено применение иностранного ПО в значимых объектах КИИ при наличии аналогов в Едином реестре российского программного обеспечения. (Федеральный закон № <nobr>58-ФЗ</nobr> от 07.04.2025).</p> <p>В 2025 году закончилась поддержка Microsoft Office 2016/2019, которые были установлены у многих заказчиков. Угроза остаться без обновлений безопасности подтолкнула их к переходу на альтернативные продукты. Существенную роль сыграла реализация нацпроекта «Цифровая экономика», в рамках которого предоставляются гранты, льготные кредиты, а также реализован приоритет для российского ПО при госзакупках по 44 ФЗ/223 ФЗ. Все это ускорило импортозамещение, в том числе в категории офисного ПО.</p> <p>По оценкам «Системного софта» российские офисные приложения достигли достаточного уровня зрелости при решении базовых задач и закрывают до 80% потребностей бизнеса. Облачные сервисы, обеспечивающие совместную работу с документами в режиме реального времени, такие как «Яндекс 360», по оценкам экспертов не уступают зарубежным аналогам. При этом они дают такие преимущества, как совместимость с российскими инфраструктурными решениями и полное соответствие регуляторным требованиям.</p> <p>При этом российское офисное ПО отстает в области работы с большими данными и сложными макросами в табличных редакторах, а также по ИИ-функциональности и автоматизации по принципу Copilot, хотя российские производители активно инвестируют в эти направления.</p> <p>Эксперты ожидают, что трендом 2026 года станут автономные ИИ-агенты, обеспечивающие интеграцию с другими офисными системами, что позволит автоматизировать рутинные операции и повысить продуктивность офисных работников на <nobr>30-40%.</nobr></p> <p>«Российский рынок офисного программного обеспечения переходит от взрывного роста к устойчивому и стабильному развитию, — прокомментировал Тайфур Касеев, руководитель направления средств совместной работы компании „Системный софт“. — Рост объемов данного рынка в <nobr>2026-2030 гг.</nobr> составит около 9%. Мы также прогнозируем дальнейшее перераспределение доли рынка в пользу российских производителей ПО. При сохранении текущих тенденций к концу 2030 года российские вендоры будут обеспечивать более половины продаж офисного ПО».</p> Объем российского рынка офисного программного обеспечения до 2030 года будет расти со среднегодовым темпом в 9% … message https://www.itweek.ru/themes/detail.php?ID=234708 Wed, 22 Apr 2026 13:57:04 +0300 <p>Yandex B2B Tech запустила консольное приложение SourceCraft CLI для работы с платформой SourceCraft. Теперь разработчики могут выполнять основные действия с ИТ-проектом прямо в режиме командной строки — писать код, управлять задачами, вносить изменения в проект и передавать их на проверку команде. Все это помогает делать встроенный ИИ-агент. По данным внутренних тестов специалистов Яндекса, консольное приложение с ИИ-агентом позволяет ускорить разработку и выпускать до 3 раз больше новой функциональности.</p> <p>В консольном приложении разработчик формулирует задачу на естественном языке, после чего агент выполняет её автономно в фоновом режиме: пишет код, проверяет его с помощью автоматических тестов и оформляет пулл-реквест. Решение можно интегрировать с платформами для разработки, которые уже использует компания, чтобы сотрудники продолжали работать в привычной среде.</p> <p>При работе с проектами в SourceCraft агент учитывает контекст разработки: определяет нужный репозиторий и связанную с ним задачу, вносит изменения в код и запускает процессы автоматической сборки, тестирования и доставки обновлений. В итоге разработчик получает готовый продукт — программу, сайт, скрипт или документ. </p> <p>Агент работает на базе языковых моделей Yandex AI Studio. Код и рабочие данные не передаются во внешние сервисы, что помогает компаниям организовывать разработку с учётом законодательных требований к защите персональных данных.</p> <p>В SourceCraft CLI также доступны «навыки» — сценарии для повторяющихся действий. Они задают фиксированную последовательность шагов и помогают выполнять типовые процессы по единым правилам, например при проверке кода. Пользователи могут создавать собственные сценарии или использовать готовые. </p> <p>«Следующий этап развития таких инструментов — работа с накопленными знаниями команды. Мы движемся к модели, в которой система сможет учитывать прошлые технические решения проекта, внутренние стандарты разработки и быстрее подключаться к новым задачам без длительной настройки», — рассказал Дмитрий Иванов, руководитель платформы SourceCraft.</p> <p>Командная строка остаётся основной рабочей средой для большинства инженеров: по данным опросов, её ежедневно используют более 70% разработчиков. В 2025 году ИИ-агенты в командной строке перешли из экспериментальных инструментов в рабочие системы — сегодня они генерируют уже 4% всех публичных изменений кода, а к концу 2026 года этот показатель может превысить 20%.</p> Yandex B2B Tech запустила консольное приложение SourceCraft CLI для работы с платформой SourceCraft. Теперь разработчики … message https://www.itweek.ru/themes/detail.php?ID=234706 Wed, 22 Apr 2026 09:53:07 +0300 <p><em>Цифровой суверенитет переходит из стадии концепции в стадию стратегического требования. Поскольку организации все больше сосредотачиваются на управлении ИТ-рисками, контроле и соблюдении нормативных требований, ожидания от поставщиков растут. Рахиэль Насир, директор IDC по европейским исследованиям облачных вычислений и ведущий аналитик по цифровому суверенитету, рассказывает в корпоративном блоге, почему ярлыка «сувереннный» уже недостаточно и что необходимо для удовлетворения этих новых требований.</em></p> <p>Многие поставщики технологий сегодня заявляют о предоставлении «суверенных» решений. Но если задать простой уточняющий вопрос, что именно делает их суверенными, ответы быстро становятся менее ясными.</p> <p>В то же время спрос на цифровой суверенитет растет. За последние 15 месяцев геополитическая и экономическая неопределенность выдвинула эту тему на более высокий уровень. Почти 50% организаций по всему миру говорят, что их интерес к цифровому суверенитету возрос по сравнению с предыдущим годом.</p> <p>Но сосредоточение внимания только на геополитике упускает из виду более масштабный сдвиг.</p> <h3>Почему меняются ожидания в отношении цифрового суверенитета</h3> <p>По мере роста интереса растут и ожидания. Цифровой суверенитет перестал быть абстрактным или чисто регуляторным понятием. Он становится важнейшим стратегическим требованием при принятии решений в сфере ИТ.</p> <p>В то же время он остается источником путаницы. Многие организации до сих пор испытывают трудности с определением того, что на самом деле означает суверенитет на практике, что необходимо для его достижения и нужен ли он им вообще. И тогда возникает вопрос: кому можно доверять?</p> <p>Это создает пробел на рынке. Поставщики говорят о суверенитете. Клиенты все еще пытаются понять, что же это такое.</p> <h3>Что на самом деле движет внедрением цифрового суверенитета</h3> <p>Несмотря на геополитическую обстановку, основные движущие силы гораздо более практичны.</p> <p>Организации отдают приоритет контролю над своими данными, более сильному управлению и соблюдению нормативных требований, а также возможности управлять рисками. В Европе, в частности, защита от экстерриториальных запросов данных стала наибольшей проблемой.</p> <p>Именно здесь начинают меняться ожидания.</p> <p>Более 40% организаций по всему миру заявляют, что увеличат частоту и детализацию проверок поставщиков ИТ-услуг и платформ, чтобы лучше оценивать и управлять этим риском. Кроме того, на вопрос о том, что наиболее необходимо для достижения суверенитета данных, 85% назвали чрезвычайно или очень важными усовершенствованные инструменты и решения для управления, рисками и соответствия требованиям.</p> <p>Таким образом, если цифровой суверенитет в конечном итоге сводится к управлению ИТ-рисками, его нельзя свести к ярлыку или характеристике. Он должен быть чем-то осязаемым, что можно четко объяснить, реализовать и проверить.</p> <p>Это также меняет роль поставщиков. Они должны помогать организациям оценивать свою склонность к риску, управлять этим риском и предоставлять решения, необходимые для удовлетворения этих ожиданий.</p> <p>И именно здесь действия многих поставщики пока не согласованы.</p> <h3>Что на самом деле требует цифровой суверенитет</h3> <p>Часть проблемы заключается в том, как формулируется суверенитет. Его часто рассматривают как единую возможность, тогда как в действительности он охватывает множество аспектов.</p> <p>Один из практических подходов — это рассмотрение трех областей: суверенитет данных, технический суверенитет и операционный суверенитет. Это три ключевых столпа облачного суверенитета, который сам по себе является частью более широкой концепции цифрового суверенитета.</p> <p>Вместе они определяют, как осуществляется контроль над данными, инфраструктурой и операциями.</p> <p>Для поставщиков это повышает планку. Суверенитет больше не является чем-то, что можно выразить в общих чертах. Его необходимо сформулировать по всем этим направлениям таким образом, чтобы это было прозрачно и поддавалось проверке.</p> <h3>Где суверенитет действительно имеет значение: высокорисковые рабочие нагрузки</h3> <p>Также важно уточнить, где суверенитет действительно необходим.</p> <p>Требования к суверенитету, как правило, сосредоточены на рабочих нагрузках, связанных с конфиденциальными данными, рисками нарушения нормативных требований и/или критически важными бизнес-процессами. Это все чаще включает в себя определенные сценарии использования искусственного интеллекта, где контроль данных и управление моделями имеют важное значение.</p> <p>Именно здесь доверие становится центральным элементом.</p> <p>Клиентам необходима уверенность в том, что заявления поставщиков о суверенитете выдерживают проверку, особенно в сценариях высокого риска. Уже недостаточно просто заявлять о суверенитете решения или рассматривать только отдельные аспекты, такие как размещение данных или локализация.</p> <p>Поставщики должны продемонстрировать, как обеспечивается суверенитет, где проходят границы и какие гарантии существуют. Эти гарантии должны распространяться на всю партнерскую экосистему, от основных поставщиков до их партнеров и далее.</p> <h3>От позиционирования к доказательству</h3> <p>Дискуссия о цифровом суверенитете быстро развивается. Ожидания растут, и вместе с ними растет и уровень контроля, применяемого к поставщикам.</p> <p>В этих условиях суверенитет перестает быть просто позиционирующим или маркетинговым заявлением. Это нечто, что необходимо четко определить, согласовать со всеми заинтересованными сторонами, последовательно внедрять и убедительно демонстрировать.</p> <p>Для многих поставщиков услуг это требует перемен. От общих заявлений к точным объяснениям. От заявлений к доказательствам.</p> <p>И в конечном итоге, от суверенитета как ярлыка к суверенитету как модели доверия, обеспечивающей автономию, контроль, прозрачность и устойчивость.</p> Цифровой суверенитет переходит из стадии концепции в стадию стратегического требования. Поскольку организации все … article https://www.itweek.ru/themes/detail.php?ID=234704 Tue, 21 Apr 2026 17:19:22 +0300 <p>Компания «Увеон — облачные технологии» (входит в «Группу Астра») выпустила обновление балансировщика нагрузки Termidesk Connect 1.3.</p> <p>Администраторы получили возможность гибко настраивать условия для автопереключения между узлами кластера высокой доступности (HA). Вместо простой схемы «активен — не активен» теперь можно задавать гранулярные критерии, учитывая состояние сервисов, сетевую доступность и пороговые значения метрик. Благодаря этому риск ложных переключений (split-brain) и запоздалых реакций на реальные аварии сводится к минимуму, что критически важно в сферах, где простой балансировщика может привести к недоступности всей ИТ-инфраструктуры: в финансовом секторе, ГИС и на промышленных предприятиях с непрерывным циклом работы.</p> <p>Termidesk Connect 1.3 поддерживает Proxy Protocol — стандартный механизм передачи на сервер данных об исходном IP-адресе и порте клиента. Они «видны» при балансировке TCP-соединений, даже если настроить связь через промежуточные прокси-уровни. Это позволяет корректно вести журналы доступа, применять ИБ-политики на основании IP-адресов, выполнять требования регуляторов в части аудита и логирования без дополнительных архитектурных ухищрений.</p> <p>На канальном (L2) и сетевом (L3) уровнях реализовали поддержку прямого возврата трафика (Direct Server Return). В этом режиме ответный трафик от серверов направляется напрямую клиенту, минуя балансировщик, что снимает ограничения с пропускной способности для исходящего трафика. Для видеостриминга, передачи больших файлов и в целом приложений с асимметричным трафиком это дает кратный рост пропускной способности. В результате можно обслуживать существенно больше пользователей без модернизации платформы балансировщика.</p> <p>При настройке виртуальных серверов и пулов теперь можно указывать диапазоны портов, а не только отдельные значения. Так намного проще конфигурировать SIP-телефонию, мультимедийные потоки, игровые серверы, сложные микросервисные приложения — сервисы, где задействовано множество портов. Более того, вместо сотен отдельных правил достаточно создать одно, и в итоге вероятность ошибок снижается, а настройки занимают меньше времени.</p> Компания «Увеон — облачные технологии» (входит в «Группу Астра») выпустила обновление балансировщика нагрузки Termidesk … message https://www.itweek.ru/themes/detail.php?ID=234703 Tue, 21 Apr 2026 17:15:44 +0300 <p>«МойОфис», российская продуктовая ИТ-компания, представила масштабное обновление — релиз «МойОфис» 26.1. В фокусе релиза интеграция технологий искусственного интеллекта в пользовательские сценарии. ИИ-функциональность теперь доступна в настольном текстовом редакторе «МойТекст», в веб-редакторах, а также в приложении для совместной работы «МояДоска». Обновление позволит сократить время выполнения рутинных задач и повысить качество контента. При этом генеративный ИИ может использоваться как в облаке, так и в закрытом контуре. В случае работы по модели on-premise обеспечивается полная безопасность корпоративных данных.</p> <p>Начиная с релиза 26.1, пользователям настольного редактора «МойТекст» доступен встроенный ИИ-помощник. Это собственная разработка «МойОфис», которая расширяет возможности настольных редакторов за счет интеграции технологий искусственного интеллекта в привычную работу с документами.</p> <p>Спектр возможностей ИИ-помощника в «МойТекст» покрывает большинство ежедневных рутинных задач: он умеет генерировать и редактировать тексты под запрос и необходимую тональность, исправлять грамматические ошибки, выполнять перевод на иностранные языки, делать содержательную выжимку из больших объемов информации. Пользователь может общаться с помощником в режиме вопросов и ответов, настраивая его роль — юриста, бухгалтера или аналитика, тон ответа — от делового до неформального, и формат ответа — сжатый или развернутый. ИИ-помощник активируется с панели управления редактора в один клик.</p> <p>ИИ-помощник способен функционировать без постоянного подключения к интернету. В случае работы в закрытом контуре загруженные пользователем данные остаются внутри компании и обрабатываются в «МойТекст». Это критически важно для организаций с высокими требованиями к информационной безопасности. На текущем этапе пилотного тестирования ИИ-функциональность предоставляется бесплатно, и для ее активации достаточно оставить заявку на получение расширенного дистрибутива.</p> <p>В релизе 26.1 ИИ-помощник также стал доступен в веб-редакторах текста, таблиц и презентаций. Пользователи «Документы Онлайн» теперь могут генерировать контент, создавать черновики писем, улучшать стилистику, переводить тексты, получать ответы на вопросы и оперативно выделять суть из многостраничных документов и переписок. Как и в настольной версии, ИИ-помощник в веб-редакторах позволяет настраивать его под нужную роль и гибко менять формат выдачи информации.</p> <p>ИИ-помощник способен работать как в облаке, подключаясь к внешним большим языковым моделям (LLM) через API, так и внутри корпоративного контура. В сценарии on-premise конфиденциальные данные не покидают периметр компании.</p> <p>ИИ-функциональность в веб-редакторах выходит в Бета-версии.</p> <p>Еще одним нововведением релиза 26.1 стала ИИ-функция генерации схем и диаграмм в приложении для совместной работы «МояДоска». Пользователю достаточно описать желаемый результат словами в диалоговом окне. Искусственный интеллект самостоятельно анализирует текстовое описание и преобразует его в Mermaid-разметку. Сгенерированная схема отображается в превью, после чего ее можно добавить на доску или скорректировать — изменить промт и сгенерировать заново.</p> <p>«Мы проработали сценарии, в которых искусственный интеллект дает ощутимую экономию времени и рост продуктивности, и в релизе 26.1 развернули ранее анонсированную ИИ-функциональность. При этом наш ключевой принцип неизменен: ускорение бизнес-процессов не должно достигаться ценой потери контроля над данными. Именно поэтому мы реализовали возможность работы ИИ как в облаке, так и в закрытом корпоративном контуре — это позволяет нашим клиентам пользоваться преимуществами генеративного ИИ, не нарушая внутренние политики безопасности», — сказал генеральный директор МойОфис Вячеслав Закоржевский.</p> <p>Кроме того, в состав релиза вошел ряд обновлений редакторов «Документы Настольные», включая улучшения интерфейса и новые функции для повседневной работы.</p> «МойОфис», российская продуктовая ИТ-компания, представила масштабное обновление — релиз «МойОфис» 26.1. В фокусе … message https://www.itweek.ru/themes/detail.php?ID=234702 Tue, 21 Apr 2026 17:10:59 +0300 <p>«Северный Народный Банк» (АО) объявил о вводе в промышленную эксплуатацию модуля Автоматизированной упрощённой системы налогообложения (АУСН) компании BSS. Теперь клиенты банка из сегмента микро- и малого бизнеса, могут подключиться к бездекларационному налоговому режиму и управлять им напрямую из интерфейса дистанционного банковского обслуживания (ДБО).</p> <p>«Северный Народный Банк» — универсальный кредитный институт, работающий в Республике Коми и Москве. Банк обслуживает как физических лиц, так и представителей малого и среднего предпринимательства, предлагая широкий спектр продуктов: от расчётно-кассового обслуживания до кредитования и операций с ценными бумагами. Цифровизация сервисов для бизнеса является одним из стратегических приоритетов банка, что подтверждается последовательным внедрением современных технологических решений.</p> <p>Автоматизированная упрощённая система налогообложения — специальный налоговый режим, действующий в России в рамках эксперимента до конца 2027 года. Он позволяет предпринимателям с годовым доходом до 60 млн рублей и численностью сотрудников до 5 человек полностью передать функции налогового администрирования банку и ФНС: налог рассчитывается автоматически на основе банковских транзакций, декларация не требуется. С 2026 года актуальность АУСН возросла: при доходе свыше 20 млн рублей на традиционной УСН бизнес обязан уплачивать НДС, тогда как на АУСН этот налог не применяется.</p> <p>Ключевым фактором при выборе технологического партнёра стала подтверждённая экспертиза BSS в области внедрения АУСН. На сегодняшний день решение компании работает в шести банках: Ак Барс Банк, СДМ-Банк, СНГБ, Банк «Центр-инвест», Абсолют Банк и Фора-Банк. Ещё два кредитных учреждения, включая Северный Народный Банк, завершили внедрение. Решение BSS построено на платформе Digital2Go — универсальной среде для быстрого создания банковских сервисов. </p> <p>В состав модуля АУСН входят:</p> <ul> <li>клиентский интерфейс в ДБО для управления налоговым режимом;</li> <li>расчётный модуль НДФЛ;</li> <li>интеграционный адаптер для защищённого обмена данными с ФНС России.</li> </ul> <p>Важно отметить: BSS — ведущий вендор на российском рынке, предлагающий полностью готовое промышленное решение по АУСН, прошедшее аккредитацию ФНС. Средний срок внедрения «под ключ» составляет около двух месяцев, что в <nobr>3–5</nobr> раз быстрее самостоятельной разработки, а бюджет проекта — существенно ниже </p> <p>«Запуск АУСН в нашем ДБО — логичный шаг в развитии цифровых сервисов для малого бизнеса Республики Коми. Мы стремились предложить клиентам максимально надёжное и проверенное решение, которое уже доказало свою эффективность в других банках. Партнёрство с BSS позволило нам быстро и без рисков пройти все этапы аккредитации в ФНС и вывести сервис в промышленную эксплуатацию. Теперь наши клиенты-предприниматели могут сосредоточиться на развитии бизнеса, делегировав налоговые вопросы автоматизированной системе», — отметила исполняющий обязанности Председателя Правления «Северный Народный Банк» (АО) Нелли Аверьянова.</p> <p>«Для нас каждый новый запуск АУСН — это подтверждение востребованности нашего подхода. Северный Народный Банк продемонстрировал системную работу: от анализа потребностей клиентов до технической реализации. Наше решение позволяет банкам любого масштаба соответствовать требованиям ФНС в сжатые сроки и с предсказуемым бюджетом. Особенно важно, что теперь предприниматели Коми получили доступ к федеральному налоговому инструменту, который реально снижает административную нагрузку на малый бизнес», — прокомментировала Юлия Савинова, руководитель направления по развитию цифровых продуктов Центра цифровых решений для бизнеса компании BSS.</p> <p>Эксперты прогнозируют, что к концу 2026 года число аккредитованных банков по АУСН может превысить 50 организаций. Для региональных игроков, таких как Северный Народный Банк, наличие готового решения становится конкурентным преимуществом в борьбе за лояльность клиентов МСБ. Сервис АУСН уже доступен для подключения в личном кабинете ДБО «Северного Народного Банка». Для перехода на новый режим предпринимателю достаточно подать заявление через банковский интерфейс — дальнейшее взаимодействие с налоговыми органами будет осуществляться в автоматическом режиме.</p> «Северный Народный Банк» (АО) объявил о вводе в промышленную эксплуатацию модуля Автоматизированной упрощённой системы … message https://www.itweek.ru/themes/detail.php?ID=234701 Tue, 21 Apr 2026 10:01:27 +0300 <p><em>Когда компании обучают ИИ на контенте, сгенерированном ИИ, производительность модели деградирует с каждым циклом. Расплата за эту ошибку уже наступает, отмечают опрошенные порталом </em><em>InformationWeek</em> <em>эксперты.</em></p> <p>Современные модели искусственного интеллекта становятся жертвами опасной уязвимости: отравления данных. Но кризис отравления данных вызван не только хакерами или злоумышленниками — или даже в основном не ими. Он вызван самими организациями. По мере того, как предприятия стремятся внедрить ИИ во все рабочие процессы, они незаметно и быстро заполняют свои внутренние базы данных сгенерированными ИИ сводками, электронными письмами, кодом и отчетами. Когда синтетический контент попадает в конвейеры обучения, используемые для создания и тонкой настройки моделей ИИ следующего поколения, происходит отравление данных.</p> <p>Для многих организаций ИИ-трансформация, в которую они инвестировали, теперь активно подрывает их ИИ-будущее, на которое они рассчитывают.</p> <p>«Происходит следующее: соотношение сигнал-шум обваливается, — говорит Дэниел Кимбер, генеральный директор австралийского стартапа Brainfish AI, специализирующегося на создании агентов ИИ. — Исходные человеческие рассуждения, знания о частных случаях и тонкий институциональный контекст размываются синтетическим контентом, который уже представляет собой абстракцию чего-то реального. Когда вы обучаете или дорабатываете модель на этих данных, вы учитесь ее не на опыте, а на копии копии».</p> <p>Конечным результатом отравления данных является риск, о котором многие CIO, возможно, уже знают: деградация модели. Однако сведение проблемы просто к «деградации модели» может скрывать то, что действительно стоит на кону — бизнес-результаты. Деградация модели может привести к деградации решений, которая происходит, когда решения — принимаемые машинами или людьми — основаны на искаженных анализе или результатах работы ИИ.</p> <p>«Потеря точности — это больше, чем деградация, это искажение. Проблемы обычно не проявляются линейно, а накапливаются незаметно и срабатывают одновременно, — говорит Збынек Сопух, технический директор ИБ-компании Safetica. — Потеря точности и петли обратной связи приводят к деградации решений в масштабе. Это означает, что вы переходите от проблемы модели к проблеме бизнеса».</p> <p>Отравление данных также может привести к удивительному разнообразию проблем, связанных с юридическим правом, соблюдением нормативных требований и институциональными знаниями. Согласно <a href="https://www.nature.com/articles/s41586-024-07566-y">исследованию</a> моделей ИИ, опубликованному в Nature.com в 2024 г., вызванная отравлением деградация данных необратима. Более того, по словам Дэна Ивцана, старшего директора по ИИ-продуктам компании Steno, поставщике юридического ИИ, это также приводит к потере «тонких, редких институциональных знаний, находящихся в хвостах распределения данных».</p> <p>«Засада в том, что беглость сохраняется, в то время как фактическая точность снижается, поэтому стандартные тесты полностью ее не учитывают», — добавляет он.</p> <p>Помимо потери точности, организации могут столкнуться с усилением предвзятости из-за таких факторов, как исчезновение данных, относящихся к группам меньшинств, и гомогенизация результатов, то есть их сближение с усредненным значением.</p> <p>«В юридическом ИИ это смещение может означать искаженные цитаты или неверные медицинские хронологии. Это реальный риск судебных исков о врачебной халатности, — говорит Ивцан. — Проверенный способ их предотвращения: всегда накапливайте реальные данные наряду с синтетическими. Никогда не заменяйте их».</p> <h3>Опасности повторяющихся циклов обратной связи</h3> <p>Отравление данных снижает ценность исходных данных, отмечает Рёдзи Мории, основатель токийской компании Insynergy.io, специализирующейся на управлении ИИ и архитектуре принятия ИИ-решений: «Данные рассматриваются как одноразовый ресурс, и вместо них используются производные значения. Это загрязняет обучающие данные и делает исходные данные менее релевантными».</p> <p>Вину за проблему можно возложить на корпоративную потребность в скорости, инстинктивное стремление людей к самому простому или просто на непонимание того, как на самом деле работает обучение и тонкая настройка ИИ. Независимо от причины или намерения, вред неоспорим.</p> <p>«То, что здесь описывается, — это „отравление данных во имя удобства“. Это не злонамеренно, но приведет к долгосрочному ущербу», — говорит Сопуч.</p> <p>Возложение вины на кого-либо имеет не такое большое значение, как способность осознать опасность сейчас.</p> <p>«На ранних этапах вы часто этого не замечаете: результаты выглядят нормально, контроль качества тоже пройден», — говорит Четан Саунданкар, генеральный директор индийской компании Coditation, которая разрабатывает и внедряет системы ИИ для корпоративных клиентов.</p> <p>Но это затишье перед бурей. «Через несколько недель или месяцев модель начинает ошибаться, причем ошибки трудно заметить, потому что ответы по-прежнему звучат вполне разумно, — отмечает он. — Инструмент для анализа кода начинает предлагать шаблоны, которые работают, но имеют уязвимости в системе безопасности. Модель обобщения начинает отбрасывать уточнения и нюансы, которые делали исходные документы полезными, сохраняя при этом авторитетный тон».</p> <p>Проблемы проникают во все важные аспекты деятельности успешной и прибыльной организации. Небольшие неточности, такие как неправильная оценка распределения ресурсов в облачных и инфраструктурных средах или неверная маркировка шаблонов использования, могут быстро накапливаться, объясняет Дирк Альшут, директор по маркетингу ​​люксембургской платформы управления облачными ресурсами Emma. В конечном итоге эти ошибки увеличивают затраты или приводят к снижению производительности с течением времени. «Обратная связь усугубляет ситуацию, потому что те же самые ошибочные результаты могут быть зарегистрированы и использованы повторно, закрепляя ошибку», — добавляет он. Это может оказать потенциально огромное влияние на бизнес.</p> <p>Еще одна проблема, которую заметил Альшут, — это потеря адаптивности. «ИИ, обученный на ИИ-выдаче, как правило, испытывает трудности, когда происходит что-то новое или неожиданное, потому что он не сталкивался с реальной вариативностью», — говорит он.</p> <p>По его словам, лучшая профилактика — это привязка обучающих данных к реальному поведению системы. «Используйте телеметрию реального времени, журналы и решения, проверенные людьми, в качестве источника достоверной информации и рассматривайте результаты, сгенерированные ИИ, как временные, а не основополагающие», — советует Альшут.</p> <h3>Надвигающийся коллапс модели</h3> <p>CIO необходимо понимать, что проблема отравления данных не заканчивается деградацией модели. Обучение на контенте, сгенерированном ИИ, может привести к «коллапсу модели», когда системы ИИ в конечном итоге полностью выходят из строя. По сути, это сводит инвестиции в ИИ к «убыткам от порчи» — они возникают, когда проекты становятся бесполезными до такой степени, что их невозможно восстановить, учитывая деградацию модели, данных и результатов.</p> <p>«Коллапс модели — это деградация, которая происходит, когда модели многократно обучаются на результатах других моделей. Со временем система становится более повторяющейся, менее детализированной и менее отражающей реальный мир», — объяснил Оли Остертаг, президент по платформам роста и ИИ компании PAR Technology, поставщике унифицированных коммерческих платформ для ресторанов и ритейла.</p> <p>Даже если организации развертывают вендорские ИИ-решения, причина коллапса может быть внутренней. «Разговоры о загрязнении данных ИИ, как правило, сосредоточены на обучении базовых моделей, то есть на том, как обучают OpenAI или Google, — говорит Кимбер. — Но более насущная проблема для большинства организаций возникает на один уровень ниже, в их собственной инфраструктуре знаний. Каждая компания теперь, по сути, занимается обучением моделей».</p> <h3>Восстановление модели и внедрение мер защиты</h3> <p>Первый шаг в решении проблемы отравления данных — это предотвращение ее усугубления. К счастью, есть способ восстановить производительность во время или после сбоя модели, хотя это требует значительных усилий. Профилактика всегда предпочтительнее, но если произошел сбой, решение состоит в переобучении на чистых данных для восстановления производительности, говорит Ивцан.</p> <p>Как утверждают авторы <a href="https://arxiv.org/abs/2404.01413">статьи</a>, сбоя можно избежать, если реальные данные накапливаются наряду с синтетическими данными, а не заменяются ими. Согласно другой <a href="https://arxiv.org/abs/2510.16657">статье</a>, даже несовершенная внешняя проверка может стабилизировать траекторию. В этом контексте «несовершенство» внешней проверки не означает использование источников или информации, которые могут быть ошибочными или неверными. Это означает использование таких методов, как выборочные проверки, экспертная оценка или основанное на опыте человеческое суждение, которые сами по себе не являются тщательной проверкой фактов, но все же, скорей всего, будут очень точными. Масштабная, целенаправленная проверка превосходит как полное отсутствие контроля, так и непрактичность исчерпывающей проверки фактов.</p> <p>Лучший вариант действий, если это возможно, — предотвращение.</p> <p>«Способ предотвратить это — проектировать системы с обратной связью человек-машина. Самые сильные системы — итеративные, человек-ИИ, ИИ-человек, где результаты постоянно формируются, проверяются и совершенствуются», — объясняет Кааре Веснаес, руководитель отдела инноваций агентства Ogilvy North America, занимающегося созданием брендов для компаний Fortune Global 500. Короче говоря, «самые сильные системы полагаются не только на ИИ. Они включают циклы человек-машина», — говорит он.</p> <p>Главная идея заключается в том, чтобы помнить, что ИИ хорош настолько, насколько хороши его данные, и действовать соответственно.</p> <p>«Компаниям необходимо защищать целостность своих данных. Это означает приоритетное использование высококачественных входных данных, созданных человеком, четкое разграничение синтетических и реальных данных и постоянное повторное внедрение в свои системы новых сигналов из реального мира», — считает Веснаес.</p> Когда компании обучают ИИ на контенте, сгенерированном ИИ, производительность модели деградирует с каждым … article https://www.itweek.ru/themes/detail.php?ID=234699 Mon, 20 Apr 2026 15:07:59 +0300 <p>Компания ITKey, российский разработчик и поставщик решений для построения корпоративной облачной инфраструктуры, объявила о выходе релиза KeyStack 2026.1 — одного из наиболее технологически значимых обновлений платформы. Новая версия сочетает актуальный OpenStack Epoxy с набором собственных промышленных доработок, ориентированных на безопасность, масштабируемость и эксплуатационную устойчивость распределенных инфраструктур.</p> <p>KeyStack — это облачная платформа для построения частных и публичных облаков в корпоративном и государственном сегменте. В версии 2026.1 продукт выходит на новый уровень зрелости: впервые на российском рынке коммерческий дистрибутив объединяет актуальный релиз OpenStack и готовые enterprise-функции «из коробки», ранее доступные только при значительных доработках.</p> <p>Ключевой особенностью релиза стало использование OpenStack Epoxy как базового слоя. Это обеспечивает прямой passthrough GPU для AI/ML-нагрузок без оверхеда виртуализации, поддержку OVN Southbound Relay для построения масштабируемых SDN-сетей между географически распределенными ЦОД, а также возможность обновления платформы без остановки сервисов (SLURP).</p> <p>Дополнительно платформа получила ряд собственных доработок, усиливающих контроль, наблюдаемость и безопасность инфраструктуры. В KeyStack 2026.1 реализован сквозной аудит с передачей реального IP-адреса пользователя в SIEM, детализированная история операций в AdminUI с возможностью фильтрации и экспорта, централизованный планировщик задач, а также механизм резервного копирования с автоматической проверкой восстановления и SHA256-валидацией.</p> <p>«KeyStack 2026.1 — это переход от набора инструментов к целостной платформе, где безопасность, масштабируемость и эксплуатация заложены на уровне архитектуры. Мы фактически убрали необходимость доработок OpenStack под требования enterprise-сегмента и сделали их частью продукта по умолчанию», — отметил Алексей Шарандин, руководитель продукта KeyStack.</p> <p>Отдельное внимание в релизе уделено построению отказоустойчивых распределенных инфраструктур. Поддержка OVN SB Relay позволяет управлять сетью тысяч узлов как единой системой, а интеграция с Prometheus, Grafana и AlertManager расширяет возможности мониторинга и автоматической оптимизации ресурсов.</p> <p>С точки зрения информационной безопасности платформа реализует комплексный подход secure-by-default. В систему встроены механизмы автоматической ротации mTLS-сертификатов и учетных данных, контроль выполнения задач через whitelist, а также сквозной аудит в формате CADF. Это снижает риски утечек данных, несанкционированных действий и ошибок эксплуатации без усложнения управления системой.</p> <p>Новая функциональность ориентирована на крупные организации с распределенной инфраструктурой и повышенными требованиями к надежности и защите данных — банки, государственные структуры, телеком-операторы, ритейл и промышленные предприятия. Для них обновление означает снижение совокупной стоимости владения за счет NFVi-подхода, сокращение операционных затрат и повышение устойчивости сервисов.</p> <p>«Мы видим, что ключевой запрос рынка — это не просто облачная платформа, а управляемая и предсказуемая инфраструктура. В этом релизе мы сделали акцент на устранении эксплуатационных рисков: автоматизировали рутинные операции, обеспечили контроль целостности данных и повысили прозрачность всех действий в системе», — добавил Максим Куликов, владелец продукта KeyStack.</p> <p>Среди практических эффектов внедрения KeyStack 2026.1 — возможность запуска AI-моделей на GPU в виртуальных машинах без выделения физической инфраструктуры, построение отказоустойчивых сетей между ЦОД без дополнительного оборудования, обновление платформы без простоев и гарантированное восстановление данных при авариях.</p> <p>Релиз KeyStack 2026.1 уже доступен для российских компаний.</p> Компания ITKey, российский разработчик и поставщик решений для построения корпоративной облачной инфраструктуры, объявила … message https://www.itweek.ru/themes/detail.php?ID=234698 Mon, 20 Apr 2026 15:00:08 +0300 <p>MWS Cloud, входит в МТС Web Services, объявила о выводе сервиса Managed Kafka в промышленную эксплуатацию (GA) в облаке MWS Cloud Platform. Новый PaaS‑сервис позволяет компаниям использовать Apache Kafka как инфраструктурный компонент для потоковой обработки данных и event-driven архитектур без необходимости самостоятельно разворачивать и обслуживать кластеры, настраивать сеть и управлять жизненным циклом Kafka. Это снижает операционные риски и позволяет командам быстрее запускать data-driven сценарии и сокращать time-to-market.</p> <p>Event-driven архитектуры становятся стандартом для современных цифровых продуктов, а компании всё чаще переходят от batch‑обработки к потоковой — для real-time аналитики, интеграции микросервисов, построения пайплайнов обработки данных и КХД, а также решений для IoT и телеметрии. При этом self-managed Kafka требует высокой инженерной экспертизы и остаётся сложной в эксплуатации из‑за чувствительности к сетевой архитектуре, задержкам и стабильности соединений.</p> <p>Managed Kafka — это полностью управляемый сервис Apache Kafka в MWS Cloud Platform, который позволяет разворачивать кластеры за несколько минут. Сервис ориентирован на средние и крупные компании, технологические стартапы и команды, которые развивают микросервисные продукты и платформы данных, включая DevOps/SRE-инженеров, дата-инженеров и бэкенд-разработчиков.</p> <p>Kafka чувствительна к сетевой архитектуре: задержкам, маршрутизации трафика и стабильности соединений. Managed Kafka объединяет Kafka с управляемой сетевой инфраструктурой MWS Cloud Platform, чтобы обеспечить предсказуемое поведение потоковых систем даже под высокой нагрузкой. Сервис спроектирован с упором на безопасность и изоляцию: кластеры разворачиваются в изолированной инфраструктуре на уровне виртуальных машин, что позволяет снизить влияние соседних нагрузок по сравнению с мультиарендными реализациями. Для приватных сценариев доступно подключение через Private Link, упрощающее построение безопасного периметра и обеспечивающее приватную связность внутри облака.</p> <p>В рамках сервиса доступны multinode‑кластеры «из коробки». Управление осуществляется через консоль MWS Cloud Platform, а также с использованием CLI и API. Сервис интегрирован с Audit Logs, что упрощает контроль действий и соответствие требованиям безопасности.</p> <p>Managed Kafka может применяться для построения event-driven архитектур и интеграции микросервисов, аналитики в реальном времени (дашборды и алерты), потоковых пайплайнов (в том числе Kafka → ClickHouse / DWH / ML), централизованного сбора логов, а также IoT и телеметрии.</p> <p>«Потоковая обработка данных и event-driven архитектуры становятся базовым сценарием для цифровых продуктов, но Kafka остаётся требовательной к инфраструктуре и сети. Мы запустили Managed Kafka как полностью управляемый сервис, который разворачивается за минуты и готов к продакшен-использованию, при этом давая большую гибкость в масштабировании. Это позволяет инженерным командам сосредоточиться на работе с данными и продуктовой логике, а не на эксплуатации Kafka кластера», — отметил Дмитрий Черёмухин, руководитель направления платформы данных в MWS Cloud Platform.</p> <p>Развернуть Kafka‑кластер в MWS Cloud Platform можно в режиме self-service через консоль управления, а также с использованием CLI и API.</p> MWS Cloud, входит в МТС Web Services, объявила о выводе сервиса Managed Kafka в промышленную эксплуатацию (GA … message https://www.itweek.ru/themes/detail.php?ID=234697 Mon, 20 Apr 2026 14:57:14 +0300 <p>В условиях нестабильной экономики российский бизнес переходит на low-code/no-code платформы, видя в них инструмент для быстрого цифрового рывка без капитальных затрат на разработку и содержание штата ИТ-специалистов. По данным GreenData, доля компаний, где есть хотя бы один рабочий контур на low-code/no-code или платформа с low-/no-code слоем находится в промышленной эксплуатации, к началу 2026 года приблизилась к <nobr>65-68%.</nobr> Рынок переходит от точечных внедрений «коробок» к платформенному мышлению и массовому использованию таких инструментов.</p> <p>Лидирует по проникновению low-/no-code финансовая сфера — порядка 88% банков и финансовых организаций уже перешли на low-code. Такие решения активно применяют в бэк-офисе, workflow-системах, риск-менеджменте и CRM — там, где где важны скорость изменений, гибкость и быстрая адаптация процессов. Напротив, почти не используют low-/no-code в сложных расчетах и казначейских ядрах. Эти задачи требуют высокой точности при обработке огромного числа транзакций — low-code здесь чаще выступает оболочкой или расширением.</p> <p>Второе место занимает ритейл. По оценкам GreenData, low-/no-code платформы используют сегодня до 60% крупных и средних сетевых ритейлеров. Наиболее востребованы такие решения в контуре ERP, CRM, партнерских сценариях, сервисных операциях и быстрых кастомизируемых функциях — в тех зонах, где требуется быстрое внедрение новых функций, которых нет в стандартных отраслевых продуктах, без масштабной ИТ-разработки. </p> <p>Слабее всего low-/no-code в ритейле проявляет себя в решении таких сложных задач, как ценообразование в реальном времени и собственные e-commerce сценарии. Таким образом, low-code в ритейле чаще закрывает задачу внедрения быстрых кастомных функций поверх ландшафта, а не заменяет его целиком.</p> <p>Наконец, тройку лидеров по внедрению low-/no-code замыкают строительство и девелопмент. Около 40% крупных и средних застройщиков и подрядчиков уже применяют такой подход — чаще всего в решениях для документооборота, управления подрядчиками, автоматизации HR, а также в разработке личных кабинетов и координационном слое проектов. Реже — в тяжелом инженерном ядре: BIM/CAD, инженерном моделировании, при формировании сложного календарно-сетевого графика или смет.</p> <p>Среди догоняющих по уровню проникновения low-/no-code — промышленность, агрокомплекс и сфера услуг. Это связано с разными факторами: от сложных бизнес-процессов до более низкого, в сравнении с лидерами, уровня цифровизации. В этих отраслях low-/no-code платформы пока решают отдельные нишевые задачи: от управления оборудованием до документооборота с контрагентами. </p> <p>По оценкам GreenData, бизнес рассматривает low-/no-code инструменты не как замену всему ИТ-ландшафту, а как быстрый и сравнительно недорогой способ закрыть прикладные задачи — от запуска клиентских сервисов до автоматизации внутренних процессов. При этом они по-прежнему слабо представлены в сегментах, где критичны высокая точность расчетов или специализированная инженерная логика. </p> <p>«Low-code — это своего рода „мост“, который позволяет оперативно адаптировать высоконагруженные бизнес-критичные приложения под меняющиеся клиентские сценарии и требования рынка и бизнеса. Именно поэтому популярность таких технологий в ближайшее время будет лишь расти: в условиях турбулентной экономики компаниям важно не „уронить“ уровень цифровизации — и при этом закрывать задачи минимальными усилиями и ресурсами», — отметил Сергей Лебедев, коммерческий директор GreenData.</p> В условиях нестабильной экономики российский бизнес переходит на low-code/no-code платформы, видя в них инструмент … message https://www.itweek.ru/themes/detail.php?ID=234695 Mon, 20 Apr 2026 10:12:41 +0300 <p><em>В новом отчете </em><em>Forrester</em> <em>«</em><em>Physical</em> <em>AI</em> <em>Perceives</em><em>, </em><em>Reasons</em><em>, </em><em>And</em> <em>Acts</em> <em>In</em> <em>The</em> <em>Real</em> <em>World</em><em>» утверждается, что более важной темой, по сравнению с темой роботов-гуманоидов, является растущий потенциал физического искусственного интеллекта. Человекоподобные роботы безусловно выигрывают от этого, но то же самое можно сказать и о многих других типах физической автоматизации — и большинство из них дешевле, долговечнее и полезнее, чем набор компромиссов, необходимых для того, чтобы втиснуть батареи, компьютеры, датчики, исполнительные механизмы и многое другое в приблизительно человекоподобную форму, пишет в корпоративном блоге Пол Миллер, вице-президент и главный аналитик </em><em>Forrester</em><em>.</em></p> <h3>Как физический ИИ соприкасается с реальным миром</h3> <p>Физический ИИ — это прежде всего внедрение ИИ в реальный мир, обеспечение осведомленности ИИ о происходящем вокруг и предоставление ИИ возможности влиять — соприкасаться — с этим миром. Физический ИИ включает в себя ряд широких возможностей. Каждая из них сама по себе является огромной областью быстро развивающихся исследований, но нечто особенное происходит, когда все они объединяются для создания физического ИИ, который:</p> <ul> <li><strong> Моделирует и имитирует реальный мир.</strong> Современные модели мира — это нейронные сети, обученные на большом объеме данных. В отличие от большой языковой модели (LLM), которая генерирует текст, эти модели мира симулируют физические пространства и генерируют взаимодействия внутри них. Хотя модель мира может и не до конца понимать закон всемирного тяготения Ньютона или уравнения движения с квадратичным сопротивлением, используемые для учета трения, она наблюдает их эффекты и может воспроизвести их для моделирования падающего объекта.</li> <li><strong> Воспринимает реальный мир.</strong> Cистемы физического ИИ обогащаются широким спектром соответствующих входных данных от датчиков реального мира, включая звук, свет, температуру, тактильную обратную связь и многое другое.</li> <li><strong> Рассуждает о реальном мире.</strong> В контексте физического ИИ концептуальные модели и наблюдения на основе датчиков являются средством достижения цели: они предоставляют физической системе ИИ факты, необходимые ей для рассуждений о том, как лучше всего достичь своей цели.</li> <li><strong> Действует в реальном мире.</strong> Концептуальные модели, наблюдение на основе датчиков и рассуждения ИИ в сочетании с физическими системами, такими как руки робота или рулевое управление беспилотного автомобиля, позволяют осуществлять изменения в реальном мире: робот поднимает банан, не сжимая его слишком сильно, а беспилотный автомобиль объезжает препятствие на своем пути. Эти возможности могут быть реализованы в физической машине (например, в роботе или беспилотном автомобиле), и в этом случае такая способность часто называется воплощенным ИИ.</li> </ul> В новом отчете Forrester «Physical AI Perceives, Reasons, And Acts In The Real World » утверждается, что более … article https://www.itweek.ru/themes/detail.php?ID=234694 Mon, 20 Apr 2026 10:02:48 +0300 <p><em>По мере того, как инструменты программирования на основе ИИ превращают не-разработчиков в создателей, появляется новая категория гипер-кастомизированного, экономически жизнеспособного ПО — и это меняет то, как работают команды, пишет на портале </em><em>The</em> <em>New</em> <em>Stack</em> <em>Джессика Вахтель, специалист по контент-маркетингу компании <a name="OLE_LINK8">InfluxData</a>.</em></p> <p>Как известно, Claude Code от Anthropic активно меняет способы создания ПО. Но новость в том, кто его создает. Разработка смещается от разработчиков ко всем остальным. Инструмент агентного кодирования Claude Code делает разработку такой же простой, как описание того, что вы хотите. И простота его использования не является секретом.</p> <p>Claude Code кардинально меняет то, как работают корпоративные инженерные команды. Еще интереснее то, как он демократизирует разработку ПО и предоставляет те же возможности командам, которые раньше полагались на SaaS и инженерных специалистов. Теперь люди из таких областей, как маркетинг, финансы и продажи, могут сами создавать ПО. Вокруг новой идеи о том, что любой может создать необходимое ему ПО, формируется целая экосистема.</p> <p>Claude Code не одинок. Другие платформы для создания приложений, не требующие технических навыков, также быстро развиваются. Согласно обобщенной <a href="https://getmocha.com/blog/ai-app-builder-statistics">статистике</a>, доход Lovable увеличился на 2800% за один год, а Replit вырос в 15 раз. Интерес к созданию ПО значительно расширился за пределы сферы профессиональной разработки.</p> <p>Добро пожаловать в эпоху расцвета «персонального ПО». Под этим термином понимается любое ПО, разработанное для удовлетворения уникальных потребностей человека, системы или команды. Это включает в себя ПО, которое приносит пользу как отдельному человеку, так и предприятию. Недавний опрос Retool показал, что 35% компаний уже заменили как минимум один SaaS-инструмент на тот, который они разработали сами, а 78% ожидают, что в 2026 г. они создадут еще больше таких инструментов. По словам генерального директора Retool Дэвида Хсу, основной вопрос в залах заседаний совета директоров смещается с «что нам купить?» на «можно ли просто это создать?».</p> <h3>Итак, как выглядит персональное ПО?</h3> <p>Тейлор Хоук, руководитель направления эффективности облачных вычислений и ИИ компании PointFive создал такое ПО менее чем за неделю, используя Claude Code. Это было решение проблемы, с которой он сталкивался каждый день, которую не решало ни одно существующее ПО и которая была недостаточно масштабной, чтобы оправдать затраты на наем команды инженеров для создания чего-то уникального.</p> <p>Команда Хоука была задействована в рабочем процессе создания контента, зависящем от людей. Кто-то заполнял форму. Член команды брал эти данные, проверял их и составлял драфт контента. Этот черновик вставлялся в общий документ Google Docs и отправлялся автору по электронной почте для проверки. Автор оставлял отзыв. Команда дорабатывала текст. После утверждения кто-то вручную загружал его в CMS. Просто и понятно, но каждый шаг был узким местом и потенциальной точкой отказа. Рабочий процесс работал, но не без задержек.</p> <p>И он остался бы таким, каким он был, если бы Хоук не автоматизировал его с помощью Claude Code. Но он это сделал, и теперь рабочий процесс полностью автоматизирован. Как только кто-то заполнит форму, веб-хук запускает агентную систему, размещенную на AWS Lambda и работающую на основе базы данных DynamoDB. Система проверяет отправленный контент, формирует черновик, генерирует URL-адрес для проверки и автоматически отправляет его по электронной почте автору. Автор просматривает его, предлагает правки или утверждает напрямую. Каждое действие автоматически запускает следующий шаг в рабочем процессе. Никто никого не ждет. После полного утверждения одним щелчком мыши контент размещается на веб-сайте через прямую интеграцию с CMS.</p> <p>На создание всего решения ушло меньше недели, оно на 100% разработано Claude Code и включает 130 файлов и 85 тыс. строк кода.</p> <p>Это простое, даже скучное ПО. Но в то же время, оно никогда бы не появилось раньше. Не потому, что идея была слишком сложной. А потому, что создание чего-то настолько специфичного для одной команды никогда не было экономически целесообразным, ведь традиционная разработка ПО требует месяцев работы инженеров, зарплат и затрат на инфраструктуру. Раньше для такой узкоспециализированной задачи «это просто никогда не было бы экономически целесообразным, — говорит Хоук. — На создание такого ПО потребовалось бы много времени инженеров. Теперь же его эксплуатация обходится менее чем в 5 долл. в месяц, а создал я его в рамках подписки на Claude за 200 долл. в месяц».</p> <p>Хоук не разработчик. Он описывает себя как человека, «достаточно знающего, чтобы быть опасным», с опытом работы в области облачной инфраструктуры, а не разработки ПО. У него не было необходимых знаний для написания кода, но он смог направлять Claude Code при разработке приложения. Прежде чем была написана хоть одна строка, он часами работал с Claude в режиме планирования, определяя требования, обсуждая архитектуру и тестируя решения на прочность.</p> <p>В результате Claude даже развернул приложение. Хоук так описывает свой опыт: «Я предоставил Claude учетные данные AWS, и он выполнил все развертывания за меня. Мне не пришлось даже щелкать мышкой. Мне не нужно было ничего делать в AWS вручную».</p> <p>На этом все не закончилось: как ожидается, Claude Code принесет Хоуку и его команде еще больше пользы. Приложение использует два сторонних SaaS-инструмента: Typeform для создания форм и Webflow для веб-сайта. Хоук уже самостоятельно создал замены обоим инструмента, используя Claude Code, и готовится к их внедрению в производство. Сейчас он перестраивает стек SaaS для своего персонального ПО.</p> <p>Делясь с другими своим первым опытом работы с Claude Code, Хоук говорит: «Есть сценарии использования, о которых я никогда бы не подумал. У каждого из нас свой опыт и набор навыков. Используйте свое уникальное видение и опирайтесь на эти инструменты как на множитель силы».</p> <p>И последствия выходят за рамки повышения индивидуальной производительности. Хоук видит в Claude Code повышение уровня всего персонала: «Отдельные сотрудники, использующие эти инструменты, теперь становятся менеджерами, а менеджеры, управляющие командами, теперь становятся директорами. Практически у каждого есть доступ ко всем этим инструментам».</p> <h3>Новая тенденция в разработке персонального ПО</h3> <p>Хоук не одинок. Ондрей Машар, руководитель отдела продуктов компании Livesport, использовал Claude Code для создания 13 проектов за 6 месяцев. В своей <a href="https://medium.com/@ondrej.machart/13-claude-code-projects-that-changed-my-product-manager-role-over-the-last-6-months-7057b9045d51">статье</a> на Medium под названием «Уроки 13 проектов на Claude Code, которые изменили мою роль менеджера по продуктам» он рассказывает о создании нативного iOS-приложения, инструмента, который помог высшему руководству его компании принять важное решение о консолидации продуктов, — всё это с помощью Claude Code, а также личного трекера задач.</p> <p>Приложение Машара начиналось не на Claude Code. Он пробовал Replit, Lovable и другие инструменты вайб-кодинга, но ни один из них не предлагал того, что ему было нужно. По совету коллеги он начал использовать Claude Code в терминале. Он потратил два месяца, изучая основы по вечерам и ночам, движимый не желанием разбогатеть в одночасье, а желанием создать что-то, чем люди действительно могли бы пользоваться.</p> <p>Его первый проект, нативное iOS-приложение для родителей, позволяющее находить ближайшие детские площадки, попал в App Store с моделью подписки и интеграцией API сторонних разработчиков. «Я не стал инженером и не планирую им становиться, — написал Машар. — Но я стал более разносторонним в плане понимания других областей и сфер деятельности. Это ценно, потому что это способствует эмпатии».</p> <p>Как и Хоук, Машар не является инженером-программистом. Ни один из них не ставил перед собой цель создать «единорога» (пока что). Им обоим требовалось ПО, которого не существовало, и поэтому они использовали Claude Code для решения этой проблемы. И преуспели. Проблемы, которые раньше не имело смысла решать, теперь стали решаемыми. Claude Code не просто ускорил разработку ПО. Он сделал её персональной.</p> По мере того, как инструменты программирования на основе ИИ превращают не-разработчиков в создателей … article https://www.itweek.ru/themes/detail.php?ID=234690 Fri, 17 Apr 2026 13:41:48 +0300 <p>На прошедшей в апреле выставке «Связь-2026» я провёл несколько дней в плотном общении с инженерами, техническими директорами и интеграторами. Несмотря на внушительные цифры площадки (15 000 м² экспозиции, более 360 компаний-участниц из России, Китая и Беларуси и свыше 16 000 посетителей), моё главное наблюдение отличается от официальных пресс-релизов. Выставка сохраняет статус одного из основных отраслевых событий, но её целевой фокус заметно размылся: аудитория стала шире и разнороднее, а концентрация узкопрофессиональных контактов снизилась. При этом чётко проступил новый тренд.</p> <p>Телеком-заказчики больше не ищут «ещё одно устройство». Они ищут предсказуемость. Ошибка в интеграции магистрального канала или ЦОДа измеряется не просто финансовыми потерями, а нарушением связности целых регионов. Поэтому рынок окончательно уходит от модели «коробочных» поставок. Сегодня ценность создаётся не объёмом отгруженного оборудования, а качеством инженерного сопровождения на всём жизненном цикле: от калибровки и сквозного тестирования до постпродажной поддержки без потери заводской гарантии.</p> <p>Параллельно моновендорность окончательно уходит в прошлое. Интегратор превращается из поставщика в архитектора совместимости. Рост присутствия производителей из КНР на площадке лишь подтверждает глобальную перестройку логистических цепочек. Для интегратора это означает новую задачу: как обеспечить бесшовную работу разнородного оборудования в единой инфраструктуре? Ответ — в создании единых стандартов мониторинга и управления. Компонент может быть любым, но если он проходит лабораторные испытания, калибруется по регламентам вендора и встраивается в общую систему контроля — заказчик получает надёжное решение, а не «лоскутное одеяло».</p> <p>Это напрямую влияет на требования к кадрам. Квалификация инженера для телеком-вертикали сегодня должна позволять действовать не только по инструкциям, но и в условиях отсутствия готовых сценариев. Отрасль делает ставку на внутреннее наставничество, обязательную сертификацию у производителей и регулярные полевые испытания оборудования в сложных климатических условиях. Без этого невозможно гарантировать бесперебойность.</p> <p>Что касается трафика: да, темпы роста снизились из-за внешних ограничений, но потребность в цифровизации не исчезает. Заказчики смещают фокус с простого наращивания мощностей на оптимизацию ресурсов и энергоэффективность. Современные платформы для магистралей уже позволяют передавать до 800 Гбит/с на одну длину волны за счёт адаптивной модуляции, а архитектура решений поддерживает поэтапное масштабирование. Это даёт возможность снижать CAPEX на старте проектов и гибко управлять OPEX в эксплуатации.</p> <p>Традиционные выставки постепенно трансформируются в площадки демонстрации оборудования и нетворкинга. Потребность же в глубокой технической проработке инфраструктурных задач только растёт. Именно поэтому профессиональное сообщество всё активнее развивает альтернативные форматы: узконаправленные технические сессии, где обсуждаются не общие тренды, а конкретные инженерные кейсы, реальные ограничения и рабочие решения. И это, на мой взгляд, и есть новый вектор развития отрасли.</p> <p>#IMAGE_234691#</p> На прошедшей в апреле выставке «Связь-2026» я провёл несколько дней в плотном общении с инженерами … article Егор Батаев, генеральный директор “БАЗИС ТЕЛЕКОМ” https://www.itweek.ru/themes/detail.php?ID=234689 Fri, 17 Apr 2026 13:40:46 +0300 <p>Компания Positive Technologies разработала нейросеть для обнаружения вредоносного кода. Модель ByteDog основана на архитектуре «трансформер», которую используют LLM (большие языковые модели). В отличие от классических моделей, ByteDog работает не с текстом или изображениями, а анализирует и понимает файлы как они есть — в виде байтов. Это позволяет ей определять вредоносное ПО на 20% точнее, чего раньше не могла достичь ни одна классическая модель машинного обучения. Это первая подобная разработка в информационной безопасности в России и Европе.</p> <p>ИИ давно применяется в кибербезопасности, но до сих пор требовал ручной подготовки данных под каждый новый вид вирусов: разметчики извлекали из файлов признаки (опкоды, подстроки, структуру импортов), по которым нейросети учились отличать вредоносный код от обычного.</p> <p>ByteDog убирает этот этап. После обучения модель анализирует байты файла напрямую — в том же виде, как они хранятся на ПК, смартфоне, в облаке или интернете. ByteDog способна сама учиться находить закономерности, экстраполировать их и обнаруживать угрозы, которые ранее не встречались в данных. Этим она превосходит системы, основанные на жестких, фиксированных правилах. Примерно так же LLM учатся понимать текст, не зная заранее грамматических правил: они обрабатывают последовательности символов и выстраивают внутренние представления о структуре языка. Только вместо слов и предложений здесь обычные файлы.</p> <p>«Обучение и тестирование ByteDog проводились образцах из реальных киберинцидентов на протяжение года. Модель продемонстрировала превосходство над классическими <nobr>ML-моделями</nobr> по качеству детектирования и скорости анализа — разница составила более 20%. ByteDog будет интегрирована в ряд продуктов и сервисов Positive Technologies по обнаружению киберугроз», — прокомментировал Андрей Кузнецов, <nobr>ML-директор</nobr> Positive Technologies.</p> <p>Один из примеров эффективности модели: представим, что сотрудник получает по электронной почте файл, который выглядит как счет от подрядчика, но сам вирус скрыт внутри файла. Чтобы его обнаружить классическими методами, антивирусу нужно совершить несколько операций, которые занимают время: распаковать файл, извлечь исходный код, пропустить данные через фиксированные антивирусные правила. ByteDog, работая на устройстве сотрудника, пропускает все эти шаги и видит файл так, как его и операционная система — последовательностью байтов. Если в этой последовательности есть признаки, характерные для вредоносного кода, модель их обнаружит даже если вирусы спрятаны сложным способом.</p> <p>Главная техническая сложность при разработке — длина входных данных. Если большая языковая модель работает, в среднем, с контекстом до 128 тысяч токенов, то обычный файл — это мегабайты, то есть миллионы байт, ни один из которых нельзя пропустить. Для решения этой проблемы модель анализирует файлы фрагментами, а затем собирает общую картину. ByteDog спроектирована так, что для применения уже обученной модели не нужен графический ускоритель, и она может работать на устройствах пользователей — ПК и смартфонах. </p> Компания Positive Technologies разработала нейросеть для обнаружения вредоносного кода. Модель ByteDog основана … message https://www.itweek.ru/themes/detail.php?ID=234688 Fri, 17 Apr 2026 13:39:10 +0300 <p>Рег.облако, облачный и Bare metal провайдер, объявил о запуске программы Free Tier (бесплатный уровень доступа), предназначенной для легкого входа бизнеса в облачные технологии без вложений. Первым продуктом в рамках программы стал базовый бесплатный облачный сервер с линейкой облегченных конфигураций, предназначенных для тестирования и запуска небольших проектов.</p> <p>Free Tier предусматривает бесплатный доступ к облачному серверу разной производительности. Например, минимальная конфигурация на срок до 6 месяцев включает сервер с одним виртуальным ядром, 1 ГБ оперативной памяти и 10 ГБ пространства на NVMe-накопителе — с возможностью ее расширения по запросу. Инфраструктура размещена в отказоустойчивом публичном облаке провайдера. В зависимости от выбранной модели сервер можно использовать для самых разных целей: размещения небольших сайтов, тестовых сред, учебных стендов или пет-проектов. А в расширенной конфигурации открываются возможности для развертывания небольших систем управления контентом (CMS) или CI/CD малого масштаба.</p> <p>Программа Free Tier будет развиваться в несколько этапов. Вторая и третья очередь будут направлены на более удобное использование возможностей сервера и представлены мощными конфигурациями. Следующие этапы направлены для решения ресурсоемких задач: от создания и управления серверами и сайтами до запуска тестовых сред, интернет-магазинов, CRM и сложных инфраструктур. Программой сможет воспользоваться и малый бизнес, и крупный бизнес — заинтересованный в диверсификации поставщиков. В компании уже открыли резервирование мест на новые этапы программы.</p> <p>Free Tier отличается от распространенных на рынке похожих предложений — Free Trial и тестовый период VPS — моделью использования, в рамках которой определенный уровень ресурсов предоставляется бесплатно на весь срок действия программы. В то время как Free Trial обычно предназначен для краткого знакомства с сервисом, после чего пользователь должен перейти на платный тариф или прекратить использование. Тестовый период VPS, которые предлагают хостинг-провайдеры, как правило, существуют как отдельные изолированные продукты с урезанными возможностями и без прямой интеграции в основную инфраструктуру.</p> <p>«Мы запустили по сути первый „живой“ Free Tier в России — программа будет расширяться в зависимости от запроса аудитории. Наша цель — снизить порог входа в облако для малого и среднего бизнеса. При дальнейшем росте проекта компании смогут перейти на более мощные конфигурации на коммерческой основе без переноса данных и изменения архитектуры. Аналогов подобного Free Tier в стране сейчас нет», — отметил Денис Прохорчик, исполнительный директор Рег.облака. </p> <p>Программа ориентирована как на начинающих разработчиков, стартап-проекты и малый бизнес, так и на зрелые компании, которые заинтересованы попробовать решения и сервисы новых поставщиков облачных продуктов. </p> <p>Запуск программы делает Рег.облако первым облачным провайдером в России, внедрившим модель бесплатного уровня доступа с возможностью перехода на основную инфраструктуру по похожим принципам международных облачных платформ. Модель бесплатного уровня доступа применяется крупнейшими мировыми облачными платформами и считается одним из ключевых инструментов развития экосистемы разработчиков.</p> Рег.облако, облачный и Bare metal провайдер, объявил о запуске программы Free Tier (бесплатный уровень доступа … message https://www.itweek.ru/themes/detail.php?ID=234687 Fri, 17 Apr 2026 11:31:02 +0300 <p><em>Анил Инамдар, руководитель Data Services в NetApp Instaclustr, рассказывает на портале </em><em>The</em> <em>New</em> <em>Stack</em> <em>о том, почему консолидация стека данных создает скрытый архитектурный долг и как инженерные руководители могут защитить автономию своих команд.</em></p> <p>Когда IBM объявила о приобретении Confluent (вскоре после поглощения DataStax) за 11 млрд. долл., большая часть комментариев была сосредоточена на том, что это означает для дорожной карты Kafka или сможет ли IBM реализовать стратегию нативно-облачной интеграции. Хотя это и разумные вопросы, инженерные руководители, вероятно, видят тему слишком узко.</p> <p>Что происходит с автономией инженеров, когда Open Source-инструменты, от которых зависит команда, перестают быть нейтральными?</p> <h3>Мы уже видели это кино раньше</h3> <p>Эта ситуация достаточно знакома, чтобы, вероятно, заслужить название. Появляется и получает широкое распространение некая Open Source-технология, потому что она действительно нейтральна и очень полезна. Никто ею не владеет, и никто полностью не контролирует ее дорожную карту. Опыт вашей команды в проектах может быть передан куда угодно, и технология становится отраслевым стандартом. Затем крупный игрок рынка приобретает коммерческую структуру, стоящую за этой технологией, и она постепенно (или, достаточно часто, не так уж и медленно) превращается из общедоступного актива в функционал платформы.</p> <p>Если вы определенного возраста, вы видели это на примере виртуализации, а затем и в начале облачной эры. Теперь мы наблюдаем, как это происходит одновременно в инфраструктурах потоковой передачи данных и баз данных. Инструменты обработки данных, от которых зависит ваш стек, поглощаются более широкими корпоративными решениями, перепозиционируясь из вариантов «лучшее в своем классе» в единый пакет функций.</p> <p>Чтобы было ясно, ничего из этого не является зловещим. Консолидация имеет смысл с точки зрения бизнеса, и иногда инженерные решения действительно становятся лучше с увеличением ресурсов. Но поглощение технологии устраняет то, что имело значение даже тогда, когда коммерческий поставщик создавал собственные функции на основе Open Source: конкурентное давление, направленное на то, чтобы клиенты могли уйти. До поглощения риск привязки к поставщику очень тщательно им управляется. После поглощения он становится особенностью платформенной стратегии материнской компании.</p> <h3>Неправильно обозначенный риск</h3> <p>Когда в разговорах руководителей поднимается вопрос о консолидации, обычно это воспринимается как проблема закупок. Ценовые рычаги и условия контрактов имеют значение, но они являются следствием более серьезной проблемы. Консолидация со временем и незаметно создает то, что я бы назвал архитектурным долгом. Разработчики говорят о техническом долге как об обходных путях в коде, которые нужно переделывать, но здесь все иначе. Архитектурный долг накапливается на уровне инфраструктуры, и его сложнее предвидеть.</p> <p>Когда поставщик интегрирует такой инструмент, как Apache Kafka, в свое собственное облако, он добавляет дополнительные уровни удобства. К ним могут относиться пользовательские API, специально разработанные коннекторы и механизмы безопасности, которые связаны с его более широкой платформой. Каждый из них сам по себе разумен, но в совокупности за <nobr>3-5</nobr> лет вы получаете нечто, что больше не является переносимой или стандартизированной инфраструктурой. Теперь у вас есть собственная реализация платформы конкретного поставщика, даже если она никогда не была разработана для этого.</p> <p>Долг такого типа не проявится при проверке кода или в вашей технической дорожной карте. Он обнаружится, когда вы попытаетесь мигрировать или пересмотреть условия контракта, и в этот момент затраты на устранение этих зависимостей могут оказаться ошеломляющими. Поставщики, конечно, это понимают. Высокая стоимость перехода — это их конкурентное преимущество, и она защищает их доходы независимо от того, продолжают ли они внедрять инновации в продукт, который вы приобрели.</p> <p>Подобная динамика существует и на нашем рынке управляемых сервисов, чтобы не показалось, что я критикую какую-то одну компанию. Любой поставщик управляемых услуг для инфраструктуры данных, который добавляет достаточное количество собственных инструментов поверх Open Source-технологий, создает ту или иную версию этой проблемы. Вопрос для инженерных руководителей заключается в том, создается ли эта зависимость сознательно или по умолчанию.</p> <h3>Затраты, которые не видны в вашей организационной структуре</h3> <p>По мере углубления архитектурного долга он тянет за собой многое другое.</p> <p>В нейтральной Open Source-среде ваши инженеры изучают основные технологии. Например, они понимают, как работает Kafka на уровне разделов и как Cassandra обеспечивает согласованность данных под нагрузкой. Это переносимые знания, принадлежащие инженеру, а не платформе.</p> <p>Однако в сильно управляемой, проприетарной среде команды перестают изучать потоковые данные и начинают изучать потоковый сервис поставщика X. Со временем экспертиза в базовой технологии атрофируется. Чем меньше команда способна работать с исходными технологиями, тем больше она зависит от управляемого уровня поставщика. Цикл замыкается сам на себя. Институциональные знания вашей организации незаметно превращаются в знания, специфичные для службы поддержки вашего поставщика ПО. Этот риск редко фигурирует в каком-либо реестре рисков и со временем накапливается.</p> <h3>Как на самом деле выглядит преднамеренная нейтральность</h3> <p>Это не аргумент против консолидации или довод о том, что каждая команда должна использовать собственную Open Source-инфраструктуру. Запуск Kafka в масштабе — это действительно сложная задача, и управляемые сервисы существуют не просто так.</p> <p>Руководителям необходимо понимать, что архитектурная нейтральность раньше автоматически обеспечивалась Open Source-инструментами. Сейчас это уже не так, и инженерные руководители, которые считают это само собой разумеющимся, принимают решение, которое заключается в том, что они его не принимают.</p> <p>Это имеет реальные последствия. Когда ваша команда оценивает управляемый сервис данных, вопрос о том, хороша ли технология сегодня, — это лишь часть обсуждения. Более полезный вопрос — будут ли создаваемые точки интеграции по-прежнему переносимыми через три года. Один из практических тестов — сможет ли ваша команда осуществить миграцию, если вам придется сменить поставщика через 18 месяцев, без многолетних усилий. Значительное сомнение само по себе является ответом.</p> <p>Настаивание на открытых стандартах вместо открытых API — это часть процесса принятия решения, как и дисциплина, при которой ваши внутренние платформы определяют интерфейс для инструментов поставщика. Если эта взаимосвязь направлена ​​в противоположную сторону, вы строите свою архитектуру на основе чужих решений.</p> <h3>Правило по умолчанию, не более того</h3> <p>Стек данных будет продолжать консолидироваться. Такова природа зрелого рынка, и инженерным руководителям придется принимать решения в рамках этой реальности.</p> <p>Просто поймите, что есть разница между принятием консолидации как факта и рассмотрением ее как проектного ограничения, которое вы действительно продумали. Переносимость раньше была неотъемлемой чертой Open Source-инфраструктуры. Сейчас это уже не так. Инженеры и технические директора, которые сейчас учитывают это, будут иметь варианты, когда произойдет следующий раунд поглощений. Те, у кого их нет, будут вести переговоры, обладая гораздо более ограниченными возможностями.</p> Анил Инамдар, руководитель Data Services в NetApp Instaclustr, рассказывает на портале The New Stack о том, почему … article https://www.itweek.ru/themes/detail.php?ID=234685 Fri, 17 Apr 2026 10:45:49 +0300 <p><em>Искусственный интеллект покинул чат — в буквальном смысле. После многих лет существования внутри экранов и цифровых рабочих процессов ИИ в 2026 г. выходит в физический мир. Он проникает в роботов, транспортные средства и окружающие среды, которые находятся над приложениями и веб-сайтами, которыми вы пользуетесь сегодня. Наш очередной ежегодный список </em>«<em>The Top 10 Emerging Technologies In 2026»</em> <em>отражает этот сдвиг и предлагает новый способ осмысления того, как взаимодействуют технологии, пишет в корпоративном блоге Брайан Хопкинс, вице-президент </em><em>Forrester</em> <em>по портфелю перспективных технологий.</em></p> <p>Взаимодействие, создание и обеспечение: новый взгляд на список</p> <p>В этом году я призываю рассматривать лучшие перспективные технологии на трех уровнях:</p> <ul> <li><strong> Технологии для взаимодействия</strong> (<strong>interact</strong> <strong>technologies</strong><strong>)</strong> — это те, с которыми люди будут взаимодействовать напрямую: опыт нулевого уровня, физический ИИ и робототехника, автономный транспорт и агентная коммерция.</li> <li><strong> Технологии для создания (</strong><strong>build</strong> <strong>technologies</strong><strong>)</strong> предоставляют новаторам инструменты для проектирования этого будущего: агентная разработка ПО, мультиагентные системы, а также безопасность ИИ и доверие к нему.</li> <li><strong> Технологии для обеспечения (</strong><strong>fuel</strong> <strong>technologies</strong><strong>) </strong>предоставляют базовые ресурсы: передовые модели, ИИ-суперкомпьютеры и квантовые вычисления.</li> </ul> <p>Вот некоторые из них, которые расскажут историю 2026 г.:</p> <p>#IMAGE_234686#</p> <ul> <li><strong> Функционал нулевого уровня: начало конца приложений в том виде, в каком вы их знаете. </strong>Самая смелая идея в этом году, возможно, самая трудноразличимая. В этом и суть. Функционал нулевого уровня — это интеллектуальный слой на основе ИИ, который парит над современными жесткими приложениями и веб-сайтами, интерпретируя ваши желания и объединяя действия между сервисами. Представьте себе планирование семейного отдыха в групповом чате: помощник нулевого уровня извлекает даты из разговора, отображает рейсы и отели, создает общий маршрут и распространяет его по приложениям и устройствам, которые использует каждый член семьи. Первые признаки этого уже проявляются в OpenAI Apps SDK и протоколе Google Agent-to-UI (A2UI), но широкое внедрение ожидается через несколько лет. Необходимо решить вопросы межбрендовых API, стандартов агентов и реальных проблем конфиденциальности. Когда нулевой уровень созреет, он изменит не только интерфейс — он изменит мир.</li> <li><strong> Физический ИИ и робототехника: от экрана до улицы.</strong> Если нулевой уровень — это ИИ, становящийся невидимым в цифровом пространстве, то физический ИИ — это ИИ, становящийся видимым в реальном мире. Это системы ИИ, встроенные в машины, которые воспринимают, рассуждают и действуют в физической среде — адаптируясь, а не следуя сценариям. Первые внедрения уже показывают повышение эффективности на <nobr>20-50%</nobr> на складах, заводах и в больницах. Google Gemini Robotics использует модели, такие как RT-2, для преобразования языка и зрения в действия роботов. <nobr>V-JEPA</nobr> изучает физическую динамику, наблюдая за окружающим миром. Широкое корпоративное значение они получат года через два-четыре. Компаниям еще предстоит преодолеть препятствия, связанные с интеграцией, безопасностью и кадрами, но сначала исчезнут вредные, опасные и скучные работы; все остальное последует за ними.</li> <li><strong> Мультиагентные системы:</strong> <strong>ОС для агентного ИИ.</strong> Нулевой уровень и физический ИИ — это масштабные идеи, но ни одна из них не масштабируется с помощью одного агента на основе чата. Мультиагентные системы — следующий шаг в развитии агентного ИИ: сети специализированных агентов, которые планируют, делегируют и выполняют сложные рабочие процессы. Они внедряют интеллект в масштабируемые паттерны для реальных операций, включая долгосрочные задачи, такие как многодневная обработка обращений и цепочки эскалации. Первые пользователи демонстрируют измеримые улучшения в решении проблем поддержки клиентов, сортировке инцидентов и доставке ПО. Для широкого внедрения сначала необходимы улучшенные оркестрация, управление и безопасность. Когда автономные агенты начинают взаимодействовать друг с другом, ситуация может быстро стать непредсказуемой. Технология реальна, но механизмы защиты еще находятся в стадии разработки.</li> <li><strong> Квантовые вычисления: практичность и «день Q» уже не за горами.</strong> Квантовые вычисления — единственная из выбранных нами технологий с долгосрочным горизонтом, до достижения ее ожидаемой ценности для большинства компаний еще пять или более лет. Так почему же мы ее включили? Потому что после многих лет упорной работы и сомнений «может быть, когда-нибудь» технология приближается к практической применимости. Но вместе с ней наступает «день Q» — момент, когда квантовые компьютеры смогут взломать существующее шифрование. Практическая ценность и критический момент могут наступить уже в 2030 г. Поэтому подготовка необходима уже сейчас, даже несмотря на то, что коммерческий потенциал пока ограничен узкими пилотными проектами в областях оптимизации портфеля, молекулярного моделирования и маршрутизации цепочек поставок. Финансовые услуги, фармацевтика и производство лидируют в этих экспериментах. Всем остальным нужно начать планировать: чрезмерные инвестиции сегодня и неподготовленность завтра — это реальные опасности.</li> <li><strong> Конфиденциальность ИИ и доверие к нему: не просто важны, но и, наконец, объединяются.</strong> Доверие остается критически важным для ИИ. Новые угрозы, такие как инъекция промптов, утечка данных и кража моделей, привели к созданию специализированных решений, таких как брандмауэры и инструменты мониторинга. Эти инструменты сейчас объединяются в интегрированные платформы, охватывающие промпты, приложения и модели. Как это уже происходило с развитием технологий в прошлом, угрозы стимулируют создание инструментов, которые в конечном итоге объединяются в более широкие системы. Безопасность ИИ обеспечивает краткосрочную ценность даже в виде набора отдельных инструментов, и все технологии ИИ зависят от нее.</li> </ul> Искусственный интеллект покинул чат — в буквальном смысле. После многих лет существования внутри экранов … article https://www.itweek.ru/themes/detail.php?ID=234683 Fri, 17 Apr 2026 10:29:56 +0300 <h3>Предисловие: о реальности ИИ в B2B</h3> <p>Чтобы не выглядеть голословным в теме, где слишком легко манипулировать цифрами и с уверенным видом рассказывать, как прекрасно работают исходящие звонки ИИ-ассистентов по базе потенциальных клиентов, сразу оговорюсь: где-то они, возможно, и работают. Но точно не там, где клиент может задать десяток встречных вопросов, уводящих вашего бедного ассистента сразу в несколько областей права, технических требований и отраслевой практики. Там и естественный интеллект не всегда быстро справляется без паузы и дополнительной проверки, а искусственный в такой ситуации легко сочинит сборник сказок. И отвечать за эти сказки потом все равно вам. И здесь, как мне кажется, важно сразу расставить акценты.</p> <h3>ИИ как рабочий инструмент, а не тренд</h3> <p>За последние два года ИИ из модной темы постепенно превратился в рабочий инструмент для бизнеса. <a href="https://issek.hse.ru/news/1139129178.html">Согласно исследованиям</a>, уже 61% малого и среднего бизнеса в России используют ИИ-технологии. Это значит, что технология в бизнес уже вошла. Однако здесь кроется парадокс: большинство компаний внедряют ИИ без чёткой стратегии. <a href="https://www.vedomosti.ru/technologies/trendsrub/articles/2026/03/04/1180756-ii-rivok-2026-chto">Лишь 26%</a> российских компаний, закладывающих бюджеты на внедрение ИИ, имеют внятную стратегию его применения. То есть технология в бизнес уже вошла, а понимание, как именно встраивать ее в процессы без лишнего шума и самообмана пока нет.</p> <p>Отсюда и возникает та самая странная информационная среда, в которой ИИ обычно показывают только с выгодной стороны: рост продаж, мгновенная автоматизация, отделы, которые будто бы можно заменить одной моделью. Но в реальности, особенно в сложных B2B-сегментах, все не так «глянцево».</p> <h3>Почему ИИ перестаёт быть волшебной кнопкой</h3> <p>Потому что там, где разговор выходит за рамки шаблонных скриптов, где нужно учитывать регуляторику, технические ограничения, отраслевые стандарты, длинный цикл сделки и высокую цену ошибки, ИИ перестает быть волшебной кнопкой. Конечно он может быть сильным помощником, но никак не универсальным заменителем экспертизы. Цифры некоторых аналитических отчетов довольно отрезвляющие. По <a href="https://companies.rbc.ru/news/1ISxaNhMer/kak-nejroseti-menyayut-malyij-i-srednij-biznes/">оценке</a> АНО «Цифровая экономика»:</p> <ul> <li> 47% предприятий МСП в Москве и Санкт-Петербурге активно используют нейросети;</li> <li> 41% планирует внедрение в ближайшее время;</li> <li> 24% практически не заметили значимого эффекта от интеграции ИИ.</li> </ul> <p>Это означает, что почти четверть компаний, потративших ресурсы на внедрение, не получили ожидаемого результата. В сложном B2B это особенно заметно. Если интернет-магазин ошибся в описании товара, максимум, что может произойти — это возврат или недовольный клиент. Если же вы работаете в нише, где каждое слово может упираться в нормативные требования, документацию, техническую совместимость или юридические риски, цена ошибки совсем другая. Тут неправильно интерпретированная норма, некорректная рекомендация или слишком смелое упрощение могут обойтись гораздо дороже, чем сэкономленные пару часов.</p> <p>Поэтому я всегда довольно спокойно отношусь к громким заявлениям о полной автоматизации продаж, консультаций и вообще всего на свете. Возможно, в каких-то сценариях это действительно работает. Но если ваш клиент привык задавать сложные вопросы и ожидает от вас не скрипт, а позицию, не скорость ответа, а точность, то роль человека никуда не исчезает. ИИ в такой модели — не тот, кто берет на себя ответственность за финальное решение. И, честно говоря, это хорошо.</p> <h3>Реальная ценность ИИ: проверка гипотез</h3> <p>Но вот на что в сложной B2B-нише действительно можно сейчас опереться, так это на другое. И здесь я уже могу говорить не в теории, а из собственного опыта. Сразу оговорюсь, я не ИТ-специалист. Хотя вектор моей деятельности с технологиями, цифровыми инструментами и сложными процессами связан напрямую. И именно в этой точке ИИ для меня стал по-настоящему полезен — не как красивая игрушка и не как повод рассказывать про «цифровую трансформацию», а как инструмент для проверки гипотез.</p> <p>Если я вижу, что какой-то блок нашей работы можно автоматизировать, или у меня появляется идея продукта, который может быть интересен рынку и реально повлиять на наши показатели — маркетинговые, финансовые или операционные, то ещё недавно передо мной стояло всего два варианта. Либо идти к профильному специалисту, либо самому заходить в программирование, что для операционного руководителя обычно означает простой выбор между просадкой по основной работе и очень медленным движением вперед. Сейчас ситуация заметно изменилась.</p> <h3>ИИ как переводчик между идеей и её реализацией</h3> <p>Благодаря ИИ я могу сесть вечером или в выходной с ноутбуком, открыть один из инструментов автоматизации (Zapier, Make, n8n или визуальные конструкторы) и собрать MVP того, что раньше существовало только в голове. А потом принести команде уже не идею в воздухе, а что-то вполне осязаемое: это можно посмотреть, покритиковать, доработать, обсудить предметно и либо быстро пустить в работу, либо также быстро отказаться от гипотезы, не сжигая лишние ресурсы. Если говорить проще, то ИИ резко снизил порог входа в эксперименты.</p> <p>Раньше между идеей и ее проверкой была довольно большая дистанция. Нужно было найти разработчика, объяснить ему логику, согласовать бюджет, заложить сроки — обычно <nobr>4-6 недель,</nobr> потом ждать реализации, и только после этого понять, туда ли вы вообще идете. Многие идеи на этом этапе просто умирали. Не потому, что они были плохими, а потому, что стоимость проверки гипотезы оказывалась почти сопоставима со стоимостью полноценного проекта. Неудивительно, что инициативы тормозились. Теперь это работает иначе. Инструментов стало много: визуальные конструкторы, сервисы автоматизации, среды для интеграций, решения для быстрой сборки прототипов. И во всей этой экосистеме ИИ выполняет очень важную роль — он становится переводчиком между управленческой идеей и технической реализацией.</p> <p>ИИ помогает быстрее сформулировать логику процесса, предложить варианты сборки, написать фрагмент кода, объяснить, как связать между собой несколько сервисов, убрать тот страх перед стартом, который раньше часто тормозил любую инициативу. Это работает на уровне рефлекса: есть идея — попробуем за вечер.</p> <h3>Особенная ценность для маленьких команд</h3> <p>Для небольшой команды это особенно важно. Когда у вас нет отдельного отдела разработки, каждая новая функция, автоматизация или внутренний сервис — это всегда вопрос ресурсов. А ресурсы у маленькой команды конечны. Именно поэтому ИИ оказывается для нее не модным дополнением, а вполне практической опорой.</p> <p><a href="https://tass.ru/ekonomika/26218961">Согласно исследованиям</a>, 45% респондентов отметили ускорение решения типовых задач — они говорили об экономии <nobr>30-40%</nobr> времени на рутину. Еще 37% отметили снижение доли ручных операций на <nobr>20-50%.</nobr> И вот что особенно интересно: 82% предпринимателей благодаря нейросетям сумели расширить штат сотрудников, вопреки мифу об вытеснении людей. Т. е. это не про то, что «искусственный интеллект заменит всех», а про то, что бизнес начинает убирать рутинные процессы, где они действительно мешают.</p> <p>По <a href="https://companies.rbc.ru/news/1ISxaNhMer/kak-nejroseti-menyayut-malyij-i-srednij-biznes/">данным</a> АНО «Цифровая экономика», отдельные ритейлеры с помощью нейросетей снизили объем пищевых отходов и сократили время на выкладку товаров на почти 40%, объем брака снизился до 0,9% вместо обычных <nobr>2-3%,</nobr> жалоб стало меньше в среднем на 35%. Вот в этом, на мой взгляд, и находится главная выгода ИИ для сложного B2B. Не в том, что он чудесным образом отменяет потребность в отраслевом опыте, а в том, что то, что раньше требовало бюджета, времени, нескольких согласований и иногда отдельной команды, теперь в ряде случаев может быстро проверить один человек, если он хорошо понимает узкие места процесса.</p> <h3>Ключевой навык в эпоху ИИ</h3> <p>Именно понимание узких мест становится главным навыком. ИИ не заменяет опыт работы в отрасли, но очень хорошо усиливает человека, который видит, где в системе накапливаются задержки, где сотрудники совершают лишние действия, где процесс перегружен ручной работой, а где, наоборот, автоматизировать ничего и не нужно вовсе.</p> <p>Как только такая точка найдена, появляется возможность довольно быстро проверить, можно ли ее упростить, ускорить или собрать вокруг нее новый рабочий контур. Иногда результат оказывается неожиданно простым. То, что годами делалось руками несколькими людьми, действительно можно свести к одной автоматической цепочке действий. Мы сэкономили 12 часов работы сотрудников в месяц на автоматизации одного сложного процесса. Просто избавились от бутылочного горлышка, и все потекло дальше.</p> <p>Иногда выходит наоборот: автоматизация не дает нужного эффекта, и тогда лучше честно оставить процесс как есть. Но даже это уже полезный результат, потому что решение принимается не через месяцы обсуждений, а за несколько дней.</p> <h3>Эффект: от «когда-нибудь» к реальности</h3> <p>Есть и ещё один эффект, который редко замечают сразу. Когда между мыслью и прототипом больше нет такой огромной дистанции, меняется сама культура работы с идеями. Люди внутри команды начинают смелее предлагать улучшения, потому что теперь это не разговор в духе «когда-нибудь надо бы сделать», а вполне реальная возможность за короткое время собрать черновой рабочий вариант и посмотреть, стоит ли идея дальнейших вложений.</p> <p>До внедрения ИИ мы получали <nobr>2-3</nobr> идеи от сотрудников в месяц. После — это выросло до более 10 идей в месяц. Из них реализуется <nobr>30-40%.</nobr> Это важное изменение культуры, а не просто эффективность. Люди начали верить, что их идеи могут быть услышаны не когда-то, а прямо сейчас.</p> <h3>Финальная мысль: ИИ как расширитель возможностей</h3> <p>Поэтому в моем понимании ИИ сегодня становится инструментом, который может значительно расширить возможности небольшой команды. Он позволяет быстрее экспериментировать, быстрее учиться на собственных ошибках, быстрее находить решения, которые действительно работают в конкретной нише. Именно в этом его настоящая ценность для сложного B2B, а не в обещаниях о полной автоматизации «всего на свете». Его ценность прежде всего в другом: у небольшой команды теперь появляется шанс двигаться быстрее многих игроков на рынке, проверять больше идей и выстраивать процессы, которые раньше казались слишком сложными, слишком дорогими или просто недостижимыми без большого штата.</p> <p> #IMAGE_234684#</p> Предисловие: о реальности ИИ в B2B Чтобы не выглядеть голословным в теме, где слишком легко … article Егор Кашка, операционный директор цифровой экосистемы регистрации медицинских изделий КРЕДО.ТЕХ https://www.itweek.ru/themes/detail.php?ID=234682 Thu, 16 Apr 2026 15:30:48 +0300 <p>Innostage PAM обновлен до версии 1.6.0. В новой версии расширены возможности проверки передаваемых файлов через ICAP и работы с SSH- и SFTP-подключениями в сетевых сегментах с пересекающейся адресацией. Также продукт получил новые возможности для инвентаризации привилегированных учетных записей и аутентификации пользователей.</p> <p>Одно из ключевых обновлений касается проверки передаваемых файлов во внешних системах антивирусной защиты и песочницах. Автоматическая проверка на вредоносное содержимое теперь охватывает ключевые каналы передачи: менеджер файлов рабочей области, RDP-подключения через Web-терминал, а также SFTP- и SCP-подключения через Web-терминал и десктопные клиенты. Это позволяет применять единый подход к контролю передачи файлов в сценариях привилегированного доступа.</p> <p>В версии 1.6.0 расширена функциональность работы по SSH-протоколу. Продукт поддерживает SSH- и SFTP-подключения в сетевых сегментах с пересекающейся адресацией за счет поддержки VRF. Дополнительно реализована поддержка SSH Agent Forwarding для проброса ключей на целевые ресурсы.</p> <p>Еще одно направление обновления связано с использованием служб каталогов как источника привилегированных учетных записей. Innostage PAM позволяет выполнять регулярную инвентаризацию учетных записей в Linux- и Windows-средах, включая AD, Samba, FreeIPA и OpenLDAP, и автоматически добавлять новые привилегированные учетные записи в PAM-систему. Такой подход помогает поддерживать актуальность данных и снижать риск появления неучтенных доступов.</p> <p>В новой версии доработана аутентификация пользователей по сертификатам X.509. Интеграция с доверенным центром сертификации позволяет использовать сертификаты для строгой аутентификации при работе с продуктом.</p> <p>В версии 1.6.0 расширены возможности управления RDP-подключениями с нативных клиентов. В продукте появились ограничения на проброс буфера обмена, сетевых дисков и принтеров, а также возможность настройки версии TLS и алгоритмов шифрования для RDP Client.</p> <p>Отдельный блок изменений касается криптографической защиты хранимых данных. В новой версии реализовано шифрование настроек подключения к БД в конфигурационном файле, что повышает защищённость чувствительных данных PAM-системы.</p> <p>Добавлена поддержка форматов CEF и LEEF для передачи событий в SIEM-системы.</p> <p>Игорь Еньков, владелец продукта Innostage PAM, отметил: «Для заказчиков важно, чтобы PAM-система обеспечивала не только базовый контроль привилегированного доступа, но и закрывала сценарии, от которых зависит безопасность эксплуатации корпоративной инфраструктуры. Изменения в версии 1.6.0 направлены именно на такие задачи — контроль передачи файлов, работу в сетевых сегментах с пересекающейся адресацией, поддержание актуальности данных о привилегированных учетных записях и применение более строгих механизмов аутентификации».</p> <p>Innostage Privileged Access Management — продукт для комплексной защиты корпоративных информационных систем от рисков ИБ, связанных с привилегированным доступом на всех уровнях: от инфраструктуры до бизнес-приложений.</p> Innostage PAM обновлен до версии 1.6.0. В новой версии расширены возможности проверки передаваемых файлов через ICAP … message https://www.itweek.ru/themes/detail.php?ID=234681 Thu, 16 Apr 2026 15:29:46 +0300 <p>Компания «РЕД СОФТ», отечественный разработчик программного обеспечения, сообщила о выходе «РЕД Виртуализация» 8.0. Продукт активно используется в органах власти, государственных корпорациях, финансовом секторе и других отраслях экономики.</p> <p>В обновлении разработчик сделал акцент на потребностях пользователей. Реализована поддержка программно-определяемых сетей (SDN), что дало возможность гибко настраивать виртуальные сети через веб-интерфейс.</p> <p>Обновлена пакетная база до oVirt 4.5. Переход на актуальную версию открыл возможность внедрения расширенных сценариев авторизации. В платформу интегрирован компонент Keycloak, обеспечивающий поддержку двухфакторной аутентификации (2FA) на портале.</p> <p>Для инженеров и администраторов создан портал обслуживания среды виртуализации. С его помощью можно отслеживать состояние оборудования, своевременно обновлять сертификаты безопасности и собирать данные для диагностики без необходимости прямого доступа к серверам, что сокращает время реагирования на инциденты</p> <p>Добавлена поддержка создания доменов хранения NVMe over Fabrics через веб-портал администратора. Использование протоколов NVME over FC / TCP/ RDMA обеспечивает прирост скорости чтения/записи внутри виртуальных машин.</p> <p>Особое внимание уделено отказоустойчивости. Модуль аварийного восстановления РЕД Виртуализации позволяет переключаться на резервный ЦОД и восстанавливать работоспособность инфраструктуры. Это помогает бизнесу избежать длительных простоев и потери данных.</p> <p>«Новая версия РЕД Виртуализации получила ряд новых инструментов для управления платформой и виртуальными машинами. Рынку нужны не просто базовые механизмы виртуализации, а современные зрелые решения, обеспечивающие безопасность, стабильность и отказоустойчивость — именно это мы реализовали в обновлении. Особое внимание было уделено улучшению пользовательского опыта, чтобы наши клиенты могли эффективно управлять своей инфраструктурой. В дальнейшем мы продолжим развивать продукт и реализовывать актуальные запросы наших заказчиков», — отметил Рустам Рустамов, заместитель генерального директора «РЕД СОФТ».</p> Компания «РЕД СОФТ», отечественный разработчик программного обеспечения, сообщила о выходе «РЕД Виртуализация» 8.0. Продукт … message https://www.itweek.ru/themes/detail.php?ID=234680 Thu, 16 Apr 2026 15:18:33 +0300 <p>Компания BSS запустила новую интеграционную платформу ТИР 3.0 — современное low-code решение с поддержкой генеративного искусственного интеллекта, предназначенное для банков и финансовых организаций.</p> <p>ТИР 3.0 — это интеграционная платформа нового поколения, объединяющая визуальное проектирование маршрутов, интеллектуальную автоматизацию и AI-ассистента для создания и сопровождения интеграций между банковскими системами. Решение построено на современном полностью импортозамещенном технологическом стеке.</p> <p>Современные банки сталкиваются с проблемами сложных и дорогих интеграций, ростом количества ИТ-систем и протоколов, а также трудностями масштабирования. ТИР 3.0 решает эти вызовы, предлагая ускоренную разработку и отладку маршрутов интеграции с помощью визуального low-code редактора и генеративного AI-ассистента, который берет на себя всю рутинную работу при разработке интеграционного маршрута.</p> <p>Основные преимущества платформы:</p> <ul> <li>снижение на <nobr>30–50%</nobr> стоимости интеграций за счет low-code подхода и автоматизации;</li> <li>ускорение вывода новых продуктов и сервисов на рынок благодаря визуальной разработке;</li> <li>высокая производительность и надежность: до 100 000 сообщений в час, 24×7 работа без деградации;</li> <li>поддержка всех ведущих <nobr>LLM-моделей,</nobr> что делает платформу гибкой и готовой к любым задачам.</li> </ul> <p>С помощью ТИР 3.0 банки могут не только оптимизировать внутренние ИТ-процессы, но и ускорить цифровую трансформацию, развивая новые сервисы и улучшая клиентский опыт. Решение позволяет эффективно интегрировать данные и системы, обеспечивая гибкость, масштабируемость и конкурентное преимущество на быстро меняющемся финансовом рынке.</p> <p>«Запуск ТИР 3.0 — это важный шаг в развитии технологической экосистемы. Мы предлагаем банкам надежный инструмент для ускорения реализации интеграционных процессов банка. Благодаря встроенным возможностям генеративного ИИ наши клиенты смогут перенять наш опыт разработки с использованием ИИ и быстрее реализовывать интеграционные проекты», — прокомментировал технический директор компании BSS Дмитрий Свалов.</p> Компания BSS запустила новую интеграционную платформу ТИР 3.0 — современное low-code решение с поддержкой генеративного … message https://www.itweek.ru/themes/detail.php?ID=234679 Thu, 16 Apr 2026 15:13:05 +0300 <p> Искусственный интеллект становится мощным драйвером перемен на рынке труда. Институт статистических исследований и экономики знаний (ИСИЭЗ) НИУ ВШЭ на основе анализа вакансий, размещенных на портале HH.ru, разработал классификацию пользователей ИИ, включающую пять категорий, и выделил для каждой из них наиболее востребованные компетенции.</p> <p>Требование к наличию у соискателей тех или иных цифровых навыков содержится в трети всех рассмотренных вакансий. Из них подавляющая часть (79,9%) предполагает владение базовыми цифровыми инструментами, которые создают потенциал для дальнейшего освоения ИИ-решений для работы. Позиции, связанные с более продвинутым владением ИИ, встречаются заметно реже: компетенции «Создателей моделей ИИ» указаны в 15,4% вакансий из цифровой выборки, «Управленцев в области ИИ» — в 2,3% и всего 0,7% таких вакансий ориентированы на поиск «Архитекторов / Интеграторов ИИ».</p> <p>В отраслевом разрезе самый большой спрос на специалистов с компетенциями в сфере ИИ зафиксирован в ИКТ (60%) и промышленности (22%). На две эти сферы приходится 82% всех цифровых вакансий, исключая категорию «Пользователи цифровых инструментов». В данных отраслях прежде всего востребованы работники с навыками «Создателей моделей ИИ»; далее, со значительным отрывом, идут «Управленцы в области ИИ» и «Пользователи ИИ-решений для профессиональных задач».</p> <p>Текущая структура спроса явно ориентирована на массовую базовую цифровую грамотность и общую готовность к работе с ИИ. Тем не менее для различных рабочих задач все чаще будут требоваться ИИ-компетенции. Исходя из прогнозов развития рынка ИИ, можно ожидать, что самая многочисленная на данный момент группа «Пользователи цифровых инструментов» будет постепенно сокращаться и пополнять категорию «Пользователей ИИ-решений для профессиональных задач», из-за этого, в частности, доля вторых вакансий в течение пяти лет может увеличиться с нынешних 1,7% до <nobr>15–20%.</nobr></p> <p>ИИ становится обязательным элементом профессиональной культуры, что заостряет и перед руководителями задачи, требующие соответствующих компетенций, понимания возможностей и ограничений ИИ-инструментов. Компании будут активнее искать менеджеров, способных интегрировать ИИ в бизнес-процессы, оценивать ROI от внедрения технологии и управлять связанными с нею рисками. Соответственно, может вырасти и доля управленцев в области ИИ с текущих 2,3% до <nobr>8–12%.</nobr></p> <p>Анализ востребованных компетенций по категориям также показал, что пока компании рассматривают ИИ как инструмент для достижения технологического и экономического лидерства. При этом компетенции, связанные с этикой и правовым регулированием технологий ИИ, редко встречаются в критериях отбора на позиции.</p> Искусственный интеллект становится мощным драйвером перемен на рынке труда. Институт статистических исследований … message https://www.itweek.ru/themes/detail.php?ID=234678 Thu, 16 Apr 2026 14:54:20 +0300 <p>В 2026 году все больше крупных российский компаний отказались от стратегии масштабных переносов инфраструктуры при переходе в облако. Вместо одномоментного переноса всей инфраструктуры или больших кластеров ИТ-отделы мигрируют наиболее критические и ресурсозатратные информационные системы, что многократно ускоряет запуск этих систем в «боевую» эксплуатацию в облаке. Владимир Лебедев, директор по развитию бизнеса сервис-провайдера M1Cloud, рассказал о тренде, при котором крупный бизнес все чаще выбирает именно гибридные и поэтапные модели, чтобы не «замораживать» бюджеты на масштабные проекты — миграцию по частям.</p> <p>Еще два-три года назад типичная миграция выглядела как масштабный проект на год-полтора с высоким риском простоя. Полная миграция «за один заход» часто приводит к непредвиденным сбоям: росту нагрузки на команды, проблемам совместимости legacy-систем и превышению бюджета. По данным M1Cloud, <nobr>80-90%</nobr> внутренних ИТ-команд уже сталкивались с проектами по миграции данных, которые не были завершены в срок из-за сложности перехода из локальной среды в облачную, а средняя миграция занимала значительно больше времени, чем планировалось.</p> <p>Сегодня картина изменилась: компании перешли от лавинообразной миграции, которая в первую очередь была связана с уходом глобальных вендоров из России в <nobr>2022-2024 годах,</nobr> к стратегическим программам, где ключевыми критериями стали скорость получения ценности и минимальное влияние на бизнес-процессы. В 2026 году ИТ-команды предпочитают начинать с <nobr>1–2 систем,</nobr> которые дают быстрый эффект: например, с высоконагруженного приложения под сезонные пики или с базы данных, требующей постоянного масштабирования. Такой подход эффективно сочетается с мультиоблачными стратегиями бизнеса, когда компании работают с несколькими провайдерами, комбинируя их возможности под конкретные задачи.</p> <p>Поэтапный подход стал нормой для холдингов, банков, промышленных предприятий и ритейл-сетей из-за существенного снижения рисков.</p> <p>Сначала проводится анализ инфраструктуры и выделяются системы, которые приносят максимум проблем: высокие затраты на поддержку, частые простои или ограниченную масштабируемость. Важно выбрать провайдера с готовыми инструментами миграции и поддержкой гибридных сценариев, а также с большой экспертизой, в том числе по отраслевым проектам. Далее запускается быстрый пилот. Перевод выбранного сегмента занимает <nobr>3–6 недель.</nobr> Уже на этом этапе компания получает работающую систему в IaaS или гибридной среде, измеряет метрики (время отклика, стоимость владения, отказоустойчивость) и принимает решение о следующем шаге. Успешный пилот становится шаблоном. Следующие волны миграции идут быстрее, потому процессы отлажены.</p> <p>Такой подход позволяет повысить доступность сервисов и высвобождение внутренних ресурсов ИТ-отдела. При этом основной бизнес продолжает работать в привычном режиме — без «окна» на миграцию и без стресса для сотрудников.</p> <p>При частичной миграции компания сразу видит реальное потребление ресурсов и может оперативно оптимизировать затраты. Это особенно актуально для холдингов с распределенной географией, где разные подразделения имеют свои пиковые нагрузки и требования к отказоустойчивости.</p> <p>Миграция по частям в 2026 году позволяет крупному бизнесу получать реальную ценность от облака уже в первые недели проекта, минимизировать риски и строить облачную инфраструктуру эволюционно, а не революционно. Те компании, которые уже перешли на такой подход, отмечают не только экономию, но и рост внутренней ИТ-зрелости. Облачная трансформация сегодня — это про умный, управляемый и предсказуемый рост.</p> В 2026 году все больше крупных российский компаний отказались от стратегии масштабных переносов инфраструктуры при … message https://www.itweek.ru/themes/detail.php?ID=234677 Thu, 16 Apr 2026 10:06:11 +0300 <p><em>Рабочие нагрузки искусственного интеллекта меняют подход к проектированию центров обработки данных, определяя переход от жесткого резервирования к гибкости, адаптированной под конкретные потребности, пишет на портале </em><em>Data</em> <em>Center</em> <em>Knowledge</em> <em>Харкс Сингх, технический директор и соучредитель InfraPartners.</em></p> <p>На протяжении десятилетий дата-центры проектировались как коммерческие авиалайнеры. Они строились с многоуровневым резервированием, потому что отказ просто не был допустим и было неясно, какие приложения будут использовать инфраструктуру объекта. Большинству дата-центров приходилось учитывать различные типы приложений, с обеспечением резервных копий на случай, если что-то пойдет не так.</p> <p>Однако развитие ИИ принесло другую реальность — реальность, которая не требует исключительной отказоустойчивости и почти идеального времени безотказной работы, но при этом ограничена тем, что цепочка поставок не масштабируется достаточно быстро. Этот сдвиг сделал индустрию дата-центров гораздо менее похожей на авиацию и гораздо сильнее похожей на более широкую транспортную сеть, с множеством эталонных архитектур для ИИ-обучения или инференса. Потому что не для каждой перевозки нужен именно самолет. Некоторые могут быть лучше организованы поездами или грузовыми судами.</p> <p>Фактически, в ответ на диверсификацию моделей ИИ операторы отказываются от строительства каждого объекта с максимальным резервированием и вместо этого отдают приоритет прибыльности и энергоэффективности, используя каждый ватт с максимальной эффективностью и инвестируя капитал таким образом, чтобы обеспечить долгосрочную окупаемость. Понимание потребностей в производительности различных моделей и рабочих нагрузок ИИ помогает согласовывать дата-центры с требованиями приложений.</p> <h3>Почему ИИ меняет историю дата-центров</h3> <p>На протяжении большей части истории отрасли 99,999% времени безотказной работы было незыблемым требованием. Дата-центры обеспечивали работу систем, где даже секунды простоя имели немедленные последствия для фондовых бирж, платежных сетей и телекоммуникационной инфраструктуры. В этих средах сбои могли иметь чрезвычайно серьезные последствия для бизнеса. Представьте себе миллионы, потерянные за минуты, или сбои в работе критически важных служб для целых регионов. Поскольку операторы не всегда могли предсказать, какие приложения действительно будут критически важными, многие объекты по умолчанию строились в соответствии с высочайшими стандартами отказоустойчивости.</p> <p>Сегодня ИИ меняет эту необходимость. Хотя многие могут предположить, что новая технологическая эра обуславливает постоянно растущие требования к отказоустойчивости, в действительности различные модели, процессы обучения и инференса требуют совершенно разных уровней обслуживания. В некоторых случаях инфраструктуре не требуются резервные генераторы, сложные системы резервирования или высокоуровневая архитектура. Для рабочих нагрузок обучения ИИ не требуется тот уровень бесперебойной работы, к которому большинство из нас привыкло.</p> <p>Почему это важно? Очевидно, что отрасль находится под сильным давлением и пристальным вниманием. Спрос превышает предложение, нехватка рабочей силы задерживает проекты, а перерасход средств остается постоянной проблемой. В то же время спрос и требования ИИ значительно растут. Использование по умолчанию сверхнадежных высокоуровневых решений для каждого развертывания ИИ усугубляет это давление. Многоуровневые системы резервирования электропитания, обширная резервная инфраструктура и полностью дублированные среды увеличивают капитальные затраты и могут значительно замедлить ввод мощностей в эксплуатацию. Они также вводят операционную сложность, которая просто не требуется для этих рабочих нагрузок.</p> <h3>Почему рабочие нагрузки ИИ отличаются</h3> <p>Многие корпоративные дата-центры были спроектированы для традиционных ИТ-нагрузок, но для ИИ нужен более широкий спектр объектов, удовлетворяющих различные потребности в производительности и времени безотказной работы. Например, крупные центры обучения ИИ работают иначе, чем традиционные площадки, вокруг которых строилась отрасль. Эти среды, использующие графические процессоры, работают в огромных масштабах, при этом основными ограничениями являются доступность электроэнергии и охлаждение. Поскольку эти рабочие нагрузки распределены и основаны на контрольных точках, они функционируют скорее как пакетная обработка, и можно предусмотреть бóльшую гибкость для более быстрого запуска и использования мощностей.</p> <p>Напротив, развертывания инференса обычно производятся ближе к населенным пунктам и службам поддержки, с которыми пользователи регулярно взаимодействуют. Поскольку они связаны с клиентским опытом, ожидания в отношении времени безотказной работы и отказоустойчивости остаются высокими, и инфраструктура должна быть спроектирована таким образом, чтобы обеспечить непрерывную доступность либо на уровне площадки, либо в распределенной модели отказоустойчивости.</p> <p>Это разнообразие требований приводит нас к портфелю различных типов объектов без универсального подхода или высоких ожиданий в отношении создания резервных копий и избыточности. В эпоху ИИ речь идет скорее о «точной отказоустойчивости», то есть об избыточности, отражающей фактическое поведение рабочих нагрузок, а не об опоре на устаревшие проектные предположения.</p> <h3>Цена избыточного проектирования</h3> <p>Ошибка, заключающаяся в проектировании чрезмерной отказоустойчивости по всем направлениям, приводит к замораживанию капитала, который мог бы быть направлен на увеличение вычислительных мощностей, и замедляет развертывание новых площадок.</p> <p>Операторам следует стремиться к балансу. Модернизируемые дата-центры, использующие стандартные эталонные дизайны и блоки,поступающие на строительные площадки, позволяют развертывать инфраструктуру гораздо быстрее. Стандартизация компонентов и их разработка в заводских условиях позволяют операторам снизить сложность на месте и получить гораздо больший контроль над затратами и сроками. Этот вариант упрощает принятие обоснованных решений об отказоустойчивости, производительности и скорости выхода на рынок.</p> <p>Эта стандартизация идет рука об руку с созданием стандартных эталонных дизайнов, которые нам начинают требоваться и которые мы уже видим в контексте ИИ. Когда базовые компоненты стандартизированы, операторы могут гораздо эффективнее собирать объекты различных типов. Стандартизация предоставляет строительные блоки, а эталонные дизайны определяют, как они собираются.</p> <h3>Гибкость имеет фундаментальное значение</h3> <p>Инфраструктура ИИ развивается слишком быстро для жестких проектных предположений, поэтому дизайны должны быть гибкими, чтобы удовлетворить потребности завтрашнего дня. В ближайшие годы ландшафт ИИ, вероятно, будет включать в себя несколько типов объектов. Это будут как энергоэффективные центры обучения, построенные вблизи источников энергии, так и распределенные площадки для инференса, где время безотказной работы и задержка напрямую влияют на пользовательский опыт, а также гибридные среды, поддерживающие как задачи ИИ, так и традиционные рабочие нагрузки.</p> <p>Подобно разнообразной транспортной сети самолетов, поездов и судов, каждый из них служит разным целям и имеет свои компромиссы. Но отказоустойчивость всегда должна быть осознанным проектным решением, определяемым рабочей нагрузкой, бизнес-моделью и получаемым доходом.</p> Рабочие нагрузки искусственного интеллекта меняют подход к проектированию центров обработки данных, определяя переход … article https://www.itweek.ru/themes/detail.php?ID=234675 Thu, 16 Apr 2026 09:52:58 +0300 <p><em>В статье расскажу</em><em>, почему постоянный контроль разрушает команду и как выстроить делегирование эффективно</em><em>.</em></p> <h3>Парадокс контроля</h3> <p>Есть одна картина, которую я наблюдаю с пугающей регулярностью. Руководитель работает больше всех в команде. Проверяет каждое решение. Согласовывает каждый подход. Лично вычитывает каждый документ, прежде чем тот уйдёт наружу. И при этом у него стойкое ощущение, что без него всё развалится — что команда не справляется, что люди недостаточно зрелые, что проще и быстрее сделать самому, чем объяснять. Он называет это ответственностью. Иногда — перфекционизмом. Иногда — «ну а кто, если не я».</p> <p>А на самом деле это управленческая ловушка, причём из тех, которые затягиваются постепенно. Пока команда маленькая — два-три человека — ещё можно лично контролировать каждую задачу. Но по мере роста задач становится больше, людей становится больше, а личная пропускная способность руководителя остаётся ровно такой же, какой была. И в какой-то момент скорость всей команды начинает упираться в скорость одного человека. Не потому что люди слабые, а потому что система устроена так, что каждое решение проходит через одну точку. Руководитель становится узким местом собственной команды — и чем старательнее он контролирует, тем уже это место становится.</p> <p>К этой ситуации хорошо подходит одна циничная, но точная управленческая шутка: <em>«„Хочешь, чтобы что-то было сделано хорошо — сделай это сам“ — отличная надпись для надгробия молодого менеджера».</em></p> <p>Она точно описывает установку, которая выглядит ответственной, но на практике разрушает и руководителя, и команду одновременно. Команда не развивается, потому что ей не дают брать ответственность. Руководитель не растёт, потому что тонет в чужой операционке. Все застревают, и никому не понятно, почему.</p> <p>Парадокс в том, что плотный контроль создаёт иллюзию управления, хотя по факту его разрушает.</p> <h3>Контроль — это не управление</h3> <p>Здесь стоит разобраться в одном различии, которое кажется очевидным, но на практике игнорируется постоянно. Контроль и управление — это разные вещи. Контроль — это проверка каждого шага: правильно ли выбран подход, в том ли порядке идёт работа, не отклонился ли человек от того, что вы имели в виду. Управление — это создание условий, при которых правильные решения принимаются без вашего ежеминутного участия. Контроль масштабируется линейно: чем больше задач, тем больше вашего времени он съедает. Управление масштабируется системно — вы строите конструкцию один раз, и она работает.</p> <p>Проблема в том, что большинство руководителей, особенно выросших из сильных специалистов, по умолчанию идут в контроль. Это привычная модель: ты лучше всех разбираешься в предмете, ты видишь ошибки быстрее, чем другие их совершают, и тебе кажется, что проще поправить самому, чем объяснять. Но с каждой такой поправкой вы укрепляете систему, в которой люди не принимают решений — они приносят вам полуфабрикаты и ждут вашего вердикта. Вы не руководитель в этот момент. Вы — самый дорогой контролёр качества в компании.</p> <p>Переход от контроля к управлению начинается с одной конкретной управленческой операции — делегирования. И здесь нужно разобраться, что это слово означает на самом деле, потому что используется оно повсюду и почти всегда неправильно. Руководитель поручил подготовить отчёт — «делегировал». Попросил коллегу провести встречу — «делегировал». Передал задачу в Jira — «делегировал». На деле ни в одном из этих случаев делегирования не произошло. Произошла постановка задачи — обычная, штатная, не требующая передачи никаких новых полномочий.</p> <p>Разница принципиальная. Постановка задачи — это когда вы поручаете человеку работу, которую он и так имеет право выполнять. Разработчик писал код и до вашего поручения, аналитик делал отчёты и до вашей просьбы. Вы определяете, что нужно сделать, человек выполняет, ответственность за правильность постановки — на вас. Делегирование начинается тогда, когда вы передаёте человеку права, которых у него раньше не было: право принимать решения, распоряжаться ресурсами, определять приоритеты в своей области. Если никаких новых полномочий не передано — делегирования не было, как бы вы это ни называли.</p> <p>Вот конкретный пример, чтобы разница стала осязаемой. Ситуация первая: вы говорите разработчику «реализуй функцию уведомлений к пятнице». Это постановка задачи — он и так пишет код, никаких новых прав не возникло. Ситуация вторая: вы говорите тому же разработчику «ты теперь отвечаешь за весь модуль уведомлений, принимаешь архитектурные решения, расставляешь приоритеты, согласовываешь требования с продактом». Вот это делегирование — человек получил полномочия, которых раньше у него не было, и вместе с ними взял на себя ответственность за результат, а не просто за исполнение.</p> <p><em>«Раньше я приказывал тебе от своего имени, а теперь ты сам приказывай себе, но от моего имени»</em><em>.</em></p> <p>Эта формула звучит грубовато, но она передаёт суть делегирования точнее, чем любое длинное объяснение. Сотрудник не получает свободу делать что угодно. Он берёт на себя функцию, которую раньше выполнял руководитель: сам ставит себе задачи, сам выбирает подход, сам расставляет приоритеты — но делает это не по собственному разумению, а по тем же принципам, по которым действовал бы руководитель. Делегирование — это не передача свободы, а передача управленческой логики.</p> <p>На практике это означает, что после делегирования у сотрудника должен работать один внутренний тест. Каждый раз, когда он сталкивается с неочевидным выбором, он спрашивает себя: «А как бы мой руководитель решил это?». Если он понимает логику, приоритеты и принципы руководителя, он способен действовать автономно и при этом оставаться управляемым. Если не понимает, начинается угадывание. А угадывание — это не автономность, это лотерея с предсказуемым финалом: либо человек дёргает вас по каждому поводу, либо принимает решение, которое вы потом называете «ну это же очевидно неправильно». Очевидно — для вас. Потому что принципы знаете вы, а ему их никто не передал.</p> <p>И вот здесь возникает неудобная правда. Делегирование требует от руководителя предварительной работы — нужно сделать свои принципы принятия решений явными. Пока они существуют только в вашей голове в виде интуиции и «ну это же понятно», передать их невозможно. А значит, каждый раз, когда вы злитесь на сотрудника за неправильное решение в делегированной области, стоит задать себе честный вопрос: а вы ему объяснили, как правильно? Не задачу объяснили — задачу-то он понял, — а именно логику, по которой нужно выбирать между вариантами?</p> <p>Делегирование состоялось не тогда, когда вы сказали «ты теперь отвечаешь», а тогда, когда человек понял, как принимать решения от вашего имени.</p> <h3>Рамка: как передать управление, не потеряв управляемость</h3> <p>Принципы — необходимая, но не достаточная часть. Чтобы делегирование реально работало, сотруднику нужна полная рамка — структурированная система договорённостей, которая закрывает все практические вопросы, возникающие в процессе автономной работы. Без этой рамки даже мотивированный и компетентный человек будет либо постоянно перестраховываться, либо заходить туда, куда заходить не должен. И оба варианта — следствие одной причины: ему не обозначили границы поля, на котором он играет.</p> <p>Рамка начинается с цели — не задачи, не функции, а конечного состояния, к которому нужно прийти. Например, стабильная работа модуля уведомлений без задержек и потерь. Именно цель становится компасом в ситуациях, когда ни одна инструкция не покрывает конкретный случай: сотрудник спрашивает себя, какое решение ведёт к этой цели, и действует. Это уже не слепое исполнение и не произвольная самодеятельность — это управляемая автономность.</p> <p>Дальше идут принципы принятия решений — те самые критерии, по которым сотрудник выбирает между вариантами. Стабильность важнее скорости. Обратная совместимость не нарушается без явного согласования. Решения, увеличивающие нагрузку на базу данных, сначала обсуждаются. Это не инструкции и не правила — это явная логика руководителя, переданная в формате, который можно применять самостоятельно.</p> <p>Третий элемент — границы решений. Что можно решать самостоятельно, что нельзя. Можно менять внутреннюю реализацию — нельзя менять публичный API. Можно привлекать других разработчиков для консультации — нельзя принимать обязательства, которые влияют на бюджет или сроки контрактов. Без этих границ человек либо боится шагнуть вправо-влево и тащит к вам каждую мелочь, либо принимает решения, выходящие далеко за пределы того, что вы имели в виду, когда говорили «ты отвечаешь».</p> <p>Четвёртый — ресурсы: что именно есть в распоряжении. Может ли сотрудник привлекать людей из других команд? Заказывать инфраструктуру? Договариваться с внешними контрагентами? Если человек отвечает за результат, но не понимает, какими инструментами вправе пользоваться, он либо действует слишком робко и не достигает цели, либо слишком широко и создаёт конфликты.</p> <p>Пятый — точки эскалации. Конкретные ситуации, в которых сотрудник прекращает действовать самостоятельно и возвращается к руководителю. Срок начинает срываться — сообщи. Нужно менять архитектуру — обсудим. Конфликт приоритетов с другой командой — это не твоё одностороннее решение. Точки эскалации — это не признак недоверия, а управленческий договор о том, где заканчивается автономность. Без них сотрудник либо тянет до последнего, скрывая нарастающую проблему, либо бегает к вам с каждым чихом.</p> <p>И наконец, элемент, который упускают чаще всего: об изменении полномочий должны знать окружающие. Если сотрудник получил право принимать решения, но коллеги и смежные команды об этом не в курсе — его будут воспринимать как самозванца. Каждое его решение будет оспариваться, каждое действие — вызывать вопрос «а кто тебе разрешил?». Информирование окружения — не бюрократия, а завершающий акт делегирования, без которого полномочия остаются декларацией.</p> <p>На практике передача рамки обычно происходит в разговоре с подчиненным. Важно проговорить все шесть элементов и убедиться, что человек понял их правильно. Например, сказать: «Смотри, давай сверимся. Как ты будешь действовать в следующий раз, когда встанет вот такой вопрос? Что учтёшь?» Если ответ совпадает с тем, что вы имели в виду, значит рамка передана. Если нет, лучше выяснить это сейчас до того как человек примет неверные решения.</p> <h3>Четыре способа сломать делегирование</h3> <p>Делегирование ломается не случайно — оно ломается в предсказуемых точках, и каждая из них связана с тем, что какой-то элемент рамки не был передан или был передан неправильно. Все четыре ошибки, которые я вижу регулярно, по-разному связаны с главным парадоксом этой статьи — с отношением руководителя к контролю.</p> <ul> <li><strong> Первая и самая распространённая — псевдоделегирование. </strong>Руководитель произносит слова «ты отвечаешь за проект», но при этом продолжает согласовывать каждое решение, регулярно переопределяет подход, меняет приоритеты на ходу. Сотрудник формально назначен ответственным, но фактически не принимает ни одного самостоятельного решения: он по-прежнему исполнитель, только теперь ещё и с грузом ответственности за результат, на который реально не влияет. Это та ситуация, когда контроль полностью сохранён, а делегирование существует только на словах. Демотивирует мгновенно, плюс для бизнеса несет серьезный ущерб: два сотрудника выполняют одну и ту же работу.</li> <li><strong> Вторая ошибка — ответственность без полномочий. </strong>Сотруднику поручили организовать мероприятие и сказали, что он за него отвечает. При этом каждого подрядчика нужно согласовать, каждый расход — получить одобрение, каждое решение о формате — провести через руководителя. Человек тратит большую часть энергии не на организацию мероприятия, а на получение разрешений. Результат зависит не от его компетентности, а от того, как быстро руководитель отвечает на запросы. Это не строгость и не осторожность. Это управленческая жестокость — потому что вы поставили человека в ситуацию, где он не может выполнить то, за что отвечает.</li> <li><strong> Третья ошибка — бросание. </strong>Это зеркальная крайность: руководитель передал задачу, обозначил рамку и полностью исчез. Сотрудник не получает обратной связи, не понимает, в правильном ли направлении движется, а главное — не имеет реальной точки, куда можно прийти с нарастающей проблемой. Точки эскалации были упомянуты, но они работают только тогда, когда руководитель доступен и реагирует. Особенно опасна эта ошибка для менее опытных сотрудников: они тянут до последнего, не желая выглядеть некомпетентными, и обнаруживают катастрофу, когда исправлять её уже поздно.</li> <li><strong> Четвёртая ошибка — переделегирование. </strong>Человеку дают уровень автономности, к которому он объективно не готов. Это часто случается при быстром карьерном росте: сильный специалист получает большую зону ответственности, но управленческая зрелость — умение работать с неопределённостью, принимать системные решения, управлять конфликтами приоритетов — не появляется одномоментно. Пока всё спокойно, он справляется. При первом серьёзном кризисе действует так, как умел раньше, а не так, как требует новая роль. Выход здесь в том, чтобы временно увеличить число точек эскалации: чаще сверяться и явно обозначить, в каких ситуациях нужно приходить, не дожидаясь катастрофы. Иногда нужно просто дать чуть меньше самостоятельности, пока человек не освоится.</li> </ul> <p>Все четыре ошибки — это разные формы одного и того же: несовпадения между объявленным уровнем автономии и реальной управленческой конструкцией вокруг неё. Делегирование было произнесено, но не было выстроено.</p> <h3>Управление — это не про то, чтобы быть самым большим растением в теплице</h3> <p>Вернёмся к парадоксу, с которого мы начали. Руководитель, который контролирует каждый шаг, не управляет — он раб системы, которую сам же и создал. Систему, в которой ничего не происходит без его ведома, ничего не решается без его участия, и каждый человек в команде постепенно привыкает не думать, а приносить полуфабрикаты на согласование. Чем дольше эта система работает, тем увереннее руководитель в том, что без него всё рухнет. И он прав — рухнет. Но не потому что люди слабые, а потому что он никогда не давал им возможности быть сильными.</p> <p>Делегирование — это выход из этого замкнутого круга. Не потому что вы «отпускаете контроль» и надеетесь на лучшее, а потому что вы заменяете ручное управление каждым решением на конструкцию, которая работает без вашего ежеминутного участия. Цель, принципы, границы, ресурсы, точки эскалации — это и есть система управления. Всё остальное — только контроль.</p> <p>Правильно выстроенное делегирование — это управленческий навык, а не врождённая черта и не следствие должности. Он требует осознанности, точности и готовности вложить время в начале, чтобы не терять его многократно потом. Но главное — он требует честного ответа на вопрос, который большинство контролирующих руководителей себе не задают: вы держите всё в своих руках потому, что так лучше для команды, — или потому, что так спокойнее лично вам?</p> <p>#IMAGE_234676#</p> В статье расскажу, почему постоянный контроль разрушает команду и как выстроить делегирование эффективно. Парадокс … article Алексей Кирсанов, руководитель отдела разработки ”1С-Битрикс” https://www.itweek.ru/themes/detail.php?ID=234674 Wed, 15 Apr 2026 16:43:33 +0300 <p>Компания «Индид», российский разработчик решений в области защиты айдентити, представила новую версию системы управления доступом и многофакторной аутентификации — Indeed Access Manager 9.4 (Indeed AM). Ключевые обновления расширяют сценарии аутентификации, усиливают безопасность доступа и делают работу с системой удобнее как для администраторов, так и для пользователей.</p> <p>В новой версии Indeed Access Manager 9.4 стал доступен расширенный список поддерживаемых каталогов пользователей, включая ALD Pro, Samba DC, РЕД АДМ и FreeIPA. Это позволяет интегрировать решение в инфраструктуру заказчика без сложных доработок и при этом сохранять привычные процессы управления учетными записями, что особенно актуально для компаний в условиях импортозамещения. Настройка каталогов выполняется через мастер конфигурации, сокращая время развертывания решения. В результате администраторы получают централизованный контроль над пользователями и группами, а сотрудники — удобный и безопасный доступ к корпоративным ресурсам.</p> <p>Отдельное внимание в Indeed AM 9.4 компания «Индид» уделила развитию модулей интеграции. Обновления позволяют гибче управлять доступом и повышать устойчивость системы без изменения существующей архитектуры. Так, в модуле Identity Provider появилась возможность настраивать политики доступа на уровне отдельных бизнес-приложений. Это дает администраторам больше контроля и позволяет учитывать требования конкретных сервисов при управлении доступом. Также реализован сценарий смены доменного пароля при входе, что упрощает аутентификацию для пользователей, у которых нет прямого доступа к доменной рабочей станции.</p> <p>Развитие получили и модули входа в систему: Linux Logon теперь поддерживает многофакторную аутентификацию с использованием RFID-карт и считывателя IronLogic Z-2 USB, а также работу через балансировщик нагрузки. Это одновременно расширяет варианты подтверждения входа, повышая уровень защиты рабочих станций и позволяет распределять нагрузку при аутентификации, делая более отказоустойчивой систему. Кроме этого, в модуле Windows Logon реализовано кеширование учетных данных, благодаря чему пользователи могут входить в систему даже при отсутствии подключения к сети. Администраторы при этом могут гибко управлять сроками действия аутентификаторов и хранения сессий. Дополнительно поддержана аутентификация с использованием RFID-карт, что повышает безопасность доступа.</p> <p>Новая версия продукта также расширяет возможности мастера конфигурации Indeed Access Manager. С его помощью можно устанавливать компоненты системы сразу на несколько физических или виртуальных серверов, при этом для каждого хоста мастер формирует отдельный набор конфигурации. Такой подход позволяет разворачивать и обновлять программный комплекс сразу в продуктовой конфигурации, сокращая время его установки и объем ручных настроек.</p> <p>В Indeed AM 9.4 разработчик добавил возможность устанавливать Indeed Key Server прямо через мастер конфигурации. Это упрощает процесс внедрения и снижает вероятность ошибок при установке, поскольку настройка сервера вынесена на отдельную страницу мастера. Indeed Key Server позволяет пользователям проходить аутентификацию с помощью push-уведомлений и одноразовых паролей, а с выходом новой версии этот сценарий стал доступнее для внедрения и использования.</p> <p>Еще одним улучшением стали новые сценарии аутентификации, которые делают подтверждение входа одновременно удобнее и безопаснее. В частности, в системе появился новый провайдер — Indeed AM eXpress Provider, позволяющий входить в корпоративные приложения через мессенджер eXpress с помощью push-уведомлений. Такой подход снижает зависимость от одноразовых кодов и упрощает пользовательский опыт, сохраняя при этом высокий уровень защиты.</p> <p>«Развивая Indeed Access Manager, мы в первую очередь стремимся совершенствовать сам подход к защите айдентити, помогая компаниям повышать уровень безопасности без усложнения сценариев его использования и дополнительной нагрузки на инфраструктуру. В новой версии 9.4 мы сосредоточились на практических задачах заказчиков: упростили внедрение и развертывание продукта, обеспечили более быструю интеграцию Indeed AM в инфраструктуру компаний, работающих в разных средах, а также добавили новые возможности аутентификации, которые делают работу пользователей удобнее. Такой подход помогает организациям выстраивать устойчивую систему управления доступом в условиях растущих угроз, эффективно использовать уже внедренные решения и последовательно повышать зрелость процессов безопасности», — отметил Николай Ильин, руководитель продукта Indeed AM компании «Индид».</p> Компания «Индид», российский разработчик решений в области защиты айдентити, представила новую версию системы управления … message https://www.itweek.ru/themes/detail.php?ID=234673 Wed, 15 Apr 2026 16:42:41 +0300 <p>Компания «Интерпроком» объявила о выходе платформы «АКСИОМА-М», которая предназначена для быстрой и эффективной разработки мобильных приложений, что позволяет предприятиям ускорить цифровую трансформацию в условиях дефицита ИТ-кадров.</p> <p>Создание платформы стало еще одним важным шагом в развитии экосистемы средств разработки ЕАМ-платформы «АКСИОМА». «АКСИОМА-М» обеспечивает единые стандарты разработки, гибкую кастомизацию интерфейсов и позволяет создавать качественные приложения с меньшими затратами, оперативно улучшая пользовательский опыт в соответствии с меняющимися ожиданиями клиентов.</p> <p>«Ускорение цифрового бизнеса становится серьёзным вызовом для ИТ-руководителей: необходимо резко увеличить скорость разработки при дефиците кадров и оптимизации затрат. „АКСИОМА-М“ решает эту задачу, позволяя создавать приложения с помощью инструментов с минимальным кодом, что снижает нагрузку на разработчиков и ускоряет вывод продуктов на рынок», — подчеркнул Леонид Винокуров, вице-президент по развитию бизнеса компании «Интерпроком».</p> <p>Возможность быстро модернизировать устаревшие приложения и внедрять новые современные цифровые решения создает условия для повышения внутренней эффективности предприятия, ускорения инноваций и трансформации рабочих процессов.</p> <p>Платформа позволяет создавать как прогрессивные веб-приложения (PWA), так и нативные мобильные приложения любого уровня сложности, используя единую кодовую базу. Создав прикладное ПО один раз, заказчик может развернуть его на различных мобильных платформах. </p> <p>«АКСИОМА-М» построена на основе трёхуровневой архитектуры, обеспечивающей разделение ответственности между отображением, логикой и данными. В ней реализованы два режима работы: мобильный онлайн-клиент для любой системы на базе «АКСИОМА» и автономная мобильная платформа для работы без доступа к сети. </p> <p>Интерфейсы приложений создаются с помощью быстрой визуальной сборки из готовых подключаемых компонентов и шаблонов. </p> <p>«АКСИОМА-М» поддерживает работу мобильных устройств под управлением отечественной операционной системы, обеспечивает многоуровневую безопасность, консолидацию платформ разработки, автоматизированное тестирование, мультиязычность, возможность использования NFC, QR-кодов и штрихкодов, предоставляет встроенный бэкенд-сервис для подключения к REST/SOAP API, базам данных и унаследованным системам и ряд других возможностей. </p> <p>Платформа обеспечивает весь жизненный цикл разработки, что позволяет предприятиям быстро внедрять мобильные решения, сокращать затраты и обеспечивать бесперебойную работу сотрудников даже при отсутствии сети.</p> <p>«АКСИОМУ-М» отличают универсальность, архитектурная прозрачность, адаптивность и простота разработки, что гарантирует получение целевого результата быстро, эффективно и качественно.</p> Компания «Интерпроком» объявила о выходе платформы «АКСИОМА-М», которая предназначена для быстрой и эффективной … message https://www.itweek.ru/themes/detail.php?ID=234672 Wed, 15 Apr 2026 16:39:44 +0300 <p>Группа Rubytech объявила о выпуске новой Машины серверной виртуализации Скала^р МДИ.В, которая пополнила линейку программно‑аппаратных комплексов (ПАК) динамической инфраструктуры и пришла на смену Машине Скала^р МВ.С. Новинка воплощает следующее поколение Машин с обновленным стеком технологий: она более производительна, универсальна и современна по сравнению с предшественником.</p> <p>Скала^р МДИ.В — это ПАК виртуализации для высоконагруженных корпоративных и государственных информационных систем, который помогает заказчикам эффективно запускать десятки и сотни виртуальных серверов на одном оборудовании — без потери скорости и надежности. Интегрированное ИТ-решение включает в себя уже успешно апробированные разработки. Аппаратную часть ПАК составляют серверы" на производственных процессорах нового поколения. Программная платформа Basis Dynamix Standard отвечает за создание отказоустойчивой среды виртуализации. Все компоненты продукта протестированы на совместимость, а поддержка осуществляется по принципу «одного окна».</p> <p>Платформа позволяет наращивать мощности по мере роста бизнеса: добавлять новые серверы и хранилища без остановки работы. Это похоже на расширение офиса без прерывания рабочего дня — новые помещения подключаются незаметно для сотрудников и клиентов. Система надежно защищает данные: если один сервер выходит из строя, работа автоматически переносится на другой, и пользователи даже не замечают сбоя. Данные дублируются в разных местах, а в случае крупной аварии, например отключения электричества в дата‑центре, бизнес может быстро переключиться на резервные площадки в других регионах.</p> <p>ПАК серверной виртуализации Группы Rubytech подойдет для самых разных задач. Он эффективно работает с корпоративными системами — ERP, CRM, базами данных, — обеспечивая их стабильную работу даже при пиковых нагрузках. Кроме того, система отлично справляется с ресурсоемкими сервисами: например, с видеоаналитикой, онлайн‑трансляциями или обработкой больших данных. Она обрабатывает потоки информации в режиме реального времени, что критически важно для современных бизнес‑процессов.</p> <p>Гибкость новой Машины серверной виртуализации заключается в ее совместимости с разными типами хранилищ данных — как с классическими аппаратными СХД, так и с современными легко масштабируемыми гиперконвергентными программно-определяемыми хранилищами. Заказчик может начать с небольшого кластера, а затем постепенно модернизировать инфраструктуру без замены всего оборудования. Управлять всей этой сложной системой можно из единого центра через простой веб‑интерфейс или программные инструменты Скала^р Геном и Базис.vControl. Администраторы видят состояние всех серверов, хранилищ и виртуальных машин в одном окне и могут оперативно реагировать на любые изменения.</p> <p>Безопасность Машины Скала^р МДИ.В соответствует строгим государственным стандартам: встроенные инструменты защиты Базис.VirtualSecurity, Avanpost FAM и «Соболь» надежно ограждают данные от несанкционированного доступа. Платформа соответствует требованиям ФСТЭК России и обеспечивают возможность хранения и обработки информации в государственных информационных системах до 1 класса защищенности включительно, в информационных системах персональных данных при необходимости обеспечения 1 уровня защищенности персональных данных, значимых объектах критической информационной инфраструктуры <nobr>1-ой</nobr> категории значимости.</p> <p>Машина Скала^р МДИ.В работает в <nobr>5–6</nobr> раз быстрее аналогов при использовании современных технологий хранения данных (HCI‑режим). Это значит, что операции ввода-вывода, которые раньше занимали минуту, теперь выполняются за <nobr>10–12 секунд.</nobr> При тестировании на сверхбыстрых дисках (NVMe) система показала рекордную скорость обработки — 2 миллиона операций в секунду. Для бизнеса это выливается в мгновенные ответы для клиентов, формирование отчетов за секунды вместо минут и бесперебойную работу сервисов даже в периоды пиковых нагрузок.</p> <p>Простота внедрения в текущую ИТ-инфраструктуру заказчика тоже играет важную роль: все настраивается и запускается автоматически, без многонедельной ручной настройки. Высококвалифицированные специалисты сопровождают решение на всех этапах — от поставки до эксплуатации.</p> <p>Успешные практические внедрения подтверждают заявленные преимущества Скала^р МДИ.В. Платформа не только соответствует заявленным техническим характеристикам, но и уже доказала свою эффективность в реальных проектах. Например, ПАК стал основой Машины специализированных банковских систем Скала^р МСП.БС и успешно прошел испытания на отраслевом полигона ИЦК «Финансы» по направлениям процессинга и АБС. Это позволило подтвердить стабильность Машины серверной виртуализации в условиях высокой нагрузки и соответствие строгим требованиям банковского сектора. Кроме того, Скала^р МДИ.В выступила технологической основой для виртуального КБ — специализированного решения для конструкторских бюро, анонсированного Группой Rubytech в марте 2026 года.</p> <p>«Скала^р МДИ.В — это не просто замена старой модели, а настоящий шаг вперед в развитии ИТ‑решений виртуализации серверной инфраструктуры. Мы пошагово формируем технологическую основу следующего поколения технологий виртуализации, призванную стать краеугольным камнем будущей ИТ‑инфраструктуры, — отметил Сергей Маркевич, владелец продукта Скала^р МДИ.В (Группа Rubytech). — Созданный нами ПАК позволяет бизнесу и госорганам строить гибкую, быструю и безопасную инфраструктуру. Он растет вместе с задачами компании и не требует постоянных вложений в модернизацию: компании экономят на оборудовании, поскольку нет необходимости покупать избыточные мощности „про запас“. Наращивание происходит точечно, по мере необходимости».</p> Группа Rubytech объявила о выпуске новой Машины серверной виртуализации Скала^р МДИ.В, которая пополнила линейку … message https://www.itweek.ru/themes/detail.php?ID=234671 Wed, 15 Apr 2026 16:37:02 +0300 <p>BSS добавила поддержку LoRA (Low-Rank Adaptation) в инструмент для обучения моделей NLU Suite. Теперь можно обучать языковые модели под локальные задачи быстрее, дешевле и даже при сильно ограниченных мощностях.</p> <p>Вместо полного переобучения модели LoRA позволяет добавить к ней «блок» под нужды клиента. В итоге обучается не исходная модель, а небольшие матрицы, которые на нее накладываются. Это позволяет создать <nobr>LLM-эксперта</nobr> в заданной области гораздо быстрее, чем при традиционном тюнинге.</p> <p>Для запуска достаточно обеспечить сервер и данные для обучения. Обучающие корпуса можно подготовить с нуля в NLU Suite с помощью любой мощной модели — например, GPT-5. Параметры дообучения можно выставить по умолчанию или настроить в процессе работы. Так можно настраивать как полные модели, так и квантизированные (сжатые) модели.</p> <p>Качество ответов после дообучения в среднем растет на 15%. При этом обученные компактные модели с меньшей памятью (1 млрд параметров) обгоняют необученные большие <nobr>(27–30 млрд)</nobr> на целевых запросах. А разница в качестве обученных компактных (1 млрд) и обученных средних (9 млрд) моделей составляет лишь <nobr>5–10%.</nobr> Это значит, что даже при ограниченных ресурсах можно получить эффективную специализированную модель.</p> <p>Обновление затрагивает и пользовательский опыт: упростилась загрузка обучающих и тестовых датасетов, обновился интерфейс для сравнения результатов, появилось автоматическое восстановление задач при сбоях.</p> <p>Как новое решение может повлиять на бизнес, рассказал директор департамента голосовых цифровых технологий BSS Александр Крушинский: «Наше решение сокращает стоимость и сроки внедрения, а также снижает зависимость от специалистов по дообучению моделей — то есть, повышает доступность использования <nobr>LLM-технологий</nobr> в бизнесе».</p> BSS добавила поддержку LoRA (Low-Rank Adaptation) в инструмент для обучения моделей NLU Suite. Теперь можно обучать языковые … message https://www.itweek.ru/themes/detail.php?ID=234669 Wed, 15 Apr 2026 10:08:37 +0300 <p>В мире мобильной безопасности существует устойчивое заблуждение: если приложение при запуске проверило, есть ли на устройстве root или джейлбрейк, значит, можно выдохнуть. Но это только видимость безопасности — создается иллюзия защиты, но профессионалы знают, что хакеры обходят примитивные проверки за минуты, используя инструменты, которые сегодня доступны буквально каждому.</p> <h3>Кто в группе риска</h3> <p>Взгляд со стороны злоумышленника всегда помогает понять, почему одни приложения атакуют постоянно, а другие обходят стороной. Хакеры идут за деньгами и вниманием государства. Основная масса атак приходится на финансовый сектор — банковские приложения остаются наиболее привлекательной целью. Следом идут приложения госорганов и «Госуслуги»: здесь цель — шпионаж и персональные данные. Замыкают список маркетплейсы и ритейл. Это обусловлено не только «ликвидностью» целей, но и темпом разработки: чем чаще обновляется приложение и чем больше в нем функций, тем выше вероятность человеческой ошибки в коде, которую и эксплуатируют хакеры.</p> <p>Однако было бы ошибкой считать, что приложения вне этих категорий никому неинтересны. Внутренние корпоративные приложения — обходчики, проводники, CRM-системы для сотрудников банков — сами по себе не слишком популярны, зато дают прямой доступ к критически важной части инфраструктуры. Такие цели для атакующих особенно интересны именно потому, что их защищают хуже.</p> <p>Чтобы понять, как именно используется root-доступ, важно посмотреть на ситуацию глазами злоумышленника. Root — это важный инструмент: он позволяет свободно анализировать приложение, перехватывать его работу и вносить изменения в код и поведение. С его помощью хакер ищет уязвимости, изучает взаимодействие с API, создает модифицированные версии приложения или вредоносные клоны.</p> <p>Почему через такие сценарии реализуются основные типы атак? Во-первых, финансовая выгода<strong>.</strong> Root-доступ позволяет модифицировать клиентское приложение (например, отключать проверки или менять параметры операций), проксировать трафик и работать с API от имени пользователя, а также создавать вредоносные клоны. Все это может приводить к хищению средств или злоупотреблению функциональностью сервиса. API часто защищают хуже, чем классические веб-приложения, и вероятность найти там серьезную уязвимость выше.</p> <p>Во-вторых, доступ к конфиденциальной информации<strong>.</strong> Внутренние приложения сотрудников — это точка входа в инфраструктуру компании. Если злоумышленник действует осторожно и только читает хранимые данные, шансы заметить такую утечку стремятся к нулю.</p> <p>В-третьих, манипуляция клиентской частью<strong>.</strong> В играх, ритейле и соцсетях злоумышленнику часто не нужен доступ к серверу, достаточно контролировать поведение приложения на устройстве. Это позволяет использовать ботов, накручивать показатели или обходить ограничения.</p> <p>В таких сценариях root-детекция играет важную роль — но не как универсальный барьер от взлома, а как один из сигналов о небезопасной среде исполнения.</p> <h3>Как хакеры «снимают замок»: типовой сценарий атаки</h3> <p>Есть несколько способов взлома. Например, разведка — при ней хакер запускает приложение и смотрит логи, трафик, подключает отладчик (Frida/Xposed). Он ищет момент, когда приложение «падает» или выдает сообщение о несовместимости. На этом этапе собирается информация о том, какие проверки сработали.</p> <p>Другой вариант — перехват управления<strong>.</strong> Самая популярная техника — хукинг (hooking). Хакер перехватывает вызов функции checkRoot(), заставляет ее всегда возвращать «все чисто» и идет дальше. Фреймворк Frida позволяет сделать это одной строкой JavaScript — без пересборки приложения.</p> <p>Еще один способ — имитация<strong>.</strong> Вместо перехвата хакер может просто скопировать приложение в изолированную среду (VirtualApp, Island) и подменить системные вызовы. Это позволяет эмулировать «чистое» устройство, пока приложение работает в виртуальном контейнере.</p> <p>Самый опасный сценарий — патч (изменение кода)<strong>.</strong> Если скрыть файлы или перехватить функцию не получается, хакер вскрывает код приложения, вшивает заплатку и пересобирает его заново. Приложение запускается, выглядит так же, работает так же — но слепой зоны, куда смотрела защита, уже нет.</p> <p>Заплатка при этом может быть крайне простой: например, подменять сервер, с которым должно взаимодействовать приложение, на прокси злоумышленника. Трафик перенаправляется через атакующего, который сохраняет логины и пароли, подменяет реквизиты и суммы в транзакциях. Заметить, что что-то идет не так, почти невозможно — в этом и состоит опасность качественных клонов: атакующему достаточно добавить минимальный вредоносный код, а не разрабатывать похожее приложение с нуля.</p> <h3>Самые популярные, но уже бесполезные методы защиты</h3> <p>Многие разработчики до сих пор используют подходы к root-детекции, которые кочуют из проекта в проект. Проблема в том, что они работали несколько лет назад, а сегодня хакеры обходят их автоматически.</p> <p>Например, разработчики могут писать детекты самостоятельно без достаточной экспертизы<strong>.</strong> Важно постоянно находиться в инфополе и знать про современный инструментарий атакующих. Человек вне контекста сделает слабую проверку, которую сломают публично доступные автоматические инструменты — те, которыми пользуются даже школьники.</p> <p>Использовать Open Source-решения сегодня — тоже не лучшая идея<strong>.</strong> Это может быть временной мерой для стартапа, но не путь серьезной организации с тысячами клиентов. В Open Source встречаются неплохие реализации, но все они на порядок проще обходятся, чем коммерческие решения.</p> <p>Если вы думаете, что экспертизу способен заменить ИИ и можно «навайбкодить защиту» — это большое заблуждение. ИИ обучен на небезопасном большинстве, поэтому и выдаст дырявую реализацию защиты. Например, пришьет к приложению давно устаревшую библиотеку RootBeer — формально защита есть, но она давно не является препятствием даже для простых инструментов анализа. Вайбкодинг будет полезен только в руках эксперта.</p> <p>Само понятие root-детекции при этом не устарело, но инструментарий хакеров настолько усовершенствовался, что полагаться только на один тип проверок бесполезно. В современных протекторах применяется совокупность десятков различных проверок, каждая из которых, например проверка root, реализована множеством способов.</p> <h3>Как построить лабиринт для хакера</h3> <p>Главный враг атакующего — время. Если код превращен в непроходимый лабиринт, злоумышленник, скорее всего, уйдет к более легкой цели. В действительности работают несколько направлений.</p> <p><strong>Применять одновременно защиту от статического и динамического анализа.</strong> Недостаточно просто накрыть код обфускатором или добавить всевозможные детекты во время запуска (RASP, runtime application self-protection). Хакер не будет выбирать только один путь атаки, поэтому и защищать нужно сразу с двух сторон.</p> <p><strong>Не делать ставку только на одну технику.</strong> Некоторые считают, что достаточно реализовать только хорошее шифрование кода или только детальный детект root-прав — и злоумышленник не преодолеет защиту. На практике атакующий будет пробовать множество обходных путей. Правильный подход — внедрять как можно больше различных техник, чтобы их совокупность давала синергетический эффект: разные техники не просто закрывают дыры, но и защищают друг друга по принципу 1+1>2.</p> <p><strong>Не экономить на старте.</strong> В безопасной разработке есть принцип shift left: чем раньше обнаружена уязвимость, тем дешевле ее исправление. Но на практике самые «ранние» практики — самые дорогие. Для начинающей команды разумнее двигаться «справа»: поставить WAF и протектор, а уже потом по мере зрелости идти влево, получая максимальный результат на всем пути.</p> <p><strong>Увеличивать стоимость ручного анализа.</strong> Самый дорогой и долгий этап для хакера — ручная работа: обход анти-реверса, изготовление клонов, поиск уязвимостей, разработка бота. Автоматизировать можно очень многое, особенно с помощью ИИ. Поэтому выгодно именно этот этап делать максимально дорогим: увеличивая стоимость реверс-инжиниринга, мы увеличиваем стоимость любой атаки — не только некоторых. Наличие даже базовой проверки увеличивает трудозатраты атакующего. Но коммерческий протектор может увеличить их буквально на порядки — в десятки и сотни раз — в то время как примитивная защита автоматически ломается инструментами, доступными каждому.</p> <p><strong>Внедрять защиту на стороне клиента.</strong> С точки зрения корпоративной инфраструктуры взлом через скомпрометированное приложение на устройстве сотрудника выглядит как обычное поведение — то же устройство, то же приложение, только аномальная активность может насторожить службу безопасности. Поэтому важно внедрять защиту непосредственно на устройство и в сами приложения.</p> <h3>Как понять, что ваше приложение атакуют</h3> <p>Рекомендация здесь стандартная: любые аномалии — повод что-то заподозрить. Приложение начало тормозить, открываться или закрываться самостоятельно, появились проблемы с соединением. Обнаружились подозрительные транзакции или новые сессии с незнакомых устройств — это можно проверить в настройках социальных сетей и мессенджеров. Также стоит обращать внимание на специальные ссылки в мессенджерах: приложения умеют их обрабатывать, и такая ссылка может быть способом атаковать приложение.</p> <p>За более чем десять лет в анализе защищенности мобильных приложений наши эксперты проверили вручную более 2000 приложений. За все это время только один раз встретилось по-настоящему хорошо защищенное приложение. Хотя оно не помешало найти критическую уязвимость, в полной мере преодолеть его защиту за время, отведенное на проект, не удалось. Все остальные приложения всегда поддавались анализу. Подавляющее большинство либо никак не были защищены, либо обход защиты происходил с использованием публично доступных автоматических инструментов. Лишь изредка возникала необходимость прибегать к ручному анализу.</p> <p>Вывод один — root-детекция работает только тогда, когда реализована правильно и в совокупности с другими техниками. Приложение, которое полагается на единственную проверку, только задержит хакера, но не сможет его остановить.</p> <p>#IMAGE_234670#</p> В мире мобильной безопасности существует устойчивое заблуждение: если приложение при запуске проверило, есть ли … article Николай Анисеня, руководитель разработки PT MAZE, Positive Technologies